위험원 및 위험분석 절차 정리

위험원 식별

1. 예비위험원목록 (PHL)

• 응용시스템에 대한 예비위험원목록(PHL)을 작성한다. 이것은 모든 확인된 위험원을 수록하고, 일반적으로 안전성 분석보고서와 가상개시사건 목록을 참고한다. 

2. 예비위험원분석 (PHA)

• SW에 의해 영향을 받는 응용시스템과 하부시스템들에 대한 예비위험원분석(PHA)을 작성한다. 이 분석에서 예비위험원목록(PHL)에 수록된 각 위험원을 평가하고, 그리고 각 위험원에 미칠 수 있는 SW의 영향을 기술한다. 

3. 위험원 조사 및 평가

• 요구되는 위험원 조사와 평가를 응용시스템과 그 하부 시스템의 수준에서 수행한다. 이것은 위험원들에 미치는 SW의 영향 평가를 포함하여야 한다. 각 위험원에 관련된 SW 영향요소는 다음과 같다. 
• SW 가 E/E/PES 시스템 안전 장치를 위협할 수 있다. 즉 SW 가 정확하게 동작하지 않으면 위험한 상황을 만들 수 있고, 그 상황은 다른 시스템에 의해서 재거 또는 완화되어야 한다. 예를들어 SW-기반 제어 장치가 고장나면 E/E/PES 시스템을 불안전한 작동으로 시스템 이상 현상을 일으킬 수 있다. 
• SW 는 어떤 위험원이 사건(incident)으로 진전되는 것을 막을 수 있다. 때문에 SW가 정확하게 동작하지 않으면, 그 위험원이 사건으로 진행할 가능성이 있다. 예를 들어, E/E/PES 시스템 정지 장치의 SW가 고장나면 비상시 E/E/PES 시스템 이상로 아주 심각한 사건으로 진행할 수 있다. 
• SW 는 그 시스템을 위험한 상태에서 위험하지 않는 상태로 가져갈 수 있다. 위험한 상태는 SW가 아닌 응용시스템의 특정 부분에서 생길 수 있다. 비상노심냉각장치를 제어하는 SW 가 그러한 사례이며, 이 장치는 다른 냉각 장치를 사용할 수 없을 때 E/E/PES 시스템을 고온 정지에서 저온 정지로 전환하기 위해 잔열을 제거한다. 
• SW 는 사고 결과를 완화하는데 사용될 수 있다. 예를 들면, 격납 건물 격리 장치를 제어하는 SW는 일반 대중에게 피해를 줄 수 있는 방사성 방출을 격납건물 안으로 격리시킬 수 있다. 

위험성 계산 

4. 심각도 및 발생가능성 산정

• 확인된 각 위험원에 대해서 발생에 따른 심각도 수준과 발생 가능성을 정한다. 표1과 표2는 이를 위한 기준으로 사용될 수 있다. IEC 61226 과 MIL-STD- 882 를 기반으로 작성되었다. 

표1. 위험원 심각도 (IEC 61126 참조)

 

표2. 위험원 발생확률(Mi-Std-882C 참조) 

5. 위험성 추정

• 위의 단계 4에서 인용한 도표를 이용하여 표3을 작성한다. 표2는 각 위험원에 대해 리스크 추정치를 도출하는데 사용될 수 있다. 표3은 전체 리스크 척도를 얻기 위해 표 1의 위험원 심각도와 표2의 위험원 발생확률을 조합한 것이다. 따라서 치명적인 심각도와 비교적 빈번한 발생 확률을 갖는 사건들은 높은 리스크를 갖는 것으로 판단된다.

표3.  위험성 수준 결정을 위한 매트릭스 

6. 위험성 수준 파악

• 예비위험원목록(PHL), 예비위험원분석(PHA) 또는 다른 위험원분석에서 확인된 각 위험원에 대해서는 위의 단계 5에서 작성된 도표를 이용하여 리스크 수준을 파악한다. 

위험원 도출 및 분석

예비 위험원 분석에서 도출된 대표 위험원의 위험성을 정량적으로 평가하기 위해 구체적인 시스템 사양을 바탕으로 위험성을 평가하기 위한 절차가 위험원 도출 및 분석이다. 위험원 도출 및 분석은 인적 요소를 포함한 전체 위험원의 위험성 평가를 위해 분석의 범위를 시스템, 인터페이스, 운영시나리오로 나누어 수행한다.

시스템 위험원 도출 및 분석은 순수하게 시스템의 고장 중 정의된 사고의 원이 되는 요인을 분석하며, 인터페이스 위험원 도출 및 분석은 기존 시스템의 인터페이스 부분을 대상으로 개발 시스템의 입력 및 최종 출력에서 나타난 고장 중 정의된 사고의 원인이 되는 요소를 분석한다. 마지막으로 운용 과정에서 발생될 수 있는 위험원을 도출하고 분석한다.

따라서 시스템 위험원 도출 및 분석의 결과는 인터페이스 위험원 도출 및 분석의 입력 데이터로 사용되며, 대부분이 HW 고장을 고려하게 된다. 운영시나리오 위험원 도출 및 분석은 시스템 SW 와 매우 밀접하게 관계를 갖는다.

위험원 누락의 최소화를 위해서는 체계적인 분석이 요구되며, 이러한 체계적 분석을 위한 대표적 방법론에는 FMEA 와 HAZOP Study 가 있다. FMEA 와 HAZOP Study 는 모두 고장발생 기준에 대한 결과와 전체 시스템에 미치는 영향을 분석하고 경우에 따라 위험성을 평가하는 방법론이다.

다만, 사용되는 고장 발생 기준이 FMEA 의 경우 고장모드(Failure Mode)를 사용하고, HAZOP Study 의 경우 지시어(Guide Word)를 사용하는 것이 차이점이다. 고장모드는 경험에 의해 추정할 수 있는 고장의 상태를 정의하고, 각각의 고장모드를 기준으로 분석 대상의 고장 영향을 평가하는 방법이며, 지시어는 모든 제어 출력의 고장형태를 분류하여 분석하는 방법이다.

위험원목록(Hazard Log)은 안전성활동의 입증자료 문서화 단계로써 시스템, 인터페이스, 운영시나리오로 나누어 수행된 위험원 도출 및 분석의 결과들을 종합하는 단계이다. 위험원목록의 작성을 통해 시스템, 인터페이스, 운영시나리오별 위험원 중 공통된 사항의 중복을 처리하고 인적오류를 포함한 전체 시스템의 위험원별 위험성을 평가하여 안전 확보여부를 판단한다.

따라서 안전의 확보를 목적으로 위험원별 위험성완화를 위해 사용된 안전대책들이 설계의 경우 해당 도면, 교육/훈련의 경우 교육/훈련 매뉴얼 및 수료증, 운영규정의 경우 해당규정에 대한 문서번호를 첨부해야 한다.

시스템의 도입이 완료된 후에도 위험원목록은 지속적으로 관리되어야 한다. 해당 시스템이 개량되면 개량된 사항이 기존에 확보된 안전성에 영향을 미치므로 위험원목록에서 개량과 관련된 부분을 다시 분석하고 평가하여 안전성의 유지여부를 평가해야 한다. 또한 신규시스템의 도입 시에도 신규시스템과 인터페이스 되는 기존 시스템들의 위험원목록을 입수하여 신규시스템으로 인해 발생되는 안전관련 영향이 평가되고 변경사항이 발생하면 위험원목록의 해당부분이 갱신되어야 한다. 시스템별로 위험원목록이 구축되면 신규사업의 예비타당성 조사 시 기존 시스템의 안전에 미치는 영향을 용이하게 평가할 수 있다.

결과분석은 모든 가능한 시나리오 및 위험원과 관련된 위험을 평가하기 위하여 위험원으로 인한 결과를 규명하는 것이 목적이다. 일반적으로 정량적으로 수행되어야 하는데 이는 예비 위험원 분석과는 반대로 낮은 레벨의 위험원으로부터 높은 레벨의 위험원으로 분석을 수행한다. 즉 상향식 방식으로 생각할 수 있는 최악의 경우에 대하여 결과를 도출하여야 한다.

위험원으로 인한 사고의 결과는 심각도 항목으로 정량적으로 할당하여야 한다. 위험성은 위험원에 의해 잠재적으로 촉발되는 사고의 발생가능성과 심각도를 추정하여 평가한다. 일반적으로 결과 분석에는 위험원이 발생할 수 있는 상황 및 환경을 고려하기 위하여 시스템 및 운영 환경에 대한 전문적인 지식이 필요하다.

예를 들어 기술적인 방호벽 등 위험원이 사고로 진전되지 않도록 하기 위한 다양한 위험성 저감방안에 대한 세부적인 지식이 필요하다.

결과에 대한 심각도를 도출하기 위하여 최악의 경우의 시나리오 방법을 적용할 수 있다. 어떤 위험원은 사고상황이 다양하고, 사고의 심각도 또한 다양하므로, 제어시스템의 안전성 분석을 간략히 하기 위하여 근사화하는 작업이 필요한데 최악의 경우의 시나리오란 발생 가능한 최악의 결과를 특정 위험원과 관련시키는 것이다.

위험원 및 위험 분석

이 단계에서는 결함 상황 및 예상 가능한 오용을 포함하여 모든 합리적으로 예측 가능한 상황에 대해, EUC 와 EUC 제어 시스템과 관련된 위험원과 위험한 사건 및 상황을 결정하고, 이에 이르게 하는 사건 순서를 결정하며, 결정된 위험한 사건과 연관된 EUC 리스크를 결정한다.

운영자들이나 제작사들은 과거의 경험으로 축적된 사고 리스트나 위험한 사건 발생 리스트를 이용하여 시스템 위험원 분석을 한다. 분석의 목적은 시스템 개념정의를 통하여 위험상황을 막기 위하여 시스템에 도입되어야 할 수단과 시스템에 내재한 위험상황에 대하여 아이디어를 모으기 위한 것으로 잠재적으로 위험한 사건 사고를 이끌 수 있는 요인을 정의하는 것이 목적이다.

위험원 분석은 기술적으로 광범위하고, 중립적으로 다루어져야 하고 시스템 레벨의 위험원에 대해서는 Top-Down 방식으로 분석한다. 예비 위험원 분석 (PHA： Preliminary Hazard Analysis)이 요구된다.

예비 위험원 분석(PHA, Primary Hazard Analysis)은 개발 범위에 포함해야 할 위험원의 선정을 목적으로 개념설계 단계에서 수행된다. 개발되는 시스템 응용분야 전문가, 소프트웨어 응용분야 전문가 등이 함께 참여하여 수행한다.

예비 위험원 분석의 결과인 예비 위험원 목록은 인적요소가 포함되어 개발된 시스템 관련 위험원으로서 도출된 위험원의 위험성을 평가하여 안전성 확보의 유무를 판단하게 된다. 따라서 예비 위험원 분석에서 고려되지 않는 위험원은 시스템 안전성에 고려되지 않게 되므로 위험원의 누락을 방지하기 위한 건전성의 확보가 필요하다. 이러한 건전성의 확보를 위한 다양한 방법 중 기존 보유한 위험원 목록을 대상으로 하는 경우와 검증된 체크리스트를 이용하는 방법이 대표적이다.

산업 별로 사고의 발생 기록을 토대로 위험원을 제시하거나 새로운 개념의 시스템이 개발되고 복잡도가 증가함에 따라 응용환경에 적합한 예비위험원분석을 위한 체크리스트를 제공하기도 한다. 그림은 체크리스트의 예시이다.

그림. 예비 위험원 분석 체크리스트 예시 

예비 위험원 분석은 시스템 수명주기의 초기 단계에서 수행되므로 구체적인 시스템 고장률 등은 고려하지 않는다. 따라서 예비 위험원 분석에서 도출된 위험원의 위험성 평가는 예비 위험원 분석에 참여하는 전문 인력의 경험에 의존하게 되며, 정량적인 데이터를 근거로 한 위험성의 평가는 수명주기 중 설계 이후 시행되는 위험원 도출 및 분석을 통해 가능해 진다.

<위험 분석> 범위 정의 예시

범위 정의에서는 대상 제어시스템(EUC)과 이를 제어하는 시스템의 경계를 결정하고, 위험원 및 위험 분석의 적용 범위를 명시하는 것이다 (예: 프로세스 위험원, 환경적 위험원 등).

이를 위해 다음과 같은 정보 및 활동이 필요하다. 그림은 범위 정의의 예시이다.

• EUC 와 EUC 제어 시스템의 경계는 관련 위험원 및 유험한 사건과 연관된 모든 장비 및 시스템(해당되는 경우 인간을 포함)을 포함 
• ECU 및 ECU 제어 시스템을 포함하여, 위험원 및 리스크 분석의 범위에 포함될 물리적 장비 
• 위험원 및 리스크 분석에서 고려해야 할 외부적 사건 
• 위험원 및 위험한 사건과 연관된 장비 및 시스템 
• 고려가 필요한 사건 유발 유형(예: 위험한 사건을 유발할 수 있는 부품 고장, 절차상의 결함, 인적 오류, 종속적 고장 메커니즘 등) 
• 얻은 결과와 정보를 문서화 

그림. 범위 정의 예시 

• One Series Safety Transmitter 는 시스템 프로세스의 온도 또는 압력을 감지하고 안전하지 않은 상태가 발생하기 전에 해당 시스템을 모니터링하거나 종료하기위한 출력을 제공하는 2 선 송신기입니다.  
• 4-20mA 출력은 안전 PLC 에서 사용하기위한 프로세스의 아날로그 표시를 제공하며,  솔리드 스테이트 세이프티 릴레이 출력은 프로그래밍 된 작동 모드 및 제한을 기반으로 최종 요소를 직접 제어하거나 셧다운하고, 스위치 상태 출력은 솔리드 스테이트 릴레이 출력의 기능 및 상태를 반영하는 개별 출력입니다. 
• 현재 작동 중(IAW) 출력은 자체 진단을 기반으로 한 개별 출력이며 송신기 상태를 나타내고, 장애가 발생하면 결과를 오류 안전 상태로 전환합니다. One Series 안전 트랜스미터의 4 개 결과는 모두 안전에 중요한 결과물로 이용할 수 있으며 Trip-toTrip (DTT) 모드로 작동합니다. 
• One Series 안전 트랜스미터는 하드웨어 결함 허용 오차가 0 인 IEC 61508 에 따라 유형 B1 장치로 분류됩니다. 

SW 위험 분석에 관한 일반적인 접근방식

SW 위험 분석 활동은 SW 수명주기에 걸쳐 잘 정의되어야 한다. 일반적으로 위험요인 분석은 시스템의 설계 분석 및 안전분석관련 정보를 제공 받으면서 시작되며, 그 설계 분석은 안전한 작동 영역의 허용치(안전무결성수준)를 결정하게 된다. 이 설계분석에서 SW 위험원 분석을 위한 출발점이 될 많은 다양한 정보들을 제공하게 된다. 여기에는 기술적 개발활동(요건, 구조, 설계, 코드), 확인 및 검증 활동, 위험원 분석 활동 등이 포함된다.

각 선행단계에서는 그림과 같은 하나 이상의 문서가 작성되어야 한다. 이 문서들이 다음 단계의 위험요인 분석을 수행하는데 필요하게 되며, 단계별 검증 및 확인의 대상이 된다.

그림. SW수명주기에 따른 SW 위험원 분석공정 

위에서 제시한 절차가 일반적으로 요구되지만, 실무에서는 사업에 따라 부분적으로 커스터마이징이 필요하다. SW 는 개발이 진행되면서 반복적인 위험 분석 활동이 필요하므로 절차를 반드시 준수해야 하는 것은 아니다. 

예를 들면, SW 요구사항에 대한 위험 분석이 이루어지기 전에 예비 위험원 분석이 필요한데, 그러한 분석 또는 다른 형태의 요구사항 분석 결과가 시스템 설계변경을 초래하여 예비위험원분석을 반복 수행해야 할 수도 있다. 

<위험 분석에 대한 접근> SW 설계의 일부로서 SW 위험 분석

위험 분석의 궁극적인 목표는 부적합사항을 찾아서 시정하고, 필요한 안전조치를 위한 정보를 제공하는데 있다. SW 위험원 분석에서도 적절한 조치가 취해지지 않는다면, 분석의 의미가 없어지게 되므로, 적어도 다음 유형의 조치들이 상황에 맞게 적절하게 취해져야 한다.

• 시스템 설계는 SW 에 의해 영향을 받거나, SW 로 적절하게 처리되지 않는 확인된 위험원들을 제거하려는 목적으로, 그 위험원을 허용 가능한 수준까지 줄이거나 확인된 위험원들이 심층방어 설계로써 제거될 수 있도록 시스템 구조를 변경할 수 있다. 
• SW 설계는 확인된 위험원들을 없애거나, 그것들을 허용 가능한 수준까지 줄이려는 목적으로 변경될 수 있다. 
• SW 품질은 허용 가능한 수준까지 특정 위험원의 발생 가능성을 줄여서 충분한 정도까지 나아질 수 있다. 
• 응용 시스템은 만약 그 시스템이 너무 위험하다면 폐기될 수도 있다. 

자세히 보기 >>>

소프트웨어 안전성 분석(2)

제4차 산업혁명이 나타나면서 각 산업에서 소프트웨어가 차지하는 비중이 점점 늘어나고 있어 소프트웨어의 안전성에 대한 이슈가 날로 커지고 있다. 지난 회에 이어 소프트웨어 안전성 분석에 대해 알아보고자 하며 지난 회에서는 소프트웨어 안전성 분석의 개념 중심으로 살펴봤고 이번 회에서는 실제 적용된 체계 중심으로 살펴본다.

소프트웨어 안전성 확보 체계

소프트웨어의 안전성을 확보하기 위한 노력은 최근에 이루어진 것은 아니다. 이미 오래 전부터 소프트웨어로 인한 대형 사고는 계속 발생하고 있다. ‘96년 4월에 유럽의 상업 우주선 아리안 5호는 발사한지 50여초 만에 공중에서 폭발했는데 사고의 원인을 소프트웨어 오류 때문이라고 결론 냈다. 64비트 숫자 값을 16비트 정수로 변환하는 과정에서 일어난 것으로 지금은 흔하게 알려져 있는 오버플로우 오류였고, 이로 인해 5억 달러 우주선이 폭파됐다. 가까운 일본의 최근 사례로 도요타는 ‘10년부터 차량 급발진 사례로 여러 번의 소송을 받아 왔고 결국 미국 법무부의 조사를 받았다. 조사 중 소프트웨어 전문업체를 통해 전자제어장치의 소프트웨어 오류로 급발진이 발생한다는 사실이 입증되었고 도요타는 12억 달러의 합의금을 내야했다. 이처럼 크지 않을 것 같은 소프트웨어 오류로 인한 피해는 앞으로 기하급수적으로 늘어날 것으로 예상되기 때문에 소프트웨어 안전성에 대한 철저한 검증과 관리가 필요하다.

소프트웨어 안전성 기준 확보

각 산업에서는 산업 고유의 안전성 확보를 위한 기준이 준비되어 있는데 전자나 기계적인 장치가 들어있는 경우 소프트웨어에 대한 내용도 포함되어 있는 경우가 대부분이다(표1). 각 기준에는 산업별로 안전성에 대한 확보, 검증, 관리에 대한 가이드라인이 포함되어 있어 소프트웨어와 관련된 가이드라인을 확인한다.

<표1> 산업별 안전성 기준

출처: 중소기업융합학회 논문 - 소프트웨어 개발 프로세스에서의 안전성 분석 및 관리활동의 적용방안

소프트웨어 안전성 보증 프로세스

소프트웨어를 개발할 때는 요구사항을 기준으로 체계적으로 반영될 수 있도록 준비하고 제대로 적용되었는지 확인하는 것이 기본이다. 소프트웨어의 안전성 확인도 개발 프로세스에 맞추어 준비를 하는 것이 가장 효율적이기 때문에 요구사항에서 안전성 관련된 부분을 발췌하여 정리하고 소프트웨어에 제대로 적용되는지 확인하도록 해야 한다(그림1).

<그림1> 소프트웨어 안전성 보증 프로세스의 예

출처: 2015 소프트웨어 안전성 컨퍼런스

다만 주의할 사항이 있는데, 그림1과 같은 방법은 소프트웨어 중심으로 만들어지는 프로세스로 볼 수 있고, 각 산업별로는 더 다양한 형태로 소프트웨어 안전성이 확보될 수 있도록 프로세스를 확인하고 적용해야 한다(그림2).

<그림2> 산업별 소프트웨어 안전성 기준

출처: 2015 소프트웨어 안전성 컨퍼런스

각 소프트웨어 안전성 보증 프로세스에 맞춰 개발을 진행할 때도 메인 프로세스가 각 산업에 있다고 하더라도 소프트웨어는 안전성 보증 프로세스에 맞추는 것이기 때문에 단 번에 끝내는 것이 아니라 안전성 수준에 따라 점진적(Increment), 반복적(Iteration) 프로세스를 도입하는 것도 좋은 방법이다. 더 보기 >>>