STPA 기법을 활용한 위험분석 방법 (1)
작성자
관리자
작성일
2022-01-26 17:49
조회
885
1. STPA 개념 및 특징
STPA(System Theoretic Process Analysis)는 STAMP(System-Theoretic Accident Model and Processes)을 기반으로 하는 위험분석 기법으로, 시스템 생명주기 모든 과정에 걸쳐 존재하는 잠재적인 위험과 발생 원인을 시스템의 상위 수준에서 분석하는 기법이다.
STPA는 위험(Hazard)을 특정 기능의 실패나 컴포넌트 오류 문제로 인식하기 보다는 시스템과 시스템 또는 구성요소들 간 제어 문제(Control Problem)에서 발생함을 기본 전제로 한다. 이 때, 시스템 구성요소는 하드웨어나 소프트웨어와 같은 시스템 뿐만 아니라 인력, 사회조직, 제도 등으로 다양할 수 있다
STPA 기반 위험분석은 시스템을 제어 관계 관점에서 분석하고 해당 제어 관계 중 위험을 유발할 수 있는 부적절한 제어를 식별하는 방식으로 이루어진다. 사고 정의에서 시작하여 원인 시나리오(Causal Scenario) 도출을 수행하는 하향식 분석 체계를 가지며, 크게 4 단계로 구성된다.
[참고] STAMP(System-Theoretic Accident Mode and Processes)는 시스템 이론(Systems Theory)에 기반한 사고 분석 모델 및 프로세스이다. STAMP는 FTA, FMEA, ETA와 같은 분석 기법(Analysis)이기 보다는 거시적 관점에서 사고의 원인을 구조화하고 식별하는 관점과 절차를 제시하는 모델이자 프로세스라 볼 수 있다.
STAMP에서 사고의 원인을 바라보는 관점은 기존의 위험분석 기법에서 제시하는 관점과 큰 차이가 있다. ‘chain of event’ 모델을 기반으로 하는 기존의 분석 기법은 특정 기능이나 컴포넌트의 결함, 동작 실패(failure), 특정 이벤트에서 사고가 기인한다고 본다. 그러나 STAMP 에서는 사고의 발생 원인을 단순히 특정 이벤트나 기능 실패의 문제로 바라보지 않는다. STAMP에서는 시스템을 구성하는 컴포넌트 간 제어문제(control problem)에서 사고가 발생 한다고 본다. 또한, STAMP에서는 사고의 원인이 시스템 그 자체 뿐 아니라, 시스템에 관여된 인력, 사회적·조직적 구조, 제도·정책 등 복합적 상호작용에서 비롯된다고 간주한다. 따라서 사고를 분석할 때는 ‘왜 시스템 동작이 실패했고, 동작 실패가 어떻게 사고로 이어지게 되었는가?’ 의 관점에 국한하기 보다는 ‘사고가 일어나지 않도록 방어하거나 그 영향을 최소화할 수 있는 적절한 제어(control)가 왜 이루어지지 않았는가? 또는 왜 부적절한 제어가 일어났는지?’ 와 같은 관점에서 분석을 수행한다.
2. STPA 절차
STPA를 활용한 위험분석은 크게 4단계로 수행된다
2-1. 1 단계: 사고 및 위험 정의
1 단계는 STPA 위험 분석 목적이 어떠한 종류의 사고 (인명 피해, 환경오염, 임무실패, 막대한 재산 손실 등)를 예방하기 위한 것인지 결정하고, 분석 대상이 되는 시스템 범위를 결정하는 단계이다. 분석 목적에 대한 정의는 다시 사고 정의, 시스템 수준 위험 정의, 시스템 수준 안전 제약사항 도출 등 세부 단계로 구분된다.
2-2. 2 단계: Control Structure 도식화
Control loop 형태를 띄며 제어의 관점으로 주체(Controller)와 객체(Controlled Process), 그리고 제어(Control Action)와 반응(Feedback)으로 구성된다. Controller는 Controlled Process를 컨트롤 하기 위한 내부 알고리즘과 Process Model을 포함한다. 여기서 Process Model이란 Controller가 Control Action을 보내기 위해 사용하는 정보, Controlled Process의 상태, 주변 환경의 상태, 다른 시스템 구성요소의 상태 등을 포함한다.
일반적인 형태의 Control Loop
Control Structure 모델링은 앞서 정의한 위험(Hazard)을 예방하고 Safety constraint를 유지하기 위해 필요한 서브시스템을 식별하여 수행한다. 복잡하게 얽힌 서브시스템을 보다 쉽게 식별하기 위해서는 시스템을 추상화 하여 모델링하는 것이 필요하다.
2-3. 3 단계: Unsafe Control Actions 도출
Unsafe Control Action(UCA)은 시스템의 위험을 유발할 수 있는 Control Action의 불안전한(Unsafe) 형태를 의미한다. 2 단계에서 정의한 모든 Control Action이 UCA 도출의 대상이 될 수 있으며, 분석의 목적과 범위에 따라 특정 Control Action 만을 대상으로 UCA를 도출할 수도 있다. Control Action에서 UCA를 도출하기 위해서는 크게 두 가지 요소가 필요하다. Controller가 Control Action을 제공하는 형태와 해당 Control Action이 행해지는 특정 상황 또는 조건(Context)이 그것이다. Control Action이 불안전할 수 있는 형태는 크게 4가지 타입으로 분류된다.
위험을 유발할 수 있는 불안전한(Unsafe) Control Action의 4가지 타입
시스템의 위험은 단순히 Control Action 제공 형태에 따라 발생하지 않으며, Control Action이 제공되는 시점의 시스템 및 시스템의 주변 환경 조건에 따라 위험이 발생할 수 있다. 이러한 정보를 Context로 정의하고, 4가지 타입의 Control Action을 조합하여 UCA를 도출한다.
2-4. 4 단계: 원인 시나리오(Casual Scenario) 도출
3단계에서는 특정 상황이나 조건(Context)과 4가지 타입의 Control Action을 바탕으로 위험을 유발할 수 있는 UCA를 도출하였다. 4 단계에서는 위험을 유발할 수 있는 UCA가 왜 발생하는지 그 원인들을 분석한다. 원인(Causal factor)들은 Control Structure를 기반으로 직관적으로 도출할 수 있으며, 크게 두 가지 유형으로 분류할 수 있다. 첫 번째는 Control Action이 왜 불안전(Unsafe)하게 제공되었는지, 즉 Controller가 UCA를 제공한 원인이 무엇인지(1)를 도출하는 것이다. 두 번째는 제공한 Control Action이 부적절하게 수행되거나 수행되지 못한 것에 대한 원인(2)이다. 최종적으로 이러한 원인(Causal Factor)들을 토대로 하여 원인 시나리오(Causal Scenario)를 작성한다.
Causal Scenario 식별 방법
1) UCA를 유발하는 시나리오 도출
Why would Unsafe Control Actions occur?’ 에 존재하는 UCA 유발 원인은 다음과 같은 질문의 답을 통해 찾을 수 있다. ‘왜 그러한 Control Action이 제공되어(혹은 제공되지 않아서, 너무 늦거나 너무 빨리 제공되어서, 너무 오래 또는 너무 짧게 제공되어서) 위험을 유발할 수 있는가?’ 등이다. 그러한 원인들은 아래에 언급한 2가지 경우로 검토할 수 있다
① Controller 자체에 존재하는 원인(Unsafe Controller Behavior)
② 부적절한 피드백 또는 잘못된 정보
2) Control Action이 부적절하게 수행되거나 Control Action이 수행되지 않은 경우의 시나리오 식별
사고는 앞서 소개한 바와 같이 UCA의 수행으로 발생될 수도 있지만 Control Action이 부적절하게 수행되거나 수행되지 않은 경우에도 발생할 수 있다. 즉 Controller와 Controlled Process 사이에서 Control Action을 전달하는 Control Path와 Control Action이 수행되는 Controlled Process 자체에서 그 원인을 찾을 수 있다.
① Control Path에서 발생 가능한 시나리오
② Controlled Process에서 발생 가능한 시나리오
이상과 같이 STPA에 대한 개략적인 개요 및 그 수행절차에 대해 간단히 살펴보았다. 차후에 각 단계별로 좀 더 구체적으로 알아보기로 하겠다.
[출처 및 참고: STPA를 활용한 위험분석 가이드(TTA, 2018.12)]
https://blog.naver.com/vway_news/222433914560
STPA(System Theoretic Process Analysis)는 STAMP(System-Theoretic Accident Model and Processes)을 기반으로 하는 위험분석 기법으로, 시스템 생명주기 모든 과정에 걸쳐 존재하는 잠재적인 위험과 발생 원인을 시스템의 상위 수준에서 분석하는 기법이다.
STPA는 위험(Hazard)을 특정 기능의 실패나 컴포넌트 오류 문제로 인식하기 보다는 시스템과 시스템 또는 구성요소들 간 제어 문제(Control Problem)에서 발생함을 기본 전제로 한다. 이 때, 시스템 구성요소는 하드웨어나 소프트웨어와 같은 시스템 뿐만 아니라 인력, 사회조직, 제도 등으로 다양할 수 있다
STPA 기반 위험분석은 시스템을 제어 관계 관점에서 분석하고 해당 제어 관계 중 위험을 유발할 수 있는 부적절한 제어를 식별하는 방식으로 이루어진다. 사고 정의에서 시작하여 원인 시나리오(Causal Scenario) 도출을 수행하는 하향식 분석 체계를 가지며, 크게 4 단계로 구성된다.
[참고] STAMP(System-Theoretic Accident Mode and Processes)는 시스템 이론(Systems Theory)에 기반한 사고 분석 모델 및 프로세스이다. STAMP는 FTA, FMEA, ETA와 같은 분석 기법(Analysis)이기 보다는 거시적 관점에서 사고의 원인을 구조화하고 식별하는 관점과 절차를 제시하는 모델이자 프로세스라 볼 수 있다.
STAMP에서 사고의 원인을 바라보는 관점은 기존의 위험분석 기법에서 제시하는 관점과 큰 차이가 있다. ‘chain of event’ 모델을 기반으로 하는 기존의 분석 기법은 특정 기능이나 컴포넌트의 결함, 동작 실패(failure), 특정 이벤트에서 사고가 기인한다고 본다. 그러나 STAMP 에서는 사고의 발생 원인을 단순히 특정 이벤트나 기능 실패의 문제로 바라보지 않는다. STAMP에서는 시스템을 구성하는 컴포넌트 간 제어문제(control problem)에서 사고가 발생 한다고 본다. 또한, STAMP에서는 사고의 원인이 시스템 그 자체 뿐 아니라, 시스템에 관여된 인력, 사회적·조직적 구조, 제도·정책 등 복합적 상호작용에서 비롯된다고 간주한다. 따라서 사고를 분석할 때는 ‘왜 시스템 동작이 실패했고, 동작 실패가 어떻게 사고로 이어지게 되었는가?’ 의 관점에 국한하기 보다는 ‘사고가 일어나지 않도록 방어하거나 그 영향을 최소화할 수 있는 적절한 제어(control)가 왜 이루어지지 않았는가? 또는 왜 부적절한 제어가 일어났는지?’ 와 같은 관점에서 분석을 수행한다.
2. STPA 절차
STPA를 활용한 위험분석은 크게 4단계로 수행된다
| 단계 구분 | 단계 명 | 주요 수행 내용 |
| 1 단계 | 사고 및 위험 정의 | - 관련 사고 도출 - 위험 정의 - 위험을 안전 제약사항으로 변환 |
| 2 단계 | Control Structure 도식화 | - 제어 관계에 따른 개체(컴포넌트) 식별 - 제어명령, 피드백, 프로세스 모델 등 도식화 |
| 3 단계 | Unsafe Control Action 도출 | - 4가지 유형에 따른 Unsafe Control Action 도출 [4가지 유형] 1) CA is not provided 2) UCA is provide 3) CA is too early, too late, out of sequence 4) CA is stopped too soon, applied too long CA: Control Action, UCA: Unsafe Control Action |
| 4 단계 | 원인 시나리오 도출 | -Unsafe Control Action 발생 원인 도출 |
1 단계는 STPA 위험 분석 목적이 어떠한 종류의 사고 (인명 피해, 환경오염, 임무실패, 막대한 재산 손실 등)를 예방하기 위한 것인지 결정하고, 분석 대상이 되는 시스템 범위를 결정하는 단계이다. 분석 목적에 대한 정의는 다시 사고 정의, 시스템 수준 위험 정의, 시스템 수준 안전 제약사항 도출 등 세부 단계로 구분된다.
2-2. 2 단계: Control Structure 도식화
Control loop 형태를 띄며 제어의 관점으로 주체(Controller)와 객체(Controlled Process), 그리고 제어(Control Action)와 반응(Feedback)으로 구성된다. Controller는 Controlled Process를 컨트롤 하기 위한 내부 알고리즘과 Process Model을 포함한다. 여기서 Process Model이란 Controller가 Control Action을 보내기 위해 사용하는 정보, Controlled Process의 상태, 주변 환경의 상태, 다른 시스템 구성요소의 상태 등을 포함한다.
일반적인 형태의 Control Loop
Control Structure 모델링은 앞서 정의한 위험(Hazard)을 예방하고 Safety constraint를 유지하기 위해 필요한 서브시스템을 식별하여 수행한다. 복잡하게 얽힌 서브시스템을 보다 쉽게 식별하기 위해서는 시스템을 추상화 하여 모델링하는 것이 필요하다.
2-3. 3 단계: Unsafe Control Actions 도출
Unsafe Control Action(UCA)은 시스템의 위험을 유발할 수 있는 Control Action의 불안전한(Unsafe) 형태를 의미한다. 2 단계에서 정의한 모든 Control Action이 UCA 도출의 대상이 될 수 있으며, 분석의 목적과 범위에 따라 특정 Control Action 만을 대상으로 UCA를 도출할 수도 있다. Control Action에서 UCA를 도출하기 위해서는 크게 두 가지 요소가 필요하다. Controller가 Control Action을 제공하는 형태와 해당 Control Action이 행해지는 특정 상황 또는 조건(Context)이 그것이다. Control Action이 불안전할 수 있는 형태는 크게 4가지 타입으로 분류된다.
| 유형(type) | 설명 |
| Not Providing causes Hazard | (Controller가) Control Action을 제공하지 않아서 위험이 발생될 수 있음 |
| Providing causes Hazard | (Controller가) Control Action을 제공하여 위험이 발생될 수 있음 |
| Too Late, Too Soon, Out of order | (Controller가) Control Action을 제공하였으나, 너무 늦게 또는 너무 빨리, 또는 잘못된 순서로 제공하여 위험이 발생할 수 있음 |
| Stopped Too Soon, Applied Too Long | (Controller가) Control Action을 너무 이른 시점에 제공이 종료되거나, 너무 오랫동안 제공하여 위험이 발생될 수 있음 |
시스템의 위험은 단순히 Control Action 제공 형태에 따라 발생하지 않으며, Control Action이 제공되는 시점의 시스템 및 시스템의 주변 환경 조건에 따라 위험이 발생할 수 있다. 이러한 정보를 Context로 정의하고, 4가지 타입의 Control Action을 조합하여 UCA를 도출한다.
2-4. 4 단계: 원인 시나리오(Casual Scenario) 도출
3단계에서는 특정 상황이나 조건(Context)과 4가지 타입의 Control Action을 바탕으로 위험을 유발할 수 있는 UCA를 도출하였다. 4 단계에서는 위험을 유발할 수 있는 UCA가 왜 발생하는지 그 원인들을 분석한다. 원인(Causal factor)들은 Control Structure를 기반으로 직관적으로 도출할 수 있으며, 크게 두 가지 유형으로 분류할 수 있다. 첫 번째는 Control Action이 왜 불안전(Unsafe)하게 제공되었는지, 즉 Controller가 UCA를 제공한 원인이 무엇인지(1)를 도출하는 것이다. 두 번째는 제공한 Control Action이 부적절하게 수행되거나 수행되지 못한 것에 대한 원인(2)이다. 최종적으로 이러한 원인(Causal Factor)들을 토대로 하여 원인 시나리오(Causal Scenario)를 작성한다.
Causal Scenario 식별 방법
1) UCA를 유발하는 시나리오 도출
Why would Unsafe Control Actions occur?’ 에 존재하는 UCA 유발 원인은 다음과 같은 질문의 답을 통해 찾을 수 있다. ‘왜 그러한 Control Action이 제공되어(혹은 제공되지 않아서, 너무 늦거나 너무 빨리 제공되어서, 너무 오래 또는 너무 짧게 제공되어서) 위험을 유발할 수 있는가?’ 등이다. 그러한 원인들은 아래에 언급한 2가지 경우로 검토할 수 있다
① Controller 자체에 존재하는 원인(Unsafe Controller Behavior)
② 부적절한 피드백 또는 잘못된 정보
2) Control Action이 부적절하게 수행되거나 Control Action이 수행되지 않은 경우의 시나리오 식별
사고는 앞서 소개한 바와 같이 UCA의 수행으로 발생될 수도 있지만 Control Action이 부적절하게 수행되거나 수행되지 않은 경우에도 발생할 수 있다. 즉 Controller와 Controlled Process 사이에서 Control Action을 전달하는 Control Path와 Control Action이 수행되는 Controlled Process 자체에서 그 원인을 찾을 수 있다.
① Control Path에서 발생 가능한 시나리오
② Controlled Process에서 발생 가능한 시나리오
이상과 같이 STPA에 대한 개략적인 개요 및 그 수행절차에 대해 간단히 살펴보았다. 차후에 각 단계별로 좀 더 구체적으로 알아보기로 하겠다.
[출처 및 참고: STPA를 활용한 위험분석 가이드(TTA, 2018.12)]
https://blog.naver.com/vway_news/222433914560