시스템 안전 분석은 점점 더 복잡해지는 현대 시스템에서 필수적인 과제가 되었습니다. 특히 소프트웨어와 복잡한 상호작용을 포함하는 시스템에서는 기존의 고장 중심 접근법으로는 충분하지 않은 경우가 많습니다. 이러한 배경에서 제안된 STPA(System-Theoretic Process Analysis)는 시스템 사고(Systems Thinking)와 제어 이론(Control Theory)을 기반으로 안전을 분석하는 강력한 도구입니다.
이번 포스팅에서는 STPA의 단계별 절차와 그 특징, 그리고 이를 활용한 반복적이고 체계적인 분석 방법에 대해 알아 보겠습니다.
STPA의 단계별 절차
- STPA: 시스템 안전분석 - (1) 분석 목적 정의
- STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링
- STPA: 시스템 안전분석 - (3) Unsafe Control Action(UCA) 식별
- STPA: 시스템 안전분석 - (4) 손실 시나리오 식별 (현재 글)
STPA 관련글
시스템 사고를 활용한 사고 원인 분석 방법 (CAST, Causal Analysis based on System Theory, STAMP)
손실(Loss) 시나리오 식별
■ 손실 시나리오(Loss Scenario)란?
손실 시나리오는 시스템이 특정 조건에서 안전 제약(Safety Constraints)을 위반하여 손실(Loss)이 발생하는 과정을 설명하는 이야기 형태의 시나리오입니다. 즉, UCA 및 위험을 초래할 수 있는 원인 요소(Causal Factor)를 기술한 것입니다. 이는 제어 실패와 프로세스 모델 결함(Process Model Flaws) 등을 통해 손실이 어떻게 발생하는지를 구체적으로 나타냅니다.
손실 시나리오는 다음과 같은 2가지 유형을 반드시 고려해야 합니다.
- 왜 언세이프 컨트롤 액션(UCA)이 발생하는가?
- 왜 컨트롤 액션이 부적절하게 실행되거나 실행되지 않아 위험을 유발하는가?
■ 손실 시나리오 식별 목적
- 손실 발생 경로 이해: 언세이프 컨트롤 액션이 어떤 과정과 조건을 통해 손실로 이어지는지 명확히 설명.
- 위험 관리 대책 마련: 사고 예방을 위해 필요한 설계 및 운영상의 개선점 도출.
- 프로세스 모델 결함 식별: 시스템이 잘못된 정보를 바탕으로 결정을 내리는 경우를 파악하여, 프로세스 모델을 개선.
1. UCA를 유발하는 시나리오 식별
이 형태의 시나리오를 만들때는 무엇이 컨트롤러로 하여금 컨트롤 액션을 제공하도록 만들었는지 설명하기 위해 UCA에서 시작하여 역으로 작업합니다.
컨트롤러와 관련된 고장(Failure)
- 컨트롤러 자체의 물리적 고장
- 전원 장애
부적절한 컨트롤 알고리즘
- 특정 컨트롤 알고리즘의 구현의 결함
- 특정 컨트롤 알고리즘 자체의 결함
- 특정 컨트롤 알고리즘이 시간이 지나면서 변경되거나 성능저하로 부적합해짐
안전하지 않은 컨트롤 입력
- 다른 컨트롤러에서 받은 UCA(다른 컨트롤러의 UCA를 고려할 때 이미 작성됨)
부적절한 프로세스 모델
- 컨트롤러가 잘못된 피드백/정보를 수신함
- 컨트롤러가 올바른 피드백/정보를 받았지만 잘못 해석하거나 무시함
- 피드백/정보가 필요한 상황이지만 컨트롤러가 이를 수신하지 못함 (지연되거나 수신되지 않음)
- 필요한 컨트롤러 피드백/정보가 존재하지 않음
UCA를 유발하는 시나리오를 식별하기 위해서는 UCA를 야기하는 안전하지 않은 컨트롤러 동작에서 시작하여 다음 그림과 같이 (1) 안전하지 않은 컨트롤러 동작과 (2) 부적절한 피드백/정보의 원인을 반드시 고려해야 합니다.
■ 안전하지 않은 컨트롤러 동작
- 컨트롤러와 관련된 실패 (물리적 컨트롤러의 경우)
- 부적절한 컨트롤 알고리즘: 컨트롤 알고리즘은 컨트롤러의 프로세스 모델, 이전 컨트롤 입/출력 및 다른 요인에 기반하여 어떤 컨트롤 액션이 선택될지를 결정합니다. 휴먼 컨트롤러의 경우 이런 컨트롤 알고리즘을 의사 결정이라고 부르기도 하며, 교육, 절차, 과거의 경험과 같은 서로 다른 요소에 의해 형성될 수 있습니다. (알고리즘 구현 결함, 알고리즘 자체의 결함, 변경에 의한 성능저하)
- 안전하지 않은 컨트롤 입력 (다른 컨트롤러로부터): 이는 이전 단계에서 다른 컨트롤러의 UCA를 식별할 때 찾아질 수도 있습니다.
- 부적절한 프로세스 모델: 프로세스 모델의 결함(flaw)은 컨트롤러의 프로세스 모델이 실제와 일치하지 않을 때 발
- 컨트롤러가 잘못된 피드백/정보를 수신함- 피드백/정보가 필요한 상황이나 컨트롤러가 이를 지연되거나 수신되지 못함
- 필요한 컨트롤러의 피드백/정보가 존재하지 않음
- 컨트롤러가 올바른 피드백/정보를 받았지만 잘못 해석하거나 무시함
■ 부적절한 피드백 및 정보의 원인
일반적으로 부적절한 피드백 및 정보와 관련된 시나리오에는 다음이 포함될 수 있습니다.
수신되지 않은 피드백 또는 정보
- 센서가 피드백/정보를 보냈지만 컨트롤러가 수신하지 않음
- 센서에 피드백/정보가 수신되거나 적용되었지만, 센서가 이를 보내지 않음
- 센서가 피드백/정보를 수신하지 않거나 적용하지 않음
- 피드백/정보가 컨트롤 스트럭처에 존재하지 않거나 센서가 존재하지 않음
부적절한 피드백 수신
- 센서가 적절하게 응답하였지만 컨트롤러가 부적절한 피드백/정보를 수신함
- 센서에 수신되거나 적용된 피드백/정보에 대하여 센서가 부적절하게 반응함
- 센서가 필요한 피드백/정보를 제공하지 못하거나 설계에 반영되지 않음
2. 컨트롤 액션이 부적절하게 실행되거나 실행되지 않는 시나리오의 식별
위험은 UCA로 인해 야기될 수도 있지만, 만약 컨트롤 액션이 부적절하게 실행되거나 실행되지 않으면 UCA 없이도 발생할 수 있습니다. 따라서 컨트롤 경로에 영향을 미치는 요인뿐만 아니라 컨트롤드 프로세스에 영향을 미치는 요인도 고려해야 합니다.
■ 컨트롤 경로와 관련된 시나리오
컨트롤 경로는 컨트롤 액션이 컨트롤러에서 액추에이터를 거쳐 컨트롤드 프로세스로 전송되는 경로를 의미합니다. 경로 상에서 문제가 발생하면 컨트롤 액션이 부적절하게 실행되거나 실행되지 않을 수 있습니다.
컨트롤 액션이 실행되지 않음
- 컨트롤러가 명령을 전송했으나 액추에이터가 수신하지 못함.
- 액추에이터가 명령을 수신했으나 반응하지 않음.
- 액추에이터가 반응했지만 명령이 컨트롤드 프로세스에 적용되지 않음.
컨트롤 액션이 부적절하게 실행됨
- 컨트롤러가 명령을 전송했으나, 부적절하게 수신됨.
- 액추에이터가 부적절하게 반응하거나 프로세스에 잘못 적용됨.
- 컨트롤 액션이 전송되지 않았지만, 액추에이터가 명령을 받은 것처럼 반응.
■ 컨트롤드 프로세스와 관련된 시나리오
컨트롤 액션이 컨트롤드 프로세스에 전달되더라도, 프로세스가 이를 제대로 처리하지 못하거나 다른 컨트롤러에 의해 무시될 수 있습니다.
컨트롤 액션이 실행되지 않음
- 명령이 프로세스에 적용되었지만 프로세스가 반응하지 않음.
컨트롤 액션이 부적절하게 실행됨
- 명령이 부적절하게 적용됨.
- 명령이 전송되지 않았으나 프로세스가 명령을 받은 것처럼 반응함.
■ 컨트롤드 프로세스와 관련된 시나리오
공격자가 시스템에 명령을 주입하여 브레이크 시스템이 "대체 브레이킹 모드"로 전환됨
흔한 실수를 예방하는 Tip
가장 흔한 실수는 시나리오가 아닌 개별적인 원인 요소를 도출하는 것이다.
예를 들어 “휠 속도 센서 고장”, “바퀴 속도 피드백 지연”, “전원 손실” 등과 같은 요인들의 목록을 만드는 유혹에 빠지는 것이다. 시나리오의 컨텍스트에서 벗어나 개별 요인을 나열하는 것의 문제는, 여러 요소가 어떻게 서로 상호작용하는지를 간과하기 쉽고 UCA와 위험을 간접적으로 야기하는 중요하지만 명확하지 않은 요인을 간과할 수 있으며 위험을 초래할 수 있는 요인들이 어떻게 조합되는지를 고려하지 않을 수 있다는 것이다. 한 가지 요소만을 고려하게 되면 필연적으로 단일 컴포넌트의 실패만 고려하는 FMEA로 축소되게 된다.
마치며...
STPA(System-Theoretic Process Analysis)의 마지막 단계인 손실 시나리오 식별은 시스템 내에서 발생할 수 있는 위험 경로를 명확히 이해하고, 사고 예방을 위한 구체적인 대책을 마련하는 데 필수적인 과정입니다. 이 단계에서는 언세이프 컨트롤 액션(UCA)이 어떻게 시스템 제어 구조와 프로세스에 영향을 미쳐 손실로 이어지는지를 체계적으로 분석합니다.
손실 시나리오를 통해 우리는 다양한 경로에서 발생할 수 있는 위험 요소를 파악하고, 최악의 상황에서도 시스템이 안전하게 작동할 수 있도록 설계를 개선할 수 있습니다. 또한, 프로세스 모델의 결함, 제어 경로의 문제, 환경적 방해 요인 등 다양한 사고 요인을 고려하여 위험 관리 체계를 강화할 수 있습니다.
특히 현대 시스템은 복잡성과 비선형적인 상호작용으로 인해 단순한 고장만으로 사고가 발생하지 않는 경우가 많습니다. 따라서 손실 시나리오 식별은 시스템 전반의 위험을 통합적으로 분석하여 사고 가능성을 줄이고, 안전 중심의 설계 문화를 정착시키는 데 중요한 역할을 합니다.
결국, 이 단계는 단순히 사고를 분석하는 데 그치지 않고, 시스템의 전반적인 안전성을 높이고 사고 예방 능력을 강화하는 데 기여합니다. 이를 통해 안전한 시스템 설계를 위한 체계적이고 실질적인 기반이 마련되며, 사람과 환경을 보호하는 신뢰성 높은 시스템을 구축할 수 있습니다.
STPA의 단계별 절차
- STPA: 시스템 안전분석 - (1) 분석 목적 정의
- STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링
- STPA: 시스템 안전분석 - (3) Unsafe Control Action(UCA) 식별
- STPA: 시스템 안전분석 - (4) 손실 시나리오 식별 (현재 글)
STPA 관련글
시스템 사고를 활용한 사고 원인 분석 방법 (CAST, Causal Analysis based on System Theory, STAMP)
'System Engineering > SE Methodology' 카테고리의 다른 글
STPA: 시스템 안전분석 - (3) Unsafe Control Action(UCA) 식별 (0) | 2025.01.31 |
---|---|
STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링 (0) | 2025.01.31 |
STPA: 시스템 안전분석 - (1) 분석 목적 정의 (0) | 2025.01.31 |
TOWS 분석: SWOT 확장으로 전략을 세우는 실질적 도구 (0) | 2025.01.27 |
SWOT 분석: 강점과 약점을 넘어 기회와 위협을 활용한 전략적 성공 비결 (0) | 2025.01.26 |