The IULS Approach to Software Wrapper Technology for Upgrading Legacy Systems Dr. David Corman The Boeing Company This article describes using software wrappers in Incremental Upgrade of Legacy Systems as a key technology for mod- ernizing legacy systems. It introduces three types of wrappers, describes a process for selecting which upgrade path to utilize, and discusses a tool-set developed by The Boeing Company for the Air Force that automatically generates wrap- pers. Lastly, it discusses real-world avionics upgrade examples where the tool-set has been applied and its effectiveness. vionics upgrades are frequent and environment (its context). The wrapped is to develop, demonstrate, and transition Aoccur for many reasons, including component becomes a software object. Its software wrapper technology that will warfighting enhancements, countering operational capability (functions and enable cost effective, incremental changing threats, hardware obsolescence, data) is encapsulated, and it can be inte- improvements to fielded weapon system and computer resource under-capacity. A grated through its standard interface with avionics. The products of IULS are: 1) typical production avionics upgrade cycle other software objects to form an opera- methodology for analyzing software for military aircraft frequently involves tional flight program (OFP) on a single or upgrade approach, 2) wrapper technology, embedded software changes. New ver- distributed processor host. The wrapper 3) tool-set for constructing wrappers for sions of mission processor software, the manages the timeliness of all shared and software upgrades, and 4) demonstrations most volatile class of avionics software, are external data, and provides any necessary of IULS wrapper technology applied to typically released annually and take two transformations. three significantly challenging problems: years to field from initial definition. For upgrades, the goal is to develop F-15E, C-17, and CV-22 avionics. Hardware obsolescence occurs collec- the new or reengineered applications IULS is funded by the Air Force tively over a longer term as vendors using the latest software engineering tech- Research Laboratory, Embedded change their business (military/commer- niques such as OO design and languages Information Systems Engineering Branch cial mix) and technology. Software tools (Ada and C++) with minimal concessions (AFRL)/(IFTA). Participants in the proj- and technology also evolve over a longer to the internal structure of the legacy sys- ect include The Boeing Company, period but may be driven by short-term tem. It is developed as if all other applica- Honeywell Technology Center, General events such as the introduction and impo- tions were resident in the new environ- Dynamics Information Systems, and sition of Ada. The change cycles are not ment. Because the new software is written TRW-Dayton. synchronized so the optimal hardware, within the paradigms of OO design and software and tool technology, and respec- languages, the wrapper can eventually be Software Wrapper Technologies tive program funding to support an removed once all of the application func- Figure 1 illustrates three hypothetical cases of implementing software changes using avionics upgrade at a given point in time tions have migrated to the new system. At wrappers. are often not available. this time, the legacy system can also be The problem of cost-effectively removed. upgrading legacy systems can be mitigat- The Incremental Upgrade of Legacy Re-Host In the case, the legacy processor is ed through reengineering with the latest Systems (IULS) program is a research and re-host obsolete and/or its resources are insuffi- generation hardware and architectural development effort, whose main objective concepts, including object-oriented (OO) software design, which inherently con- Figure 1: Wrapper Cases tains and isolates change. However, legacy Re-host Sync avionics software represents a large invest- Legacy Source Rehosted Executable Re-hosted Upgrade Executable ...1100110001110101 Processor ment in development tools, executable [Translate] In ...110011000111010 Out 010101010101010010 1010101010101010 code, and ground and flight qualification. 111010010011010001 0101110100100110 Compile 1100111001010010... 100010101001010... Should the upgrade require complete reengineering of this legacy software, Put Get much of this investment is lost; many air- craft programs simply cannot afford the Hybrid Sync up-front costs associated with reengineer- Legacy Executable Legacy Upgrade Processor ...110011000111010 Processor ...11001100011101 In ing and complete re-qualification. 0101010101010101 1010101010101010 Out 0101110100100110 0010111010010011 100010101001010... One solution to this dilemma is 01000101010010... implementing reengineering incremental- ly by inserting the latest technology in Put Get smaller, affordable steps, thereby reducing Emulate ISA Emulator Sync risk and deferring or reducing cost. Legacy Executable Fetch Legacy Upgrade Executable Software wrapper technologies hold par- Decode Processor ...11001100011101 ...110011000111010 In 0101010101010101 1010101010101010 Out I/O ? ticular promise in meeting this challenge. 0101110100100110 0010111010010011 100010101001010... 01000101010010... A wrapper is a software adapter or Emulate ISA Emulator ? Branch shell that isolates a software component Put Get from other components and its processing December 2001 www.stsc.hill.af.mil 9 Software Legacy Systems process and the data that flows between them. Wrapper Implementation Considerations Wrappers are generally applied at the application domain level. They act as clients and servers to the encapsulated component. Figure 3 illustrates a general wrapper structure for an OFP on a single processor. The legacy application inter- faces with other applications and other layers only through the wrapper. The wrapper architecture is tailored to the spe- cific legacy OFP environment. The method selected to implement the upgrade of a legacy system is to an extent an economic decision. The emulation option will tend to favor a context of a sta- ble application, infrequent OFP modifica- tion, and obsolete hardware. These cases Figure 2: Nominal Legacy Operational Flight Program Wrapper Process will generally be lower in performance, cient to support additional upgrades. The wrapper components. As components in being older systems. Therefore, the con- legacy software is re-hosted to a new the legacy OFP require changes, they can text analysis would focus on issues of processor by translating its source code be reengineered and moved to the new throughput, OFP stability, parts obsoles- (e.g., Ada 83 to C++) and/or recompiling processor. At some point in the migration, cence, OFP utility, etc. it for the new target (e.g., Ada 83 to Ada the remaining legacy components are re- Selecting a hybrid or re-host approach 95). Reengineering the OFP on the new hosted, the legacy processor is upgraded would generally be appropriate for a more processor could not be justified so wrap- or discarded, and the wrapper compo- dynamic and/or higher performance sys- per components are added to make it look nents in the new OFP, associated with the tem. Typical context would be OFPs that like an object in the OFP. New software legacy OFP interfaces, can be removed. are subject to periodic update and version features can be added incrementally to the release. In addition, the higher the wrapped component, or preferably, Emulate throughput needed, the more likely the designed as new objects in the OFP. Obsolete or underpowered hardware is upgrade path will not include emulation. also addressed in the emulate case. The The reason for this analysis factor is that Hybrid legacy software is judged to be very costly while software emulation provides a growth In the hybrid case, the legacy processor to reengineer and/or re-qualify. The path for the legacy upgrade, there is a and its OFP are retained for various rea- object code is executed on the new proces- penalty paid for using processing resource sons (high reengineering or logistics costs, sor by an emulation of the legacy proces- overhead. A hardware emulator approach etc.), but its resources are insufficient to sor’s instruction set architecture. will, with time, become a technology support additional upgrades. Also, there is Changes can still be made to the lega- dead-end (as would be the case for the an opportunity to satisfy upgrade require- cy executable using the legacy compiler legacy system) and require more near term ments with reuse library components that and software engineering environment. upgrade effort. are developed with more modern lan- The emulator and other wrapper compo- Any selected legacy upgrade technique guages (such as Ada 95 or C++) and tools. nents make the legacy executable compo- will, of course, be subject to obsolescence New features can be added incremen- nent (binary) look like an object. Other and eventual upgrading. Therefore, the tally to the upgrade OFP as objects on a feature upgrades could be added as new methods described for the upgrade process new processor. The objects will be bridged objects on the new processor. and wrapper generation emphasize as flexi- to the legacy OFP and processor with ble an approach as possible. Also, the Wrapping Process methods need to be portable between Figure 3: Wrapper Software Structure As with any other software development hardware platforms since these compo- activity, wrapper creation follows a nents will