Figure 2 is a reproduction of the simplified V-model referenced by ISO 13849, superimposed with an illustration of how the LDRA tool suite and other complementary tools can be applied within the process.

For the most safety critical applications, ISO 13849 defers to the E/E/PES safety lifecycle requirements laid down in section 7 of IEC 61508- Part 3: Software requirements. Much of the development lifecycle specified in ISO 13849 therefore applies only to PL d or less, and the standard further subdivides them into “Safety-related embedded software (SRESW)” and “Safety-related application software (SRASW).” Each has slightly different sets of objectives.

Figure 2: Mapping the capabilities of the LDRA tool suite and complementary tools to the ISO 13849-1:2015 Simplified V-model

Implementing the Safety-Related Software Specification

The first step in the simplified V-model concerns the definition of a software related specification. The V-model illustrates the need for this specification to be fully implemented in the system design, for that to be fully implemented in module design, and so on.It would be easy to dismiss the task of tracing between the development lifecycle phases as trivial. But consider, for instance, an unexpected change of requirement imposed by a customer. What is impacted? Which requirements? What elements of the code design? What code needs to be revised? And which parts of the software will require re-testing?

Figure 3: Automating Requirements Traceability with the TBmanager component of the LDRA tool suite

The most effective way to ensure that the project is not thrown off course by such eventualities is to maintain Bidirectional Traceability of Requirements6 to determine that all source requirements have been completely addressed, that all lower level requirements can be traced to valid source code, and that there is no source code that is surplus to requirements. For more critical projects adhering to the IEC 61508:2010 lifecycle, bi-directional traceability is specified by that standard as an explicit objective in its Annex A tables.A requirements traceability tool alleviates the resulting project management overhead by automatically maintaining the connections between the requirements, development, and testing artefacts and activities. Any changes in the associated documents or software code are automatically highlighted such that any re-testing can be dealt with accordingly (Figure 3).

System & Module Design

Since the system design is based on the software specification, developing it means defining the interfaces between the software items that will implement the requirements. Many of these software elements will be created by the project, but some may be brought in from other projects, possibly in the form of third-party libraries. IEC 61508 highly recommends the use of “trusted/verified software elements”. Note that many components of the LDRA tool suite are as applicable to legacy code, as they are to code that is newly written.

If a model-based approach is taken to system design - for example, using MathWorks® Simulink®7, IBM®Rational®Rhapsody®8, or ANSYS® SCADE Suite®9 then a tool suite that is integrated with the chosen modelling tools will make the analysis of generate code and traceability to the models far more seamless.

Module design can be built on the foundation of system design, and it specifies algorithms, data representations, and interfaces between different software units and data structures. Because implementation depends on module design, it is necessary to verify the module design before the activity is complete, generally by means of a technical evaluation of the module design as a whole, and verification of each software unit and its interfaces.

Where the IEC 61508 development lifecycle is applicable, the analogous phase to module design is known as “Detailed design and development”. In either case, the TBmanager component of the LDRA tool suite can help by verifying that all aspects of system design are traceable to module design, and vice versa.

Coding

Static AnalysisStatic analysis, is a method of assessing the quality of software code by examining the code without executing it.

Both ISO 13849 (PLr c or d) and IEC 61508 require the use of coding standards, which are rule sets restricting the use of the chosen language to a preferred subset. In general, coding standards are used to specify a preferred coding style, aid understandability, apply language usage rules or restrictions, and manage complexity. The use of a static analysis tool is recommended to ensure that code complies with the nominated standard in a timely and cost-effective manner.

Verification tools such as the TBvision component of the LDRA tool suite largely offer support for a range of coding standards such as MISRA C and C++, JSF++ AV, HIS, CERT C, and CWE. Beyond the use of coding standards, automated static analysis can also make other valuable contributions, including the generation of code quality complexity metrics to help limit the complexity of source code, the enforcement of structured control flow, and the creation of data and control flow diagrams.

Lesson 2 – The software development lifecycle – specification, design and coding