Is Aviation Software Dangerous ?

Posted by Kevin Brady on Mon 25th February 2008 at 11:19 AM, Filed in Software Development

Recently, on a flight to Bangalore India and in the ensuing boredom I struck up a conversation with the passenger sitting next to me.

After a short chat it was clear we had something in common professionally. It turned out that “Mr X” was a senior software engineer for Honeywell and responsible for the developing of new fly-by-wire flight systems.

“Wow” how interesting! A branch of IT I knew little about, and an opportunity to learn something new.

One of the first questions I asked “Mr X” was concerning a matter that had bugged me for years. I wanted to know “If aviation software suppliers /developers build software in a different way to the rest of the IT industry (which has a poor reputation for software reliability).

Ultimately our lives depend on it, RIGHT!”

He stated that aviator software was indeed developed to a higher standard when compared to the rest of the IT industry, and conformed to a standard set of standards developed by the US-based Radio Technical Commission for Aeronautics, and more specifically regulations DO-178B. He explained that these regs are recognised by the Federal Aviation Administration (FAA), and rate software on how seriously it would compromise safety were it to fail. Then it recommends different levels of testing depending on the rating. “The most rigorous “level A” tests, reserved for software whose failure would cause a catastrophic event, are called “modified condition /decision coverage”(MCDC), and it tests the software in as many situations as possible to see if it crashes or produces anomalous output”.

“If this testing is so great” I pointed out “then how come I read in the newspapers that the National Academy of Sciences (NAS) had catalogued a number of frightening problems during commercial flights?” In one instance in August 2005, a computer in a Boeing 777 presented the pilot with contradictory reports of airspeed. “The gauges apparently stated that the plane was going so fast it could be torn apart, and at the same time that the plane was flying so slowly it would stall”. I questioned how this could happen if the regulations were as good as he claimed.  Furthermore, I showed Mr X the “Daily Mail” sitting on my lap which was detailed a crash landing at Heathrow due to a suspected software failure. All a real worry in my view.

He stated that he believed these were rare and isolated occurrences, and that he had a strong belief in the regulations and the standards of care taken in aviation software development from 20 years of hands-on experience in this area. While he was saying this I got the sense from his body language that he perhaps was not being as truthful about this statement as he would have liked. I then asked one final question before he cut the conversation short with the statement that he was turning in for some sleep. The question was “what code does Boeing use to build its flight control software”? He stated that “they used a mixture of languages C, C++, assembler and Ada”.

This surprised me as “C” allows programmers to write vague and /or ambiguous code, which is the kind of thing that often leads to bugs.

Wow more worries!!

I could immediately see that aviation software was prone to failure in two areas:-

• Whatever software you build, it has to sit on some kind of middleware or operating system constructed and built by organisations outside the aviation industry regulations. This is a serious area for potential latent software defects.
• The aviation industry develops aviation systems with code which does not verify itself as it is coded, such as B and SPARK (version of Ada). These languages, and their compiler software, have strict controls within them, which makes it very difficult for programmers to write vague or ambiguous code.

I then read in the Daily Mail that the National Academy of Sciences (NAS) had published a report recently stating that indeed stricter controls on languages were required, stating that “Safe programming Languages are likely to reduce the cost and difficulty of producing dependable software”
My concern with all this is how long are we going to use tools and operating systems which we know are not fit-for-purpose to develop software upon which peoples lives depend (on working 100% correctly a 100% of the time)? In the civil engineering or construction industry the use of tools with known and potentially dangerous faults would not be tolerated for a moment. So why do we accept a lower standard of care in the aviation industry?

This needs to be fixed soon before people get hurt.

These thoughts didn’t exactly help me sleep for the remainder of the flight :(

This entry has been viewed 1134 times.

READER COMMENTS: