Military embedded-system designers are turning toward POSIX for their real-time operating systems needs. Meanwhile RTOS vendors continue to meet the many security standards required for mission-critical applications.
By Ben Ames
Looking to save money and reuse software, Pentagon planners are turning to POSIX. The U.S. Navy’s Open Architecture Computing Environment is driving the move to interoperable systems. If all real-time operating systems (RTOSs) work with POSIX, then soldiers can swap code from a broken computer to a new one.
However, some contractors are dragging their heels-driven by a fear of losing maintenance and consulting contracts if other companies can access their systems.
At the same time, security is in high demand, with specifications calling for certification to standards like DO-178B, ARINC 653, and EAL Level 6.
The challenge for RTOS vendors is to keep their platforms safe and open. They are meeting the challenge with new kinds of software partitions and with systems that run several operating systems at once.
Next-generation platforms use POSIX
Designers of the U.S. Army’s Joint Tactical Radio System (JTRS) want to go to multiple vendors for the waveforms they will use in different radios. That means they will only buy POSIX-certified systems, so different applications can run on a single software-defined radio.
POSIX is in demand in other military applications as well.
“We see it quite broadly now, among all programs that want to use multiple suppliers,” says Barnett. In turn, the major RTOS suppliers have earned POSIX certification for their platforms. Green Hills won it for Integrity in July 2004.
The movement began in August 2004, when Navy leaders established an Open Architecture Enterprise Team, led by the [Program Executive Officer] for Integrated Warfare Systems, Rear Admiral Charles T. Bush. The move followed a Pentagon directive that “a modular, open-systems approach shall be employed where feasible.”
That team now measures compliance with the Navy Open Architecture Computing Environment (OACE) to ensure that open-standards operating systems on new platforms can support system interoperability and software reuse.
“One year ago, the Navy founded the open architecture computing environment to support spiral technology insertion. Now it has teeth; they can force folks to agree with POSIX,” says Bob Morris, vice president of sales and marketing for LynuxWorks in San Jose, Calif.
One of the most common POSIX-type operating systems is Linux, the basis for LynuxWorks’ LynxOS. That operating system is compliant with Navy OACE, though Linux is not a good fit for some high-performance, real-time military applications, Morris says.
Still, LynxOS runs the shipboard self-defense system (SSDS), DD(X) destroyer prototype, and Army Future Combat System, he says. SSDS engineers picked LynxOS because they needed a POSIX environment so they could also use Solaris and other UNIX platforms.
Unmanned aerial vehicles (UAVs) are one of the most promising markets for new operating systems, Morris says. After successful use in Iraq and Afghanistan, they now need long-term design plans, instead of low-rate production by the Defense Advanced Research Projects Agency (DARPA). Those UAV builders want to build links to the Global Information Grid (GIG), a POSIX-oriented network.
Likewise, POSIX operating systems are in demand for MCAP III, the Manned/Unmanned Common Architecture Program Phase III. Planners at the Army’s Aviation Applied Technology Directorate want to use open-architecture avionics to provide interoperability and commonality between the mission processing systems for Army helicopters, Future Combat System (FCS) ground vehicles, and UAVs.
Accordingly, engineers at Rockwell Collins chose the LynxOS-178 RTOS to build a common computing and open-systems network architecture for the Army AH-64 Apache helicopter, Unmanned Combat Armed Rotorcraft (UCAR), Shadow 200, A-160 Hummingbird, and Fire Scout.
LynxOS-178 is a commercially available, DO-178B Level A certifiable RTOS that meets standards for safety-critical avionics systems, and also enables multiple software applications of different criticality levels to run within partitions on the same hardware resource. And as a POSIX-conformant operating system, it also assures application portability, software reuse, and interoperability between embedded military systems.
“The military is budget-constrained right now,” says Morris. “They are facing deferred maintenance for ongoing operations in Iraq and Afghanistan. So they will take some technology planned for the future and put it in the current force. That means an increased focus on applications in the network-centric battlespace, such as FBCB2 and the GIG (global information grid).”
By the same token, engineers will soon merge the POSIX-oriented integrated data modem (IDM) with other platforms like MCAP and FBCB2 (Force 21 Battle Command, Brigade-and-Below).
Securing the RTOS
A big challenge for RTOS designers is to balance the demands for security and portable code.
“People are starting to realize they don’t get security with general-purpose operating systems. So we’re going after EAL Level 6-Plus,” says David Barnett, director of product marketing for Green Hills Software, in Santa Barbara, Calif.
That is why Green Hills released Integrity PC in November 2004. Its “padded cell” design creates a secure, virtual computer on top of the standard Integrity operating system. That allows engineers to build high-security applications that incorporate nonsecure legacy software and open operating systems like Linux. They can even use multiple cells to run concurrent guest operating systems. All the while, the high-assurance environment guarantees processor-time and memory protection.
“They still want to be able to run legacy programs, despite using a high assurance API [application programming interface]. So Integrity PC merges both-it lets legacy programs run in ‘padded cells.’ Then over time, users can port those applications over to high-assurance kernels,” Barnett says.
Engineers at Boeing are already using Integrity PC for their software defined radio product, he says. That will enable scattered fire and police departments to communicate over a collection of software applications running on a single hardware platform.
Another application involves combining secure government networks. Today, the Pentagon mandates that secret communications never travel over an unclassified network such as the Internet. But this high-assurance application could do both on a single machine, running Niprnet and Siprnet side by side, Barnett says.
That is one reason Green Hills is trying to earn Common Criteria EAL Level 6 certification for Integrity. The company expects it will earn that title within 18 months, pending approval from the National Information Assurance Partnership (NIAP) and certification by the U.S. National Security Agency.
Features burden RTOSs
“The problem with real-time operating systems over the last 30 years is the need to add more features,” says Victor Yodaiken, president of FSM Labs in Socorro, N.M.
“An RTOS used to be incredibly simple but as you add features, it gets expensive to maintain, and non-real-time processes start to interfere with real time.”
That happened to the Mars Exploration Rover, and nearly scuttled the mission. One rover’s non-real-time memory system used up all available memory, so its real-time system couldn’t run. Fortunately, NASA engineers were able to clear the memory remotely, and the mission went forward.
Yodaiken has a solution. His company makes computers that run two operating systems-one takes care of real-time tasks with RTCore, while another takes care of features and non-real-time work with standard Linux or Open BSD.
“You can’t allow non-real-time to interfere with real-time response, so we decouple them,” he says. “The Linux scheduler doesn’t know anything about the real-time threads; it operates in blissful ignorance.”
Since the non-real-time system uses Linux or Open BSD, it agrees with Pentagon requirements for open-source software.
RTCore uses POSIX threads. And RTLinux is merely RTCore plus Linux, so it offers POSIX compliance to the full PSE54 level. Together, they include a lean POSIX version stripped down to run at real-time machine speeds, as well as full POSIX for non-real-time tasks.
Running two systems instead of one can slow the design down, but customers are willing to trade a small performance penalty in exchange for using all their features, Yodaiken says.
“All the features work but you still get precise real time. We modify Linux to make it preemptable; whenever anything happens, the real-time system gets it first, then hands it off to the other system.”
One customer, Pratt and Whitney, recently used the system in their simulator for the F-35 Joint Strike Fighter jet engine afterburner. They ran RTLinux on dual PowerPCs. In another job, Harris used the system in prototypes of their software defined radio, running RTLinux on quad Curtiss-Wright Synergy VME boards.
Designers often pick the FSM system for simulators and test equipment because it runs real-time threads in protected space, inside a UNIX process. That lets them do sophisticated data sharing and networking without much work.
“Those jobs are easy to do compared to a traditional RTOS, because you’re using the standard UNIX system; not a version, but the same one used by SQL, DB2, Oracle,” Yodaiken says. The next step for FSM Labs is to win DO-178B certification, expected within two years.
Cutting cost with COTS
Companies are more worried than ever about cost and schedule. At the same time, many lost expertise when they had to lay off software engineers in the dot-com collapse.
“So they’re moving from custom hardware and [application-specific integrated circuits] to COTS [commercial-off-the-shelf] hardware and operating systems. People are recognizing that it costs more than predicted to roll your own, and to keep adding features as the application grows,” says Gerald A. Wilson, chief executive officer of OmniSoft, Cupertino, Calif.
“These customers change very slowly, they don’t introduce brand new technologies, and trends build very gradually. So it will be a while until we see which operating system they will chose.”
A company choosing a commercial real-time operating system faces a quandary of choices, Wilson says. Do you want hard real-time? How do you evaluate whether you need that? Do you need the source code? What debugging tools and compilers do you need? Can you afford a large footprint? Do you need all the bells and whistles of VxWorks? Or would you prefer to use small micro-kernels like Green Hills is pushing?
“Most military and aerospace companies think like hardware companies; they have only been using a significant software component in last 10 to 15 years,” he says.
“The GOES weather satellite costs $250 million to produce with less than 10 percent for software cost. So management looks first at the expensive hardware; but that is the tail wagging the dog, because a software problem could make entire satellite into space junk.”
At the same time, military contractors are feeling pressure from Pentagon leaders to accomplish missions with fewer people, Wilson says.
One way to do that is with standardized software interfaces, letting maintenance workers move from one missile to another in the Navy, or from one plane to another in the Air Force. Leaders could avoid major retraining, because workers would recognize the same interface.
Standardized software could ensure that a radar operator sees the same interface in a submarine as on an airplane. That same operator could even learn to use both sonar and radar, since the algorithms are similar, and most ships use both systems to see below and above the surface.
Cutting cost with Linux
“We’re seeing migration toward Linux environments, by people who are committed to the real-time performance from a commercial RTOS like Wind River, but grumble about the onerous licensing and development costs,” says Rodger Hosking, vice president of Pentek, Upper Saddle River, N.J.
In comparison, Linux has free open-source distribution and real-time extensions sold by commercial companies. So users can respond to an interrupt with a guaranteed latency.
Pentek offers another open-source option-eCos is a license-free RTOS managed by virtual community of users and developers, he says.
“We started using it five or six years ago as real-time control for board management, running the TCP/IP stack, bus management to backplane, or interrupt handling,” Hosking says “We have had G4 PowerPCs or [Texas Instruments digital signal processors (DSPs)] running independent OSs, and making calls through eCos for data or other housekeeping services, as it ran on a small Intel processor in the middle of the board,” Hosking says.
Then Pentek opened up eCos to its customers, including full source code and access to libraries and kernel code.
The company uses eCos in its model 4205, with a single G4 PowerPC I/O processor acting as a real-time kernel for straightforward jobs like moving data off the analog-to-digital converter to a fibre channel disk. Pentek also uses eCos for the RTS 2501, a real-time radar recording system for high-speed data transfer.
“To me, real time is fast enough to meet the needs of the application, and that’s it. If you can watch streaming video during a webcast on your laptop, and it works, then that’s real time,” he says.
Another hardware trend affecting operating systems is the powerful performance and flexibility of field programmable gate arrays (FPGAs).
“A lot of things that used to be done on multiple PowerPCs or DSPs are shifting over to FPGAs. And an FPGA doesn’t need an OS. You can achieve that signal-processing function on a piece of hardware that doesn’t inherently need an OS; it runs algorithm in configurable hardware. An FPGAs can be thought of as OS-reconfigurable ASIC,” Hosking says.
Mathworks tool helps keep programming simple
Engineers at The Mathworks in Natick, Mass., make a tool that helps designers develop their proprietary real-time operating systems (RTOSs).
“People are using our Simulink tool to model algorithms and generate C-code, then they use a hand-coded operating system in applying it for embedded systems, or we can generate calls to an existing OS like VxWorks or Integrity,” says Tom Erkkinen, embedded applications manager at The Mathworks.
Instead of buying a commercial RTOS, many military designers still like to “roll their own.”
“The more safety-critical the code is, the less likely they will be using an RTOS to begin with. A lot of companies don’t need all the services of a DO-178B-qualified OS; they just need a foreground/background scheduler,” he says.
Honeywell avionics designers developed their own digital engine operating system (DEOS) for the company’s flagship PRIMUS EPIC avionics system, used today in Bombardier Global Express, Gulfstream IV & V, and Dassault Falcon 900 aircraft for automatic flight controls, monitoring warning systems, and fly-by-wire control systems. Honeywell used Mathworks tools to develop DO-178B certified code for the system.
BAE Systems used Simulink to create code for its own CsLEOS, used today on the Northrop Grumman Pegasus X-47B J-UCAS, C-17 Globemaster III, and Sikorsky S-92 and H-92.
Likewise, a customer doing FADEC (full-authority digital electronic controls) for jet-engine controls had more need for application software and less for the RTOS. So they used their tried-and-true scheduler, a proprietary kernel created in-house, Erkkinen says. That type of simple system boots the chip then maps an interrupt or two, but does not include all the semaphores and queues of a full RTOS. It executes tasks and shifts priority to interrupt as needed-just providing the basic services.
“Now the job of the RTOS vendor is to show them you can still do that reliably with a commercial version, and also use the additional features,” Erkkinen says.
“It’s a very conservative industry; they stick with what works, has been certified, and is predictable. But if a company comes along and says they have an RTOS that’s reliable and COTS and they can support the cost of maintaining it spread across many customers, it will be much cheaper than the user supporting it on their own.”
Europe leads safety-certifiable orders
Board makers in the past year saw a sudden demand for safety-certifiable products.
Those cards will make a major impact on the market next year, including Pentagon demands for both DO-178B for software and DO-254 for hardware, says Mike Hornby, director of integrated product team for graphics and safety certifiable for Curtiss-Wright Controls Embedded Computing in Ottawa, Ontario.
The company used to produce both foundation firmware and the board support package (BSP) for customers needing a safety-certifiable card. But the work took so much time and money that Curtiss-Wright recently subcontracted the work to a partner company. They will announce the deal this summer.
Likewise, Curtiss-Wright has retained CSI in Seattle, Wash., as a subcontractor on DO-254 work for its European customers.
“Eighty to 90 percent of the safety-certifiable market is in Europe. It will arrive in the U.S., but it’s not here yet; I expect that to change over the next year,” Hornby says.
“This is a trend that’s here to stay; it’s not a flash in the pan. It’s taken root in Europe, and is coming to the U.S. Having a safety-certifiable option is critical to maintaining and competitive advantage in the marketplace; we can’t afford not to.”
Tools ease development
One way contractors can develop their real-time embedded software is with the Graphical Entry Distributed Application Environment (Gedae), from Gedae Inc. in Mt. Laurel, N.J.
Designers create software using Gedae’s library of block diagrams and algorithms. Then Gedae implements the application by generating code targeted to the specific embedded hardware and multiprocessor. That lets them correct potential bottlenecks in software processing flow, says Gedae President Bill Lundgren.
Engineers at Lockheed Martin in Dallas, Texas, used this method recently to create automatic target-recognition (ATR) algorithms to run a November 2004 captive flight test of a laser radar (LADAR) seeker.
Engineers will also use Gedae to create software for the Captor Tranche II RADAR program, according to a January 2005 announcement from BAE Systems in Edinburgh, Scotland, and EADS in Ulm, Germany. Captor is a third-generation, coherent multimode radar, used as the primary sensor on the Eurofighter Typhoon.
Another benefit of automated software generation is code portability.
“Lockheed Martin has gone through two or three platforms without recoding the application, as long as the BSP is available,” Lundgren says. “We get code portability with a virtual machine built on top of BSP, on top of the hardware. So we’re building on a known target. Even if they change, it is simple to implement.”
The board support package (BSP) is an application-programming interface (API) provided by the hardware vendor.
A customer can easily port software between major COTS brands like Mercury, Curtiss-Wright, and Sky, since Gedae has BSPs for that equipment, says Lundgren. The change takes longer if a user changes to custom hardware, since engineers must implement the unique BSP.
COMPANY INFORMATION
Accelerated Technology
Wilsonville, OR 800-468-6853
www.acceleratedtechnology.com.
Aonix
San Diego, Calif. 800-972-6649
www.aonix.com.
BAE Systems (CSLEOS)
Johnson City, N.Y. 800-295-3530
platformsolutions.na.baesystems.com:8080/CsLeos/index.jsp.
Curtiss-Wright Controls Embedded Computing
Kanata, Ontario 613-599-9191
www.dy4.com.
Enea Embedded Technology
San Jose, Calif. 866-844-7867
www.enea.com.
Express Logic
San Diego, Calif. 858-613-6640
www.expresslogic.com.
FSMLabs
Socorro, N.M. 505 838-9109
www.fsmlabs.com.
Green Hills Software
Santa Barbara, Calif. 805-965-6044
www.ghs.com.
LynuxWorks
San Jose, Calif. 408-979-3900
www.lynuxworks.com.
Mathworks
Natick, Mass. 508-647-7000
www.mathworks.com.
Monta Vista
Sunnyvale, Calif. 408-328-9200
www.mvista.com.
OmniSoft
Cupertino, Calif. 408-865-0186
www.omnisoftinc.com.
Real-Time Innovations Inc.
Santa Clara, Calif. 408-200-4700
www.rti.com.
Seaweed Systems
Woodinville, Wash. 425-895-1721
www.seaweed.com.
Timesys
Pittsburgh, Pa. 888-432-8463
www.timesys.com.
Wind River Systems
Alameda, Calif. 510-748-4100
www.windriver.com.
