Consider common causes of failure in the process industries, such as pipes becoming corroded and fracturing, valves sticking, or other physical problems with individual components.

The safety of the whole system depends on the reliability of these individual components, so systems are designed to eliminate (so far as practicable) single points of failure where one component could fail and cause an accident. Even where this involves precisely duplicated components, the exact timing of any likely failure is sufficiently unpredictable (“random failure”) for it to be extremely unlikely that both will fail at the same time (Figure 1).

Figure 1: A pumping system designed using the principle of dual modular redundancy

In those cases where the single point of failure cannot be eliminated (the rotor blades in a helicopter, for example) these critical components have to be designed and built in such a way that failure is extremely improbable. A process of hazard analysis attempts to identify all the dangerous states that the system could get into, and fault trees are drawn up to analyse the circumstances that could lead to each dangerous occurrence. Such a process is built on an underlying assumption that the system design is sound. If that is not the case, any resulting “systemic” failures will always occur whenever particular circumstances co-exist.

Software does not age in the way that physical components do. Software failures are, in general, the result of software faults that were created when the system was specified, designed and built and these faults will cause a failure whenever certain circumstances occur. They too are systematic failures, but in a world where (for example) modern cars can contain 100 million lines of software it would be foolhardy to ignore them.

Redundancy in software

Most functional safety process standards reference some form of a “V” model. Consider the example shown in Figure 2 from EN/ISO 13849:2015, “Safety of machinery — Safety-related parts of control systems”

Figure 2: V-model software development lifecycle model from ISO 13849:2015, “Safety of machinery – Safety related parts of control systems”

Suppose that the simple system shown in Figure 1 is to be upgraded and applied to a situation where each pump needs to have its own custom-built, safety critical, embedded controller, to be developed in accordance with ISO 13849.

If the same controller is applied to both pumps, then the robust dual redundancy protection afforded in the original system will be compromised. If there is a bug in the software that causes a pump to malfunction under a particular set of circumstances, then both pumps will fail at the same time.

If that is unacceptable, then the risk can be minimized by deploying two different design teams to develop the system from requirements through to completion, using different hardware, different operating systems, and discrete development teams using different high level languages.

That might be commercially justifiable – but probably not. For a compromise to be made, a definition of what represents a system that is “safe enough” is required. A common approach to quantifying that leverages the value placed on a statistical life or VSL. This is defined as the additional cost that individuals would be willing to bear for reductions in risks that, in the aggregate, reduce the expected number of fatalities by one.

With reference to the V-model in Figure 2, the development lifecycle of new code can be dissected to reduce risk to an acceptable level without resorting to entirely separate developments. For example, one approach to reducing risk whilst limiting expenditure might be to use a common design, but to develop two control system software packages based on it. In this scenario, the risk of a shared design flaw remains, but the likelihood of a shared software bug or coding error is considerably reduced.

Other compromises might be to use two different POSIX-compliant RTOS, which would allow the same code to be executed on either, the same code running on different hardware, different compilers…. the possibilities, especially in combination, are almost endless.