Professional Documents
Culture Documents
Iso 13849-1-2023
Iso 13849-1-2023
STANDARD 13849-1
Fourth edition
2023-04
Reference number
ISO 13849-1:2023(E)
© ISO 2023
ISO 13849-1:2023(E)
Contents Page
Foreword........................................................................................................................................................................................................................................ vi
Introduction............................................................................................................................................................................................................................viii
1 Scope.................................................................................................................................................................................................................................. 1
2 Normative references...................................................................................................................................................................................... 1
3 Terms, definitions, symbols and abbreviated terms..................................................................................................... 2
3.1 Terms and definitions....................................................................................................................................................................... 2
3.2 Symbols and abbreviated terms........................................................................................................................................... 10
4 Overview..................................................................................................................................................................................................................... 12
4.1 Risk assessment and risk reduction process at the machine...................................................................... 12
4.2 Contribution to the risk reduction...................................................................................................................................... 14
4.3 Design process of an SRP/CS.................................................................................................................................................... 14
4.4 Methodology........................................................................................................................................................................................... 15
4.5 Required information..................................................................................................................................................................... 16
4.6 Safety function realization by using subsystems.................................................................................................. 17
5 Specification of safety functions....................................................................................................................................................... 17
5.1 Identification and general description of the safety function.................................................................... 17
5.2 Safety requirements specification...................................................................................................................................... 18
5.2.1 General requirements.................................................................................................................................................. 18
5.2.2 Requirements for specific safety functions............................................................................................. 21
5.2.3 Minimizing motivation to defeat safety functions............................................................................. 24
5.2.4 Remote access..................................................................................................................................................................... 25
5.3 Determination of required performance level (PLr) for each safety function............................. 25
5.4 Review of the safety requirements specification (SRS).................................................................................. 26
5.5 Decomposition of SRP/CS into subsystems................................................................................................................. 26
6 Design considerations.................................................................................................................................................................................. 27
6.1 Evaluation of the achieved performance level......................................................................................................... 27
6.1.1 General overview of performance level....................................................................................................... 27
6.1.2 Correlation between performance level (PL) and safety integrity level (SIL).......... 29
6.1.3 Architecture — Categories and their relation to MTTFD of each channel,
average diagnostic coverage and common cause failure (CCF)............................................. 29
6.1.4 Mean time to dangerous failure (MTTFD)................................................................................................. 36
6.1.5 Diagnostic coverage (DC)......................................................................................................................................... 37
6.1.6 Common cause failures (CCFs)............................................................................................................................. 38
6.1.7 Systematic failures......................................................................................................................................................... 38
6.1.8 Simplified procedure for estimating the performance level for subsystems............. 39
6.1.9 Alternative procedure to determine the performance level and PFH
without MTTFD.................................................................................................................................................................. 40
6.1.10 Fault consideration and fault exclusion....................................................................................................... 42
6.1.11 Well-tried component.................................................................................................................................................. 43
6.2 Combination of subsystems to achieve an overall performance level of the safety
function....................................................................................................................................................................................................... 43
6.2.1 General...................................................................................................................................................................................... 43
6.2.2 Known PFH values.......................................................................................................................................................... 43
6.2.3 Unknown PFH values................................................................................................................................................... 44
6.3 Software based manual parameterization.................................................................................................................. 44
6.3.1 General...................................................................................................................................................................................... 44
6.3.2 Influences on safety-related parameters................................................................................................... 45
6.3.3 Requirements for software based manual parameterization................................................. 46
6.3.4 Verification of the parameterization tool.................................................................................................. 47
6.3.5 Documentation of software based manual parameterization................................................ 47
7 Software safety requirements............................................................................................................................................................ 47
7.1 General......................................................................................................................................................................................................... 47
7.2 Limited variability language (LVL) and full variability language (FVL).......................................... 49
7.2.1 Limited variability language (LVL).................................................................................................................. 49
7.2.2 Full variability language (FVL)........................................................................................................................... 49
7.2.3 Decision for limited variability language (LVL) or full variability language
(FVL)........................................................................................................................................................................................... 49
7.3 Safety-related embedded software (SRESW)........................................................................................................... 51
7.3.1 Design of safety-related embedded software (SRESW)............................................................... 51
7.3.2 Alternative procedures for non-accessible embedded software.......................................... 52
7.4 Safety-related application software (SRASW)........................................................................................................ 52
8 Verification of the achieved performance level................................................................................................................ 55
9 Ergonomic aspects of design................................................................................................................................................................. 55
10 Validation................................................................................................................................................................................................................... 55
10.1 Validation principles....................................................................................................................................................................... 55
10.1.1 General...................................................................................................................................................................................... 55
10.1.2 Validation plan................................................................................................................................................................... 57
10.1.3 Generic fault lists............................................................................................................................................................. 58
10.1.4 Specific fault lists............................................................................................................................................................. 58
10.1.5 Information for validation....................................................................................................................................... 58
10.2 Validation of the safety requirements specification (SRS)........................................................................... 59
10.3 Validation by analysis.................................................................................................................................................................... 60
10.3.1 General...................................................................................................................................................................................... 60
10.3.2 Analysis techniques....................................................................................................................................................... 60
10.4 Validation by testing........................................................................................................................................................................ 60
10.4.1 General...................................................................................................................................................................................... 60
10.4.2 Measurement accuracy............................................................................................................................................... 61
10.4.3 Additional requirements for testing............................................................................................................... 62
10.4.4 Number of test samples.............................................................................................................................................. 62
10.4.5 Testing methods................................................................................................................................................................ 62
10.5 Validation of the safety functions........................................................................................................................................ 63
10.6 Validation of the safety integrity of the SRP/CS..................................................................................................... 63
10.6.1 Validation of subsystem(s)...................................................................................................................................... 63
10.6.2 Validation of measures against systematic failures......................................................................... 64
10.6.3 Validation of safety-related software............................................................................................................ 65
10.6.4 Validation of combination of subsystems.................................................................................................. 66
10.6.5 Overall validation of safety integrity............................................................................................................. 66
10.7 Validation of environmental requirements................................................................................................................ 66
10.8 Validation record................................................................................................................................................................................ 67
10.9 Validation maintenance requirements........................................................................................................................... 67
11 Maintainability of SRP/CS........................................................................................................................................................................ 67
12 Technical documentation.........................................................................................................................................................................68
13 Information for use.........................................................................................................................................................................................68
13.1 General......................................................................................................................................................................................................... 68
13.2 Information for SRP/CS integration.................................................................................................................................. 68
13.3 Information for user........................................................................................................................................................................ 69
Annex A (informative) Guidance for the determination of required performance level (PLr).......... 71
Annex B (informative) Block method and safety-related block diagram................................................................. 76
Annex C (informative) Calculating or evaluating MTTFD values for single components......................... 78
Annex D (informative) Simplified method for estimating MTTFD for each channel.....................................86
Annex E (informative) Estimates for diagnostic coverage (DC) for functions and subsystems.......88
Annex F (informative) Method for quantification of measures against common cause
failures (CCF)......................................................................................................................................................................................................... 92
Annex G (informative) Systematic failure..................................................................................................................................................96
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO’s adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 199, Safety of machinery, in collaboration
with the European Committee for Standardization (CEN) Technical Committee CEN/TC 114, Safety of
machinery, in accordance with the Agreement on technical cooperation between ISO and CEN (Vienna
Agreement).
This fourth edition cancels and replaces the third edition (ISO 13849-1:2015), which has been
technically revised.
The main changes are as follows:
— the whole document was reorganized to better follow the design and development process for
control systems;
— new Clause 4 on recommendation for risk assessment;
— specification of the safety functions (updated Clause 5);
— combination of several subsystems (updated in Clause 6);
— new Clause 7 on software safety requirements;
— new Clause 9 on ergonomic aspects of design;
— validation (updated Clause 8 and moved to Clause 10);
— new G.5 on management of the functional safety;
— new Annex L on electromagnetic interference (EMI) immunity;
— new Annex M with additional information for safety requirements specification;
— new Annex N on fault-avoiding measures for the design of safety related software;
— new Annex O with safety-related values of components or parts of the control systems.
A list of all parts in the ISO 13849 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
Introduction
The structure of safety standards in the field of machinery is as follows:
a) Type-A standards (basis standards) give basic concepts, principles for design and general aspects
that can be applied to machinery.
b) Type-B standards (generic safety standards) deal with one or more safety aspect(s), or one or more
type(s) of safeguards that can be used across a wide range of machinery:
— type-B1 standards on particular safety aspects (e.g. safety distances, surface temperature,
noise);
— type-B2 standards on safeguards (e.g. two-hand controls, interlocking devices, pressure
sensitive devices, guards).
c) Type-C standards (machinery safety standards) deal with detailed safety requirements for a
particular machine or group of machines.
This document is a type-B1 standard as defined in ISO 12100:2010.
The first edition of this document was published in 1999 based on EN 954-1:1996 (withdrawn standard).
The second edition was revised in 2006 and the third edition was revised in 2015.
This document is of relevance, in particular for the following stakeholder groups with regard to
machinery safety:
— machine manufacturers (small, medium and large enterprises);
— health and safety bodies (regulators, accident prevention organisations, market surveillance).
Others can be affected by the level of machinery safety achieved with the means of the document:
— machine users/employers (small, medium and large enterprises);
— machine users/employees (e.g. trade unions);
— service providers, e.g. for maintenance (small, medium and large enterprises);
— consumers (i.e. machinery intended for use by consumers).
The above-mentioned stakeholder groups have been given the possibility to participate in the drafting
process of this document.
In addition, this document is intended for standardization bodies elaborating type-C standards, as
defined in ISO 12100:2010.
The requirements of this document can be supplemented or modified by a type-C standard.
For machines which are covered by the scope of a type-C standard and which have been designed and
built according to the requirements of that standard, the requirements of that type-C standard take
precedence.
NOTE 1 The examples and basis for most content is based on stationary machines in factory applications.
However, other machines are not excluded. This document was written without considering if certain machinery
(e.g. mobile machinery) has specific requirements. However, this document is intended to be used across many
machinery industries and as a basis for type-C standards developers, as far as applicable.
This document is intended to give guidance to those involved in the design and assessment of control
systems, and those preparing type-B2 or type-C standards.
Risk reduction according to ISO 12100:2010, Clause 6, is accomplished by applying, in the following
sequence, inherently safe design measures, safeguarding and/or complementary risk reduction
measures and information for use. A designer can reduce risks by risk reduction measures that can
have safety functions. Parts of machinery control systems that are assigned to provide safety functions
are called safety-related parts of control systems (SRP/CS). These can consist of hardware or a
combination of hardware and software and can either be separate from the machine control system
or an integral part of it. In addition to implementing safety functions, SRP/CS can also implement
operational functions.
ISO 12100:2010 is used for risk assessment of the machine. Annex A of this document can be used for
the determination of the required performance level (PLr) of a safety function performed by the SRP/
CS, where its PLr is not specified in the applicable type-C standard. This document is relevant for the
SRP/CS safety functions that are used to address risks for cases where a risk assessment conducted
according to ISO 12100:2010 determines that a risk reduction measure is needed that relies on a safety
function (e.g. interlocking guard). In those cases, the safety-related control system performs a safety
function. This document is intended to be used to design and evaluate the SRP/CS. Only the part of the
control system that is safety-related falls under the scope of this document.
Figure 1 illustrates the relationship between ISO 12100:2010 and this document. For a detailed
overview see Figure 2.
NOTE 2 See also ISO/TR 22100-2:2013 for further information.
Figure 1 — Integration of this document (ISO 13849-1) within the risk reduction process of
ISO 12100:2010
NOTE 3 Figure 1 shows where the SRP/CS contributes to the risk reduction process of ISO 12100:2010: Step
2. The SRP/CS supports the combined risk reduction measures by the implementation of safety functions. The
ability of safety-related parts of control systems to perform a safety function under foreseeable conditions is
allocated one of five levels, called performance levels (PL). The required performance level (PLr) for a particular
safety function (depending on the required risk reduction) will be determined by risk estimation.
Informative Annex A of this document contains a method for risk estimation and can be used for the
determination of the PLr of a safety function performed by the SRP/CS. Any risk estimation method will
show a variance because of the subjective nature of the evaluation criteria. In comparison to Annex A,
type-C standards can have more specific risk estimation methods for specific machine applications.
The frequency of dangerous failure of the safety function depends on several factors, including but
not limited to, hardware and software structure, the extent of fault detection mechanisms [diagnostic
coverage (DC)], reliability of components [mean time to dangerous failure (MTTFD), common cause
failure (CCF)], design process, operating stress, environmental conditions and operation procedures.
In order to facilitate the design of SRP/CS and the assessment of achieved PL, this document employs
a methodology based on the categorization of architectures with specific design criteria (e.g. MTTFD,
DCavg) and specified behaviour under fault conditions. These architectures are allocated one of five
levels termed Categories B, 1, 2, 3 and 4.
Functional safety considers the failure characteristics of elements/components performing a safety
function. For each safety function, this failure characteristic is expressed as the frequency of dangerous
failure per hour (PFH).
The performance levels and categories can be applied to SRP/CS, e.g.:
— control units (e.g. a logic unit for control functions, data processing, monitoring);
— electro-sensitive protective devices (e.g. photoelectric barriers), pressure sensitive devices.
The performance levels can be defined, and categories determined, for subsystems of SRP/CS using
safety parts (components), e.g.:
— protective devices (e.g. two-hand control devices, interlocking devices);
— power control elements (e.g. relays, valves);
— sensors and HMI elements (e.g. position sensors, enable switches).
Machinery covered by this document can range from simple (e.g. small kitchen machines, or automatic
doors and gates) to complex (e.g. packaging machines, printing machines, presses and integrated
machinery into a system).
This document and IEC 62061 both specify a methodology and provide related guidance for the design
and implementation of safety-related control systems of machinery.
The requirements of Clause 10 of this document supersede the requirements of ISO 13849-2:2012
(excluding the informative annexes).
1 Scope
This document specifies a methodology and provides related requirements, recommendations and
guidance for the design and integration of safety‐related parts of control systems (SRP/CS) that perform
safety functions, including the design of software.
This document applies to SRP/CS for high demand and continuous modes of operation including their
subsystems, regardless of the type of technology and energy (e.g. electrical, hydraulic, pneumatic, and
mechanical). This document does not apply to low demand mode of operation.
NOTE 1 See 3.1.44 and the IEC 61508 series for low demand mode of operation.
This document does not specify the safety functions or required performance levels (PLr) that are to be
used in particular applications.
NOTE 2 This document specifies a methodology for SRP/CS design without considering if certain machinery
(e.g. mobile machinery) has specific requirements. These specific requirements can be considered in a Type‑C
standard.
This document does not give specific requirements for the design of products/components that are
parts of SRP/CS. Specific requirements for the design of some components of SRP/CS are covered by
applicable ISO and IEC standards.
This document does not provide specific measures for security aspects (e.g. physical, IT-security, cyber
security).
NOTE 3 Security issues can have an effect on safety functions. See ISO/TR 22100-4 and IEC/TR 63074 for
further information.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 12100:2010, Safety of machinery — General principles for design — Risk assessment and risk reduction
ISO 13849-2:2012, Safety of machinery — Safety-related parts of control systems — Part 2: Validation
ISO 13855:2010, Safety of machinery — Positioning of safeguards with respect to the approach speeds of
parts of the human body
ISO 20607:2019, Safety of machinery — Instruction handbook — General drafting principles
IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safety-related
systems — Part 3: Software requirements
IEC 62046:2018, Safety of machinery — Application of protective equipment to detect the presence of
persons
3.1.2
machine control system
system which responds to input signals from parts of machine elements, operators, external control
equipment or any combination of these and generates output signals causing the machine to behave in
the intended manner
Note 1 to entry: The machine control system can use any technology or any combination of different technologies
(e.g. electrical/electronic, hydraulic, pneumatic and mechanical).
3.1.3
safety requirements specification
SRS
specification containing the requirements for the safety functions (3.1.27) that have to be met by
the safety-related control system in terms of characteristics of the safety functions (functional
requirements) and required performance levels (PLr) (3.1.6)
[SOURCE: IEC 61508‑4:2010, 3.5.11, modified — Information from IEC 61508‑4:2010, 3.5.12 has been
included.]
3.1.4
category
classification of the subsystem (3.1.45) in respect to its resistance to faults (3.1.8) and the subsequent
behaviour in the fault condition which is achieved by the structural arrangement of the parts, fault
detection and/or by their reliability
3.1.5
performance level
PL
discrete level used to specify the ability of safety-related parts of control systems (SRP/CS) (3.1.1) to
perform a safety function (3.1.27) under foreseeable conditions
Note 1 to entry: See 6.1 for a general overview of performance level.
3.1.6
required performance level
PLr
performance level (3.1.5) required in order to achieve the required risk (3.1.19) reduction for each safety
function (3.1.27)
Note 1 to entry: See 5.3 and Figure A.1 for further information on required performance level (PLr).
3.1.7
safety integrity level
SIL
discrete level (one out of a possible four) for specifying the safety integrity requirements of safety
functions (3.1.27) to be allocated to the safety-related systems, where safety integrity level 4 has the
highest level of safety integrity and safety integrity level 1 has the lowest
Note 1 to entry: In this document only SIL 1 to SIL 3 are considered.
[SOURCE: IEC 61508‑4:2010, 3.5.8, modified — “allocated to safety-related systems” has been added to
definition, NOTES have been deleted and new Note 1 to entry has been added.]
3.1.8
fault
abnormal condition that may cause a reduction in, or loss of, the capability of a functional unit to
perform a required function
Note 1 to entry: A fault is often the result of a failure (3.1.10) of the item itself, but can exist without prior failure.
Note 2 to entry: In this document “fault” means random fault or fault caused by a systematic failure (3.1.14).
Note 3 to entry: Failures which only affect the availability of the process under control are outside of the scope of
this document.
b) decreases the probability that the safety function operates correctly when required
[SOURCE: IEC 61508-4:2010, 3.6.7, modified — "EUC" has been replaced by "machine/machinery".]
3.1.13
common cause failure
CCF
failure (3.1.10) that is the result of one or more events, causing concurrent failures of two or more
separate channels (3.1.47) in a multiple channel subsystem (3.1.45), leading to failure of a safety function
(3.1.27)
Note 1 to entry: Common cause failures are not identical with common mode failures (see ISO 12100:2010, 3.36).
[SOURCE: IEC 61508‑4:2010, 3.6.10, modified — "system failure" has been changed to "failure of a
safety function". Note 1 to entry has been added.]
3.1.14
systematic failure
failure (3.1.10) related in a deterministic way to a certain cause, which can only be eliminated by a
modification of the design or of the manufacturing process, operational procedures, documentation or
other relevant factors
Note 1 to entry: Corrective maintenance without modification will usually not eliminate the failure cause.
Note 2 to entry: A systematic failure can be induced by simulating the failure cause.
— is permanently present during the intended use of the machine (e.g. motion of hazardous moving elements,
electric arc during a welding phase, unhealthy posture, noise emission, high temperature); or
[SOURCE: ISO 12100:2010, 3.6, modified — Note 3 to entry has been deleted.]
3.1.18
hazardous situation
circumstance in which a person is exposed to at least one hazard (3.1.17)
Note 1 to entry: The exposure can result in harm (3.1.16) immediately or over a period of time.
[SOURCE: ISO 12100:2010, 3.13, modified — Note 1 to entry has been modified.]
3.1.21
risk assessment
overall process comprising risk analysis (3.1.23) and risk evaluation (3.1.24)
[SOURCE: ISO 12100:2010, 3.17]
3.1.22
risk reduction measure
protective measure
action or means to eliminate hazards (3.1.17) or reduce risks (3.1.19)
EXAMPLE Inherently safe design; protective devices; personal protective equipment; information for use
and installation; organization of work; training; application of equipment; supervision.
3.1.26
reasonably foreseeable misuse
use of a machine in a way not intended by the designer, but which can result from readily predictable
human behaviour
[SOURCE: ISO 12100:2010, 3.24]
3.1.27
safety function
function of a machine whose failure (3.1.10) can result in an immediate increase of the risk(s) (3.1.19)
Note 1 to entry: A safety function is a function implemented by a safety-related part of a control system, which is
needed to achieve or maintain a safe state for the machine, in respect of a specific hazardous event.
[SOURCE: ISO 12100:2010, 3.30, modified — Note 1 to entry has been added.]
3.1.28
sub-function
part of a safety function (3.1.27) whose failure (3.1.10) results in a failure of the safety function
Note 1 to entry: A sub-function is a function implemented by a subsystem (3.1.45) of the safety-related part of a
control system (SRP/CS). See also IEC 61800-5-2:2016.
EXAMPLE Sub-functions according to IEC 61800-5-2 are, e.g. safe torque off (STO), safe stop 1 (SS1). See
Figure 6.
3.1.29
monitoring
diagnostic measure which detects a state and compares it to the expected value
Note 1 to entry: Monitoring is realised by the following methods, e.g. plausibility check (3.1.52), direct, indirect or
cross monitoring (3.1.30) (see Annex E), cyclic test stimulus.
3.1.30
cross monitoring
diagnostic measure which checks plausibility of redundant signals in both channels (3.1.47) of a
redundant subsystem (3.1.45)
3.1.31
programmable electronic system
PE system
system for control, protection or monitoring (3.1.29) based on one or more programmable electronic
devices, including all elements of the system such as power supplies, sensors and other input devices,
data highways and other communication paths, and actuators and other output devices
[SOURCE: IEC 61508‑4:2010, 3.3.1]
3.1.32
mean time to dangerous failure
MTTFD
expectation of the mean time to dangerous failure
Note 1 to entry: In the case of items with an exponential distribution of operating times to dangerous failure (i.e.
a constant failure rate) the MTTFD is numerically equal to the reciprocal of the dangerous failure rate.
[SOURCE: IEC 62061:2021, 3.2.38, modified — Note 1 to entry has been modified.]
3.1.33
MTBF
mean time between failures
expected value of the operating time between consecutive failures (3.1.10)
3.1.34
RDF
ratio of dangerous failures
fraction of the overall failure (3.1.10) rate of an element that can result in a dangerous failure (3.1.12)
3.1.35
diagnostic coverage
DC
measure of the effectiveness of diagnostics, which is determined as the ratio between the failure (3.1.10)
rate of detected dangerous failures (3.1.12) and the failure rate of total dangerous failures
Note 1 to entry: Diagnostic coverage can exist for the whole or parts of a safety-related system. For example,
diagnostic coverage can exist for sensors and/or logic systems and/or power control elements.
3.1.36
mission time
TM
period of time covering the intended use of a safety-related part of a control system (SRP/CS)
3.1.37
test rate
rt
frequency of tests to detect faults (3.1.8) in a safety-related part of a control system (SRP/CS)
Note 1 to entry: Test rate is also used as reciprocal value of diagnostic test interval.
3.1.38
demand rate
rd
frequency of demands for a safety function (3.1.27) to be performed by the safety-related part of a
control system (SRP/CS)
3.1.39
limited variability language
LVL
type of language that provides the capability to combine predefined, application specific, library
functions to implement the safety requirements specifications (SRSs) (3.1.3)
Note 1 to entry: An LVL provides a close functional correspondence with the functions required to achieve the
application.
Note 2 to entry: Typical examples of LVL are given in IEC 61131-3. They include ladder diagram, function block
diagram and sequential function chart. Instruction lists and structured text are not considered to be LVL.
Note 3 to entry: Typical example of systems using LVL: Programmable Logic Controller (PLC) configured for
machine control.
Note 2 to entry: FVL is normally found in embedded software and is rarely used in application software.
Note 3 to entry: FVL examples include: Ada, C, Pascal, Instruction List, assembler languages, C++, Java, SQL.
3.1.41
safety-related application software
SRASW
software specific to the application and generally containing logic sequences, limits and expressions
that control the appropriate inputs, outputs, calculations and decisions necessary to meet the safety-
related part of a control system (SRP/CS) requirements
3.1.42
safety-related embedded software
SRESW
software that is part of the system supplied by the manufacturer and is not intended for modification
by the end-user
Note 1 to entry: Embedded software is also referred to as firmware or system software. See, full variability
language (FVL) (3.1.40).
[SOURCE: IEC 61508‑4:2010, 3.5.16, modified — Note 1 to entry has been amended.]
3.1.45
subsystem
entity which results from a first-level decomposition of a safety-related part of a control system (SRP/
CS) and whose dangerous failure (3.1.12) results in a dangerous failure of a safety function (3.1.27)
Note 1 to entry: The subsystem specification includes its role in the safety function and its interface with the
other subsystems of the SRP/CS.
Note 2 to entry: One subsystem can be part of one or several SRP/CS, e.g. the same combination of contactors can
be used to de-energise a motor in case of detection of a person in a danger zone and also in case of opening a safe
guard.
3.1.46
subsystem element
part of a subsystem (3.1.45) comprising a single component or any group of components
Note 1 to entry: A subsystem element can comprise hardware or a combination of hardware and software. For
the purposes of this document, software-only components are not considered subsystem elements.
Note 2 to entry: For the safety-related values of components or parts of control systems, see Annex O.
3.1.47
channel
element or group of elements that independently implement a safety function (3.1.27) or a part of it
Note 1 to entry: Channel can be a functional channel or a testing channel.
[SOURCE: IEC 61508‑4:2010, 3.3.6, modified — “or a part of it” has been added to the definition and
Note 1 to entry has been added.]
3.1.48
operating mode
mode of operation in a machine (e.g. automatic, manual, maintenance) to select predefined machine
functions and safety measures related to those functions
Note 1 to entry: For each specific operating mode, the relevant safety functions (3.1.27) and/or risk reduction
measures (3.1.22) are implemented.
Note 2 to entry: Operating mode is not a machine function itself. The functions (including safety functions)
summarized under an operating mode can only be used when that particular operating mode has been activated.
3.1.49
well-tried safety principle
principle that has proved effective in the design or integration of safety-related control systems in the
past, to avoid or control critical faults (3.1.8) or failures (3.1.10) which can influence the performance of
a safety function (3.1.27)
Note 1 to entry: Newly developed safety principles can only be considered as equivalent to well-tried if they are
verified using methods which demonstrate their suitability and reliability for safety-related applications.
Note 2 to entry: Well-tried safety principles are effective not only against random hardware failures, but also
against systematic failures (3.1.14) which can creep into the product at some point in the course of the product life
cycle, e.g. faults arising during product design, integration, modification or deterioration.
Note 3 to entry: ISO 13849-2:2012, Tables A.2, B.2, C.2 and D.2 address well-tried safety principles for different
technologies.
3.1.50
well-tried component
component successfully used in safety-related applications
Note 1 to entry: See 6.1.11 for requirements and ISO 13849-2:2012 for a list of recognized well-tried components.
3.1.51
dynamic test
executing either software or operating hardware, or both, in a controlled and systematic way, so as to
demonstrate the presence of the required behaviour and the absence of unwanted behaviour
Note 1 to entry: The test fails if monitoring (3.1.29) did not detect the change as expected.
Note 2 to entry: The use of test pulses is a common technology of dynamic testing and is widely used to detect
short circuits or interruptions in signal paths or malfunctions.
3.1.52
plausibility check
diagnostic measure which is monitoring (3.1.29) that the state of an input (output) fits to the state of the
system or other inputs (outputs)
3.1.53
verification
confirmation, through the provision of objective evidence, that specified requirements have been
fulfilled
Note 1 to entry: The objective evidence needed for a verification can be the result of an inspection or of other
forms of determination such as performing alternative calculations or reviewing documents.
Note 2 to entry: The activities carried out for verification are sometimes called a qualification process.
Note 3 to entry: The word “verified” is used to designate the corresponding status.
Note 2 to entry: The word “validated” is used to designate the corresponding status.
Note 3 to entry: The use conditions for validation can be real or simulated.
[SOURCE: ISO 14990‑1:2016, 3.5.4, modified — “electricity” has been replaced by “the relevant
equipment” in the definition and Note 1 to entry has been added.]
3.1.56
black box
device, system or object which can be viewed in terms of its inputs and outputs only
3.1.57
grey box
device, system or object where some of the internal functions are known
Note 1 to entry: The third way for functional testing is “white box”, where all internal functions are known.
3.1.58
average frequency of a dangerous failure per hour
PFH
average frequency of a dangerous failure of a safety-related part of a control system (SRP/CS) (3.1.1) to
perform the specified safety function over a given period of time
[SOURCE: IEC 61508-4:2010, 3.6.19, modified — “an E/E/PE” has been deleted.]
Table 1 (continued)
Symbol or
abbreviated Description Subclause or section
term
CCF common cause failure 3.1.13
DC diagnostic coverage 3.1.35
DCavg average diagnostic coverage E.2
EMI electromagnetic interference F.3.6.1
ETA event tree analysis 10.3.2
F, F1, F2 frequency and/or exposure times to hazard A.3.2
FB function block Annex J
FVL full variability language 3.1.40
FMEA failure modes and effects analysis 6.1.5
FMECA failure modes, effects and criticality analysis 10.3.2
FTA fault tree analysis 10.3.2
FD(t) cumulated distribution function C.4.3
HFT hardware fault tolerance 6.1
I, I1, I2 input device, e.g. sensor 6.1
i, j index for counting Annex D
I/O inputs/outputs Table E.1
im interconnecting means Figures 7, 8, 9, 10
K1A, K1B contactors Annex I
L, L1, L2 logic 6.1
LVL limited variability language 3.1.39
λD dangerous failure rate of a component Annex C
M motor Annex I
MTTF mean time to failure Annex C
MTTFD mean time to dangerous failure 3.1.32
MTTR mean time to restoration Annex D
n, N, Ñ number of items 6.2, D.1
Nlow number of subsystems with PLlow in a combination of subsystems 6.2
nop mean number of annual operations Annex C
output device, output of the test equipment, e.g. power control
O, O1, O2, OTE 6.1
elements
P, P1, P2 possibility of avoiding or limiting harm A.3.3
PE system programmable electronic system 3.1.31, Annex H
average frequency of a dangerous failure per hour 3.1.58, Table 2,
PFH
Table K.1
PL performance level 3.1.5
PLC programmable logic controller Annex I
lowest performance level of a subsystem in a combination of sub-
PLlow 6.2
systems
PLr required performance level 3.1.6
rd demand rate 3.1.38
rt test rate 3.1.37
RDF ratio of dangerous failures 3.1.34
RS rotation sensor Annex I
Table 1 (continued)
Symbol or
abbreviated Description Subclause or section
term
S, S1, S2 severity of injury A.3.1
SB subsystem Figures 13, H.1, H.2
SOS safe operating stop 5.2.2.2
SS2 safe stop 2 5.2.2.2
SW1A, SW1B, position switches
Annex I
SW2
SIL safety integrity level 3.1.7, Clause 6
SLS safely limited speed Table 3
SRASW safety-related application software 3.1.41
SRESW safety-related embedded software 3.1.42
SRP/CS safety-related part of a control system 3.1.1
SRS safety requirements specification 3.1.3
STO safe torque off Tables 3 and N.2
TE test equipment 6.1
TM mission time 3.1.36
T10D mean time until 10 % of the components fail dangerously Annex C
4 Overview
The SRS and the design of the SRP/CS shall take into account the result of the risk assessment including
the intended use and reasonably foreseeable misuse of the machine (see Figure 1 and Figure 2).
NOTE 2 This document does not apply to non-SRP/CS of a machine (see Figure 6).
Key
a The first time the question is asked, it is answered by the result of the initial risk assessment.
Risk reduction by safeguarding may be realized by SRP/CS that execute safety functions. In this case this
document can be applied.
NOTE 3 In special cases, this document applies also to step 3 of Figure 2. For examples of indications and
alarms see Annex M.
Key
Solution 1 Important part of risk reduction due to protective measures other than the safety function (e.g.
mechanical measures), small part of risk reduction due to safety function (e.g. guard or interlocking
function).
Solution 2 Important part of risk reduction due to the safety function, small part of risk reduction due to
protective measures other than the safety function.
Figure 3 — Overview of the risk reduction measures for each hazardous situation
Figure 4 — Iterative process for design of safety-related parts of control systems (SRP/CS)
4.4 Methodology
This document uses the following methodology:
a) specification of safety functions (Clause 5);
b) design and technical realization of the safety functions including identification of the SRP/CSs and
their subsystems which carry out each safety function;
1) design considerations (Clause 6),
2) software safety requirements (Clause 7);
c) verification that the achieved PL meets PLr (Clause 8);
d) ergonomic aspects of the design (Clause 9);
e) validation (Clause 10 or ISO 13849-2:2012);
f) maintenance (Clause 11);
g) technical documentation (Clause 12);
h) information for use (Clause 13).
The required performance level (PLr) corresponds to the required risk reduction to be provided by
the safety function. The greater the contribution to the risk reduction needed (depending on the initial
risk), the higher the required safety performance shall be. The performance levels of the safety function
are defined in terms of average frequency of dangerous failure of the safety function per hour. There
are five performance levels, ranging from providing a low contribution to risk reduction for PL a, to a
high contribution to the risk reduction for PL e. The defined ranges of frequency of a dangerous failure
per hour are shown in Table 2.
Subsystems (see 5.5) shall be evaluated using the same process as is used for SRP/CS systems, according
to Clauses 5 to 13. For each safety function, the achieved performance level shall meet or exceed the
required performance level (PLr).
Key
a Electrosensitive protective equipment (ESPE).
5.2.1.1 General
The SRS is the basis for all SRP/CS design activities and shall document details of each safety function
to be performed.
The SRS provides the necessary information at the transition from the risk assessment and risk
reduction process according to ISO 12100:2010 to the SRP/CS design and evaluation process according
to this document, especially if these two processes are performed by different persons or organizations
(see Table 3).
Table 3 — Transition from the risk assessment and risk reduction process according to
ISO 12100:2010 to the SRP/CS design and evaluation process according to ISO 13849-1 (this
document)
Necessary information to produce the Examples of specifications of safety func-
Transformation
SRS (see 5.2.1.2) tions in the SRS (see 5.2.1.3)
— results of risk assessment of the required safety functions (examples):
machine or part of it, including
hazardous parts and required 1) interlocking function
overall risk reduction
— operating mode (all)
— machine operating characteristics,
e.g. intended use — triggering event: opening of a
movable guard
— emergency operation
— safety-related reaction: safe torque
— description of the interaction of off (STO) of all movements
different working processes and
manual activities, e.g. repairing — PLr d
— ergonomic aspects — response time
— limits of use in relation to — etc.
environmental conditions
— PLr c
— response time
— etc.
The following information shall be available to the designer of the safety-related control system to
develop the SRS where relevant:
a) results of the risk assessment of the machine or part of it for each specific hazard where the
associated risk reduction measure(s) relies on a safety-related control system to perform a safety
function;
b) machine operating characteristics, including:
1) intended use of the machine,
2) reasonably foreseeable misuse,
3) operating modes (e.g. local mode, automatic mode, modes related to a zone or part of the
machine),
4) the mode(s) of operation during which the safety function is to be active,
NOTE 3 Operational functions (e.g. starting, normal stopping) can also be safety functions, but
this can be ascertained only after a complete risk assessment on the machinery has been carried out.
5.2.1.3 Specification of all safety functions in the safety requirements specification (SRS)
The SRS shall have the following information for each safety function in relation to the specific
application:
a) the brief description / title of the safety function;
b) the event that triggers the safety function;
c) the reaction to be initiated by the safety function output(s) to reach the intended safe state;
EXAMPLE 1 Stop hazardous movements.
j) the demand rate of the safety function and/or the frequency of operation of the SRP/CS;
k) the priority of the safety functions that can be simultaneously active and that can cause conflicting
action;
EXAMPLE 4 An emergency stop function has priority over all other functions.
EXAMPLE 5 The safely limited speed (SLS) function can be a precondition of a "hold to run" safety
function.
See 5.2.2 and Annex M for typical safety functions and their characteristics and safety-related
parameters.
5.2.2.1 General
This subclause provides additional requirements for specific safety functions that are commonly
applied in many SRP/CS.
A safety-related stop function (e.g. initiated by a safeguard) shall as soon as necessary after actuation,
put the machine in a safe state. Such a safety-related stop function shall have priority over all relevant
starts and non-safety-related stops. When a group of machines is working together in a coordinated
manner, provision shall be made for signalling either the supervisory control or the other machines, or
both, that such a stop condition exists.
As a result of the risk assessment, safety-related stop functions can be realised according to the stop
categories in IEC 60204-1:2016+AMD1:2021, 9.2.2.
NOTE IEC 61800-5-2:2016 provides information about safety-related power drive systems including
descriptions of safe-torque off (STO), safe stop 1 (SS1), safe stop 2 (SS2) and safe operating stop (SOS).
After a stop command has been initiated by a safety function, the stop condition shall be maintained
until safe conditions for restarting exist. See also Table M.1.
The re-establishment of the safety function by resetting of the safeguard cancels the stop command. If
indicated by the risk assessment, this cancellation of the stop command shall be confirmed by a manual,
separate and intended action (manual reset).
The manual reset function shall:
— be provided through a separate and manually operated device that is separate from start command,
— only be achieved if all affected safety functions and safeguards are operational,
— not initiate a hazardous situation by itself,
— be initiated by intended action,
— enable the control system to accept a separate start command, and
— only be accepted by monitored signal change, in order to avoid foreseeable misuse.
When the function “manual reset” is required to be a safety function (e.g. prevention of unexpected
start-up), the required performance level (PLr) shall be determined. The PL of the manual reset function
can be different from the PLr of the associated safety function.
NOTE The manual reset function often is not a separate additional safety function when the safe state is still
maintained by a safety function (safe condition), e.g. initiated by a safeguard (cover) where stepping behind is
not possible.
The reset actuator shall be located outside the hazard zone and in a position from which there is
sufficient visibility to ensure that no person is inside the hazard zone. It shall not be possible to activate
the reset function from inside the hazard zone. Where the visibility of the hazard zone is not sufficient,
a specific reset sequence or monitoring of the area that is not visible, shall be provided. When specific
reset sequence or monitoring of the area are not possible, other equivalent risk reduction measures
shall be used.
EXAMPLE One solution is the use of a sequenced resetting. The reset function is initiated within the hazard
zone by the first actuator in combination with a second reset actuator located outside the hazard zone (near
the safeguard). This reset procedure can be realized within a limited time before the control system accepts a
separate start command. Monitoring of the area can be done by, e.g. use of presence sensing devices that detect
persons in hazard zones not visible from the reset position.
A restart shall take place automatically only if the safe condition is guaranteed. In particular, for
interlocking guards with a start function, ISO 12100:2010, 6.3.3.2.5 shall apply.
EXAMPLE In automatic machine operations, sensor feedback signals to the control system are often used to
control the process flow. If a workpiece has come out of position, the process flow is stopped. If the monitoring
of the interlocked safeguard does not have a higher priority than the automatic process control, there can be
a danger of unexpected restarting of the machine while the operator readjusts the workpiece. Therefore, the
automatic restart should not to be allowed until the safeguard is closed again and the operator has left the hazard
zone. The contribution of the prevention of unexpected start-up (see ISO 14118:2017) provided by the control
system is dependent on the result of the risk assessment.
When a machine is controlled locally, e.g. by a portable control station that can be a portable device or
pendant, the following requirements shall apply:
— the means for granting local control shall be situated outside the hazard zone;
— it shall only be possible to initiate command by a local control station in a zone defined by the risk
assessment in order to avoid hazardous situations;
— switching between local and a different control shall not create a hazardous situation;
— initiation of commands from multiple control stations (local or remote) shall not lead to a hazardous
situation. It can be necessary to preclude use of other control stations when a local control station
is selected or when certain commands are initiated.
See also Table M.1.
Muting is a temporary automatic suspension of a safety function by the machine safety-related control
system. It can be used to allow access by persons or by materials:
— during a non-hazardous portion of the machine cycle, or
When safety-related parameters, e.g. position, speed, temperature, time, torque or pressure, deviate
from pre-set limits, the safety-related control system shall initiate appropriate measures.
If errors in manual inputting of safety-related data in programmable or configurable electronic systems
can lead to a hazardous situation, then a data checking measure shall be provided, e.g. check of limits,
either format or logic input values, or both. For additional requirements, see 6.3 and Table M.2.
When fluctuations in energy levels outside the designed operating range occur, including loss of energy
supply, the SRP/CS shall continue to provide or initiate output signal(s) which will enable other parts of
the machine system to maintain a safe state. See also Table M.2.
Selection of operating mode is a safety function when the selection enables or disables safety function(s).
The following is required:
a) only one operating mode shall be active at a time; each selected operating mode shall be clearly
identifiable or indicated;
b) mode selection by itself shall not initiate machine operation. A separate actuation of the start
control shall be required;
c) when changing from one operating mode to another, safety functions and/or risk reduction
measures necessary for the selected operating mode shall be activated without any loss of the
intended risk reduction during the transition;
d) the means of selecting the operating mode shall not degrade the PL of the safety functions active in
that mode.
See also Table M.1.
The design of the machine shall take into account maintenance tasks on the machine and provide
safety functions for these tasks. The results of the risk assessment for each maintenance task shall be
considered in the specification of the safety functions.
NOTE 1 Maintenance tasks can include, but are not limited to:
— setting;
— teaching/programming;
— process/tool changeover;
— sanitizing;
— troubleshooting/fault finding;
— fault diagnosis.
Some maintenance tasks require a full isolation of the machine from all power sources and therefore
do not rely on the SRP/CS. Where manual suspension or override of specific safety functions is needed
for maintenance tasks that require either power or machine movements, or both, while maintenance
personnel are inside the hazard zone, such operation shall only be allowed by providing appropriate
alternative safety functions (e.g. enabling device safety function with a speed limiting safety function).
EXAMPLE Teaching/ programming, troubleshooting, process fine-tuning are tasks requiring power and
machine movement.
The following safety functions, used singularly or in combination, are examples of what is often
provided for maintenance tasks:
a) hold-to-run;
b) enabling control;
c) monitoring or limiting of, e.g. speed, torque, power, position, location, temperature, level;
d) prevention of unexpected start-up;
e) disconnection and energy dissipation;
f) mechanical restraint or containment.
See Annex M for additional information.
The motivation to defeat or circumvent risk reduction measures provided by the SRP/CS during
maintenance of the machine shall be considered when specifying, designing and selecting the SRP/CS
(see 5.2.3).
The design of SRP/CS shall consider that additional personnel other than the intended operator(s)
perform a task, e.g.:
— an operator performs reset and restart functions while maintenance personnel are inside the
hazard zone;
— risk reduction measures intended to protect an individual are inappropriately used for multiple
personnel.
In maintenance mode, the design of the SRP/CS shall prevent a remote access (see 5.2.4) to the machine
control system without appropriate notification or indication to persons that are at or near the machine.
The motivation to defeat or circumvent a safety function depends on the process, the intended use
of the machine (or parts of the machine) and the design details of the risk reduction measure(s). The
motivation to defeat a safety function shall be minimized in the design of the SRP/CS.
NOTE 1 Safety research has shown that many injuries occur due to defeat of either safety function or
safeguards, or both. See Bibliography for more information.
EXAMPLE When designing risk reduction measures and safety functions, the following circumstances can
introduce a motivation to defeat and can be considered:
— the risk reduction measure prevents the task from being performed;
— there is a need to perform a task that was not identified and assessed for hazards and risks;
— the risk reduction measure slows down production or interferes with any other activities or preferences of
the user;
— either the risk reduction measure or its associated hazard, or both, are not recognized as such by personnel;
— the risk reduction measure is not accepted as suitable, necessary or appropriate for its function;
— unlimited access to the SRP/CS hardware and software systems which implement the safety functions.
NOTE 2 Providing means to perform tasks easily whilst protecting operators can lessen the motivation to
defeat or circumvent safety function(s) and/or safeguard(s).
NOTE 3 ISO 14119 gives a method and shows examples on how to minimize possibilities to defeat an
interlocking device.
The use and access to programmable systems introduces an additional possibility to defeat or
circumvent safety functions if not properly applied or supervised.
When the machine control system can be accessed remotely, the SRP/CS shall remain operational.
Additional risk reduction measures can be used when provided in the information for use.
The design of the SRP/CS shall only allow remote access of a machine when specific measures are in
place to prevent dangerous situations that can arise due to the undetected presence of persons being
inside or near to the machine (e.g. see 5.2.2.2).
Safety-related software of the SRP/CS shall not be modifiable by remote access unless the local
validation of the safety function is performed.
NOTE A remote start that is unexpected to persons working at the machine can lead to injury.
5.3 Determination of required performance level (PLr) for each safety function
For each selected safety function, a required performance level (PLr) shall be determined and
documented. The determination of the PLr shall be based on the result of the risk assessment and shall
correlate to the needed risk reduction (see Figure 3). Annex A provides guidance for the determination
of the PLr for the safety function. Overlapping hazards, if relevant, shall also be considered when
defining the safety functions. See A.3 for further guidance.
NOTE 1 Other methods for the determination of PLr can be used (e.g. the method in IEC 62061:2021, Annex A).
NOTE 3 As the methodology for determining PLr includes subjective estimations, some variability is acceptable
in the practical application of particular cases.
NOTE 4 The PLr for a safety function determines the required reliability of the control system to execute the
safety function and to achieve the intended risk reduction. The PLr is determined using several factors of risk.
See also Annex A.
NOTE 1 Safety function 1 is decomposed into sub-function 1, sub-function 2 and sub-function 3. Sub-function
1 is performed by subsystem 1, etc.
NOTE 2 Safety function 2 is decomposed into sub-function 4 and sub-function 5. Sub-function 4 is performed
by subsystem 4, etc.
NOTE 3 Safety function 3 is decomposed into sub-function 6 and sub-function 5. Sub-function 6 is performed
by subsystem 6, etc.
NOTE 5 One subsystem or SRP/CS can implement safety functions and standard control functions. The
designer can use any of the technologies available, single or in combination. SRP/CS can also provide an
operational function (e.g. an AOPD as a means of cycle initiation).
The designer of a previously validated subsystem shall provide the relevant information according to
13.2.
NOTE 6 The designer of a previously validated subsystem can be a system integrator, machine manufacturer
or a component manufacturer.
6 Design considerations
The ability to perform a safety function is determined by the evaluation of the performance level.
A performance level shall be determined for either each subsystem or each combination of subsystems,
or both, that perform a safety function. The PL of the subsystem shall be determined by the estimation
of the following aspects:
a) the architecture (see 6.1.3);
1) assign a category to the subsystem;
2) evaluate if the applicable qualitative (non-quantifiable) requirements of the category are met,
including:
— basic safety principles (ISO 13849-2:2012, Tables A.1, B.1, C.1 and D.1);
— well-tried safety principles (ISO 13849-2:2012, Tables A.2, B.2, C.2 and D.2);
— well-tried components (ISO 13849-2:2012, Tables A.3 and D.3, Annexes B and C);
3) evaluate that required behaviour under fault condition(s) is met;
b) the MTTFD value for single components (see 6.1.4, and Annexes C and D);
NOTE 2 For safety-related values of components or parts of control systems see Annex O.
These aspects can be grouped under two approaches in relation to the evaluation process:
— quantifiable aspects (MTTFD value for single components, DC, CCF, architecture);
— non-quantifiable, qualitative aspects which affect the behaviour of the subsystem (behaviour of the
safety function under fault conditions, safety-related software, systematic failure, the application of
basic and well-tried safety principles, the use of well-tried components, environmental conditions
and fault exclusion).
NOTE 3 The contribution of reliability (e.g. MTTFD, architecture) can vary with the SRP/CS used.
NOTE 4 There are several methods for estimating the quantifiable aspects of the PL for any type of system
(e.g. a complex structure), for example, Markov modelling, generalized stochastic petri nets (GSPN), reliability
block diagrams (see, e.g. the IEC 61508 series, IEC 61078, the IEC 62021 series).
To make the assessment of the PL easier, this document provides a simplified method based on the
definition of five designated architectures that fulfil specific design criteria and behaviour under a fault
condition (see 6.1.3).
For PL evaluation of a subsystem the requirements are given in 6.1. A simplified approach for the PL
evaluation of a subsystem is given in 6.1.8 (Figure 12) and 6.1.9, using the procedure given in Annexes B
to Annex H, Annex J, Annex K and Annex L. For PL evaluation of subsystem combinations see 6.2.
Qualitative aspects of the PL and the avoidance of systematic failures shall be achieved by fulfilling the
requirements and guidance of this document. See 6.1.7 for systematic failure and guidance in Annex G.
Where product-specific standards such as the IEC 61496 series for electro-sensitive protective
equipment (ESPE) or the ISO 13856 series for pressure-sensitive protective equipment, specify
requirements to avoid or control systematic or random failures, such subsystems shall meet the
requirements of these product standards in addition to the requirements specified in this document.
Risk reduction measures shall be applied and the following shall be fulfilled:
— Reduce the probability of faults at the component level which affect the safety function. This can be
done by increasing the reliability of components, e.g. by selection of either well-tried components
or applying well-tried safety principles, or both, in order to minimize or exclude critical faults or
failures (see also ISO 13849-2:2012).
— Improve the architecture of the subsystem to avoid the dangerous effect of a fault. Some faults can
require detection, thereby necessitating an either redundant or monitored architecture, or both.
Reducing the probability of faults and avoiding dangerous effects of faults can be applied separately or
in combination. Depending on the technologies, this can be achieved by
— selecting reliable components and by fault exclusions; or
— the safety function having either a redundant or monitored architecture system, or both.
The structure including fault tolerance and fault detection are important parameters to determine
the PL. Architectural constraints limit the maximum achievable PL of category B, 1 and 2. For these
architectural constraints, see 6.1.3.2.2 to 6.1.3.2.4.
Requirements to prevent or avoid CCFs shall be fulfilled.
For subsystems that have PL or SIL and PFH values from the manufacturer, further estimation (e.g. DC,
MTTFD, CCF, SRESW evaluation) is unnecessary. See also Table O.1.
6.1.2 Correlation between performance level (PL) and safety integrity level (SIL)
When a safety function is designed using one or more subsystems, each subsystem shall be designed
either using PLs according to this document, or using SILs according to IEC 62061:2021 or the
IEC 61508 series. Subsystems designed according to the IEC 61508 series or IEC 62061:2021 may be
used but shall be restricted to those designed for high demand or continuous mode that use Route 1H
(see IEC 61508-2:2010, 7.4.4.2). Subsystems shall be combined according to 6.2. See Table 4 for
correlations between PLs and SILs.
Table 4 — Correlation between performance level (PL) and safety integrity level (SIL)
SIL
PL
(see IEC 62061:2021 for information) high/continuous operating mode
a no correlation
b 1
c 1
d 2
e 3
NOTE 1 PL a has no correlation on the SIL scale and is mainly used to reduce the risk of slight, normally reversible, injury.
NOTE 2 PL e corresponds to SIL 3 which is defined as the highest level typically used for machinery.
6.1.3 Architecture — Categories and their relation to MTTFD of each channel, average
diagnostic coverage and common cause failure (CCF)
6.1.3.1 General
Subsystems designed according to this document shall be in accordance with the requirements of one
of the categories specified in 6.1.3.2. The categories are fundamental to achieving a specific PL. They
describe the required behaviour of the subsystem in respect to its resistance to faults based on the
design considerations described in 6.1.1.
Category B is the basic category. The occurrence of a fault can lead to the loss of the safety function. In
category 1, improved resistance to faults is achieved predominantly by using high quality components.
In categories 2, 3 and 4, improved performance is achieved predominantly by improving either fault
tolerance or diagnostic measures, or both. In category 2 this is provided by periodically checking that
the specified sub-function is being performed correctly (without faults). In categories 3 and 4, this is
provided by ensuring that the single fault does not lead to the loss of the sub-function. In category 4,
and whenever reasonably practicable in category 3, such faults are detected. Category 4 is resistant to
accumulation of faults. Table 5 gives an overview of categories of the subsystem, the requirements and
the sub-function behaviour in case of faults.
When considering the causes of failures in some components it is possible to exclude certain faults (see
6.1.10.3).
Table 5 (continued)
MTTFD
Principle used of each
Summary of require- Sub-function be-
Category to achieve func- DCavg CCF
ments for subsystems haviour
safety tional
channel
4 Requirements of B and the When a single fault Mainly char- High High See
use of well-tried safety occurs, the sub-func- acterized by including Annex F
(see
principles shall apply. tion is always per- structure (re- accumu-
6.1.3.2.6)
formed. dundancy) lation of
Subsystem shall be de-
faults
signed, so that Detection of accu-
— a single fault in any of mulated faults re-
these parts does not duces the probabil-
lead to a loss of the ity of the loss of the
sub-function, and sub-function (high
DC).
— the single fault is The faults will be
detected at or before detected in time to
the next demand upon prevent the loss of
the sub-function, the sub-function.
but if this detection
is not possible, an
accumulation of
undetected faults shall
not lead to the loss of
the sub-function.
NOTE For full requirements, see 6.1.3.2.
6.1.3.2.1 General
The following designated architectures meet the requirements of the respective category.
The designated architectures show a logical representation of the structure of the subsystems for each
category.
NOTE 1 For categories 3 and 4 not all parts are necessarily physically redundant but there are redundant
means of assuring that a single fault cannot lead to the loss of the sub-function. Therefore, the technical
realization (for example, the circuit diagram) can differ from the logical representation of the architecture.
Figure 7 to Figure 11 do not show examples but general designated architectures. A deviation from
these architectures is always possible, but any deviation shall be justified, by means of appropriate
analytical tools, e.g. Markov modelling, fault tree analysis (FTA), such that the subsystem meets the
required performance level (PLr). For a subsystem that deviates from the designated architectures, a
detailed calculation shall be provided to demonstrate the achievement of the PLr.
The lines and arrows in Figure 7 to Figure 11 represent logical interconnecting means and, where
applicable, diagnostic means.
NOTE 2 The structure of a subsystem is a key characteristic having great influence on the PL. Even if the
variety of possible structures is high, the basic concepts are often similar. Thus, most structures that are present
in the machinery field can be mapped to one of the categories. For each category, a typical representation as a
safety-related block diagram can be made. These typical realizations are called designated architectures and are
listed in the context of each of the following categories.
If the simplified procedure of 6.1.8 is used to estimate the PL, the architecture of the subsystem shall be
equivalent to the designated architecture of the claimed category.
6.1.3.2.2 Category B
NOTE 2 When a fault occurs it can lead to the loss of the sub-function.
Specific requirements for EMI (immunity requirements) are found in the relevant product or generic
standards. Immunity requirements are particularly relevant for subsystems. Subsystems containing
active electronic components shall meet EMI immunity requirements based on the environment as
appropriate. For practical guidance see Annex L.
Key
im interconnecting means
I input device, e.g. sensor
L logic
O output device, e.g. main contactor
6.1.3.2.3 Category 1
For category 1, the same requirements as those according to 6.1.3.2.2 for category B shall apply. In
addition, the following applies.
Subsystems of category 1 shall be designed and constructed using well-tried components according to
6.1.11 and well-tried safety principles (see 3.1.49 and ISO 13849-2:2012). The MTTFD of the channel
shall be high.
NOTE 1 There is no average diagnostic coverage (DCavg = none) within category 1 architectures. In such
structures (single-channel architectures) the consideration of CCF is not relevant.
Key
im interconnecting means
I input device, e.g. sensor
L logic
O output device, e.g. main contactor
6.1.3.2.4 Category 2
For category 2, the same requirements as those according to 6.1.3.2.2 for category B shall apply. “Well–
tried safety principles” according to 3.1.49 and ISO 13849-2:2012 shall also be followed. In addition, the
following applies.
Subsystems of category 2 shall be designed so that their functional channel (I, L, O) is tested at suitable
intervals. The test of the sub-function(s) shall be performed before or at least at the demand of the
safety function prior to any hazardous situation, e.g.:
a) prior to the start of a new cycle;
b) prior to the start of other movements;
c) immediately upon demand of the safety function;
d) periodically during operation if the risk assessment and the kind of operation shows that it is
necessary.
The test itself shall not lead to a hazardous situation (e.g. due to an increase in response time). The
test equipment may be integral with, or separate from, the safety-related part(s) providing the safety
function.
Based on the risk assessment of the machine or part of it, the initiation of this test may be manual. Any
test of the sub-function(s) shall either
— allow operation if no faults have been detected, or
— generate an output [output of the test equipment (OTE)] that initiates appropriate control action, if
a fault is detected.
For PLr d the OTE shall initiate a safe state that is maintained until the fault is cleared.
For PLr up to and including PLr c, whenever practicable the output (OTE) shall initiate a safe state that is
maintained until the fault is cleared. When this is not practicable (e.g. welding of the contact in the final
switching device) it may be sufficient for the OTE to provide a warning.
The calculation of DCavg shall take into account only the blocks of the functional channel (i.e. I, L and O
in Figure 9) and not the blocks of the testing channel.
For category 2, the following shall be applied:
— demand rate ≤ 0,01 test rate (see Table K.1, NOTE 1); or testing occurs immediately upon demand
of the safety function and the overall time to detect the fault and to bring the machine to a non-
hazardous condition (usually to stop the machine) is shorter than the time to reach the hazard (see
also ISO 13855:2010).
— MTTFD of the testing channel (TE and OTE in Figure 9) is greater than one half of MTTFD of the
functional channel.
The DC of all parts of the functional channel (I, L, O) shall be at least low. The MTTFD of the functional
channel shall be low-to-high, depending on the required performance level (PLr). Measures against CCF
of the functional channel and the testing channel shall be applied (see 6.1.6 and Annex F).
The maximum PL achievable with category 2 is PL d.
NOTE 1 The test of the blocks in the functional channel can be realized by, e.g. monitoring.
— the occurrence of a fault leading to the loss of the sub-function between tests, and
NOTE 3 The principle that supports the validity of a category 2 function is that the adopted technical
provisions, and, for example, the choice of test rate and reliability of the test equipment, can decrease the
probability of occurrence of a dangerous fault.
Key
im interconnecting means O output device, e.g. main contactor
I input device, e.g. sensor TE test equipment
L logic OTE output of TE
m monitoring/testing
The dashed lines represent reasonably practicable fault detection.
6.1.3.2.5 Category 3
For category 3, the same requirements as those according to 6.1.3.2.2 for category B shall apply. Well-
tried safety principles according to 3.1.49 and ISO 13849-2:2012 shall also be followed. In addition, the
following applies.
The maximum PL achievable with category 3 is PL e.
Subsystems of category 3 shall be designed so that a single fault does not lead to the loss of the sub-
function. Whenever reasonably practicable, the single fault shall be detected at or before the next
demand upon the safety function.
The DC of the total subsystem shall be at least low. The MTTFD of each of the redundant channels shall
be low-to-high, depending on the PLr. Measures against CCF shall be applied (see Annex F).
NOTE 1 The requirement of single-fault detection does not mean that all faults will be detected. Consequently,
the accumulation of undetected faults can lead to an unintended output and a hazardous situation at the machine.
Typical examples of practicable measures for fault detection are use of the feedback of mechanically guided relay
contacts and monitoring of redundant electrical outputs (see Annex E).
NOTE 2 If necessary, because of technology and application, type-C standard makers can give further details
on the detection of faults.
Key
im interconnecting means L1, L2 logic
c cross monitoring m monitoring
I1, I2 input device, e.g. sensor O1, O2 output device, e.g. main contactor or drive system
The dashed lines represent reasonably practicable fault detection.
6.1.3.2.6 Category 4
For category 4, the same requirements as those according to 6.1.3.2.2 for category B shall apply. Well-
tried safety principles according to 3.1.49 and ISO 13849-2:2012 shall also be followed. In addition, the
following applies.
The maximum PL achievable with category 4 is PL e. Subsystem of category 4 shall be designed such
that
— a single fault does not lead to a loss of the safety function, and
— the single fault is detected at or before the next demand upon the safety functions, e.g. immediately,
at switch on, or at the end of a machine operating cycle but if this detection is not possible, then an
accumulation of undetected faults shall not lead to the loss of the safety function.
NOTE 1 Based on an analysis, e.g. FMEA, undetected failures with a very low probability do not need to be
considered for accumulation of faults if this is documented and verified.
The average diagnostic coverage (DCavg) of the total subsystem shall be high. The MTTFD of each of the
redundant channels shall be high. Measures against CCF shall be applied (see Annex F).
NOTE 2 Category 4 system behaviour is characterized by
— detection of faults in time to prevent the loss of the safety function, and
NOTE 3 The difference between category 3 and category 4 is a higher DCavg in category 4 and a required
MTTFD of each channel of “high” only.
Key
im interconnecting means L1, L2 logic
c cross monitoring m monitoring
I1, I2 input device, e.g. sensor O1, O2 output device, e.g. main contactor or drive system
Solid lines for monitoring (m) represent DC that is higher than in the designated architecture for category 3.
The mean time to dangerous failure (MTTFD) is a quantity with the dimension of time to characterize
the basic reliability of the components used. Given a constant dangerous failure rate, the MTTFD is
reciprocal of the dangerous failure rate (e.g. with failures in 109 hours converted into years between
failures).
For the estimation of MTTFD of a component, the order of priorities is:
a) use manufacturer’s data;
NOTE 1 When MTTFD data of components (e.g. electromechanical components) are provided by the
manufacturer, the number of operations indicated by the manufacturer is considered so that the number of
operations in the real application is not higher than the number of operations indicated by the manufacturer.
d) choose 10 years.
Annex C gives practical guidance on how to calculate or evaluate MTTFD values for single components.
Annex D describes how to derive the MTTFD of each channel from this, including parts-count method
and symmetrisation.
For each subsystem according to Table 5, the maximum value of MTTFD for each channel is limited
to 100 years. For category 4 subsystems, the maximum value of MTTFD for each channel is limited to
2 500 years.
NOTE 3 This higher value is justified because in category 4 the other quantifiable aspects, structure and DC,
are at their maximum point and this allows the series combination of more than 3 subsystems with category 4 to
achieve PL e in accordance with 6.2.
The value of the MTTFD of each channel is given in three levels (see Table 6) and shall be taken into
account for each channel (e.g. single channel, each channel of a redundant system) individually.
Diagnostic coverage (DC) is determined as the ratio between rate of detected dangerous failures and
the rate of total dangerous failures. DC shall be considered in categories 2, 3 and 4.
∑ λDD
DC = (1)
∑ λDtotal
where
DC shall be based on either failure modes and effects analysis (FMEA) (see IEC 60812:2018), or by
using simplified estimation of DC based on E.1 and Table E.1. E.2 describes how the average diagnostic
coverage (DCavg) can be estimated.
NOTE 1 For the estimation of DC, in most cases, FMEA (see IEC 60812 and EN 50495:2010, Annex B) or similar
methods can be used to consider either all relevant faults or failure modes, or both. See also ISO 13849-2:2012,
E.5.3.
NOTE 2 Often logic units take care of diagnostic functions of input and output device.
NOTE 3 The used technology will influence the possibilities for the implementation of fault detection.
The probability of two or more separate faults having a common cause shall be taken into account for
subsystems of category 2, 3 and 4. In category 2 CCF refers to common cause failures in the functional
channel and the testing channel. In category 3 and 4, CCF refers to common cause failures in both
functional channels. Sufficient measures against CCF shall be carried out (for guidance, see Annex F).
In the design process especially, control and avoidance of systematic failures shall be implemented (see
Clause 10 and Annex G).
6.1.8 Simplified procedure for estimating the performance level for subsystems
This subclause describes a simplified procedure for estimating the PL of a subsystem based on
designated architectures. Other architectures may be mapped to these designated architectures in
order to obtain an estimation of the PL (see 6.1.1).
The designated architectures are represented as block diagrams and are listed in the context of each
category in 6.1.3.2. Information about the block method and the safety-related block diagrams are given
in 6.1.3.2 and Annex B. See also IEC 61078:2016.
A designated architecture is always assigned to a subsystem. In case the SRP/CS consists of one
subsystem, the designated architecture will be the same for the entire SRP/CS. In case the SRP/CS
consists of multiple subsystems, every subsystem shall be assigned a designated architecture, so a
single SRP/CS can comprise multiple architectures.
The simplified approach is based on:
a) mission time (T M), 20 years (see 3.1.36);
b) constant failure rates within the mission time;
c) sufficient measures to prevent CCF have been applied (beta factor of 2 %). For guidance see Annex F
or IEC 61508-6:2010, Annex D.
NOTE The mission time (T M) is assumed to be 20 years, within which the component reliability by constant
failure rates can be described or approximated. This is generally accomplished in electronic subsystems. The
SRP/CS is replaced when the mission time has been reached or equivalent measures are performed to ensure
that the estimated PL is still valid.
In order to claim a mission time of 20 years, the requirements according to 6.1.3.2.2 for Category B shall
be observed. The actual mission time may be less than 20 years when using components which wear
out sooner or for other technical reasons which should be documented. See also C.4.
The methodology considers the categories as architectures with defined DCavg. The PL of each
subsystem depends on the architecture, the MTTFD in each channel and the DCavg.
For a subsystem with software, the requirements of Clause 7 shall be applied. The combination of
several subsystems is considered in 6.2.
Figure 12 shows which selection of categories in combination with the MTTFD of each channel and
DCavg is able to achieve the PL. For the estimation of the PL, Figure 12 gives the different possible
combinations of category with DCavg (horizontal axis) and the MTTFD of each channel (columns). The
columns in the diagram represent the three MTTFD ranges of each channel (low, medium and high)
which can be selected to achieve the required PL.
Before using this simplified approach with Figure 12 (which represents results of different Markov
models based on designated architectures of 6.1.3), the category of the subsystem (see 6.1.3.2) as well
as DCavg (see 6.1.5) and the MTTFD of each channel (see 6.1.4) shall be determined (see Annex C to
Annex E). For categories 2, 3 and 4, sufficient measures against CCF shall be carried out (for guidance,
see 6.1.6 and Annex F). Taking these parameters into account, Figure 12 provides a graphical method
for determining the PL, achieved by the subsystem. The combination of category (including CCF) and
DCavg determines which column of Figure 12 is to be chosen. According to the MTTFD of each channel,
one of the three different shaded areas of the relevant column shall be chosen.
The vertical bands in Figure 12 show the range of performance that can be expected from each
combination of MTTFD, Category and DCavg. Finding the appropriate ranges for each of these variables
in the bands in the Figure 12 and then reading across to the vertical axis will indicate the PL that can be
achieved with this combination. For a more precise numerical selection of PL depending on the precise
value of MTTFD of each channel, see Annex K.
A detailed example of this simplified procedure for estimating the performance level for subsystems is
shown in Annex I.
Key
PFH average frequency of dangerous failure per hour
PL performance level
6.1.9 Alternative procedure to determine the performance level and PFH without MTTFD
6.1.9.1 General
The alternative procedure to determine the PL without MTTFD is limited to subsystems incorporating
mechanical, hydraulic, pneumatic, electrohydraulic or electropneumatic components where no
reliability data is available and where the good engineering practice method given in C.2 cannot be
applied. In that case, the machine manufacturer may use the alternative procedure described in 6.1.9.2
to 6.1.9.4 to evaluate the PL without any MTTFD calculation.
The combination of several subsystems is considered in 6.2.
6.1.9.2 Preconditions
Table 8 shows the relationship between achievable PL (corresponding to Figure 12) and categories. PL a
and PL b can be implemented with Cat. B if basic safety principles are followed. PL c can be implemented
with Cat. 1 or Cat. 2, if well-tried components, basic and well-tried safety principles are used.
PL d can be implemented with Cat. 3, respectively PL e with Cat. 4, if well-tried components, basic and
well-tried safety principles are used.
Table 8 — Performance level and PFH estimation based on category and component selection
Estimated PFH
Categorya Additional requirements Achievable PLb
(1/h)
B → 5,0 × 10−6 b
1 → 1,7 × 10-6 c
2 Only well-tried components are used → 1,7 × 10-6 c
3 Only well-tried components are used → 2,9 × 10−7 d
4 Only well-tried components are used → 4,7 × 10−8 e
a All requirements in 6.1.3.2.2 to 6.1.3.2.6 for the respective category shall be fulfilled, except MTTFD.
b The achievable PL mentioned here only covers quantifiable aspects. Additional requirements for non-quantifiable
aspects such as systematic failure and software (see 6.1.1) shall be fulfilled.
Where no MTTFD data is available a conservative approach using estimated MTTFD can be assumed.
— For category B, 2 and 3 MTTFD for each channel is 10 years.
— For category 1 a MTTFD of the channel of 30 years can be assumed since well-tried components shall
be used (see 6.1.3.2.3).
The maximum PL that can be achieved is PL c (see Annex K).
For category 2 and category 3 common-cause failures and DC shall be considered. The DCavg shall match
at least 60 % for category 2 and category 3.
Category 4 is excluded in this method.
With the category, the MTTFD and the DCavg , the PL and the PFH of the subsystem can be determined
with Table K.1.
6.1.10.1 General
When designing safety subsystems, faults and their effects shall be assessed. Each element, whose fault
may cause the failure of the safety function in one of the functional channels of a subsystem, shall be
considered. The designer shall make a list of faults, which can occur in the SRP/CS. This list shall include
all considered faults, explanation how these faults have been noted in the design, and if fault exclusion
is claimed to give reasons for these exclusions. For subsystems pre-validated by the component
manufacturer, it is not necessary by the designer of the safety functions to take into account internal
failures of the component(s), only failures of the interfaces.
NOTE Faults of elements, which are not directly necessary for the execution of the safety function, but which
can support it (e.g. filter elements, protection against over-voltage), generally do not contribute to the MTTFD of
each channel.
ISO 13849-2:2012 lists the important faults and failures for the various technologies. The lists of
faults are not exhaustive and, if necessary, additional faults shall be considered and listed. In such
cases, the method of evaluation shall also be clearly elaborated. For components not mentioned
in ISO 13849-2:2012, a methodology to evaluate the impact of either probable faults or failures of
components, or both, shall be carried out, e.g. FMEA (see IEC 60812), aiming at the identification of
faults that are to be considered for those components.
In general, the following fault criteria shall be taken into account:
— if, as a consequence of a fault, further components fail, the first fault together with all following
faults shall be considered as a single fault;
— the simultaneous occurrence of two or more faults having separate causes is considered highly
unlikely and therefore needs not be considered.
Two or more separate faults having a common cause shall be considered as a CCF (see Annex F).
It can be necessary to exclude faults in order to evaluate subsystems. Fault exclusion is a compromise
between technical safety requirements and the theoretical possibility of occurrence of a fault.
Fault exclusion can be based on
a) the technical improbability of occurrence of some faults,
b) generally accepted technical experience, independent of the considered application, and
c) technical requirements related to the application and the specific hazard.
Fault exclusion is only applicable for certain failures of an element and it is up to the designer
(manufacturer or integrator) to prove the exclusion of the respective faults based on the limits
set forward by the design and use. Such fault exclusion is only possible provided that their unlikely
occurrence can be justified based on the known laws of physical science. Any such fault exclusions shall
be justified and documented.
The application of fault exclusion to certain faults for an element inside a subsystem does not limit the
necessity of applying measures against systematic failures.
It is possible that some faults are excluded by the manufacturer and some by the subsystem integrator.
There shall be a specific characterization of the type of fault that is excluded. It would not be acceptable
to state simply that a component will not break, distort or degrade due to wear. It is necessary to state
the direct influence under which the component will not break, distort or degrade due to wear. For
example, the component will have no faults when subjected to a force of X Newtons from direction Y.
The fault exclusion shall be justifiable under all expected environmental conditions including
temperature, pressure, vibration, pollution, corrosive atmosphere.
PL e shall not depend solely on fault exclusion.
NOTE 1 Information on fault exclusions is available in ISO 13849-2:2012, Annexes A to D.
6.2.1 General
An SRP/CS may be realized using a combination of subsystems and an overall PL may be achieved using
the methods described in this subclause. In this case, the validation of the combination of subsystems as
an SRP/CS is required (see Figure 13). These subsystems may be assigned to one or different categories.
According to 6.1.3.2, the combination of subsystems to an SRP/CS starts at the points where the safety-
related signals are initiated and ends at the output of the power control elements. The combined
subsystems can consist of several parts connected in a linear (series alignment) way. To avoid a new
complex estimation of the performance level (PL) achieved by combined subsystems where the separate
PLs of all parts are already calculated, the following estimations are presented for a combination of
subsystems.
If previously validated subsystems according to IEC 62061:2021 or the IEC 61508 series (SIL) for high
demand or continuous mode that use Route 1H (see IEC 61508-2:2010, 7.4.4.2) are used, the SIL can
be correlated to a PL using 6.1.2 and 6.2.2. PFH values calculated according to the IEC 61508 series or
IEC 62061:2021 with the above-mentioned limitations can be considered as PFH values according to
this document.
Category cannot always be deduced and is not required from a subsystem validated according to
IEC 62061:2021 or the IEC 61508 series.
When combining subsystems with known PFH values, the PFH values can be combined as shown
below assuming that there are n separate subsystems SB1 to SBn. These subsystems operate in a
series combination, which as a whole performs a safety function. For each SBi, a PLi has already been
evaluated. This situation is illustrated in Figure 13 (see also Figure 5 and Figure H.2).
If the PFH values of all subsystemss are known, then the PFH of the SRP/CS is the sum of all PFH values
of the n individual subsystem. The PL of the SRP/CS is limited by:
— the lowest PL of any individual subsystem involved in performing the safety function, and
— the PL corresponding to the PFH of the combined SRP/CS according to Table 2.
NOTE See Annex H for an example of this method.
If the PFH values of all individual SBi are not known, then as an alternative to 6.2.2, the PL of the SRP/CS
performing the safety function may be defined according to 6.1 or calculated using Table 9 as follows:
a) Identify the lowest PL of all subsystems: this is PLlow;
b) Identify the number of subsystems with PLlow: this number is Nlow;
c) Look-up PL in Table 9.
6.3.1 General
This subclause is limited in scope to only manual, software based parameterization that is performed
and controlled by an authorized person. See also 5.2.2.6 and Table M.2.
Some safety-related subsystems or SRP/CS need parameterization for a safety function or a sub-
function.
EXAMPLE A converter with integrated sub-functions can be parameterized via a PC-based configuration
tool for setting the upper speed limit parameter. To establish the detection zone of a laser scanner, parameters
such as angle and distance can be configured per the manufacturer’s safety documentation and the machine risk
assessment.
The objective of the requirements for software based manual parameterization is to guarantee that the
safety-related parameters specified for a safety function or a sub-function are correctly transferred
into the hardware performing the safety function or a sub-function. Different methods can be applied
to set such parameters, such as dip-switch based parameterization or dedicated parameterization
software (commonly called configuration or parameterization tools).
NOTE 1 Safety-related parameterization which is carried out automatically without human interaction, for
example, based on input signals, is not considered in this subclause.
NOTE 2 Direct control of a machine by an operator, e.g. speed control of a forklift truck, is not considered as
manual parameterization as described in this subclause.
If the configuration or parameterization tool is pre-designed in accordance with this document or the
IEC 61508 series, for example together with its dedicated subsystem, it is assumed that there will be
no dangerous failures due to the influences listed in 6.3.2 or any other influence that is reasonably
foreseeable. The requirements of 6.3.5 apply when a software based manual parameterization is
performed with the pre-designed tool.
If a safety-related subsystem or SRP/CS is not capable of being parameterized by software based
manual parameterization as described above, 6.3 does not apply.
Software based manual parameterization shall use a dedicated tool provided by the manufacturer or
supplier of the SRP/CS or the related subsystem(s). The SRP/CS or the related subsystem(s) and the
parameterization tool shall have the capability to prevent unauthorized modification, for example by
using a dedicated password.
Parameterization while the machine is running shall be permitted only if it does not cause an unsafe
state.
It is possible to fulfil the requirements by using a pre-designed subsystem.
When using a pre-designed SRP/CS or subsystem that is capable of software based manual
parameterization, the target is to prevent dangerous failure due to the influences listed in 6.3.2 or
any other influence that is reasonably foreseeable. The validation of the pre-designed subsystem shall
include the issue of parameterization.
When an SRP/CS or subsystem that is capable of software based manual parameterization is designed
according to this document there shall be no undetected dangerous failure due to the influences listed
above or any other influence that is reasonably foreseeable. The following requirements shall be
fulfilled in addition:
a) The design of the software based manual parameterization shall be considered as a safety-related
aspect of SRP/CS design that is described in an SRS.
b) The SRP/CS or subsystem shall provide means to check the data plausibility, e.g. checks of data
limits, format and/or logic input values.
c) The integrity of all data used for parameterization shall be maintained. This shall be achieved by
applying measures to:
1) control the range of configured values by a validity (range) check;
2) control data corruption before transmission;
3) control the effects of errors from the parameter transmission process;
4) control the effects of incomplete parameter transmission;
5) control the effects of faults and failures of hardware and software of the parameterization;
6) control the effect of the interruption of the power supply.
d) The parameterization tool shall fulfil all relevant requirements for SRP/CS according to this
document or the IEC 61508 series.
e) Alternatively to d), a special procedure shall be used for setting the safety-related parameters. This
procedure shall include confirmation of input parameters to the SRP/CS by either:
— retransmitting of modified parameters to the parameterization tool; or
— other means to confirm the integrity of the parameters;
— as well as subsequent confirmation, for example by a suitably skilled person and by means of an
automatic check by a parameterization tool. New values of safety-related parameters shall not
be used for safety-related operation before the changes are acknowledged and confirmed.
NOTE This is of particular importance where a parameterization software tool uses a device not specifically
intended for this purpose (e.g. personal computer or equivalent).
The software modules used for encoding/decoding within the transmission/retransmission process
and software modules used for visualization of the safety-related parameters to the user shall, as a
minimum, use diversity in function(s) to avoid systematic failures.
The following verification activities shall be performed to verify the basic functionality of the
parameterization tool:
— verification of the correct setting for each safety-related parameter (minimum, maximum and
representative values);
— verification that the safety-related parameters are checked for plausibility, for example by detection
of invalid values;
— verification that means are provided to prevent unauthorized modification of safety-related
parameters.
NOTE This is of particular importance where the parameterization is carried out using a device not
specifically intended for this purpose (e.g. personal computer or equivalent).
Software based manual parameterization shall be carried out using the dedicated parameterization
tool provided by the manufacturer or supplier of the SRP/CS or the related subsystem(s) and shall
be documented according to the requirements given in the information for use. This information can
originate from different parties, see also Clause 13 (information for use). Protective measures against
unauthorized access shall be activated and used.
The initial parameterization, and subsequent modifications to the parameterization, shall be
documented. The documentation shall include:
a) the date of initial parameterization or change;
b) data or version number of the data set;
c) name of the person carrying out the parameterization;
d) an indication of the origin of the data used (e.g. pre-defined parameter sets);
e) clear identification of safety-related parameters;
f) effects and boundaries for cases where parameterization is possible or needed on a continuous
basis;
g) clear identification of the SRP/CS or associated subsystem which is subject to specific
parameterization settings.
7.1 General
Although artificial intelligence (AI) can be used for SRP/CS, this clause does not address additional
specific requirements necessary for AI technology and its use as part of SRP/CS.
Activities related to the development of safety-related embedded or application software shall primarily
consider the avoidance of faults during the software lifecycle [see Figure 14 a)]. The main objective of
the following requirements is to have readable, understandable, testable and maintainable software.
NOTE 1 Annex J gives more detailed recommendations for lifecycle activities.
NOTE 2 Annex N gives an overview of measures which apply to SRASW performed by usage of LVL and SRASW
or SRESW performed by usage of FVL.
If pre-assessed safety-related hardware and software modules are used in combination with LVL, a sim-
plified software lifecycle shown in Figure 14 b) is applicable.
b) Simplified V-model for software if pre-assessed safety-related hardware and software mod-
ules are used in combination with LVL
Key
result
verification
NOTE Typically, the simplified software lifecycle, shown in Figure 14 b), applies to the use of module-based
programming in LVL, that only require simple interconnections to be configured, which limits the inputs and
outputs to a pre-defined set of values, including a combination of modules.
When safety and non-safety functions are implemented in the same hardware environment, it shall
be demonstrated that the safety functions are not impacted by the non-safety functions under normal
or fault conditions, e.g. which may include, but is not limited to, blocking or delaying a safety response
which is required to be performed at any time.
7.2 Limited variability language (LVL) and full variability language (FVL)
LVL is a software programming language, whose notation is textual or graphical or has characteristics
of both, for commercial and industrial programmable electronic controllers with a range of capabilities
limited to their application (see IEC 61508-4:2010, 3.2.14).
LVL should be designed to be easily understandable by the software designer and should be stringently
focused on the applications to be implemented.
The following are examples of LVLs:
a) ladder diagram (see IEC 61131-3:2013, 8.2): a graphical language consisting of a series of input
symbols (representing behaviour similar to devices such as normally open and normally closed
contacts) interconnected by lines (to indicate the flow of current) to output symbols (representing
behaviour similar to relays);
b) Function block diagram (see IEC 61131-3:2013, 8.3): in addition to Boolean operators, allows the
use of more complex functions such as data transfer file, block transfer read/write, shift register
and sequencer instructions;
c) Sequential function chart (see IEC 61131-3:2013, 6.7): a graphical representation of a sequential
program consisting of interconnected steps, actions and directed links with transition conditions;
d) Boolean algebra: a low-level language based on Boolean operators such as AND, OR and NOT with
the ability to add some mnemonic instructions.
This type of language is designed for computer programmers and provides the capabilities to implement
a wide variety of functions and applications. This type of language offers all possible programming
options and can be used to create an application program with full flexibility in how the logic is
constructed.
NOTE Typical examples of systems using FVL are general purpose computers.
In the machinery sector, FVL is found in embedded software and rarely in application software.
EXAMPLE Ada, C, Pascal, Instruction List, assembler languages, C++, Java, MATLAB, Simulink, ST and SQL
(without limitations for use and full variety of instructions).
7.2.3 Decision for limited variability language (LVL) or full variability language (FVL)
In general, software can be written in FVL or LVL. The designer of the SRP/CS shall follow Figure 15 for
the determination, if a programming language is FVL or LVL.
EXAMPLE 1 If language C is used there is no accordance with IEC 61131-3 and if any of the questions 2.1 to 2.4
in Figure 15 are answered with no, the result will be FVL.
EXAMPLE 2 If a type of structured text or a limited sub-set of language C is used with restrictions within
either the compiler or development tools, or both, and restrictive coding guidelines which fulfil 7.4 a) and b) and
all of the questions 2.1 to 2.4 in Figure 15 can be answered with yes, the result will be LVL.
EXAMPLE 3 If Visual Basic is used it is not in accordance with IEC 61131-3 and the questions 2.1 to 2.4 in
Figure 15 answered with no, the result will be FVL.
EXAMPLE 4 If the software flow is influenced by the programming language, e.g. by using interrupt (question
2.1 in Figure 15), the result will be FVL.
EXAMPLE 5 If a function block diagram is used with self-declared functions blocks in structured text in
accordance with IEC 61131-3 and the restrictions of 7.4 a) and b) are fulfilled the result will be LVL.
NOTE 1 Annex N gives an overview on the measures that apply to SRASW and SRESW performed either by
usage of LVL or FVL.
NOTE 2 The technical documentation, especially safety manuals of products, can be followed for both LVL and
FVL. Both limitations via internal functions of the compiler and limitations via coding guideline can be used.
For SRESW for components with PLr a to d, the following basic measures shall be applied:
a) software safety lifecycle with verification and validation activities, e.g. reviews and tests, see
Figure 14 a);
b) documentation of specification and design, e.g. software design specification, software system
design specification (SSDS), module design specification (MDS), code listings including comments;
c) modular and structured design and coding, e.g. hierarchy and limitation of functionality, clear
program structure, definition of interfaces, well-structured call-graph, avoidance of interrupts, use
of coding guidelines (see IEC 61508-7:2010, C.2.6.2);
d) control of systematic failures, e.g. program sequence monitoring, controlling errors in the data
communication process (see G.2);
e) where using software based diagnostic measures for control of random hardware failures,
verification of correct implementation, e.g. correct implementation of diagnostic measures, RAM/
ROM/CPU tests, hardware tests, plausibility checks;
f) functional testing, e.g. black box testing implemented e.g. by verification of correct output data
based on input data (valid, invalid and border values), compatibility of interfaces, timing;
g) appropriate software safety lifecycle activities after modifications, e.g. based on an impact analysis.
For SRESW for components with PLr c or d, the following additional measures shall be applied:
h) project management and quality management processes comparable to, e.g. the IEC 61508 series,
e.g. definition of workflow, responsibilities;
i) documentation of all relevant activities during software safety lifecycle, e.g. documentation of
reviews, testing, validation and verification;
j) configuration management to identify all configuration items and documents related to a SRESW
release, e.g. version control of code listings, modules, design documents, test plans, release control,
archiving, system compatibility of different versions of hardware, software and programming
tools;
k) structured specification with safety requirements and structured design;
l) use of suitable programming languages and computer-based tools with confidence from use;
m) modular and structured programming, separation from non-safety-related software, limited
module sizes with fully defined interfaces, e.g. use of design and coding guidelines;
n) coding verification by walk-through/review with control flow analysis, e.g. to check for faults,
quality of comments, conformity with coding guidelines, clarity, readability, completeness;
o) extended functional testing, e.g. grey box testing, performance testing or simulation, e.g. by using
unspecified input data, extreme environmental conditions, full load, testing based on knowledge of
internal coding.
For the testing channel in Category 2, the requirements are reduced by one performance level. If
diversity is used in the functional channels of Category 3 or 4, the requirements are reduced by one
performance level.
SRESW for components with PLr e shall be in accordance with IEC 61508-3:2010, Clause 7, appropriate
for SIL 3. When using diversity in specification, design and coding, for the two channels used in a
subsystem with category 3 or 4, PLr e can be achieved with the above-mentioned additional measures
for PLr of c or d.
NOTE For SRESW with diversity in design and coding, for components used in a subsystem with category 3
or 4 or in testing channel of category 2, the effort involved in taking measures to avoid systematic failures can
be reduced by, for example, reviewing parts of the software only by considering structural aspects instead of
checking each line of code. Annex G gives guidance referring the usable measures to carry out these aspects.
When the designer of the SRP/CS is not able to access the embedded software, e.g. PLCs without safety
rating by the manufacturer, the SRESW requirements of 7.3.1 cannot be fulfilled. These components
may be used under the following alternative conditions:
— the subsystem is limited to PL a or b and uses category B, 2 or 3;
— the subsystem is limited to PL c with category 2 or PL d with category 3 and it is necessary to
fulfil the diversity requirements of the CCF, where both channels use diverse technologies, design
or physical principles;
— the associated hardware and the requirements for SRASW shall be assessed in accordance with the
requirements of this document, especially for CCF (see Annex F).
For SRASW for components with PLr from c to e, the following additional measures with increasing
efficiency (lower effectiveness for PLr of c, medium effectiveness for PLr of d, higher effectiveness for
PLr of e) apply.
For the testing channel in Category 2, the requirements are reduced by one performance level. If
diversity is used in the functional channels of Category 3 or 4, the requirements are reduced by one
performance level.
a) The software design specification shall be reviewed (see also Annex J), made available to persons
involved in the lifecycle and shall contain the description of:
1) safety functions with required PL and associated operating modes;
2) performance criteria, e.g. reaction times;
3) communication interfaces;
4) detection and control of hardware failures to achieve the required DC and fault reaction.
b) Selection of tools, libraries, languages:
1) Tools shall be suitable for the application. Technical features which detect conditions that can
cause systematic error (such as data type mismatch, ambiguous dynamic memory allocation,
incomplete called interfaces, recursion, pointer arithmetic) shall be used. Checks shall mainly
be carried out during compile time and not only at runtime. Tools should enforce language
subsets and coding guidelines or at least supervise or guide the developer using them. For PL e
achieved with one component and its tool, the tool shall be in conformity with the applicable
component standard. If two diverse components with diverse tools are used, successful
operating experience gained from prior projects can be sufficient.
2) Whenever reasonable and practicable, validated function block libraries should be used
– either safety-related function block libraries provided by the tool manufacturer (highly
recommended for PL e) or validated application specific FB libraries and in conformity with
this document.
3) A justified LVL-subset suitable for a modular approach should be used (see 7.2.1), e.g. accepted
subset of IEC 61131-3 languages.
c) Software design shall feature:
1) semi-formal methods to describe data and control flow, e.g. state diagram or program flow
chart;
2) modular and structured programming predominantly realized by function blocks deriving
from safety-related validated function block libraries or other modularity structure to achieve
easy code reading and testability;
3) function blocks of limited size of coding;
4) code execution inside function block with only one entry and only one exit point;
5) architecture model of three stages: inputs ⇒ processing ⇒ outputs (see Figure 16 and Annex J);
6) assignment of a safety output at only one program location;
7) use of techniques for detection and control of hardware failure and for defensive programming
within input, processing and output blocks which lead to safe state.
NOTE Verification is only used for application-specific code, and not for validated library functions.
i) Configuration management:
1) It is highly recommended that procedures and data backup be established to identify and
archive documents, software modules, verification/validation results and tool configuration
related to a specific SRASW version.
j) Modifications:
1) Prior to a modification of SRASW, an impact analysis shall be performed to ensure
consistency with the software design. Appropriate lifecycle activities shall be performed
after modifications. Means shall be provided to protect against unauthorized modifications to
SRASW and the modification history shall be documented.
10 Validation
10.1.1 General
The purpose of the validation process is to confirm that the SRP/CS meets the overall SRS created in
accordance with Clause 5 and Clause 7.
Figure 17 gives an overview of the validation process. The validation consists of applying analysis (see
10.3) and executing tests (see 10.4) under foreseeable conditions in accordance with the validation plan.
NOTE 1 The SRP/CS validation ensures that the safety functions achieve the intended risk reduction and is
intended to be part of the overall validation process of the machine.
The validation activities shall ensure the completeness and correctness of each design activity
identified in the validation plan.
The validation to be applied to the SRP/CS includes inspection (e.g. by analysis) and testing of the SRP/
CS to ensure that it achieves the requirements stated in the SRS (according to Clause 5).
The validation shall demonstrate that the SRP/CS meets the requirements and, in particular, the
following:
a) the specified functional requirements of the safety functions provided by that part, as set out in the
SRS;
b) the requirements of the specified PL in accordance with 6.1.1:
1) the requirements of the specified category,
2) the measures for control and avoidance of systematic failures (systematic integrity),
3) if applicable, the requirements of the software, and
4) the ability to perform a safety function under expected environmental conditions;
c) the ergonomic design, interaction and positioning of the operator interface.
The validation process should be carried out by person(s) who is/are independent from the design of
the SRP/CS.
NOTE 2 An independent person is a person not involved in the design of the SRP/CS and does not necessarily
mean that a third-party is required.
The analysis should be started as early as possible, and in parallel with, the design process. It can be
necessary for some parts of the analysis to be delayed until the design is well developed.
NOTE 3 Problems can then be corrected early while they are still relatively easy to correct, i.e. during steps
“design and technical realization of the safety function” and “evaluate the PL”.
Where necessary due to the size of the system, complexity or the effects of integrating it with the
control system (of the machinery), special arrangements should be made for
— validation of the subsystem separately before integration, including simulation of the appropriate
input and output signals, and
— validation of the effects of integrating SRP/CS into the remainder of the control system within the
context of its use in the machine.
The balance of analysis and testing depends on the technology used for the SRP/CS and the required
performance level (PLr). For categories 2, 3 and 4 the validation of the safety function shall also include
testing by appropriate fault injection to show that among other things, the fault reaction will be initiated
by the implemented diagnostic function.
“Modification of the design” in Figure 17 refers to the design process. If the validation cannot be
successfully completed, changes in the design are necessary. The validation of the modified parts of the
SRP/CS shall then be repeated. This process shall be iterated until the SRP/CS for each safety function
is successfully validated.
The validation plan shall identify and describe the requirements for carrying out the validation process
and shall be made available to affected persons and parties involved in the validation process. The
validation plan shall also identify the means to be employed to validate the specified safety functions. It
shall identify, where appropriate
a) the specification documents,
b) the operational and environmental conditions during testing,
Validation involves consideration of the behaviour of the SRP/CS for all faults to be considered. A basis
for fault consideration is given in the tables of fault lists in ISO 13849-2:2012, Annexes A to D, which are
based on experience and which contain
— the components/elements to be included, e.g. conductors/cables,
— the faults to be taken into account, e.g. short circuits between conductors,
— the permitted fault exclusions, taking into account environmental, operating and application
aspects, and
— a remarks section giving the reasons for the fault exclusions.
Only permanent faults are taken into account in the fault lists.
If necessary, a specific product-related fault list shall be generated as a reference document for the
validation of the subsystem(s) and/or subsystem element(s). The list can be based on the appropriate
generic list(s) found in the annexes of ISO 13849-2:2012 or (reoccurring) faults found as a result of
product observation.
Where the specific product-related fault list is based on the generic list(s) it shall state
a) the faults taken from the generic list(s) to be included,
b) any other relevant faults to be included but not given in the generic list (e.g. common-cause failures),
c) the faults taken from the generic list(s) which may be excluded on the basis that the criteria given
in the generic list(s) are satisfied, and
d) in exceptional circumstances, any other faults for which justification and rationale for an exclusion
is presented.
Where this list is not based on the generic list(s), the designer shall give the rationale for fault exclusions.
The information required for validation varies with the technology used, the category or categories
and PL to be demonstrated, SRS, and the contribution of the SRP/CS to the reduction of the risk.
Documents containing sufficient information from the following list shall be included in the validation
to demonstrate that the SRP/CS perform the specified safety functions to the required PL and category:
a) SRS, including the required characteristics of each safety function, e.g. response time (according
to ISO 13855:2010), operating mode, PL, interfaces between the subsystems of the SRP/CS and if
necessary characteristics of used category of each subsystem of the SRP/CS;
b) drawings and specifications, e.g. for mechanical, hydraulic and pneumatic parts, printed circuit
boards, assembled boards, internal wiring, enclosure, materials, mounting;
c) block diagram(s) and where needed for clarification with a functional description of the blocks;
d) circuit diagram(s), including interfaces/connections;
i) report of analysis of all relevant faults according to 10.1.3 and 10.1.4, such as those listed in the
tables of ISO 13849-2:2012, Annexes A to D, including the justification of any excluded faults;
j) report of analysis of the influence of processed materials;
k) information for use, maintenance requirements, e.g. installation and operation manual/instruction
handbook.
Where software is relevant to the safety function(s), the software documentation shall include
— a specification which is clear and unambiguous,
— evidence that the software is designed to achieve the required PL (see 10.6.3), and
— details of tests (in particular test reports) carried out to prove that the required PL is achieved.
Information is required on how the PL and PFH is determined. The documentation of the quantifiable
aspects shall include
— the safety-related block diagram or designated architecture according to 6.1.3.2,
— the determination of MTTFD, DCavg and CCF, and
— the determination of the category.
NOTE 2 For guidance on safety-related block diagram see Annex B.
Information is required for documentation on measures against systematic failures of the SRP/CS.
Information is required to describe how the combination of several subsystems achieves the required
PL.
NOTE 3 Where practicable, a clear and traceable reference to existing documents is acceptable.
10.3.1 General
Validation of the SRP/CS shall be carried out by analysis. Inputs to the analysis include the following:
— the safety function(s), their characteristics and the safety integrity specified according to 5.2;
— the system structure (e.g. designated architectures) according to 6.1.3.2;
— the quantifiable aspects (MTTFD, DCavg and CCF) according to 6.1.4, 6.1.5, and 6.1.6 by validating
assumptions and data that were associated in selecting the values used in the system calculations;
— the non-quantifiable, qualitative aspects which affect system behaviour (if applicable, software
aspects);
— deterministic arguments;
— fault lists;
— criteria for fault exclusion.
NOTE A deterministic argument is an argument based on qualitative aspects (e.g. quality of manufacture,
experience of use). This consideration depends on the application, which, together with other factors, can affect
the deterministic arguments. Deterministic arguments differ from other evidence in that they show that the
required properties of the system follow logically from a model of the system. Such arguments can be constructed
on the basis of simple, well-understood concepts.
The following are two basic techniques that can be used for analysis:
a) Top-down (deductive) techniques are suitable for determining the initiating events that can lead
to identified top events and calculating the probability of top events from the probability of the
initiating events. They can also be used to investigate the consequences of identified multiple
faults.
EXAMPLE 1 FTA (see IEC 61025), ETA (see IEC 62502).
b) Bottom-up (inductive) techniques are suitable for investigating the consequence of identified single
faults.
EXAMPLE 2 FMEA (see IEC 60812) and failure modes, effects and criticality analysis (FMECA) (see
IEC 60812).
10.4.1 General
Testing shall be part of the validation. In case the category is B or 1, tests under fault conditions are not
required and analysis with functional testing may be sufficient.
Validation tests shall be planned and implemented in a logical manner. In particular:
a) a test plan shall be produced before testing begins that shall include
1) the test specifications,
2) the required outcome of the tests for conformity, and
The accuracy of measurements during the validation by testing shall be appropriate for the test carried
out. In general, these measurement accuracies shall be within +/−5 K for temperature measurements
and +/−5 % for the following:
a) time measurements;
b) pressure measurements;
c) force measurements;
d) electrical measurements;
e) relative humidity measurements;
f) linear measurements.
Deviations from these measurement accuracies shall be justified.
If the SRP/CS is required to fulfil more stringent requirements than those within this document, the
testing shall be extended to cover these more stringent requirements as well.
NOTE Depending on the risk assessment, more stringent requirements can apply if the control system has to
withstand particularly adverse service conditions, e.g. rough handling, humidity effects, hydroxylation, ambient
temperature variations, effects of chemical agents, corrosion, and high strength of electromagnetic fields, for
example, due to close proximity of transmitters.
Unless otherwise specified in the test specification, the tests shall be made on a single production
sample of the subsystem being tested.
Subsystem(s) under test shall not be modified during the course of the tests.
Certain tests can permanently change the performance of some components. Where a permanent
change in a component causes the safety-related part to be incapable of meeting the requirements of
further tests, a new sample or samples shall be used for subsequent tests.
Where a particular test is destructive and equivalent results can be obtained by testing part of SRP/CS
in isolation, a sample of that part of the SRP/CS may be used instead of the whole SRP/CS for the purpose
of obtaining the results of the test. This approach shall only be applied where it has been shown by
analysis that testing of a part of SRP/CS is sufficient to demonstrate the safety integrity of the whole
SRP/CS that performs the safety function.
Depending on the application, different testing methods shall be used to validate the SRP/CS. In some
applications it can be necessary to divide the connected SRP/CS into several functional groups and to
subject these groups and their interfaces to fault simulation tests. The precise instant at which a fault
is injected into a system can be critical. The worst-case effect of a fault injection shall be determined by
analysis and by injecting the fault at this appropriate critical time. Common test methods are:
a) simulation of control system behaviour in the event of a fault, e.g. by means of either hardware or
software models, or both;
b) software simulation of faults;
c) functional testing of the safety functions in all operating modes of the machine, to establish
whether they meet the specified characteristics (see Clause 5). The functional tests shall ensure
that all safety-related outputs are realized over their complete ranges and respond to safety-related
input signals in accordance with the specification. The test cases are normally derived from the
specifications but can also include some cases derived from analysis of the schematics or software;
d) extended functional testing to check foreseeable abnormal signals or combinations of signals from
any input source, including power interruption and restoration, and incorrect operations;
e) fault injection tests on the actual circuit and fault initiation on actual components, particularly in
parts of the system where there is doubt regarding the results obtained from failure analysis;
f) fault injection tests into a production sample;
g) fault injection tests into a hardware model;
h) subsystem failure test (e.g. power supplies).
b) Simulation.
c) Check of the hardware components installed in the machine and details of the associated software
to confirm their correspondence with the documentation (e.g. manufacturer, type, version).
d) Functional testing (see 10.4.5).
e) Check of the operator-SRP/CS interface for the meeting of ergonomic principles.
The safety integrity of each subsystem of the SRP/CS shall be validated by confirming the requirements
of Table 10 according to the category used.
Table 10 (continued)
Category
Requirements
B 1 2 3 4
Measures against software faults X — X X X
Key
X required
— not required
NOTE The categories are those given in 6.1.3.2.
In addition, the safety integrity of each subsystem of the SRP/CS shall be validated by confirming
— the probability of dangerous random hardware failure, and
— the systematic integrity (see Annex G, Clause 7 Software, CCF).
In this context the validation of MTTFD (including B10D, T10D and nop values), DCavg and CCF is typically
performed by analysis and visual inspection.
Where fault exclusion claims mean that particular components do not contribute to the channel MTTFD,
the plausibility of the fault exclusion shall be checked.
NOTE A fault exclusion implies infinite MTTFD, therefore, fault excluded failure modes of the component do
not contribute to the calculation of channel MTTFD.
The MTTFD of each channel of the subsystem, including application of the symmetrisation formula
(see Annex D) to dissimilar redundant channels, shall be checked for correct calculation. MTTFD of
individual channels shall be restricted to no greater than 100 years (2 500 years for category 4) before
the symmetrisation formula is applied.
The DC values for either components (subsystem elements) or logic blocks, or both, shall be checked for
plausibility (e.g. against measures in Annex E). The correct implementation (hardware and software) of
checks and diagnostics, including appropriate fault reaction, shall be validated by testing under typical
environmental conditions in use.
The correct implementation of sufficient measures against common-cause failures shall be validated
(e.g. Annex F). Typical validation measures are static hardware analysis and functional testing under
environmental conditions.
Generally, for the specification of the MTTFD values of electronic components, an ambient temperature
of +40 °C is taken as a basis. During validation, it is important to ensure that, for MTTFD values, the
environmental and functional conditions (in particular temperature) taken as basis are met. Where a
device, or component, is operated significantly above (e.g. > 10 °K) the specified temperature of +40 °C,
it is necessary to use MTTFD values for the increased ambient temperature.
The validation of measures against systematic failures can typically be provided by:
a) inspections of design documents which confirm the application of
1) basic and well-tried safety principles (see ISO 13849-2:2012, Annexes A to D),
2) further measures for avoidance of systematic failures according to Annex G, and
3) further measures for the control of systematic failures, such as hardware diversity, modification
protection or failure assertion programming;
b) failure analysis (e.g. FMEA);
c) fault injection tests/fault initiation;
NOTE 2 Black-box testing aims to check the dynamic behaviour under real functional conditions, and to reveal
failures to meet functional specification, and to assess utility and robustness. Grey-box testing is similar to black-
box testing but additionally monitors relevant test parameter(s) inside the software module.
Individual software functions which have already been validated do not need to be validated again.
Where a number of such safety function blocks are combined for a specific project, however, the
resulting total safety function shall be validated.
The measures for software implementation and configuration and modification management according
to Clause 7, which depend on the PL to be attained, shall be examined with regard to their proper
implementation.
Should the safety-related software be subsequently modified, it shall be revalidated on an appropriate
scale.
Where the safety function is implemented by two or more subsystems, validation of the combination –
by analysis and by testing – shall be undertaken to establish that the combination achieves the safety
integrity specified in the design. Existing recorded validation results of subsystems can be taken into
account. The following validation steps shall be performed:
— inspection of design documents describing the overall safety function(s);
— a check that the overall PL of the subsystem combination has been correctly evaluated, based on the
PL of each individual subsystem (according to 6.2);
— consideration of the characteristics of the interfaces, e.g. voltage, current, pressure, data format of
information, signal level;
— failure analysis relating to combination/integration, e.g. by FMEA;
— testing of the subsystem combination;
— for redundant systems, fault injection tests relating to combination/integration.
11 Maintainability of SRP/CS
Preventive or corrective maintenance can be necessary to maintain the specified performance of the
SRP/CS.
NOTE Exceeding specified lifetime or test interval can lead to deterioration in safety or to a hazardous
situation.
The following factors shall be taken into account to enable maintenance of the SRP/CS:
— accessibility, taking into account the environment and the human body measurements, including
the dimensions of the working clothes and tools used;
— ease of handling, taking into account ergonomic capabilities;
— limitation of the number of special tools and equipment where possible;
— indication(s) that maintenance is necessary (e.g. increased vibration) ideally with automated
generation of warning signals (e.g. lifetime recording, self-test, monitoring of process parameters);
— required illumination levels.
12 Technical documentation
When designing an SRP/CS according to this document at least the following information relevant to
the safety-related part shall be documented for internal purposes:
a) SRS (see 5.2.1);
b) exact points at which the safety-related part(s) starts and ends;
c) decomposition into subsystems (see 5.2.2), if applicable;
d) environmental conditions (e.g. EMI immunity, temperature, vibration);
e) achieved performance level and PFH value;
f) category or categories selected (may not be applicable for previously validated subsystems);
g) parameters relevant to the reliability (MTTFD, DC, CCF and T10D) and the mission time;
h) measures against systematic failure;
i) the technology or technologies used;
j) the safety-relevant faults considered;
k) justification for fault exclusions (see 6.1.10.3 and all annexes of ISO 13849-2:2012);
l) software documentation if applicable;
m) measures against reasonably foreseeable misuse;
n) safety-related block diagram;
o) relevant design documentation, test, verification and validation records, where applicable.
NOTE The design documentation is generally foreseen to be used for internal purposes of the manufacturer
or to exchange technical information between sub-contractors (e.g. external system designer, certification body)
and the manufacturer. The design documentation is also necessary to fulfil legal documentation requirements.
The design documentation does not need to be distributed to the machine user but parts of it are relevant to
prepare adequate information for use (see Clause 13).
13.1 General
The information for use of the SRP/CS shall be according to ISO 20607:2019 or IEC/IEEE 82079-1:2019
including the relevant instructions for the intended target groups. The lifecycle phases of the machine
where an SRP/CS is involved shall be covered by this information.
Specific information for each safety function on categories and performance level shall be provided (see
5.3), as follows:
— the categories of the subsystems forming the SRP/CS (may not be applicable for previously validated
subsystems);
— the performance level, a, b, c, d or e;
— the PFH value for SRP/CS related to the safety function, if relevant per subsystem(s).
j) instructions relating to maintenance actions (e.g. replacement of parts) which do not require
specific skills and hence may be carried out by machine users (e.g. operators). It should be brought
to the attention of maintenance staff which parts are critical to safety and shall only be replaced
with original parts or parts fulfilling the same safety requirements;
k) controlling hazardous energy (manual measures/other means) guidance, signs, and devices;
l) drawings/diagrams enabling maintenance personnel to perform their tasks (especially fault-
finding tasks to isolate conditions that caused the fault);
m) information about replacement of components at or before the Tm period ends (for pneumatic,
mechanical and electromechanical components see also C.4.2).
NOTE 1 For additional information see ISO 20607:2019 and IEC 60204-1:2016+AMD1:2021, 17.2 f.
If any maintenance activity requires the repair or modification of an SRP/CS revalidation including
functional test shall be performed.
NOTE 2 The relevant revalidation activities would be dependent upon the extent of differences between the
original and the replacing component.
Annex A
(informative)
A.1 General
Key
1 starting point for evaluation of safety function’s contribution to risk reduction
L low contribution to risk reduction
H high contribution to risk reduction
PLr required performance level
Risk parameters:
S severity of injury
S1 slight (normally reversible injury)
S2 serious (normally irreversible injury or death)
F frequency and/or exposure times to hazard
F1 seldom-to-less-often and/or exposure time is short
F2 frequent-to-continuous and/or exposure time is long
P possibility of avoiding or limiting harm
P1 possible under specific conditions
P2 scarcely possible
Figure A.1 provides guidance for the determination of the safety-related PLr for the safety function. The
diagram should be considered for each safety function.
A.3 Guidance for selecting parameters S, F and P for the risk estimation
A.3.1 Severity of injury, S1 and S2
In estimating the risk, only slight injuries or serious injuries are considered.
To make a decision, the usual consequences of accidents and normal healing processes should be taken
into account in determining S1 and S2. For example, bruising and/or lacerations without complications
would be classified as S1, whereas amputation or death would be S2.
NOTE For guidance about the evaluation of severe or slight injury see also ISO/TR 14121-2.
The period of exposure to the hazard should be evaluated on the basis of an average value which can
be seen in relation to the total period of time over which the equipment is used. For example, if it is
necessary to reach regularly between the tools of the machine during cyclic operation in order to feed
and move workpieces, then F2 should be selected.
In case of no other justification, F2 should be chosen if the frequency is higher than once per 15 min.
F1 may be chosen if the accumulated exposure time does not exceed 1/20 of the overall operating time
and the frequency is not higher than once per 15 min.
EXAMPLE At a machine with an overall operating time of 8 h per day a person is exposed 2 min once an
hour to change workpieces (estimated average value) so the accumulated exposure time is 16 min in relation to
8 min × 60 min resulting in 1/30. Since also the frequency is 1/h, F1 can be chosen.
The approach based on Table A.1 and Table A.2 should always be used with the following basic intention:
P1 should only be selected if there is a realistic possibility of avoiding harm or of significantly reducing
its effect; otherwise P2 should be selected.
EXAMPLE 2 For a robot cell in which separate robots are working, for the cell areas where only one robot can
create at the same time a hazard, the robots can be considered separately.
EXAMPLE 3 As a result of a risk assessment it can be sufficient for a rotary table with clamping devices to
consider each clamping device separately.
Annex B
(informative)
Key
I1, I2 input devices, e.g. sensor
L logic
O1, O2 output devices, e.g. main contactor
T testing device
I1 and O1 build up the first channel (series alignment)
I2, L and build up the second channel (series alignment); with both channels executing the sub-function
O2 redundantly (parallel alignment)
T used for testing only
Annex C
(informative)
C.1 General
This annex gives several methods for calculating or evaluating MTTFD values for single components:
the method given in C.2 is based on the application of good engineering practices for the different
kinds of components; that given in C.3 is applicable to hydraulic components; C.4 provides a means
of calculating the MTTFD of pneumatic, mechanical and electromechanical components from B10 (see
C.4.1); C.5 lists MTTFD values for electrical components.
b) The manufacturer of the component specifies the appropriate application and operating conditions
for the SRP/CS designer.
c) The design of the SRP/CS fulfils the basic and well-tried safety principles according to
ISO 13849-2:2012, for the implementation and operation of the component.
Table C.1 — International Standards dealing with MTTFD or B10D for components
Basic and well-tried safety
Relevant Typical values: MTTFD
principles according to
standards (years) B10D (cycles)
ISO 13849-2:2012
mechanical components Table A.1 and Table A.2 — MTTFD = 150
hydraulic components with Table C.1 and Table C.2 ISO 4413 MTTFD = 150
nop ≥ 1 000 000 cycles per yeara
hydraulic components with Table C.1 and Table C.2 ISO 4413 MTTFD = 300
1 000 000 cycles per year
> nop ≥ 500 000 cycles per year a
hydraulic components Table C.1 and Table C.2 ISO 4413 MTTFD = 600
with 500 000 cycles per
year > nop ≥ 250 000 cycles per yeara
hydraulic components with nop Table C.1 and Table C.2 ISO 4413 MTTFD = 1 200
< 250 000 cycles per year a
pneumatic components Table B.1 and Table B.2 ISO 4414 B10D = 20 000 000c
relays and contactor relays with small Table D.1 and Table D.2 IEC 61810-3 B10D = 20 000 000
load
IEC 60947
series
relays and contactor relays with nom- Table D.1 and Table D.2 IEC 61810-3 B10D = 400 000
inal load
IEC 60947
series
proximity switches with small load Table D.1 and Table D.2 IEC 60947 B10D = 20 000 000
series
ISO 14119
proximity switches with nominal load Table D.1 and Table D.2 IEC 60947 B10D = 400 000
series
ISO 14119
contactors with small loadd Table D.1 and Table D.2 IEC 60947 B10D = 20 000 000
series
contactors with nominal loadd Table D.1 and Table D.2 IEC 60947 B10D = 1 300 000
series
NOTE 1 For the definition and use of B10D, see C.4.
NOTE 2 B10D is estimated as two times B10 (50 % dangerous failure) if no other information (e.g. product standard) is
available.
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 category 1 or category 3/4 subsystem depending on the number of electrical output
contacts and on the fault detection in the subsequent subsystem. Each contact element (including the mechanical actuation)
can be considered as one channel with a respective B10D 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 is possible that the machine builder
can apply fault exclusion according to ISO 13849-2:2012, Table D.8, considering the specific application and environmental
conditions of the device.
NOTE 4 Reduction of switching cycles can lead to an increasing probability of sticking of the switching elements in spool
valves (see ISO 4413).
NOTE 5 The MTTFD for mechanical components refers exclusively to mechanically moving components/parts (not to
housing).
a B10D calculation for hydraulic components is not permitted as a reverse calculation from standard MTTFD values.
b If fault exclusion for direct opening action is possible.
c In general, this value can be assumed for most pneumatic components. However, depending on the application and
type, e.g. shut-off valve, this value can be significantly lower.
d “Nominal load” or “small load” should take into account safety principles described in ISO 13849-2:2012, such as over-
dimensioning of the rated current value. “Small load” means, for example, 20 %.
to use the B10D concept for MTTFD of pneumatic, mechanical and electromechanical components also
for hydraulic components if the manufacturer can provide data, e.g. B10, B10D, T10, T10D.
c) The manufacturer of the component specifies the appropriate application and operating conditions
for the SRP/CS designer. The SRP/CS designer should provide information pertaining to their
responsibility to fulfil the basic safety principles according to ISO 13849-2:2012, Table A.1, Table B.1
or Table D.1, for the implementation and operation of the component. For category 1, 2, 3 or 4, the
user should be informed of their responsibility to fulfil the well-tried safety principles according
to ISO 13849-2:2012, Table A.1, Table B.2 or Table D.2, for the implementation and operation of the
component.
1) If the ratio of dangerous failure (RDF) of B10 is not given (e.g. by components manufacturer), 50 % of B10 can be
used, so B10D = 2 B10 is recommended.
tcycle is the mean operation time between the beginning of two successive cycles of the compo-
nent (e.g. switching of a valve) in seconds per cycle.
The operating life time of the component is limited to T10D, the mean time until 10 % of the components
fail dangerously:
B10D
T10D = (C.3)
nop
In case no B10D is given by the manufacturer of the component, it is permitted to determine the B10D by
the Formula (C.4)
B10
B10D = (C.4)
RDF
If the ratio of dangerous failures (RDF ) given by the component manufacturer is estimated at less than
50 % then T10D value is limited to T10 × 2.
When the T10D value for a component is less than the mission time (20 years or less), the manufacturer
responsible for the integration of the SRP/CS providing the safety function will inform the user to
replace the component at or before the T10D period ends. Limiting the use of components to T10D allows
maintaining the expected performance level of the safety function.
C.4.4 Example
For a pneumatic valve, a manufacturer determines a mean value of 60 million cycles as B10D. The valve
is used for two shifts each day on 220 operation days a year. The mean time between the beginnings of
two successive switching of the valves is estimated as 5 s. This yields the following values:
— dop of 220 d per year;
60 × 106
T10D = = 23,7 years (C.9)
2,53 × 106
23,7
MTTFD = = 237 years (C.10)
0,1
This calculation gives a MTTFD for the component “high” according to Table C.5. These assumptions are
only valid for a restricted operation time of 23,7 years for the valve.
C.5.2 Semiconductors
See Table C.2 and Table C.3.
Annex D
(informative)
MTTFD is the mean time to dangerous failure for the complete channel;
MTTFD i, MTTFD j is the MTTFD of each component which has a contribution to the sub-function;
The first sum is over each component separately; the second sum is an equiva-
lent, simplified form where all nj identical components with the same MTTFD j
are grouped together.
The example given in Table D.1 gives a MTTFD of the channel of 22,4 years, which is “medium” according
to 6.1.4, Table 6.
NOTE 1 This method is based on the presumption that a dangerous failure of any component (worst case
estimation) within a channel leads to dangerous failure of the channel. The MTTFD calculation illustrated by
Table D.1 is based upon this.
NOTE 2 In this example, the main influence comes from the contactor. The chosen values for MTTFD and
B10D for this example are based on Annex C. For the example application dop = 220 days/year, hop = 8 h/day and
tcycle = 10 s/cycles is assumed, giving nop = 633 600 cycles/year. In general, taking manufacturer’s values for
MTTFD and B10D leads to a much better result, that is, a higher MTTFD for the channel.
NOTE 3 When MTTR (mean time to restoration) can be considered negligible, MTTF can be considered equal
to MTBF.
NOTE 4 Where only MTBF values are available, a conversion to MTTFD values can be done by MTTFD ≈ 2*MTBF.
D.2 MTTFD for different channels, symmetrisation of MTTFD for each channel
The designated architectures of 6.1.3.2 assume that for different channels in a redundant SRP/CS the
values for MTTFD for each channel are the same. This value per channel should be input for Figure 12.
If the MTTFD of the channels differ, there are two possibilities:
— as a worst-case assumption, the lower value should be taken into account;
— Formula (D.2) can be used as an estimation of a value that can be substituted for MTTFD for each
channel:
2 1
MTTFD = MTTFD C1 + MTTFD C2 − (D.2)
3 1 1
+
MTTFD C1 MTTFD C2
where
MTTFD C1 and MTTFD C2 are the values for two different redundant channels each limited to a
maximum value of 100 years (categories B, 1, 2 and 3) or 2 500 years
(category 4).
EXAMPLE One channel has an MTTFD C1 = 3 years, the other channel has an MTTFD C2 = 100 years, then
the resulting MTTFD = 66 years for each channel. This means a redundant system with 100 years MTTFD in one
channel and 3 years MTTFD in the other channel is equal to a system where each channel has a MTTFD of 66 years.
A redundant system with two channels and different MTTFD values for each channel can be substituted
by a redundant system with identical MTTFD in each channel by using the above formula. This procedure
is necessary for the correct use of Figure 12.
NOTE This method assumes independent parallel channels.
Annex E
(informative)
b If medium or high DC is claimed for the logic, at least one measure for each of variable memory, invariable
memory and processing unit with each DC at least 60 % shall be applied. Other measures can be used than
those listed in this table.
For the application of Table E.1 see the indicative examples below.
EXAMPLE 1 ISO 13849-2:2012, Annex E presents a complete worked example (which is very detailed) for the
validation of fault behaviour and diagnostic means on an automatic assembly machine.
NOTE ISO/TR 24119 describes a pragmatic step-by-step table-based methodology for evaluation of DC for
series connected interlocking devices with potential free contacts.
EXAMPLE 2 The DC measure “fault detection by the process” can only be applied if the safety-related
component is involved in the production process, e.g. a standard PLC or standard sensors are used for workpiece
processing and as part of one of two channels executing the safety function. The appropriate DC level depends
on the overlap of the commonly used resources (logic, inputs/outputs). For example, when all faults of a rotary
encoder on a printing machine lead to highly visible interruption of the printing process, the DC for this sensor
used to monitor a safely limited speed can be estimated as 90 % up to 99 %.
DC may be determined as the ratio between the failure rate of detected dangerous failures and the
failure rate of total dangerous failures. According to this definition an average diagnostic coverage
DCavg is estimated by Formula (E.1):
DC1 DC2 DCN
+ + ... +
MTTFD1 MTTFD2 MTTFDN
DCavg = (E.1)
1 1 1
+ + ... +
MTTFD1 MTTFD2 MTTFDN
All components of the SRP/CS without fault exclusion should be considered and summed up. For each
block, the MTTFD and the DC are taken into account. DC in this formula means the ratio of the failure
rate of detected dangerous failures of the part (regardless of the measures used to detect the failures)
to the failure rate of all dangerous failures of the part. Thus, DC refers to the tested part and not to
the testing device. Components without failure detection (e.g. which are not tested) have DC = 0 and
contribute only to the denominator of DCavg.
Annex F
(informative)
F.1 General
The comprehensive procedure for measures against CCF as described in F.2 and F.3 should be followed
for each subsystem of category 2, 3 or 4 which contributes to the SRP/CS.
The simplified procedure in 6.1.8 of this document assumes a β-factor of 2 % according to
IEC 61508-6:2010, Annex D. This can be reached by following the procedure in F.2.
The measures described in F.2 and F.3 should be documented in order to support a minimum score of
65 points is achieved.
The measures listed in Table F.1 should be evaluated according to their effectiveness to avoid or control
CCFs of redundant channels. Engineering judgement should support that typical causes for CCF are
reduced as much as reasonably possible.
NOTE 1 The calculation of the CCF is usually performed on a subsystem level, as the measures for the
individual subsystems differ (e.g. inputs, logic and outputs).
NOTE 2 Redundant channels in this annex means functional channel and testing channel in category 2 or
redundant functional channels in categories 3 and 4.
NOTE 3 Typical CCF causes are over-voltage, over-pressure, over-current, over-temperature, humidity,
shock, vibration, EMI, impurity of the pressure medium. The appropriate level of these causes is deduced from
the expected application of the SRP/CS including foreseeable faults (e.g. failure of a cooling fan) and reasonably
foreseeable misuse. The measures can vary for different categories (category 2 vs. 3 and 4) or input/logic/output
parts of the SRP/CS.
F.3 Description of the measures against common cause failure (CCF) in Table F.1
F.3.1 Separation/segregation
Physical separation between signal paths of redundant channels, for example:
a) separation in wiring (e.g. multi conductor cable with suitable insulation between conductors);
b) separation in piping (e.g. avoiding damaging of a hydraulic pipe due to high pressure released from
another adjacent pipe);
c) detection of short circuits and open circuits in cables by dynamic test;
d) separate shielding for the signal path of each channel;
e) redundant channels on separate printed-circuit boards or in separate housings or cabinets;
f) sufficient clearances and creepage distances between redundant channels on printed-circuit
boards, also taking into account e.g. tin whiskers (see ISO 13849-2:2012, D.2.2).
F.3.2 Diversity
Diversity considerations include, for example:
a) Different technologies/design or physical principles are used, for example:
— first channel electronic or programmable electronic and second channel electromechanical
hardwired;
— different initiation of safety function for each channel (e.g. position, pressure, temperature);
— first channel valve with rubber seal and second channel with metal seal;
— two position switches are used to detect the opening of a movable guard (safety guard), the first
one is operated when the safety guard is opened and uses a break-contact element with direct
opening action in accordance with IEC 60947-5-1:2020 Annex K, the second one is operated
when the safety guard is closed and uses a make-contact element;
b) Sensing elements employ different measurement principles (e.g. digital and analogue) or physical
principles (e.g. distance, pressure or temperature);
c) Different components, e.g. of different manufacturers (not re-badged);
d) Different loads, e.g. contact/valve of one channel switches without load, contact/valve in the second
channel switches under load.
F.3.3 Design/application/experience
Protection against or control of over-voltage, over-pressure, over-current, over-temperature, for
example:
a) Inputs and outputs of the SRP/CS and the power supply of the logic are protected from potential
levels of over-voltage and/or over-current (see also IEC 60204-1);
NOTE Parts of the SRP/CS are capable of withstanding or are protected from potential levels of either
over-voltage or over-current, or both. Possible maximum over-voltage level of SW mode PSU (switch mode
power supply) depends on the applied standard (e.g. maximum voltages limit under single fault condition).
It is important to take into account the possible maximum over-voltage level by applied standard SW
mode PSU as well as other operating conditions (e.g. over-voltage category, operating temperature).
b) The measure against over-pressure can be a single channel system if the primary pressure in
case of failure can never rise over the operating pressure multiplied by 1,5. ISO 4414 defines a
requirement for protection from unintended pressure (e.g. a pressure relief valve).
Only well-tried components are used. See 6.1.11 and ISO 13849-2.
F.3.4 Assessment/analysis
For each part of SRP/CS a failure mode and effect analysis or FTA has been carried out to identify
potential causes for CCF and its results are taken into account to avoid CCFs in the design.
F.3.5 Training
Designers have been trained (with training documentation, e.g. certificate of training) to understand
the causes and consequences of CCFs.
F.3.6 Environmental
For fluidic systems, filtration of the pressure medium, prevention of dirt intake, drainage of compressed
air, is implemented in conformity with the component manufacturers’ requirements concerning purity
of the pressure medium (see ISO 8573-1 for guidance).
For combined fluidic and electric systems, both aspects should be considered.
The SRP/CS is immune to all relevant environmental influences such as temperature, shock, mechanical
stresses, vibration, humidity, as specified in relevant standards, e.g. the IEC 60068 series, taking into
account the increased requirements for safety-related applications.
F.4 Measures against common cause failure (CCF) and other relevant standards
For some SRP/CS (subsystems) not all the measures against CCF listed in Table F.1 can provide an
appropriate reduction of the CCF impact since the potential risk reduction that can be provided by
those SRP/CS is limited also by their systematic capabilities (e.g. detection principle of sensors).
NOTE Some relevant standards (e.g. the IEC 62024 series for the application of protecting equipment
to detect the presence of persons or ISO 14119:2013 for the selection and application of interlocking devices
associated with guards) can include application limits related to systematic capabilities.
The designer of the complete SRP/CS applies the measures stated in these standards and conforms with
the instructions for use provided by the manufacturer.
Annex G
(informative)
Systematic failure
G.1 General
This annex provides guidance on measures to control and avoid systematic failures during the design
and integration of SRP/CS.
NOTE For examples for over-dimensioning see ISO 13849-2:2012, Table D.2.
— project management;
— documentation.
In addition, black-box testing should be applied, taking into account the complexity of the SRP/CS and
its PL.
NOTE 2 The content of the functional safety plan depends upon the specific circumstances, which can include:
— size of project;
— degree of complexity;
— SRS change;
— incident/accident experience;
— obsolescence;
The effect of the requested modification should be analysed to establish the effect on the safety function.
All accepted modifications that have an effect on the SRP/CS should initiate a return to an appropriate
design phase for its hardware and/or for its software (e.g. specification, design, integration, installation,
commissioning, and validation). All subsequent phases and management procedures should then be
carried out in accordance with the procedures specified for the specific phases in this document. All
relevant documents should be revised, amended and reissued accordingly.
Annex H
(informative)
Figure H.1 is a schematic diagram of the combination of subsystems of an SRP/CS providing one of
the safety functions controlling a machine actuator. This is not a functional/working diagram and
is included only to demonstrate the principle of combining categories and technologies in this one
function.
The control is provided through electronic control logic and a hydraulic directional control valve. The
risk is reduced by an AOPD, which detects access to the hazard zone and prevents start-up of the fluidic
actuator when the light beam is interrupted.
The subsystems of the SRP/CS which provide the safety function are: AOPD, electronic control logic,
hydraulic directional control valve and their interconnecting means.
These combined subsystems provide a stop function as a safety function. As the AOPD is interrupted,
the outputs transfer a signal to the electronic control logic, which provides a signal to the hydraulic
directional control valve to stop the hydraulic flow as the output of the SRP/CS. At the machine, this
stops the hazardous movement of the fluidic actuator.
This combination of subsystems creates a safety function demonstrating the combination of different
categories and technologies based on the requirements given in Clause 6. Using the principles given in
this document, the subsystems shown in Figure H.2 can be described as follows.
— Category 2, PL c, PFH = 1,5 × 10−6/h for the electro-sensitive protective device (light barrier). To
reduce the probability of faults this device uses well-tried safety principles;
— Category 3, PL d, PFH = 2,0 × 10−7/h for the electronic control logic. To increase the level of safety
performance of this electronic control logic, the structure of this subsystem is redundant and
implements several fault detection measures such that it is able to detect most of single faults;
— Category 1, PL c, PFH = 1,1 × 10−6/h for the hydraulic directional control valve. The status of being
well-tried is mainly application-specific. In this example, the valve is considered to be well-tried. In
order to reduce the probability of faults, this device comprises well-tried components applied using
well-tried safety principles and all application conditions are considered (see 6.1.3.2.3).
NOTE 1 The position, size and layout of the interconnecting means have also to be taken into account.
This combination leads to a summed-up value of PFH = 2,8 × 10−6/h in the range of PL c. Together with
the lowest PL of all three subsystems PLlow c a leads to an overall performance level of PL c (see 6.2).
NOTE 2 In case of one fault in the category 1 or the category 2 subsystem of Figure H.2 there can be a loss of
the safety function.
Key
AOPD active optoelectronic protective device (e.g. light curtain)
SB1 category 2 [Type 2], PL c
SB2 category 3, PL d (electronic control logic)
SB3 category 1, PL c (fluidic control system)
PES programmable electronic system
Key
AOPD active optoelectronic protective device (e.g. light curtain)
I, I1, I2 input devices, e.g. sensor
L, L1, L2 logic
O, O1, O2, OTE output devices, e.g. main contactor
SB1 category 2 [Type 2], PL c
SB2 category 3, PL d (electronic control logic)
SB3 category 1, PL c (fluidic control system)
TE test equipment
Annex I
(informative)
I.1 General
This annex illustrates the use of the simplified procedure for estimating PL given in 6.1.8 and the
preceding annexes for identifying safety functions and determining the PL. The quantification of two
control circuits is given. For the stepwise procedure, see Figure 4.
The following examples do not take into account the measures to ensure systematic integrity, software
requirements, and the correct application of basic and well-tried principles. They are only intended to
show quantification of MTTFD, DCavg , CCF, category and corresponding PL.
Two examples (A and B) of control circuits for different machines are examined (see Figure I.1 and
Figure I.3). Both illustrate the performance of the same safety function of the interlocking of the guard
door, but they have different PLr due to differences in the applications. The first example consists of
one channel of electromechanical components with medium and high MTTFD values, while the second
example is made up of two channels, one electromechanical and the other programmable electronic, of
components with medium and high MTTFD values, and with appropriate diagnostic testing.
The minimum distance between the interlocking guard and moving parts of the machine was
determined according to ISO 13855:2010, based on the machine stopping performance.
For example, A, the risk parameters according to the risk graph method (see Figure A.1) are as follows:
— severity of injury, S = S2, serious;
— frequency and/or exposure time to hazard, F = F1, seldom to less often and/or the exposure time is
short;
— possibility of avoiding or limiting harm, P = P1, possible under specific conditions.
These risk parameter selections lead to a PLr of c.
Determination of the preferred category: a performance level of “c” can be achieved typically by very
reliable single-channel systems (category 1), tested single-channel systems (category 2) or redundant
architectures (category 3) (see Figure 12).
For example, B, the risk parameters S2 and P1 are the same, but for frequency and/or exposure time to
hazard, F = F2, frequent to continuous and/or the exposure time is long.
Key
O guard interlocking is open
C guard interlocking is not open
M motor
K1A contactor relay
SW1A position switch (NC)
L power supply
direct opening
In this example, a position switch SW1A with direct opening action is used in the positive mode of
actuation but no-fault exclusion is justified for the mechanical parts. The position switch is connected
to a contactor relay K1A, which is able to switch off the power to the motor. The key features of these
SRP/CS are therefore:
— one channel of electromechanical components;
— position switch SW1A (NC) has direct opening action of the contact and high B10D;
— contactor relay K1A has high B10D.
The position switch and contactor relay in this example are both well-tried components when
implemented according to ISO 13849-2:2012.
The SRP/CS can be illustrated in a safety-related block diagram as shown in Figure I.2.
Key
SW1A position switch
K1A contactor relay
Figure I.2 — Safety-related block diagram identifying safety-related parts (SRPs) of example A
I.3.2 Quantification of MTTFD, DCavg, measures against CCF, category and performance
level
The values for MTTFD, DCavg and measures against CCF are assumed to be estimated according
to Annex C, Annex D, Annex E and Annex F, or to be given by the manufacturer. The categories are
estimated according to 6.1.3.
— MTTFD
The position switch SW1A and the contactor relay K1A contribute to the MTTFD of the one
channel. The values of B10D,SW1A = 20 000 000 cycles (position switch independent of load) and
B10D,K1A = 400 000 cycles (contactor relay with maximum load) are assumed to be provided by the
manufacturer. Applying the method of C.4.2 with 220 working days per year, 8 working hours per
day and a cycle time of 60 min gives MTTFD,SW1A = 113 636 years and MTTFD,K1A = 2 273 years.
Then using the parts count method of D.1, the MTTFD of the one channel is calculated as:
1 1 1 1 1 0 ,0
000 45
= + = + = (I.1)
MTTFD MTTFD,SW1A MTTFD,K1A 113 636 years 2 273 years year
which gives MTTFD = 2 222 years (limited to 100 years) for the channel, which is “high” according
to 6.1.4, Table 6.
NOTE If no B10D information for SW1A or K1A is available, a worst-case assumption according to C.2 or
C.4 can be made.
— T10D
The method given in C.4.2 gives T10D,SW1A of 11 364 years and T10D,K1A of 227 years, which both
exceed the mission time of 20 years and therefore eliminate the need for any preventive exchange.
— DC
No diagnostic testing is performed in control circuit A, the DC = 0 or “none”, as only one channel is
used, DC is not relevant.
— CCF
As only one channel is used, measures against CCF are not relevant.
— Category
The characteristics of category 1 (basic and well-tried safety principles, well tried components) are
fulfilled, including the requirement for the MTTFD of the channel to be “high”.
Input data for Figure 12: MTTFD of the channel is “high” (100 years), DCavg is “none” and category is 1.
Using Figure 12, this is interpreted as performance level c.
Application of Annex K gives an PFH of 1,14 × 10−6/h and PL c.
This result matches the PLr c according to Figure I.2. The control system of example A therefore satisfies
the requirements for risk reduction of the example A application of I.2, with S2, F1, P1 and PLr c.
Key
PLC programmable logic controller Cs stop signal (standard)
CC current converter ES enable (standard)
M motor K1B contactor relay
RS rotation sensor SW1B position switch (NC)
O guard interlocking is open SW2 position switch (NO)
C guard interlocking is not open
direct opening
Key
SW1B position switch PLC programmable logic controller
K1B contactor relay CC current converter
SW2 position switch RS rotation sensor
I.4.2 Quantification of MTTFD for each channel, average diagnostic coverage, measures
against CCF, category and performance level
The values for MTTFD for each channel, DCavg and measures against CCF are assumed to be evaluated
according to Annex C, Annex D, Annex E and Annex F, or to be provided by the manufacturer. The
categories are determined according to 6.1.3.
The position switch SW1B has a direct opening action and is used in the positive mode of actuation but
no-fault exclusion is justified for the mechanical parts.
— MTTFD
The position switch SW1B and contactor relay K1B contribute to the MTTFD,C1 of the first
channel. The values of B10D,SW1B = 20 000 000 cycles (position switch independent of load) and
B10D,K1B = 400 000 cycles (contactor relay with maximum load) are assumed to be provided by the
manufacturer. Applying the method of C.4.2 with 300 working days per year, 16 working hours
per day and a cycle time of 4 min gives MTTFD,SW1B’ = 2 778 years and MTTFD,K1B = 56 years. Then
using the parts count method of D.1, the MTTFD,C1 of the first channel is calculated as
1 1 1 1 1 0 , 018 2
= + = + = (I.2)
MTTFD,C1 MTTFD,SW1B MTTFD,K1B 2 778 years 56 years year
which gives an MTTFD = 55 years for the channel, which is “high” according to 6.1.4 and Table 6.
In the second channel SW2, PLC and CC contribute to MTTFD,C2. The B10D,SW2 of 1 000 000 cycles
is assumed to be given by the manufacturer. Applying the method of C.4.2 as for the first channel
gives an MTTFD,SW2 of 139 years. For PLC and CC an MTTFD of 20 years is assumed to be given by
the manufacturer. Applying the parts count method of D.1, to calculate the MTTFD,C2 of the second
channel gives
1 1 1 1 1 1 1 0 , 107 2
= + + = + + =
MTTFD ,C 2 MTTFD ,SW 2 MTTFD ,PLC MTTFD ,CC 139 years 20 years 20 years year
(I.3)
which gives an MTTFD = 9,3 years for the channel, which is “low” according to 6.1.4, Table 6.
NOTE If no MTTFD information for SW1B, SW2 or K1B is available, a worst-case assumption according
to C.2 or C.4 can be made.
As both channels have different values of MTTFD, Formula (D.2) can be used to calculate equivalent
identical values of MTTFD for a symmetrical two-channel system. Applying this formula yields an
MTTFD = 37 years for each channel, which is “high” according to 6.1.4, Table 6.
— T10D
The method of C.4.2 gives T10D,SW1B of 278 years, T10D,K1B of 5.5 years and T10D,SW2 of 13,9 years,
with the latter two being lower than the mission time of 20 years. The estimation of PL and PFH is
therefore only valid if K1B is exchanged before 5,5 years and if SW2 is exchanged before 13,9 years
of operation respectively.
— DC
In control circuit B, five of the SRP/CS are tested by the PLC. This testing consists of SW1B, SW2 and
K1B being read back by the PLC, the CC being read back by the PLC via RS and the PLC performing
self-tests. The DC values associated with each of these tested parts are
a) DCSW1B = DCSW2 = 99 %, “high”, due to plausibility check, see Table E.1 (second line of input
device part),
b) DCK1B = 99 %, “high”, due to normally open and normally closed mechanically linked contacts,
see Table E.1 (second line of input device part),
c) DCPLC = 30 %, “none”, due to low effectiveness of self-tests (this value comes out of the specific
application), and
d) DCCC = 90 %, “medium”, due to indirect monitoring of the machine actuator by control logic, see
Table E.1 (sixth line of output device part) – if the PLC monitors a failure of CC, it is able to stop
the motion with the enable (standard) and to de-energize the contactor relay K1B (additional
shut-off path).
For an estimation of the PL, an average DC value is needed as input for Figure 12:
DCSW1B DCK1B DCSW2 DCPLC DCCC
+ + + +
MTTFD,SW1B MTTFD,K1B MTTFD,SW2 MTTFD,PLC MTTFD,CC
DCavg = =
1 1 1 1 1
+ + + +
MTTFD,SW1B MTTFD,K1B MTTFD,SW2 MTTFD,PLC MTTFD,CC
0 , 99 0 , 99 0 , 99 0 , 3 0 , 9
+ + + +
= 2 778 56 139 20 20 = 0 , 09 = 67 , 9 % (I.4)
1 1 1 1 1 0 , 13
+ + + +
2 778 56 139 20 20
Sufficient measures against CCF require a minimum score of 65, so for example B the score of 85 is
sufficient to fulfil the requirements against CCF.
The characteristics of category 3 are fulfilled because a single fault in any of the parts does not lead to
the loss of the safety function. Whenever reasonably practicable the single fault is detected at or before
the next demand upon the safety function, the average diagnostic coverage (DCavg) is in the range 60 %
to 90 %, the measures against CCF are sufficient and the equivalent MTTFD for each channel is “high”.
Input data for Figure 12: MTTFD for the channel is “high” (37 years), DCavg is “low” and category is 3.
Using Figure 12 this can be interpreted as performance level d.
Application of Annex K (use 36 years) gives an PFH of 5,16 × 10−7/h and PL d.
This result matches the PLr d according to I.2. Control circuit B therefore satisfies the requirements for
risk reduction of the example B application of I.2 with S2, F2, P1 and PLr d.
Annex J
(informative)
J.3 Verification of software specification at different levels (i.e. SDS, SSDS, MDS)
As part of the software safety lifecycle according to Figure 14 a), the verification activities at each
level of the software specifications consists in reading the specifications in order to verify that all
the sensitive points are properly described. The following should be considered when verifying each
software function:
a) limiting the cases of erroneous interpretation of the software specifications;
b) avoiding gaps in the specifications resulting in an unknown behaviour of the SRP/CS;
c) precisely defining conditions for activation and de-activation of functions;
d) precisely guaranteeing that all the possible cases are handled;
e) consistency tests;
f) the different parameterizing cases;
g) the reaction following a failure.
Annex K
(informative)
116
MTTFD for Average frequency of a dangerous failure per hour (PFH) (1/h) and corresponding performance level
each channel Cat. B Cat. 1 Cat. 2 Cat. 2 Cat. 3 Cat. 3 Cat. 4
years DCavg = none DCavg = none DCavg = low DCavg = medium DCavg = low DCavg = medium DCavg = high
3 3,80 × 10−5 a 2,58 × 10−5 a 1,99 × 10−5 a 1,26 × 10−5 a 6,09 × 10−6 b
ISO 13849-1:2023(E)
3,3 3,46 × 10−5 a 2,33 × 10−5 a 1,79 × 10−5 a 1,13 × 10−5 a 5,41 × 10−6 b
3,6 3,17 × 10−5 a 2,13 × 10−5 a 1,62 × 10−5 a 1,03 × 10−5 a 4,86 × 10−6 b
3,9 2,93 × 10−5 a 1,95 × 10−5 a 1,48 × 10−5 a 9,37 × 10−6 b 4,40 × 10−6 b
4,3 2,65 × 10−5 a 1,76 × 10−5 a 1,33 × 10−5 a 8,39 × 10−6 b 3,89 × 10−6 b
4,7 2,43 × 10−5 a 1,60 × 10−5 a 1,20 × 10−5 a 7,58 × 10−6 b 3,48 × 10−6 b
5,1 2,24 × 10−5 a 1,47 × 10−5 a 1,10 × 10−5 a 6,91 × 10−6 b 3,15 × 10−6 b
5,6 2,04 × 10−5 a 1,33 × 10−5 a 9,87 × 10−6 b 6,21 × 10−6 b 2,80 × 10−6 c
6,2 1,84 × 10−5 a 1,19 × 10−5 a 8,80 × 10−6 b 5,53 × 10−6 b 2,47 × 10−6 c
6,8 1,68 × 10−5 a 1,08 × 10−5 a 7,93 × 10−6 b 4,98 × 10−6 b 2,20 × 10−6 c
7,5 1,52 × 10−5 a 9,75 × 10−6 b 7,10 × 10−6 b 4,45 × 10−6 b 1,95 × 10−6 c
8,2 1,39 × 10−5 a 8,87 × 10−6 b 6,43 × 10−6 b 4,02 × 10−6 b 1,74 × 10−6 c
9,1 1,25 × 10−5 a 7,94 × 10−6 b 5,71 × 10−6 b 3,57 × 10−6 b 1,53 × 10−6 c
10 1,14 × 10−5 a 7,18 × 10−6 b 5,14 × 10−6 b 3,21 × 10−6 b 1,36 × 10−6 c
11 1,04 × 10−5 a 6,44 × 10−6 b 4,53 × 10−6 b 2,81 × 10−6 c 1,18 × 10−6 c
12 9,51 × 10−6 b 5,84 × 10−6 b 4,04 × 10−6 b 2,49 × 10−6 c 1,04 × 10−6 c
13 8,78 × 10−6 b 5,33 × 10−6 b 3,64 × 10−6 b 2,23 × 10−6 c 9,21 × 10−7 d
15 7,61 × 10−6 b 4,53 × 10−6 b 3,01 × 10−6 b 1,82 × 10−6 c 7,44 × 10−7 d
16 7,13 × 10−6 b 4,21 × 10−6 b 2,77 × 10−6 c 1,67 × 10−6 c 6,76 × 10−7 d
18 6,34 × 10−6 b 3,68 × 10−6 b 2,37 × 10−6 c 1,41 × 10−6 c 5,67 × 10−7 d
20 5,71 × 10−6 b 3,26 × 10−6 b 2,06 × 10−6 c 1,22 × 10−6 c 4,85 × 10−7 d
22 5,19 × 10−6 b 2,93 × 10−6 c 1,82 × 10−6 c 1,07 × 10−6 c 4,21 × 10−7 d
NOTE 1 If for category 2 the demand rate is less than or equal to 1/25 of the test rate (see 6.1.3.2.4), then the PFH values stated in this table for category 2 multiplied by a factor of
1,1 can be used as a worst-case estimate.
NOTE 2 The calculation of the PFH values was based on the following DCavg:
— DCavg = low, calculated with 60 %;
— DCavg = medium, calculated with 90 %;
Table K.1 (continued)
MTTFD for Average frequency of a dangerous failure per hour (PFH) (1/h) and corresponding performance level
each channel Cat. B Cat. 1 Cat. 2 Cat. 2 Cat. 3 Cat. 3 Cat. 4
years DCavg = none DCavg = none DCavg = low DCavg = medium DCavg = low DCavg = medium DCavg = high
24 4,76 × 10−6 b 2,65 × 10−6 c 1,62 × 10−6 c 9,47 × 10−7 d 3,70 × 10−7 d
27 4,23 × 10−6 b 2,32 × 10−6 c 1,39 × 10−6 c 8,04 × 10−7 d 3,10 × 10−7 d
62 1,84 × 10−6 c 9,06 × 10−7 d 4,43 × 10−7 d 2,13 × 10−7 d 8,84 × 10−8 e 4,22 × 10−8 e
68 1,68 × 10−6 c 8,17 × 10−7 d 3,90 × 10−7 d 1,84 × 10−7 d 7,68 × 10−8 e 3,80 × 10−8 e
75 1,52 × 10−6 c 7,31 × 10−7 d 3,40 × 10−7 d 1,57 × 10−7 d 6,62 × 10−8 e 3,41 × 10−8 e
82 1,39 × 10−6 c 6,61 × 10−7 d 3,01 × 10−7 d 1,35 × 10−7 d 5,79 × 10−8 e 3,08 × 10−8 e
91 1,25 × 10−6 c 5,88 × 10−7 d 2,61 × 10−7 d 1,14 × 10−7 d 4,94 × 10−8 e 2,74 × 10−8 e
100 1,14 × 10−6 c 5,28 × 10−7 d 2,29 × 10−7 d 1,01 × 10−7 d 4,29 × 10−8 e 2,47 × 10−8 e
110 2,23 × 10−8 e
120 2,03 × 10−8 e
130 1,87 × 10−8 e
150 1,61 × 10−8 e
160 1,50 × 10−8 e
180 1,33 × 10−8 e
NOTE 1 If for category 2 the demand rate is less than or equal to 1/25 of the test rate (see 6.1.3.2.4), then the PFH values stated in this table for category 2 multiplied by a factor of
1,1 can be used as a worst-case estimate.
NOTE 2 The calculation of the PFH values was based on the following DCavg:
— DCavg = low, calculated with 60 %;
— DCavg = medium, calculated with 90 %;
117
ISO 13849-1:2023(E)
118
MTTFD for Average frequency of a dangerous failure per hour (PFH) (1/h) and corresponding performance level
each channel Cat. B Cat. 1 Cat. 2 Cat. 2 Cat. 3 Cat. 3 Cat. 4
years DCavg = none DCavg = none DCavg = low DCavg = medium DCavg = low DCavg = medium DCavg = high
200 1,19 × 10−8 e
220 1,08 × 10−8 e
ISO 13849-1:2023(E)
510 4,52 × 10−9 e
560 4,11 × 10−9 e
620 3,70 × 10−9 e
680 3,37 × 10−9 e
750 3,05 × 10−9 e
820 2,79 × 10−9 e
910 2,51 × 10−9 e
1 000 2,28 × 10−9 e
1 100 2,07 × 10−9 e
1 200 1,90 × 10−9 e
1 300 1,75 × 10−9 e
1 500 1,51 × 10−9 e
NOTE 1 If for category 2 the demand rate is less than or equal to 1/25 of the test rate (see 6.1.3.2.4), then the PFH values stated in this table for category 2 multiplied by a factor of
1,1 can be used as a worst-case estimate.
NOTE 2 The calculation of the PFH values was based on the following DCavg:
— DCavg = low, calculated with 60 %;
— DCavg = medium, calculated with 90 %;
Table K.1 (continued)
MTTFD for Average frequency of a dangerous failure per hour (PFH) (1/h) and corresponding performance level
each channel Cat. B Cat. 1 Cat. 2 Cat. 2 Cat. 3 Cat. 3 Cat. 4
years DCavg = none DCavg = none DCavg = low DCavg = medium DCavg = low DCavg = medium DCavg = high
1 600 1,42 × 10−9 e
1 800 1,26 × 10−9 e
— DCavg = medium, calculated with 90 %;
— DCavg = high, calculated with 99 %.
119
ISO 13849-1:2023(E)
ISO 13849-1:2023(E)
Annex L
(informative)
The following routes (see Figure L.1) provide guidance to fulfil EMI immunity measures for an SRP/CS
or subsystems.
— separate metal cabinets for power electronics and low power electronics;
d The score of PLC as part of SRP/CS can only be assigned once per SRP/CS.
(hr) This measure is highly recommended. If this measure is applicable but not realized, a detailed justification
shall be given, on how the EMI immunity is achieved in an equivalent way.
Annex M
(informative)
Table M.1 and Table M.2 list typical safety functions and their characteristics and safety-related
parameters, while making reference to other International Standards whose requirements relate to the
safety function, characteristic or parameter.
As most of the safety functions referenced in Table M.1 and Table M.2 relate to electrical standards, the
applicable requirements need to be adapted when other technologies or energy sources (e.g. hydraulic,
pneumatic) are used.
Table M.2 — Examples of International Standards giving requirements for certain safety
functions and safety-related parameters
Requirement
Safety function/ safety-re-
This document (ISO For additional information
lated parameter ISO 12100:2010
13849-1)
response time 5.2 — ISO 13855:2010, 3.2, A.3, A.4
13.2 IEC 62046:2018, 4.4.2.2
ISO 10218-1:2011, Annex B
safety-related parameter 5.2 6.2.11.7.3 IEC 60204-1:2016+AMD1:
such as speed, temperature, 2021, 7.1, 9.3.2
pressure, position or torque
IEC 61800-5-2:2016
fluctuations, loss and resto- 5.2.2.8 6.2.11.4 IEC 60204-1:2016+AMD1:2021,
ration of power sources 4.3, 7.1, 7.5
6.2.11.5
ISO 4413:2010
ISO 4414:2010
indications and alarms — 6.2.11.6 ISO 7731:2003
ISO 11428:1996
ISO 11429:1996
IEC 61310-1:2007
IEC 60204-1:2016+AMD1:
2021, 10.3, 10.4
IEC 61131-3:2013
IEC 62061:2021
Annex N
(informative)
EXAMPLE For a subsystem with PLr of c and category 2, case 2 is chosen for the functional channel and case
1 is chosen for the testing channel.
The fault-avoiding measures for SRESW and SRASW in Table N.2 and Table N.3 are graded according to
the category and PL:
a) PL a and b are typically realized using a category B structure with software used in the logic block
of the functional channel.
b) PL c and d may be realized using a category 2 structure with software used in the logic block of the
functional channel or in the test equipment block in the testing channel. For the testing channel the
requirements are reduced by one performance level.
c) PL d and e may be realized using a category 3 structure with software used in the logic block of
the functional channels. “Channel 1 and channel 2” means that software is used in both functional
channels. “Channel 1 or channel 2” means that software is used only in one of both functional
channels.
d) SRASW in PL d and e may also be realized using a pre-assessed platform (safety-related hardware
in combination with operating system and programming tool). In this case, only one application
software is used for both functional channels.
b Highly recommended.
Key
r recommended: measure should be used to improve the quality of the software; its use is not mandatory,
but if it is not used, this should be justified.
m mandatory (with low, medium or high effectiveness, see 7.4): this measure should always be used.
“-“ this measure is not required.
Key
1 ACK1 - acknowledge button of interlocking guard door 1 (accessible area) and emergency stop 1
2 GD1 - interlocking guard door 1
3 ES1 - emergency stop button 1
4 M1- motor 1 stopped with STO (safe torque off)
If all safety-relevant requirements of the manufacturer of the safety PLC (K1) are used, the simplified
V-model is sufficient, see Figure 14 b).
Those components represent pre-designed subsystems provided by component manufacturers.
The converter (drive T1) provides the integrated safety-related sub-function STO (Safe Torque Off)
according to IEC 61800-5-2.
NOTE The parameterisation of the converter is also, in general, within the scope of this document and the
validation process, but is not shown in this example.
Table N.4 shows the relevant signals to perform the safety function and complementary function, which
should be controlled and tested depending on the hardware wiring and the software implementation.
In Figures N.3, N.4 and N.5 the safety related block diagrams are represented.
SF1: If the interlocking guard door 1 is opened then M1 will be switched into STO by converter (drive T1).
function blocks
NOTE 1 #bSTO_OK is transferred by fieldbus using a safety protocol to the converter (drive 1).
NOTE 2 Indication and error handling is application specific and is not considered in this example.
Figure N.6 — Application program (SRASW) implemented in the safety PLC K1 based on pre-
assessed software modules (function blocks)
N.2.6.1 General
Table N.5 lists test cases to perform an FMEA and tests of the interlocking safety guard. Test 1 in
Table N.5 is a functional test without fault injection. Tests 2 and 3 simulate permanent HIGH signals on
one of the contacts related to the interlocking guard. Tests 4 and 5 simulate permanent LOW signals on
one of these contacts. Tests 6 and 7 simulate signal changes of both contacts outside the set discrepancy
time. Test 8 simulates a stuck at fault (permanent HIGH) of the acknowledge contact. For all eight test
cases, the correct responses of #bGD1_OK and #bGD1_ERROR are validated.
Relevant flags
(Reset)
Internal Flag #bGD1_OK Bool NO This release flag is used for subsequent processing.
137
ISO 13849-1:2023(E)
138
1 Functional test with no fault injection and no #bGD1_OK = LOW and Yes No
expected fault reaction:
#bGD1_ERROR = LOW.
When the safety function is requested (by
HIGH signal of #bGD1_OK is only restored
opening the interlocking guard door) IS_bG-
after closing GD1 and pressing ACK1.
D1_1=LOW and IS_bGD1_2=LOW.
ISO 13849-1:2023(E)
NOTE 1 Error-free state (initial situation / normal state before tests are performed, interlocking guard door is closed).
2 Permanent HIGH Signal on IS_bGD1_1 (I1.1) Safe state with #bGD1_OK = LOW Yes No
When the safety function is requested (by and initiated fault reaction
opening the interlocking guard) only IS_bGD1_2
#bGD1_ERROR = LOW changes to
changes to LOW
#bGD1_ERROR = HIGH
Block SF_GUARD cannot be acknowledged
After GD1 is closed block SF_GUARD can still
not be acknowledged.
SF_GUARD can only be acknowledged by a
signal changing of ACK1 after repair and
HIGH – LOW – HIGH signal change for both
IS_bGD1_1 and IS_bGD1_2.
NOTE 2 Message error I1.1.
3 Permanent HIGH signal on IS_bGD1_2 (I1.2). Safe state with #bGD1_OK = LOW Yes No
When the safety function is requested (by and initiated fault reaction
opening the interlocking guard) only IS_bGD1_1
#bGD1_ERROR = LOW changes to
changes to LOW
#bGD1_ERROR = HIGH
Block SF_GUARD cannot be acknowledged
After GD1 is closed block SF_GUARD can still
not be acknowledged.
SF_GUARD can only be acknowledged by a
signal changing of ACK1 after repair and
HIGH – LOW – HIGH signal change for both
IS_bGD1_1 and IS_bGD1_2.
NOTE 3 Message error I1.2.
NOTE 5 Message Error I1.2.
6 IS_bGD1_1 (I1.1) changes the signal state outside Safe state with #bGD1_OK = LOW Yes No
the set discrepancy time to IS_bGD1_2
and initiated fault reaction
#bGD1_ERROR = LOW changes to
#bGD1_ERROR = HIGH
Block SF_GUARD cannot be acknowledged
After GD1 is closed block SF_GUARD can still
not be acknowledged.
SF_GUARD can only be acknowledged by a
signal changing of ACK1 after repair and
HIGH – LOW – HIGH signal change for both
IS_bGD1_1 and IS_bGD1_2.
NOTE 6 This diagnostic function is for protection against manipulation.
139
ISO 13849-1:2023(E)
Table N.5 (continued)
140
7 IS_bGD1_2 (I1.2) changes the signal state out- Safe state with #bGD1_OK = LOW Yes No
side the set discrepancy time to IS_bGD1_1
and initiated fault reaction
#bGD1_ERROR = LOW changes to
#bGD1_ERROR = HIGH
ISO 13849-1:2023(E)
NOTE 8 Acknowledgement is edge-controlled and not level-controlled. This diagnostic function is a preventive measure against manipulation.
Table N.6 lists test cases to perform an FMEA and tests of the emergency stop. Test 1 in Table N.6 is a
functional test without fault injection. Tests 2 and 3 simulate permanent HIGH signals on one of the
contacts related to the emergency stop. Tests 4 and 5 simulate permanent LOW signals on one of these
contacts. Tests 6 and 7 simulate signal changes of both contacts outside the set discrepancy time. Test
8 simulates a stuck at fault (permanent HIGH) of the acknowledge contact. For all eight test cases, the
correct responses of #bES1_OK and #bES1_ERROR are validated.
N.2.6.4 Evaluation of the interlocking safety guard and the emergency stop with motor M1
N.2.6.5 Documentation
This document sets additional requirements for validation, for example software specification(s),
software guidelines, evidence that the software is designed to achieve the required PL, evidence that
the software supports the required DC, and documentation on measures against systematic failures
associated with software. Validation also includes analysis of these aspects. Table N.8 does not include
details for all of these aspects, therefore further documentation will be necessary.
Annex O
(informative)
NOTE 2 Parameters can depend on other application-specific data (e.g. limitation of the maximum switching
frequency).
NOTE Some devices can include components with failure modes depending on the operating cycles and
other components which are nearly independent of the operating cycles. It is up to the manufacturer whether to
define such a device as type 1, 2 or 3 and which characteristic values and application limits are given to the user.
Examples are the combination of an MTTFD value with a limitation to a maximum number of operating cycles or
the combination of a B10D value with a limitation of a minimal nop to be used for the application of Formula (C.1).
Bibliography
[1] ISO/IEC Guide 51:2014, Safety aspects — Guidelines for their inclusion in standards
[2] ISO 4413:2010, Hydraulic fluid power — General rules and safety requirements for systems and
their components
[3] ISO 4414:2010, Pneumatic fluid power — General rules and safety requirements for systems and
their components
[4] ISO 7731:2003, Ergonomics — Danger signals for public and work areas — Auditory danger signals
[5] ISO 8573-1, Compressed air — Part 1: Contaminants and purity classes
[6] ISO 9000:2015, Quality management systems — Fundamentals and vocabulary
[7] ISO 9001:2015, Quality management systems — Requirements
[8] ISO 9241-210, Ergonomics of human-system interaction — Part 210: Human-centred design for
interactive systems
[9] ISO 10218-1:2011, Robots and robotic devices — Safety requirements for industrial robots — Part
1: Robots
[10] ISO 10218-2, Robots and robotic devices — Safety requirements for industrial robots — Part 2:
Robot systems and integration
[11] ISO 11161:2007, Safety of machinery — Integrated manufacturing systems — Basic requirements
[12] ISO 11428:1996, Ergonomics — Visual danger signals — General requirements, design and testing
[13] ISO 11429:1996, Ergonomics — System of auditory and visual danger and information signals
[14] ISO 13850:2015, Safety of machinery — Emergency stop function — Principles for design
[15] ISO 13851, Safety of machinery — Two-hand control devices — Principles for design and selection
[16] ISO 13856-1, Safety of machinery — Pressure-sensitive protective devices — Part 1: General
principles for design and testing of pressure-sensitive mats and pressure-sensitive floors
[17] ISO 13856-2, Safety of machinery — Pressure-sensitive protective devices — Part 2: General
principles for design and testing of pressure-sensitive edges and pressure-sensitive bars
[18] ISO 14118:2017, Safety of machinery — Prevention of unexpected start-up
[19] ISO 14119:2013, Safety of machinery — Interlocking devices associated with guards — Principles
for design and selection
[20] ISO/TR 14121-2, Safety of machinery — Risk assessment — Part 2: Practical guidance and examples
of methods
[21] ISO/TS 15066:2016, Robots and robotic devices — Collaborative robots
[22] ISO 16090-1, Machine tools safety — Machining centres, Milling machines, Transfer machines —
Part 1: Safety requirements
[23] ISO 19973 (all parts), Pneumatic fluid power — Assessment of component reliability by testing
[24] ISO/TR 22100-2:2013, Safety of machinery — Relationship with ISO 12100 — Part 2: How ISO 12100
relates to ISO 13849-1
[25] ISO/TR 22100-3, Safety of machinery — Relationship with ISO 12100 — Part 3: Implementation of
ergonomic principles in safety standards
[26] ISO/TR 22100-4, Safety of machinery — Relationship with ISO 12100 — Part 4: Guidance to
machinery manufacturers for consideration of related IT-security (cyber security) aspects
[27] ISO 23125, Machine tools — Safety — Turning machines
[28] ISO/IEC/IEEE 26512, Systems and software engineering — Requirements for acquirers and
suppliers of information for users
[29] EN 614-1, Safety of machinery — Ergonomic design principles — Part 1: Terminology and general
principles
[30] EN 1005-3, Safety of machinery — Human physical performance — Part 3: Recommended force
limits for machinery operation
[31] EN 50178, Electronic equipment for use in power installations
[32] IEC 60204-1:2016+AMD1:2021, Safety of machinery — Electrical equipment of machines — Part 1:
General requirements
[33] IEC 60447, Basic and safety principles for man-machine interface (MMI) — Actuating principles
[34] IEC 60050-192:2015, International electrotechnical vocabulary — Part 192: Dependability
[35] IEC 60529, Degrees of protection provided by enclosures (IP code)
[36] IEC 60812, Analysis techniques for system reliability — Procedure for failure mode and effects
analysis (FMEA)
[37] IEC 60947 (all parts), Low-voltage switchgear and controlgear
[38] IEC 60950-1, Information technology equipment — Safety — Part 1: General requirements
[39] IEC 61000-1-2, Electromagnetic compatibility (EMC) — Part 1‑2: General — Methodology for the
achievement of functional safety of electrical and electronic systems including equipment with
regard to electromagnetic phenomena
[40] IEC 61000-6-2, Electromagnetic compatibility (EMC) — Part 6‑2: Generic standards — Immunity
for industrial environments
[41] IEC 61000-6-7:2014, Electromagnetic compatibility (EMC) — Part 6‑7: Generic standards —
Immunity requirements for equipment intended to perform functions in a safety-related system
(functional safety) in industrial locations
[42] IEC 61025, Fault tree analysis (FTA)
[43] IEC 61078, Reliability block diagrams
[44] IEC 61300 (all parts), Fibre optic interconnecting devices and passive components — Basic test and
measurement procedures
[45] IEC 61310 (all parts), Safety of machinery — Indication, marking and actuation
[46] IEC 61131-3:2013, Programmable controllers — Part 3: Programming languages
[47] IEC 61310-1:2007, Safety of machinery — Indication, marking and actuation — Part 1: Requirements
for visual, acoustic and tactile signals
[48] IEC 61326-3-1, Electrical equipment for measurement, control and laboratory use — EMC
requirements — Part 3‑1: Immunity requirements for safety-related systems and for equipment
intended to perform safety-related functions (functional safety) — General industrial applications
[49] IEC 61496-1:2020, Safety of machinery — Electro-sensitive protective equipment — Part 1: General
requirements and tests
[50] IEC 61496-2, Safety of machinery — Electro-sensitive protective equipment — Part 2: Particular
requirements for equipment using active opto-electronic protective devices
[51] IEC 61496-3, Safety of machinery — Electro-sensitive protective equipment — Part 3: Particular
requirements for active opto-electronic protective devices responsive to diffuse reflection (AOPDDR)
[52] IEC 61506, Industrial-process measurement and control — Documentation of software for process
control systems and facilities
[53] IEC 61508-1, Functional safety of electrical/electronic/programmable electronic safety-related
systems — Part 1: General requirements
[54] IEC 61508-2:2010, Functional safety of electrical/electronic/programmable electronic safety-
related systems — Part 2: Requirements for electrical/electronic/programmable electronic safety-
related systems
[55] IEC 61508-4:2010, Functional safety of electrical/electronic/programmable electronic safety-
related systems — Part 4: Definitions and abbreviations
[56] IEC 61508-5, Functional safety of electrical/electronic/programmable electronic safety-related
systems — Part 5: Examples of methods for the determination of safety integrity levels
[57] IEC 61508-6:2010, Functional safety of electrical/electronic/programmable electronic safety-
related systems — Part 6: Guidelines on the application of IEC 61508‑2 and IEC 61508‑3
[58] IEC 61508-7:2010, Functional safety of electrical/electronic/programmable electronic safety-
related systems — Part 7: Overview of techniques and measures
[59] IEC 61511-1:2016, Functional safety — Safety instrumented systems for the process industry sector
— Part 1: Framework, definitions, system, hardware and application programming requirements
[60] IEC 61558-2-16, Safety of transformers, reactors, power supply units and combinations thereof -
Part 2-16: Particular requirements and tests for switch mode power supply units and transformers
for switch mode power supply units for general applications
[61] IEC 61709,2)Electric components — Reliability — Reference conditions for failure rates and stress
models for conversion
[62] IEC 61784 (all parts), Industrial communication networks — Profiles
[63] IEC 61800-3, Adjustable speed electrical power drive systems — Part 3: EMC requirements and
specific test methods
[64] IEC 61800-5-2:2016, Adjustable speed electrical power drive systems — Part 5‑2: Safety
requirements — Functional
[65] IEC 61810-2-1, Electromechanical elementary relays — Part 2-1: Reliability — Procedure for the
verification of B10 values
[66] IEC 61810-3, Electromechanical elementary relays — Part 3: Relays with forcibly guided
(mechanically linked) contacts
[67] IEC 62021 (all parts), Insulating liquids — Determination of acidity
[68] IEC 62024 (all parts), High frequency inductive components — Electrical characteristics and
measuring methods
2) Identical to RDF 2000/Reliability Data Handbook, UTE C 80-810, Union Technique de l’Electricité et de la
Communication.
[69] IEC 62368-1, Audio/video, information and communication technology equipment — Part 1: Safety
requirements
[70] IEC 62502, Analysis techniques for dependability — Event tree analysis (ETA)
[71] IEC/TR 63074, Safety of machinery — Security aspects related to functional safety of safety-related
control systems
[72] EN 50495:2010, Safety devices required for the safe functioning of equipment with respect to
explosion risks
[73] ANSI B11.26:2018Functional Safety for Equipment: General Principles for the Design of Safety
Control Systems Using ISO 13849-1
[74] SN 29500 (all parts), Failure rates of components, Edition 1999-11, Siemens AG 1999s
[75] VDMA 66413, Functional Safety — Universal data format for safety-related values of components
or parts of control system
[76] VDMA 24584:2020, Safety functions of regulated and unregulated (fluid) mechanical systems
[77] Goble W.M., Control systems Safety Evaluation and Reliability. 3rd Edition:2010 (ISBN-
101934394807)
[78] IFA-Report 2/2017e, Functional safety of machine controls – Application of ISO 13849, German
Social Accident Insurance (DGUV), June 2009, ISBN 978‑3‑88383‑793‑2, free download in the
Internet: www.dguv.de/ifa/13849e
[79] Chinniah Yuvin2015) , Analysis and prevention of serious and fatal accidents related to moving
parts of machinery, Safety Science 75 (2015) 163–173
[80] Haghighi A., Jocelyn S., Chinniah Y.“, Testing and Improving an ISO 14119-Inspired Tool to
Prevent Bypassing Safeguards on Industrial Machines”; Safety, volume 6, issue 3, 2020 https://
www.mdpi.com/2313-576X/6/3/42
[81] IFA. “SISTEMA Cookbook 6: Definition of safety functions: what is important?” (https://w ww.dguv
.de/webcode.jsp?query=e109249)
[82] Reliability Prediction of Electronic Equipment, MIL-HDBK‑217E, Notice-2, Department of Defense,
Washington, DC, 1995
[83] British Handbook for Reliability Data for Components used in Telecommunication Systems, British
Telecom (HRD5, last issue)
[84] Chinese Military Standard GJB/Z 299C-2006 Reliability prediction handbook for electronic
equipment (English Version)
[85] EMC The easy way, Pocket guide, published by Division of Switching Devices, Switchboards and
Industrial Controls of the ZVEI (German Electrical and Electronic Manufacturer’s Association),
Frankfurt/Main, Germany (https://w ww.zvei.org/f ileadmin/user upload/Presse und Medien/
Publikationen/2008/Januar/EMC-Pocket-Guide-ZVEI-english.pdf)
ICS 13.110
Price based on 152 pages