IEC 61508-3 SW Engineering

ISO 26262 Road vehicles - Functional safety Training by Korea Testing Laboratory
Introduction to Functional safety (IEC 61508)
• Software Development

ⓒ-Copyright 2014 Korea Testing Laboratory 2 / 166
안전관련 소프트웨어
안전관련 시스템에 의해 사용되도록 개발된 모든
소프트웨어
안전관련 시스템 개발 중 사용된 모든 소프트웨어
안전관련 시스템이 목표하는 안전기능과 안전무결
성 달성
안전관련 시스템의 안전성 및 신뢰성 달성
 정의
 목적

IEC 61508-3 소프트웨어 요구사항
 소프트웨어 품질 및 안전 관리에 대한 요구사항
 소프트웨어 개발 프로세스(또는 개발 수명주기)에 대한 요구사항
 소프트웨어 안전기능에 대한 요구사항
 소프트웨어 안전무결성에 대한 요구사항
 소프트웨어 Verification 및 Validation에 대한 요구사항
 소프트웨어 형상관리에 대한 요구사항
 소프트웨어 개발 및 운영에 관련된 이들에 대한 교육 및 능력에 대한 요구사항

Contents
안전 관련 소프트웨어 관리 (61508-3, Ch6)
소프트웨어 안전 생명 주기 (61508-3, Ch7)
소프트웨어 안전 요구사항 명세(7.2)
시스템 안전의 SW 관점에 대한 validation계획(7.3)
소프트웨어 설계 및 개발(7.4)
PE 통합(HW, SW)(7.5)
소프트웨어 운영 및 변경 절차(7.6)
시스템 안전 validation의 소프트웨어 관점(7.7)
소프트웨어 변경(modification)(7.8)
소프트웨어 verification(7.9)
아키텍처 설계 (7.4.3)
Tool qualification (7.4.4)
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)
Functional Safety Assessment (61508-3, Ch8)
Annex A, B

V-모델
요구사항 분석
(Requirements)
설계
(Design)
구현
(Coding)
단위시험
(Unit Test)
시스템 시험
(System Test)
Validation
상세화
(Specification)
통합시험
(Integration Test)
 Validation : Do right job(올바르게 일을 하고 있는가) – 요구사항도 틀릴 수 있다는 가정
 Verification : Do job right(명세대로 수행했는가) – 요구사항은 틀리지 않는다는 전제

6 Management of safety-related software

Management of safety-related software
소프트웨어 조달(procurement)
개발(development)
통합(integration)
검증(Verification)
확인(Validation)
변경(modification)
기능 안전 계획
(Functional safety planning)
 목적
• 소프트웨어 개발을 정의된 절차 및 활동으로 구조화 하기 위해
 요구사항
• 기능 안전 계획은 다음과 같은 사항에 대한
전략을 정의해야 한다.
※ SIL 등급에 따라
달성되어야 하는 목
표들을 표준에 정의

 목적
• 소프트웨어 개발을 정의된 절차 및 활동으로 구조화 하기 위해서
 요구사항
• 소프트웨어 형상 관리에 대한 요건을 만족시키기 위한 계획을 세워야 한다.
수행 활동 수행 활동의 목적
1. 소프트웨어 안전 수명주기 전반에 걸쳐
관리 및 기술 제어를 적용한다
소프트웨어 변경 사항을 관리하고 안전 관련
소프트웨어의 특정 요구사항이 계속 만족된다
는 것을 보장하기 위하여
2. 모든 필요한 작업이 수행되었다는 것을
보장한다
요구된 소프트웨어 시스템적 능력이 달성되었
다는 것을 입증하기 위해
3. 필요한 모든 형상 아이템의 정확한 고유
식별을 유지한다
E/E/PE 안전 관련 시스템의 안전 무결성 요구
사항을 충족하기 위해

형상 아이템에 포함되는 항목(최소 사양)
1. 안전 분석 및 요구사항
2. 소프트웨어 사양 및 설계 문서
3. 소프트웨어 소스 코드 모듈
4. 테스트 계획 및 결과
5. verification 문서
6. E/E/PE 안전 관련 시스템에 통합되는 기존 소프트웨어 엘리먼트와 패키지
7. 어떤 작업을 수행하는데 사용되는 모든 도구 및 개발 환경

소프트웨어 형상 관리 수행 요건
1. 변경제어 절차를 적용해야 한다.
2. 런타임 시스템에 유효한 소프트웨어 엘리먼트 및 데이터를 로드 하도록 적절한 방
법이 구현되었음을 보장해야 한다.
3. 후속 작업으로 기능 안전 심사(audit)를 받기 위해 자료가 문서화되어야 한다
4. 안전 관련 소프트웨어의 릴리즈를 공식적으로 문서화해야 한다. 릴리즈된 소프트웨
어의 작동 수명 내내 소프트웨어 및 모든 관련 문서 그리고 서비스의 모든 데이터 버전
의 원본(master copy)은 유지 및 변경을 가능하게 하기 위해서 유지되어야 한다.
IEC 61508-7을 참조
기능 안전 심사(audit)를
받기 위해 필요한 문서
1. 형상 상태 (configuration status)
2. 릴리즈 상태
3. 모든 변경 승인에 대한 정당한
이유(Impact analysis 수행)
4. 변경의 세부사항

목표 이하 안전 성능
시스템적 결함
신/ 개정된 법적 규제
안전요구사항 변경
목표수준 이하인 운영 중 성능
일상적 기능안전성 감사[변경요청]
[변경 계획서]
[변경을 위한 분석 연구]
영향 분석
(Impact analysis)
위험원 및 리스크 분석
영향분석
보고서
변경 허가
변경 보고서 및
일지
Re-validation,
Re-verification
소프트웨어 수정 절차
 변경 제어(Change-control)

 변경 제어(Change-control)를 수행하는 목적
– 허가되지 않은 변경을 방지
• 변경 요청을 문서화
• 제안된 변경의 영향을 분석
• 요청의 승인 또는 거부
• 허가(authorization)
• 모든 승인된 변경의 세부 사항을 문서화
• 소프트웨어 개발의 적절한 시점에 형상 베이스라인을 수립
• 베이스라인에서 (부분)통합 테스트를 문서화
• 모든 소프트웨어 베이스라인의 구성 또는 빌드를 보장(초기 베이스라인의 re-build 포함)

7 Software safety lifecycle

Software safety lifecycle 계획
 목적
• 소프트웨어 개발을 정의된 절차 및 활동으로 구조화 하기 위해서
 요구사항
• IEC61508-1의 시스템 계획에 부합하여야 함
• 표준에 적합한 lifecycle model(ex: waterfall, spiral, etc)을 선택해야 함
• 소프트웨어 안전 라이프사이클의 각 단계는 scope, input, output가 정의되어야 함
• 소프트웨어 안전 라이프사이클을 적용하기 위해 customization 가능함. 단 justify해야함
• Quality 및 safety assurance가 소프트웨어 안전 라이프사이클에 포함되어야 함
• 각각의 라이프사이클 단계에서 적절한 기술과 방법이 사용되어야 함. 부속서 A, B에서 가
이드를 제시함
(but, 그런 가이드를 준수한다고 해서 안전 무결성이 달성됨을 보장하는 것이 아님)
• 소프트웨어 안전 라이프사이클의 개발 주기 동안에 발생된 변경(modification)이 발생하
는 경우 impact analysis가 수행되어야 한다.
– Impact analysis를 통해 (1) 어떤 소프트웨어 모듈이 영향을 받는지 파악, (2) 안전 라이프사
이클의 이전 단계 중에 어느 부분이 반복 수행되어야 하는지를 파악해야 함
– 영향 분석에 대한 지침은 IEC 61508-7을 참조

Software safety lifecycle
Title Objectives Inputs Outputs
10.1
SW 안전 요구 사
항 명세
1) SW 안전 기능과 SW의 시스템적 역
량에 대한 요구사항의 관점에서 안전과
관련된 SW에 대한 요구사항을 명세하
기 위해서
[WP01] E/E/PE 시
스템 안전 요구 사항
명세의 할당동안 개
발된 E/E/PE 안전
요구사항 명세서
[WP02] SW 안전 요구 사항
명세서
2) 요구된 안전 기능을 구현하기 위해
필요한 각각의 E/E/PE 안전 관련 시스
템에 대한 SW 안전 기능 요구 사항을
명세하기 위해
3) E/E/PE안전 관련 시스템에 할당된
각각의 안전 기능에 할당된 안전 무결
성 등급(SIL)을 달성하기 위해 각각의
E/E/PE안전관련 시스템에 필요한 SW
시스템적 능력에 대한 요구사항을 명세
하기 위해
10.2
시스템 안전의
SW 측면에 대한
검증 계획
시스템 안전의 SW 측면을 검증하기 위
한 계획을 개발하기 위해
[WP02] SW 안전 요
구 사항 명세서
[WP03] 시스템 안전의 SW 측
면에 대한 검증 계획서

10.3 SW 설계 및 개발
아키텍처 :
[WP04] E/E/PE 시
스템 HW 아키텍처
설계서 (IEC 61508-
2에서)
[WP05] SW 아키텍처 설계
[WP06] SW 아키텍처 통합 테
스트 명세서
[WP07] SW/PE 통합 명세서
(IEC 61508-2에서도 역시 요
구됨)
1) 필요한 안전 무결성 수준(SIL)에 대
해 안전 관련 SW의 특정 요구 사항을
충족하는 SW 아키텍처를 만들기 위해
서,
2) 제어하의 장치 안전을 위한 E/E/PE
HW/SW의 상호작용의 중요성을 포함
하여 E/E/PE 안전 관련 시스템의 HW
아키텍처에 의해 SW에 배치된 요구 사
항을 평가하기 위해
지원 도구와 프로그래밍 언어 :
[WP05] SW 아키텍
처 설계
[WP09] 지원 도구 및 코딩 표
준
[WP08] 개발 도구의 선택
1) SW의 전체 안전 수명주기에 걸쳐 확
인, 검증, 평가 및 수정을 지원하는 언어,
컴파일러, 런타임 시스템 인터페이스,
사용자 인터페이스 및 필요한 안전 무
결성 수준에 대한 데이터 형식과 표현
등을 포함하여 도구의 적절한 집합을
선택하기 위해

세부 설계 및 개발 (SW 시스템 설계) :
[WP05] SW 아키텍
처 설계
[WP09] 지원 도구
및 코딩 표준
[WP10] SW 시스템 설계 사양
[WP17] SW 시스템 통합 테스
트 사양
1) 분석 가능하고 검증가능하며 안전하
게 수정될 수 있는 필요한 SIL의 관점에
서 안전 관련 SW에 대한 명세된 요구
사항을 충족시키기 위해 SW를 설계 및
구현하기 위해
세부 설계 및 개발 (개별 SW 모듈 설
계) :
[WP10] SW 시스템
설계 사양
및 코딩 표준
[WP11] SW 모듈 설계 사양
[WP12] SW 모듈 테스트 사양
구현하기 위해
자세한 코드 구현 :
[WP11] SW 모듈 설
계 사양
및 코딩 표준
[WP13] 소스 코드 목록
[WP14] 코드 검토 보고서
구현하기 위해

SW 모듈 테스트 :
[WP12] SW 모듈 테
스트 사양
[WP13] 소스 코드
목록
[WP14] 코드 검토
보고서
[WP15] SW 모듈 테스트 결과
[WP16] 검증되고 및 테스트
완료된 SW 모듈
1) 달성되어야 하는 안전 관련 SW에 대
한 요구사항을 검증하기 위해서(필요한
SW 안전 기능과 SW의 시스템적 능력
관점에서)
2) 각각의 SW 모듈이 의도된 기능대로
동작하고 의도되지 않은 기능을 수행하
지 않음을 보이기 위해
3) 적절하다면, PE시스템의 데이터에
의한 설정(configuration)이 SW의 시스
템적 능력에 대한 명세된 요구사항에
부합하는지를 보이기 위해

SW 통합 시험 :
[WP17] SW 시스템
통합 테스트 사양
[WP18] SW 시스템 통합 테스
트 결과
[WP19] 검증된 SW 시스템
1) 안전 관련 SW에 대한 요구 사항 (필
수 SW 안전 기능과 SW의 체계적인 기
능의 측면에서) 을 만족하는지 확인하
기 위해
2) 모든 SW 모듈, 엘리먼트, 서브시스
템들이 그들의 의도된 기능대로 동작하
고 의도되지 않은 기능은 수행하지 않
는 상호작용을 보이기 위해
3) 적절하다면, PE시스템의 데이터에
의한 설정(configuration)이 SW의 시스
템적 능력에 대한 명세된 요구사항에
부합하는지를 보이기 위해
10.4
프로그램 전자 통
합 (HW 및 SW)
1) 대상 프로그램 가능한 전자 HW에
SW를 통합하기 위해서
[WP06] SW 아키텍
처 통합 테스트 명세
서
[WP07] SW/PE 통
합 명세서(IEC
61508-2에서도 역
시 요구됨)
[WP20] 통합된 PE
[WP21] SW 아키텍처 통합 테
스트 결과
[WP22] PE 통합 테스트 결과
[WP23] 검증된 통합 PE
2) SW와 HW를 안전관련 프로그램 가
능한 전자장치에 통합하여 그들의 호환
성과 안전 무결성 등급의 의도된 요구
사항에 만족함을 보이기 위해서

10.5
SW 운영 및 변경
절차
1) E/E/PE 안전 관련 시스템의 기능 안
전이 운영 및 수정중에 유지되는 것을
보이기 위해 필요한 SW와 관련된 정보
및 절차를 제공하기 위해
관련된 것들
[WP24] SW 운영 및 변경 절
차
10.6
시스템 안전 검증
SW 측면
1) 통합된 시스템이 의도된 안전 무결
성 등급에서 안전 관련 SW에 대한 명
세된 요구사항들을 조합하였음을 보이
기 위해
[WP25] 시스템 안전
의 SW 측면에 대한
검증 계획
[WP26] SW 안전 검증 결과
[WP27] 검증 SW
- SW 수정
1) 요구된 SW가 시스템적인 능력이 유
지됨을 보이면서 확인된 SW에 대한 수
정, 향상, 적용을 가이드하기 위해
[WP28] SW 수정 절
차
[WP30] SW 수정 요
청
[WP29] SW 변경 영향 분석
결과
[WP31] SW 수정 로그
- SW 검증
1) 이 단계에 입력으로 제공되는 출력
과 표준에 관하여 정확성과 일관성을
보장하기 위해 특정 SW 안전 수명주기
단계에서 출력을 테스트하고 평가하기
위해
적절한 검증 계획
(단계에 따라 다름)
적절한 검증 보고서 (단계에
따라 다름)
-
SW 기능 안전 평
가
1) E/E/PE 안전 관련 시스템에 의해 달
성된 기능 안전의 SW 측면에 대한 조
사 및 판단을 하기 위해
[WP32] SW 기능 안
전 평가 계획
[WP33] SW 기능 안전 평가
보고서

Lifecycle model
소프트웨어
안전요구사항 명세
모듈 설계
코딩(Coding)
(코드검증/자료검증)
모듈 시험
(Module testing)
안전관련
밸리데이션 시험
(소프트웨어 안전
요구사항 시험)
Validation
소프트웨어
시스템 설계
모듈 통합시험
소프트웨어
아키텍처
SW&HW 통합시험
(Integration Test)
Verification
Output
E/E/PE 시스템
안전요구사항
명세
E/E/PE
시스템
아키텍처
Validated
Software

Lifecycle model – 소프트웨어 안전요구사항 명세
소프트웨어
• E/E/PE 안전 요구사항 명세서
• 소프트웨어 안전에 대한 요구사항은 E/E/PE 안전 관련 시스템의 요
구사항과 기능 안전 계획에 명시된 특정 요구사항으로 부터 도출되
어야 한다.
• 요구사항의 명세가 완료되어야 하며 적절한 상세화 수준을 가져야
한다.
• SIL 등급에 적절하도록, 요구사항들은 Clear, Precise, 명백한
(Unequivocal), Verifiable, Testable, Maintainable, Feasible 해야 한
다.
• 모호함이 없어야 한다.
• 요구사항은 작동의 모든 mode를 명시해야 한다.
• 하드웨어에 의해 부과된 모든 관련 비 기능 제약 조건이 명시되어
야 한다.
• 기능과 관련된 Safety와 non-safety의 차이가 고려되어야 한다.
• 외부 인터페이스와 관련된 요구된 안전 속성이 명시되어야 한다.
 소프트웨어 안전 요구사항 명세의
모든 SIL 에 대한 Objectives
• 소프트웨어 self-monitoring, electronic 하드웨어의 monitoring, 진
단 및 주기적 테스트에 대한 적절한 고려사항이 명시되어야 한다.
• 제품의 요구된 안전 속성이 다음을 포함하여 명시되어야 한다.
 안전 상태(safe state)를 달성하거나 유지하기 위한 UEC를
가능하게 하는 기능
 결함 탐지, 통보 및 관리와 관련된 기능
• SW 안전 요구 사항 명세서
 안전 기능 및 진단에 대한 소프트웨어 안전 요구사항 명
세의 모든 SIL 에 대한 Objectives

Lifecycle model – 소프트웨어 아키텍처
• E/E/PE 시스템 HW 아키텍처 설계서
• SW 아키텍처 설계
• SW 아키텍처 통합 테스트 명세서
• SW/PE 통합 명세서
소프트웨어
아키텍처
• 소프트웨어 공급자/개발자에 의해 제안된 소프트웨어 아키텍처가
작성되고, 소프트웨어 아키텍처 설계의 설명은 상세해야 한다.
• 소프트웨어 아키텍처의 설명은 적절한 redundancy와 diversity를
포함하여 fault tolerance와 fault avoidance에 대한 설계 전략들을
포함해야 한다.
• 아키텍처 설명은 컴포넌트/하위컴포넌트로 설계를partitioning한
것에 기반해야 한다.
• 아키텍처 설계 설명은 모든 소프트웨어/하드웨어 상호작용을 결정
하고, 정상 및 고장의 경우를 포함하여 그것 들의 중요성을 평가해
야 한다.
• 아키텍처 설계 설명은 모호함이 없어야 한다.
• 아키텍처 설계 설명은 모든 데이터의 안전 무결성을 유지하는데 사
용되는 설계 특징들을 나타내야 한다.
 소프트웨어 아키텍처 설계의

Lifecycle model – 소프트웨어 시스템 설계
• 지원 도구 및 코딩 표준
소프트웨어
시스템 설계
• 소프트웨어 상세 설계 이전에 다음의 정보가 이용 가능해야 한다.
 소프트웨어 안전 요구사항 명세
 소프트웨어 아키텍처 설계의 설명
 소프트웨어 안전 validation 계획
• 소프트웨어는 안전한 수정(safe modification)의 modularity,
structure, testability, capacity를 달성하기 위해 생성되어야 한다.
• 소프트웨어 모듈의 설계 및 각 소프트웨어 모듈에 적용되는 테스트
가 명시되어야 한다.
• 구조화된 방법이 도입되어야 한다.
• SW 시스템 설계 사양
• SW 시스템 통합 테스트 사양
 Detailed design and development의
모든 SIL에 대한 Objectives

Lifecycle model – 모듈 설계
• SW 모듈 설계 사양
• SW 모듈 테스트 사양
모듈 설계
• 요구된 SIL에 따라서, 언어, 컴파일러, 형상 관리 도구 및 적절
한 자동화 도구를 포함하는 통합된 tool의 적절한 set이 선택
되어야 한다.
• SIL에 의해 요구되는 정도에 따라, 선택된 프로그래밍 언어는
국내/국제 표준에 의해 유효성이 입증되거나 해당 목적에 대
한 적합성을 확인하기 위해 평가된 compiler/translator가 있어
야 한다.
• 프로그래밍 언어는 application의 특징과 일치해야 한다.
• IDE/compiler/translator는 프로그래밍 실수의 검출을 용이하
게 해야 한다.
• 프로그래밍 언어는 설계 방법(design method)에 적합해야 한
다.
• 프로그래밍 언어의 전체 또는 일부는 강형 언어(strongly
typed)여야 한다.
• 코딩 표준은 모든 안전 관련 소프트웨어의 개발에 사용되어야
한다.
• 코딩 표준은 평가자(assessor)에 의해 목적에 맞도록 검토되어
야 한다.
• 최소한 코딩 표준은 좋은 프로그래밍 사례 명시, 안전하지 않
은 언어 특징들에 대한 금지 그리고 소스 코드 문서화 절차를
구성 및 명시해야 한다.
• SW 시스템 설계 사양
 Programming tools의

Lifecycle model – 코딩(Coding)
• SW 모듈 설계 사양
코딩(Coding)
(코드검증/자료검증)
• 소스 코드는 readable, understandable, testable 해야 한다.
• 소스 코드는 소프트웨어 모듈 설계에 대한 특정 요구사항을 만족해
야 한다.
• 소스 코드는 안전 계획(Safety planning) 동안 명시된 모든 관련 요
구사항을 만족해야 한다.
• 각 소스 코드 모듈은 review되어야 한다.
• 소스 코드 목록
• 코드 검토 보고서
 Code implementation의

Lifecycle model – 모듈 시험
• SW 모듈 테스트 사양
• 소스 코드 목록
• 코드 검토 보고서
모듈 시험
(Module testing)
• 각 소프트웨어 모듈이 의도된 기능을 수행하고 의도되지 않은 기능
을 수행하지 않는다는 것을 보장하기 위해 소프트웨어 설계 동안
명시된 대로 테스트되어야 한다.
• 데이터 기록 및 분석이 수행되어야 한다.
• Functional black-box testing이 수행되어야 한다.
• 모듈 테스트의 결과가 문서화되어야 한다.
• 테스트에서 발견된 결함에 대한 시정 조치(corrective action)의 절
차가 명시되어야 한다.
• SW 모듈 테스트 결과
• 검증되고 테스트 완료된 SW 모듈
 Module testing의

Lifecycle model – 모듈 통합시험
• SW 시스템 통합 테스트 사양
모듈 통합시험
• 소프트웨어 통합 테스트는 설계 및 개발 단계와 동시에 명시되어야
한다.
• 명시된 통합 테스트는 test case와 test data, 수행되어야 하는 test
type, test 환경, 도구, 설정 및 프로그램을 명시해야 한다.
• 소프트웨어 통합 동안의 어떠한 수정 또는 변경은 다음 사항을 고
려하여 impact analysis의 대상이 될 수 있다.
 영향을 받은 소프트웨어 모듈
 re-verification과 re-design 활동의 필요성
• SW 시스템 통합 테스트 결과
• 검증된 SW 시스템
 Software Integration testing의

Lifecycle model – SW&HW 통합시험
• SW 아키텍처 통합 테스트 결과
• PE 통합 테스트 결과
• 검증된 통합 PE
SW&HW 통합시험
(Integration Test)
• 통합 테스트는 device에서 하드웨어와 소프트웨어의 호환성
(compatibility)을 보장하기 위해 설계 및 개발 단계 동안 명시되어
야 한다.
• device에 대한 통합 테스트는 다음 사항을 명시해야 한다.
 통합 레벨로 시스템 분할
 테스트 케이스 및 테스트 데이터
 수행되어야 하는 테스트 유형
 도구, 지원 소프트웨어 및 설정 설명을 포함하는 테스트
환경
 테스트 종료를 판단하기 위한 기준
• 명시된 통합 테스트는 개발자 site에서 수행될 수 있는 활동과 사용
자 site에서 수행되어야 하는 활동을 구분해야 한다.
• PE에 대해 명시된 통합 테스트는 다음 활동들을 구분해야 한다.
 PE 하드웨어 target에 소프트웨어 시스템을 통합(merge)
 E/E/PE 통합
 Device와 E/E/PE 안전 관련 시스템의 전체적인 통합
(IEC 61508-2에서도 요구됨)
• 통합된 PE
 통합 테스트 명세서의

Lifecycle model – 안전관련 Validation 시험
안전관련
• 계획이 수행되고, 소프트웨어가 안전 요구사항을 만족하는지 입증
하는데 사용될 절차적, 기술적 단계가 명시되어야 한다.
• Validation 활동은 소프트웨어 안전 validation 계획에 명시된 대로
수행되어야 한다.
• Testing은 소프트웨어에 대한 주요 validation 방법이다; validation
활동을 보충하기 위해, animation 및 modelling이 사용될 수 있다.
• 소프트웨어 안전 밸리데이션 결과
• 밸리데이션된 소프트웨어
 Validation planning의
 소프트웨어 안전 validation 실행의
• Validation 계획의 범위 및 내용은 독립적인 평가자(independent
assessor)에 의해 검토되어야 한다.
• 시스템 안전 측면의 소프트웨어
• 밸리데이션 계획
 Validation plan review의

7.2 Software Safety Requirements Specification

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Software Safety Requirements Specification
Title 10.1 SW 안전 요구 사항 명세
Objectives
1) SW 안전 기능과 SW의 시스템적 역량에 대한 요구사항의 관점에서 안전과 관련된 SW에 대한 요
구사항을 명세하기 위해서
2) 요구된 안전 기능을 구현하기 위해 필요한 각각의 E/E/PE 안전 관련 시스템에 대한 SW 안전 기능
요구 사항을 명세하기 위해
3) E/E/PE안전 관련 시스템에 할당된 각각의 안전 기능에 할당된 안전 무결성 등급(SIL)을 달성하기
위해 각각의 E/E/PE안전관련 시스템에 필요한 SW 시스템적 능력에 대한 요구사항을 명세하기 위해
Scope PE 시스템, 소프트웨어 시스템
Inputs
[WP01] E/E/PE 시스템 안전 요구 사항 명세의 할당 동안 개발된 E/E/PE 안전 요구사항 명세서
Outputs
[WP02] SW 안전 요구 사항 명세서

• 안전 관련 소프트웨어에 대한 요구
사항이 E/E/PE 안전 관련 시스템에
대해 명시되었다면 소프트웨어 안
전 요구사항의 명세는 반복될 필요
가 없음
E/E/PE 시스템
안전요구사항
명세
• 안전 관련 소프트웨어에 대한 요구사
항의 명세는 식별된 E/E/PE 안전 관
련 시스템의 안전 요구사항과 안전 계
획의 어떠한 요구사항으로부터 파생
되어야 함
• SW 요구사항의 명세는 요구된 안
전 무결성을 달성하여 설계 및 구
현이 가능해야 함
소프트웨어
요구사항 속성
•Accuracy
•Timing
•Performance
•Capacity
•Robustness
•Overload tolerance
•etc

소프트웨어
E/E/PE 시스템
안전요구사항
명세
※ 검토 시 고려사항
1. 안전 기능
2. 시스템 configuration 또는 아키텍처
3. 하드웨어 안전 무결성 요구사항 (프로그램 가
능한 전자장치, 센서, 엑츄에이터)
4. 소프트웨어의 시스템적 능력 요구사항
5. 용량(capacity) 및 응답 시간
6. 합리적으로 예측 가능한 잘못된 사용(misuse)
을 포함한 장비 및 운영자 인터페이스

 요구사항 작성 방법(7.2.2.1 ~ 7.2.2.4)
1. 안전 관련 소프트웨어에 대한 요구사항이 E/E/PE 안전 관련 시스템에 대해 명시되었다
면 소프트웨어 안전 요구사항의 명세는 반복될 필요가 없음
2. 안전 관련 소프트웨어에 대한 요구사항의 명세는 식별된 E/E/PE 안전 관련 시스템의
안전 요구사항과 안전 계획의 어떠한 요구사항으로부터 파생되어야 함
3. SW 요구사항의 명세는 요구된 안전 무결성을 달성하여 설계 및 구현이 가능해야 함
요구사항 속성
Accuracy
Timing
Performance
Capacity
Robustness
Overload
tolerance
4. 공통 원인 고장(CCF) 분석이 수행되어야 함.
1. 목적: 독립성을 해결하기 위함
2. 분석 이후 활동: 신뢰할 수 있는 고장 메커
니즘이 확인되는 경우, 효과적인 방어 수
단을 취해야 함
시험을 통해 방어수단의 효과성에 대한 확인이 필요함!

 요구사항 작성 방법
안전 요구사항이 충분히 정의되지 않은 경우
안전 관련 소프트웨어의 요구사항에 자세히 기술되어야 하는 항목
1. E/E/PE 안전 관련 시스템
2. E/E/PE 시스템의 EUC에 대한 모든 관련 동작 모드
3. E/E/PE 시스템에 연결된 장치 및 시스템
10.1
SW 안전 요구 사
항 명세
1) SW 안전 기능과 SW의 시스템적 역량에 대한
요구사항의 관점에서 안전과 관련된 SW에 대한
요구사항을 명세하기 위해서
[WP01] E/E/PE 시
스템 안전 요구 사항
명세의 할당동안 개
발된 E/E/PE 안전
요구사항 명세서
[WP02] SW 안전 요구 사항
명세서
2) 요구된 안전 기능을 구현하기 위해 필요한 각
각의 E/E/PE 안전 관련 시스템에 대한 SW 안전
기능 요구 사항을 명세하기 위해
3) E/E/PE안전 관련 시스템에 할당된 각각의 안
전 기능에 할당된 안전 무결성 등급(SIL)을 달성
하기 위해 각각의 E/E/PE안전관련 시스템에 필
요한 SW 시스템적 능력에 대한 요구사항을 명세
하기 위해

 요구사항 작성을 위한 요건(계속)
7. 소프트웨어 안전 요구사항의 명세는 하드웨어와 소프트웨어 사이의 안전 관련 또는 연관
된 제약 조건을 명시하고 문서화해야 한다.
8. E/E/PE 하드웨어 아키텍처 설계에 필요한 범위 내에서, 그리고 가능한 복잡성의 증가를
고려하여, 소프트웨어 안전 요구사항 명세는 다음을 고려해야 한다.
9. E/E/PE 안전 관련 시스템이 비 안전 기능을 수행하기 위해 필요한 경우, 안전 관련 소프
트웨어에 대해 지정된 요구사항은 비 안전 기능(non safety-related)을 명확하게 식별해야
한다.
– 안전 기능과 비 안전 기능 사이의 비 간섭에 대한 요구사항은 7.4.2.8 및 7.4.2.9를 참조
소프트웨어 안전 요구사항 명세 시 고려할 사항들
1. 소프트웨어 자체 모니터링(IEC 61508-7 참조)
2. 프로그래밍 가능한 전자 하드웨어, 센서, 그리고 엑츄에이터의 모니터링
3. 시스템이 실행되는 동안 안전 기능의 주기적 테스트
4. EUC가 작동 할 때 테스트가 가능하게 하는 안전 기능 활성화
5. E/E/PE 안전 관련 시스템의 안전 무결성 요구사항을 충족하기 위해 증명 테스트
(proof tests) 및 모든 진단 테스트를 실행하는 소프트웨어 기능

10. 소프트웨어 안전 요구사항 명세는 제품의 안전 특성을 표현해야 한다
(61508-1의 6절 참조).
소프트웨어 안전 기능에 대한 요구사항들
1. 안전 상태를 달성하거나 유지하기 위해 EUC를 활성화 하는 기능
2. 프로그래밍된 전자 하드웨어의 결함의 탐지(detection), 고지(annunciation) 및 관리
(management)와 관련된 기능
3. 센서와 액츄에이터 결함의 탐지, 고지 및 관리와 관련된 기능
4. 소프트웨어 자체 결함의 탐지, 고지 및 관리와 관련된 기능(소프트웨어 자체 모니터링)
5. 안전 기능이 On-line 되어 있을 때(safety functions on-line)의 주기적 테스트와 관련된 기능(즉,
의도된 운영 환경에서)
6. 안전 기능이 Off-line 되어 있을 때의 주기적 테스트와 관련된 기능(즉, EUC가 그것의 안전 기능
에 의존하지 않는 환경에서)
7. PE 시스템이 안전하게 수정될 수 있도록 하는 기능
8. 비 안전 관련 기능에 대한 인터페이스
9. 용량 및 응답 시간 성능
10. 소프트웨어와 PE 시스템 사이의 인터페이스(오프라인 및 온라인 프로그래밍 장비 포함)
11. 안전 관련 통신(IEC 61508-2의 7.4.11 참조)

10. 소프트웨어 안전 요구사항 명세는 안전 계획에 의해 다루어지는 프로젝트가 아닌 제품
의 안전 특성을 표현해야 한다(61508-1의 6절 참조).
• 시스템 관점에서의 소프트웨어의 능력(capability)에 대한 요구사항
1) 각 기능에 대한 안전 무결성 수준(IEC 61508-5의 Annex A를 참조)
2) 기능 사이의 독립성 요구사항
11. 소프트웨어 안전 요구사항이 설정 데이터(configuration data)에 의해 표현되거나 구현
되는 경우:
Configuration data가 만족되어야 하는 사항들
1. 시스템의 안전 요구 사항에 부합해야 함
2. 허용된 범위에서 표현되어야 함.
3. 조합 가능한 운영상의 모든 시나리오(operational parameter)에 대해서 검토하여 승인되어야 함
4. 내부 소프트웨어와 호환되는 방식으로 정의(예를 들어, 실행, 런타임, 데이터 구조 등)

12. 데이터가 소프트웨어와 외부 시스템 사이의 인터페이스를 정의하는 경우, IEC 61508-2
의 7.4.11항 이외에도, 다음과 같은 성능 특성이 고려되어야 한다.
13. 다음과 같은 내용에 대하여 운전 파라미터(Operational parameter)가 보호되어야 한다:
데이터의 성능 특성
1. 데이터 정의(data definitions)의 관점에서 일관성을 위한 요구사항
2. 유효하지 않은(invalid), 범위를 벗어난(out of range) 또는 타이밍이 맞지 않는
(untimely) 값
3. 최대 로딩 상태(maximum loading conditions)를 포함한, 응답 시간 및 처리량
(throughput)
4. 실행 시간과 교착 상태(deadlock)의 최상(best) 및 최악(worst)의 경우
5. 데이터 저장 용량의 오버 플로우 및 언더 플로우
보호되어야 하는 operational parameter
1. 유효하지 않은(invalid), 범위를 벗어난(out of range) 또는 타이밍이 맞지 않는
(untimely) 값
2. 허가되지 않은 변경(unauthorized changes)
3. 손상(corruption)

• 비고
– 오퍼레이터 정보 시스템은 오퍼레이터에게 익숙한 그림 레이아웃 및 용어를 사용해야 한다.
이것은 명확하고, 이해가능하고, 불필요한 세부사항 또는 측면이 없어야 한다.
– 오퍼레이터에게 표시되는 EUC에 대한 정보는 밀접하게 EUC의 물리적 배치(physical
arrangement)를 따라야 한다.
– 오퍼레이터에게 표시되는 항목 중 여러 가지 내용이 실현 가능한 경우 그리고/또는 가능한
오퍼레이터 동작이 한눈에 결과를 확인할 수 없는 상호작용을 허용할 때, 표시된 정보는 시
퀀스의 상태가 도달될 때, 작업이 가능할 때, 가능한 결과가 선택될 수 있을 때 디스플레이
또는 동작 시퀀스(action sequence)의 각 상태를 자동으로 포함해야 한다.

Table A.1 – Software safety requirements specification
Technique/Measure * Ref. SIL 1 SIL 2 SIL 3 SIL 4
1a Semi-formal methods Table B.7 R R HR HR
1b Formal methods B.2.2, C.2.4 --- R R HR
2 Forward traceability between the system safety
requirements and the software safety requirements
C.2.11 R R HR HR
3 Backward traceability between the safety
requirements and the perceived safety needs
C.2.11 R R HR HR
4 Computer-aided specification tools to support appropriate
techniques/measures above
B.2.4 R R HR HR
NOTE 1 The software safety requirements specification will always require a description of the problem in natural language and
any necessary mathematical notation that reflects the application.
NOTE 2 The table reflects additional requirements for specifying the software safety requirements clearly and precisely.
NOTE 3 See Table C.1.
NOTE 4 The references (which are informative, not normative) “B.x.x.x”, “C.x.x.x” in column 3 (Ref.) indicate detailed descrip
tions of techniques/measures given in Annexes B and C of IEC 61508-7.
* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/me
asures are indicated by a letter following the number. It is intended the only one of the alternate or equivalent techniques/measure
s should be satisfied. The choice of alternative technique should be justified in accordance with the properties, given in Annex C,
desirable in the particular application.

 Semi-formal method (Table B.7)
• Semi-formal notations
The description can in some cases be analyzed by machine or animated
to display various aspects of the system behavior.
(IEC 61508 2nd edition – CDV version에 기술된 semi-formal의 정의)
-예1) Finite state machines/state transition diagram.
-예2) Time Petri nets
(IEC 61508 2nd edition – CDV version에 제시된 2가지 semi-formal method)

 Formal notations
<Larch를 사용한 C++ object의 표현>
Ref) IEEE Transaction on software engineering vol16. no9.
1990
Using Larch to specify Avalon/C++ Object
<Common Algebraic Specification Language>
Ref) http://www.informatik.uni-bremen.de
- Formal하다는 뜻은 Mathematical 하다는 의미이다. 즉 software architectural design을
할 때 수학적인 notation을 사용한다는 의미이다.
- Formal notation으로 기술된 design은 그 design의 무결성을 수학적으로 증명 할 수 있다.

Reference
 IEEE 830-1998 Recommended Practice for Software Requirement
Specification
43
4.7 SRS에서 디자인을 포함시키기
SRS는 다음의 사항들을 명세해야 한다.
(1) 어떤 기능이 수행되어야 하는지
(2) 어떤 데이터가 생성되어야 하는지
(3) 누구를 위해 어떤 위치에서 어떤 결과가 생성되어야 하는지
SRS는 수행되어야 하는 서비스에 집중해야 한다.
SRS는 다음과 같은 디자인 아이템에 대해 보통은 명시하지 않아
야 한다.
a) software를 module로 분해하는 것
b) functions을 module에 할당하는 것
c) information의 흐름이나 모듈간의 control을 기술하는 것
d) data structure를 선택하는 것
요구사항을 작성하는 활동이 아니라, 소프트웨어 설계를 하는 활동의 범주에 해당함
/ 110

 General Requirements from other resources
컴퓨터 시스템은 의도된 용도와 환경에서의 작동을 위해 validation되어야 한다. 이러한 validation은 동작 조건과 환경
하에서의 테스트를 포함해야 한다.
최대 시스템 부하 시, CPU 처리량은 설계된 값의 80%를 초과해서는 안 된다.
컴퓨터 시스템 아키텍처는 single fault tolerant(고장 방지) 이어야 한다. Single software fault 또는 output으로 인해 , ha
zardous operation, critical accident 또는 catastrophic accident(비참한 사고)는 시작되면 안된다.
컴퓨터 시스템은 안전한 data 전송을 포함한 safety critical 컴퓨터 하드웨어와 safety critical 소프트웨어 기능들이 정확
하게 동작하는 것을 주기적으로 입증해야 한다.
컴퓨터 시스템은 적용 가능한 실시간 소프트웨어 안전 data의 유효성을 주기적으로 입증해야한다.
소프트웨어는 hazardous event의 time-to-criticality 내에 필요한 명령어를 처리해야 한다.
메모리 할당은 초기화 시에만 발생해야 한다.
시스템이 프로그램 코드의 유효하지 않은 메모리 영역을 사용하려고 하면, 시스템은 안전 상태로 복귀해야 한다.
RAM과 같은 Memory partitions은 소프트웨어를 불러오기전에 clear 시켜야 한다.
확인된 위험 명령어의 안전한 실행을 위해 명령어를 시작하기 전에 사전 조건이 존재해야 한다. 이러한 조건들의 예들
은 correct mode, correct configuration, component availability, proper sequence , parameters in range를 포함한다. 만
약 사전에 필요한 조건들이 충족되지 않는다면, 소프트웨어는 명령어를 reject하고, 사람에게 경고 메시지를 보낸다.
메모리 지역 명령어의 접근 보호 및 critical 소프트웨어 기능에 dedicate된 data의 보호에 대한 규정이 있어야 한다.
소프트웨어는 safety-critical한 명령어들의 timing을 포함한 적절한 순서를 제공해야 한다.

7.3 Validation plan for
software aspects of system safety

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Lifecycle model – 안전관련 Validation 시험(2)
안전관련
• Validation 수행 시기
• Validation 수행 인력
• Device 작동의 해당 mode
• Device의 각 mode에 대한 안전 관련 소프트웨어의 식별
• 기술적인 전략
• Validation 활동이 수행될 요구된 환경
• 소프트웨어 validation을 달성하기 위한 요구된 입력과 예상되는 출
력을 포함하는 Pass/Fail 기준
• Validation의 결과(특히 고장에 대하여)를 평가하기 위한 정책 및 절
차
• 소프트웨어 안전 밸리데이션 결과
• 밸리데이션된 소프트웨어
 Validation 고려사항(consideration)의
• 시스템 안전 측면의 소프트웨어
• 밸리데이션 계획
EUC동작의 중요한 모드
1. 설정(setting) 및 조정(adjustment)를 포함한
사용을 위한 준비;
2. 시작(start up), 교육(teach), 자동(automatic),
수동(manual), 반 자동(semi-automatic), 정상 상
태 운전(steady state operation);
3. 재 설정(re-setting), 종료(shut down), 유지보
수(maintenance);
4. 합리적으로 예측 가능한 비정상 상태 및 합리
적으로 예측 가능한 운영자의 잘못된 사용
(misuse)
a. 각각의 순서(sequences) 및 값(values)을 포함
한 필요한 입력 신호
b. 각각의 순서(sequences) 및 값(values)을 포함
한 예상 출력 신호; 그리고
c. 다른 판정 기준, 예를 들어, 메모리 사용
(memory usage), 타이밍(timing), 값 허용 오차
(value tolerances)

Validation plan for software aspects of system safety
Title 10.2 시스템 안전의 SW 측면에 대한 검증 계획
Objectives 시스템 안전의 SW 측면을 검증하기 위한 계획을 개발하기 위해
Inputs
[WP02] SW 안전 요구 사항 명세서
Outputs
[WP03] 시스템 안전의 SW 측면에 대한 검증 계획서
소프트웨어
E/E/PES
소프트웨어 안전
밸리데이션 계획
호환성 확인 호환성 확인

 목적
• 시스템 안전에 대한 안전과 관련된 소프트웨어 측면의 validation 계획을 개발
 요구사항(7.3.2.1~7.3.2.2)
1. 계획은 절차와 기술 모두의 단계를 지정하기 위해 수행되어야 한다. 즉, 계획은 소프트
웨어가 안전 요구사항을 충족함을 입증하기 위해 사용됨.

 요구사항(계속)
2. 시스템 안전의 소프트웨어 측면에 대한 검증 계획은 다음 사항을 고려(계속)
시스템 안전의 소프트웨어 측면에 대한 검증 계획 시 고려사항
1. validation을 수행해야 하는 시점에 대한 세부사항;
2. validation을 수행해야 하는 사람에 대한 세부사항
3. EUC 동작의 중요한 모드에 대한 식별(reference to next slide)
4. 시운전을 시작하기 전에 EUC 작업의 각 모드에 대해 validation이 필요한 안전 관련
소프트웨어의 식별;
5. validation에 대한 기술적 전략(예를 들어, 분석 방법(analytical methods), 통계 시험
(statistical tests) 등);
6. 다섯 번째 항목(5)에 따라, 각 안전 기능이 안전 기능을 위해 규정된 요구사항과 소프
트웨어의 시스템적 능력에 대해 규정된 요구사항을 준수하는지 확인하기 위해 사용되
어야 하는 수단(기술) 및 절차
7. validation 활동이 발생한 요구된 환경(예를 들어, 시험을 위해 교정된 도구
(calibrated tool)와 장비를 포함할 수 있다.);
8. pass/fail 기준;
9. validation의 결과(특히 실패에 대하여)를 평가하기 위한 정책 및 절차

2. 시스템 안전의 소프트웨어 측면에 대한 검증 계획은 다음 사항을 고려(계속)
시스템 안전의 소프트웨어 측면에 대한 검증 계획 시 고려사항
1. validation을 수행해야 하는 시점에 대한 세부사항;
2. validation을 수행해야 하는 사람에 대한 세부사항
3. EUC 동작의 중요한 모드에 대한 식별
EUC동작의 중요한 모드
1. 설정(setting) 및 조정(adjustment)를 포함한 사용을 위한 준비;
2. 시작(start up), 교육(teach), 자동(automatic), 수동(manual), 반 자동(semi-automatic),
정상 상태 운전(steady state operation);
3. 재 설정(re-setting), 종료(shut down), 유지보수(maintenance);
4. 합리적으로 예측 가능한 비정상 상태 및 합리적으로 예측 가능한 운영자의 잘못된
사용(misuse)

3. validation은 선택한 전략에 대한 근거를 제공해야 한다. :
안전 관련 소프트웨어의 validation을 위한 기술적 전략에서 포함되어야 할 정보
1. 수동 또는 자동 기술의 선택 또는 모두;
2. 정적 또는 동적 기술의 선택 또는 모두;
3. 분석 또는 통계 기술의 선택 또는 모두;
4. 객관적 요인에 따른 허용 기준 또는 전문가의 판단 또는 모두;
Table A.7 – Software aspects of system safety validation
1 Probabilistic testing C.5.1 --- R R HR
2 Process simulation C.5.18 R R HR HR
3 Modelling Table B.5 R R HR HR
4 Functional and black-box testing B.5.1
B.5.2
Table B.3
HR HR HR HR
5 Forward traceability between the software safety
requirements specification and the software safety
validation plan
C.2.11 R R HR HR
6 Backward traceability between the software safety
validation plan and the software safety requirements
specification
C.2.11 R R HR HR

4. 안전 관련 소프트웨어 측면의 validation을 위한 절차의 부분으로, 안전 무결성 수준에 따
라 필요한 경우(IEC 61508-1의 8항 참조), 시스템 안전의 소프트웨어 측면을 위한
validation 계획의 범위 및 내용은 평가자 또는 평가팀과의 의견이 일치해야 한다.
이 절차는 테스트 도중 평가자의 참석에 대한 내용을 또한 작성해야 한다.
5. 소프트웨어 validation을 달성하기 위한 pass/fail 기준은 다음을 포함해야 한다 :
a. 각각의 순서(sequences) 및 값(values)을 포함한 필요한 입력 신호
b. 각각의 순서(sequences) 및 값(values)을 포함한 예상 출력 신호; 그리고
c. 다른 판정 기준, 예를 들어, 메모리 사용(memory usage), 타이밍(timing), 값 허용 오차
(value tolerances)
Sequence Inputs Outputs Pass/Fail Criteria
1 I_var1 = 3
I_var2 = 5
O_var1 = 10
O_var2 = 20
Tolerance 10%
2 I_var1 = 3
I_var2 = 4
O_var1 = X
O_var2 = 30
Timing constraint = in 100ms
Tolerance 5%
… … … …
Sequence Inputs Outputs Pass/Fail Criteria
1 I_var1 = 3
I_var2 = 5
O_var1 = 10
O_var2 = 20
Tolerance 10%
2 I_var1 = 3
I_var2 = 4
O_var1 = X
O_var2 = 30
Timing constraint = in 100ms
Tolerance 5%
… … … …
A set of test suites

7.4 Software design and development

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Software design and development
 목적
• 요구된 안전 무결성 수준에 대하여 안전 관련 소프트웨어를 위한 특정 요구사항을 충족
하는 소프트웨어 아키텍처를 생성하는 것
• 제어중인 장비의 안전을 위한 E/E/PE 하드웨어/소프트웨어 상호작용의 중요성을 포함하
여, E/E/PE 안전 관련 시스템의 하드웨어 아키텍처에 의해 소프트웨어에 할당된 요구사
항을 평가하는 것
• 언어 및 컴파일러를 포함하여, verification, validation, 평가 및 수정을 지원하는 소프트웨
어의 전반적인 안전 라이프 사이클의 요구된 안전 무결성 수준을 위한 런타임 시스템 인
터페이스, 유저 인터페이스 그리고 포맷 및 표현에 대한 도구의 적절한 세트 선택을 하는
것
• 분석 가능하고 확인 가능하며, 안전하게 변경될 수 있도록 요구된 안전 무결성 수준에 대
하여 안전 관련 소프트웨어를 위한 특정 요구사항을 수행하는 소프트웨어를 설계하고 구
현하는 것
• 안전 관련 소프트웨어(요구된 소프트웨어 안전 기능 및 소프트웨어 시스템적 기능의 측
면에서)에 대한 요구사항이 달성되었는지 확인하는 것
• 데이터에 의한 PE 시스템의 설정이 소프트웨어 시스템적 기능에 대한 특정 요구사항을
충족하는지 보장하는 것
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)소프트웨어 설계 일반 (7.4.2)

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)
소프트웨어 설계 일반 (7.4.2)

 일반적인 요구사항(7.4.2.1~7.4.2.2)
1. 소프트웨어 개발 특성에 따라, 소프트웨어 설계 및 개발의 책임은 다음의 둘 중 하나이
다.
 안전 관련 프로그래밍 환경을 공급하는 업체(예, PLC 공급 업체) 혼자의 책임
 공급업체 및 개발업체 둘 다의 책임
2. 안전 기능에 대해 요구된 안전 무결성 수준과 특정 기술 요구사항에 따라, 선택된 설계
방법은 설계 특성이 있어야 함.
3. 안전한 수정을 위한 테스트 용이성 및 능력은 최종 안전 관련 시스템에서 이러한 속성들
의 구현을 용이하게 하기 위해 설계 활동에서 고려되어야 한다.
4. 선택된 설계 방법은 소프트웨어 수정을 사용할 수 있게 하는 기능을 포함해야 한다. 이러
한 기능은 모듈화, 정보 은닉 및 캡슐화를 포함한다.(F.7을 참조)
5. 설계 표현(design representations)은 명확하게 정의된 기능을 명확하게 정의하거나 제한
하는 표기법(notation)을 기준으로 해야 한다.
6. 설계가 실행 가능할 때까지 소프트웨어의 안전 관련 부분을 단순하게 유지해야 한다.

 일반적인 요구사항(7.4.2.2)
2. 안전 기능에 대해 요구된 안전 무결성 수준과 특정 기술 요구사항에 따라, 선택된 설계
방법은 설계 특징이 있어야 함.
선택한 설계방법의 특징
1 복잡성을 제어하는 추상화(abstraction), 모듈화(modularity) 및 다른 특징들
2 다음의 표현이 존재해야 함
a. 기능
b. 엘리먼트 간의 정보 흐름(data flow)
c. 시퀀스 및 시간 관련 정보
d. 타이밍 제약 사항
e. 동시성(concurrency) 및 공유 자원 액세스 동기화;
f. 데이터 구조 및 그 속성;
g. 설계 가정 및 종속성;
h. 예외 처리;
i. 설계 가정(사전 조건, 사후 조건, 고정 조건)
j. 주석(comments)
3 구조적(structural) 및 행동적(behavioural) 뷰를 포함하여 설계의 다양한 뷰를 나타내는 능력
4 설계를 이해해야 하는 개발자 및 다른 사람들의 이해;
5 verification과 validation

 일반적인 요구사항
3. 소프트웨어 설계는 요구된 안전 무결성 수준에 어울리는 제어 흐름 및 데이터 흐름의 자
체 모니터링을 포함해야 한다. 고장 감지에 대해, 적절한 조치가 취해져야 한다.
4. 소프트웨어가 안전과 비 안전 기능을 모두 구현하는 경우, 비 안전 기능의 고장이 안전
기능에 악영향을 주지 못한다는 것을 적절한 설계 방법이 보장할 수 없다면, 모든 소프트웨
어는 안전 관련(safety-related)으로 간주한다.
안전 관련
SW
안전 관련
되지 않은
SW
impact
안전과 관련되지 않은 SW라 할지라도
안전과 관련된 SW에게 영향을 미치므
로 안전과 관련된 SW로 간주한다.
어떤 control flow를 모니터링 하지?
어떤 data flow를 모니터링 하지?
선정 기준?
구현 전략?

5. 소프트웨어가 서로 다른 안전 무결성 수준의 안전 기능의 구현을 하는 경우, 설계에서 서
로 다른 안전 무결성 수준이 할당된 안전 기능들 사이의 적절한 독립성이 보여질 수 없다면,
모든 소프트웨어는 가장 높은 안전 무결성 수준에 속하는 것으로 간주되어야 한다.
다음 중 하나를 증명해야 한다.
– (1) 공간과 시간 영역 모두에서 독립성이 달성됨, 또는
– (2) 독립성의 모든 위반이 통제됨.
독립성을 위한 정당화(justification)은 문서화되어야 한다.(Annex F를 참조)
SIL 1 SIL 2 SIL 1 SIL 2vs
SIL 1
SIL 1
SIL 1등급으로 개발해도 됨
SIL 2등급으로 개발해야 함
분할(partitioning)설계 적용

6. 소프트웨어 엘리먼트의 시스템적 성능이 소프트웨어 엘리먼트가 지원하는 안전 기능의
안전 무결성 수준보다 낮은 경우, 엘리먼트는 안전 기능의 안전 무결성 수준과 동일하도록
시스템적 성능과 같은 다른 엘리먼트의 조합(combination)과 함께 사용되어야 한다.
7. 안전 기능이 시스템적 성능(capability)이 알려진 소프트웨어 엘리먼트의 조합을 사용하
여 구현되는 경우, IEC 61508-2의 7.4.3의 시스템적 성능 요구사항이 엘리먼트의 조합에 적
용되어야 한다.
소프트웨어의 방법으로 SIL등급을 targeting
하기가 어렵다면 additional methods가
system level에서 고려되어야 할 필요가 있다.

8. 기존의 소프트웨어 엘리먼트가 안전 기능의 전체 또는 일부를 구현하기 위해 재사용되는
경우, 엘리먼트는 시스템적 안전 무결성을 위해 아래 a)와 b)의 두 가지 요구사항을 모두 만
족해야 한다.
a. 다음의 준수 경로(compliance routes) 중 하나의 요구사항을 충족해야 한다:
– 경로 1s : 규격을 따르는 개발. 소프트웨어의 시스템적 결함 회피 및 제어에 대해 본 표준
의 요구 사항을 따른다.
– 경로 2s : 사용 입증(proven in use). 엘리먼트를 사용하여 입증된 증거(evidence)를 제공
한다. IEC 61508-2의 7.4.10을 참조하라.
– 경로 3s : 준수하지 않는 개발(non-compliant development)에 대한 평가(assessment).
7.4.2.13을 따른다.
b. 이미 존재하는 소프트웨어 엘리먼트에 전적 또는 부분적으로 의존하는 특정 안전 기능의
무결성 평가를 가능하게 하기 위해 엘리먼트에 대해 충분히 정확하고 완전한 설명을 제공
하는 안전 매뉴얼(IEC 61508-2의 Annex D와 본 표준의 Annex D를 참조하라)을 제공하라.

 일반적인 요구사항 <in depth>
9. 기존의 소프트웨어 엘리먼트가 안전 기능의 전체 또는 일부를 구현하기 위해 재사용되는
경우……
a. 다음의 준수 경로(compliance routes) 중 하나의 요구사항을 충족해야 한다:
– 경로 3s : 준수하지 않는 개발(non-compliant development)에 대한 평가(assessment).
7.4.2.13을 따른다.
10. 경로 3s를 준수하기 위해, 이미 존재하는 소프트웨어 엘리먼트는 다음의 a) 부터 i)까지
의 요구사항을 모두 만족해야 한다.
간단하게 표현해서, 안전 관점에서 기존 엘리먼트가 문제가 없다는
증거가 제시되어야 함.
a ~ i 까지의 항목은 그 증거를 제시하는 contents를 나타냄
경로 3s는 기존 소프트웨어 엘리먼트가 functional safety
기반으로 개발되었다면 고려해 볼 수 있는 방법이다.
과거에 개발된 소프트웨어 엘리먼트가 functional safety
기반으로 개발되지 않았다면 사용할 수 없음을 의미함. 즉,
다시 개발해야 한다는 것을 의미함.

이미 존재하는 소프트웨어 엘리먼트의 안전성 평가 항목 <in depth>
a) 안전 요구사항 명세는 본 표준에서 요구하는 바와 같이 동일한 상세 수준으로 문서화 되어야 함.
소프트웨어 안전 요구사항 명세는 새로운 애플리케이션에 엘리먼트를 적용함에 따라 기능적이고 안전한 동작을 커버해야 한다.
참조: 표 A.1
b) 바람직한 안전 속성이 고려되었음에 대한 증거를 제공
c) 엘리먼트의 설계는 정밀한 수준에서 요구사항 명세와 요구된 시스템적 능력의 준수에 대한 증거를 제공하
기에 충분하게 문서화
d) 소프트웨어의 하드웨어와의 통합에 대한 증거
e) 엘리먼트 설계 및 코드의 모든 부분에 대해 문서화된 테스트와 리뷰를 포함한 체계적 접근법을 사용하여
엘리먼트가 verification과 validation을 받고 있다는 증거
f) 소프트웨어 엘리먼트가 안전 관련 시스템에서 요구되지 않는 기능을 제공하는 경우, 원치 않는 기능이 이
것의 안전 요구사항을 만족시키는 것으로부터 E/E/PE 시스템을 방해하지 못한다는 증거
g) 소프트웨어 엘리먼트의 모든 믿을 수 있는 고장 메커니즘이 식별되고, 적절한 완화 수단이 수행되었다는
증거
h) 엘리먼트 사용을 위한 계획은, 소프트웨어와 하드웨어 런타임 환경 그리고 필요한 경우 컴파일/linking 시스
템의 설정과 같은 소프트웨어 엘리먼트의 설정을 식별
i) 엘리먼트 사용의 타당한 이유에 대한 안전 매뉴얼 제공

이미 존재하는 소프트웨어 엘리먼트의 안전성 평가 항목(계속) <in depth>
f) 소프트웨어 엘리먼트가 안전 관련 시스템에서 요구되지 않는 기능을 제공하는 경우, 원치 않는 기능이 이
것의 안전 요구사항을 만족시키는 것으로부터 E/E/PE 시스템을 방해하지 못한다는 증거
증거
h) 엘리먼트 사용을 위한 계획은, 소프트웨어와 하드웨어 런타임 환경 그리고 필요한 경우 컴파일/linking 시
스템의 설정과 같은 소프트웨어 엘리먼트의 설정을 식별
이 요구사항을 충족시킬 수 있는 방법
1) 빌드에서 기능을 제거함
2) 기능 비활성화
3) 적절한 시스템 아키텍처 (예. 파티셔닝, wrappers, diversity, checking the
credibility of outputs);
4) 광범위한 테스팅;

이미 존재하는 소프트웨어 엘리먼트의 안전성 평가 항목 <in depth>
증거
h) 엘리먼트 사용을 위한 계획은, 소프트웨어와 하드웨어 런타임 환경 그리고 필요한 경우 컴파일/linking 시스
템의 설정과 같은 소프트웨어 엘리먼트의 설정을 식별
적절한 완화 수단
적절한 시스템 아키텍처 (예. 파티셔닝, wrappers, diversity, checking the
credibility of outputs);
예외 처리

11. (만약 가능하다면), 데이터와 데이터 생성 언어를 적용해야 한다.
a. PE 시스템이 특정 애플리케이션 요구사항을 만족하기 위해 데이터에 의해 설정되는 이미
존재하는 기능을 구성하는 경우, 애플리케이션 소프트웨어의 설계는 애플리케이션 설정의
수준, 이미 인도되어 존재하는 PE 안전 관련 시스템의 기능 및 복잡성에 상응해야 한다.
b. PE 시스템의 안전 관련 기능이 시스템 설정 데이터에 의해 상당히 또는 압도적으로 결정되
는 경우, 설정 데이터의 설계, 생산, 적재 그리고 수정 동안 결함 도입을 방지하기 위해서 그
리고 설정 데이터가 애플리케이션 로직을 정확하게 나타낸다는 것을 보장하기 위해서 적절
한 기술 및 수단이 사용되어야 한다.
c. 데이터 구조의 명세는 다음과 같아야 한다:
1. 애플리케이션 데이터를 포함하여, 시스템의 기능 요구사항과의 일치
2. 완전함(complete);
3. 자체 일관성(self consistent);
4. 데이터 구조가 변경 또는 손상되는 것으로부터 보호와 같은
d. 특정 애플리케이션 요구사항을 만족하기 위해 데이터에 의해 설정되는 이미 존재하는 기능
으로 구성된 PE 시스템의 경우, 설정 프로세스는 적절하게 문서화되어야 한다..

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Lifecycle model – 소프트웨어 아키텍처
• E/E/PE 시스템 HW 아키텍처 설계서
소프트웨어
아키텍처
• 소프트웨어 공급자/개발자에 의해 제안된 소프트웨어 아키텍처가
작성되고, 소프트웨어 아키텍처 설계의 설명은 상세해야 한다.
• 소프트웨어 아키텍처의 설명은 적절한 redundancy와 diversity를
포함하여 fault tolerance와 fault avoidance에 대한 설계 전략들을
포함해야 한다.
• 아키텍처 설명은 컴포넌트/하위컴포넌트로 설계를partitioning한
것에 기반해야 한다.
• 아키텍처 설계 설명은 모든 소프트웨어/하드웨어 상호작용을 결정
하고, 정상 및 고장의 경우를 포함하여 그것 들의 중요성을 평가해
야 한다.
• 아키텍처 설계 설명은 모호함이 없어야 한다.
• 아키텍처 설계 설명은 모든 데이터의 안전 무결성을 유지하는데 사
용되는 설계 특징들을 나타내야 한다.
 소프트웨어 아키텍처 설계의
파티셔닝 된 각 엘리먼트/하위 시스템에 대해 필요한 정보:
1. 엘리먼트/하위 시스템이 이전에 검증(verification)되었는지,
만약 검증되었다면, 그것들의 검증 조건들;
2. 각 하위 시스템/엘리먼트의 안전 관련(safety-related) 여부
3. 하위 시스템/엘리먼트의 소프트웨어 시스템적 능력

Title 10.3 소프트웨어 설계 및 개발
Objectives
아키텍처 :
1) 필요한 안전 무결성 수준(SIL)에 대해 안전 관련 SW의 특정 요구 사항을 충족하는 SW 아키텍처를
만들기 위해서,
2) 제어하의 장치 안전을 위한 E/E/PE HW/SW의 상호작용의 중요성을 포함하여 E/E/PE 안전 관련
시스템의 HW 아키텍처에 의해 SW에 배치된 요구 사항을 평가하기 위해
Inputs [WP02] SW 안전 요구 사항 명세서
[WP04] E/E/PE 시스템 HW 아키텍처 설계서 (IEC 61508-2에서)
Outputs
[WP06] SW 아키텍처 통합 테스트 명세서
[WP07] SW/PE 통합 명세서(IEC 61508-2에서도 역시 요구됨)

 소프트웨어 아키텍처 설계의 요구사항
소프트웨어 아키텍처는 소프트웨어의 주요 엘리먼트 및 하위 시스템이 어떻게 상호 연결되
고, 어떻게 속성(특히 안전 무결성)이 획득되는지에 대하여 정의한다.
이는 또한 어떻게 소프트웨어 엘리먼트들이 인터페이스 되고 상호작용 하는지 정의하고 소
프트웨어 전반적인 동작을 정의한다.
주요 소프트웨어 엘리먼트의 예는 운영 체제, 시스템, 데이터 베이스, EUC 입력/출력 하위
시스템, 통신 하위 시스템, 애플리케이션 프로그램, 프로그래밍 및 진단 도구, 등을 포함한
다.

 소프트웨어 아키텍처 설계의 요구사항
1. 소프트웨어 개발의 특성에 따라, 소프트웨어 아키텍처 설계의 준수에 대한 책임은 여러
단체(multiple parties)에게 나눠 질 수 있다. 책임의 분할은 안전 계획 동안 문서화되어
야 한다. (IEC 61508-1의 6절 참조).
2. 소프트웨어 아키텍처 설계는 소프트웨어 공급 업체 그리고/또는 개발자에 의해 작성되
고, 상세화 되어야 한다.
3. 아키텍처 설계를 적용한 이후 E/E/PE 시스템 안전 요구사항 명세(7.2.2 참조)에 대한 모
든 변화는 E/E/PE 개발자에 의해 동의를 얻어야 하며, 문서화되어야 한다.
불가피하게 하드웨어와 소프트웨어 아키텍처 사이의 반복이 있을 것이며, 따라서, 프로
그램 가능한 전자(PE) 하드웨어와 소프트웨어의 통합을 위한 테스트 명세와 같은 이슈
에 대해 하드웨어 개발자와의 논의가 필요하다. (7.5 참조)

소프트웨어 설계시 고려사항
a. 요구된 안전 무결성 수준에서 소프트웨어 안전 요구사항 명세를 만족시키기 위해 소프트웨어 생명 주
기 단계 동안 필요한 기술 및 수단의 통합된 세트를 선택하고 정당화 해야 한다. 이러한 기술 및 수단은
(적절한 경우) 중복 구현(redundancy) 및 다양화(diversity)를 포함하여, fault tolerance와 fault avoidance
를 둘다 소프트웨어 설계 전략을 포함한다;
b. 엘리먼트/하위 시스템에 파티셔닝을 기반으로 해야 한다. (reference to next slide)
c. 모든 소프트웨어/하드웨어 상호작용은 결정되어야 하며, 그것들의 특징들은 평가되고 상세화 되어야
한다.
d. 명확하게 정의된 특징에 대해 명확하게 정의되거나 제한된 아키텍처를 나타내는 표기법을 사용한다.
e. 안전 무결성을 유지하기 위해 사용된 설계 특징을 선택한다. 이러한 데이터는 플랜트 입력-출력 데이
터, 통신 데이터, 운영자 인터페이스 데이터, 유지보수 데이터, 내부 데이터 베이스 데이터를 포함할 수
있다.
f. 요구된 안전 무결성 수준에서 소프트웨어 아키텍처가 소프트웨어 안전 요구사항 명세를 만족하는지
보장하기 위해 적절한 소프트웨어 아키텍처 통합 테스트를 기술한다.

소프트웨어 설계시 고려사항
a. 요구된 안전 무결성 수준에서 소프트웨어 안전 요구사항 명세를 만족시키기 위해 소프트웨어 생명 주
기 단계 동안 필요한 기술 및 수단의 통합된 세트를 선택하고 정당화 해야 한다. 이러한 기술 및 수단은
(적절한 경우) 중복 구현(redundancy) 및 다양화(diversity)를 포함하여, fault tolerance와 fault avoidance
를 둘다 소프트웨어 설계 전략을 포함한다;
b. 엘리먼트/하위 시스템에 파티셔닝을 기반으로 해야 한다.
c. 모든 소프트웨어/하드웨어 상호작용은 결정되어야 하며, 그것들의 특징들은 평가되고 상세화 되어야
한다.
d. 명확하게 정의된 특징에 대해 명확하게 정의되거나 제한된 아키텍처를 나타내는 표기법을 사용한다.
e. 안전 무결성을 유지하기 위해 사용된 설계 특징을 선택한다. 이러한 데이터는 플랜트 입력-출력 데이
터, 통신 데이터, 운영자 인터페이스 데이터, 유지보수 데이터, 내부 데이터 베이스 데이터를 포함할 수
있다.
f. 요구된 안전 무결성 수준에서 소프트웨어 아키텍처가 소프트웨어 안전 요구사항 명세를 만족하는지
보장하기 위해 적절한 소프트웨어 아키텍처 통합 테스트를 기술한다.
SIL 1 SIL 2
분할(partitioning)설계 적용

Table A.2 – Software design and development – software architecture design
Architecture and design feature
1 Fault detection C.3.1 --- R HR HR
2 Error detecting codes C.3.2 R R R HR
3a Failure assertion programming C.3.3 R R R HR
3b Diverse monitor techniques (with independence b
etween the monitor and the monitored function in t
he same computer)
C.3.4 --- R R ----
3c Diverse monitor techniques (with separation betw
een the monitor computer and the monitored com
puter)
C.3.4 --- R R HR
3d Diverse redundancy, implementing the same soft
ware safety requirements specification
C.3.5 --- --- --- R
3e Functionally diverse redundancy, implementing dif
ferent software safety requirements specification
C.3.5 --- --- R HR
3f Backward recovery C.3.6 R R --- NR
3g Stateless software design (or limited state design)
C.2.12 --- --- R HR

4a Re-try fault recovery mechanisms C.3.7 R R --- ---
4b Graceful degradation C.3.8 R R HR HR
5 Artificial intelligence - fault correction C.3.9 --- NR NR NR
6 Dynamic reconfiguration C.3.10 --- NR NR NR
7 Modular approach Table B.9 HR HR HR HR
8 Use of trusted/verified software elements (if availa
ble)
C.2.10 R HR HR HR
requirements specification and software architectu
re
C.2.11 R R HR HR
requirements specification and software architectu
re
C.2.11 R R HR HR

11a Structured diagrammatic methods ** C.2.1 HR HR HR HR
11b Semi-formal methods ** Table B.7 R R HR HR
11c Formal design and refinement methods ** B.2.2, C.2.
4
--- R R HR
11d Automatic software generation C.4.6 R R R R
12 Computer-aided specification and design tools B.2.4 R R HR HR
13a Cyclic behavior, with guaranteed maximum cycle t
ime
C.3.11 R HR HR HR
13b Time-triggered architecture C.3.11 R HR HR HR
13c Event-driven, with guaranteed maximum response
time
C.3.11 R HR HR -
14 Static resource allocation C.2.6.3 - R HR HR
15 Static synchronization of access to shared resour
ces
C.2.6.3 - - R HR

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Objectives
지원 도구와 프로그래밍 언어 :
1) SW의 전체 안전 수명주기에 걸쳐 확인, 검증, 평가 및 수정을 지원하는 언어, 컴파일러, 런타임 시
스템 인터페이스, 사용자 인터페이스 및 필요한 안전 무결성 수준에 대한 데이터 형식과 표현 등을 포
함하여 도구의 적절한 집합을 선택하기 위해
Scope PE 시스템, 소프트웨어 시스템, 지원 도구, 프로그래밍 언어
Inputs [WP02] SW 안전 요구 사항 명세서
Outputs [WP09] 지원 도구 및 코딩 표준
[WP08] 개발 도구의 선택

 프로그래밍 언어를 포함한, 지원 도구에 대한 요구사항
1. 온라인 지원 도구 소프트웨어는 안전 관련 시스템의 소프트웨어 엘리먼트로 고려되어
야 한다.
2. 오프라인 지원 도구 소프트웨어는 소프트웨어 개발 활동의 일관된 부분으로 선택되어
야 한다.
소프트웨어의 개발을 지원하는 적절한 오프라인 도구는 개발 동안 오류를 도입하거나 탐지
하지 못하는 가능성을 줄임으로써 소프트웨어의 무결성을 증대하기 위해 사용되어야 한다.
a. 이러한 데이터는 함수 파라미터, 명령어 범위, alarm 그리고 trip levels을 포함하고, 고장시
에 요구되는 출력 상태, geographical layout.
소프트웨어 개발 lifecycle 단계에 관련된 도구의 사례
하나의 추상화 수준에서 다른 수준으로 소프트웨어 또는 설계 표현을 변환하는 변형 또는 번역 도구: 설
계 정제 도구, 컴파일러, 어셈블러, 링커, 바인더, 로더, 그리고 코드 생성 도구;
정적 코드 분석기, 테스트 커버리지 모니터, theorem proving 지원도구, 그리고 시뮬레이터와 같은
verification 및 validation 도구.
작동 상태에 있는 소프트웨어의 유지보수 및 모니터에 사용되는 진단 도구
개발 지원 시스템과 같은 인프라 도구
버전 제어 도구와 같은 설정 도구
파라미터를 결정하고 시스템 함수를 인스턴스화 하기 위해 필요한 데이터를 생산하거나 유지 보수하는
애플리케이션 데이터 도구.

3. 오프라인 지원 도구의 선택은 정당화 되어야 한다.
4 .T2와 T3 클래스에 있는 모든 오프라인 도구는 도구의 동작을 명확하게 정의한 명세 또
는 제품 문서와 이것의 사용에 대한 어떤 설명 또는 제한사항을 가지고 있어야 한다.
software off-line support tool
소프트웨어 개발 라이프사이클 단계에서 지원하고 소프트웨어의 run-time동안에 안전 관련 시스템에 직
접적으로 영향을 끼칠 수 없는 도구. 소프트웨어 오프라인 도구는 다음과 같이 분류될 수 있다:
T1 안전 관련 시스템의 실행 가능한 코드(데이터 포함)에 직/간접적으로 영향을 끼치는 출
력을 생성하지 않음;
T1 examples include: a text editor or a requirements or design support tool with no automatic code
generation capabilities; configuration control tools.
T2 설계 혹은 실행 가능한 코드의 시험이나 검증을 지원함, 도구의 오류로 소프트웨어의
결함이 드러나지 않을 수 있으나 직접적으로 실행 가능한 소프트웨어에 영향을 미치지
는 않음;
T2 examples include: a test harness generator; a test coverage measurement tool; a static analysis tool.
T3 안전 관련 시스템의 실행 가능한 코드에 직/간접적으로 영향을 끼치는 출력 결과를 생
성함
T3 examples include: an optimizing compiler where the relationship between the source code program and
the generated object code is not obvious; a compiler that incorporates an executable run-time package into
the executable code.

5. 도구의 배치에 의존하는 수준과 실행 가능한 소프트웨어에 영향을 미칠 수 있는 도구의
잠재 고장 메커니즘을 결정하기 위해 T2 그리고 T3 클래스에서 오프라인 지원 도구에 대한
평가는 수행되어야 한다. 이러한 고장 메커니즘이 확인되는 경우, 적절한 완화 조치를 취해
야 한다.
 도구에 대한 failure mode and effect analysis를 수행해야 함을 의미함
6. T3 클래스의 각 도구에 대하여, 도구가 이것의 명세 또는 문서에 준수한다는 증거가 이용
가능해야 한다. 증거는 비슷한 환경과 비슷한 애플리케이션에서의 성공적인 히스토리와 다
음의 도구 validation의 결과(7)에 명세된 도구 확인의 적절한 조합에 기반할 수 있다.

7. 도구 validation의 결과는 다음과 같은 결과를 포함하여 문서화되어야 한다.
8. 도구 validation 결과와 같은 적합성 증거를 사용할 수 없는 경우, 도구에 기인하는 결함
에서 해당 결과의 실행 가능한 안전 관련 시스템의 고장을 제어하는 효과적인 수단
(measures)이 있어야 한다.
9. 통합 도구 세트의 도구 호환성은 검증(verification)되어야 한다.
도구 validation에 의한 문서화 작업시 포함되어야 하는 내용
a. validation 활동의 기록(chronological record);
b. 사용되는 도구 제품 설명서의 버전;
c. validation된 도구 기능
d. 사용된 도구 및 장비;
e. validation 활동의 결과; 문서화된 validation의 결과는 소프트웨어가 validation을 통과 또는 실패
한 이유에 대하여 기재해야 한다.
f. 후속 분석을 위한 테스트 케이스 및 그 결과
g. 예상 결과와 실제 결과의 불일치(discrepancies)

10. 안전 무결성 수준에 의해 요구된 범위에서, 소프트웨어 또는 설계 표현(프로그래밍 언
어를 포함하여)은 다음을 선택해야 한다:
a. 적절하게 국제 또는 국가 표준에 대하여 목적에 대한 적합성이 평가된 번역기;
b. 정의된 언어 특징에 대해서만 사용;
c. 애플리케이션의 특징과 일치;
d. 설계 또는 프로그래밍 실수들의 탐지를 용이하게 하는 특징 포함;
e. 설계 방법과 일치하는 특징 지원;
11. 위의 조건(10)을 완벽하게 만족할 수 없는 경우, 언어의 식별된 단점의 모든 추가적인
수단 언어의 목적에 대한 적합성은 정당화 되어야 한다.
12. 모든 안전 관련 소프트웨어의 프로그래밍 언어는 적절한 프로그래밍 언어 코딩 표준에
따라 사용되어야 한다.

Table B.1 – Design and coding standards
(Referenced by Table A.4)
1 Use of coding standard to reduce likelihood of erro
rs
C.2.6.2 HR HR HR HR
2 No dynamic objects C.2.6.3 R HR HR HR
3a No dynamic variables C.2.6.3 --- R HR HR
3b Online checking of the installation of dynamic varia
bles
C.2.6.4 --- R HR HR
4 Limited use of interrupts C.2.6.5 R R HR HR
5 Limited use of pointers C.2.6.6 --- R HR HR
6 Limited use of recursion C.2.6.7 --- R HR HR
7 No unstructured control flow in programs in higher
level languages
C.2.6.2 R HR HR HR
8 No automatic type conversion C.2.6.2 R HR HR HR
* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent technique
s/measures are indicated by a letter following the number. It is intended the only one of the alternate or equivalent technique
s/measures should be satisfied. The choice of alternative technique should be justified in accordance with the properties, giv
en in Annex C, desirable in the particular application.

13. 프로그래밍 언어 코딩 표준은 좋은 프로그래밍 사례, 안전하지 않은 언어 기능 금지, 코
드의 이해도를 증진, verification 및 테스트 용이성 그리고 소스 코드 문서화를 위한 절차를
포함해야 한다. 실제의 경우, 다음의 정보는 소스 코드에 포함되어야 한다.
a. 법적 실체(legal entity) (예를 들어, 회사, 저자, 등);
b. 설명;
c. 입력 및 출력;
d. 형상 관리 이력;
14. 자동 코드 생성 또는 유사한 자동 번역이 발생하는 경우, 안전 관련 시스템 개발을 위한
자동 번역의 적합성은 개발 지원 도구가 선택된 개발 lifecycle의 시점에 평가되어야 한다.
15. T2 및 T3 클래스의 오프라인 지원 도구가 configuration baseline의 항목을 생성하는 경
우, 형상 관리는 도구에 대한 정보가 기록되었는지 확인해야 한다. 이는 특히 다음을 포함한
다:
a. 도구 및 그 버전의 식별;
b. 도구 버전이 사용되고 있는 configuration baseline items의 식별;
c. 각 configuration baseline items에 대하여 도구가 사용된 방법(도구 파라미터, 선택된 옵션
및 스크립트를 포함하여)

16. T2 및 T3 클래스의 툴에 대해, 형상관리는 자격을 갖춘 버전(qualified version)이 사용되
는 것을 보장한다.
17. 형상 관리는 안전 관련 시스템과 상호 호환되는 도구의 사용을 보장해야 한다.
18. 오프라인 지원 도구의 각 새로운 버전은 qualified 되어야 한다. 충분한 증거가 다음과
같다면, 이 자격은 초기 버전을 위하여 제공된 증거에 의존 할 수 있다.
a. (있는 경우) 기능 차이가 도구 세트의 나머지 부분과의 도구 호환성에 영향을 미치지 않음;
그리고
b. 새로운 버전이 알 수 없는 결함과 같은 중요한 새로운 사항을 포함하지 않음;
(비고) 새로운 버전이 알 수 없는 결함과 같은 새로운 사항을 포함하지 않음은 다음에 의거
한다.
1. 변경 발생의 명확한 식별
2. 새로운 버전에 대해 수행된 확인 및 검증 활동의 분석
3. 새 버전과 관련된 다른 사용자의 기존 운영 경험.
19. 소프트웨어 개발 특성에 따라, 7.4.4(프로그래밍 언어를 포함한, 지원 도구에 대한 요구
사항)의 준수는 나머지 다양한 조직의 책임 일 수 있다. 책임의 분할은 안전 계획 동안 문서
화 되어야 한다 (IEC 61508-1의 6절(Management of functional safety) 참조)

Table A.3 – Software design and development – support tools and programming language
1 Suitable programming language C.4.5 HR HR HR HR
2 Strongly typed programming language C.4.1 HR HR HR HR
3 Language subset C.4.2 --- --- HR HR
4a Certified tools and certified translators C.4.3 R HR HR HR
4b Tools and translators: increased confidence from u
se
C.4.4 HR HR HR HR
NOTE 2 The references (which are informative, not normative) “B.x.x.x”, “C.x.x.x” in column 3 (Ref.) indicate detailed descri
ptions of techniques/measures given in Annexes B and C of IEC 61508-7.
* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/m
easures are indicated by a letter following the number. It is intended the only one of the alternate or equivalent techniques/meas
ures should be satisfied. The choice of alternative technique should be justified in accordance with the properties, given in Annex
C, desirable in the particular application.

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Objectives
세부 설계 및 개발 (SW 시스템 설계) :
1) 분석 가능하고 검증가능하며 안전하게 수정될 수 있는 필요한 SIL의 관점에서 안전 관련 SW에 대
한 명세된 요구사항을 충족시키기 위해 SW를 설계 및 구현하기 위해
Scope 주요 요소 및 소프트웨어 아키텍처 설계의 서브 시스템
Inputs [WP05] SW 아키텍처 설계
[WP09] 지원 도구 및 코딩 표준.
Outputs [WP10] SW 시스템 설계 사양
[WP17] SW 시스템 통합 테스트 사양
상세 설계 (7.4.5) 구현 (7.4.6)

Objectives
세부 설계 및 개발 (개별 SW 모듈 설계) :
Scope 소프트웨어 시스템 설계
Inputs [WP10] SW 시스템 설계 사양
[WP09] 지원 도구 및 코딩 표준
Outputs [WP11] SW 모듈 설계 사양
상세 설계 (7.4.5) 구현 (7.4.6)

Objectives
자세한 코드 구현 :
Scope 개별 소프트웨어 모듈
Inputs [WP11] SW 모듈 설계 사양
[WP09] 지원 도구 및 코딩 표준
Outputs [WP13] 소스 코드 목록
상세 설계 (7.4.5) 구현 (7.4.6)

Reference
 ISO/IEC/IEEE 42010:2011 - System 및 software engineering을 위한
Architecture Description에 대한 표준
Architecture Description은 다음을 식별해야만 한다.
1) Concern
2) Stakeholder
3) System-of-interest
Architecture Description은 위의 식별된 내용을 바탕으로
Architecture를 표현해야 한다.
Stakeholder는 시스템의 특정 영역에 대하여 관심을 가지고
있다.
(Ex: 개발자, 유지보수자, 프로젝트 매니저, 테스터들은 아키
텍처의 stakeholder이지만 각기 시스템에 공통적으로 관심이
있을 수도 있지만, 특정 부분에만 관심이 있을 수 있다.)
상세 설계 (7.4.5) 구현 (7.4.6)

 상세 설계 및 개발에 대한 요구사항 – 소프트웨어 시스템 설계
(비고1) 소프트웨어 시스템 설계를 의미하는 상세 설계는 여기서 정의된다: 소프트웨어 모
듈 방식으로 아키텍처의 주요 엘리먼트 분할; 개별 소프트웨어 모듈 설계; 그리고 코딩. 작
은 애플리케이션에서, 소프트웨어 시스템 설계 및 아키텍처 설계는 조합될 수 있다.
(비고2) 상세 설계 및 개발의 특성은 소프트웨어 개발 활동 및 소프트웨어 아키텍처의 특성
에 따라 변할 것이다. 예를 들어 ladder logic과 function blocks와 같은 애플리케이션 프로그
램의 일부 상황에서, 상세 설계는 설정(configuring)이 아닌 프로그래밍으로 간주될 수 있다.
다음이 구조화된 방법으로 소프트웨어를 설계하는 것은 여전히 좋은 방법이다.
• 가능한 안전 관련 부품이 분리되도록 소프트웨어를 모듈형 구조로 조직화
• 데이터 입력 실수를 보호하는 범위 확인 이나 다른 매커니즘을 포함하도록 설계
• 이전에 검증되었던 소프트웨어 모듈을 사용
• 향후 소프트웨어 수정을 용이하게 하는 설계를 제공
상세 설계 (7.4.5) 구현 (7.4.6)
설계 원칙(표준)을 준수하라.

1. 소프트웨어 개발의 특성에 따라, 7.4.5항 준수에 대한 여러 당사자들에게 책임이 있을 수
있다. 책임의 구분은 (IEC 61508-1의 6 절 참조) 안전 계획 단계에서 문서화되어야 한다.
2. 상세 설계의 시작 이전에 다음의 정보가 이용 가능해야 한다
– E/E/PE 안전 관련 시스템에 대한 요구사항의 명세;
– 소프트웨어 아키텍처 설계;
– 시스템 안전 측면의 소프트웨어에 대한 validation 계획.
상세 설계 (7.4.5) 구현 (7.4.6)

3. 개발자들은 소프트웨어가 모듈성, 테스트 가능성, 그리고 안전한 수정이 가능하도록 만
들어야 한다.
4. 소프트웨어 아키텍처 설계의 각 주요 엘리먼트/하위 시스템에 대하여, 설계의 further
refinement는 소프트웨어 모듈로의 분할(partitioning)에 기초한다(예, 소프트웨어 시스템 설
계의 명세). 각 소프트웨어 모듈의 설계 및 각 소프트웨어 모듈에 적용될 verification이 명시
되어야 한다.
5. 적절한 소프트웨어 시스템 통합 테스트는 소프트웨어 시스템이 요구된 안전 무결성 수준
에서 소프트웨어 안전 요구사항 명세를 만족하는지 보장하기 위해 명시되어야 한다.
상세 설계 (7.4.5) 구현 (7.4.6)

Table A.4 – Software design and development – detailed design
1a Structured methods ** C.2.1 HR HR HR HR
1b Semi-formal methods ** Table B.7 R HR HR HR
1c Formal design and refinement methods ** B.2.2, C.2.4 --- R R HR
2 Computer-aided design tools B.3.5 R R HR HR
3 Defensive programming C.2.5 --- R HR HR
5 Design and coding standards C.2.6
Table B.1
R HR HR HR
6 Structured programming C.2.7 HR HR HR HR
7 Use of trusted/verified software elements (if availab
le)
C.2.10 R HR HR HR
8 Forward traceability between the software safety re
quirements specification and software design
C.2.11 R R HR HR
상세 설계 (7.4.5) 구현 (7.4.6)

Table B.7 – Semi-formal methods
(Referenced by Tables A.1, A.2 and A.4)
Technique/Measure * Ref SIL 1 SIL 2 SIL 3 SIL 4
1 Logic/function block diagrams See Note 1 R R HR HR
2 Sequence diagrams see Note 1 R R HR HR
3 Data flow diagrams C.2.2 R R R R
4a Finite state machines/state transition diagrams B.2.3.2 R R HR HR
4b Time Petri nets B.2.3.3 R R HR HR
5 Entity-relationship-attribute data models B.2.4.4 R R R R
6 Message sequence charts C.2.14 R R R R
7 Decision/truth tables C.6.1 R R HR HR
8 UML C.3.12 R R R R
NOTE 1 Logic/function block diagrams and sequence diagrams are described in IEC 61131-3. NOTE 2 See T
able C.17.
NOTE 3 The references “B.x.x.x”, “C.x.x.x” in column 3 (Ref.) indicate detailed descriptions
of techniques/measures given in Annexes B and C of IEC 61508-7.
상세 설계 (7.4.5) 구현 (7.4.6)

Table B.9 – Modular approach
1 Software module size limit C.2.9 HR HR HR HR
2 Software complexity control C.5.13 R R HR HR
3 Information hiding/encapsulation C.2.8 R HR HR HR
4 Parameter number limit / fixed number of subprogram
parameters
C.2.9 R R R R
5 One entry/one exit point in subroutines and functions C.2.9 HR HR HR HR
6 Fully defined interface C.2.9 HR HR HR HR
* Appropriate techniques/measures shall be selected according to the safety integrity level. No single techniqu
e is likely to be sufficient. All appropriate techniques shall be considered.
상세 설계 (7.4.5) 구현 (7.4.6)

 코드 구현에 대한 요구사항
1. 소프트웨어 코드의 각 모듈은 검토되어야 한다. 코드가 자동 도구에 의해 생성되는 경우,
Tool qualification (7.4.4)의 요구사항을 만족해야 한다. 소프트웨어를 기존의 소프트웨어로
구성하는 경우, 소프트웨어 설계 일반(7.4.2)의 요구사항을 만족해야 한다.
(비고) 코드 리뷰는 verification 활동이다( 7.9 참조).
코드 리뷰는 코드의 검사(inspection)에 의해 수행된다. 수행 방법은 다음의 세 가지가 있다
(1) 개인에 의해;
(2) 소프트웨어 walk-though에 의해(IEC61508-7 C.5.15 참조);
(3) 엄격한 공식적인 검사(formal inspection)에 의해 (IEC 61508-7 C.5.14 참조)
상세 설계 (7.4.5) 구현 (7.4.6)

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Objectives
SW 모듈 테스트 :
1) 달성되어야 하는 안전 관련 SW에 대한 요구사항을 검증하기 위해서(필요한 SW 안전 기능과 SW
의 시스템적 능력 관점에서)
2) 각각의 SW 모듈이 의도된 기능대로 동작하고 의도되지 않은 기능을 수행하지 않음을 보이기 위해
3) 적절하다면, PE시스템의 데이터에 의한 설정(configuration)이 SW의 시스템적 능력에 대한 명세된
요구사항에 부합하는지를 보이기 위해
Scope 소프트웨어 모듈
Inputs
[WP13] 소스 코드 목록
Outputs [WP15] SW 모듈 테스트 결과
[WP16] 검증되고 및 테스트 완료된 SW 모듈
단위 시험 (7.4.7)

 소프트웨어 모듈 테스트에 대한 요구사항
(비고 1) 소프트웨어 모듈이 그것의 테스트 사양을 정확하게 만족하도록 테스트하는 것은
verification 활동이다(7.9 참조). 이는 소프트웨어 모듈이 그것의 관련 규격을 만족하는지에
대한 보장을 제공하는 코드 리뷰 및 소프트웨어 모듈 테스트의 조합이다.
1. 각 소프트웨어 모듈은 소프트웨어 시스템 설계 동안 개발된 소프트웨어 모듈 테스트 명
세에 의해 검증되어야 한다. (7.4.5 참조)
2. verification은 각 소프트웨어 모듈이 그것의 의도된 기능을 수행하고 의도되지 않은 기
능을 수행하지 않는지에 대한 여부를 보여야 한다.
단위 시험 (7.4.7)

 소프트웨어 모듈 테스트에 대한 요구사항
(비고1) 이는 모든 입력의 조합의 테스트 또는 모든 출력의 조합을 의미하지는 않는다. 모
든 equivalence classes 또는 구조 기반 테스트를 테스트 하는 것은 충분할 수 있다. 경계 값
분석 또는 제어 흐름 분석은 테스트 케이스를 허용 가능한 수로 줄일 수 있다. 분석 가능한
프로그램은 요구사항을 수행하기 쉽게 만든다. 이러한 기술에 대해서는 IEC 61508-7의
Annex C를 참조하라.
3. 소프트웨어 모듈 테스트의 결과는 문서화되어야 한다.
4. 테스트를 통과하지 못한 시정 조치(corrective action)의 절차가 명시되어야 한다.
단위 시험 (7.4.7)
Boundary value
pairwise
Unit test
Robustness test
Equivalence class
Blackbox test
Whitebox test
Coverage criteria
Test에 대한 기본 개념에 대해 인지하고 있어야 함
Interface test

Table A.5 – Software design and development – software module testing and integration
1 Probabilistic testing C.5.1 --- R R R
2 Dynamic analysis and testing B.6.5
Table B.2
R HR HR HR
3 Data recording and analysis C.5.2 HR HR HR HR
4 Functional and black box testing B.5.1
B.5.2
Table B.3
HR HR HR HR
5 Performance testing Table B.6 R R HR HR
6 Model based testing C.5.27 R R HR HR
7 Interface testing C.5.3 R R HR HR
8 Test management and automation tools C.4.7 R HR HR HR
9 Forward traceability between the software design spe
cification and the module and integration test specific
ations
C.2.11 R R HR HR
10 Formal verification C.5.12 --- --- R R
단위 시험 (7.4.7)

Table B.2 – Dynamic analysis and testing
(Referenced by Tables A.5 and A.9)
1 Test case execution from boundary value analysis C.5.4 R HR HR HR
2 Test case execution from error guessing C.5.5 R R R R
3 Test case execution from error seeding C.5.6 --- R R R
4 Test case execution from model-based test case gene
ration
C.5.27 R R HR HR
5 Performance modelling C.5.20 R R R HR
6 Equivalence classes and input partition testing C.5.7 R R R HR
7a Structural test coverage (entry points) 100 % ** C.5.8 HR HR HR HR
7b Structural test coverage (statements) 100 %** C.5.8 R HR HR HR
7c Structural test coverage (branches) 100 %** C.5.8 R R HR HR
7d Structural test coverage (conditions, MC/DC) 100 %** C.5.8 R R R HR
NOTE 1 The analysis for the test cases is at the subsystem level and is based on the specification and/or th
e specification and the code.
NOTE 3 The references (which are informative, not normative) “B.x.x.x”, “C.x.x.x” in column 3 (Ref.) indic
ate detailed descriptions of techniques/measures given in Annexes B and C of IEC 61508-7.
* Appropriate techniques/measures shall be selected according to the safety integrity level.
** Where 100 % coverage cannot be achieved (e.g. statement coverage of defensive code), an app
ropriate explanation should be given.
단위 시험 (7.4.7)

Table B.3 – Functional and black-box testing
1 Test case execution from cause consequence
diagrams
B.6.6.2 --- --- R R
2 Test case execution from model-based test case
generation
C.5.27 R R HR HR
3 Prototyping/animation C.5.17 --- --- R R
4 Equivalence classes and input partition testing,
including boundary value analysis
C.5.7
C.5.4
R HR HR HR
5 Process simulation C.5.18 R R R R
NOTE 1 The analysis for the test cases is at the software system level and is based on the specification only.
NOTE 2 The completeness of the simulation will depend upon the safety integrity level, complexity and
application.
NOTE 4 The references (which are informative, not normative) “B.x.x.x”, “C.x.x.x” in column 3 (Ref.) indicat
e detailed descriptions of techniques/measures given in Annexes B and C of IEC 61508-7.
단위 시험 (7.4.7)

Table B.6 – Performance testing
(referenced by Tables A.5 and A.6)
1 Avalanche/stress testing C.5.21 R R HR HR
2 Response timings and memory constraints C.5.22 HR HR HR HR
3 Performance requirements C.5.19 HR HR HR HR
NOTE 2 The references (which are informative, not normative) “B.x.x.x”, “C.x.x.x” in column 3 (Ref.) indica
te detailed descriptions of techniques/measures given in Annexes B and C of IEC 61508-7.
단위 시험 (7.4.7)

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Objectives
SW 통합 시험 :
1) 안전 관련 SW에 대한 요구 사항 (필수 SW 안전 기능과 SW의 체계적인 기능의 측면에서) 을 만족
하는지 확인하기 위해
2) 모든 SW 모듈, 엘리먼트, 서브시스템들이 그들의 의도된 기능대로 동작하고 의도되지 않은 기능은
수행하지 않는 상호작용을 보이기 위해
3) 적절하다면, PE시스템의 데이터에 의한 설정(configuration)이 SW의 시스템적 능력에 대한 명세된
요구사항에 부합하는지를 보이기 위해
Scope 소프트웨어 아키텍처, 소프트웨어 시스템
Inputs
[WP17] SW 시스템 통합 테스트 사양
Outputs [WP18] SW 시스템 통합 테스트 결과
[WP19] 검증된 SW 시스템
통합 시험 (7.4.7)

 소프트웨어 통합 테스트에 대한 요구사항
1. 소프트웨어 통합 테스트는 설계 및 개발 단계 동안 명시되어야 한다(7.4.5 참조).
2. 소프트웨어 시스템 통합 테스트 명세는 다음을 나타내야 한다:
소프트웨어 시스템 통합 테스트 명세에서 표현되어야 하는 내용들
a. 관리 가능한 통합 세트로 소프트웨어의 분할;
b. 테스트 케이스 및 테스트 데이터;
c. 수행될 테스트의 타입;
d. 테스트 환경, 도구, 설정 및 프로그램;
e. 테스트의 완료가 판단될 테스트 판정 기준(test criteria);
f. 테스트에 실패에 대한 시정 조치(corrective action)의 절차;
통합 시험 (7.4.7)

3. 소프트웨어는 소프트웨어 시스템 통합 테스트 명세(software system integration test
specification)에 명세된 소프트웨어 통합 테스트에 따라 시험되어야 한다.
이러한 테스트는 소프트웨어 모듈과 소프트웨어 엘리먼트/하위 시스템이
a) 의도된 기능을 수행하고,
b) 의도되지 않은 기능을 수행하지 않음
에 대한 증거를 보여야 한다.
노트
a. 이는 모든 입력의 조합의 테스트 또는 모든 출력의 조합을 의미하지는 않는다.
b. 모든 equivalence classes 또는 구조 기반 테스트를 테스트 하는 것은 충분할 수 있다.
c. 경계 값 분석 또는 제어 흐름 분석은 테스트 케이스를 허용 가능한 수로 줄일 수 있다.
d. 분석 가능한 프로그램은 요구사항을 수행하기 쉽게 만든다.
e. 참고: IEC 61508-7의 Annex C
통합 시험 (7.4.7)

4. 소프트웨어 통합 테스트의 결과는 테스트 결과를 언급하고 목표와 테스트 기준이 충족되
었는지의 여부에 대하여 문서화되어야 한다. 통합 테스트에 실패가 있으면, 실패의 이유가
기록되어야 한다.
5. 소프트웨어 통합 시, 소프트웨어에 대한 모든 수정은 영향 받은 모든 소프트웨어 모듈과
필요한 재 확인(re-verification) 및 재 설계(re-design) 활동이 결정되도록 하는 영향 분석
(impact analysis)을 받아야 한다.
통합 시험 (7.4.7)

7.5 Programmable electronics integration
(hardware and software)

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Title 10.4 프로그램 전자 통합 (HW 및 SW)
Objectives
1) 대상 프로그램 가능한 전자 HW에 SW를 통합하기 위해서
2) SW와 HW를 안전관련 프로그램 가능한 전자장치에 통합하여 그들의 호환성과 안전 무결성 등급
의 의도된 요구사항에 만족함을 보이기 위해서
Scope 프로그램 전자 하드웨어, 통합 소프트웨어
Inputs
[WP06] SW 아키텍처 통합 테스트 명세서
[WP07] SW/PE 통합 명세서(IEC 61508-2에서도 역시 요구됨)
[WP20] 통합된 PE
Outputs
[WP21] SW 아키텍처 통합 테스트 결과
[WP22] PE 통합 테스트 결과
[WP23] 검증된 통합 PE

Programmable electronics integration
 목적
• 소프트웨어를 programmable electronic hardware 타깃(target)에 통합하기 위해
• 안전 관련 programmable electronic가 호환성을 보장하고 의도된 안전 무결성 수준의 요
구사항을 충족시키도록 소프트웨어와 하드웨어를 결합하기 위해
(비고) 소프트웨어가 올바르게 programmable electronic hardware에 통합되었는지 테스트
하는 것은 하드웨어 verification 활동이다(7.9 참조).
(비고) 애플리케이션의 특성에 따라, 이러한 활동은 7.4.8(SW 통합)에 조합될 수 있다.
 요구사항
1. 통합 테스트는 안전 관련 programmable electronics에서 하드웨어와 소프트웨어의 호환
성을 보장하기 위해 설계 및 개발 단계에서 명시되어야 한다(7.4.3 아키텍처 설계 참조).
2. 소프트웨어/PE 통합 테스트 사양(하드웨어 및 소프트웨어)은 다음을 나타내야 한다.
소프트웨어/PE 통합 테스트 사양(하드웨어 및 소프트웨어)에서 표현되어야 하는 내용들 - 1
a. 시스템을 통합 수준으로 나눔;
b. 테스트 케이스 및 테스트 데이터;
c. 수행될 테스트의 종류;
d. 지원 소프트웨어 및 설정 설명(configuration description)을 도구를 포함한 테스트 환경;
e. 테스트의 완료를 판단할 기준

소프트웨어/PE 통합 테스트 사양(하드웨어 및 소프트웨어)에서 표현되어야 하는 내용들 - 2
3. 개발자의 site에서 개발자에 의해 수행되는 활동과 사용자의 site에서 액세스를 필요로 하는 활동들
을 구별해야 한다.
4. 다음과 같은 활동을 구별해야 한다:
a. programmable electronic 하드웨어 타깃상의 소프트웨어 시스템의 병합(merging);
b. E/E/PE 통합, 즉, 센서와 액츄에이터와 같은 인터페이스 통합;
c. EUC에 E/E/PE 안전 관련 시스템에 적용
(비고) 항목 b)와 c)는 IEC 61508-1과 IEC 61508-2에 의해 커버되며, 문맥의 완전성을 위해 항목
a)가 여기에 포함된다. 그것들은 일반적으로 소프트웨어 개발자의 책임이 아니다.
5. 소프트웨어는 소프트웨어/PE 통합 테스트 명세(하드웨어 및 소프트웨어)에 따라 안전 관련
programmable electronic 하드웨어와 통합되어야 한다.
6. 안전 관련 programmable electronics하드웨의 통합 테스트 동안(하드웨어 및 소프트웨어), 통합된
시스템에 모든 변화는 영향 분석(impact analysis)에 따라야 한다. 영향 분석은 모든 영향을 받은 소프
트웨어 모듈과 재 확인(re-verification) 활동이 필요한 소프트웨어 모듈을 결정해야 한다.
7. 테스트 케이스 및 그것들의 예상된 결과는 이후 분석을 위해 문서화되어야 한다.

 요구사항
8. 안전 관련 programmable electronics의 통합 테스트(하드웨어 및 소프트웨어)는 테스트
결과와 목적 및 테스트 기준이 충족되었는지의 여부를 언급하여 문서화되어야 한다. 고장
이 있는 경우, 고장의 원인이 문서화되어야 한다.
소프트웨어에 대한 수정 또는 변화의 모든 결과는, 영향을 받은 모든 소프트웨어 엘리먼트/
모듈과 필요한 재 설계 활동을 결정해야 하는 영향 분석에 따라야 한다.

Table A.6 – Programmable electronics integration (hardware and software)
B.5.2
Table B.3
HR HR HR HR
3 Forward traceability between the system and
software design requirements for hardware/softwar
e integration and the hardware/software integration
test specifications
C.2.11 R R HR HR
NOTE 1 Programmable electronics integration is a verification activity (see Table A.9). NOTE 2 See Table C.
6.

7.6 Software operation and
modification procedures

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Title 10.5 SW 운영 및 변경 절차
Objectives
1) E/E/PE 안전 관련 시스템의 기능 안전이 운영 및 수정중에 유지되는 것을 보이기 위해 필요한 SW
와 관련된 정보 및 절차를 제공하기 위해
Scope
Inputs 관련된 것들
Outputs
[WP24] SW 운영 및 변경 절차

Software operation and modification procedures
 목적
• E/E/PE 안전 관련 시스템의 기능 안전이 작동 및 수정 동안 유지 보수된다는 것을 보장하
기 위해 필요한 소프트웨어와 관련된 정보와 절차를 제공하는 것
 요구사항
• 요구사항은 IEC 61508-2의 7.6 및 본 표준의 7.8에 나와 있다.

Table A.8 – Modification
1 Impact analysis C.5.23 HR HR HR HR
2 Re-verify changed software module C.5.23 HR HR HR HR
3 Re-verify affected software modules C.5.23 R HR HR HR
4a Re-validate complete system Table A.7 --- R HR HR
4b Regression validation C.5.25 R HR HR HR
5 Software configuration management C.5.24 HR HR HR HR
7 Forward traceability between the Software safety
requirements specification and the software
modification plan (including re-verification and
re-validation)
C.2.11 R R HR HR
8 Backward traceability between the software modific
ation plan (including re-verification and
re-validation) and the software safety requirements
specification
C.2.11 R R HR HR

7.7 Software aspects of system safety
validation

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

Title 10.6 시스템 안전 검증 SW 측면
Objectives
1) 통합된 시스템이 요구된 안전 무결성 수준에서 소프트웨어 안전 요구사항 명세를 준수하는지 보장
하는 것
Scope
Inputs [WP25] 시스템 안전의 SW 측면에 대한 검증 계획
Outputs [WP26] SW 안전 검증 결과
[WP27] 검증 SW

Software aspects of system safety validation
 목적
• 통합된 시스템이 요구된 안전 무결성 수준에서 소프트웨어 안전 요구사항 명세를 준수하
는지 보장하는 것
 요구사항
1. 안전 관련 소프트웨어 요구사항에 대한 준수가 E/E/PE 안전 관련 시스템의 안전
validation 계획에 이미 설정된 경우(IEC 61508-2의 7.7 참조), validation은 반복될 필요가
없다.
2. validation 활동은 시스템 안전의 소프트웨어 측면에 대하여 validation 계획에 명시된 대
로 수행되어야 한다.
3. 소프트웨어 개발 특성에 따라, 7.7절 준수에 대한 책임은 여러 당사자들에게 있을 수 있
다. 책임의 구분은 (IEC 61508-1의 6 절 참조) 안전 계획 단계에서 문서화되어야 한다.
4. 시스템 안전의 소프트웨어 측면에 대한 validation 결과는 문서화 되어야 한다.

 요구사항
5. 각 안전 기능의 경우, 소프트웨어 안전 validation은 다음의 결과를 문서화 해야 한다.
6. 예상 결과와 실제 결과 사이의 불일치가 발생할 때, validation을 계속 할지 또는 변경 요청
을 발행하고 개발 라이프사이클의 이전 단계로 돌아갈지에 대하여 작성된 분석과 선택된 결
정은 시스템 안전의 소프트웨어 측면에 대한 validation 결과의 부분으로 문서화 되어야 한다.
소프트웨어 안전 validation에 대한 내용
a. 되돌아오는 활동(activities to be retrace)의 시퀀스를 허용하는 validation활동의 시간 순의 기록;
(비고) 테스트 결과를 기록할 때, 활동의 시퀀스를 되돌아 올 수 있는 것은 중요하다. 이 요구사
항은 문서의 시간/날짜 리스트를 생성할 때가 아니라 활동의 시퀀스를 되돌아 올 때 강조된다.
b. 시스템 안전의 소프트웨어 측면(7.3 참조)에 대한 사용된 validation 계획의 버전
c. 시스템 안전의 소프트웨어 측면의 validation 계획에 대한 참조(reference)와 함께, validation된
안전 기능(테스트 또는 분석에 의하여);
d. calibration 데이터와 함께 사용된 도구 및 장비;
e. validation 활동의 결과;
f. 예상 결과와 실제 결과 사이의 차이(discrepancies);

 요구사항
7. 시스템 안전의 안전 관련 소프트웨어 측면의 validation은 다음의 요구사항을 만족해야
한다.
a. 테스트가 소프트웨어의 주요한 validation 방법이 되어야 한다; 분석, 애니메이션 및 모델링
은 validation 활동을 보충하기 위해 사용될 수 있다.
b. 소프트웨어는 다음의 시뮬레이션에 의해 시험되어야 한다:
1) 정상 작동 시 현재 입력 신호;
2) 예측된 발생;
3) 시스템 동작의 바람직하지 않은 조건
c. 공급 업체 그리고/또는 개발자(또는 준수에 책임이 있는 다양한 당사자)는 시스템 개발자의
제품이 IEC 61508-1과 IEC 61508-2의 요구사항을 충족시키기 위해, 시스템 안전의 소프트
웨어 측면 validation의 문서화된 결과와 모든 관련 문서가 시스템 개발자에게 이용 가능하
도록 해야 한다.

 요구사항
8. 소프트웨어 도구는 7.4.4(Software design and development)의 요구사항을 충족해야 한
다.
9. 시스템 안전의 안전 관련 소프트웨어 측면에 대한 validation 결과는 다음의 요구사항을
충족해야 한다:
소프트웨어 안전 validation 결과에 포함되어야 하는 내용
a. 테스트는 안전 관련 소프트웨어에 대한 모든 규정된 요구사항이 정확하게 만족되고
소프트웨어가 의도하지 않은 기능을 수행하지 않음을 보여야 한다.
b. 테스트 케이스와 그것들의 결과는 다음의 분석과 안전 무결성 수준에 의해 요구되는 독립적
인 평가(IEC 61508-1의 8절 참조)를 위해 문서화되어야 한다.
c. 시스템 안전의 소프트웨어 측면을 validation한 문서화된 결과는 (1) 소프트웨어가 validation
을 통과함 또는 (2) validation을 통과하지 못한 이유를 나타내야 한다.

B.5.2
Table B.3
HR HR HR HR
validation plan
C.2.11 R R HR HR
validation plan and the software safety requirement
s specification
C.2.11 R R HR HR

7.8 Software modification

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

- SW 수정
1) 요구된 SW가 시스템적인 능력이 유
지됨을 보이면서 확인된 SW에 대한 수
정, 향상, 적용을 가이드하기 위해
[WP28] SW 수정 절
차
[WP30] SW 수정 요
청
[WP29] SW 변경 영향 분석
결과
[WP31] SW 수정 로그
- SW 검증
위해
따라 다름)
-
가
전 평가 계획
보고서

Software modification
 목적
• 요구된 소프트웨어의 시스템적 능력이 유지되는 것을 보장하면서 validation된 소프트웨
어에 대한 교정, 개선 또는 개정(adoption)을 안내하는 것
 요구사항
1. 모든 소프트웨어 변경의 수행 이전에, 소프트웨어 변경 절차(IEC 61508-1의 7.16 참조)
를 제공해야 한다.
(비고1) 하위 항 7.8.2.1 부터 7.8.2.9는 소프트웨어의 운영 단계 동안 발생하는 변화에 주로
적용한다. 그것들은 또한 PE 통합과 전체 설치 및 시운전 단계에도 적용할 수 있다(IEC
61508-1의 7.13 참조).
(비고2) 변경 절차 모델의 예는 IEC 61508-1의 그림 9에 도식화 되어 있다.

 요구사항
2. 변경은 안전 계획 동안에 명시된 절차 하의 승인된 소프트웨어 변경 요청의 이슈에 대해
서만 시작되어야 하며, 세부 사항은 다음과 같다:
– a) 영향을 받을 수 있는 위험원(hazards);
– b) 제안된 변경(proposed modification);
– c) 변경에 대한 이유
(비고) 변경에 대한 요청은 다음 예와 같은 이유로 발생 할 수 있다.
– 기능 안전이 안전 요구사항 명세에 의해 요구된 것보다 낮은 수준으로 밝혀짐;
– 시스템적 결함 경험;
– 새로운 또는 개정된 안전 법규;
– EUC 또는 그것의 사용에 대한 변경;
– 전체 시스템 요구사항에 대한 변경;
– 성능이 목표 이하임을 나타내는, 운영 및 유지 보수 성능의 분석;
– 일상적 기능 안전 감사(audits);

 요구사항
3. E/E/PE 안전 관련 시스템의 기능 안전 관점에서 제안된 소프트웨어 수정에 대한 영향 분
석이 수행되어야 한다.
– a) 위험원 및 리스크 분석이 필요한지 판단;
– b) 소프트웨어 안전 수명 주기 단계가 반복되어야 하는지 판단;
4. 위의 항목(3)에서 얻은 영향 분석(impact analysis) 결과는 문서화되어야 한다.
5. E/E/PE 안전 관련 시스템의 기능 안전에 대한 영향을 갖는 수정은 소프트웨어 안전 수명
주기의 적절한 단계로 복귀해야 한다. 모든 후속 단계는 본 표준의 요구사항에 따라 특정 단
계에 지정된 절차에 따라 수행되어야 한다. 안전 계획(6절 참조)은 모든 후속 활동을 상세화
해야 한다.
(비고) E/E/PE 안전 관련 시스템에 의해 구현된 안전 기능에 대해 현재 명시된 것 보다, 안
전 무결성 수준에 대한 요구를 생성하여, 전체 위험원 및 리스크 분석을 수행할 필요가 있다.
6. 안전 관련 소프트웨어의 변경에 대한 안전 계획은 IEC 61508-1의 6절에 주어진 요구사
항을 만족해야 한다. 특히:
– a) 직원 및 사양(specification)에 요구된 역량(competency)의 식별;
– b) 변경의 상세한 사양;
– c) verification 계획;
– d) 안전 무결성 수준에 의하여 확장되어 요구되는 변경의 re-validation과 테스트의 범위

 요구사항
7. 변경은 계획된 대로 수행되어야 한다.
8. 다음에 대한 참조를 포함하여, 모든 변경의 세부사항은 문서화되어야 한다.
– a) 수정/보수(retrofit) 요청;
– b) 기능 안전에 대하여 제안된 소프트웨어 수정의 영향을 평가하는 영향 분석의 결과와 연
관된 타당한 이유를 적용한 결정(decision);
– c) 소프트웨어 형상 관리 히스토리;
– d) 정상 운영 및 조건에서의 편차(deviation);
9. 모든 수정의 세부 사항에 대한 정보는 문서화되어야 한다. 문서는 데이터 및 결과의 재
검증 및 재 확인을 포함해야 한다.
10. 필요한 수정 또는 보수 활동의 평가는 영향 분석 및 소프트웨어 시스템적 능력의 결과
에 의존한다.

7.9 Software verification

Contents
상세 설계 (7.4.5)
구현 (7.4.6)
단위 시험 (7.4.7)
통합 시험 (7.4.7)

- SW 검증
위해
따라 다름)

Software verification
 목적
• 안전 무결성 수준에서 필요로 하는 정도에서, 해당 단계의 입력에 대해 정확성과 일관성
을 보장하기 위하여 주어진 소프트웨어 안전 수명주기로부터의 출력을 테스트 및 평가하
는 것
(비고1) 본 하위 항은 여러 안전 수명주기 단계들에 일반적인 verification의 공통적 측면을
고려한다.
본 하위 항은 7.4.7 (소프트웨어 모듈 테스트), 7.4.8 (소프트웨어 통합) 그리고 7.5 (PE 통합)
의 verification 테스트 엘리먼트에 대한 요구사항을 추가하지 않는다. 그것들은 그 자체로
검증 활동이기 때문이다.
본 하위 항은 본 표준의 소프트웨어 validation이 안전 요구사항 명세 준수에 대한 입증이기
때문에 소프트웨어 validation에 추가적으로 verification을 요구하지는 않는다.
안전 요구사항 명세 자체가 정확한지 확인하는 것은 도메인 전문가에 의해 수행된다.
(비고2) 소프트웨어 아키텍처에 따라, 소프트웨어의 개발 및 변경에 연관된 모든 조직으로
verification 활동의 책임이 분담될 수 있다.

 요구사항
1. 각 소프트웨어 안전 수명주기 단계에 대하여, 소프트웨어 verification은 개발과 동시에
계획(7.3 참조)되고 문서화 되어야 한다.
2. 소프트웨어 verification 계획은 verification 활동에 사용된 기준(criteria), 기술 및 도구를
참조해야 한다.
소프트웨어 verification 계획에서 다루어야 하는 사항
a. 안전 무결성 요구사항의 평가;
b. verification 전략, 활동 및 기술의 선택 및 문서화;
c. verification 도구(테스트 장치(test harness), 특수 테스트 소프트웨어, 입력/출력 시뮬레이
터 등)의 선택 및 활용;
d. verification 결과의 평가;
e. 행해진 시정조치;

 요구사항
3. 계획대로 소프트웨어 verification이 수행되어야 한다.
(비고) verification을 위한 기술, 수단과 verification 활동의 독립성 정도에 대한 선택은 여러
가지 요인에 따라 달라지며, 응용 분야 표준에 따라 지정될 수 있다. 그 요인들은 다음의 예
를 포함할 수 있다.
– 프로젝트의 크기;
– 복잡성의 정도;
– 설계의 새로운 정도;
– 기술의 새로운 정도;
4. 증거는 verification된 단계가 모든 측면에서 만족스럽게 완료되었다는 것을 보이기 위해
서 문서화 되어야 한다.
5. 각 verification 후, verification 문서는 다음을 포함해야 한다:
소프트웨어 verification 보고서에서 포함되어야 하는 내용
a. verification된 아이템의 식별;
b. verification이 수행된 정보의 식별;
(비고1) verification을 수행했던 것에 대한 정보는 이전 수명주기 단계, 설계 표준, 코딩 표준 그
리고 사용된 도구로부터의 입력들을 포함할 수는 있지만 이것에 한정되지는 않는다.
c. 부적합;
(비고2) 부적합의 예는 소프트웨어 모듈, 데이터 구조, 그리고 형편없는 알고리즘을 포함한다.

 요구사항
6. 다음의 N+1 단계의 올바른 실행을 위한 소프트웨어 안전 수명주기 N 단계의 모든 필요
한 정보가 제공되고 verification되어야 한다. N 단계의 출력은 다음을 포함한다:
a. 다음에 대한 명세, 설계 또는 N단계의 적절성:
1) 기능;
2) 안전 무결성, 안전 계획의 성능 및 다른 요구사항
(6절 - Software safety lifecycle 계획 참조);
3) 개발팀에 의한 가독성;
4) 추가 verification을 위한 테스트 용이성;
5) 더 나은 변화(further evolution)를 허용하는 안전한 변경;
b. N단계의 설계를 명시하고 설명하기 위한 N단계의 validation 계획 그리고/또는 명시된 테스
트의 적절성;
c. 다음 항목 간의 비호환성 확인:
1) N단계에 명시된 테스트, 그리고 이전 N-1 단계에 명시된 테스트;
2) N단계 내의 출력;

 요구사항
7. 소프트웨어 개발 수명주기의 선택에 따라, 다음의 verification 활동이 수행되어야 한다.
a. 소프트웨어 안전 요구사항의 verification;
b. 소프트웨어 아키텍처의 verification;
c. 소프트웨어 시스템 설계의 verification;
d. 소프트웨어 모듈 설계의 verification;
e. 코드의 verification;
f. 데이터의 verification;
g. 타이밍 성능의 verification;
h. 소프트웨어 모듈 테스트 (7.4.7 참조);
i. 소프트웨어 통합 테스트 (7.4.8 참조);
j. PE 통합 테스트 (7.5 참조);
k. 시스템 안전 validation의 소프트웨어 측면 (7.7 참조);
비고 a)에서 g)의 요구사항에 대해서는 7.9.2.8~7.9.2.14을 참조한다.

 요구사항
8. 소프트웨어 안전 요구사항의 verification: 소프트웨어 안전 요구사항 명세가 완료된 후,
그리고 소프트웨어 설계 및 개발이 시작되기 전, verification은 다음 사항을 수행해야 한다:
a. 소프트웨어 안전 요구사항 명세가 기능, 안전 무결성, 성능 그리고 안전 계획의 모든 다른
요구사항에 대하여 E/E/PE 시스템 안전 요구사항 명세를 적절하게 충족하는지 고려해야
한다;
b. 시스템 안전의 소프트웨어 측면에 대한 validation 계획이 소프트웨어 안전 요구사항 명세
를 적절하게 충족하는지 고려해야 한다;
c. 다음 항목 사이의 호환성을 확인한다:
1) 소프트웨어 안전 요구사항 명세와 E/E/PE 시스템 안전 요구사항 명세 (see 7.10 of IEC
61508-1 and 7.2 of IEC 61508-2);
2) 소프트웨어 안전 요구사항 명세와 시스템 안전의 소프트웨어 측면에 대한 validation 계
획;

 요구사항
9. 소프트웨어 아키텍처의 verification: 소프트웨어 아키텍처 설계가 완료된 후, verification
은 다음 사항을 수행해야 한다:
a. 소프트웨어 아키텍처 설계가 소프트웨어 안전 요구사항 명세를 적절하게 만족하는지 고려
해야 한다;
b. 소프트웨어 아키텍처 설계에 명시된 통합테스트가 적절한지 고려해야 한다;
c. 다음을 참조하여, 각 주요 엘리먼트/하위 시스템의 속성이 적절한지 고려해야 한다:
1) 요구된 안전한 성능(performance)의 실행 가능성(feasibility)
2) 추가 verification의 테스트 가능성(testability);
3) 개발자 및 verification 팀에 의한 가독성(readability);
4) 더 나은 변화를 허용하는 안전한 변경;
d. 다음 항목 사이의 호환성을 확인한다:
1) 소프트웨어 아키텍처 설계와 소프트웨어
안전 요구사항 명세;
2) 소프트웨어 아키텍처 설계와 그 통합 테스트;
3) 소프트웨어 아키텍처 설계 통합 테스트와
시스템 안전의 소프트웨어 측면에 대한
validation 계획;

 요구사항
10. 소프트웨어 시스템 설계의 verification: 소프트웨어 시스템 설계가 완료된 후, verification은
다음 사항을 수행해야 한다:
a. 소프트웨어 시스템 설계가 소프트웨어 아키텍처
설계를 적절하게 만족하는지 고려해야 한다;
b. 소프트웨어 시스템 통합(7.4.5 참조)이 소프트웨어
시스템 설계(7.4.5 참조)를 적절하게 충족했는지
고려해야 한다;
c. 다음을 참조하여, 소프트웨어 시스템 설계 명세의
각 주요 엘리먼트의 속성이 적절한지 고려해야 한다:
1) 요구된 안전 성능의 실행 가능성;
2) 추가 verification에 대한 테스트 용이성;
3) 개발 및 verification 팀에 의한 가독성;
4) 더 나은 변화를 허용하는 안전한 변경(safe modification);
비고 소프트웨어 시스템 통합 테스트는 소프트웨어 아키텍처 통합 테스트의 부분으로 지정될 수
있다.
1) 소프트웨어 시스템 설계 명세(7.4.5 참조)와 소프트웨어 아키텍처 설계;
2) 소프트웨어 시스템 설계 명세(7.4.5 참조)와 소프트웨어 시스템 통합 테스트 명세(4.5 참조);
3) 소프트웨어 시스템 통합 테스트 명세(7.4.5 참조)에 의해 요구된 테스트와 소프트웨어 아키
텍처 통합 테스트 명세(7.4.3 참조)

 요구사항
11. 소프트웨어 모듈 설계의 verification: 각 소프트웨어 모듈의 설계가 완료된 후, verification
은 다음 사항을 수행해야 한다:
a. 소프트웨어 모듈 설계 명세(7.4.5 참조)가
소프트웨어 시스템 설계 명세(7.4.5 참조)를
적절하게 만족하는지 고려해야 한다;
b. 소프트웨어 모듈 테스트 명세(7.4.5 참조)가
소프트웨어 모듈 설계 명세(7.4.5 참조)에 대하여
적절한지 고려해야 한다;
c. 다음을 참조하여, 각 소프트웨어 모듈의 속성이
적절한지 고려해야 한다.
1) 요구된 안전 성능의 실행 가능성
(소프트웨어 안전 요구사항 명세 참조);
2) 추가 verification에 대한 테스트 용이성;
3) 개발 및 verification 팀에 의한 가독성;
4) 더 나은 변화를 허용하는 안전한 변경(safe modification);
1) 소프트웨어 모듈 설계 명세(7.4.5 참조)와 소프트웨어 시스템 설계 명세(7.4.5 참조);
2) (각 소프트웨어 모듈에 대하여)소프트웨어 모듈 설계 명세(7.4.5 참조)와 소프트웨어 모듈
테스트 명세(7.4.5 참조);
3) 소프트웨어 모듈 테스트 명세(7.4.5 참조)와 소프트웨어 시스템 통합 시험 명세(7.4.5 참조)

 요구사항
12. 코드의 verification: 소스 코드는 소프트웨어 모듈 설계 명세, 요구된 코딩 표준 그리고
시스템 안전의 소프트웨어 측면을 위한 validation계획에 대한 적합성을 보장하기 위하여
정적 방법에 의해 verification되어야 한다.
(비고) 소프트웨어 안전 수명주기의 초기 단계에서, verification은 정적(static)이다(예를 들
어, 검사(inspection), 리뷰, 정형 증거(formal proof) 등). 코드 verification은 소프트웨어 검사
(software inspection), 워크 스루(walk-throughs)와 같은 기술을 포함한다. 이는 각 소프트웨
어 모듈이 그것의 관련 사양을 만족한다는 보장을 제공하는 코드 verification과 소프트웨어
모듈 테스트 결과의 조합이다. 이후 테스트는 검증의 기본 수단이 된다.

 요구사항
13. 데이터의 verification
a. 데이터 구조는 verification 되어야 한다.
b. 애플리케이션 데이터는 다음에 대해 verification 되어야 한다:
1) 데이터 구조의 일관성;
2) 애플리케이션 요구사항에 대한 완전성;
3) 기본 시스템 소프트웨어와의 호환성(예를 들어, 실행 순서, 실행 시간(run-time), 등);
4) 데이터 값의 정확성;
c. 모든 동작 파라미터는 애플리케이션 요구사항에 대하여 verification 되어야 한다.
d. 모든 플랜트 인터페이스 및 관련된 소프트웨어(즉, 센서 및 액츄에이터 그리고 오프라인 인
터페이스: )는 다음에 대하여 verification 되어야 한다.
1) 예상 인터페이스 고장의 탐지(detection);
2) 예상 인터페이스 고장에 대한 내성(tolerance);
e. 모든 통신 인터페이스 및 관련된 소프트웨어는 다음에 대하여 적절한 수준에서 verification
되어야 한다.
1) 고장 탐지;
2) 손상에 대한 보호;
3) 데이터 validation.

 요구사항
14. 타이밍 성능의 verification: 시간 영역(time domain)에서 동작의 예측 가능성이
verification되어야 한다.
(비고) 타이밍 동작은 다음을 포함할 수 있다: 성능, 자원, 응답 시간, 최악의 경우 실행 시
간, 스래싱, 교착 자유 상태(dead-lock free), 런타임 시스템

Table A.9 – Software verification
1 Formal proof C.5.12 --- R R HR
2 Animation of specification and design C.5.26 R R R R
3 Static analysis B.6.4
Table B.8
R HR HR HR
Table B.2
R HR HR HR
5 Forward traceability between the software
design specification and the software
verification (including data verification) plan
C.2.11 R R HR HR
6 Backward traceability between the software
verification (including data verification) plan
and the software design specification
C.2.11 R R HR HR
7 Offline numerical analysis C.2.13 R R HR HR
Software module testing and integration See Table A.5
Programmable electronics integration testing See Table A.6
Software system testing (validation) See Table A.7

Table B.8 – Static analysis
1 Boundary value analysis C.5.4 R R HR HR
2 Checklists B.2.5 R R R R
3 Control flow analysis C.5.9 R HR HR HR
4 Data flow analysis C.5.10 R HR HR HR
5 Error guessing C.5.5 R R R R
6a Formal inspections, including specific criteria C.5.14 R R HR HR
6b Walk-through (software) C.5.15 R R R R
7 Symbolic execution C.5.11 --- --- R R
8 Design review C.5.16 HR HR HR HR
9 Static analysis of run time error behaviour B.2.2,
C.2.4
R R R HR
10 Worst-case execution time analysis C.5.20 R R R R
* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivale
nt techniques/measures are indicated by a letter following the number. It is intended the only one of the alternat
e or equivalent techniques/measures should be satisfied. The choice of alternative technique should be justified
in accordance with the properties, given in Annex C, desirable in the particular application.

8. Functional safety assessment

-
가
전 평가 계획
보고서

Functional safety assessment
(비고) 본 절의 요구사항을 구현하기 위한 적절한 기술 및 수단의 선택을 위해
(Annex A와 B 참조), 기능 안전 평가의 다음의 속성(see Annex C for guidance on
interpretation of properties, and Annex F of IEC 61508-7 for informal definitions)은 고려되
어야 한다.
• 본 표준에 대한 기능 안전 평가의 완전성;
• 설계 사양에 대한 기능 안전 평가의 정확성(성공적인 완료);
• 모든 식별된 이슈에 대해 추적 가능한 종료(traceable closure);
• 평가의 광범위한 재 작업을 할 필요 없이, 변경 후 기능 안전 평가의 수정 가능성;
• 반복 가능성;
• 적시성;
• 정확하게 정의된 설정.

Functional safety assessment
요구사항
• IEC-61508-1 8절의 목적 및 요구사항은 안전 관련 소프트웨어의 평가에 적용된다.
• 애플리케이션 분야 국제 표준에 명시되지 않는 한, 기능 안전 평가를 수행하는 사람들에
대한 독립성의 최소 수준은 IEC 61508-1 8절에 명시된 내용을 따라야 한다.
• 기능 안전 평가는 표 A.10 활동의 결과를 사용할 수 있다.
(비고) Annex A와 B의 기술을 선택하는 것이 요구된 안전 무결성 획득(7.1.2.7 참조)을 보
장하지 않는다. 평가자는 다음 사항을 고려해야 한다:
– 법, 언전체 개발 주기에 대해 선택된 방법, 언어 및 도구의 일관성 및 상호 보완적 성격;
– 개발자가 사용하는 방법, 언어 및 도구를 그들이 충분히 이해하는지 여부;
– 방어 및 도구가 개발 중 발생하는 특정 문제에 잘 적응되는지 여부.

Table A.10 – Functional safety assessment
Assessment/Technique * Ref. SIL 1 SIL 2 SIL 3 SIL 4
2 Decision/truth tables C.6.1 R R R R
3 Failure analysis Table B.4 R R HR HR
4 Common cause failure analysis of diverse softw
are (if diverse software is actually used)
C.6.3 --- R HR HR
5 Reliability block diagram C.6.4 R R R R
6 Forward traceability between the requirements
of Clause 8 and the plan for software functional
safety assessment
C.2.11 R R HR HR
NOTE 2 The references (which are informative, not normative) “B.x.x.x”, “C.x.x.x” in column 3 (Ref
.) indicate detailed descriptions of techniques/measures given in Annexes B and C of IEC 61508-7.

Annex A

Table A.1 – Software safety requirements specification
1a Semi-formal methods Table B.7 R R HR HR
1b Formal methods B.2.2, C.2.4 --- R R HR
2 Forward traceability between the system safety
requirements and the software safety requirements
C.2.11 R R HR HR
3 Backward traceability between the safety
requirements and the perceived safety needs
C.2.11 R R HR HR
4 Computer-aided specification tools to support appropriate te
chniques/measures above
B.2.4 R R HR HR
NOTE 1 The software safety requirements specification will always require a description of the problem in natural language and
any necessary mathematical notation that reflects the application.
NOTE 2 The table reflects additional requirements for specifying the software safety requirements clearly and precisely.
NOTE 4 The references (which are informative, not normative) “B.x.x.x”, “C.x.x.x” in column 3 (Ref.) indicate detailed descrip
tions of techniques/measures given in Annexes B and C of IEC 61508-7.
* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/me
asures are indicated by a letter following the number. It is intended the only one of the alternate or equivalent techniques/measure
s should be satisfied. The choice of alternative technique should be justified in accordance with the properties, given in Annex C,
desirable in the particular application.

11a Structured diagrammatic methods ** C.2.1 HR HR HR HR
11b Semi-formal methods ** Table B.7 R R HR HR
11c Formal design and refinement methods ** B.2.2, C.2.
4
--- R R HR
11d Automatic software generation C.4.6 R R R R
12 Computer-aided specification and design tools B.2.4 R R HR HR
13a Cyclic behaviour, with guaranteed maximum cycle
time
C.3.11 R HR HR HR
13b Time-triggered architecture C.3.11 R HR HR HR
13c Event-driven, with guaranteed maximum response
time
C.3.11 R HR HR -
14 Static resource allocation C.2.6.3 - R HR HR
15 Static synchronization of access to shared resour
ces
C.2.6.3 - - R HR

Table A.3 – Software design and development – support tools and programming language
1 Suitable programming language C.4.5 HR HR HR HR
2 Strongly typed programming language C.4.1 HR HR HR HR
3 Language subset C.4.2 --- --- HR HR
4a Certified tools and certified translators C.4.3 R HR HR HR
4b Tools and translators: increased confidence from u
se
C.4.4 HR HR HR HR
NOTE 2 The references (which are informative, not normative) “B.x.x.x”, “C.x.x.x” in column 3 (Ref.) indicate detailed descri
ptions of techniques/measures given in Annexes B and C of IEC 61508-7.
* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalent techniques/m
easures are indicated by a letter following the number. It is intended the only one of the alternate or equivalent techniques/meas
ures should be satisfied. The choice of alternative technique should be justified in accordance with the properties, given in Annex
C, desirable in the particular application.

Table A.4 – Software design and development – detailed design
1a Structured methods ** C.2.1 HR HR HR HR
1b Semi-formal methods ** Table B.7 R HR HR HR
1c Formal design and refinement methods ** B.2.2, C.2.4 --- R R HR
2 Computer-aided design tools B.3.5 R R HR HR
3 Defensive programming C.2.5 --- R HR HR
5 Design and coding standards C.2.6
Table B.1
R HR HR HR
6 Structured programming C.2.7 HR HR HR HR
7 Use of trusted/verified software elements (if availab
le)
C.2.10 R HR HR HR
8 Forward traceability between the software safety re
quirements specification and software design
C.2.11 R R HR HR

Table A.5 – Software design and development – software module testing and integration
1 Probabilistic testing C.5.1 --- R R R
Table B.2
R HR HR HR
B.5.2
Table B.3
HR HR HR HR
6 Model based testing C.5.27 R R HR HR
7 Interface testing C.5.3 R R HR HR
8 Test management and automation tools C.4.7 R HR HR HR
9 Forward traceability between the software design spe
cification and the module and integration test specific
ations
C.2.11 R R HR HR
10 Formal verification C.5.12 --- --- R R

Table A.6 – Programmable electronics integration (hardware and software)
B.5.2
Table B.3
HR HR HR HR
3 Forward traceability between the system and softw
are design requirements for hardware/software
integration and the hardware/software integration t
est specifications
C.2.11 R R HR HR
NOTE 1 Programmable electronics integration is a verification activity (see Table A.9). NOTE 2 See Table C.
6.

B.5.2
Table B.3
HR HR HR HR
validation plan
C.2.11 R R HR HR
validation plan and the software safety requirement
s specification
C.2.11 R R HR HR

Table A.8 – Modification
1 Impact analysis C.5.23 HR HR HR HR
2 Reverify changed software module C.5.23 HR HR HR HR
3 Reverify affected software modules C.5.23 R HR HR HR
4a Revalidate complete system Table A.7 --- R HR HR
4b Regression validation C.5.25 R HR HR HR
5 Software configuration management C.5.24 HR HR HR HR
7 Forward traceability between the Software safety r
equirements specification and the software
modification plan (including reverification and revali
dation)
C.2.11 R R HR HR
8 Backward traceability between the software modific
ation plan (including reverification and
revalidation)and the software safety requirements s
pecification
C.2.11 R R HR HR

Table A.9 – Software verification
1 Formal proof C.5.12 --- R R HR
2 Animation of specification and design C.5.26 R R R R
3 Static analysis B.6.4
Table B.8
R HR HR HR
Table B.2
R HR HR HR
5 Forward traceability between the software desig
n specification and the software verification (incl
uding data verification) plan
C.2.11 R R HR HR
6 Backward traceability between the software
verification (including data verification) plan an
d the software design specification
C.2.11 R R HR HR
7 Offline numerical analysis C.2.13 R R HR HR
Software module testing and integration See Table A.5
Programmable electronics integration testing See Table A.6
Software system testing (validation) See Table A.7

Table A.10 – Functional safety assessment
Assessment/Technique * Ref. SIL 1 SIL 2 SIL 3 SIL 4
2 Decision/truth tables C.6.1 R R R R
3 Failure analysis Table B.4 R R HR HR
4 Common cause failure analysis of diverse softw
are (if diverse software is actually used)
C.6.3 --- R HR HR
5 Reliability block diagram C.6.4 R R R R
6 Forward traceability between the requirements
of Clause 8 and the plan for software functional
safety assessment
C.2.11 R R HR HR
NOTE 2 The references (which are informative, not normative) “B.x.x.x”, “C.x.x.x” in column 3 (Ref
.) indicate detailed descriptions of techniques/measures given in Annexes B and C of IEC 61508-7.

Annex B

Table B.1 – Design and coding standards
1 Use of coding standard to reduce likelihood of errors C.2.6.2 HR HR HR HR
2 No dynamic objects C.2.6.3 R HR HR HR
3a No dynamic variables C.2.6.3 --- R HR HR
3b Online checking of the installation of dynamic variables C.2.6.4 --- R HR HR
4 Limited use of interrupts C.2.6.5 R R HR HR
5 Limited use of pointers C.2.6.6 --- R HR HR
6 Limited use of recursion C.2.6.7 --- R HR HR
7 No unstructured control flow in programs in higher level
languages
C.2.6.2 R HR HR HR
8 No automatic type conversion C.2.6.2 R HR HR HR

Table B.2 – Dynamic analysis and testing
(Referenced by Tables A.5 and A.9)
1 Test case execution from boundary value analysis C.5.4 R HR HR HR
2 Test case execution from error guessing C.5.5 R R R R
3 Test case execution from error seeding C.5.6 --- R R R
4 Test case execution from model-based test case gene
ration
C.5.27 R R HR HR
5 Performance modelling C.5.20 R R R HR
6 Equivalence classes and input partition testing C.5.7 R R R HR
7a Structural test coverage (entry points) 100 % ** C.5.8 HR HR HR HR
7b Structural test coverage (statements) 100 %** C.5.8 R HR HR HR
7c Structural test coverage (branches) 100 %** C.5.8 R R HR HR
7d Structural test coverage (conditions, MC/DC) 100 %** C.5.8 R R R HR
NOTE 1 The analysis for the test cases is at the subsystem level and is based on the specification and/or th
e specification and the code.
NOTE 3 The references (which are informative, not normative) “B.x.x.x”, “C.x.x.x” in column 3 (Ref.) indic
ate detailed descriptions of techniques/measures given in Annexes B and C of IEC 61508-7.
** Where 100 % coverage cannot be achieved (e.g. statement coverage of defensive code), an app
ropriate explanation should be given.

Table B.3 – Functional and black-box testing
1 Test case execution from cause consequence
diagrams
B.6.6.2 --- --- R R
2 Test case execution from model-based test case
generation
C.5.27 R R HR HR
3 Prototyping/animation C.5.17 --- --- R R
4 Equivalence classes and input partition testing,
including boundary value analysis
C.5.7
C.5.4
R HR HR HR
5 Process simulation C.5.18 R R R R
NOTE 1 The analysis for the test cases is at the software system level and is based on the specification only.
NOTE 2 The completeness of the simulation will depend upon the safety integrity level, complexity and
application.

Table B.4 – Failure analysis
1a Cause consequence diagrams B.6.6.2 R R R R
1b Event tree analysis B.6.6.3 R R R R
2 Fault tree analysis B.6.6.5 R R R R
3 Software functional failure analysis B.6.6.4 R R R R
NOTE 1 Preliminary hazard analysis should have already taken place in order to categorize the software into t
he most appropriate safety integrity level.

Table B.5 – Modelling
(referenced by Table A.7)
2a Finite state machines B.2.3.2 --- R HR HR
2b Formal methods B.2.2,
C.2.4
--- R R HR
2c Time Petri nets B.2.3.3 --- R HR HR
3 Performance modelling C.5.20 R HR HR HR
4 Prototyping/animation C.5.17 R R R R
5 Structure diagrams C.2.3 R R R HR
NOTE 1 If a specific technique is not listed in the table, it should not be assumed that it is excluded
from consideration. It should conform to this standard.
NOTE 2 Quantification of probabilities is not required. NOTE 3 See Table C.15.
* Appropriate techniques/measures shall be selected according to the safety integrity level. Alternate or equivalen
t techniques/measures are indicated by a letter following the number. It is intended the only one of the alternate o
r equivalent techniques/measures should be satisfied. The choice of alternative technique should be justified in a
ccordance with the properties, given in Annex C, desirable in the particular application.

Table B.6 – Performance testing
(referenced by Tables A.5 and A.6)
1 Avalanche/stress testing C.5.21 R R HR HR
2 Response timings and memory constraints C.5.22 HR HR HR HR
3 Performance requirements C.5.19 HR HR HR HR

Table B.7 – Semi-formal methods
1 Logic/function block diagrams See Note 1 R R HR HR
2 Sequence diagrams see Note 1 R R HR HR
4a Finite state machines/state transition diagrams B.2.3.2 R R HR HR
4b Time Petri nets B.2.3.3 R R HR HR
5 Entity-relationship-attribute data models B.2.4.4 R R R R
6 Message sequence charts C.2.14 R R R R
7 Decision/truth tables C.6.1 R R HR HR
8 UML C.3.12 R R R R
NOTE 1 Logic/function block diagrams and sequence diagrams are described in IEC 61131-3. NOTE 2 See T
able C.17.

Table B.8 – Static analysis
1 Boundary value analysis C.5.4 R R HR HR
3 Control flow analysis C.5.9 R HR HR HR
4 Data flow analysis C.5.10 R HR HR HR
5 Error guessing C.5.5 R R R R
6a Formal inspections, including specific criteria C.5.14 R R HR HR
6b Walk-through (software) C.5.15 R R R R
7 Symbolic execution C.5.11 --- --- R R
8 Design review C.5.16 HR HR HR HR
9 Static analysis of run time error behaviour B.2.2,
C.2.4
R R R HR
10 Worst-case execution time analysis C.5.20 R R R R

Table B.9 – Modular approach
1 Software module size limit C.2.9 HR HR HR HR
2 Software complexity control C.5.13 R R HR HR
3 Information hiding/encapsulation C.2.8 R HR HR HR
4 Parameter number limit / fixed number of subprogram
parameters
C.2.9 R R R R
5 One entry/one exit point in subroutines and functions C.2.9 HR HR HR HR
6 Fully defined interface C.2.9 HR HR HR HR
* Appropriate techniques/measures shall be selected according to the safety integrity level. No single techniqu
e is likely to be sufficient. All appropriate techniques shall be considered.

IEC 61508-3 SW Engineering

More Related Content

What's hot

Viewers also liked

Similar to IEC 61508-3 SW Engineering

IEC 61508-3 SW Engineering