By Ole N. Oest
Migrating a safety-critical system can be a costly, risky process that developers avoid whenever possible. In some cases, however, migration is inescapable. Safety-critical embedded systems deployed in aerospace and defense often have a service life that exceeds that of the individual components in the system. Those components can become obsolete years or even decades before the system itself will be retired, forcing a migration decision.
If systems designers must upgrade individual components in the underlying embedded target hardware, which in turn requires migration of software components to the new hardware, the real-time operating system (RTOS)-or more primitive run-time support that was available on the old hardware-may not be available on the new hardware, which also calls for migration. Even the host computer hardware and operating system from which the system is maintained may become obsolete and require replacement.
No matter what triggers the change in hardware or software, migrating the embedded application implies changing, retesting, and possibly recertifying. The key to a successful migration is to minimize cost and risk with a thorough decision process.
Real-world migration
One example of a safety-critical avionics application was a migration on a display unit on the U.S. Air Force RC-135 Rivet Joint electronic surveillance aircraft. The primary trigger for the migration was the obsolescence of the Intel i960 microprocessor on which the system was built.
Once it was clear that migration was necessary, a secondary objective emerged to simplify the system by replacing the three i960-based avionics boxes-including three separate applications and three dedicated display units-with one Intel Pentium processor-based box and a shared display unit.
Within the system, two applications were coded in C, and one in Ada. Because neither DDC-I nor systems designer had any prior experience with the system or these embedded applications, the goal was to leave the applications unchanged as much as possible.
The migration project included several results. First, the simplified post-migration system consisted of one Pentium processor-based box and one shared display unit. The new target environment provided the necessary services to the applications.
Second, a mixed-language development environment was established based on off-the-shelf components from different vendors. This environment could handle Ada 83, C, and Pentium assembly code. Designers deemed using Ada tasking as overkill, so they deployed a nontasking Ada run-time system.
Designers developed a small and efficient cyclic executive to schedule which activities had to take priority and run to conclusion, and which could split over several time slots. Since the activities communicated via shared memory interrupts, some had to be postponed to the next available time slot or needed to be handled locally.
Finally, designers converted target-specific data layouts, such as representation specifications and machine-code insertions in Ada, from i960 to Pentium architecture as necessary, and developed a common graphical user interface for the three applications.
For this project, migration was unavoidable because the target hardware was obsolete, and designers wanted to simplify the system by merging three avionics systems into one. A customized development system avoided the need to change the application software, which prevented errors from being introduced into the system.
This approach was also cost-effective because designers to a large extent could reuse the certification documentation for the original system. The most critical component of the redesigned system was the cyclic executive, which had to guarantee that tasks like changing with the phase of the flight were always allowed to run to completion. In addition, engineers designed and tested the cyclic executive as a separate component independent of the applications.
Migration issues
Systems designers should consider several factors when considering whether to migrate a safety-critical system: performance of the embedded application; resource restrictions like such as memory and power; timing constraints; data layout to match the underlying hardware; consequences of change in target word length from 8 to 16 bits, 16 to 32 bits; extendibility with new functionality; readability and maintainability; traceability of changes; requirements for certification or recertification; and side effects of introducing an RTOS into what was a bare-board environment.
Designers should avoid the temptation to modernize other aspects of the application, such as converting the application from a legacy to a current programming language. Instead they should take advantage, if available, of a development system for the old language and the new target hardware. That way they limit the number of concurrent changes-and risk-to just two: development system and target hardware.
Many embedded systems in the aerospace sector were developed using the old Digital VAX computers and the VMS operating system. VAX/VMS has not been produced for quite some time, spare parts are difficult to find, and the VAX hardware may fail.
The lowest-risk migration is to change only one aspect of the system, namely the host platform. This is feasible if the original software development system and software tools are available on a current platform such as PC running Microsoft Windows. Otherwise, move to a VAX emulator running on a PC. Both these routes have been successful, and the binary form of the embedded application generated on the new platform will typically be identical to the original, reducing retesting and recertification.
If none of these routes are feasible, the migration becomes risky and costly. It may require not only a host platform change (for example, from VAX/VMS to PC/Windows), but also deployment of different software system.
The generated application will not be identical to the original, requiring costly retesting and recertification. Other factors come into play as well: the generated code will have a different layout and may no longer fit in the available memory; data layout will be different and will no longer map correctly to the underlying hardware; and performance and timing aspects will change. The application must be modified at the source-code level, which will require training software engineers in the programming language as well as in the design and inner workings of the application.
Migration only as a last resort
Although it might be tempting to migrate to a new language if there is no programmer available who is trained in the application’s programming language-Ada and JOVIAL are examples-this should be the last resort.
Before going that route, consider training programmers in the old languages. Programmers proficient in relatively complicated current languages such as Java or C++ will not find it insurmountable to learn another language.
If in the final analysis the original language must be scrapped, systems designers can change languages in part through translation tools. Be warned, however, that no tool can do a complete job and the readability of the converted source program may be questionable. If the designer has no choice, however, he should use a development tool set that supports the old and the new target languages with the ability to mix languages.
Ole N. Oest is chief operating officer of DDC-I Inc. in Phoenix.
Events that can trigger a possible migration
- The host computer on which the application is maintained becomes obsolete (for example, VAX/VMS, Sun/SunOS)
- The development tools originally used are no longer supported
- The original development tools aren’t available in a version for the new host computer and operating system platform
- The target hardware or processor becomes obsolete (for example, Intel 80860)
- The peripherals change or the communication bus or protocol changes
- The application must be augmented with new functionality, which may require a target operating system where there was none originally
- The new standards or FAA certification are imposed on the system
- The interoperability with newer systems is required
- The production royalties affect the profitability of the system
- Expertise in the application tools or languages is lost
