Eneric Functional Safety Standards Vs Sector Specific Functional Safety Standards

Generic Safety Standards Versus Sector Standards
A report submitted
by
Md. Murtoza Siddiqui
Matriculation No. 35529590
Winter Semester 2019/2020
Course: Safety Standards and Norms of Electronic Systems

Master course: Functional Safety Engineering
Department of Electrical Engineering and Computer Science Computer Architecture and System
Programming
Universität Kassel
Submitted on 10 January 2020

Abstract
Every day the complexity in electrical and electronic systems, devices, and equipment used for safety
purposes is increasing at an unprecedented rate. This is because of the development of latest
technologies, researches, and discovering new solutions. This in turn is helping in creating new
electrical and electronic devices capable of handling intricate problems.
On the other hand, the requirements, specifications, definitions, and methodologies for functional safety
standards for safety related systems are changing too. In order to keep up with the new upgraded safety
related systems. As a matter of fact, the finding of new ways or technologies has led to developing
various products and services playing vital roles in our everyday life, which in turn made it necessary
to have different sector specific industries to meet our ever-increasing demand.
To keep those various industries in a safe state and efficient. It has become necessary to have different
sector specific safety standards derived or adapted from the original generic safety standards.
This report on 'Generic Safety Standards versus Sector Standards' has been presented to highlight and
inform some of the aspects of the generic safety standards and those of sector standards that have been
modified and tailored from the generic standards to render their specific safety functions.
i
Table of Contents
Abstract................................................................................................................................................... i
1 Executive Summary ...................................................................................................................... 1
2 Introduction ................................................................................................................................... 2
2.1 Background on Safety Standards ........................................................................................ 2
2.2 Introduction to the Thesis .................................................................................................... 2
3 Generic Safety Standards IEC 61508 .......................................................................................... 4
3.1 Introduction ........................................................................................................................... 4
3.2 IEC 61508-1 ........................................................................................................................... 6
3.3 IEC 61508-2 ......................................................................................................................... 12
3.4 IEC 61508-3 ......................................................................................................................... 16
3.5 IEC 61508-4 ......................................................................................................................... 21
3.6 IEC 61508-5 ......................................................................................................................... 22
3.7 IEC 61508-6 ......................................................................................................................... 26
3.8 IEC 61508-7 ......................................................................................................................... 31
3.9 Summary.............................................................................................................................. 31
4 Sector Standards ......................................................................................................................... 32
4.1 IEC 61511 - Process Industry ............................................................................................ 32
4.2 IEC 61513 - Nuclear Power Plants .................................................................................... 34
4.3 IEC 62061 - Machinery Sector ........................................................................................... 36
4.4 IEC 60601 - Medical Electrical Equipment ...................................................................... 37
4.5 IEC 61800 - Power Drive System....................................................................................... 38
4.6 ISO 26262 - Road Vehicles (Automotive E/E System) ..................................................... 38
4.7 EN 5012-6/8/9 - Rail ............................................................................................................ 40
4.8 DO-254 (Hardware) & DO-178 (Software) - Avionics..................................................... 40
5 Comment and Conclusion .......................................................................................................... 42
5.1 Comment.............................................................................................................................. 42
5.2 Conclusion ........................................................................................................................... 42
6 Acknowledgement ....................................................................................................................... 43
7 References .................................................................................................................................... 44
ii
List of Figures:
Figure 1: Overall framework of the IEC 61508 series [8] ...................................................................... 5
Figure 2: Primary causes of failures by phase [9] ................................................................................... 8
Figure 3: Safety life-cycle of IEC 61508 [8] .......................................................................................... 9
Figure 4: Hardware Safety life-cycle [10] ............................................................................................ 13
Figure 5: Hardware & Software Life-cycle comparison [10] ............................................................... 14
Figure 6: Software Safety life-cycle [11] .............................................................................................. 17
Figure 7: V-Model [11] ......................................................................................................................... 17
Figure 8: Risk reduction: General concept [12] .................................................................................... 22
Figure 9: Tolerable risk and ALARP concept [12] ............................................................................... 23
Figure 10: Example of a quantitative method for determining SIL [12] .............................................. 24
Figure 11: Shows the Risk graph [12] .................................................................................................. 25
Figure 12: Shows the Hazardous matrix [12] ....................................................................................... 26
Figure 13: The block diagram of 1oo1 Architecture [2] ....................................................................... 27
Figure 15: The block diagram of 1oo2D Architecture [2] .................................................................... 29
Figure 17: Structure of IEC 61511 [14] ................................................................................................ 33
Figure 18: General framework of IEC 61513 [15]................................................................................ 35
Figure 19: Overview structure of ISO 26262 [20] ................................................................................ 39
List of Tables:
Table 1: Shows SILs for low demand mode [7] ................................................................................... 10
Table 2: Shows SILs for high demand or continuous mode [7] ........................................................... 10
Table 3: Assessment independence [7] ................................................................................................. 11
Table 4: Assessment Independence for E/E/PES [7] ............................................................................ 11
Table 5: Annex-A Documentation format of IEC 61508 [7] ................................................................ 12
Table 6: Shows the SFF Chart for Type-A component [7] ................................................................... 15
Table 7: Shows the SFF chart for type-B component [7] ..................................................................... 15
Table 8: Risk classification of accidents [12] ....................................................................................... 23
Table 9: Elaborates interpretation of risk classes [12] .......................................................................... 24
Table 10: SIL derived from the requirements of IEC 62061 [17]......................................................... 36
Table 11: Risk factors of IEC 62061 [17] ............................................................................................. 36
Table 12: Risk Matrix of IEC 62061 [17] ............................................................................................. 37
Table 13: Design Assurance levels (DALs) [22] .................................................................................. 40
iii
1 Executive Summary
This report on generic safety standards versus sector standards has been presented as it represents a
certain evaluation grade for the master course on Functional Safety Engineering at the University of
Kassel, Germany.
The report highlights various features of the derivative sector specific standards and the generic or
"umbrella" safety standards.
In addition, this report provides information on some aspects of the sector standards and the generic
standards in a single set of documentation. Therefore, it could be used as a resourceful reference.
The report starts off with presenting some of the features of the generic standards IEC 61508 and its
seven parts. And goes on to discussing some of the features from the following sector standards: IEC
61511, IEC 61513, IEC 62061, IEC 60601, IEC 61800, ISO 26262, EN 5012-6/8/9, DO-254, and DO-
178B.
The contents of this report are composed from various sources including websites of relevant
organizations, books, research papers, and from relevant standards publications released by different
standardization body. Therefore, the scope of this report has been restricted by the availability of the
resources and the time constraints.
Finally, the report could be used as a handy reference resource future research on the similar topic.
1
2 Introduction
The main purpose of having functional safety in any safety electronic device or system is to ensure that
the automatic protection feature will perform its intended or its programmed function correctly.
Otherwise in the case of a failure, it guarantees that the devices or the system fail in a predictable or in
a safe manner. [1]
2.1 Background on Safety Standards
It is necessary for the proprietor of an industry to have proper safety management. If, in the event of a
failure or a mishap, the safety-related system does not respond according to the compliance of a standard
safety guidelines. The industry in question could be held liable for negligence and the matter could go
to trial in civil court. To avoid such undesirable situation, a proper safety technology that follows the
guidelines of an international standard has become essential for many sectors to operate without causing
hazards to people, environment or other relevant stakeholders. Thus, IEC in 1999 accorded and
published IEC 61508 as an international standard for safety for electrical, electronic and programmable
electronic system (E/E/PES). [2]
2.2 Introduction to the Thesis
Throughout its entire life cycle, safety must be considered starting from initial concept, to risk
assessment, design and engineering, operation and even to decommissioning. No harm, risk or hazard
may be posed to neither man, machine nor the environment. Possible failures or faults by the machine
which could lead to a hazard or a mishap, must be analyzed in detail. The aim is to determine measures
eliminating hazards or reducing the risks by applying Functional Safety to the systems in various
industries. [3]
In public spaces, factories, offices or homes; we are surrounded by an increasing number of electric and
electronic devices and systems. Many of them could cause harm to humans, animals or the environment
if they didn’t have built-in safety mechanisms that activate exactly when needed to reduce potential
risks down to a tolerable level.
Functional safety is part of the overall safety of a system or piece of equipment and generally focuses
on electronics and related software. It looks at aspects of safety that relate to the function of a device or
system and ensures that it works correctly in response to commands it receives. In a systemic approach
Functional safety identifies potentially dangerous conditions, situations or events that could result in an
accident that could harm somebody or destroy something. It enables corrective or preventive actions to
avoid or reduce the impact of an accident.
For example, when you enter a shop you want the automatic doors to open fast enough and close safely
behind you. If you walk slower than the programmed time, built-in sensors will make certain that the
door doesn’t close on you and protecting you from getting injured.
The aim of Functional safety is to bring risk down to a tolerable level and to reduce its negative impact;
however, there is no such thing as zero risk or complete risk-free state. Functional safety measures risk
by how likely it is that a given event will occur and how severe it would be. In other words, how much
harm it could cause in the event of a failure. [4]
2
However, safety, risk levels, risk reduction methodology, and overall functional safety of any systems
varies from industries to industries. Therefore, a generic or an umbrella-standard was initially created
which later paved the way for various sector specific standards.
Today, IEC 61508 is considered as the generic standard or the universal guideline for functional safety
of electrical, electronic, and programmable electronic (E/E/PE) safety related systems. IEC 61508
defines the standards necessary for fabricating safety related systems' hardware and software.
Industry specific standards which has been derived from IEC 61508 are as follows: IEC 61511, IEC
61513, IEC 62061, IEC 60601, IEC 61800, ISO 26262, EN 5012-6/8/9, DO-254 and DO-178B. [5]
It is therefore important to recognize that the IEC 61508 is a generic and can be used directly by various
industries and by international standards organizations as a reference for the development of different
sector specific standards for E/E/PE safety related systems.
This following sections of the report is mainly focused on some of the features of the generic standard,
IEC 61508 and its seven parts. [6]
3
3 Generic Safety Standards IEC 61508
3.1 Introduction
IEC 61508 is a generic safety publication of the International Electrotechnical Commission (IEC). As
such, it is also known as an “umbrella” document covering multiple industries and applications. A
primary objective of the standard is to help individual industries develop supplemental standards,
tailored specifically to those industries based on the original IEC 61508 standard. A secondary goal of
the standard is to enable the development of E/E/PE safety-related systems where specific application
sector standards do not already exist.
Several such industries whose specific standards have now been developed based on the framework
from the IEC 61508 and with more on the way are; IEC 61511 has been qualified for the process
industries, IEC 62061 addresses machinery safety, and IEC 61513 for the nuclear industry. All of these
standards are the derivative adaptations from IEC 61508 and reference it accordingly. [7]
Although IEC 61508 was initially criticized for its detailed documentation requirements and use of
unproven statistical techniques for hardware failures, many industries considered it as a progressive
step towards bringing change on how the industries used to operate without any sort of safety guidelines.
The standard focuses attention on risk-based safety-related system design, which should result in far
more cost-effective implementation. The standard also requires the attention to detail that is important
towards designing any safe system. Because of these features and the large degree of international
acceptance for a single set of documents, many consider IEC 61508 to be major advance for the
technical world which helped them to incorporate baseline safety standards into different sectors.. [7]
IEC 61508 does not cover safety issues like electric shock, hazardous falls, long-term exposure to a
toxic substance, etc.; these issues are covered by other pertinent standards. IEC 61508 also does not
cover low safety E/E/PE systems where a single E/E/PE system is capable of providing the necessary
risk reduction and the required safety integrity of the E/E/PE system is less than safety integrity level-
1, i.e., the E/E/PE system is only available 90 percent of the time or less. [7]
IEC 61508 has been divided into 7 sections. Sections or parts: 1, 2, 3, and 4 of IEC 61508, are basic
safety standards. And sections: 5,6, and 7 are for providing additional information on how to work with
and apply sections 1 to 4.
Sections: 1, 3, 4, and 5 of IEC 61508 standards were approved in 1998. While the sections: 2, 6, and 7
were approved in 2000. [7]
4
Figure 1: Overall framework of the IEC 61508 series [8]
5
3.2 IEC 61508-1
Part 1 of IEC 61508 covers the basic or the general requirements of the standard and provides a detailed
presentation of the safety life cycle. This section is the most important, as it provides overall
requirements for documentation, compliance, management of functional safety, and functional safety
assessment. Three annexes provide examples of documentation structure (Annex A), a personnel
competency evaluation (Annex B), and a bibliography (Annex C). [7]
IEC 61508-1 focuses on the general conformance requirements. It states, “To conform to this standard
it shall be demonstrated that the requirements have been satisfied to the required criteria specified (for
example: safety integrity level) and therefore, for each clause or sub-clause, all the objectives have been
properly met.” There is a statement that acknowledges that the “degree of rigor” (which determines if
a requirement has been met) depends on several factors, including the nature of the potential hazard,
degree of risk, etc.
Often, in providing proof of compliance involves listing all IEC 61508 requirements with an
explanation of how the requirement has been met. The high level of documentation for compliance is
consistent with the importance of keeping detailed records stressed throughout the standard.
The terminology of conformance in the standard is quite precise. If an item is listed as "shall be..." or
"must…", it is required for compliance. If an item is listed as "may be…" it is not specifically required
for compliance but explicit reasoning and explanation must be shown to justify its omission. [7]
The entire documentation must contain adequate information in order to make it possible for all phases
of the safety life-cycle, designs, verification tasks, safety management and safety investigation to be
implemented efficiently. The format of documentation should be accurate and to-the-point, making it
easy to understand. Moreover, it must be always accessible, useable, and upgradable. Certain section of
IEC 61508 specifies clearly what information has to be documented and in what manner. [2]
The required format for the documentation is as follows:
1. It must have sufficient information to effectively perform each phase of the safety life-cycle
and the associated verification tasks;
2. It must have adequate information to properly manage functional safety and support functional
safety assessment;
3. It must be accurate and to-the-point;
4. It must be easy to understand and follow;
5. It must satisfy the purpose for which it was intended;
6. It must be accessible and maintainable;
7. It must have titles, or names clearly mentioning the scope of the contents;
8. It must have a good table of contents and indexes;
9. It must have a reliable edition control system which will clearly identify or differentiate various
versions of each documentation and indicate revisions, amendments, reviews, and approvals.
[7]
Personnel or organization responsible for any phases, or for the whole life-cycle, must clearly specify
all the technical and management activities. This will ensure that the E/E/PES will achieve and will be
able to maintain the necessary functional safety. Among these activities the most important ones are:
the organization of the internal information exchange, the strategy for achieving desired functional
safety, and the qualifications of the personnel involved. [2]
Managing functional safety includes taking on various activities and responsibilities to ensure that the
functional safety objectives are achieved and maintained. These activities must be documented,
typically in a document called the functional safety management (FSM) plan. The FSM plan must
consider the following:
6
1. The overall strategy and methodology for achieving functional safety, including evaluation
methods and the way in which the process is communicated within the organization;
2. The identification of the authorities, departments, and organizations that are responsible for
carrying out and reviewing the applicable overall, E/E/PES, or software safety life cycle phases
(including, where relevant, licensing authorities or safety regulatory bodies);
3. The safety-life cycle phases to be used;
4. The documentation structure;
5. The measures and steps used for meeting the requirements;
6. The functional safety assessment activities to be performed and the safety life cycle phases
where they will be performed;
7. The procedures for follow-up and resolution of recommendations arising from hazard and risk
analyses, functional safety assessment, verification and validation activities;
8. The plan of action for ensuring that personnel are competent;
9. The procedures for ensuring that hazardous incidents (or near misses) are analyzed, and the
appropriate actions are taken to avoid repetition;
10. The methodologies for analyzing operations and maintenance performance, including periodic
functional safety inspections and audits; the inspection frequency and level of independence of
personnel to perform the inspection/ audit should be documented;
11. The action plan for management of change;
12. All those responsible for managing functional safety activities must be informed and aware of
their responsibilities. Suppliers providing products or services in support of any safety life-
cycle phase, shall deliver products or services as specified by those responsible for that phase.
These suppliers also shall have an appropriate quality management system. [7]
The safety life cycle can be viewed as a logical closed loop. The intended result is the optimum design
where the risk reduction provided by the safety-related system matches the risk reduction required by
the process.
The safety life cycle concept came from studies done by the Health Safety Executive (HSE) in the
United Kingdom, the report titled: "Out of control'. The HSE studied accidents involving industrial
control systems and classified accident causes out of total 34 incidents as shown in the Figure 2 below.
[7]
7
Figure 2: Primary causes of failures by phase [9]
From the analysis of the above figure-2, it suggests that most control system failures may have their
root cause in an inadequate specification.
In some case this was because insufficient hazard analysis of the equipment under control (EUC) had
been carried out; in others it was because the impact on the specification of a critical failure mode of
the control system had not been properly assessed. The control system needs to be continually reviewed
throughout all life-cycle phases, both from the perspective of the EUC and the detailed design and
implementation of the control system itself.
Otherwise, the end result is a machine, or plant, with inadequate protection against the hazard. And thus
remain as underlying cause which silently brewing an inevitable hazardous incident. [9]
The basic reason for creation of the safety life cycle were to be as a useful tool in the development of
safety-related control systems in order to address all the causes identified in the HSE study. The figure
3 below shows the overall safety life-cycle of IEC 61508. [7]
8
Figure 3: Safety life-cycle of IEC 61508 [8]
As shown in the figure 3 above, the first section of the safety life cycle, from boxes: 1 to 5, is known as
the analysis staged which considers the following:
1. Concept and scope of the system or equipment under control;
2. Hazard and risk analysis to identify both hazards and the events that can lead to a hazardous
incident;
3. Creation of overall safety requirements and identification of specific safety functions to prevent
the identified hazards or risks;
9
4. Safety requirements allocation, i.e., assigning the safety function to an E/E/PE safety-related
system, an external risk reduction facility, or a safety-related system of different technology.
This also includes assigning a safety integrity level (SIL) or risk reduction factor required for
each safety function. [7]
The middle part of the safety life-cycle, from boxes: 6 to 13, deals with the realization activities. This
mid-section of the safety life-cycle ensures that the safety system has been designed to completely
satisfy the target safety integrity level as defined from the Box-3: Hazard and risk analysis of the safety
life-cycle. This necessitates that a probabilistic calculation be done to verify that the design can meet
the Safety integrity levels (SILs) either in low demand mode or continuous mode of operations as shown
in the following tables1 and 2, respectively.
Safety Integrity Level (SIL) Low demand mode of Risk Reduction Factor
operation (Average probability (RFF)
of failure to perform its 1/PFD
intended function on demand)
PFD
4 ≥10-5 to < 10-4 100,000 to 10,000
3 ≥10-4 to < 10-3 10,000 to 1,000
2 ≥10 to < 10
-3 -2
1,000 to 100
1 ≥10-2 to < 10-1 100 to 10
Table 1: Shows SILs for low demand mode [7]
Safety Integrity Level (SIL) High demand or continuous mode of

operation (Probability of a dangerous failure
per hour) PFH
4 ≥10-9 to < 10-8
3 ≥10-8 to < 10-7
2 ≥10-7 to < 10-6
1 ≥10-6 to < 10-5
Table 2: Shows SILs for high demand or continuous mode [7]
SILs are discrete levels of risk reduction. There are four SIL levels as defined by the IEC 61508, where
SIL 1 has the lowest level of risk reduction and SIL 4 has the highest level of risk reduction. SILs are
specified by their mode of operations as well. As shown in above table 1 and 2, SIL values are different
for low demand mode and high demand or continuous mode of operations, respectively.
Also, the safety system must meet the detailed hardware and software implementation requirements
given in Parts; 2 and 3 of the IEC 61508. One of the most important factors to consider is the Safe
Failure Fraction calculation which can be found in the part-2 of IEC 61508. [7]
IEC 61508-1 also describes the functional safety assessment activities required by IEC 61508 standard.
The objective of the assessment is to investigate and arrive at a conclusion regarding the level of safety
achieved by the safety-related system. The process requires that one or more competent persons be
appointed to carry out a functional safety assessment. These individuals must be suitably independent
of those responsible for the functional safety being assessed, depending on the SIL and consequences
involved. The necessary requirements are shown in the following Tables: 3 and 4. [7]
10
Minimum level of independence Consequence
A B C D
Independent person HR HR NR NR
Independent department - HR HR NR
Independent organization - - HR HR
Normal consequences could be:
Consequence A: Minor injury (for example, temporary loss of function);
Consequence B: Serious permanent injury to one or more persons, death to one person;
Consequence C: Death to several people;
Consequence D: Several fatalities.
Legends: HR- Highly recommended; NR- Not recommended
Table 3: Assessment independence [7]
Minimum level of independence Safety Integrity Level (SIL)

1 2 3 4
Independent person HR HR NR NR
Independent department - HR HR NR
Independent organization - - HR NR
Table 4: Assessment Independence for E/E/PES [7]
The functional safety assessment shall include all phases of the safety life cycles. The assessment must
consider the life cycle activities carried out and the outputs obtained. The assessment may be done in
parts after each activity or group of activities. The main requirement is that the assessment be done
before the safety-related system is needed to protect against a hazard.
The functional safety assessment must consider:
1. All work done since the previous functional safety assessment;
2. The plans for implementing further functional safety assessments;
3. The recommendations of the previous assessments including a check to verify that the changes
have been made.
The functional safety assessment activities shall be consistent and planned. The plan must specify the
personnel who will perform the assessment, their level of independence, and the competency required.
The assessment plan must also state the scope of the assessment, outputs of the assessment, any safety
bodies involved, and the resources required. At the conclusion of the functional safety assessment,
recommendations shall indicate acceptance, qualified acceptance, or rejection. [7]
The documentation must contain enough information to effectively perform each phase of the safety
life cycle, manage functional safety, and allow functional safety assessments. However, IEC 61508
does not specify any documentation structure. Users have flexibility in choosing their own
documentation structure if it meets the criteria described earlier. An example set of documents for a
safety life cycle project is shown in the table 5 below. [7]
11
Safety Life-cycle Phases Information needs to be documented
Safety requirements Safety requirements specification (including safety
functions and safety integrity levels)
E/E/PES Validation planning Validation Plan
E/E/PES Design and development Architecture Design Description (Hardware and
E/E/PES Architecture Software);
Hardware Architecture Specification (Integration tests)
Hardware Module Design Hardware Architecture Design Description;
Component construction and/or Procurement Detail Design Specifications Hardware modules;
Report (Hardware Modules test)
Programmable electronic integration Integration Report
E/E/PES Operation and Maintenance Procedures Operation and Maintenance Instructions
E/E/PES Safety Validation Validation Report
E/E/PES Modification E/E/PES Modification Procedures;
Modification Request;
Modification Report;
Modification Log
Concerning all phases Safety Plan;
Verification Plan and Report;
Functional Safety Assessment Plan and Report.
Table 5: Annex-A Documentation format of IEC 61508 [7]
IEC 61508 specifically states, “All persons involved in any overall, E/E/PES or software safety life
cycle activity, including management activities, should have the appropriate training, technical
knowledge, experience and qualifications relevant to the specific duties they have to perform. It is
recommended that a number of things be considered in the evaluation of personnel qualification. These
are:
1. Engineering knowledge in the application;
2. engineering knowledge appropriate to the technology;
3. safety engineering knowledge appropriate to the technology;
4. knowledge of the legal and safety regulatory framework;
5. the consequences of safety-related system failure;
6. the assigned safety integrity levels of safety functions in a project;
7. experience and its relevance to the job assigned.
8. Also, the training, experience, and qualifications of all personnel should be documented. [7]
A list of many related IEC standards, ISO standards, and other relevant references is provided in this
annex of the IEC 61508. [7]
3.3 IEC 61508-2
The IEC 61508-2 applies to all safety-related systems, which fall under the definition in part-1 of the
IEC 61508. It makes additional requirements on the hardware. Moreover, requirements are specified
for all activities, which are mandatory during the developmental and manufacturing process for
hardware. This does not include extant system software, which is discussed in the part-3 of IEC 61508.
[2]
As in other parts of the standard, a safety life cycle is to be used as the basis of requirement compliance.
The hardware safety life cycle is an expanded plan for box 9 of the overall safety life cycle from Part-
1 of IEC 61508 that is focused on the design of the control hardware for safety systems. As for the
overall safety life-cycle, there are requirements for a functional safety management plan and safety
12
requirements specification including all verification and assessment activities which are shown in the
following figure 4 and figure 5. [7]
Figure 4: Hardware Safety life-cycle [10]
13
Figure 5: Hardware & Software Life-cycle comparison [10]
The safety requirements specification shall include details on both the safety function and the safety
integrity level of that function. Some of these safety function details are:
1. How safe state is achieved;
2. Operator interfaces;
3. Required E/E/PES behavior modes;
4. Response time;
5. Operating modes of equipment under control;
6. Start-up requirements.
Some of the safety integrity level details are:

1. SIL for each function;
2. Environmental extremes;
3. High or low demand class for each function;
4. Electromagnetic immunity limits.
One aspect of the hardware design and development requirements is the limit on the safety integrity
level achievable by any level of fault tolerant safety redundancy. These are shown in the following
tables for various fractions of failures leading to a safe state. [7]
14
Safe failure fraction Hardware fault tolerance (HFF) (see note 1)
(SFF)
0 1 2
< 60% SIL 1 SIL 2 SIL 3
60% to < 90% SIL 2 SIL 3 SIL 4
90% to < 99% SIL 3 SIL 4 SIL 4
≥ 99% SIL 3 SIL 4 SIL 4
Note 1: A hardware fault tolerance of N means that N+1 faults could cause a loss of the safety
function.
Table 6: Shows the SFF Chart for Type-A component [7]
Safe failure fraction Hardware fault tolerance (HFF) (see note 1)

(SFF)
0 1 2
< 60% Not Allowed SIL 1 SIL 2
60% to < 90% SIL 1 SIL 2 SIL 3
90% to < 99% SIL 2 SIL 3 SIL 4
≥ 99% SIL 3 SIL 4 SIL 4
Note 1: A hardware fault tolerance of N means that N+1 faults could cause a loss of the safety
function.
Table 7: Shows the SFF chart for type-B component [7]
Type-A components: are described as simple devices with well-known failure modes and a solid history
of operation.
Type-B components: are complex components with potentially unknown failure modes, i.e.,
microprocessors, ASICs, etc. [7]
This annex qualifies claims that can be made for self-diagnostic capabilities and also recommends
methods of failure control. Numerous types of failures are addressed including random, systematic,
environmental, and operational failures. It should be noted that following these methods do not
guarantee that a given system will meet a specific SIL. [7]
In this annex, numerous tables present recommended techniques for different life cycle phases to
achieve different SILs. Again, simply using these techniques do not guarantee a system will achieve a
specific SIL. [7]
In this annex, a basic procedure is described for calculating the fraction of failures that can be self-
diagnosed and the fraction that result in a safe state. [7]
15
3.4 IEC 61508-3
IEC 61508-3 refers to each software system which is either a part of a safety-related E/E/PES or an
application used during its development. [2]
Software Requirements:
As in other parts of the standard, a safety life cycle is to be used as the basis of requirement compliance.
The software safety life cycle is an expanded plan for Box 9 of the overall safety life-cycle of IEC
61508-1 and is closely linked with the hardware life cycle. As for the overall safety life cycle, there are
requirements for a functional safety management plan and safety requirements specification, including
all verification and assessment activities.
Here the functional safety is addressed in the context of a software quality management system (QMS).
A detailed functional safety plan is presented as part of this QMS. As in other parts of the standard, the
same key features of change management, demonstration, and documentation are present.
A software functional safety plan (either as a part of other documentation or as a separate document)
shall define the strategy for the software procurement, development, integration, verification,
validation, and modification as required for the SIL level of the safety-related system. The plan must
specify a configuration management system.
This software configuration management system must:
1. Manage software changes to ensure that the specified requirements for software safety are
satisfied;
2. guarantee that all necessary activities have been carried out to demonstrate that the required
software safety integrity has been achieved;
3. accurately maintain all documentation and source code including the safety analysis and
requirements; software specification and design documents; software source code modules; test
plans and results; commercial off the shelf (COTS) and preexisting software components which
are to be incorporated into the E/E/PE safety-related system; all tools and development
environments which are used to create or test, or carry out any action on, the software of the
E/E/PE safety-related system;
4. prevent unauthorized modifications;
5. document modification/ change requests;
6. analyze the impact of a proposed modification;
7. approve or deny the modification request;
8. establish baseline software and document the (partial) integration testing that justifies the
baseline;
9. formally document the release of safety-related software.
In addition, master copies of the software and all documentation should be maintained throughout the
operational lifetime of the released software. [7]
IEC 61508 has a considerable but appropriate number of requirements for safety critical software put
forth in the details of the software safety life cycle framework. The major phases of the software safety
life cycle are shown in the figure 6 below.
IEC 61508-3 requires that a process (such as the safety life cycle) for the development of software shall
be selected and specified during safety planning. Note that the exact process is not specified, it may be
customized according to company preference. Appropriate quality and safety assurance procedures
must be included. Each step of the software safety life cycle must be divided into elementary activities
with the functions, inputs, and outputs specified for each phase. [7]
16
Figure 6: Software Safety life-cycle [11]
IEC 61508 has complete details of an example software safety life cycle. Many practitioners use a
version of the V-model as shown in the figure 7 below. [7]
Figure 7: V-Model [11]
17
Software Safety Requirements Specification:
The functional safety requirements for software must be specified. This can be done in a separate
document or as part of another document. The specification of the requirements for software safety shall
be derived from the specified safety requirements of the safety-related system and any requirements of
safety planning.
The requirements for software safety shall be sufficiently detailed to allow design and implementation
and to allow a functional safety assessment. The software developers should review the document to
verify that it contains sufficient details. It should be noted that this is often another iterative process.
The requirements must be clear, precise, verifiable, testable, maintainable, and feasible. The
requirements must also be appropriate for the safety integrity level. and traceable back to the
specification of the safety requirements of the safety-related system. Terminology must be clear and
understandable by those using the document. All modes of operation for the safety-related system must
be listed. The requirements must detail any relevant constraints between the hardware and the software.
Since the software is often called upon to perform much of the on-line diagnostics, the requirements
must detail all software self-monitoring, any diagnostic tests performed on the hardware, periodic
testing of critical functions, and means for on-line testing of safety functions. If the software also
performs non-safety functions, means to insure that the software safety is not compromised (non-
interfering) must also be specified. [7]
Software Safety Validation Planning:

A plan must be set up to demonstrate that the software satisfies the safety requirements set out in the
specification. A combination of analysis and testing techniques is allowed, and the chosen techniques
must be specified in the plan. The plan must consider the following:
1. Required equipment;
2. when validation will be done;
3. who will do the validation;
4. the modes of operation to be validated including start up, teach, automatic, manual,
semiautomatic, steady state of operation, re-set, shut down, and maintenance;
5. reasonably foreseeable abnormal conditions;
6. identification of the safety-related software that needs to be validated;
7. specific reference to the specified requirements for software safety;
8. expected results and pass/ failure criteria.
Moreover, the plan must show how assessment will be done, who will review the plan, and the
assessor’s level of independence. [7]
Design methods shall be chosen that support abstraction, modularity, information hiding, and other
good software engineering practices. The design method shall allow clear and unambiguous expression
of functionality, data flow, sequencing, and time-dependent data, timing constraints, concurrency, data
structures, design assumptions, and their dependencies.
During design, the overall complexity of the design, its testability, and the ability to make safe
modifications shall be considered. The entire design is considered safety-related even if non-safety
functions are included unless sufficient independence between safety and non-safety can be
demonstrated. If different safety integrity levels are part of the design, the overall design is only valid
for the least stringent SIL of the component parts.
The design must include software functions to execute proof tests and all on-line diagnostic tests as
specified in the requirements. Software diagnostics shall include monitoring of control flow and data
flow.
18
The architectural design defines the major components and subsystems of the software. The
architectural design description must include:
1. interconnections of these components;
2. the “techniques and measures” necessary during the software safety life cycle phases to satisfy
requirements for software safety at the required safety integrity level including software design
strategies for fault tolerance and/ or fault avoidance (redundancy/ diversity);
3. the software safety integrity level of the subsystem/component;
4. all software/hardware interactions and their significance;
5. the design features for maintaining the safety integrity of all data;
6. software architecture integration tests to ensure that the software architecture satisfies the
requirements for software.
It is assumed and permitted that iteration occurs between the design and the requirements phases. Any
resulting changes in requirements must be documented and approved.
Support tools and programming languages must meet the safety integrity needs of the software. A set
of integrated tools, including languages, compilers, configuration management tools, and, when
applicable, automatic testing tools, shall be selected for the required safety integrity level.
Detailed design and coding shall follow the software safety life cycle. Coding standards shall be
employed and must specify good programming practice, prohibit unsafe language features, and specify
procedures for source code documentation including:
1. legal entity;
2. description;
3. inputs and outputs;
4. configuration management history.
Also, the software code must be:

1. readable, understandable, and testable;
2. able to satisfy the specified requirements;
3. reviewed;
4. tested as specified during software design. [7]
Tests of the integration between the hardware and software are created during the design and
development phases and specify the following:
1. test cases and test data in manageable integration sets;
2. test environment, tools, and configuration;
3. test criteria;
4. procedures for corrective action on failure of test.
The integration testing results shall state each test and the pass/ failure results. [7]
Software validation is done as an overall check to ensure that the software design meets the software
safety requirements and must include the appropriate documentation. The validation may be done as
part of overall system validation or it may be done separately for the software. Testing must be the
primary method of validation with analysis used only to supplement. All tools used in the validation
must be calibrated and an approved quality system must be in place.
If validation is done separately for the software, the validation must follow the software safety
validation plan. For each safety function, the validation effort shall document:
1. A record of the validation activities;
19
2. the version of the software safety validation plan;
3. the safety function being validated with reference to planned test;
4. test environment (tools and equipment);
5. the results of the validation activity with discrepancies, if any.
If discrepancies occur, a change request must be created and an analysis must be done to determine if
the validation may continue. [7]
Operation and modification:

Software modification requires authorization under the procedures specified during safety planning and
must insure that the required safety integrity level is maintained. This authorization must address:
1. the hazards that may be affected;
2. the proposed change;
3. the reasons for change.
The modification process starts with an analysis on the impact of the proposed software modification
on functional safety. The analysis will determine how much of the safety life cycle must be repeated.
[7]
Software Verification:
The software verification process tests and evaluates the results of the software safety life cycle phases
to insure they are correct and consistent with the input information to those phases. Verification of the
steps used in the software safety life cycle must be performed according to the plan and must be done
concurrently with design and development. The verification plan must indicate the activities performed
and the items to be verified (documents, reviews, etc.). A verification report must include an explanation
of all activities and results. Verification must be performed on:
1. software safety requirements;
2. software architecture design;
3. software system design;
4. software module design;
5. software source code;
6. data;
7. software module testing;
8. software integration testing;
9. hardware integration testing;
10. software safety requirements testing (software validation). [7]
Annex-A: Guide to the selection of techniques and measures. This section of the IEC 61508-3 provides
ten tables of different techniques relevant to the software safety requirements, software design and
development, architecture design, support tools and programming languages, detailed design, software
module testing, integration testing, safety validation, modification and functional safety assessment.
Different techniques are “recommended” or “highly recommended” as a function of safety integrity
level required. Some techniques are used alone or in combination with other techniques to show
compliance with the standard. [7]
20
Annex-B: Detailed tables. This annex of IEC 61508-3 provides nine tables of detailed techniques for
design and coding standards, dynamic analysis and testing, functional and black box testing, failure
analysis, modeling, performance testing, semi-formal methods, static analysis, and modular approaches.
These tables are also referenced in the tables from Annex-A. [7]
3.5 IEC 61508-4
IEC 61508-4 contains the abbreviations and definitions of all terms used in IEC 61508 standards this
includes everything mentioned from part-1 to part-7 of IEC 61508. [2]
Some of the selected key definitions are as follows:
a) Diversity - different means of performing a required function.
b) Equipment under control (EUC) - equipment, machinery, apparatus, or plant used for
manufacturing, process, transportation, medical, or other activities.
c) Functional safety - part of the overall safety relating to the EUC and the EUC control system
which depends on the correct functioning of the E/E/PE safety-related systems, other
technologies safety-related systems, and external risk reduction facilities.
d) Harm - physical injury or damage to the health of people either directly or indirectly as a result
of damage to property or to the environment.
e) Hazard - potential source of harm.
f) Limited variability language - software programming language, either textual or graphical, for
commercial and industrial programmable electronic controllers with a range of capabilities
limited to their application.
g) Redundancy - means, in addition to the means which would be sufficient, for a functional unit
to perform a required function or for data to represent information.
h) Risk - combination of the probability of occurrence of harm and the severity of that harm.
i) Safety - freedom from unacceptable risk.
j) Safety function - function to be implemented by an E/E/PE safety-related system, other
technology safety-related system, or external risk reduction facilities which is intended to
achieve or maintain a safe state for the EUC, with respect to a specific hazardous event.
k) Safety integrity - probability of a safety-related system satisfactorily performing the required
safety functions under all the stated conditions within a stated period of time.
l) Safety integrity level (SIL) - One of four discrete levels for specifying the safety integrity
requirements of the safety functions to be allocated to the E/E/PE safety-related systems, where
safety integrity level 4 has the highest level of safety integrity and safety integrity level 1 has
the lowest.
m) Safety life cycle - necessary activities involved in the implementation of safety-related systems,
occurring during a period of time that starts at the concept phase of a project and finishes when
all of the E/E/PE safety-related systems, other technology safety-related systems, and external
risk reduction facilities are no longer available for use.
n) Safety-related system - designated system that implements the required safety functions
necessary to achieve or maintain a safe state for the EUC; and is intended to achieve, on its own
or with other E/E/PE safety-related systems, other technologies safety-related systems or
external risk reduction facilities, the necessary safety integrity for the required safety functions.
o) Systematic failure - failure 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.
p) Tolerable risk - risk which is accepted in a given context based on the current values of society.
[7]
21
3.6 IEC 61508-5
IEC 61508-5 primarily consists of Annexes from A-E and provides an overview of the underlying risk
concepts, and the relationship between risk and safety integrity. Moreover, various methodologies are
explained for determining the safety integrity level. [2]
Annex-A: General Concepts. The required risk reduction, the role of the E/E/PES, the safety integrity,
as well as the safety integrity level are defined and described. The figure 8 below shows the concept of
risk reduction down to the remaining residual risk. The residual risk must always be smaller than the
tolerable risk. The tolerable risk depends on the following factors: Severity of injury; number of people
who are exposed to the danger; frequency; and duration of exposure to the risk. [2]
Figure 8: Risk reduction: General concept [12]
22
Annex-B: ALARP and the concept of tolerable risk. In the figure 9 below shows the ALARP (As Low
As Reasonably Practicable) concept of IEC 61508. [2]
Figure 9: Tolerable risk and ALARP concept [12]
Frequency Consequence
Catastrophic Critical Marginal Negligible
Frequent I I I II
Probable I I II III
Occasional I II III III
Remote II III III IV
Improbable III III IV IV
Incredible IV IV IV IV
Table 8: Risk classification of accidents [12]
From the table 8 shown above on the risk classification of accidents the following points are interpreted:
Risk class I is in the unacceptable region;
Risk classes II and III are in the ALARP region, risk class II being just inside the ALARP region;
Risk class IV is in the broadly acceptable region. [12]
23
Risk Class Interpretation
Class I Intolerable risk
Class II Undesirable risk, and tolerable only if risk reduction is impracticable or if the
costs are grossly disproportionate to the improvement gained
Class III Tolerable risk if the cost of risk reduction would exceed the improvement
gained
Class IV Negligible risk
Table 9: Elaborates interpretation of risk classes [12]
Annex-C: Quantitative methods for determining the Safety Integrity Level. This section of the annex
shows the calculation involved in determining the safety integrity levels. With the help of an example
of a quantitative method shown in the figure 10 below. For this, the tolerable risk is linked to the risk
of the EUC in a systematic manner, in order to determine the required risk reduction: [2]
PFDAVG = Ft ÷ Fnp = ∆R
With the following definitions
PFDAVG: Average probability of failure of the safety-related protection system on low demand mode
operation
Ft: Tolerable risk frequency
Fnp: Classification grade/demand rate of the safety-related device
∆R: Required risk reduction [2]
Figure 10: Example of a quantitative method for determining SIL [12]
24
Annex-D: Qualitative methodology for determining the safety integrity level. This section of the IEC
61508-5 explains the qualitative method for determining the safety integrity level with the help of a risk
graph as shown in the figure 11 below. [2]
Figure 11: Shows the Risk graph [12]
Annex-E: Specification of the Safety Integrity Level, a qualitative method using matrix of a dangerous
event. In the event, the methodology mentioned in Annex-C of IEC 61508-5 cannot be applied because
of the lack of quantitative information of the risk factors. Then the qualitative method for determining
the SIL using the matrix of a dangerous (dangerous) event as shown in the figure 12 below can be used.
[2]
25
Figure 12: Shows the Hazardous matrix [12]
3.7 IEC 61508-6
IEC 61508-6 provides information, guidelines, and examples for the application of IEC 61508-2 and
IEC 61508-3. This section contains detailed explanations for the quantitative calculation of the E/E/PES
in the following format:
▪ Block diagram and formula for PFD calculation and PFH calculation.
▪ Table for determining the β-factor (β: percentage of unknown malfunctions resulting from the
common cause).
▪ Tables for estimating the diagnostic coverage.
▪ Tables with calculated PFD and PFH numbers for all system configurations shown in the IEC
61508, with variants in all relevant parameters. [2]
Annex-A: Application of IEC 61508-2 and -3. This section contains a short overview of the contents
of IEC 61508 from parts 1 to 3. Also, individual functional procedures are explained for the application
of IEC 61508-2 and IEC 61508-3 for hardware and software development, respectively. [2]
Annex-B: Examples on procedures for determining hardware failures. There are several methods for
the analysis of safety integrity of safety-related E/E/PES. Some of the common methods are reliability
block diagrams and Markov models. Both methods render similar results, however reliability block
diagrams for complex PES give less accurate result than Markov models.
26
The probability of failure of a safety function of the E/E/PES, for the low demand operation mode, is
determined by finding medium probabilities of the each sub-system's failure and adding the results as
shown in the equation below: [2]
PFDsys = PFDS + PFDL + PFDFE
Where:
PFDsys: is the probability of the failure of a safety function during demand
PFDS: is the probability of failure during demand of a safety function
PFDL: is the probability of failure on demand for the logic system
PFDFE: is the probability of failure on demand for the output subsystem [2]
In order to calculate the medium failure probability for each subsystem, the following must be
determined:
▪ The underlying architecture (for example: 1oo2D, 2oo3, etc.).
▪ The diagnostic coverage of each channel.
▪ The failure rate per hour λ for each channel.
▪ The β-factors β and βD for failures resulting from the common cause. [2]
Different Architectures, their block diagrams and the calculation of probability for each architecture
operating on low demand mode are as follows:
1oo1 Architecture, consists of a single channel where every dangerous error lead to a failure of the
safety function. The figure 13 below shows the 1oo1 Architecture. [2]
Channel
Diagnosis
Figure 13: The block diagram of 1oo1 Architecture [2]
For 1oo1 Architecture, the probability of failure operating on low demand mode is as follows:
PFDAVG = (λDD + λDU) × tCE
27
Where;
λDD: is the rate of dangerous failures
λDU: is the rate of undetected dangerous failures
tCE: is the failure duration of a channel [2]
1oo2 Architecture has two channels in parallel and each channel can perform safety function. The
figure 14 below shows the 1oo2 Architecture. [2]
For 1oo2 Architecture, the probability of failure operating on low demand mode is calculated as follows:
T1
PFDAVG = 2{(1- βD)λDD +(1-β) λDU}2 tCE tGE + βD λDD MTTR + βλDU [ 2 + MTTR]
Where,
tGE: is the failure duration for group equivalent
MTTR: Mean time to repair [2]
In the 1oo2D Architecture two parallel channels are observed by a diagnosis unit. If a fault is detected
in any channel, then the total output is done exclusively through the intact channel. Only if faults are
found in both channels, or an error cannot be linked to any channel then the output goes into a safe state
or shutdown. The figure 15 below shows the 1oo2D Architecture. [2]
28
Figure 15: The block diagram of 1oo2D Architecture [2]
The probability of failure for 1oo2D Architecture operating in low demand mode is as follows:
T1
PFDG = 2(1- β)λDU {(1- β)λDD +(1- βD) λDU + λSD } tCE tGE + βD λDD MTTR + βλDU [ 2 + MTTR] [2]
2oo2 Architecture has two parallel-switched channels as shown in the figure 16 below. Both the
channels must request the safety function before it can be executed. [2]
The probability of failure for 2oo2 Architecture operating on low demand mode is as follows:
PFDG = 2 λD tCE [2]
29
2oo3 Architecture has three parallel-switched channels and with a majority voting arrangement for the
output signal. So, the output is not changed if only one channel gives a discrepant value. The output
depends on at least results from two channels. The probability of failure for 2oo3 Architecture operating
on low demand mode is as follows:
T1
PFDG = 6{(1- βD)λDD +(1-β) λDU}2 tCE tGE + βD λDD MTTR + βλDU [ + MTTR] [2]
2
The methodologies for calculating the probability per hour for E/E/PES operating on high demand or
continuous mode is similar to those of operating on low demand mode and the equation is shown below:
PFDsys = PFDS + PFDL + PFDFE
For E/E/PES working on high demand or continuous mode, the abovementioned various Architecture
modes are applicable. Their block diagram schematics are like those for operating on low demand mode.
The formulas for calculating the probability of failure on high demand modes are as follows:
For 1oo1 Architecture:
PFHG = λDU

PFHG = 2{(1- βD)λDD +(1-β) λDU}2 tCE + βD λDD + βλDU
For 1oo2D Architecture:

PFHG = 2(1- β)λDU {(1- β)λDD +(1- βD) λDU + λSD } tCE + βD λDD + βλDU

PFHG = 2 λDU

PFDG = 6{(1- βD)λDD +(1-β) λDU}2 tCE + βD λDD + βλDU [2]
Annex-D: Methods for quantifying the consequences of hardware failures due the common cause in
E/E/PES. This procedure is used to calculate β, a factor which is used numerously in model building of
failures caused by the common cause. This is done by calculating the rate of accidental hardware
malfunctions. And this annex explains the entire methodology for calculating the β factor. [2]
30
3.8 IEC 61508-7
IEC 61508-7 provides descriptions and an explanation of the many engineering techniques presented
in the earlier sections of the IEC 61508 standard. [7]
Annex-A: Overview of techniques and measures for E/E/PES: control of random hardware failures.
This annex addresses random hardware failures. It contains methods and techniques useful to prevent
or maintain safety in the presence of component failures. The explanations provided here support many
of the recommended techniques listed in the hardware tables in IEC 61508-2. [7]
Annex-B: Overview of techniques and measures for E/E/PES; Avoidance of systematic failures. This
annex covers the avoidance of systematic failures in both hardware and software systems and is
referenced by IEC 61508-2 and IEC 61508-3. It is structured according to the safety life cycle and
addresses numerous points relevant to the key phases. [7]
Annex-C: Overview of techniques and measures for achieving software safety integrity. This annex
provides an overview of techniques for achieving high software safety integrity. Many of these
techniques fall into the detailed design phase of the life cycle. Architectural design issues are also
addressed as well as development tools and programming languages. The annex also addresses the
verification, modification, and functional safety assessment phase of the life cycle. [7]
Annex-D: Probabilistic approach to determining software safety integrity for pre-developed software.
This annex covers a probabilistic approach for SIL determination of proven software. With many
systems seeking to employ previously written software, this annex can be valuable. It lists several tests
to determine the integrity level of the software based on statistical analysis. [7]
3.9 Summary
IEC 61508 and its seven parts' implementation offer a systematic approach and a safe and economic
method for the development of E/E/PE safety-related systems. That can be used as a generic procedure
and can be applied to various sector-specific standards as a guidance to achieve their required functional
safety. [6]
31
4 Sector Standards
The main objective of sector specific standards that have been adapted from the generic functional
safety standard IEC 61508 is to define and provide specifications for the proper execution of functional
safety of E/E/PES used in protection systems designed specifically for that particular industry's safety.
Though sector specific standards are derived from the same generic standard, their application,
definition, qualification, methodology, and specification are interpreted differently.
This section of the report discusses and highlights some of the notable sector specific standards and
their methodologies that have been adapted from the IEC 61508 generic standards.
4.1 IEC 61511 - Process Industry
The IEC 61511 is the safety standard specifically used for process industry. And it is tailored for clients,
end-users, and for engineering partners and integrators of safety instrument system. Whereas IEC 61508
is used as a generic standard for product and device manufacturers or designers of safety-related system.
This is the basic difference between IEC 61508 and IEC 61511. IEC 61511 describes the requirements
on how to install, integrate, operate, maintain and repair the safety instrumented systems.
IEC 61511 has been divided into three sections and they are as follows:
1. IEC 61511-1 focused on framework, definitions, system, hardware and software requirements
2. IEC 61511-2 provides the guidelines on the application of IEC 61511-1
3. IEC 61511-3 describes the methods for calculating the required safety integrity levels. [13]
The IEC 61511 put emphasis on the determination of requirements of safety instrumented systems in
the process industry. And it only focuses on the devices, systems, and application software which are
particularly used for safety instrumented system. The figure 17 below shows how the IEC 61511 is
structured. [2]
32
Figure 17: Structure of IEC 61511 [14]
33
4.2 IEC 61513 - Nuclear Power Plants
IEC 61513 defines the requirements for instrumentation and control systems (I&C systems) that are
necessary to perform the safety functions in nuclear power plants (NPPs). It primarily focuses on the
interrelation between the safety goals of the NPP, and the essentials of the general architecture of the
I&C systems needed for safety and the requirements of the individual systems used for safety. Also, it
is made as a guidance specifically for designers, engineers, developers, operators of NPP, system
evaluators and by license providers. Concerning the continuing application of IEC 61513 it is important
to note that IEC 61513 does not provide any additional functional requirements for safety systems other
than those specifically mentioned in the document. And for future application the IEC 61513 has given
importance on the publications of its concepts rather than identifying specific technologies for the NPP
safety functions. [15]
IEC 61513 defines the requirements and provides recommendation for the general I&C architecture
which may consist of conventional hard-wired equipment or computer-based (CB) equipment or
consisting of both technologies. In addition, IEC 61513 focuses on the comprehensive or specific
requirements for general I&C architecture and for the individual I&C systems used for safety purposes
by analyzing the safety targets.
Moreover, IEC 61513 clarifies the requirements for the overall I&C architecture and the requirements
of the individual systems for safety function by describing the safety goals of the NPP. It does that
through the introduction of the concept of a safety life cycle for the general I&C architecture and for
the individual systems. And it is not limited only for the use of I&C for new NPP but it can as well be
used for I&C up-gradation or retrofitting of currently operational or existing NPPs. And for existing
NPPs, only a subset of requirements is applicable and this subset must be declared clearly at the
beginning of any project. [15]
Structure of IEC 61513

IEC 61513 consists of four derivative clauses:
1. Clause 5 describes the general I&C systems architecture used for safety. It clearly states the
structuring, requirements, classification, plant lay-out, and operational manual of the I&C
functions and other related systems and devices identified from the safety analysis of the NPP;
2. Clause 6 is focused on the requirements of the computer-based technology used for safety
functions including the requirement of the individual safety I&C systems;
3. Clauses 7 & 8 define the comprehensive integration, commissioning, operation and
maintenance of the I&C systems.
In addition to the above four clauses the IEC 61513 also have five annexes:
1. Annex-A emphasizes the relation between International Atomic Energy Agency (IAEA) and
the basic safety principles that are applied in IEC 61513;
2. Annex-B gives the information on the classification concepts;
3. Annex-C provides examples of I&C that are sensitive to common cause failures;
4. Annex-D substantiates the relation between IEC 61513 with parts 1, 2, and 4 of IEC 61508.
This annex analyzes and justifies that the methods used in IEC 61513 is in line with the proper
safety functions mentioned in IEC 61508 and uses the prescriptive methodology. Otherwise,
provides explanation or reasons for adopting different techniques or terms;
5. Annex-E explains the steps for future modification of IEC 61513 in order to make future
versions consistent and to reduce vagueness.
The following figure 18 shows the general framework of IEC 61513 [15]
34
Figure 18: General framework of IEC 61513 [15]
35
4.3 IEC 62061 - Machinery Sector
IEC 62061 for safety of machinery-Functional safety of safety-related electrical, electronic and
programmable electronic control systems (SRECS) consists of the specifications from IEC 61508
generic standard. Furthermore, it narrow downs the safety requirement of both hardware and software
and thus make them appropriate for particular requirements of industrial devices to execute safety
functions. The safety requirements of IEC 62061 consider only high demand mode or continuous mode
of operations in other words, in cases where the request for safety function is more than once per year.
IEC 62061 is focused on two basic concepts:
1. Management of Functional Safety; and
2. Safety Integrity Level. [16]
IEC 62061 defines a comprehensive design specification required to achieve the required functional
safety level, starting from concept, allocation of safety requirements, documentation, design planning
up to validation. Every model has its own functional safety plan clearly written, documented, and
carefully revised as deemed necessary. In addition, the functional safety of IEC 62061 identifies people,
operations, processes, and resources needed for development and application of the safety system. [16]
Safety Integrity Level Probability of a dangerous failure per hour

(PFHd)
3 ≥10-8 to < 10-7
2 ≥10-7 to < 10-6
1 ≥10-6 to < 10-5
Table 10: SIL derived from the requirements of IEC 62061 [17]
IEC 62061 provides an example on methodology for qualitative risk assessment and definition of SIL.
This method must be applied on each hazard identified and to achieve the required risk reduction
through SRECS. This method is basically derived from ISO 14121 (Standard for Safety of Machinery)
and is applied for calculating risk factors.
For every hazard, individual risk factors are identified and calculated using the values corresponding to
their different scales. The table 11 below shows the various risk factors defined by IEC 62061. [17]
Seriousness S Frequency of Fr Probability of Pr Possibility of P
exposure occurrence prevention
Irreversible: 4 ≤ 1h 5 Very high 5 Impossible 5
death, loss of an
eye or arm
Irreversible: 3 ˃ 1h to < 1 day 5 Probable 4 Rarely 3
broken limbs, loss
of a finger
Reversible: 2 ˃ 1day to < 2 weeks 4 Possible 3 Probable 1
treatment by a
physician required
Reversible: first 1 ˃ 2 weeks ≤ 1 year 3 Rarely 2
aid required
˃ 1year 2 Negligible 1
Table 11: Risk factors of IEC 62061 [17]
36
The class of probability of harm K is calculated by summing the values for the frequency of exposure
Fr, probability of occurrence Pr, and the possibility of prevention P from the risk factor table 9 shown
above. Thus, K= Fr + Pr + P. Then the two factors Seriousness S and calculated K are applied in the
matrix in the table 12 shown below to calculate the relevant SIL. In the matrix below (OM) stands for
other measures. [17]
Class of probability of harm (K)

Seriousness (S) 3 to 4 5 to 7 8 to 10 11 to 13 14 to 15
4 SIL 2 SIL 2 SIL 2 SIL 3 SIL 3
3 (OM) SIL 1 SIL 2 SIL 3
2 (OM) SIL 1 SIL 2
1 (OM) SIL 1
Table 12: Risk Matrix of IEC 62061 [17]
4.4 IEC 60601 - Medical Electrical Equipment
The IEC 60601 is a series of specific standards used as a guidance for the safety and efficient used of
medical electrical equipment. [18]
The IEC 60601 is considered as the central standard which primarily defines the designs of medical
equipment. It was first approved and published in 1977. It is now mandatory for any new medical
devices developed, to be complied with the safety specifications and required performance mentioned
in IEC 60601-1 in order to introduce their equipment in the market for public usage.
IEC 60601-1 consists of several sub-category standards called collateral standards those are more
focused on a particular field. For example, IEC 60601-1-2 deals with the safety specification for
electromagnetic compatibility in medical devices. Also, IEC 60601-1-3 highlights the safety
requirements for diagnostic X-ray devices and systems. The IEC 60601-1-9 is focused on safety
essentials on environmental design and IEC 60601-1-11 has been recently approved for home health
care equipment, devices, and systems.
In addition to the collateral standards, IEC 60601 consists of numerous specific standards that provides
the relevant requirements for specialized kind of devices or equipment covered by IEC 60601-2-XX
and IEC 60601-3-XX series. For example, IEC 60601-2-16 is applicable for safety specification and
performance for medical equipment used for the treatment of blood dialysis and blood filtration. [18]
37
4.5 IEC 61800 - Power Drive System
IEC 61800 series defines the safety standards for Adjustable speed electrical power drive systems
(PDS). Various parts within the IEC 61800 series are focused on different categories of PDS and they
are as follows:
1. PDS connected to direct current (d.c.) motors are defined in IEC 61800-1;
2. IEC 61800-2 defines the general specification for adjustable speed PDS. This part is particularly
focused on overall requirements for PDS connected to alternative current (a.c.) motors and rated
voltages up to 1000 Volts a.c.;
3. IEC 61800-3 is focused on the requirements of Electromagnetic Compatibility (EMC);
4. The PDS used for a.c. motors with rated input voltages of above 1000 Volts a.c. are specified
in IEC 61800-4;
5. IEC 61800-5-1 details the Electrical safety specifications;
6. IEC TR 61800-6 describes the types of load duty requirements;
7. IEC 61800-7 series discusses the communication profiles specification between a generic PDS
and the control systems;
8. IEC TS 61800-8 defines the power interface voltage requirements. [19]
4.6 ISO 26262 - Road Vehicles (Automotive E/E System)
ISO 26262 was approved in 2011 by the International Organization for Standardization (ISO) to provide
a universal functional safety standard for electrical and electronic system used for ensuing safety in
automobile industry. ISO 26262 is the derivative version of IEC 61508 to define and follow the
functional safety requirements for electrical and electronic systems in road vehicles. Today, ISO 26262
is considered as the state of the art functional safety guideline for electrical and electronic system in
automobiles. [20]
The ISO 26262 consists of 10 sections or parts and together they provide a comprehensive approach to
attain the required functional safety in development stage of automobiles. The 10 sections of ISO 26262
are as follows:
▪ ISO 26262-1 provides a glossary of terms and abbreviations for application across all parts of
the standard;
▪ ISO 26262-2 provides management of functional safety and defines the structural features of
functional safety management;
▪ ISO 26262-3 is focused on concept phase where risk evaluations and concepts are described;
▪ ISO 26262-4 defines the specifications for product development at the system level;
▪ ISO 26262-5 provides requirements for the product development at the hardware level;
▪ ISO 26262-6 deals with the specifications for the product development at the software level;
▪ ISO 26262-7 is focused on production and operation and defines the safety requirements for
maintenance, repair and decommissioning of the safety system;
▪ ISO 26262-8 gives information on supporting processes for quality assurance;
▪ ISO 26262-9 describes the automotive safety integrity level (ASIL) oriented and safety-
oriented analyses;
▪ ISO 26262-10 provides guidelines on ISO 26262.
The following figure 19 shows the comprehensive overview of the structure of ISO 26262. [20]
38
Figure 19: Overview structure of ISO 26262 [20]
39
4.7 EN 5012-6/8/9 - Rail
The EN 50126, EN 50128, and EN 50129 standards are the derivative versions of IEC 61508
specifically adapted for the railway industry approved by the European Standards (EN). Each standard
is focused on defining specific requirements necessary for achieving functional safety of equipment and
software used for safety process.
EN 50126: Is focused on specifying and implementation of the Reliability, Availability,
Maintainability, and Safety (RAMS) system. EN 50126 is primarily focused on providing definition
and demonstration of RAMS requirements. EN 50126 discusses a universal approach for RAMS
management.
EN 50128: Provides specification on functional safety for railway communication, signaling,
controlling, processing, and protection system. EN 50126 also describes the methodology which is
necessary for defining the software that meets the required safety integrity level for the railway industry.
The SIL of the software in railway is quantified on five levels of SIL, starting from SIL-0 to SIL-4. The
methodology for calculating these SIL levels are defined by their relevance in the risk management,
frequency of hazard and the severity of the hazardous incident. EN 50128 provides the necessary
information required for calculating required SIL level for the software in railway.
EN 50129: Explains the necessary functional safety specification for safety electronics systems used
for signaling in railway industry. EN 50129 provides methodology in order to justify the safety process
of individual systems that could be either software or equipment and for the overall system as well. EN
50129 provides justification of each individual system in accordance of its SIL level. [21]
4.8 DO-254 (Hardware) & DO-178 (Software) - Avionics
DO-254 is a safety standard guidance specification used for the design of electronic hardware used for
safety purposes in aviation industry. Basically DO-254 is applicable to any electronic devices in aircraft
that is used for safety related systems.
According to the safety criticality, various electronic and electrical equipment in the aircraft are given
different Design Assurance Levels (DALs). For example, a safety device or system that is highly critical
will be graded higher DAL, where DAL A represents the most critical systems. This safety criticality
is calculated through a safety assessment of the aircraft and its interacting systems to identify the
required failure rate. The table 13 below shows the different Design Assurance Levels (DALs). [22]
Design Assurance Level Description Target System Failure Example System

(DAL) Rate
Level A (Catastrophic) Failure causes crash, < 1× 10-9 chance of Flight controls
deaths failure/flight per hour
Level B (Hazardous) Failure may cause crash, < 1× 10-7 chance of Braking systems
deaths failure/flight per hour
Level C (Major) Failure may cause stress, < 1× 10-5 chance of Backup systems
injuries failure/flight per hour
Level D (Minor) Failure may cause No safety metric Ground navigation
inconvenience systems
Level E (No effect) No safety effect on No safety metric Passenger entertainment
passengers/crew
Table 13: Design Assurance levels (DALs) [22]
40
DO-178 is a Software assessment tool used in Airborne Systems & Equipment Certification standards
and is published by the Radio Technical Commission for Aeronautics (RTCA). But, RTCA is not an
official governmental agency, its recommendations may not be regarded as statements of official
government policy unless proclaimed by a government organization or agency having statutory
jurisdiction over any matters to which the recommendations relate. Yet, in reality, all governments and
agencies have given approval for these standards for civil aviation.
The DO-178B and DO-178C safety standards are also published by the European Organization for Civil
Aviation Equipment (EUROCAE) as ED-12B and ED-12C respectively. These standards are identical
in contents and are referenced as DO-178.
DO-178B was published in 1992 and was superseded in 2011 by DO-178C, together with an additional
standard DO-330 Software Tool Qualification Considerations.
DO-178 standards require that all airborne software is given a Design Assurance Level (DAL)
according to the impacts of a failure condition in the system. These levels range from the lowest E ‘No
Effect’ to the highest A ‘Catastrophic’. [23]
The failure conditions are classified by their impacts as shown below:
Level A - Catastrophic: Failure may cause a fatal crash;
Level B - Hazardous: Failure compromises the ability of the aircraft operators to control the aircraft
properly and therefore may lessen the safety or reduce the performance of the aircraft;
Level C - Major: Failure has less effect than a hazardous failure, but it is still significant enough to
increase the workload of the aircraft operators;
Level D - Minor: Failure has lesser effect than a major failure but noticeable;
Level E - No Effect: Failure is insignificant and does not compromise the safety of the aircraft or has
any effect on the workload of the aircraft operators. [24]
Airborne software safety sensitivity Levels examples:
The software safety Levels of A and B, includes the following systems:
▪ Fly-by-wire/ Semi-automatic control systems;
▪ Auto-pilot systems;
▪ Air-traffic separation control systems;
▪ Glass display systems in coRckpit;
▪ RADAR;
▪ Jet engine control systems;
▪ Identification of friend or foe (IFF) systems;
▪ Missile guidance systems;
▪ Missile launching systems;
▪ Missile self-destruct systems.
The software safety levels of C and D, includes the following systems;
▪ Anti-missile defense system;
▪ Data mining;
▪ Aircraft health monitoring systems;
▪ Mission planning and execution systems;
▪ Mission simulation and training systems;
▪ Real-time data recording and analyzing systems;
▪ Self-healing communication network systems;
▪ Telemetry systems;
▪ Weapons targeting systems. [25]
41
5 Comment and Conclusion
5.1 Comment
From the above discussion on the generic safety standard IEC 61508 and its derivative sector specific
standards IEC 61511, IEC 61513, IEC 62061, IEC 61800, ISO 26262, EN 5012-6/8/9, DO-254, and
DO-178B. It is seen that the primary objective of all these standards is to provide definition,
methodology, specification, requirements, qualification, life-cycle concept, determination of safety
integrity levels, risk reduction factor, reliability, availability, failure rate, hardware fault tolerance, safe
failure fraction, safe failure, dangerous failure, and common cause failures, etc.
So, that the standards could suggest a proper method which is applicable for a particular E/E/PES used
for protection system in various sectors to perform the required functional safety operation to contain
the electronic or electrical systems, devices, and programs within the safe state margin when the
situation turns into a hazardous one. And it is done by activating the relevant safety related system to
do the necessary risk reduction process to reduce the risk from unacceptable or catastrophic level to
acceptable or tolerable level.
Thus, keeping the E/E/PES in safe state whether they are working on low demand mode or high demand
or continuous mode of operations. Finally, the method for performing this necessary functional safety
process differs from industries to industries because they have different risk reduction methods and
targets. Therefore, the generic functional safety standard IEC 61508 for E/E/PES has been adapted and
modified according to the various sector's functional safety targets.
5.2 Conclusion
The research scope of this report is limited due time limitations and for the exclusive copyright
restriction on the IEC standards and other standardization organizations' publications.
There is only a handful of limited resources available for free of cost. Mostly, these available resources
are withdrawn or outdated standards which are now no longer used. Therefore, some of the contents in
this report may no longer applicable to the contemporary situations or circumstances.
Moreover, some of the contents of this report has been adapted or taken from websites of various
organizations. These contents might no longer be available or match exactly because of the frequent
updates or revisions done on these websites by the proprietary organizations.
However, this report could be used as a quick reference guide for those who are interested to work
further on the similar topic.
42
6 Acknowledgement
I would like to express my gratitude and sincere thanks to our Professor and Lecturers from the
Functional Safety Engineering, Department of Electrical Engineering and Computer Science Computer
Architecture and System Programming, University of Kassel for their continuous support in providing
information and clarification on the course material. I truly appreciate their relentless guidance and
motivation which helped me in making this report.
Also, I would like to express my appreciation to authors of the various information sources without
which this report would not have been possible.
Finally, I would like to express my sincere gratefulness towards my parents, family, and friends for
being there with me throughout the time I was preparing this report.
43
7 References
[1] LLC ec. Functional Safety Standards - IEC 61508 vs. IEC 61511 | exida. [December 24, 2019];
Available from: https://www.exida.com/Blog/functional-safety-standards-iec-61508-vs.-iec-
61511.
[2] Börcsök J. Functional Safety: Basic Principles of Safety-related Systems. 2nd ed. Berlin: VDE
Verlag; 2017.
[3] Rheinland TÜV. Functional Safety | WO | TÜV Rheinland. [December 03, 2019]; Available from:
https://www.tuv.com/world/en/functional-safety-services.html.
[4] International Electrotechnical Commission. Briefing paper: Functional safety essential to overall
safety – en, ru – IEC Basecamp. [December 25, 2019]; Available from:
https://basecamp.iec.ch/download/functional-safety-essential-to-overall-safety/.
[5] IEC 61508 and Industries | High Integrity Systems. [December 25, 2019]; Available from:
https://www.highintegritysystems.com/iec-61508-safety-standards/.
[6] Frost S. Future developments in functional safety. In: IEE Seminar Programmable Electronics and
Safety Systems: Issues, Standards and Practical Aspects. IEE; 2002, p. 7.
[7] Smith R. IEC 61508 Overview Report: A Summary of the IEC 61508 Standard for Functional
Safety of lectrical/Electronic/Programmable Electronic Safety-Related Systems 2006:1–29.
[8] International Electrotechnical Commission. IEC 61508-1:1998 Withdrawn: International
Standard. 1st ed.: International Electrotechnical Commission; 1998; Available from:
https://webstore.iec.ch/publication/19800. [December 27, 2019].
[9] Great Britain Health and Safety Executive. Out of control: Why controls system go wrong and
how to prevent failure. 2nd ed. Sudbury: HSE Books; 2003.
[10] International Electrotechnical Commission. IEC 61508-2: 2000 Withdrawn: Functional safety of
electrical/electronic/programmable electronic safety-related systems - Part 2: Requirements for
electrical/electronic/programmable electronic safety-related systems. 1st ed.: International
Electrotechnical Commission; 2000; Available from: https://webstore.iec.ch/publication/19802.
[January 02, 2020].
electrical/electronic/programmable electronic safety-related systems - Part 3: Software
requirements. 1st ed.: International Electrotechnical Commission; 1998; Available from:
https://webstore.iec.ch/publication/19803. [January 02, 2020].
electrical/electronic/programmable electronic safety-related systems - Part 5: Examples of
methods for the determination of safety integrity levels. 1st ed.: International Electrotechnical
Commission; 1998; Available from: https://webstore.iec.ch/publication/19807. [January 03,
2020].
[13] IEC 61511 standard | Risknowlogy. [January 04, 2020]; Available from:
https://risknowlogy.com/en/rkb/functional-safety/iec-61511-standard/.
[14] International Electrotechnical Commission. IEC 61511-1: 2003 Withdrawn: Functional safety -
Safety instrumented systems for the process industry sector - Part 1: Framework, definitions,
system, hardware and application programming requirements. 2nd ed.: International
Electrotechnical Commission; 2003; Available from: https://webstore.iec.ch/publication/5522.
[January 05, 2020].
[15] International Electrotechnical Commission. IEC 61513: 2011: Nuclear power plants -
Instrumentation and control important to safety - General requirements for systems. 2nd ed.:
International Electrotechnical Commission; 2011; Available from: https://www.vde-verlag.de/iec-
normen/218139/iec-61513-2011.html. [January 05, 2020].
[16] User S. IEC 62061 SIL - Conclusions. [January 05, 2020]; Available from:
https://www.reersafety.com/si/en/safety-guide/safety-in-the-working-environment/iec-62061-sil.
[17] Leuze electronic GmbH + Co. KG. 2.4.2 IEC/EN 62061: Functional safety, control systems Leuze
electronic the sensor people. [January 05, 2020]; Available from:
https://www.leuze.com/en/deutschland/loesungen/anwenderwissen/arbeitssicherheit/2_maschine
44
nsicherheit_in_der_eu/2_4_2_iec_en_62061__funktionale_sicherheit__steuerungssysteme/2_4_
2_iec_en_62061__funktionale_sicherheit__steuerungssysteme.php.
[18] Inc CUI. IEC 60601-1 Medical Design Standards for Power Supplies | CUI Inc:1–14.
[19] International Electrotechnical Commission. IEC 61800-2: 2015: General requirements-Rating
specifications for low voltage adjustable speed a.c. power drive systems 2015(2.0):1–82.
[20] TÜV SÜD. ISO 26262 compliance: Addressing the compliance complexity of safety-relevant E/E
systems.:1–12.
[21] CLEARSY. THE IEC STANDARD AND ITS DERIVATIVES. [January 06, 2020]; Available
from: https://www.clearsy.com/en/the-iec-standard-and-its-derivatives/.
[22] CADENCE. DO-254 Explained 2019:1–6.
[23] QA Systems GmbH. DO-178B and DO178-C Qualification | Testing Tools - QA-Systems.
[January 10, 2020]; Available from: https://www.qa-systems.com/solutions/do-178/.
[24] HCL Technologies Limited. What is DO-178B? | HCL Technologies: WHAT IS DO-178B?
[January 07, 2020]; Available from: https://www.hcltech.com/technology-qa/what-is-do-178b.
[25] Ákos Horváth. Standards in Avionics System Development.
45

Eneric Functional Safety Standards Vs Sector Specific Functional Safety Standards

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Eneric Functional Safety Standards Vs Sector Specific Functional Safety Standards

Uploaded by

Copyright:

Available Formats

Generic Safety Standards Versus Sector Standards

Course: Safety Standards and Norms of Electronic Systems

Submitted on 10 January 2020

2.1 Background on Safety Standards

2.2 Introduction to the Thesis

Safety Integrity Level (SIL) High demand or continuous mode of

Minimum level of independence Safety Integrity Level (SIL)

3.3 IEC 61508-2

Figure 4: Hardware Safety life-cycle [10]

Some of the safety integrity level details are:

Safe failure fraction Hardware fault tolerance (HFF) (see note 1)

Figure 7: V-Model [11]

Software Safety Validation Planning:

Also, the software code must be:

Operation and modification:

3.5 IEC 61508-4

Figure 8: Risk reduction: General concept [12]

Figure 9: Tolerable risk and ALARP concept [12]

Figure 10: Example of a quantitative method for determining SIL [12]

Figure 11: Shows the Risk graph [12]

3.7 IEC 61508-6

PFDsys = PFDS + PFDL + PFDFE

Figure 13: The block diagram of 1oo1 Architecture [2]

Figure 14: The block diagram of 1oo2 Architecture [2]

Figure 16: The block diagram of 2oo2 Architecture [2]

For 1oo2 Architecture:

For 1oo2D Architecture:

For 2oo2 Architecture:

For 2oo3 Architecture:

4.1 IEC 61511 - Process Industry

Structure of IEC 61513

Safety Integrity Level Probability of a dangerous failure per hour

Class of probability of harm (K)

4.4 IEC 60601 - Medical Electrical Equipment

4.6 ISO 26262 - Road Vehicles (Automotive E/E System)

4.8 DO-254 (Hardware) & DO-178 (Software) - Avionics

Design Assurance Level Description Target System Failure Example System

You might also like