소프트웨어 안전성 분석
방법의 종류와 검증 기법 소개
대부분의
산업계에서
디지털
컨버전스의
추세에
따라,
컴퓨터
소프트웨어의
‘안전성
확보’
가
중요한
현안으로
부각되고
있다.
이에
따라
소프트웨어
개발공정
각
단계별
안전성
분석
수행을
인허가
기준으로
의무화
하고
있는데,
소프트웨어
개발공정
단계
중
요구사항
명세
단계에서
안전성
분석을
수행하기
위한
방법들은
무엇이
있는지
알아보고,
산업에서
실제
적용해본
알아보도록
하자.
1.
소프트웨어 안전성 분석기법의 필요성
2.
시스템 요구 분석 단계에서 안전 요건을 도출하는 기법들의 종류와 특징
3.
시스템 개발 안전성 분석의 성공전략
Q)
소프트웨어 안전성 분석기법은 왜 필요한건가요?
소프트웨어의 규모가 커지고 복잡해지면서 소프트웨어의 기능적 실패 (Failure)를 만들어 내는 위험(Hazard)요소들을 분석하기가 어려워지고
있습니다.
이제는
산업시스템 (원자력, 항공관제, 철도운영 등)에서도 디지털 컨버전스로 인한 소프트웨어의 중요성은 두말하면 잔소리로 여겨질 만큼 중요한데요.
이런
기능적 실패는 곧 큰 사고로 이어지게 되기 때문에 더더욱 중요하게 생각하지 않을 수 없습니다.
이러한
소프트웨어의 기능적 실패를 제거하고 안전성과 신뢰성을 높이기 위해 안전성 분석이 필요해지고, 또 안전성 분석을 요구하고 있습니다. 이에 따라
정확한 분석을 위해 다양한 분석기법들이 나오게 되었습니다.
먼저
안전성을 분석하기 전에 개념에 대해 명확히 해두고 가야할 것 같습니다.
[용어정의]
Error
: 설계(design)의 결함 또는 바랐거나 의도했떤 상태로부터 벗어남
Hazard : 시스템 환경에서 다른 상태들과 연관되어 필연적으로
사고를 발생시키게 되는 시스템의 상태나 상태들의 모임
Failure : 특정 환경상태에서 특정 시간동안 시스템 또는
컴포넌트(Component)가 수행하기를 희망했던 기능의 불이행, 불능
Accident : 특정 수준의 손실이라는 결과를 내거나 계획하지
않았던 이벤트
Q) 소프트웨어 안전성 분석 기법이 어떤 것을 뜻하는지 좀 더 자세히 알고 싶습니다.
안전성 분석의 목적은 위험식별, 위험 영향분석, 위험 원인 분석이며 분석기법에 따라 한 가지 이상의 목적을 달성할 수 있기 때문에목적에 따라 기법을 선택해야 합니다.
소프트웨어 산출물 (명세서, 디자인, 프로그램 코드 등) 을 검토하는 방법도 하나의 방법이 될 수있고,
FTA, FMEA, HAZOP. 등과 같은 시스템 요구분석 단계에서 안전요건을 도출하는 방법도 있습니다.
또, 코딩단계에서 적용되는방어적 프로그래밍 방법도 있으며, 도출된 안전요건의 충족여부를 정형적으로 검증하는 모델 검증방법도 있습니다.
시스템 요구 분석 단계에서 안전 요건을 도출하는 기법들의 종류와 특징에 대해 설명드리자면 아래와 같습니다.
(1)
FHA (Functional Hazard Assessment)
-
failure 에 유발하는 기능 (function)을 찾아내는 기법으로 개발 초기 또는 시스템을 정의하는 단계에서 적용할 수 있으며, 하향식(Top-down) 으로 분석을 반복하게 됩니다. 브레인스토밍을 통해 기능과 관련된 위험을 정의하고 위험이 미칠 영향, 영향의 심각성등을 정의하게 됩니다.
(2)
PHA(Preliminary Hazard Analysis)
- 요구사항 분석의 늦은 단계나 설계 과정의 이론 단계에서 사용하기 좋은 방법으로, 이것도 브레인스토밍 방법을 사용합니다. 따라서시스템을 잘 이해하고 있는 전문가나 안전성 분석 기법 경험자가 사용하기에 적합하다고 볼 수 있습니다.
PHA 과정에서는 안전성 분석을 위한 체크리스트를 사용합니다. 체크리스트에 점검되는 항목은 다음과 같습니다.
< 표 1>
PHA 과정에서 사용되는 안전성 분석을 위한 체크리스트
이러한 방식으로 테이블 형태의 문서를 제공하고, 테이블에는 위와 같은 속성들이 있습니다.
(3) FMEA(Failure Mode and Effect
Analysis)- 존재하고 있는 잠재적인 고장, 문제, 오류들이 사용자에게 닿기 전에
찾고(identify), 정의하고(define), 제거하는(eliminate) 안전성 분석기법입니다.
FMEA
의 단계는 먼저 모든 컴포넌트를 리스트 형태로 정의하고, 각각의 고장 모드가 영향을 미칠 모든 컴포넌트, 시스템을 정의하고, 각각의 고장 모드의
가능성과 심각성을 개선하는 단계로 진행됩니다.
소프트웨어
개발 생명주기의 이론 단계에 이 분석 기법을 사용하는 것이 비용 측면에서 유리하며, 단계에서의 적용은 경고(warning),
예방(preventive)을 통해 안전성을 위한 설계수정을 최소화 할 수 있습니다.
< 표 2>Failure
Mode and Effect Analysis
(4)
FSD(Failure Sequence Diagram)
- 방금 설명한 FMEA 는 컴포넌트의 고장을 확인하기에 아주 좋은 분석기법이지만, 컴포넌트의 상호작용에 대해서는 설명하지 못합니다.
그래서 이런 FMEA 의 단점을 보완하기 위해 UML의 sequence
diagram을 사용한 FSD 기법이 제시되었습니다.
FSD 는 FMEA 의조사 단계가 끝난 후 수행되고, 컴포넌트 간의 상호 작용을 보여주기 위해 UML
Sequence diagram 을 작성합니다.
이것을 통해 현재의 제어상태와 참조하고 있는 행동(Action)에 대해 기술할 수 있는데, 아래 그림을 통해 HazardActor 에서 발생된 입력이 컴포넌트들을 거치면서 사용자에게 어떻게 고장의 형태로 전달되는지 그 과정을 볼 수 있습니다.
< 그림 1>
Example of FSD
(5)
HAZOP(HAZard and Operability Analysis)
- 이 방법은 이름에서 알 수 있듯이 위험과 시스템의 운영상의 위협요소를 조사하는 기법입니다.
전통적으로 성공한 널리 알려진 방법중에 하나인데, 기본적으로 시스템을 검토하고 잠재적인 위험을 찾는 것이 목적이며, 브레인스토밍 단계에서 Guide
word를 이용한다는 특징이 있습니다.
Guide
word : No, Less, More, Reverse, Also, Other, Function, Early, Late,
Before/After, etc
- 브레인스토밍, 팀장의 체계적진행,
Study Node, Guide Words, 공정변수의 순차적 적용을 통하여 가이드워드 조합, 이탈의 전개, 이탈에 대한 원인파악, 결과 예측안전조치의 강구, 위험등급을 산정합니다.
(6)FTA(Fault
Tree Analysis)
- 다음 기법은 시스템의 기능과 고장에 대한 정보를 그림과 같이 트리구조로 제공합니다.
현재 항공, 전자공학, 원자력 등 다양한 분아에서 사용되고 있고, 개발의 모든단계에서 사용 가능하다는 장점이 있습니다.
하지만 지금까지 언급한 기법들과 달리 FTA 는 위험이발생할 원인들을 분석할 수는 있으나, 위험을 찾아내는 기법은 아닙니다.
Root 에 의도하지 않은 이벤트를 두고, 이를 발생시킬 수 있는 잠재적인 faulty
event 또는 normal
mode를 노드(node) 로 표현하고, 이것을 Booleanlogic(AND,OR)을 사용해 조합하여 비쥬얼하게 보여주는 방식입니다.
< 그림 2>
FTA(Fault Tree Analysis)
Q) 많은 종류의 안정성 분석기법이 있는데요, 이 중에
가장 많이 사용되는 기법들은 무엇이고, 어떤 차이가 있나요?
3 가지 정도의 대표적인 분석기법을 뽑을 수
있는데요.
FTA(Fault Tree Analysis), FMEA(Failure
Mode and Effect Analysis), HAZOP(HAZard and Operability Analysis) 이 세 가지에 대해
간략하게 특징만 요약해 보겠습니다.
-FTA 기법은 특정 사고에 대한 연역적 해석을 하여, 사건사고의
원인파악하며 설비결함 및 작업자의 실수도 포함하여 분석되는 기법입니다.
장치의 이상이나 작업자 실수의 조합까지도 발견할 수 있습니다.
-FMEA 기법은 작업자의 실수는 확인되지 않으나, 중대사고에 영향을
미치는 직접적인 원인이 되는 시스템의 설비등을 파악할 때 주로 사용됩니다.
- 마지막으로 HAZOP 기법은 Guide word 를 사용하여
브레인스토밍 방법으로 진행되기 때문에 위험요소나 조업상의 문제점을 사전에 파악할 수 있다는 장점이 있습니다.
FTA 기법이 결과의 형태가 에러의 집합 목록이라면, FMEA 는
체계적인 참고 목록이 될 수 있고, HAZOP 는 문제점을 도출하여 수정안을 제시하고, 보완방법과 후속조치에 대한 연구제안 등이 분석기법의
산출물로 표현될 수 있습니다.
각 기법에 따라 필요인원을 살펴보면 FTA 기법은 1인 혹은 팀으로
구성되는데 반해, FMEA 는 시스템의 대상의 크기와 수에 따라 다르고, HAZOP 기법은 5~7 팀 또는 더 작은 규모라면, 2~3 명 정도
까지도 가능하다고 볼 수 있습니다.
Q) 안전이 필수인 시스템 개발 안전성 분석의 성공전략이 있다면
무엇일까요?아래 도표와
같은 프로세스를 통해 체계적으로 분석하고 관리하여 소프트웨어에 대한 평가를 수행한다면, 소프트웨어의 품질을 높이고 완성도 있는 개발을 할 수
있을 것입니다.
또한, 시스템의 종류, 목적에 맞는 위험식별, 위험영향 분석, 위험
원인분석 기법선택이 프로세스 내에 녹아있어야 할텐데요.
소프트웨어는 많은 발전을 이루어왔고, 규모가 커지고 복잡해졌으며,
사용분야도 일상과 밀접한 곳으로부터 안전한 필수 시스템까지 다양한 곳에 쓰이게 됐습니다.
특히, 안전 필수 시스템에서는 안전성을 위해 안전성 분석 기법의 적용이
필수적인데요. 현재 다양한 안전성 분석 기법들이 제시되어 왔으며, 새로운 안전성 분석 기법들도 계속해서 제시되고 있습니다.
각 시스템에 적합한 분석기법들을 도입해, 안전한 소프트웨어
개발이 될 수 있도록 해야 할 것입니다.
< 참고문헌 >
소프트웨어 기반의 안전 시스템을 위한
안정성분석 ( 정보과학회지 2015.7)
차량전장용 운영체제 검증 사례를 통한 소프트웨어 안전성 검증기법 소개 ( 한국 정보처리학회지
2014)
안전 필수 시스템을 위한 안전성 분석기법 ( 중소기업정보기술융합학회 논문지 제 2 권 제 1 호 pp.
11-18,2012)
소프트웨어 요구명세 안전성 분석을 위한 HAZOP 방안 (2003 춘계학술발표회 논문집 한국 원자력학회
)
글 : NBP IT 보안개발팀 최원석 과장
