THE AIRBUS APPROACH TO OPEN INTEGRATED MODULAR
AVIONICS (IMA): TECHNOLOGY, METHODS, PROCESSES
AND FUTURE ROAD MAP
Henning Butz
Dpmt. Information Systems Architecture & Integration, Airbus SAS
Kreetslag 10, D-21129 Hamburg, Germany
mailto:henning.butz@airbus.com
Abstract
Since twenty years the rapid increase of micro electronics performance according to Moores
Law pushed the respective customer demand for more and smarter functionality on modern
Aircraft (A/C) systems. In order to keep the volume, weight, power consumption and cost of
avionic within reasonable limits the classical concept: one function = one avionic controller
can finally not be maintained. Concepts are due to get multiple software (SW) functions of
different origin and criticality level to be integrated on single avionic controller devices. This
is the step to Integrated Modular Avionics (IMA). The first IMA solution was introduced
1995 on the Boeing 777. It was the A/C Information Management System (AIMS) from
Honeywell, a backplane based modularized cabinet. The AIMS Cabinet integrated several
flight guidance, data recording and maintenance applications. After several years of in service
experience the new avionic concept proved to be at least one order of magnitude more
reliable than conventional embedded controllers. Today the IMA cabinet technology is state
of the art on different A/C programs.
In Europe Airbus together with THALES-DIEHL took a further step in the
development of an Open IMA technology standard on the A380 program. The features of
open IMA go beyond the initial approach of AIMS by Honeywell in terms of applying
open avionic and commercial communication standards as well as sharing knowledge
between the IMA platform provider and the airframer on the technical features of the
standardized computing resources.
In order to achieve this, the proprietary cabinet solutions were abandoned and
substituted by general purpose ARINC 600 Standard avionic controllers, labeled CPIOM
(Core Processing & IO Module), which are applied to both cockpit and utility functions, i.e.
quite across all A/C system domains. Further, an A/C Full DupleX (AFDX) switched
Ethernet communication network was provided which connects all controller devices of the
A/C. Ethernet switches and CPIOM are designed according to the common aeronautic
ARINC 600 standards and thus, are open to all potential avionic manufacturers. Additionally
Airbus and THALES-DIEHL developed the necessary processes, methods and tools that
support the new Open IMA technology.
The presentation will give a survey on the state of the art of the A380 IMA concept in
terms of technical aspects and with a strong focus on the methodical features of this
technology (configuration, incremental qualification, tools, industrial roles & responsibilities,
liabilities etc.). Finally derived from the Lessons learnt a roadmap towards further needs
and targets and the respective technology will be given.
AST 2007, March 29-30, Hamburg, Germany
Henning Butz
1 INTRODUCTION
A strong pull for more and more computer centred information processing on board
aircraft is driven by high demands on safety, dependability, and handling quality
subject to stringent economic constraints. For this reason we find Moores Law (i. e.
the doubling of micro electronic performance every 18th months) quite exactly ruling
on avionic system design since more than 35 years. The exponential increase of the
performance does not only apply to memory capacity, which host the application
software (SW) code and the respective processing power for getting it executed. The
demand for more data communication especially drives the number of signal
interfaces between the systems into quantities which were beyond imagination some
600
400
Function SW in
200 MB
0 Signal Interfaces
1965
x 1000
1975
1985
1995
2005
Figure 1 Installed function SW and signal interfaces on board commercial A/C
years ago. Thus, complexity becomes the issue (Fig. 1).
Up to the 90ies avionic system design followed the federated architecture
principle: one function - one computer. This approach finally met its natural limit
when the weight and volume of the black boxes hit the envelope restrictions of the
aircraft. And, another burden became obvious: the huge number of different black
boxes charged the balances of the airlines with significant maintenance costs for
world wide computer spare provisioning and handling. In order to shrink volume,
weight and costs the aerospace industry developed concepts to integrate multiple SW
functions of different origin and criticality level on singe computing devices. This
indeed showed the desired effect on weight and volume reduction however, not on the
expenses. The high level of function integration forced fault propagation and in-
transparent functional interference, which turned the reliability of the black boxes
down and created severe industrial liability issues. Troubleshooting and modifications
became significant cost drivers.
Multiple function integration on one computer requires specific provisions on
the operating system. Middleware has to be implemented that keep the different SW
functions virtually apart, separate it from the HW and provide services for more
sophisticated built in fault diagnostic. However, these provisions are quite expensive
2
AST 2007, March 29-30, Hamburg, Germany
to develop. For the amortization of these extra cost for integration standardization
is mandatory. Controller HW and SW are designed as multipurpose devices in order
to get them spread over many A/C system function domains and A/C programs.
PRIM
FCGU3 SEC3 FMADIRU
FCGU3 CM EC
PRIM PRIM
SFCC1 FCGU1
SEC1 FCGU1 FCGU2
FCGU2
SEC2SFCC2
Integrated 18+2F 18+2F
IOM SW- SW- IOM
Modular IOM
ADIRU
SW-
13+1F
SW-
SW- IOM
ADIRU
SW-
Avionics FM FM
CD
L CD
L CD
C R CD
CD R
EECA A EEC
B CD
L CD
C CD
R B
EECA A EEC
B B
CABINET CPIOM-
SC
CPIOM-
CPIOM-
ACR SW- SW-
SW- SW-
AESU AESU
IOM
IOM
16+2F 15+2F IOM
IOM
CPIOM- CDA CPIOM-
display CPIOM-
CIDS
SDS1
CPIOM-
CIDS
SDS1
SW- SW-
18+2F SW- SW- 15+2F
actuators CPIOM-
CPIOM-
CPIOM-
CPIOM-
18+2F
SW-
SW-
CPIOM- CPIOM-
CPIOM- CPIOM-
CPIOM- CPIOM-
CPIOM- CPIOM-
1111 CPIOM- OSC
CPIOM-
SPDB SPDB
senss SPDB
SEPDC1
SPDB
SEPDC
LRUs Multi-transmitterSPDB
SPDB DSM
SPDB
SPDB
Federated sensors bus network
architectures d LRU CPIOM & AFDX NETWORK (ADCN)
i
actuators OPEN IMA
s
p Integrated LRU
l Golden Box
a
1990 y 1995 2000
Figure 2 Concepts and evolution of avionic integration and modularization
The first step into this direction was taken by Honeywell, 1995 with the concept of
Integrated Modular Avionic (IMA), Fig. 2. It featured the decomposition of the
avionic devices into its basic functional elements: Processing, I/O, Power Supply and
Gateway. These functions were allocated to distinct modules (CPM = core processing
module, IOM = I/O module, PSM = power supply module, GWM = gate way
module). Physically the modules were assembled within a cabinet frame. The
communication between the modules provided a highly failure tolerant time triggered
back plane bus (SAFE BUSTM). The back plane bus protocol and the module
operating system middleware provided certified services for strong SW/SW
partitioning, HW/SW segregation, and failure monitoring. This IMA controller
concept first was applied on the Boeing 777 aircraft for cockpit functions (AIMS =
Aircraft Information Management System). It turned out to achieve reliability figures
and No Fault Found (NFF) rates that were up to one order of magnitude higher than
comparable devices the aeronautical industry used before.
Airbus, in parallel took the same approach in order to prepare the avionic design
of the A380 but went further on three properties:
1. Airbus abandoned the proprietary cabinet and module standard of Honeywell
and selected the open ARINC 600 norm for the avionic modules.
3
Henning Butz
2. The back plane bus was replaced by a 100Mbit Full DupleX (AFDX)
switched Ethernet network according to the commercial open standard to
which all types of avionic devices can be attached to, and
3. The IMA modules were applied to all types of aircraft functions i. e. cockpit
and utility systems.
According to these principles Airbus labelled its concept the Open IMA
(Fig. 3). One main consequence of the Airbus approach is that the modules and
the communication devices might be procured from third party avionic suppliers
according to the specification owned by Airbus. The aim is to develop a market
for the open IMA standard in order to control the costs by competition.
FCSC1 FCGC1 FCGC2 FCSC2
COM MON COM MON
Flight COM MON COM MON
SFCC1 SFCC2
COM MON FCGC3
Control COM MON
FCSC3 TBC
COM MON
COM MON
IOM IOM
SW13 FM2
ADIRU1 FM1 ADIRU2
Cockpit ADIRU3 FM3
EEC1 EEC3
L1 L2 C1 R2 R1 EHM3
EHM1
ATC2 EEC4
EEC2 ACR1
ATC1 L3 C2 R3 EHM4
EHM2
FW1 ACR2 opt
FCDC1 FW2
FCDC2
AESU1
AESU2
IOM ACMF ELM
ELM IOM
SCI CBM FDIF CBM
SB24 SCI
SB24 HSM
HSM
AIC? AIC?
Fuel Fuel
LG,TP&BS LG,TP&BS
COM MON
COM MON Energy COM MON
COM MON
ECB ext lights
ctrl
Fuel&LG
CIDS CIDS
IPCU
IRDC IRDC
PWCU IPCU
PESC
VSC Cabin
doors ctrl,
SPDB oxygen ctrl SPDB
implementation TBD
Air conditioning Ventil&press Air conditioning Ventil&press
Figure 3 The Open IMA network on the A380
2 THE IMA DEVELOPMENT PROCESSES, METHODS AND TOOLS
The goal is to get the majority of the aircraft system functions operated on
standardized IMA controllers being linked to the Aircraft Data Communication
Network (ADCN) based on the Aeronautical Full DupleX (100Mbit AFDX) switched
Ethernet technology. For this purpose Airbus has to modify the conventional
development processes, methods and responsibilities. The IMA / system development
and integration procedure is split between
4
AST 2007, March 29-30, Hamburg, Germany
- the Avionic Module Supplier
- the Aircraft System Manufacturer and
- Airbus.
Bare Module Spec. & User Guide
FCSC1 FCGC1 FCGC2 FCSC2
COM MON COM MON
Flight COM MON COM MON
SFCC1 SFCC2
COM MON FCGC3
Control COM MON
FCSC3 TBC
COM MON
COM MON
IOM IOM
System Rqmts
SW13 FM2
ADIRU1 FM1 ADIRU2
Cockpit ADIRU3 FM3
EEC1 EEC3
L1 L2 C1 R2 R1 EHM3
EHM1
ATC2 EEC4
EEC2 ACR1
ATC1 L3 C2 R3 EHM4
EHM2
FW1 ACR2 opt
FCDC1 FW2
FCDC2
AESU1
AESU2
IOM ACMF EL M
EL M IOM
SCI CBM FDIF CBM
SB24 SCI
SB24 HSM
HSM
AIC? AIC?
Fuel Fuel
LG,TP&BS
LG,TP&BS
COM MON
COM MON Energy COM MON
COM MON
ECB ext lights
ctrl
Fuel&LG
CIDS CIDS
IPCU
IRDC IRDC
PWCU IPCU
PESC
VSC Cabin
doors ctrl,
SPDB oxygen ctrl SPDB
imp lementation TBD
Air conditioning Ventil&press Air conditioning Ventil&press
System Function Rqmts
FCSC1 FCGC1 FCGC2 FCSC2
COM MON COM MON Flight COM MON COM MON
SFCC1 SFCC2
COM MON FCGC3
Control COM MON
FCSC3 TBC
Confi SW Fct. SW
COM MON
COM MON
IOM IOM
SW13 FM2
ADIRU1 FM1 ADIRU2
Cockpit ADIRU3 FM3
EEC1 EEC3
L1 L2 C1 R2 R1 EHM3
EHM1
ATC2 EEC4
EEC2 ACR1
ATC1 L3 C2 R3 EHM4
EHM2
FW1 ACR2 opt
FCDC1 FW2
FCDC2
AESU1
AESU2
IOM ACMF
ELM ELM IOM
SCI FDIF CBM
CBM SCI
SB24 SB24
HSM HSM
AIC? AIC?
Fuel Fuel
LG,TP&BS LG,TP&BS
COM MON
COM MON
Energy COM MON
COM MON
ECB ext lights
ctrl
Fuel&LG
CIDS CIDS
IPCU
Fct. SW
IRDC IRDC
PWCU IPCU
PESC
VSC Cabin
doors ctrl,
SPDB oxygen ctrl SPDB
imp lementation TBD
Air conditioning Ventil&press Air conditioning Ventil&press
Figure 4 Development steps and processes to IMA network integration
In a first step Airbus specifies the basic features of the IMA modules
according to the IMA ARINC standards 600, 615 and 653. This covers the module
packaging, the API services, the monitoring, data loading etc. Then Airbus collects
and merges the specific requirements of the different system functions, which shall be
processed by IMA modules. This concerns special signal types, processing cycles,
memory use, EMC, etc. to be added to the basic module specification. Based on this
specification the avionic module manufacturer develops the respective standardized
multi purpose IMA modules (CPIOM = Core Processing & I/O Module). In parallel
system specifications are issued to the system manufacturers who are obliged to use
those standard CPIOM controllers within their system design.
This requires that the system suppliers have to be provided with a very detailed
description of the CPIOM. This is the Module User Guide, a manual, which
precisely explains the CPIOM design features and how it must be operated.
5
Henning Butz
Additional refinement iterations are executed between the system suppliers and the
module manufacturer in the frame of requirement capturing workshops under the
governance of Airbus in order to complete the module design and to promote a
mutual understanding (Fig. 4 top).
When the system suppliers start the function development a complete tool
chain is delivered to them, which supports their development process. The tool chain
provides SW configuration tools, SW linkers and loaders and module emulation
devices. These tools enable the system manufacturers to debug and verify the SW of
their functions in the very early stage of the development cycle even if the physical
CPIOMs are not yet available (desktop validation). The efficiency of this approach
can be quantified from the fact that on the A380 the system function qualification on
IMA modules was achieved up to one year earlier than with conventional controller
design.
When the IMA modules are ready Airbus provides the necessary quantity of
them to each system manufacturer who run their application on a CPIOM. On site the
different system suppliers perform their local single function integration and system
qualification. The modules are pre-configured by Airbus according to the final
integration condition on the aircraft when several functions from different system
suppliers will have to be processed on the module. This is the process of
incremental qualification which means that each system manufacturer only gets
its own function integrated to the module without being obliged to consider the
presence of any function from other system vendors, which will be integrated to the
same module afterwards (Fig. 4 center). The incremental qualification approach is
supported by the strong partitioning property of the IMA modules. The validity of this
property has to be verified and demonstrated by the CPIOM manufacturer according
to the Airbus CPIOM specification. Because of the novelty of the technology Airbus
double checks the partitioning features again after Module delivery. For this purpose
a specific test suite is applied to the modules, which proves that the different SW
partitions on a CPIOM cannot interfere under any condition. The tests must comply
with the demands of the aircraft certification process. The verification of the
partitioning mechanisms is worth the effort because it enables Airbus to integrate the
module with several pre-qualified functions from different system suppliers on the
aircraft without the obligation to re-qualify the system functions after final integration
the functions will not interfere.
The open IMA concept puts Airbus into the position of the IMA system
integrator. The development responsibility for the single systems and their functions
remains at the system manufacturers. The avionic module supplier provides Airbus
with empty IMA modules. Airbus, in turn integrates those empty CPIOM with the
AFDX-Ethernet-ADCN on the aircraft in order to establish the basic computing
resource for different system functions (Fig. 4 bottom).
Before the system functions can be processed on the IMA Network Airbus has
to generate appropriate configuration files for the ADCN communication and for the
CPIOM operation.
The ADCN configuration mainly concerns the address tables of the Ethernet
switches, the data frame size, its transmission rate and the required bandwidth of the
Virtual Links (VL). The VL feature communication lines which the signals take along
the network. They can be considered as virtual wires, which transmit data according
the ARINC429 standard protocol across the AFDX switches and cables. Adding new
or changing subscribers to the ADCN only means to establish a new VL between the
6
AST 2007, March 29-30, Hamburg, Germany
transmitting and the receiving device. This makes the configuration and the
modification of the avionic architecture quite flexible.
The configuration of the CPIOM concerns the allocation of memory space,
signal ports and processing cycle times to the different application SW partitions. The
configuration data is laid down in configuration table files, which are loaded on the
CPIOM in order to get the operating system perform as required by the different SW
applications, which run on the module.
After completion of the local system function qualification the system
suppliers provide their respective application SW partitions to Airbus. Airbus assorts
and collates these files according to the individual IMA system configuration, which
depends on the actual serial production number (MSN) of the aircraft and adds the
respective configuration tables. Application SW partitions plus configuration table
files make up the final SW load that is delivered to the final assembly line where it is
loaded up to the empty CPIOMs on the aircraft under production. As an interface
between Airbus IMA SW integration facility and the final assembly line - for the
hand over of the final SW loads - a protected database the SW Ground
Repository, SGR is installed (Fig. 4 bottom).
Application SW and configuration files always constitute a tight entity, which
must not be confused or mistaken for safety reasons. This is why the application SW
loads and the respective configuration files are processed through a validated tool
chain that automatically performs the version management based upon qualified
Product Data Management (PDM) tools (Fig. 5).
Integration of auto-coded Field Loadable Software for IMA
IMA MCCT Software Load Generation Process
DCF CRC3
2
CRC3
2 C VerificationCRC3
R 2
CRC3
CRC3 C VUDIMA Status
2
2 Chk CRC3
2 CT
CRC3
CT Compiler S Record
MICS CRC3.C Files
CRC3
C 2 CRC3
2 Linker file
CRC3
R 2
2
C COTAGE 2
ALCS
Chk
XX .C signature
CRC3ALCS Files
2 YY ALCS
CRC3 ZZ
2 CRC3
2 C
R
Go / No IMASC
AIRBUS DEUTSCHLAND GMBH. Alle Rechte vorbehalten. Vertrauliches und geschtztes Dokument.
C
Go Chk
Load files
BETSI LODGE
VUDIMA Usage Domain Verification Tool
CPIOM
COTAGE Autocode Generator for MCCT
LODGE Software Load Generator
BETSI Software Dataloader
Page 13 of 19
Figure 5 IMA development tool chain
3 PRESENT STATUS OF IMA DEVELOPMENT
Not long ago the A380 after having passed all her Flight Tests gained the Type
Certificate (TC) from EASA and FAA. She is now ready to enter service soon. The
7
Henning Butz
TC includes the approval that the new IMA technology and the equivalently new
processes and means being applied to show compliance with the safety objectives
have been considered valid by the authorities. In detail this applies to the following
items:
1. the CPIOM basic features for incremental function integration like strong
partitioning, fault monitoring, HW/SW segregation etc.,
2. the configuration tables for the ADCN and CPIOM,
3. the respective system validation and verification at the system suppliers
facilities,
4. the compilation of the different application SW partitions and the respective
configuration tables for the final CPIOM SW load. The validity of the final
SW load and the respective configuration table for each individual fully
integrated CPIOM has been approved in the frame of distinct IMA bench tests
for the bare module, the configured module and the integrated module,
5. the transmission of the final CPIOM SW load to the final assembly line
through the SGR,
6. the on board SW loading of the empty CPIOM,
7. the correct operation and configuration of the fully integrated IMA /AFDX
network in context with the connected aircraft systems in the frame of ground
tests and a more than one year flight test campaign which successfully
accomplished the IMA verification and validation process.
By passing the a. m. steps the AFDX and IMA avionic network was experienced
as a very mature system that needed only minor modifications and ran stable virtually
from the first day when operated on the aircraft. Constantly remaining in the table of
the 10 most fault free systems indicates the quality of the IMA components, the
underlying topology and of the respective development tools and processes.
4 LESSONS LEARNT
The handling of the IMA devices, the understanding of their technical features and
behavior, the management of the new three lateral IMA industrial processes (the
IMA-Triangle) and interfaces had successfully performed within a worldwide
network of distributed stakeholders. Considering the ratio of local and remote
assistance Airbus had to provide to the respective stakeholders we can conclude that
the manuals and tools, which support the development are already in a quite
satisfying condition so that fairly remote development processes of the IMA-
Triangle were feasible. Due to the stringent guiding of the IMA development plan
and the early availability of network and module emulators the system function
integration to the IMA CPIOM was achieved between six to twelve months earlier
than on classical controller devices.
The Virtual Link (VL) concept of the ADCN turned out to be a very flexible
means for the handling of modification and extension of communication requests.
Whereas in the past new wires had to be physically installed on the aircraft the
activity is now reduced to the definition of a new VL, which simply means to enter a
new address and some data frame transmission parameters to the configuration table
of the network.
IMA modules were equipped with in depth fault monitoring, instrumentation
services and Built In Test (BIT) facilities at a very early stage of function integration.
8
AST 2007, March 29-30, Hamburg, Germany
These provisions could be used for debugging and trouble shooting at system and
aircraft integration, which saves time and cost for additional test installation.
In order to fit the IMA CPIOM to the collective function requirements of the
users (i. e. the system manufacturers) background knowledge has to be exchanged
between the system vendors and the IMA supplier. For this purpose Airbus has
organized requirement capturing workshops which proved to be an efficient means
for getting a comprehensive view on the necessary provisions that have to be
implemented on the IMA devices in order to meet the functional application demands
of the users.
Expecting ambiguous failure cases, and as an instrument to handle the
successive finger-pointing situations, Airbus has established an arbitration board,
which constitutes system-, avionic- and aircraft experts who investigate the situation
in order to find the root cause and to agree on a reasonable and economic solution. It
can be stated, that up to now no such ambiguous failure case had been experienced
that might have justified the activation of the arbitration board.
At the present instant Airbus does not experience any issues with the split
liabilities of the IMA process where the responsibility for the proper operation of the
system function is shared between the system manufacturer, the avionic CPIOM
provider and the IMA network integrator. The present Airbus contracts, which
concern the IMA-Triangle, provide the clauses, which cover the liability subject.
However, only in service experience will bring the evidence that the provisions taken
so far are adequate. Revision of the contracts concerning legal issues will be one
major task of the IMA arbitration board.
5 NEXT STEPS
There are some items, which need further development:
The allocation of the various system functions and SW partitions to the different
CPIOM within the ADCN is still a manual process at design time. With increase of
the IMA integration level on future A/C programs, the IMA development tool chain
needs completion at the front end by a provision that supports the allocation of SW
functions and communication needs to the available IMA / ADCN resources in order
to automatically satisfy all relevant performance indices for cost, safety, availability
etc. subject to pre-defined optimization criteria. Airbus presently is going to develop
such facility.
The quality of the results when using such IMA configuration optimizer
significantly depends on the flexibility of the IMA modules. Therefore it is
reasonable to remove the analog signal interfaces from the CPIOM and make it a pure
digital CPM in order to get it independent from its location within the ADCN. The
analog signals can be shifted to smart units, Remote Data Concentrators (RDC) or
Remote Electronic Units (REU), linked by serial data buses and Gateway Modules to
the ADCN. Power distribution boxes (PDB) or solid state power contactors (SSPC)
within the central electric power system may serve as the respective switching
devices. This step definitely will impact the overall system architecture on aircraft
level as can be seen from comparison of Fig. 6 and 7. This obviously indicates how
the IMA approach drives the system design and function breakdown all across the
aircraft. The IMA network optimizer therefore has to cover or at least support those
indirect effects on the overall system architecture on aircraft level as well.
9
Henning Butz
Avionics
server Open World
DLCS
CMS IFE
Ethernet network
AFDX
SCI RLRU
AFDX
ADCN network
switch switch switch switch
AFDX
AFDX AFDX AFDX AFDX
A429 or Actuators with
Field Bus field bus
discrete, some closed loops
RLRU CPIOM SSPC LRU IOM RLRU RLRU analogue,
A429 or field bus A429 or field bus
discrete, analogue,
AVIONICS
LRU LRU
BAY
ARINC 600
Avionics World
document.
Loads
confidentiel.
Actuators with
some closed loops
proprietary
A429, field bus, discrete, analogue, A429, field bus, discrete, analogue,
rservs.
Confidential
Tous droits Document
and
ATA42 perimeter
AIRBUS
S.A.S.
AIRBUS All rights
FRANCE reserved.
S.A.S.
PART 7 - IMA 2G roadmap - 5th October 2006 Page 3
Figure 6 Present embedded system architecture based on CPIOM solution
Avionics Actuators with
server Open World some closed loops
Actuators with
some closed loops TBD
IFE
SMART
Ethernet network
discrete, analogue, discrete, analogue,
discrete, analogue,
AFDX Field Bus
RLRU RDC REU
REU SCI
AFDX low cost AFDX AFDX
ADCN network
switch switch switch switch
AFDX AFDX AFDX AVIONICS OPEN LRM AFDX
Actuators with
discrete, some closed loops
RDC SSPC LRU CPB ASB IOB RLRU analogue,
Objectives:
discrete, analogue,
Field Bus
Largely distributed and
Field Bus
standardized I/Os
Field Bus
ATA42 LRM types & ATAXX
LRU P/Ns drastic reduction
document.
Loads REU
confidentiel.
Full use of AFDX, of
proprietary
Document
discrete, analogue, common avionics generic
and
RDC (ATA42), of REU (ATA
rservs.
Confidential
Smart Smart Smart Smart
42) and of SSPC (ATA24/42);
Tous droits
ATAXX Smarts
reserved.
S.A.S.
All rights
Actuators with
Avionics World
FRANCE
some closed loops
ATA42 perimeter
S.A.S.
New architecture with open LRM principle
AIRBUS
AIRBUS
PART 7 - IMA 2G roadmap - 5th October 2006 Page 6
Figure 7 Example for a more federated IMA architecture
When in the frame of the iterative function allocation process the IMA network and
the aircraft systems shall be handled as an entity this task will be facilitated if IMA
10
AST 2007, March 29-30, Hamburg, Germany
items like API middleware, monitoring functions or data bus standards may be used
within proprietary system computers and smart electronic devices as well. Therefore
one future topic will be to check the portability of IMA SW, HW and middleware
standards and their application within the frame of proprietary system controller
devices.
Parallel to the aeronautic IMA development other fields of embedded system
application like tele-communication or automotive industry have developed some
own products, which partly have already achieved the state of extended commercial
of the shelf (COTS) standards. Especially the open COTS operating systems from
Wind River Systems, Green Hills Software, OSE, and Lynux Works have gained a
considerable maturity status that makes them interesting for the application on highly
dependable and safety critical computing devices. The same applies for Middleware
in the field of system and component failure diagnostic where especially the
automotive industry follows and promising trail from a tooling and commercial point
of view. Another item, which attracts the attention of the aeronautic IMA community
concerns the highly dependable data bus protocol products like TTP or FlexRay
which find quite broad resonance in different fields of application. The wide spread
industrial acceptance of the a. m. COTS standards will lead to stable and mature
products with a well balanced price/performance ratio. The basic idea of the Open
IMA concept relies on the broad application of COTS products to which the
stakeholders of the IMA technology have free access. On the other hand it is obvious
that big COTS standards are much less under the rule of an Aircraft manufacturer
than own or aeronautical specifications. Therefore Airbus has to consider how COTS
standard products, which we cannot drive directly will impact the life cycle of the
aircraft systems. In this context a reasonable approach may be to consider common
interests and procedures between the telecom, the automotive and the aeronautic
industry in order to gain more dominance on the specification of big standards and
profit from common experience and strategies.
6 CONCLUSION
It was shown how the avionic architectures and devices developed from purely
proprietary products to a highly integrated, modularized general purpose avionic
network based on open standards. The reasons, which impelled the IMA technology,
were explained and the necessary features and provisions of an IMA network were
detailed. It was shown how the IMA solution affects the industrial processes and the
way in which they were implemented on the A380. The present state of the art of the
IMA solution and its respective processes, means and tools were outlined. From a
comparison of the achievements and lessons learnt versus the future targets of the
IMA approach a reasonable road map of the future steps in order to exploit the
inherent potential of the IMA solution on future aircraft programs were derived.
Finally it is worth stating that presently Airbus stays ahead worldwide with its
capability to manage the tri-angular IMA development and integration process
(avionic manufacturer airframer system supplier) within an industrial environment
on aircraft program level.
11
