feature article
Subscribe Now

When Software Flies

Doing DO-178B

Software development is still, by far, the squishiest segment of the engineering discipline.

This is not because software engineers lack discipline.  Certainly some of the most methodical and disciplined individuals I have ever met were in the software engineering profession.  The problem is in the discipline itself – software is the most complex component of almost every modern embedded system.  As a component becomes more complex, our ability to conceptualize its operation and to design an organized methodology for its development and verification is dramatically reduced.

Aviation is one of the most conservative areas of engineering.  The acute awareness that even small engineering decisions and procedures carry a great weight in the potential loss of human life has pushed the community into a cautious rigor that would craze engineers accustomed to working in more liberal fields.  This extreme caution, and the regulation that goes along with it, has kept aviation decades behind the technology curve in many areas such as materials, powerplant design, and, most notably, electronics. 

When the loose and liberal landscape of software development eventually reached the “document and test every nut and bolt” conservatism of the aviation world, there was bound to be confusion.  Over the course of a few decades, that confusion settled into a standard for software development called DO-178B.  The standard was developed by the Radio Technical Commission for Aeronautics (RTCA) and the European Organization for Civil Aviation Equipment (EUROCAE).  It was later accepted by the US Federal Aviation Administration (FAA) as an acceptable means of developing and certifying software for use in avionics.

The process is based on the understanding that all software is not equal when it comes to its effect on aircraft safety.  DO-178B specifies a safety assessment process that considers the effects of a software-related failure in the system in terms of its impact on the aircraft, the crew, and the passengers.  Based on this assessment, software is rated at a particular level – A through E. 

Level A – “Catastrophic” means that a failure in the system may cause a crash.
Level B – “Hazardous” means that a failure has “a large negative impact on safety or performance, or reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers.”
Level C – “Major” means that a failure “is significant, but has a lesser impact than a Hazardous failure (for example, leads to passenger discomfort rather than injuries). 
Level D – “Minor” means that a failure is noticeable, but has a lesser impact than a Major failure (for example, causing passenger inconvenience or a routine flight plan change).
Level E – “no effect” means that a failure has no impact on safety, aircraft operation, or crew workload.

Each of these levels carries with it a corresponding number of development and verification objectives that need to be satisfied and a notion of the separation of the development and verification tasks that must be accomplished “with independence,” meaning that the responsibilities for development and verification must be separated so that the same engineers are not responsible for both the development and testing tasks.

Interestingly, unlike many aspects of aviation-related engineering, and in a world where things such as the proper rotational direction of safety wire are typically specified, DO-178B is objective-based, not process based.  The standard says you must have processes, and those processes must meet certain objectives, must have well defined entry and exit criteria, and must be documented.  It does not, however, specify what those processes must be.  The definition of the actual software development and testing process is left as an exercise for the user.  Caveat Engineer.  (Let the programmer beware.)

The standard, although complex, is straightforward enough that a reasonable development team, creating a software system from the ground up, would have a reasonable chance of digesting the documents and developing compliant software.  Notice, however, that we said “from the ground up”.  As anyone in software engineering knows, “from the ground up” is a fictitious situation that probably only really existed when the first line of code was written by the first software engineer – in approximately the year 1212.  (NOTE:  Don’t come back posting a thousand comments that this date is wrong.  We looked it up in wikipedia… or, maybe not.)

At the very least, if we’re developing an air-bound application, we will probably need to be using an operating system.  As you might have guessed by now, that operating system is software too, and it must be certified by DO-178B right along with your application.  Does that seem like a problem?  Here’s a hint:  The operating system running on the machine where you’re reading this article almost certainly doesn’t cut it.  Luckily, the people who make operating systems for embedded use have thought of this already and have provided support – in varying degrees.  RTOS offerings, including Wind River -VxWorks, LynuxWorks – LynxOS-178, Green Hills – Integrity-178B, Micrium – uC/OS-II, and Mentor Graphics – Nucleus, have all been certified under DO-178B and are promoted by their suppliers as “certifiable.”  (We too have been called “certifiable”, but we’re pretty sure that is in a different context.)

A “certifiable” RTOS still has to be proven in your system.  Most of these vendors supply some sort of a certification package that includes things like “Certification Evidence,” which is the documentation required to support whatever level of certification (A, B, C, or D) that your system is after.  There are also a number of consultancies that specialize in helping you get your system certified, and many of them have experience certifying systems with the OS components listed above.

LynuxWorks has taken the process one step farther, going after the relatively new Reusable Software Component (RSC) acceptance procedures outlined by the FAA.  These procedures are designed to allow certain certified components to be re-used without re-certification.  This means that some software components – like most of a typical RTOS, can be certified in a way that is portable.  LynuxWorks LynxOS-178 was the first OS to get RSC certification by the FAA.

The RSC approach is particularly useful in developing portable, safety-critical applications.  The re-use of certified software components also enhances overall safety by reducing the proliferation of large numbers of similar components, focusing the verification efforts on shared, portable, re-usable software.

Of course, the need for certification of the parts of your system you didn’t develop doesn’t stop with the OS.  Compilers (and linkers and loaders and…) are also in the critical path for software functionality.  A compiler bug can easily create a malfunction by generating incorrect code, even when the application developer does things right.  For the most common development languages like C, C++, and Ada, compilers and compiler verification tools are available to certify that the compiler is actually creating object code that does the same thing your source code intends.

The FAA cares less about your debuggers and your IDE in general.  Since those components are not actively modifying or generating source or object, they are not directly in the critical path for software reliability.  You are pretty much free to use your favorite IDE and debugging techniques. 

So, next time you’re in a meeting with those marketing folks, and one of them pops out something like “we could take this into the aerospace market as well,” you’ll be ready.  Grab a whiteboard marker.  Walk them through the basics of DO-178B.  It’ll make you sound smart. It’ll almost certainly get you an early adjournment for lunch, and – unless your company is in the aviation software business already, it’ll probably keep you away from the frustrations of flying software.

Leave a Reply

featured blogs
May 14, 2021
Another Friday, another week chock full of CFD, CAE, and CAD news. This week features a topic near and dear to my heart involving death of the rainbow color map for displaying simulation results.... [[ Click on the title to access the full blog on the Cadence Community site....
May 13, 2021
Samtec will attend the PCI-SIG Virtual Developers Conference on Tuesday, May 25th through Wednesday, May 26th, 2021. This is a free event for the 800+ member companies that develop and bring to market new products utilizing PCI Express technology. Attendee Registration is sti...
May 13, 2021
Our new IC design tool, PrimeSim Continuum, enables the next generation of hyper-convergent IC designs. Learn more from eeNews, Electronic Design & EE Times. The post Synopsys Makes Headlines with PrimeSim Continuum, an Innovative Circuit Simulation Solution appeared fi...
May 13, 2021
By Calibre Design Staff Prior to the availability of extreme ultraviolet (EUV) lithography, multi-patterning provided… The post A SAMPle of what you need to know about SAMP technology appeared first on Design with Calibre....

featured video

Industry’s First USB4 Silicon Success

Sponsored by Synopsys

USB4 offers up to 40Gbps speeds for incredibly fast connections. Join Synopsys to see the first demonstration of USB4 IP in silicon, along with real TX eyes for DesignWare USB4, DisplayPort, and USB 3.x IP.

Click here for more information about DesignWare USB4 IP

featured paper

Keys to quick success using high-speed data converters

Sponsored by Texas Instruments

Hardware designers using modern high-speed data converters face tough challenges. Issues might include connecting with your field-programmable gate array (FPGAs), being confident that your first design pass will work, or determining how to best model the system before building it. In this article, Texas Instruments takes a closer look at each of these challenges.

Click to read more

featured chalk talk

Single Pair Ethernet

Sponsored by Mouser Electronics and Phoenix Contact

Single-pair Ethernet is revolutionizing industrial system design, with new levels of performance and simplicity. But, before you make the jump, you need to understand the options for cables, connectors, and other infrastructure. In this episode of Chalk Talk, Amelia Dalton chats with Lyndsey Walling of Phoenix Contact about the latest in single-pair Ethernet for industrial applications.

Click here for more information about Phoenix Contact Single Pair Ethernet (SPE) Connectors