Ove en Iec 62061

ENTWURF
OVE EN IEC 62061

Ausgabe: 2019-06-01
Safety of machinery –
Functional safety of safety-related control systems
(IEC 44/847/CDV)
Normen-Download-Beuth-Enway GmbH-KdNr.7970880-ID.ZD2O5VEOM1RBNDL19GHN6NKN.3-2020-02-04 12:14:20
Hinweis:
Aufgrund von Stellungnahmen kann die endgültige Fassung
dieser OVE-Norm vom vorliegenden Entwurf abweichen.
Stellungnahmen (schriftlich) bis 2019-07-01 an den OVE.
Medieninhaber und Hersteller: ICS 13.110, 25.040.99, 29.020

OVE Österreichischer Verband für Elektrotechnik
Copyright © OVE – 2019.

Alle Rechte vorbehalten! Nachdruck oder Ident (IDT) mit IEC 44/847/CDV
Vervielfältigung, Aufnahme auf oder in sonstige Medien Ident (IDT) mit prEN IEC 62061:2019
oder Datenträger nur mit Zustimmung gestattet!
OVE Österreichischer Verband für Elektrotechnik zuständig OVE/TK E

Eschenbachgasse 9, 1010 Wien Elektrische Niederspannungsanlagen
E-Mail: verkauf@ove.at
Internet: http://www.ove.at
Webshop: www.ove.at/webshop
Tel.: +43 1 587 63 73
ENTWURF OVE EN IEC 62061:2019-06-01
Erläuterungen zum Entwurf
Die von IEC TC 44 ausgearbeitete Internationale Norm wurde als Entwurf zu einer Europäischen Norm
EN IEC 62061 den CENELEC-Mitgliedern zur Abstimmung vorgelegt. Im Falle eines positiven
Abstimmungsergebnisses im Sinne der CENELEC-Regeln wird dieser Entwurf zu einer EN führen.
Wie alle Mitgliedsorganisationen von CENELEC ist der OVE grundsätzlich verpflichtet, Europäische Normen
in das nationale Normenwerk zu übernehmen und entgegenstehende Normen zurückzuziehen.
Der OVE legt hiermit diesen Entwurf eines europäischen Normungsdokumentes der Öffentlichkeit zur
Information und Stellungnahme als OVE-Entwurf vor.
Da eine Übersetzung in die deutsche Sprache zu diesem Zeitpunkt noch nicht vorhanden ist, wird – um die
von CENELEC vorgegebene Einspruchsfrist einzuhalten – die englischsprachige Fassung
des IEC 44/847/CDV zur Information und Stellungnahme vorgelegt.
Interessenten können das gegenständliche Dokument beim Österreichischen Verband für Elektrotechnik
beziehen bzw. in den Text Einsicht nehmen.
2
ENTWURF OVE
44/847/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
P ROJECT NUMBER :
IEC 62061 ED2
D ATE OF CIRCULATION : C LOSING DATE FOR VOTING :
2019-04-26 2019-07-19
S UPERSEDES DOCUMENTS :
44/827/CD, 44/844A/CC
IEC TC 44 : S AFETY OF MACHINERY - E LECTROTECHNICAL ASPECTS
S ECRETARIAT : S ECRETARY :
United Kingdom Mrs Nyomee Hla-Shwe Tun
O F INTEREST TO THE FOLLOW ING COMMITTEES : P ROPOSED HORIZONTAL STANDARD :
Other TC/SCs are requested to indicate their interest, if any, in

this CDV to the secretary.
F UNCTIONS CONCERNED :
EMC E NVIRONMENT Q UALITY ASSURANCE S AFETY
S UBMITTED FOR CENELEC PARALLEL VOTING N OT SUBMITTED FOR CENELEC PARALLEL VOTING
Attention IEC-CENELEC parallel voting

The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft for
Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the

CENELEC online voting system.
This document is still under study and subject to change. It should not be used for reference purposes.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.
T ITLE :
Safety of machinery – Functional safety of safety-related control systems
PROPOSED STABILITY DATE : 2024
N OTE FROM TC/SC OFFICERS :
Copyright © 2019 International Electrotechnical Commission, IEC. All rights reserved. It is permitted to download this
electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.
You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.
ENTWURF OVE
–2– IEC CDV 62061  IEC 2019
CONTENTS
FOREWORD ........................................................................................................................... 9
INTRODUCTION ................................................................................................................... 12
1 Scope ............................................................................................................................ 13
2 Normative references .................................................................................................... 14
3 Terms, definitions and abbreviations ............................................................................. 15
3.1 Alphabetical list of definitions ................................................................................ 15
3.2 Terms and definitions............................................................................................ 17
3.3 Abbreviations ........................................................................................................ 28
4 Design process of an SCS and management of functional safety ................................... 29
4.1 Objective .............................................................................................................. 29
4.2 Design process ..................................................................................................... 29
4.3 Management of functional safety using a functional safety plan ............................ 31
4.4 Configuration management ................................................................................... 32
4.5 Modification .......................................................................................................... 33
5 Specification of a safety function ................................................................................... 33
5.1 Objective .............................................................................................................. 33
5.2 Safety Requirements Specification (SRS) ............................................................. 33
5.2.1 Information to be available............................................................................. 34
5.2.2 Functional requirements specification ............................................................ 34
5.2.3 Safety integrity requirements specification ..................................................... 35
6 Design of an SCS .......................................................................................................... 35
6.1 General ................................................................................................................. 35
6.2 Subsystem architecture based on top down decomposition ................................... 36
6.3 Basic methodology – Use of subsystem ................................................................ 36
6.3.1 General ......................................................................................................... 36

6.3.2 SCS architecture design based on subsystems .............................................. 36
6.3.3 Sub-function allocation .................................................................................. 38
6.3.4 Use of a pre-designed subsystem .................................................................. 38
6.4 Determination of safety integrity of the SCS .......................................................... 38
6.4.1 General ......................................................................................................... 38
6.4.2 Average frequency of dangerous failures ....................................................... 39
6.5 Requirements for systematic safety integrity of the SCS ....................................... 39
6.5.1 Requirements for the avoidance of systematic hardware failures ................... 39
6.5.2 Requirements for the control of systematic faults ........................................... 40
6.6 Electromagnetic immunity ..................................................................................... 41
6.7 Software based manual parameterization .............................................................. 41
6.7.1 General ......................................................................................................... 41
6.7.2 Influences on safety-related parameters ........................................................ 41
6.7.3 Requirements for software based manual parameterization ........................... 42
6.7.4 Verification of the parameterization tool ......................................................... 43
6.7.5 Performance of software based manual parameterization .............................. 43
6.8 Security aspects ................................................................................................... 43
6.9 Aspects of periodic testing .................................................................................... 44
6.9.1 General principle ........................................................................................... 44
ENTWURF OVE
IEC CDV 62061  IEC 2019 –3–
6.9.2 Proof test ....................................................................................................... 44

7 Design and development of a subsystem ....................................................................... 45
7.1 General ................................................................................................................. 45
7.2 Subsystem architecture design ............................................................................. 46
7.3 Requirements for the selection and design of subsystem and subsystem
elements ............................................................................................................... 46
7.3.1 General ......................................................................................................... 46
7.3.2 Systematic integrity ....................................................................................... 46
7.3.3 Fault consideration and fault exclusion .......................................................... 49
7.3.4 Failure rate of subsystem element ................................................................. 50
7.4 Architectural constraints of a subsystem ............................................................... 52
7.4.1 General ......................................................................................................... 52
7.4.2 Estimation of safe failure fraction (SFF) ......................................................... 53
7.4.3 Behaviour (of the SCS) on detection of a fault in a subsystem ....................... 54
7.4.4 Realization of diagnostic functions ................................................................. 55
7.5 Subsystem design architectures ............................................................................ 56
7.5.1 General ......................................................................................................... 56
7.5.2 Basic subsystem architectures ....................................................................... 56
7.5.3 Basic requirements ........................................................................................ 57
7.6 Probability of dangerous random hardware failures of subsystems ........................ 58
7.6.1 General ......................................................................................................... 58
7.6.2 Methods to estimate the PFH of a subsystem ................................................ 58
7.6.3 Methods to estimate the PFD avg of a subsystem ............................................ 58
7.6.4 Simplified approach to estimation of contribution of common cause
failure (CCF) .................................................................................................. 58
8 Software ........................................................................................................................ 59
8.1 General ................................................................................................................. 59
8.2 Definition of Software Levels................................................................................. 59
8.3 Software Level 1 ................................................................................................... 60
8.3.1 Software safety lifecycle SW Level 1 ............................................................. 60

8.3.2 Software Design SW Level 1 ......................................................................... 61
8.3.3 Module design SW Level 1 ............................................................................ 63
8.3.4 Coding SW Level 1 ........................................................................................ 64
8.3.5 Module test SW Level 1 ................................................................................. 64
8.3.6 Software testing SW Level 1 .......................................................................... 64
8.3.7 Documentation SW Level 1 ............................................................................ 65
8.3.8 Configuration and modification management process SW Level 1 .................. 65
8.4 Software Level 3 ................................................................................................... 66
8.4.1 Software safety lifecycle SW Level 3 ............................................................. 66
8.4.2 Software Design SW Level 3 ......................................................................... 68
8.4.3 Software system design SW Level 3 .............................................................. 69
8.4.4 Module design SW Level 3 ............................................................................ 70
8.4.5 Coding SW Level 3 ........................................................................................ 70
8.4.6 Module test SW Level 3 ................................................................................. 71
8.4.7 Software integration testing SW Level 3 ........................................................ 71
8.4.8 Software testing SW Level 3 .......................................................................... 71
8.4.9 Documentation SW Level 3 ............................................................................ 73
8.4.10 Configuration and modification management process SW Level 3 .................. 73
9 Validation ...................................................................................................................... 73
ENTWURF OVE
–4– IEC CDV 62061  IEC 2019
9.1 Validation principles .............................................................................................. 73

9.1.1 Validation plan ............................................................................................... 77
9.1.2 Use of generic fault lists ................................................................................ 77
9.1.3 Specific fault lists .......................................................................................... 78
9.1.4 Information for validation ............................................................................... 78
9.1.5 Validation record ........................................................................................... 79
9.2 Analysis as part of validation ................................................................................ 79
9.2.1 General ......................................................................................................... 79
9.2.2 Analysis techniques ....................................................................................... 79
9.2.3 Verification of safety requirements specification for safety functions .............. 79
9.3 Testing as part of validation .................................................................................. 80
9.3.1 General ......................................................................................................... 80
9.3.2 Measurement accuracy .................................................................................. 80
9.3.3 More stringent requirements .......................................................................... 81
9.3.4 Number of test samples ................................................................................. 81
9.4 Validation of the safety function ............................................................................ 81
9.4.1 General ......................................................................................................... 81
9.4.2 Analysis and testing....................................................................................... 82
9.5 Validation of the safety integrity of the SCS .......................................................... 82
9.5.1 Validation of subsystem(s) ............................................................................. 82
9.5.2 Validation of measures against systematic failures ........................................ 82
9.5.3 Validation of safety-related software .............................................................. 83
9.5.4 Validation of combination of subsystems ....................................................... 83
9.5.5 Verification of safety integrity......................................................................... 84
10 Documentation .............................................................................................................. 84
10.1 General ................................................................................................................. 84
10.2 Technical documentation ...................................................................................... 84
10.3 Information for use of the SCS .............................................................................. 85
10.3.1 General ......................................................................................................... 85

10.3.2 Information for use given by the manufacturer of subsystems ........................ 86
10.3.3 Information for use given by the SCS integrator ............................................. 86
Annex A (informative) Determination of required safety integrity ......................................... 88
A.1 General ................................................................................................................. 88
A.2 Matrix assignment for the required SIL .................................................................. 88
A.2.1 Hazard identification/indication ...................................................................... 88
A.2.2 Risk estimation .............................................................................................. 88
A.2.3 Severity (Se) ................................................................................................. 89
A.2.4 Probability of occurrence of harm .................................................................. 89
A.2.5 Class of probability of harm (Cl) .................................................................... 92
A.2.6 SIL assignment .............................................................................................. 92
A.3 Overlapping hazards ............................................................................................. 94
Annex B (informative) Example of SCS design methodology ............................................... 95
B.1 General ................................................................................................................. 95
B.2 Safety requirements specification ......................................................................... 95
B.3 Decomposition of the safety function ..................................................................... 95
B.4 Design of the SCS by using subsystems ............................................................... 97
B.4.1 General ......................................................................................................... 97
B.4.2 Subsystem 1 design – “guard door monitoring” .............................................. 97
ENTWURF OVE
IEC CDV 62061  IEC 2019 –5–
B.4.3 Subsystem 2 design – “evaluation logic” ........................................................ 99

B.4.4 Subsystem 3 design – “motor control” ............................................................ 99
B.4.5 Evaluation of the SCS .................................................................................... 99
B.5 Verification ......................................................................................................... 100
B.5.1 Analysis ....................................................................................................... 100
B.5.2 Tests ........................................................................................................... 100
Annex C (informative) Examples of MTTF D values for single components ......................... 101
C.1 General ............................................................................................................... 101
C.2 Good engineering practices method .................................................................... 101
C.3 Hydraulic components ......................................................................................... 101
C.4 MTTF D of pneumatic, mechanical and electromechanical components ................ 101
Annex D (normative) Low demand requirements ................................................................ 103
D.1 General ............................................................................................................... 103
D.2 Normative references .......................................................................................... 103
D.3 Terms and definitions.......................................................................................... 103
D.4 Design process of an SCS and management of functional safety ........................ 103
D.5 Specification of a safety function ......................................................................... 103
D.6 Design of an SCS ............................................................................................... 104
D.7 Design and development of subsystem ............................................................... 105
D.8 Software ............................................................................................................. 106
D.9 Validation............................................................................................................ 106
D.10 Documentation .................................................................................................... 106
Annex E (informative) Examples for diagnostic coverage (DC) .......................................... 107
Annex F (informative) Methodology for the estimation of susceptibility to common
cause failures (CCF) .................................................................................................... 109
F.1 General ............................................................................................................... 109
F.2 Methodology ....................................................................................................... 109
F.2.1 Requirements for CCF ................................................................................. 109
F.2.2 Estimation of effect of CCF .......................................................................... 109

Annex G (informative) Guideline for Software level 1 ........................................................ 111
G.1 Software safety requirements .............................................................................. 111
G.2 Coding guidelines ............................................................................................... 112
G.3 Specification of safety functions .......................................................................... 112
G.4 Specification of hardware design ........................................................................ 114
G.5 Software system design specification .................................................................. 115
G.6 Protocols ............................................................................................................ 118
Annex H (informative) ((void)) ........................................................................................... 120
Annex I (informative) Examples of safety functions ........................................................... 121
I.1 Examples of safety functions .............................................................................. 121
I.2 Example of low demand function ......................................................................... 122
Annex J (informative) ((void)) ............................................................................................ 126
Annex K (informative) Simplified approaches to evaluate the PFH value of a
subsystem ................................................................................................................... 127
K.1 Table allocation approach ................................................................................... 127
K.2 Simplified Formulas for the estimation of PFH ..................................................... 129
K.2.1 General ....................................................................................................... 129
K.2.2 Basic subsystem architecture A: single channel without a diagnostic
function ....................................................................................................... 129
ENTWURF OVE
–6– IEC CDV 62061  IEC 2019
K.2.3 Basic subsystem architecture B: dual channel without a diagnostic

function ....................................................................................................... 130
K.2.4 Basic subsystem architecture C: single channel with a diagnostic
function ....................................................................................................... 130
K.2.5 Basic subsystem architecture D: dual channel with a diagnostic
function(s) ................................................................................................... 135
K.3 Parts count method ............................................................................................. 135
Annex L ((void)) .................................................................................................................. 137
Annex M (informative) The functional safety plan and design activities ............................. 138
M.1 General ............................................................................................................... 138
M.2 Example of a machine design plan including a safety plan .................................. 138
M.3 Example of activities, documents and roles ......................................................... 138
Bibliography ........................................................................................................................ 141
Figure 1 - Relationship of this standard to other standards ................................................... 14

Figure 2 – Integration within the risk reduction process of ISO 12100 (excerpt) .................... 29
Figure 3 – Iterative process for design of the safety-related control system .......................... 30
Figure 4 – Examples of combination of subsystems as one SCS ........................................... 31
Figure 5 – Examples of typical decomposition of a safety function into sub-functions
and its allocation to subsystems ........................................................................................... 37
Figure 6 - Example of safety integrity of a safety function based on allocated
subsystems as one SCS ....................................................................................................... 38
Figure 7 – Subsystem A logical representation ..................................................................... 56
Figure 8 – Subsystem B logical representation ..................................................................... 57
Figure 9 – Subsystem C logical representation ..................................................................... 57
Figure 10 – Subsystem D logical representation ................................................................... 57
Figure 11 – V-model for SW level 1....................................................................................... 60
Figure 12 – V-model for software modules customized by the designer for SW level 1 .......... 60
Figure 13 – V-model of software safety lifecycle for SW Level 3 ........................................... 66
Figure 14 – Overview of the validation process ..................................................................... 76
Figure A.1 - Parameters used in risk estimation .................................................................... 88
Figure A.2 – Example proforma for SIL assignment process ................................................. 93
Figure B.1 – Decomposition of the safety function ................................................................ 96
Figure B.2 – Overview of design of the subsystems of the SCS ............................................ 97
Figure D.1 — Example of safety integrity of a safety function based on allocated
subsystems as one SCS ..................................................................................................... 104
Figure G.1 – Plant sketch ................................................................................................... 113
Figure G.2 – Principal module architecture design .............................................................. 116
Figure G.3 – Principal design approach of logical evaluation .............................................. 117
Figure G.4 – Example of logical representation (program sketch)........................................ 118
Figure I.1 – Relationship between demand of a safety function, failure and trip limit in a
safety function .................................................................................................................... 123
Figure I.2 - Typical configuration of a gas turbine ............................................................... 124
Figure K.1 - Subsystem A logical representation. ................................................................ 129
Figure K.2 - Subsystem B logical representation ................................................................. 130
Figure K.3 – Subsystem C logical representation ................................................................ 130
ENTWURF OVE
IEC CDV 62061  IEC 2019 –7–
Figure K.4 - Correlation of subsystem C and the pertinent fault handling function .............. 131
Figure K.5 - Subsystem C with external fault handling function ........................................... 131
Figure K.6 – Subsystem C with external fault diagnostics ................................................... 132
Figure K.7 – Subsystem C with external fault reaction ........................................................ 133
Figure K.8 – Subsystem C with internal fault diagnostics and internal fault reaction ............ 133
Figure K.9 - Subsystem D logical representation ................................................................. 135
Figure M.1 – Example of a machine design plan including a safety plan ............................. 138
Figure M.2 – Example of activities, documents and roles .................................................... 139
Table 1 – SIL and limits of PFH values ................................................................................. 35

Table 2 – Required SIL and PFH of pre-designed subsystem ................................................ 38
Table 3 – Relevant information for each subsystem .............................................................. 45
Table 4 – Architectural constraints on a subsystem: maximum SIL that can be claimed
for an SCS using the subsystem ........................................................................................... 53
Table 5 – Overview of basic requirements and interrelation to basic subsystem
architectures ......................................................................................................................... 58
Table 6 – Different levels of software .................................................................................... 59
Table 7 – Minimum levels of independence for review, testing and verification activities
SW Level 1 ........................................................................................................................... 61
Table 8 – Minimum levels of independence for review, testing and verification activities
SW Level 3 ........................................................................................................................... 67
Table 9 – Minimum levels of independence for validation activities ....................................... 77
Table 10 – Documentation of an SCS ................................................................................... 85
Table A.1 – Severity (Se) classification ................................................................................. 89
Table A.2 – Frequency and duration of exposure (Fr) classification ...................................... 90
Table A.3 – Probability (Pr) classification .............................................................................. 91
Table A.4 – Probability of avoiding or limiting harm (Av) classification .................................. 91

Table A.5 – Parameters used to determine class of probability of harm (Cl) .......................... 92
Table A.6 – Matrix assignment for determining the required SIL (or PL r ) for a safety
function................................................................................................................................. 93
Table B.1 – Safety requirements specification – example of overview ................................... 95
Table B.2 – Systematic integrity – example of overview ...................................................... 100
Table B.3 – Verification by tests ......................................................................................... 100
Table C.1 – Standards references and MTTF D or B 10D values for components ..................... 102
Table D.1 – SIL and limits of PFD avg values in low demand mode of operation .................... 103
Table E.1 – Estimates for diagnostic coverage (DC) ........................................................... 107
Table F.1 – Criteria for estimation of CCF ........................................................................... 109
Table F.2 – Criteria for estimation of CCF ........................................................................... 110
Table G.1 – Example of relevant documents related to the simplified V-model .................... 111
Table G.2 – Examples of coding guidelines ......................................................................... 112
Table G.3 – Specified safety functions ................................................................................ 113
Table G.4 – Relevant list of input and output signals ........................................................... 114
Table G.5 – Example of simplified cause and effect matrix.................................................. 118
Table G.6 – Verification of software system design specification ......................................... 119
Table G.7 – Software code review ...................................................................................... 119
ENTWURF OVE
–8– IEC CDV 62061  IEC 2019
Table G.8 – Software validation .......................................................................................... 119

Table I.1 – Examples of typical safety functions .................................................................. 121
Table K.1 – Allocation of PFH value of a subsystem ........................................................... 128
Table K.2 – Relationship between B 10D , operations and MTTF D .......................................... 129
ENTWURF OVE
IEC CDV 62061  IEC 2019 –9–
1 INTERNATIONAL ELECTROTECHNICAL COMMISSION

2 ____________
3
4 SAFETY OF MACHINERY –
5 FUNCTIONAL SAFETY OF SAFETY-RELATED CONTROL SYSTEMS
6
7
8 FOREWORD
9 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
10 all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
11 international co-operation on all questions concerning standardization in the electrical and electronic fields. To
12 this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
13 Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
14 Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
15 in the subject dealt with may participate in this preparatory work. International, governmental and non-
16 governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
17 with the International Organization for Standardization (ISO) in accordance with conditions determined by
18 agreement between the two organizations.
19 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
20 consensus of opinion on the relevant subjects since each technical committee has representation from all
21 interested IEC National Committees.
22 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
23 Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
24 Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
25 misinterpretation by any end user.
26 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
27 transparently to the maximum extent possible in their national and regional publications. Any divergence
28 between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
29 the latter.
30 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
31 assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
32 services carried out by independent certification bodies.
33 6) All users should ensure that they have the latest edition of this publication.
34 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
35 members of its technical committees and IEC National Committees for any personal injury, property damage or
36 other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
37 expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
38 Publications.
39 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
40 indispensable for the correct application of this publication.
41 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
42 patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
43 International Standard IEC 62061 has been prepared by IEC technical committee 44: Safety
44 of machinery – Electrotechnical aspects.
45 This second edition cancels and replaces the previous edition. This edition constitutes a
46 technical revision and it includes the following significant technical changes:
47 1. structure has been changed and contents have been updated to reflect the design
48 process of the safety function
49 2. standard extended to non-electrical technologies
50 3. standard extended to low demand mode for specific applications (Annex D)
51 4. definitions updated to be aligned with IEC 61508
52 5. functional safety plan introduced and configuration management updated (Section 4)
53 6. requirements on parametrization expanded (Section 6)
54 7. reference to requirements on security added (Section 6.8)
55 8. requirements on periodic testing added (Section 6.9)
56 9. various improvements and clarification on architectures and reliability calculations
57 (Sections 6 and 7)
58 10. shift from SILCL to maximum SIL of a subsystem (Section 7)
59 11. use cases for software described including requirements (Section 8)
ENTWURF OVE
– 10 – IEC CDV 62061  IEC 2019
60 12. requirements on independence for software verification (Section 8) and validation

61 activities (Sections 9) added
62 13. new informative annex with examples (Annex I)
63 14. new informative annexes on typical MTTF D values, diagnostics and calculation
64 methods for the architectures (Annexes C, E and K)
65 The text of this standard is based on the following documents:
FDIS Report on voting

XX/XX/FDIS XX/XX/RVD
66
67 Full information on the voting for the approval of this standard can be found in the report on
68 voting indicated in the above table.
69 This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
70
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 11 –
71 The committee has decided that the contents of this publication will remain unchanged until
72 the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
73 related to the specific publication. At this date, the publication will be
74 • reconfirmed,
75 • withdrawn,
76 • replaced by a revised edition, or
77 • amended.
78
79 The National Committees are requested to note that for this publication the stability date
80 is 20XX.
81 THIS TEXT IS INCLUDED FOR THE INFORMATION OF THE NATIONAL COMMITTEES AND WILL BE DELETED
82 AT THE PUBLICATION STAGE .
83
ENTWURF OVE
– 12 – IEC CDV 62061  IEC 2019
84 INTRODUCTION
85 As a result of automation, demand for increased production and reduced operator physical
86 effort, Safety-related Control Systems (referred to as SCS) of machines play an increasing
87 role in the achievement of overall machine safety. Furthermore, the SCS themselves
88 increasingly employ complex electronic technology.
89 IEC 62061 and ISO 13849-1 specify requirements for the design and implementation of
90 safety-related control systems of machinery. This standard is machine sector specific within
91 the framework of IEC 61508.
92 This International Standard is intended for use by machinery designers, control system
93 manufacturers and integrators, and others involved in the specification, design and validation
94 of an SCS. It sets out an approach and provides requirements to achieve the necessary
95 performance.
96 It is intended to facilitate the specification of the safety functions intended to achieve the risk
97 reduction of machine when it is intended to be achieved by safety-related control systems.
98 This standard provides a machine sector specific framework for functional safety of a SCS of
99 machines. It only covers those aspects of the safety lifecycle that are related to safety
100 requirements allocation through to safety validation. Requirements are provided for
101 information for safe use of SCS of machines that can also be relevant to later phases of the
102 lifecycle of a SCS.
103 There are many situations on machines where SCS are employed as part of safety measures
104 that have been provided to achieve risk reduction. A typical case is the use of an interlocking
105 guard that, when it is opened to allow access to the danger zone, signals the machinecontrol
106 system to stop hazardous machine operation. Also in automation, the machine control system
107 that is used to achieve correct operation of the machine process often contributes to safety by
108 mitigating risks associated with hazards arising directly from control system failures. This
109 standard gives a methodology and requirements to
110 • assign the required safety integrity for each safety function to be implemented by SCS;
111 • enable the design of the SCS appropriate to the assigned safety (control) function(s);
112 • integrate safety-related subsystems designed in accordance with other applicable

113 functional safety-related standards (see 6.2.4);
114 • validate the SCS.
115 This standard is intended to be used within the framework of systematic risk reduction, in
116 conjunction with risk assessment described in ISO 12100. Suggested methodologies for a
117 safety integrity assignment are given in informative Annex A.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 13 –
118 SAFETY OF MACHINERY –

119 FUNCTIONAL SAFETY OF SAFETY-RELATED CONTROL SYSTEMS
120
121
122 1 Scope
123 This International Standard specifies requirements and makes recommendations for the
124 design, integration and validation of safety-related control systems (SCS) for machines. It is
125 applicable to control systems used, either singly or in combination, to carry out safety
126 functions on machines that are not portable by hand while working, including a group of
127 machines working together in a co-ordinated manner.
128 This standard is machinery sector specific standard within the framework of the IEC 61508
129 series.
130 The design of complex programmable electronic subsystems or subsystem elements is not in
131 the scope of this standard. This is in the scope of IEC 61508 or standards linked to it, see
132 Figure 1.
133 The main body of this sector standard specifies general requirements for the design, and
134 verification of a safety-related control system intended to be used in high/continuous demand
135 mode.
136 Specific requirements for design, and verification of a safety-related control system intended
137 to be used in low demand mode are given in normative Annex D.
138 NOTE 1 It’s recognized that a subsystem can be shared by high and low demand functions.
139 This standard:
140 – is concerned only with functional safety requirements intended to reduce the risk of injury
141 or damage to the health of persons in the immediate vicinity of the machine and those
142 directly involved in the use of the machine;
143 – is restricted to risks arising directly from the hazards of the machine itself or from a group
144 of machines working together in a co-ordinated manner;
145 NOTE 2 Requirements to mitigate risks arising from other hazards are provided in relevant sector standards.
146 For example, where a machine(s) is part of a process activity, additional information is available in IEC 61511.
147 This document does not cover
148 – electrical hazards arising from the electrical control equipment itself (e.g. electric shock –
149 see IEC 60204–1);
150 – other safety requirements necessary at the machine level such as safeguarding;
151 – specific measures for security aspects – see IEC TR 63074.
152 This document is not intended to limit or inhibit technological advancement.
153 Figure 1 shows the relationship of this standard to other relevant standards.
ENTWURF OVE
– 14 – IEC CDV 62061  IEC 2019
154
IEC 62061
Machinery Machinery
sector sector
Hardware software and
application
software
In scope of Not In scope In scope of In scope of IEC Not In scope of

IEC 62061 of IEC 62061 IEC 62061 62061 IEC 62061
Design of low Design of Integration of Using Hardware Design of

complexity complex subsystem (type B complex
subsystems subsystems into a safety technology) subsystems
related control developed and
Follow system assessed Follow
IEC 61508 or according to IEC IEC 61508 or
other 61508 or other other functional
functional functional safety safety standards
safety standards linked linked to IEC
standards to IEC 61508 e.g. 61508 e.g. IEC
linked to IEC IEC 61800-5-2 or 61800-5-2
61508 e.g. IEC already safety
61800-5-2 and assessed de-
IEC 61496 vices(see 6.2.4).
Developing application Developing application

program using full program using limited

variability languages variability or fixed
Follow program languages
IEC 62061 (SW level 3) Follow
IEC 62061 (SW level 1)
155
156 Figure 1 - Relationship of this standard to other standards
157 2 Normative references

158 The following documents, in whole or in part, are normatively referenced in this document and
159 are indispensable for its application. For dated references, only the edition cited applies. For
160 undated references, the latest edition of the referenced document (including any
161 amendments) applies.
162 IEC 60204–1, Safety of machinery – Electrical equipment of machines – Part 1: General
163 requirements
164 IEC 61000-1-2, Electromagnetic compatibility (EMC) – Part 1-2: General - Methodology for
165 the achievement of functional safety of electrical and electronic systems including equipment
166 with regard to electromagnetic phenomena
167 IEC 61508-1, Functional safety of electrical/electronic/ programmable electronic safety-related

168 systems – Part 1: General requirements
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 15 –
169 IEC 61508-2, Functional safety of electrical/electronic/ programmable electronic safety-related

170 systems – Part 2: Requirements for electrical/electronic/programmable electronic safety-
171 related systems
172 IEC 61508-3, Functional safety of electrical/electronic/programmable electronic safety-related

173 systems – Part 3: Software requirements
174 ISO 12100:2010, Safety of machinery – General principles for design — Risk assessment and
175 risk reduction
176 ISO 13849-1:2015, Safety of machinery – Safety-related parts of control systems – Part 1:
177 General principles for design
178 ISO 13849-2:2012, Safety of machinery – Safety-related parts of control systems – Part 2:
179 Validation
180 3 Terms, definitions and abbreviations

181 3.1 Alphabetical list of definitions
Term Definition
number
application software 3.2.61
architectural constraint 3.2.48
architecture 3.2.47
average frequency of dangerous failure per hour (PFH) 3.2.31
average probability of dangerous failure on demand (PFDavg) 3.2.33
baseline (configuration) 3.2.69
bypass 3.2.19
common cause failure (CCF) 3.2.58
complex component 3.2.8
configuration management 3.2.68

continuous mode 3.2.30
dangerous failure 3.2.54
demand 3.2.27
diagnostic coverage (DC) 3.2.51
diagnostic test interval 3.2.52
embedded software 3.2.62
failure 3.2.53
fault 3.2.35
fault tolerance 3.2.36
full variability language (FVL) 3.2.63
functional safety 3.2.10
hardware fault tolerance (HFT) 3.2.37
hardware safety integrity 3.2.24
harm 3.2.12
hazard 3.2.11
hazardous situation 3.2.13
ENTWURF OVE
– 16 – IEC CDV 62061  IEC 2019
high demand mode 3.2.29

integrator 3.2.14
limited variability language (LVL) 3.2.64
low complexity component 3.2.7
low demand mode 3.2.28
machine control system 3.2.2
machinery (machine) 3.2.1
mean repair time (MRT) 3.2.42
mean time to failure (MTTF) 3.2.39
mean time to dangerous failure (MTTF D ) 3.2.40
mean time to restoration (MTTR) 3.2.41
muting 3.2.18
pre-designed (SCS or subsystem) 3.2.5
probability of dangerous failure on demand (PFD) 3.2.32
process safety time 3.2.43
proof test coverage (PTC) 3.2.50
protection layer 3.2.16
proof test 3.2.49
protective measure 3.2.15
random hardware failure 3.2.59
ratio of dangerous failure (RDF) 3.2.57
risk 3.2.17
safe failure 3.2.55
safe failure fraction (SFF) 3.2.56

safe state 3.2.70
safety 3.2.9
safety function 3.2.20
safety integrity 3.2.23
Safety Integrity Level (SIL) 3.2.26
safety-related control system (SCS) 3.2.3
safety-related software 3.2.65
security 3.2.71
(SCS) diagnostic function 3.2.21
(SCS) fault reaction function 3.2.22
subsystem 3.2.4
subsystem element 3.2.6
sub-function 3.2.38
systematic failure 3.2.60
systematic safety integrity 3.2.25
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 17 –
target failure value 3.2.34

useful lifetime 3.2.44
validation (of the safety function) 3.2.67
verification 3.2.66
well-tried component 3.2.45
well-tried safety principles 3.2.46
182 3.2 Terms and definitions
183 For the purposes of this document, the following terms and definitions apply.
184 3.2.1
185 machinery
186 machine
187 assembly, fitted with or intended to be fitted with a drive system consisting of linked parts or
188 components, at least one of which moves, and which are joined together for a specific
189 application.
190 Note 1 to entry: The term “machinery” also covers an assembly of machines which, in order to achieve the same
191 end, are arranged and controlled so that they function as an integral whole.
192 [SOURCE: ISO 12100:2010, 3.1]
193 3.2.2
194 machine control system
195 system that responds to input signals from the machinery and/or from an operator and
196 generates output signals causing the machinery to operate in the desired manner.
197 Note 1 to entry: The machine control system includes input devices and final elements.
198 [SOURCE IEC 61508-4, 3.3.3 modified]
199 3.2.3
200 Safety-related Control System
201 SCS
202 part of the control system of a machine which implements a safety function.
203 Note 1 to entry: A SCS is the combination of one or more subsystems necessary to implement the respective safety
204 sub-function(s). See Figure 5.
205 Note 2 to entry: SCS is similar to SRECS of IEC 62061:2015.
206 3.2.4
207 subsystem
208 entity of the top-level architectural design of a safety-related system where a dangerous failure of the
209 subsystem results in dangerous failure of a safety function
210 Note 1 to entry: This differs from common language where “subsystem” may mean any sub-divided part of an
211 entity, the term “subsystem” is used in this standard within a strongly defined hierarchy of terminology: “subsystem”
212 is the first level subdivision of a system. The parts resulting from further subdivision of a subsystem are called
213 “subsystem elements”.
214 Note 2 to entry: A complete subsystem can be made up from a number of identifiable and separate subsystem
215 elements.
216 Note 3 to entry: The subsystem specification includes its role in the safety function and its interface with the other
217 subsystems of the SCS.
218 Note 4 to entry: One subsystem can be part of several safety functions, e.g. the same combination of contactors
219 can be used for de-energise a motor in case of detection of a person in a danger zone and also in case of opening
220 a safe guard.

ENTWURF OVE
– 18 – IEC CDV 62061  IEC 2019
222 3.2.5
223 Pre-designed (SCS or subsystem)
224 SCS or subsystem which meets the relevant requirements of a functional safety standard.
225 Example to entry: when a specific standard is referred to, it might be added in brackets: pre-designed software
226 module (IEC 61508, SC2).
227 3.2.6
228 subsystem element
229 part of a subsystem, comprising a single component or any group of components
230 Note 1 to entry: A subsystem element may comprise hardware and software.
231 Note 2 to entry: Here are not included other elements, which are not directly necessary for the safety function, but
232 may support it (for example, filters elements, protection against over-voltage).
233 Note 3 to entry: The lowest level that the subsystem designer has to consider in order to ensure that the
234 requirements of a sub-function are met.
235 3.2.7
236 low complexity component / subsystem
237 component / subsystem in which
238 – the failure modes are well-defined; and
239 – the behaviour under fault conditions can be completely defined
241 Note 1 to entry: Behaviour of the low complexity component / subsystem under fault conditions may be determined
242 by analytical and/or test methods.
243 Note 2 to entry: Examples of low complexity components / subsystem are limit switches, electro-mechanical relays
244 or contactors.
245 3.2.8
246 complex component / subsystem
247 component / subsystem in which
248 – the failure modes are not well-defined; or
249 – the behaviour under fault conditions cannot be completely defined
250 Note 1 to entry: REMOVED (type B)
251 3.2.9
252 safety
253 freedom from unacceptable risk

254 [SOURCE IEC 61508-4, 3.1.11]
255 3.2.10
256 functional safety
257 part of the overall safety of the machine and the machine control system that depends on the
258 correct functioning of the SCS and other risk reduction measures
259 [SOURCE IEC 61508-4, 3.1.12 modified, using terms machine, machine control system and
260 SCS]
261 Note 1 to entry: ISO/IEC Guide 51 defines safety as freedom from unacceptable risk
262 3.2.11
263 hazard
264 potential source of harm
265 [SOURCE ISO 12100, 3.6]

266 Note 1 to entry: The term hazard can be qualified in order to define its origin or the nature of the expected harm
267 (e.g. electric shock hazard, crushing hazard, cutting hazard, toxic hazard, fire hazard).
268 3.2.12
269 harm
270 injury or damage to the health of people
271 [SOURCE ISO/IEC Guide 51:2014, 3.1, without damage to property or the environment]
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 19 –
272 3.2.13
273 hazardous situation
274 circumstance in which a person is exposed to at least one hazard
275 [SOURCE ISO 12100, 3.10]
276 3.2.14
277 integrator
278 entity who designs, manufactures or assembles an integrated manufacturing system and is in
279 charge of the safety strategy, including the protective measures, control interfaces and
280 interconnections of the control system
281 Note 1 to entry: The integrator may be a manufacturer, assembler, engineering company or the user.
282 [SOURCE ISO 11161:2007, 3.10]
283 3.2.15
284 protective measure
285 measure intended to achieve risk reduction
286 [SOURCE ISO 12100, 3.19 modified]
287 3.2.16
288 protection layer
289 any independent mechanism or circumstances that reduces risk by control, prevention or
290 mitigation
291 NOTE It can be a design feature of the machinery such as guards, fuses, barriers, control functions, safety
292 functions or an administrative procedure such as an emergency plan against an imminent hazard or critical
293 elements of instructions for use.
294 [SOURCE IEC 61511-1:2016, 3.2.57 Modified]
295 3.2.17
296 risk
297 combination of the probability of occurrence of harm and the severity of that harm
298 [SOURCE: ISO/IEC Guide 51:2014, 3.9]

299 3.2.18
300 muting
301 temporary automatic suspension of a safety function(s)
302 Note 1 to entry: Other means are used to maintain the safety level.
303 [SOURCE: ISO 13849-1:2015, 3.1.8 modified]
304 3.2.19
305 bypass
306 action or facility to prevent all or parts of the SCS functionality from being executed.
307 NOTE 1 Examples of bypassing include:
308 – the input signal is blocked from the trip logic while still presenting the input parameters and alarm to the
309 operator;
310 – the output signal from the trip logic to a final element is held in the normal state preventing final element
311 operation;
312 – a physical bypass line is provided around the final element;
313 – preselected input state (e.g., on/off input) or set is forced by means of an engineering tool (e.g., in the
314 application program).
315 NOTE 2 Other terms are also used to refer to bypassing, such as override, defeat, disable, force, or inhibit or
316 muting.
317 [SOURCE IEC 61511-1:2016, 3.2.4 Modified]

ENTWURF OVE
– 20 – IEC CDV 62061  IEC 2019
318 3.2.20
319 safety function
320 function implemented by a SCS with a specified integrity level that is intended to maintain the
321 safe condition of the machine or prevent an immediate increase of the risk(s) in respect of a
322 specific hazardous event
323 Note 1 to entry: This term is used instead of “safety-related control function (SRCF)” of IEC 62061:2015. This
324 definition differs from ISO 12100 because this standard addresses risk reduction performed by SCS.
325 Note 2 to entry: A safety function is typically starting with a detection and evaluation of an ‘initiation event’ and
326 ending with an output causing a reaction of a ‘machine actuator’.
327 Note 3 to entry: Parts of machine operating function(s), e.g. the reaction of a machine actuator, can also be part of
328 safety function(s).

330 3.2.21
331 (SCS) diagnostic function
332 function intended to detect faults in the SCS and initiate a specified fault reaction function
333 when a fault is detected
334 Note 1 to entry: This function is intended to detect faults that could lead to a dangerous failure of a safety function
335 and initiate a specified fault reaction function.
336 3.2.22
337 (SCS) fault reaction function
338 function that is initiated when a fault within a SCS is detected by the SCS diagnostic function
339 3.2.23
340 safety integrity
341 probability of an SCS or its subsystem satisfactorily performing the required safety function
342 under all stated conditions within a stated period of time
343 [SOURCE: IEC 61508-4, 3.5.4 modified]

344 Note 1 to entry: The higher the level of safety integrity of the item, the lower the probability that the item will fail to
345 carry out the required safety function.
346 Note 2 to entry: Safety integrity comprises hardware safety integrity (see 3.2.19) and systematic safety integrity
347 (see 3.2.20).
348 3.2.24
349 hardware safety integrity

350 part of the safety integrity of an SCS or its subsystems comprising requirements for both the
351 probability of dangerous random hardware failures and architectural constraints
352 3.2.25
353 systematic safety integrity
354 part of the safety integrity of a SCS or its subsystems relating to its resistance to systematic
355 failures (see 3.2.51) in a dangerous mode.

357 Note 1 to entry: Systematic safety integrity cannot usually be quantified precisely.
358 Note 2 to entry: Requirements for systematic safety integrity apply to both hardware and software aspects of a SCS
359 or its subsystems.
360 3.2.26
361 Safety Integrity Level
362 SIL
363 discrete level (one out of a possible three) for describing the capability to perform a safety
364 function where safety integrity level three has the highest level of safety integrity and safety
365 integrity level one has the lowest
366 3.2.27
367 demand
368 event that causes the SCS to perform a safety function
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 21 –
369 Note 1 to entry: Demand mode means that a safety function is only performed on request (demand) in order to
370 transfer the machine into a specified state. The SCS does not influence the machine until there is a demand on the
371 safety function.
372 Note 2 to entry: Demand Rate (DR) or the frequency of demands is one of the main factor that is considered for
373 assessing the Demand Mode, Low or High. For this particular purpose the Demand Rate (DR) can be identified with
374 the rate of events, where harm would occur without intervention of the safety function. This rate may be lower than
375 an actual rate of triggering the safety function during operation.
376 NOTE 3 to entry: For an emergency stop function the demand mode is not defined. To determine the achieved SIL
377 the principle for evaluation of the selected demand mode of the other functions is usually applicable.
378 3.2.28
379 low demand mode
380 mode of operation in which the frequency of demands of a safety function is no greater than
381 one per year and no greater than twice the proof-test frequency
382 3.2.29
383 high demand mode
384 mode of operation in which the frequency of demands of a safety function is greater than one
385 per year or greater than twice the proof-test frequency

387 Note 1 to entry: Continuous mode means that a safety function is performed perpetually (continuously), i.e. the
388 SCS is continuously controlling the machine and a (dangerous) failure of its function can result in a hazard.
389 Note 2 to entry: The distinction between high demand and continuous mode is relevant for the qualification of
390 diagnostic measures (refer to clause 7.4.3 and 7.4.4). It is not relevant for target failure measure and SIL
391 assignment.
392 3.2.30
393 continuous mode
394 Mode of operation where the safety function retains the machinery in a safe state as a part of
395 normal operation.

397 Note 1 to entry: Continuous mode means that a safety function is performed perpetually (continuously), i.e. the
398 SCS is continuously controlling the machine and a (dangerous) failure of its function can result in a hazard.
399 Note 2 to entry: The distinction between high demand and continuous mode is relevant for the qualification of
400 diagnostic measures (refer to clause 7.4.3 and 7.4.4). It is not relevant for target failure measure and SIL
401 assignment”
402 3.2.31
403 average frequency of a dangerous failure per hour
404 PFH
405 average frequency of dangerous failure of an SCS to perform a specified safety function over
406 a given period of time
408 3.2.32
409 probability of dangerous failure on demand
410 PFD
411 safety unavailability (see IEC 60050-192) of an SCS to perform the specified safety function
412 when a demand occurs from the Machinery or Machinery control system
413 NOTE 1 The [instantaneous] unavailability (as per IEC 60050-192) is the probability that an item is not in a state to
414 perform a required function under given conditions at a given instant of time, assuming that the required external
415 resources are provided. It is generally noted by U (t).
416 NOTE 2 The [instantaneous] availability does not depend on the states (running or failed) experienced by the item
417 before t. It characterizes an item which only has to be able to work when it is required to do so, for example, an
418 SCS working in low demand mode
419 NOTE 3 If periodically tested, the PFD of an SCS is, in respect of the specified safety function, represented by a
420 saw tooth curve with a large range of probabilities ranging from low, just after a test, to a maximum just before a
421 test.

ENTWURF OVE
– 22 – IEC CDV 62061  IEC 2019
423 3.2.33
424 average probability of dangerous failure on demand
425 PFDavg
426 mean unavailability (see IEC 60050-192) of an SCS to perform the specified safety function
427 when a demand occurs from the Machinery or Machinery control system as an average over
428 time
429 NOTE 1 The mean unavailability over a given time interval [t1, t2] is generally noted by U (t1, t2).
430 NOTE 2 Two kind of failures contribute to PFD and PFDavg: the dangerous undetected failures occurred since the
431 last proof test and genuine on demand failures caused by the demands (proof tests and safety demands)
432 themselves. The first one is time dependent and characterized by their dangerous failure rate λ DU (t) whilst the
433 second one is dependent only on the number of demands and is characterized by a probability of failure per
434 demand (denoted by γ).
435 NOTE 3 As genuine on demand failures cannot be detected by tests, it is necessary to identify them and take them
436 into consideration when calculating the target failure measures.
438 3.2.34
439 target failure value
440 intended PFH or PFD avg to be achieved to meet a specific safety integrity requirement(s)
441 Note 1 to entry:
442 Target failure value is specified in terms of:
443 – the average probability of a dangerous failure of the safety function on demand, (for a low demand mode of
444 operation);
445 – the average frequency of a dangerous failure [h -1 ] (for a high demand mode of operation or a continuous mode
446 of operation)
448 3.2.35
449 fault
450 abnormal condition that may cause a reduction in or loss of, the capability of a SCS, a
451 subsystem, or a subsystem element to perform a required function

453 Note 1 to entry: In IEV 192-04-01 a fault of an item is described as inability to perform as required, due to an
454 internal state 3.2.33

455 3.2.36
456 Fault tolerance
457 ability of a SCS, a subsystem, or subsystem element to continue to perform a required
458 function in the presence of faults or failures
460 3.2.37
461 Hardware fault tolerance
462 HFT
463 a hardware fault tolerance of N means that N+1 faults of a subsystem could cause a loss of
464 the safety function.
465 [SOURCE: IEC 61508-2, 7.4.4]
466 3.2.38
467 sub-function
468 part of a safety function whose failure can result in a failure of the safety function
469 Note 1 to entry: In this standard, a safety function can be seen as a logical AND of the sub-functions.
470 3.2.39
471 Mean Time To Failure
472 MTTF
473 expectation of the mean time to failure
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 23 –
474 [SOURCE: IEV 192-05-11, modified]

475 Note 1 to entry: MTTF is normally expressed as an average value of expectation of the time to failure.
476 3.2.40
477 mean time to dangerous failure
478 MTTF D
479 expectation of the mean time to dangerous failure
480 [SOURCE: IEV 192-05-11, modified]
481
482 3.2.41
483 mean time to restoration
484 MTTR
485 expected time to achieve restoration after a fault has been detected in a safety function by
486 diagnostics and machine continues to operate
487 NOTE MTTR encompasses:
488 • the time to detect the failure (a); and,
489 • the time spent before starting the repair (b); and,
490 • the effective time to repair (c); and,
491 • the time before the component is put back into operation (d)
492 • The start time for (b) is the end of (a); the start time for (c) is the end of (b); the start time for (d) is the
493 end of (c).
494 [Source IEC 61508-4:2010, 3.6.21 Modified]
495 3.2.42
496 Mean repair time
497 MRT
498 mean repair time after a fault has been detected in a safety function by proof test and
499 machine continues to operate
500 NOTE 1 MRT encompasses:
501 • the time spent before starting the repair (b); and,
502 • the effective time to repair (c); and,

503 • the time before the component is put back into operation (d)
504 NOTE 2 Depending on the type of detected fault and the fault reaction the numerical values for MRT and MTTR
505 can be different.
506 [Source IEC 61508-4:2010, 3.6.22 Modified]
507 3.2.43
508 process safety time
509 period of time between a failure, that has the potential to give rise to a hazardous event,
510 occurring in the Machinery or Machinery control system and the time by which action has to
511 be completed in the Machinery to prevent the hazardous event occurring
512 NOTE It is foreseen that the Safety Function detects the failure and completes its action soon enough to prevent
513 the hazardous event taking into account any process lag (e.g. stopping times).
514 [SOURCE: IEC 61508-4:2010, 3.6.20 modified]
515 3.2.44
516 useful lifetime
517 minimum elapsed time between the installation of the SCS or subsystem or subsystem
518 element and the point in time when component failure rates of the SCS or subsystem or
519 subsystem element can no longer be predicted, with any accuracy
520 [SOURCE: IEC 61131-6:2012, 3.57, modified]

521 Note 1 to entry: Typically it will be 20 years or less unless the manufacturers of the SCS and its subsystems can
522 justify a longer lifetime by providing evidence, based on calculations, showing that reliability data is valid for the
523 longer lifetime.
ENTWURF OVE
– 24 – IEC CDV 62061  IEC 2019
524 3.2.45
525 well-tried component
526 for a safety-related application is a component for a safety-related application which has been either
527 a) widely used in the past with successful results in similar safety-related applications as given as well-tried
528 components in the informative annexes of ISO 13849-2, or
529 b) made and verified using principles which demonstrate its suitability and reliability for safety -related
530 applications. ISO 13849-2 lists a variety of components and the conditions for specific technologies under which
531 the component can be considered well-tried.
532 Newly developed components may be considered as equivalent to “well-tried” if they fulfil the conditions of b).
533 The decision to accept a particular component as being “well-tried” depends on the application, e.g. owing to the
534 environmental influences and can be impacted by product or manufacturer changes.
535 Complex electronic components (e.g. PLC, microprocessor, application-specific integrated circuit)
536 cannot be considered as equivalent to “well tried”.
537 Note 1 to entry: a well-tried component is not a proven in use component.
538 3.2.46
539 well-tried safety principles
540 principles have proved effective in the design or integration of safety-related control systems in the past, to avoid
541 or control critical faults or failures which can influence the performance of a safety function
542 Note 1 to entry: Newly developed safety principles may be considered as equivalent to “well-tried” if they are
543 verified using principles which demonstrate their suitability and reliability for safety-related applications.
544 Note 2 to entry: Well-tried safety principles are effective not only against random hardware failures, but also
545 against systematic failures which may creep into the product at some point in the course of the product life cycle,
546 e.g. faults arising during product design, integration, modification or deterioration.
547 Note 3 to entry: Tables A.2, B.2, C.2 and D.2 in the informative annexes of EN ISO 13849-2 address well-tried
548 safety principles for different technologies
549 [SOURCE: ISO 13849-1]

550 3.2.47
551 architecture
552 specific configuration of hardware and software elements in a SCS
554 3.2.48
555 architectural constraint

556 set of architectural requirements that limit the SIL that can be claimed for a subsystem
557 3.2.49
558 proof test
559 periodic test that can detect faults and degradation in a SCS and its subsystems so that, if
560 necessary, the relevant parts of the SCS and its subsystems can be restored to an “as new”
561 condition or as close as practical to this condition
562 [SOURCE: IEC 61508-4:2010, 3.8.5 modified]

563 Note 1 to entry: A proof test is intended to confirm that relevant parts of an SCS are in a condition that assures the
564 specified safety integrity.
565 Note 2 to entry: The effectiveness of the proof test will be dependent both on failure coverage and repair
566 effectiveness. In practice detecting 100 % of the degradation that could lead to the hidden dangerous failures later
567 on is not easily achieved. For complex elements or safety features that are difficult to verify a Proof Test Coverage
568 of 100 % cannot be usually obtained (see PTC definition in Annex D).
569 3.2.50
570 Proof Test Coverage
571 PTC
572 Part of failure rate that is related to safety functionalities that are confirmed and\or restored
573 by the proof test.
574 NOTE 1 If the proof test is perfect PTC=100 % all parameters of the safety functions as specified in the Safety
575 Requirements Specification are verified. It doesn’t include general aging or degradation that has not yet led to a
576 functional failure.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 25 –
577 NOTE 2 It is aim of a proof test to restore aging or degradation to a state that is close to as close as practical to
578 “as new” condition. This is a qualitative requirement of a proof test and only expressed in the PTC when functions
579 are actually impaired.
580 3.2.51
581 diagnostic coverage
582 DC
583 fraction of dangerous failures detected by automatic on-line diagnostic tests. The fraction of
584 dangerous failures is computed by using the dangerous failure rates associated with the
585 detected dangerous failures divided by the total rate of dangerous failures
586 NOTE 1 The dangerous failure diagnostic coverage is computed using the following equation, where DC is the
587 diagnostic coverage, λ DD is the detected dangerous failure rate and λ D total is the total dangerous failure rate:
∑ 𝜆DD
588 𝐷𝐷 = ∑
𝜆Dtotal
589 NOTE 2 This definition is applicable providing the individual components have constant failure rates.
590 [SOURCE: IEC 61508-4:2010, 3.8.6]
591 3.2.52
592 diagnostic test interval
593 interval between on-line tests to detect faults in a subsystem that has a specified diagnostic
594 coverage
595 3.2.53
596 failure
597 termination of the ability of an item (SCS, a subsystem or a subsystem element) to perform a
598 required function
599 [IEC 61508-4, 3.6.4 modified and ISO 12100-1:2010, 3.32]

600 Note 1 to entry: Failures are either random (in hardware) or systematic (in hardware or software).
601 Note 2 to entry: After a failure, the item has a fault.
602 Note 3 to entry: “Failure” is an event, as distinguished from “fault”, which is a state.
603 Note 4 to entry: The concept of failure as defined does not apply to items consisting of software only.
604 3.2.54
605 dangerous failure
606 failure of a SCS, a subsystem, or a subsystem element that plays a part in implementing the
607 safety function that:
608 a) prevents a safety function from operating when required (demand mode) or causes
609 a safety function to fail (continuous mode) such that the machine is put into a
610 hazardous or potentially hazardous state; or
611 b) decreases the probability that the safety function operates correctly when required
613 3.2.55
614 safe failure
615 failure of a SCS, a subsystem, or a subsystem element that plays a part in implementing the
616 safety function that:
617 a) results in the spurious operation of the safety function to put the machine (or part thereof)
618 into a safe state or maintain a safe state; or
619 b) increases the probability of the spurious operation of the safety function to put the machine
620 (or part thereof) into a safe state or maintain a safe state
622 3.2.56
623 Safe Failure Fraction
624 SFF
625 fraction of the overall failure rate of a subsystem that does not result in a dangerous failure
ENTWURF OVE
– 26 – IEC CDV 62061  IEC 2019
626 Note 1 to entry: The diagnostic coverage (if any) of each subsystem in SCS is taken into account in the calculation
627 of the probability of random hardware failures. The safe failure fraction is taken into account when determining the
628 architectural constraints on hardware safety integrity (see 7.4).
629 Note 2 to entry: “No effect failures” and “no part failures” (see IEC 61508-4) is not used for SFF calculations.
630 3.2.57
631 ratio of dangerous failure
632 RDF
633 fraction of the overall failure rate of an element that can result in a dangerous failure
634 3.2.58
635 Common Cause Failure
636 CCF
637 failure, which is the result of one or more events, causing concurrent failures of two or more
638 separate channels in a multiple channel subsystem, leading to failure of a safety function
640 3.2.59
641 random hardware failure
642 failure occurring at a random time, which results from one or more of the possible degradation
643 mechanisms in the hardware
644 [SOURCE: IEC 61508-4, 3.6.5]
645 3.2.60
646 systematic failure
647 failure related in a deterministic way to a certain cause, which can only be eliminated by a
648 modification of the design or of the manufacturing process, operational procedures,
649 documentation or other relevant factors
650 [SOURCE: IEC 61508-4, 3.6.6]

651 Note 1 to entry: Corrective maintenance without modification will usually not eliminate the failure cause.
652 Note 2 to entry: A systematic failure can be induced by simulating the failure cause.
653 Note 3 to entry: Examples of causes of systematic failures include human error in
654  the safety requirements specification;
655  the design, manufacture, installation and/or operation of the hardware;

656  the design and/or implementation of the software.
657 3.2.61
658 application software
659 software specific to the application, that is implemented by the designer of the SCS, generally
660 containing logic sequences, limits and expressions that control the appropriate input, output,
661 calculations, and decisions necessary to meet the SCS functional requirements
662 3.2.62
663 embedded software
664 software, supplied by the manufacturer, that is part of the SCS and relates to the functioning
665 of, and services provided by, the SCS or subsystem, as opposed to the application software
666 Note 1 to entry: Firmware and system software are examples of embedded software.
667 3.2.63
668 Full Variability Language
669 FVL
670 type of language that provides the capability to implement a wide variety of functions and
671 applications
672 [SOURCE: IEC 61511-1:2016, 3.2.81.1.3 modified]

673 Note 1 to entry: Typical example of systems using FVL are general-purpose computers.
674 Note 2 to entry: FVL is normally found in embedded software and is rarely used in application software.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 27 –
675 Note 3 to entry: FVL examples include: Ada, C, Pascal, Instruction List, assembler languages, C++, Java, SQL.
676 3.2.64
677 Limited Variability Language
678 LVL
679 type of language that provides the capability to combine predefined, application specific,
680 library functions to implement the safety requirements specifications
681 [SOURCE: IEC 61511-1:2016, 3.2.75.2 modified]

682 Note 1 to entry: A LVL provides a close functional correspondence with the functions required to achieve the
683 application.
684 Note 2 to entry: Typical examples of LVL are given in IEC 61131-3. They include ladder diagram, function block
685 diagram and sequential function chart. Instruction lists and structured text are not considered to be LVL.
686 Note 3 to entry: Typical example of systems using LVL: Programmable Logic Controller (PLC) configured for
687 machine control.
688 3.2.65
689 safety-related software
690 software that is used to implement safety functions in a safety-related system
691 3.2.66
692 verification
693 confirmation by examination (e.g. tests, analysis) that the SCS, its subsystems or subsystem
694 elements meet the requirements set by the relevant specification

696 Note 1 to entry: EXAMPLE: Verification activities include
697  reviews on outputs (documents from all phases) to ensure compliance with the objectives and requirements of
698 the phase, taking into account the specific inputs to that phase;
699  design reviews;
700  tests performed on the designed products to ensure that they perform according to their specification;
701  integration tests performed where different parts of a system are put together in a step-by-step manner and by
702 the performance of environmental tests to ensure that all the parts work together in the specified manner.
703 3.2.67
704 validation (of the safety function)
705 confirmation by examination (e.g. tests, analysis) that the SCS meets the functional safety
706 requirements of the specific application
708 3.2.68
709 configuration management
710 discipline of identifying the components of an evolving system for the purposes of controlling
711 changes to those components and maintaining continuity and traceability throughout the
712 lifecycle at a specific point of time.
713 [SOURCE: IEC 61508-4, 3.7.3]
714 3.2.69
715 baseline (configuration)
716 A baseline is an agreed set of elements (hardware, software, documentation, tests, …) of a
717 SCS at a specific point in time, which serves as a basis for verification, validation,
718 modification and changes. If an element is changed the status of the baseline is intermediate
719 until a new baseline is defined.
720 3.2.70
721 safe state
722 state of the SCS when safety is achieved
723 Note 1 to entry: The safe state doesn’t include the restoration of initial equipment failures.
724 [SOURCE: IEC61508-4:2010, 3.1.13 Modified]

ENTWURF OVE
– 28 – IEC CDV 62061  IEC 2019
725 3.2.71
726 security
727 1) measures taken to protect a system
728 2) condition of a system that results from the establishment and maintenance of
729 measures to protect the system
730 3) condition of system resources being free from unauthorized access and from
731 unauthorized or accidental change, destruction, or loss
732 4) capability of a computer-based system to provide adequate confidence that
733 unauthorized persons and systems can neither modify the software and its data nor
734 gain access to the system functions, and yet to ensure that this is not denied to
735 authorized persons and systems
736 5) prevention of illegal or unwanted penetration of, or interference with the proper and
737 intended operation of an industrial automation and control system
738 Note 1 to entry: Measures can be controls related to physical security (controlling physical access to computing
739 assets) or logical security (capability to login to a given system and application).
740 [SOURCE: IEC/TS 62443-1-1, 3.2.99]
741 3.3 Abbreviations

742 The following abbreviations are used in this standard.
CCF Common Cause Failure(s)

DC Diagnostic Coverage
EMC Electromagnetic Compatibility
FVL Full Variability Language
I/O Input/Output
LVL Limited Variability Language
HFT Hardware Fault Tolerance
PFH average frequency of dangerous failure per Hour
MRT Mean Repair Time
MTTF Mean Time To Failure
MTTF D Mean Time to Dangerous Failure

MTTR Mean Time To Restoration
PFD probability of dangerous failure on demand
PFDavg average probability of dangerous failure on demand
PL Performance Level
PTC Proof Test Coverage
RDF Ratio of Dangerous Failure
SFF Safe Failure Fraction
SIL Safety Integrity Level
SCS Safety-Related Control System
SRS Safety Requirements Specification
743
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 29 –
744 4 Design process of an SCS and management of functional safety

745 4.1 Objective
746 The objective of Clause 4 is to describe the design process and the tasks that have to be
747 completed to realize each safety function by the related part of the control system for a given
748 machine.
749 4.2 Design process
750 If as result of the risk assessment of the whole machine according to ISO 12100 (see
751 Figure 2) a need for risk reduction has been identified and if certain selected risk reduction
752 measures depend on the control system corresponding safety functions have to be specified.
753 Iteration of risk assessment and risk reduction (can include machinery redesign) can be
754 necessary to eliminate hazards as far as practicable and to adequately reduce risks by the
755 implementation of protective measures.
756 The strategy for risk reduction at the machine is given in ISO 12100, Clause 6 and further
757 guidance is given in Clauses 6.2 (inherent design measures) and 6.3 (safeguarding and
758 complementary protective measures). This strategy covers the whole life cycle of the
759 machine.
760 The SCS shall be designed and constructed so that the principles of ISO 12100 are fully
761 taken into account (see Figure 2). The design of the SCS shall take into account the intended
762 use and reasonably foreseeable misuse of the machine. From the risk reduction strategy, as
763 outlined in ISO 12100 any need for safety function supported by a control system shall be
764 determined. If the selected risk reduction measure depends on the control system then this
765 risk reduction measure shall be fulfilled by a safety function as defined in this standard.
766 The determination of the required performance for the safety function is the result of the risk
767 assessment and refers to the amount of the risk reduction to be carried out by the safety
768 function implemented in the SCS. Examples of a methodology are given in Annex A.
Step 2 of three-step method of ISO 12100
Step 1
YES Is the
Can the risk be

Risk reduction by inherently safe design intended
reduced by inherently safe
measures risk reduction
design measures?
achieved?
NO
NO
Step 2
Risk reduction by safeguarding
Implementation of complementary
YES protective measures Is the
Can the risk be
intended
reduced by guards,
If the selected risk reduction measure depends risk reduction
Protective devices?
on the control system then the SCS can be achieved?
designed by application of IEC 62061
(see Figure 2)
NO
NO
769
770 Figure 2 – Integration within the risk reduction process of ISO 12100 (excerpt)
771 NOTE 1 Figure 2 shows where the SCS contributes to the risk reduction process of ISO 12100: Step 2. The SCS
772 supports the combined protective measures by the implementation of safety functions. ISO 12100 also provides
773 general design rules for the machine which are applicable for the design of the SCS (see 6.2.11 and 6.2.12 of
774 ISO 12100).
775 NOTE 2 A resulting SIL makes no sense for a slipping hazard or falling hazard. Not all aspects of the control
776 system perform safety functions such as some proximity sensors, parts counters, or monitoring devices. There is
777 no need to apply this standard to non-safety-related parts of the control system.
ENTWURF OVE
– 30 – IEC CDV 62061  IEC 2019
778 NOTE 3 In the risk assessment and iterative risk reduction process of ISO 12100, the hazards related to a machine
779 is identified and the risk estimated. As required by ISO 12100, risk estimation initially occurs prior to risk reduction.
780 The initial risk is estimated using one of various risk scoring systems or methods (see for example
781 ISO/TR 14121-2).
782 The design process (see Figure 3) of each safety function implemented by a safety-related
783 control system (SCS) shall include at least the safety function specification (see Clause 5)
784 and the safety-related control system design (see Clause 6) and the associated verification
785 and validation activities.
Information from the risk assessment

(see Figure 1)
Safety Requirements Specification (5.2.1, 5.2.2)

for each
selected
safety Determine the required safety integrity (5.2.3)
function
Design of an SCS to perform a safety function:

Identify the combination of subsystems that
implement the safety function (6)
Pre-designed subsystem(s) ?
(6.2.4)
No
Design and development of subsystems (7) No
No
architecture, PFHD
Yes
Combine subsystems to an SCS (6.2),

considering their systematic integrity (6.3.3,
7.3.2), software (8)
Validation (9):
Are all requirements
met including the required
safety integrity ?
Yes
Have
all safety functions
been analysed ?
Yes
Information to the risk assessment

786
787 NOTE Each step described in the process flow diagram includes also verification activities.
788 Figure 3 – Iterative process for design of the safety-related control system
789 The realization of a safety function following the determined required safety integrity shall
790 either been done by
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 31 –
791 – using an already developed SCS and meeting the required safety integrity, or
792 – designing a new SCS using pre-designed subsystems according to Clause 6 or designing
793 new subsystems according to Clause 7, or a combination of both.
794 If additional design considerations for software are necessary, Clause 8 applies.
795 A safety function can be implemented by one or more subsystem(s) of a safety-related control
796 system (SCS), and several safety functions can share one or more subsystem(s) (e.g. a logic
797 unit, power control element(s)), see examples in Figure 4. A control system can be subdivided
798 into a safety-related part and a non-safety-related part. It is also possible that one subsystem
799 is involved in the implementation of safety functions and control functions. The designer may
800 use any of the technologies available, singly or in combination.
SET
D Q 0 &
0
L CLR Q
Logic subsystem
Input subsystem Output subsystem
(e.g. safety
(e.g. light curtain) (e.g. valves)
controller)
801
802 Figure 4 – Examples of combination of subsystems as one SCS
803 4.3 Management of functional safety using a functional safety plan

804 This sub-clause specifies management and technical activities that are necessary for the
805 achievement of the required functional safety of the SCS.
806 NOTE 1 For further information see IEC 61508-1:2010, clause 6.
807 A functional safety plan shall be drawn up and documented for each SCS design project, and
808 shall be updated as necessary. The functional safety plan is intended to provide measures for
809 preventing incorrect specification, implementation, or modification issues.
810 The functional safety plan shall identify the relevant design activities (see Figure 3) and shall
811 be adapted to the project. See Examples in Annex M.
812 NOTE 2 The functional safety plan can be part of a global machine design plan.
813 NOTE 3 The content of the functional safety plan depends upon the specific circumstances, which can include:
814 – size of project;
815 – degree of complexity;
816 – degree of novelty of design and technology;
817 – degree of standardization of design features;
818 – possible consequence(s) in the event of failure.
819 In particular the functional safety plan shall:
820 a) identify the relevant activities specified in Clauses 5 to 9;

821 b) describe the policy and strategy to fulfil the specified functional safety requirements;
822 c) describe the strategy to achieve functional safety for the application software, results of a
823 development, integration, verification and validation;
824 d) identify persons, departments or other units and resources that are responsible for
825 carrying out and reviewing each of the activities specified in Clauses 5 to 9. The level of
ENTWURF OVE
– 32 – IEC CDV 62061  IEC 2019
826 appropriate competency of the involved persons (i.e. training, technical knowledge,
827 experience and qualifications) should be taken into account.
828 NOTE 4 The appropriateness of competence are considered in relation to the particular application, taking into
829 account all relevant factors including:
830 a) the responsibilities of the person;
831 b) the level of supervision required;
832 c) the potential consequences in the event of failure of the SCS;
833 d) the safety integrity levels of the SCS;
834 e) the novelty of the design, design procedures or application;
835 f) previous experience and its relevance to the specific duties to be performed and the technology being
836 employed;
837 g) the type of competence appropriate to the circumstances (for example qualifications, experience, relevant
838 training and subsequent practice, and leadership and decision-making abilities);
839 h) engineering knowledge appropriate to the application area and to the technology;
840 i) safety engineering knowledge appropriate to the technology;
841 j) knowledge of the legal and safety regulatory framework;
842 k) relevance of qualifications to specific activities to be performed.
843 e) identify or establish the procedures and resources to record and maintain information
844 relevant to the functional safety of a SCS;
845 NOTE 5 The following are considered:
846 - the results of the hazard identification and risk assessment;
847 - the equipment used for safety-related functions together with its safety requirements;
848 - the organization responsible for maintaining functional safety;
849 - the procedures necessary to achieve and maintain functional safety (including SCS modifications).
850 f) describe the strategy for configuration management (see 4.4) taking into account relevant
851 organizational issues, such as authorized persons and internal structures of the
852 organization;
853 g) describe the strategy for modification (see 4.5);
854 h) establish a verification plan that shall include:
855 – details of when the verification shall take place;
856 – details of the persons, departments or units who shall carry out the verification;
857 – the selection of verification strategies and techniques;
858 – the selection and utilization of test equipment;
859 – the selection of verification activities;
860 – acceptance criteria; and
861 – the means to be used for the evaluation of verification results;
862 i) establish a validation plan comprising:
863 – results of previous verification
864 – details of when the validation shall take place;
865 – identification of the relevant modes of operation of the machine (e.g. normal operation,
866 setting);
867 – requirements in respect of which the SCS shall be validated;
868 – the technical strategy for validation, for example analytical methods or statistical tests;
869 – acceptance criteria; and
870 – actions to be taken in the event of failure to meet the acceptance criteria;
871 NOTE 6 The validation plan indicates whether the SCS and its subsystems are to be subject to routine testing,
872 type testing and/or sample testing.
873 4.4 Configuration management
874 The main operational aspects of configuration management are
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 33 –
875 – Identification of the structure of the SCS, identifies e.g. system, subsystems, functions,
876 function blocks, management documents, tools for creating a baseline
877 – Controlling of the release of an element created during each lifecycle phase at a specific
878 point in time
879 – Recording and reporting of the status of each element which is and/or will be part of a
880 baseline
881 – Audit and review of all elements and maintaining consistency among all elements of a
882 baseline
883 Procedures shall be developed for configuration management of the SCS during the overall,
884 SCS system and software safety lifecycle phases, including in particular:
885 a) the point, in respect of specific phases, at which formal configuration control is to be
886 implemented;
887 b) the procedures to be used for uniquely identifying all constituent parts of hardware and
888 software;
889 c) the procedures for preventing unauthorized entering service.
890 The configuration management procedures shall be implemented in accordance with the
891 functional safety plan (see 4.3).
892 The procedures for an appropriate change-control-process shall consider the requirements of
893 procedures for defining a unique baseline of each version of the SCS.
894 4.5 Modification

895 If a modification is to be implemented then relevant activities shall be identified specifically
896 and an action plan shall be prepared and documented before carrying out any modification.
897 NOTE 1 The request for a modification can arise from, for example:
898 – safety requirements specification changed;
899 – conditions of actual use;
900 – incident/accident experience;
901 – change of material processed;
902 – modifications of the machine or of its operating modes.

903 NOTE 2 Interventions (e.g. adjustment, setting, repairs) on the SCS made in accordance with the information for
904 use or instruction manual for the SCS are not considered to be a modification in the context of this Clause.
905 The reason(s) for the request for a modification shall be documented.
906 The effect of the requested modification shall be analyzed to establish the effect on the safety
907 function.
908 The modification impact analysis and the effect on the functional safety of the SCS shall be
909 documented.
910 All accepted modifications that have an effect on the SCS shall initiate a return to an
911 appropriate design phase for its hardware and/or for its software (e.g. specification, design,
912 integration, installation, commissioning, and validation). All subsequent phases and
913 management procedures shall then be carried out in accordance with the procedures
914 specified for the specific phases in this standard. All relevant documents shall be revised,
915 amended and reissued accordingly.
916 5 Specification of a safety function

917 5.1 Objective
918 This Clause sets out the procedures to specify the requirements of safety function(s) to be
919 implemented by the SCS.
920 5.2 Safety Requirements Specification (SRS)

921 Each safety function shall be specified by:
ENTWURF OVE
– 34 – IEC CDV 62061  IEC 2019
922 – functional requirements specification (see 5.2.2);

923 – safety integrity requirements specification (see 5.2.3).
924 and these shall be documented in the safety requirements specification (SRS).
925 Where a product standard specifies the safety requirements for the design of an SCS or
926 subsystem (e.g. ISO 13851 for two-hand control devices), these should be considered.
927 5.2.1 Information to be available

928 The following information shall be used to produce both the functional requirements
929 specification and safety integrity requirements specification of SCS:
930 – results of the risk assessment for the machine including all safety functions determined to
931 be necessary for the risk reduction process for each specific hazard;
932 – machine operating characteristics, including:
933 • modes of operation of machine,
934 • cycle time,
935 • response time performance,
936 • environmental conditions,
937 • interaction of person(s) with the machine (e.g. repairing, setting, cleaning);
938 – all information relevant to the safety function(s) which can have an influence on the SCS
939 design including, for example:
940 • a description of the behaviour of the machine that a safety function is intended to
941 achieve or to prevent;
942 • all interfaces between the safety functions, and between safety functions and any
943 other function (either within or outside the machine);
944 • required fault reaction functions of the safety function.
945 5.2.2 Functional requirements specification
946 The functional requirements specification shall describe details of each safety function to be
947 performed including as applicable:
948 – a description of each safety function;

949 – the condition(s) (e.g. operating mode) of the machine in which the safety function shall be
950 active or disabled;
951 – the condition(s) of the machine in which safety functions can be selected (e.g. by
952 parameterization or configuration)
953 – the priority of those functions that can be simultaneously active and that can cause
954 conflicting action;
955 – the reset of a safety function;
956 – the frequency of operation of each safety function (rate of operating cycles, duty cycle);
957 – demand mode of operation;
958 NOTE For definitions refer to clauses 3.2.23, 3.2.24, 3.2.25.
959 – the required response time of each safety function;

960 – the required response times of subsystem(s);
961 – the interface(s) of the safety functions to other machine functions;
962 – a description of fault reaction function(s) and any constraints on, for example, re-starting
963 or continued operation of the machine in cases where the initial fault reaction is to stop
964 the machine;
965 – tests and any associated facilities (e.g. test equipment, test access ports);
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 35 –
966 – a description of the operating environment (e.g. electromagnetic immunity, temperature,

967 humidity, dust, chemical substances, mechanical vibration and shock);
968 NOTE 1 The specification of the electromagnetic environmental condition is within the scope of IEC 61000-1-2.
969 The electromagnetic environment is defined as the totality of electromagnetic phenomena existing at a
970 particular location. These phenomena can vary over time.
971 The electromagnetic environment is influenced by, for example:
972 - fixed and moving sources of electromagnetic energy,
973 - low, medium and high voltage equipment,
974 - control, signalling, communication and power systems,
975 - intentional radiators,
976 - physical processes (e.g. atmospheric discharges, switching actions),
977 - random or infrequent transients,
978 which all can produce disturbances that adversely impact the safety-related system or element under
979 consideration.
980 – rate of operating cycles, duty cycle, and/or utilisation category, for electromechanical
981 devices intended for use in the safety function;
982 NOTE 2 The duty cycle of subsystems or subsystem elements can be higher than required for the safety
983 function, e.g. when used also for non safety-related machine functions (the total number of cycles is to be
984 considered).
985 – other specific requirements which can impact functional safety.

986 5.2.3 Safety integrity requirements specification
987 The safety integrity requirements for each safety function shall be derived from the risk
988 assessment to ensure the necessary risk reduction can be achieved. In this standard, a safety
989 integrity requirement is expressed as a target failure value for the average frequency of a
990 dangerous failure per hour (PFH).
991 The required safety integrity for each safety function to be carried out by an SCS shall be
992 specified in terms of SIL according to Table 1 and documented.
993 Table 1 – SIL and limits of PFH values
SIL limits of PFH values (1/h)

-
1 < 10 5
-
2 < 10 6
-
3 < 10 7
994 The determination of the required safety integrity is the result of the risk assessment and
995 refers to the amount of the risk reduction to be carried out by the SCS. Examples of a
996 methodology are given in Annex A.
997 NOTE 1 Where a product standard specifies a required SIL for a safety function then this takes precedence over
998 Annex A.
999 NOTE 2 Examples of safety functions are given in Annex I.
1000 6 Design of an SCS

1001 6.1 General
1002 The SCS shall be designed in accordance with the safety requirements specification (see
1003 5.2), using one or several subsystems by:
1004 – selection of subsystems (see 6.2, 6.3 and 7);

1005 – determining the safety integrity (see 6.4);
1006 – complying to the requirements of the systematic safety integrity of the SCS (see 6.5),
1007 including, where applicable, Electromagnetic immunity (see 6.6), security (see 6.8),
1008 periodic testing (see 6.9) and, software (see 6.7 and 8).
1009
ENTWURF OVE
– 36 – IEC CDV 62061  IEC 2019
1010 6.2 Subsystem architecture based on top down decomposition

1011 The following clause describes the design process of an SCS. An SCS can include:
1012 – one or several pre-designed subsystem(s), and/or

1013 – one or several subsystem(s) developed according to this standard, based on subsystem
1014 element(s) (see Clause 7).
1015 NOTE 1 The designer of a pre-designed subsystem can be a manufacturer of the machine or a device
1016 manufacturer.
1017 NOTE 2 The relevant safety integrity characteristic values come from the designer of pre-designed subsystem.
1018 NOTE 3 Clauses 6 and 7 focus on high demand and continuous mode. For low demand mode see Annex D.
1019 6.3 Basic methodology – Use of subsystem

1020 6.3.1 General
1021 Each safety function identified in the risk reduction process (see Clause 4) is performed by an
1022 SCS consisting of one or several subsystems. A failure of any subsystem will result in the loss
1023 of the whole safety function. Clause 6.2 describes the principle of this allocation task.
1024 Where a SCS or part of a SCS (i.e. its subsystem(s)) is to implement both safety functions
1025 and other functions, then all its hardware and software shall be treated as safety-related
1026 unless it can be shown that the implementation of the safety functions and other functions is
1027 sufficiently independent (i.e. that the normal operation or failure of any other functions do not
1028 affect the safety functions).
1029 NOTE 1 Sufficient independence of implementation is established by showing that the probability of a dependent
1030 failure between the non-safety and safety-related parts is equivalent to that of the safety integrity level of the SCS.
1031 IEC 61508-3, Annex F describes techniques for achieving non-interference between software elements.
1032 For a SCS or its subsystems that implements safety functions of different safety integrity
1033 levels, its hardware and software shall be treated as requiring the highest safety integrity level
1034 unless it can be shown that the implementation of the safety functions of the different safety
1035 integrity levels is sufficiently independent.
1036 NOTE 2 Sufficient independence of implementation is established by showing that the probability of a dependent
1037 failure between the non-safety and safety-related parts is sufficiently low in comparison with the highest safety
1038 integrity level associated with the safety functions involved.
1039 Where digital data communication is used as a part of a SCS implementation it shall satisfy
1040 the relevant requirements of IEC 61508-2:2010, 7.4.11 (which refers to IEC 61784-3 series for
1041 functional safety fieldbuses) in accordance with the SIL target(s) of the safety function(s).
1042 6.3.2 SCS architecture design based on subsystems
1043 Each safety function shall be decomposed to a structure of sub-function(s). The

1044 decomposition process shall lead to a structure of sub-functions that fully describes the
1045 functional and integrity requirements of the SCS. This process should be applied down to that
1046 level that permits the functional and integrity requirements determined for each sub-function
1047 to be allocated to a single subsystem.
1048 Figure 5 shows examples of typical decompositions starting with a detection and evaluation of
1049 an ‘initiation event’ and is ending with an output causing a reaction of a ‘machine actuator’.
1050 For each sub-function the following shall be specified:
1051 – the safety requirements (functional and integrity) and

1052 – inputs and outputs of each sub-function.
1053 By the decomposition an initial architecture of the SCS is created by the structure of the sub-
1054 functions.
1055 NOTE 1 The inputs and outputs of each sub-function are the information that is transferred, for example speed,
1056 position, mode of operation, etc.
1057 NOTE 2 The sub-functions can have associated diagnostic functions (see 7.4.3.3, diagnostic coverage).
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 37 –
1058 NOTE 3 An SCS can consist of one single subsystem. Example for a SCS implementation with a single subsystem
1059 is an “Intelligent” sensor unit (e.g. laser scanner) with integrated output switching device (e.g. relay).
1060 NOTE 4 A subsystem which implements a sub-function can consist of more than one physical unit. An example is a
1061 safety controller which has separate input, logic, output (and safety-related fieldbus communication) units. The
1062 manufacturer can provide separately the safety-related data for the units.
1063 Another example is a safety relay module which monitors the status of an input device. When the safety relay
1064 module does not contain enough output contacts for the specific sub-function then an extension safety module can
1065 be added. The manufacturer(s) provides separately the safety-related data for all the modules.
1066 The decomposition of an SCS into subsystems represented in Figure 5 is typical but the
1067 whole SCS can be realized by any number of subsystems.
1068 Figure 5 does not present the possible diagnostic functions that can be required to fulfil the
1069 safety requirements.
1070
Safety Function 1 Virtual view:

Functional description (decomposition)
initiation event sub-function 1 sub-function 2 sub-function 3 machine actuator

(cause) (detection, input) (evaluation, logic) (reaction, output) (effect)
allocation
subsystem 1 subsystem 2 subsystem 3

(e.g. position switches, (e.g. safety controller/ (e.g. contactors,
light curtain) embedded systems) valves)
Real view:
Physical allocation
Safety-related Control System (SCS)
(logical representation)
Safety Function 2 Virtual view:

Functional description (decomposition)
initiation event sub-function 1 sub-function 2 sub-function 3 sub-function 4 machine actuator

(cause) (detection, input) (evaluation, logic) (reaction, output) (reaction, output) (effect)
allocation
subsystem 1 subsystem 2 subsystem 3 subsystem 4
(e.g. safety mats) (e.g. safety (e.g. valves) (e.g. Power Drive System
controller) Safe Torque Off function)
Real view:
Physical allocation
(logical representation)
1071
1072 NOTE 1 The fieldbus communication can be part of one or more subsystems.
1073 NOTE 2 Interconnection (e.g. wiring) aspects can be relevant in subsystem(s) (see 6.3.2.2).
1074 Figure 5 – Examples of typical decomposition of a safety function into sub-functions
1075 and its allocation to subsystems
ENTWURF OVE
– 38 – IEC CDV 62061  IEC 2019
1076 6.3.3 Sub-function allocation

1077 Each sub-function shall be allocated to a subsystem within the architecture of the SCS. More
1078 than one sub-function (for example implementing different safety functions), can be allocated
1079 to a subsystem.
1080 NOTE An example of a subsystem that implements several sub-functions is a safety controller which acts as a logic
1081 solver for guard interlocking function and overspeed protection function.
1082 6.3.4 Use of a pre-designed subsystem

1083 The safety performance of a pre-designed subsystem, according to other standards, shall be
1084 in line with Table 2.
1085 Table 2 – Required SIL and PFH of pre-designed subsystem
IEC 62061 IEC 62061 IEC 61508 Type B ISO 13849 IEC 61496
(IEC 61508) subsystem (see also NOTE 2)
(see also NOTE 1)
PFH SIL at least … at least … at least …
< 10 5
-
SIL 1 SIL 1 PL c Type 2
< 10 6
-
SIL 2 SIL 2 PL d Type 3
< 10 7
-
SIL 3 SIL 3 PL e Type 4
NOTE 1 This column includes SIL-based standards that fulfil the architectural constraints of the IEC 61508,
such as IEC 61800-5-2 and IEC 60947-5-3.
NOTE 2 Does not apply to subsystems using complex components.
NOTE 3 A relation between IEC 62061 and IEC 61511 or ISO 26262 cannot be assumed within this table.
1086 6.4 Determination of safety integrity of the SCS

1087 6.4.1 General
1088 The SIL(s) that can be achieved by the SCS shall be considered separately for each safety
1089 function and shall be determined from the SIL and the average frequency of dangerous
1090 failures per hour (PFH) of each subsystem, as follows:
1091 – the SIL that is achieved is equal to or less than the lowest SIL of any of the subsystems
1092 and
1093 – the SIL is limited by the sum PFH value of all subsystems according to Table 1.
1094 Figure 6 shows an example of an SCS with safety integrity of SIL 2 despite the overall PFH
1095 value being suitable for a higher SIL.
1096
1097 Figure 6 - Example of safety integrity of a safety function based on allocated
1098 subsystems as one SCS
1099
1100 NOTE An SCS can be a combination of subsystems based on different architectures.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 39 –
1101 6.4.2 Average frequency of dangerous failures

1102 The average frequency of a dangerous failure PFH of each safety function due to dangerous
1103 random hardware failures shall be equal to or lower than the PFH of Table 1 related to
1104 required SIL as specified in the safety requirements specification.
1105 The estimation of the average frequency of a dangerous failure shall be based on the
1106 probability of dangerous random hardware failure of each relevant subsystem including,
1107 where appropriate, for digital data communication processes between subsystems. The
1108 probability of dangerous random hardware failure of the SCS is the sum of the probabilities of
1109 dangerous random hardware failure of all subsystems involved in the performance of the
1110 safety function and shall include, where appropriate, the probability of dangerous
1111 communication errors for digital data communication processes (P TE ):
1112 𝑃𝑃𝑃 = 𝑃𝑃𝑃1 + ⋯ + 𝑃𝑃𝑃n + 𝑃TE .

1113 NOTE 1 This approach is based on the definition of a subsystem which states that a failure of any subsystem will
1114 result in a failure of the SCS (see 6.2.1).
1115 NOTE 2 Hardware wiring aspects are part of systematic integrity and possible failures can be detected by
1116 diagnostics.
1117 NOTE 3 For the determination of the P TE , see for example IEC 61784-3.
1118 6.5 Requirements for systematic safety integrity of the SCS
1119 6.5.1 Requirements for the avoidance of systematic hardware failures
1120 6.5.1.1 The following measures shall apply when appropriate:
1121 a) the SCS shall be designed and implemented in accordance with the functional safety plan
1122 (see 4.3);
1123 b) proper selection, combination, arrangements, assembly and installation of subsystems,
1124 including cabling, wiring and any interconnections;
1125 c) use of the SCS within the manufacturer’s specification;
1126 d) use of subsystems that have compatible operating characteristics
1127 NOTE: see also ISO 13849-2:2012, Clauses A.1, B.1, C.1 and D.1.
1128 e) the SCS shall be installed and protected in accordance with IEC 60204-1, including earth
1129 fault detection;
1130 f) undocumented modes of component operation shall not be used (e.g. ‘reserved’ registers
1131 of programmable equipment); and
1132 g) consideration of foreseeable misuse, environmental changes or modification(s)
1133 h) consideration of wiring interconnection of subsystems (single or dual channel). This will
1134 require specific fault considerations and fault exclusions (see 7.3.3);
1135 i) consideration of communication errors. Examples for typical failures are transmission
1136 errors, repetitions, deletion, insertion, re-sequencing and masquerade when data
1137 communication is used for the implementation of a safety function. See IEC 61508-2:2010:
1138 7.4.11.2 and IEC 61784-3:2010, Table 1.
1139 j) manufacturer’s instructions (including e.g. application examples) of both interconnected
1140 subsystems (outputs of the preceding subsystem and inputs of the subsequent
1141 subsystem) shall be applied; these can include:
1142 • Hardware aspects (e.g. interface information, shielding, signal level, pressure
1143 threshold, test pulses, architectural constraints),
1144 • Software aspects (e.g. definition of data communication telegrams) and
1145 • Diagnostic coverage aspects.
1146 6.5.1.2 In addition, at least one of the following techniques and/or measures shall be
1147 applied taking into account the complexity of the SCS and the SIL(s) for
1148 those functions to be implemented by the SCS:
1149 a) SCS hardware design review (e.g. by inspection or walk-through): to reveal by reviews
1150 and/or analysis any discrepancies between the specification and implementation;
ENTWURF OVE
– 40 – IEC CDV 62061  IEC 2019
1151 NOTE 1 In order to reveal discrepancies between the specification and implementation, any points of doubt
1152 or potential weak points concerning the realization, the implementation and the use of the product are
1153 documented so they can be resolved; taking into account that on an inspection procedure the author is passive
1154 and the inspector is active whilst on a walk-through procedure the author is active and the inspector is
1155 passive.
1156 b) advisory tools such as computer-aided design packages capable of simulation or analysis,
1157 and/or the use of computer-aided design tools to perform the design procedures
1158 systematically with the use of pre-designed elements that are already available and
1159 tested;
1160 NOTE 2 The integrity of these tools can be demonstrated by specific testing, or by an extensive history of
1161 satisfactory use, or by independent verification of their output for the particular SCS that is being designed.
1162 c) simulation: perform a systematic and complete assimilation of a SCS design in terms of
1163 both functional performance and the correct dimensioning and interaction of its
1164 subsystems.
1165 EXAMPLE The functions of the SCS can be simulated on a computer via a software behavioural model where
1166 individual subsystems or subsystem elements each have their own simulated behaviour, and the response of
1167 the circuit in which they are connected is examined by looking at the marginal data of each subsystem or
1168 subsystem element.
1169 6.5.2 Requirements for the control of systematic faults

1170 The following measures shall be applied:
1171 a) use of de-energization: the SCS shall be designed so that with loss of its electrical supply
1172 a safe state of the machine is achieved or maintained;
1173 b) measures to control the effect of temporary subsystem failures: the SCS shall be designed
1174 so that, for example:
1175 • voltage variation (e.g. interruptions, dips) to an individual subsystem or a part of a
1176 subsystem does not lead to a hazard (e.g. a voltage interruption that affects a motor
1177 circuit shall not cause an unexpected start-up when the supply is restored), and
1178 NOTE 1 See also relevant requirements of IEC 60204-1. In particular:
1179 overvoltage or undervoltage should be detected early enough so that all outputs can be switched to a safe
1180 condition by the power-down routine or a switch-over to a second power unit; and/or
1181 where necessary, overvoltage or undervoltage should be detected early enough so that the internal state
1182 can be saved in non-volatile memory, so that all outputs can be set to a safe condition by the power-down
1183 routine, or all outputs can be switched to a safe condition by the power-down routine or a switch-over to a
1184 second power unit.

1185 See also relevant information in IEC 61131-2.
1186 • the effects of electromagnetic interference from the physical environment or a

1187 subsystem(s) do not lead to a hazard;
1188 c) measures to control the effects of errors and other effects arising from any data
1189 communication process, including transmission errors, repetitions, deletion, insertion, re-
1190 sequencing, corruption, delay and masquerade;
1191 NOTE 2 Further information can be found in IEC 61784-3 and IEC 61508-2.
1192 NOTE 3 The term ‘masquerade’ means that the true contents of a message are not correctly identified. For
1193 example, a message from a non-safety component is incorrectly identified as a message from a safety
1194 component.
1195 d) when a dangerous fault occurs at an interface, the fault reaction function shall be
1196 performed before the hazard due to this fault can occur. When a fault that reduces the
1197 hardware fault tolerance to zero occurs, this fault reaction shall take place before the
1198 estimated MTTR (see D.3.2.1) is exceeded.
1199 The requirements of item d) apply to interfaces that are inputs and outputs of subsystems and
1200 all other parts of subsystems that include or require cabling during integration (for example
1201 output signal switching devices of a light curtain, output of a guard position sensor).
1202 NOTE 4 This does not require that a subsystem or subsystem element on its own has to detect a fault on its
1203 outputs(s). The fault reaction function may also be initiated by any subsequent subsystem after a diagnostic test is
1204 performed.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 41 –
1205 6.6 Electromagnetic immunity

1206 The function of electrical or electronic safety-related systems shall not be affected by external
1207 influences in a way that could lead to an unacceptable risk of harm to persons. Acceptable
1208 performance with respect to electromagnetic disturbances is therefore mandatory. A
1209 comprehensive safety analysis shall include the effects of electromagnetic disturbances and
1210 the electromagnetic immunity limits that are required to achieve functional safety. These limits
1211 should be derived taking into account both the electromagnetic environment and the required
1212 safety integrity levels.
1213 The SCS shall fulfil the applicable requirements of IEC 61000-1-2.
1214 NOTE 1 The appropriate immunity levels in the case of industrial environments are given by IEC 61326-3-1 or IEC
1215 61000-6-7 as a minimum.
1216 NOTE 2 If a subsystem has been designed following appropriate safety-related product standard (e.g.
1217 IEC 61496-1, etc.) or to IEC 61326-3-1 or IEC 61000-6-7 it can be possible that information is supplied with the
1218 subsystem that facilitates verification of the SCS level requirements by analysis.
1219 NOTE 3 Guidance design principles are available in EMC standards, but functional safety standards require higher
1220 immunity levels. It is important to recognise that higher immunity levels, or additional immunity requirements, than
1221 those specified in such standards can be necessary for particular locations or when the equipment is intended for
1222 use in harsher, or different, electromagnetic environments.
1223 6.7 Software based manual parameterization
1224 6.7.1 General
1225 Some safety related subsystems or SCS need parameterization to carry out a safety function
1226 or a sub-function. For example a converter with integrated sub-functions has to be
1227 parameterized via a PC-based configuration tool, with respect to the upper safe speed limit.
1228 Similarly, to properly establish the detection zone of a laser scanner, parameters such as
1229 angle and distance can need to be configured per the manufacturer’s safety documentation
1230 and the machine risk assessment.
1231 The objective of the requirements for software based manual parameterization is to guarantee
1232 that the safety-related parameters specified for a safety function or a sub-function are
1233 correctly transferred into the hardware performing the safety function or a sub-function.
1234 Different methods can be applied to set such parameters; even dip switch based
1235 parameterization can be used to set or change safety-related parameters. However, PC-
1236 based tools with dedicated parameterization software, commonly called configuration or
1237 parameterization tools, are becoming more prevalent. This subclause is limited in scope to
1238 only manual, software based parameterization that is performed and controlled by an
1239 authorized person.
1240 NOTE 1 Safety-related parameterization which is carried out automatically without human interaction, for example,
1241 based on input signals, is not considered in this clause.
1242 NOTE 2 Direct control of a machine by an operator, e.g. speed control of a forklift truck is not considered as
1243 manual parameterization as described in this subclause.
1244 NOTE 3 If the configuration or parameterization tool is pre-designed in accordance with IEC 61508, for example
1245 together with its dedicated subsystem, it is assumed that there will be no dangerous failures due to the influences
1246 listed in 6.5.2 or any other influence that is reasonable foreseeable. The requirements of 6.5.5 apply when a
1247 software based manual parameterization is performed with the pre-designed tool.
1248 NOTE 4 If a safety-related subsystem or SCS is not capable of being parameterized by software based manual
1249 parameterization as described above, 6.5 does not apply.
1250 6.7.2 Influences on safety-related parameters
1251 During software based manual parameterization the parameters can be affected by several
1252 influences, such as:
1253 – data entry errors by the person responsible for parameterization;

1254 – faults of the software of the parameterization tool;
1255 – faults of further software and/or service provided with the parameterization tool;
1256 – faults of the hardware of the parameterization tool;
1257 – faults during transmission of parameters from the parametrization tool to the SCS or a
1258 subsystem;
1259 – faults of the SCS or a subsystem to store transmitted parameters correctly;
ENTWURF OVE
– 42 – IEC CDV 62061  IEC 2019
1260 – systematic interference during the parameterization process, e.g. by Electromagnetic

1261 Interference or loss of power.
1262 – interference due to external influences or factors, such as Electromagnetic Interference or
1263 (random) loss of power.
1264 With no measures applied to counteract, avoid or control potential dangerous failures caused
1265 by the influences listed above, such influence can lead to the following:
1266 – parameters are not updated by the parameterization process, completely or in parts
1267 without notice to the person responsible for the parametrization;
1268 – parameters are incorrect, completely or in parts;
1269 – parameters are applied to an incorrect device, such as when transmission of parameters is
1270 carried out via a wired or wireless network.
1271 6.7.3 Requirements for software based manual parameterization
1272 Software based manual parameterization shall use a dedicated tool provided by the
1273 manufacturer or supplier of the SCS or the related subsystem(s). This tool shall have its own
1274 identification (name, version, etc.). The SCS or the related subsystem(s) and the
1275 parameterization tool shall have the capability to prevent unauthorized modification, for
1276 example by using a dedicated password.
1277 Parameterization while the machine is running shall be permitted only if it does not cause an
1278 unsafe state.
1279 It is possible to fulfil the requirements by using a pre-designed subsystem or the design shall
1280 follow this standard as detailed below.
1281 When using a pre-designed SCS or subsystem that is capable of software based manual
1282 parameterization, the target is to prevent dangerous failure due to the influences listed in
1283 6.5.2 or any other influence that is reasonable foreseeable. The validation of the pre-designed
1284 subsystem shall include the issue of parameterization.
1285 When a SCS or subsystem that is capable of software based manual parameterization is
1286 designed according to this standard there shall be no dangerous failure due to the influences
1287 listed above or any other influence that is reasonable foreseeable. The following requirements
1288 shall be fulfilled in addition.
1289 a) The design of the software based manual parameterization shall be considered as a
1290 safety-related aspect of SCS design that is described in a safety requirements
1291 specification, e.g. the software safety requirements specification (see 8.3.2.2 and 8.4.2.2).
1292 b) The SCS or subsystem shall provide means to check the data plausibility, e.g. checks of
1293 data limits, format and/or logic input values.
1294 c) The integrity of all data used for parameterization shall be maintained. This shall be
1295 achieved by applying measures to
1296 • control the range of valid inputs;
1297 • control data corruption before transmission;
1298 • control the effects of errors from the parameter transmission process;
1299 • control the effects of incomplete parameter transmission;
1300 • control the effects of faults and failures of hardware and software of the
1301 parameterization; and
1302 • control the effect of the interruption of the power supply.
1303 d) The parameterization tool shall fulfil all relevant requirements for a subsystem according
1304 to IEC 61508 to ensure correct parameterization.
1305 e) Alternatively to d) a special procedure shall be used for setting the safety-related
1306 parameters. This procedure shall include confirmation of input parameters to the SCS by
1307 either:
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 43 –
1308 • retransmitting of modified parameters to the parameterization tool; or

1309 • other means to confirm the integrity of the parameters
1310 as well as subsequent confirmation, for example by a suitably skilled person and by
1311 means of an automatic check by a parameterization tool. New values of safety-related
1312 parameters shall not be activated before the changes are acknowledged and confirmed.
1313 NOTE This is of particular importance where a parameterization software tool uses a device not specifically
1314 intended for this purpose (e.g. personal computer or equivalent).
1315 The software modules used for encoding/decoding within the transmission/retransmission
1316 process and software modules used for visualization of the safety-related parameters to
1317 the user shall, as a minimum, use diversity in function(s) to avoid systematic failures.
1318 6.7.4 Verification of the parameterization tool
1319 As a minimum, the following verification activities shall be performed to verify the basic
1320 functionality of the parameterization tool:
1321 – verification of the correct setting for each safety-related parameter (minimum, maximum
1322 and representative values);
1323 – verification that the safety-related parameters are checked for plausibility, for example by
1324 detection of invalid values, etc.;
1325 – verification that means are provided to prevent unauthorized modification of safety-related
1326 parameters;
1327 NOTE This is of particular importance where the parameterization is carried out using a device not specifically
1328 intended for this purpose (e.g. personal computer or equivalent).
1329 6.7.5 Performance of software based manual parameterization
1330 Software based manual parameterization shall be carried out using the dedicated
1331 parameterization tool provided by the manufacturer or supplier of the SCS or the related
1332 subsystem(s) and shall be documented according to the requirements given in the information
1333 for use. This information can originate from different parties, see also 10.3 (information for
1334 use). Protective measures against unauthorized access shall be activated and used.
1335 The initial parameterization, and subsequent modifications to the parameterization, shall be
1336 documented. The documentation shall include:
1337 a) the date of initial parameterization or change;

1338 b) data or version number of the data set;
1339 c) name of the person carrying out the parameterization;
1340 d) an indication of the origin of the data used (e.g. pre-defined parameter sets);
1341 e) clear identification of safety related parameters.
1342 6.8 Security aspects

1343 Security aspects are considered in the security lifecycle of the machine (or higher system
1344 level) and throughout the life cycle of the machine.
1345 NOTE 1 Security aspects can include intentional attacks on the hardware, application programs and related
1346 software, as well as unintended events resulting from human error.
1347 When security countermeasures are applied they shall not adversely affect safety integrity
1348 (e.g. increase in response time etc.). This can require an iterative multi-disciplinary team
1349 analysis.
1350 When security countermeasures implemented within the SCS are declared then information
1351 should be provided as appropriate.
1352 This standard does not provide specific measures for security aspects.
1353 NOTE 2 Guidance to identify security countermeasures and requirements applicable to SCS security is provided in draft of
1354 IEC TR 63074 (44_764e_NP, IEC/ TC 44 WG 15), ISA TR84.00.09, ISO/IEC 27001:2013, ISO TR 22100-4 and IEC 62443
1355 series.
ENTWURF OVE
– 44 – IEC CDV 62061  IEC 2019
1356 6.9 Aspects of periodic testing

1357 6.9.1 General principle
1358 Periodic testing of the safety function or sub-functions serves two different purposes:
1359 – periodic testing confirms at a given point of time that the tested function is not failed;
1360 – periodic testing in conjunction with inspections assures that the boundary conditions for
1361 equipment reliability figures are met.
1362 In general two types of periodic testing are distinguished (diagnostic test and proof test):
1363 – diagnostic tests are carried out automatically (initiated automatically or manually) and
1364 frequently (related to the process safety time and demand rate);
1365 NOTE 1 Periodic testing can apply to a sub-function or a safety function.
1366 – proof tests try to verify the complete function, typically by simulating the dangerous
1367 condition to the sensors or at least to the logic solver. Also, inspections for ageing and
1368 degradation of components are done as part of proof tests.
1369 NOTE 2 The dangerous failures that cannot be detected by the diagnostics are considered to be undetected
1370 dangerous failures (related failure rate λ DU ). These failures can only be found by the proof-test.
1371 In order to use periodic testing as safety integrity assurance, the following conditions shall be
1372 met by both diagnostic and proof testing:
1373 – in the test procedure, a fault reaction shall be implemented to set the relevant parts of the
1374 machine in a safe state as consequence of a detected fault;
1375 NOTE 3 The nature of fault reaction can be different for diagnostic and proof test and this also depend on the
1376 demand mode and architecture. For architecture of functions without hardware fault tolerance and high or
1377 continuous demand it is usually required to immediately shut-down the machinery.
1378 – the proof test interval shall be adequate to reveal failures in respect to demand rate;
1379 – for diagnostic tests see also 7.4.3 and 7.4.4 for specific requirements.
1380 6.9.2 Proof test
1381 The entire safety function shall be tested including the input, the logic solver and the output
1382 (e.g., shutdown valves and motors). This includes also side functionalities such as bypass
1383 functions, manual reset, diagnostic function(s) and similar.
1384 NOTE 1 Testing of the SCS can be performed either end-to-end or in segments.
1385 A proof test can need some time to be achieved. During this time the safety-related control
1386 system can be inhibited partially or completely. The proof test duration can be neglected only
1387 if the part of the safety related system under test remains available in case of a demand for
1388 operation or if the machine is shut down during the test.
1389 NOTE 2 Proof tests are usually performed at pre-defined test intervals which are typically in the range of months or
1390 more.
1391 NOTE 3 A proof test can also be performed for a specific component by exchanging it with a new one and
1392 conducting the test for the overall system after the exchange. In this case the proof test interval is the same as the
1393 lifetime of the component.
1394 NOTE 4 Particular attention can be made to identify failure causes that can lead to common cause failures.
1395 NOTE 5 Functional test procedures can also emphasize the need to avoid introducing common cause failures.
1396 Proof test procedures shall include a description of the actions to take, regarding the
1397 operation of the machine, should repair be required. W here relevant, including the time
1398 interval that can be allowable for operating the machinery without repair (MRT) and that the
1399 proof test shall be repeated after the repair is completed.
1400 NOTE 6 Additional tests and investigations can be necessary after repair or replacement.
1401 Proof tests shall be described in a written procedure to reveal undetected faults.
1402 In the information for use it shall be specified how the entire safety function shall be
1403 functionally tested before putting into service.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 45 –
1404 The proof test interval is an input to the formulae for the calculation of random hardware
1405 failure.
1406 NOTE 7 Different subsystems can require different proof test intervals, for example, sensors can require a different
1407 proof test interval than final elements.
1408 The overall efficiency of the proof test procedure shall be subject to validation.
1409 7 Design and development of a subsystem

1410 7.1 General
1411 The subsystem shall be designed in accordance with its safety requirements specification
1412 (see 5.2), including basically:
1413 – the functional requirements;

1414 – the requirements for hardware safety integrity:
1415 • architectural constraints (see 7.4) and
1416 • probability of dangerous hardware failures (see 7.6);
1417 – the requirements for systematic integrity (see 7.3.2 and estimation of CCF in Annex F);
1418 – the requirements for subsystem behaviour on detection of a fault (fault reaction) (see
1419 7.4.3);
1420 – the requirements for software (see Clause 8).
1421 The following information of Table 3 shall be available where relevant for each subsystem
1422 during the design and development.
1423 Table 3 – Relevant information for each subsystem
Functional description
1) A functional description of the function(s) and interface(s) of the subsystem.
Hardware information
2) The estimated rates of failure (due to random hardware failures and failure modes) for each subsystem
element which could cause a dangerous failure of the subsystem (see Annex C);
3) Any test and/or maintenance requirements;

4) The probability of dangerous communication errors for digital data communication processes, where
applicable.
Environmental conditions
5) The environment and operating conditions which should be observed in order to maintain the validity of the
estimated rates of failure due to random hardware failures;
6) The useful lifetime (see 7.3.4.2) of the subsystem which should not be exceeded, in order to maintain the
validity of the estimated rates of failure due to random hardware failures.
Design information
7) The diagnostic coverage and/or safe failure fraction and the diagnostic test interval (see 7.4.3 and 7.4.4);
8) Limits on the application of the subsystem which should be observed in order to avoid or control systematic
failures;
9) Information which is required to identify the hardware and software configuration of the subsystem;
10) The highest SIL that can be claimed for a safety function under consideration which uses the subsystem on
the basis of:
- architectural constraints,
- measures and techniques used to avoid or control systematic faults being introduced during the design
and implementation of the hardware and software of the subsystem, and
- the design features that make the subsystem tolerant against systematic faults.
NOTE One subsystem can implement sub-functions of several safety functions with different SIL.
ENTWURF OVE
– 46 – IEC CDV 62061  IEC 2019
1424 7.2 Subsystem architecture design

1425 The architecture of a subsystem is defined by a process of functional decomposition similar
1426 as that of the complete safety function that leads to the SCS architecture - see clause 6.2.2.:
1427 The specific sub-function of the subsystem can be decomposed into sub-functions of the next
1428 lower order which are then assigned to subsystem elements.
1429 As a result a set of subsystem element(s) can be defined that meets the functional
1430 requirements and the integrity requirements of the sub-function.
1431 NOTE 1 A subsystem can be designed by using one single subsystem element.
1432 NOTE 2 The decomposition into subsystem element(s) can be an iterative process.
1433 NOTE 3 The failure of a subsystem element does not necessarily result in a failure of the subsystem or sub-
1434 function. Where subsystem elements are parts of redundant channels, a single element failure will not result in a
1435 failure of the safety function.
1436 The design of the subsystem architecture shall be documented in terms of its subsystem
1437 elements and their interrelationships, e.g. circuit diagram with description, safety-related
1438 block diagram.
1439 Subsystem(s) incorporating complex components shall comply with appropriate product
1440 standards or IEC 61508-2 and IEC 61508-3 as appropriate for the required SIL and the design
1441 shall use Route 1 H (see IEC 61508-2:2010, 7.4.4.2) for high demand and\or continuous mode.
1442 Where a subsystem design includes such a complex component as a subsystem element, it
1443 can be considered as a low complexity component in the context of a subsystem design since
1444 its relevant failure modes, behaviour on detection of a fault, rate of failure, and other safety-
1445 related information are known. Such components shall only be used in accordance with its
1446 specification and the relevant information for use provided by its manufacturer.
1447 NOTE 4 In this standard, it is presumed that the design of complex programmable electronic subsystems or
1448 subsystem elements conforms to the relevant requirements of IEC 61508 and uses Route 1 H (see IEC 61508-
1449 2:2010, 7.4.4.2).
1450 Route 2 H (see IEC 61508-2:2010, 7.4.4.3) may only be used for low complexity components in
1451 low demand mode of operation in combination with route 2S of IEC 61508. The requirements
1452 of IEC 61508-2:2010 (Clause 7.4.10) shall be met where applicable.
1453 7.3 Requirements for the selection and design of subsystem and subsystem elements
1454 7.3.1 General

1455 There are two types of requirements to subsystems and subsystem elements:
1456 – qualitative requirements: systematic integrity; fault consideration(s) and fault exclusion(s);
1457 – quantitative requirements: failure rate and other relevant parameters.
1458 Qualitative requirements are defined in the following sub-clauses 7.3.2 and 7.3.3. Where not
1459 explicitly stated otherwise, these requirements apply independently of the SIL requirement to
1460 the safety function from SIL1 up to SIL3.
1461 NOTE: SIL 4 is not considered in this standard, as it is not suitable to the risk reduction requirements associated
1462 with machinery. For requirements applicable to SIL 4, see IEC 61508-1 and IEC 61508-2.
1463 The quantitative requirements are described in clause 7.4 in general terms and for
1464 determination of probability of dangerous random hardware failures refer to clauses 6.3.2 and
1465 7.6.
1466 7.3.2 Systematic integrity

1467 7.3.2.1 General
1468 The systematic safety integrity requirements for a subsystem are met by fulfilling the
1469 requirements in 7.3.2.2 and 7.3.2.3 and are the same for SIL 1, SIL 2 and SIL 3.
1470 NOTE The subsystem can be partitioned into subsystem elements, pre-designed in agreement with IEC61508, with
1471 different systematic capability level. Then the systematic capability of one subsystem element can potentially limit
1472 the SIL level of its subsystem. For additional details see IEC61508-2:2010.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 47 –
1473 7.3.2.2 Requirements for the avoidance of systematic failures

1474 The following measures shall all be applied if applicable:
1475 – appropriate selection, combination, arrangements, assembly and installation of

1476 components, including cabling, wiring and any interconnections:
1477 Apply manufacturer's application notes, e.g. user manual, installation instructions,
1478 specifications and use of good engineering practice (e.g. IEC 60204-1);
1479 – use of the subsystem and subsystem elements within the manufacturer’s specification and
1480 installation instructions;
1481 – compatibility: Use components with compatible operating characteristics;
1482 – withstanding specified environmental conditions:
1483 Design the subsystem so that it is capable of working in all expected environments and in
1484 any foreseeable adverse conditions (within the defined limit of use), for example
1485 temperature, humidity, vibration and electromagnetic fields;
1486 – use of components that are in accordance with an applicable standard and have their
1487 failure modes well-defined: to reduce the risk of undetected faults by the use of
1488 components with specific characteristics;
1489 NOTE 1 Components such as hydraulic or pneumatic valves can require cyclic switching to avoid the failure
1490 mode of non-switching or unacceptable increase in switching times. In this case a periodic test can be
1491 necessary.
1492 – use of suitable materials and adequate manufacturing:

1493 Selection of material, manufacturing methods and treatment in relation to, for example
1494 stress, durability, elasticity, friction, wear, corrosion, temperature, conductivity, dielectric
1495 strength;
1496 – correct dimensioning and shaping:
1497 Consider the effects of, for example, stress, strain, fatigue, temperature, surface
1498 roughness, manufacturing tolerances.
1499 NOTE 2 IEC 61508-2:2010, Annex F specifies techniques and measures for avoidance of systematic failures during
1500 design and development of application-specific integrated circuits (ASICs), field programmable gate arrays
1501 (FPGAs), programmable logic devices (PLDs) etc.
1502 NOTE 3 Table B.1 to B.5 of IEC61508-2:2010 Annex B give techniques and measures to avoid failures in safety-
1503 related systems which can be useful during specification, design, integration, operation, maintenance and
1504 validation phases.
1505 In addition, one or more of the following measures shall be applied if applicable:
1506 a) hardware design review (e.g. by inspection or walk-through):

1507 To reveal by reviews and/or analysis discrepancies between the specification and
1508 implementation;
1509 NOTE 4 In order to reveal discrepancies between the specification and implementation, any points of doubt or
1510 potential weak points concerning the realization, the implementation and the use of the product are documented so
1511 they can be resolved; it is recommended that on an inspection procedure the author is passive and the person
1512 inspecting is active whilst on a walk-through procedure the author is active and the person inspecting is passive.
1513 b) computer-aided design tools capable of simulation or analysis:

1514 Perform the design procedure systematically and include appropriate automatic
1515 construction elements that are already available and tested;
1516 NOTE 5 These tools can be qualified by specific testing, or by an extensive history of satisfactory use, or by
1517 independent verification of their output for the particular subsystem that is being designed.
1518 c) simulation:
1519 Perform a systematic simulation of a subsystem design in terms of both the functional
1520 performance and the correct dimensioning of their components.
1521 NOTE 6 The function of the subsystem can be simulated on a computer via a software behavioral model where
1522 individual components of the circuit each have their own simulated behavior, and the response of the subsystem in
1523 which they are connected is examined by looking at the marginal data of each component.
1524 7.3.2.3 Requirements for the control of systematic failures
1525 The following measures shall all be applied if applicable:
1526 a) measures to control the effects of insulation breakdown, voltage variations and
1527 interruptions, overvoltage and undervoltage: subsystem behaviour in response to
ENTWURF OVE
– 48 – IEC CDV 62061  IEC 2019
1528 insulation breakdown, voltage variations and interruptions, overvoltage and undervoltage
1529 conditions shall be pre-determined so that the subsystem can achieve or maintain a safe
1530 state of the SCS;
1531 NOTE 1 Further information can be found in IEC 60204-1 and IEC 61508-7:2010, A.8.
1532 b) measures to control or avoid the effects of the physical environment (for example,
1533 temperature, humidity, water, vibration, dust, corrosive substances, electromagnetic
1534 interference and its effects): subsystem behaviour in response to the effects of the
1535 physical environment shall be pre-determined so that the SCS can achieve or maintain a
1536 safe state of the machine. See also IEC 60529, IEC 60204-1 and IEC 60721 series;
1537 c) measures to control or avoid the effects of temperature increase or decrease, if
1538 temperature variations can occur: the subsystem should be designed so that, for
1539 example, over-temperature can be detected before it begins to operate outside
1540 specification;
1541 NOTE 2 Further information can be found in IEC 61508-7:2010, Clause A.10.
1542 d) measures to control the effects of hose breakdown, pressure variations and interruptions,
1543 too low or too high pressure: subsystem behaviour in response to hose breakdown,
1544 pressure variations and interruptions, too low or too high pressure shall be pre-
1545 determined so that the subsystem can achieve or maintain a safe state of the SCS.
1546 NOTE 3 Further information can be found in ISO 4414:2010 for pneumatic systems or ISO 4413 for hydraulic
1547 systems.
1548 When PELV/SELV power supply (see IEC 60364-4-41, 414) is used, the over voltage at the
1549 output in event of a single fault shall be taken into account in the analysis of the effects of
1550 over voltage including the possibility of common cause failure.
1551 NOTE 7 over voltage ranges are given for example in IEC 60950-1, IEC 60204-1, IEC 61204-7, IEC 62477, IEC
1552 60449.
1553
1554 In addition, the following basic safety principles, as appropriate, shall be applied for the
1555 control of systematic failures:
1556 – use of de-energization:
1557 The subsystem should be designed so that with loss of its power supply a safe state of the
1558 machine can be achieved or maintained;
1559 NOTE 8 For further information see ISO 13849-2.

1560 – measures for controlling the effects of errors and other effects arising from any data
1561 communication process (see IEC 61508-2:2010, 7.4.11).
1562 Depending on the selected architecture of the subsystem, the following well tried safety
1563 principles, as appropriate, shall be applied to the subsystem element for the control of
1564 systematic failures:
1565 – failure detection by automatic tests;
1566 – tests by comparison of redundant hardware;
1567 NOTE 9 For further information see ISO 12100:2010, 6.2.12.4.
1568 – diverse hardware;
1569 – operation in the positive mode (e.g. a limit switch is pushed when a guard is opened);
1570 – mechanically linked contacts;
1571 – direct opening action;
1572 – oriented mode of failure;
1573 NOTE 10 For further information see ISO 12100:2010, 6.2.12.3.
1574 – over-dimensioning by a suitable factor can improve reliability and an appropriate factor of
1575 over-dimensioning shall be determined
1576 NOTE 4 For further information see ISO 13849-2 and Annex A of IEC61508-2:2010.
1577 7.3.2.4 Electromagnetic immunity
1578 Subsystem design shall take into account the requirements of 6.4.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 49 –
1579 7.3.2.5 Security aspects

1580 Subsystem design shall take into account the requirements of 6.6.
1581 7.3.3 Fault consideration and fault exclusion
1582 7.3.3.1 General
1583 All subsystem elements shall be designed to achieve the required safety requirement
1584 specification. The ability to resist faults shall be assessed. Where not explicitly stated
1585 otherwise, the requirements of this clause apply independently of the required safety integrity
1586 of the safety function.
1587 7.3.3.2 Fault consideration

1588 To estimate the capability of a subsystem element to reach a certain safe state, an analysis of
1589 each subsystem element shall be performed to determine all relevant faults and their
1590 corresponding failure modes. Whether a failure is a safe or a dangerous failure depends on
1591 the SCS and the intended safety functions, including fault reaction function.
1592 Analysis technique such as failure mode and effect analysis (FMEA, see IEC 60812), fault
1593 tree analysis (FTA, see IEC 61025) or event tree analysis (ETA, see IEC 62502) can be
1594 carried out to establish the faults that are to be considered for those components.
1595 The probability of each failure mode shall be determined based on the probability of the
1596 associated fault(s) taking into account the intended use and can be derived from sources
1597 such as:
1598 – dependable failure rate data collected from field experience by the manufacturer and
1599 relevant to the intended use;
1600 – component failure data from a recognised industry source and relevant to the intended
1601 use;
1602 – failure mode data;
1603 – failure rate data derived from the results of testing and analysis.
1604 In general, the following fault criteria shall be taken into account:
1605 – if, as a consequence of a fault, further components fail, the first fault together with all
1606 following faults shall be considered as a single fault (known as a dependent fault);
1607 – two or more separate faults having a common cause shall be considered as a single fault
1608 (known as a CCF);
1609 – the simultaneous occurrence of two or more faults having separate causes is considered
1610 highly unlikely and therefore need not be considered.
1611 7.3.3.3 Fault exclusion
1612 It is not always possible to evaluate subsystems without assuming that certain faults may be
1613 excluded. Fault exclusion is a compromise between technical safety requirements and the
1614 theoretical possibility of occurrence of a fault.
1615 Fault exclusion can be based on:

1616 – the technical improbability of occurrence of some faults,
1617 – generally accepted technical experience, independent of the considered application,
1618 and
1619 – technical requirements related to the application and the specific hazard.
1620 Fault exclusion is only applicable for certain failures of an element and it is up to the designer
1621 (manufacturer or integrator) to prove the exclusion of the respective faults based on the limits
1622 set forward by the design and use. Such fault exclusion is only possible provided that the
1623 impossibility of them occurring can be justified based on the known laws of physical science.
1624 Any such fault exclusions shall be justified and documented.
1625 The application of fault exclusion to certain faults for an element inside a subsystem does not
1626 limit the necessity of the application of systematic measures.
ENTWURF OVE
– 50 – IEC CDV 62061  IEC 2019
1627 It is possible some faults are excluded by the manufacturer and some by the subsystem
1628 integrator.
1629 Fault exclusion is one principle to limit the failure of a component/subsystem, also other
1630 methods are possible (e.g. architectures, limitation of systematic failures).
1631 There shall be a specific characterization of the type of fault that is excluded. It would not be
1632 acceptable to state simply that a component will not break, distort or degrade due to wear. It
1633 would be necessary to state the direct influence under which the component will not break,
1634 distort or degrade due to wear. E.g. the component will have no faults when subjected to a
1635 force of X Newtons from direction Y.
1636 The fault exclusion must be justifiable under all expected industrial environments including
1637 temperature, pressure, vibration, pollution, corrosive atmosphere etc.
1638 NOTE Useful information on fault exclusions is available in ISO 13849-2:2012, Annex A to D.
1639 Fault exclusion can only be applied for the entire subsystem when all dangerous failures of a
1640 subsystem can be excluded
1641 LIMITATION: For some application it is not expected that all failures can be excluded with
1642 sufficient confidence for SIL 3. The following non exhaustive list provides an indication of the
1643 type of application of fault exclusion where a maximum of SIL 2 can be appropriate provided
1644 that sufficient justification is given:
1645 – Position switch with mechanical aspects with HFT of 0;

1646 – Leakage of a fluid power valve (where leakage is dangerous failure);
1647 – Cos/sin coder with mechanical fixing with HFT of 0;
1648 – No redundant field wiring, protected but outside an enclosure.
1649 7.3.3.4 Functional testing to detect fault accumulation and hidden faults
1650 In a redundant system, an accumulation of faults over time might lead to a loss of the safety
1651 function. In a single channel system, hidden faults might also lead to a loss of the safety
1652 function. For an SCS with non-electronic technology and using automatic monitoring to
1653 achieve the necessary diagnostic coverage for the required safety performance the monitoring
1654 function cannot be possible unless there is a change of state, e.g. at every operating cycle. If,
1655 in such a case, there is only infrequent operation the probability of occurrence of an
1656 undetected fault is increased. When a functional test is necessary to detect a possible
1657 accumulation of faults or a hidden fault before the next demand, it shall be made within the
1658 following test intervals:
1659 – at least every month for SIL 3;

1660 – at least every 12 months for SIL 2.
1661 EXAMPLE: The control system of a machine can demand these tests at the required intervals e.g. by visual display
1662 unit or signal lamp, and can monitor the tests and stop the machine if the test is omitted or fails.
1663 7.3.4 Failure rate of subsystem element
1664 7.3.4.1 General
1665 The mathematical probability of failure of a subsystem element is mostly characterized by one
1666 of three parameters: λ (Lambda), MTTF (Mean Time To Failure) or B 10 .
1667 NOTE Although the parameters above can be delivered in several valuable formats, the typical formats are:
1668 - λ: failures per hour;
1669 - MTTF: mean time to failures expressed in years;
1670 - B 10 : switching cycles of wearing components.
1671 For the estimation of the parameters of a subsystem element, the hierarchical procedure for
1672 finding data shall be, in the order given:
1673 a) Use manufacturer’s data;
1674 b) Use Annex C of this standard;
1675 c) Choose a MTTF D of ten years.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 51 –
1676 The data could be delivered as values with respect to the dangerous failures (λ D , MTTF D ,
1677 B 10D ) or with respect to all failures (λ, MTTF, B 10 ).
1678 To determine the dangerous failures from the overall failures the different failure modes of the
1679 subsystem element should be taken into account. It is typically assumed that not all failures
1680 modes lead to a dangerous failure. This depends mainly on the application, so generally the
1681 failure mode data used should reflect practical application of the components. A precise way
1682 of determining the “failure modes” of a subsystem element is to carry out an FMEA. If no
1683 specific or sufficient knowledge and information is available concerning the failure modes,
1684 50 % of the failures can be estimated as dangerous.
1685 7.3.4.2 Relationship of relevant parameters

1686 For subsystem elements constant failure rates (λ) of the subsystem elements are assumed.
1687 The following basic equations can be used:
1
1688 𝜆= (1)
𝑀𝑀𝑀𝑀
1
1689 𝜆D = (2)
𝑀𝑀𝑀𝑀D
1690 NOTE 1 For calculation purposes MTTF can be assumed equal to MTBF.
1691 MTTF and MTTF D are mostly indicated in years [a]. λ values are commonly indicated in FIT
9
1692 (FIT = Failure In Time) where 1 FIT means one failure in 10 hours.
1693 1 𝐹𝐹𝐹 = 1 ∙ 10−9 ℎ−1 (3)
1694 One year is approximately 8760 hours. Therefore a MTTF value can be converted into a λ
1695 value.
1
1696 𝜆= ℎ (4)
𝑀𝑀𝑀𝑀 ∙8760
𝑎
1697 NOTE 2 Example, MTTF = 1000a:

1
1698 𝜆example = ℎ
1000𝑎 × 8760
𝑎
1
1699 𝜆example =
8 760 000ℎ
1
1700 𝜆example = ℎ−1
8 760 000
1701 𝜆example = 1,14155 × 10−7 ℎ−1

1702 𝜆example = 114,155 × 10−9 ℎ−1
𝜆example = 114,155 𝐹𝐹𝐹
1703 For pneumatic, mechanical and electromechanical components (pneumatic valves, relays,
1704 contactors, position switches, cams of position switches, etc.) it can be difficult to calculate
1705 the mean time to dangerous failure (MTTF D for components), which is given in years. Most of
1706 the times the manufacturers of these kinds of components only give the mean number of
1707 cycles until 10 % of the components fail dangerously (B 10D ). This clause gives a method for
1708 calculating an MTTF D for components by using B 10D given by the manufacturer related closely
1709 to the application dependent cycles.
1710 NOTE 3 Hydraulic components are mostly characterized with MTTF D .
1711 If the appropriate basic and well-tried safety principles are met, the MTTF D value for a single
1712 pneumatic, electromechanical or mechanical component can be estimated.
1713 The mean number of cycles until 10 % of the components fail dangerously (B 10D ) should be
1714 determined by the manufacturer of the component in accordance with relevant product
1715 standards for the test methods (e.g. IEC 60947-5-1, ISO 19973, IEC 61810). The dangerous
1716 failure modes of the component have to be defined, e.g. sticking at an end position or change
1717 of switching times. If not all the components fail dangerously during the tests (e.g. seven
1718 components tested, only five fail dangerously), an analysis taking into account the
1719 components that were not dangerously failed components should be performed.
1720 With B 10D and n op , the mean number of annual operations, MTTF D for components can be
1721 calculated as
ENTWURF OVE
– 52 – IEC CDV 62061  IEC 2019
𝐵10D
1722 𝑀𝑀𝑀𝑀D = (5)
0,1 × 𝑛op
𝑠
𝑑op × ℎop × 3600
1723 where 𝑛op = ℎ
(6)
𝑡cycle
1724 and with the following assumptions having been made on the application of the component:
1725 – ℎop is the mean operation, in hours per day;

1726 – 𝑑op is the mean operation, in days per year;
1727 – 𝑡cycle is the mean time between the beginning of two successive cycles of the component.
1728 (e.g. switching of a valve) in seconds per cycle.
1729 In terms of failure rate λ the following relationship can be expressed as
0,1 C 0,1 nop
1730 λD = = h (7)
B10D B10D × 8760
a
1731 where C (C = n op / 8760) is the duty cycle or mean operation per hour.
1732 The relation between B 10D , B 10 and the ratio of dangerous failure (RDF) is
B10
1733 B10D = . (8)
ratio of dangerous failure
1734 The useful lifetime of the component is limited to T 10D , the mean time until 10 % of the
1735 components fail dangerously:
B10D
1736 T10D = . (9)
nop
1737 NOTE 4 For electronic systems the exponential distribution is applicable. For non-electronic systems the
1738 exponential distribution is not applicable. The Weibull distribution (see also IEC 61649) is more appropriate, but
1739 parameters and calculations are difficult to apply. However, when using exponential distribution for non-electronic
1740 components within the limits of T 10D then the results of the calculations are pessimistic and the formula with 1-e -λt
1741 could be applied as a simplified method.
1742 If the ratio of dangerous failure is estimated less than 0.5 (50 % dangerous failure) the useful
1743 lifetime of the component is limited to twice T 10 .
1744 The ratio of dangerous failure is estimated as 0.5 (50 % dangerous failure) if no other
1745 information (e.g. product standard) is available.
1746 7.4 Architectural constraints of a subsystem
1747 7.4.1 General
1748 In the context of hardware safety integrity, the highest safety integrity level that can be
1749 claimed for a SCS is limited by the hardware fault tolerances (HFT) and safe failure fractions
1750 (SFF) of the subsystems that carry out that safety function. Table 4 specifies the highest
1751 safety integrity level that can be claimed for a SCS that uses a subsystem taking into account
1752 the hardware fault tolerance and safe failure fraction of that subsystem. The architectural
1753 constraints given in Table 4 shall be applied to each subsystem developed according to
1754 clause 7. With respect to these architectural constraints:
1755 a) a hardware fault tolerance of N means that N+1 faults could cause a loss of the safety
1756 function. In determining the hardware fault tolerance, no account is taken of other
1757 measures that can control the effects of faults such as diagnostics; and
1758 b) where one fault directly leads to the occurrence of one or more subsequent faults, these
1759 shall be considered as a single fault;
1760 c) in determining hardware fault tolerance, certain faults may be excluded, provided that the
1761 likelihood of them occurring is very low in relation to the safety integrity requirements of
1762 the subsystem, see 7.3.3.3.
1763 A subsystem that comprises only a single subsystem element shall satisfy the requirements of
1764 Table 4. In particular, for such a subsystem that has a hardware fault tolerance of zero (i.e.
1765 N = 0) then a SFF of greater than 99 % shall be achieved by a SCS diagnostic function(s).
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 53 –
1766 NOTE 1 This requirement is necessary to ensure an appropriate form of the architectural constraints is applied to
1767 subsystems that comprise only a single subsystem element in order to justify a reachable SIL of SIL 3.
1768 When two or more pre-designed subsystems are combined into one redundant subsystem, the
1769 architectural constraints of the combined subsystem can be determined. This can be done by
1770 taking the subsystem with the highest SIL according to the architectural constraints and
1771 looking for the corresponding SIL in Table 4 in column HFT=0. This will return the applicable
1772 SFF range. The SIL of the combined subsystem shall be derived by increasing the HFT by
1773 one in the same SFF range. More guidance can be found in 61508-2 7.4.4.2.4
1774 NOTE 2 .This procedure is only applicable for combining subsystems with a defined SIL.
1775 Table 4 – Architectural constraints on a subsystem: maximum SIL

1776 that can be claimed for an SCS using the subsystem
Safe failure fraction Hardware fault tolerance (HFT) (see NOTE 1)

(SFF) 0 1 2
< 60 % Not allowed (for SIL 1 SIL 2
exceptions see NOTE 3)
60 % – < 90 % SIL 1 SIL 2 SIL 3
90 % – < 99 % SIL 2 SIL 3 SIL 3 (see NOTE 2)
≥ 99 % SIL 3 SIL 3 (see NOTE 2) SIL 3 (see NOTE 2)
NOTE 1 A hardware fault tolerance of N means that N+1 faults could cause a loss of the safety function.
NOTE 2 SIL 4 is not considered in this standard. For SIL 4 see IEC 61508-1.
NOTE 3 Where subsystems which have a safe failure fraction of less than 60 % and zero hardware fault tolerance,
that use well-tried components can be considered to achieve SIL 1; or for subsystems where fault exclusions
have been applied to faults that could lead to a dangerous failure.
NOTE 4 In IEC 62061:2015 the maximum SIL that could be claimed was named SILCL.
NOTE 5 See 7.3.3.3 for limitation of SIL when applying fault exclusion.
NOTE 6 For HFT=0 at SFF ≥ 99 % it is only possible when there is continuous monitoring of the correct
functioning of the element. Typically, electronic technology will be required to achieve this.
1777
1778 7.4.2 Estimation of safe failure fraction (SFF)

1779 To estimate the SFF, an analysis (e.g. fault tree analysis, failure mode and effects analysis)
1780 of each subsystem shall be performed to determine all relevant faults and their corresponding
1781 failure modes. Whether a failure is a safe or a dangerous failure depends on the SCS and the
1782 intended safety function, including fault reaction function (see 7.4.3). The probability of each
1783 failure mode shall be determined based on the probability of the associated fault(s) taking into
1784 account the intended use and may be derived from sources such as:
1785 a) dependable failure rate data collected from field experience by the manufacturer and
1786 relevant to the intended use;
1787 b) component failure data from a recognised industry source and relevant to the intended
1788 use;
1789 c) failure rate data derived from the results of testing and analysis.
1790 NOTE 1 Information of the failure rates for electrical/electronic component can be found in several sources
1791 including:
1792 - MIL-HDBK 217F(Notice 2) Reliability Prediction of Electronic Equipment (28-02-95), Parts Stress Analysis
1793 - MIL-HDBK 217F(Notice 2) Reliability Prediction of Electronic Equipment (28-02-95), Appendix A, Parts Count
1794 Reliability Prediction
1795 - SN 29500 Part 7, Failure Rates of Components, Expected Values for Relays, November 2005
1796 - SN 29500 Part 11, Failure Rates of Components, Expected Values for Contactors, April 2015
1797 - IEC 61709:2017 Electric components – Reliability – Reference conditions for failure rates and stress models
1798 for conversion
1799 - Failure mode/mechanism distributions FMD-91, RAC 1991.
1800 - OREDA Handbook 2015, 6th edition – Volume I and II
1801 - EXIDA Safety Equipment Reliability Handbook - 4th edition
ENTWURF OVE
– 54 – IEC CDV 62061  IEC 2019
1802 - EXIDA Electrical & Mechanical Component Reliability Handbook - 3rd Edition
1803 NOTE 2 Failure rate data can be provided by manufacturers.
1804 NOTE 3 Some component standards provide relevant data (e.g. Annex K of IEC 60947-4-1:2009+A1:2012).
1805 NOTE 4 Lists of faults to be considered for mechanical, pneumatic, hydraulic and electrical technologies are given
1806 in Annexes A, B, C and D of ISO 13849-2:2012.
1807 In general the SFF can be calculated as follows:
∑ 𝜆S + ∑ 𝜆DD
𝑆𝑆𝑆 =
∑ 𝜆S + ∑ 𝜆D
1808 where
1809 𝜆S is the rate of safe failure,
1810 ∑ 𝜆S + ∑ 𝜆D is the overall failure rate,
1811 𝜆DD is the rate of dangerous failure which is detected by the diagnostic functions,
1812 𝜆D is the rate of dangerous failure.

1813 NOTE 5 Only failures detected by diagnostic tests (see 6.9.1) are accounted for in the safe failure fraction
1814 calculation.
1815 The failure of an element that plays a part in implementing the safety function but has no
1816 direct effect on the safety function is termed a no effect failure and is not considered as a safe
1817 failure (𝜆S ). Therefore it shall not be used for SFF calculations.
1818 For non-electronic components 𝜆S is typically assumed as equal to 0 or is negligible because

1819 the probability occurrence of a random hardware failure that causes the safety function to go
1820 to or remain in the safe state is in most cases insignificant in comparison to the probability of
1821 occurrence of dangerous detected and undetected failures. In this case the following
1822 simplification can be applied (see also example in B.4):
∑ 𝜆S +∑ 𝜆DD ∑ 𝜆DD
1823 𝑆𝑆𝑆 = ∑ 𝜆S +∑ 𝜆D
= ∑ 𝜆D
.
1824 EXAMPLE 1 Where the hardware fault tolerance of a subsystem is equal to 0 SFF becomes
𝜆DD1 𝐷𝐷1 𝜆D1
𝑆𝑆𝑆 = = = 𝐷𝐷1
𝜆D1 𝜆D1
1825 with 𝐷𝐷1 the diagnostic coverage of subsystem element 1.

1826 EXAMPLE 2 Where the hardware fault tolerance of a subsystem is equal to 1 SFF becomes
𝐷𝐷1 𝐷𝐷2
𝜆DD1 + 𝜆DD2 𝐷𝐷1 𝜆D1 + 𝐷𝐷2 𝜆D2 +
𝑀𝑀𝑀𝑀D1 𝑀𝑀𝑀𝑀D2
1827 𝑆𝑆𝑆 = = = 1 1
𝜆D1 + 𝜆D2 𝜆D1 +𝜆D2 +
𝑀𝑀𝑀𝑀D1 𝑀𝑀𝑀𝑀D2
1828 with 𝐷𝐷1 and 𝐷𝐷2 the diagnostic coverages respectively of subsystem element 1 and 2 (see also 7.4.2 relationship
1829 between λ and MTTF).
1830 7.4.3 Behaviour (of the SCS) on detection of a fault in a subsystem
1831 7.4.3.1 General
1832 The detection of a dangerous fault in any subsystem that has a hardware fault tolerance of
1833 more than zero shall result in the performance of the specified fault reaction function.
1834 The specification can allow isolation of the faulty part of the subsystem to continue safe
1835 operation of the machine while the faulty part is repaired. In this case, if the faulty part is not
1836 repaired within the estimated maximum time as assumed in the calculation of the probability
1837 of random hardware failure, then a second fault reaction shall be performed to maintain a safe
1838 condition.
1839 Where the SCS is designed for online repair, isolation of a faulty part shall only be applicable
1840 where this does not increase the probability of dangerous random hardware failure of the SCS
1841 above that specified in the SRS.
1842 As long as operation is continued and hardware fault tolerance is reduced to zero, the
1843 requirements of 7.4.3.2 apply.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 55 –
1844 7.4.3.2 Fault reaction function

1845 Where a diagnostic function is necessary to achieve the required probability of dangerous
1846 random hardware failure or safe failure fraction and the subsystem has a hardware fault
1847 tolerance of zero, then
1848 – the sum of the diagnostic test interval and the time to perform the specified fault reaction
1849 function to achieve or maintain a safe state shall be shorter than the time needed to reach
1850 the hazardous situation (e.g. see ISO 13855); or,
1851 – when operating in high demand mode of operation, the ratio of the diagnostic test rate to
1852 the demand rate shall equal to or exceed 100.
1853 Where performance of a fault reaction function as part of an SCS that is specified as SIL 3
1854 has resulted in the machine being stopped, subsequent normal operation of the machine via
1855 the SCS (e.g. enabling re-start of the machine) shall not be possible until the fault has been
1856 repaired or rectified. For an SCS with a specified safety performance of less than SIL 3, the
1857 behaviour of the machine after performance of a fault reaction function (e.g. re-starting
1858 normal operation) shall depend on the specification of relevant fault reaction functions (see
1859 5.2.2).
1860 7.4.3.3 Diagnostic coverage (DC)

1861 Diagnostic coverage (DC) can be calculated as the fraction of dangerous failures by using the
1862 following equation:
1863 𝐷𝐷 = ∑ 𝜆DD ⁄∑ 𝜆D
1864 where 𝜆DD is the rate of detected dangerous hardware failures and 𝜆D is the rate of dangerous
1865 hardware failures.
1866 For the estimation of DC (3.2.42), in most cases, Failure Mode and Effects Analysis (FMEA –
1867 see IEC 60812), Failure Mode Effects and Diagnostic Analysis (FMEDA) or equivalent
1868 methods can be used. In this case all relevant faults and/or failure modes should be
1869 considered.
1870 For a simplified approach to estimating DC see Annex E.

1871 NOTE Annex C of IEC 61508-2 provides further information.
1872 7.4.4 Realization of diagnostic functions

1873 Each subsystem shall be provided with associated diagnostic functions that are necessary to
1874 fulfil the requirements for architectural constraints and the probability of dangerous random
1875 hardware failures.
1876 The diagnostic functions are considered as separate functions that can have a different
1877 structure than the safety function and can be performed by
1878 – the same subsystem which requires diagnostics; or

1879 – other subsystems of the SCS; or
1880 – subsystems of the SCS not performing the safety function.
1881 Diagnostic functions shall satisfy the following:
1882 – applicable requirements for the avoidance of systematic failure; and

1883 – applicable requirements for the control of systematic failure.
1884 NOTE 1 Timing constraints applicable to the testing of the subsystem performing a diagnostic function can differ
1885 from those applicable to safety functions.
1886 NOTE 2 The necessity of checking the diagnostic function can depend on aspects such as the safety integrity level,
1887 the demand rate, the used technology and application specific capabilities.
1888 A clear description of the SCS diagnostic function(s), their failure detection/reaction, and an
1889 analysis of their contribution towards the safety integrity of the associated safety functions
1890 shall be provided.
ENTWURF OVE
– 56 – IEC CDV 62061  IEC 2019
1891 To apply the simplified approach of this standard for the estimation of probability of
1892 dangerous random hardware failures of subsystems, the following shall apply:
1893 – SCS diagnostic function(s) shall as a minimum be implemented so that the probability of
1894 random hardware failure and the systematic safety integrity are the same as those
1895 specified for the corresponding safety function(s),
1896 or
1897 where the probability of dangerous random hardware failure is of an order of magnitude
1898 greater than that specified for the safety function, then a test shall be performed to
1899 determine whether diagnostic function(s) remain operational; a test of the diagnostic
1900 function(s) shall be carried out at a minimum of 10 times at equal intervals during the
1901 proof test interval for the subsystem;
1902 – Requirements from clause 7.4.3.2.
1903 NOTE 3 Architectural constraints on hardware safety integrity need not apply to the realization of diagnostic
1904 function(s).
1905 NOTE 4 A test of the diagnostic function(s) is foreseen to cover, as far as practicable, 100 % of those parts
1906 implementing the diagnostic function(s).
1907 NOTE 5 Where a diagnostic function is implemented by the logic solver of the SCS it can be unnecessary to
1908 perform a separate test of the diagnostic function as its failure can be revealed as a failure of the safety function.
1909 NOTE 6 A test can be performed by either external means (e.g. test equipment) or internal dynamic checks (e.g.,
1910 embedded within the logic solver) of the SCS.
1911 7.5 Subsystem design architectures
1912 7.5.1 General
1913 The architecture of any subsystem described in this sub clause can be used to evaluate the
1914 architectural constraints and to estimate the probability of dangerous random hardware
1915 failures, see Annex K.
1916 NOTE The figures in this sub-clause represent a logical view of the subsystem architectures and are not intended
1917 to represent any specific physical connection schemes. A hardware fault tolerance of 1 is represented by parallel
1918 subsystem elements but the physical connections will depend on the application of the subsystem.
1919 7.5.2 Basic subsystem architectures

1920 7.5.2.1 Basic subsystem architecture A: single channel without a diagnostic function
1921 In this architecture, any dangerous failure of a subsystem element causes a failure of the
1922 safety function. This architecture corresponds to a hardware fault tolerance of 0.
1923 In high or continuous mode of operation, architecture A shall not rely on a proof test interval
1924 shorter than life time.
Subsystem A
Subsystem element 1 Subsystem element n

λDe1 λDen
1925
1926 Figure 7 – Subsystem A logical representation
1927 7.5.2.2 Basic subsystem architecture B: dual channel without a diagnostic function
1928 This architecture is such that a single failure of any subsystem element does not cause a loss
1929 of the safety function. This architecture corresponds to a hardware fault tolerance of 1.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 57 –
Subsystem B
Subsystem element 1
λDe1
Common cause failure
Subsystem element 2
λDe2
1930
1931 Figure 8 – Subsystem B logical representation
1932 7.5.2.3 Basic subsystem architecture C: single channel with a diagnostic function
1933 Any undetected dangerous fault of the subsystem element leads to a dangerous failure of the
1934 safety function. Where a fault of a subsystem element is detected, the diagnostic function(s)
1935 initiates a fault reaction function (see 7.4.3). This architecture corresponds to a hardware fault
1936 tolerance of 0.
Subsystem C

λDe1 λDen
Diagnostic function(s)
1937
1938 Figure 9 – Subsystem C logical representation
1939 7.5.2.4 Basic subsystem architecture D: dual channel with a diagnostic function(s)
1940 This architecture is such that a single failure of any subsystem element does not cause a loss
1941 of the safety function. Where a fault of a subsystem element is detected, the diagnostic
1942 function(s) initiates a fault reaction function (see 7.4.3). This architecture corresponds to a
1943 hardware fault tolerance of 1.
Subsystem D
Subsystem element 1
λDe1
Diagnostic function(s) Common cause failure
Subsystem element 2
λDe2
1944
1945 Figure 10 – Subsystem D logical representation
1946 7.5.3 Basic requirements
1947 As shown in Table 5 the basic requirements depending on the architectural constraints and
1948 the basic subsystem architectures shall be applied.
ENTWURF OVE
– 58 – IEC CDV 62061  IEC 2019
1949 Table 5 – Overview of basic requirements and interrelation to basic subsystem

1950 architectures
Hardware fault tolerance (HFT)
Basic 0 1
Comments / Examples
Requirements SFF SFF
<60 % ≥ 60 % <60 % ≥ 60 %
Basic safety Use of suitable materials

principles
M M M M
ISO 13849-2, Annex A to D
Mechanically linked contacts

Well-tried safety and contacts with direct
principles
M M M M opening action
Well-tried Contactor (IEC 60947-4-1)

components
M -- -- --
not
CCF
relevant
M M M
Type of basic
subsystem A C B D
architecture
M = mandatory, -- = no requirement
NOTE Table 4 for architectural constraints is still applicable.
1951
1952 7.6 Probability of dangerous random hardware failures of subsystems

1953 7.6.1 General
1954 The following parameters have to be determined to be able to determine the PFH:
1955 – Subsystem architecture (see 7.5)

1956 – DC and test intervals (see 7.4.3 and 7.4.4)
– CCF (see Annex F)
1957
1958 – λ D or MTTF D of subsystem elements (see 7.3.4)

1959 – Useful lifetime
1960 NOTE Because a typical machine life is about 20 years a useful lifetime of 20 years is preferred. The intention is to
1961 clarify the maximum usage period for the subsystem. For components with wear out characteristics useful lifetime
1962 can be limited by T 10D .
1963 7.6.2 Methods to estimate the PFH of a subsystem
1964 One of the following methods of Annex K may be used to calculate the PFH as simplified
1965 approach:
1966 – Allocation table approach (see K.1)
1967 – Formulas (see K.2)
1968 Modelling based on e.g. fault tree analysis (see B.6.6.5 of IEC 61508-7:2010 and
1969 IEC 61025:2006), Markov models (see B.6.6.6, C.6.4 of IEC 61508-7:2010 and IEC 61165-13)
1970 or reliability block diagrams (see C.6.4 of IEC 61508-7:2010) is always possible.
1971 7.6.3 Methods to estimate the PFD avg of a subsystem

1972 See Annex D.
1973 7.6.4 Simplified approach to estimation of contribution of common cause failure

1974 (CCF)
1975 Knowledge of the susceptibility of a subsystem to CCF is required to contribute to the
1976 estimation of the probability of dangerous random hardware failure of a subsystem.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 59 –
1977 The probability of occurrence of the CCF will usually be dependent upon a combination of
1978 technology, architecture, application and environment. The use of Annex F will be effective in
1979 avoiding many types of CCF.
1980 8 Software
1981 8.1 General
1982 All lifecycle activities of safety-related embedded or application software shall focus on the
1983 avoidance of faults introduced during the software lifecycle. The main objective of the
1984 following requirements is to produce readable, understandable, testable, maintainable and
1985 correct software.
1986 Where the software performs both non-safety and safety functions, then all of the software
1987 shall be treated as safety-related, unless sufficient independence between the functions can
1988 be demonstrated in the design. It is therefore preferable to separate non-safety functions such
1989 as basic machine functions from safety functions wherever practicable.
1990 This standard shall only be used for application software that is running in a pre-designed
1991 platform e.g IEC 61508-3, IEC 61131-6.
1992 8.2 Definition of Software Levels

1993 This standard describes three different levels of software application, see Table 6.
1994 Table 6 – Different levels of software
SW Level Main principle Subprinciple Example

1 Platform (combination of Application software Safety PLC with LVL or
hardware and software) pre- complying with this Safety programmable relay
designed according to standard.
IEC 61508.
Application software making
use of a limited variability
language (LVL).
2 Platform (combination of Application software Safety PLC with FVL (FVL
hardware and software) pre- complying with IEC according IEC 61508)
designed according to 61508-3.

IEC 61508.
3 Application software Safety PLC with FVL (FVL
Application software making complying with this complying with this
use of another language standard. standard.)
than a limited variability
language (LVL).
1995
1996 NOTE 1 For other types of platforms no requirements are set forward in this standard. IEC 61508-2 and 61508-3
1997 describe how to handle such systems.
1998 In the case that an element used is pre-designed but is only part of the platform, e.g. SoC
1999 (system on chip) or Micro Controller Board, the complete platform, including Power Supplies
2000 and associated add-ons necessary for it to function as intended, shall be considered. The
2001 complete platform shall pass an appropriate level of testing (including but not limited to
2002 increased immunity, increased environmental and foreseeable fault insertion etc.) in order to
2003 achieve systematic integrity.
2004 Software Level 2 is not further described in this standard since it is covered by correct
2005 application of the respective parts of IEC 61508. A high level of competence is required in
2006 order to design according to SW level 2 or 3. Factors that make the use of IEC 61508-3
2007 (software level 2) more appropriate than the use of this standard (software level 3) are:
2008 – high degree of complexity of the safety function(s);

2009 – large number of safety functions;
2010 – large project size.
ENTWURF OVE
– 60 – IEC CDV 62061  IEC 2019
2011 The software safety lifecycle requirements for the different SW Levels are detailed in the
2012 following subclauses:
2013 – SW Level 1: see 8.3;

2014 – SW Level 3: 8.4.
2015 8.3 Software Level 1
2016 8.3.1 Software safety lifecycle SW Level 1
2017 8.3.1.1 Maximum achievable SIL SW Level 1
2018 The maximum achievable SIL for SW Level 1 is SIL 3.
2019 8.3.1.2 Software safety lifecycle model SW Level 1
2020 A software safety lifecycle model which is resolved into distinct phases shall be used (e.g. V-
2021 model), including management and documentation activities to achieve the required level of
2022 safety.
2023 Any software lifecycle model may be used provided all the objectives and requirements of this
2024 clause are met. Safety-related software shall be validated as described in 9.5.3.
2025 SW level 1 is of reduced complexity due to the use of pre-designed safety-related hardware
2026 and software modules. Therefore the simplified V-model in Figure 11 is applicable. The
2027 design of customized, or self-created software modules can be necessary (e. g. in the case of
2028 the library modules provided by the component manufacturer being inadequate or not
2029 suitable). The design of software modules customized by the designer is an additional activity
2030 which shall be carried out according to the V-model in Figure 12.
2031 NOTE 1 A software module (or briefly module) is a functional unit of the software, which is typically only accessible
2032 through its input and output interface. It is reusable and facilitates the modular software development. Software
2033 modules are often part of a library. In PLC-programming software modules are functions or function blocks.
2034 NOTE 2 The V-model is a static model used to structure the software design into small parts. It does not introduce
2035 any sequence of creation of specifications or implementation. The left side represents requirements; i.e. things to
2036 achieve. The right side details testing of the software.
2037 NOTE 3 On the left side of the V-model the output of each phase is reviewed. Review means to check the output of
2038 a phase in the V-model against the requirements of the input of the same phase. The arrow ‘Review’ represents the
2039 first step of the software verification.
2040 NOTE 4 Project management techniques and processes appropriate for the size and scope of the project are
2041 recommended.
2042
2043 Figure 11 – V-model for SW level 1
2044
2045 Figure 12 – V-model for software modules customized by the designer for SW level 1
2046 NOTE 5 In the V-models the arrow ‘Test’ represents the results of test cases according to the specification and, in
2047 addition, the need for more precise test case requirements and specifications.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 61 –
2048 NOTE 6 The result of Figure 12 is an input to the coding of Figure 11.
2049 8.3.1.3 Independence of review, testing and verification activities SW Level 1

2050 Where this standard requires carrying out review or testing/verification activities these shall
2051 be performed by persons not involved directly in the design of the safety-related software, i.e.
2052 who are independent of the design process. The parties concerned may be other persons,
2053 departments or bodies who/which are not subordinate to the design department within the
2054 organization’s hierarchy. The level of independence shall be commensurate with the risk, i.e.
2055 with the required SIL, see Table 7.
2056 The level of independence specified in the table below is the minimum for the safety integrity
2057 level. Depending on a number of factors specific to the application (like previous experience,
2058 degree of complexity etc) it could be appropriate to choose a higher level of independence.
2059
2060 Table 7 – Minimum levels of independence for review, testing and verification activities
2061 SW Level 1
Minimum level of Required SIL for the safety function up to

independence SIL 1 SIL 2 SIL 3
Same person not sufficient not sufficient not sufficient

sufficient only for sufficient only for
combination of combination of
Other Person not sufficient
pre-designed pre-designed
software modules software modules
Independent
sufficient sufficient sufficient
person
Independent possible but not possible but not possible but not
department/group necessary necessary necessary
organisation necessary necessary necessary
2062
2063 An “other person” may be involved in the same project, but shall not be involved in the design
2064 activities. An “independent person” may be involved in the same project, but shall not be
2065 involved in the design activities and shall not have responsibility for project management and
2066 shall not have a superior role .

2067 NOTE 1 An “independent department” is not involved in design activities of the project. An “independent
2068 organisation” is separate and distinct, by management and other resources from the organisation responsible for
2069 the design activities of the project.
2070 NOTE 2 Depending upon the company organisation and expertise within the company, the requirement for
2071 independent persons and departments can have to be met by using an external organisation. Conversely,
2072 companies that have internal organisations skilled in risk assessment and the application of safety-related
2073 systems, that are independent of and separate (by ways of management and other resources) from those
2074 responsible for the main development, can be able to use their own resources to meet the requirements for an
2075 independent organisation.
2076 8.3.1.4 Tools usage SW Level 1
2077 The tools shall be applied according to the recommendations of the relevant manufacturer of
2078 the safety-related system(s) (e.g. PLC, Electro Sensitive Protective Equipment).
2079 8.3.2 Software Design SW Level 1
2080 8.3.2.1 General SW Level 1
2081 The software design specification shall be developed on basis of the software safety
2082 requirements and managed throughout the lifecycle of the SCS.
2083 8.3.2.2 Software safety requirements SW Level 1

2084 To support the software design process the following information shall be considered:
2085 a) specification of the safety function(s) (see 5.2);

2086 b) configuration or architecture of the SCS (e. g. hardware architecture, wiring diagram,
2087 safety-related inputs and outputs);
ENTWURF OVE
– 62 – IEC CDV 62061  IEC 2019
2088 c) response time requirements;

2089 d) operator interfaces and controls, such as: switches, joysticks, mode selector, dials, touch
2090 sensitive control devices, keypads, etc.;
2091 e) relevant modes of operation of the machine;
2092 f) requirements on diagnostics for hardware including the characteristics of sensors, final
2093 actuators, etc.;
2094 g) effects of mechanical tolerances, e.g. of sensors and/or their sensing counter parts;
2095 h) coding guidelines.
2096 8.3.2.3 Software design specification SW level 1
2097 The software design specification shall be derived from the software safety requirements of
2098 the SCS.
2099 The software design specification shall be:
2100 – structured, reviewable, testable, understandable, maintainable and operable;

2101 – developed for each subsystem on the basis of the SCS specification and architecture;
2102 – sufficiently detailed to allow the design and implementation of the SCS to achieve the
2103 required level of safety (SIL), and to allow verification and testing.
2104 – traceable back to the specification of the software safety requirements of the SCS. This
2105 means that the specification is as such understandable such that another person (e.g.
2106 non-software specialist) can verify if the specification corresponds to the software safety
2107 requirements of the safety functions defined in the risk assessment.
2108 – free of ambiguous terminology and irrelevant descriptions.
2109 It shall be possible to relate the inputs of the software design specification in a straightforward
2110 manner to the desired outputs and vice versa. Where appropriate, easy readable semi-formal
2111 methods such as cause&effect tables, logictables or diagrams, function-blocks or sequence
2112 diagrams shall be used in the documentation.
2113 NOTE 1 Where appropriate depends on the number of safety functions involved in the program. Whenever the total
2114 amount of safety functions inside the program is larger than 3, it is considered appropriate.
2115 The following shall be specified within the software design specification:
2116 a) logic of the safety functions, including safety-related inputs and outputs and proper
2117 diagnostics on detected faults. Possible methods include, but are not limited to,
2118 cause&effect table, written description or function blocks;
2119 NOTE 2 Faults can also be detected by hardware (e.g. signal discrepancy detected by input card).
2120 b) test cases that include:
2121 – the specific input value(s) for which the test is carried out and the expected test results
2122 including pass/fail criteria;
2123 – fault insertion or injection(s).
2124 NOTE 3 For simple functions the test case(s) can be given implicitly by the specification of the safety function.
2125 c) diagnostic functions for input devices, such as sensing elements and switches, and final
2126 control elements, such as solenoids, relays, or contactors;
2127 d) functions that enable the machine to achieve or maintain a safe state;
2128 e) functions related to the detection, annunciation and handling of faults;
2129 f) functions related to the periodic testing of SCS(s) on-line and off-line;
2130 g) functions that prevent unauthorized modification of the SCS (e. g. password);
2131 h) interfaces to non SCS;
2132 i) safety function response time;
2133 j) in complicated cases it is recommended to specify the software architecture (e. g.
2134 invocation hierarchies, data flow).
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 63 –
2135 NOTE 4 Guidance on software documentation is given in IEC 61508, ISO/IEC/IEEE 26512:2011
2136 It is recommended to use pre-designed software modules within the software design
2137 specification wherever possible, for example a software module used for muting function
2138 according to IEC 61496-1 and designed by the manufacturer of the platform.
2139 It is recommended that In case of pre-designed safety sub-functions, for example IEC 61800-
2140 5-2, a reference to the specification provided by the manufacturer should be used.
2141 The information in the software design specification shall be reviewed and where necessary
2142 revised, to ensure that the requirements of the software safety requirements (see 8.3.2.2) are
2143 adequately specified.
2144 8.3.2.4 Software system design specification SW Level 1

2145 The software system design shall explain the main software aspects such as indicated in the
2146 following list for example:
2147 – the software architecture that defines the structure decided to satisfy the software design
2148 specification;
2149 – the global data;
2150 – data libraries used;
2151 – pre-existing software modules used;
2152 – diagnostic functions (internal, external);
2153 – programming tools including information which uniquely identifies the tool;
2154 – integration test cases and procedures, including specification of the test environment,
2155 support software, configuration description and procedures for corrective action on failure
2156 of test.
2157 A software system design specification is the output of the software system design.
2158 The information contained in the software system specification shall be reviewed against the
2159 software design specification.
2160 8.3.3 Module design SW Level 1

2162 Where previously developed software library modules are to be used as part of the design,
2163 their suitability in satisfying the specification of requirements of the software safety shall be
2164 analyzed. Constraints from the previous software development environment (for example
2165 operating system and compiler dependencies) shall be evaluated.
2166 8.3.3.2 Input information SW Level 1

2167 For software modules the following information shall be available in the module requirements:
2168 a) module description;

2169 b) module interface (inputs and outputs with data types, and, if necessary, with data ranges);
2170 c) module libraries used;
2171 d) specific coding rules.
2172 8.3.3.3 Module design specification SW Level 1
2173 The module design specification shall contain the following information:
2174 a) description of the logic (i.e. the functionality) of each module;

2175 b) fully defined input and output interfaces assigned for each module;
2176 c) format and value ranges of input and output data and their relation to modules;
2177 d) test cases which shall include normal and outside normal operation;
2178 NOTE Although test cases usually comprise the individually testing of parameters within their specified ranges, a
2179 varying combination of these parameters can introduce unpredicted operation.
2180 This information shall be reviewed against the input information (see 8.3.3.2).
ENTWURF OVE
– 64 – IEC CDV 62061  IEC 2019
2181 8.3.4 Coding SW Level 1

2182 Software shall be developed in accordance with the design specifications and coding rules.
2183 Coding rules can be either well-known industry standards or can be internal to the
2184 manufacturer. The code shall be reviewed against the design specifications and coding rules.
2185 NOTE Coding rules are intended to restrict the freedom of programming in order to avoid the program code
2186 becoming incomprehensible and in order to reduce the likelihood of the program entering unintended states
2187 The output of coding shall comprise
2188 – source code listing (e.g. ladder, function blocks, models);

2189 – code review report.
2190 Some typical coding rules to be applied, but not limited to, are:
2191 – Make sure the structure of the program is as easy and clear as possible
2192 – Structure of the program should be such that the logical flow starts at the top and follow in
2193 the effective sequence
2194 – Every part has to have sufficient comments in a predefined way
2195 – Use the same names for parameters as during design
2196 – Make sure the name represents the clear function of the parameter
2197 – Make sure you have a predefined state. Limit the use of set/reset for safety functions
2198 – Safety outputs can only be assigned once inside a program
2199 – Non safety parameters can never be used to bypass safety functions
2200 8.3.5 Module test SW Level 1
2201 Each module, which was not previously assessed, shall be tested by functional and black-box
2202 or grey-box testing as required against the test cases defined in the module design.
2203 If the module does not pass the testing then predefined corrective action shall be taken.
2204 The test results, and corrective actions, shall be documented.

2205 NOTE 1 Functional testing aims to reveal failures during the specification and design phases, and to avoid failures
2206 during implementation and the integration of software and hardware.

2207 NOTE 2 Black-box testing aims to check the dynamic behaviour under real functional conditions, and to reveal
2208 failures to meet functional specification, and to assess utility and robustness. Grey-box testing is similar to Black-
2209 box testing but additionally monitors relevant test parameter(s) inside the software module.
2210 8.3.6 Software testing SW Level 1

2212 The main goal of software testing is to ensure that the functionality as detailed in the software
2213 design specification is achieved.
2214 The main output of software testing is a document e.g. a test report with test cases and test
2215 results allowing an assessment of the test coverage.
2216 Software testing shall also include failure simulation and the associated failure reaction
2217 depending on the required safety integrity.
2218 When pre-designed input cards or software modules which incorporate failure detection and
2219 reaction are utilised (e.g. discrepancy of input signals or feedback contact of output) then the
2220 test of those failure detection and reaction is not necessary. In that case only the integration
2221 of these input cards or software modules in accordance with the manufacturer’s specification
2222 shall be tested.
2223 Software testing can be carried out as part of the system validation if testing is performed on
2224 the target hardware.
2225 Functional testing as a basic measure shall be applied. Code should be tested by simulation
2226 where feasible.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 65 –
2227 It is recommended to define general guidelines or procedures for the testing of safety-related
2228 software. These guidelines or procedures should include:
2229 – types of tests to be performed;

2230 – specification of test equipment including tools, support software and configuration
2231 description;
2232 – management of software versioning during testing and correcting of safety-related
2233 software;
2234 – corrective actions on failed test;
2235 – criteria for the completion of the test with respect to the related functions or requirements;
2236 physical location(s) of the testing, such as computer simulation, bench top or lab, factory,
2237 or on the machine.
2238 8.3.6.2 Test planning and execution SW Level 1
2239 Test planning based on test cases shall include:
2240 – definition of roles and responsibilities by name;

2241 – installation testing;
2242 – functional testing.
2243 8.3.7 Documentation SW Level 1
2244 All life cycle activities shall be traceable forwards and backwards from the specification of the
2245 safety function(s) and through the completed validation plan.
2246 The inputs and outputs of all software safety lifecycle phases shall be documented and made
2247 available to the relevant persons.
2248 The test activities results, and corrective actions taken shall be documented.
2249 8.3.8 Configuration and modification management process SW Level 1

2250 Any modifications or changes to software shall be subject to an impact analysis that identifies
2251 all software parts affected and the necessary re-design, re-review and re-test activities to
2252 confirm that the relevant software safety requirements are still satisfied.
2253 Configuration management processes and modifications management processes shall be

2254 defined and documented. This should, as a minimum, include the following items:
2255 – articles managed by the configuration, at least: software safety requirements preliminary
2256 and detailed software design, source code modules, plans, procedures and results of the
2257 validation tests;
2258 – identification rules which uniquely identify each software module or configuration element;
2259 – modification processes which are comprehensive from request through to implementation.
2260 For each article of configuration, it should be possible to identify any changes that can have
2261 occurred and the versions of any associated elements.
2262 NOTE 1 The purpose is to be able to trace the historical development of each article: what modifications have been
2263 made, why, and when.
2264 Software configuration management should allow a precise and unique software version
2265 identification to be obtained. Configuration management should associate all the articles (and
2266 their version) needed to demonstrate the functional safety.
2267 All articles in the software configuration should be covered by the configuration management
2268 procedure before being tested or being requested by the analyst for final software version
2269 evaluation.
2270 NOTE 2 The objective here is to ensure the evaluation procedure is performed on software with all elements in a
2271 precise state. Any subsequent change can necessitate revision of the software so that it can be identifiable by the
2272 analyst.
ENTWURF OVE
– 66 – IEC CDV 62061  IEC 2019
2273 Procedures for the archiving of software and its associated data should be established
2274 (methods for storing backups and archives).
2275 NOTE 3 These backups and archives can be used to maintain and modify software during its functional lifetime.
2276 8.4 Software Level 3
2277 8.4.1 Software safety lifecycle SW Level 3
2278 8.4.1.1 Maximum achievable SIL SW Level 3
2279 The maximum achievable SIL for SW Level 3 is SIL 3.
2280 8.4.1.2 Software safety lifecycle model SW Level 3
2281 A software safety lifecycle model which is resolved into distinct phases shall be used (e.g. V-
2282 model), including management and documentation activities to achieve the required level of
2283 safety.
2284 Any software lifecycle model may be used provided all the objectives and requirements of this
2285 clause are met. Safety-related software shall be validated as described in 9.5.3.
2286 Software level 3 is of increased complexity in comparison with SW level 1 due to the use of
2287 fully variable programming languages. Therefore the more detailed V-model in Figure 13 is
2288 applicable
2289 NOTE 1 The V-model is a static model used to structure the software design into small parts. It does not introduce
2290 any sequence of creation of specifications or implementation. The left side represents requirements; i.e. things to
2291 achieve. The right side details testing of the software.
2292 NOTE 2 On the left side of the V-model the output of each phase is reviewed. Review means to check the output of
2293 a phase in the V-model against the requirements of the input of the same phase. The arrow ‘Review’ represents the
2294 first step of the software verification.
2295 NOTE 3 Project management techniques and processes appropriate for the size and scope of the project are
2296 recommended.
2297
2298
2299 Figure 13 – V-model of software safety lifecycle for SW Level 3

2300 NOTE 4 In the V-models the arrow ‘Test’ represents the results of test cases according to the specification and, in
2301 addition, the need for more precise test case requirements and specifications.
2302 8.4.1.3 Independence of review, testing and verification activities SW Level 3

2303 Where this standard requires carrying out review or testing/verification activities these shall
2304 be performed by persons not involved directly in the design of the safety-related software, i.e.
2305 who are independent of the design process. The parties concerned may be other persons,
2306 departments or bodies who/which are not subordinate to the design department within the
2307 organization’s hierarchy. The level of independence shall be commensurate with the risk, i.e.
2308 with the required SIL, see Table 8.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 67 –
2309 The level of independence specified in the table below is the minimum for the safety integrity
2310 level. Depending on a number of factors specific to the application (like previous experience,
2311 degree of complexity etc) it could be appropriate to choose a higher level of independence.
2312
2313 Table 8 – Minimum levels of independence for review, testing and verification activities
2314 SW Level 3

independence SIL 1 SIL 2 SIL 3

sufficient only for
combination of
Other Person not sufficient not sufficient
pre-designed
software modules
sufficient only for sufficient only for
Independent combination of combination of
sufficient
person pre-designed pre-designed
software modules software modules
Independent possible but not
sufficient sufficient
department/group necessary
2315
2319 shall not have a superior role.
2320 NOTE 1 An “independent department” is not involved in design activities of the project. An “independent
2323 NOTE 2 Depending upon the company organisation and expertise within the company, the requirement for
2324 independent persons and departments can have to be met by using an external organisation. Conversely,
2325 companies that have internal organisations skilled in risk assessment and the application of safety-related
2326 systems, that are independent of and separate (by ways of management and other resources) from those
2327 responsible for the main development, can be able to use their own resources to meet the requirements for an
2328 independent organisation.

2329 8.4.1.4 Tools usage SW Level 3
2330 A suitable set of tools shall be selected (e.g. configuration management, simulation, and test
2331 equipment with test generator). Preferably, the recommended tools from the manufacturer
2332 should be applied. The availability of suitable tools for service, updating the machine, and
2333 parameterization over the lifetime of the safety-related control system shall be considered.
2334 Either the tools provided by the manufacturer of the equipment are used or the suitability of
2335 the tools shall be explained and documented.
2336 Suitability shall be proven as follows:
2337 – an analysis carried out to identify possible effects of a failure caused by these tools in the
2338 tool chain; and
2339 – appropriate fault avoiding and fault controlling measures be selected, applied, and their
2340 effectiveness be verified via rigorous testing and the results documented.
2341 NOTE 1 The appropriateness of fault avoiding and fault controlling measures depends on the severity of the
2342 consequence of a failure. The basis of this evaluation is an analysis. To carry out this analysis it is necessary to
2343 have knowledge regarding the application of the support tool and of the machine.
2344 NOTE 2 The effect of failures may vary between different support tools. Therefore IEC 61508-4 differentiates
2345 between three categories for off-line support tools used within the software development lifecycle. The analysis
2346 should point out, if a classification for off-line support tools, which are intended to be used outside the software
2347 lifecycle, is appropriate.
2348 NOTE 3 See IEC 61508-4 for definition of support tools and examples.
2349 NOTE 4 This standard does not specify any measures for avoiding or controlling faults of off-line support tools. For
2350 examples see IEC 61508-3, 7.4.4.
ENTWURF OVE
– 68 – IEC CDV 62061  IEC 2019
2351 8.4.2 Software Design SW Level 3

2353 The software design specification shall be developed on basis of the software safety
2354 requirements and managed throughout the lifecycle of the SCS.
2355 8.4.2.2 Software safety requirements SW Level 3

2356 To support the software design process the following information shall be considered:
2357 a) specification of the safety function(s) (see 5.2);

2358 b) configuration or architecture of the SCS (e. g. hardware architecture, wiring diagram,
2359 safety-related inputs and outputs);
2360 c) response time requirements;
2361 d) operator interfaces and controls, such as: switches, joysticks, mode selector, dials, touch
2362 sensitive control devices, keypads, etc.;
2363 e) relevant modes of operation of the machine;
2364 f) requirements on diagnostics for hardware including the characteristics of sensors, final
2365 actuators, etc.;
2366 g) effects of mechanical tolerances, e.g. of sensors and/or their sensing counter parts;
2367 h) coding guidelines.
2368 When applying SW level 3 the tables of IEC 61508-3:2010, Annex A and Annex B shall be
2369 taken into consideration when it is appropriate to use alternative techniques and measures of
2370 an equivalent effectiveness. IEC 61508-7 provides additional information.
2371 The design and choice of the language chosen to satisfy the required SIL of the SCS shall be
2372 appropriate for the application.
2373 The design shall include self-monitoring of control flow and data flow appropriate to the SIL of
2374 the SCS. On failure detection, appropriate actions shall be performed to achieve or maintain a
2375 safe state.
2376 8.4.2.3 Software design specification SW Level 3
The software design specification shall be derived from the software safety requirements of
2377
2378 the SCS.
2379 The software design specification shall be:
2380 – structured, reviewable, testable, understandable, maintainable and operable;

2381 – developed for each subsystem on the basis of the SCS specification and architecture;
2382 – sufficiently detailed to allow the design and implementation of the SCS to achieve the
2383 required level of safety (SIL), and to allow verification and testing.
2384 – traceable back to the specification of the software safety requirements of the SCS. This
2385 means that the specification is as such understandable such that another person (e.g.
2386 non-software specialist) can verify if the specification corresponds to the software safety
2387 requirements of the safety functions defined in the risk assessment.
2388 – free of ambiguous terminology and irrelevant descriptions.
2389 It shall be possible to relate the inputs of the software design specification in a straightforward
2390 manner to the desired outputs and vice versa. Where appropriate, easy readable semi-formal
2391 methods such as cause&effect tables, logic tables or diagrams, function-blocks or sequence
2392 diagrams shall be used in the documentation.
2393 NOTE 1 Where appropriate depends on the number of safety functions involved in the program. Whenever the total
2394 amount of safety functions inside the program is larger than 3, it is considered appropriate.
2395 The following shall be specified within the software design specification:
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 69 –
2396 a) logic of the safety functions, including safety-related inputs and outputs and proper
2397 diagnostics on detected faults. Possible methods include, but are not limited to,
2398 cause&effect table, written description or function blocks;
2399 NOTE 2 Faults can also be detected by hardware (e.g. signal discrepancy detected by input card).
2400 b) test cases that include:
2401 – the specific input value(s) for which the test is carried out and the expected test results
2402 including pass/fail criteria;
2403 – fault insertion or injection(s).
2404 NOTE 3 For simple functions the test case(s) can be given implicitly by the specification of the safety function.
2405 c) diagnostic functions for input devices, such as sensing elements and switches, and final
2406 control elements, such as solenoids, relays, or contactors;
2407 d) functions that enable the machine to achieve or maintain a safe state;
2408 e) functions related to the detection, annunciation and handling of faults;
2409 f) functions related to the periodic testing of SCS(s) on-line and off-line;
2410 g) functions that prevent unauthorized modification of the SCS (e. g. password);
2411 h) interfaces to non SCS;
2412 i) safety function response time;
2413 j) in complicated cases it is recommended to specify the software architecture (e. g.
2414 invocation hierarchies, data flow).
2415 NOTE 4 Guidance on software documentation is given in IEC 61508, ISO/IEC/IEEE 26512:2011
2416 It is recommended to use pre- designed software modules within the software design
2417 specification wherever possible
2418 It is recommended that in case of pre- designed safety sub-functions, for example IEC 61800-5-
2419 2, a reference to the specification provided by the manufacturer should be used.
2420 The information in the software design specification shall be reviewed and where necessary
2421 revised, to ensure that the requirements of the software safety requirements (see 8.4.2.2) are
2422 adequately specified.
2423 8.4.3 Software system design SW Level 3

2425 Software system design starts with architecture definition. Software architecture shall be
2426 established that fulfils the software design specification. The software architecture defines the
2427 major elements and subsystems of the software, how they are interconnected and how the
2428 required attributes will be achieved. It also defines the overall behavior of the software, and
2429 how software elements interface and interact. Examples of major software elements include
2430 operating systems, databases, input/output subsystems, communication subsystems,
2431 application programs, programming and diagnostic tools, etc.
2432 The software system design shall follow a modular approach with a limited software module
2433 size a fully defined interface and one entry/one exit point in subroutines and functions. Each
2434 module should have a single, clearly understood function or purpose. The maximum module
2435 size should be limited to one complete safety function.
2436 The following programming techniques shall be used to avoid systematic failures:
2437 – range checking and plausibility checking of variables and configuration parameters;
2438 – temporal or logical program sequence monitoring to detect a defective program sequence:
2439 A defective program sequence exists if the individual elements of a program (e.g. software
2440 modules, subprograms or commands) are processed in the wrong sequence or period of
2441 time or if the clock of the processor is faulty (see IEC 61508-7:2010, A.9);
2442 – limiting the number or extent of global variables.
2443 NOTE For Software level 3 see Annex G of IEC 61508-7 for guidance on object oriented architecture and design.
ENTWURF OVE
– 70 – IEC CDV 62061  IEC 2019
2444 8.4.3.2 Software system design specification SW Level 3

2445 A software system design specification shall be provided as an output of the software system
2446 design. This shall explain the main software aspects such as indicated in the following list for
2447 example:
2448 – the software architecture that defines the structure decided to satisfy the software design
2449 specification;
2450 – the global data;
2451 – data libraries used;
2452 – pre-existing software modules used;
2453 – diagnostic functions (internal, external);
2454 – programming tools including information which uniquely identifies the tool;
2455 – integration test cases and procedures, including specification of the test environment,
2456 support software, configuration description and procedures for corrective action on failure
2457 of test.
2458 The information contained in the software system specification shall be reviewed against the
2459 software design specification.
2460 8.4.4 Module design SW Level 3

2462 Where previously developed software library modules are to be used as part of the design,
2463 their suitability in satisfying the specification of requirements of the software safety shall be
2464 analyzed. Constraints from the previous software development environment (for example
2465 operating system and compiler dependencies) shall be evaluated.
2466 8.4.4.2 Input information SW Level 3

2467 For software modules the following information shall be available in the software system
2468 design specification:
2469 a) module description;

2470 b) module interface (inputs and outputs with data types and, if necessary, with data ranges);
2471 c) module libraries used;

2472 d) special coding rules.
2473 8.4.4.3 Module design specification SW Level 3
2474 The module design specification shall contain the following information:
2475 a) description of the logic (i.e. the functionality) of each module;

2476 b) fully defined input and output interfaces assigned for each module;
2477 c) format and value ranges of input and output data and their relation to modules;
2478 d) test cases which shall include normal and outside normal operation;
2479 NOTE Although test cases usually comprise the individual testing of parameters within their specified ranges, a
2480 varying combination of these parameters can introduce unpredicted operation.
2481 e) documentation of the interrupts.

2482 This information shall be reviewed against the input information (see 8.4.4.2).
2483 8.4.5 Coding SW Level 3

2484 Software shall be developed in accordance with the design specifications and coding rules.
2485 Coding rules can be either well-known industry standards or can be internal to the
2486 manufacturer. The code shall be reviewed against the design specifications and coding rules.
2487 NOTE 1 Coding rules are intended to restrict the freedom of programming in order to avoid the program code
2488 becoming incomprehensible and in order to reduce the likelihood of the program entering unintended states
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 71 –
2489 NOTE 2 Coding rules usually define a subset of a programming language or use of a strongly typed programming
2490 language (see IEC 61508-7:2010, C4.1).
2491 The output of coding shall comprise
2492 – source code listing (e.g. ladder, function blocks, models);

2493 – code review report.
2494 Some typical coding rules to be applied, but not limited to, are:
2495 – Make sure the structure of the program is as easy and clear as possible
2496 – Structure of the program should be such that the logical flow starts at the top and follow in
2497 the effective sequence
2498 – Every part has to have sufficient comments in a predefined way
2499 – Use the same names for parameters as during design
2500 – Make sure the name represents the clear function of the parameter
2501 – Make sure you have a predefined state. Limit the use of set/reset for safety functions
2502 – Safety outputs can only be assigned once inside a program
2503 – Non safety parameters can never be used to bypass safety functions
2504 8.4.6 Module test SW Level 3
2505 Each module, which was not previously assessed, shall be tested by functional and black-box
2506 or grey-box testing as required against the test cases defined in the module design.
2507 If the module does not pass the testing then predefined corrective action shall be taken.
2508 The test results, and corrective actions, shall be documented.

2509 NOTE 1 Functional testing aims to reveal failures during the specification and design phases, and to avoid failures
2510 during implementation and the integration of software and hardware.
2511 NOTE 2 Black-box testing aims to check the dynamic behaviour under real functional conditions, and to reveal
2512 failures to meet functional specification, and to assess utility and robustness. Grey-box testing is similar to Black-
2513 box testing but additionally monitors relevant test parameter(s) inside the software module.
2514 Module testing shall use as a minimum dynamic analysis and testing
2515 8.4.7 Software integration testing SW Level 3

2516 The software shall be tested against the integration test cases. The results of software
2517 integration testing shall be documented.
2518 NOTE The objective of these tests is to show that all software modules and software elements/subsystems interact
2519 correctly to perform their intended function and do not perform unintended functions. This does not imply testing of
2520 all input combinations, nor of all output combinations. Testing all equivalence classes or structure based testing
2521 can be sufficient. Boundary value analysis or control flow analysis can reduce the test cases to an acceptable
2522 number. Analyzable programs make the requirements easier to fulfil.
2523 8.4.8 Software testing SW Level 3

2525 The main goal of software testing is to ensure that the functionality as detailed in the software
2526 design specification is achieved.
2527 NOTE This can imply testing of all input combinations, and/or all output combinations.
2528 The main output of software testing is a document e.g. a test report with test cases and test
2529 results allowing an assessment of the test coverage.
2530 Software testing shall also include failure simulation and the associated failure reaction
2531 depending on the required safety integrity.
2532 When pre- designed input cards or software modules which incorporate failure detection and
2533 reaction are utilised (e.g. discrepancy of input signals or feedback contact of output) then the
2534 test of those failure detection and reaction is not necessary. In that case only the integration
ENTWURF OVE
– 72 – IEC CDV 62061  IEC 2019
2535 of these input cards or software modules in accordance with the manufacturer’s specification
2536 shall be tested.
2537 Software testing can be carried out as part of the system validation if testing is performed on
2538 the target hardware.
2539 Functional testing as a basic measure shall be applied. Code should be tested by simulation
2540 where feasible.
2541 It is recommended to define general guidelines or procedures for the testing of safety-related
2542 software. These guidelines or procedures should include:
2543 – types of tests to be performed;

2544 – specification of test equipment including tools, support software and configuration
2545 description;
2546 – management of software versioning during testing and correcting of safety-related
2547 software;
2548 – corrective actions on failed test;
2549 – criteria for the completion of the test with respect to the related functions or requirements;
2550 physical location(s) of the testing, such as computer simulation, bench top or lab, factory,
2551 or on the machine.
2552 8.4.8.2 Test planning and execution SW Level 3
2553 Test planning based on test cases shall include:
2554 – definition of roles and responsibilities by name;

2555 – installation testing;
2556 – functional testing.
2557 Testing of software includes two types of activities:
2558 – Static analysis: Analysis of software documentation, e.g. by review, inspection, walk-
2559 through, control flow analysis, or dataflow analysis.
2560 – Dynamic testing: Execution of the software in a controlled and systematic way, so as to
2561 demonstrate the presence of the required behaviour and the absence of unwanted
2562 behaviour. This includes, in particular, functional testing, black-box or grey-box-testing.
2563 In the early phases of the software lifecycle, verification is static. Dynamic testing becomes
2564 possible, when code is produced. For verifying the output of software lifecycle activities, both
2565 activities are required in combination. For further description of static analysis and dynamic
2566 testing see IEC61508:2010.
2567 The following is required for verification and testing of safety-related software:
2568 – static analysis shall be done and documented in any case;

2569 – dynamic testing shall be done and documented for any software, which is required for a
2570 safety function of SIL 2 or higher;
2571 – where software is required for a safety function of up to SIL 1 and is not subject to
2572 dynamic testing, this shall be justified with respect to the structural simplicity of the
2573 software;
2574 – for dynamic testing, every subprogram (subroutine or function) shall have been called at
2575 least once (entry points) during testing;
2576 – for software, which is required for a safety function of SIL 2 or higher, all statements in
2577 the code shall be executed at least once during dynamic testing;
2578 – where software is used in diagnostic functions for controlling random hardware failures,
2579 dynamic testing shall address the correct implementation of the diagnostics e.g. by fault
2580 insertion testing;
2581 – dynamic testing shall include a final test on the target hardware.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 73 –
2582 8.4.9 Documentation SW Level 3

2583 All life cycle activities shall be traceable forwards and backwards from the specification of the
2584 safety function(s) and through the completed validation plan.
2585 The inputs and outputs of all software safety lifecycle phases shall be documented and made
2586 available to the relevant persons.
2587 The test activities results, and corrective actions taken shall be documented.
2588 8.4.10 Configuration and modification management process SW Level 3

2589 Any modifications or changes to software shall be subject to an impact analysis that identifies
2590 all software parts affected and the necessary re-design, re-review and re-test activities to
2591 confirm that the relevant software safety requirements are still satisfied.
2592 Configuration management processes and modifications management processes shall be

2593 defined and documented. This should, as a minimum, include the following items:
2594 – articles managed by the configuration, at least: software safety requirements, preliminary
2595 and detailed software design, source code modules, plans, procedures and results of the
2596 validation tests;
2597 – identification rules which uniquely identify each software module or configuration element;
2598 – modification processes which are comprehensive from request through to implementation.
2599 For each article of configuration, it should be possible to identify any changes that can have
2600 occurred and the versions of any associated elements.
2601 NOTE 1 The purpose is to be able to trace the historical development of each article: what modifications have been
2602 made, why, and when.
2603 Software configuration management should allow a precise and unique software version
2604 identification to be obtained. Configuration management should associate all the articles (and
2605 their version) needed to demonstrate the functional safety.
2606 All articles in the software configuration should be covered by the configuration management
2607 procedure before being tested or being requested by the analyst for final software version
2608 evaluation.
2609 NOTE 2 The objective here is to ensure that the evaluation procedure be performed on software with all elements
2610 in a precise state. Any subsequent change can necessitate revision of the software so that it can be identifiable by
2611 the analyst.
2612 Procedures for the archiving of software and its associated data should be established
2613 (methods for storing backups and archives).
2614 NOTE 3 These backups and archives can be used to maintain and modify software during its functional lifetime.
2615 9 Validation
2616 9.1 Validation principles
2617 In this standard, the purpose of the validation is to confirm that the SCS reaches the safety
2618 requirements specification given in Clause 5.
2619 NOTE 1 In this standard, the validation is limited to the designed SCS or a part of it supporting the safety functions
2620 required from the risk reduction strategy at the machine level given in ISO 12100. The SCS validation result is
2621 intended to be part of the overall validation of the machine.
2622 The validation activities consist of collecting and checking the availability of the evidence
2623 demonstrating the completeness of each design activity identified in the safety plan.
2624 The validation to be applied to the SCS includes inspection (e.g. by analysis) and testing of
2625 the SCS to ensure that it achieves the requirements stated in the safety requirements
2626 specification (according to Clause 5).
2627 The validation shall demonstrate that the SCS meets the requirements and, in particular, the
2628 following:
ENTWURF OVE
– 74 – IEC CDV 62061  IEC 2019
2629 a) the specified functional requirements of the safety functions provided by that part
2630 (see 5.2), as set out in the design rationale;
2631 b) the requirements of the specified SIL;
2632 Validation should be carried out by persons who are independent from the design of the SCS.
2633 NOTE 2 “Independent person” does not necessarily mean that a third-party test is required.
2634 The analysis should be started as early as possible in, and in parallel with, the design
2635 process. Problems can then be corrected early while they are still relatively easy to correct,
2636 i.e. during steps “design and technical realization of the safety function” and “evaluate the
2637 SIL”. It can be necessary for some parts of the analysis to be delayed until the design is well
2638 developed.
2639 Figure 14 gives an overview of the validation process: Validation consists of applying analysis
2640 (see 9.2) and executing functional tests (see 9.3) under foreseeable conditions in accordance
2641 with the validation plan. The balance between the analysis and testing depends on the
2642 technology used for the safety-related parts and the required safety integrity level. For
2643 architectures with diagnostic function the validation of the safety function shall also include
2644 testing under fault conditions to show that the fault reaction will be initiated by the
2645 implemented diagnostic function.
2646 Where appropriate due to the system’s size, complexity or the effects of integrating it with the
2647 control system (of the machinery), special arrangements should be made for
2648 – validation of the subsystem separately before integration, including simulation of the
2649 appropriate input and output signals, and
2650 – validation of the effects of integrating safety-related parts into the remainder of the control
2651 system within the context of its use in the machine.
2652 “Modification of the design” in Figure 14 refers to the design process. If the validation cannot
2653 be successfully completed, changes in the design are necessary. The validation of the SCS
2654 should then be repeated as appropriate. This process should be iterated until the SCS for
2655 each safety function is successfully validated.
2656
IEC CDV 62061  IEC 2019
– 75 –
ENTWURF OVE
2657
– 76 –
ENTWURF OVE
Figure 14 – Overview of the validation process

IEC CDV 62061  IEC 2019
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 77 –
2658 9.1.1 Validation plan

2659 The validation plan shall identify and describe the requirements for carrying out the validation
2660 process. The validation plan shall also identify the means to be employed to validate the
2661 specified safety functions. It shall set out, where appropriate:
2662 a) the identity of the specification documents,

2663 b) the operational and environmental conditions during testing,
2664 c) the analyses and tests to be applied,
2665 d) the reference to test standards to be applied,
2666 e) the persons or parties responsible for each step in the validation process, and
2667 f) the required equipment.
2668 Subsystems which have previously been validated to the same specification need only a
2669 reference to that previous validation.
2670 9.1.1.1 Minimum levels of independence for validation activities

2671 The minimum level of independence of those carrying out validation shall be as specified in
2672 the table. The level of independence specified is the minimum for the safety integrity level.
2673 The table shall be interpreted as follows:
2674 - X: Design or integration of SCS.
2675 - MM: Minor modification with low degree of complexity (change on existing safety
2676 function or new safety function which is similar to an existing safety function)
2677 Depending on a number of factors specific to the application it could be appropriate to choose
2678 a higher level of independence.
2679 Factors that will make a higher level more appropriate are:
2680 - – lack of previous experience with a similar design;
2681 - – greater degree of complexity;
2682 - – greater degree of novelty of design;
2683 - – greater degree of novelty of technology.
2684 Table 9 – Minimum levels of independence for validation activities

independence
SIL 1 SIL 2 SIL 3
Other Person MM MM not sufficient

Independent
X X MM
person
Independent possible but not possible but not
X
department/group necessary necessary
2685
2689 shall not have a superior role.
2690 NOTE An “independent department” is not involved in design activities of the project. An “independent
2693 9.1.2 Use of generic fault lists
2694 Validation involves consideration of the behaviour of the SCS for all faults to be considered. A
2695 basis for fault consideration is given in the tables of fault lists of ISO 13849-2, Annexes A to
2696 D, which are based on experience and which contain:
2697 – the components/elements to be included, e.g. conductors/cables,

2698 – the faults to be taken into account, e.g. short circuits between conductors,
ENTWURF OVE
– 78 – IEC CDV 62061  IEC 2019
2699 – the permitted fault exclusions, taking into account environmental, operating and
2700 application aspects, and
2701 – a remarks section giving the reasons for the fault exclusions.
2702 Only permanent faults are taken into account in the fault lists.
2703 9.1.3 Specific fault lists

2704 If necessary, a specific product-related fault list shall be generated as a reference document
2705 for the validation of the subsystem(s) and/or subsystem element(s).
2706 NOTE The list can be based on the appropriate generic list(s) found in the annexes A to D in ISO 13849-2.
2707 Where the specific product-related fault list is based on the generic list(s) it shall state
2708 a) the faults taken from the generic list(s) to be included,

2709 b) any other relevant faults to be included but not given in the generic list (e.g. common-
2710 cause failures),
2711 c) the faults taken from the generic list(s) which may be excluded on the basis that the
2712 criteria given in the generic list(s) are satisfied (see 7.3.3),
2713 d) and exceptionally any other faults for which the generic list(s) do not permit an exclusion,
2714 but for which justification and rationale for an exclusion is presented (see 7.3.3).
2715 Where this list is not based on the generic list(s), the designer shall give the rationale for fault
2716 exclusions.
2717 9.1.4 Information for validation

2718 The information required for validation will vary with the technology used, the architectural
2719 constraints and SIL to be demonstrated, the design rationale of the system, and the
2720 contribution of the SCS to the reduction of the risk. Documents containing sufficient
2721 information from the following list shall be included in the validation to demonstrate that the
2722 safety-related parts perform the specified safety functions to the required SIL and
2723 architectural constraints:
2724 a) specification of the required characteristics of each safety function, especially the required
2725 SIL and architectural constraints;
2726 b) drawings and specifications, e.g. for mechanical, hydraulic and pneumatic parts, printed
2727 circuit boards, assembled boards, internal wiring, enclosure, materials, mounting;
2728 c) block diagram(s) with a functional description of the blocks;
2729 d) circuit diagram(s), including interfaces/connections;
2730 e) functional description of the circuit diagram(s);
2731 f) time sequence diagram(s) for switching components, signals relevant for safety;
2732 g) description of the relevant characteristics of components previously validated;
2733 h) for safety-related parts other than those listed in g), component lists with item
2734 designations, rated values, tolerances, relevant operating stresses, type designation,
2735 failure-rate data and component manufacturer, and any other data relevant to safety;
2736 i) analysis of all relevant faults according to 9.1.2 and 9.1.3, such as those listed in the
2737 tables of ISO 13849-2, Annexes A to D, including the justification of any excluded faults;
2738 j) an analysis of the influence of processed materials;
2739 k) information for use, e.g. installation and operation manual/instruction handbook.
2740 Where software is relevant to the safety function(s), the software documentation shall include
2741 – a specification which is clear and unambiguous and which states the safety integrity the
2742 software is required to achieve,
2743 – evidence that the software is designed to achieve the required SIL (see 9.5.3), and
2744 – details of the verification (in particular test reports) carried out to prove that the required
2745 SIL is achieved.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 79 –
2746 Information is required on how the SIL and average probability of a dangerous failure per hour
2747 is determined. The documentation of the quantifiable aspects shall include
2748 – the basic subsystem architecture according to 7.5.2,

2749 – the determination reliability parameters (e.g. MTTF D or λ D of subsystem elements and
2750 CCF), and
2751 – the determination of the architectural constraints.
2752 Information is required for documentation on systematic aspects of the SCS. Information is
2753 required to describe how the combination of several subsystems achieves a SIL in
2754 accordance with the required SIL.
2755 9.1.5 Validation record

2756 Validation by analysis and testing shall be recorded, see also Clause 10.
2757 9.2 Analysis as part of validation

2758 9.2.1 General
2759 Validation of the SCS shall be carried out by analysis. Inputs to the analysis include the
2760 following:
2761 – the safety function(s), their characteristics and the safety integrity specified according to
2762 Clause 5;
2763 – the system structure (e.g. basic subystem architectures) according to 7.5.2;
2764 – the quantifiable aspects (e.g. MTTF D or λ D , DC and CCF) according to 6.3.2;
2765 – the non-quantifiable, qualitative aspects which affect system behaviour (if applicable,
2766 software aspects);
2767 – deterministic arguments.
2768 NOTE 1 A deterministic argument is an argument based on qualitative aspects (e.g. quality of manufacture,
2769 experience of use). This consideration depends on the application, which, together with other factors, can affect
2770 the deterministic arguments.
2771 NOTE 2 Deterministic arguments differ from other evidence in that they show that the required properties of the
2772 system follow logically from a model of the system. Such arguments can be constructed on the basis of simple,
2773 well-understood concepts.
2774 9.2.2 Analysis techniques

2775 The selection of an analysis technique depends upon the particular object. Two basic
2776 techniques exist, as follows.
2777 a) Top-down (deductive) techniques are suitable for determining the initiating events that can
2778 lead to identified top events, and calculating the probability of top events from the
2779 probability of the initiating events. They can also be used to investigate the consequences
2780 of identified multiple faults.
2781 EXAMPLE Fault tree analysis (FTA, see IEC 61025), event tree analysis (ETA).
2782 b) Bottom-up (inductive) techniques are suitable for investigating the consequence of
2783 identified single faults.
2784 EXAMPLE Failure modes and effects analysis (FMEA, see IEC 60812) and failure modes, effects and criticality
2785 analysis (FMECA).
2786 9.2.3 Verification of safety requirements specification for safety functions
2787 The requirements specification for the safety function shall be verified to ensure consistency
2788 and completeness and correctness for its intended use.
2789 Verification may be performed by reviews and inspections of the SCS safety requirements and
2790 design specification(s), in particular to prove that all aspects of
2791 – the intended application requirements and safety needs, and

2792 – the operational and environmental conditions and possible human errors (e.g. misuse)
2793 have been considered.
ENTWURF OVE
– 80 – IEC CDV 62061  IEC 2019
2794 9.3 Testing as part of validation

2795 9.3.1 General
2796 Testing shall be carried out to complete the validation. Validation tests shall be planned and
2797 implemented in a logical manner. In particular:
2798 a) a test plan shall be produced before testing begins that shall include
2799 1) the test specifications;
2800 2) the required outcome of the tests for compliance, and
2801 3) the chronology of the tests;
2802 b) test records shall be produced that include
2803 1) the name of the person carrying out the test;
2804 2) the environmental conditions;
2805 3) the test procedures and equipment used;
2806 4) the date of the test, and
2807 5) the results of the test;
2808 c) the test records shall be compared with the test plan to ensure that the specified
2809 functional and performance targets are achieved.
2810 The test sample shall be operated as near as possible to its final operating configuration, i.e.
2811 with all peripheral devices and covers attached.
2812 This testing can be applied manually or automatically, e.g. by computer.
2813 Where applied, validation of the safety functions by testing shall be carried out by applying
2814 input signals, in various combinations, to the SCS. The resultant response at the outputs shall
2815 be compared to the appropriate specified outputs.
2816 It is recommended that the combination of these input signals be applied systematically to the
2817 control system and the machine. An example of this logic is power-on, start-up, operation,
2818 directional changes, restart-up. Where necessary, an expanded range of input data shall be
2819 applied to take into account anomalous or unusual situations, in order to see how the SCS
2820 responds. Such combinations of input data shall take into account foreseeable incorrect
2821 operation(s).
2822 The objectives of the test will determine the environmental condition for that test, which can
2823 be one or another of the following:
2824 – the environmental conditions of intended use;

2825 – the conditions at a particular rating;
2826 – a given range of conditions if drift is expected.
2827 The range of conditions which is considered stable and over which the tests are valid should
2828 be agreed between the designer and the person(s) responsible for carrying out the tests and
2829 should be recorded.
2830 9.3.2 Measurement accuracy

2831 The accuracy of measurements during the validation by testing shall be appropriate for the
2832 test carried out. In general, these measurement accuracies shall be within 5 K for temperature
2833 measurements and 5 % for the following:
2834 a) time measurements;

2835 b) pressure measurements;
2836 c) force measurements;
2837 d) electrical measurements;
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 81 –
2838 e) relative humidity measurements;

2839 f) linear measurements.
2840 Deviations from these measurement accuracies shall be justified.
2841 9.3.3 More stringent requirements

2842 If, according to its accompanying documentation, the requirements for the SCS exceed those
2843 within this standard, the more stringent requirements shall apply.
2844 NOTE More stringent requirements can apply if the control system has to withstand particularly adverse service
2845 conditions, e.g. rough handling, humidity effects, hydrolysation, ambient temperature variations, effects of chemical
2846 agents, corrosion, high strength of electromagnetic fields — for example, due to close proximity of transmitters.
2847 9.3.4 Number of test samples
2848 Unless otherwise specified, the tests shall be made on a single production sample of the
2849 subsystem being tested.
2850 Subsystem(s) under test shall not be modified during the course of the tests.
2851 Certain tests can permanently change the performance of some components. Where a
2852 permanent change in a component causes the safety-related part to be incapable of meeting
2853 the requirements of further tests, a new sample or samples shall be used for subsequent
2854 tests.
2855 Where a particular test is destructive and equivalent results can be obtained by testing part of
2856 SCS in isolation, a sample of that SCS may be used instead of the whole SCS for the purpose
2857 of obtaining the results of the test. This approach shall only be applied where it has been
2858 shown by analysis that testing of a part of SCS is sufficient to demonstrate the safety integrity
2859 of the whole SCS that performs the safety function.
2860 9.4 Validation of the safety function

2861 9.4.1 General
2862 The validation of safety functions shall demonstrate that the SCS provides the safety
2863 function(s) in accordance with their specified characteristics.
2864 NOTE 1 A loss of the safety function in the absence of a hardware fault is due to a systematic fault, which can be
2865 caused by errors made during the design and integration stages (a misinterpretation of the safety function
2866 characteristics, an error in the logic design, an error in hardware assembly, an error in typing the code of software,
2867 etc.). Some of these systematic faults will be revealed during the design process, while others will be revealed
2868 during the validation process or will remain unnoticed. In addition, it is also possible for an error to be made (e.g.
2869 failure to check a characteristic) during the validation process.
2870 Validation of the specified characteristics of the safety functions shall be achieved by the
2871 application of appropriate measures from the following list:
2872 – functional analysis of schematics, reviews of the software (see 9.5.3);

2873 NOTE 2 Where a machine has complex or a large number of safety functions, an analysis can reduce the
2874 number of functional tests required.
2875 – simulation;
2876 – check of the hardware components installed in the machine and details of the associated
2877 software to confirm their correspondence with the documentation (e.g. manufacture, type,
2878 version);
2879 – functional testing of the safety functions in all operating modes of the machine, to
2880 establish whether they meet the specified characteristics (see Clause 5). The functional
2881 tests shall ensure that all safety-related outputs are realized over their complete ranges
2882 and respond to safety-related input signals in accordance with the specification. The test
2883 cases are normally derived from the specifications but could also include some cases
2884 derived from analysis of the schematics or software;
2885 – extended functional testing to check foreseeable abnormal signals or combinations of
2886 signals from any input source, including power interruption and restoration, and incorrect
2887 operations;
2888 – check of the operator–SCS interface for the meeting of ergonomic principles.
ENTWURF OVE
– 82 – IEC CDV 62061  IEC 2019
2889 NOTE 3 Other measures against systematic failures mentioned in 9.5.2 (e.g. diversity, failure detection by
2890 automatic tests) can also contribute in the detection of functional faults.
2891 9.4.2 Analysis and testing

2892 Analysis and testing will require failure analysis using circuit diagrams and, where the failure
2893 analysis does not reach a clear result:
2894 – fault injection tests on the actual circuit and fault initiation on actual components,
2895 particularly in parts of the system where there is doubt regarding the results obtained from
2896 failure analysis (see 9.2); or
2897 – a simulation of control system behaviour in the event of a fault, e.g. by means of hardware
2898 and/or software models.
2899 Fault injection or fault simulation tests can be performed at different levels, e.g. subsystem
2900 element or subsystem level, considering the specific application and test setup.
2901 When validating by testing, the tests should include, as appropriate,
2902 – fault injection tests into a production sample,

2903 – fault injection tests into a hardware model,
2904 – software simulation of faults, and
2905 – subsystem failure, e.g. power supplies.
2906 The precise instant at which a fault is injected into a system can be critical. The worst-case
2907 effect of a fault injection shall be determined by analysis and by injecting the fault at this
2908 appropriate critical time.
2909 9.5 Validation of the safety integrity of the SCS

2910 9.5.1 Validation of subsystem(s)
2911 The safety integrity of each subsystem of the SCS is characterized by its SIL and shall be
2912 validated by confirming (verification) the following:
2913 – the used architecture (see 7.5.2) and

2914 – the probability of dangerous random hardware failure (see 7.6) and
– the systematic integrity (see 7.3.2, Software, CCF).
2915
2916 In this context the validation of MTTF D or λ D , DC and CCF is typically performed by analysis
2917 and visual inspection. The MTTF D or λ D values for components (including B 10 or B 10D , T 10D and
2918 duty cycle values) shall be checked for plausibility. For example, the value given on the
2919 manufacturer’s datasheet is to be compared with Annex C.
2920 NOTE 1 A fault exclusion implies infinite MTTF D ; therefore, the component will not contribute to the calculation of
2921 channel MTTF D .
2922 The DC values for components (subsystem elements) and/or logic blocks shall be checked for
2923 plausibility (e.g. against measures in Annex E). The correct implementation (hardware and
2924 software) of checks and diagnostics, including appropriate fault reaction, shall be validated by
2925 testing under typical environmental conditions in use.
2926 The correct implementation of sufficient measures against common-cause failures shall be
2927 validated (e.g. against Annex F). Typical validation measures are static hardware analysis
2928 and functional testing under environmental conditions.
2929 NOTE 2 Generally for the specification of the MTTF D or λ D values of electronic components, an ambient
2930 temperature of +40 °C is taken as a basis. During validation, it is important to ensure that, for MTTF D or λ D values,
2931 the environmental and functional conditions (in particular temperature) taken as basis are met. Where a device, or
2932 component, is operated significantly above (e.g. more than 15 °C) the specified temperature of +40 °C, it will be
2933 necessary to use MTTF D or λ D values for the increased ambient temperature
2934 9.5.2 Validation of measures against systematic failures
2935 The validation of measures against systematic failures can typically be provided by:
2936 a) inspections of design documents which confirm the application of

ENTWURF OVE
IEC CDV 62061  IEC 2019 – 83 –
2937 – basic and well-tried safety principles (see ISO 13849-2, Annexes A to D);
2938 – further measures for avoidance of systematic failures, and
2939 – further measures for the control of systematic failures such as hardware diversity,
2940 modification protection or failure assertion programming;
2941 b) failure analysis (e.g. FMEA);
2942 c) fault injection tests/fault initiation;
2943 d) inspection and testing of data communication, e.g. parameterization, installation;
2944 e) checking that a quality management system avoids the causes of systematic failures in
2945 the manufacturing process.
2946 9.5.3 Validation of safety-related software
2947 The validation of software shall include:
2948 – the specified functional behaviour and performance criteria (e.g. timing performance) of
2949 the software when executed on the target hardware,
2950 – verification that the software measures are sufficient for the specified required SIL of the
2951 safety function, and
2952 – measures and activities taken during software development to avoid systematic software
2953 faults.
2954 As a first step, check that there is documentation for the specification and design of the
2955 safety-related software. This documentation shall be reviewed for completeness and absence
2956 of erroneous interpretations, omissions or inconsistencies.
2957 NOTE In the case of small programs, an analysis of the program by means of reviews or walk-through of control
2958 flow, procedures, etc. using the software documentation (control flow chart, source code of modules or blocks, I/O
2959 and variable allocation lists, cross-reference lists) can be sufficient.
2960 In general, software can be considered a “black box” or “grey box” (see Clause 8), and
2961 validated by the black- or grey-box test, respectively.
2962 Depending on the required SIL the tests should include:
2963 – black-box testing of functional behaviour and performance (e.g. timing performance),
2964 – additional extended test cases based upon limit value analyses, recommended for SIL 2 or
2965 SIL 3,
2966 – I/O tests to ensure that the safety-related input and output signals are used properly, and
2967 – test cases which simulate faults determined analytically beforehand, together with the
2968 expected response, in order to evaluate the adequacy of the software-based measures for
2969 control of failures.
2970 Individual software functions which have already been validated do not need to be validated
2971 again. Where a number of such safety function blocks are combined for a specific project,
2972 however, the resulting total safety function shall be validated.
2973 Software documentation shall be checked to confirm that sufficient measures and activities
2974 have been implemented against systematic software faults in accordance with the simplified
2975 V-model (see Figure 11).
2976 The measures for software implementation and configuration and modification management
2977 according to Clause 8, which depend on the SIL to be attained, shall be examined with regard
2978 to their proper implementation.
2979 Should the safety-related software be subsequently modified, it shall be revalidated on an

2980 appropriate scale.
2981 9.5.4 Validation of combination of subsystems

2982 Where the safety function is implemented by two or more subsystems, validation of the
2983 combination — by analysis and, if necessary, by testing — shall be undertaken to establish
2984 that the combination achieves the safety integrity specified in the design. Existing recorded
ENTWURF OVE
– 84 – IEC CDV 62061  IEC 2019
2985 validation results of subsystems can be taken into account. The following validation steps
2986 shall be performed:
2987 – inspection of design documents describing the overall safety function(s);

2988 – a check that the overall SIL of the subsystem combination has been correctly evaluated,
2989 based on the SIL of each individual subsystem (according to 6.3.2);
2990 – consideration of the characteristics of the interfaces, e.g. voltage, current, pressure, data
2991 format of information, signal level;
2992 – failure analysis relating to combination/integration, e.g. by FMEA;
2993 – for redundant systems, fault injection tests relating to combination/integration.
2994 9.5.5 Verification of safety integrity
2995 The following steps shall be performed:
2996 – verification for correct evaluation of SIL of the subsystem based on the architecture, and
2997 reliability parameters (e.g. DC and MTTF D or λ D );
2998 – verification that the SIL achieved by the SCS satisfies the required SIL in the safety
2999 requirements specification for the machinery: SIL ≥ required SIL.
3000 10 Documentation
3001 10.1 General
3002 The manufacturer of an SCS and the manufacturer of subsystems shall prepare the relevant
3003 technical documentation in 10.2 and information for use in 10.3.
3004 The documentation shall demonstrate the procedure that has been followed and the results
3005 that have been received.
3006 10.2 Technical documentation

3007 The documentation shall contain information relevant to the safety-related part:
3008 – safety function(s) provided by the SCS according to Clause 5 or the safety sub-function
3009 provided by the SCS subsystem;
3010 NOTE 1 Only safety functions which are required by the specific application need to be considered.
3011 – if the design includes the subsystem design (see Clause 7), then the technical
3012 documentation shall:
3013 • cover the test or analysis of fault behaviour leading to a loss of the safety function or
3014 • refer to a qualified example (e.g. an application note);
3015 – the characteristics of each safety function according to 5.2;
3016 – environmental conditions;
3017 – measures against systematic failure (e. g. within generic design rules completed by
3018 elements within the risk assessment document);
3019 – software documentation according to Clause 8;
3020 NOTE 2 In general, this documentation is foreseen as being for the manufacturer’s internal purposes and will not
3021 be distributed to the machine user.
3022 If well-tried components are used, the documentation of these components

3023 shall include following aspects:
3024 – Version, component and application description
3025 – Application specific information
3026 • use limits for the component to be regarded as well-tried
3027 • suitability analysis: e.g. functional behaviour, accuracy, behaviour in the case of a
3028 fault, time response, usability and maintainability
3029 • required testing
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 85 –
3030 – when based on past use for the demonstration of equivalence between the intended
3031 operation and the previous operation experience, an impact analysis on the differences
3032 between past use case and current situation should be present;
3033 The documentation shall be subject to version control.
3034 Table 10 summarizes the documentation to be available, where appropriate.
3035 Table 10 – Documentation of an SCS
Information required Subclause

Functional safety plan 4.3
Safety requirements specification (SRS) 5.2
Functional requirements specification (for SCS) 5.2.2
Safety integrity requirements specification (for SCS) 5.2.3
SCS design 6.3
Structured design process 4.2
Structure of s ub -functions 6.2.2
SCS architecture 6.2.2
Sub-function and Subsystem safety requirements 6.2.3
Subsystem realization 7.1
Subsystem architecture 7.2
Fault exclusions claimed when estimating fault tolerance/SFF 7.3.3.3 and 7.4.1
Subsystem assembly 7.4 and 7.5
Software safety requirements 8.3.2.2 or 8.4.2.2
Software based parameterization 6.5.5
Software configuration management items 8.3.8 or 8.4.10
Suitability of software development tools 8.3.1.4 or 8.4.1.4
Documentation of the application program 8.3.7 or 8.4.9
Results of application software module testing 8.3.5 or 8.4.6
Results of application software integration testing 8.4.7
Documentation of SCS integration (testing) 9.5.4
Documentation of well-tried components 10.2

Documentation for installation, use and maintenance 10.3
Documentation of SCS validation 9.4 and 9.5
Documentation for SCS configuration management 4.4
3036 Refer to Annex M which provides example of activates, documents and roles (see Figure
3037 M.2).
3038 10.3 Information for use of the SCS

3039 10.3.1 General
3040 The information for use of the SCS shall provide relevant information for installation, use and
3041 maintenance. This shall include a comprehensive description of the equipment, installation
3042 and mounting as following.
3043 10.3.1.1 Specification of safety integrity

3044 Specific information shall be provided on the safety integrity of the SCS, as follows:
3045 – SIL 1, 2 or 3
3046 – if relevant, architectural constraints of the subsystem(s);
3047 10.3.1.2 SCS and subsystems
3048 SCS are typically designed and implemented as a safety-related system by a machine
3049 manufacturer using available separate subsystems.
ENTWURF OVE
– 86 – IEC CDV 62061  IEC 2019
3050 Subsystems are typically manufactured and placed on the market as a complete device ready
3051 for use.
3052 Therefore there are different requirements for the information for use that apply to
3053 manufacturer of the machine or the manufacturer of the subsystems. A manufacturer of a
3054 machine can also have the role of a manufacturer of the SCS subsystem.
3055 10.3.2 Information for use given by the manufacturer of subsystems

3056 The principles of ISO 12100, 6.4 and the applicable sections of other relevant documents
3057 (e.g. IEC 60204-1:2016, Clause 17), shall be applied.
3058 In particular the manufacturer of a subsystem shall indicate in the instructions that information
3059 which is important for the safe installation, use and maintenance of the subsystem. This shall
3060 include, but is not limited to, the following:
3061 a) description of the subsystem including:

3062 – general description of the subsystem and its function;
3063 – installation instructions;
3064 – interfacing requirements;
3065 – configuration, settings or programming information where applicable a statement of the
3066 intended use of the subsystem and any measures that can be necessary to prevent
3067 reasonably foreseeable misuse.
3068 b) information on operating limits of the subsystem including:
3069 – specification of environmental limits e.g. temperature, lighting, vibration, noise ,
3070 atmospheric contaminants;
3071 – specification of interfacing limits e.g. electrical, hydraulic, pneumatic or mechanical
3072 characteristics;
3073 – specification of any other limits relevant to the intended safety functionality e.g.
3074 operating frequency, strength, range;
3075 c) a description of any fault exclusions essential for maintaining the intended safety
3076 integrity. Appropriate information (e.g. for modification, maintenance and repair) shall be
3077 given to ensure the continued justification of the fault exclusion(s);
3078 d) a description of any necessary measures at the subsystem to ensure that there will be no
3079 degradation of the intended SCS function caused by a machine control system
3080 e) response time of the subsystem;
3081 f) useful lifetime of the subsystem;
3082 g) information on diagnostic functions required for correct interfacing and safe use;
3083 h) information on indications and alarms;
3084 i) the nature and frequency of any required inspection procedures:
3085 j) the nature and frequency of any required test procedures, e.g. testing, whether the
3086 diagnostic is still working:
3087 k) provisions for the maintainability of the subsystem where relevant. All information for
3088 maintenance shall comply with ISO 12100:2010, 6.4.5.1 e). The information shall include:
3089 – procedures for fault diagnosis and repair;
3090 – procedures for confirming correct operation subsequent to repairs
3091 l) safety related parameters (e.g. PFH, PFD, SIL … ).
3092 10.3.3 Information for use given by the SCS integrator
3093 The SCS integrator (typically the manufacturer of the machine) shall include the relevant
3094 information in the instructions for use to enable the machine user to develop procedures to
3095 ensure that the required functional safety of the SCS is maintained during use and
3096 maintenance of the machine.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 87 –
3097 In particular SCS integrator shall indicate in the instructions that information which is
3098 important for the safe use of the SCS including information on any measures that can be
3099 necessary to prevent reasonably foreseeable misuse.
3100 Information for use shall include, but is not limited to, the following:
3101 a) operating limits of the SCS (including environmental conditions);

3102 b) clear descriptions and related instructions for the user interfaces with the SCS e.g.
3103 operator panel, indications and alarms;
3104 c) description of the safety functions implemented in the SCS, including description of
3105 hazards and hazardous situation, the safety state, process safety time, overview (block)
3106 diagram(s) and circuit diagram(s) where appropriate;
3107 d) a description (including interconnection diagrams) of the interaction (if any) between the
3108 SCS function (s) and the machine control system function(s);
3109 e) marking if required, according to ISO 12100:2010, 6.4.4;
3110 f) useful lifetime and requirements for the SCS components;
3111 g) information related to any muting and/or suspension of safety functions;
3112 h) any operating mode relevant to the safety function(s);
3113 i) inspection and periodic testing where relevant (e.g. a certain safety distances have to be
3114 tested periodically) including the nature of any required test procedures, see also for
3115 details 6.7.2;
3116 j) the tools necessary for maintenance and re-commissioning, and the procedures for
3117 maintaining the tools and equipment;
3118 k) provisions for maintenance of the SCS where relevant including any implications for fault
3119 exclusion. All information for maintenance shall comply with ISO 12100:2010, 6.4.5.1 e).
3120 The information shall include:
3121 – procedures for fault diagnosis and repair; e.g. instructions for SCS functional recovery
3122 in case of failure,
3123 – procedures for confirming correct operation subsequent to repairs,
3124 – preventive maintenance and corrective maintenance-
3125 NOTE 1 Periodic tests are those functional tests necessary to confirm correct operation and to detect faults.
3126 NOTE 2 Preventive maintenance are the measures taken to maintain the required performance of the SCS.
3127 NOTE 3 Corrective maintenance includes the measures taken after the occurrence of specific fault(s) that bring the
3128 SCS back into the as-designed state
ENTWURF OVE
– 88 – IEC CDV 62061  IEC 2019
3129 Annex A
3130 (informative)
3131
3132 Determination of required safety integrity
3133 A.1 General
3134 This informative Annex provides methods of qualitative approach for risk estimation and SIL
3135 assignment that can be applied to SCSs for machines, for determining the required SIL of
3136 subclause 5.2.
3137 NOTE 1 Whenever a risk assessment has indicated a safe control measure is required, the matrix method in A.2
3138 can be used to determine the required SIL.
3139 Experience in successfully dealing with similar machines/hazards should be taken into
3140 account when estimating the required SIL.
3141 NOTE 2 Other risk estimation methods for specific types of machine can be used as appropriate (e.g. methods are
3142 available in IEC61508-5:2010 and IEC61511-3:2016). Therefore, the SIL required by a type-C standard can deviate
3143 from that indicated by the generic approaches given in this annex.
3144 Other SIL assignment methods are available in IEC61508-5:2010 and IEC61511-3:2016.
3145 A.2 Matrix assignment for the required SIL

3146 A.2.1 Hazard identification/indication
3147 Indicate the hazards, including those from reasonable foreseeable misuse, whose risks are to
3148 be reduced by implementing an SCS. List them in the hazard column in Table A.5.
3149 A.2.2 Risk estimation

3150 Risk estimation should be carried out for each hazard by determining the risk parameters that
3151 as shown in Figure A.1 should be derived from the following:
3152 – severity of harm, Se; and

3153 – probability of occurrence of that harm, which is a function of:
3154 • frequency and duration of the exposure of persons to the hazard, Fr;
3155 • probability of occurrence of a hazardous event, Pr; and

3156 • possibilities to avoid or limit the harm, Av.
3157
A.2.3 A.2.4.1
Frequency and duration
A.2.4
of exposure Fr
Required Severity of
SIL the possible Probability of occurrence
A.2.4.2 Probability of
: and occurrence
(risk related to harm of a hazardous event Pr
the identified
Se of that harm
hazard)
A.2.4.3
Probability of avoiding
or limiting harm Av
3158
3159 Figure A.1 - Parameters used in risk estimation

3160 The estimates entered into Table A.5 should normally be based on worst-case considerations
3161 and need to be justified. However, in a situation where, for example, an irreversible injury is
3162 possible but at a significantly lower probability than a reversible one, then each severity level
3163 should have a separate line on the table. It can be the case that a different SCS is
3164 implemented for each line. If one SCS is implemented to cover both lines, then the highest
3165 target SIL or PL requirement should be used.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 89 –
3166 Depending on the individual application, available information such as service experience and
3167 incident statistics might be taken into account to select the ranking of the parameters.
3168 A.2.3 Severity (Se)

3169 Severity of injuries or damage to health can be estimated by taking into account reversible
3170 injuries, irreversible injuries and death. Choose the appropriate value of severity from
3171 Table A.1 based on the consequences of an injury, where:
3172 4 fatal or a significant irreversible injury such that it will be impossible or at least very
3173 difficult to continue the same work after healing, e.g. loss of limbs, pulmonary permanent
3174 damages, loss of an eye or partial or total loss of the sight;
3175 3 major or irreversible injury in such a way that it can be possible to continue the same
3176 work after healing such as loss of some fingers or toes. It can also include a severe major
3177 but reversible injury such as broken limbs;
3178 2 more severe reversible injury which requires attention from a medical practitioner and it is
3179 possible to resume the work activity after a short period of time, e.g. severe lacerations,
3180 stabbing, and severe bruises;
3181 1 slight injury where first aid cares without medical intervention are sufficient, e.g. minor
3182 injury including scratches and minor bruises.
3183 NOTE For examples of severity aspects, see also appendix 5 of the EU Guidelines 2010/15/EU (RAPEX).
3184 Select the appropriate row for consequences (Se) of Table A.1. Insert the appropriate number
3185 under the Se column in Table A.5.
3186 Table A.1 – Severity (Se) classification
Consequences Severity (Se)

Irreversible: death, losing an eye or arm 4
Irreversible: broken limb(s), losing a finger(s) 3
Reversible: requiring attention from a medical practitioner 2
Reversible: requiring first aid 1
3187 A.2.4 Probability of occurrence of harm

3188 Each of the three parameters of probability of occurrence of harm (i.e. Fr, Pr and Av) should
3189 be estimated independently of each other. A worst-case assumption needs to be used for
3190 each parameter to ensure that SCS(s) are not incorrectly assigned a lower PL/SIL than is
3191 necessary. Generally, the use of a form of task-based analysis is strongly recommended to
3192 ensure that proper consideration is given to estimation of the probability of occurrence of
3193 harm.
3194 A.2.4.1 Frequency and duration of exposure

3195 On determination of the exposure level of people to a hazard, according to 5.5.2.3.1 of ISO
3196 12100:2010, the work situation should be assessed considering factors such as:
3197 – the mode of operation during the access (setting/automatic/manual/special mode);

3198 – nature of access (feeding of materials, correction of malfunction, maintenance or repair)
3199 – time spent in the hazardous area
3200 – frequency of access to the hazardous area
3201 The parameter Fr is defined by frequency of presence of the people in the hazardous area
3202 and by the average duration of presence.
3203 It should then be possible to estimate the interval between accesses to a hazardous area and
3204 therefore the frequency of the exposure to a potential hazard (referred to a period > to one
3205 year). This factor does not include consideration of the failure of the SCS.
ENTWURF OVE
– 90 – IEC CDV 62061  IEC 2019
3206 Select the appropriate row for frequency and duration of exposure (Fr) of Table A.2. Insert the
3207 appropriate number under the Fr column in Table A.5.
3208 Table A.2 – Frequency and duration of exposure (Fr) classification
Frequency and duration of exposure (Fr)
Frequency of exposure Frequency, Fr
Duration of Duration of
exposure ≥ 10 min exposure < 10 min
≥ 1 per h 5 5
< 1 per h to ≥ 1 per day 5 4

< 1 per day to ≥ 1 per 2 weeks 4 3
< 1 per 2 weeks to ≥ 1 per year 3 2
< 1 per year 2 1
3209 A.2.4.2 Probability of occurrence of a hazardous event

3210 The probability of occurrence of harm should be estimated independently of other related
3211 parameters Fr and Av. A worst-case assumption should be used for each parameter to ensure
3212 that SCS(s) are not incorrectly assigned a lower SIL than is necessary. To prevent this
3213 occurring the use of a form of task-based analysis is strongly recommended to ensure that
3214 proper consideration is given to estimation of the probability of occurrence of harm.
3215 This parameter can be estimated by taking into account:
3216 a) Predictability of the behaviour of component parts of the machine relevant to the hazard in
3217 different modes of use (e.g. normal operation, maintenance, fault finding).
3218 – This will necessitate careful consideration of the control system especially with regard
3219 to the risk of unexpected start up. Do not take into account the protective effect of any
3220 SCS. This is necessary in order to estimate the amount of risk that will be exposed if
3221 the SCS fails. In general terms, it must be considered whether the machine or material
3222 being processed has the propensity to act in an unexpected manner.
3223 – The machine behaviour will vary from very predictable to not predictable but
3224 unexpected events cannot be discounted.
3225 NOTE 1 Predictability is often linked to the complexity of the machine function.
3226 b) The specified or foreseeable characteristics of human behaviour with regard to interaction
3227 with the component parts of the machine as an origin of to the hazard. This can be
3228 characterised by:
3229 – stress (e.g. due to time constraints, work task, perceived damage limitation); and/or
3230 – lack of awareness of information relevant to the hazard. This will be influenced by
3231 factors such as skills, training, experience, and complexity of machine/process.
3232 These attributes are not usually directly under the influence of the SCS designer, but a
3233 task analysis will reveal activities where total awareness of all issues, including
3234 unexpected outcomes, cannot be reasonably assumed.
3235 “Very high” probability of occurrence of a hazardous event should be selected to reflect
3236 normal production constraints and worst case considerations. Positive reasons (e.g. well-
3237 defined application and knowledge of high level of user competences) are required for any
3238 lower values to be used.
3239 Any required or assumed skills, knowledge, etc. should be stated in the information for
3240 use.
3241 Select the appropriate row for probability of occurrence of hazardous event (Pr) of Table A.3.
3242 Indicate the appropriate number under the Pr column in Table A.3.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 91 –
3243 Table A.3 – Probability (Pr) classification
Probability of occurrence Probability (Pr)

Very high 5
Likely 4
Possible 3
Rarely 2
Negligible 1
3244
3245 A.2.4.3 Probability of avoiding or limiting harm (Av)

3246 This parameter describes whether or not harm could be avoided or limited in case of a
3247 hazardous event. For example, the exposure to a hazard can be directly identified by its
3248 physical characteristics, or recognized only by technical means, e.g. indicators. The
3249 probability of avoiding or limiting harm (or the controllability) is predominantly determined by
3250 human intervention and depends to a large extent on individual human abilities. Avoidance
3251 must not be used as a substitute for basic hazard elimination. Avoiding or limiting harm
3252 considers, for example:
3253 – Characteristics of the hazardous event:

3254 • speed/acceleration: evolves quickly or slowly;
3255 • the nature of the component or system, for example a knife is usually sharp, a pipe in
3256 a dairy environment is usually hot, electricity is usually hazardous by its nature but is
3257 not visible;
3258 • possibility of recognition of a hazard, for example electrical hazard: a copper bar does
3259 not change its aspect whether it is under voltage or not; to recognize if one needs an
3260 instrument to establish whether electrical equipment is energised or not; ambient
3261 conditions, for example high noise levels can prevent a person hearing a machine
3262 start;
3263 • complexity of the operations (human interaction in terms of numbers of operation
3264 and/or timing available for this operations);
3265 – Spatial possibility to withdrawn from the hazard;

3266 – Human abilities:
3267 • skills of persons involved;
3268 • abilities to react (e.g. take action, escape etc.);
3269 • aspects that reduce the ability (e.g. stress, distraction, fatigue);
3270 NOTE: Human abilities cannot be accounted more than once for each safety function.
3271 Select the appropriate row for probability of avoidance or limiting harm (Av) of Table A.4.
3272 Insert the appropriate number under the Av column in Table A.4.
3273 Table A.4 – Probability of avoiding or limiting harm (Av) classification
Probabilities of avoiding or limiting harm (Av)

Impossible 5
Rarely 3
Probable 1
3274
3275 The classification should only be set as probable if the hazard is clearly recognizable and if
3276 there is sufficient time to take counteractions or to leave the hazardous area.
ENTWURF OVE
– 92 – IEC CDV 62061  IEC 2019
3277 A.2.5 Class of probability of harm (Cl)

3278 For each hazard, and as applicable, for each severity level add up the points from the Fr, Pr
3279 and Av columns and enter the sum into the column Cl (where Cl = Fr + Pr + Av ) in Table A.5.
3280 Table A.5 – Parameters used to determine class of probability of harm (Cl)
ID. Hazard Fr Pr Av Cl
1
2
3
4
3281
3282 A.2.6 SIL assignment

3283 Using Table A.6, where the severity (Se) row crosses the relevant column (Cl), the
3284 intersection point indicates whether action is required. The black area indicates the SIL
3285 assigned as the target for the SCS. The lighter shaded areas should be used as a
3286 recommendation that other measures (OM) be used.
3287 Where function(s) have safety implications but application leads to a required safety integrity
3288 less than that required by SIL 1 (OM or No SIL), compliance with the requirements of IEC
3289 60204-1 or other relevant standards can lead to an adequate performance of the control
3290 system.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 93 –
3291 Table A.6 – Matrix assignment for determining the required SIL (or PL r ) for a safety
3292 function
Severity Class Cl = Fr + Pr + Av
Consequences
Se 3 4 5 6 7 8 9 10 11 12 13 14 15
Death, losing an SIL 1 SIL 2 SIL 2 SIL 3 SIL 3
4
eye or arm PL r b PL r c PL r d PL r d PL r e PL r e
Permanent injury, OM SIL 1 SIL 2 SIL 3
3
losing fingers PL r a PL r b PL r c PL r d PL r e
OM SIL 1 SIL 2
Reversible injury,
2
medical attention PL r a PL r b PL r c PL r d
No SIL (or PL) required
Reversible injury, OM SIL 1
1
first aid OM: Other Measures (e.g. basic safety principles) PL r a PL r b PL r c
EXAMPLE: For a specific hazard with an Se assigned as 3, an Fr as 4, an Pr as 5 and an Av as 5 then:
Cl = Fr + Pr + Av = 4 + 5 + 5 = 14
Using this table, this would lead to a SIL 3 or PL e being assigned to the safety function that is intended to mitigate against the
specific hazard.
NOTE 1 SIL 2 at Class 3 and 4 in the previous published edition is now reduced to SIL 1 because of the low score for the classes of
Frequency, Probability and Avoiding Harm.
NOTE 2 SIL 2 at Class 5, 6 and 7 is not calibrated in line with the rest of the table because it is the intention to take account of the
moderate score for the classes of Frequency, Probability and Avoiding Harm in combination with the possibility of death as a
consequence.
NOTE 3 Due to characteristics of risks present at machinery SIL 4 is not considered in this standard. For SIL 4 see IEC 61508-1.
NOTE 4 This correspondence between SIL and PLr is valid only for the required level and not for the achieved level.
3293 Figure A.2 shows an example of documentation.

3294
3295 Figure A.2 – Example proforma for SIL assignment process

ENTWURF OVE
– 94 – IEC CDV 62061  IEC 2019
3296 A.3 Overlapping hazards

3297 If several hazards can be caused in a single zone by the failure of a single safety-related
3298 function, these are called overlapping hazards.
3299 All hazards are considered as a specific hazard or hazardous situation. For the quantification
3300 of risk, each hazard can therefore be evaluated separately.
3301 When it is obvious that there is a combination of directly linked hazards which always occur
3302 simultaneously then they should be combined during risk estimation.
3303 The determination of whether hazards should be considered separately or in combination

3304 should be considered during the risk assessment of the machine.
3305 EXAMPLE 1. A continuous welding robot can create various simultaneous hazardous
3306 situations, for example crushing caused by movement and burning due to the welding
3307 process. This can be considered as a combination of directly linked hazards.
3308 EXAMPLE 2. For a robot cell in which separate robots are working, each robot is considered
3309 separately.
3310 EXAMPLE 3. As a result of a risk assessment it can be sufficient to consider at rotary table
3311 with clamping devices each clamping device separately.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 95 –
3312 Annex B
3313 (informative)
3314
3315 Example of SCS design methodology
3316 B.1 General
3317 Examples of typical safety functions are cited in Table I.1. In the following example “safety-
3318 related stopping initiated by a guard” the basic methodology of Clause 6 and Clause 7 will be
3319 shown.
3320 In the example it is assumed that the safety function is operated in high demand mode of
3321 operation.
3322 B.2 Safety requirements specification

3323 The relevant information can be exemplarily summarized as shown in Table B.1.
3324 Table B.1 – Safety requirements specification – example of overview
Functional requirements specification of the safety function

Description: When the guard door will be opened then the electrical motor shall stop
Condition(s): Operating mode “all”
Restart/Reset Manual human action required where the operator can stay in the hazard zone
(according to ISO 12100, 6.2.11.3)
Priority: High priority in comparison to other safety functions; emergency stop function will have
the highest priority
Frequency of operation: 10 time per hour; 16 hours per day; 250 days per year
Response time: Maximum 500 ms from initiation event (opening of the guard door) to de-energizing
electrically the motor (stop category 0 acc. to IEC 60204-1)
Interface(s) to other Realized by a pre-designed safety-related device (information for use of the component
machine functions: manufacturer to be referenced)
Fault reaction function: Stopping immediately or detection at restart at least by prohibiting restart
Defeating: Design of guard door and mounting of guard interlocking devices acc. to ISO 14119
Environment Temperature, dust, vibration, …

Safety integrity requirements specification of the safety function
Required SIL or PL SIL 2 with related target PFH value (see Table 1)
Architectural constraints – Use of mechanical guard interlocking devices (position switches) due to vibration
– No type C standard requirements (e.g. required HFT)
3325 B.3 Decomposition of the safety function

3326 The safety function can be decomposed logically into sub-functions which can be allocated
3327 physically to subsystems, see Figure B.1.
sub-function 1 sub-function 2 sub-function 3

opening of guard door evaluation logic for motor
the guard monitoring sub-function 1 and 3 motor control switching
off
allocation
subsystem 1 subsystem 2 subsystem 3
position switch(es) safety controller contactor(s)

3328
– 96 –
ENTWURF OVE
Figure B.1 – Decomposition of the safety function

IEC CDV 62061  IEC 2019
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 97 –
3329 B.4 Design of the SCS by using subsystems

3330 B.4.1 General
3331 Figure B.2 shows a technical solution for the subsystems design. For subsystem 2 the
3332 relevant safety-related data are available and are assumed as shown in Figure B.2.
Subsystem 1 Subsystem 2 Subsystem 3

two position switches safety controller two contactors
Pre- designed device (L)
1. Design (I1/I2) based on (information available): 1. Design (Q1/Q2) based on
architectural constraints SIL 3 or PL d architectural constraints
2. Evaluation of PFH PFH < 10 -8 2. Evaluation of PFH

3333
3334
3335 Figure B.2 – Overview of design of the subsystems of the SCS
3336 B.4.2 Subsystem 1 design – “guard door monitoring”

3337 B.4.2.1 Architectural constraints
3338 This subsystem is to be designed and evaluated as described in Clause 7. Regarding a

3339 required SIL 2 an architecture with a hardware fault tolerance equal to 1 (HFT = 1) has been
3340 chosen, see Table 4.
3341 B.4.2.2 Evaluation of SFF

3342 The Safe Failure Fraction (SFF) can be calculated using the following equation:
∑ 𝜆DD + 𝜆S
𝑆𝑆𝑆 =
∑ 𝜆D + 𝜆S
3343 where
3344 𝜆S is the safe failure rate,

3345 𝜆D is the dangerous failure rate
3346 𝜆DD is the dangerous failure rate which is detected by the diagnostic function,
3347 ∑(𝜆D + 𝜆S ) = 𝜆 is the overall failure rate.
3348 Depending from the safety function, a failure can be safe (𝜆𝑆 ) or dangerous (𝜆𝐷 ).
3349 Identification of failure modes:
3350 A fault of an electromechanical component generally represents a situation (state) that can
3351 lead to a failure. Assuming that the safe state is an open circuit:
3352 – the contact remains open: safe state;

3353 – the contact remains closed: dangerous state.
3354 The theoretical failure effects of the position switch are:
ENTWURF OVE
– 98 – IEC CDV 62061  IEC 2019
3355 – the contact will not (anymore) open: dangerous failure (unintended closed);
3356 – the contact will open "by itself": safe failure (unintended opened, can be considered as
3357 very unlikely for an electromechanical device);
3358 – the contact will not (anymore) close: safe failure which do not have any influence of the
3359 safety function (unintended opened)
3360 – the contact will close "by itself": dangerous failure (unintended closed)
3361 NOTE See also failure modes IEC 60947-4-1.
3362 Practical considerations:
3363 The opening of the guard door defines the failure modes to be considered of the position
3364 switch. That means that practically no safe failures of the position switch related to this safety
3365 function exist:
3366 – the failure mode “unintended closed” contact always is dangerous (typical dangerous
3367 failure of the position switch)
3368 – the failure mode “unintended opened“ contact is not relevant for the opening of the guard
3369 door and only has an influence on the availability of the machine. It is a no effect failure
3370 (IEC61508-4, 3.6.14) for the defined function. Therefore it is not a safe failure and λ S = 0.
3371 Evaluation of SFF:
3372 The safe failure fraction in this example is given by following equation:
∑ 𝜆DDI1 + 𝜆SI2 𝜆DDI1 𝜆DDI2

𝑆𝑆𝑆 = = = = 𝐷𝐷I1 = 𝐷𝐷I2
∑ 𝜆DI1 + 𝜆SI2 𝜆DI1 𝜆DI2
3373 where
3374 – the fundamental definition of 𝜆DD = 𝐷𝐷 𝜆D is used;

3375 – I1 and I2 have the same failure rates;
3376 – 𝐷𝐷I1 of I1 and 𝐷𝐷I2 of I2 are equal due to cross-checking;
3377 B.4.2.3 Evaluation of DC I1 and DC I2
DC of 99 % can be assumed based on Table E.1:
3378
3379 – “Cross monitoring of input signals and intermediate results within the logic (L) and
3380 temporal and logical software monitor of the program flow and detection of static faults
3381 and short circuits (for multiple I/O)”.
3382 According to Table 4 the subsystem can claim maximum SIL 3.
3383 B.4.2.4 Evaluation of PFH

3384 B.4.2.4.1 Failure rates of position switches (I1/I2)
3385 The failure rate will be determined by using B 10D (or B 10 and RDF) as follows (see 7.3.4.2):
𝑠
𝑑op × ℎop × 3600 250 𝑑 × 16 ℎ�𝑑 × 3600
3386 – 𝑛op = = ℎ
= 40 000 𝑐𝑐𝑐𝑐𝑐𝑐 𝑝𝑝𝑝 𝑦𝑦𝑦𝑦;
𝑡cycle 360 𝑠
𝐵10D 2.000.000
3387 – 𝑀𝑀𝑀𝑀D = 0,1 × 𝑛op
=
0,1 × 40.000
= 500 𝑦𝑦𝑦𝑦𝑦;
1
3388 – 𝜆D =
𝑀𝑀𝑀𝑀D × 8760 ℎ�𝑎
= 2,28 10−7 𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 𝑝𝑝𝑝 ℎ𝑜𝑜𝑜.
3389 NOTE In this example B10 D of Table C.1 (position switches with separate actuator) is used. In practice the safety-
3390 related data provided by the component manufacturer will be used.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 99 –
3391 B.4.2.4.2 Annex K approaches

-7
3392 – Table allocation approach (see Table K.1): PFH = 0,10 x 10 . This approach is simple but
3393 gives a conservative approach.
-9
3394 – Formulas (see K.2.5): PFH = 4,65 10 (with β= 2 %, T 1 = 175.200 h, T 2 = 1/C = n op /8760 h).
3395 This approach is more complex but gives a more accurate result.
3396 B.4.3 Subsystem 2 design – “evaluation logic”
3397 According to the data provided by the component manufacturer of the pre-designed safety
-8
3398 controller, subsystem 2 can claim SIL 3 with a PFH < 10 .
3399 NOTE The instruction for use of the component manufacturer will provide all safety-related information.
3400 B.4.4 Subsystem 3 design – “motor control”
3402 This subsystem is to be designed and evaluated as described in Clause 7. Regarding a
3403 required SIL 2 an architecture with a hardware fault tolerance equal to 1 (HFT = 1) has been
3404 chosen, see Table 4.
3405 B.4.4.1.1 Evaluation of SFF

3406 The same approach as described in B.4.2.2 is valid: SFF = DC Q1 = DC Q2 .
3407 B.4.4.1.2 Evaluation of DC Q1 and DC Q2

3408 The diagnostic function will disable a reset when the mirror contacts (Q1.1 and Q2.1,
3409 Figure B.2) are not closed.
3410 DC of 99 % can be assumed based on Table E.1:
3411 – “Redundant shut-off path with monitoring of the actuators by logic and test equipment”.
3412 According to Table 4 the subsystem can claim maximum SIL 3.
3413 B.4.4.2 Evaluation of PFH

3414 B.4.4.2.1 Failure rates of contactors (Q1/Q2)
3415 The failure rate will be determined by using B 10D (or B 10 and RDF) as follows (see 7.3.4.2):
𝑠
𝑑op × ℎop × 3600 250 𝑑 × 16 ℎ�𝑑 × 3600
3416 – 𝑛op = = ℎ
= 40 000 𝑐𝑐𝑐𝑐𝑐𝑐 𝑝𝑝𝑝 𝑦𝑦𝑦𝑦 ;
𝑡cycle 360 𝑠
𝐵10D 1.300.000
3417 – 𝑀𝑀𝑀𝑀D = 0,1 × 𝑛op
=
0,1 × 40.000
= 325 𝑦𝑦𝑦𝑦𝑦;
1
3418 – 𝜆D =
𝑀𝑀𝑀𝑀D × 8760 ℎ�𝑎
= 3,51 10−7 𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 𝑝𝑝𝑝 ℎ𝑜𝑜𝑜.
3419 NOTE In this example B10 D of Table C.1 (contactors with nominal load) is used. In practice the safety-related data
3420 provided by the component manufacturer will be used.
3421 B.4.4.2.2 Annex K approaches
-7
3422 – Table allocation approach (see Table K.1): PFH = 0,10 x 10 . This approach is simple but
3423 gives a conservative result.
-9
3424 – Formulas (see K.2.5): PFH = 7,23 x 10 (with β= 2 %, T 1 = 175.200 h, T 2 = 1/C = n op /8760
3425 h). This approach is more complex but gives a more accurate result.
3426 B.4.5 Evaluation of the SCS
3427 The SCS can reach SIL 3 (see 6.3.2).
3428 B.4.5.1 Systematic integrity and CCF

3429 The relevant requirements for each subsystem design are given in 7.3.2. Table B.2 gives an
3430 overview. The evaluation of the common cause failures (see Annex F) is based on the
3431 measures of the systematic integrity and on the architecture of the SCS.

3433 All subsystems are claiming SIL 3. This SCS reaches SIL 3 (see 6.3.2).
ENTWURF OVE
– 100 – IEC CDV 62061  IEC 2019
3434 Table B.2 – Systematic integrity – example of overview
Avoidance of systematic failures

Measure Comment/Examples
Proper selection, combination, The right component for the application and used in the correct way
arrangements, assembly (instruction for use of the component manufacturer):
Position switches useable for this application?
Wiring, interconnections See instruction for use of the component manufacturer; measures
against short-circuit failures
Correct dimensioning and shaping Electrical overdimension: Load of contactors correct?
Hardware design review Analysis of plausibility and considering the instruction for use of the
component manufacturer
Control of systematic failures
Measure Comment/Examples
Voltage variations and interruptions Hardware design acc. to IEC 60204-1
Effects of the physical environment and Hardware design acc. to IEC 60204-1; see instruction for use of the
EM immunity component manufacturer
Effects of temperature increase or See instruction for use of the component manufacturer; if necessary
decrease including relevant hints into the information for use of the safety function
Use of de-energization Switching off of the motor by actuating the position switches
Well-tried safety principles
- Failure detection by automatic tests Monitoring of two position switches and two contactors; short-circuit
detection
- Operation in the positive mode Positively driven contacts of the position switches
- Mechanically linked contacts Contactors with mirror contacts
3435 B.4.5.3 Probability of dangerous random hardware failure

-7
3436 The overall PFH by summation of the PFH of the three subsystems will be < 10 .
3437 This SCS reaches SIL 3 (see 6.3.2.1).
3438 B.5 Verification

3439 The overall validation process requires at each design and evaluation state different
3440 verification activities (see validation principles represented in Figure 14).
3441 B.5.1 Analysis
3442 Check of plausibility of the safety requirements specification (see B.2), the decomposition of
3443 the safety function (see B.3) and the design and evaluation of the SCS (see B.4).
3444 B.5.2 Tests
3445 The following tests of Table B.3 should be performed.
3446 Table B.3 – Verification by tests
Tests Examples of test criteria

Testing by functional tests of the SCS - Opening of the guard door and verifying of the stop of the motor
- Closing of the guard door and verifying that no restart occurs
Tests by using fault injection
 Subsystem “guard door monitoring”: Verification of detection of discrepancy between the position switch
input signals (e.g. by dismounting of one of the positions switches
and short-circuit test)
 Subsystem “evaluation logic”: Test of reset when the guard door is opened and test when a failure
is present (during the test by using fault injection)
 Subsystem “motor control”: Verification of monitoring of the mirror contacts of the contactors
(e.g. by electrical disconnection of the feedback signal of the
contactors)
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 101 –
3447 Annex C
3448 (informative)
3449
3450 Examples of MTTFD values for single components
3451 C.1 General
3452 This Annex describes different methods to calculate or evaluate MTTF D values for single
3453 components. C.2 describes a method based on the respect of good engineering practices for
3454 different kinds of components, C.3 describes a method for hydraulic components, C.4
3455 describes the calculation of MTTF D for components from B 10 .
3456 C.2 Good engineering practices method

3457 If all following requirements are fulfilled, the MTTF D or B 10D value for a component can be
3458 estimated according to Table C.1:
3459 a) The manufacturer of the component confirms the use of basic and well-tried safety
3460 principles according to ISO 13849-2, or the relevant standard (see Table C.1) for the
3461 design of the component (confirmation in the data sheet of the component).
3462 b) The manufacturer of the component specifies the appropriate application and operating
3463 conditions for the subsystem designer.
3464 c) The design of the subsystem fulfils the basic and well-tried safety principles according to
3465 ISO 13849-2, for the implementation and operation of the component.
3466 C.3 Hydraulic components

3467 If all following requirements are fulfilled, the MTTF D value for a single hydraulic component,
3468 e.g. valve, can be estimated as 150 years:
3469 a) The manufacturer of the hydraulic component specifies the appropriate application and
3470 operating conditions for the subsystem designer and
3471 b) The manufacturer of the hydraulic component specifies the appropriate application and
3472 operating conditions for the user. The user has to be informed about his responsibility to
3473 fulfill the basic and well-tried safety principles according to ISO 13849-2 for the
3474 implementation and operation of the hydraulic component.
3475 If the criteria presented in C.4 are met, the MTTF D value for a single hydraulic component,
3476 e.g. valve, can be estimated at 150 years. If the mean number of annual operations (n op ) is
3477 below 1 000 000, then the MTTF D value can be estimated higher as shown in Table C.1.
3478 But if either a) or b) is not achieved, the MTTF D value for the single hydraulic component has
3479 to be given by the manufacturer. Instead of using a fixed value for the MTTF D as described
3480 above it is permissible to use the B 10D concept for MTTF D of pneumatic, mechanical and
3481 electromechanical components also for hydraulic components if the manufacturer can provide
3482 data.
3483 C.4 MTTF D of pneumatic, mechanical and electromechanical components

3484 For pneumatic, mechanical and electromechanical components (pneumatic valves, relays,
3485 contactors, position switches, cams of position switches, etc.) it can be difficult to calculate
3486 the mean time to dangerous failure (MTTF D for components), which is given in years and
3487 which is required by this standard. Most of the time the manufacturers of these kinds of
3488 components only give the mean number of cycles until 10 % of the components fail
3489 dangerously (B 10D ). This clause gives a method for calculating an MTTF D for components by
3490 using B 10 or T (lifetime) given by the manufacturer related closely to the application
3491 dependent cycles.
3492 For relationship see 7.3.4.2

ENTWURF OVE
– 102 – IEC CDV 62061  IEC 2019
3493 Table C.1 – Standards references and MTTF D or B 10D values for components
Basic and well-tried safety Other relevant standards Typical MTTF D (y) or B 10D
principles (ISO 13849-2) (cycle) values
Mechanical components Tables A.1 and A.2 MTTF D = 150

Hydraulic components Tables C.1 and C.2 ISO 4413 MTTF D = 150
with n op ≥ 1 000 000
1 000 000 > n op ≥ 500 000
500 000 > n op ≥ 250 000
Hydraulic components Tables C.1 and C.2 MTTF D = 1 200
250 000 > n op
Pneumatic components Tables B.1 and B.2 ISO 4414 B 10D = 20 000 000
Relays and contactor relays Tables D.1 and D.2 EN 50205, IEC 61810, B 10D = 20 000 000
with small load (mechanical IEC 60947
load)
Relays and contactor relays Tables D.1 and D.2 EN 50205, IEC 61810, B 10D = 400 000
with maximum load IEC 60947
Proximity switches with small Tables D.1 and D.2 IEC 60947, ISO 14119 B 10D = 20 000 000
load (mechanical load)
Proximity switches with Tables D.1 and D.2 IEC 60947, ISO 14119 B 10D = 400 000
nominal load
Contactors with small load Tables D.1 and D.2 IEC 60947 B 10D = 20 000 000
(mechanical load)
Contactors with nominal load Tables D.1 and D.2 IEC 60947 B 10D = 1 300 000
(see Note 1)
a Tables D.1 and D.2 IEC 60947, ISO 14119 B 10D = 20 000 000
Position switches
Position switches (with Tables D.1 and D.2 IEC 60947, ISO 14119 B 10D = 2 000 000
separate actuator, guard-
a
locking)
a Tables D.1 and D.2 IEC 60947, ISO 13850 B 10D = 100 000
Emergency stop devices
Push buttons (e.g. Enabling Tables D.1 and D.2 IEC 60947 B 10D = 100 000
switches)
For the definition and use of B 10D see 7.3.4.2.
NOTE 1 B 10D is estimated as two times B 10 (50 % dangerous failure) if no other information (e.g. product standard or results
of analysis) is available.
NOTE 2 Small load means e.g. 20 % of the rated value; for more information see ISO 13849-2.
NOTE 3 Emergency stop devices according to IEC 60947-5-5 and ISO 13850 and enabling switches according to
IEC 60947-5-8 can be estimated as a HFT = 0 or HTF = 1 subsystem depending on the number of electrical output contacts
and on the fault detection in the subsequent SCS. Each contact element (including the mechanical actuation) can be
considered as one channel with a respective B 10D value.
For enabling switches according to IEC 60947-5-8 this implies the opening function by pushing through or by releasing. In
some cases it can be possible, that the machine builder can apply fault exclusion according to Table A to D of ISO 13849-2,
considering the specific application and environmental conditions of the device.
a
If fault exclusion for direct opening action is possible.
3494
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 103 –
3495 Annex D
3496 (normative)
3497
3498 Low demand requirements
3499 D.1 General
3500 This annex specifies requirements for the design, construction and testing of a safety-related
3501 control system intended to be used in low demand mode within the scope of this standard.
3502 Where a particular clause or subclause of the clauses of main body of the standard is not
3503 mentioned in this annex, that clause or subclause applies. Where this annex states "addition",
3504 "modification", "replacement" or “not applicable”, the equivalent text of main body of the
3505 standard should be adapted accordingly (for example clause D.5.2.3 Replacement will apply
3506 in place of clause 5.2.3).
3507 D.2 Normative references

3508 Addition:
3509 IEC 61511-1:2016, Functional safety - Safety instrumented systems for the process industry
3510 sector - Part 1: Framework, definitions, system, hardware and application programming
3511 requirements
3512 D.3 Terms and definitions

3513 Clause 3 applies.
3514 D.4 Design process of an SCS and management of functional safety

3516 D.5 Specification of a safety function

3517 Clause 5 applies by replacing clause 5.2.3 with the following:
3518 D.5.2.3 Safety integrity requirements specification
3519 The safety integrity requirements for each safety function shall be derived from the risk
3520 assessment to ensure the necessary risk reduction can be achieved.
3521 In this standard, a safety integrity requirement is expressed as a target failure value for the
3522 average probability of dangerous failure on demand (PFD avg ) of each SCS.
3523 The required safety integrity for each safety function to be carried out by a SCS, shall be
3524 specified and documented in terms of SIL for a low demand mode of operation indicating the
3525 target failure measure as the average probability of dangerous failure on demand (PFD avg )
3526 according to Table D.1.
3527 Table D.1 – SIL and limits of PFD avg values in low demand mode of operation
Limits of PFDavg values in low

SIL
demand mode of operation
1 < 10-1
2 < 10–2
3 < 10–3
3528 The determination of the required performance is the result of the risk assessment and refers
3529 to the amount of the risk reduction to be carried out by the SCS. Examples of a methodology
3530 are given in Annex A.
3531 NOTE 1 Where a product standard specifies a required SIL for a safety function then this takes precedence over
3532 Annex A.
ENTWURF OVE
– 104 – IEC CDV 62061  IEC 2019
3533 NOTE 2 Examples of safety functions are given in Annex I.
3534 D.6 Design of an SCS

3536 D.6.3.4 Use of a pre-designed subsystem
3537 Replacement
3538 Any subsystem that is intended for low demand of operation and is in compliance with
3539 IEC 61508 to the relevant SIL can be integrated as a subsystem into a SCS designed in
3540 accordance with IEC 62061.
3541 NOTE It is not sufficient to derive PFD data from PFH data without consideration of all required aspects.
3542 D.6.4 Determination of safety integrity of the SCS
3543 Replacement:
3544 D.6.4.1 General
3545 The SIL(s) that can be achieved by the SCS shall be considered separately for each safety
3546 function and shall be determined from the SIL and the average probability of dangerous
3547 failures on demand (PFD avg ) of each subsystem, as follows:
3548 – the SIL that is achieved is equal to or less than the lowest SIL of any of the subsystems
3549 and
3550 – the SIL is limited by the sum PFD avg value of all subsystems according to Table D.1.
3551 Figure D.1 shows an example of an SCS with safety integrity of SIL 2 despite the overall
3552 PFD avg values being suitable for a higher SIL.
Subsystem 1 Subsystem 2 Subsystem 3

(detection, input) (evaluation, logic) (reaction, output)
SIL 2 SIL 3 SIL 2
-4 -4 -4
PFD avg = 1,5 x 10 PFD avg = 2 x 10 PFD avg = 4 x 10
Safety integrity of the SCS

lowest SIL of all subsystems: SIL 2
-4
Probability of dangerous hardware failure: ∑ PFD avg = 7,5 x 10
 SCS achieves SIL 2
NOTE The SCS has a safety integrity of limited to SIL 2 despite the overall PFD avg values being suitable for a higher SIL.
3553 Figure D.1 — Example of safety integrity of a safety function based on allocated
3554 subsystems as one SCS
3555 NOTE 1 An SCS can be a combination of subsystems based on different architectures.
3556 NOTE 2 For example in high demand applications the failure rate can be determined by wear and B 10D is used as a
3557 reliability parameter. In principle a failure rate can calculated from a B 10D value, taking the expected actuation
3558 frequency into account. If actuation frequency is very low in a given application compared to frequency that was
3559 assumed for the evaluation of B 10D the real failure behavior of the component is not more related to wear anymore.
3560 Instead aging becomes determining and a failure rate derived for B 10D would be too low. In such cases it is can be
3561 required to evaluate the reliability parameters with the manufacturer for the specific application.
3562
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 105 –
3563 Replacement:
3564 D.6.4.2 Hardware safety integrity
3565 The average probability of a dangerous failure on demand PFD avg of each safety function due
3566 to dangerous random hardware failures shall be equal to or lower than the PFD avg of
3567 Table D.1 related to required SIL as specified in the safety requirements specification.
3568 The estimation of the probability of dangerous failure shall be based on the probability of
3569 dangerous random hardware failure of each relevant subsystem as derived using the
3570 information required in 7.1 including, where appropriate, for digital data communication
3571 processes between subsystems. The probability of dangerous random hardware failure of the
3572 SCS is the sum of the probabilities of dangerous random hardware failure of all subsystems
3573 involved in the performance of the safety function and shall include, where appropriate, the
3574 rate of dangerous transmission errors for digital data communication processes (P TE ):
3575 𝑃𝑃𝑃avg = 𝑃𝑃𝑃avg 1 + ⋯ + 𝑃𝑃𝑃avg 𝑁 + 𝑃TE

3576 NOTE 1 This approach is based on the definition of a subsystem which states that a failure of any subsystem will
3577 result in a failure of the SCS (see 6.2.1).
3578 NOTE 2 Hardware wiring aspects are part of systematic integrity and possibly of diagnostic coverage, but do not
3579 have a PFD av g .
3580 NOTE 3 For the determination of the P TE for safety fieldbuses, when applicable, see for example IEC 61784-3.
3581
3582 Addition:
3583 D.6.9.2 Proof test
3584 If a safety function is specified as a safety function in low demand mode of operation a proof
3585 test procedure and interval shall be defined.
3586 In case of a function in low demand of operation with a hardware fault tolerance of zero the
3587 safety function depends largely on proof testing to ensure the safety integrity.
3588 The MRT (see also Annex D, D.3.2.42) can be neglected for SIL calculations only if the
3589 machine is shut down during repair or if other risk measures are put in place with equivalent
3590 effectiveness.
3591 The required frequency of proof tests for a safety function shall be determined through PFD avg
3592 calculation.
3593 For maintenance or testing design requirements clause 11.8 of IEC 61511-1:2016 shall be
3594 applied.
3595 D.7 Design and development of subsystem

3596 D.7.3.3.4 Fault accumulation
3597 Clause 7.3.3.4 is not applicable.
3599 Addition:
3600 For a subsystem implementing a safety function operating in low demand mode of operation
3601 the following may be used instead of Table 4;
3602 – requirements of 7.4.4.2 (route 1H) of IEC 61508-2:2010 or,

3603 – requirements of 7.4.4.3 (route 2H) of IEC 61508-2:2010.
3604 D.7.5 Subsystem design architectures
3605 Clause 7.5 is not applicable.

ENTWURF OVE
– 106 – IEC CDV 62061  IEC 2019
3606 Replacement:
3608 The following parameters have to be determined to be able to determine the PFD avg :
3609 – subsystem architecture (see IEC 61508-6)

3610 – DC, failure rate of diagnostics and diagnostic test intervals (see 7.4.3 and 7.4.4)
3611 – proof test interval and proof test coverage
3612 – CCF (see Annex F and Annex D of IEC 61508-6)
3613 – failure rates of subsystem elements (see 7.3.4)
3614 – useful lifetime
3615 – MTTR, MRT
3616 D.7.6.2 Methods to estimate the PFH of a subsystem
3617 Clause 7.6.2 is not applicable.
3618 D.7.6.3 Methods to estimate the PFD avg of a subsystem
3619 Replacement:
3620 The probabilistic calculations can be performed analytically or by numerical simulation (e.g.,
3621 Monte Carlo simulation) - see IEC 61508-6:2010, annex B for available methods.
3622 D.8 Software

3624 D.9 Validation

3626 D.10 Documentation

3627 D.10.3.3 Information for use given by the SCS integrator
3628 Addition:
3629 NOTE 4 The operating and maintenance procedures can include verification that bypasses are removed after proof
3630 testing.
3631 NOTE 5 The status of all bypasses is usually recorded in a bypass log.
3632 m) Operators skills and required training

3633 n) Troubleshooting information, such as:
3634 – the failures and failure modes of equipment forming part of the SCS, including those
3635 identified during normal operation, inspection, testing or demand on a Safety Function;
3636 – the cause and expected frequency of spurious trips;
3637 o) Information about assumption in the risk assessment, which can be confirmed or corrected
3638 by the end user, such as:
3639 – the demand rate on each safety function;
3640 – the cause of the demands;
3641 – the efficiency of compensating measures that are taken when the safety functions are
3642 by-passed.
3643 p) A clear statement that the user must put in place a system capable of ensuring that during
3644 the entire lifetime (operation, maintenance) of the installation the requirements given by
3645 the SCS integrator can be assured.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 107 –
3646 Annex E
3647 (informative)
3648
3649 Examples for diagnostic coverage (DC)
3650 Typical examples of DC values are given in Table E.1.
3651 For measures where a DC range is given (e.g. fault detection by the process) the correct DC
3652 value can be determined by considering all dangerous failures and then deciding which of
3653 them are detected by the DC measure. In case of any doubt a FMEA should be the basis for
3654 the estimation of the DC.
3655 NOTE 1 Additional estimations for DC see e.g. IEC 61508-2:2010, Tables A.2 to A.15.
3656 Table E.1 – Estimates for diagnostic coverage (DC)
Measure Diagnostic coverage (DC) Examples
Input device
Cyclic test stimulus by dynamic 90 % Automatically changing an output to check

change of the input signals whether the input connected with this output will
change state
Plausibility check, e.g. use of 99 % Compare automatically a normally closed contact
normally open and normally closed with a normally open contact off a single sensor
mechanically linked contacts
Cross monitoring of inputs without 0 % to 99 %, depending on Emergency stop dual channel without short circuit
dynamic test how often a signal change is detection  DC = 90 %
done by the application Emergency stop dual channel with short circuit
detection  DC = 99 %
Cross monitoring of input signals 90 % Comparing the signals of 2 position monitoring
with dynamic test if short circuits devices if the devices is automatically moved
are not detectable (for multiple I/O) between the two positions and thus the expected
position can be compared with effective position
(without short circuit detection)
Cross monitoring of input signals 99 % Electronic devices continuously checking its
and intermediate results within the functioning
logic (L) and temporal and logical
software monitor of the program

flow and detection of static faults
and short circuits (for multiple I/O)
Indirect monitoring (e.g. monitoring 90 % to 99 %, depending on Monitoring a cylinder is in its end position and
by pressure switch, electrical the application remains in this end position
position monitoring of actuators) Care should be taken the system can detect a
failure before a dangerous situation can exist
(e.g. if the cylinder leaves its position it should be
possible to place the system automatically in a
safe state)
Direct monitoring (e.g. electrical 99 % Monitoring the functioning of a contactor by a
position monitoring of control mechanically linked NC contact
valves, monitoring of electro-
mechanical devices by mechanically
linked contact elements)
Fault detection by the process 0 % to 99 %, depending on - Degradation of the outcome of the production
the application; this measure process indicates a probable future loss of the
alone is not sufficient for safety function
SIL 3 - A measured value (e.g. level) does not
correspond with the expected value
Monitoring some characteristics of 60 % Checking an analogue value remains within
the sensor (response time, range of predefined borders (e.g. 12 to17mA)
analogue signals, e.g. electrical
resistance, capacitance)
3657
ENTWURF OVE
– 108 – IEC CDV 62061  IEC 2019
3658 Table E.1 (continued) – Estimates for diagnostic coverage (DC)
Measure Diagnostic coverage (DC) Examples
Output device
Monitoring of outputs by one 0 % to 99 % depending on how Check if a contactor is switched off by measuring
channel without dynamic test often a signal change is done by the current (DC = 0 % if change is done less than
the application once a year and DC = 90 % if change is done
weekly)
Cross monitoring of outputs 0 % to 99 % depending on how
without dynamic test often a signal change is done by
the application
Cross monitoring of output 90 % Check if the two 3/2 exhaust valves have switched
signals with dynamic test without off by making use of a pressure switch and
detection of short circuits (for switching on the valves one by one to see if a
multiple I/O) difference in pressure occurs.
Cross monitoring of output 99 % Speed detection after activation of SLS which is
signals and intermediate results compared with the expected program values
within the logic (L) and temporal
and logical software monitor of
the program flow and detection
of static faults and short circuits
(for multiple I/O)
Redundant shut-off path with 99 % Monitoring both NC mechanically linked contacts
monitoring of the actuators by (placed in series or in parallel on the logic) of a
logic and test equipment redundant contactor arrangement
Indirect monitoring (e.g. 90 % to 99 %, depending on the Monitoring a cylinder is in its end position and
monitoring by pressure switch, application remains in this end position.
electrical position monitoring of Care should be taken the system can detect a
actuators) failure before a dangerous situation can exist (e.g.
if the cylinder leaves its position it should be
possible to place the system automatically in a
safe state)
Fault detection by the process 0 % to 99 %, depending on the - Degradation of the outcome of the production
application; this measure alone process indicates a probable future loss of the
is not sufficient for the required safety function
SIL 3! - A measured value (e.g. level) does not
correspond with the expected value
Direct monitoring (e.g. electrical 99 % Monitoring the functioning of a contactor by a

position monitoring of control mechanically linked NC contact
valves, monitoring of
electromechanical devices by
mechanically linked contact
elements)
3659 For the application of Table E.1 see the indicative example below.
3660 EXAMPLE The DC measure “fault detection by the process” is only be applied if the safety-related component is
3661 involved in the production process, e.g. a standard PLC or standard sensors are used for workpiece processing
3662 and as part of one of two redundant functional channels executing the safety function. The appropriate DC level
3663 depends on the overlap of the commonly used resources (logic, inputs/outputs etc.). E.g. when all faults of a rotary
3664 encoder on a printing machine lead to highly visible interruption of the printing process, the DC for this sensor used
3665 to monitor a safely limited speed is estimated as 90 % up to 99 %.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 109 –
3666 Annex F
3667 (informative)
3668
3669 Methodology for the estimation of susceptibility to common cause
3670 failures (CCF)
3671 F.1 General
3672 This informative Annex provides two simple qualitative approaches for the estimation of CCF
3673 that can be applied to the subsystem design.
3674 F.2 Methodology

3675 F.2.1 Requirements for CCF
3676 A comprehensive procedure for measures against CCF for sensors/actuators and separately
3677 for control logic is given, for example, in IEC 61508-6:2010, Annex D. Not all measures given
3678 therein are applicable to the machinery application. The most important measures are given
3679 here.
3680 NOTE It is assumed that for redundant systems a β-factor according to IEC 61508-6:2010, Annex D is less than or
3681 equal to 2 %.
3682 F.2.2 Estimation of effect of CCF
3683 This quantitative process should be passed for the whole system. Every part of the safety-
3684 related parts of the control system should be considered.
3685 Table F.1 lists the measures and contains associated values, based on engineering
3686 judgement, which represent the contribution each measure makes in the reduction of common
3687 cause failures. For each listed measure, only the full score or nothing can be claimed. If a
3688 measure is only partly fulfilled, the score according to this measure is zero.
3689 Table F.1 – Criteria for estimation of CCF
Item Reference Score

Separation/segregation
Are SCS signal cables for the individual channels routed separately from other 1a 5
channels at all positions? For example:
- Signal cables for the individual channels separate from other channels at all
positions or sufficiently shielded (connected to protective earth)
- Short circuit detection provided
- Sufficient clearances and creepage distances on printed-circuit boards
Where information encoding/decoding is used, is it sufficient for the detection of 1b 10
signal transmission errors?
Are SCS signals and power cables / sources separate at all positions or sufficiently 2 5
shielded (no interference from any other electrical system to the SCS signals, see
IEC 60204-1:2016, Annex H)?
If subsystem elements can contribute to a CCF, are they provided as physically 3 5
separate devices in their local enclosures?
Diversity/redundancy
Does the subsystem employ different technologies for example, one electronic or 4 8
programmable electronic and the other an electromechanical relay or a hydraulic
valve?
Does the subsystem employ elements that use different physical principles (e.g. 5 10
sensing elements at a guard door that use mechanical and magnetic sensing
techniques)?
Does the subsystem employ elements with temporal differences in functional 6 10
operation and/or failure modes?
Do the subsystem elements have a diagnostic test interval of ≤1 min? 7 10
Complexity/design/application
Is cross-connection between channels of the subsystem prevented with the exception 8 2
ENTWURF OVE
– 110 – IEC CDV 62061  IEC 2019

of that used for diagnostic testing purposes?
Assessment/analysis
Has an analysis been conducted to establish sources of common cause failure and 9 9
have predetermined sources of common cause failure been eliminated by design?
For example over voltage, over temperature, over pressure etc. (see 7.3.2.3)
3690 Table F.1 – Criteria for estimation of CCF (continued)

Are field failures analysed with feedback into the design? 10 9
Competence/training
Do subsystem designers understand the causes and consequences of common cause 11 4
failures?
Environmental control
Are the subsystem elements likely to operate always within the range of temperature, 12 9
humidity, corrosion, dust, vibration, etc. over which it has been tested, without the
use of external environmental control? (See IEC 60068 series)
Is the subsystem immune to adverse influences from electromagnetic interference 13 9
(See IEC 61326-3-1 or IEC 61000-6-7)
NOTE 1 An alternative item (e.g. references 1a and 1b) is given in Table F.1 where it is intended that a claim can
be made for a contribution towards avoidance of CCF from only the most relevant item.
NOTE 2 Similar criteria can be derived for other technologies based on the same principles.
3691
3692 Note: Similar criteria can be derived for other technologies based on the same principles
3693 Using Table F.1 those items that are considered to affect the subsystem design should be
3694 added to provide an overall score for the design that is to be implemented. Where it can be
3695 shown that equivalent means of avoiding of CCF can be achieved through the use of specific
3696 design measures (e.g. the use of opto-isolated devices rather than shielded cables) then the
3697 relevant score can be claimed as this can be considered to provide the same contribution to
3698 the avoidance of CCF.
3699 It is expected that the references 9, 11, 12 and 13 are always addressed unless it can be
3700 justified.
3701 This overall score can be used to determine a common cause failure factor (β) using
3702 Table F.2.
3703 Table F.2 – Criteria for estimation of CCF
Overall score Common cause failure factor (β)

≤ 35 10 % (0,1)
36 – 65 5 % (0,05)
66 – 85 2 % (0,02)
86 – 100 1 % (0,01)
3704
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 111 –
3705 Annex G
3706 (informative)
3707
3708 Guideline for Software level 1
3709 G.1 Software safety requirements
3710 Relevant input and output information are given in Table G.1.
3711 Based on one example some guidance related to some relevant documents will be shown.
3712 Table G.1 – Example of relevant documents related to the simplified V-model
Document Comments
Coding guidelines Generally reusable, see Table G.2

Specification of the safety functions Should already exist, see Table G.3 and
Figure G.2
Specification of the hardware design (see note 1)
 plant sketch(s) Should already exist, see Figure G.1
 control system design Should already exists
(not shown in this example)
 wiring diagram(s) Should already exist
 I/O-list Should already exists, see Table G.4
Software design specification (see note 2)
 Safety-related software specification and validation Table G1 or relevant documents clearly stating
plan the activities
 Architecture of safety-related program Unnecessary in case of a simple application
 Architecture of non-safety-related program Unnecessary in case of a simple application
 Module architecture of safety-related program Optional, see Figure G.3

 Program sketch (logical representation) Optional, see Figure G.4
Protocols
 Software Verification See Table G.6
 Code review See Table G.7
 Software validation See Table G.8
NOTE 1 Hardware printout generated by CAD tools can be used.
NOTE 2 Software printout generated by pre-designed software-platform can be used.
3713 All documents should be clearly identified to ensure the interrelationship between hardware
3714 and software design:
3715 – Date: YYYY-MM-DD (currently valid version/changes)

3716 – Name: (responsible person)
3717 – Software signature: (number or string, easy to track and trace, e.g. CRC value)
3718 – Hardware signature: (number or string, easy track and trace)
3719
ENTWURF OVE
– 112 – IEC CDV 62061  IEC 2019
3720 G.2 Coding guidelines

3721 Table G.2 shows a non-exhaustive template providing a typical list of coding guidelines for
3722 SW level 1 applications. For clarification it is populated with specific examples.
3723 Table G.2 – Examples of coding guidelines
A. Variables
Prefixes of boolean variables: "b".
Prefixes of binary inputs: "I_b" (non-safety-related input), "IS_b" (safety-related input).
Prefixes of binary outputs: "Q_b" (non-safety-related output) or "QS_b" (safety-related input).
Prefixes of instances: Timers: "T_", positive edge detections: "R_", Flip-Flops: “FF_”
Prefixes of instances: Instances of SF_GUARD: GUARD_<guard name>, SF_ESTOP: ESTOP_<number>,
SF_FDBACK: CONTACTORS_<contactors>
Prefixes of global variables: "G_" (non-safety-related), "GS_" (safety).
Prefixes of temporary variables: “#”
Variable names: The variable name after the prefix should be self-explanatory, e. g. should
contain the device name under consideration. For example..GD1.. for guard door 1.
Variable declaration: Initialize with the safest condition. Include a comment in each declaration.
B. Signal processing
Software architecture: Partition the software data flow in a pre-processing layer (inputs), a switch off logic
(logic) and a post-processing layer (outputs).
Realize the pre-processing layer in consecutive networks. The output of each network should somehow
contribute to the switch off logic.
For each binary output: Realize the corresponding switch off logic and the post-processing layer in one
network (if possible).
Assignment: Use outputs and variables in only one program statement.
Comments: Each network has a comment.
Cyclic processing: Run each part of the safety-related software unconditionally as part of each cycle.
Monitoring of two channel inputs: Monitor on two channel inputs (e. g. push buttons) by the input cards
with a discrepancy time of e.g. 100 ms.
Monitoring of contactors: Monitor of the mirror contacts of contactors with a feedback time of e.g. 1 s.
Monitoring of guard door: Monitor of the interlocking devices with a discrepancy time of e.g.100-500 ms.
Automatic restart: Is only allowed for guard doors where the operator cannot stay in the hazard zone.
Errors in peripheral devices: Manual reset is necessary.
Triggering of safety functions: Trigger by FALSE.
Concept of acknowledge of detected failures: Selectivity of “reset/acknowledge” depending on the
availability concept; human actions requirements
Reaction time (typical): Calculate or test and document the reaction time of the safety-related program.
C. Library function blocks / functions (FBs/FCs)
Usage: Wherever applicable use pre-designed library FBs/FCs.
Guard door: SF_GUARD.
Emergency stop device: SF_ESTOP.
Contactor: SF_FDBACK.
Enabling device: SF_EV2DI
Automatic Reset: Depending on the library functions (to be cited here)
Activation: Depending on the library functions (to be cited here)
Self-developed FBs/FCs: If applicable capsule logical signal combinations which have multiple assignments
within the project in a FB/FC . The life cycle complies with the V-model.
These FBs/FCs shall be password protected. A library management is necessary.
3724 G.3 Specification of safety functions

3725 This example refers to Clause 8, especially to 8.3.1, SW level 1 and is based on the simplified
3726 V-model of Figure 11.
3727 The plant sketch in Figure G.1 helps to understand the safety concept.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 113 –
3728
3729 Keys:
3730 ACK1, ACK2 acknowledge (related to guard doors and emergency stop devices)
3731 ES1, ES2 emergency stop devices (with two positively driven contacts)
3732 EN1, EN2 enabling devices for safely limited speed (with two positively driven contacts)
3733 GD1, GD2 guard doors (monitored by two position switches)
3734 M1, M2 motors controlled by frequency converters with safety-related sub-functions (STO and SLS)
3735 M3 motor of pump (switched off by two contactors)
3736 Figure G.1 – Plant sketch
3737 During risk assessment the following safety functions with a required SIL 2 or PL d are
3738 specified and summarized in Table G.3.
3739 Table G.3 – Specified safety functions
Safety function Functional description Operating

mode
Nr. Description IF (CAUSE) THEN (EFFECT) Reaction
time
(see note 3)
SF1 Emergency stop ES1 is pushed (#bES1_OK = 0) M1 shall stop (#bM1_STO = 0) < 1s all
SF2 functions (see ES2 is pushed (#bES2_OK = 0) M1, M2 and M3 shall stop (#bM1_STO = 0) < 1s all
note 1 and 2) (#bM2_STO = 0) (#bM3_ON = 0)
SF10 GD1 is opened (#bST1_OK = 0) M1 shall stop (#bM1_STO = 0) < 1s all

Monitoring of
SF11 guard doors GD2 is opened (#bST2_OK = 0) M1, M2 and M3 shall stop (#bM1_STO = 0) < 1s all
(#bM2_STO = 0) (#bM3_ON = 0)
SF20 Reduced speed GD1 is opened and EN1 is pushed reduced speed is allowed < 500ms reduced
control by using (#bEN1_OK = 1) (#bM1_STO = 1) and (#bM1_SLS = 0) speed
SF21 enabling devices GD2 is opened and EN2 is pushed reduced speed is allowed < 500ms reduced
EN1 or EN2 (#bEN2_OK = 1) (#bM2_STO = 1) and (#bM2_SLS = 0) speed
NOTE 1 An emergency stop function represents a complementary measure (acc. to ISO 12100). The evaluation can be made by using
the principles of the design of a safety function, see Table 2.
NOTE 2 Depending on the area of the hazard zone SF2 can be subdivided into several independent safety functions (see overlapping
hazards, A.4).
NOTE 3 The overall reaction that is accepted to stop dangerous movements. See also stop categories of IEC 60204-1.
ENTWURF OVE
– 114 – IEC CDV 62061  IEC 2019
3740 The normal operation mode related to plant sketch in Figure G.1 is as follows:
3741 – Pieces are transported by a feed in carrier to the machine and after the process these will
3742 be moved by a feed out carrier. These carriers are not considered in this example.
3743 – Milling centre (M2) is working automatically and treated pieces are transported by the
3744 carrier (M1) for cooling. The guard doors must be closed at this time.
3745 – Sometimes a worker opens the guard door GD2 and withdraws the foam piece and cleans
3746 the tool; after this the worker goes out and closes GD2 again. After acknowledging (ACK2)
3747 the process can be restarted.
3748 – Sometimes a worker needs to readjust the milling centre (M2) and is using therefore the
3749 enabling device EN2 to activate the reduced speed of M2. Only while the GD2 is opened
3750 this work is allowed.
3751 – Sometimes the carrier must be cleaned using a reduced speed. When the guard door GD1
3752 will be opened by the worker the carrier must stop. Only while the GD1 is opened, GD2 is
3753 closed and the enabling device EN1 is activated the carrier can be moved slowly for
3754 cleaning. After closing GD1 the process can be restarted by acknowledging (ACK1).
3755 G.4 Specification of hardware design

3756 The relevant components for the hardware design of the control system e.g. are:
3757 – Safety-related CPU;

3758 – Safety-related I/O card(s);
3759 – Non-safety-related Input card(s);
3760 – Fieldbus (allowing functional safety-related communication acc. to IEC 61784-3 series);
3761 – Safety-related converter (acc. to IEC 61800-5-2).
3762 Those components represent pre-designed subsystems provided by a component
3763 manufacturer(s).
3764 The converters provide the integrated safety-related sub-functions STO (Safe Torque Off) and
3765 SLS (Safely Limited Speed) acc. to IEC 61800-5-2.
3766 Table G.4 shows the relevant signals to perform the safety functions which should be
3767 controlled and tested depending on the hardware wiring and the software implementation.
3768 Table G.4 – Relevant list of input and output signals
List of input signals

HW SW
Description Variable Address wiring interconnection
(function, signal) (designation) (designation) correct correct
(y/n) (y/n)
GD1, contact 1 (NC) IS_bGD1_1 I8.0
GD1, contact 2 (NO) IS_bGD1_2 I9.4
GD2, contact 1 (NC) IS_bGD2_1 I8.1
GD2, contact 2 (NO) IS_bGD2_2 I9.5
ES1, two contacts (NC) IS_ES1 I8.4 (I10.0)
ES2, two contacts (NC) IS_ES2 I8.5 (I10.1)
M3, feedback contactors (NC) IS_bSTAT_M3 I8.6
EN1, enabling contact 1 (NO) IS_bEN1_1 I9.0 (I10.4)
ACK1, acknowledge contact (NO) I_bACK1 I4.0
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 115 –
ACK1, acknowledge contact (NO) I_bACK2 I5.0
List output signals
M1, STO QS_bM1_STO Q32.0
M1, SLS QS_b12_SLS Q32.4
M2, STO QS_bM2_STO Q48.0
M2, SLS QS_bM2_SLS Q48.4
M3, two contactors QS_bM3 Q24.0

Date:
Name:
Software signature:
Hardware signature:
3769 NOTE 1 NC means normally closed and NO normally open.
3770 NOTE 2 The controlling of the hardware and software design can be executed by different persons. Important is the
3771 confirmation by one person that those controlling activities were executed.
3772 G.5 Software system design specification

3773 Figure G.2 shows the software system design based on principal design of the module
3774 architecture.
ENTWURF OVE
– 116 – IEC CDV 62061  IEC 2019

3775
3776 Figure G.2 – Principal module architecture design
3777 The following pre-designed function blocks (library) are used:
3778 – SF_GUARD: Monitoring of a guard door by two interlocking devices (e.g. position switches
3779 with NC contacts) IS_bGDx_1 and IS_bGDx_2 (discrepancy time control realised by the
3780 function block); when the state of one of these two input signals is equal to 0 then
3781 #bGDx_OK is set to 0; #bGDx_OK will be set to 1 by closing the guard door and after this
3782 applying a rising edge at I_ACKx.
3783 – SF_ESTOP: Monitoring of two NC contacts of the emergency stop device IS_ES1 and
3784 IS_ES2 (discrepancy time control realised by the input card); when the state of one of
3785 these two input signals is equal to 0 then #bESx_OK is set to 0; #bESx_OK will be set to 1
3786 by unlatching the emergency stop device and after this applying a rising edge at I_ACKx.
3787 – SF_EV2DI: Monitoring of two NC contacts of the enabling device IS_bENx_1 and
3788 IS_bENx_2 (discrepancy time control realised by the function block); when the state of
3789 one of these two input signals is equal to 0 then #bENx_OK is set to 0; #bENx_OK will be
3790 set to 1 automatically by releasing the enabling device.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 117 –
3791 – SF_FDBACK: Monitoring of contactors by using the mirror contacts (as feedback); a
3792 feedback error is detected if the inverse signal state of the feedback input IS_STAT_M3
3793 does not follow the signal state of output QS_M3 within the maximum tolerable feedback
3794 time.
3795 NOTE The reset of any failures, e.g. discrepancy time or feedback error is not shown here.
3796
3797 Figure G.3 shows the principal design approach of the logic layer.
3798
3799 Figure G.3 – Principal design approach of logical evaluation
3800
3801 Figure G.4 represents logic evaluation of the safety functions described in Table G.3.
3802
ENTWURF OVE
– 118 – IEC CDV 62061  IEC 2019
3803
3804 Figure G.4 – Example of logical representation (program sketch)
3805 Alternatively a simplified cause and effect matrix can be used, showing all the safety functions
3806 with the corresponding input(s) which will initiate the safety functions (causes or initiation
3807 events) and switched output(s) (effects), see Table G.5. There are different types of
3808 representation of a cause and effect matrix. The more convenient can be used.
3809 Table G.5 – Example of simplified cause and effect matrix
Safety
functions Inputs M1_STO M1_SLS M2_STO M2_SLS M3_ON
SF1 ES1_OK &

SF2 ES2_OK & & &
SF10 GD1_OK &
SF11 GD2_OK & & &
SF20 GD1_OK or EN1_OK &
SF21 GD2_OK or EN2_OK &
Causes Effects
3810
3811 G.6 Protocols

3812 Table G.6 and Table G.7 show the protocol of verification of the software system design
3813 specification and protocol of software code review. It represents only an important summary
3814 of already executed verifications.
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 119 –
3815 Table G.6 – Verification of software system design specification
to be checked reference correct (y/n)

1. Does the module architecture comply with the specification of the safety Figure G.3
functions?
2. Does the software design specification comply with the specification of the Table G.3
safety functions? Figure G.4
Figure G.5
Date:
Name:
Software signature:
Hardware signature:
3816 Table G.7 – Software code review

1. Does the software comply with the coding guidelines? Table G.2
2. Does the control system design comply with the specification?
3. Is the interconnection of the I/O-signals in the software correct? Is the
parameterization of the relevant FBs correct?
4. Does the hierarchy of the plc-safety program comply with the
specification?
5. Does the architecture of safety-plc-program comply with the specification?
6. Does the plc-safety-program comply with the table specification?
7. Does the safety-related software specification comply with the
specification of the safety functions?
Date:
Name:
Software signature:
Hardware signature:
3817 The software validation Table G.8 is partially a summary of already executed tests. Additional
3818 manufacturer specific tests of e. g. the correct parameterization of external safety devices like
3819 laser scanners, converts, light curtains etc. are required. In the example under consideration
3820 the threshold of the safely limited speed of the converter (and other parameters) has to be
3821 checked. These manufacturer specific tests were not shown here. The required
3822 documentation listed in Table G.8 can be archived electronically. This documentation is
3823 important e. g. for an external certification of the machine.
3824 Table G.8 – Software validation

1. Was the I/O-test carried out with a positive result? Table G.4
2. Was the test of the safety functions and other test requirements carried Table G.4
out with a positive result? Figure G.4
Figure G.5
3. Were all manufacturer specific tests of the parameterization of external
safety devices (e. g. laser scanners, converters …) carried out positively
and documented?
necessary documentation needed reference existent (y/n)
4. Documents of the V-model
5. Final document of the safety relevant software including signatures
6. Final document of the control system hardware configuration with
checksums and all adjustments
7. Archiving of the handbooks of all safety relevant system components
8. Final document of the configuration of all safety relevant peripheral
devices
9. The relevant C standards
Date:
Name:
Software signature:
Hardware signature:
3829
3828
3827
3826
3825
– 120 –
((void))
Annex H
ENTWURF OVE
(informative)
IEC CDV 62061  IEC 2019
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 121 –
3830 Annex I
3831 (informative)
3832
3833 Examples of safety functions
3834 I.1 Examples of safety functions
3835 Examples of typical safety functions with their relevant references to international standards
3836 are given in Table I.1.
3837 Table I.1 – Examples of typical safety functions
Safety function ISO 12100 Standards and information
Safety-related stopping, 6.2.11.3 IEC 60204-1, stop categories

initiated by a IEC 61800-5-2, drive functions, e.g. STO, SS1, SBC
- guard ISO 14119 Interlocking devices associated with guards
- protective device IEC 61496 s eries, Electro-sensitive protective
equipm ent
Start and re-start 6.2.11.3 IEC 60204-1, EN 1037, ISO 14118

(see Note 1)
Manually operated control 6.2.11.8 IEC 60204-1, Type C standards

system (manual handling) ISO 11161 Integrated manufacturing systems
Type C standards
- device with reset (push 6.2.11.8 b)
button)
- two-hand control 6.2.11.8 b) ISO 13851 Two-hand control devices
6.2.11.9
- manual avoiding of 6.2.11.8 b)
safety functions
Adjusting, teaching, IEC 60204-1,

retooling, fault finding, Type C standards
maintenance, cleaning IEC 60947-5-8
- enabling function IEC 61800-5-2, drive functions, e.g. SLS, SOS
- safe motion,
safe “positioning”
Selection of control or 6.2.11.10 9.2.3.5 of IEC 60204-1:2016 ; 8.4 of ISO 11161:2007,

operating modes (Integrated manufacturing systems); Type C standards
(see Note 2)
Guard locking 3.27.5 ISO 14119 Interlocking devices associated with guards
Emergency stop IEC 60204-1, stop categories; ISO 13850 emergency

(see Note 3) stop functions
NOTE 1 To be considered in interrelationship to “unexpected starting”.

NOTE 2 In general to be evaluated in interrelationship to machine functions ( e . g . selection of routine in the
application software of the safety controller) and requirements of systematic integrity.
NOTE 3 Complementary protective measures refer to ISO 12100.
3838
ENTWURF OVE
– 122 – IEC CDV 62061  IEC 2019
3839 I.2 Example of low demand function

3840 Demand to a safety control function is an event that causes the safety control system to
3841 perform the safety control function. As such, the demand is only related to the application and
3842 its hazards, but not to technology used. The event is a situation where an accident with a
3843 specified level of harm to people would occur, unless prevented by the safety control function
3844 under assessment.
3845 The demand rate DR to a safety function is the rate of initiating events IR, reduced by the
3846 overall probability, that the specified harm to people is avoided and that the machine is put in
3847 a safe state, without assuming the intervention of the safety function.
3848 Diagnostic capability depends on technology used. Especially when electro-mechanical
3849 technology is used, a high diagnostic coverage may not be reachable. Then proof tests at
3850 appropriate intervals need to be applied. Those intervals relate to demand intervals.
3851 In summary, the safety function can be treated as a function in low demand mode of
3852 operation, if all the following apply:
3853 • The frequency of demands is no greater than one per year.
3854 • Proof tests at regular intervals are necessary, foreseen and practicable in the environment
3856 • The proof test interval is no longer than twice the average period between “initiating
3857 events”: DR / 2TR <1, then DR < 2TR or TI < 2 DI.
3858 Some of the machinery that have low demand functions are Gas Turbines, Steam Turbines,
3859 Centrifugal Compressors, Reciprocating Compressor, Motors, Generators and Pumps.
3860 In what follows, an example of two low demand function for a Gas Turbine (GT) Unit is
3861 presented. Figures I.1 and I.2 show a typical configuration of a GT unit where a Control
3862 System is only used to regulate continuously the GT operation and the Safety System will be
3863 requesting to operate the safety functions only in case of a demand (e.g. speed of the rotor or
3864 vibration of the rotor will be over the defined setting limits).
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 123 –
3865
3866
Figure I.1 – Relationship between demand of a safety function, failure and trip limit in a
3867
3868 safety function
ENTWURF OVE
– 124 – IEC CDV 62061  IEC 2019

GAS TURBINE TYPICAL CONFIGURATION

3869
3870
Key — Type of equipment

1 manual isolation valve 8 automatic shut-off valve or fast acting shut-off valve a
2 strainer, optional 9 vent valve b
3 automatic shut-off 10 automatic shut-off valve or automatic fast acting shut-
off valve a
valve
11 flow control valve
5 vent valve
6 vent 13 combustion system
7 strainer, optional 14 typical gas turbine enclosure or building limits
position
a Close on every shut-down.

b Vent on every shut-down.
3871 Figure I.2 - Typical configuration of a gas turbine
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 125 –
3872
3873 Safety Function – Rotor Overspeed (each shaft)

3874 Causes
3875 Main causes considering the entire GT lifecycle are:
3876 • Load rejection;
3877 • Huge load shedding;
3878 • Controller/Valve failure;
3879 • Coupling failure.
3880
3881 Potential Consequences
3882 High kinetic energy due to Overspeed condition could determine an uncontained failure
3883 (e.g.: blade -out, coupling, etc.).
3884
3885 Safe State
3886 When GT has one of the highlighted causes and control system will not be able to
3887 regulate then GT will have an overspeed of the Rotor. In this situation, the safety
3888 function will be operated (Demand) to shut down the GT unit closing the shut-down
3889 valves to stop as soon as possible the GT unit.
3890
3891
3892 Safety Function -- Excessive Vibration (each shaft)
3893 Causes
3894 Main causes considering the entire GT lifecycle are:
3895 • Rotor Unbalance;
3896 • Rotating parts misalignment;
3897 • Bearings failure;
3898 • Rubbing/mechanical interference;
3899 • Aeroelastic interactions
3900
3901 Potential Consequences
3902 High uncontrolled GT vibrations event can lead to major failures and possible loss of
3903 containment or collateral damage. Risks are related with possible gas leak and
3904 projectiles.
3905
3906 Safe State

3907 When GT has one of the highlighted causes and control system will not be able to
3908 regulate then GT will have an excessive vibration of the Rotor. In this situation, the
3909 safety function will be operated (Demand) to shut down the GT unit closing the shut-
3910 down valves to stop as soon as possible the GT unit.
3915
3914
3913
3912
3911
– 126 –
((void))
Annex J
ENTWURF OVE
(informative)
IEC CDV 62061  IEC 2019
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 127 –
3916 Annex K
3917 (informative)
3918
3919 Simplified approaches to evaluate the PFH value of a subsystem
3920 K.1 Table allocation approach
3921 The following procedure allows evaluating the PFH value of a subsystem:
3922 1) Selection of the used architecture of a not-pre-designed subsystem based on the DC(s)
3923 per channel;
3924 NOTE 1 A pre-designed subsystem is characterized by a SIL with a PFH value (see also 6.1). A not-pre-
3925 designed subsystem claims a maximum SIL based on the architectural constraints (see 7.4).
3926 Where the DCs per channel are different either the lowest DC per channel may be used
3927 as a worst case approach, or the arithmetic average of DC per channel of both channels.
3928 2) Determination of PFH value with Table K.1 and Table K.2 for not-pre-designed
3929 subsystems:
3930 – using Table K.1 for components qualified by MTTF D per channel and DC to allocate the
3931 PFH value within a range of 10 %, 20 %, 30 %, 40 % or 50 % of the limit of the
3932 respective required SIL, or
3933 – using Table K.2 for components qualified by B 10D and equation (5) in 7.3.4.2 to
3934 determine the MTTF D per channel and then, by use of Table K.1, allocating the PFH
3935 value within a range of 10 %, 20 %, 30 %, 40 % or 50 % of the limit of the respective
3936 required SIL.
3937 NOTE 2 Where a dual channel architecture is used and the MTTF D per channel are different,
3938 either the lowest MTTF D per channel of both channels can be used as a worst case approach,
3939 or the geometric average of MTTF D per channel of both channels. Example: MTTF De1 = 20 a,
3940 MTTF De2 = 200 a. The geometric average is calculated as follows:
3941 𝑀𝑀𝑀𝑀D average = √20𝑎 × 200𝑎 = 63,2𝑎.
3942 The following examples show the use of the table allocation approach:
-06 -07
3943 – with DC 1 = 90 %, DC 2 = 90 % and MTTF D = 60 years per channel, 0,1 x 10 = 1 x 10 as
3944 10 % of the PFH value for SIL 2 can be allocated;
-06 -07
3945 – with DC 1 = 90 %, DC 2 ≥ 99 % and MTTF D = 50 years per channel, 0,2 x 10 = 2 x 10 as
3946 20 % of the PFH value for SIL 2 with DC ≥ 90 % can be allocated;
-05 -06
3947 – with DC 1 = 90 %, DC 2 = 90 % and MTTF D = 20 years per channel, 0,3 x 10 = 3 x 10 as
3948 30 % of the PFH value for SIL 1 with DC ≥ 60 % can be allocated;
3949 – with DC 1 = 99 %, DC 2 = 99 %, MTTF D1 = 20 years and MTTF D2 = 200 years,
-07 -08
3950 MTTF D average = 63,2 years per channel can be used and 0,5 x 10 = 5 x 10 as 30 % of
3951 the PFH value for SIL 3 can be allocated.
ENTWURF OVE
– 128 – IEC CDV 62061  IEC 2019
3952 Table K.1 – Allocation of PFH value of a subsystem
3953
3954 NOTE 1 This table is based on the formulas described in clause K.2. A common cause factor of β = 2 % and a
3955 useful life time of 20 years have been assumed.
3956 NOTE 2 In case of architecture C the diagnostic channel was assumed to have the same MTTF D as the functional
3957 channel. The diagnostic channel may have a MTTF D down to the half of the MTTF D of the functional channel. The
3958 consequent increase of the actual PFH from the table value remains below an acceptable limit. Moreover, time-
3959 optimal monitoring is assumed, see NOTE 1 of K.2.4.
3960 NOTE 3 In case of architecture D the diagnostic test interval T 2 was assumed to not exceed 1 week.
3961 NOTE 4 In case of architecture C a fault handling function is assumed. Its realisation should have at least the half
3962 MTTF D of the functional channel.
3963 NOTE 5 It is always allowed to claim a lower DC than actually achieved (see 3 rd numerical example above).
3964
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 129 –
3965 Table K.2 – Relationship between B 10D , operations and MTTF D
3966
3967 K.2 Simplified Formulas for the estimation of PFH

3968 K.2.1 General
3969 This subclause describes a simplified approach to the estimation of probability of dangerous
3970 random hardware failures for a number of basic subsystem architectures and gives formulas
3971 that can be used for subsystems. The formulas are in themselves a simplification and are
3972 intended to provide estimates that are biased towards the safe direction. The precondition for
3973 the validity for all formulas given in this subclause is that the subsystem is operating in the
3974 “high demand or continuous mode” (3.1.13).
3975 NOTE 1 For equations (K.1) to (K.8) given in K.2.2 to K.2.5 constant and sufficiently low (1 >> λ x T 1 ) failure rates
3976 (λ) of the subsystem elements are assumed (this means that the mean time to dangerous failure is much greater
3977 than the proof test interval or the useful lifetime of the subsystem).
3978 K.2.2 Basic subsystem architecture A: single channel without a diagnostic function
3979 This single channel subsystem covers the architecture A subsystem of 7.5.2.1. In this
3980 architecture (see Figure K.1), any dangerous failure of a subsystem element causes a failure
Subsystem A

λDe1 λDen
3982
3983 Figure K.1 - Subsystem A logical representation.

3984 For architecture A, the average frequency of a dangerous failure of the subsystem is the sum
3985 of the dangerous failure rates of all subsystems elements:
𝑷𝑷𝑷 = 𝝀𝐃𝐃𝟏 + ⋯ + 𝝀𝐃𝐃𝒏 (K.1)
3986 where
3987 𝜆De𝑖 is the dangerous failure rate of element ei within the single functional channel.
ENTWURF OVE
– 130 – IEC CDV 62061  IEC 2019
3988 K.2.3 Basic subsystem architecture B: dual channel without a diagnostic function
3989 This dual channel subsystem covers the architecture B subsystem of 7.5.2.2. This
3990 architecture (see Figure K.2) is such that a single failure of any subsystem element does not
3991 cause a loss of the safety function. Thus, there would have to be a dangerous failure in more
3992 than one element before failure of the safety function can occur.
Subsystem B
Subsystem element 1
λDe1
Common cause failure
Subsystem element 2
λDe2
3993
3994 Figure K.2 - Subsystem B logical representation

3995 For architecture B, the average frequency of a dangerous failure of the subsystem is:
𝑷𝑷𝑷 = (𝟏 − 𝜷)𝟐 × 𝝀𝐃𝐃𝟏 × 𝝀𝐃𝐃𝟐 × 𝑻𝟏 + 𝜷 × (𝝀𝐃𝐃𝟏 + 𝝀𝐃𝐃𝟐 )⁄𝟐 (K.2)
3996 where
3997 𝜆De1 is the dangerous failure rate of element e1 comprising the first functional channel;
3998 𝜆De2 is the dangerous failure rate of element e2 comprising the second functional
3999 channel;
4000 𝑇1 is the proof test interval or useful lifetime whichever is the smaller;
4001 𝛽 is the susceptibility to common cause failures.
4002 K.2.4 Basic subsystem architecture C: single channel with a diagnostic function
4003
4004 K.2.4.1 General

4005 This single channel subsystem covers the architecture C subsystem of 7.5.2.3 (see Figure
4006 K.3).
Subsystem C

λDe1 λDen
Diagnostic function(s)
4007
4008 Figure K.3 – Subsystem C logical representation

4009 The safety function is performed by a single channel comprising the elements e1 to en. Any
4010 undetected dangerous fault of a subsystem element leads to a dangerous failure of the safety
4011 function. Where a fault of a subsystem element is detected, the diagnostic function(s) initiates a fault
4012 reaction function (see 6.3.2).
4013
4014 In the following the notion of fault handling function is used. The fault handling function comprises both
4015 the fault detection function and the fault reaction function, see Figure K.1.
4016
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 131 –
4017
4018 Figure K.4 - Correlation of subsystem C and the pertinent fault handling function
4019
4020 All approaches of K.2.4 for the calculation of PFH assume time-optimal fault handling. Time-optimal
4021 fault handling of a subsystem element can be assumed if:
4022 • The diagnostic rate is at least a factor of 100 higher than the demand rate of the safety
4023 function and the time needed for the fault reaction is sufficiently short to bring the
4024 system to a safe state before a hazardous event occurs, or
4025 • The fault handling is performed immediately upon any potential demand of the safety
4026 function and the time needed to detect a detectable fault and to bring the system to a
4027 safe state is shorter than the process safety time, or
4028 • The fault handling is performed continuously and the time needed to detect a
4029 detectable fault and to bring the system to a safe state is shorter than the process
4030 safety time, or
4031 • The fault handling is performed periodically and the sum of the test interval, the time
4032 needed to detect a detectable fault and time needed to bring the system to a safe
4033 state is shorter than the process safety time.
4034
4035 NOTE 1: Although the failure of the fault handling function will not cause a failure of the safety function, the elements
4036 contributing to the fault handling function are assigned a dangerous failure rate containing the letter D in the index of λ.
4037 Dangerous failures in this sense are failures that lead to a loss of the fault handling function. The dangerous failure rate of
4038 element involved in the fault handling function does not cover failures which lead to a fault reaction although there is no failure
4039 of the functional channel (so-called “false trips”).
4040
4041 K.2.4.2 External fault handling function

4042 The fault handling function may be completely performed by a separate SCS which is also
4043 involved in performing the safety function, thus contributing to its PFH. These conditions are
4044 depicted in Figure K.5.
Subsystem C
Separate SCS
involved in performing
Subsystem the safety function
element(s) and providing
λDe diagnostics and
fault reaction for
subsystem C
4045
4046 Figure K.5 - Subsystem C with external fault handling function

4047
4048 Subsystem C may be comprised of n elements numbered from 1 to n.

ENTWURF OVE
– 132 – IEC CDV 62061  IEC 2019
4049 If the diagnostic function and the fault reaction function are provided by separate
4050 subsystem(s) within the SCS the average frequency of a dangerous failure of the subsystem
4051 is:
𝑷𝑷𝑷 = (𝟏 − 𝑫𝑫𝟏 ) × 𝝀𝐃𝐃𝟏 + ⋯ + (𝟏 − 𝑫𝑫𝒏 ) × 𝝀𝐃𝐃𝒏 (K.3)
4052 where
4053 𝜆De1 is the dangerous failure rate of the first element 𝑒1 within the single functional channel;
4054 𝜆De𝑛 is the dangerous failure rate of the 𝑛𝑡ℎ element 𝑒𝑛 within the single functional channel;
4055 𝐷𝐷1 is the diagnostic coverage for the first element 𝑒1 of the single functional channel;
4056 𝐷𝐷𝑛 is the diagnostic coverage for the 𝑛𝑡ℎ element 𝑒𝑛 of the single functional channel;
4057 𝑛 is the number of elements of the single functional channel.
4058
4059 K.2.4.3 Fault handling partially or completely done within the subsystem
4060
4061 For the following case, the notion of a fault handling function is needed with the dangerous
4062 failure rate λ D FH associated to it. It is defined as follows:
4063 • If the diagnostic function is provided by a separate subsystem within the SCS and the
4064 fault reaction function is provided by this architecture C subsystem, the reaction
4065 function is comprised by the fault reaction function only and λ D FH = λ D FR . These
4066 conditions are depicted in Figure K.6.
4067 • If the diagnostic function is provided by this architecture C subsystem and the fault
4068 reaction function is provided by a separate subsystem within the SCS, the reaction
4069 function is comprised by the diagnostics reaction function only and λ D FH = λ D FD . These
4070 conditions are depicted in Figure K.7.
4071 • If the diagnostic function and the fault reaction function are both provided by this
4072 architecture C subsystem, the reaction function is comprised by the diagnostic
4073 function and the fault reaction function and λ D FH = λ D FD + λ D FR . These conditions are
4074 depicted in Figure K.8.
4075
4076 In all three cases the dangerous failure rate of the fault handling function λ D FH is given by the
4077 sum of the dangerous failure rates of all elements which contribute to the fault handling
4078 function and which are part of subsystem C.
4079
Subsystem C
Separate SCS
Subsystem
the safety function
element(s)
and providing
λDe
diagnostics for
subsystem C
Element(s) performing
fault reaction
λD FR
4080
4081 Figure K.6 – Subsystem C with external fault diagnostics

4082
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 133 –
Subsystem C
Separate SCS
Subsystem
the safety function
element(s)
and providing fault
λDe
reaction for
subsystem C
Element(s) performing
fault diagnostics
λD FD
4083
4084 Figure K.7 – Subsystem C with external fault reaction

4085
Subsystem C
Subsystem
element(s)
λDe
Element(s) performing Element(s) performing

fault diagnostics fault reaction
λD FD λD FR
4086
4087 Figure K.8 – Subsystem C with internal fault diagnostics and internal fault reaction
4088
4089 If in one of the three above-described cases all of the following conditions apply
4090 • β ≤ 2%
4091 • DC ≤ 99%
• 1/ λ De ≤ 1000 years
4092
4093 • 1/ λ D FH has at least the minimum value according to Table K.3

4094 then the PFH value of the subsystem C can be calculated using equation (K.3).
4095 Table K.3 – Minimum value of 1/ λ D FH for the applicability of PFH equation (K.3)
Minimum value
DC range of
1/ λ D FH [years]
60 % ≤ DC < 65 % 44
65 % ≤ DC < 70 % 59
70 % ≤ DC < 75 % 100
75 % ≤ DC < 80 % 170
80 % ≤ DC < 85 % 300
85 % ≤ DC < 90 % 550
90 % ≤ DC < 95 % 1200
95 % ≤ DC ≤ 99 % 5900
NOTE If the functional channel is comprised by
more than one element the related DC is
ENTWURF OVE
– 134 – IEC CDV 62061  IEC 2019
calculated by using Equation (K.6).
4096
4097 If at least one of the above conditions is not fulfilled then one of the following approaches can
4098 be used. These approaches are also applicable if the conditions are fulfilled.
4099 If the functional channel is comprised by one element only and the fault handling function(s)
4100 within the subsystem is (are) realized by another single element, the following equation (K.4),
4101 can be used to calculate PFH:
𝑷𝑷𝑷 = 𝝀𝐃𝐃 − 𝑫𝑫 × [𝝀𝐃𝐃 − 𝜷 × 𝐦𝐢𝐧(𝝀𝐃𝐃 , 𝝀𝐃 𝐅𝐅 )]

𝟏 (K.4)
× �𝟏 − [𝝀𝐃 𝐅𝐅 − 𝜷 × 𝐦𝐦𝐦(𝝀𝐃𝐃 , 𝝀𝐃 𝐅𝐅 )] × 𝑻𝟏 �
𝟐
4102 where
4104 𝜆De is the dangerous failure rate of the single element e of the functional channel;
4105 𝜆D FH is the failure rate of the single element that realizes the fault handling function(s)
4106 within the subsystem;
4107 𝐷𝐷 is the diagnostic coverage for the single element e of the functional channel;
4108 β is the susceptibility to common cause failures of the functional channel and the
4109 channel that realizes the fault handling function(s) within the subsystem.
4110 If the functional channel is comprised by n elements and the fault handling function(s) within
4111 the subsystem is (are) realized by m elements, the following equations (K.5), (K.6) and (K.7)
4112 can be used to calculate PFH:
𝒏 𝒏 𝒎
𝟏 (K.5)
𝑷𝑷𝑷 = � 𝝀𝐃𝐃𝒊 − 𝑫𝑫 × �� 𝝀𝐃𝐃𝒊 − 𝝀𝐂𝐂 � × �𝟏 − �� 𝝀𝐃 𝐅𝐅𝒋 − 𝝀𝐂𝐂 � × 𝑻𝟏 �
𝟐
𝒊=𝟏 𝒊=𝟏 𝒋=𝟏
4113 with
∑𝒏
𝒊=𝟏(𝑫𝑫𝒊 × 𝝀𝐃𝐃𝒊 ) (K.6)
𝑫𝑫 = ∑𝒏
𝒊=𝟏 𝝀𝐃𝐃𝒊
4114
𝝀𝐂𝐂 = 𝜷 × 𝐦𝐦𝐦 �∑𝒏𝒊=𝟏 𝝀𝐃𝐃𝒊 , ∑𝒎 (K.7)

𝒋=𝟏 𝝀𝐃 𝐅𝐅𝒋 �
4115
4116 where
4118 𝜆De𝑖 is the dangerous failure rate of element ei within the single functional channel;
4119 n is the number of elements of the single functional channel;
4120 λ D FH j is the failures rate of the element number j within the single channel that realizes
4121 the fault handling function(s) for the functional channel within the subsystem;
4122 m is the number of elements of the single channel that realizes the fault handling
4123 function(s) for the functional channel within the subsystem;
4124 DC i is the diagnostic coverage for element ei of the single functional channel;
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 135 –
4125 β is the susceptibility to common cause failures of the functional channel and the
4126 channel that realizes the fault handling function(s) for the functional channel
4127 within the subsystem.
4128 NOTE 2: In case that the the dangerous failure rate(s) of the fault handling function(s) within the subsystem can be
4129 assumed to be zero ( λ D FH j = 0) equations (K.5) to (K.7) simplify to equation (K.3).
4130
4131 K.2.5 Basic subsystem architecture D: dual channel with a diagnostic function(s)
4132
Subsystem D
Subsystem element 1
λDe1
Diagnostic function(s) Common cause failure
Subsystem element 2
λDe2
4133
4134 Figure K.9 - Subsystem D logical representation

4135 This dual channel subsystem covers the architecture D subsystem of 7.5.2.4. This
4136 architecture (see Figure K.9) is such that a single failure of any subsystem element does not
4137 cause a loss of the safety function.
4138 For subsystem elements of different design, the average frequency of a dangerous failure of
4139 the subsystem is:
𝑷𝑷𝑷 = (𝟏 − 𝜷)𝟐 (K.8)
× [𝝀𝐃𝐃𝐃 × 𝝀𝐃𝐃𝐃 × (𝑫𝑫𝟏 + 𝑫𝑫𝟐 ) × 𝑻𝟐 ⁄𝟐 + 𝝀𝐃𝐃𝐃 × 𝝀𝐃𝐃𝐃
× (𝟐 − 𝑫𝑫𝟏 − 𝑫𝑫𝟐 ) × 𝑻𝟏 ⁄𝟐 ] + 𝜷 × (𝝀𝐃𝐃𝐃 + 𝝀𝐃𝐃𝐃 )⁄𝟐
4140 where
4141 T2 is the diagnostic test interval;
4142 T1 is the proof test interval or useful lifetime whichever is the smaller;
4143 β is the susceptibility to common cause failures;
4144 λ De1 is the dangerous failure rate of subsystem element e1;
4145 λ De2 is the dangerous failure rate of subsystem element e2;
4146 DC 1 is the diagnostic coverage for subsystem element e1;
4147 DC 2 is the diagnostic coverage for subsystem element e2.
4148 For architecture D for subsystem elements of the same design, the probability of dangerous
4149 failure of the subsystem is:
(K.9)
𝐏𝐏𝐏 = (𝟏 − 𝜷)𝟐 × [𝑫𝑫 × 𝑻𝟐 + (𝟏 − 𝑫𝑫) × 𝑻𝟏 ] × 𝝀𝐃𝐃 𝟐 + 𝜷 × 𝝀𝐃𝐃
4150 where
4151 λ De is the dangerous failure rate of subsystem element e1 or e2;

4152 DC is the diagnostic coverage for subsystem element e1 or e2.
4153 K.3 Parts count method

4154 Use of the “parts count method” serves to estimate the λ D for each channel separately.
ENTWURF OVE
– 136 – IEC CDV 62061  IEC 2019
4155 NOTE The parts count method is an approximation which always errs on the safe side. If more exact values are
4156 required, the designer should take the failure modes into account, but this can be very complicated.
𝑵 �
𝑵
(K.10)
𝝀𝐃 = � 𝝀𝐃𝒊 = ��𝒏𝒋 𝝀𝐃𝒋 �
𝒊=𝟏 𝒋=𝟏
4157 where
4158 λD is the dangerous failure rate of the complete channel;
4159 λ Di is the dangerous failure rate of each component which has a contribution to the
4160 safety function;
4161 N is the total Number of components;
4162 nj is the number of components within a set of equal components;
4163 λ Dj is the dangerous failure rate of each component of set number j of equal
4164 components which have a contribution to the safety function;
~
4165 N is the number of sets of equal components.
4169
4168
4167
4166
IEC CDV 62061  IEC 2019
– 137 –
((void))
Annex L
ENTWURF OVE
ENTWURF OVE
– 138 – IEC CDV 62061  IEC 2019
4170 Annex M
4171 (informative)
4172
4173 The functional safety plan and design activities
4174 M.1 General
4175 This annex illustrates the relationship between activities, documentation and roles of involved
4176 personnel during the lifetime of a machine.
4177 M.2 Example of a machine design plan including a safety plan

4178 The Figure M.1 illustrates a non-exhaustive example of a machine design plan including a
4179 safety plan.
4180
4181
4182 Figure M.1 – Example of a machine design plan including a safety plan
4183 M.3 Example of activities, documents and roles

4184 The Figure M.2 illustrates example of activities, documentation and roles over the lifecycle.
4185
ENTWURF OVE
IEC CDV 62061  IEC 2019 – 139 –

4186
4187 Figure M.2 – Example of activities, documents and roles

ENTWURF OVE
– 140 – IEC CDV 62061  IEC 2019

4188
4189 Figure M.2 – Example of activities, documents and roles (continued)

ENTWURF OVE
IEC CDV 62061  IEC 2019 – 141 –
4190 Bibliography
4191 IEC 60364-4-41, Low voltage electrical installations - Part 4-41: Protection for safety -
4192 Protection against electric shock
4193 IEC 60812, Failure modes and effects analysis (FMEA and FMECA)
4194 IEC 61000-6-7, Electromagnetic compatibility (EMC) - Part 6-7: Generic standards - Immunity
4195 requirements for equipment intended to perform functions in a safety-related system
4196 (functional safety) in industrial locations
4197 IEC 61025, Fault tree analysis (FTA)
4198 IEC 61131-6, Programmable controllers - Part 6: Functional safety
4199 IEC 61165, Application of Markov techniques
4200 IEC 61326-3-1, Electrical equipment for measurement, control and laboratory use - EMC
4201 requirements - Part 3-1: Immunity requirements for safety-related systems and for equipment
4202 intended to perform safety-related functions (functional safety) - General industrial
4203 applications

4205 systems – Part 4: Definitions and abbreviations

4207 systems – Part 5: Examples of methods for the determination of safety integrity levels

4209 systems – Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3

4211 systems – Part 7: Overview of techniques and measures
4212 IEC 61511-3, Functional safety – Safety instrumented systems for the process industry sector
4213 – Part 3: Guidance for the determination of the required safety integrity levels
4214 IEC 61649, Weibull analysis
4215 IEC 61709, Electric components - Reliability - Reference conditions for failure rates and
4216 stress models for conversion
4217 IEC 61784-3, Industrial communication networks - Profiles - Part 3: Functional safety
4218 fieldbuses - General rules and profile definitions
4219 IEC 61800-5-2 Adjustable speed electrical power drive systems – Part 5-2: Safety
4220 requirements – Functional
4221 IEC/TS 62443-1-1, Industrial communication networks - Network and system security - Part 1-
4222 1: Terminology, concepts and models
4223 IEC 62502, Analysis techniques for dependability - Event tree analysis (ETA)
4224 _____________
Stellungnahmen zu diesem Entwurf
Hier einige praktische Hinweise, die Ihnen und dem zuständigen Komitee die Behandlung von Stellungnahmen
und Änderungsvorschlägen erleichtern:
Vorlage Verwenden Sie für Ihre Stellungnahmen/Änderungsvorschläge bitte das
entsprechende Formular im Internet. Download unter
www.ove.at/oek/einspruch.htm
Gliederung Kommentare zu einzelnen Abschnitten oder Punkten des Entwurfs bitte in
getrennten Zeilen anführen. Dies erleichtert die Zuordnung der
eingelangten Stellungnahmen zu den einzelnen Abschnitten.
Sprache Stellungnahmen zu Europäischen Normen fassen Sie bitte in englischer
Sprache – der gemeinsamen Arbeitssprache der europäischen
Normungsgremien – ab.
Redaktionelle bzw. sprachliche Änderungs-/Verbesserungsvorschläge zu
deutschsprachigen Fassungen Europäischer Normen bitte
(selbstverständlich) in deutscher Sprache.
Schrift/Formatierung Verwenden Sie bitte die Schriftart „Arial“ mit 9 pt Schriftgröße. Formate
bitte nicht ändern.
Zusendung Die Stellungnahme senden Sie bitte per E-Mail an die OEK-Geschäftsstelle
(ove@ove.at)
Eine weitere Möglichkeit, Stellungnahmen bzw. Änderungsvorschläge an

die OEK-Geschäftsstelle zu übermitteln, bietet das Online-Entwurfsportal
unter www.ove.at/entwurfsportal
Patentrechtliche Aspekte Empfänger dieses OVE-Entwurfes werden gebeten, mit ihren Kommentaren
jegliche relevante Patentrechte, die Sie kennen, mitzuteilen und
unterstützende Dokumentationen zur Verfügung zu stellen.

Ove en Iec 62061

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ove en Iec 62061

Hochgeladen von

Copyright:

Verfügbare Formate

ENTWURF

OVE EN IEC 62061

Medieninhaber und Hersteller: ICS 13.110, 25.040.99, 29.020

Copyright © OVE – 2019.

OVE Österreichischer Verband für Elektrotechnik zuständig OVE/TK E

Erläuterungen zum Entwurf

COMMITTEE DRAFT FOR VOTE (CDV)

D ATE OF CIRCULATION : C LOSING DATE FOR VOTING :

IEC TC 44 : S AFETY OF MACHINERY - E LECTROTECHNICAL ASPECTS

United Kingdom Mrs Nyomee Hla-Shwe Tun

O F INTEREST TO THE FOLLOW ING COMMITTEES : P ROPOSED HORIZONTAL STANDARD :

Other TC/SCs are requested to indicate their interest, if any, in

Attention IEC-CENELEC parallel voting

The CENELEC members are invited to vote through the

PROPOSED STABILITY DATE : 2024

N OTE FROM TC/SC OFFICERS :

–2– IEC CDV 62061  IEC 2019

6.3.1 General ......................................................................................................... 36

IEC CDV 62061  IEC 2019 –3–

6.9.2 Proof test ....................................................................................................... 44

8.3.1 Software safety lifecycle SW Level 1 ............................................................. 60

–4– IEC CDV 62061  IEC 2019

9.1 Validation principles .............................................................................................. 73

10.3.1 General ......................................................................................................... 85

IEC CDV 62061  IEC 2019 –5–

B.4.3 Subsystem 2 design – “evaluation logic” ........................................................ 99

F.2.2 Estimation of effect of CCF .......................................................................... 109

–6– IEC CDV 62061  IEC 2019

K.2.3 Basic subsystem architecture B: dual channel without a diagnostic

Figure 1 - Relationship of this standard to other standards ................................................... 14

IEC CDV 62061  IEC 2019 –7–

Table 1 – SIL and limits of PFH values ................................................................................. 35

Table A.4 – Probability of avoiding or limiting harm (Av) classification .................................. 91

–8– IEC CDV 62061  IEC 2019

Table G.8 – Software validation .......................................................................................... 119

IEC CDV 62061  IEC 2019 –9–

1 INTERNATIONAL ELECTROTECHNICAL COMMISSION

– 10 – IEC CDV 62061  IEC 2019

60 12. requirements on independence for software verification (Section 8) and validation

FDIS Report on voting

IEC CDV 62061  IEC 2019 – 11 –

– 12 – IEC CDV 62061  IEC 2019

112 • integrate safety-related subsystems designed in accordance with other applicable

IEC CDV 62061  IEC 2019 – 13 –

118 SAFETY OF MACHINERY –

139 This standard:

147 This document does not cover

– 14 – IEC CDV 62061  IEC 2019

In scope of Not In scope In scope of In scope of IEC Not In scope of

Design of low Design of Integration of Using Hardware Design of

Developing application Developing application

program using full program using limited

156 Figure 1 - Relationship of this standard to other standards

157 2 Normative references

167 IEC 61508-1, Functional safety of electrical/electronic/ programmable electronic safety-related

IEC CDV 62061  IEC 2019 – 15 –

169 IEC 61508-2, Functional safety of electrical/electronic/ programmable electronic safety-related

172 IEC 61508-3, Functional safety of electrical/electronic/programmable electronic safety-related

180 3 Terms, definitions and abbreviations

configuration management 3.2.68

– 16 – IEC CDV 62061  IEC 2019

high demand mode 3.2.29

safe failure fraction (SFF) 3.2.56

IEC CDV 62061  IEC 2019 – 17 –