문서요약 - 영국 국방부의 시스템 안전성 관리에 대한 소개 by MOD

제목: 영국 국방부의 시스템 안전성 관리에 대한 소개(An Introduction to System Safety Management in the MOD)

저자: 영국 국방부(Ministry of Defence)

문서유형: 소책자(총 31페이지), 2011년

 

영국 국방부(MOD)의 시스템 안전성 관리에 대한 개념, 용어, 활동을 안내하는 소책자에서 1장과 2장의 주요 메시지와 8장의 내용을 요약 정리함

 

---

 

1. 서론(Introduction)

• 완벽한 안전성(perfect safety)은 드물며, 따라서 리스크가 반드시 인지되고(recognised), 이해되고(understood), 통제되어야(controlled) 한다.
• 어떤 혜택(a benefit)이 예상되는 경우에만 사람들이 안전성 리스크(safety risks)에 노출되게 되며, 이 리스크가 적절하게 통제되어야 한다.
• 안전성 관리(safety management)는 하고자 하는 뭔가를 안전하게 할 수 있도록 허용하며, 해롭다는 이유로 그것을 하는 것을 회피하는 것이 아니다.
• 안전성 관리에 모두가 관여하지만, 자원 제공 및 올바른 조직/태도/우선순위를 수립할 권한이 있는 상위 관리자(senior managers)가 핵심 역할을 하게 된다.
• MOD와 그 도급업자들(contractors)이 다양한 수준에서 안전성 관리 시스템(safety management systems)을 가져야 한다.
• 엔지니어/관리자/군사령관에 의한 전문적 판단(professional judgement)이 안전성 관리의 가장 중요한 부분이다.
• 안전성 케이스(safety case)는 안전성이 제대로 고려되었고 의사결정이 충분한 근거에 의했음을 보이는 방법을 제공한다.

 

2. 안전성(Safety)이란?

• 안전성(safety)은 사람에게 가해질 수 있는 가능한 피해(possible harm)와 관련 있다.
• 시스템의 안전성을 이해하기 위해서 시스템 하드웨어뿐만 아니라 소프트웨어, 사람, 절차적 측면, 조직적 측면을 이해할 필요가 있다. 또한 해당 시스템의 환경 및 타 시스템과의 상호작용(interactions)도 시스템의 안전성에 영향을 미친다.
• 물리적 안전성(physical safety)은 컴포넌트(what the system is)에 의존하지만 기능적 안전성(functional safety)은 시스템이 하는 일(what the system does)에 의존한다. 기능적 안전성을 평가하는 일은 가능한 실패(failures) 및 오작동(malfunctions)을 조사하기 위한 탐색적 분석(exploratory analysis)을 요구한다.
• 해저드(hazards)는 피해를 입힐 수 있는 잠재력을 가진 상황이며, 사고(accidents)는 피해를 야기하는 의도되지 않은 이벤트(unintended events)이다. 해저드가 존재한다고 해서 항상 사고로 변해 피해를 야기하는 것은 아님
• 해저드 통제(hazard control)는 유해한 조건(hazardous condition)이 발생하는 것을 예방하는 일과 이것이 사고(accident)로 가는 것을 막는 일 두 가지와 관련 있다. 식별이 안된 해저드는 평가될 수가 없고 통제 대책이 시행될 수도 없으므로 시스템의 생명주기 동안 일어날 수 있는 모든 해저드를 식별하는 것이 매우 중요
• 안전성 리스크(safety risk)는 사람이 어떤 가능한 피해에 노출된 정도의 측정치이다. 리스크는 피해의 심각도(severity)와 해당 피해가 발생할 가능성(likelihood)의 조합이다.
• 리스크는 여러 다른 안전성 이슈의 중대성(significance)을 비교하는 것을 허용하는 측정치이다.
• 사용자가 반드시 시스템 생명주기 전반에 거쳐 안전성 관리에 관여해야 한다. 즉, 적절한 안전성 요구사항(safety requirements)을 설정하는 것부터 잔여 리스크(residual risk)를 관리하고 서비스 사용 상의 문제에 대한 피드백을 주는 것까지 참여

 

2.6 사고(Accidents)와 사건(Incidents)

• 사고는 “피해를 야기하는 의도되지 않은 이벤트 또는 이벤트 시퀀스”로 정의됨. 사고는 시작 이벤트(initiating event) 또는 어떤 중간 상태(intermediate state) 라기 보다는 바람직하지 않은 결과(the undesired outcome)이다.
• 아래 그림에서 볼 수 있듯이 일부 유해 상태(hazardous states)가 존재하기 위해서는 그 전에 시작 이벤트(an initiating event)가 요구되지만 그렇지 않은 유해 상태들도 있음(이를 점선 사각형으로 표현). 마찬가지로 어떤 유해 상태가 항상 사고로 이어지는 것은 아니지만, 만일 사고가 되면 이것이 “사고 시퀀스(accident sequence)”를 구성함. 이 시퀀스가 어떤 지점에서 깨지면 사고가 없게 되고 해당 사고 시퀀스가 불완전해짐
• 사건은 “사고로 진전될 수도 있었지만 그렇지 않은 해저드의 발생”으로 정의됨. 대개 사고보다 훨씬 많은 사건이 있고, 이 둘 모두 안전성을 개선하기 위한 방법에 대한 정보를 제공할 수 있음

 

[사고 시퀀스]

 

8. 분석 기법(Analytical Techniques)

8.1 서론

• 시스템 안전성을 분석하기 위한 표준적이고 정규적인 방식은 없으며 항상 사람의 판단이 요구된다. 이 때 필요한 것은 시스템 설계 및 그 오퍼레이션이 개발됨에 따라 안전성을 고려하고 문서화하는 정돈된 접근방법(an ordered approach)이다.
• 안전성 평가(safety assessment)는 시스템 개발 전반에서의 반복적인 프로세스이다. 이 장에서 언급된 기법들이 개발 프로세스의 여러 다른 단계에서 여러 다른 깊이로 사용될 수 있다.
• 설계자는 비정상 보다는 정상적 오퍼레이션에 집중한다. 안전성 평가는 시스템이 어떻게 돌아가는지 뿐만 아니라 어떻게 실패할 수 있는지 질문해야 하며, 사고로 이어질 수 있는 가능한 이벤트 시퀀스를 결정하는데 상상력을 사용할 필요가 있다.
• 어떤 특정 해저드가 여러 가능한 원인(혼자 독립적으로 작용하거나 또는 함께 작용)을 가질 수 있으며, 동일한 해저드가 여러 다른 결과(일부는 사고가 되고 또 일부는 상대적으로 중요하지 않게됨)로 이어질 수도 있다. 리스크 평가(risk assessment)가 사고 결과에 적용되므로 특정한 해저드를 해당 해저드가 야기할 수 있는 사고로 연결시키는 것이 매우 중요

 

이 장은 안전성 평가를 위해 사용되는 몇몇 분석 기법(analytical techniques)을 소개한다(크게 아래 세 개 범주로 나눠짐).

• 해저드 식별 기법(Hazard identification techniques)
• 원인에 관한 기법(Causal techniques): 어떻게 해저드와 사고가 야기될 수 있었는지 돌아봄
• 결과에 관한 기법(Consequence techniques): 주어진 이벤트 또는 상황으로부터 가능한 결과를 식별하기 위해 앞 선 예측을 함

 

[전향적 분석 기법과 회고적 분석 기법]

 

8.2 해저드 식별 기법(Hazard Identification Techniques)

• 만일 가능한 안전성 문제가 인지되지 않으면 이를 통제하거나 그 리스크를 평가할 기회가 없게 된다. 해저드 식별은 아래를 포함한 여러 목적을 가짐
  - 안전성 요구사항(safety requirements) 설정
  - 해저드를 제거하거나 또는 통제함
  - 해저드 분석 및 리스크 평가를 위한 필수적인 선행 작업
  - 비상 및 긴급 조치를 계획
• MOD의 안전성 관리자 툴킷은 아래와 같은 여러 해저드 식별 기법에 대한 정보를 포함:
  - 해저드 체크리스트(Hazard checklist)
  - 해저드 및 운영성 연구(HAZard and OPerability Studies: HAZOPS)
  - 구조화된 What-If 기법(Structured What-If Technique: SWIFT)
  - 실패 모드 및 영향 분석(Failure Mode and Effects Analysis: FMEA)
• 가능한 해저드를 식별하기 위해 현대식의 개방적 방법을 사용하는 것이 중요하지만, 안전성 연구가 다른 수단(기 발생된 사건, 체크리스트, 설계 검토 등)에 의해 식별된 해저드도 고려해야 함. 어떤 기법이 사용되는 간에 좋은 해저드 식별은 경험과 상상력에 달려있다. 해저드 식별이 해당 타입의 시스템 또는 장비에 대해 알고 있는 사람(예, 설계자, 오퍼레이터, 유지보수자, 기타 업무전문가)의 지식과 이해에 기반해야 함

 

8.3 원인에 관한 기법(Causal Techniques)

• 어떤 알려진 해저드(최상위 이벤트)가 어떻게 야기될 수 있는지 조사하기 위한 가장 흔한 기법이 결함 트리 분석(Fault Tree Analysis: FTA)이다.
• FTA는 중복성(어떤 기능을 달성하는데 있어 둘 또는 그 이상의 방식이 있음)을 가진 시스템에 특히 유용하며, 바람직하지 않은 최상위 이벤트를 야기하는데 필요한 별도의 이벤트들을 조사하는데 유용함. 또한 여러 개의 명백히 분리된 중복 장비(예, 임무중인 전력공급장치와 대기중인 전력공급장치)에 영향을 미칠 수 있는 “종속 실패(dependent failures)”를 가진 잠재적 문제를 식별할 수도 있다.
• FTA가 정성적 분석(qualitative analysis)을 통해 가치 있는 정보를 제공하지만, 얼마나 자주 최상위 이벤트가 발생할지 추정치를 주기 위해 이벤트확률(event probabilities) 또는 이벤트율(event rates)로 정량화될 수도 있다.
• HAZOPS, SWIFT, FMEA에서 뒤쪽을 보는 부분이 원인 분석 기법이다. 신뢰성 블록 다이어그램(Reliability Block Diagram: RBD)과 원인 결과 다이어그램(Cause Consequence Diagram: CCD) 모델링 같은 다른 기법들도 어떤 정의된 이벤트의 원인(들)을 표현하는데 사용될 수 있다. 표현(representation)은 다르지만 분석 프로세스는 FTA의 분석 프로세스와 매우 유사

 

 

 

8.4 결과에 관한 기법(Consequence Techniques)

• 결과에 관한 기법은 어떤 상황 또는 이벤트가 어떻게 전개될 수 있는지 평가하는데 사용된다. 이 기법들이 가능한 결과를 탐색함(모든 결과가 피해로 귀결되는 것은 아님)
• 아래를 포함한 다수의 결과에 관한 기법이 존재함:
  - 이벤트 트리 분석(Event Tree Analysis: ETA)
  - 실패 모드 및 영향 분석(Failure Mode and Effects Analysis: FMEA)
• HAZOPS, SWIFT, FMEA에서 앞쪽을 보는 부분이 결과 분석 기법이다. 원인 결과 다이어그램(Cause Consequence Diagram: CCD) 모델링과 나비 넥타이 다이어그램(Bow-tie diagrams) 같은 다른 기법들도 시작 이벤트부터 결과까지 완전한 사고 시퀀스를 표현하는데 사용될 수 있다. 표현은 다르지만 분석 프로세스는 FTA와 ETA의 분석 프로세스와 매우 유사

 

결과 모델과 시뮬레이션(Consequence Models and Simulations)

 

많은 상황에서 결과의 규모(scale)에 대해 확신하기가 어려움. 드문 이벤트(예, 큰 폭발, 유독 가스 구름 배출)에 대한 가용한 정량적 데이터가 거의 없을 수도 있음. 그래서 가능한 결과를 연구하는데 모델(흔히 컴퓨터 기반)이 사용된다. 이런 모델로부터 나온 결과가 안전성 증거(safety evidence)의 한 부분을 형성하며, 따라서 그 가정(assumptions)이 반드시 추적가능(traceable) 해야 한다. 가능하다면 이 모델이 실험에 따른 결과(experimental results)와 대조를 통해 확인되어야(validated) 하며, 그 결과가 다른 소스로부터의 정보와 비교되어야 한다.

 

 

8.5 소프트웨어를 위한 분석 기법(Analysis Techniques for Software)

• 소프트웨어가 야기할 수 있는 시스템 결함(system faults)이 생소하고 예측불가능하기 때문에 시스템의 소프트웨어 부분의 안전성이 중대한 문제를 초래할 수 있음
• 소프트웨어 문제는 여러 원인으로부터 생겨남:
  - 명세에서의 실수(Mistakes in specification)
  - 설계에서의 실수(Mistakes in design)
  - 구현에서의 실수(Mistakes in implementation)
  - 테스팅에서의 실수(Mistakes in testing)
  - 유지보수에서의 실수(Mistakes in maintenance)
  - 형상관리에서의 실수(Mistakes in configuration management)
  - 변경통제에서의 실수(Mistakes in change control): 알려진 문제를 고치는 중에 새 문제가 도입됨
• 이런 원인들에 의한 결함(Faults)이 소프트웨어에 잠복해 있다가 예상 못한 입력 또는 운영 조건의 변화 등에 의해 드러나게 됨. 이렇게 드러난 결함(fault)은 요구되는 상태로부터의 차이(discrepancy)를 의미하는 소프트웨어 에러(a software error)가 된다. 소프트웨어 실패(a software failure)는 이 에러가 의도된 기능에게 미치는 영향(effect)이며, 영향을 받은 소프트웨어 기능에 따라 사소한 불편부터 큰 재앙까지 야기될 수 있다.
• 안전성 평가 또는 소프트웨어를 어떻게 설계할지 선택하는데 있어서 필요한 첫 단계는 시스템에서 수행할 기능을 살펴보는 것이다. 위에서 언급된 어떤 기법이든 소프트웨어에 의해 야기될 수 있는 시스템 해저드를 식별하는데 사용될 수 있다. 만일 소프트웨어가 어떤 이유에서든 그 책무(job)를 하지 않으면 그것이 결과로 나올 수 있는 바람직하지 않은 조건이다.