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
9 Forward traceability between the software safety
requirements specification and software architectu
re
C.2.11 R R HR HR
10 Backward traceability between the software safety
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)

Title 10.3 소프트웨어 설계 및 개발
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) 참조)

IEC 61508-3 SW Engineering

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (19)

Similar to IEC 61508-3 SW Engineering

Similar to IEC 61508-3 SW Engineering (20)

IEC 61508-3 SW Engineering