If real-time operating systems (RTOS) are the heart of safety-critical, air transport avionics, then ARINC 653 is at the heart’s core. RTOS conformance to the low-level capabilities described in the specification allows designers to host multiple applications of different criticality levels on the same hardware through the use of time and space partitioning. This capability is increasingly important to military developers, as well.
But now the industry wants more. Representatives to the Application Executive (APEX) Working Group of the Systems Architecture and Interface Committee are preparing a major revision to the specification, which will add to ARINC 653’s application programming interface (API). The goal is to provide a standardized approach to the use of optional, higher-level services such as file systems, networking and alternate schedules. Developers already employ these tools, but a common approach—achievable within real-time constraints—will make it easier to port software applications from one RTOS and computer platform to another. The revision also reflects the need to accommodate computers hosting multiple applications from multiple vendors, such as the common core system planned for the Boeing 7E7.
File System Support
The revision will comprise three parts:
-
Part 1—Required Services (Supplement 2, in development),
-
Part 2—Extended Services (optional services, proposed), and
-
Part 3—Conformity Test Plan (proposed).
Participants hope to complete the revision package by June 2005. The dividends from the project will be realized in avionics development programs and subsequent support activity over the life of the airplane.
Many avionics applications already use file systems as a way to organize permanent data for storage and retrieval from local or networked computers or to store data temporarily in “volatile,” power-dependent memory. A flight management system (FMS), for example, needs a file system to look up route information during flight. A terrain avoidance warning system (TAWS) needs a file system to access digital terrain elevation and obstacle data from aircraft databases. Other applications may need to store built-in test (BIT) fault data for later retrieval.
There also is debate about how complex the ARINC 653 file system services should be. Some participants, such as Honeywell, have advocated a full-bodied file system based on POSIX, the Unix-derived API standard used in the commercial world. Others, such as Airbus, prefer a simpler form of file system known as “logbook services.”
“Most applications need to get some sort of file data and need to communicate with somebody else,” says Jeff McGookey, chief engineer for the C-130 Avionics Modernization Program (AMP) with Smiths Aerospace. If compute platforms could do standardized networking and file systems, there would be less redevelopment work required to move applications from one RTOS to another.
Increased flexibility in scheduling applications on processors also would help maximize computing efficiency. Under ARINC 653’s current “hard” scheduling model only one schedule is available for allocating processor bandwidth to all of the software applications. An aircraft is certified with this “static” allocation model and continues to use it throughout its service life.
Multiple Schedules
Smiths Aerospace, however, is proposing the use of multiple scheduling modes—within appropriate safety constraints—because this approach enables ARINC 653 systems to schedule different functions at different times. Smiths’ concept would allow a maximum of 16 modes, says Jay Pruiett, a technical lead with the company’s Infrastructure Software Group. Data loading and autoland functions, for example, could be scheduled more efficiently under a more flexible model.
Smiths has developed an approach for multiple schedules with Wind River Systems, its RTOS partner on the Boeing C-130 AMP program and B767 tanker transport program. The relevant code is in Wind River’s new AE 653 RTOS, which is targeting certification to DO-178B, Level A. First use of the RTOS will be in a Level B application in the avionics and flight management computer on the Boeing tanker transport, followed by the Level B, C-130 AMP mission display processor.
In the Smiths implementation of multiple schedules, “we run the data loader as a partition, so it receives time and space allocation,” Pruiett says. In the “data loading” mode, the data loading function gets all the central processing unit bandwidth for maximum speed and efficiency. But after data loading is complete, built-in mechanisms allow the software to switch to the “normal operational flight mode,” with data loading deactivated. Smiths hopes to standardize the multiple scheduling modes approach in the revised specification. Future aircraft employing the approach would have to certify each mode and the transitions between modes, Pruiett says. Transitioning between modes is managed by low-level ARINC 653 board support software or by using the standard’s system partition concept.
Network support is an item thought to be particularly important to Boeing, as it moves toward the 7E7. There has been debate on how much networking content to bring over to ARINC 653 from other specs such as ARINC 664 (the avionics Ethernet standard), but it appears that the working group will at least try to standardize on some data types.
Another potential addition to the ARINC spec is support for interrupts, the signals from hardware devices that temporarily interrupt a program’s running. With typical, non-partitioned operating systems, interrupts are “global” in nature, potentially affecting all the tasks that may be running, says Bill Barnes, senior principal software engineer with BAE Systems Platform Solutions. But critical avionics systems need to service interrupts within real-time constraints. BAE Systems backs an approach to interrupt support using semaphores, standard operating system mechanisms used in the POSIX world. Since semaphores already exist in ARINC 653, the new approach would take the existing concept and expand its use.
Conformance Testing
Another item on the agenda is a guideline for testing RTOS conformity to ARINC 653, something that is timely, given the standard’s wide use. Airbus is pushing this idea, the ultimate goal of which is to provide a standard test suite and set of test code. (In the interest of time, however, the initial test spec may cover only the standard’s already defined, “essential services,” rather than the new services.)
Since ARINC is not in a position to function as a test lab, according to one participant, there is a plan to contact the Open Group, which assesses conformance to the POSIX standard. ARINC encourages developers of ARINC 653 operating systems to work together to reach consensus on methods for independent testing, says Paul Prisaznuk, secretary of the APEX working group.
Under the current standard an RTOS vendor who claims to be compliant may have only individual, internally developed test scenarios, which must be audited by the potential user, a time-consuming and expensive process. But if an RTOS supplier can show conformance with the API, that might take care of 80 percent of the compliance issues. Given a certain level of confidence in RTOS compliance up front, application developers can begin to write code earlier in a program.
Coming up with a single set of test code that all of the operating systems can run will be difficult because each RTOS developer implements services a little differently. However, the new standard, as a minimum, probably will provide some “test cases,” which will supply high-level descriptions of things to test for specific functions.
Linux Debate
At the opposite end of the spectrum from ARINC 653 RTOS is Linux—the open source code operating system. Linux is big, complex and susceptible to bugs. It evolves through collaborative development, and no one can point to the original documentation or claim a rigorously controlled, DO-178B-style software engineering process.
Nevertheless, Linux is attractive for networked applications because it boasts topnotch communications protocol support. Emerging programs such as the Joint Tactical Radio System (JTRS), Cluster 1, and the Future Combat System have been using Linux in some areas, and architectures are being developed to control it within the context of robust safety/security rules.
Radstone Technology, a developer of commercial off-the-shelf (COTS) computer cards, supplied a product with Linux support three years ago, which the military did not pick up, says Andy West, software marketing manager-processors. “But there are a number of projects to effectively advance the acceptability of Linux for flight-ready [applications].”
Linux is not DO-178B-certified for avionics applications and it would be difficult to do so. “I think you could [certify] it, but it probably wouldn’t be Linux any more,” says Bob Morris, vice president of sales and marketing for LynuxWorks, a company that provides both the DO-178B-certified LynxOS-178 RTOS and Linux.
But for non-flight critical applications, it may be possible to run Linux in a partition controlled by an aviation-approved RTOS. LynuxWorks is developing a BlueCat mode of Linux to run in a partition on LynxOS-178, says Morris. “We’re betting on the come that some program will want it.”
JTRS, Cluster 1, reportedly is using Linux in a portion of the program, which is developing software defined radios for future U.S. Army helicopters and other platforms. Key wideband networking waveform (WNW) software, written as a Linux application, is understood to run inside of a virtual memory partition of the full Green Hills Integrity RTOS. The WNW application, Linux kernel and a “Linux isolation layer” run on top of Integrity. (It is unlikely that JTRS would run Linux in an ARINC 653-style, time-scheduled partition, because Linux is not “architected” to support that.)
A spokesman for the program told Avionics Magazine that the JTRS Cluster 1 radio can use several operating systems, but he was unable to confirm which RTOS or configurations would be used in testing or production. Whether or not Linux ultimately is used, Green Hills’ “Linux on Integrity” subsystem indicates an approach to Linux in non-safety critical aviation applications.
Linux boasts a strong suite of TCP/IP networking protocols. That’s useful because radio waveforms like WNW go beyond just broadcast and receive: they have network characteristics and must tie into standard TCP/IP protocols. The JTRS program also has to be interested in the evolution of those protocols. With its strong developer community, Linux often incorporates such advances before anyone else.
Boeing, the Cluster 1 prime system integrator, could be viewed as getting the best of both worlds. It gets the advantages of Linux “but isolate[s] it in a memory partition, where it can’t have direct access to the entire system,” says a Green Hills manager. Linux can be used in its own application domain but without direct control over hardware or critical resources, so any potential problem can be localized “without compromising the entire radio.”
Green Hills also has provided the Linux isolation layer for Integrity, which includes the necessary security features, and has adapted a version of Linux for use in this environment, which Boeing would support. The partitioning approach adds processing overhead but is said to still meet JTRS’ real-time performance goals. In this approach, “anything that goes into or out of Linux goes through Integrity and a security manager,” says Dan O’Dowd, Green Hills’ chief executive officer. Linux has no direct access to the hardware or the outside world, and Integrity serves as its security layer.
Use of Linux in a circumscribed manner is also appropriate in a security context, Morris says. The National Security Agency has said you can use Linux in a secure partition, he says. “You can use it in the [evaluation assurance level, or EAL] ‘seven’ environment,” the highest RTOS security level.
Hawkeye Interest
Advanced Hawkeye (AHE) prime contractor, Northrop Grumman, also is eyeing Linux for possible use on the AHE’s mission computer. Fitted with a new radar, the airborne early warning (AEW) aircraft is slated to begin deployment to the U.S. Navy in 2011 (see story, page 22).
Northrop Grumman has rehosted the operational software of Hawkeye 2000—an interim Hawkeye upgrade—in Linux on a single-board computer, “because we want to look at the challenge of migrating to a purely commercial operating system,” says Tim Farrell, the company’s vice president of AEW programs. “It’s our intent to go to a commercial operating system on Advanced Hawkeye,” he says, “and I think Linux is probably the lead candidate now.”
Farrell acknowledges Linux’s “security challenges,” but says the market is starting to address them. “There also are architectures [with] multilevel-secure protection, vulnerability protection at the application level,” he says, alluding to efforts like the Multiple Independent Levels of Security, or MILS program (March 2004, page 24).
COMPANIES
ARINC Inc
Aonix
BAE Systems
Dy 4 Systems Inc
Ensco Inc
Green Hills Software
LynuxWorks
MontaVista Software
Objective Interface Systems
OSE Systems Inc
QNX Software Systems
Radstone Technology
SBS Technologies
Thales Computers
TimeSys
Wind River Systems