2017년 4월 28일 금요일

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 개발 단계


2017년 4월 27일 목요일

수명주기별 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 개발 수명주기 


2017년 4월 26일 수요일

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 이 되어야 하는 것은 물론이다.