SW 계획(SP) 단계에서의 안전 활동

1. SW 안전 분석 

본 단계는 개발할 안전관련 시스템에 대한 위험분석 단계와 동시에 이루어 진다. 위험 분석에 대한 결과를 받아 소프트웨어에 반영하기 위한 준비를 한다.

전체 안전 요구사항에서는 필요한 기능안전성을 달성하기 위하여 안전관련 시스템, 기타 리스크 감소 설비에 대한 안전기능 요구사항과 안전무결성 요구사항으로 나타나는 전체 안전 요구사항 명세서를 개발한다.

전체 안전 요구사항 할당은 전체 안전 요구사항 명세(안전기능 및 안전 무결성 요구사항 모두)에 제시된 안전기능을 지정된 안전관련 시스템, 기타 리스크 감소수단에 할당하고 안전무결성 수준을 안전관련 시스템에 의해 수행될 각 안전기능에 할당한다.

2. SW 안전 계획서 작성 
SW 위험 분석 절차을 활용하여 SW 의 위험을 분석한 후 안전을 확보하기 위한 SW 안전성 위험 분석에 관한 SW 안전계획서를 작성한다. SW 안전계획서는 SW 안전성 위험 분석 방법을 상세히 기술한다. 경우에 따라 SW 안전계획서는 시스템 안전계획서 내에 포함시킬 수 있다.

IEC 61508-3 표준에 맞는 기능 안전 검증 기법(Technique/Measures)  

IEC61508-3 A.10 - Functional safety assessment 

IEC61508-3 B.4 – Failure analysis

SW 계획(SP) 단계에서의 개발과 확인 검증 활동

개발활동

1. SW 개발 계획 수립
SW 에 할당된 요구사항을 구현하기 위한 SW 개발계획서를 작성한다. SW 개발계획서는 시스템의 전체 수명주기에 참여하는 사람들이 이해 가능 하도록 표현한다.

개발계획서에는 개발 조직, 작업계획, 통제 계획 등의 기본적인 내용을 포함하고, 개발 절차, 자원 계획 등이 포함된다.


2. SW 환경 계획 수립
SW 개발 환경에 대한 계획을 수립한다. 개발 환경에는 사용언어 및 컴파일러, SW 테스트 환경 등이 포함된다. SW 환경은 SW 전체 수명주기에 걸쳐 요구되는 SW 안전 무결성 수준에 적합하게 수립한다.

SW 개발환경은 다음을 고려하여 선정한다.

• SW 개발환경은 최종 SW 에 미치는 잠재적인 위험을 최소화하기 위해 선정한다. 
• 자격 있는 도구 또는 도구들의 조합, SW 개발환경은 어느 한 부분에서 도입된 오류를 다른 곳에서 찾아낼 수 있는 확신의 수준을 달성하기 위해 선정된다. 
• 잠재적인 SW 개발 환경과 관련된 오류를 최소화하기 위해 SW 안전 무결성 수준을 고려한 SW 검증 활동 또는 SW 개발 표준이 정의되어야 한다. 
• 가능하다면 검증자 및 확인자의 니즈를 고려하여, 자동화 테스트 도구와 통합 개발 도구를 사용한다. 
• SW 안전 무결성 수준에서 요구되는 정도까지, 선정된 프로그래밍 언어는 다음 중 하나의 조건을 만족하는 번역기 또는 컴파일러를 제공해야 한다 
• 인정된 국내 국제 표준 규격에 대해 "확인 인증" 
• 목적 적합성을 상세히 설명한 평가 보고서 
• 변환 오류 검출을 제공하는 중복 서명 통제 기반의 프로세스. 
• 선정된 언어는 다음의 요구사항을 반드시 만족해야 한다. 
• 선정된 언어는 프로그래밍 오류 식별을 활성화하는 특성을 포함해야 한다. 
• 선정된 언어는 설계 방법에 맞는 특성을 지원해야 한다. 
• 위의 내용이 만족되지 않을 경우 대안으로 선택된 언어가 목적에 적합하다는 정 당성을 설명한 내용을 SW 개발계획서에 기록한다. 
• SW 테스트 환경은 통합 단계의 결과물을 테스트하는데 사용될 방법, 도구, 절차 및 HW 를 정의한다. 테스팅은 타겟 컴퓨터, 타겟 컴퓨터 에뮬레이터 또는 호스트 컴퓨터 시뮬레이터를 사용하여 수행될 수도 있다. 이 때 에뮬레이터 또는 시뮬레이터와 타겟 시스템과의 차이점을 고려해야 한다. 

3. SW 개발 표준 수립
SW 개발 표준은 SW 개발을 위한 규칙과 제약사항을 정의한다. SW 개발표준에는 SW 요구사항 표준, SW 설계 표준, SW 코드 표준 등이 포함된다. SW 개발 표준은 검증함 수 없거나 안전 요구사항에 적합하지 않은 결과물을 생성하는 것을 방지할 수 있어야 한다.

• 코딩 관련 표준 규격은 훌륭한 프로그래밍 프랙티스를 명시하며, 불안전한 언어 특성을 사용 금지하며, 소스 코드 문서화 절차를 설명하여야 한다. 최소한 각 SW 모듈은 소스 코드 내에 작성자, 형상 이력, 간단한 설명을 포함하여야 한다. 이러한 정보에 대한 표준 양식이 사용되는 것이 좋으며, 모든 모듈에 대하여 동일하게 적용되도록 한다. 

확인 검증 활동

1. SW 검증 계획 수립 

검증 활동이 적절히 안내되고. 특정 설계 또는 기타 검증 니즈가 적절히 제공되도록 SW 확인 검증 계획서를 생성한다. 개발 과정에서 여러 개의 작은 문서로 분할 또는 추가될 수 있다. SW 확인 검증 계획서에는 다음을 포함한다. 

• 검증 전략 및 기법의 선정 
• SW 테스트 장비의 선정 및 활용  
• 검증 활동의 선정 및 문서화  
• 검증 결과의 평가  
• 신뢰성 요구사항의 평가 
• 테스트 프로세스에 참여한 사람들의 역함 및 책임  
• 테스트 커버리지 정도 

 

2. SW 개발 계획 평가 

SW 계획, SW 환경 및 SW 개발 표준이 SW 안전 무결성 수준에 적합한지 다음 항목을 사용하여 검증한다. 

• 선정된 방법이 본 방법론의 절차를 준수하는지 여부  
• SW 개발 방법이 일관성 있게 적용되는지 여부 각 단계에서 만들어지는 결과물이 추적될 수 있는지 여부  
• SW 계획 단계의 결과물이 일관성 있고 표준에 따라 작성되었는지 여부 

3. 확인 검증 보고서 작성 

각 검증 활동의 종료 후에 작성하는 SW 확인 검증 보고서는 SW 검증 합격 유무 또는 불합격의 원인에 대하여 서술한다. 

신뢰 안전 SW 개발 단계

SW 안전 수명주기를 V&V 다이어그램 형태로 표현하면 그림 1 과 같다. 개발 수명주기는 시스템 개발에 관한 활등은 사전에 이루어졌으며, 시스템 중 SW 에 할당된 요구사항이 확정되어 있다고 가정한다. 따라서 본 수명주기에 포함하는 부분은 SW 계획수립에서 SW 검증 확인 단계이다.

그림1. 신뢰 안전 SW 개발 단계

수명주기별 Technique/Measure 매칭

SW 개발(Realization)시 적용하는 Technique/Measure 은 반드시 하나의 단계에서만 사용하는 것이 아닌 여러 단계에서 사용하는 경우도 있다. 각 단계별 Technique/Measure 간의 연결은 그림 1과 같다.

그림1. 수명주기별 Technique/Measure 매칭 

SIL 수준에 맞는 검증기법 선정 및 활용법

안전활동에 포함된 “기능 안전 검증 기법(Technique/Measures)”은 각각의 SIL Level 별로 단계별 검증해야 할 것을 설명하는데, 표1은 IEC 61508-6 Annex E 에 나와있는 예시에 해당한다. 추가로 SIL 2 를 기준으로 “Software safety requirements specification” 부분에 대한 점검 목록 및 활용방법을 설명하면 표2와 같다.

표1. 점검 대상 목록 : IEC61508-3 A.1 - Software safety requirements specification 

SIL 1 에서 4 까지에 대한 Technique/Measure 적용 시 권고하는 내용은 다음과 같다. 

• HR：이 기법 및 수단은 안전무결성을 위해 반드시 권고되는 기법임을 나타낸다. 이 기법이나 수단이 이용되지 않는다면 안전 계획에서 그 합리적 근거가 상술 되어야 하고 평가자의 동의를 얻어야 한다. 
• R：이 기법 및 수단은 안전무결성을 위해 HR 보다 낮은 권고 수준을 갖는다. 
• • ---：이 기법 및 수단은 안전무결성을 위해 권고되는 사항이 없음을 의미한다. 
• NR：이 기법 및 수단은 안전무결성을 위해 절대 권고되지 않음을 의미한다. 이 기법이나 수단을 이용한다면 그것을 이용하는 합리적 근거를 안전 계획중에 상술되어야 하고 평가자의 동의를 얻어야 한다. 

표 2. 목록 활용 방법 : IEC61508-3 A.1 - Software safety requirements specification

표 2 의 SIL 2 수준은 모두 R, 권고 수준이므로 해당 Technique/Measure 필수로 적용할 필요는 없다. 하지만 SIL 3 수준은 HR 에 해당하는 Technique/Measure 은 반드시 적용해야 한다.

SW 안전 수명주기 ScarFS(Software to be Careful about Functional Safety)

그림은 IEC61508 의 전체 안전 수명주기와 본 가이드의 SW 안전 수명주기의 연결을 보여준다. ※ 참고: NIPA에서는 SW 안전 수명주기를 ScarFS(Software to be Careful about Functional Safety)로 명명하고 활용한다.

그림. SW 개발 수명주기 

ETA (Event Tree Analysis)

만약 제품을 사용하는 중에 발생할 수 있는 여러 가지 상황들을 다 그려볼 수만 있다면 재해사고예방은 좀 더 효과적일 것이다. 바로 이런 목적을 위해 개발된 것이 사상수목분석이다.

즉, 이 기법은 의사결정수목 (Decision Tree) 의 원리를 이용, 재해사고의 발생과정을 재해요인들의 연쇄로 파악하여, 재해발생의 초기사상 혹은 촉발사상 (initiating event) 으로부터 재해사고까지의 연쇄적 전개를 나뭇가지 형태로 표현하는 귀납적인 제품 안전성 분석기법이다.

더욱이 각 재해발생요인들의 발생확률을 알고 있다면, 정성적인 분석기법인 동시에 정량적인 분석기법의 장점도 활용할 수 있다.


분석절차와 내용

어떤 사고에든 여러 가지 재해발생요인들이 연관되어 있다. 이 요인들을 도표 상단에 왼쪽에서부터 오른쪽으로 차례대로 나열한다. 이 때 가장 왼쪽의 요인은 제품에 고장이나 사고가 발생하게 되는 부정적인 사상, 다시 말해 사고의 촉발사상을 기입하는 것이 보통이고, 오른쪽 끝은 제품 구성요소의 상태조합에 의한 결과상황들이 나열되는 것이니까, 그 중간의 재해요인들은 가급적 시간경과에 따라 재해사고가 전파되거나 혹은 확산되는 데 관계되는 요인들을 나열하도록 한다.

재해촉발사상이 결정되었으면 그 점에서 다음 요소의 발생사상에 따라 가지를 나눈다. 이 때 성공사상, 다시 말해 제품 구성요소가 정상적으로 작동하는 경우를 맨 윗가지에, 정상적으로 작동하지 못하는 고장상태를 맨 아래 가지에 할당한다. 필요하다면 다양한 고장양식에 따라 그 중간에 여러 개의 가지를 더 만들 수 있다. 그 다음 단계에서는 벋어진 가지의 끝 점에서, 또 다시 다음 재해발생요소의 성공, 실패에 따라 가지를 나누어 간다. 이렇게 하여 결과상황까지 벋어 나가면, 제품에 발생할 수 있는 모든 상황들이 오른쪽 가지 끝에 나열되게 되며, 각 결과상황들은 상호 배반적이라는 통계적 성질을 유지하게 된다.

그림 1은 이렇게 하여 만들어진 기본적인 사상수목을 보여주고 있다. 초기사상 즉 촉발사상에 해당하는 것은 파이프 파단이며, 재해요인들이 5 개이니까 최종적인 결과사상은 2의 4승으로 총 16가지가 나열된다. 일반적으로 재해요인들이 n 개라면 결과사상들의 가지수는 2의 (n-1)승 개의 가지수이다.

그림 1. ETA 사상수목 예(원자력 분야) 

그러나 경우에 따라서는 이렇게 많은 가지들을 각각 모두 고려할 필요가 없을 수 있다. 왜냐하면 어떤 요인의 성공 혹은 고장여부는 이후 다른 요인들의 성패에 관계없이 제품의 상태를 결정해버리기 때문이다.

예를 들어 위의 그림에서 전원의 공급이 이루어지지 않으면 그 이후의 긴급노심냉각장치 (ECCS), 방사능제거, 격납용기의 건전성 등에 관한 분석은 하나마나이다. 그러므로 이런 경우에는 전원공급실패 이후에는 가지를 분지하지 않고 그냥 하나의 가지로 남도록 가지를 잘라 버린다. 이 작업을 전지 작업이라고 하며, 그 결과는 그림 2와 같이 나타나게 된다.

그림 2. ETA 사상수목 예(2) 

마지막으로, 재해요인들의 정상적 작동확률 (신뢰도) 이나 고장발생확률 (불신뢰도) 을 알 수 있다면, 각각의 요소에 그 수치들을 기입하고, 그 확률들을 곱하면 결과적으로 발생될 수 있는 상황의 발생확률을 얻게 된다. 이 때 모든 상황에 대한 확률들의 최종합이 1 이 되어야 하는 것은 물론이다. 

FTA 분석절차와 내용

FTA 의 분석절차는 분석 목적이나 분석 수준에 따라 다르지만 일반적으로 다음과 같은 순서에 따라 진행된다. 즉, 분석범위의 정의 및 분석수준의 결정, 대상 제품의 특성파악, 정상사상의 설정, 결함수의 구성, 결함수의 정성적 분석, 결함수의 정량적 분석, 분석결과의 평가 및 보고라는 단계를 거치는 것이다.

1) 분석범위의 정의 및 분석수준의 결정 
분석되어야 할 제품, 분석목적과 범위, 제품 운용상의 초기조건들과 현재의 조건, 그리고 기본적인 가정사항들을 정의한다. 이 때 기본적인 가정들이란 모든 사용조건 하에서의 제품 성능뿐만 아니라, 예상되는 운용조건들과 보전조건들과 관련된 모든 가정사항들을 포함한다.

2) 대상제품의 특성 파악 
결함수 분석이 성공적으로 이루어지려면 분석자가 제품을 상세히 숙지하고 있어야 한다. 이 때 필요한 지식이란 생산공정의 구성, 기능, 작동 및 작업방법이나 동작 등 현장정보에 의한 제품의 안전보건상의 문제점을 파악하는 데 관계되는 지식들을 말한다. 또한 여기에는 부품, 구성품들의 고장률 자료와 신뢰도 구조를 입수하여, 신뢰도 블록 다이어그램 분석 (Reliability Block Diagram Analysis) 을 행하는 것도 포함되며, 인간과오의 요인, 형태, 발생확률 등의 자료도 확보되어야 한다.

3) 정상사상의 정의 
작업자의 과오나 기계설비로 인한 경과를 모형화하고 대책을 설정할 문제점들에 대해 중요도나 우선순위를 결정하여 분석할 대상이 되는 사항을 정상사상으로 선정한다. 이 때 분석대상이 되는 정상사상은 분석목적과 수준, 범위에 맞게 설정되어야 한다.

4) 결함수의 구성 
정해진 기호를 이용하여 재해사고의 발생과 관련된 요인들간의 논리적인 관계를 나무모양으로 구성한다. 사용기호에는 표 III.4.6 과 같이 여러 가지가 있으나, 분석자의 편의에 따라 첨삭이나 수정이 가능하다.

표 1. FTA 사용 기호 

수목을 구성하는 방법으로는, 우선 분석하려고 하는 제품 전체의 고장이라든가 결함과 같은 바람직하지 않은 사상을 정상사상으로 채택하여 최상단에 직사각형을 그리고 그 안에 내용을 기입한다. 이것이 결함수 최정상의 출력사상, 다시 말해 제 1 수준의 출력사항이라고 할 수 있다.

다음에는 정상사상의 하단에 그 재해의 직접원인이 되는 기계 등의 불안전 상태나 작업자의 과오인 결함사상들, 다시 말해 논리 게이트의 입력사상들을 나열한다. 이것은 제 2 수준에 해당한다. 그리고 나서, 입력사상들과 출력사상과의 관계를 고려하여 제 1 수준의 정상사상과 제 2 수준의 기초사상들과를 논리 게이트로 연결한다.

다음 단계에서는 반복적으로 제 2 수준의 결함사상들을 각각 하나의 중간사상으로 하여, 그것들의 직접원인이 되는 결함사상들을 각각 제 3 수준에 쓰고, 제 2 수준의 사상들과 관계를 고려하여 다시 제 2 수준의 사상들과 제 3 수준들과의 사이를 논리 게이트로 연결한다.
이와 같은 과정을 반복해서 위에서부터 아래로, 차례대로 써 나가 최종적으로 모든 나뭇가지의 끝이 모두 다음 중 어느 하나에 해당되면 분지(, branching) 작업을 종료한다.

• 통상사상 
• 기본사상 
• 미개발 (생략) 사상  
• 전이기호 

5) 결함수목의 정성적 분석 
결함수의 정성적 분석이란 정량적인 변수들을 이용하지 않고 제품의 구조적 특성이나 각 기본사상들이 정상사상의 발생에 미치는 상대적 중요도 등을 평가하는 분석을 말한다.
이 분석은 다음과 같이 3 단계로 나뉘어진다.

• 결함수의 타당성 조사 
• 결함수의 축약 
• 절단집합과 경로집합 

이 중 가장 중요한 것은 최소절단집합 (minimal cut sets) 의 도출이다. 최소절단집합이란, 정상사상, 즉 원하지 않는 재해사고가 발생하기 위해 동시에 발생하여야 하는 최소한의 기본사상들의집합을 말하는데, 이것은 이후 정량적인 분석을 진행해 나가는 데에도 매우 중요하다.

6) 결함수목의 정량적 분석 

• 사상 발생확률의 평가: 결함수에 대한 정량적 분석의 최대 장점 중의 하나로서, 각 기본사상들의 발생확률만 알고 있다면 몇 가지 가정사항들을 추가함으로써 중간사상들이나 정상사상의 발생확률을 계산할 수 있다. 
• 중요도 지수: 중요도란 어떤 기본사상의 발생이 정상사상의 발생에 어느 정도의 영향을 미치는가를 정량적으로 나타낸 것으로서, 재해예방책 선정의 우선 순위를 제시한다. 여기에는 구조중요도, 확률중요도, 치명중요도 등 여러 가지가 있으며, 이 척도들을 이용하면 재해사고의 예방을 위하여 어느 사상부터, 혹은 어떤 부품부터 개선하여야 할 것인가를 결정할 수 있다. 
• 평균고장률과 평균수리시간: 만약 제품이 수리가능한 제품이라면, 하위수준의 기본사상이나 중간사상들의 평균고장률 와 평균수리시간 로부터 정상사상으로 인한 제품의 평균고장률이나 평균수리시간도 쉽게 구할 수 있다. 
• 기타 신뢰도척도의 추정: 이 외에도 해당 제품의 여러 가지 신뢰도 특성이나 척도들을 추정할 수 있다. 이런 경우에 매우 유용한 것이 최소절단집합이다. 

7) 분석결과의 평가 및 보고 
이상의 과정을 거쳐 정성적 분석 또는 정량적 분석이 종료되면, 최종적인 보고서를 준비한다. 보고서에 포함되어야 하는 기본적인 사항들은 다음과 같이 정리될 수 있으며, 분석목적과 상황에 따라 약간씩 차이가 있을 수 있다.

• 목적과 범위 
• 제품 설명 
• 설계 설명 
• 제품 운용 
• 상세한 제품 경계정의 
• 가정사항
• 제품 설계 가정
• 운용, 보전, 시험 및 검사의 가정
• 신뢰도 및 가용도 모형의 가정
• 제품 결함의 정의 및 기준
• 결함수 분석
• 분석내용
• 자료
• 사용기호
• 결과 및 결론 

이 이외에 결과 보고서에 추가적으로 포함될 수 있는 자료는 아래와 같다.

• 제품 블록/회로 다이어그램 
• 사용된 신뢰도 및 보전도 자료의 요약 
• 컴퓨터 입력 양식의 결함수 표현 

끝으로 이렇게 분석보고까지 끝나면 효과적인 개선안을 검토한다. 최소절단집합은 재해를 예방하기 위한 노력이 어느 곳에 집중되어야 하는가를 나타내기는 하지만 실제적인 비용, 시간, 기술적 이유 등 여러 가지 면에서 제약이 있을 수 있으므로, 여러 가지 중요도 지수와 경제성, 보수성 등을 고려하고, 또 절충연구 (trade-off study) 의 결과와도 비교하여 대책을 수립한다.

FTA (Fault Tree Analysis)

FTA 는 결함수 분석, 결함수목분석, 고장수목분석 등 여러 가지 용어로 번역되어 사용된다. 고장 (failure) 이란 해당 부품이나 제품이 다시 정상적으로 작동하기 전에 수리를 요하는 기능장애를 말하고, 결함 (fault) 이란 일단 기능장애를 야기시킨 조건이 교정되면 저절로 치유될 수 있는 기능장애를 말한다. 이 차이를 고려하면 제품의 안전성을 향상시키기 위해 조사하고 분석해야 할 대상은 고장뿐만 아니라 결함도 망라하여야 하므로, 고장수목분석 이 아니라 결함수분석 또는 결함수목분석 이라고 부르는 것이 바람직하다.

원래 이 기법은 미국의 미닛트 맨 (Minute Man) 미사일 발사 시스템을 개발하던 도중 1962 년 벨 (Bell) 전화 연구소의 왓트슨 (Watson) 이라는 사람에 의해 제안되었는데, 초기의 개발 목적은 지금도 충족되고 있다.

• 정상 사건(top event)을 초래하는 원인이나 원인들 조합의 구명 
• 특정한 제품 신뢰성 척도가 서술된 요구사항을 충족시키는가 여부의 결정 
• 제품의 독립성과 고장의 비관련성에 대하여, 다른 분석들에서 이루어진 가정들이 위배되지 않는가에 대한 결정 
• 특정 신뢰도 척도에 가장 심각한 영향을 미치는 요인들과 그 척도를 개선하기 위하여 필요한 변경들의 결정 
• 공통적 사상이나 공통원인고장의 구명 

결함수란 ETA 의 나무모양의 구조를 말하는데, 다른 점이 있다면 ETA 의 나무는 촉발사상으로부터 시작되어 제품 상태를 나타내는 결과로 발전하여 가는 귀납적 구조였지만, FTA 의 나무는 정상 사상 (top event) 이라고 부르는 바람직하지 않은 사상을 시작으로 그 발생원인이나 거기에 기여하는 조건들이나 요인들을 찾아 시간적 흐름을 거슬러 분석해 가는 연역적 구조라는 점이다. 또한, 정성적인 분석과 정량적인 분석이 모두 가능하고, 제품 구성수준측면에서 보면 하향성 분석방법 (top-down approach) 이며, 수학적 논리는 부울 대수 (Boolean Algebra) 에 의해 지원되고 있다.

FMEA 분석절차

일반적으로 10단계의 절차를 따른다.

1. 제품과, 그 기능적 최소 운용요구조건의 정의 
2. 기능적 신뢰도 블록 다이어그램, 기타 다이어그램 또는 수학적 모형의 개발과 설명 
3. 분석 수행상의 기본원칙과 그에 상응하는 문서양식의 설정 
4. 고장모드, 그들의 원인과 영향, 상대적인 중요성, 그리고 그 연쇄들의 구명 
5. 고장검출과 격리규정 및 방법의 구명 
6. 특히 바람직하지 않은 사건에 대한 설계 및 운용규정의 구명 
7. 사건 치명도 (event criticality) 의 결정 
8. 고장확률의 평가   
9. 필요한 경우, 고려되어야 하는 특정조합의 다중고장에 대한 탐색 
10. 권장사항 

구체적 내용을 소개한다.

(1) 분석과제 정의 및 분석준비 

가장 먼저 이루어져야 할 것은, FMEA 에 포함되어야 할 구체적인 항목과, 그것들이 분석되어야 할 조건들을 규정하는 일로서, 적절한 분석수준과 분석의 경계 조건들을 정의하는 것을 말한다.  다음의 절차를 수행한다. 

• 제품을 효율적으로 다룰 수 있게 어셈블리로 분할한다. 
• 제품과 어셈블리의 기능 다이어그램, 구성도, 도면 등을 검토하여 그들의 연관관계를 결정한다. 
• 분석되어야 할 각 어셈블리에 대하여 완벽한 구성부품목록을 준비한다. 

(2) 분석의 실시 

분석 수행시 가장 중요한 것은, 치명적인 상호작용과 숨겨져 있는 제품 설계상의 상호작용을 도출하기 위하여 분석자가 부품의 구조와 기능에 관하여 충분한 지식을 가지고 있어야 한다는 점이다. 

FMEA 는 결함수 분석 (Fault Tree Analysis) 과 같이 제품 구성요소간의 상세한 기능적 연관관계나 종속성에 관한 정보를 제공하지는 않으므로 이 부족한 상세사항은 분석팀의 경험과 지식으로 보충되어야 한다. 분야 전문가를 포함한 여러 분야의 전문가들의 협력에 의하여 학제간 연구 (multidisciplinary study) 로 이루어져야 한다. 

그러므로, 최소한 분석 팀에는 다음의 전문가가 반드시 참여하여야 한다. 

• 제품의 설계와 운용을 잘 아는 제품 공학자나 사용 전문가 
• 전기적 제어설계, 논리, 사용장비 등을 잘 아는 제어 전문가 

 

직접 수행되는 구체적인 분석내용은 다음과 같다. 

• 제품에 영향을 미치는 운용상의 또는 환경적인 스트레스를 설정한다. 
• 공학적 도면이나 기능 다이어그램의 분석으로부터 구성요소에 영향을 미칠 수 있는 중요한 고장 메커니즘을 결정한다. 
• 모든 구성부품의 고장모드를 판명한다. 
• 운용, 스트레스, 인적반응조치, 사건들의 조합에 있어서 고장이나 손상의 가능성을 증가시키는 특별한 기간이 있는지, 구성부품에 영향을 미치는 각 조건들을 나열한다. 
• 위험성 범주를 평가한다. 
• 위험성을 제거하거나 최소화하기 위한 예방대책 또는 사후대책을 나열한다. 

 

작업의 결과는 표 1과 같은 형태로 문서화한다.  

표1. 분석결과 문서화 예

• 항목번호는 도면이나 블록 다이어그램에서 식별할 수 있는 식별기호를 나타낸다. 
• 장비특성에는 장비유형, 운용모드, 기타 고장모드와 효과에 영향을 미칠 수 있는 기능 특성, 예를 들어 고온, 고압, 부식 등을 기입한다. 
• 고장모드에는 장비특성과 관련된 부품의 모든 고장모드를 나열한다. 이 때 각각의 고장은 제품 내의 다른 고장들과 관계없이 독립적으로 발생한다고 가정한다. 
• 고장원인을 나열하는 이유는, 고장 시나리오를 함축적으로 서술함으로써 고장의 성질을 명확히 하기 위한 것이다. 

고장영향에는 고장위치에 미치는 부품고장의 직접적인 효과와, 다른 장비나 전체 제품에 영향을 줄 것으로 예상되는 결과를 모두 기입한다. 특히 제품의 사고를 예방하기 위해서는, 제품 설계내에 존재하는 안전방호장치가 정상적으로 작동하지 않는다고 가정하고, 그 결과 예견될 수 있는 최악의 상황을 염두에 두고 영향을 평가한다. 

고장검출방법은 고장모드를 어떻게 검출할 것인가 하는 방법을 말한다. 

시정조치에는 해당 고장모드와 관련된 효과의 발생 가능성을 감소시킬 수 있는 모든 사후조치를 나열한다. 만약 제품의 자동제어기능이 별다른 손실없이 고장의 영향을 흡수해 버릴 수 있다면 이 사실도 기입되어야 한다. 

FMEA 에서는, 피해규모의 경중에 차이없이 제품 기능 상실을 초래하는 고장들의 위중함이 모두 같다고 가정되지만, 실제로 고장이 제품에 미치는 영향은 서로 다르기 때문에 집중적으로 관리할 필요성이 대두되기 때문에, 이를 위해 제품 기능에 미치는 치명성을 언급하는 공란을 추가하거나 비고란을 추가하여 이에 대한 사항을 기록한다. 표 1의 치명도는 바로 이러한 목적을 위해 이용된다. 

(3) 분석결과의 정리 및 심층 분석 

이상의 분석이 끝나면 해당 구성요소의 고장이 각 제품 수준에 미치는 대략적인 영향을 파악할 수 있다. 그러나 좀 더 정확하고 비교가 가능한 척도를 얻기 위하여 고장확률을 계산할 수 있다. 구체적인 내용은 다음과 같다. 

• 각 구성부품의 고장발생확률을 기입한다. 
• 하부 어셈블리, 어셈블리, 제품의 고장확률을 계산한다. 
• 구성부품의 치명도를 계산하는 등 분석을 계속하고, 고장이 임무수행에 가져올 수 있는 영향을 분석한다. 

FMEA (Failure Modes and Effects Analysis) 개념

FMEA 는 What If 분석을 좀 더 체계화한 것이다. 즉, 만약 무슨 일이 벌어진다면 어떻게 될까 (what happens if ) ?" 라는 질문을 염두에 두어 하나의 재료, 부품, 장비 등이 고장났을 경우 그것이 전체 제품이나 사용자, 혹은 제품기능에 어떠한 영향을 미치는가, 생각의 범위를 점차 넓혀가면서 상위수준으로 분석하여 가는 것이다.

그러므로 이 기법은 전형적인 귀납적 분석방법이며 상향성 (bottom-up), 정성적인 위험성 분석기법의 대표라고 할 수 있다. 특히 결함과, 다음 상위 수준의 기능적 제품에 미치는 영향과 메커니즘을 연구하는 데 적합하다.

IEC 812 는 이 기법의 목적을 다음과 같이 밝히고 있다.

• 원인이 무엇이든 제품 기능적 구조의 다양한 수준에서, 각각의 규정된 품목의 고장모드가 초래할 수 있는 사건의 영향과 연쇄를 평가한다. 
• 각 고장모드가 제품의 정상적 기능이나 성능, 또는 관련된 과정의 신뢰도나 안전성에 미치는 중요성이나 치명도를 결정한다. 
• 판명된 고장모드를 검출성 (detectability), 진단성 (diagnosability), 시험성 (testability), 교체성 (replaceability), 보상 및 운용성, 기타 적절한 특성에 따라 분류한다. 
• 자료의 가용여부에 따라 중요도와 고장확률을 추정한다.  

시기적으로, 이 분석은 제품 구상, 계획, 정의단계에서 시행될 수는 있으나 제품의 구성과 기능에 관계된 구체적이고도 많은 자료를 필요로 하기 때문에 그 효과가 한정적이어서, 주로 제품 설계단계와 개발단계에서 이루어지는 것이 일반적이다.

자세히 보기 >>>

HAZOP 의 분석 순서

1) 목적 및 분석범위의 설정 
분석목적과 범위를 결정한다. 지나치게 많은 분석 대상은 많은 노력을 필요로 하기 때문에, 보통은 위험성이 높다고 판단되는 부분을 선정하여 분석을 집중하는 것이 보통이다.

2) 분석 팀의 구성 
분석 팀은 학제간 연구가 가능하여야 한다. 이것은 최초 ICI 사에서 규정한 HAZOP 의 정의에서도 분명히 규정하고 있는 사항이다. 그러므로 분석 팀은 전문가들이 참여하여야 하고, 아울러 관리가능하여야 하기 때문에 대체로 57 인 정도로 유지하는 것이 중요하지만, 작은 제품의 경우에는 경험많은 전문가 23 인으로도 가능하다.

분석팀의 구성원이 분석에 전념할 수 있도록 하기 위해서는 기록이나 보고서 작성을 위한 인원을 추가할 수 있다.

3) 예비조사 
예비작업은 일반적으로 다음과 같이 진행된다.

• 필요한 자료의 획득 
• 획득된 자료를 적절한 형태로 전환하거나 분석하기 위한 절차의 수립 
• 회의일정의 계획 

HAZOP 을 실시하기 위해서는 사전에 대상 제품에 대하여 충분히 숙지하고 있어야 한다. 또한 제품변수를 파악하고 그 결과를 예측하기 위해서는 제품설계도, 사용절차, 공정 흐름도 등 상세한 공정설명과 관계자료를 확보하고 있어야 한다. 이 때 확보되고 검토되어야 하는 자료들은 다음과 같다.

• P&IDs 
• 제품설계도 
• 제품흐름도 
• 선형 다이어그램 
• 제품설명 
• 사용설명서/절차 
• 제품재료정보 및 규격 
• 필요시 논리 다이어그램 추가 

4) 난상토론의 실시 

팀 구성원들이 함께 모여 난상토론을 한다. 난상토론 (brainstorming) 의 주된 장점은 팀 구성원들의 다양한 전문지식과 의견교환을 통하여 창조력과 상상력을 자극하여 다양한 아이디어를 만들어낸다는 점이다. 

이 때, 분석 및 검토대상은 보통 연구 절점 (study node) 이라고 부르는 제품변수들의 일탈이 조사될 제품 구조 및 기능상의 위치를 말한다. 일탈 (deviation) 이란 지침어를 체계적으로 적용시킴으로써 의도된 기능으로부터 벗어나는 상황을 가리킨다. 

안내 단어 (guide word) 란 HAZOP 만이 가지고 있는 독특한 기법으로, 난상토론을 통해 쉽게 일탈을 발견할 수 있도록, 의도된 기능을 정성화 또는 정량화하는 데 사용되는 간단한 용어들을 말한다. 각 안내 단어는 공정변수들과 적절히 결합될 수 있으며 연구절점, 제품의 일부, 사용단계 등 어떤 대상점에 대해서도 활용될 수 있다. 예를 들어 표 1과 같은 결합이 가능하다는 뜻이다. 

표 1. 안내 단어와 일탈  

공정변수들의 종류와 성격에 따라 많은 안내 단어들이 만들어질 수도 있고, 그렇지 않을 수도 있다. 예를 들어 온도의 경우에는 적정온도 이상 혹은 이하의 두 가지만 있을 뿐이다. 반면 어떤 변수들에 대해서는 이 안내 단어들이 적절하지 않을 수도 있으므로 약간의 수정을 가하여 활용하기도 한다.

5) 분석결과의 기록 
난상토론을 통하여 얻어지는 결과는 다음과 같다.

• 발견된 위험원 또는 제품 사용상의 문제 
• 안전성 향상을 위해 수행되어야 하는 설계 및 사용절차의 수정사항 
• 미진한 분석결과를 보완하기 위하여 수행되어야 하는 심층분석 

이 결과는 표2와 같은 양식으로 문서화한다.

표2. 분석결과 기록 양식의 예 

위험 분석 기법 - HAZOP (Hazard and Operability)

HAZOP 의 기본 전제는, 제품이 원래 설계된 대로 작동하는 한 근본적인 위험성이나 운용상의 문제는 없다는 것이다. 그러나, 만일 무엇인가의 이유로 인해 이상요인이 발생하게 되면, 제품이 그 충격을 감당할 수 있느냐 없느냐에 따라 사고가 발생한다는 것이다.

이 기법은 영국의 임페리얼 화학공업주식회사 (Imperial Chemical Industries Ltd., ICI) 에서 개발되어 미국 화공기술자협회 화학공정안전센터 (American Institute of Chemical Engineers Center for Chemical Process Safety) 에서 정리된 기법으로서, 여러 전문분야의 구성원들로 이루어진 분석 팀이 조직적으로 난상토론 (brainstorming) 을 하는 과정에서 시스템의 위험원들과 운용상의 문제점을 구명하는 것이다.

방법론과 분석내용으로 보아서는 앞에서 살펴 본 What If 분석과 크게 다르지 않지만, 분석을 연구 절점 (study nodes) 이라고 하는 특정부분에 집중시키며, 지침어 (guide words) 라고 하는 독특한 분석지침을 도입하기 때문에 좀 더 조직적이고 체계적으로 분석을 할 수 있다는 점에 차이가 있다.

HAZOP 의 분석 목적은 다음과 같이 정리할 수 있다.

• 의도된 설계기능이나 조건 등을 포함하여, 제품이나 시스템의 상세한 설명을 제공한다. 
• 시스템이나 제품의 모든 부분을 체계적으로 검토함으로써, 설계의도로부터의 일탈이 어떻게 발생하는가를 파악한다. 
• 이러한 일탈들이 위험이나 사용상의 문제들을 초래할 수 있는지 결정한다. 

HAZOP 에서는 기본적으로, 제품의 기능특성이 제품의 상태변수를 통해 표현되어야 한다. 제품의 상태변수 (process parameters) 란 제품의 기능이나 운용상태를 나타내기 위한 물리적 변수들을 말하는데, 표 1 에서 보는 바와 같이 온도, 습도, 압력, 유속, 반응속도 등이 그 예이다.

표1. 제품의 상태변수 예시 

SW 제어 구분(예시)

SW 는 제어 특성에 따라 6 개의 제어 범주로 구분할 수 있다.

범주 1

• 시스템의 기능을 독자적으로 제어하는 SW
• 해당 SW 의 오작동으로 인한 위험원 발생을 완화하기 위한 다른 독립 적인 하위 시스템이 없어서 해당 SW 의 고장이 직접적으로 시스템의 위험원을 발생시킨다. 

범주 2

• 시스템의 기능을 제어하는 SW
• 해당 SW 의 오작동으로 인한 위험원 발생을 완화하기 위한 다른 독립적인 하위 시스템이 있다. 

범주 3

• 시스템의 위험원을 탐지하고, 위험원을 완화하기 위한 사용자의 조치를 요구하는 기능을 수행하는 SW
• 해당 SW 의 오작동은 시스템의 위험원을 발생시킨다. 

범주 4

• 시스템의 기능을 제어하는 SW
• 해당 SW 의 오작동으로 인한 위험원을 방지할 수 있는 다중의 독립된 하위 시스템이 존재한다. 

범주 5

• 시스템의 위험원을 탐지하고, 위험원을 완화하기 위한 사용자의 조치를 요구하는 기능을 수행하는 SW
• 그러나 해당 SW 외에도 다중의 독립적인 상태정보를 제공하는 독립적인 하위 시스템이 있다. 

범주 6

• 시스템의 기능을 제어하지 않으며, 사용자 조치를 위한 정보를 제공하지도 않는 SW 

표는 SW 의 안전무결성 수준 결정을 위한 SW 위험원 심각성 매트릭스로 SW 의 안전무결성 수준은 SW 의 제어특성과 시스템의 안전무결성 수준의 조합으로 결정된다. 세로축은 SW 의 제어범주를 나타내며, 가로축은 시스템의 안전무결성 수준을 나타낸다. 예를 들어, 시스템의 안전무결성 수준이 4 이고 SW 의 제어범주가 ④이면, 해당 SW 의 안전무결성 수준은 최소한 2 이상으로 개발되어야 한다. 

안전 무결성 수준(SIL) 결정

IEC61508 에서는 안전 무결성수준(SIL)을 주어진 조건하에 있는 안전관련 시스템이 주어진 시간 내에 요구되는 안전 기능을 만족스럽게 수행할 수 있는 확률로 정의하며, 크게 네가지 등급으로 분류하고 있으며, SIL 4 가 가장 높은 수준이고 SIL 1 이 낮은 수준이다. 안전 무결성은 안전 기능을 수행하는 안전관련 시스템의 성능과 관계되어 있다.

SW 안전 무결성 수준은 모 시스템의 안전 무결성 수준을 하위시스템으로 할당하는 과정을 통해서 결정된다. 즉, 시스템의 안전 무결성 수준을 SW 를 하나의 구성요소로 갖고 있거나 또는 SW 가 유일한 구성요소일 수 있는 하위시스템으로 할당하므로 하위 SW 시스템에 대한 안전 무결성 수준은 상위의 시스템 안전 무결성 수준과 같은 수준으로 배정한다. 그림 1은 할당 과정을 보여준다.

그림1. 안전 무결성 할당 과정

이와 같은 조건은 SW 안전 무결성 수준이 다음과 같은 사항들을 고려하여 감소될 때까지 그대로 유지된다.

위험 완화 기능을 수행하는 하위 시스템에서 단일 또는 복수 고장이 발생하여도 위험한 사건(hazardous Event)이 감소되도록 안전 기능을 복수 이상 제공하는 구조적 설계를 시스템에 반영한다. 하위 시스템이 도출된 위험한 사건 또는 감소 기능에서 어떤 역할을 수행하는지 파악한다. 하위 시스템들의 역할과 그 연계를 파악할 수 있도록 충분히 상세하게 시스템의 구조적 특징이 정의되어야 한다.

SW 의 무결성 수준을 결정하기 위해 필요한 내용은 다음과 같다.

• 시스템 안전 무결성 수준 
• 위험원 목록과 각 위험원에 대한 다음과 같은 정보 
• 위험원을 초래한 수 있는 개시 사건들 
• 각 개시 사건에 대한 발생 예상 빈도 또는 확률 
• 각 하위시스템의 역할을 결정하고 완화 기능을 파악하기 위해 충분히 상세한 시스템 구조의 정의  

하위 시스템에 안전 무결성 수준을 할당하는 방법은 아래와 같다.

• 대상 시스템을 구성하는 모든 하위 시스템들을 규명한다.  
• 어떤 하위시스템의 고장이 단일 또는 복합적으로(다른 하위시스템의 상태와 조합해서) 시스템의 위험원이 되는지 결정한다. 복합 구성에서 만약 한 하위 시스템의 고장이 독자적으로 시스템의 위험원이 된다면 그 하위 시스템의 안전 무결성 수준은 시스템의 안전 무결성 수준과 동일하게 할당된다. 만약 그 하위시스템의 고장이 다른 하위시스템들의 상태와 조합해서 시스템의 위험원이 된다면 그 하위시스템의 무결성 수준은 다음에 정의된 평가결과에 따라 감소될 수 있다. 다음에 언급된 평가는 강제 사항은 아니나, 하위시스템의 무결성 수준을 감소시키기 위해 수행한다. 
• 어떤 하위시스템의 고장이 독립적으로 또는 다른 하위시스템의 상태와 조합해서 시스템의 완화 기능의 수행 여부에 영향을 줄 수 있는지 결정한다. 그림 2는 시스템 사이의 관계를 개념적으로 보여준다. 

 그림 2. 시스템 사이의 관계 

• 하나의 하위 시스템의 고장이 독자적으로 시스템의 완화 기능을 수행하지 못하게 한다면 그 하위시스템의 무결성 수준은 시스템의 무결성 수준과 동일하게 할당된다. 만약 그 하위시스템의 고장이 다른 하위시스템들의 상태와 조합해서 시스템의 완화 기능을 수행하지 못하게 한다면 그 하위시스템의 무결성 수준은 다음에 정의된 평가결과에 따라 감소될 수 있다. 다음에 언급된 평가는 강제사항은 아니나, 하위 시스템의 무결성 수준을 감소시키기 위해 수행한다. 
• 고장이 시스템의 위험원이 되지 않거나, 시스템 사건의 완화 기능과 관계가 없는 SW 가 탑재된 하위시스템들이 있는지를 결정한다. 그러한 SW 는 가장 낮은 무결성 수준을 할당한다. SW 고장이 위험원을 초래할 수 없도록 하기 위하여 결함 격리(fault isolation)가 필요하다. 시스템의 설계 담당자와 안전(또는 품질보증) 담당자는 결함이 적절하게 격리되도록 하기 위하여 시스템의 구조가 적합한지 조사해야 한다. 만약 결함 격리가 고장처리방법으로 가능하다면 그 방법은 시스템과 동일한 SW 무결성 수준이 할당된다. 

위의 네 가지 절차는 SW 만으로 이루어진 모든 하위시스템들의 무결성 수준이 결정될 때까지 또는 SW 를 하나의 구성요소로 하는 모든 하위시스템들의 무결성 수준이 설계 담당자와 안전 담당자에게 적절하다고 인정될 때까지 반복적으로 적용한다.

<위험 분석 절차> 안전 기능 할당

시스템의 위험원에 대하여 위험성이 정해진 후 해당 위험성을 수용할 수 없을 경우에 어떻게 위험원의 발생빈도를 허용 가능한 발생빈도로 낮출 것인지, 제어시스템의 위험성을 허용 가능한 목표치에 도달시키기 위한 안전 기능은 무엇인가에 대한 문제를 해결한다. 이러한 문제를 해결하기 위해서는 다음 사항을 만족 해야한다.

• 모든 위험원과 관련된 발생원인을 세부적으로 도출한다. 
• 발생 원인이 위험원으로 진전되지 않도록 하는 안전기능을 도출한다. 
• 발생 원인을 나눌 경우 가능한 한 최소한으로 나누어야 한다. (Minimal Cut Set) 

각 안전기능은 개발된 관련 안전무결성 요구사항을 하나 이상의 지정된 E/E/PE 안전관련 시스템 및/또는 기타 리스크 감소 설비에 할당하여 안전기능을 위한 허용 가능 리스크가 달성될 수 있도록 한다. 

이런 할당은 반복적이며, 허용 가능 리스크가 달성되기 어렵다고 판단되면 위험요인을 감소하기 위한 기능을 추가로 개발하여 EUC 제어 시스템, 지정된 E/E/PE 안전관련 시스템 및 기타 리스크 감소 설비를 위한 명세를 변경하고, 할당을 반복한다. 명세된 안전기능을 모두 할당하고 목표고장 기준으로 각 안전기능을 정의한다. 그림 1은 위험원 제거를 위한 안전기능 할당의 절차를 보여준다. 

그림 1.  위험원 제거을 위한 안전 기능 할당 절차

제어시스템의 안전 기능을 도출하여 해당 위험성을 낮추려고 할 경우에는 가능한 한 최악의 경우를 고려한다. 그러나 제어시스템과 같이 복잡한 시스템의 안전기능의 정도를 설정함에 있어서 다음과 같은 어려움이 있다. 

• 시스템의 갖가지 기능들이 고장날 경우 그 고장 정도는 매우 다양하다. 
• 시스템의 고장을 방지할 안전 기능은 일반적으로 몇 가지 위험원에만 영향을 미친다. 
• 위와 같은 특성을 가지는 안전기능에 단순히 안전 무결성 수준을 설정하여 평준화하는 것은 주관적이며, 모호한 작업일 수 있다. 

 

이러한 SIL 할당의 어려움을 보완하기 위하여 다음과 같은 절차를 적용한다. 

• 조치를 취해야 하는 위험원에 대하여 최대로 수용 가능한 발생 빈도 또는 허용 가능한 위험률을 적용한다. 
• 어느 고장측 고장이 어떤 기능에 영향을 미쳐 잠재적으로 위험원이 발생하는지 확인한다. 이는 어느 고장측 고장이 다른 고장측 고장과 And 게이트로 연결되어 있는지 확인하는 것이다. 
• 잠재적인 위험원 중 가장 낮은 값을 선택한다. 
• 해당 안전 기능을 안전무결성 수준으로 전환한다. 

제어시스템을 운영하는 동안 다양한 상황이 발생한다. 매우 다양한 위험원이 발생할 수 있으나 그 발생 빈도를 평가한다는 것은 매우 어려운 작업이다. 예를 들어 인적 요인과 관련된 위험원이 그런 경우이다. 따라서 각각의 위험원을 보완하는 안전기능들이 필요한지, 필요하지 않은지를 결정하는 문제부터, 안전기능에 필요한 레벨은 어느 정도인지를 결정하기 위해서 주어진 운영환경의 특징 및 통계값을 살펴보고, SIL 에 기반을 두어 좀더 자세히 위험성 분석을 수행해야 한다.
 

<위험 분석 절차> 안전 요구사항 할당

지정된 E/E/PE 안전관련 시스템 및 기타 리스크 감소 설비에 전체 안전 요구사항(전체 안전기능 요구사항과 안전무결성 요구사항 모두)에 대한 명세를 포함하여 안전기능을 할당하고, 각 안전 기능에 목표고장 기준과 안전무결성 수준을 할당한다.

필요한 기능안전성을 달성하기 위해 사용될 지정된 안전관련 시스템을 명시한다. 허용가능 리스크 감소는 E/E/PE 안전관련 시스템 및 기타 리스크 감소 설비에 의해 충족될 수 있다.

각 안전기능과 안전무결성 요구사항을 하나 이상의 지정된 E/E/PE 안전관련 시스템 또는 기타 리스크 감소 설비에 할당하여 안전기능을 위한 허용 가능 리스크가 달성될 수 있도록 한다. 이런 할당은 반복적이며, 허용 가능 리스크가 달성되기 어렵다고 판단되면 EUC 제어 시스템, 지정된 E/E/PE 안전관련 시스템 및 기타 리스크 감소 설비를 위한 명세를 변경하고, 할당을 반복한다.

안전무결성 요구사항 할당은 확률을 조합하는 적절한 기법을 이용하여 수행한다. 할당이 충분히 진행되면 E/E/PE 안전관련 시스템(들)에 할당된 각 안전기능에 대한 안전무결성 요구사항을 안전무결성 수준으로 명시한다. 표를 참고한다.

• 저요구 작동모드(low demand mode of operation)에 대한 안전 기능의 요구 시 위험측 고장평균 확률(PFDavg, Probability of Failure on Demand) 
• 고요구 작동모드 (high demand mode of operation)에 대한 안전 기능의 위험측 고장 평균 빈도(PFH, Probability of Failure per Hour) 
• 연속적인 작동모드(continuous mode of operation)에 대한 안전 기능의 위험측 고장 평균빈도(PFH). 

위와같이 세가지 유형의 작동 모드를 구분하는 이유는 빈번한 호출이 이루어지지 않는 경우에는 확률적으로 정확한 측정이 어렵기 때문에 이를 보완하기 위한 별도의 측정 변수 및 기준이 필요하기 때문이다.

서로 다른 안전무결성 수준을 가지는 안전기능들을 구현하는 E/E/PE 안전관련 시스템의 경우 특정 안전기능들 간의 구현 독립성이 충분하다는 것을 보여줄 수 없다면, 이렇게 구현 독립성이 불충분한 안전관련 하드웨어와 소프트웨어의 각 부분(Part)들은 가장 높은 안전무결성 수준을 가지는 안전기능에 속하는 것으로 취급한다. 그러므로 가장 높은 관련 안전무결성 수준에 적용 가능한 요구사항들을 모든 부분(Part)에 적용한다.

<위험 분석 절차> 안전 요구사항 명세

이 단계에서는 E/E/PE 안전관련 시스템 및 기타 리스크 감소 설비에 대해 필요한 기능안전성을 달성하기 위해 안전기능 요구사항 및 안전무결성 요구사항의 측면에서 전체 안전 요구사항에 대한 명세를 개발한다.

위험원 및 위험 분석으로부터 얻은 위험한 사건에 기초하여 필요한 모든 전체 안전기능 요구사항에 대한 명세를 개발한다. 보안 위협이 확인된 경우 보안 요구사항을 규정하기 위해 취약점 분석을 수행한다.

각각의 전체 안전기능을 위해 목표 안전무결성 요구사항을 허용 리스크에 부합되도록 결정하고 각각의 요구사항은 정량적 또는 정성적 방법으로 결정하며, 이는 전체 안전무결성 요구사항의 명세를 구성되며, 전체 안전무결성 요구사항은 다음중 하나의 관점에서 규정한다.

• 허용 가능 리스크를 달성하는 데 필요한 리스크 감소 
• 허용 가능 리스크를 충족하기 위한 허용 가능 위험한 사건 

EUC 리스크를 평가할 때 단일 EUC 제어 시스템 기능의 위험측 고장의 평균 빈도가 시간당 10－5 이하일 경우 그 EUC 제어 시스템은 요구사항에 따르는 안전관련 제어 시스템으로 간주한다.

EUC 제어 시스템의 고장으로 하나 이상의 E/E/PE 안전관련 시스템 및/또는 기타 리스크 감소 설비가 필요한 경우, 그리고 EUC 제어 시스템을 안전관련 시스템으로 지정하지 않는 경우, 다음의 요구사항을 적용한다.

• 위험측 고장률은 다음에서 얻은 데이터로써 확인 
• 유사한 응용에서의 EUC 제어 시스템의 실제 운영 경험 
• 인정되는 절차에 의해 수행된 신뢰도 분석 
• 일반 장비의 신뢰성있는 산업 데이터베이스 
• 위험측 고장률은 시간당 10의 (-5)승 보다 높아야 함 
• 합리적으로 예측 가능한 모든 위험측 고장 모드는 전체 안전 요구사항에 대한 명세의 개발을 고려 
• E/E/PE 안전관련 시스템 및 기타 리스크 감소 설비로부터 독립적 

위 요구사항을 충족할 수 없는 경우, EUC 제어 시스템을 안전관련시스템으로 지정해야 한다. EUC 제어 시스템 기능의 안전무결성 수준에 따라서 EUC 제어 시스템에 대해 요구되는 위험측 고장률에 의해 결정된다. 그러한 경우, 할당된 안전무결성 수준에 해당되는 요구사항을 EUC 제어 시스템에 적용한다.

자세히 보기 >>>

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

위험원 식별

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) 프로세스를 도입하는 것도 좋은 방법이다. 더 보기 >>>

모바일 기기 확대로 인한 회사들의 보안 문제

거의 모든 회사원들에게 모바일 기기가 보급되면서 모바일을 이용하여 업무를 수행하도록 하는 회사들이 지속적으로 늘어나면서 회사 업무 보안에 대한 관심도가 증가하고 있지만 이보다 더 임직원들을 통해 회사 안으로 들어오는 모바일 자체에 대한 보안 문제는 고민거리를 더 안겨주는 추세다. 이번 회에서는 단국대학교 보안연구실의 연구원들, 글로벌테크 이성규 이사와 함께 모바일의 확대로 인해 늘어가는 회사들의 고민거리에 대해 알아보기로 한다.

Q: 안녕하세요. 최근에 스마트폰의 등장으로 기업에서 스마트폰을 이용하여 업무 영역을 확대하는 사례가 늘고 있습니다. 모바일과 관련된 기업들의 움직임에 대해 먼저 부탁합니다.

회사 내에서 스마트폰이 없는 사람은 아마 거의 없을 겁니다. 스마트폰 자체를 거부하는 일부 피쳐폰 사용자 말고요. 그러다 보니 기업의 경영자 입장에서는 스마트폰을 이용하여 업무의 편의성을 제공하려 한다지만 어떻게 보면 더 타이트한 업무 범위를 강조하는 것일 수 있지요. 회사에 도움이 되지 않는데 일부러 비용을 들여서 적용할 필요는 없기 때문이죠. 이메일도 더 빨리 볼 수 있고 결재도 더 신속히 결정되고 근태도 스마트폰으로 신청할 수 있고요. PC 앞에서 처리하던 것들을 스마트폰으로 할 수 있으니 업무 관점의 신속성이 더 높아진 것이죠.

<그림1> 기업 내 업무 커뮤니케이션 설문 결과

출처: 이스트소프트

그림1을 보면 스마트폰으로 업무를 활용하는 수치가 지금도 계속 증가하고 있습니다. 우리가 스마트폰으로 흔히 이용하는 메신저나 이메일 뿐만 아니라 자료 공유나 문서 작성에도 많이 활용하고 있다는 것이 눈에 띄는 변화입니다. 그리고 다소 사용률이 떨어질 것 같은 중년층의 경우도 지속적으로 늘어가고 있고 사장이나 임원들이 더 적극적으로 활용하고 있는 추세이기 때문에 증가하는 속도는 더 빨라질 것으로 보입니다.

Q: 업무에 스마트폰을 활용하는 경우가 계속 증가하고 있는 것은 부정할 수 없는 사실이긴 한데 업무에 도움이 많이 되기 때문인가요?

논란이 있기는 하지만 도입한 회사들의 경우 커뮤니케이션에는 상당히 도움이 된다는 보고가 나오고 있기는 합니다만 사용자인 직원들은 불만 섞인 피드백이 많이 나오는 것도 사실입니다. 시도 때도 없이 울려대는 스마트폰 때문에 회사 안과 밖의 경계가 없어진 때문이겠죠. 긍정적인 면을 본다면 담당자와 한시도 떨어지지 않는 스마트폰은 업무 공백을 없애주는 핵심 요소이기 때문에 업무에 도움을 준다고 봐야겠지요.

<그림2> 모바일 오피스의 예

출처: 삼양데이타시스템

예전에 그룹웨어(Groupware)가 유행하던 현상과 비슷하다고 보시면 되지요. 그룹웨어도 처음에는 이메일이나 회사 게시판 정도가 운영되다가 화상 회의나 일정 관리, 주요 거래선 관리, 결국 회사 전용 메신저도 추가되었고 구글 드라이브와 같은 문서 공유 솔루션도 만들어졌지요.

더 보기 >>>

Technical Debt as a Core Software Engineering Practice

참석자

Ipek Ozkaya - At the SEI she is the deputy lead for the Architecture Practices initiative.

요약

---
기술 채무 (Technical Debt): 소프트웨어 개발 프로젝트를 진행할 때, 초기에 제대로 처리하지 않은 일이 반복 주기에서는 문제점으로 나타나고, 이러한 문제점이 다른 수정사항이나 또 다른 문제를 나타낼 수 있어 원금에 이자까지 지불해야 하는 상황이 온다는 개념

---

이번 이야기는 기술 부채와 소프트웨어에서의 의미에 관한 것입니다. 수년에 걸쳐서 우리는 레거시 현대화, 애자일 적용, 아키텍처가 충분히 많은지, 어떤 것을 바꿔야 기술이 바뀌는지 문제를 겪은 많은 고객과 함께 했습니다.

다양한 고객과 다양한 문제에 걸쳐 한 가지 사실은 있습니다. 실제로 시스템에 남는 것을 표현할 수 없다는 것입니다. 예를 들어, 정말로 레거시를 업그레이드 해야 합니까? 정말로 아키텍처를 다시 만들어야 합니까? 그리고 어떻게 트레이드-오프를 결정해야 합니까? 결국 마지막에는 비즈니스 결정만 아니라 디자인 결정을 해야 한다는 것입니다. 하지만 일단 비용 측면을 고려하면서 트레이드-오프를 이야기하면 계속 반복될 겁니다. 그것은 커뮤니케이션 메커니즘뿐만 아니라 연관된 여러 연구 과제에서 기술적 부채를 찾는 시작입니다. 이것이 프로젝트의 착수 방법입니다.

요약글 더 보기 >>>

<위험 분석에 대한 접근> 시스템 안전 분석의 일부로서 SW 위험 분석

SW 는 시스템의 일부분으로 위험 분석은 전체 시스템의 설계 맥락에서 수행되어야 한다. SW 그 자체만으로는 안전성 문제를 발생시키지 않고, SW 가 시스템의 일부분으로 구성될 때 비로소 문제가 발생한다. 따라서 SW 안전성은 HW 와 결합되는 지점부터 위험분석이 시작되어야한다. 또한 관련된 HW, 주변 환경, 그리고 사람 등을 고려해야 한다. 때문에 SW 위험 분석을 수행하는 분석가는 시스템 안전 기능의 수행과 시스템 제어 및 감시 기능의 수행에 있어서 SW 역할을 이해해야 하고, 해당 시스템 안전성 달성에 있어서 SW 가 시스템에 미치는 영향을 잘 파악해야 한다.

시스템 설계에 있어 안전 특성들은 기본적으로 품질, 다양성, 그리고 심층방어의 세 가지 설계 원칙으로 결정된다. 이 원칙들이 여러 계층의 설계에 적용될 수 있으며, 어디에 어떻게 적용할 것인지를 결정하는 것이 설계 공정의 중요한 활동이고, 세 가지 원칙은 다양한 형태의 공정제어 장치에 적절하게 적용 가능하다.

물리적인 관점에서 심층방어 개념을 예를 들어 살펴보면, 핵분열 생성물의 누출을 통제 하기 위해 세 계층의 심층방어 설계가 마련되어 있다. 각 계층은 어느 정도 심각한 수준의 방사선으로부터 일반 대중의 피폭을 방지할 수 있어야 한다. 첫 번째 계층은 핵연료봉이 그 피복재로 싸여져 있다. 두 번 째 계층은 핵연료봉에서 세어나온 핵분열 생성물이 E/E/PES 시스템냉각재장치(RCS)에 의해 격리된다. 세 번째 계층은 E/E/PES 시스템 건물이 E/E/PES 시스템 냉각재 장치를 에워싸고 있다. 이들 각 계층은 기본적으로 서로 다른 설계이며, 각 계층마다 다양성을 부여하고 있다.

계측제어 관점에서 살펴본 심층방어 개념으로는 각 기능이 여러 개의 독립적인 시스템들에 의하여 작동될 수 있다. 예를 들면, 제어봉은 제어 장치, E/E/PES 시스템보호장치, ATWS 완화 장치, 공학적안전설비 작동 장치(ESFAS)에 의해 자동 또는 수동으로 작동될 수 있다. 또한 컴퓨터 기반 제어 및 보호장치들을 포함한 신형 E/E/PES 시스템 설계에서는 적어도 두 개의 자동시스템이 각 안전 기능을 개시할 수 있어야 한다. 그리고 운전원이 각 안전 기능을 시작, 가동, 종료할 수 있도록 충분한 정보와 수동 제어기능을 마련하여야 한다.

위험 분석 절차와 수행할 안전 요구사항

1. 개념
• EUC(Equipment Under Control) 이해 
• 필요한 제어 기능 및 물리적 환경 정의 
• 유해 사건 원인 결정, 위험원 정보, 현재 안전규정(법/제도) 등 파악 
2. 범위 정의
• EUC 와 제어시스템의 경계 결정 
• 위험원과 리스크 분석 적용 범위(프로세스, 환경) 결정 
• 고려할 외부 사건, 연관된 장비/시스템, 고려할 사건 유발 유형 결정 
3. 위험원 및 위험 분석 
• 위험원 식별 
• 위험원, 위해 사건 식별 (위험원 제거/감소 도 고려) 
• 위험한 상황(결함, 예상 가능한 오용, 악의, 비 허가) 결정 
• 위험성 계산 
• 결정된 위해 사건으로 이어지는 사건 순서를 결정 
• 명시된 상황에서 위해 사건 발생 가능성 평가 
• 결정된 위해 사건과 연관된 잠재 결과 확인(심각도) - 정량적 또는 정성적인 위험원 및 리스크 분석 기법 적용 
• 위험한 사건과 관련된 위험 결정(평가/추정) 
4. 안전 요구사항 명세
• 기능 안전성 달성(위험 제거/감소) 전체 요구사항 명세 개발 
• 안전 기능(Safety Function) 요구사항 명세 
• 안전 무결성(SIL, safety Integrity Level) 요구사항 명세
• 목표 안전 무결성 요구사항: 허용 리스크에 부합
• 필요한 리스크 감소 : 허용 가능한 리스크 달성
• 허용 가능한 사건 : 허용 가능한 리스크 충족 
5. 안전 요구사항 할당 
• 안전 기능 --> 안전관련 시스템, 위험 감소 수단에 할당 
• 안전 기능이 허용 가능한 리스크 달성하도록 할당 지속
• 달성이 어려우면 명세를 변경하면서 지속적으로 할당 반복 
• 전체 안전 기능이 할당되고, 목표 고장 기준이 안전 기능에 할당 
• 안전 무결성 수준(SIL) --> 각 안전 기능에 할당 
• 확률을 조합하여 적절한 기법 이용, 공통 원인 고장 가능성 고려 
• 목표 고장 기준 : 저요구/고요구/연속적 작동 모드 

위험 분석 절차

위험성은 위험원의 발생빈도와 심각도의 조합으로서 발생빈도가 빈번하거나 발생빈도가 빈번하지 않더라도 사고가 발생하면 치명적인 결과를 초래하는 위험원은 위험성이 크다고 정의한다. 사고관련 위험원의 위험성을 허용할 수 있는 수준으로 제어하고자 하는 안전성 관리는 시스템 수명주기의 요구사항 분석 단계부터 안전계획을 수립하여 도출된 안전 요구사항을 바탕으로 안전한 시스템이 되도록 설계, 구현 및 시험을 수행하여 위험원을 지속적으로 관리하고 확인 및 검증을 통해 시스템의 안전성을 확보한다.

안전성 확보를 위한 위험분석 절차는 대상 제어시스템에서 위험원을 중심으로 결과, 손실, 위험성을 파악하는 위험분석 단계와 해당 위험에 대한 원인 분석을 통해 위험 제거 및 감소를 위한 안전 기능을 도출하여 SIL 을 할당하고 이를 시스템 하위 서브시스템, HW, SW 에 할당하는 단계로 정의할 수 있다.

IEC61508 에서 제시하는 전체 안전 수명주기에서 위험분석 단계로 그림과 같은 개념정의(Concept), 범위 정의(Overall Scope Definition), 위험원 및 위험 분석(Hazard & Risk Analysis), 안전 요구사항 명세(Overall Safety Requirements), 안전 요구사항 할당(Overall Safety Requirements Allocation) 으로 구성 된다.

그림. IEC61508 기준 위험분석 절차

위험성은 위험원의 발생빈도와 심각도의 조합으로서 발생빈도가 빈번하거나 발생빈도가 빈번하지 않더라도 발생 시 치명적인 결과를 초래하는 위험원은 위험성이 크다. 사고관련 위험원의 위험성을 허용할 수 있는 수준으로 제어하고자 하는 안전성 관리는 시스템 수명주기의 위험분석 단계부터 안전계획을 수립하여 도출된 안전 요구사항을 바탕으로 안전한 시스템이 되도록 설계, 구현 및 시험을 수행하여 위험원을 지속적으로 관리하고 확인 및 검증을 통해 시스템의 안전성을 확보한다.

수명주기별 안전성 관리

가. 수명주기 개요 

안전관련 시스템에 의해 수행되는 안전기능에 대해 필요한 안전무결성 수준을 달성하기 위한 모든 활동을 체계적인 방법으로 다루기 위하여, IEC 61508 에서는 기술 프레임워크로서 전체 안전수명주기를 제시하고자 한다. 전체 안전수명주기는 이 표준 준수를 위한 객관적 참조물로 제시되고, 각 단계의 목적과 요구사항에 충족된다면, 다른 SW 개발 안전수명주기를 이용할 수 있다.

소프트웨어 개발을 위한 안전수명주기는 IEC 61508 에 따라 전체 시스템 개발계획에 안전계획이 결정되고 명시되어야 한다. 표준에서 요구하는 사항을 만족시키는 안전수명주기 모델은 본 가이드에서 참조 가능하도록 상세하게 제시하였으며, 프로젝트나 조직의 특정한 구체적 요구에 맞추어 적절하게 조정하여 사용할 수 있다. 다음은 IEC 61508 에서 제시하는 수명주기 관련 요구사항은 다음과 같다.

• 품질과 안전 보증 절차는 안전수명주기의 각 활동들과 통합되어야 한다. 
• 소프트웨어 안전수명주기의 각 단계는 적용범위를 갖는 기초 활동과 각 단계를 위해 명시된 입력과 그 결과물인 산출물로 구분되어야 한다. 
• SW 수명주기 단계에 관한 자세한 정보는 ISO/IEC 12207 을 참조한다. 
• IEC 61508－1 의 안전수명주기 단계별 산출물들이 포함되어야 한다. 
• 산출물은 E/E/PE 안전관련 시스템의 개발마다 때로는 몇 개가 병합되기도 하고 세분화되어 나누어진 별개의 문서로 제공될 수도 있다.  
• 핵심적인 요구사항은 모든 안전수명주기 단계들의 산출물은 그 의도된 목적에 적합해야 한다는 것이다. 간단한 개발에서는 일부 안전수명주기 단계들이 병합될 수 있다. 
• 소프트웨어 안전수명주기가 IEC61508 에서 요구하는 사항을 만족시킨다면, V 모델 단계들의 정도, 수, 작업규모를 안전무결성 및 프로젝트의 복잡성을 고려하여 일부 절차 및 활동은 조정할 수 있다. 
• 표준에서 제시하는 수명주기 단계들의 전체 리스트는 대체로 규모가 크고 새로 개발된 시스템에 적합하다. 예를 들면 소규모 시스템에서는 소프트웨어 시스템 설계 및 아키텍처 설계 단계를 병합하는 것이 적합할 수도 있다. 
• 표준의 모든 목적과 요구사항을 만족한다면, 다르게 소프트웨어 프로젝트를 관리할 수 있다(즉, 다른 소프트웨어 안전수명주기 모델 이용 가능). 
• 각 안전수명주기 단계에서 SW 안전성 보증을 위해 적절한 기법과 수단이 이용되어야 한다.  
• 소프트웨어 안전수명주기에서의 활동 결과들은 문서화되어야 한다. 

나. 수명주기 개발 참조 관련 규격 및 문헌 

• IEC 61508-1:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 1: General requirements 
• IEC 61508-2:2010, Functional safety of electrical/electronic/programmable electronic safetyrelated systems – Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems 
• IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safetyrelated systems – Part 3: Software requirements 
• IEC 61508-4:2010 Functional safety of electrical/electronic/programmable electronic safetyrelated systems – Part 4: Definitions and abbreviations 
• IEC 61508-5:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 5: Examples of methods for the determination of safety integrity levels 
• IEC 61508-6:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3 
• IEC 61508-7:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems – Part 7: Overview of techniques and measures 
• KS C IEC61508－1:2010 전기/전자/프로그램 가능 전자식 안전관련 시스템의 기능 안전성 - 제 1 부: 일반 요구사항 
• KS C IEC61508－3:2010 전기/전자/프로그램 가능한 전자장치 안전관련 시스템의 기능안전성－제 3 부：소프트웨어 요구사항 
• 철도 소프트웨어 안전 기준 및 체계 구축 연구보고서, 2008 
• NUREG CR-6430 UCRL-ID-122514 SW Safety Hazard Analysis, NRC, USA 
• NUREG IA-0145 RELAP5 Assessment Against - Revision 1, NRC, USA 
• IEEE730 A guide to writing successful SQA plans 
• IEEE829:2008 SW test documentation 
• IEEE1016:2009 Software design description 
• IEEE1012:2004 Standard for Software Verification and Validation 
• IEEE1228:1994 IEEE Standard for Software Safety Plans 
• IEEE1540:2001 Software Engineering Risk Management: Measurement-Based Life Cycle Risk Management 
• ISO12207:2004 Systems and software engineering - Software life cycle processes 
• SIL4 인증문서 한글 표준양식(템플릿) 적용사례 연구, 한국철도학회 
• 소프트웨어 개발 프로세스에서의 안전성 분석 및 관리 활동의 적용방안, 중소기업융합학회 
• 기능안전 적용을 위한 소프트웨어 개발 가이드라인, KTL 

 

다. 안전 수명주기 구성 

기능 안전 표준인 IEC61508 과 SW 수명주기 표준인 ISO12207 을 참고하여 안전 수명 주기를 구성하였다. SW 안전 수명주기는 크게 세 부문으로 구성되고 각 부문에는 아래와 같이 세분화된 단계로 구성될 수 있다.

 

• Analysis 부문 
• 위험분석 단계 
• Realization 부문 
• SW 계획 단계 
• SW 요구분석 
• SW 설계 단계 
• SW 구현 단계 
• SW 통합 단계 
• SW 확인 검증 단계 
• Operation 부문 
• SW 운영 단계 

Realization 부분의 SW 검증 및 확인 단계는 Realization 부문의 단계 시작 전에 계획되어 전 단계에 걸쳐 활동이 진행된다. 

그림. 전체 안전 수명주기(IEC61508) 

안전 기능과 안전 무결성

안전기능 요구사항은 위험원 분석을 통해 도출되고, 안전무결성 요구사항은 위험성 평가를 통해 도출된다. 안전 무결성(Safety Integrity)은 주어진 모든 조건하에 있는 안전관련 시스템이 주어진 시간 내에 요구되는 안전기능을 만족스럽게 수행할 수 있는 확률로 정의되고 안전무결성수준이 높을수록 해당 장비 또는 시스템의 고장 발생 가능성은 낮아진다. 그림은 안전 기능과 안전무결성의 관계를 보여준다.

그림. 안전 기능과 안전무결성 

안전무결성수준(SIL)은 전기전자프로그래머블제어기의 국제규격인 IEC61508 에 명시되어 있다. 안전무결성수준이 널리 사용되는 이유는 적용 대상이 명확하게 정의되지 않은 경우에 시스템의 안전성을 평가하여 시스템의 안전성을 상호 비교할 수 있는 방법이기 때문이다. 

예를 들어, 전자 연동 장치의 종합 안전성은 사고를 열차 충돌과 탈선으로 정의하는 경우에 전자연동장치의 출력에 의해 제어되는 선로 전환기나 신호기와 같은 장치와의 인터페이스 구조 및 전자연동장치 운영시나리오에 따라 결정된다. 따라서 연동장치가 설치될 역의 규모, 인터페이스 장치의 안전수준, 운용인력의 안전문화 등이 고려되지 않으면 열차충돌 및 탈선에 대한 안전성 확보를 평가할 수 없다. 이러한 경우 전자연동장치의 안전성을 평가하기 위해서 전자연동장치의 위험측 고장(Dangerous Failure)의 발생빈도를 평가하여 등급을 부여한 것이 안전무결성수준이다.

위험측 고장률은 위험원이라는 특별한 요건에 대한 발생빈도를 예측하고 입증하여 평가한 정량적 수치이다. 정의된 사고와 관련된 위험원을 도출하고 분석하는 단계는 위험원 관리와 같이 수행되며 위험원들의 발생빈도는 FTA(Fault Tree Analysis)와 ETA(Event Tree Analysis) 등의 기법에 의해 정량화되어 목표와 비교된다.

최종 사용자의 시스템 안전성 요구사항은 정량적 수치로 주어지기도 하지만 정성적이고 모호하게 제시되기도 한다. 이러한 경우 안전이 확보되어야 할 사고의 정의부터 위험성의 제어를 위해 필요한 안전 대책의 적용 범위도 명확히 분석되어야 한다. 시스템 개발 과정에서 공급범위를 벗어나는 안전 대책에 의해서만 위험원이 안전하게 제어되는 경우를 예측하여야 한다.

안전 요구사항의 할당은 시스템 안전성과 종합 안전성에 따라 상이하다. 시스템적 안전성만을 관리하는 경우에는 안전무결성수준과 같이 시스템에 요구되는 위험측 고장률의 목표 만족을 위한 하부 구성요소들의 위험측 고장률 목표를 설계단계에서 위험원 도출 및 분석을 통해 산출하여 배분해야 한다. 종합적 안전성의 경우 시스템적 안전성을 포함하여 설치, 테스트, 운용, 유지보수와 같이 인적요소가 가입되는 사항에 대한 안전 요구사항을 도출하여 해당 수명주기에 할당해야 한다.
 

영국의 안전성 관리 및 문서화 지침 CASS(Conformity Assessment of Safety-related Systems)

영국과 같이 안전분야의 선진국에서는 안전관련 시스템의 도입, 수정, 유지보수의 수명주기 단계별로 안전 활동을 수행하고 그 결과물을 국가가 지정한 기관에서 심사하도록 정부차원에서 강제하고 있다.

이러한 공인 기관의 심사를 위해서는 안전성 관련 요구사항 준수여부에 대한 객관적이고 효율적인 평가를 위해 공통의 양식이 필요하게 되었으며, 이러한 요구에 의한 안전성 관리 및 문서화 지침은 CASS(Conformity Assessment of Safety-related Systems)에 공유되어 많은 사업의 안전성 관리 문서화에 활용되고 있다.

그림. CASS 자료 공개 사이트(http://www.61508.org)

SW 영향평가 제도

SW분야에서 공공과 민간의 역할 정립을 위해 공공정보화 사업의 기획단계부터 민간시장에 미치는 부정적 영향을 평가.

정부가 민간시장을 위축시키면 안 되며 민간시장에 미치는 영향을 사전 평가하는 등 공공정보화 사업 추진절체 개선(SW중심사회 실현전략 보고회, ’14.7월)

자세히 보기 >>>

SW ASSETBANK UI UX (동영상)

IEC 61508의 안전성 관리

안전성 관리를 위한 국제 규격 IEC61508 은 수명주기 단계별 요구사항을 제시하고 있다. 수명주기 별 요구사항은 규격을 적용하는 시스템의 환경 및 범위 별 차별화되지 않고 모두 적용할 수 있도록 보편화되어 있으므로 요구사항의 만족을 입증하기 위한 문서화 및 입증자료 작성에 대한 구체적인 요구사항을 요구하지 않는다. 국제 표준을 적용한 국내외 인증기관들이 제공하는 입증자료인 위험분석 기법이나 위험원 목록의 양식이 다양한 이유도 이러한 요구사항의 보편성 때문이다.

안전성 관리는 안전관련 시스템 또는 소프트웨어 안전수명주기의 하나 이상의 단계에 대해 책임이 있는 사람들이 수행해야 할 기능안전성 관리 책임을 규정하는 것으로, 안전관련 활동 또는 안전수명주기에 대한 책임자가 해야 할 일은 다음과 같다.

• 시스템 및 수명주기 단계별 안전관련 활동 수행자의 역할 할당/조정 
• 이들 단계와 타 조직/시스템 간 인터페이스 
• 기능안전성 달성 정책, 전략, 평가 수단, 소통 수단 
• 감지되는 모든 위험한 사건 분석, 권고사항의 반복 발생 가능성 최소화 
• 기능안전성 평가 실행/조정(의사소통, 계획 및 문서화, 판단, 권고 등) 
• 기능안전성이 이 표준의 목적 및 요구사항에 따라 달성 및 입증되고 있는지를 확인 

또한 다음으로부터 발생하는 것들을 포함하여 안전관련 시스템에 관하여 즉시 대응 및 권고사항의 만족스러운 해결을 확보할 수 있는 절차를 개발해야 한다.

• 위험원 및 위험성 분석, 기능안전성 평가 
• 각 수명주기의 단계별 산출물 검증 활동 
• 전체 안전 검증 계획 및 검증 활동 
• 위험관련 사건의 보고 및 분석 
• 기능안전성 심사 빈도, 심사자들의 독립성 수준, 필요한 문서화와 후속 활동 
• 위험원과 위험 사건, 안전 기능 및 안전관련 시스템에 대해 정확한 정보를 유지하기 위한 절차를 개발 

안전성 관리를 위해 사고의 원인이 되는 위험원(Hazard)의 크기를 상대적으로 정량화한 위험성(Risk)가 허용할 수 있는 수준으로 제어된 상태를 의미하므로 안전성 관리를 위해서는 반드시 사고에 대한 정의가 먼저 수행되어야 한다. 이를 위해 대상 시스템의 정의와 안전성 관리 범위를 선정한다.

이어 위험원 식별, 위험성 계산, 위험성 결정을 수행하고 해당 허용 또는 수용 가능 여부에 따라 적정한 안전 수준을 확보하기 위한 안전기능을 추가하는 과정을 되풀이하여 가능한 안전 기능을 할당하고 이를 요구사항에 반영하여 개발 수명주기에 따라 관리한다.

정보공개제도란?

정의

"정보공개제도"란 국가기관 지방자치단체등 공공기관이 업무 수행 중 생산하여 보유ㆍ
관리하는 정보를 국민에게 공개함으로써, 국민의 알 권리를 보장하고 더 많은 정보를
바탕으로 국정운영에 대한 참여를 유도하기 위한 제도입니다.

정보공개법의 제정ㆍ시행

• 정보공개법의 개정(1998.1.1 시행)
• 국민의 알 권리를 확대하고 국정운영의 투명성을 높이기 위해
  지난 '96년 <공공기관의 정보공개에 관한 법률> 을 제정ㆍ공포하고, ’98년1월1일부터 시행

공개형태

• 청구공개
• 공공기관이 직무상 작성 또는 취득하여 관리하고 있는 정보를 청구인의 청구에 의하여 공개하는 제도
  (예)공문서의 열람, 복사청구 등
• 정보공개
• 정보를 보유한 공공기관이 자발적으로 또는 법령상 의무적으로 정보를 제공하는 제도
  (예)인터넷을 통한 정보제공, 간행물의 배포 등 

IEC62304 : 의료분야 국제 표준

의료기기 기능 안전성 확보를 위해 국제표준이 제정되어 각 나라에서 사용하고 있다. IEC60601 에서는 의료기기에 대한 안전 요구사항을 도출해 안전성을 분석하고 있으며, IEC62304 에서는 의료기기의 개발 및 유지보수의 개발 생명주기를 정의하고 각 단계별로 수행해야 하는 활동과 지표 및 산출물을 정의하고 있다.

ISO14971 은 의료기기 개발 시 필요한 위험분석 방법을 규정하고 있으며 소프트웨어 개발 단계에 이를 적용하고 있다.

어떤 종류의 소프트웨어도 안전성을 100% 보장할 방법은 없다. 의료기기 소프트웨어의 안전성을 향상시키는 주요 원칙 세 가지는 위험관리, 품질관리, 소프트웨어 엔지니어링이다.

안전한 의료기기 소프트웨어를 개발하고 유지보수하려면 적절한 소프트웨어 엔지니어링 방법 및 기술에 대한 전체적인 체제로서 품질관리시스템의 일부로 위험관리를 확립해야 한다.

이러한 세 가지 개념을 조합하면 의료기기 제조업체가 잘 구성되고 일관성 있게 반복 정밀도가 높은 의사결정 프로세스를 사용해 의료기기 소프트웨어의 안전성을 향상시킬 수 있다.

의료기기에 포함되는 소프트웨어 및 자동화 공정 소프트웨어의 안전성을 확보하기 위해선 위험관리와 소프트웨어 검증(Software Validation) 활동을 통해 확인 검증할 수 있다. 소프트웨어 기능 안전성 평가모델의 수행절차는 그림과 같다.

그림. IEC62304 기반 기능안전성 평가모델 

IEC62304 는 안전기능 요구사항을 도출하는 과정이 포함되어 있지는 않으나, 소프트웨어의 위험등급을 나누고, 위험등급에 따라 개발프로세스의 세부적인 사항들을 바꾸는 방법으로 소프트웨어의 안전성을 확보하고자 하였다.

IEC62304 는 필요한 소프트웨어의 위험등급을 구분하고 이에 따른 소프트웨어 개발 프로세스를 정의했다는 측면에서 소프트웨어의 안전성을 확보하는 표준으로 참고할 만 하지만 적극적으로 안전기능 요구사항을 도출하고 이를 구현하기 위한 구체적인 방법을 제시하는 데에는 한계가 있다.

DO-178C : 항공분야 국제 표준

DO-178C(Software considerations in airbone systems and equipment certification: 항공 시스템 및 장비 인증의 소프트웨어 고려사항)는 1992 년에 제정된 표준으로 항공분야에서 소프트웨어 기능안전성 표준으로 널리 알려진 표준이다. 그러나 이 표준 역시 엄밀하게는 기능 안전성이라는 개념을 가지고 있지는 않다.

그림. DO-178C requires a documented connection 

DO-178C 는 시스템을 위험등급에 따라 5 가지로 구분하여 개발하도록 정의하고 있다. 레벨 A 부터 레벨 D 까지는 소프트웨어의 오작동이 발생했을 때, 유발할 수 있는 장애의 등급을 나누어 소프트웨어 등급을 정하고 있는데, 특히, 레벨 E 는 항공기의 운항이나 파일럿의 임무에 영향을 미치지 않는 소프트웨어로 본 표준의 대상이 아님을 명시하고 있다. 

DO-178C 는 장애(failure condition)에 대한 등급을 정의하고 있다. ‘Catastrophic’ 등급은 항공기 자체가 추락할 수 있는 장애, ‘Hazardous/Servere-Major’ 등급은 항공기의 기능이나 항공승무원의 임무에 심각한 피해를 주거나 탑승자 일부에게 생명을 위협하는 부상을 입힐 수 있는 장애, ‘Major’등급은 항공기의 기능이나 항공승무원의 임무에 주요한 피해를 주거나 탑승자에게 부상을 입힐 수 있는 장애, ‘Minor’등급은 항공기나 승무원에게 그 자신의 능력범위 안에서 해결할 수 있을 정도의 피해를 주는 장애를 말한다. 

DO-178C 는 소프트웨어 테스팅과 관련하여 커버리지(Coverage)라는 정량화된 조건을 명시하고 있다. 이는 소프트웨어 테스팅의 완숙도를 정량적으로 측정하는 지표로써 이후 다른 표준에서도 사용하도록 영향을 주었다고 할 수 있다. DO178C 에서 제시하는 커버리지는 두 가지 종류가 있는데, 하나는 요구사항 커버리지(Requirement Coverage)이며, 나머지는 구조적 커버리지(Structural Coverage)이다.

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

산업 내에서 직접적인 소프트웨어 활용이 많아지면서 소프트웨어의 안전성에 대한 고민이 다른 측면으로 다시 시작되었다. 소프트웨어가 오류없이 동작하는데 초점이 맞춰진 예전에는 소프트웨어 테스팅이나 보안 중심으로 안전성을 확인했지만 지금은 소프트웨어가 산업 자체에 영향을 주는 경우가 많아 이 외에도 다양한 관점으로 안전성을 살펴볼 필요가 생겼다. 2회에 걸쳐 소프트웨어 안전성 분석에 대해 알아보고자 하며 이번 회에서는 소프트웨어 안전성 분석의 개념 중심으로 살펴보도록 한다.

소프트웨어 관점의 소프트웨어 안전성 분석

소프트웨어가 사용되면서 사용자들에게 가장 큰 고민은 소프트웨어 오류였다. 소프트웨어를 개발하면서 나타나는 오류는 사용자뿐만 아니라 개발을 완료한 개발자 입장에서도 많은 시간과 노력을 들여야 하는 경우가 많았다. 또한 소프트웨어를 사용하는 범위가 산업의 기반 시설들을 다루는 경우보다는 대체로 오퍼레이션과 관련된 것들이 많아 소프트웨어의 안전성이 좋지 않아도 산업 자체가 동작하는데 큰 무리는 없었다. 그래도 소프트웨어의 안전성을 높이기 위해 글로벌 기업을 중심으로 많은 예산과 인력을 투입하였고 다양한 소프트웨어 분석 도구와 기술을 개발하여 대처하였다. 개발 과정에서부터 보안 안전성을 고려하여 개발하는 시큐어 소프트웨어 개발 방법론(Secure Software Development Methodology)도 소프트웨어 안전성이나 보안 위협을 고려한 방법이라고 할 수 있다.

과거에 많이 사용된 소프트웨어 안전성 분석 방법은 크게 화이트박스 테스팅(White box Testing)과 블랙박스 테스팅(Black box Testing)으로 볼 수 있다. 화이트박스 테스팅은 분석 대상이 되는 소프트웨어의 소스코드를 대상으로 취약성이 발생할 수 있는 패턴을 분석하거나 버퍼 오버플로우와 포맷 스트링 취약점 등을 점검하여 소프트웨어가 적절하게 데이터를 처리하는지 점검하는 방식이다. 블랙박스 테스팅은 소프트웨어에 데이터를 입력하고 소프트웨어의 동작을 모니터링하면서 안전성을 점검한다. 블랙박스 테스팅은 소스코드가 반드시 필요하지는 않고 화이트박스 테스팅이 발견하지 못하는 예외적인 상황을 유발시켜 다양한 형태의 안전성 분석을 할 수 있지만 시간과 비용이 많이 드는 것이 단점이기 때문에 효율적인 테스팅을 위해서 자동화된 안전성 분석 도구가 이용되는 경우가 많다(그림1).

<그림1> 블랙박스 테스트와 화이트박스 테스트

소프트웨어의 안전성 분석을 위해서는 분석 대상 소프트웨어의 수준에 따라 분석 방법을 결정하는데 실행 프로그램만 있는 경우에는 블랙박스 테스팅, 소스코드가 제공되는 경우에는 화이트박스 테스팅을 수행하는 경우가 많다. 블랙박스 테스팅과 리버스 엔지니어링(Reverse Engineering)을 접목한 그레이박스 테스팅(Gray box Testing)도 알려져 있다(표1).

<표1> 소프트웨어 안전성 분석 방법의 장단점

출처: 한국전자통신연구원(ETRI)

블랙박스 테스팅과 화이트박스 테스팅을 활용하는 방법도 여러가지가 있다. 먼저 소프트웨어에 다양한 입력을 하여 실행시킨 후 결과를 살펴보는 동적 분석(Dynamic Analysis)과 소프트웨어를 실행시키지 않고 소스 코드의 내용으로 판단하는 정적 분석(Static Analysis)이 있다. 블랙박스 테스트와 화이트박스 테스트를 이 두가지 방법으로 구분하여 안전성을 테스트 할 수 있다(표2).

<표2> 정적 분석과 동적 분석

출처: 데이터베이스진흥원

소프트웨어 안전성 확인을 위해서 동적 분석은 소프트웨어의 특성에 따라 다양한 방법으로 확인해야 하지만 정적 분석은 요구사항을 받아 개발을 하면서 확인하기 때문에 요구사항을 받은 후 진행되는 프로세스에 따라 안전성 확인 방법이 어느 정도 정해져 있다.

더 보기 >>>