First rule of Software Club: If it's not broke, don't talk about touching it. However, that is just not feasible in many situations, like when code that’s working perfectly well has to be migrated for a system-related reason. This becomes a big problem in safety-critical systems, where altering code can trigger a bunch of other expensive, risky activities. So what are designers to do? Here's an explanation of how to gauge what the team is in for and which options should be considered.

Migrating a safety-critical system to a new technology can be a costly, risky process that developers should avoid whenever possible. In some cases, however, migration is desirable for financial or performance reasons or inescapable because of hardware obsolescence and new requirements. Developers facing migration will need to carefully consider the type and extent of system changes to compare the benefits of in-house activity with design service support.

Safety-critical embedded systems deployed in aerospace and defense often have a service life exceeding that of individual system components. The rapid pace of technology evolution creates a high probability that at least one of those components will need to be changed years or even decades before the system itself will be retired. Such hardware changes can, in turn, trigger a need for developers to migrate system software to a new technology to ensure continued serviceability.

A number of system changes can trigger software component migration. For instance, peripherals, communications buses, or protocols may change, forcing code segment migration to new hardware. The target hardware or processor can become obsolete, as was the case with Intel 80860-based systems, compelling the entire system software to migrate to an entirely new platform. New functional requirements or certification standards may arise, forcing the system design to incorporate a Real-Time Operating System (RTOS) where none was needed before. Similarly, the imposition of new standards, new requirements for certification from regulatory agencies such as the FAA, and the need to interoperate with newer systems can generate a need for migrating software to a new platform.

Changes to the development environment also can elicit a need to migrate system software. Obsolescence of the host computer on which the application was developed and maintained, as happened with VAX/VMS hosts, can force system software migration to new development tools when spares for failing hardware become hard to find. Obsolescence of the development tools themselves or loss of expertise in the application tools or language can initiate migration to new tools to ensure that developers can continue supporting installed systems. Similarly, obsolescence of the RTOS can prompt software migration to a new platform.

Even business changes can spur migration. The production royalties associated with an RTOS or another software component can affect system profitability. As margins narrow, developers may choose to migrate system software to eliminate such royalties.

Reducing cost and risk

No matter what triggers the change in hardware or software, migrating system software involves cost and risk. Software migration implies not just changing the software and its attendant risk of introducing errors, but also retesting and possibly recertifying the software. The combined cost of development and test efforts can be considerable, especially for safety-critical systems that must meet strict requirements.

Factors in migration

One key to successful migration – minimizing cost and risk – is thoroughly understanding the impact of migration. Developers need to consider a number of factors, including:

• Performance: Will the new processor/RTOS/platform meet the system‚Äôs real-time deadlines?
• Resource restrictions: Will the software fit within the limits of system memory and register availability?
• RTOS impact: Changing or adding an RTOS into a once-bare board environment may alter code execution sequence or timing. It also may increase system complexity and alter memory requirements.
• Word length: How will changes in word length, say from 16 to 32 bits, affect existing code? Computation algorithms, pointers, counters, overflow/underflow conditions, and execution speed can be influenced by word length change.
• Tool availability: Will the host or target platform change also mean a tool set change? The development tools used to create and maintain system software may not be available for a given combination of host system and target processor or RTOS.
• Data layout: Compilers vary in the way they map data to registers and memory. Such variations may result in conflicts with implied or expected mappings in the software.
• Extendibility: Software migration may require upgrades or enhancements to functionality to meet new requirements. Tools and system resources need to support such enhancements.
• Traceability: The ability to trace migrated software back to the original can help reduce test costs by proving that the software has not changed.

The more changes made during migration, the more factors come into play. The lowest-risk migration is to change only one aspect of the system, such as the host development platform. This is feasible if the original software development system and software tools are available on a current host platform such as a PC running Microsoft Windows. Changing only the development host has a minimal impact on the rest of the system and software.

Developers should seek creative ways to keep the number of changes to a minimum. If development tools are not available on the new host platform, for instance, emulation may provide an alternative to switching tool sets. A VAX emulator running on a PC has proven successful in allowing continued tool use, and the binary object code thus generated has typically been identical to the original. The tools, source, and object code did not change, reducing the need for retesting and recertification.

Tool changes require compiler expertise

When tool sets must change, developers face additional challenges. Compilers vary in the way they map the source code to the underlying hardware structure, such as memory addressing and register usage. Unless developers carefully constrain the compiler’s behavior, these variations can result in changes to the object code. At best, this triggers a need to retest and possibly recertify the software. At worst, the changes can cause unexpected and potentially flawed system behavior during execution.

Changing tool sets without causing other changes demands that the development team have expertise in compiler behavior – expertise that application-level engineers typically lack. To avoid spending time and effort acquiring the needed skills, development teams can look outside for assistance. Design service organizations usually have experience working with a wide variety of tool sets and can bring that experience to bear in ensuring that a tool change does not trigger software changes.

Designer teams should avoid some changes as much as possible, such as converting the application from a legacy to a current programming language. Instead of converting, teams should utilize a development system for the old language and the new target hardware. This limits the number of concurrent changes and risks to just two: development system and target hardware.

Changing languages involves many possible pitfalls. 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 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 new programming language as well as in the design and inner workings of the application.

Although it might be tempting to migrate to a new language if none of the programmers are trained in the application’s programming language, this should be the last resort. Before taking 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.

Design services offer expert assistance

Another possibility is to engage design services that offer the necessary language expertise. For specialized languages such as Ada and JOVIAL, which target military and avionics systems, design service providers often have extensive experience in the application space as well as the language, including experience with the needs of safety-critical system design. This enables them to quickly develop an in-depth understanding of system software and provide the maintenance and upgrade support the development team requires.

If, in the final analysis, the original language must be scrapped, systems designers can change languages in part using translation tools (such as in Figure 1). No tool, however, can do a complete job, and converted source program readability may be questionable. When possible, development teams should strive to change languages only for sections where it is absolutely necessary.

One way to accomplish this is to use a tool set that supports the old and new target languages and can mix languages. This allows teams to keep intact those sections of original code that are still useable and limit language changes to sections involved in meeting the new requirements.

A key part of such mixed-language tools is the debugger. While many compilers can combine code segments in different languages, most debugger tools handle only one language at a time. This means that developers must invoke several tools simultaneously to view interactions among code segments, and these tools seldom interact in a coordinated fashion or exchange information to help correlate object code to multiple language sources. Tools such as DDC-I’s OpenArbor (shown in Figure 2) that allow mixed-language debugging from a single launch can significantly reduce debug time and more readily detect interaction errors.

Whether or not a language change is involved, migrating safety-critical system software is a complex task with many potential pitfalls. Each change in hardware, host, target, tool, and language introduces complications and may force additional changes, leading to escalating consequences. The costs and risks inherent in migration should be avoided as much as possible by maximizing legacy tool and code reuse. When changes are necessary, carefully selecting new tools and strategically using experienced design services can mitigate software migration risks and costs.

Ole N. Oest is Chief Technology Officer and cofounder of DDC-I (Phoenix, Arizona), a leading supplier of software tools and services for safety-critical embedded applications. Ole holds an MS in Electrical Engineering and a PhD in Software Engineering from the Technical University of Denmark, with special interest in programming languages and compiler construction as well as formal specification and program development.

DDC-I
602-386-4360
[email protected]
www.ddci.com