A little heralded document issued by FAA in December 2004 describes how software developers and avionics manufacturers can obtain limited approval of software components that can be reused in many other aircraft computers. It also describes how they can leverage the initial approval to streamline requalification on subsequent projects. If the new approach catches on in the industry, it could reduce some of the enormous expense required to field avionics systems and allow avionics companies and FAA to use resources more efficiently.
But the optional guidance has no track record and many skeptics. And it is unclear how practical it will be to extract software that already has been accepted as part of a technical standard order (TSO) on a certain set of hardware and establish that software as reusable under the new system. The jury is out, as people weigh the cost of adopting the new method against the as yet uncertain benefits of doing so.
‘A First in Avionics’
FAA’s advisory circular (AC 20-148), published on Dec. 7, 2004, provides a national, standard approach to software reuse, a "first in avionics," according to John Lewis, a computer engineer with FAA’s Aircraft Engineering Division. "It’s a big step forward in how we do business," he says. The AC, on page 1, lists real-time operating systems (RTOS), software libraries and communications protocols as potential "reusable software components," or RSCs.
"To me it’s kind of a win/win for both [government and industry]," says David Hempe, manager of the Aircraft Engineering Division within FAA’s Aircraft Certification Service. "This gives us the ability to apply discretionary risk management approaches to how we work with applicants in the software area. We have precious few resources these days."
So far, operating systems are at the forefront of the standardization effort. FAA doesn’t want to prohibit companies from using third-party software like operating systems but wants users to be confident that such software will operate correctly, says Mike DeWalt, chief scientist with Certification Services Inc. (CSI), the first company to receive an RSC letter of acceptance. Formerly DeWalt was FAA’s national resource specialist for software.
Avionics manufacturers have reused software for years. But the traditional approach has been informal and variable. Integrators have managed projects on a case-by-case basis with individual FAA aircraft certification offices (ACOs).
The problem for an operating system is that "there’s no way to get a TSO for it," explains Marty Gasiorowski, Honeywell’s certification manager for Primus Epic. TSOs are tied to avionics functions and associated with avionics hardware.
The RSC advisory circular aims to enable avionics manufacturers to reuse software components from different vendors with less requalification work than before. Adhering to the AC, an RSC developer will be able to reuse the same software data–including requirements, source code and object code–in another project if the data (including the code) hasn’t changed. An integrator will be able to take "credit" for the original applicant’s work without necessarily having to see it, an approach that encourages reuse. Such work includes records that:
Indicate the component’s development processes,
Indicate full or partial satisfaction of DO-178B objectives,
Demonstrate how requirements were tested, and
Prove that every line of code was exercised appropriately.
DO-178B is the standard by which FAA approves aircraft software.
The business case for reuse, from a software developer’s point of view, can depend on the ability to isolate a portion of the code as much as possible from hardware change. Otherwise the hardware in question might not be manufactured long enough to justify the expense of obtaining the RSC. Aviation RTOS suppliers generally have done a good job of isolating hardware-independent portions of the software–such as the kernel–from hardware-dependent portions, says Frank McCormick, president of CSI.
The RSC approach can make it easier for subsequent users to gain FAA approval, McCormick says. "Without the RSC approach, the second guy has to secure access to all the original data in some manner that is acceptable to the original developer." Since that data typically is proprietary, "it often has been problematic to figure out how to share the data in subsequent efforts without jeopardizing the proprietary protections of the original applicant."
But with the RSC approach, some data need not be shared, he explains. The original developer shows the second user only the following:
An acceptance letter for the software component,
A list of the DO-178B objectives that have been fully satisfied, and
An explanation of what work is still to be done on the remaining objectives.
As FAA’s Lewis puts it, "The RSC acceptance letter can be used from ACO to ACO without further FAA review of the data."
The second user might be required, for example, to rerun test cases on the new hardware, proving that the new implementation produces the expected results, McCormick says. The issue is defining what has changed and what has not changed. "Executable code might change without disrupting the requirements and design data that led to the code. So a nontrivial body of upstream data might well remain stable." A test case could be as finite as a software routine to calculate a trigonometry function for a navigation system, DeWalt explains. The source code would be compiled into executable code and run on the new hardware to verify that it produces the expected results.
There are pros and cons to the reusable software concept, Gasiorowski says. If you can get the RSC approval, potentially "you can skip getting some audits, approvals of data, tests and so forth" that you’ve already gone through. It gets rid of the current system’s built-in duplications of effort. But the first applicant inevitably will have to do more work. And that company will ask itself why it should incur additional expense, especially if the work may end up helping a competitor.
Projects Afoot
The ideal candidate for an RSC is a software module developed from scratch or a major revision to an existing package. Rockwell Collins, Honeywell and Avidyne incorporated such a module in prototype radios as part of FAA’s Next Generation Communications (NEXCOM) program. Collins then carried forward the module–a vocoder algorithm developed by DVSI Inc.–as an RSC in the avionics manufacturer’s VHF digital link, Mode 3 (VDL-3), implementation. Collins’ VHF-2100 transceiver containing the RSC was certified on a Delta Air Lines Boeing 737-800 last October. (The vocoder is used to digitize and compress analog voice data in order to improve sound quality.)
The DVSI module was accepted as a Level C reusable software component, according to Nancy Guzak, Collins’ VHF program manager. CSI, which assisted in the process, received the acceptance letter in January, and DVSI controls its distribution. This particular RSC is hardware-specific, however. If an integrator moves the RSC software to different hardware, some requalification will be involved.
If FAA deploys NEXCOM in its current form–and that’s a big if–all VDL-3 radio designers will be required to use the same vocoder algorithm. They can–under a business arrangement with DVSI–use the software and include the RSC approval in their TSO submittal to streamline their certification efforts. Validation testing also is required to confirm the RSC is performing correctly in the specific hardware application.
With NEXCOM funding, Collins also will include the vocoder module in its VHF radio for business and regional aviation.
Larger Components
Getting a Level C RSC on a single-purpose piece of code is one thing, but getting a Level A RSC on an operating system–a large and complex piece of software–is another. LynuxWorks has set itself this task for the latest version of its LynxOS-178 RTOS. Although the guidance does not require it, LynuxWorks also wants to prove that its RTOS kernel will function correctly, independent of any underlying hardware.
LynuxWorks has partnered with Rockwell Collins on the RSC project, which involves the Bombardier Challenger 300 adaptive flight display system. That system originally was certified using the virtual machine operating system (VMOS), which Collins developed from an earlier LynuxWorks product. Collins modified that product to meet ARINC 653 requirements for time and resource partitioning and health monitoring. A few years ago the integrator licensed back to LynuxWorks the changes and additions to the software. LynuxWorks offers the combined product–identical to VMOS–as LynxOS-178. Now the process has gone full circle: Collins is seeking a TSO of the Challenger 300 application using the commercialized product, LynxOS-178. And LynuxWorks is applying for an RSC approval under the TSO, covering the RTOS kernel and POSIX application programming interface (API) library.
Before the advisory circular, "The only certification [the RTOS supplier] could get was in conjunction with the hardware," says Bob Morris, LynuxWorks’ vice president of marketing and sales. Collins stands to gain from the RSC because it plans to use the operating system in projects such as the flight management system (FMS) for the ARJ21 Chinese regional jet. LynuxWorks is undertaking the task because it will make LynxOS-178 more attractive to other customers, who will be able to reference the RSC in DO-178B, Level A, B or C approvals.
Collins has permitted LynuxWorks to use the VMOS artifacts–the documentation associated with the RTOS’ approval for use in the Challenger display system. But that’s just the beginning, explains Nick Bloom, Rockwell Collins’ principal engineering manager for architectures. To carry on with the commercialized RTOS in the safety-critical market, LynuxWorks needs to be able to prove it has the processes in place to develop new RTOS features and "RSC" them on its own.
Joint Effort
Using the Collins artifacts as a guide, LynuxWorks needs to establish the software development processes and configuration management processes, for example, to enable it to develop and RSC Level A, flight critical software. It has to show it can develop independent test cases, Bloom adds. The real challenge for a complex component such as an operating system, DeWalt says, has nothing to do with DO-178B issues. "It has to do with how you go about extracting a component from the bowels of a project and put infrastructure around the component to make sure it is reusable in the widest sense."
LynuxWorks has created comparable processes and has submitted its complete data package to its own and Collins’ designated engineering representatives (DERs), Morris says. The DERs are comparing LynuxWorks’ data with Collins’ data. Among other things, "They validate that LynuxWorks has recreated a Level A development process," Bloom explains. Part of the technology transfer included methodologies that Collins uses to meet DO-178B objectives–how the company does peer reviews on particular software requirements and the use of certain tools, for example. Various levels of DO-178B may require independent reviews of certain things, he says.
Scrutiny of code at this level takes time. A single person can get through about 20 lines of code a day, Morris says. Analyzing an RTOS kernel, which may include 100,000 to 200,000 lines of code, obviously requires considerable investment. However, the benefit will be considerable, as well, if the RTOS attracts sufficient interest in the market. LynuxWorks plans to sell customers the use of the RSC "at a steep discount, compared to what they would pay otherwise," he says. LynuxWorks hopes to conclude the process by August 2005.
The Competition
LynuxWorks’ competitor, Wind River Systems, praises the concept, but mentions no immediate plans to file for an RSC approval. "All the certification evidence we have ever created around DO-178B has been predicated around the advisory circular’s reusable software model," asserts John Fanelli, vice president of product management and planning. Smiths Aerospace uses Wind River’s RTOS, VxWorks 653, in the Boeing 787’s common core system and in the avionics flight management computer of the B767 tanker transport.
Wind River says military customers will be able to move applications between its internal "platforms," the integrated software bundles containing an operating system kernel, a common development environment and other software. Galileo Avionica, an Italian avionics firm, could take advantage of this feature. It chose Wind River’s "general purpose platform" as the basis for developing a map generation function for the NH90 naval helicopter. If Galileo Avionica wins the production contract, it could port the NH90 application from Wind River’s general-purpose platform to its "platform for safety critical," which is moving to a common development environment.
Green Hills Software has considered the RSC guidance, as well, and is looking for places to apply it, says Patrick Huyck, the company’s systems certification manager for safety critical products. "The big thing you’re trying to do is to reduce the time spent in accrediting [code] from one project to another," he says. "You need people to support the audit and follow-up questions." Using the traditional DO-178B approach, however, the company already has delivered certification packages for the Integrity RTOS, or variations of it, 15 times, he says. Green Hills has developed software to be employed as an RSC "since day one."
Integrator Viewpoint
Since RSC developers have to partner with an applicant for a TSO, supplemental type certificate or type certificate, integrators–and airframers–will play a large role in how the RSC acceptance turns out.
"The RSC development is a very important process change," says Collins’ Bloom. "Having portions [of software] declared reusable, and not having to basically rework them on a continuous basis, should improve cycle time overall," he says. Collins could purchase that RSC approval from the RSC developer and "integrate it into our product without having to go through the recertification of that component," notes Steve Brandt, Collins’ senior director of aircraft systems and architectures.
Getting a component RSC’d won’t be a trivial undertaking, Brandt says. But the current process of getting approval to reuse software–if it involves going from one ACO to another–can take more than 50 percent of the effort involved in the first certification, Bloom says. Although Collins is able to reuse some of the documentation, there is an education process with each new ACO. "In many cases that means answering questions and additional DER reviews."
BAE Systems Platform Solutions comes to the RSC debate as a developer of flight control systems for military and commercial aircraft. It’s taking a wait-and-see attitude toward the RSC idea because it’s so new.
The company evaluated the RSC concept in connection with its work on the S-92 fly-by-wire flight controls, recalls Leo Moran, BAE’s director of software engineering. BAE looked at potentially reusable components such as its CsLEOS operating system, the board support package and built-in test software. The review indicated that migrating the components to the new process would cost more than the traditional approach for that particular application.
BAE Systems Platform Solutions doesn’t want to be the first or the second one down the RSC path. It’s hard to tell whether FAA is going to treat the advisory circular "as advertised," or whether the first reuse of an RSC will be as difficult as the original approval, Moran observes. "But if I had four or five applications that would be very similar," he qualifies, "I wouldn’t mind being first because there’s a true potential benefit."
Any time a new approach is involved, there also will be "gray areas" to work out, Moran says. Because it will take additional time to get an RSC approval, and compliance with guidance involving DO-178B is very subjective, it’s not clear yet what the long-term benefit is. "At this point, we’re not really convinced it’s going to save us time."
Using Different ‘Chunks’
Smiths is watching the advisory circular, too, with an eye to larger functions such as flight management system software. The company sees the potential for reusing parts of applications developed to run in an ARINC 653 environment, where functions are "partitioned," so that multiple applications can coexist on the same hardware.
Applications will be difficult to RSC because they typically change from box to box. But if they are segmented, reuse would be easier. If FMS code–up to a million lines long–can be divided into customized and generic chunks, there could be a case for shifting to the new process.
Perhaps the static portions could be "rearchitected" as different applications, speculates Gerry Vossler, Smiths’ director of technology development. "You can RSC for the [flight path] predictive or computational portion because it’s not going to change."
Smiths is developing the FMS software for the C-130 avionics modernization program (AMP)–using an ARINC 653 environment. But the company is not pursuing an RSC on any part of the FMS software at this time, even though its design processes are "fairly similar" to those outlined in the advisory circular.
Integrators, moreover, can’t do RSCs in a vacuum, he adds. If it’s a Boeing aircraft, Boeing "has to adopt the philosophy that they’re going to ask suppliers to build reuse and the cost of change into their designs, so Boeing can take advantage of it." Otherwise, in a competitive bidding environment, the integrator with the longer-range but more costly approach is at a disadvantage.
Honeywell does not appear to be pursuing RSCs at this time, either, in its business, regional and general aviation area. When the company wanted to reuse core Primus Epic software components from airplane to airplane, it used the preexisting TSO process, which meets the intent of the advisory circular, Gasiorowski says.
"We did a TSO on the entire [Primus Epic] system," he recalls. "We delivered the whole field loadable software package on one CD that has a part number. We have a TSO on that part number."
Reusable IMA?
Integrated modular avionics (IMA) systems are natural hosts for reusable software. IMA, after all, is "a shared set of flexible, reusable and interoperable hardware and software resources," Hempe says.
FAA’s RSC guidance could be used to streamline the processes required to reuse integrated modular avionics software across multiple aircraft platforms, says Collins’ Brandt. He cites RTCA’s Special Committee 200 (SC-200), which is looking at how to simplify the certification of the same system in two aircraft.
FAA’s Hempe elaborates. "With reusable software components and a common IMA platform/architecture, IMA developers will not have to completely start over in developing IMA software for the next customer."
IMA is a system-wide concept, Brandt says, "and many of the pieces of that system could be put together as reusable software." A good example is a "foundational database" that provides a common access point for navigational information among IMA components. SC-200’s document will refer to both the RSC guidance and RTCA’s DO-178B standard for the development of flight critical software.
If you combine the RSC, the work in RTCA Special Committee 200, and the work to update ARINC 653, you have the foundation for drawing some costs out of fielding avionics, comments Vossler.
The SC-200 document, expected to appear as an RTCA standard this summer, focuses on the hardware as well as the software, says committee chairman, Cary Spitzer. On the software side it envisions situations that would be uncommon today–for example, a Thales application reused on a Honeywell IMA system. Companies could modify applications and test only the parts that have changed. Qualified developers could generate software to put on an airplane without having to build the underlying hardware. The RSC guidance could become a key milestone along the route to the larger IMA objectives.
New Ball Game
Developing new software to FAA’s reusable software component (RSC) guidelines promises to be a lot easier than adapting existing software to the process. FAA "does not intend to retroactively grant RSC letters for previously accepted software components based solely on compliance with DO-178B," says David Hempe, manager of the Aircraft Engineering Division within FAA’s Aircraft Certification Service.
Why so difficult? Partly because existing software–accepted as part of a prior technical standard order (TSO), for example–may be freighted with assumptions related to that application, which may limit the component’s reusability in a larger context. Take a graphics software library used to convert pitch and roll data into a ball and line on a primary flight display. Say, it was designed for airplanes that would never exceed 90 degrees of bank. If the developer later decides to include the component as part of a system for aircraft that will exceed 90 degrees of bank, he would, among other things, have to describe such limitations.
If the component is to be hosted on new hardware, moreover, portions of tests and analyses relating to the original hardware would no longer apply. The component developer also has to show how he is going to meet all of the requirements described in the RSC advisory circular.