Software development processes - Article #9

This is the ninth 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-3, clause 7, requires an understanding of the development processes of the Electrical/Electronic/Programmable Electronic System (E/E/PES) software lifecycle. The objectives of IEC 61508-3, clause 7, are:

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

IEC 61508-3 parts ways with IEC 61508-2 here. IEC 61508-3 additionally requires quality assurance as specified in IEC 61508-3, subclause 7.1.2.2. 7.1.2.2. also requires safety assurance procedures. IEC 61508-3, subclause 7.1.2.4 requires the notorious V-model. IEC 61508-3, subclause 7.1.2, spells out other systematic requirements for software. For consistency, all the requirements specified in IEC 61508-3, subclause 7.1.2, should also apply to IEC 61508-2, subclause 7.1.1. A functional safety management system requires all of these. Future revisions of IEC 61508 should include more consistency between IEC 61508-2 and IEC 61508-3.

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

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

The software requirements process traces to IEC 61508-3, subclause 7.2. The input to this process is the E/E/PES Safety Requirements Specification. The software requirements process develops software requirements in accordance with IEC 61508-3, subclause 7.2.2.6 and the chosen requirements method. IEC 61508-3, Annex A, Tables A.1, A.2, and A.4, determine the required techniques and measures described in IEC 61508-7 to meet the Safety Integrity Level (SIL) for the software requirements process. The output from this process is the Software Safety Requirements Specification. The required techniques and measures during this process reduce the likelihood of errors being introduced into the Software Safety Requirements Specification. As the defined and planned transition criteria are met, the software design process can be invoked. The software requirements process is re-entered as necessary from other software development processes to address detected errors found in those processes that are a result of the software requirements process and manifested in the Software Safety Requirements Specification. The software requirements process is assessed and the results are documented per an approved verification plan. Quality Assurance audits this process, reviews the Software Safety Requirements Specification, and reports the results to management.

The software design process traces to IEC 61508-3, subclause 7.4. The input to this process is the Software Safety Requirements Specification. The software design process develops the software design per IEC 61508-3, subclause 7.4.2.2 and the chosen design method. IEC 61508-3, Annex A, Tables A.2 and A.4, determine the required techniques and measures described in IEC 61508-7 to meet the SIL for the software design process. The output from this process is the Software Design Document. The required techniques and measures during this process reduce the likelihood of errors being introduced into the Software Design Document. As the defined and planned transition criteria are met, the software implementation process can be invoked. The software design process is re-entered as necessary from other software safety development processes to address detected errors found in those processes that are a result of the software design process and manifested in the Software Design Document. The software design process is assessed and the results are documented per an approved verification plan. Quality Assurance audits this process, reviews the Software Design Document, and reports the results to management.

The software implementation process traces to IEC 61508-3, subclause 7.4. The input to this process is the Software Design Document. The software implementation process implements the software design per IEC 61508-3, subclause 7.4.6.1 and the chosen implementation method. This process is implementation at the atomic or module level. Each software module that has been identified in the Software Design Document is coded in the appropriate source code language and tested. IEC 61508-3, Annex A, Tables A.3 and A.4, determine the required techniques and measures described in IEC 61508-7 to meet the SIL for the software implementation process. The output from this process is the Software Implementation Documentation composed of the Software Source Code and the Software Object Code. The required techniques and measures during this process reduce the likelihood of errors being introduced into the Software Implementation Documentation. As the defined and planned transition criteria are met, the software integration process can be invoked. The software implementation process is re-entered as necessary from other software safety development processes to address detected errors found in those processes that are a result of the software implementation process and manifested in the implemented Software Implementation Documentation. The software implementation process is assessed and the results are documented per an approved verification plan. Quality Assurance audits this process, reviews the Software Implementation Documentation, and reports the results to management.

The software integration process traces to IEC 61508-3, subclause 7.5. The input to this process is the Software Implementation Documentation. This software integration process integrates the tested software modules to build the Software Executable Object Code per IEC 61508-3, subclause 7.5.2. IEC 61508-3, Annex A, Table A.5, determines the required techniques and measures described in IEC 61508-7 to meet the SIL for the software integration process. The output from this process is the Software Integration Documentation, which is the integrated and tested Software Executable Object Code. The required techniques and measures during this process reduce the likelihood of errors being introduced into the integrated and tested Software Executable Object Code. As the defined and planned transition criteria are met, the integrated software is validated against the Software Safety Requirements Specification. The software integration process is re-entered as necessary from other software safety development processes to address detected errors found in those processes that are a result of the software integration process and manifested in the Software Integration Documentation. The software integration process is assessed and the results are documented per an approved verification plan. Quality Assurance audits this process, reviews the integrated and tested Software Integration Documentation, and reports the results to management.

The software verification process traces to IEC 61508-3, subclause 7.9. The inputs to this process are the validated inputs, and procedures of all the other software safety development processes. The software verification process determines that valid inputs were used by a valid procedure to produce the software safety development process outputs per IEC 61508-3, subclause 7.9.2. IEC 61508-3, Annex A, Table A.9, determines the required techniques and measures described in IEC 61508-7 to meet the SIL for the software verification process. The output from this process is the Software Verification Results. The required techniques and measures during this process reduce the likelihood of errors being introduced into the Software Verification Results. As the defined and planned transition criteria are met, the functional safety assessment process, IEC 61508-3, clause 8, can be invoked. The software verification process is re-entered as necessary from other software lifecycle processes to address detected errors found in those processes that are a result of the software verification process and manifested in the Software Verification Results. The software verification process is also subjected to verification, so the software verification process is assessed and the results are documented per an approved verification plan. Quality Assurance audits this process, reviews the Software Verification Results, and reports the results to management.

The software validation process traces to IEC 61508-3, subclause 7.7. The inputs to this process are the outputs of the verified software safety development processes. The software validation process determines that each software safety development process output is validated before it can be used as an input by the next consecutive dependent software safety development process. IEC 61508-3, Annex A, Table A.7, determines the required techniques and measures described in IEC 61508-7 to meet the SIL for the software validation process. The output from this process is the Software Validation Results. The required techniques and measures during this process reduce the likelihood of errors introduced into the Software Validation Results. As the defined and planned transition criteria are met, the functional safety assessment process, IEC 61508-3, clause 8, can be invoked. The software validation process is re-entered as necessary from other software lifecycle processes to address detected errors found in those processes that are a result of the software validation process and manifested in the Software Validation Results. The software validation process is assessed and the results are documented per an approved verification plan. Quality Assurance audits this process, reviews the Software Validation Results, and reports the results to management.

Verification and validation work together: a little verification, then some validation, and then more verification. See the third article in this series for more about verification and validation. Some safety standards consider validation a subset of verification.

This article presented the software safety development processes with their trace abilities to IEC 61508-3. The software safety development engineer should become familiar with these IEC 61508-3 subclauses to fully understand how to comply with this international safety standard. The next article in this series will address software 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.