Software Development Assurance integral processes

The detection and diagnosis tasks can be carried out on the process measurements to obtain critical insights into the performance of not only the process itself but also the automatic control system that is deployed to assure normal operation. Today, the integration of such tasks into the process control software associated with Distributed Control Systems (D-CS) is in progress. The technologies continue to advance, especially in the incorporation of multivariate statistics as well as recent developments in signal processing methods such as wavelets and hidden Markov models. 

A complete lEC 61508 assessment includes a FMEDA, a study of Prior Use and adds an assessment of all fault avoidance and fault control measures during hardware and software development as well as detail study of the testing, modification, user documentation and manufacturing processes. The objective of all this effort is to provide a high level of assurance that an instrument has sufficient quality and integrity for a safety instrumented system application. This is clearly more important for products containing software as many end users have the strong opinion that software is "bad... 

Software reliability assessment is different from traditional reliability techniques and requires a different process. The use of development standards is common in current good practice. Software safety standards recommend processes to design and assure the integrity of safety-related software. However the reasoning on the validity of these processes is complex and opaque. 

Systemic failures are due to human errors (e.g. mistakes, misconceptions, miscommunications, omissions) in the specification, design, build, operation and/or maintenance of the system. Errors in this case are taken to include both mistakes and omissions. Errors can be introduced during any part of the lifecycle and errors are caused by failures in design, manufacture, installation or maintenance. Systematic failures occur whenever a set of particular conditions is met and are therefore repeatable (i.e. items subjected to the same set of conditions will fail consistently) and thus apply to both hardware and software. It is difficult to quantify the rate at which systemic failures will occur and a qualitative figure based on the robustness of the development/build process is normally used. The probability of systemic failures is often evaluated by means of safety integrity (or development assurance) levels. 

It is almost impossible to test complex software fully - even if it is run many times - as there are an almost infinite number of possible loops, variables and subroutines that may or may not be run in any single program. Program operation is by its very nature non-linear or non-determined and therefore can never be fully tested at box level. For these reasons, reliability calculations are not applied to software, as it has no MTBF. Instead, we make use of development assurance levels (DAL) or safety integrity levels (SIL) (see Table B.6). The main aim or purpose of DALs and SILs is to introduce a number of repeatable life-cycle processes which (if used by the developer) will produce a final product that is capable of meeting not only the original specification requirements, but also producing the correct level of safety both for the developed equipment and the overall aircraft. 

At the other end of the spectrum, are standards which address the processes of development and manufacture - non-safety examples range from the very broadly based ISO 9000 series to the more specific ED-78A (Guidelines for the Approval of the Provision and Use of ATS Supported by Data Communications) and ED-109 ( Guidelines for CNS/ATM System Software Integrity Assurance). In none of these cases would it be appropriate to certify a product against them, from a safety viewpoint however, compliance with such standards, especially the more specific ones, could provide excellent Backing Evidence for safety requirements... 

---