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
Jul 28, 2021
The System Analysis Knowledge Bytes blog series will explore the capabilities and potential of the System Analysis tools offered by Cadence®. In addition to providing insight into the useful... [[ Click on the title to access the full blog on the Cadence Community site....
Jul 28, 2021
Here's a sticky problem. What if the entire Earth was instantaneously replaced with an equal volume of closely packed, but uncompressed blueberries?...
Jul 28, 2021
Hyperscale data centers are driving demand for high-bandwidth Ethernet protocols at speeds up to 800G to support HPC, AI, video streaming, and cloud computing. The post What's Driving the Demand for 200G, 400G, and 800G Ethernet? appeared first on From Silicon To Software....
Jul 9, 2021
Do you have questions about using the Linux OS with FPGAs? Intel is holding another 'Ask an Expert' session and the topic is 'Using Linux with Intel® SoC FPGAs.' Come and ask our experts about the various Linux OS options available to use with the integrated Arm Cortex proc...

featured video

Intelligent fall detection using TI mmWave radar sensors

Sponsored by Texas Instruments

Actively sense when a fall has occurred and take action such as sending out an alert in response. Our 60GHz antenna-on-package radar sensor (IWR6843AOP) is ideal for fall detection applications since it’s able to detect falls in large, indoor environments, can distinguish between a person sitting and falling, and utilizes a point cloud vs a person’s identifiable features, which allows the sensor to be used in areas where privacy is vital such as bathrooms and bedrooms.

Click here to explore the AOP evaluation module

featured paper

Configure the backup voltage in a reversible buck/boost regulator

Sponsored by Maxim Integrated

This application note looks at a reference circuit design using Maxim’s MAX38888, which provides a supercapacitor-based power backup in the absence of the system rail by discharging its stored charge. The backup voltage provided by the regulator from the super cap is 12.5% less than the system rail when the system rail is removed. This note explains how to maintain the backup voltage within 5% of the minimum SYS charge voltage.

Click to read more

featured chalk talk

Using the Graphical PMSM FOC Component in Harmony3

Sponsored by Mouser Electronics and Microchip

Developing embedded software, and particularly configuring your embedded system can be a major pain for development engineers. Getting all the drivers, middleware, and libraries you need set up and in the right place and working is a constant source of frustration. In this episode of Chak Talk, Amelia Dalton chats with Brett Novak of Microchip about Microchip’s MPLAB Harmony 3, with the MPLAB Harmony Configurator - an embedded development framework with a drag-and-drop GUI that makes configuration a snap.

Click here for more information about Microchip Technology MPLAB® X Integrated Development Environment (IDE)