I won’t go so far as to say that functional safety guys hate software but sometimes you would be forgiven for thinking so. From a safety point of view, software is deemed to have too many states and is said to be un-testable.
Figure 1 - A book I look forward to reading
Because of its un-testability there was no way to demonstrate the safety of software and instead in the past relatively simple logic was used, implemented with safety relays and the like.
However, given the flexibility and power that software brings to systems its use in safety was inevitable. With the advent of new standards such as IEC 61508-3 designers have a way to show that their software is sufficiently safe by following a set of techniques that have been shown to deliver safe software in the past.
Figure 2 - The power of software
Things which make software different to hardware include:
While software doesn’t wear out and doesn’t have random failures like hardware it can contain systematic errors. Systematic errors are errors which can only be removed by a design change i.e. change the code. Systematic errors are always present but are only exposed when a certain set of conditions arise. Hardware reliability uses traditional reliability methods and is based on probabilities. You can attempt to use probabilities for software, but the probability of software failure is 1; when the right conditions arise to expose a bug.
Estimates for the number of errors per 1,000 LOC (lines of code) vary but the estimates are generally in the range of 1 to 10 EPTLOC (errors per thousand lines of code) for good code. The book “Software assessments, Benchmarks and Best practices” by Addison-Wesley gives figures for various CMM (capability maturity models) levels as level 1 – 7 EPTLOC, level 2 – 6 EPTLOC , level 3 – 5 EPTLOC, level 4 – 2 EPTLOC, level 5 – 1 EPTLOC. While other data sources give values in the range of rates per 1,000 lines of code for office applications as 7, industrial applications as 2 and space shuttle applications as 0.1. All of this shows the challenge of making software safe.
The book “Software Safety primer” describes 5 types of software errors and estimates that 60% of the errors are related to specification and design with 40% related to coding.
So, what do the safety standards say. They advocate a set of methods and processes designed to reduce the chances of introducing an undetected error into the code. The lifecycle model below is advocated by IEC 61508:2010 and I will come back to it in a later blog. The process is holistic going the whole way from requirements to architecture to design and eventually to coding with verification and validation steps to match each stage.
Figure 3 - Software V-model from IEC 61508-3:2010
Typically, the processes advocated by functional safety standards are rigorous compared to even good software development practices advocated for the non-safety domains. The table below shows estimates of the gaps between CMMI and the avionics D0-178 standard.
Source page 172 of Avionics certification (see below)
The main gaps relate to things like
while tasks such as
are well covered by the standard non-safety high quality development processes.
Functional safety for software standards which are worth reading regardless of the domain for which you are developing include
While the end domain for each of the above is different the intent of each is the same and what is described badly in one standard is often described much better in another.
For those who want to read more on software safety for themselves, here are my recommendations.
This week’s video is at https://www.youtube.com/watch?v=gp_D8r-2hwk and shows an Ariane 5 rocket launch which doesn’t go so well due to a rounding issue in re-used software. The cause was related to the use of software from the Ariane 4 which was slower to accelerate.
This is the first in a series of software related blogs. Functional safety for software is a massive issue. It was hard to know where to go for the next blog but in the end, I decided that for next time, the discussion will be on “Software systematic capability”.