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!”smile

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:

As one famailar with avionics in the manned spaceflight area (using the same 777 suite), there’s more to testing than the IT folks understand.
A full fidelity simualtion of the spacecraft, with full fidelity realtime behaviour is the starting point for the Verification and Validation process. This Independent V&V;stage is missing in IT.
As well, the specification of the design and development of the code is orders of magnitude more controlled in avionics than in IT.
No one woudl dare to change a line of code in a production product without a full change board review and approval. Quite the opposite of the “change on the fly” approach I’ve seen in many enterprise IT projects.

Posted by Glen B. Alleman  on Sun 2nd March 2008 at 09:00 PM | #

Thanks Glen for your interesting contribution. I am glade to hear that you have confidence in the testing aspect of Avionics software delivery. However,one of the points i make in this post is that more latent and more importantly life threatening software defects might be present in flight software due to the languages used to construct the software. Latent defects are by their nature not always picked up through testing. You only need one at the wrong time /place to be life threatening. We have to listen to the recommendations of the National Academy of Sciences (NAS) who are calling for the restricted use of only certain types of software code for the building of mission critical flight software.

The numbers of flight software reported faults being reported that have lead to near catastrophes does appear to be on the increase.

I am calling for an international review of this area by the FAA and where appropriate a tightening up of the regulations /controls and independent QA checks in this area of software development.

Posted by Kevin Brady  on Mon 3rd March 2008 at 09:07 PM | #

Kevin,
Could you post the link to the references of the “increase in FSW defects.”
What’s more interesting is the offshoring of the FSW development teams. This is not outsourcing, but it does move the development teams from the US to the far east.
In the deepspace coding business Handel (as in Franz Joseph) is the language of choice, where the FSW ends up in FPGAs or ASICS.

Posted by Glen B. Alleman  on Tue 25th March 2008 at 02:11 AM | #

POST A COMMENT:

Please feel free to submit relevant comments to this entry but note: inappropriate or purely promotional comments may be removed as will be personal abuse and defamatory remarks. Reasoned debate and substantiated critique on the topic in hand is encouraged and welcomed. Email addresses are never displayed, but they are required to confirm your comments.

Name:

Email address is required but will not appear publicly:

Add your comments below:

Remember my personal information for next time

Submit the word you see below:

1 + 4 =