The IULS Approach to 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 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 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 change rapidly (on the order of process, shown in the IDEF0 diagram in months vs. years). Therefore, the initial sys- Legacy Wrapper Figure 2, and is automated with tools. In tem context analysis would focus on OFP Legacy issues such as throughput, stability, etc. Application an IDEF0 diagram, consumed inputs Application Layer (e.g., data files) go in the left side of an activity box; generated outputs (e.g., com- Using the IULS Tool-Set in pleted design objects) emerge from the Database/Utilities Upgrading right side; constraints (e.g., requirements, As part of the IULS program, Boeing and Executive/Run-Time schedules) go in the top; and mechanisms its IULS teammates developed a set of (e.g., tool support) go in the bottom. The guidelines, processes, and tools to help the Backplane or Shared Memory Driver following subsections describe tool mech- avionics engineer determine and imple- anisms that support the wrapper design ment a best wrapper upgrade strategy. The

10 CROSSTALK The Journal of Defense Software Engineering December 2001 The IULS Approach to Software Wrapper Technology for Upgrading Legacy Systems

IULS tool-set that was developed in this Wrapper Architectures Wrapper Wrapper Library Shelf effort has played a major role in automat- Legacy Signature Framework Data Transforms ing the upgrade approach in the re- Legacy Controller Sync/Control host/hybrid domains. The tool-set is used In/Out/Put/Get ISA Emulator to iteratively develop high-level and Modeling Environment detailed models of the OFP model, the ...1100110001110101010101 host model, and the upgrade model. 010101010010111010010011 Graphical Architecture 010001010100100110101010 Wrapper Toolset 111110001001010010101110 Design & Design 100010100101010110101010 Figure 4 displays some of the basic ele- 0101010101001010101010... Editor Analyzer ments of the IULS graphical tool-set. Legacy Software Briefly, the tool provides a graphical capability to model the legacy and upgrad- Sync Design ...110011000111 In 01010101010101 Out New 0101001011... ed system, including data interfaces and Database t S/W constraints. It includes a re-use compo- ISA Put Get nent library that can be used to meet Auto-code Test requirements common to avionics applica- New Host Processor Generator Generator Infrastructure-CPU-I/O tions. It provides code and documentation Proposed New Document Upgraded Software Generator generation capability to construct and System With Wrapped Legacy document the software wrapper used to Figure 4: Graphical Tool-Set bridge the legacy and upgraded system. Also, the tool provides system-modeling upgrades influence the choice of wrapper reusable wrapper components are linked capabilities that can be applied to validate approaches. to requirements and test cases that are also system performance against scheduling The characterization step provides reused. The process of wrapper design constraints common to hard real-time high-level information that can be used to includes specifying the following within avionics systems. perform coarse trade-off analyses that con- the tool-set: tribute toward a final selection of wrapper • Invocation interface: This is the inter- Customer Inputs to the Process approach as well as some of the basic deci- face for entering into and returning The select preferred wrapper approaches sions about the wrapper design. Some of from the OFP code. It includes the activity consists of selecting from among this high-level model will identify wrapper description of error handling inter- the three basic wrapper approaches. The components able to be tailored from a faces. host plans, legacy OFP, and host interface reuse library. • Semaphores and interrupt handlers: (I/F) are information supplied by the cus- This is the interface that defines syn- tomer. The information specifies the OFP Wrapper Design chronous process behavior, both hard- re-hosting problem in a manner that is As shown in Figure 4, the wrapper is ware supported and software only. sufficient to trigger the next activities. The designed using the OFP model, host • Data accessors: This interface defines host plans identify the need to re-host the model, and upgrade model, as well as the accessors for data objects that the OFP OFP onto a new target platform and are reusable wrapper components. The IULS shares with other software modules. used to select one of the three wrapper tool-set includes a set of reusable wrapper • Emulator configuration: This approaches, or possibly narrow the selec- components that are placed on the shelf describes the emulator that may be tion down to two of the three approaches and can be either quite general in nature interfaced to the wrapper, depending that will be considered during the wrapper (e.g., format converters from one process on the wrapper approach used. design process. to another) or domain specific (data • Object adapter: This is software that access methods for an aircraft). The makes the wrapped OFP look like one Characterizing the Problem Figure 5: OFP Wrapper for F-15 Demonstration The IULS tool-set is used to characterize and model the legacy system OFP. The Upgraded Software Architecture resulting OFP model is a description of the legacy code, it’s source language, the F-15E New Host IULS Wrapper Rehosted available documentation and compilers, Avionics F-15 OFP F-15 OWS and the description of the I/O required by OO C++ C++ Ada95 Ada83 the OFP, including timing. The model Stores Load Avionics Get Transfer OWS Fuel Load describes each interface modality that the Inputs Data Data Inputs OFP has with other OFPs and with the Inertial legacy host hardware. The tool-set is also Navigation System G’s OWS Transform Transform used to develop the host model, which pro- Processing: Data Data vides a description of the target host com- 10 Hz puter environment (not the legacy host). 10 Hz Warn It includes a description of the machine Heads Up 20 Hz code, compilers available, event capabili- Display G’s Display ties, I/O capabilities, and kernel operating Get Display Data Transfer OWS system (OS) interfaces. Data Data Outputs The upgrade model is a description of Head-Down OWS the plans to upgrade the target host com- Auto-coded C++ & Ada95 puter in the future. The plans for future Display

December 2001 www.stsc.hill.af.mil 11 Software Legacy Systems

Component Software Lines of Codes Total Source Lines wrapper was designed and auto-generated (Not Comment/Blank) using the IULS tool-set. This was the first Total OFP (C++ and Ada) 119,363 3 534,054 4 application of the IULS tool-set and pro- OWS Application (Ada Including PIMs) 7,195 5 23,738 8 vided us a framework for testing and tun- Ada Wrapper 482 2 880 0 C++ Wrapper 408 8 811 1 ing of the tool. Figure 5 (see page 11) shows elements Table 1: Wrapper Component Sizes of the wrapper design. In particular it or more objects to an underlying OFP Integration, Test, and shows how the wrapper supports transfer of data from the OO C++ domain into object request broker (ORB). It Documentation defines the OO interface classes and The wrapped components and host com- process interface messages understood by methods comprised in the wrapper. ponents are compiled, linked, and integrat- the legacy Ada software. The wrapper also • design: If the wrapper ed into the target processor system. System performs necessary data transforms and approach calls for re-hosting the lega- and software testing is performed to a level includes a bridge from the Ada 83 software cy OFP, then a description of the appropriate to the avionics application. By to the C++ and display processes. tools, process, and wrapper interface using the same specification for wrapper The F-15 IULS activity culminated in objects needed to support that design, evaluation, and implementation, a successful live flight demonstration con- approach are specified. traceability is greatly simplified and facili- ducted on Dec. 1, 1999. The demonstra- tated. Model objects can be cross-refer- tion flight plan called for execution of six enced to requirements, implementation test points. These corresponded to combi- Evaluation of the Wrapped OFP nations of three different weapon loads After a candidate wrapper is designed and components, evaluation models, tests, and with two different fuel configurations. The a baseline determined, it is evaluated. The test results. The IULS tool-set includes a pilot, weapon systems officer, and flight evaluation is performed using component document generator that compiles software test engineer reported successful test selected from a library. The compo- documentation from the design database models results. using customizable templates. nent models are the representations of the The relative sizes of the components (in target hardware system. These are used in source lines of code) for the final demon- running simulations of the target system to Demonstrations stration and flight test OFP are shown in determine performability. System model- The IULS program included major Table 1. ing and evaluation tools such as Cosmos demonstrations of two of the wrapper We collected metrics on the wrapped and Foresight can be used in concert with approaches: modified re-host and emula- system to measure wrapper overhead. It the IULS tool-set to simulate and evaluate tion. The demonstrations provided an was indicated that wrapped system added the wrapper design. opportunity to test and tune the tool-set in an average of 0.36 msec and 0.16 msec to a real-world avionics upgrade environ- the OWS application execution timelines Wrapper Code Generation ment. The following subsections describe for the 20 Hz and 10 Hz tasks, respective- Once the wrapper design has successfully the results of the application of the IULS ly, for operation on a PowerPC 603E. The passed evaluation tests, the IULS tool-set tool-set. computations were all performed within provides the capability to automatically the time-frame requirements for the OFP. generate the wrapper using a code genera- F-15 Demonstration The F-15 demonstration thoroughly tor. It identifies the versions of the compo- For the F-15 demonstration, the IULS validated the IULS re-host process and nents, how those components were tai- problem was to port a legacy F-15 Ada 83 tool-set. Operationally, the demonstration lored, and how those components are to OFP component, the overload warning received enthusiastic endorsement from link together with the OFP. The wrapper is system (OWS), into a F-15 OFP written in the flight crew who referred to it as a home then linked with the OFP to create the C++ running on a new commercial off- run in the post flight debrief. The in-flight wrapped OFP. the-shelf (COTS) PowerPC processor. A performance was 100 percent in agreement with the a priori estimates matching all six Figure 6: C-17 Demonstration for Emulation Wrapping test points, exactly. The WrapidH tool Aircrew Laptop CCU NO. 2 proved to be extremely valuable in devel- Not Present CCU Legacy (ALC) Database Download OFP oping the wrapper design, and the auto- mated code generator worked as expected in both the Ada and C++ domains. Radio (UHF1) As predicted, considerable domain expertise was required to develop the wrap-

MCDMCD MCK/MCD Emulator 1 2 per. However, IULS engineers who initial- MCD MCK ly had no familiarity with the heritage code MCD performed the bulk of this work. These engineers were able to readily understand TRW's the legacy Ada and Common Operational VIEWstation TRW RePlace Flight Program (COFP) C++ to the extent Debug Toolset Radio (VHF2) Emulator required to support wrapper design and system de-bug. Wrapper testing confirmed the prediction that wrapped code integrity would be intact – no problems were detect- VME Chassis ed in which wrapped code operation was CCU NO. 1 an issue. Wrapper overhead was not sub-

12 CROSSTALK The Journal of Defense Software Engineering December 2001 The IULS Approach to Software Wrapper Technology for Upgrading Legacy Systems stantial and confirmed system modeling IULS AutoWrapper conducted during phase one of the IULS Quiet Migrate to Knight program, which had predicted system Sync Upgrade Legacy Processor Modules throughput was more than adequate for Legacy OFP Ada 95 Processor (Ada 83) the demonstration requirements. ...11001100011101 In 0101010101010101 Out ...11001100011101 0010111010010011 0101010101010101 0100010101001010 0010111010010011 ... C-17 Emulation Demonstration 01000101010010... The IULS emulator approach was demon- Put Get PowerPC strated by wrapping a legacy C-17 radio Adv. AYK-14 (MIPS) control function (RCF) executable Tech Demo Outputs (JOVIAL source, MIL-STD-1750A Legacy System Issues • Proof of concept for CV-22 object) with a 1750A ISA emulator run- Open System Architecture • Limited / No expandability candidate ning on a PowerPC processor that repre- in current CPU to meet sented an upgraded communications con- • Demonstrated growth SOCOM potential for CAAP trol unit. The emulator interface and •needsProprietary processor function processor context wrappers were generated andsystem • Upgrade to CV-22 with with TRW’s RePLACE tool-set. Figure 6 bus Candidate CAAP S/W using shows the demonstration concept. IULS Toolset to auto A COTS replacement box (CRB) was generate wrapper constructed, including COTS processor • Wrapping legacy S/W (PowerPC). The emulation engine and enables incremental COTS Replacement Box (CRB) upgrades and incremental RCF OFP were loaded onto the CRB. The COTS Proc COTS Proc re-qualification CRB operated in concert with the 2nd JASS QK OFP (Ada) Wra- RT Wra- Modules communications control unit (CCU). This pper - pper Bold Stroke OB AARTS API provided a timing challenge since hand- Infrastructure shaking, normally performed by two COTS 1750A processors across the 1553 inter- face, was now being performed by the Figure 7: IULS CV-22 Wrapper Demonstration CRB and one CCU. The system was System Software mission software from demonstrated in the C-17 avionics labora- proprietary processor and system architec- About the Author tory with production test cases and avion- ture to a COTS PowerPC processor and ics system hardware. The demonstration VME architecture residing under the David Corman, Ph.D., showed an approximately 90 percent Boeing Bold Stroke software infrastruc- is a technical fellow of growth capacity for the CRB ture. Second wrap a new application The Boeing Corpora- The emulation tool-set is being transi- (Quiet Knight – Ada 95) to be executed on tion. Dr. Corman is cur- tioned to the C-17 as part of the on-going a second COTS processor using the tool- rently working on a vari- communications open systems architecture set and object request broker (ORB) for engineering and manufacturing develop- ety of projects that focus distribution. on upgrading of legacy systems. He was ment program. In this application, emula- The CV-22 demonstration is a work in the lead engineer on the Incremental tion is being extended as part of a larger progress. At the time this article was writ- open system upgrade. In particular, a new ten, the demonstration is planned for Upgrade of Legacy Systems (IULS) pro- C++ native language executive is being December 2001. The wrapper tool-set is gram that resulted in the development of developed that will then make calls to being used to develop the ORB interface a wrapper tool-set that has been demon- selected (emulated) legacy components. In definition language to construct the wrap- strated in real-time applications includ- effect, the emulated legacy software func- per. Initial results have been very promis- ing the F-15, C-17, and CV-22. Dr. tions as a library of callable functions. This ing. The mission OFP has largely (99 per- Corman has more than 20 years experi- is in contrast to the standard emulation cent) been ported to the COTS processor, ence in software development, including wrapper in which what is simply desired is and the IULS tool-set has been used to gen- real time, mission planning, C4I sys- to execute the legacy software on a more erate the wrapper software for the ORB. modern processor. tems, and avionics domains, and holds bachelor’s and master’s degrees in systems The lesson in transiting the emulation Summary wrapper is that quite frequently programs This article has described several impor- science and mathematics, and applied will apply tools in a different manner than tant applications of software wrappers to mathematics from Washington were originally planned, and the tool-set legacy . Under the University in St. Louis. He earned a doc- needs to provide inherent flexibility. AFRL-sponsored IULS program, Boeing torate in electrical engineering from the developed a tool-set that can be made University of Maryland, College Park. CV-22 Demonstration available to qualified requestors from We are applying the re-host wrapper AFRL/IFTA to support avionics upgrade The Boeing Company approach with a twist during an on-going opportunities. Wrappers are not a panacea P.O. Box 516 demonstration with the CV-22 program. for every modernization need. However, St. Louis, MO 63166 Figure 7 shows the basic elements of the experience to date indicates that they can Phone: (314) 234-3725 demonstration. The challenges are twofold: be an important element within the First, migrate Ada JASS-JVX Avionics upgrade process.N E-mail: [email protected]

December 2001 www.stsc.hill.af.mil 13