Accidents will continue to happen, but better critical systems software will help to avoid them

There are many reasons why accidents continue, including increasing system complexity and the fact that digital systems can be compromised. "But there is also interaction between systems and interaction between people and systems," he noted. Martyn Thomas, pictured, an independent consultant, was more aggressive with his personal view of safety critical systems design. One of Thomas' main targets was those writing safety critical software. "Most critical software has been built using methods that aren't fit for purpose." In his opinion, the industry hasn't learned the lessons of the last 40 years. "One of the basic lessons has been the importance of type safety in computer languages, where a strong structure of data types meant tools could tell if you had made a mistake. Yet you will still find type errors," he contended. Thomas said a glaring example could be found on some websites. "If you type some Java script in an input field – for example, where text is supposed to be captured – the code will execute," he asserted. "And you'll see the same with SQL injection. It's completely unprofessional." His wrath is focused on C. "C rejoices in a weak underlying type framework," he continued, "which is why you get buffer overflows. C can't tell the difference between a pointer and a variable and there's no protection for the programmer who makes a trivial mistake." Thomas says the solution is the use of 'industrial strength' languages and tools. A language recommended by SCSC is SPARK, a subset of ADA. "This enables very deep static analysis," Thomas believed. "There are promising developments, including F#, but how do you stop people writing software in C?" There is a school of thought which suggests C is prevalent because it's the only language in which recent graduates can program. "What profession would allow its junior staff to dictate terms?," Thomas asked. "It makes no sense at all, because learning new languages is not difficult." Apart from the use of C, Thomas despairs at the decline of the formal specification. "It's where you get the biggest return for a small investment," he contended. "If your spec is informal, you don't know what it is you're trying to do." Supporting the argument, Thomas advanced statistics from NASA, which showed that less time spent developing requirements correlated with longer project overruns. Code is but one of Thomas' criticisms of safety critical system design; another is system boundaries. "Where do you draw a system boundary?," he asked. "What people forget is that users are inside the system and should be treated as such; for example, pilots should be part of an avionics system. So training users should also be seen as safety critical, if you assume the user will recover the system when it fails. So simulators could be seen as safety critical, but they are not built to this standard." He is also wary about claims of system safety. "Most claims that systems are safe are based on inadequate evidence and part of the reason for this is we set safety targets probabilistically, then ask people to meet targets that can't be determined. All that can be provided is evidence that the computer system runs tests. If you can't model the consequences, you shouldn't build the system." Things to bear in mind? "Never ignore a near miss," he advised, "it's a valuable warning of a potential accident. And beware of single failures that have multiple effects." In his view, failure of the GPS system is one such possibility. "A $200 jammer has sufficient power to take out GPS in the South of England, but nobody seems to care."