Migrating safety-critical software in military and aerospace systems
StoryJune 20, 2011
Tim King
DDC-I
DO-178B applications face reverification and recertification with the impending migration to DO-178C standard.
There are hundreds of millions of lines of legacy code in use in today’s military and commercial avionics systems. Most of these legacy systems were developed using programming languages and development systems that are now obsolete (or obsolescing) and programming expertise that is no longer available. As a result, these legacy systems have become increasingly difficult and expensive to maintain and upgrade, thereby forcing developers to migrate their applications to new development hosts, compilers, safety-critical operating systems, and programming languages. In addition, the imposition of new standards and new requirements for certification from regulatory organizations can also trigger a need for software migration and reverification.
Migrating complex embedded software, specifically 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, rereviewing, reanalyzing, and even recertifying. There are many factors that make legacy applications difficult to port. These factors include programming language nuances, compiler-specific implementations, runtime and hardware dependencies, the use of extensions beyond the defined programming language, and incompatible application code structures. Migrating applications can also impact reuse of code that has been certified to DO-178B or that will be certified to the upcoming DO-178C.
Migrating to a new language
The most challenging of all migration efforts is moving code written in a legacy language such as Ada or JOVIAL to another language such as C. Because the generated application will not be binary identical to the original, it will require at a minimum basic retesting and probably full reverification. Moreover, because the application must be modified at the source code level, new software engineers assigned to the program will likely have to be trained in the legacy programming language as well as in the application’s design and inner workings. This will inevitably introduce bugs into the application. Other factors will also come into play. For example, the generated code will have a different layout and may no longer fit in the available memory. The data layout will also be different and no longer map correctly to the underlying hardware. Performance and timing aspects will also change.
When changing languages, it is best to use a development environment that supports the legacy language as well as the new target language, with the ability to mix languages. This will allow designers to migrate slowly and to test in steps. 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 between code segments. These tools seldom interact in a coordinated fashion or exchange information to help correlate object code to multiple language sources. Mixed-language development environments such as DDC-I’s OpenArbor allow mixed-language debugging from a single launch, making it easier to detect interaction errors and coordinate new and existing code.
Developers might also want to take advantage of tools and services that expedite the conversion process. These include 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 features and/or augmented with new functionality.
DO-178B/DO-178C migration
If an application was originally certified to DO-178B and it is migrated, it will have to be reverified and recertified with the new language, development environment, verification environment, and runtime environment. As mentioned, later this year, the industry will begin its transition from DO-178B to DO-178C, which will have new implications, both in new development and legacy code reuse. Along with adding some clarification to the guidance of DO-178B, the DO-178C document adds new guidance to accommodate development technologies that have become common since the publication of DO-178B, including object-oriented programming, model-based development (UML or Simulink), tool qualification, and formal methods.
The good news for developers is that DO-178C preserves the core DO-178B guidance with some modifications for clarification. Developers will still have to familiarize themselves with the guidance in each area applicable to their specific processes and procedures. Developers will also have to assess the impact of the additional guidance, tailor their processes and procedures accordingly, and update any software and certification artifacts that they migrate. However, the bulk of DO-178B will remain intact, thereby simplifying the transition to DO-178C.
Tim King is Technical Marketing Manager at DDC-I. He can be contacted at tking@ddci.com.
