ISO/IEC Guide 51

ISO/IEC Guide51 은 제품 규격에 안전에 관한 규정을 도입하기 위한 기본적인 가이드라인으로 가이드라인의 A 규격은 광범위한 제품, 프로세스 및 서비스에 대해서 적용하는 일반적인 안전 측면에 관한 기본 개념과 원칙, 요구사항을 포함하고 있고 B 규격은 몇 개 또는 한 무리의 유사한 제품, 프로세스 및 서비스에 적용할 수 있는 안전 측면을 포함하는 규격으로 IEC61508 규격 등이 이에 해당한다. C 규격은 특정 분야의 제품, 프로세스 또는 서비스의 안전 측면을 포함하는 규격으로 IEC62278, 60601, 61511 등이 이에 해당한다. 여기에서 하위 규격은 상위규격에서 산업분야별로 파생되었거나, 상위 규격에 근거하여 규격이 제정되고 있다(그림 참조).

그림. 전기전자 기능안전 규격군  

최근 많이 발생되고 있는 소프트웨어 안전성을 위배하는 오류들

최근 많이 발생되고 있는 소프트웨어 안전성을 위배하는 오류들

1. 시스템, 하드웨어 또는 소프트웨어의 올바른 기능과 요구사항 명세의 불일치, 소프트웨어와 시스템 사이의 인터페이스 불일치 
2. 안전 요구사항 명세에서 누락(예를 들면, 서로 다른 모드들로 운영되는 동안에 관련된 모든 안전 기능이 나타나지 않는 고장) 
3. 전체 시스템 관점에서 요구사항 완전성 부족하면 도출된 요구사항을 모두 구현했더라도 전체 시스템 관점에서는 불안전한 상태임 
4. 요구사항이 시스템 안전을 위해 필요한 특정 행위를 미반영, 요구사항 이외에 소프트웨어가 의도하지 않는 행위를 수행 
5. 하드웨어 우발 고장 메커니즘을 소프트웨어에 미반영 
6. 공통 소프트웨어 고장에 의한 영향 
7. 인적 오류(소프트웨어 조작자의 실수) 
8. 환경적인 영향(예를 들면, 전자기, 온도, 기계적인 현상들) 
9. 공급 시스템 전압 불안정(예를 들면, 공급 손실, 전압 감소, 공급의 재연결) 

자세히 보기 >>

안전관련 소프트웨어의 제어 분류

소프트웨어는 하드웨어와 달리 제품이 마모 파손되거나 허용 오차가 증가와 같은 방식으로 오류 발생하지 않으며 일반적으로 구현 오류 (코드 오류, 설계 요구 사항을 잘못 해석) 혹은 외부 소프트웨어에 오류에 대하여 발생한다.

따라서 소프트웨어와 관련된 위험을 평가하는 것은 다소 복잡하다. 정확하게 소프트웨어 오류 발생을 예측할 수 없기 때문에 추가적으로 위험 분류의 방법이 필요하다. 소프트웨어의 동작에 영향을 주거나 일반 요인을 이용하여 위험 분류 방법은 표와 같다.

표. 안전관련 소프트웨어의 제어 분류 

소프트웨어의 안전성

소프트웨어의 안전성은 과거 소프트웨어 중심의 프로세스 안전성 관점에서 시스템과 소프트웨어를 동시에 바라보는 개념으로 변화하고 있다. 이같은 변화는 소프트웨어를 전체 시스템의 일부로 인식하여 전체 시스템 레벨에서 위험성 분석을 선행하고, 시스템 위험분석 결과로 도출된 시스템 안전요구사항을 바탕으로 소프트웨어 안전요구사항을 도출해야 한다는 것을 의미한다.

소프트웨어 안전성을 보증한다는 의미는 소프트웨어가 가지고 있는 여러 가지 속성 중에서 특히 안전기능(Safety Function)이 올바르게 선정되었는지를 확인할 수 있어야 하고, 최종 개발 결과물이 수행하는 안전기능이 정상적으로 작동하는가를 확인하는 것이다.

예를 들어 “원자로를 안전하게 보호할 수 있고, 위험성을 알릴 수 있는 SW 를 개발하자” 라는 안전 요구사항을 기반으로 프로젝트를 시작한다고 하면 먼저 사업계획서를 만들고, 요구사항 명세서를 정리하고, 상세기술 명세서를 만들고, 소스코드를 만드는 등 여러 엔지니어들의 손과 머리를 거치게 된다. 하지만 작업이 끝난 후엔 처음에 의도했던 바와 전혀 다른 결과물이 나올 수 있게 된다. 그렇기 때문에 처음에 의도한 안전 요구사항과 최종 결과물의 일치성을 확보하고, 특히 안전기능(Safety Function)이 원래 의도한대로 개발되었는가를 반드시 검사해야 한다.

안전 소프트웨어 개발이라는 목표 달성이라는 측면에서 볼 때 가장 중요한 요소는 세가지로 구분된다.

첫째, SW 개발 안전 수명주기에 대한 이해이다. SW 개발 안전 수명주기는 개발 조직 내의 모든 개발자가 숙지하고 각 단계 별 결과물들을 사전에 계획된 바에 따라 생성해 나가야 하는 것인데 수명주기는 경우에 따라 국제표준에서 제시하는 가이드를 일부 테일러링하여 개발 프로젝트에 최적화시킬 수 있다.

둘째, 시스템 및 소프트웨어 위험분석 기법에 대한 이해가 필요하다. 안전한 소프트웨어 개발은 시스템 위험분석을 통하여 도출된 시스템 안전기능 요구사항을 근간으로 개발이 이루어 지기 때문이다. 시스템 레벨에서 도출된 안전기능 요구사항 중에서 소프트웨어가 수행하여야 하는 요구사항들이 소프트웨어 관점에서 명세화되고 이를 바탕으로 소프트웨어가 구현되어야 한다.

셋째, 소프트웨어 안전기능이 의도한 바와 같이 구현이 되었는지를 확인하는 올바른 검증 시험 방법을 적용하는 것이 중요하다. 소프트웨어의 안전성을 검증하는 시험은 디바이스 레벨에서 이루어지며, 검증의 목표는 시스템 안전 요구사항 및 소프트웨어 안전 요구사항이 원래 의도와 같이 구현되었는지를 검증하는 것이기 때문이다.


안전 기능으로 다뤄지는 항목들은 대개 표의 범주를 벗어나지 않으며, 아래 항목에 있는 부분들은 최상위 안전등급으로 다뤄져야 한다.

표. Safety Critical 소프트웨어 유형 

안전기능 요구사항과 안전무결성 요구사항

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

이와 같이 어떠한 기술로 구현된 시스템이 안전기능을 수행하면 안전관련시스템(SRS, Safety Related System)이라고 한다. 안전관련시스템은 장치 또는 시스템을 제어하는 기존 시스템과 분리하여 작동하거나, 그 안에 포함되어 일부로서 작동하거나, 기존 제어시스템 그 자체가 안전관련시스템의 역할을 하기도 한다. 안전무결성 요구사항 수준이 높을수록 안전관련 시스템이 더욱 엄격하게 적용해야 한다. 표는 기능안전성 관련 시스템의 사례를 보여준다.

표. 기능 안전에 의존하는 안전관련시스템 예시 

이러한 시스템은 보통 복잡하고, 모든 고장 모드를 완전하게 사전에 예측하거나 발생 가능한 모든 경우를 사전에 테스트하는 것은 현실적으로 불가능하다. 테스트는 항상 필수적으로 수행해야 하지만, 안전을 위한 충분한 성능을 예측 및 시험하는 것은 매우 어려운 일이다. 기능 안전성을 달성하기 위해서는 위험한 고장을 방지하거나, 고장이 발생할 때 그것을 제어하는 방식으로 시스템을 설계해야 한다. 

더 보기 >>>

기능안전성과 안전한 시스템

기능안전성은 시스템이나 장비에 의해 좌우되는 전체적인 안전성의 일부분으로 안전 기능을 수행하는 시스템이나 장치는 조건 입력에 대해 사전에 정의한 대로 의도된 반응이 올바르게 수행되어야 한다.

전기 모터의 권선에 열 센서를 달아 과열되기 전에 동력을 차단하기 위한 고온 방지 장치는 기능안전성의 한 예로 볼 수 있다. 그러나 고온을 견디기 위해 특수화된 절연체를 입히는 것은 기능 안전성에 포함되지 않는다. 안전의 예시이고 동일한 위험원에 대해 방어 또는 보호할 수 있는 위험 방지 대책에는 해당하지만 기능안전성이라고 말하지는 않는다.

기능안전성은 시스템 전체적인 측면과 상호 작용하는 환경을 고려하지 않고서는 결정될 수 없다. 안전 기능은 그 입력에 응답하여 시스템 또는 올바르게 작동하는 장치로 구성되며 유해 사건을 방지하거나 유해 사건의 결과를 감소, 방지하기 위하여 제어 기기 및 장치를 활성화하여 잠재적으로 발생 가능한 위험한 상황을 사전에 검출하는 활성화된 기능이다.

그림. 기능안전성과 안전관련 시스템(SRS)의 관계 

그림은 기능안전성과 안전관련 시스템의 관계를 보여준다. Non-Safety System 에서는 별도의 Functional Safety 를 요구하지 않지만 안전관련시스템(SRS, Safety Related System)에서는 안전기능이 반드시 필요하다.

일반적으로 안전 설비 및 사전 정의된 환경에서 작동하도록 만들어진 안전 기능인 제어 시스템의 주요 위험원은 분석자 또는 개발자에 의한 위험원 분석을 통해 사전에 식별되어야 한다. 이 분석을 통해서 주요 위험원에 대한 적절한 보호를 위해 기능안전성이 꼭 필요한 것인지 결정하여 설계 시에 적절한 방법을 고려하여 구현할 수 있도록 해야 한다. 기능안전성은 위험원을 다루는 하나의 방법일 뿐이고 설계를 통해 고유의 안전성을 확보하는 것과 같이 위험원을 제거하거나 감소시키는 방법이 가장 중요한 것이다.

안전관련(Safety Related)이라는 용어는 특정한 기능을 수행하거나 위험성을 허용 가능한 수준으로 유지되도록 보증하는 안전 기능들을 수행하는 시스템을 설명하는데 사용한다.

수용 또는 허용 가능한 위험(Risk)

안전하다고 해도 반드시 약간의 위험성이 남아 있기 마련이기 때문에 절대적으로 안전하다는 의미의 절대 안전을 주장할 수는 없다. 반드시 어떤 크기의 위험성이 남아 있고 항상 사고는 일어날 수 있다는 것을 의미를 포함한다. 남아 있는 위험성, 즉 수용할 수 있거나 허용할 수 있는 위험성은 일반적으로 잔류 위험성(residual risk)이라고 일컬어진다.

여기에서 무엇을 가지고 안전하다고 할 것인가 할 때에 두 개의 다른 단어가 나온다. 하나는 「수용 가능한 위험성」(Acceptable Risk)이고, 다른 하나는 「허용 가능한 위험성」(Tolerable Risk)이다.

그림. 수용 또는 허용 가능한 위험성과 안전 

제품 또는 시스템을 설계하는 초기 단계에서는 여러 가지 큰 위험성(risk)이 존재하고 안전상 불안한 상황이다. 그래서 각각의 위험성에 대하여 설계, 제작 및 운영 단계에서 각종 안전 기능 또는 안전 대책을 마련하여 위험성의 크기를 줄여야 한다. 

누가 생각하더라도 이 정도 크기의 위험성만 존재한다면 문제가 되지 않는 상태를 수용 가능한 위험성이라고 할 수 있다. 한 마디로 위험성이 매우 적거나 낮아졌기 때문에 문제가 되지 않은 위험성 영역이 바로 진정으로 안전한 상태(Safety State)라고 말할 수 있다.