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 November, 2003

Why IEC 61508? - Article#2

This is the second in a series of short articles on IEC 61508, the standard used when computer-based systems are developed to carry out safety functions. The purpose of these articles is to give the reader an appreciation for this international standard.

How is the safety of a computer-based system measured?  This problem is addressed by the international standard, IEC 61508.

The International Electrotechnical Commission (IEC) is now based in Geneva, Switzerland.  The IEC was officially founded in June 1906, in London, England, where its Central Office was set up.  The IEC is a worldwide organization for standardization comprising all national electrotechnical committees.  The objective of the IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields.

Electrical components such as transistors, diodes, resistors, etc. have predictable failure rates.  These failure rate predictions assume that the designer has not stressed the electrical component during the development processes.  The science of component reliability has been around for a long time.  When one of these components fails statistically, it is said to be a random failure.

Of greater concern are systematic failures.  Systematic failures are a result of defects being injected into the product during the lifecycle processes.  An unanticipated input to a circuit or software module is one way a defect can be injected into a product.  IEC 61508 defines a systematic failure as a "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."  Systematic failures are not receiving the necessary exposure today to develop safety systems.  To understand systematic failures, complex and non-deterministic systems need to be addressed.  Complex and non-deterministic systems can be hardware, or software, or both.

Since microprocessors were deployed in safety systems beginning in the 1980's, the safety of these systems have been questioned by industry.  Microprocessors require software (firmware).  Together, microprocessors with software are complex systems.  Complex means the system has many components and the interfaces between these components are unknown or incompletely defined.  Non-complex means the system is one with few components respectively and all interfaces are known.

A deterministic system has a unique output for each specific input, and therefore the system can be completely tested.  A deterministic system with a 16 bit input requires 216 or 65536 tests.  This requires a lot of testing.

A non-deterministic system means that the system output is a function of the current input and the previous output.  A state machine is an example of a non-deterministic system.  Most systems today are non-deterministic systems, since the outputs of the system are a function of the inputs and the previous system state.  A complex non-deterministic system cannot be completely tested.  For example, to test a non-deterministic system with a 16 bit input, and a 16 bit output, requires 655362 tests.  This is a big number, over 4 billion.  There is not enough time to perform that many tests.  A system like this is still relatively simple for the systems of today.  This system is not even a Pentium processor.  Therefore testing is insufficient to prove that a complex non-deterministic system is safe.  This is a very important point.  In fact, this is what IEC 61508 is all about.  I will say it again; testing alone cannot prove that a complex, non-deterministic system is safe.

So, how can a complex non-deterministic system be determined safe?  To determine a complex non-deterministic system safe, all components of the system and all interfaces between components must be defined.  IEC 61508 identifies specific techniques and measures to accomplish this during the product lifecycle.  These techniques and measures save time, since testing is impractical.

To assure that the proper techniques and measures were utilized during the product lifecycle, quality systems theory is required.  From quality systems theory, the quality of a process output is a function of the quality of the process input and the quality of the process that transforms that input into the output.  Inputs to lifecycle processes need to be defect free.  Lifecycle processes must not inject errors into those inputs so the lifecycle process outputs are defect free.  What this means is a quality management system is required during the product lifecycle.  IEC 61508 is based upon a sophisticated quality management system.

Failures in computer-based systems impact the safety of persons, property, environment, and the economy.  Safety is defined in IEC 61508 as "freedom from unacceptable risk."  IEC 61508 defines risk as the "combination of the probability of occurrence of harm and the severity of that harm."  (R = P X S or risk = probability X severity).

How can the safety of a system be measured?  The safety integrity level (SIL) was invented to quantify safety.  Safety integrity is defined in IEC 61508 as the "probability of a safety-related system satisfactorily performing the required safety functions under all the stated conditions within a stated period of time."  The SIL attempts to measure the probability of harm.  SILs are defined in four levels, 4 being the highest.  The techniques and methods used during the product lifecycle must meet the required SIL to comply with the system safety requirements.

The next article in this series will address the starting point for compliance to IEC 61508.

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 at Why Not Engineering, on the Contact Us page at http://www.whynotengineering.com.

Back to the Home page

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

Why Not Engineering - All Rights Reserved