Developer's Toolkit

Blog archive

We Can’t Live with Embedded Bugs

The Tuesday, May 30, 2006 Wall Street Journal (www.wsj.com; paid subscription required) offers an unusually candid look at how flaws in avionics software can introduce new elements of risk into flying. It cites several documented examples where software bugs provided wrong or conflicting information to flight control systems, which responded by making the wrong decisions, putting crew and passengers in danger.

Avionics and other safety-critical systems are built differently from business software, and any comparison between the two is unrealistic. Aviation software is regulated by a standards body called RTCA (http://www.rtca.org); the applicable standard is DO-178B, Software Considerations in Airborne Systems and Equipment Certification. Aviation system software cost a great deal more to develop, and is commensurately more reliable.

But aviation software is also getting much more complex. The WSJ article notes that the average airliner today has about five million lines of code, as opposed to about one million on older planes. As complexity grows, so does the potential for bugs. And future airliners (the Airbus A380 and Boeing 787) are integrating avionics systems so that the same software will perform many related tasks, rather than using separate programs for specific and narrow operations. This could well further increase complexity.

How can we resolve the conflict between complexity and reliability when lives hang in the balance? Here are two broad suggestions.

1. Establish development and testing procedures that maximize the likelihood of producing high quality software. Experience tells us that perfection cannot be achieved, even at prohibitive costs. But if there were ever a need for defined and enforced processes for development and test, this is it. But rigorous adherence to software engineering principles during development, and the use of comprehensive cases and analysis during test, can bring incremental improvements to software quality.

2. Fail safe. Besides being the name of a classic movie, it also refers to the concept that a system should fail in the safest possible way. In the case of aviation systems, a system failure or data conflict should result in control being turned back over to the pilots in a way that enables them to seamlessly take over. The design of such software will be a challenge, but it is achievable.

There is no panacea to producing high-quality software for safety-critical systems. The challenge will be greater as avionics become more complex and interrelated. But as the WSJ article points out, software-enhanced avionics systems have actually helped make flying significantly safer over the last two decades. We shouldn't give up these benefits, but building safety-critical systems is a need that is growing rapidly.

Posted by Peter Varhol on 05/30/2006


comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube