I

....................................................................

....
..............................................................................................................................................

Integrated Modular Avionics

Gordon R. PARR,R. EDWARDS Over the past 20 years or so avionics have been designed using common standards and this has improved the quality and to some extent the interoperability of equipment. Yet aircraft systems are still a patchwork of one-off designs and the current thrust in Integrated Modular Avionics (IMA) is to address this issue.

he opportunities presented through the NATO based Allied Standard Avionics Architecture Council (ASAAC) programme and the USA's Integrated Sensor Systems (ISA) programme aim to generate new ~4opdoww, systems-driven standards which are therefore more durable and possess the right interfaces to make these next generation standards more technology independent. The first challenge facing IMA systems integrators is to bring together successfully core architecture elements (the digital processing) and traditional sensor/ effector elements. Key objectives include better mission/operational performance achieved with present federated architecture systems, affordability and maintaining certification over extended aircraft lifetimes. Since they will take considerable time to generate, these open standards should be durable enough to last 40 years - potentially the time from design to dispersal - and with the right emphasis on interface definition the standards should maintain technology independence. Modular avionics is a vast subject and this article will focus on selected key issues considered to be of relevance to all modular avionics programmes: technology transparency, durability of standards, open standards, mission performance, operational performance, qualification and certification and life cycle cost payback.

Technology transparency
Technology transparency encompasses two aspects of growth: system growth, the incorporation of new or enhanced capabilities in the weapon system at various points in its service life; and technology growth, the incorporation of the latest technology with minimal disturbance of the system in order to support system growth or to minimise support costs. Transparency is important because the rate of development produces several new generations of technology within the life time of a military aircraft. For example, the performance of data processors is doubling every eighteen months, often making new designs obsolete before they enter service. The primary goal of technology transparency is to ensure that when new technology is incorporated it remains back-compatible with existing products already in the field, greatly reducing the logistics burden, giving access to the most cost-effective technology on a rolling basis and retaining interchangeability. A good example of how technology transparency can be achieved in IMA is provided by the distribution of electrical power to line replaceable modules (LRMs) in a rack via a backplane (figures l(a) and l(b)). A common method is to use a number of power conversion modules (PCMs) to convert the platform
72

electrical supply voltage to logic levels which are then routed to the backplane as dedicated rails and picked up by the appropriate LRMs. This method has a number of weaknesses including the number of different voltages that must be generated to cater for the different technologies, the high power levels which would be incompatible with trends and the high temperatures demanding extreme dissipation requirements of up to 200W resulting in backplane/pin current for a single LRM of more than 60A! A technology transparent solution would be to distribute a single dc voltage on the backplane and provide dedicated dc to dc converters at the point of use for each LRM.

Durability of standards
The two most important questions ask whether standards are really necessary and, if so, over what lifetime will they remain useful. It is hard to see how large scale multi-project, international, hardware and software reuse could take place without them. The great danger is that IMA building blocks will be tailored to the needs of a single project with subsequent projects producing noninterchangeable items. IMA standards have a large part to play in ensuring interchangeability and interoperability of building blocks from different vendors. As stated earlier, back-compatibility of

PROGRAMMES
PLATFORM SUPPLY
\

PRODUCTS
PLATFORM SUPPLY B 11._sv.~ac ~ _ __ ~ 3.

PLATFORM SUPPLY A __ ~115V_aac3~ RACK

I *24V dc

BACKPLANE

It.
f
PCM I
.

,,,,+svo
. . . . .

_+.vc

l / +12Vda \ I ! I t - - - / l\

I I
LRMs LRMs ~ i

1
PCM TypeC

I \ I

PCM TypeB

LRMn

b L-

LRM1

LRMn

LRM20

Figure I. Technology transparency: (a) Conventional Power Distribution (b) Technology Transparent Power Distribution (Doc. Smiths Industries Aerospace).
LRMs is simply long term interchangeability. It is hard to state a definite life expectancy for IMA standards but they must surely remain for the 40 years or so of a project's life span. Studies conclude that the problems of writing long term standards can only be met by basing them on a set of well defined interfaces. Long term IMA standards must also be written to cater for supplier innovation, keeping free the opportunity for manufacturers to incorporate novel approaches, methods, processes, materials and devices.

Mission performance
Project managers of both large and small projects must be confident enough in applying the IMA standards to manage efficiently the total systems engineering aspects of their programmes. This includes IMA project definition, systems definition, systems/software design, build, integration and test and the provision of adequate user documentation and training. Project managers will need to ensure that the main drivers for IMA (integrated logistic support and life cycle cost goals) are successfully achieved. The interface standards and performance specifications must also allow for systems growth and mission performance upgrades in order to satisfy pre-planned product improvement objectives. An important part of this process is ensuring that the IMA is capable of handling software system changes throughout a platform's life cycle. System/software changes are prevalent in cycles within an aircraft programme; many changes to start with, settling down as the system matures, then this cycle repeating a number of times with upgrades in both functionality and performance. It is clear that the move from federated systems to IMA will be something of a culture change in the avionics industry but the results from the Industrial Avionics Working Group studies reveal system solutions that should meet both present and future developments in mission requirements for a range of platforms. C
AIR & SPACE

Operational performance
The mission sustaining capability of some current platforms using highest reliability subsystem equipment and components with ~single thread functionality>> is in the range of several hours to a few tens of hours. Single thread functionality is used here to be synonymous with simplex operation. The wartime goal set by the Allied Standard Avionics Architecture Council is for sustained performance and system availability of 95% for an all-out period of at least 30 days in a remote austere operating environment without ground support. The corresponding peacetime goal was set at a minimum 95% availability over a period of 150 flying hours without maintenance. Considering just the hardware, although improvements in basic electronic component reliability will continue, the rate of progress is fairly slow and dependent on a large number of complex physical and mechanical factors. In addition there is the requirement for interchangeability of equipment at aircraft, fleet, multi-fleet and national levels. Figure 2 shows some of the interfaces and performance specifications which can affect the interchangeability of IMA equipment at the operational flight line. The most obvious intuitive one is the physical/mechanical/connector interface at module insertion level. Clear part number identification will need to establish all the hardware (computing) and firmware (protocols) capability resident
EUROPE VOL. I No 2 1999

Open standards
IMA standards need to give the system integrator and the system user a degree of supplier independence by allowing alternative sources for a particular building block. This will allow flexible purchasing decisions to be made on the basis of supplier performance, cost and schedule factors. Open standards should define how properties such as interoperability, interchangeability and back-compatibility can be verified. The standards must work well together as an integrated set and the need to adopt commercial standards which have been originated in isolation could make this a challenging proposition. The standards also need to be maintained as an integrated set over a lengthy period probably requiring the coordination of a number of standardisation bodies. Writing and maintaining standards for IMA is a large undertaking but the payback makes it all worthwhile.

~
ii

~ ..,~. ......... .. . .

in the item including for example minimum processing, memory and baseline facilities.The IMA can interrogate replacement resources electronically, verify acceptability and signal this to maintenance crews. The other major item which affects interchangeability concerns the software loading interface where the processor types within the modules could change a number of times over the lifetime of the platform.

system and application software embedded within the boxes. The qualified black boxes are housed in the appropriate avionics cabinets and clearance is effected at subsystem and total system levels. In IMA the case is slightly different in that it is the electronicmodules and the software operating system which will need to be qualified and the subsystems, which are now combinations of electronicmodules, which will be cleared at avionic cabinet or part-cabinet level.

boundaries. Only in this way can the full payback from IMA be realised.

An example of IMA systems architecture

The simplified diagram of an integrated modular avionics system architecture (figure 3) is intended to highlight the relationship of the core to the non-core parts and excludes integrated systems. It shows an IMA with a core suite of avionic cabinets and interfaces to the non-core embedded sensor/effector essential to the total avionics suite. Using published ASAAC (Allied Standard Avionics Architecture Council) material as the basis the module set includes Signal, Data, Graphics and Cryptographic Processing Modules interconnected by the very high speed serial optical Data Transmission Network (DTN). The DTN physical data link network and transport layers provide the hardware and protocols needed for the very fast sensor and display signalling, traditionally known as the ~<Sensor/Video Bussing>>, and also signalling between modules and between cabinets, traditionally called ~AvionicsBussing>>. Each data processor on each module of whatever type would have its own standardised operating system and would run under the control of a System Manager operating at avionic system

Qualification and certification

Clearance for flight worthiness of IMA based military platforms and systems should follow the routes which have become well established within the industry over the years. There is a natural progression from the clearance of federated systems which have some intermediate levels of integration into IMA systems with higher levels of functional and physical integration. The flight safety critical and the survival criticalsubsystems will naturally follow the established routes as their boundaries and operation should remain clearly defined, even though these types of subsystem may use their own separate IMA hardware and operating system components. Federated systems are in general qualified at black-box level with the electronic modules, software operating

Life-cycle cost payback

This is one area which is still regarded as an art rather than a sciencebut, because it is claimed as one of the main benefits of IMA, it is important to understand what the payback will be. Assuming that suitable IMA building blocks are available ~off-the-shel6>, studies have shown that avionics acquisition and support costs could be expected to reduce by 15% and 40% respectively for a single IMA project. Further improvements are possible if a multi-project approach can be adopted and this is the key to maximising payback. This implies a change in the procurement culture to allow much wider acquisition and support cost tradeoffs to be taken into account, cutting across traditional air force, nav~ army projects and national

.......

II

.......

DATA PROCESSOR

SIGNAL PROCESSOR

.......

II

.......

I ............ II ............ I
LOAD & DUMP LOAD & DUMP

PHYSICAL (OOMMS) LAYER

SWITCH NET OPTION

T O SENSORS ~

TO SENSORS

Figure 2. Principal interfaces affecting interchangeability (Doc. Smiths Industries Aerospace).

PROGRAMMES 6~: PRODUCTS

CNI INTEGRATION ~ Vile AREA U.F

CSI - COMMON

SENSOR

INTERFACE

CS'-OOMMONS,ONA',ROOESS,NO(MOOO,E)
OP,MOE.ERA P O R , O S E OAT .ROCESS.NO MOOO E

"
'
_

/
RADAR HEAD

RADAR JNTEGRAT,ON AREA

POTENTIALLY EXTENDED CORE BOUNDARY

N.
-I I I CSI

"O~oN~'A~L~,?~O

I. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .
I I [ I,

' ......
l

i C81 i
I I

I r-~-~,~:~E A .... AR
I

Ir-~co~
L
I GPPM

AREA

..... I I~ b__~l CSI

C~ I

NAV

IRST

~
I

-;

~
I

csP

QPPM CORE
CORE

i i

ic~ I .....................
. . . . . . . .

I ~~

- IFF

............

"1

CORE

,.

,- . . . . . . . . . . . . . .
A

~,
[ OSI

........
AREA

..........
AREA

i !
ICSII

AID.DA

....

I .......
1 VIDEO

HU D

o. . . . .
SUITE

II

VM~

LASER

I i

I . . . . . . . . . . . . . .

IN,

,E ~

' 1 i

I
I

I'll
I

I
L . . . . . . .

I
I CORE BOUNDARY

L. . . . . . . . . . . . . .
POTENTIALLY E X T E N D E D

J .............

: ~ _ - ".

- -- ..~CSI . . . . . . . . . . . . . /

VMS (SMS)INTEGRATION EO/DASS INTEGRATION AREA / ~

AREA

// MISSION/MMI INTEGRATION AREA /

Figure 3. An example of IMA systems architecture (Doc. Smiths Industries Aerospace),

level. The core/non-core problem must be solved before the design process can move to developing more elaborate integration strategies although there is no reason why the ASAAC set of standards should not grow from the core outwards and encompass for instance the integration of the whole sensor suite. There is a consequence of increasing the level of systems integration above the levels achieved in current federated systems. In these the <<limit of liability>> of fault propagation is contained by separation of the functionality into subsystems <<black boxes>> and by control of the interfaces between the boxes and the power supply. In the IMA the mission avionics subsystem boundaries are not as sharply defined in hardware as this and the task is more in the domain of the operating system and the subsystem manager functions. These software items will be used to control the integration boundaries. If these items fail, a number of subsystems could also fail simultaneously and the failure analysis for the overall system can become quite complex. For these reasons, the operating system and the system manager functions will be elevated to a higher level of integrity compared to current practice in <<single computing thread>> mission functions. The operating system will need to be able to <<firewall>>the applications within a subsystem and also between subsystems integration areas. The integrity of the operating system controlling the integration of mission subsystems might need to be of the order of 10.5per hour based on it being about an order of magnitude better than a total mission failure rate of 10.4. Furthermore, elements of the operating system could have direct control over the covert parts of the avionics suite and thereby control the separation of covert data. Coupled to this the operating system could have an intimate relationship with the software which controls the DTN bussing network. These are compounding reasons for the increased integrity required of the operating system.
Acknowledgment

This article is published with the kind permission of Smiths Industries Aerospace and British Aerospace.

AIR

& SPACE

EUROPE

- VOL.

I No

2 -

1999