Migrating complex embedded systems

Story

June 24, 2008

Ole N. Oest

DDC-I

Migrating today's complex military and commercial avionics systems can be quite a daunting proposition, but several steps can be taken to alleviate some of the headache.

There are hundreds of millions of lines of legacy code in use in today's key military, commercial avionics, and other systems. Most of these legacy systems were developed using programming languages that are now obsolete (or obsolescing) and development systems that are antiquated and no longer serviceable. As a result, these legacy systems have become increasingly difficult and expensive to maintain and upgrade, forcing developers to migrate their applications to new development hosts, compilers, operating systems, and even programming languages.

When it does become necessary to upgrade a system, avoid the temptation to modernize other aspects of the application at this time, such as converting the application to a new programming language. It can be tempting to migrate to the "latest and greatest," but it is generally wiser to take it slow and migrate only when it is really needed and economically justified. Ideally, new functionality should be added using the original development system and language or another language supported by the same development system in a mixed-language configuration.

Migrating complex embedded software - particularly in applications requiring real-time response and a high degree of safety criticality - can be a costly, time consuming, and risky process requiring code changes, retesting, and even recertifying. There are many factors that make legacy applications difficult to port, including programming language nuances, compiler implementations, runtime and hardware dependencies, the use of extensions beyond the defined programming language, and incompatible application code structures. Migrating applications might also impact prior certification efforts (for example, DO-178).

Still, it is critical to retain well-proven applications - and enable them to operate on different processors, development environments, compilers, or even newer programming languages. Mission- and safety-critical software can cost well over $10/line and years to create (upwards of $100/line for safety-critical with artifacts). Legacy software, by contrast, can typically be migrated for a few dollars per line and redeployed within a year.

A number of factors must be taken into account when considering whether or not to migrate legacy applications. Among these are the performance of the embedded application, resource constraints such as memory and power, timing constraints, data layout (must match the underlying hardware), extendibility with new functionality, and the consequences of changing the target word length (for example, from 8 to 16 bits, 16 to 32 bits). Other factors include readability and maintainability, traceability of changes, requirements for certification or recertification, and potential side effects for introducing an RTOS into a bare-board environment.

The complexity of migrating legacy applications makes proper planning essential. Before starting a migration project, for example, DDC-I performs a migration assessment study to identify technical challenges and resolve unknowns. With this information, DDC-I's professional services team can make recommendations and propose technical solutions for how to best approach the migration effort, including manpower requirements and cost estimates.

Changing programming languages

The most challenging of all migration efforts is moving code written in a legacy language like Ada or Jovial to a new language such as C or real-time Java. Whether this is done to facilitate maintenance or to take advantage of advanced new language features, it is best to use a development environment that supports the legacy language and the new target language, with the ability to mix languages. This will allow you to migrate slowly and to test in steps. Developers may also want to take advantage of tools and services that expedite the conversion process.

DDC-I, for example, offers semi-automated tools that convert applications in a predictable and straightforward manner while retaining the original application structure and source code comments. This enables the converted code to be readable and maintainable, minimizes the risk of introducing software errors, and eliminates any further dependency on the software conversion tool. Once in the new language, the application can then be optimized with newer language optimization tools, augmented with new functionality, or transposed to model languages (for example, UML).

Even with the help of these tools, converting applications is rarely trivial, particularly when mission or safety criticality is required. Still, given the exorbitant cost and time associated with developing new applications, migrating existing applications is usually the best option. With the aid of proper planning, conversion tools, and professional services companies who have specific expertise in this area, developers can greatly expedite the conversion process while mitigating their risk.

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. He can be reached at [email protected].

DDC-I
602-386-4360
www.ddci.com