프로그램 가능형 안전시스템의 기능안전 확보에 관한 기술지침(KOSHA GUIDE E-183-2021) - 2장
6. 소프트웨어의 품질관리시스템
6.1 일반사항
(1) 소프트웨어는 수명기간동안 안전을 확보하기 위하여 변경 및 행정․기술적 인 관리를 하여야 한다.
(2) 소프트웨어의 안전무결성이 확보되었음을 증명할 수 있도록 수행되어야 한
다.
(3) 안전관련 시스템 소프트웨어의 안전무결성을 만족시키기 위해서는 다음의 항목을 구분하여 관리하여야 한다.
(가) 안전성평가 및 요구사항
(나) 소프트웨어의 사양 및 설계문서
(다) 소프트웨어의 원시부호(Source code) 모듈
(라) 시험계획 및 결과
(마) 안전관련 시스템 소프트웨어와 병합된 패키지 또는 원래의 소프트웨어 구 성요소
(바) 안전관련 시스템 소프트웨어에 관한 생산․시험․기타작업과 관련된 도구 및 환경
(4) 임의의 변경을 방지하기 위한 절차를 수행하여야 한다.
(5) 소프트웨어의 안전과 관련된 문서를 기록하고 소프트웨어에 관한 원본 및 관련문서는 소프트웨어의 안전수명주기 전반에 걸쳐서 보수 및 변경이 가 능하도록 관리하여야 한다.
6.2 소프트웨어 안전수명주기의 요구조건
6.2.1 소프트웨어 안전수명주기의 기본구조
(1) 목적
본 단계의 목적은 프로그램 가능형 안전시스템의 소프트웨어를 개발하는 경우 <그 림 9> 및 <그림 10>와 같이 안전수명주기 단계별 요구사항을 만족시키기 위 한 것이다.
(2) 요구조건
(가) 기본구조의 기능안전성을 확보하기 위해서는 단계별로 요구되는 조건을 만족 시켜야 한다.
(나) 기본구조의 단계별로 지정한 업무범위, 입력, 출력 등이 검토되어야 한다.
(다) 각각의 단계에서 달성할 목표, 범위, 입력 등은 <별표 2>에 규정되어 있다.
(라) 계획단계에서 기능안전성을 지정하지 않은 경우 또는 현장적용 규격이 지정되어 있지 않은 경우에는 각 단계에서 요구되는 출력이 <별표 2>와 같아야 한다.
(마) 안전수명주기의 각 단계별 결과는 각각의 단계에서 지정하는 목적과 요 구조건을 만족시켜야 한다.
6.2.2 소프트웨어의 안전조건
(1) 목적
(가) 본 단계의 목적은 소프트웨어의 안전무결성에 대한 안전기능 및 안전요 구사항을 지정하는 것이다.
(나) 본 단계의 두 번째 목적은 E/E/PE 안전관련 시스템 소프트웨어에 대한 안전사양을 지정하는 것이다.
(다) 본 단계의 마지막 목적은 E/E/PE 안전관련 시스템의 안전기능을 확보하 고, 각각의 E/E/PE 안전관련 시스템 소프트웨어의 안전요구사양을 지정 하는 것이다.
(2) 요구조건
(가) 소프트웨어에 대한 안전요구사양이 E/E/PE 안전관련 시스템의 요구사양 에 지정되어 있으면 소프트웨어의 안전사양을 반복해서 지정할 필요가 없다.
(나) 소프트웨어의 안전사양은 E/E/PE 안전관련 시스템의 안전사양을 기본으 로 하며 이 정보는 소프트웨어 개발자들이 이용할 수 있도록 한다.
(다) 소프트웨어 설계 시 안전무결성의 확보가 가능하도록 안전사양을 지정하 여야 하며 소프트웨어의 운영에 따른 기능안전성평가를 수행하여야 한
다.
(라) 소프트웨어 개발자는 (다)항에 만족하는 요구조건을 충족시키는 소프트웨 어를 개발하여야 한다. 개발자는 다음과 같은 사항을 고려하여야 한다.
① 안전기능
② 시스템의 구성 또는 구조
③ 소프트웨어의 안전무결성 요구사항
④ 용량 및 응답속도 성능
⑤ 장비 및 사용자 인터페이스
(마) 소프트웨어 개발자는 소프트웨어의 안전무결성 수준미달에 따른 해결방 법을 제시하여야 한다.
(바) 소프트웨어의 안전요구사항은 안전무결성 수준에 적절하도록 검증․시 험․유지관리․실행이 가능하여야 한다.
(사) 제어장비의 운용과 관련된 안전관련 시스템의 운전 형태가 지정되어있지 않은 경우에는 소프트웨어의 안전요구사항에서 이를 정의하여야 한다.
(아) 소프트웨어 안전요구사양은 하드웨어와 소프트웨어 사이의 제약조건에 관한 내용을 규정하고 이를 문서화하여야 한다.
(자) 소프트웨어의 안전사양은 E/E/PE 하드웨어 구조설계에 필요한 다음의 사항을 고려하여야 한다.
① 소프트웨어 자기감시기능(Self-monitoring)
② 프로그램이 가능한 하드웨어, 센서, 동작부의 감시기능
③ 시스템 운전 중 안전기능의 정기적인 시험
④ 제어방비의 운전 중 안전기능 시험
(차) E/E/PE 안전관련 시스템이 안전과 무관한 기능을 수행할 경우 안전요구 사항에서 이를 설명하여야 한다.
(카) 소프트웨어의 프로젝트에 관한 안전사양은 사업수행내역이 아닌 소프트 웨어의 안전기능과 안전무결성에 관한 요구사항이 기술되어야 한다.
6.2.3 소프트웨어의 안전검증계획
(1) 목적
본 단계의 목적은 기능안전성을 효과적으로 유지하기 위하여 소프트웨어의 안 전시스템을 운전하고 정비하기 위한 계획을 세우는 것이다.
(2) 요구조건
(가) 소프트웨어가 안전요구사항을 충족시키는 것을 확인하기 위한 절차 및 기술을 지정하여야 한다.
(나) 안전검증계획에는 다음의 내용이 포함되어야 한다.
① 검증 수행시기에 대한 내용
② 검증 수행인원에 대한 내용
③ 다음의 운전과정에 대한 소프트웨어 안전시스템의 제어사양
- 설정, 조정 등을 포함한 설치준비 및 시운전과정
- 운전훈련과정
- 자동, 수동 및 반자동 운전과정
- 정상운전과정
- 재설정, 정지 및 정비과정
- 비정상 운전상태
④ 검증을 위한 분석방법, 통계처리 등의 기술적 방법
⑤ 설비의 정상운전을 위하여 검증할 필요가 있는 소프트웨어의 안전시스템 사양
⑥ 위험사건 발생 시의 조치내용
⑦ 검증결과의 평가방법과 절차
⑧ 검사자의 자격 및 합격․불합격 기준
(다) 소프트웨어의 검증을 위한 기술에는 아래의 내용이 포함되어야 한다.
① 수동 및 자동기법
② 정적 및 동적기법
③ 해석적 및 통계기법
(라) 소프트웨어의 검증 시 합격기준에는 다음의 사항이 포함되어야 한다.
① 순서(Sequence) 및 해당 값을 갖는 입력신호
② 순서(Sequence) 및 해당 값을 갖는 출력신호
③ 메모리 등 기타 다른 승인 기준
6.2.4 소프트웨어의 설계 및 개발
(1) 목적
(가) 안전무결성 수준과 관련하여 소프트웨어의 안전요구사항을 충족시킬 수 있는 소프트웨어를 개발하는 것이다.
(나) E/E/PE 안전관련 시스템의 구조에 의해 소프트웨어에 부과된 요구사항 을 검토하고 평가하는 것이다.
(다) 소프트웨어에 요구되는 안전수명주기 동안 안전무결성 수준을 확보하기 위하여 검증, 확인, 평가 및 변경된 언어, 컴파일러, 도구 등을 선정하는 것이다.
(라) 안전무결성 수준과 관련된 안전요구사항을 충족시키는 소프트웨어를 설 계․제작하는 것이다.
(마) 소프트웨어의 안전요구사항이 구현되었다는 것을 검증하기 위한 것이다.
(2) 요구조건
(가) 소프트웨어의 설계에 관한 공급자와 사용자의 책임구분은 안전계획 시에 결정되어야 한다.
(나) 소프트웨어의 설계방법에는 다음과 같은 내용이 포함되어야 한다. ① 복잡한 제어를 단순화 시킬 수 있는 기능 ② 다음 사항에 관한 설명이 있어야 한다. - 기능성
- 구성요소 사이의 정보 흐름
- 순서(Sequence) 및 시간관련 정보
- 시간제약조건
- 데이터 구조 및 해당 특성
- 전제조건 및 종속성
③ 이해하기 쉬운 내용으로 기술
④ 검증 및 절차
(다) 소프트웨어 설계 시에는 기능유지 및 안전관련 시스템의 시험가능성 기 능을 고려하여야 한다.
(라) 설계방식은 소프트웨어의 변경이 가능한 기능을 가져야 한다.
(마) 설계에 대한 설명은 기능 및 제한되는 기능에 대하여 분명하게 표현하여야 한다.
(바) 설계 시에는 가능한 소프트웨어의 안전관련 부분을 최소화시켜야 한다.
(사) 소프트웨어가 안전기능과 비안전기능을 모두 실행하는 경우에는 기능간 의 독립성이 증명되지 않는 한 전체를 안전관련 소프트웨어로 간주하여 야 한다.
(아) 소프트웨어가 서로 다른 안전무결성 수준을 요구하는 경우 안전기능간에 독립성이 증명되지 않는 한 가장 높은 안전무결성 수준을 요구하는 것으 로 간주한다.
(자) 설계 시 E/E/PE 안전관련 시스템의 안전무결성 수준을 확보하기 위한 불량검사 및 자기진단검사를 수행할 수 있는 소프트웨어 기능을 포함시 켜야 한다.
(차) 설계 시에는 안전무결성 수준에 적합하도록 제어흐름과 데이터흐름에 대 한 자기감시기능이 포함되어야 한다.
(카) 이전에 개발된 기술기준 및 소프트웨어를 설계에 사용하는 경우에는 이 를 명확하게 구분하여야 한다. 또한, 이전에 개발된 소프트웨어는 신규제 약조건에 대하여 적합성을 평가하여야 한다.
(3) 소프트웨어의 구조에 관한 요구조건
(가) 소프트웨어의 안전수명주기 동안 안전요구사항을 만족시키기 위한 기법 및 수단을 기술하여야 한다.
(나) 소프트웨어의 각 구성요소 및 하부 시스템을 구분하여 다음의 정보를 제 공하여야 한다.
① 구성요소 및 하부 시스템이 신규 또는 기존인지의 여부
② 검증 여부
③ 구성요소 및 하부 시스템이 안전관련 시스템인지의 여부
④ 구성요소 및 하부 시스템의 안전무결성 수준 (다) 소프트웨어와 하드웨어간의 상호작용에 대하여 기술하여야 한다.
(라) 구조설명은 기능 및 특성에 대하여 분명하게 표현하여야 한다.
(마) 안전관련 시스템에 관한 모든 데이터의 안전무결성을 유지․관리할 수 있는 설계기능을 가져야 한다.
(바) 소프트웨어의 안전무결성 수준과 안전요구사양을 만족시키기 위한 소프 트웨어 구조에 관한 시험방법을 지정하여야 한다.
(4) 보조도구 및 프로그램언어에 관한 요구조건
(가) 보조도구 및 프로그램 언어에 관한 공급자와 사용자간의 책임구분은 안 전계획 시 결정하여 문서화하여야 한다.
(나) 언어, 컴파일러, 자동검사도구 등은 안전무결성 수준에 적합하여야 하며, 안전관련 시스템의 전 수명기간 동안 공급되는 도구의 이용가능성도 고 려되어야 한다.
(다) 안전무결성 수준에 따라 프로그램언어는 다음의 내용을 만족하여야 한다.
① 국가 또는 국제표준에 맞는 컴파일러가 있어야 하며, 그렇지 않은 경 우 사용적합성 평가를 수립하여야 한다.
② 언어의 특징이 명확하게 정의되거나 한정된 조건으로 정의하여야 한
다.
③ 시스템에 적용될 특성과 일치하여야 한다.
④ 프로그램 오류를 찾아낼 수 있는 기능이 있어야 한다. ⑤ 설계방식에 적합한 기능을 지원하여야 한다.
(라) 상기 (다)항을 충족시킬 수 없으면, 소프트웨어 구조설계 기술의 대체 언 어에 관한 검정사항을 기록하여야 한다.
(마) 부호화(Coding) 표준은 다음과 같아야 한다.
① 평가자의 용도에 적합하여야 한다.
② 안전관련 소프트웨어 개발에 사용되어야 한다.
(바) 부호화(Coding) 표준은 작성방법 및 안전하지 못한 작성법을 규명하고 원 시부호(Source code)에 관하여 다음의 내용을 포함한 문서작성․절차 등을 기술한다.
① 사용장소
② 소프트웨어의 내용
③ 입․출력 정보
④ 구성관리에 관한 이력사항
(5) 상세 설계 및 개발에 관한 요구조건
(가) 소프트웨어 안전사양, 안전검증계획, 구조에 관한 요구조건 등을 확인할 수 있어야 한다.
(나) 소프트웨어는 안전한 변경을 위하여 모듈성과 시험 용이성 및 수용성이 확보되도록 제작되어야 한다.
(다) 소프트웨어의 안전무결성 수준을 확보하기 위해서는 소프트웨어의 안전 요구사항을 만족시키도록 소프트웨어의 무결성 시험방법을 규정하여야 한다.
(6) 소프트웨어 모듈시험에 관한 요구조건
(가) 소프트웨어 설계 시에는 지정된 대로 각 소프트웨어 모듈을 시험하여야 한다.
(나) 소프트웨어 모듈이 설계의도대로 기능을 수행하고 있음을 증명하여야 한
다.
(다) 소프트웨어 모듈 시험 결과는 문서화한다.
(라) 시험 실패에 관한 보안절차를 지정하여야 한다.
(7) 소프트웨어의 통합시험요건
(가) 소프트웨어의 통합시험은 설계 및 개발단계에서 수행하여야 한다.
(나) 소프트웨어의 통합시험에는 다음의 사항이 포함되어야 한다.
① 관리 가능한 소프트웨어의 분할
② 시험 사례 및 시험 데이터
③ 시험방법
④ 시험 환경, 도구, 구성 및 프로그램
⑤ 시험결과를 판정할 수 있는 시험 기준
⑥ 시험 실패시의 교정 조치에 관한 절차
(다) 소프트웨어의 통합시험에서 소프트웨어의 모듈 및 구성요소 또는 하부 시스템들이 설계의도대로 기능을 수행하고 있음을 증명하여야 한다.
(라) 소프트웨어의 통합시험결과를 기록하여야 하며, 이상이 있는 경우에는 그 이유를 명시하여야 한다.
(마) 소프트웨어의 통합 도중, 소프트웨어에 대한 어떤 수정 또는 변경 시에는 모든 소프트웨어의 모듈에 대한 영향, 재검증 등의 영향분석을 수행하여 야 한다.
6.2.5 프로그램 가능형 전자장치 통합(하드웨어와 소프트웨어)
(1) 목적
(가) 목적대상의 프로그램 가능한 전자장치에 소프트웨어를 결합시키는 것이
다.
(나) 프로그램 가능형 안전시스템 소프트웨어 및 하드웨어를 결합하여서, 이들 상호간의 호환성을 확인하고 의도한 안전무결성 수준을 만족시키기 위한 것이다.
(2) 요구조건
(가) 설계 및 개발단계에서 무결성시험을 시행하여 프로그램 가능형 전자기기 의 하드웨어 및 소프트웨어간의 호환성을 확인하여야 한다.
(나) 프로그램 가능형 전자기기에 대한 통합시험에는 다음의 사항이 포함되어야 한다.
① 각 시스템에 할당된 무결성 수준
② 사례 및 시험 데이터
③ 시험 방법
④ 도구, 지원 소프트웨어 및 구성 기술을 포함하는 시험환경
⑤ 시험을 판정할 수 있는 시험 기준
(다) 프로그램 가능형 전자기기 통합시험에는 다음과 같은 조치들이 포함되어야 한다.
① 프로그램 가능형 전자기기 하드웨어와 소프트웨어 시스템의 결합
② 센서 및 동작부와 같은 인터페이스가 추가된 E/E/PE의 결합
③ 제어설비 및 E/E/PE 안전관련 시스템의 결합
(라) 소프트웨어는 통합시험에 따라 안전관련 시스템 하드웨어와 결합시켜야 한다.
(마) 프로그램 가능형 하드웨어와 소프트웨어의 통합 시험 도중에, 통합 시스 템에서의 어떤 변경 또는 수정사항 발생 시에는 모든 소프트웨어의 모듈 에 대한 영향 및 재검증 조치 등의 필요성을 판단하는 영향분석을 실시 하여야 한다.
(바) 시험 사례 및 그 결과는 향후 분석을 위하여 문서화한다.
6.2.6 소프트웨어의 안전검증
(1) 목적
본 단계의 목적은 소프트웨어 안전시스템의 안전검증을 위한 계획을 개발하는 것이다.
(2) 요구조건
(가) 안전검증계획에는 다음의 내용이 포함되어야 한다.
① 검증 수행시기에 대한 내용
② 검증 수행인원에 대한 내용
③ 소프트웨어 안전시스템의 제어사양에는 다음의 운전과정이 포함되어야 한다.
- 설정, 조정 등을 포함한 설치준비 및 시운전과정
- 운전훈련과정
- 자동, 수동 및 반자동 운전과정
- 정상운전과정
- 재설정, 정지 및 정비과정
- 비정상 운전상태
④ 설비의 정상운전을 위하여 검증할 필요가 있는 안전시스템 소프트웨어의 사양
⑤ 검증을 위한 분석방법, 통계처리 등의 기술적 방법
⑥ 안전기능이 효과적임을 확인할 수 있는 방법 및 절차
⑦ 측정장비의 보정 등 검증에 필요한 사항
⑧ 합격 및 불합격 기준
⑨ 검증결과에 대한 평가방법과 절차
(나) 상기 (가)항의 안전검증계획은 문서화한다.
(다) 안전관련 소프트웨어의 검증은 다음의 요구사항을 만족시켜야 한다.
① 소프트웨어에 대한 타당한 검증방법
② 다음의 내용에 대하여 소프트웨어는 실행이 가능하여야 한다.
- 운전 시 존재하는 입력신호
- 예상되는 결과
- 정상운전에 반하는 조건
③ 소프트웨어의 검증결과는 다음과 같아야 한다.
- 소프트웨어의 안전요구사항이 모두 만족되고 설계의도대로 기능하고 있음을 증명
- 안전무결성 수준에 대한 분석 및 결과를 문서로 기록
- 안전검증의 합격여부에 대한 결과 및 불합격 사유의 명시
6.2.7 소프트웨어의 변경
(1) 목적
본 단계의 목적은 소프트웨어 안전시스템을 변경하는 경우에 기능안전성이 확 보되어 있는지를 확인하는 것이다.
(2) 요구조건
(가) 변경작업을 수행하기 전 작업절차를 수립하여야 한다.
(나) 변경은 기능안전성 확보를 위하여 사전 승인요청에 의해 시행되어야 하 며, 요청 시 다음과 같은 사항이 명시되어야 한다.
① 변경에 의해 발생하는 새로운 위험
② 소프트웨어의 변경내용
③ 변경하는 사유
(다) 변경작업이 소프트웨어 안전시스템의 기능안전성에 미치는 영향을 평가 하여야 한다. 평가에는 소프트웨어 안전수명주기 각 단계에서의 위험성평 가가 포함되어야 하며 함께 진행 중인 다른 변경작업에 대한 영향, 변경 작업을 하는 동안 및 수행된 이후의 기능안전성도 평가되어야 한다.
(라) 변경작업의 수행여부는 영향평가의 결과에 따라 결정한다.
(마) 변경 시에는 다음의 내용을 시간대별로 문서화 하여야 한다.
① 변경작업의 승인요청 내용
② 영향평가의 결과
③ 입력과 결과에 대한 재검증 및 확인 결과
④ 변경으로 인해 영향을 받은 문서목록
(바) 안전관련 소프트웨어의 변경계획에는 다음의 사항을 포함하여야 한다.
① 작업자의 자격에 관한 사항
② 변경에 관한 상세사양
③ 검증계획
④ 소프트웨어의 구성
⑤ 정상운전과 조건과의 차이
⑥ 변경작업과 관련된 모든 정보
(사) 변경과 재조정에 관한 평가는 영향분석 및 소프트웨어의 안전무결성 수 준에 맞게 실시하여야 한다.
6.2.8 소프트웨어 확인
(1) 확인의 목적
본 단계의 목적 소프트웨어의 안전수명주기 각 단계에서 지정한 목적과 요구 조건을 만족시키고 있음을 확인하는 것이다.
(2) 요구조건
(가) 소프트웨어의 안전수명주기 단계별로 확인 작업을 수행하기 위한 계획을 수립하여야 한다.
(나) 확인계획에는 적용될 기준, 기술, 시험장비 등의 내용을 포함시켜 문서로 작성하여야 한다.
(다) 확인과정이 모든 측면에서 완벽하게 수행되었음을 증명할 수 있는 정보 와 자료를 수집하고 이를 문서로 작성하여야 한다.
(라) N+1 단계를 정확하게 실행하기 위해서는 안전수명주기 N 단계로부터 생 성된 소프트웨어의 모든 정보가 이용․가능하여야 하고 검증되어야 한다.
N 단계의 출력에는 다음사항이 포함되어야 한다.
① N 단계에서의 사양과 설계내용 및 코드의 적합성
② N 단계에서 사용된 검증 계획 및 시험의 적합성 ③ N-1 단계의 시험과 N 단계에서의 시험에 관한 일관성
(마) 확인 작업에는 다음의 내용이 포함되어야 한다. ① 안전요구사항에 관한 확인
② 구조에 관한 확인
③ 소프트웨어 시스템 설계에 관한 확인
④ 모듈 설계에 관한 확인
⑤ 부호에 관한 확인
⑥ 데이터 확인
⑦ 모듈 시험
⑧ 소프트웨어 통합시험
⑨ 프로그램가능 하드웨어와의 통합시험
⑩ 소프트웨어의 검증
(바) 다음 단계를 시작하기 전 소프트웨어의 확인 시에는 다음의 사항이 검토 되어야 한다.
① 소프트웨어의 안전요구사항이 E/E/PES 안전요구사항을 충족하는지에 대한 여부
② 검증계획이 안전요구사항을 만족하였는지의 여부 ③ 소프트웨어와 E/E/PS 시스템간의 안전요구사항의 일관성
(사) 소프트웨어의 구조를 설계한 경우에는 다음의 사항을 확인한다. ① 소프트웨어 구조가 안전요구사항을 만족하는지의 여부
② 소프트웨어 구조의 통합이 구조설계기준과 일치하는지의 여부
③ 주요구성요소 및 하부시스템의 안전기능, 확인시험, 개선을 위한 변경 등이 가능한지에 대한 여부
④ 소프트웨어 구조의 설계기준과 안전요구사항
(아) 소프트웨어 시스템을 설계한 경우 다음의 사항이 확인되어야 한다. ① 소프트웨어 시스템의 설계가 안전요구사항을 만족하는지의 여부
② 소프트웨어 시스템 설계의 통합이 구조설계기준과 일치하는지의 여부
③ 주요구성요소 및 하부시스템의 안전기능, 확인시험, 개선을 위한 변경 등이 가능한지에 대한 여부
④ 소프트웨어 시스템 설계의 설계기준과 안전요구사항
(자) 소프트웨어의 모듈을 설계한 경우 다음의 사항이 확인되어야 한다. ① 소프트웨어 모듈이 안전요구사항을 만족하는지의 여부
② 소프트웨어 모듈의 통합이 구조설계기준과 일치하는지의 여부
③ 주요구성요소 및 하부 시스템의 안전기능, 확인시험, 개선을 위한 변경 등이 가능한지에 대한 여부
④ 소프트웨어 모듈의 설계기준과 안전요구사항
(차) 프로그램언어는 소프트웨어 모듈의 설계기준, 6.2.4 (4) 항의 프로그램 언 어에 관한 국제표준, 안전검증계획의 요구사항 등을 확인하여야 한다.
(카) 데이터 확인
① 설계 시에 지정된 데이터 구조
② 적용 데이터는 다음 사항에 대하여 확인하여야 한다.
- 데이터 구조에 대한 일관성
- 완전성
- 실행순서, 시간 등을 지정하는 기초 시스템 소프트웨어와의 일관성
- 데이터 값의 정확성
③ 변경이 가능한 모든 매개변수는 다음의 값들에 대해 보호되는지에 대 한 여부를 확인하여야 한다. - 불분명한 초기 값
- 오류, 불일치 또는 불합리한 값
- 무단 변경
- 데이터 손상
④ 설비내의 모든 인터페이스 및 관련 소프트웨어는 다음의 사항을 확인 하여야 한다.
- 인터페이스의 고장 시 탐지기능
- 인터페이스의 고장 시 허용오차
⑤ 인터페이스와 관련 소프트웨어간의 고장 탐지, 손상 방지, 데이터 확인 등에 관한 모든 통신자료는 적정수준으로 확인하여야 한다.
6.3 기능안전성의 평가
(1) 기능안전성 평가의 목적
기능안전성 평가는 소프트웨어 안전시스템에 의한 기능안전성이 적절한 지를 판단하기 위한 것이다.
(2) 기능안전성 평가의 요구조건
(가) 소프트웨어 안전시스템에 의한 기능안전성을 평가하기 위하여 복수의 담 당자를 임명하여야 한다.
(나) 기능안전성 평가를 수행하는 담당자는 E/E/PES 및 소프트웨어의 안전수 명주기 각 단계에서의 작업자, 관련 설비의 정보 등에 대해 조사할 수 있 는 권한을 가져야 한다.
(다) 기능안전성 평가는 E/E/PES 및 소프트웨어 안전수명주기의 모든 단계에 대해 수행되어야 한다. 기능안전성 평가를 수행한 담당자는 안전수명주기 각각의 단계에서 평가한 결과가 단계별 목적과 요구사항을 만족하는지를 판단하여야 한다.
(라) 위험성평가를 통해 파악된 위험원이 여러 단계에 걸쳐 영향을 미치는 경°단계기능안전성 평가는 각각의 안전수명주기 단계 및 여러 단계의 안 전수명주기 전체에 대하여 수행되어야 한다.
(마) 일부 장비가 E/E/PES 및 소프트웨어의 안전수명주기 동안 설계나 평가 도구로서 사용되는 경우 그 장비에 대한 기능안전성 평가도 포함되어야 한다.
(바) 기능안전성 평가는 다음의 내용을 포함하여야 한다.
① 기존의 기능안전성 평가 이후 수행된 작업내용
② E/E/PES 및 소프트웨어에 대하여 추가적인 기능안전성 평가가 필요한 경우 이를 위한 계획 및 전략
③ 기존의 기능안전성 평가에 의한 권장사항과 이에 따라 변경된 사항
(사) E/E/PES 및 소프트웨어의 서로 다른 수명단계에서 수행한 기능안전성 평가 간에 상호 일관성이 있어야 한다.
(아) 기능안전성 평가계획에는 다음의 내용이 규명되어야 한다.
① 기능안전성 평가를 수행하는 담당자
② 기능안전성 평가에 의한 결과
③ 기능안전성 평가의 범위
(자) 기능안전성 평가는 기능안전성을 책임지고 있는 담당자와 평가를 수행하 는 담당자의 승인을 받은 후 시행되어야 한다.
(차) 기능안전성 평가를 수행한 후 인증, 조건부 인증 또는 불합격의 결정을 내려야 한다.
(카) 기능안전성 평가자는 안전시스템에 대한 지식과 현장경험, 관계법령의 숙 지, 안전요구사항 및 안전무결성 수준, 설계 등에 대한 평가능력을 갖추 어야 한다.
<별표 2> 소프트웨어의 안전수명주기의 개요
| 안전수명주기 단계 | 목적 | 범위 | 입력 | 출력 | ||
| <그림 9>의 번호 |
제목 | |||||
| 9.1 | 소프트웨어의 안전요구사양 | 1. 소프트웨어의 안전기능과 안전보 전을 위한 요구사항을 상술하기 위함. 2. 각각의 E/E/PES의 안전과 관련 된 시스템이 안전기능의 요구사 항을 수행하기 위한 소프트웨어 의 안전기능을 상술하기 위함. 3. 시스템마다 할당된 안전기능의 안 전무결성 수준을 확보하기 위한 각각의 소프트웨어에 대해 안전무 결성 요구사양을 명시하기 위함. |
PES : 소프트 웨어 시스템 | E/E/PES의 안전요구사양 | 소프트웨어의 전요구사양 | 안 |
| 9.2 | 소프트웨어의 안전확인계획 | 소프트웨어의 안전 확인을 위한 계 획을 수립하는 것 | PES : 소프트 웨어 시스템 | 소프트웨어의 안전요구사양 | 소프트웨어의 전확인계획 | 안 |
| 9.3 | 소프트웨어의 설계 및 개발 | 구조 1. 안전보전수준에 관한 소프트웨어 의 안전을 위해 필요한 요구사항 을 수행하기 위한 소프트웨어의 체계를 개발하는 것 2. 하드웨어와 소프트웨어의 상호작 용에 관한 중요성과 시스템의 하 드웨어의 구조에 따라 소프트웨 어에 부과한 요구사항을 검토하 고 평가하는 것. |
PES : 소프트 웨어 시스템 | 소프트웨어의 안전요구사양 | 소프트웨어의 조설계 기술 소프트웨어와 로그램이 가 전자기기의 시험사양 |
구 프 능한 통합 |
| 9.3 | 소프트웨어의 설계 및 개발 | 보조도구 및 프로그램이 가능한 언어 요구된 안전무결성 수준을 위한 컴 파일러와 언어, 평가 및 변경, 확인 이 가능한 소프트의 안전 수명을 포함한 적절한 모든 도구를 선정하 는 것, |
PES : 소프트웨어 시 스템 보조 도구 프로그램언어 |
소프트웨어의 안전요구사양 소프트웨어의 구조설계기술 |
개발도구 및 부호 화표준 개발도구의 선정 | |
| 안전수명주기 단계 | 목적 | 범위 | 입력 | 출력 | |
| <그림 9>의 번호 |
제목 | ||||
| 9.3 | 소프트웨어 의 설계 및 개발 | 세부 설계 및 개발(소프트웨어 시 스템 설계 필수 안전무결성 수준 중 분석․검 증․변경이 가능하고, 소프트웨어의 안전요구사양을 충족시킬 수 있는 소 프트웨어를 설계하여 도입하는 것. |
소프트웨어 구조 설계의 주요구성 요소 및 하부시 스템 | 소프트웨어의 구조설계 기술 보조도구 및 부 호화표준 |
소프트웨어 시 스템의 설계사 양 소프트웨어시 스템의 통합시 험사양 |
| 9.3 | 소프트웨어 의 설계 및 개발 | 세부 설계 및 개발 (개별 소프트웨 어의 모듈 설계) 필수 안전무결성 수준 중 분석․검 증․변경이 가능하고, 소프트웨어의 안전요구사양을 충족시킬 수 있는 소 프트웨어를 설계하여 도입하는 것. |
소프트웨어시스템 의 설계 | 소프트웨어시스 템의 설계사양 보조도구 및 부 호화표준 |
소프트웨어 모 듈의 설계사양 소프트웨어 모 듈의 시험사양 |
| 9.3 | 소프트웨어 의 설계 및 개발 | 세부화된 부호화(coding) 도입 필수 안전무결성 수준 중 분석․검증 ․변경이 가능하고, 소프트웨어의 안 전요구사양을 충족시킬 수 있는 소프 트웨어를 설계하여 도입하는 것. |
개별 소프트웨 어 모듈 | 소 프 트 웨 어 모듈의 설계 사양 보조도구 및 부 호화표준 |
원 시 부 호 ( s o u r c e code) 목록 부 호 ( c o d e ) 검토 보고서 |
| 9.3 | 소프트웨어 의 설계 및 개발 | 소프트웨어 모듈 시험 모든 소프트웨어의 모듈, 구성요소 및 하부시스템들의 상호 작용을 통해 의도하거나 혹은 의도하지 않았을 시에 기능이 수행되지 아 니함으로써 소프트웨어의 안전요 구가 이루어 졌음을 확인하는 것. |
소프트웨어의 모듈 | 소프트웨어 모 듈의 시험사양 원 시 부 호 (source code) 목록 |
소 프 트 웨 어 모듈의 시험 결과 시 험 ․ 검 증 된 소프트웨 어의 모듈시 험 |
| 9.3 | 소프트웨어 의 설계 및 개발 | 소프트웨어 모듈 시험 모든 소프트웨어의 모듈, 구성요소 및 하부시스템들의 상호 작용을 통해 의도하거나 혹은 의도하지 않았을 시에 기능이 수행되지 아 니함으로써 소프트웨어의 안전요 구가 이루어 졌음을 확인하는 것. |
소프트웨어의 구조 소프트웨어의 시스템 |
소프트웨어 시 스템의 통합시 험사양 | 소 프 트 웨 어 의 통합시험 결과 시험·검증된 소 프 트 웨 어 시스템 |
| 안전수명주기 단계 | 목적 | 범위 | 입력 | 출력 | |
| <그림 9>의 번호 |
제목 | ||||
| 9.4 | 하드웨어와 소프트웨어 의 통합 | 프로그램이 가능한 전자기기 하드웨어의 소프트웨어를 안전 무결시키는 것 안전관련 프로그램이 가능한 전자기기에 소프트웨어와 하드 웨어를 결합시켜 이들의 호환 성이 의도한 안전무결성 수준 을 충족시킨다는 것을 확인하 는 것 |
프 로 그 램 가능형 통 합 하드웨 어․소프트 웨어 | 소프트웨어 구조통 합시험사양 프로그램 가능형 통합시험사양 프로그램 가능형 통합 하드웨어 |
소프트웨어 구조 통합시험결과 프로그램가능형 통합하드웨어의 시험결과 시험·검증된 프 로그램 통합 하 드웨어 |
| 9.5 | 소프트웨어 운용 및 변경 절차 | 운용 및 변경 시에 E/E/PE 안 전관련 시스템의 기능안전성이 유지관리 되도록 하기 위해 필 요한 소프트웨어관련 정보 및 절차를 제공하는 것 | 위와 같음 | 5.6 | 소프트웨어의 운 영 및 변경절차 |
| 9.6 | 소프트웨어 안전검증 |
시스템이 의도한 안전무결성 수준에서 소프트웨어 안전에 관한 요구사항에 확실하게 부 합할 수 있도록 하는 것 | 위와 같음 | 5.7 | 소프트웨어의 안 전검증결과 검증 소프트웨어 에 관한 변경영 향평가 결과 |
| - | 소프트웨어 변경 |
확인된 소프트웨어를 점검, 보 강 또는 변경하여 필수 소프트 웨어의 안전무결성 수준을 확 실하게 유지시키는 것 | 위와 같음 | 5.7 | 소프트웨어 변경 절차 소프트웨어 변경 요구 |
| - | 소프트웨어 확인 |
특정 소프트웨어 안전수명주기 단계를 안전무결성 수준이 요 구하는 정도까지 시험하고 평 가하여 해당 단계에 대해 인풋 으로 수립된 아웃풋 및 표준과 관련하여 이를 점검하고 그 일 관성을 확실히 유지하는 것 | 단계에 따 라 좌우됨 | 5.7 | 확인결과 보고서 |
| - | 소프트웨어 의 기능안전성 평가 |
E/E/PE 안전관련 시스템으로 확보된 기능안전성에 대한 판 단을 검토하여 결론에 도달하 는 것 | 위의 같음 | 6 | 소프트웨어 기능 안전성평가 보고 서 |
7. 구조적 고장예방을 위한 안전사양
7.1 구조적 고장예방을 위한 안전사양
전기·전자·프로그램 가능형(이하 “E/E/PE"라 한다.)시스템의 안전사양을 작성하 는 목적은 가능한 한 실수를 최소화시키고, 오작동을 방지하기 위한 것이며, 완 전성을 간단히 증명할 수 있도록 하는 것이다.
7.1.1 체계적인 사양
(1) 목적
체계적인 사양은 E/E/PE 시스템의 안전요구사항을 계층적 구조로 구성하여 단순화 시키고 인터페이스간의 고장을 예방할 수 있다.
(2) 방법
(가) 체계적인 사양은 기능적인 요구사양을 가능한 한 단순하게 분리시켜, 이 들 간의 관계를 쉽게 파악할 수 있도록 구성한다.
(나) 요구사항이 쉽게 구분이 가능할 때까지 연속하여 세분화시킨다.
(다) 이러한 세분화 과정의 결과를 바탕으로 전체 안전요구사양을 완전히 구 성하고 있는 계층적 구조의 안전요구사양을 구성한다.
7.1.2 공식적 방법(Formal method)
(1) 목적
명확하고 일관된 안전사양을 바탕으로 실수 또는 누락 부분을 쉽게 파악할 수 있다.
(2) 방법
(가) 공식적 방법은 사양작성 또는 설계 단계에서 시스템에 대한 정의를 개발 할 수 있는 수단이다.
(나) 개발된 정의는 수학적 형태를 취하며, 수학적 분석을 통해 다양한 불일치 성 및 오류를 탐지할 수 있다.
(다) 컴파일러에 의한 원시프로그램(Source program)의 구문검사(Syntax checking)와 마찬가지로 개발된 정의는 기계를 이용하여 분석하거나, 시 스템 특성의 여러 측면을 애니메이션을 통해 표시할 수 있다.
(라) 애니메이션 기법은 요구사양을 개선할 수가 있으며, 공식화된 요구사항뿐 만 아니라 실제 상황에서 요구조건을 충족하고 있음을 가시적으로 확신 할 수 있다.
(마) 공식적 방법은 일반적으로 사용되는 불연속 형태로 나타내어지는 수학적 표기와 수학적 표기를 도출하는 기법 및 개발된 정의가 올바른 것인가를 검토하는 방법 등을 제공한다.
(바) 수학적으로 규정된 사양을 논리회로설계의 단계별 체계화에 활용함으로 써 설계를 변형할 수 있다.
7.1.3 준 공식적 방법(Semi-formal method)
(1) 일반사항
(가) 목적 준 공식적 방법은 E/E/PE 시스템의 설계가 안전관련 사양을 만족시킨다 는 것을 검증하기 위함이다.
(나) 방법
① 본 방법은 사양ㆍ설계 또는 부호화(Coding)를 개발할 수 있는 수단을 제공한다.
② 개발된 정의는 기계를 이용하여 분석하거나 시스템 특성의 여러 측면 을 가시적으로 표시할 수 있다.
③ 애니메이션 기법은 요구사양을 개선할 수가 있으며 공식화된 요구사항 뿐만 아니라 실제 상황에서도 요구조건을 충족하고 있음을 확신할 수 있다.
(2) 유한 상태 기계/상태 전이도(Finite state machines/state transition diagram)
(가) 목적
본 방법은 제어시스템의 모델링, 규정 및 수행을 위한 것이다.
(나) 방법
① 대부분의 시스템은 현재의 상태ㆍ입력, 이에 따른 동작의 측면에서 표현한 다. 예를 들면 S1 상태에서 입력 1이 주어지면 동작 A를 하여 상태 S2로 전이된다.
② 모든 상태와 입력에 대한 동작을 기술하게 되면 전체 시스템이 완성되 는데 이렇게 구성된 모델을 유한 상태 기계라 한다.
③ 시스템의 상태가 전이되는 과정을 도표화한 것 또는 상태와 입력을 행 렬(Matrix)화 시키고 각각의 행렬요소가 현재의 상태에서 입력에 의해 새로운 상태로 이동하는 과정을 보여주는 것을 “상태 전이도”라 한다.
④ 시스템이 복잡한 경우에는 유한 상태 기계를 계층화시켜 구성할 수 있다.
⑤ 유한 상태 기계의 사양과 설계 내용은 다음의 사항에 대하여 검토하여야 한다.
- 완전성(모든 입력에 대하여 상태 전이가 이루어져야 한다.)
- 일관성(입력과 상태 전이는 일대일 대응으로 이루어져야 한다.)
- 접근성(일련의 연속 입력에 의해 상태 전이가 연속적으로 가능한 지를 확인하여야 한다.)
⑥ 상기 ⑤항의 검토는 주요 시스템에 대해서 반드시 수행하여야 하며, 유한 상태 기계의 기능을 증명하기 위한 시험 표본을 자동적으로 생 성하는 알고리즘이 개발되어야 한다.
(3) 시간 페트리 네트(Time Petri net)
(가) 목적
본 방법은 시스템의 분석 및 재설계를 통해 시스템의 특성ㆍ안전성ㆍ운전
성 등의 향상과 관련된 모델을 개발하는 것이다.
(나) 방법
① 페트리 네트는 시스템의 동시성 및 비 동시성 특성과 관련된 정보화 제어 간의 흐름을 보기 쉽게 표현한 도표 이론 모델이다.
② 페트리 네트는 위치와 전이관계를 나타내는 것으로써 위치는 표지 (Mark)로 표기를 하거나 안 하는 경우도 있지만, 전이는 모든 입력이 표지로 표기된 경우에만 이루어진다.
③ 전이가 가능할 때 프로그램의 실행이 가능하며 이후 입력 위치의 모든 표지는 지워지고 전이된 출력위치에서 모든 표지가 생성된다.
④ 잠재위험은 특별한 상태를 표지(Marking)하여 나타낼 수 있다. 또한, 본 모델은 시스템의 시간 특성을 고려할 수 있다.
7.1.4 컴퓨터 지원 사양 도구
(1) 일반사항
(가) 목적
본 방법은 명확하고 완전한 공식화된 사양을 자동적으로 생성하기 위한 것이다.
(나) 방법
① 본 기법은 데이터베이스를 기초로 하여 일관성과 완전성을 갖는 공식 화된 사양을 생성하는 것이다.
② 본 사양도구는 사용자가 특정시스템의 여러 측면을 가시적으로 표현할 수 있다.
③ 본 기법은 사양의 개발뿐만 아니라 안전수명주기 각 단계에서의 설계 에도 적용할 수 있다.
(2) 특정 방식이 없는 도구
(가) 목적 본 방법은 사양과 관련된 부분의 자료를 연결(Link)하여 사용자가 자유롭 게 공식화된 사양을 작성할 수 있는 도구이다.
(나) 방법
① 본 사양도구는 사용자가 통상적인 업무를 수행하도록 한다.
② 특별한 사양기법이 적용되지 아니하는 방법이다.
③ 본 방법은 사양을 개발하는 경우 매우 자유로울 뿐만 아니라 특별한 지원이 필요 없으나 작성하기가 매우 어렵다.
(3) 계층 분석에 의한 모델
(가) 목적
본 방법은 사용자가 이상적인 상태에 대하여 시스템의 동작과 요구 자료 간의 일관성을 확신함으로써 명확한 사양을 작성하는 것이다.
(나) 방법
① 본 방법은 이상적인 상태에 대하여 시스템이 요구하는 기능을 작성하는 것이다.
② 각 단계에서의 시스템 동작과 요구 자료에 대하여 분석하는 것이다.
③ 완전성 평가는 이상적인 상태에 대하여 계층구조뿐만 아니라 기능측면 에서도 분석이 가능하다.
(4) 실체 모델(Entity model)
(가) 목적
시스템 내에서 실체간의 관계를 규명함으로써 사양을 작성하는 것이다.
(나) 방법
① 개발하고자 하는 시스템은 실체의 목적과 실체 상호간의 관계를 파악 함으로써 정의된다.
② 본 모델은 시스템 내에서 실체간의 관계를 규명할 수 있게 한다.
③ 본 방법은 대상ㆍ자료흐름ㆍ자료간의 상호관계 등에 관한 계층적 구조 를 파악할 수 있다.
④ 본 방법을 확장하면 검사와 지원활동에도 적용할 수 있다.
⑤ 본 방법은 상호관계가 많은 경우에는 적용하기가 매우 복잡하다.
(5) 동기부여 및 답변(Incentive and answer)
(가) 목적
신호-응답관계(Stimulus-response relationship)를 규명함으로써 공식화된 사양을 작성하기 위한 것이다.
(나) 방법
① 시스템 실체간의 관계를 동기부여 및 답변형식으로 작성하는 것이다.
② 질문의 내용을 확장하여 대상ㆍ상호관계ㆍ특징ㆍ구조물 등을 포함시킨
다.
7.1.5 점검목록
(1) 목적
안전수명주기 단계별로 중요한 사항에 대하여 정확한 요구사항을 파악하지 않 더라도 주요 사항을 확인할 수 있도록 하는 것이다.
(2) 방법
(가) 점검목록에 수록된 질문에 답변함으로써 수행된다.
(나) 대부분의 질문은 일반적 사항이고 검토자는 특정 항목에 대해서만 주의 를 기울일 수 있다.
(다) 점검목록은 하드웨어ㆍ소프트웨어의 안전수명주기 전체단계 또는 각 단 계별로 기능안전성평가를 수행하는데 유용하다.
(라) 점검목록의 사용은 전문가의 판단에 의해 결정되며 전문가의 추가적인 질문이 보완됨으로써 완전한 사양을 작성하고 이를 검증하여야 한다.
(마) 검증은 동일한 점검목록으로 동일한 조건에서 적용할 경우 동일한 결과 가 도출되었는지를 통해서 확인한다.
(바) 점검목록은 단순화하는 것이 좋으며 확대가 필요한 경우에는 추가적인 문서를 참고하여 수행하는 것이 바람직하다.
(사) 점검목록에 대한 답변은 합격ㆍ불합격, 보류, 조건부 합격등과 같은 문구 로 구분하고 이를 문서화한다.
7.1.6 사양서 검사
(1) 목적
사양서의 불완전성과 모순을 방지하기 위한 절차이다.
(2) 방법
(가) 검사는 사양서를 평가하는 일반적 방법으로써 사양작업에 참여하지 않은 독립적인 팀에 의해 평가되어야 한다.
(나) 독립성의 정도는 시스템의 안전무결성 수준에 의해 결정된다.
(다) 검사자는 운전 및 구조측면에서 모든 안전성 및 기술적 사항을 검토하여야 한다.
7.2 구조적 고장예방을 위한 설계 및 개발
본 단계의 목적은 사양을 만족하는 안전관련 시스템을 안정적으로 설계ㆍ제작 하기 위한 것이다.
7.2.1 지침과 기술표준의 준수
(1) 목적
응용 분야의 표준을 준수하여야 한다.
(2) 방법
안전관련 시스템의 설계과정에서 기술지침이 준수되어야 하고 그 내용은 안전 관련 시스템의 안전성을 확보하고 고장이나 오작동이 발생하지 않도록 하기 위한 것이다.
7.2.2 체계적 설계
(1) 목적
시스템을 계층적인 구조로 세분화하여 각각의 부분에 관한 요구조건을 충족시 키고, 이를 토대로 인터페이스 간의 고장을 예방하고 검증을 단순화하기 위한 것이다.
(2) 방법
(가) 하드웨어 설계 시 특정 기준 및 방법을 적용하여야 하며 다음과 같은 조 건이 요구된다.
① 계층적 구조의 회로설계
② 시험ㆍ검증된 회로부품의 사용
(나) 소프트웨어 설계 시 구조도를 사용하면 소프트웨어의 모듈을 명확하게 구성할 수 있으며, 구조도는 모듈간의 관계, 모듈간의 입ㆍ출력 자료, 모 듈간의 제어요소 등을 파악할 수 있게 한다.
7.2.3 충분히 검증된 구성요소의 적용
(1) 목적
특정 부품을 사용하는 경우 부품이 처음 사용되거나 밝혀지지 않은 위험이 있 을 경우를 대비하기 위하여 사용한다.
(2) 방법
(가) 높은 수준의 안전요구사양 또는 안전관련 프로그램이 저장된 메모리 등 과 같은 부품은 충분히 검증된 부품을 사용하여야 하며 제작자는 이에 관한 신뢰성을 검증하여야 한다.
(나) 안전관련 메모리는 무단으로 접근하거나 환경의 영향, 사고 시의 부품의 응답특성에 대하여 기술하여야 한다.
7.2.4 모듈화(Modularization)
(1) 목적
복잡성을 줄이고 하부시스템 간의 인터페이스 고장을 예방하기 위함이다.
(2) 방법
(가) 모든 하부시스템은 설계단계에서 정의되고 보유기능에 대한 규모가 정해 져야 한다.
(나) 하부시스템간의 인터페이스를 가능한 간결하게 유지하고 데이터 공유 및 정보교환을 위한 상호섹션(Cross section)을 최소화 시켜야 한다.
7.2.5 컴퓨터 지원 설계(CAD)
(1) 목적
본 방법은 이미 검증이 완료된 구성요소를 사용하여 설계 과정을 체계적으로 실행하기 위한 것이다.
(2) 방법
(가) 컴퓨터 지원 설계(CAD)는 시스템이 복잡한 경우 하드웨어 및 소프트웨 어의 설계 시에 사용된다.
(나) 컴퓨터 지원 설계(CAD)의 보정방법은 특정 시험, 과거의 사용실적 및 안 전관련 시스템의 적용사례 등을 통하여 증명하여야 한다.
.
7.2.6 시뮬레이션
(1) 목적
전기ㆍ전자회로, 부품의 기능 및 크기 등에 대하여 체계적이고 완전한 검사를 수행하기 위한 것이다.
(2) 방법
(가) 안전관련 시스템의 회로기능은 소프트웨어 동작모델을 통해 시뮬레이션 한다.
(나) 회로의 각 부품은 한계 데이터(Marginal data)에 의해 응답특성을 시뮬레 이션 하여야 한다.
7.2.7 지시문(Walk-through)
(1) 목적
사양과 제품 간의 차이를 파악하기 위한 것이다.
(2) 방법
(가) 안전관련 시스템의 기능이 안전요구사양을 만족하는지 시험하고 평가하 기 위한 것이다.
(나) 제품을 제작하고 사용하기 위한 잠재적인 위험요소를 문서화하고 이를 해결하기 위한 것이다.
(다) 지시문의 작성자는 능동적이고 검사자는 수동적이다.
7.3 E/E/PE 시스템의 안전성 검증
7.3.1 주변 환경에 대한 기능시험
(1) 목적
본 시험은 주변 환경에 의하여 안전관련 시스템이 영향을 받는지의 여부를 확 인하기 위한 것이다.
(2) 방법
다양한 주변 환경 조건을 사용하여 안전 기능의 신뢰성을 평가하는 기법이다.
7.3.2 간섭 충격파 내성시험(Interference surge immunity testing)
(1) 목적
간섭 충격파가 안전관련 시스템에 침입했을 경우를 대비하여 이에 대한 내성 을 시험한다.
(2) 방법
(가) 시스템에는 응용 프로그램이 설치되어 있고, 인터페이스 및 전원공급선과 같은 전선으로 인해 소음신호가 침입할 수 있다.
(나) 간섭충격파 한계치의 정량화는 간섭 충격파 값을 서서히 증가시키면서 기능이 실패한 경우의 수치를 한계치로 설정하는 것이다.
7.3.3 정적 분석(Static analysis)
(1) 목적
본 방법은 시스템을 시험하거나 운전 중에 발생할 수 있는 구조적 고장을 예 방하기 위한 것이다.
(2) 방법
(가) 본 분석은 체계적이고 컴퓨터 지원이 가능한 방법으로서, 안전요구사항과 관련된 사항이 완전성ㆍ일관성ㆍ명확성 등에 부합하는지를 확인하기 위 하여 시제품의 정적특성을 검사한다.
(나) 정적 분석은 반복시험이 가능하고, 시험은 완료단계에 도달한 안정된 시 제품을 대상으로 한다.
(다) 하드웨어와 소프트웨어에 대한 정적 분석의 예시는 다음과 같다.
① 동일한 입력자료가 시스템 내에서 동일한 값을 가지고 있는지를 파악 하는지에 대한 데이터 흐름의 일관성 분석
② 제어 경로의 결정, 접근 불가능한 경로파악 등의 제어흐름분석
③ 소프트웨어의 모듈 간에 이루어지는 변수의 이동경로파악과 같은 인터 페이스 분석
④ 생성ㆍ참조ㆍ삭제되는 변수가 잘못된 절차에 의해 이루어지는지를 확 인하는 데이터 흐름분석
⑤ 특정 지침의 물리적 특성을 만족하는지의 여부
7.3.4 동적 분석(Dynamic analysis)
(1) 목적
본 방법은 완성단계에 앞서 시제품의 동적 특성을 검사함으로서 사양과 일치 하지 않는 부분을 찾아내기 위한 것이다.
(2) 방법
(가) 안전관련 시스템의 동적 분석은 실제 사용 환경에 부합하는 상태의 입력 값을 적용시켜 시제품이 실제 운전조건과 유사한 결과를 나타내는지를 확인한다.
(나) 안전관련 시스템의 출력이 해당 조건에 부합하는 결과가 도출된 경우에 는 분석결과에 만족하지만, 결과가 조건에 부합하지 않는 경우에는 안전 관련 시스템을 보완하여 새로운 시제품으로 재분석을 실시하여야 한다.
7.3.5 고장 분석
(1) 고장 형태 영향분석(Failure modes and effects analysis)
(가) 목적
시스템 구성요소에 의해 발생 가능한 고장 원인을 예측하고, 이 고장이 시스템에 미치는 영향을 평가함으로써 시스템 설계 내용을 분석하는 것이
다.
(나) 방법
분석은 일반적으로 기술자 회의를 통해 이루어지며 시스템의 각 구성요소 에 대하여 고장 형태, 원인과 결과, 검출 절차 및 권장 사항 등을 체계적 으로 분석한다. 권장 사항에 대한 조치를 실시한 경우에는 그 내용과 시 정 조치를 문서화하여야 한다.
(2) 원인-결과도(Cause consequence diagram)
(가) 목적
시스템에서 발생할 수 있는 일련의 사고를 다이어그램 형식으로 모델링하 기 위한 것이다.
(나) 방법
① 이 방법은 고장나무 분석(Fault tree analysis: FTA)과 사건나무 분석 (Event tree analysis: ETA)을 종합한 것으로써 원인-결과도를 귀납적 및 연역적 방법으로 분석하는 것이다.
② FTA는 주요 위험사상인 정상사상을 중심으로 위험원인을 추적하는 연역적 방법이며, ETA는 사고 원인으로부터 그 결과를 추적하는 귀납 적 방법이다.
③ 도표에는 정상사상을 기준으로 하부 사상들이 여러 갈래로 연결되어 나타낼 수 있는데, 이를 "FT도"라 한다.
④ 사상들을 연결하는 표준기호는 논리 기호와 결합하여 다이어그램을 보 다 간결하게 표현할 수 있고 이를 통해 보다 쉽게 다이어그램을 이용 하여 특정 주요 사고의 발생 확률을 산출할 수 있다.
(3) 사건나무 분석
(가) 목적
초기 사고 발생 이후 시스템에 발생할 수 있는 일련의 사고를 다이어그램 형식으로 도표화하고 이를 통해서 어느 정도의 심각한 결과가 발생하였는 지를 확인하는 것이다.
(나) 방법
① 다이어그램 맨 상단에 초기 사고를 설정하고, 사고 이후 결과를 순차 적으로 기록한다.
② 정상사상을 기준으로 사고 조건에 따라 “예"와 ”아니오" 갈래로 분류 하여 조건에 따라 사고가 어떻게 나타나는지를 기술하고 이러한 과정 을 반복하여 다이어그램을 완성한다.
③ 일련의 사고과정에 대한 확률을 계산함으로써 사고로 인한 최종 피해 결과의 확률을 계산한다.
(4) 고장형태, 영향 및 치명도 분석(Failure modes, effects and criticality analysis)
(가) 목적
가장 중요한 구성요소를 결정하고 이에 대한 안전대책을 수립하기 위하여 단일 고장으로 인한 재해 및 기능저하에 가장 큰 영향을 미치는 구성요소 의 우선순위를 정하는 것이다.
(나) 방법
① 치명도는 다양한 방법으로 결정할 수 있으나 일반적으로 치명도 수준
(Criticality number)은 9개의 파라미터로 구성된 함수로 표현된다.
② 치명도를 결정하는 단순한 방법은 구성요소의 고장 확률과 피해를 곱 하여 결정하며, 이는 위험성 평가방법과 유사하다.
(5) 결함나무 분석
(가) 목적
위험은 파악과 이의 사고로 인한 피해결과를 예측할 수 있도록 사건 및 일련의 사건조합을 분석할 수 있도록 하는 것이다.
(나) 방법
① 주요 위험 또는 피해의 원인이 되는 사건을 정상사건으로 설정하고 수 치상으로 이의 원인을 분석하는 방법이다.
② 각각의 사건에 대한 원인을 논리연산자를 사용하여 결합시키고 동일한 방법으로 최종 원인이 도출될 때까지 진행한다.
③ 결함나무 분석은 도식화된 방법이며 표준화된 기호를 사용한다.
④ 본 기법은 주로 하드웨어 시스템 분석에 사용되지만 소프트웨어 고장 분석에도 용이하다.
7.3.6 최악의 사고사례 분석(Worst-case analysis)
(1) 목적
주변 환경과 구성요소의 최대허용범위에 대하여 정상상태를 벗어나는 최악의 구조적 고장원인을 찾아내기 위한 것이다.
(2) 방법
(가) 시스템의 운전능력과 구성요소의 기능에 대하여 이론적으로 시험하고 계 산하는 것이다.
(나) 주변 환경의 조건을 구성요소가 허용하는 범위까지 계속 악화시키면서 시 험한다.
(다) 시스템의 필수 응답특성을 검사하고 사양과 비교한다.
7.3.7 기능 확장 시험 (Expanded functional testing)
(1) 목적
사양 및 설계․개발 단계에서 발생할 수 있는 고장원인을 찾아내고, 사전에 알려지지 않은 입력 또는 발생가능성이 낮은 사건에 대하여 안전관련 시스템 의 동작특성을 파악하기 위한 것이다.
(2) 방법
(가) 본 방법은 매우 드물게 발생하거나 사양을 벗어나는 입력조건에 대한 안 전관련 시스템의 동작특성을 검토하는 것이다.
(나) 안전관련 시스템에서 나타난 동작특성을 사양과 비교하게 된다.
(다) 안전관련 시스템의 동작특성이 사양에 지정되어 있지 아니한 경우에는 관찰된 동작특성이 설비안전에 미치는 영향을 검토하여야 한다.
7.3.8 최악의 사고사례에 대한 시험(Worst-case testing)
(1) 목적
최악의 사고사례분석에서 검토된 결과에 대하여 시험하는 것이다.
(2) 방법
(가) 시스템의 운전능력과 구성요소의 기능에 대하여 시험하는 것이다.
(나) 주변 환경의 조건을 구성요소가 허용하는 범위까지 계속 악화시켜 시험 한다.
(다) 시스템의 필수 응답특성을 검사하고 사양과 비교한다.
7.3.9 삽입 사고 시험(Fault insertion testing)
(1) 목적
하드웨어의 고장이나 시뮬레이션을 통해 얻은 실패사례를 문서화하기 위한 것 이다.
(2) 방법
(가) 본 방법은 사고의존성을 평가하는 정량적 방법이다.
(나) 본 방법은 상세 기능블록도 및 회로도를 사용하여 고장의 위치와 유형이 어떤 경로로 유입하는지를 규명하는 것이다.
(다) 본 방법은 기본적으로 단일 사고에 대하여 분석한다.
(라) 사고가 불분명한 경우에는 두 번째 사고를 가정하여 이에 대한 영향을 검토하여야 하며, 삽입 사고는 수백 개까지 증가시킬 수 있다
(마) 본 작업은 여러 분야의 전문가로 이루어진 팀에 의해 수행되며, 시험 전 시스템 제작자와 사전 협의하여야 한다.
(바) 중대한 사고를 야기하는 고장에 대하여 평균운전시간을 계산하고, 계산된 값이 너무 작으면 시스템을 변경하여야 한다.