Figure 1 - F-16 Mission Software main architectural elements

Figure 1 shows the basis for the F-16 Mission Software architecture; it depicts the main architectural elements:

• Software that is unique to the application(s) for which the embedded computer exists, it represents some 80-90% of the total software (in terms of long-term development cost)
• Application Software Interface, the boundary between the Application Software and the Software Execution Platform. This provides the methods by which the Application Software can make requests and use the services of the Software Execution Platform and the Software Execution Platform can provide its services to the Application Software
• Software Execution Platform, low-level software, the purpose of which is to allow the Application Software to run on the hardware; The software execution platform incorporates device drivers, the built-in test and the RTOS.
• Hardware, the embedded system hardware for the F-16 Mission Management system.

The software execution platform effectively raises the abstraction level of the hardware to provide a platform on which code generated from Executable UML models can run directly. Lockheed Martin's goal of complete cross-platform compatibility implies a very strong form of platform independence whereby the UML models which specify the Application software behaviour can be ported without change even if the Application Software Interface changes.

The Approach - Model Driven Architecture using Executable UML
The use of MDA allows the mission software functionality to be formalised as Executable UML models (xUML); such models are Platform Independent Models (PIM) in MDA. Platform independence is essential if the goal of decoupling the models from any changes to the Software Execution Platform is to be achieved. xUML models are expressed using a UML action language based on the newly adopted precise action semantics for the UML (see http://www.omg.org/technology/documents/modeling_spec_catalog.htm#Action_Semantics).

Executable models support the MDA approach in two main ways. First, they allow early testing using simulation and debug tools. Secondly, since they are a full and formal specification of the system behaviour, they allow generation of the target code. Defining a mapping from the rigorously defined PIM (expressed in xUML) to the implementation is what is at the heart of MDA. Since xUML models are executable and rigorous they act as much more than a simple visual agenda for the software developers, they actually embody all the business logic required to execute and verify the system.

B a c k

Page 2 of 4

C o n t i n u e