Electronic Design

DO-178B: Fail-Safe Aviation

A - catastrophic
B - hazardous-severe
C - major
D - minor
E - no effect

I've never written applications for airplanes, but I do try to write applications that degrade gracefully. It's not too hard a task when it comes to microcontrollers, where control over all of the code is relatively common. At the other extreme, though, is DO-178B, the U.S. de facto standard that defines the guidelines for the development of aviation software. Attaining DO-178B certification is a long and meticulous process. Innumerable artifacts must be maintained and tracked. Just the list of documents and records is extensive, not to mention the actual information that must be collected, correlated, inspected, and verified.

DO-178B is just one of many standards from RTCA Inc. (www.rtca.org), originally known as the Radio Technical Commission for Aeronautics. Unlike interface standards, DO-178B specifies a process to follow and artifacts to collect. The end result is supposed to be a highly reliable product that can handle a variety of errors when deployed. It doesn't guarantee that a product will be able to handle every situation or that it has been tested under all conditions. Nonetheless, every effort is made to do so, and there's documentation to back up those claims.

A small but growing number of companies deals in DO-178B-related products, yet the entry bar is high. Vance Hilderman, VP of Enea Embedded Technology, North America, says, "New suppliers polled believe DO-178B adds 50% to 100% to development costs. But knowledgeable suppliers say added cost is only 20%, and increased quality and maintainability make it well worth it. There is a huge delta, depending upon experience and best practices." Experience and best practices are the key to applicability outside of the aviation industry.

For example, what do you know about the real-time operating system (RTOS) you're using? Has it been certified to DO-178B level A? It's not enough to simply have the source code in hand. This is a sufficient starting point to begin certification, but the task of certifying just the RTOS is significant. This has made companies like Aonix, Enea, Lynuxworks, Green Hills Software, Wind River, and BAE Systems very important to developers seeking certification for their products.

Most DO-178B RTOS vendors supply the same RTOS to commercial users. Inder Singh, CEO and chairman of LynuxWorks, indicates that developers can use the same version of its LynxOS as DO-178B customers at a significantly lower price. What's missing is the documentation and records necessary for DO-178B certification. These must be combined with corresponding documentation for the rest of the system when applying for DO-178B certification.

Another key issue about using a DO-178B certifiable RTOS is the version involved. It tends to be very stable, although that's not the case for the latest available version of the noncertified RTOS. This is because all new features or even minor changes to a DO-178B system require recertification. Many need the latest enhancements, but being proven is more important for most applications than being current.

One thing DO-178B RTOSs have in common is the ARINC-653 application programming interface (API). ARINC-653 is a partitioning system and scheduler designed to prevent cascading failures when an application goes awry. In fact, ARINC-653 is very important to DO-178B because it allows applications to be isolated. Thus, application recertification is possible versus recertification of the entire system. ARINC-653 along with POSIX support provides a level of compatibility among DO-178B RTOS vendors that enables easy migration of applications from one RTOS to another. This type of migration is rarely done because entire systems must then be recertified. But the use of ARINC-653 can be invaluable to commercial users from a standards as well as a portability view.

Though standards comparable to DO-178B are active in other industries, DO-178B still tends to be one of the most rigorous. That should make our pilots feel more secure. So DO-178B may be worth considering, even if it's not required for your application.

Plan for Software Aspects of Certification (PSAC)
Software Development Plan (SDP)
Software Verification Plan (SVP)
Software Configuration Management Plan (SCMP)
Software Quality Assurance Plan (SQAP)
Software Requirements Standards (SRS)
Software Design Standards (SDS)
Software Code Standards (SCS)
Software Requirements Data (SRD)
Software Design Description (SDD)
Software Verification Cases and Procedures (SVCP)
Software Life Cycle Environment Configuration Index (SECI)
Software Configuration Index (SCI)
Software Accomplishment Summary (SAS)
Software Verification Results (SVR)
Problem Reports
Software Configuration Management Records
Software Quality Assurance Records

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.