2017년 4월 10일 월요일

IEC61508. 기능안전이 구현된 하드웨어에 대한 요구사항

IEC61508 에는 기능안전이 구현된 하드웨어에 대한 요구사항이 정의되어 있다. 안전 요구사항에 따라 하드웨어를 설계하고 구현하는 것과 이것들에 대한 계획, 검증, 구조적 제한, 결함방지능력, 시험, 수정시 영향분석을 정의하고 있다.

또한 하드웨어는 정량적인 신뢰성 예측(고장율)을 통해 안전무결성수준을 검증하게 되는데, 다음과 같이 신뢰성 예측기술과 안전무결성수준 검증 기술을 다루고 있다.


  • 안전 요구사항 정의, 설계, 검증(validation), 확증(verification), 구조상 제약사항, 결함방지능력(fault tolerance), 시험, 수정활동과 같은 수명주기활동 정의 
  • 설정된 안전무결성수준 목표치에 대비하여 정량적인 신뢰성 분석을 통한 평가(예측)의 필요성을 설명하고 신뢰성 예측 
  • 시스템적인 하드웨어 고장에 대비하기 위한 기술과 절차 
  • SIL 에 대한 구조상 제약사항(architectural constraint) 정의 


IEC61508 에는 소프트웨어를 설계하는데 요구되는 활동 및 설계기술의 요구사항도 정의되어 있다. 안전 시스템의 구성 중 소프트웨어 경우 실제 고장률을 측정한다는 불가능하므로 주로 시스템이 결합되는 하드웨어 및 시스템의 전체 고장률 또는 허용 가능한 범위의 고장률을 결정하여 목표하는 SIL(안전무결성)을 결정한 다음, IEC61508 에서 제시하는 단계별 요구사항을 따르도록 하고 있다. 즉 SW 에 대해서는 SIL 에 대한 달성정도를 증명하지 않고, 단계별 기술 요구사항에 따라 수행해야할 활동에 대한 증거를 확인함으로써 목표하는 SIL 을 달성되었다고 가정한다. 이는 소프트웨어의 경우 수명주기 접근 방법에 따라 필수적으로 수행해야 할 활동들에 의하여 결함이 각 수명주기마다 추가되는 가능성을 낮추거나 방지 가능하다는 것을 전제로 하고 있다.

  • 소프트웨어라는 특성상, 시스템적인 고장에 대해서 다루고 있으며 정량적인 신뢰성 예측은 포함되지 않는다. 
  • 소프트웨어 설계기술들에 대해 각 SIL 마다 적용가능성과 수행해야할 활동에 대해서 표로 제공하고 있다. 


IEC61508 은 목표안전 달성을 위하여 먼저, 어떤 안전기능을 추가할 것인가를 결정(안전기능 요구사항)하고 그 다음으로 정의한 안전기능의 달성 가능한 정도(안전기능의 성능 정도)를 안전무결성 수준(SIL: Safety Integrity Level)으로 결정하는 절차를 제시한다.

즉, 시스템 전체 안전기능 요구사항은 안전무결성 요구사항(SIL)과 함께 구성되어 각 하위 시스템의 요구사항으로 할당함으로써, 하위 시스템의 구조 또는 각 시스템의 기능들을 구현하는 기술 및 측정법을 결정하게 되는 것이다. 안전 기능요구사항과 안전무결성 요구사항을 시스템 설계측면에서 그 역할의 차이를 구별한다면, 안전 기능 요구사항은 시스템을 구성하는 서브시스템(Sub-system) 또는 컴퍼넌트의 생성에 영향을 미치고, 안전무결성 요구사항은 구조에 영향을 미치는 것이다. 안전무결성 요구사항에 의해 시스템의 구조가 결정이 되고, 시스템의 구조를 어떻게 정의하느냐에 따라서 SIL 즉, 고장확률 수준이 결정된다고 할 수 있다.

안전공학(Safety Engineering) 측면에서 리스크(Risk) 제로상태는 불가능 하므로 허용가능한 수준의 위험까지 리스크를 줄이도록 하는 리스크 평가 및 관리가 오히려 더 중요. 이 점을 고려하여 International Electronic Commitment(이하 IEC)는 완전무결한 시스템은 불가능함을 수용하고 허용 가능한 범위의 리스크에 대해 정의하였다.

즉 IEC61508 의 기능안전 요구사항은 시스템의 위험한 사건의 원인이 될 수 있는 위험원에 대응 하도록 예측 가능한 모든 위험을 제거하고 남은 허용 가능한 위험수준을 안전무결성 요구사항으로 정의하여 시스템의 SIL 을 정의하도록 한 것이다.

또한, IEC61508 은 다른 안전 표준들과 달리 단순한 안전 요구사항만을 제시하는 것이 아니라 위험 감소를 위한 정량적인 측정법을 이용하여 구현된 안전 기능이 달성되었음을 평가 및 검증단계와 결합되어 있다. 평가 및 검증은 정성적인 평가뿐만 아니라 고장률, 즉 확률적 고장률을 이용한 안전무결성수준(Safety Integrity Level, SIL) 에 대한 정의를 통해 정량적인 접근을 제공한다.

2017년 4월 7일 금요일

IEC61508에서 안전 기능 도출 과정 6 단계

IEC61508 에서 안전 기능 도출 과정은 6 단계로 이루어져 있으며, 시스템 개념 정의에서부터 출발하여 위험 분석을 통한 안전 요구사항을 도출하고, 최종적으로 안전 기능 요구사항을 도출하게 된다.

IEC61508 에서는 안전수명주기를 정의하고 이에 따른 활동, 절차, 기술을 정의하고 있는데 이들은 위험 검증과 무결성 수준(integrity level)을 만족하도록 설계하는데 필요한 것으로 위해요인(Hazard)분석을 통해 위험감소 대상을 식별하고 ISO9001 과 같이 조직, 프로세스, 인적자격요소 등이 식별된 위험을 감소시키기 위해 어떤 활동을 해야 하는지 이를 다루고 있다.

즉, 이 표준에서는 안전 수명주기의 사용으로 시스템의 모든 단계에 관한 시스템적인 상태에 적용되는 안전을 보증하는 것을 뒷받침하며 시스템적인 에러에 관해 가능성을 감소하려는 목적을 가진다. 안전 수명주기 동안 적용되는 시스템 안전 활동은 위험원을 증명, 리스크를 분석, 위험원을 감소 또는 소거하기 위한 설계를 사용하는 것을 지침을 제공하고 있는 것이다. IEC61508 은 전체 개발 단계에서 수행해야할 각 단계별 안전 활동에 대한 지침을 제공하고, 정량적·정성적 리스크 평가(Risk Assessment)법을 제시하고 있다.


그림. 안전기능 요구사항 도출과정


IEC 61508

1998 년 IEC 에서는 전기, 전자, 프로그램 가능한 전자시스템의 기능안전(Functional safety of electrical/ electronic/ programmable electronic safety-related systems) 표준으로 IEC61508 을 발표하였으며, 최근 국내외에서는 안전시스템의 복잡화로 인하여 의도된 기능 수행에 대한 확신을 마련하기 위하여 안전시스템의 관리 방법론으로 IEC61508 또는 그와 관련한 표준에 대해 주목하고 있다. 모든 종류의 산업에 적용 가능한 기본적인 기능 안전 표준이 될 의도로 작성되었다.

IEC61508 은 안전생명주기, 하드웨어, 소프트웨어 등 세 가지에 대한 안전성 구현 방법 및 검증 방법을 제시하고 있는데, 안전관련 시스템은 IEC61508 에서 정의된 안전수명주기에 따라 위험분석 및 평가, 안전무결성수준(SIL: Safety Integrity Level)을 설정하고, 하드웨어와 소프트웨어를 목표된 수준(SIL 수준)에 충족하도록 구현하며, 설치, 운영, 유지보수, 변경, 폐기까지 관리해야 한다.

표. IEC 61508 의 구성



ISO/IEC Guide 51

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

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

2017년 4월 6일 목요일

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

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



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

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

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


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

소프트웨어의 안전성

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

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

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

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

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

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

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


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

표. Safety Critical 소프트웨어 유형