Functionality of avionics software continues to expand. Additional software capabilities bring many more lines of code, and greater opportunity for error. At the same time, the more critical an avionics software suite becomes, the higher its risk of cyber terrorism and being hacked, so current and future safety-critical software offer safety and security with software development tools, testing and verification utilities, and operating systems that are tamper-proof.
“When it comes to avionics, I think everyone understands that whenever you get on a plane, your life is completely in the hands of a fairly large and compact piece of software,” notes Robert Dewar, president of AdaCore in New York.
“We have fortunately not experienced an aircraft accident where a software bug has resulted in loss of human life,” Dewar points out -- but with a caveat. Although no one has died from a software problem on a commercial flight, "there have been some close calls; we have had one or two hair-raising incidents,” he adds.
A Malaysian Airlines flight in August 2005 had an “in-flight upset” in which software fed faulty accelerometer data into the primary flight computer, autopilot, and other aircraft systems. Original testing did not uncover the software anomaly. “We definitely can improve what we do,” Dewar says. "The avionics software supplier and the Federal Aviation Administration (FAA) need to have much higher assurance in the system's reliability, safety, and security.”
Diligent development
“Safety-critical software has to be bug free, and it has to work according to specifications,” Dewar explains. That's where the FAA's DO-178B standard comes in. This standard, officially known as Software Considerations in Airborne Systems and Equipment Certification, can make safety-critical code expensive to develop, "but the alternative would not be acceptable.”
The standard is “basically a formalized testing protocol that requires a very careful collection of all the requirements in a formalized form,” Dewar describes. “You have to develop comprehensive tests that test out every requirement; the effort of producing those tests means the code is very carefully looked at, but there isn’t any mathematical proof that the things work. People are moving more in the direction of mathematical proof and formal methods.”
Static analysis software tools can analyze source code to derive properties such as maximum memory usage that can help detect errors that might not be apparent to the programmer, while dynamic analysis tools can help show what code is executed by a test suite. “All have their place in safety-critical development,” Dewar says.
Engineers from the Lockheed Martin Aeronautics Co. in Marietta, Ga., used AdaCore’s GNAT Pro to develop the Flight Management System Interface Manager and Radio Control software on the C-130J Super Hercules aircraft. They used GNAT Pro High-Integrity Edition for a PowerPC target running VxWorks 653, the time- and memory-partitioned, real-time operating system (RTOS) from Wind River Systems in Alameda, Calif. GNAT Pro helped with the Block 7.0 software upgrade of the C-130J's new flight management system developed by GE Aviation in Grand Rapids, Mich., and Lockheed Martin Aeronautics.
Entrenched in Ada
Ada has for decades been the standard for reliability in avionics software and other mission-critical applications. “Tens of millions of lines of Ada is running around the DOD,” Dewar says. “Ada has disappeared from most people’s awareness, but not in the area of big, safety-critical programs,” admits Dewar. “GE Aviation did quite a bit of new Ada development for the [Boeing] 787; between 40 and 60 percent of the avionics software on the 787 is in Ada.”
National Air Traffic Services (NATS) in Whiteley, England, provides air traffic control for aircraft flying in United Kingdom airspace and over the eastern part of the North Atlantic, selected Altran Praxis Ltd., a specialist in embedded and critical systems engineering in Bath, England, to develop the advanced iFACTS system and to support and maintain its Traffic Load Prediction Device (TLPD). The iFACTS replaces traditional paper information strips with electronic data and new displays, provides tools for trajectory prediction, conflict detection, and monitoring aids. The TLPD uses flight plan, tactical, and radar messages.
Ada was designed from the start as a secure language. “It’s not a magic bullet, but you really want to take advantage of a language that’s considerably more secure,” Dewar recommends. “C++ and Ada are really night and day. If you are programming in Ada and you have quantities that are U.S. or metric measures, those would be separate types that you couldn’t mix up in an unfortunate way. In a typical C/C++ program, it’s all too easy to mix something like that up. The Mars Climate Orbiter (MCO) was lost because of confusion between metric and non-metric types. Of course, anyone can manage to write junk in any language, but such an error is less likely in an Ada environment.”
Model-based design
In general, the goal of any software development process is to deliver high-quality and robust software that meets the customer’s requirements, says Jon Friedman, aerospace and defense industry marketing manager at The MathWorks in Natick, Mass. “A well-defined process includes the following phases: a requirements capture and validation stage, design and test, implementation and integration, final verification, and sign off. However, many mission critical applications also have to conform or be certified to specific industry standards, such as IEC-61508, ISO-26262, or DO-178B.
“These standards require specific steps be followed and artifacts produced,” Friedman adds. For example, within DO-178B, requirements have to be established and tests identified to verify that the requirements are met; in addition, each line of code needs to be traced back to a requirement to be able to demonstrate why it is included in the code, he says.
The impact of incomplete design testing can be seen in the unfortunate failure on the MCO, which burned up in the Martian atmosphere when it entered a lower trajectory than planned. “The final integrated design was not fully tested and the results were catastrophic,” Friedman explains. In another example, the control software for the Ariane 5 (501) was primarily reused from the Ariane 4, but the mission profile of the Ariane 5 was different. “As a result, an arithmetic overflow caused a set of cascading failures that resulted in the destruction of the rocket.”
Engineers have to create and verify that their designs meet ever more complex system level requirements. To meet this challenge, many engineers have adopted model-based design. This approach starts with the same set of requirements as a traditional design, but engineers develop executable specifications in the form of models rather than textual specifications, Friedman says.
Prime contractor Swedish Space Corp. (SSC) in Solna, Sweden, developed the attitude and orbit control system (AOCS) of the Small Missions for Advanced Research and Technology (SMART-1) using automatically generated flight code. "The MathWorks tools for model-based design helped us to design and automatically generate code for the SMART-1 flight application software for attitude control, power control, thermal control, and FDIR," explains Per Bodin, SMART-1 AOCS manager at SSC. “Based on this success, we plan to develop all onboard application software, nearly 95 percent of the full flight software, using Simulink and Real-Time Workshop Embedded Coder.”
SSC implemented a new development process based on The MathWorks tools for model-based design to model, simulate, automatically generate code, and test the onboard AOCS software. SSC used The MathWorks tools to generate the application C code automatically, which was compiled, integrated, and linked into the overall onboard software. Engineers developed accurate simulation models to predict system behavior and to create exhaustive system and software test cases, which met the European Space Agency (ESA) PSS-05 software development standard.
In addition to meeting low-level software requirements, the unit and integration tests included structural code coverage analysis, input range testing, and max-path testing. SSC performed software system testing on a hard real-time simulation environment and analyzed the results with MATLAB. They verified the AOCS at the system level using the integrated spacecraft. These tests included open and closed-loop tests at the European Space Research and Technology Centre (ESTEC) in the Netherlands.
Validation and testing
For safety-critical avionics software, the requirements for testing and validation are higher than most other software, recognizes Andy Chou, chief technology officer of Coverity Inc. in San Francisco. “A failure in an aircraft software system may cause environmental and equipment losses at best, and injury or death to human beings at worst; hence, for avionics software, there is a higher level of requirement on the correctness of its behavior -- all the way from when the requirements for the software are defined, a higher level design is decided, and a detailed specification is created, down to when code is written. To ensure that avionics software behaves as expected requires that validation and testing is targeted at each of the design and development stages,” Chou explains.
Coverity’s developer solutions for automated code testing use advanced static analysis. Users can analyze parts of software without needing to execute the entire system, which is useful as avionics software components are added from third-party suppliers. “It gives an early indication of the potential safety issues by detecting software defects in supplier’s software at the code level before integration at system or aircraft level,” Chou adds.
On the requirements side, software designated engineering representatives (DERs) help the FAA ensure compliance, checking information provided by the applicant to show that DO-178B processes were followed in developing airborne software. “There is no single tool that can provide a guarantee of compliance. A combination of multiple processes and tools has to be used. Static analysis is one form of developer testing and verification. In its most basic form, one can consider it an automated code review,” Chou says. “The goal is to look for inconsistencies in code which are indicators of workmanship. At a minimum, such inconsistencies indicate broken processes in design and development.”
An unnamed provider of communication and aviation electronics solutions uses Coverity to help enforce software integrity across its product line, as well as provide assurance of the quality, safety, and security of code it provides to its software supply chain, consisting of large aircraft manufacturers.
“The company realizes the importance of DO-178B conformance and its value, which validates that compliant processes are followed in developing the software,” Chou notes. “More importantly, they understand that DO-178B compliance does not necessarily mean bug free. What it boils down to is ensuring that they use all tools and technology at their disposal given the safety-critical nature of the aviation software they create, whether mandated in DO-178B or not. Part of their motivation is this understanding that even developers of non-safety-critical software have adopted static analysis to ensure that their software does not crash or operate in an unpredictable manner.”
Safety critical is security critical
Any safety critical software today is also security critical, Dewar proclaims. “All safety-critical software is bound to be security critical, too. If your life depends on no bugs, then it also depends on no bad guys hacking into such a system. Security-critical software has to be impregnable to deliberate attack from outside. Worrying about cyber security is not crying wolf, there are huge potential weaknesses in our whole infrastructure. In a way, I look at the modern world and I think it’s amazing that more horrible things haven’t happened.”
“The consequences of using an untrusted or non-proven solution are severe, and can include loss of aircraft and its cargo, whatever that may be,” says John Warther, vice president of government programs at Green Hills Software in Santa Barbara, Calif. “The folks at [the Research and Innovative Technology Administration’s] Volpe National Transportation Systems Center in Cambridge, Mass., are looking at some of these issues, as is RTCA Special Committee 216 [in Washington].”
From a security perspective, a back-door communication mechanism to either an airborne or ground-based flight control system is a potential terrorist threat, says Robert Day, vice president of marketing at LynuxWorks Inc. in San Jose, Calif. “Remote connection to and subsequent communication with an aircraft in flight could inflict widespread terrorist damage from anywhere in the world. This could apply to both military and commercial airframes. Having systems that can detect, resist, or limit these threats is of paramount importance,” he says. LynuxWorks products have been used in airborne, flight-critical, and ground-based systems requiring safety and security functionality.
RTOS and partitioning
“Only real-time operating systems are viable for avionics systems to provide the high degree of reliability and security required,” Warther says. “The RTOS should be designed from the ground up with secure partitioning to meet the highest levels of assurance and guarantees for time and space.”
A partitioned RTOS offers protection of memory and applications by allocating, or partitioning, resources, Day mentions. Each partition provides protection against any faulty behavior exhibited by other applications. “In an avionics system, partitioning has been typically used to prove that multiple functions running on a single system can be protected from one another,” he says. “These operating systems are typically used to prevent against and or help contain fault conditions, rather than malicious attacks because the systems are often a self-contained entity (i.e., not communicating with the outside world).
“As avionics systems consolidate more and more physical hardware and systems onto a single platform and, at the same time, add more and more communications links to the outside world, the greater the issue of malicious faults being injected into the system,” Day continues. “A traditional partitioned safety-critical RTOS may prevent some of them, but to be really secure in the air, a Multiple Independent Levels of Security (MILS) separation kernel is a better choice. It has a partitioned system with security features built into it, and has been exposed to more rigorous penetration testing against malicious attacks.”
L-3 Communications Display Systems staff chose LynuxWorks’ LynxOS-178 RTOS to power a portion of the Panoramic Cockpit Display (PCD) subsystem for the Lockheed Martin F-35 Joint Strike Fighter (JSF) aircraft. The DO-178-certifiable RTOS was selected for its adherence to open standards, its Linux compatibility, the interoperability benefits of a POSIX API, and support for the ARINC 653 specification. The LynxOS-178 RTOS provides security through virtual machine brick-wall partitions.
“We chose LynuxWorks's operating system because the company offered a very complete RTOS and artifact package, along with support services and business models that were unmatched by other vendors," says Bob McGill, president of L-3 Displays Group. "With LynuxWorks, we were able to capitalize on their product's strengths and deliver a solution that will exceed our customers' expectations with respect to performance and safety."
RTOS and development environment
Lockheed Martin’s F-35 Lightning II Joint Strike Fighter also takes advantage of secure software solutions from Green Hills Software. Lockheed Martin engineers selected Green Hills Software's Integrity-178B RTOS and AdaMULTI integrated development environment (IDE) to develop safety- and security-critical software for the F-35. Avionics software developed by Lockheed Martin is running on Integrity-178B in multiple airborne, Power Architecture-based systems, says a Green Hills representative.
Green Hills has a long pedigree of operating in military aircraft, Warther mentions. “Today, the Integrity-178B operating system is being designed or has been deployed into almost every major next-generation commercial and military aircraft. Among them are Boeing’s new 787 Dreamliner, F-22 Raptor, C-130J Super Hercules, VH-71 Marine One helicopter, Airbus’s new A400M military transport, Northrop Grumman’s B-2 Spirit Stealth Bomber, Boeing’s C-17 Globemaster III military transport, and Sikorsky’s S-92 helicopter.
Lockheed Martin Aeronautics staff selected the Integrity RTOS for the F-16 fighter jets on-board Color Display Processor (CDP). The CDP generates real-time video for cockpit displays, enabling pilots to monitor aircraft situation, engine performance, and weapon system functionality in flight. Lockheed Martin Aeronautics also is using Green Hills Software's Multi IDE to develop CDP application software, which runs on a PowerPC PPC7400 processor under the Integrity RTOS.
“We need an ultra-reliable RTOS for the CDP," says Darrell Kindley, F-16 block 60 core processors and displays team lead at Lockheed Martin Aeronautics. "In particular, we need a memory-protected, partitioned RTOS that enables us to isolate different parts of the application from others, so that errors in one part of the application will not affect other parts of the CDP. Integrity's built-in memory protection, together with its hard real-time response and guaranteed resource availability, made it a perfect fit for this safety-critical application."
COTS RTOS
The use of commercial off-the-shelf (COTS) tools in mil-aero environments is not limited to hardware. COTS software, including operating systems, is increasingly making its way into mil-aero platforms.
The Boeing B1-B also employs the GE Intelligent Platforms Octegra3 6U VME rugged video/graphics processor and VIM2 rugged video input mezzanine, as well as a certifiable Board Support Package and OpenGL ES SC drivers, to process multiple video input streams simultaneously, providing situational awareness to the crew.
Boeing officials required the subsystems be DO-178B certified, meaning that the development process used conforms to strict quality criteria designed to maximize the safety of airborne systems. GE Intelligent Platforms subcontracted Ultra Electronics Controls in the U.K. to undertake the necessary development and qualification of the board support package (BSP), while Presagis provided a DO-178B-compliant version of its OpenGL embedded graphics solution.
“Deos has already been certified to DO-178B Level A in dozens of programs and flies on more commercial and military airframes than any other certifiable COTS RTOS,” says Greg Rose, vice president of marketing at DDC-I in Phoenix. “Deos represents the culmination of hundreds of person-years of engineering investment.” The Deos RTOS, originally developed at Honeywell, flies in the Airbus A400M, Augusta AB-139 Helicopter, Australia CASA, Boeing 787, the Bombardier Global Express, C-5, C-17, C-130J, CV-22 Osprey, F-18, Cessna Citation V and Sovereign, and various Dassault, Embraer, Gulfstream, and Raytheon platforms.
Goodrich Sensors and Integrated Systems has selected DDC-I’s time and space partitioned Deos RTOS, OpenArbor development tools, and DO-178B certification artifacts for use in the Concentrator and Multiplexor for Video (CMV), which is part of the Airbus A350’s External Cameras and Cockpit Video (ECCV) System.
DDC-I’s memory-protected RTOS features deterministic real-time response and employs patented “slack scheduling” to deliver high CPU utilization. “Deos is the only certifiable time and space partitioned, COTS RTOS built from the ground up for safety-critical applications,” says a company spokesperson. “Deos also provides an easy, low-cost path of any COTS RTOS to DO-178B Level A certification, the highest level of safety criticality.”
Development support for Deos includes DDC-I’s Eclipse-based OpenArbor IDE with C and C++ optimizing compilers, a color-coded source editor, project management support, automated build utilities, and a mixed-language, multi-window, symbolic debugger.
Software security
Software-defined radios (SDRs) fielded for platforms such as the U.S. Air Force’s F-22 and F-35 aircraft, and for Joint Tactical Radio Systems (JTRS) ensure security through encryption. “Software enables technology refresh, and with proper controls the entire Operational Flight Program (OFP) can be secured through encryption,” explains John Balcerzak, business area manager, space and avionics programs, General Dynamics C4 Systems, Information Assurance Division, in Scottsdale, Ariz.
Platforms and radios that are not software-based will have difficulty adopting new capability enhancements, Balcerzak adds. An example is the cryptography built into the Common Data Link (CDL) standard used for video transmission. CDL is not software based and, to date, it has been difficult to add a CDL requirement to F-22 and F-35 platforms or JTRS radios.
“In December 2009, a news story was published about militants in Iraq using $26 off-the-shelf software to intercept live video feeds from U.S. Predator drones,” Balcerzak says. “Availability of a software-defined secure video standard would have thwarted this occurrence.”
General Dynamics C4 Systems’ Advanced INFOSEC Machine (AIM) product family supports the F-22 and F-35 platforms and key components of the JTRS product family that are under development. AIM comprises a secure hardware foundation with embedded software-based cryptographic algorithms to protect classified information from use by unauthorized personnel. The AIM family of products supports software-defined radio methodologies to secure platform software and is field updatable.
“Our involvement,” Balcerzak describes, “consists of building integrated, low size, weight, and power, information assurance technologies, products, and systems for avionics, and for industry-leading modernized Identify Friend or Foe (IFF) systems.”
The company’s AIM II was certified by the National Security Agency (NSA) for protecting classified data in July 2010; its AIM Xcelerator, using NSA-approved single chip cryptography field-programmable gate arrays (FPGAs), completed NSA evaluation for the same purpose in May 2010.
The same lessons learned in the development of software-defined radios can be applied to the newly developing communication standards for small unmanned airborne systems (SUAS), especially those in the handheld weight class, Balcerzak says. “Through the use of cryptographic standards, tools, and product families, the size, weight, and power advantages of cryptographic solutions can get down to the ‘micro’ level.”
Shared airspace
Military aircraft that fly through civilian space must be certified to the standards that the FAA requires of civilian planes. “That’s relatively new,” Dewar says, “and it even applies to unmanned aerial vehicles (UAVs). The FAA doesn’t want UAVs buzzing around in civilian airspace unless they are certified, so there’s pressure to certify that software, as well. I think there’s some amazing rule that only a very small number, a handful, of UAVs can be over the U.S. at any one time, pending resolving that concern. They can still fly in restricted military space, but there’s less and less of that; more and more of the airspace is shared between military and civilian aircraft.”
DO-178B certification is required for airborne vehicles flying in commercial airspace, so this applies to UAVs, explains says Ben Brosgol, a member of AdaCore’s senior technical staff. “That's one of the reasons that DO-178B, which is historically a standard for commercial aircraft, is attracting the attention of the military community. AdaCore's GNAT Pro High-Integrity for DO-178B product addresses the avionics safety certification community, and applies to UAV software development.” AdaCore's customer EADS-CASA in Madrid, Spain, is currently working on an unmanned combat aircraft vehicle (UCAV) for the nEUROn program.
LDRA’s tool suite has also been used on a leading, short-range UAV, as well as the Airbus A400M, Eurofighter Typhoon, Extended Air defense Testbed, F-16 Fighting Falcon, F/A-22 Raptor, and F-35 Lightning II JSF, says Bill StClair, director of U.S. operations at LDRA Technology Inc. in San Bruno, Calif.
Lockheed Martin Aeronautics officials formally released the JSF++ air vehicle (AV) coding standard and selected LDRA is the tool of choice for the JSF project. LDRA worked closely with prime contractor Lockheed Martin during the critical system design and development phase of the project. Most recently, the technology partnership has seen LDRA assisting with the development of a C++ coding standard specifically for the JSF Air Vehicle Systems division.
LDRA developers enhanced the company’s tool suite to incorporate the necessary technical features required to implement the software test process of the Lockheed Martin AV coding standard. The enhanced version of the LDRA tools provides users with an automated process for checking the C++ standards required by the JSF project, helping to ensure that software is developed to a consistent style, is portable to other architectures, free from common errors, and easily understandable and maintainable by any team member.
Looking ahead
“Designing for safety-critical avionics requires highly rigorous, best practice design methodologies along with strict oversight to ensure compliance to specific regulatory policy mandated by the FAA and other certification agencies,” explains Michelle Lange, DO-254 program manager at Mentor Graphics in Wilsonville, Ore.
Electronic design automation (EDA) tools from industry firms such as Mentor Graphics play a similar role in building a complex, safety-critical design. “Tools are always used in these development processes, but some tools are more tuned for the compliance aspect of these processes than others,” Lange says. “For this to be the case, the tool vendor must understand the regulatory policy and what companies (their customers) are required to do to meet it. They can then leverage this understanding to tune and tweak the development tools to support development in the context of compliance. Having a tool that supports a pre-packaged set of best practice coding standards for safety-critical aviation design can help companies meet a requirement of regulatory compliance, which contributes to end-product safety while at the same time making the process more efficient.”
Company List
AdaCore; www.adacore.com
Aonix; www.aonix.com
Black Duck; www.blackducksoftware.com
Coverity; www.coverity.com
DDC-I; www.ddci.com
Future Airborne Capability (FACE) Consortium; www.opengroup.org/face
GE Intelligent Platforms; www.ge-ip.com
GE Aviation Systems; www.geaviationsystems.com
General Dynamics C4 Systems; www.gdc4s.com
GrammaTech; www.grammatech.com
Green Hills Software; www.ghs.com
HighRely; www.highrely.com
LynuxWorks; www.lynuxworks.com
The MathWorks; www.mathworks.com
Mentor Graphics; www.mentor.com
Software Engineering Institute; www.sei.cmu.edu
Wind River; www.windriver.com
