8/7/2019 MP-072-15

1/12

15-1

Transitioning to Integrated Modular Avionicswith a Mission Management System

M. Gangkofer, Dr. H. Kader, Dr. W. Klckner, C.G. WhiteESG Elektroniksystem- und Logistik GmbH, Fixed Wing Aircraft - Advanced Avionics,

PO Box 80 05 69, 81605 Munich, Germany; e-mail: asaac@esg-gmbh.de

1 SUMMARYThis paper presents an incremental approach towardsthe adoption of an Integrated Modular Avionics(IMA) architecture, via the implementation of aMission Management System using present-dayCommercial Off-The Shelf (COTS) technology.While standardised IMA modules are planned to bedeveloped in the medium term, the approachpresented enables the maximum benefits to be

obtained from those aspects of the IMA conceptswhich are the most advanced, while exploiting theavailability of today's COTS hardware. This approachis embodied in the Mission Management System,which is under development at ESG.

The Mission Management System is a computer-based system which is intended to host advancedmission management applications focussed on crewassistance functions, including mission planning andterrain-based display. The hardware of the MissionManagement System comprises a single unit, theMission Management Computer. The system, and inparticular its software structure and systemmanagement functions, are based on the IMAconcepts developed in the ASAAC (AlliedStandardised Avionics Architecture Council)programme, which are applied here to the extent thatthey are compatible with the available COTScomponents. The Mission Management Systemimplements those elements of the ASAAC IMAconcepts that are most suitable for near-termadoption, and in particular those related to thesoftware structure, which is based on the use of aCOTS Real-Time Operating System.In implementing the IMA concepts from ASAAC, the

Mission Management System is designed around anopen system architecture, using COTS hardware andsoftware components. This approach providestechnology transparency, and supports the substitutionof system components, such as the replacement of system hardware or the Real-Time Operating Systemimplementation, to mitigate the effects of hardwareand software component obsolescence.The paper first presents the approach adopted intransitioning towards the IMA architecture via the useof current-day COTS components. The MissionManagement System is then described from thesystem architecture, software architecture andhardware architecture points of view, noting theimplementation constraints of current COTS

components. The system characteristics which areachieved through the adoption of the relevant IMAprinciples together with open systems and COTSpractices are presented.The mission management functions to beimplemented on the system are defined, and anexample is then presented of a complete avionicssystem built using the transitional technology of theMission Management System in a number of

Integrated Computers to provide a completecomputing core.

Some certification issues are discussed, and theadoption of an incremental certification approach isrecommended. A path forward towards thedevelopment of a true IMA system implementation isproposed, including further development of theMission Management System, and the migration to amodular implementation.

2 INTRODUCTIONIntegrated Modular Avionic concepts for militaryaircraft have been developed under a number of national [Ref. 1] and international projects, the latterincluding in particular the completed EuropeanEUCLID RTP 4.1 programme [Ref. 2], and the keyASAAC programme [Ref. 3, Ref. 4, Ref. 5].The IMA concepts developed, and particularly thoseof the ASAAC programme, are based on theprinciples of modular systems, open systems andCOTS. In an IMA architecture, the computingcapacity is concentrated into a 'Core', which consistsof interchangeable processing modules of a limitednumber of standardised types, particularly for data,signal and graphics processing. IMA systems provide

a high level of technology transparency by beingbased on a set of open standardised interfaces, sofacilitating the replacement of hardware componentswithout affecting the application software. Inaddition, the use of open standardised interfacesdirectly supports the use of COTS components, whichis of great benefit in combating the effects of component obsolescence. IMA systems alsoimplement fault tolerance, so that when a modulebecomes defective, the system reconfigures and aspare module takes over the functionality of the failedmodule. The IMA concepts developed in the ASAACprogramme have been adopted as the basis for the

Mission Management System reported on in thispaper.

Paper presented at the RTO SCI Symposium on Strategies to Mitigate Obsolescence in Defense SystemsUsing Commercial Components, held in Budapest, Hungary, 23-25 October 2000, and published in RTO MP-072.

8/7/2019 MP-072-15

2/12

15-2

The development of the required set of ASAAC IMAhardware modules will be a substantial task, and itscompletion lies some way off in the future. Evengiven the availability of hardware modules, a veryconsiderable certification effort will be required toqualify an ASAAC IMA-based system, particularly

due to the system-wide configurability under softwarecontrol it exhibits.It is, however, possible to exploit the elements of theASAAC IMA system, software and hardwareconcepts which will have been developed before sucha stage is reached, while using the COTS-basedboard-level hardware components available today.Such advanced IMA concepts may be implemented insystems without expending significant additionaleffort in comparison with a more conventionallybased solution. In this way a significant number of thebenefits promised by the IMA architecture may beachieved today: a key example is the use of technology transparency to combat obsolescence.

A transitional step towards the implementation of thetrue IMA architecture is therefore now being takenwith the development of a Mission ManagementSystem. In defining the Mission Management System,the aim has been to define a demonstrator which willallow the implementation of a representative set of application functions, using an architecture based onthe IMA architecture of ASAAC. This will permitprogress to be made towards the implementation andcertification of an IMA-based avionics system, bygaining experience in the implementation of an

ASAAC IMA-based software structure, andevaluating the consequences of hosting applicationson such a structure.

The Mission Management System is designed toexploit: The ASAAC IMA concepts:

Currently available elements of the ASAAC IMAconcepts have been realised.

Open system architectures:In accordance with the principle of offering anopen architecture, open standards have beenadopted. The use of an open architecture supports

especially technology transparency, applicationportability and system scalability.

Available COTS hardware and softwaretechnology:Extensive use is made in the Mission ManagementSystem of COTS components, both hardware andsoftware. The use of COTS supports particularlythe lowering of system costs and reduction of development time.

By the adoption of these concepts in the MissionManagement System, it is aimed to achieve thefollowing characteristics typical of IMA systems:

Application Portability:The portability of application functions betweenhardware platforms is supported in turn bytechnology transparency.

Technology Transparency:Technology transparency embraces hardwareindependence, which supports hardwarereplacement for future system upgrading and tocounter component obsolescence, network independence, which enables the network technology to be upgraded, and also extends to thesoftware technology.

Scalability:Scalability supports the application to avionicsystems of different sizes and roles, as well asfuture avionic system growth. The scalabilitycharacteristic is in turn supported by technologytransparency, in particular by hardware and

network independence. System Reconfigurability:

By reconfiguring the system depending on thesystem mode, the total resource requirements of the system may be reduced. Reconfigurability maybe used on the occurrence of faults to support faulttolerance.

Fault Tolerance:Fault tolerance may be used to improve systemreliability, and is supported in turn by systemreconfigurability.

3 SYSTEM ARCHITECTURAL CONCEPT

3.1 Key ConceptsThe architecture of the Mission Management System(MMS) is a transitional architecture between that of the current generation of federated architectures, andfuture IMA architectures. It is designed to becompatible with the avionics system architectures of both new-build aircraft designs and retrofitapplications.

The architecture defined for the MMS utilises theelements of the ASAAC concepts which are the mostadvanced, but which are also compatible with

conventional federated avionics systems. The aspectsof the ASAAC concepts which have been adopted liemainly in the Software Architecture and SystemManagement areas, although some aspects of thehardware concepts have also been employed. Thefollowing key concepts have been applied: Use of a standardised interface between

Application Software and the Operating SystemLayer.

Hardware abstraction by software. Use of a system management structure and

'Blueprints' which together support systemconfiguration and reconfiguration.

8/7/2019 MP-072-15

3/12

15-3

Use of a standardised software interface for alldata communication.

Due to the requirement to be able to integrate theMMS within a conventional federated avionicssystem, the aspects of the ASAAC IMA conceptswhich extend throughout the entire avionics systemhave necessarily found only partial application. Theseinclude for instance the system health andconfiguration management concepts.

3.2 Open ArchitectureOpen architectures are characterised by the use of widely accepted and supported standards set byrecognised standards organisation or the commercialmarket place. As the standards are available to all, asystem based on an open architecture is open to theincorporation of components from potentially anysource. The IMA architecture defined in ASAAC issuch an open architecture, as it both defines its ownopen standards, and supports the use of available openstandards in its implementation.

An ASAAC IMA system may be regarded ascomprising a set of application functions hosted on anopen architecture platform. The applications are notdependent on the underlying technology andhardware, as the interface between the applicationsand the system functions is established as an openstandard, so allowing different manufacturers of software and hardware components to contribute tothe system.

A common example of an open architecture in thecommercial world is the POSIX system [Ref. 6],which allows Unix systems and applications to bedeveloped independently of the underlying hardware,regardless of the hardware manufacturer. WhilePOSIX is unsuitable for an IMA System, whichrequires fully predictable real-time behaviour of itscomponents, applications in ASAAC IMA systemsare hosted on an open platform with an openinterface, the Application to Operating System layer(APOS) interface (see Sec. 4.3).

3.3 Modes and ConfigurationsIn the MMS, the various mission managementfunctions are each only required to operate during therelevant phases of the aircraft's mission. For example,different mission planning functions are likely to beapplicable to different mission phases, and displayfunctions for high-altitude combat air patrol woulddiffer from those for low-level target ingress.

In order to optimise the utilisation of the hardwareresources in the MMS, and so reduce the total systemresource requirements, the same hardware in theMMS will be used to host different applicationfunctions at different times, according to therequirements of the mission phase.

Because of the strict separation of applicationfunction design from the system hardware design, it ispossible for the MMS application functions to be

distributed over the hardware in a number of differentways, and hence for an application to be easilytransferred from one processor to another.

At the transition from one mission phase to anotherthe MMS will be reconfigured by halting andremoving the relevant software components from theprocessors, and loading and starting new componentsfrom the Mass Memory Unit.A set of MMS modes is defined to cover the variousphases of the mission, where a specific set of functions runs in each mode. Within each mode, anumber of different configurations of the functions onthe various hardware resources may also be possible.

3.4 Fault ToleranceASAAC IMA systems offer fault tolerance byreconfiguring on the occurrence of faults. A newmodule may be substituted for a faulty module, and

the application functions reconfigured accordingly.The fault tolerance concept of the MMS is derivedfrom that of ASAAC IMA systems.

It is not possible to implement the same degree of redundancy in the MMS as in the ASAAC IMAconcept, as the latter relies on full hardwareredundancy between modules. The components of theMMS, on the other hand, are integrated with oneanother at a lower level: powering on and off individual hardware components is not supportedwithin the MMS, for instance.

The MMS implements a limited degree of faulttolerance. Some redundancy is likely to be availablebetween the multiple instances of the varioushardware components, such as the Single BoardComputers (SBCs) which are used within the MMS.Where such redundant capacity is available, when acomponent becomes defective, the system isreconfigured so that a spare component takes over thefunctionality of the failed one. Alternatively, whereno extra resources are available, non-critical functionsmay be dropped, to free resources for higher priorityfunctions, or reversionary implementations of functions, with lower resource requirements, may beused. In this way, a significantly greater faulttolerance capability is achieved than withconventional systems.

3.5 System ManagementASAAC IMA systems implement a standardisedsystem management structure that is responsible forperforming the following major functions: Initialisation and shutdown management. Configuration management, including

reconfiguration on mission mode transitions andon faults.

Fault management, including health managementsuch as the processing of Built-In Test (BIT)data.

8/7/2019 MP-072-15

4/12

15-4

For the Mission Management System, elements of theASAAC IMA system management have been adoptedas appropriate. Whereas the ASAAC systemmanagement concepts, such as for instance healthmanagement and configuration management,generally encompass the entire avionics system, it has

only been possible to implement these within thescope of the MMS.One of the prime responsibilities of systemmanagement is managing the control of theapplication functions, which includes theirinstantiation, start, suspension and removal from thesystem. System management is also responsible forconfiguring communications between applications,which is performed in a similar manner to the processscheduling, in order to guarantee predictablecommunications.

The system management functions manage the system

in accordance with the blueprints. The blueprintsprovide the definition of the system resources, anddefine the possible configurations of the system. Theconfigurations are deterministic, and are defined atdesign time: such strict system control will benecessary in order to certify the system. As well as theconfigurations themselves, the blueprints also definethe reconfiguration processes which are carried out onthe occurrence of faults.

System management in the ASAAC IMA concept isperformed throughout the avionics system on ahierarchical basis. In the MMS, system managementis performed at two levels. The top-level manager is

the System Manager, and this controls the ResourceManager, which manages a particular single boardcomputer hosting a number of application functions.Figure 1 shows the MMS system managementhierarchy.

SM -MM S

RM -CU

I/O G1 G2

RM -GP U

D1 D2

RM -DPU1

D3 D5

RM -DPU2

D4

SM System Manager RM Resource ManagerCU Communications Unit DPU Data Processing UnitGPU Graphics Processing Unit I/O Input / OutputD1-Dn Data Processing Processes G1-Gn Graphics Processing Processes

Figure 1: System Management Hierarchy

The MMS system management differs from that of the ASAAC concepts primarily as follows: The system manager hierarchy is limited to two

levels.

Fault detection is dependent on the capabilities of the COTS components.

Only limited reconfiguration is supported,particularly for fault tolerance.

The ASAAC System Management Blueprint(SMBP) interface between the GSM and theblueprint data is not implemented.

The system management functions are implementedby the software of the Generic System Management(GSM: see Sec. 4) together with the blueprint data,which are provided as part of the software load.

4 SOFTWARE ARCHITECTURE

4.1 The ASAAC Software ArchitectureThe software architecture of the Mission ManagementSystem is based on the ASAAC software architecture,modified to suit the COTS-based hardwarearchitecture of the MMS.

Application Layer

OS Extensions

Management

Communications

Time

RTOS

Thread Services

Virtual Memory

Communications

Synchronisation

Time

Generic SystemManagement

Operating System

HealthManagement

FaultManagement

ConfigurationManagement

SecurityManagement

SystemBlueprints(Run-time)

Operating System Layer

MemoryResources

TimerResources

CommsResources

InterruptResources

BITResources

BootLoader

Module Support Layer

APOS

MOS

P roc es s P roc es s P ro ces s

System Management

APOS

ApplicationBlueprints(Design)

Process Process Process

ResourceBlueprints(Design)

SystemBlueprints(Design)

SMOS SMBP

APOS Application to Operating System Layer InterfaceBIT Buil t-In TestMOS Module Support Layer to Operating System InterfaceOS Operating SystemRTOS Real-Time Operating SystemSMBP System Management Blueprint InterfaceSMOS System Management to Operating System Interface

Figure 2: The ASAAC Software Architecture

The main components of the ASAAC softwarearchitecture are the Application Functions, theOperating System (OS), the Generic SystemManagement (GSM) and the Runtime Blueprintrepresentation (RTBP), as depicted in Figure 2. TheGSM defines and manages the processing andcommunication resources required by the application,and the operating system provides the applicationwith access to these resources. The blueprints providethe definition of the resources and of the possiblesystem configurations. The GSM and the runtimeblueprints are associated with both the systemhardware and the application-independent operating

system layer.

8/7/2019 MP-072-15

5/12

15-5

This architecture is based on the principle of a three-layer software stack, where the layers have thefollowing properties: Application Layer

Application Dependent, Hardware Independent

Operating System Layer Application Independent, Hardware Independent Module Support Layer

Application Independent, Hardware Dependent.

This architecture as implemented in the MMS isillustrated by Figure 3.

BSP OS Drivers

TCManager

COTS OS Communi-cation

Services

NII

Board dependent

Processor dependent Network

dependent

OS Extension

MMSAppli-cation

Process

SystemManager Resource

Manager

SMOSAPOS

Hardware independent

Hardware Abstraction

BLUEPRINTS

APOS Application to Operating System InterfaceBSP Board Support PackageNII Network Independent InterfaceOS Operati ng SystemSMOS System Management to Operating System InterfaceTC Transfer Connect ion

Figure 3: Design of the MMS Software Stack

In this design, the ASAAC software architecture hasbeen adapted to the requirements and constraints of acomputer architecture based on COTS VME hardwareand a COTS real-time operating system: There is no Module Support Layer: hardware

abstraction is achieved by the architecture of the

real-time operating system. The GSM function is simplified into two kinds of

management functions, a top level SystemManager, which controls the overall computer,and a Resource Manager for every single boardcomputer, which controls the board localresources.

4.2 Hardware AbstractionA prime property of the ASAAC softwarearchitecture is the independence of the applicationsoftware from the hardware, as the highest costs thatarise in the replacement of obsolete hardware areincurred in the consequential adaptation of theapplication software.

In the ASAAC software architecture, a hardwareabstraction layer is provided in the form of theModule Support Layer (MSL). This hardwareabstraction provides the system with hardwareindependence: the higher software layers areindependent from the hardware details, so that

hardware changes do not affect either the operatingsystem layer or the application layer software, socountering the effects of component obsolescence. Inthe Mission Management Computer, this architecturehas been adapted to the architecture of a COTS real-time operating system. This adaptation provides thesame hardware abstraction characteristics as specifiedfor the Module Support Layer.

This hardware independence is provided at the levelof source code compatibility, as binary compatibilitywould require a much higher degree of standardisation. Standardisation down to the level of binary compatibility has to be very detailed, and istherefore very restrictive, so limiting the openness of the architecture. Source code compatibility appearsfor this reason to be the appropriate choice.In addition to the issue of source code compatibility,hardware modifications are likely to result in changesin the resource characteristics of the hardware, suchas enhancements to the processing power orcommunication capacity, which would affect thesystem operation. This issue is addressed byseparating the configuration data from the systemmanagement functions, and encapsulating it in theform of blueprints. A change of hardware or the

porting of an application to another system wouldtherefore only require the adaptation of the blueprintsand the recompilation of the relevant software,including the operating system layer and applicationcode.

4.3 The Operating System LayerThe Operating System Layer includes the OperatingSystem itself, together with the system managementcomponents, ie. the system managers and the run-timerepresentation of the systems blueprints.

One of the chief benefits from the use of the ASAACsoftware architecture for the Mission ManagementSystem is application portability, which supports thereuse of the application software. Applicationportability is provided primarily by the use of astandardised Application to Operating System(APOS) layer interface. As it is the only interface of the ASAAC software architecture visible to theapplication, the application is dependent only on thisinterface for the satisfaction of its processing andcommunication resource requirements. As theMission Management System offers the same APOSas any ASAAC system, the mission managementapplications are therefore portable to other systemsbuilt using the ASAAC standards.A COTS real-time operating system is used as thecore of the operating system layer. In comparison

8/7/2019 MP-072-15

6/12

15-6

with the alternative approach, which is thedevelopment of a bespoke operating system, theCOTS approach exhibits greater flexibility and costefficiency due to the commercial support provided forthe adaptation to new hardware components. The useof a COTS operating system supports the efficient

implementation of the operating system layer on theunderlying COTS hardware, both for the MMShardware, and for ASAAC IMA systems. A COTSReal-Time Operating System is therefore well suitedto support the transition from the federated systemarchitecture of the MMS to an IMA system, providinga stable Application Programming Interface togetherwith off-the-shelf compatibility with COTS hardware.

The COTS operating system is complemented in theoperating system layer by additional software whichprovides the adaptation to the ASAAC operatingsystem interfaces, and in particular to the APOS.

4.4 Application Function Software StructureThe application process is the basic software elementof an application function, and represents theconfiguration unit of a system. Each applicationprocess depends on processing and communicationresources, namely on threads and virtual channels,and can only be executed when the systemmanagement function provides its required processingand communication resources.

In the Mission Management System, three differentkinds of application processes have to beaccommodated: data processing processes, graphics

processes and mass memory -related processes. Thelast of these includes such processes as databaseapplications, and is implemented in the form of fileaccess functions. While data processing and massmemory applications may be freely located on anyprocessor, graphics processing is restricted to thespecific hardware capable of providing the OpenGLinterface and functionality.

The mission management application is built from anumber of small but simple processes, most of whichcontain only a single thread, and which are configuredin accordance with the currently active mission mode.Each of these processes depends on both transientdata and persistent information: the transient data isprovided via the MMS interface, and the persistentinformation from a central database, which isrepresented by an application process that providesinformation on request.

4.5 Properties of the Software ArchitectureThe software architecture of the MMS offers anumber of beneficial properties in comparison withconventional systems.

Application portability and technology transparencyare both provided by the use of the APOS as a

standardised interface between the applicationsoftware and the operating system layer. This permitsthe reuse of the application software on other systems

offering the ASAAC APOS interface, and also thereplacement of the MMS hardware withoutmodification of the application software source code.Performing the application design independently of the underlying hardware is also supported.In addition, hardware abstraction below the level of the APOS provides protection against componentobsolescence, by supporting hardware independence.Technology transparency in the MMS also extends tosoftware technologies: as the APOS is independent of the underlying COTS OS used, the COTS OS mayalso be replaced without affecting the applicationfunctions.

The GSM and blueprints support the ability toreconfigure the system in accordance with the missionrequirements, so providing for efficient hardware use,and also supporting fault tolerance, which contributesto improved system reliability.

The open standards used include the open commercialstandard OpenGL, and the ASAAC standards. COTScomponents used include the COTS operating system,together with its board support packages and drivers.

Due to the intention to maximise the use of COTScomponents in the development of ASAAC modules,the approach adopted for the Mission ManagementComputer of employing the ASAAC software stack with a COTS operating system is likely to remaineffective throughout the continuing transition fromtoday s federated system architecture to tomorrow sIMA architectures.

5 HARDWARE ARCHITECTURE

5.1 The Mission Management ComputerWhile current work is focussed on the softwarestructure, using laboratory development hardware, theMission Management Computer (MMC), whichwould form the hardware of the Mission ManagementSystem in a real aircraft application, and on which theapplication functions would run, has also beendefined.In an avionics system application, the MissionManagement System would be integrated with and

exchange data with other avionics system computersand peripheral devices, including sensors, effectorsand displays and controls: a possible systemimplementation is shown in Sec. 7.

In order for the MMS to be able to perform therequired application functions, the MMC mustsupport the relevant low-level functions, whichinclude data processing, graphic display processing,provision of mass memory, and communication. TheMMC has been defined for hosting the MMSfunctions discussed in Sec. 6.

5.2 Structure and PackagingThe packaging concept of the MMC differsconsiderably from that of IMA systems. Whereas in

8/7/2019 MP-072-15

7/12

15-7

an IMA system, the line-replaceable items are theindividual modules, the MMC is, in line withcontemporary avionic systems, itself the line-replaceable item.

The basic principle behind the construction of theMMC is the exploitation of available COTScomponents, and in particular the use of VME boards.This enables the demonstrator to be built usingstandard commercial grade racks and boards, and aruggedised version suitable for service use to beproduced using components qualified to theappropriate environmental standards. In an aircraftapplication, the MMC would take the form of astandard ATR format unit, which would be mountedon an ATR rack in the avionics bay.While the application of the IMA hardware conceptsto the MMS is limited by the use of pure COTShardware for the MMC, the hardware structure of the

MMC has been influenced by the ASAAC conceptswhere possible, in order to support the ASAACsoftware and system architecture concepts employed,and to support the future development path towardsan IMA system.

The structure of the MMC therefore conforms withthe ASAAC concepts in the segregation of the dataprocessing, graphics processing and mass-memorycapabilities. Areas in which the structure of the MMCdiverges from the ASAAC structure include theseparation of the external communications interfacefrom the processing capacity, and the lack of aModule Support Unit local to each of the processors.

Power-Up and Continual Built-In Test areimplemented to the degree that these are supported bythe COTS hardware.The structure of the MMC is shown in Figure 4below, and discussed in the following text. The MMCis constructed using 64-bit VME boards: whererequired, for instance for communications, PMCmodules are mounted on the VME cards.

Mission Management Computer

VME Backplane

C U

1553 FC

G PU

G P G PGP

M M UDP U

DPU Data Process ing Unit s 1 -3 GPU Graphics Processing UnitGP Graphics Processor MMU Mass Memory UnitCU Communications Unit 1553 Mil Std 1553BFC Fibre Channel

Figure 4: The Mission Management Computer

5.3 Hardware ComponentsThe MMC consists of four main types of VME-buscomponent:

Data Processing Unit Graphics Processing Unit Mass Memory Unit Communications Unit.The data processing hardware comprises three DataProcessing Units, each taking the form of a PowerPCSingle Board Computer (SBC).The graphic display processing implements threegraphics processing channels, and so provides thecapability of driving three displays with separateformats. The graphics processing hardware comprisesa Graphics Processing Unit, consisting of three 3Dgraphics PMCs supporting OpenGL, mounted on aPowerPC SBC. Each graphics processor PMCprovides the following key features: OpenGL implementation 1024 x 1024 resolution 1 M three-dimensional-polygons / sec.The Mass Memory Unit is implemented as a solidstate memory or hard disk interfaced with a PowerPCSBC.

The Communications Unit consists of the relevantnetwork interfaces implemented as PMC modulesmounted on a PowerPC SBC: in addition, analogueand discrete input / output is provided for as required.

5.4 Data CommunicationsAll data communication within the MMS betweenprocessor boards and between the MMS and externalequipment takes place via a standardised softwarenetwork interface, termed the Network IndependentInterface (NII), which has been derived as part of theASAAC concepts. Data transfer takes place throughthe NII via a Transfer Connection (TC), which acts asa virtual channel, and which is established explicitlyprior to the data transfer.

The use of the Network Independent Interfaceprovides the ability to change the network technologyused, for instance when reconfiguring the system andre-routing a particular transfer from an MMS-internaltransfer to an external transfer. The network technology used for external transfers might also beupgraded as part of a future system improvement.Communications within the MMC takes place usingthe buses available with the COTS boards, such as theVME and PCI buses.The network technology used for externalcommunication depends on the particular avionicssystem implementation into which the MMS isintegrated: options range from the conventional Mil-Std 1553 command / response bus or ARINC 429 datadistribution bus, to a high-capacity optical serialCOTS Fibre Channel network.

8/7/2019 MP-072-15

8/12

15-8

5.5 Properties of the Hardware ArchitectureThe hardware architecture of the MMS offers anumber of beneficial properties in comparison withconventional systems.Technology transparency is supported by the Network Independent Interface, which provides for thereplacement of the network technologies used whilemaintaining the software interface to the network, soallowing for data transfer growth.

Support is provided for scalability and system growth,particularly by the use of an open COTS-basedarchitecture. The MMC is capable of being extendedto cater for the addition of further MMS functionality,should this be required for a particular systemapplication. Further data processing SBCs may beadded to provide the required capacity, and thenumber of graphics processing PMCs may be chosento feed the number of displays required. Hardware

components of the computer may be replaced,providing that the availability of the relevant COTSoperating system, board support package and driversis assured.

Within the MMC, a limited degree of interchangeability between components could beoffered by the use of a number of identical VMESBCs and PMC modules.Open standards used in the MMC include opencommercial standards as ATR, VME64, PCI, PMCand Fibre Channel, open military standards such asMil-Std-1553B, and the ASAAC standards.

Use is made of Commercial (COTS) and MilitaryOff-The-Shelf (MOTS) components as follows: SBCs, PMCs: COTS boards, using commercial

chip-level components. Network: COTS, MOTS.

6 MMS FUNCTIONALITY

6.1 Generic Mission Management FunctionsThe possible system applications of a MissionManagement System extend across a range of aircraftroles, from combat aircraft, including rotary wingtypes, to heavier patrol and transport aircraft. The

specific functions implemented on the MissionManagement System in a particular avionics systemimplementation would depend on the role of theaircraft and the allocation of functionality within thecomplete avionics system.Typical mission management functions include thefollowing: Situation Assessment Conflict Management Mission Planning Man-Machine Interface Navigation Flight Guidance.

The functional structure of a Mission ManagementSystem is shown in Figure 5 below.

Tactical Mission Ma nagement

M i s s

i o n

D a

t a B a s e

A/C

Sensors / Com munication / D ata-Link

Cockpit P i lo t

Data Management

FlightSituationAnalysis

Tact icalSituationAnalysis

ConflictDetect ion

andResolution

MissionPlanner

Man-Machine-Interface

Figure 5: Functional Components of a MissionManagement System

6.2 Functions SelectedFor the Mission Management System underdevelopment, a representative set of functions whichis broadly aimed at a multi-role fighter application hasbeen chosen.

The primary functions selected are mission planning,representing a high-performance data processingapplication, and the production and presentation of perspective flight guidance information, a three-dimensional graphic application.

These functions are based on those underdevelopment in parallel activities being performed atESG, as previously reported [Ref. 7], and are now tobe ported to the Mission Management Computer fromtheir original implementations on a laboratoryworkstation-based environment.To provide the required functionality, the MissionManagement System will comprise the followingfunctional components: Databases:

Terrain Database Navigation Database

Functional components: Threat Analysis Mission Planner, including:

- Transit Planner- Low-Level Flight Planner- Attack Planner

Graphics processing: Head-Up Display with Terrain Graphics Head-Down Display with Synthetic Vision Tactical Navigation Display.

External inputs received by the MMS from otheravionics system components include: Aircraft Data (eg. Position, Velocity, etc.) Sensor Data (eg. Threat warnings, Datalink).

Details of the functions have been given previously in[Ref. 7].

8/7/2019 MP-072-15

9/12

15-9

The functional structure of the system has beendesigned to accommodate the addition of furtherfunctional components as and when required,depending on the requirements of the anticipatedapplication avionics system.

7 AVIONICS SYSTEM ARCHITECTURE7.1 Architectural ConceptsThis section addresses the system architecture of anavionics system into which the Mission ManagementSystem might be integrated. The system exampledescribed here is a near-term new system design,again based on a multi-role fighter application.

The proposed system architecture is based on the useof Integrated Computers, of which the MissionManagement Computer is an example, each based onthe same system, software and hardware architecturesas described for the MMS above.The avionics system structure remains essentially afederated architecture. As in conventional federatedsystems, the overall avionics system is divided into anumber of dedicated systems / sub-systems, eg.Mission Management System, Stores ManagementSystem. The overall system consists of a number of Integrated Computers, together with essentially thesame dedicated equipment found in conventionalfederated systems, eg. Radar, Radio, Displays andControls.The computing capacity of the avionics system isdistributed between the Integrated Computers, which

are interconnected via the communication network. Incomparison with other federated architectures, theIntegrated Computer-based architecture ischaracterised by the centralisation of the processingcapacity in a smaller number of higher-capacityprocessors.

Most of the processing of the sensor data, includingthe signal processing, takes place in the sensorequipment itself, whereas the subsequent system-leveldata processing of the sensor data is performed in theIntegrated Computers. The degree to which the sensordata processing is implemented in the IntegratedComputers depends on the capability provided by theparticular sensors themselves.System management, embracing moding,configuration management and fault tolerance, wouldinitially remain implemented largely at the level of the Integrated Computers, rather than being integratedat an aircraft level, as with an ASAAC IMA system.However, for critical functions additionalreversionary implementations with reducedcapabilities could be hosted on alternative computers.

7.2 System StructureFour Integrated Computers form the core of the

avionics system, connected with the peripheralequipment, including sensors and effectors, and

displays and controls, and also the safety-criticalStores Management System.The Integrated Computers perform the followingroles: Interface and Monitoring Processor

Mission Management System Communications Processor Defence, Attack and Armament Computer.The structure of the avionics system is shown inFigure 6 below. The equipment shown in grey isexternal to the avionics system.

Displaysan d

Controls

MissionManagement

Computer

Interface andMonitoringProcessor

Communi-cations

Processor

Flight ControlSystem

UtilitiesControlSystem

Defence,Attack andArmamentComputer

StoresManagement

System

NavigationSensors

ElectronicW arfareSensors

Electro-Optical

Sensors

RadarSensors

Communi-cation

Sensors

Figure 6: Example Avionics System Structure

Due to the high level of integration within theIntegrated Computers, the data transfer loadingbetween the individual equipment remains relatively

moderate. Data transfer between equipment takesplace either as in a conventional system via aCommand / Response or Data Distribution Bus (eg.Mil-Std 1553 or ARINC 429), or by the use of asupplementary Fibre Channel overlay network, whichis indicated by the broad lines in Figure 6. The latterprovides for higher data rates between particularequipment, where these are required, for instancebetween the integrated computers, and for video data.

Interchangeability between the various IntegratedComputers could be provided by the use of multipleinstances of the same computer design. This should inprinciple be possible, due to the similarity of therequirements for the various system computers.

8 THE PATH FORWARD TOWARDS IMA

8.1 Further Development of the MMSThe Mission Management System defined in thispaper represents a significant step towardsimplementing an ASAAC IMA architecture, a goalwhich is to be achieved with the introduction of theIMA hardware modules. There would, however, be anumber of potential advantages in further developingthe MMS concept by adding additional IMA featuresbefore progressing to a definitive IMA system:

8/7/2019 MP-072-15

10/12

15-10

Multiple instances of Integrated Computerssimilar to the Mission Management System couldbe integrated in an avionics system, as shown inSec. 7. The implementation of the ASAACsystem management concept could be extendedincrementally to encompass system-level

management, so that such functions asinitialisation and reconfiguration would beperformed on a system-wide basis.

A form of design-time blueprints could beimplemented, containing resource requirementsand specifications, to provide system designsupport.

When available, the ASAAC network technologycould be introduced, to provide the required highcapacity, real-time deterministic behaviour, andnetwork redundancy.

Signal processing capability might also be addedto the MMC, following the IMA strategy of centralising processing in the core.

8.2 Migration to an IMA ImplementationThe eventual implementation of a system withASAAC IMA modules will result in fundamentalefficiency advantages for system development andoperation, due to the use of a standardised,interchangeable hardware set.

The example system implementation presented in Sec.7, based on the use of four Integrated Computers,represents an architecture which could be migrated toa full ASAAC IMA architecture, by the replacement

of each of the Integrated Computers by an IMAIntegration Area.

The use of individual modules will improve thehardware efficiency of reliable system designs, bypermitting system reconfigurability at the modulelevel. This represents a significant improvement,when compared with non-modular equipment such asthe MMC, which is integrated as a complete unit, andwhich is therefore potentially susceptible to singlepoint failures.

8.3 IMA Certification ConsiderationsSystems such as the Mission Management Computerthat are based on IMA principles introduce a numberof new factors, including in particular theirreconfigurability, which are likely to affect theircertification.With traditional systems, certification has beenachieved for the complete system, including both itshardware and its software. Some systems haveimplemented a degree of reconfiguration, but with arelatively restricted number of configuration cases, allof which have usually been designed into the systemtogether with the hardware and application software,with the system being certified as a whole.

In contrast, in the ASAAC IMA system, and in theMMS, the hardware, operating system layer softwareand application functions are to be developed

separately, with well-defined interfaces, andconfigurations determined for the integrated system.The system configurations of the MMS aredeterministic, in that all possible configurations aredetermined at design time, and stored in theblueprints. The total number of system configurationsmay however be very high, as the overall systemconfiguration is made up of all the individualprocessor configurations, and as the processors areconfigurable at the level of individual processes.

While it will be necessary to certify each systemconfiguration, it will not be practical to verify indetail the complete correct operation of an integratedASAAC IMA system in all possible modes. Thisleads to the proposal to adopt a new approach andperform certification incrementally using acomponent-based method, as discussed below.

8.4 Incremental CertificationThe basic principle of the incremental certificationapproach is to be able to modify a certified system,and to achieve certification for the modified systemby certifying only the changes, without having torepeat the full certification process anew on themodified system in its entirety.

In order to be able to perform incrementalcertification, it is necessary to constrain, and to beable to identify, the effects of the modifications on theoriginal certified system. In this way, the certificationprocess for the modified system may be concentratedon the changes introduced and their resultingconsequences.Incremental certification can be applied to thedevelopment of completely new systems, byperforming certification of the system at variousstages in its development, as well as to themodification of in-service systems: the incrementalcertification approach is particularly applicable to theaddition of application functions to an existingsystem.The principle of incremental certification may befurther developed to include component-basedcertification. Here, the basic principle is that each

component is certified in its own right, so that when asystem is assembled out of a number of components,it is then just the integration of the components whichneeds to be certified.

8.5 MMS Incremental CertificationIt is proposed to adopt a component-basedincremental certification approach for the MissionManagement System. The main characteristics of theMission Management System which supportincremental certification are application portabilitytogether with the related technology transparency.These characteristics are derived primarily from the

use of the APOS, the Application to OperatingSystem layer interface. Due to the definition andstandardisation of this interface, the Application

8/7/2019 MP-072-15

11/12

15-11

Functions are decoupled from the underlyingoperating system, hardware and drivers, which in turnenables the certification of the components either sideof the APOS to be decoupled.

The adoption of incremental certification will requirethe development of an appropriate certificationprocess by the certification authorities, and it isproposed that the MMS be used as a vehicle fordevelopment work on such a process.

When applying the principles of component-basedincremental certification to the development of theMMS, there are a number of steps which may betaken to ease its certification.

Firstly, the application functions, in particular for thefirst MMS implementation, should be of a lowcriticality. In view of this, those that have beenselected for the MMS are non- safety-critical, and donot require fail-safe implementation due to reliability

considerations.Further, due to the concerns regarding thecertification of reconfigurable systems discussedabove, it might be advisable to limit the scope of thereconfiguration mechanisms implemented in theMMS, in order to ease the first certification. Onepotential measure would be to limit the configurationsto a small number, so that each reconfiguration stepcould be examined in detail. A further measure wouldbe to exclude all fault-triggered reconfiguration,leaving only reconfiguration on mission modechanges. Once initial certification was obtained, thescope of the reconfiguration could be successivelyextended.

9 CONCLUSIONSThe Mission Management System described in thispaper and being prototyped at ESG has been seen tofeature an effective IMA-derived architecture, and tooffer a representative set of mission managementfunctions.

Through the adoption of the IMA principles from theASAAC programme, and their implementation usingCOTS components on the basis of an open systemarchitecture, the Mission Management System is able

to offer the following key characteristics: Application portability is achieved by the

application functions use of the APOS interface. Hardware independence is provided by hardware

abstraction, and provides protection againstcomponent obsolescence.

Reduced development time and lower costs aresupported by the use of COTS components andmethods.

A number of further valuable properties are alsorealised: System reconfigurability is provided by the

system management function and blueprint data,and supports the optimisation of the use of thehardware resources.

Fault tolerance is achieved by means of systemreconfigurability, and improves systemreliability.

System growth and the ability to apply the systemto aircraft for a wide range of roles are supportedby the use of an open system architecture.

Network independence is provided by the use of the NII, and permits the upgrading of the network technology.

Software technology transparency is supportedby the standardisation of the APOS interface tothe operating system at a level above the

underlying COTS operating system.The development of the Mission Management Systemas a transitional architecture implementing missionmanagement functions should achieve a major steptowards the implementation of IMA systems, andprovide valuable experience for their consequentimplementation and certification. In accordance withthe proposed incremental certification approach, theMission Management System is open to progressivedevelopment to incorporate further aspects of theASAAC IMA concepts, so supporting the eventualmigration to a true IMA system.

In conclusion, it is hoped that development of systemsbased on transitional architectures, and particularlythe Mission Management System presented in thispaper, will significantly ease the introduction of Integrated Modular Avionic systems.

8/7/2019 MP-072-15

12/12

15-12

10 REFERENCESRef. 1 Integrated Modular Avionics Architecture

Concepts Demonstration, BDir J. Potthaus,Dr. W. Kl ckner, I. Sprang, C.G. White,NATO AGARD Mission Systems PanelSymposium, Istanbul, Oct. 1996.

Ref. 2 Modular Avionic System ArchitectureDefinition in the EUCLID R&T Programme4.1, A. Marchetto, NATO AGARD MissionSystems Panel Symposium, Istanbul, Oct.1996.

Ref. 3 ASAAC Phase II Programme Progress on theDefinition of Standards for the CoreProcessing Architecture of Future MilitaryAircraft, G. Multedo, D. Jibb, Dr. G. Angel,ERA Avionics Conference, London, Nov.1998.

Ref. 4 Modular Avionics: The future of GreatWeapon Systems, W. Br hmann, D. Shealey,NATO RTA System Concepts andIntegration Panel Symposium, Florence, Sep.1999.

Ref. 5 Avionics Architecture Standards as anApproach to Obsolescence Management,D.J. Jibb, J.B. Walker, NATO RTA SystemConcepts and Integration Panel Symposium,Budapest, Oct. 2000.

Ref. 6 POSIX Standard, IEEE Std. 1003.

Ref. 7 Cognitive Concepts for Tactical MissionManagement, Dr. A. Schulte, Dr. P. St tz,Dr. W. Kl ckner, NATO RTA SystemConcepts and Integration Panel Symposium,Florence, Sep. 1999.

11 ABBREVIATIONSA/C AircraftAPOS Application to Operating System Interface

LayerARINC Aeronautical Radio Inc.ASAAC Allied Standard Avionics Architecture

CouncilATR Air Transport RackingBIT Built-In TestBSP Board Support PackageCOTS Commercial Off-The Shelf CU Communications UnitDPU Data Processing UnitEUCLID European Co-operation for the Long Term

in DefenceFC Fibre ChannelGP Graphics ProcessorGPU Graphics Processing UnitGSM Generic System ManagementI/O Input / OutputIMA Integrated Modular AvionicsMil Std Military Standard (US)MMC Mission Management ComputerMMS Mission Management SystemMMU Mass Memory UnitMOS MSL to Operating System Interface LayerMOTS Military Off-The- Shelf MSL Module Support LayerNII Network Independent InterfaceOpenGL Open Graphics LanguageOS Operating System

OSL Operating System LayerPCI Peripheral Component InterconnectPMC PCI Mezzanine CardPOSIX Portable Operating System InterfaceRM Resource ManagerRTBP Run-Time BlueprintsRTOS Real-Time Operating SystemRTP Research and Technology ProgrammeSBC Single Board ComputerSM System ManagerSMBP System Management Blueprint InterfaceSMOS System Management to Operating System

Interface Layer

TC Transfer ConnectionVME Versa Module Europe