System Engineering/SE Methodology

STPA: 시스템 안전분석 - (3) Unsafe Control Action(UCA) 식별

habana4 2025. 1. 31. 12:22
반응형

시스템 안전 분석은 점점 더 복잡해지는 현대 시스템에서 필수적인 과제가 되었습니다. 특히 소프트웨어와 복잡한 상호작용을 포함하는 시스템에서는 기존의 고장 중심 접근법으로는 충분하지 않은 경우가 많습니다. 이러한 배경에서 제안된 STPA(System-Theoretic Process Analysis)는 시스템 사고(Systems Thinking)와 제어 이론(Control Theory)을 기반으로 안전을 분석하는 강력한 도구입니다.

이번 포스팅에서는 STPA의 단계별 절차와 그 특징, 그리고 이를 활용한 반복적이고 체계적인 분석 방법에 대해 알아 보겠습니다.

반응형

 

STPA의 단계별 절차

STPA: 시스템 안전분석 - (1) 분석 목적 정의

STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링

STPA: 시스템 안전분석 - (3) Unsafe Control Action(UCA) 식별 (현재 글)

STPA: 시스템 안전분석 - (4) 손실(Loss) 시나리오 식별

 

STPA 관련글

시스템 사고를 활용한 사고 원인 분석 방법 (CAST, Causal Analysis based on System Theory, STAMP)

 

 

언세이프 컨트롤 액션(Unsafe Control Actions, UCA) 식별

STPA(System-Theoretic Process Analysis)의 세 번째 단계는 언세이프 컨트롤 액션(UCA)을 식별하는 단계입니다. 이 단계에서는 시스템의 제어 행동(Control Actions)이 어떤 조건에서 안전 제약(Safety Constraints)을 위반하여 위험한 상태를 초래할 수 있는지를 분석합니다.

 

UCA는 시스템 내에서 발생할 수 있는 사고를 예방하기 위해 반드시 파악해야 하는 중요한 요소로, 제어 실패의 다양한 유형을 통해 안전성을 위협하는 조건을 식별하는 데 중점을 둡니다.

 

 

■ STPA의 UCA와 HAZOP의 Guideword 차이점 및 상호 보완

구분 STPA의 UCA (Unsafe Control Action) HAZOP의 Guideword
분석 대상 제어 행동 (Control Action) 프로세스 변수 (온도, 압력, 유량 등)
위험 접근 방식 제어 실패 및 상호작용에 의한 위험 분석 프로세스가 정상 작동하지 않는 상태에서 위험 식별
위험 원인 시스템 내 제어 구조 및 상호작용 실패 매개변수의 변화 또는 비정상 조건
적용 범위 제어 시스템, 소프트웨어, 상호작용이 많은 복잡한 시스템 화학 공정, 제조 시스템 등 물리적 프로세스 중심
위험 분석 방법 제어 행동이 언제, 어떻게 위험을 초래하는지 조건별 분석 Guideword를 적용하여 비정상 상황을 탐색
결과 중점 제어 행동이 안전 제약을 위반하여 발생할 수 있는 손실 예방 변수의 변동으로 인한 위험 조건 예측
사례 제어 행동이 늦게 제공되어 차량이 사고를 초래함 반응기 온도가 과다 상승하여 폭발하여 위험이 증가함

 

STPA는 제어 시스템과 소프트웨어가 포함된 복잡한 시스템에 적합하며, 상호작용제어 실패를 통한 위험 분석에 강점을 가집니다. 반면 HAZOP은 물리적 프로세스에서 발생할 수 있는 비정상 조건을 탐색하는 데 적합합니다. 두 기법은 서로 다른 시스템 특성을 고려하기 때문에, 특정 프로젝트에서는 두 방법을 상호보완적으로 활용할 수 있습니다.

 

언세이프 컨트롤 액션의 정의

언세이프 컨트롤 액션(Unsafe Control Action, UCA)특정 상황과 최악의 환경에서 위험을 초래할 수 있는 컨트롤 액션입니다.

 

언세이프 컨트롤 액션은 시스템의 제어 행동이 특정 조건에서 손실(Loss)을 유발할 수 있는 경우를 의미합니다. UCA는 올바르게 작동해야 할 제어 행동이 적절하게 수행되지 않거나, 잘못된 시점이나 조건에서 수행될 때 발생할 수 있습니다.

 

■ 언세이프 컨트롤 액션 유형

UCA 유형 설명
필요한 제어 행동이 제공되지 않음
(Not Provided)
필요한 상황에서 제어 행동이 제공되지 않으면 위험 상태로 이어질 수 있습니다.
부적절한 제어 행동이 제공됨
(Provided Incorrectly)
제어 행동이 잘못된 값이나 명령으로 전달된 경우 위험이 발생합니다.
제어 행동이 너무 늦거나 너무 일찍 제공됨
(Wrong Timing or Sequence)
제어 행동이 적절한 시점에 이루어지지 않으면 안전 제약이 위반될 수 있습니다.
제어 행동이 지속되거나 멈추지 않음
(Stopped to Soon or Applied Too Long)
제어 행동이 필요 이상으로 계속 적용되거나, 필요한 타이밍보다 일찍 중단될 때 위험이 발생할 수 있습니다.

 

모든 UCA는 어떤 조건에서(어떤 컨텍스트에서) 컨트롤 액션이 안전하지 않은지 명시해야 합니다. 그런 다음 시스템 설계에서 그런 안전하지 않은 컨트롤 액션을 제거하거나 완화할 수 있는 방법을 찾을 수 있습니다. 또한 UCA를 작성함에 있어 "-일 때(when)", "-하는 동안(while)" 또는 "-하는 중에(during)"와 같은 단어를 사용하면 컨텍스트를 개발하는 데 도움이 됩니다. 

<언세이프 컨트롤 액션> = <소스> <유형> <컨트롤액션> <컨텍스트> <위험과의 연결>

 

예: 

  • <소스> : 브레이크 시스템
  • <유형> : 작동하지 않음 / 너무 빨리 작동함 / 너무 늦게 작동함 / 해제되지 않음
  • <컨트롤액션> : 브레이크 동작
  • <컨텍스트> : 정차중 승객하차

 

■ 언세이프 컨트롤 액션 특징

  • UCA가 발생하더라도 최선의 시나리오에서는 위험이 발생하지 않을 수 있습니다. 예를 들어 운전자가 즉각적으로 UCA를 인식하고 대응하면 사고를 예방할 수 있습니다. 반면, 최악의 시나리오에서는 운전자가 시간 내에 대응하지 못하거나 보호장치가 제대로 작동하지 않으면 사고가 발생할 수 있습니다. 
  • 만약 사전에 정의된 Fail-Safe 액션이 있는 경우에도 UCA 식별은 필수적입니다. Fail-Safe 액션이 의도한 대로 작동하지 않거나 충분하지 않을 수 있기 때문입니다. 
  • UCA의 각 유형별로 하나의 UCA만 존재하는 것은 아닙니다. 각 유형에 따라 UCA는 0개부터 여러 개까지 존재할 수 있습니다.
  • UCA의 유형은 위 네가지 유형 외에 추가로 특정 조건에 따라 하위 유형이 존재할 수도 있습니다.
  • 모든 UCA는 하나 이상의 시스템 수준위험과 연관되어야 합니다. 만약 관련 위험이 없다면 새로운 위험을 추가하거나 기존 위험 집합을 수정해야 합니다.
  • UCA 작성 시, 프로세스 모델의 결합을 명시하지 말아야 합니다. 예를 들어 "도어 컨트롤러가 도어 상태 정보를 잘못 송출하여 브레이크 컨트롤러가 브레이크를 동작시키지 않는다." 를 보면, 도어 컨트롤러가 도어 상태 정보를 잘못 송출하고 있다는 프로세스 모델의 결함을 명시하고 있기 때문에, 이는 "도어 컨트롤러로부터 도어 상태 정보를 수신하며, 승객 승하차 중 브레이크 동작이 작동하지 않는다." 의 형태로 수정해야 합니다.
 
 

UCA를 식별할 때 흔한 실수를 방지하는 Tip

  • 모든 UCA가 컨트롤 액션을 안전하지 않게 하는 컨텍스트를 명시하는지 확인합니다.
  • UCA 컨텍스트가 실제 상황에 대한 잠재적 가능성이 아니라 컨트롤 액션을 안전하지 않게 만드는 실제 상태 또는 조건을 명시하는지 확인합니다.
  • UCA 컨텍스트가 명확하게 정의되었는지 확인합니다.
  • UCA 컨텍스트가 포함되었는지 확인하고 미래의 영향이나 결과로 대체되지 않았는지 확인합니다.
  • 모든 UCA에 대해 UCA와 관련된 하나 이상의 위험을 문서화 하였는지 확인합니다.
  • N/A로 간주된 모든 컨트롤 액션 유형을 검토하고 적용할 수 없는 것인지 확실히 합니다.
  • 파라미터를 사용한 연속적인 컨트롤 액션의 경우, 파라미터가 과도하거나 불충분하거나, 방향이 잘못되지 않았느닞 확인합니다.
  • UCA 배후에 있는 가정이나 특별한 추론이 문서화되어 있는지 확인합니다.

 

 컨트롤러 안전 제약사항 정의

컨트롤러 안전 제약사항은 UCA를 예방하기 위해 충족되어야 하는 컨트롤러의 동작을 의미합니다. UCA가 식별되면 UCA는 각 컨트롤러의 동작에 대한 안전 제약사항으로 변환될 수 있습니다. 

 


마치며...

STPA(System-Theoretic Process Analysis)에서 언세이프 컨트롤 액션(Unsafe Control Actions, UCA) 단계에서는 제어 행동이 언제, 어떤 조건에서 안전 제약을 위반하여 위험을 초래할 수 있는지를 체계적으로 분석합니다. 이를 통해 사고로 이어질 수 있는 위험 요소를 사전에 파악하고, 예방 조치를 강화할 수 있습니다.

 

UCA 식별은 제어 행동의 네 가지 유형(제공되지 않음, 잘못 제공됨, 잘못된 타이밍, 필요 이상 지속)에 따라 다양한 위험 시나리오를 분석하고, 안전성을 위협할 수 있는 잠재적 상황을 명확히 정의하는 데 중점을 둡니다. 이 과정은 단순히 위험 가능성을 나열하는 것이 아니라, 시스템이 복잡한 상황에서도 안전 제약을 준수하도록 설계를 개선하는 데 기여합니다.

 

특히 현대의 복잡한 시스템에서는 상호작용과 제어 실패가 주요 사고 요인으로 작용합니다. STPA의 UCA 분석은 이러한 비선형적 상호작용을 고려하여, 위험 예방을 위한 실질적 설계 및 운영 개선안을 도출하는 데 도움을 줍니다.

 

결국, 언세이프 컨트롤 액션 식별 단계는 시스템의 안전성을 높이고, 위험 관리 체계를 강화하여 사고 발생 가능성을 줄이는 중요한 역할을 수행합니다. 이를 통해 시스템이 최악의 상황에서도 안정적이고 신뢰성 있게 작동하도록 돕는 안전 중심의 접근법을 실현할 수 있습니다.

 


STPA의 단계별 절차

STPA: 시스템 안전분석 - (1) 분석 목적 정의

STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링

STPA: 시스템 안전분석 - (3) Unsafe Control Action(UCA) 식별 (현재 글)

STPA: 시스템 안전분석 - (4) 손실(Loss) 시나리오 식별

 

STPA 관련글

시스템 사고를 활용한 사고 원인 분석 방법 (CAST, Causal Analysis based on System Theory, STAMP)

 

반응형