June 5, 2017 Founder's articles on IEC 61508
  Articles Written by our Founder
Founder's Articles on IEC 61508 and ISO 9000
Published in October, 2003


An Introduction to IEC 61508 - Article #1

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 is required.

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.

Copyright (C) 2003 Paul Bodeau. All Rights Reserved.

Why Not Engineering - All Rights Reserved