This is the first in a series of short articles on IEC 61508. IEC 61508 is required whenever
a computer-based system is used to carry out a safety function. The purpose of these articles is
to give the reader an appreciation for this international standard.
Computer-based systems that carry out safety functions can be found everywhere. Passenger airliners,
amusement park attractions, nuclear reactors, heart pacemakers, automobiles, railroads, alarm systems,
and government voting machines are some examples of safety functions employing computer-based systems.
With the proliferation of programmable electronic systems (PESs), the World is exposed to greater
safety risks. To mitigate these risks, the International
Electrotechnical Commission (IEC) released the international standard IEC 61508. IEC 61508 is a
unified approach adopted to develop a rational and consistent technical policy for all computer-based
systems. The release of IEC 61508 is generating mounting interest in compliance, since non-compliance
may mean expensive lawsuits or even criminal penalties.
Although IEC 61508 addresses system safety (PES), hardware safety (subsystem), and software
safety separately, the paramount issue with IEC 61508 is how to develop safe software. To make the
issue more poignant, what if a commercial airliner flying at 30,000 feet with 200 passengers on board,
has an error in the Flight Control Computer Software? The flight crew cannot be expected to execute
a "Ctrl-Alt-Del" command. Software is manufactured only once; thereafter it is cloned.
Therefore software must be manufactured right the first time. Software does not wear out, so software
does not have an associated random failure rate. Software only fails systematically. That is, software
always performs exactly the way it was programmed.
The civil aviation industry addresses systematic failures in software with RTCA/DO-178B. RTCA/DO-178B
is a guideline that recommends what to do to eliminate systematic failures during the software safety
development processes. IEC 61508 addresses the same issues, but takes the next step, by saying what must
be done to eliminate systematic failures during the software safety development processes. However,
software requires a target computer, and a target computer is required to perform a safety function
within a subsystem. To see how all this fits together an understanding of the structure of IEC 61508
This series of articles focuses on IEC 61508, parts 1, 2, and 3, with the other four parts mentioned
as necessary, a formidable document costing about $1000 dollars (US) is about two inches in thickness.
Because of the complexity, cost, and other issues, IEC 61508 has not proliferated the safety industry.
IEC 61508 is composed of seven parts.
IEC 61508-1, Part 1: General requirements
IEC 61508-2, Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems
IEC 61508-3, Part 3: Software requirements
IEC 61508-4, Part 4: Definitions and abbreviations
IEC 61508-5, Part 5: Examples of methods for the determination of safety integrity levels
IEC 61508-6, Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3
IEC 61508-7, Part 7: Overview of techniques and measures
Part 1 contains two clauses that are of particular interest. Clause 6 is management of functional safety,
and Clause 7 is the overall safety requirements. Clause 7 invokes Parts 2 and 3 as appropriate. Part 2 applies
to subsystems, which contain an electrical, electronic, or programmable electronic (E/E/PES) component. When
software is involved, Part 2 invokes Part 3. Part 3 applies to any software forming part of a safety-related
system, typically software that executes in the programmable electronic subsystem. Part 4 provides definitions
and explanations of terms used in IEC 61508. Part 5 provides examples for determining safety integrity levels.
Part 6 provides detailed examples of the application of IEC 61508-2 (Part 2) and IEC 61508-3 (Part 3). Part 7
provides the techniques and measures required to achieve the safety integrity levels applicable to the
electrical, electronic, or programmable electronic subsystems and associated software.
The next article in this series will address the reasons that the International Electrotechnical Commission
released IEC 61508. Future articles planned include: compliance starting point, overall safety lifecycle
requirements, E/E/PES compliance, E/E/PES development processes, E/E/PES development documentation, software
compliance, software development processes, and software development documentation.
Paul Bodeau is a member of the Safety Division with over 25 years of diversified engineering experience,
mostly in safety firmware development for military and civilian aviation. Mr. Bodeau can be reached on the
Contact Us page at Why Not Engineering web site at http://www.whynotengineering.com.