As the complexity, requirements, and criticality of avionics software grow, innovative tools are increasingly necessary to test, verify, and secure military and aerospace systems.
By Courtney E. Howard
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 of being hacked, so current and future avionics software offer safety and security through 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."
|DDC-I's Deos safety-critical RTOS is used to host DO-178B-certifiable avionics flight deck software in a variety of cockpit applications.|
"Safety-critical software has to be bug free, and it has to work according to specifications," Dewar says. 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 mathematical proof that the things work. People are moving more in the direction of mathematical proof and formal methods."
Static analysis software tools analyze source code to derive properties that can help detect errors that might not be apparent to the programmer, while dynamic analysis tools help show what code is executed by a test suite. "All have their place in safety-critical development," Dewar says.
Engineers from 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," he admits. "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 staff, providing 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 iFACTS system and support and maintain its Traffic Load Prediction Device (TLPD). iFACTS replaces traditional paper information strips with electronic data and new displays, and 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 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."
|Swedish Space Corp. (SSC) developed the attitude and orbit control system of the Small Missions for Advanced Research and Technology (SMART-1) European Space Agency satellite using automatically generated flight code and The MathWorks tools for model-based design. (Photo courtesy of SSC.)|
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: requirements capture and validation, 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 identi- fied to verify that 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 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 says. 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. "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.
"Engineers use these models to clarify requirements and specifications, evaluate design and configuration choices, and facilitate simulations to verify that a design satisfies the requirements," Friedman adds. "In one study, engineers uncovered more than three times as many issues with requirements by using model-based design than by using traditional methods." By using model-based design to develop flight controls, aerospace companies have reported 40 to 60 percent reductions in development time, given the ability to address requirements and design errors early in the life of a program.
Prime contractor Swedish Space Corp. (SSC) in Solna, Sweden, devel- oped the attitude and orbit control system (AOCS) of the Small Missions for Advanced Research and Technology (SMART-1) satellite using automatically generated flight code. "The MathWorks tools for model-based design helped us design and automatically generate code for the flight application software for attitude control, power control, thermal control, and FDIR," says 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.
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. Open and closed-loop tests were done at the European Space Research and Technology Centre 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. For avionics software, there is a higher-level requirement on the correctness of its behavior. To ensure that avionics software behaves as expected requires that validation and testing is targeted at each of the design and development stages."
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 repre- sentatives help the FAA to 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," Chou says.
"DO-178 certification, a must-have for safety-critical avionics, demands rigorous testing and verification," says Bill StClair, director of U.S. operations at LDRA Technology Inc. in San Bruno, Calif. "Tools used in the verification process must be deterministic and provide a set of metrics that can be consistently applied across both host and embedded target systems."
The primary form of DO-178 verification, StClair adds, is provided by dynamic analysis tools which operate on the host and the embedded target, and also measure code coverage. DO-178 Level C requires Statement coverage, Level B requires Decision coverage, and Level A requires MC/DC coverage, at both the source code and the object code levels.
"DO-178 also demands requirements traceability," StClair says. "Establishing and maintaining manual traceability is costly, time consuming, and error prone. A requirements traceability tool is essential, especially if one considers the bidirectional traceability mandated by DO-178C."
The LDRA tool suite integrates coding standards compliance, requirements traceability, and complete code coverage across the development lifecycle. TBreq, using patent-pending requirements-to-code mapping technology, links requirements to software design, code, and test cases using a requirements traceability matrix. LDRA's graphical reports pinpoint compliance problems, verify code coverage, and detail DO-178 documentation. Lastly, StClair explains, "LDRA's DO-178B Tool Qualification Support Pack eases the certification process and has been used on projects, such as the Boeing 787 and Superjet 100."
Providers of aviation electronics solutions use Coverity's tools to help enforce software integrity across their product lines, and to provide assurance of the quality, safety, and security of code provided to the software supply chain, including large aircraft manufacturers, Chou says.
These companies "realize the importance of DO-178B conformance and its value, which validates that compliant processes are followed in developing the software," Chou explains. "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."
|The Honeywell Primus Apex integrated digital avionics suite with flight-ready software onboard is shown on a Viking Twin Otter Series 400 technical demonstrator.|
Safety critical is security critical
Any safety-critical software today is also security-critical, Dewar says. "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," 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."
From a security perspective, a back-door communication mecha- nism to 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 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." LynuxWorks tools have been used in airborne, flight-critical, and ground-based systems requiring safety and security functionality.
The Airbus A400M military transport aircraft required the highest DO-178 design assurance level. "HighRely engineers deployed best-in-class avionics engineering services and tools to help develop and optimize A400M engine control software certified to the most critical Level A compliance," says Vance Hilderman, president and co-founder of HighRely Inc. in Phoenix. "The A400M met all of its first flight objectives and is now well on its way to achieving certification via the ongoing flight-test regimen."
The fastest-growing business seg- ment for HighRely is military avionics, adhering to commercial DO-178 and DO-254 standards. HighRely's avionics development checklists via RelyCheck, software development, RelyTrace for traceability, and DO-178B/DO-254 verification and qualification have been used in military fighter and cargo planes, such as the C-17, F-35, and unmanned aircraft.
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 robust scheduler from the selected development tool set is also an important architecture consideration, he explains. "It needs to manage resources to the developer's requirements and is key to success. Most existing RTOS implementations utilize a central kernel memory pool for satisfying application requests. This can allow a malicious or poorly written task to consume all resources and 'denial of service' can result."
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 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 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 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.
"The company offered a 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. "We were able to capitalize on its product's strengths and deliver a solution that will exceed our customers' expectations with respect to performance and safety."
Lockheed Martin's F-35 Lightning II Joint Strike Fighter 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 onboard 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, with its hard real-time response and guaranteed resource availability, made it a perfect fit for this safety-critical application."
|Pilots are increasingly reliant upon safety-critical avionics software, as demonstrated by this image of the Kings Avionics SVT Terrain Alert Traffic Chart PFD and MFD G600.|
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 application software for the Vertical Situation Display [for the U.S. Air Force's B1-B bomber] was written by Boeing on top of the GE Intelligent Platforms certifiable COTS platform," explains Simon Collins, product manager at GE Intelligent Platforms in Northampton, England. "The benefits of a certifiable COTS solution were: to allow Boeing to begin development of its application on the platform sooner than if a custom solution had been implemented, thus reducing the development time; a reduced overall risk of integrating hardware and software components; and a single point of responsibility for achieving certification of the video/graphics platform.
The Boeing B1-B employs 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 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 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, 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 spokesperson. "Deos provides a path to DO-178B Level A certification, the highest level of safety criticality."
Software-defined radios (SDRs) fielded for platforms, such as the U.S. Air Force's F-22 and F-35, and for the Joint Tactical Radio System (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, he says.
"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) 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. AIM products support software-defined radio methodologies to secure platform software and can be field updated.
"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.
Balcerzak sees a growing trend from the armed services and NSA to use cryptographic solutions that are common across platforms, which reduces the development, embedment, and maintenance costs to bring advanced features and interoperability to the soldier. "As the services unify their communication, networking, and key management standards, there will be additional motivation to employ common cryptographic solutions. From a technology standpoint, all the building blocks for cryptographic commonality are in place if the military chooses to pursue them."
The same lessons learned in the development of software-defined radios can be applied to the 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."
|Aircraft Spruce & Specialty's Odyssey flight, engine, and navigation instrument is a hardware and software concept that promotes a flexible platform with a user-modifiable software application system.|
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. 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."
UAVs are increasingly being used in commercial airspace, such as for homeland-security operations, admits Hilderman. "Situations regarding UAV operations have showcased the need for greater UAV certification scrutiny and coordination with the FAA. UAV manufacturers throughout the world are increasingly complying with DO-178B and placing greater emphasis upon safety while operating in commercial airspace."
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 LDRA's StClair.
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, portable to other architectures, free from common errors, and easily understandable and maintainable by any team member, reveals a representative.
"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.
"Tools are a vital part of any software/hardware design process," Lange says. "Today's designs are far too complex to develop without the aid of tools. You wouldn't dream of building a complex skyscraper without some sophisticated tools tuned for such an undertaking to make the process efficient and the end product safe for its intended function."
Electronic design automation tools from firms such as Mentor Graphics play a similar role in building a complex, safety-critical design.
"Tools are used in these development processes, but some tools are more tuned for the compliance aspect 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 prepackaged 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 making the process more efficient."
It is important to be "very clear about some of the policy/regulation governing this industry, as there are a lot of recent/upcoming changes to be aware of," explains Michelle Lange, DO-254 program manager at Mentor Graphics in Wilsonville, Ore. Lange offers the following summary.
DO-254: Governs PLD/FPGA/ASIC design ("custom micro-coded components"). Published in 2000, it became regulatory policy in 2005, with some additional FAA guidance published in 2008. It is still relatively new and evolving.
DO-178B/C: DO-178 has been around since the 1970s. Revision C has just been finalized.
DO-297: Governs integrated modular avionics (IMA). IMA is described as a shared set of flexible, reusable, and interoperable hardware and software resources that, when integrated, form a platform that provides services, designed and verified to a defined set of requirements, to host applications performing aircraft functions. DO-297 has not been invoked as policy, so it is considered "optional" at this time.
DO-160: Governs environmental conditions and aircraft testing.
ARP 4754A: Governs aircraft systems development. While the original version has been around since 1996, it was never officially invoked as policy. The "A" revision has just published, and it is expected to become regulatory policy in 2011.
ARP 4761A: Governs safety assessments of aircraft systems. Similar to ARP 4754A, the "A" version is still in its final stages of revision and will likely be completed in 2011.