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
Nov 30, 2023
No one wants to waste unnecessary time in the model creation phase when using a modeling software. Rather than expect users to spend time trawling for published data and tediously model equipment items one by one from scratch, modeling software tends to include pre-configured...
Nov 27, 2023
See how we're harnessing generative AI throughout our suite of EDA tools with Synopsys.AI Copilot, the world's first GenAI capability for chip design.The post Meet Synopsys.ai Copilot, Industry's First GenAI Capability for Chip Design appeared first on Chip Design....
Nov 6, 2023
Suffice it to say that everyone and everything in these images was shot in-camera underwater, and that the results truly are haunting....

featured video

Dramatically Improve PPA and Productivity with Generative AI

Sponsored by Cadence Design Systems

Discover how you can quickly optimize flows for many blocks concurrently and use that knowledge for your next design. The Cadence Cerebrus Intelligent Chip Explorer is a revolutionary, AI-driven, automated approach to chip design flow optimization. Block engineers specify the design goals, and generative AI features within Cadence Cerebrus Explorer will intelligently optimize the design to meet the power, performance, and area (PPA) goals in a completely automated way.

Click here for more information

featured webinar

Rapid Learning: Purpose-Built MCU Software Tools for Data-Driven Embedded IoT Systems

Sponsored by ITTIA

Are you developing an MCU application that captures data of all kinds (metrics, events, logs, traces, etc.)? Are you ready to reduce the difficulties and complications involved in developing an event- and data-centric embedded system? This webinar will quickly introduce you to excellent MCU-specific software options for developing your next-generation data-driven IoT systems. You will also learn how to recognize and overcome data management obstacles. Register today as seats are limited!

Register Now!

featured chalk talk

Addressing the Challenges of Low-Latency, High-Performance Wi-Fi
In this episode of Chalk Talk, Amelia Dalton, Andrew Hart from Infineon, and Andy Ross from Laird Connectivity examine the benefits of Wi-Fi 6 and 6E, why IIoT designs are perfectly suited for Wi-Fi 6 and 6E, and how Wi-Fi 6 and 6E will bring Wi-Fi connectivity to a broad range of new applications.
Nov 17, 2023
1,813 views