June 5, 2017 Founder's article on IEC 61508 - January, 2004
  Articles Written by our Founder
Founder's Articles on IEC 61508 and ISO 9000
Published in March, 2004

E/E/PES Safety Development Process (Objective 1) - Article #6

This is the sixth 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.

IEC 61508-2, clause 7 requires an understanding of the development processes of the Electrical/Electronic/Programmable Electronic System (E/E/PES) lifecycle. The objectives of IEC 61508-2, clause 7 are:

    1. define the processes of the E/E/PES development to achieve the required functional safety.
    2. document all information relevant to the functional safety of the E/E/PES development.

This article addresses the E/E/PES safety development processes item 1 above. The next article in this series will address the E/E/PES safety development documentation required to support these processes item 2 above. The E/E/PES safety development processes are required to reduce the likelihood of systematic failures in the delivered E/E/PES. The E/E/PES safety development processes are: E/E/PES requirements process, E/E/PES design process, E/E/PES implementation process, E/E/PES integration process, E/E/PES verification process, and E/E/PES validation process.

The E/E/PES safety development processes are sometimes referred to as the waterfall approach. This is often done to attack the E/E/PES safety development processes with the accusation that all of one process must be completed before the next consecutive dependent process can be started. The E/E/PES safety development processes are not a waterfall approach. Transition criteria are established between each E/E/PES safety development process and itís next consecutive dependent process. The transition criteria requires just enough completion of that process to permit entering the next consecutive dependent process. Good judgment and understanding of the E/E/PES safety development processes are prerequisites for determining transition criteria. Brief explanations of the E/E/PES safety development processes follow.

The E/E/PES requirements process traces to IEC 61508-2, subclause 7.2. The input to this process will most likely be an internal company proposal for those companies developing generic safety products. An external proposal or some other document stating requirements may be presented from a customer for a bespoke E/E/PES. The proposal or other external document must define the functional requirements and the safety integrity requirements for the E/E/PES. See IEC 61508-2, subclause 7.2.1. IEC 61508-2, Annex B, Table B.1, determines the required techniques and measures described in IEC 61508-7 to meet the SIL for the E/E/PES requirements process. The output from this process is the E/E/PES Safety Requirements Specification. The required techniques and measures reduce the likelihood of errors being introduced into the E/E/PES Safety Requirements Specification during this process. As soon as the defined and planned transition criteria have been met, the E/E/PES design process is invoked. The E/E/PES requirements process is re-entered as necessary from other E/E/PES safety development processes to address detected errors found in those processes that are a result of the E/E/PES requirements process and manifested in the E/E/PES Safety Requirements Specification. The E/E/PES requirements process is assessed and the results are documented per an approved verification plan. Quality Assurance audits this process, reviews the E/E/PES Safety Requirements Specification, and reports the results to management.

The E/E/PES design process traces to IEC 61508-2, subclause 7.4. The input to this process is the E/E/PES Safety Requirements Specification. IEC 61508-2, Annex B, Table B.2, determines the required techniques and measures described in IEC 61508-7 to meet the SIL for the E/E/PES design process. The output from this process is the E/E/PES Design Document. The required techniques and measures reduce the likelihood of errors being introduced into the E/E/PES Design Document during this process. As soon as the transition criteria have been met, the E/E/PES implementation process is invoked. The E/E/PES design process is re-entered as necessary from other E/E/PES safety development processes to address detected errors found in those processes that are a result of the E/E/PES design process and manifested in the E/E/PES Design Document. The E/E/PES design process is assessed and the results are documented per an approved verification plan. Quality Assurance audits this process, reviews the E/E/PES Design Document, and reports the results to management.

The E/E/PES implementation process traces to IEC 61508-2, subclause 7.4. The input to this process is the E/E/PES Design Document. IEC 61508-2, Annex B, Table B.2, determines the required techniques and measures described in IEC 61508-7 to meet the SIL for the E/E/PES implementation process. The output from this process is the implemented E/E/PES with documentation. This process is implementation at the atomic or circuit level. Each circuit that has been identified in the E/E/PES Design Document is physically implemented by breadboard or is simulated. The required techniques and measures reduce the likelihood of errors being introduced into the implemented E/E/PES or itís documentation during this process. As soon as the transition criteria have been met, the E/E/PES integration process is invoked. The E/E/PES implementation process is re-entered as necessary from other E/E/PES safety development processes to address detected errors found in those processes that are a result of the E/E/PES implementation process and manifested in the implemented E/E/PES or itís documentation. The E/E/PES implementation process is assessed and the results are documented per an approved verification plan. Quality Assurance audits this process, reviews the implemented E/E/PES with documentation, and reports the results to management.

The E/E/PES integration process traces to IEC 61508-2, subclause 7.5. The inputs to this process are the implemented E/E/PES and the Executable Object Code from the software development process if software is required. IEC 61508-2, Annex B, Table B.3, determines the required techniques and measures described in IEC 61508-7 to meet the SIL for the E/E/PES integration process. The output from this process is the integrated and tested E/E/PES with documentation. The required techniques and measures reduce the likelihood of errors being introduced into the integrated and tested E/E/PES during this process. The E/E/PES integration process is re-entered as necessary from other E/E/PES safety development processes to address detected errors found in those processes that are a result of the E/E/PES integration process and manifested in the integrated and tested E/E/PES or itís documentation. The E/E/PES integration process is assessed and the results are documented per an approved verification plan. The integrated E/E/PES is validated against E/E/PES Safety Requirements Specification at the end of this process. Quality Assurance audits this process, reviews the integrated and tested E/E/PES with documentation, and reports the results to management.

The E/E/PES verification process traces to IEC 61508-2, subclause 7.9. The inputs to this process are the inputs, outputs, and procedures of all the other E/E/PES safety development processes. The E/E/PES verification process uses some of the same techniques and measures as the E/E/PES validation process. Therefore, IEC 61508-2, Annex B, Table B.5, can be used to determine some of the required techniques and measures described in IEC 61508-7 to meet the SIL for the E/E/PES verification process. IEC 61508 is somewhat weak in defining verification requirements. Other standards can be consulted for more information. The E/E/PES verification process determines that valid inputs were used by a valid procedure to develop the E/E/PES safety development process outputs. Verification determines that the techniques and measures have reduced the likelihood of systematic defects introduce by the E/E/PES safety development process into the process output. The output from this process is the E/E/PES Verification Results. The E/E/PES verification process is also subjected to verification. Management uses the E/E/PES Verification Results to help determine if the safety integrity level requirements have been met.

The E/E/PES validation process traces to IEC 61508-2, subclause 7.7. The inputs to this process are the outputs of all the other verified E/E/PES safety development processes. Each E/E/PES safety development process output must be validated before it can be used as an input by the next consecutive dependent E/E/PES safety development process. Once the verification process has verified the E/E/PES safety development process, the E/E/PES safety development process output is validated. Validation determines that the techniques and measures have reduced the likelihood of systematic defects introduced by the E/E/PES safety development process into the process output. This validated output is the correct output, and can now be used by the next consecutive dependent process. The output from this process is the E/E/PES Validation Results. Management used the E/E/PES Validation Results to help determine if the safety integrity level requirements have been met.

This article presented the E/E/PES safety development processes with their trace abilities to IEC 61508-2. The E/E/PES safety development engineer should become familiar with these IEC 61508-2 subclauses to fully understand how to comply with this international safety standard. The next article in this series will address E/E/PES safety development documentation (Objective 2).

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 (661) 260-1210, or pbodeau@WhyNotEngineering.com.

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

Why Not Engineering - All Rights Reserved