Module 13.20 Integrated Modular Avionics (Ata 42)

PART 66 CAT B2
MODULE 13 AIRCRAFT AERODYNAMICS, STRUCTURES & SYSTEMS (AVIONICS)

INTEGRATED MODULAR AVIONICS (ATA 42)
MODULE 13.20: INTEGRATED MODULAR AVIONICS (ATA

42) (PART 66 CATEGORY B2)
WARNING
This document is intended for the purposes of training only. The information contained herein is as
accurate as possible at the time of issue, and is subject to ongoing amendments where necessary
according to any regulatory journals and documents. Where the information contained in this
document is in variation with other official journals and/or documents, the latter must be taken as
the overriding document. The contents herein
shall not be reproduced in any form without the expressed permission of AAC.
For Training Purposes Only B2M13.20 Trainee Notes V1.1 dated 15.04.14
PART 66 CAT B2
Table of Contents
Module 11.19/13.20 Integrated Modular Avionics (ATA 42) __________________________________________________________________________ 1

Terminology_______________________________________________________________________________________________________________ 1
Integrated Modular Avionics (IMA) Concept ____________________________________________________________________________________ 3
The Need for IMA _______________________________________________________________________________________________________ 3
Avionics Full-Duplex Switched Ethernet (AFDX)________________________________________________________________________________ 4
AFDX Applications _______________________________________________________________________________________________________ 6
IMA Advantages _________________________________________________________________________________________________________ 6
Manufacturer’s Approaches _______________________________________________________________________________________________ 9
Aircraft Data Networks _____________________________________________________________________________________________________ 10

Aircraft Data Network (ADN) Characteristics __________________________________________________________________________________ 10
Emergence of AFDX ______________________________________________________________________________________________________ 10
AFDX Characteristics _____________________________________________________________________________________________________ 11
IMA General Layout ________________________________________________________________________________________________________ 12
The Controller Area Network (CAN) Bus ________________________________________________________________________________________ 15
Avionics Data Communication Network (ADCN) _________________________________________________________________________________ 18

General ________________________________________________________________________________________________________________ 18
The Virtual Link (VL) ______________________________________________________________________________________________________ 20
Core System ______________________________________________________________________________________________________________ 24

Core Processing Input/Output Modules (CPIOMs) ______________________________________________________________________________ 24
CPIOM Components _____________________________________________________________________________________________________ 24
i
PART 66 CAT B2
CPIOM Variations _______________________________________________________________________________________________________ 29

Systems Integration______________________________________________________________________________________________________ 30
Example CPIOM Interface with an Aircraft System______________________________________________________________________________ 33
Input / Output Modules (IOM) _____________________________________________________________________________________________ 34
Component Failures _____________________________________________________________________________________________________ 38
Network Components______________________________________________________________________________________________________ 42
General Description______________________________________________________________________________________________________ 42
AFDX Switch Components _________________________________________________________________________________________________ 45
AFDX Switch Software ____________________________________________________________________________________________________ 46
ADCN failures ___________________________________________________________________________________________________________ 47
Combining Technologies _______________________________________________________________________________________________________ 54

General ________________________________________________________________________________________________________________ 54
Common Remote Data Concentrator (CRDC) __________________________________________________________________________________ 55
Example Implementation – Fuel Measurement and Management System on the Airbus A380 ______________________________________________ 57
ii
PART 66 CAT B2
Module 11.19/13.20 Integrated Modular Avionics (ATA 42)
Terminology
Federated Architecture – An avionic structure that has major functions (e.g., flight management, communications management, analogue signal
consolidation and conversion to digital data, etc.) implemented in LRUs that interchange information over digital databuses.
ARINC 653 – “Avionics Application Standard Software Interface” is a software specification for space and time partitioning in Safety-critical avionics Real-
time operating systems. It allows hosting of multiple applications of different software levels on the same hardware in the context of an Integrated Modular
Avionics architecture..
ARINC 664 – defines the use of a deterministic Ethernet network as an avionic databus in modern aircraft like the Airbus A380, Sukhoi Super Jet 100 and the
Boeing 787 Dreamliner.
Ethernet - Ethernet is a family of computer networking technologies for local area networks (LANs). Systems communicating over Ethernet divide a stream
of data into shorter pieces called frames. Each frame contains source and destination addresses and error-checking data so that damaged data can be
detected and re-transmitted. The Ethernet specification served as the basis for the IEEE 802.3 standard, which specifies the physical and lower software
layers.
Deterministic Ethernet - The ability to send a piece of information to a destination and receive a response in a repeatable time frame.
Avionics Full-Duplex Switched Ethernet (AFDX) – AFDX is a next-generation aircraft data network (ADN). It is based upon IEEE 802.3 Ethernet specification
and utilizes commercial off-the-shelf hardware.
IEEE 802.3 – IEEE 802.3 is a working group and a collection of IEEE standards produced by the working group defining the physical layer and data link layer's
media access control (MAC) of wired Ethernet. This is generally a local area network technology with some wide area network applications. Physical
connections are made between nodes and/or infrastructure devices (hubs, switches, routers) by various types of copper or fibre cable.
1
PART 66 CAT B2
Virtual Link (VL) – The communication channels used to transfer user’s data from an End-System to one or more End Systems, across the switched AFDX
network. The VL utilizes a Bandwidth Allocation Gap (BAG); specifying minimal gap between sending time of two consecutive frames for a VL.
End System – An active AFDX subscriber, connected to an AFDX Network to communicate with other subscribers respecting AFDX rules is called an End-
System. It is the subsystem part which must be embedded in each avionics equipment, connected to the AFDX network to communicate with the other
AFDX subscribers.
Commercial Off-The-Shelf (COTS) – Defining a non-developmental item (NDI) of supply that is both commercial and sold in substantial quantities in the
commercial marketplace, and that can be procured or utilized in the same precise form as available to the general public. For example, technology related
items, such as computer software, hardware systems or free software with commercial support,
Star Topology – A networking topology in which the components are connected by individual cables to a central unit, usually a hub. When a computer or
other networking component transmits a signal to the network, the signal travels to the hub, which forwards the signal simultaneously to all other
components connected to the hub.
Jitter – Distortion in transmission that occurs when a signal drifts from its reference position. Jitter can be caused by variations in the timing or the phase of
the signal in an analog or digital transmission line. Jitter typically results in a loss of data because of synchronization problems between the transmitting
stations, especially in high-speed transmissions.
Media Access Control (MAC) address – A unique 6-byte (48-bit) address that is usually permanently burned into a network interface card (NIC) or other
physical-layer networking device and that uniquely identifies the device on an Ethernet-based network. A MAC address is also known as an Ethernet
address, hardware address or physical address.
Application – System specific software, loaded onto the CPIOM, which runs and controls an associated aircraft system.
2
PART 66 CAT B2
Integrated Modular Avionics (IMA) Concept
The Need for IMA
The Boeing 767 and 757 were the first commercial aircraft to take advantage of the digital federated architecture. The Airbus A320 followed shortly and
extended the idea to become the first fly-by-wire transport aircraft.
However, two generations of aircraft beyond the initial federated avionics aircraft, ARINC 429 has become the victim of its own success. The amount of
digital information exchanged by LRUs has grown beyond the capability of ARINC 429 to carry it. The initial ARINC 429 standard of 1978 included the
definition of about a hundred (32-bit) data word definitions identified by unique "labels." By the early 1990s the number of such definitions had increased
to the point that the ARINC 429 standard was divided into three parts. Part 2 contains the label and word format definitions and is approaching 200 pages
in the latest supplement published in 2004. Part 3 defined a method for sending data files as bulk data transfer became important.
The ARINC 429 bus consists of a single transmitting LRU connected to one or more receiving LRUs transferring data at a rate of either 12-14.5 Kbps or 100
Kbps. The sending unit will place relevant 32-bit data words on the bus at a repetition rate appropriate for the data parameter(s) transmitted on the bus.
The protocol for the receiving units is simple; take in the 32-bit word, read the label and if you need the data, take it. No source or destination addresses or
time stamping is needed. This means two-way data transfer requires two 429 buses. Different data sets (i.e., different sets of unrelated labels) might
require more than one 429 bus. This has led to a proliferation of 429 buses among the various LRUs in order to transfer needed information. In 1987, the
industry recognized the need for the ability to transfer data files as opposed to individually defined data "words" across ARINC 429. The Williamsburg
protocol was documented for this purpose in ARINC 429 Part 3, which became part of Supplement 12. The ARINC 429 standard describes everything from
the physical layer (e.g., signal levels, timing), the link layer (e.g., error checking), to the application layer (i.e., bit formats of the words and their meanings).
Beginning with the Boeing 777, the federated avionics architecture moved toward an Integrated Modular Architecture (IMA) with the Airplane Information
Management System, or AIMS Cabinet. Several major functions (e.g., flight management, communications management, aircraft condition monitoring)
previously implemented as independent LRUs were implemented using IMA.
Furthermore, the concentration of functions within the IMA Cabinet demanded increased bandwidth for communications with avionics implemented
outside the Cabinet.
3
PART 66 CAT B2
Avionics Full-Duplex Switched Ethernet (AFDX)
AFDX is a next-generation aircraft data network (ADN). It is based upon IEEE 802.3 Ethernet and utilizes commercial off-the-shelf hardware thereby
reducing costs and development time. AFDX is one implementation of deterministic Ethernet defined by ARINC Specification 664 Part 7. AFDX was
developed by Airbus Industries for the A380, initially to address real-time issues for fly-by-wire system development. A similar implementation of
deterministic Ethernet is used on the Boeing 787 Dreamliner. AFDX bridges the gap on reliability of guaranteed bandwidth from the original ARINC 664
standard. It utilizes a cascaded star topology network, where each switch can be bridged together to other switches on the network. By utilizing this form of
network structure, AFDX is able to significantly reduce wire runs thus reducing overall aircraft weight. Additionally, AFDX provides dual link redundancy and
the required Quality of Service (QoS) for safety critical avionics systems.
ARINC Specification 664 Part 7 defines AFDX. AFDX takes existing Ethernet physical layer technology and, using switched Ethernet in full-duplex mode as a
basis, adds deterministic packet delivery, and high-integrity and high-availability mechanisms.
In the Ethernet standard (IEEE 802.3) one physical layer option describes the use of two pairs of wires to be used for transmitting and receiving. One mode
of operation, customarily called half-duplex, gave IEEE 802.3 its name: Carrier Sense Multiple Access with Collision Detection (CSMA/CD). In this mode, each
end system monitors it’s receive port for indications that something is being transmitted. Prior to transmitting, such indications are used to avoid
interfering with the ongoing transmission (i.e., the carrier sense function). During a transmission, any indication of another transmission indicates a
collision, which results in corrupted communication (i.e., the collision detection function). This was the original principle of arbitrating communication,
adapted from voice radio communication procedures.
Full-duplex mode separates both communication directions in each end-system and can thus obviate the need for a CSMA/CD mechanism.
A given LRU may now communicate with many other LRUs over one set of AFDX wires as opposed to one ARINC 429 bus pair for each set of one-way data
words and each set of recipient LRUs.
The use of Ethernet permits the reuse of commercial off-the-shelf (COTS) protocols, e.g. IP addressing and fragmentation, any Ethernet interface hardware
and the switched Ethernet configuration.
4
PART 66 CAT B2
But AFDX tailors these to the requirements of the avionics environment. For instance, Virtual Links, bandwidth allocation and redundant LANs add the
necessary integrity, availability and deterministic performance needed for avionics applications.
The Aircraft Data Network defined in ARINC 664 has been developed in several parts and written with the view that commercially available information
technology standards can be applied to aviation with minimal changes. ARINC 664 Parts 2 and 7 are based on IEEE 802.3 Ethernet. Further, where there are
selections among the commercial standards or deviations for aviation requirements, there is provision to record and disclose those selections and
deviations in the form of Protocol Implementation Conformance Statements (PICS) and Services Implementation Conformance Statements (SICS). The use
of PICS and SICS increases interoperability, broadens supplier availability, and ultimately, reduces cost.
Each LRU has an AFDX end-system, which has both transmit and receive ports connecting it to the switch. The path from one LRU to the others is a Virtual
Link (VL).
The hardware that implements AFDX (e.g., Tx and Rx connections to the switch, the switch itself, etc.) replaces the many ARINC 429 buses needed for all of
the LRUs on the AFDX LAN. The deterministic aspect of AFDX is implemented by the architecture of a given aircraft LAN configuration. The controlled traffic
that flows through the VLs plus the bounded transit times through end-systems and switches allows a determination of maximum latency between a sender
and receiver. This also allows the bandwidth usage to be limited over any given small time interval, which then allows the deterministic properties of the
LAN to be analyzed. Traffic shaping is implemented in the end-system and a policing function is implemented in the switch in order to maintain the
deterministic delivery of message frames across the LAN. The integrity of each packet sent across the VL is checked using a Cyclic Redundancy Check which
is verified at the destination.
Each network has one or more AFDX switches. A failure, either hardware, protocol or software, will cause that network to be disabled. All messages are
transmitted to both networks. Each receiving end-system implements a policy of accepting the first valid copy of any message. By implementing this policy
in the end-system, the application software is relieved of any responsibility for dealing with the redundancy in the network.
The implementation of redundant networks also allows lost or corrupted frames on one network to be replaced by a copy from the other network. This
work is performed at the end-system level.
5
PART 66 CAT B2
AFDX Applications
AFDX has been implemented in the Airbus A380 and military A400M as well as the Boeing 787 next generation aircraft. In the A380, the AFDX backbone is
connected to 23 major functions with about 120 subscribers. The advantages of using AFDX are weight savings by elimination of most of the ARINC 429 uses
estimated at about 100 Kg, as well as providing for simpler configuration management. The new A350XWB also will use this technology. Currently, 36 major
functions with about 150 subscribers will be connected to the AFDX backbone.
IMA Advantages
Traditional avionic systems are based on federated architectures where different subsystems exist on their own hardware. These subsystems are physically
separated from one another. In Integrated Modular Avionics (IMA) all these subsystems are on a common platform, sharing resources (such as memory and
processor) and increasing the utilization. IMA has gained popularity over other systems because of reduced weight, size, power and recurring cost.
The Integrated Modular Avionics (IMA) concept, which replaces numerous separate processors and line replaceable units (LRU) with fewer, more
centralized processing units, provides significant weight reduction and maintenance savings in the new generation of commercial airliners. From an airline
standpoint, fewer types and varieties of avionics spares drive higher reliability, and therefore less maintenance.
The traditional avionics approach is to use a separate LRU hardware for each avionics function, and interconnect each one using point-to-point data buses
such as ARINC 429 or ARINC 629, to each other LRU that it is required to communicate to. The limitation of this is that it is difficult to expand. Any additional
LRU requires an additional cable link to each other existing LRU as required. This architecture requires long cable runs for interconnecting distant LRUs that
increase weight and may introduce reliability issues.
6
PART 66 CAT B2
Figure 19.1: Traditional federated architecture approach
The integrated modular avionics approach connects all “modules” (CPIOMs and IOMs) to an ADCN network, and all information is routed, via AFDX
switches, to the intended recipient Line Replaceable Modules (LRMs).
Integrated Modular Avionics (IMA) replaces the point-to-point cabling with a “virtual backplane” data communications network. The network connects
software-configurable LRUs that can adapt to changes in network functioning or operating modes. There is a potential path between any of the LRUs, with
the software and network defining the active Virtual Links in real-time. In the event of failures, the system can quickly reconfigure, resulting in a very robust
system. The ARINC 653 Standard “Avionics Application Software Standard Interface” describes an application program interface and operating system for
producing a flight-critical avionics system that partitions critical and non-critical functions so that they cannot interfere with each other. Not only does this
simplify software design and implementation, it allows more flexibility.
7
PART 66 CAT B2
Figure 19.2: Modular avionics approach
By using the IMA approach, Boeing is able to save 2,000 lbs. of weight on the avionics suite of the 787 Dreamliner, versus previous comparable aircraft. The
IMA approach cuts in half the part numbers of processor units for Airbus’s A380 avionics suite.
It also offers an open architecture allowing for the use of common software, which makes upgrades and changes both cheaper and easier to accomplish.
An IMA operator can upgrade software without having to upgrade the hardware, and vice versa. Using elements common to different computer modules
makes maintenance of the computer less expensive. Since the same part (or card) can be used in any of the IMA computers, inventory in the shop is
smaller.
One of the benefits of this ARINC 653 Standard is that once flight certification is achieved, it is possible to add software such as health monitoring or mission
support functions within new ARINC 653 partitions that may not be certified to the same level as flight critical functions.
8
PART 66 CAT B2
Manufacturer’s Approaches
While adapting the general concept of "shared resources," the Boeing 787 and the Airbus A380 approaches to IMA differ. Both aircraft have applications for
specific LRUs that are on the aircraft and individual computers for certain systems.
Key to the B787 avionics suite, which Boeing developed with partners Smiths Aerospace, Rockwell Collins and Honeywell, is a central computing system
which Boeing calls the Common Core System (CCS), which eliminates more than 100 different LRUs.
The A380 Super Jumbo, applies the IMA concept with computers capable of hosting different functions and integrated modular avionics connected by a
network. This approach differs from Boeing’s 787 central computing system in that it does not rely on a single (or dual) central processor to run most of the
aircraft systems.
Instead, the A380’s IMA approach relies on eight processing modules, some tailored for specific applications, but all tied together by a common Avionics
Full-Duplex Switched Ethernet (AFDX) communication network, in the form of ARINC 664 standard network system. Seven of the computers are core
processing input/output modules (CPIOM); the eighth is an input/output module (IOM).
Although the Airbus IMA computers have eight different part numbers, the memory and power supply cards are common to all the computers. It is only the
input/output card that is different, depending on what type of system the computer interfaces with.
9
PART 66 CAT B2
Aircraft Data Networks
Aircraft Data Network (ADN) Characteristics
The most important characteristics of an ADN are Quality of Service (QoS), available bandwidth, weight and the cost of its development and deployment.
Various ADN attributes such as bandwidth guarantee, jitter, transmit latency and Bit Error Ratio (BER) determine the QoS. A guaranteed bandwidth, limited
jitter, upper bounded transmit latency and a low BER (typically 10-12, i.e. one error bit in a trillion) are imperative attributes of a reliable and deterministic
ADN.
New generation aircraft such as the A380, A350, B787 and A400M are required to feature more sophisticated functions than previous aircraft generations.
For reasons of weight savings, less required space as well as reduced maintenance costs it is desired to implement as much functionality as possible in
avionics. This leads to more complex avionics systems that need to process more data than legacy systems, and consequently a need for ADNs with higher
available bandwidths arises.
Another important attribute of an ADN is the required wiring. The less wiring required, the less its weight which leads to a more fuel efficient aircraft.
Finally, the cost of an ADN's development and deployment is an important factor as well. Traditionally, ADNs have been based on new technologies
specifically developed for the purpose, thereby making the ADN development very expensive. Meanwhile, it has become much more desirable to utilize
already existing commercial technologies more or less adapted to the requirements of ADNs. The purpose of this is not only to benefit from the lower costs
of COTS equipment, but also to take advantage of the fact that COTS equipment is already field proven.
Emergence of AFDX
Prior to the Airbus 380 Aircraft, the three main ADNs were ARINC 429, MIL-STD-1553 and ARINC 629 with a maximum bandwidth of 100 Kbps, 1 Mbps and 2
Mbps, respectively. For the new generation A380, none of these ADNs would fulfil the aircraft's demanding requirements of a high available bandwidth,
minimum wiring to reduce the weight and low development cost. As a consequence, the Avionics Full Duplex Switched Ethernet (AFDX) was conceived by
Airbus and first implemented on the A380.
10
PART 66 CAT B2
Meanwhile AFDX is not only used on the A380 but also on the Airbus 400M military transport aircraft and the Boeing 787 Dreamliner, the latter, however,
with some minor extensions to the standard. Furthermore, AFDX is foreseen as the ADN backbone in the planned Airbus A350. This shows a broad
appliance and acceptance of the AFDX technology leading to reduced cost of AFDX equipment, thus making it even more attractive to deploy this
technology.
AFDX Characteristics
The AFDX standard was originally defined by Airbus in the "AFDX Detailed Functional Specification (DFS)" standard. Meanwhile the same standard also
exists as an ARINC standard which is called "ARINC 664".
As mentioned earlier, Boeing has based the ADN backbone of their 787 aircraft on the ARINC 664 standard, however with some minor extensions. The
Boeing AFDX standard is called "Interoperability Specification for the 787 End System".
AFDX is a serial data transfer method based on conventional Ethernet defined in the standard IEEE 802.3. AFDX allows for transfer rates of either 10 or 100
Mbps over either a copper or fibre optic transmission medium. Since conventional Ethernet is not a deterministic network, AFDX had to be extended to
ensure a deterministic behaviour and a high reliability in order to comply with the stringent requirements to ADNs.
AFDX ensures a deterministic behaviour through traffic control. Traffic control is achieved by guaranteeing the bandwidth of each logical communication
channel, called a Virtual Link (VL), thereby limiting the jitter and transmit latency.
To improve reliability, the AFDX standard requires each AFDX channel to be a dual redundant channel, i.e. two channels transmitting the same data stream
and at the same time. At any one time AFDX will only forward one data stream to the upper layers, and automatically exclude an erroneous data stream
from being forwarded.
With these characteristics AFDX ensures a BER as low as 10-12 while providing a bandwidth up to 100 Mbps thereby fulfilling the requirements of new
generation aircraft avionics in terms of reliability and available bandwidth.
11
PART 66 CAT B2
IMA General Layout
Thanks to the new avionics concept Integrated Modular Avionics (IMA), most of the conventional LRU functions are done by avionics “applications”. These
independent applications are hosted in shared IMA modules, called Core Processing Input/Output Modules (CPIOMs).
There are seven CPIOMs doing different types of functions. Airbus has preferred to develop what they call an “open IMA” - computing resources on which
they can have different functions hosted.
The three functional domains of the Airbus IMA model are: cockpit (electrical flight control, communications and warning); cabin (air conditioning and
pneumatics); and utilities (including energy, fuel functions and landing gear functions).
There are 30 line replaceable modules (LRMs), and 22 software functions hosted in the CPIOMs.
Each CPIOM integrates new hardware and software technologies and hosts these independent applications in the same computing and memory resource,
and also supplies an Input/Output interface service to some of the conventional avionics.
Moreover, in order to satisfy the high demand of conventional avionics, this service capability has been increased thanks to additional IMA modules called
Input/Output Modules (IOMs).
CPIOMs and IOMs are Line Replaceable Modules (LRMs).
These LRMs communicate through the Avionics Data Communication Network (ADCN) by the means of a communication technology developed from a non-
aeronautical standard, which has been adapted to aviation constraints.
This technology is called Avionics Full DupleX switched Ethernet (AFDX).
12
PART 66 CAT B2
Figure 19.3: The functional domains of Open IMA system communicate with the ADCN
13
PART 66 CAT B2
Figure 19.4: Conventional LRUs are replaced by software “Applications” loaded onto the CPIOMs
14
PART 66 CAT B2
The Controller Area Network (CAN) Bus
The CAN bus is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other within a vehicle without a host
computer.
The CAN data bus is a serial communications protocol that supports distributed real-time control with a high level of security. Controllers connected to the
CAN bus can transmit data to the bus and receive data from the bus.
The CAN bus operates at data rates of up to 1 Mb/sec for cable lengths less than 40 meters. If the cable length increases, the data rate typically falls to 125
Kb/sec for 500 meters (1,640 feet) in length. The data signal is normally transmitted on a twisted pair of wires (shielded or unshielded), but single wire and
ground, optical fibre can also be used.
Data collisions on the bus are avoided using the CSMA/AMP technique. Carrier Sense Multiple Access (CSMA) ensures that a terminal will transmit only
when the bus is quiet. If two or more terminals try to transmit at the same time, the bus arbitration logic connects the terminal with a higher-priority
message (Arbitration based on Message Priority).
Each node is able to send and receive messages, but not simultaneously. A message consists primarily of an ID (identifier), which represents the priority of
the message, and up to eight data bytes. It is transmitted serially onto the bus. This signal pattern is encoded in non-return-to-zero (NRZ) and is sensed by
all nodes.
The devices that are connected by a CAN network are typically sensors, actuators, and other control devices. These devices are not connected directly to
the bus, but through a host processor and a CAN controller.
If the bus is free, any node may begin to transmit. If two or more nodes begin sending messages at the same time, the message with the more dominant ID
(which has more dominant bits, i.e., zeroes) will overwrite other nodes' less dominant IDs, so that eventually (after this arbitration on the ID.) only the
dominant message remains and is received by all nodes. This mechanism is referred to as priority based bus arbitration. Messages with numerically smaller
values of IDs have higher priority and are transmitted first.
15
PART 66 CAT B2
Each node requires a:
• Host processor - The host processor decides what received messages mean and which messages it wants to transmit itself. Sensors, actuators and
control devices can be connected to the host processor.
• CAN controller (hardware with a synchronous clock) –
o Receiving: the CAN controller stores received bits serially from the bus until an entire message is available, which can then be fetched by
the host processor (usually after the CAN controller has triggered an interrupt).
o Sending: the host processor stores its transmit messages to a CAN controller, which transmits the bits serially onto the bus.
• Transceiver
o Receiving: it adapts signal levels from the bus to levels that the CAN controller expects and has protective circuitry that protects the CAN
controller.
o Transmitting: it converts the transmit-bit signal received from the CAN controller into a signal that is sent onto the bus.
16
PART 66 CAT B2
Use of CAN bus on the Airbus A380
To reduce the number of interconnecting wires from control panels in the flight deck to system computers in the avionics compartment, Airbus deployed
CAN bus.
A typical overhead panel like an electrical power system control panel may have about 14 to 15 switches and system- related local indicator lights, each
switch having at least six wires, totalling at least 90 wires running from the flight deck to the avionics compartment from just one control panel.
Airbus redesigned these control panels by connecting all the switches and indicators on a panel to a CAN bus controller, which is integral with the panel,
and data is transmitted using only two wires. These are called Integrated Control Panels (ICP). ICPs connect to Input/Output Modules (IOM) using CAN data
buses.
From IOMs, data is transmitted to the Avionics Data Communication Network (ADCN) using the highly reliable Avionics Full Duplex Switched Ethernet bus
(AFDX), and goes to system computer LRUs to perform the intended action. Many overhead panels are connected like this, except for flight critical systems.
Data is carried by just two wires to the CAN bus, replacing 90+ wires in older type of aeroplanes. This type of approach reduces the wiring, improves
maintenance and reduces aircraft weight.
Even though Airbus started utilizing the CAN bus extensively in the A380 to reduce wiring, the popular ARINC 429 bus is still used on the superjumbo to
interconnect radio system control panels (like VHF/HF) in the flight deck to LRUs in avionics compartments.
Currently, many of the radio communication and navigation system LRUs, including VHF/HF transceivers, ATC transponder, weather radar, ILS receivers,
VOR receivers and ADF receivers, are manufactured with an interface to the ARINC 429 bus only. There is currently no radio communications and navigation
system component manufactured to interface with CAN
bus. Many electronic engine control units, which control powerplant systems, have ARINC 429 interfaces.
This is because the ARINC 429 bus has a well-defined data structure suitable for aircraft systems. It is easy to implement and maintain, and it has a simple
transmission protocol suitable for many avionics systems.
17
PART 66 CAT B2
Avionics Data Communication Network (ADCN)
General
The Avionics Data Communication Network (ADCN) is the principal means of communication technology between avionics equipments for the Airbus A380
and aircraft of similar technology level.
ADCN is the name of the system; the technology is called Avionics Full DupleX Switched Ethernet (AFDX).
ADCN is used for the exchange of operational, maintenance and loading data between subscribers. This type of network is easily configurable and does not
require new connections in case of new messages.
The ADCN is composed of two redundant networks (A and B). Both networks are composed of AFDX switches, connected to each other with AFDX cables.
Each ADCN subscriber has an input/output interface called AFDX End System. This AFDX End System lets the subscriber send and receive AFDX frames to
and from another(s) ADCN subscriber(s).
The AFDX End System duplicates AFDX frames in transmission and keeps the first incoming valid one in reception. This duplication increases the availability
of aircraft system data by sending them simultaneously on both redundant networks A and B.
On the A380, the subscribers can communicate at 10 or 100 Mbits/s bitrates.
18
PART 66 CAT B2
Figure 19.5: Avionics Data Communication Network (ADCN)
19
PART 66 CAT B2
The Virtual Link (VL)
Aircraft system data is sent simultaneously from an ADCN subscriber to other ADCN subscriber(s) on both redundant networks A and B through AFDX
switches according to a predefined path called Virtual Link (VL).
The central feature of an AFDX network is its Virtual Links (VL). In one abstraction, it is possible to visualise the VLs as an ARINC 429 style network each with
one source and one or more destinations. Virtual Links are unidirectional logic path from the source end-system to all of the destination end-systems.
Unlike that of a traditional Ethernet switch which switches frames based on the Ethernet destination or MAC address, AFDX routes packets using a Virtual
Link ID. The Virtual Link ID is a 16-bit Unsigned integer value that follows the constant 32-bit field. The switches are designed to route an incoming frame
from one, and only one, End System to a predetermined set of End Systems. There can be one or more receiving End Systems connected within each Virtual
Link.
Each Virtual Link is allocated dedicated bandwidth with the total amount of bandwidth defined by the system integrator. However total bandwidth cannot
exceed the maximum available bandwidth on the network. Bi-directional communications must therefore require the specification of a complimentary VL.
Each VL is frozen in specification to ensure that the network has a designed maximum traffic, hence determinism. Also the switch, having a VL configuration
table loaded, can reject any erroneous data transmission that may otherwise swamp other branches of the network. Additionally, there can be sub-virtual
links (sub-VLs) that are designed to carry less critical data. Sub-virtual links are assigned to a particular Virtual Link. Data is read in a round robin sequence
among the Virtual Links with data to transmit. Also sub-virtual links do not provide guaranteed bandwidth or latency due to the buffering, but AFDX
specifies that latency is measured from the traffic regulator function anyway.
A Virtual Link is defined as one source (i.e., a Tx end-system port) and one or more destinations (i.e., Rx end-system port or ports). Virtual Links are defined
for each unidirectional path through an AFDX LAN and are assigned a MAC address. Each end-system (transmitter and receiver) is assigned a MAC address.
Each VL is assigned a maximum frame size and a minimum time between two transmissions of a frame, called the Bandwidth Allocation Gap (BAG). In this
manner, a Virtual Link is analogous to a single ARINC 429 bus in that it carries a unidirectional information stream.
20
PART 66 CAT B2
The Virtual Link (VL) is similar to a unidirectional "pipe" through the ADCN:
• carries the AFDX frame,
• It has one specific identification
• It is sent by one transmitter only
• It is received by one or more subscribers in receive mode
Each AFDX switch has a switching function. This function receives the VL coming from one emitter, routes it to the appropriate output port(s) based on the
configuration table.
To sum up, the emitter sends a VL simultaneously to both first AFDX switches (one per network), then, each AFDX switch, according to the VL identification
and its configuration table, routes the VL to the following AFDX switch and so forth till the receiver.
• A Virtual Link is uni-directional
• A Virtual Link has a unique emitter and one or more receivers
• A Virtual Link always follows a frozen route on the network
• A Virtual Link has a maximum fixed bandwidth = size/BAG
21
PART 66 CAT B2
Figure 19.6: Virtual links (VLs)
22
PART 66 CAT B2
Figure 19.7: The Virtual Link philosophy
23
PART 66 CAT B2
Core System
Core Processing Input/Output Modules (CPIOMs)
These computers are the “Modules” that form the core of the Integrated Modular system.
In the Airbus configuration for example, there are 7 types of CPIOM, each one identified by a letter (A to G). Each type is associated to a specific part
number. Within a given type, all CPIOMs are interchangeable but may require a software reconfiguration.
Each type hosts avionics applications:

• CPIOM-A: Pneumatic and optional air conditioning applications,
• CPIOM-B: Air conditioning applications,
• CPIOM-C: Cockpit and flight controls applications,
• CPIOM-D: Data link applications,
• CPIOM-E: Energy applications,
• CPIOM-F: Fuel applications,
• CPIOM-G: Landing gear applications.
CPIOM Components
A CPIOM is composed of various components, which are:
Hardware Boards
• A power supply board connected to the 28 VDC,
• 2 inputs/outputs boards connected to the aircraft systems through analogue, ARINC, Controller Area Network (CAN) and/or discrete signals,
• 1 Central Processing Unit (CPU) board supporting an AFDX END-SYSTEM board. This AFDX END-SYSTEM board supplies an AFDX interface to the
CPIOM to exchange AFDX data with the ADCN.
• Field Loadable Module Software.
24
PART 66 CAT B2
One CPIOM core software operates the module and its hosted avionics applications.
One CPIOM configuration table software gives the module and the avionics applications with the configuration data. (e.g. memory, CPU, input/output
allocations, etc.).
For each ATA Chapter, software is composed of one or more avionics applications and may include one or more databases.
Figure 19.8: CPIOM Internal components
25
PART 66 CAT B2
Figure 19.9: The sections of a CPIOM
26
PART 66 CAT B2
CPIOM - Avionics Partitions
• OPS-CT = OPerational Configuration Table, to configure the CPIOM with the actual partitions implemented on it.
• Avionics Partition: a software implementing an avionics function.
CPIOM Basic Software
• The Airbus API is based on the ARINC 653 Standard.

• CSW tables: Tables internal to the Core Software.
• A 653: ARINC 653 (Standard of API).
• DRV MNGR: Drivers manager.
• Drivers: CPU Driver, IO Driver.
• Libraries: Libraries of the OS.
• Specific services: offered by the O.S. to the System Applications.
• System partitions (software partitions similar to application partitions, but included in the CSW to have privileged access to specific services of the
OS):
o MONIT NVM = Management of the Non Volatile Memory
o Instrumentation DAtaLoad = Downloading function, compliant to ARINC 615A standard + related instrumentation
o resource BITE: Built In Test Equipment of the computer resource
o SNMP-MIB: Simple Network Management protocol-Management Information Base
• BOOT: to start the CPIOM up.
27
PART 66 CAT B2
CPIOM Hardware
• RAM, Flash, NVM (Non Volatile memory): Memories of the Avionics Computer Resource
• Partitioning control: to guarantee a complete segregation between the partitions
• Inputs / Outputs of the CPIOM (may differ on the different CPIOMs):
o I/O AFDX: Input/output on the AFDX bus (AFDX = Avionics Full DupleX)
o DGI = DiGital Input
o DGO = DiGital Output
o AN = Controller Area Network
o DSI = DiScret Input
o DSO = DiScret Ouput
o ANI = ANalogic Input
o ANO = ANalogic Output
28
PART 66 CAT B2
CPIOM Variations
Although the CPIOMs are considered the core of the “modular” system, there are some variations. The computers have eight different part numbers, the
memory and power supply cards are common to all the computers. It is only the input/output card that is different, depending on what type of system the
computer interfaces with.
Figure 19.10: CPIOM Applications
29
PART 66 CAT B2
Systems Integration
CPIOM-A
The CPIOM-A computers host the pneumatic and optional air conditioning applications, which are:
ATA 36 applications:
• The Engine Bleed Air system (EBAS),
• The Over Heat Detection System (OHDS),
• The Pneumatic Air Distribution System (PADS).
ATA 21 application:
• The Supplemental Cooling System (SCS).
CPIOM-B
The CPIOM-B computers host the air conditioning applications, which are:
• The Air Generation System (AGS),
• The Avionics Ventilation System (AVS),
• The Cabin Pressure Control System (CPCS),
• The Temperature Control System (TCS),
• The Ventilation Control System (VCS).
CPIOM-C
The CPIOM-C computers host the cockpit and flight controls applications, which are:
• The Flight Control Unit (FCU) backup,
30
PART 66 CAT B2
• The Weight and Balance Backup Computation (WBBC).
ATA 27 application:
• The Flight Control Data Concentrator (FCDC).
ATA 31 application:
• The Flight Warning System (FWS).
CPIOM-D
The CPIOM-D computers host the data link applications, which are:
ATA 46 application:
• The Air Traffic Control (ATC) system.
ATA 23 application:
• The Avionics Communication Router (ACR).
CPIOM-E
The 2 CPIOM-E computers host the energy applications, which are:
• The Circuit Breaker Monitoring System (CBMS),
• The Electrical Load Management System (ELMS),
• The Electrical System Bite (ESB).
CPIOM-F
The 4 CPIOM-F computers host the fuel applications, which are:
31
PART 66 CAT B2
• The fuel CG measurement,
• The fuel measurement,
• The fuel management.
• The fuel system BITE,
• The fuel CG measurement,
• The fuel integrity,
• The fuel monitor.
CPIOM-G
The 4 CPIOM-G computers host the landing gear applications, which are:
• The braking control system,
• The steering control system,
• The Landing Gear Extension and Retraction System (LGERS),
• The steering control system BITE.
• The braking control system,
• The steering control system,
• The LGERS High (HI),
• The landing gear monitoring system,
• The braking control system BITE,
• The LGERS BITE,
• The landing gear monitoring system BITE.
32
PART 66 CAT B2
Example CPIOM Interface with an Aircraft System

Figure 19.11 shows how the Avionics Ventilation System (AVS) application (as loaded onto one of the CPIOMs) interfaces with and controls the many
components of the aircraft ventilation and cabin pressurisation system components.
Figure 19.11: CPIOM interface with the air conditioning system
33
PART 66 CAT B2
Input / Output Modules (IOM)

An IOM is used on some functions whenever an LRU needs to dialogue with other ADCN subscribers via the ADCN. Note that the CPIOM incorporates its
own IOM.
In normal operation, the IOMs convert the aircraft system data sent and received by LRUs directly connected to them from non-AFDX into AFDX format and
vice versa.
The “Mirror” IOM Principle

On the Airbus A380, used as an example, there are 8 IOMs connected tothe ADCN. There are 4 IOMs on side 1 and 4 IOMs on side 2.
The IOM 1/3/5/7 are all "mirror" IOMs of IOM 2/4/6/8 and vice versa.
An LRU such as a computer, sensor, etc., that exchanges message with the ADCN subscribers must use both "mirror" IOMs.
For an aircraft system composed of more than one LRU (e.g.: Navigation system), each LRU (e.g. Rad Alt) of this system dialogs through "mirror" IOMs
different from those used by the other LRUs.
Thus, the LRU and the ADCN subscriber both send or receive redundant messages.
In case of one IOM loss, the communication between a LRU and an ADCN subscriber is not lost thanks to the "mirror" IOM.
34
PART 66 CAT B2
Figure 19.12: “Mirror” IOM principle
35
PART 66 CAT B2
IOM Components
An IOM is composed of various components, which are:
Hardware boards
• A power supply board connected to the 28 VDC,
• 2 inputs/outputs boards connected to the aircraft systems through analogue, ARINC, CAN and/or discrete signals,
• 1 CPU board supporting an AFDX END SYSTEM board. This AFDX END SYSTEM board lets the IOM exchange AFDX data with the ADCN.
• Field Loadable Module Software
• One IOM operational program software that mainly assumes the gateway function between the non-AFDX data to AFDX data and vice versa.
• One IOM configuration table software provides the module with configuration data. (e.g. input/output allocations, etc.)
36
PART 66 CAT B2
Figure 19.13: IOM internal components
IOM Software
An IOM does not host avionics applications.
The IOMs host the module software, which are:
• The IOM operational program software,
• The IOM configuration table software.
All IOMs are fully interchangeable.
37
PART 66 CAT B2
Component Failures
Loss of CPIOM
In case of CPIOM failure, only the cockpit effect related to the loss of its hosted applications is annunciated, not to the loss of the CPIOM itself.
Figure 19.14: CPIOM failure
Single IOM Loss
In case of a single IOM loss, only its mirror IOM is converting the aircraft system data.
It is a class 4 fault. If this failure is not repaired prior to 1000 flight hours, it becomes a class 1 level 1 fault.
There is no functional effect on aircraft systems.
According to the Master Minimum Equipment List (MMEL) this failure is a GO with a specified rectification interval.
38
PART 66 CAT B2
Figure 19.15: Single loss of IOM
39
PART 66 CAT B2
Multiple "Non-Mirror" IOMs Loss

In case of loss of multiple "non-mirror" IOMs, only their "mirror" IOMs convert the aircraft system data.
It is a class 1 level 1 fault.
There is no functional effect on aircraft systems. According to the Master Minimum Equipment List (MMEL) this failure is a NO GO.
Figure 19.16: Multiple “Non-Mirror” IOM Loss
40
PART 66 CAT B2
Multiple "Mirror" IOMs Loss

In case of loss of multiple "mirror" IOMs, the aircraft system data sent and received by LRUs connected to them are lost.
There is a functional effect on aircraft systems. According to the Master Minimum Equipment List (MMEL) this failure is a NO GO.
Figure 19.17: Multiple “Mirror” IOM loss
41
PART 66 CAT B2
Network Components
General Description
The system gathers the aircraft systems supplied within specific functional areas, related to:
• Flight Controls and Auto Flight,
• Cockpit,
• Engines control,
• Energy (electrical power),
• Pneumatic and Cabin,
• Fuel,
• Landing Gear.
These functional areas group computers like LRUs, IOMs, CPIOMs and/or LRUs with AFDX interface that share a common interest or characteristics.
These computers exchange operational and maintenance data between each other. For most of them, this exchange is done through the Avionics Data
Communication Network (ADCN). The ADCN is composed of two redundant networks, A and B. Both networks are composed of a number of AFDX switches,
connected to each other with AFDX cables.
The ADCN uses AFDX technology based on the Ethernet protocol adapted for in-flight use. It is used for the exchange of operational, maintenance and
loading data between the ADCN subscribers, which are LRUs with AFDX interface and the LRMs.
The subscribers can communicate at speeds 10 or 100 Mbits/s. This type of network is extensible and does not need specific connections for new
subscribers.
In case of total network failure, all essential data transmission is backed up using ARINC 429 databus systems.
42
PART 66 CAT B2
Figure 19.18: Avionics Data Communication Network (ADCN) interfaces
43
PART 66 CAT B2
Data Transmission using ADCN

Aircraft system data are sent simultaneously from an ADCN subscriber to another ADCN subscriber(s) on both redundant network A and B through AFDX
switches according to predefined paths called Virtual Links (VL).
Figure 19.19: Data transmission using ADCN
44
PART 66 CAT B2
AFDX Switch Components

An AFDX switch is composed of various components, which are:
• Hardware Boards
• A power supply board connected to the 28 VDC bus,
• A switching board, which routes the AFDX frames according to a configuration table,
• An inputs/outputs board connected to other AFDX switches and ADCN subscribers.
• Field Loadable Module Software
• One AFDX SW operational program software that operates the module.
• One AFDX SW configuration table software that provides the AFDX switch with configuration data. (e.g. switching board configuration, etc.)
Figure 19.20: AFDX Switch internal components
45
PART 66 CAT B2
AFDX Switch Software

The AFDX switches host the following software:
• The AFDX SW operational program software,
• The AFDX SW configuration table software.
All AFDX switches are interchangeable but may require software reconfiguration.
46
PART 66 CAT B2
ADCN failures
Normal Operation
In normal operation, the Virtual Link (VL) is transmitted onto both redundant networks A and B.
Single AFDX Switch Loss

In case of a single AFDX switch loss, the non-degraded network is transmitting the aircraft system data.
There is no functional effect on aircraft systems. According to the Master Minimum Equipment List (MMEL) this failure is a GO with a specified rectification
interval.
47
PART 66 CAT B2
Figure 19.21: Single AFDX switch loss
48
PART 66 CAT B2
Multiple AFDX Switches Loss (Same Network)

In case of multiple AFDX switches loss (two or more) on the same network (A or B), the non-degraded network is transmitting the aircraft system data.
It is a class 1 level, 1 fault.
There is no functional effect on aircraft systems. According to the Master Minimum Equipment List (MMEL) this failure is a NO GO.
Figure 19.22: Multiple AFDX switch loss (same network)
49
PART 66 CAT B2
Multiple AFDX Switches Loss (Both Networks)

In case of multiple AFDX switches loss (two or more) on both networks, aircraft system data is partially or no more transmitted.
It is a class 1 level, 2 fault.
There is a functional effect on aircraft systems. According to the Master Minimum Equipment List (MMEL) this failure is a NO GO.
Figure 19.23: Multiple AFDX switch loss (both networks)
50
PART 66 CAT B2
All AFDX Switches Loss

In the case of all AFDX switches loss, aircraft system data is not transmitted.
It is a class 1 level 2 fault. There is therefore a functional effect on aircraft systems. According to the Master Minimum Equipment List (MMEL) this failure is
a NO GO.
Note: The aircraft can still be safely operated thanks to the backup interconnections of the main aircraft systems (mainly using ARINC 429 buses).
Figure 19.24: All AFDX switches loss
51
PART 66 CAT B2
Single AFDX Cable Loss

In case of a single AFDX cables loss, the non-degraded network is transmitting the aircraft system data.
There is no functional effect on aircraft systems. According to Master Minimum Equipment List (MMEL) this failure is a GO with a specified rectification
interval.
Figure 19.25: Single AFDX cable loss
52
PART 66 CAT B2
Multiple AFDX Cables Loss

In case of multiple AFDX cables loss (two or more), the aircraft system data is partially transmitted or not transmitted at all.
There might be a functional effect on aircraft systems. According to the Master Minimum Equipment List (MMEL) this failure is a NO GO.
Figure 19.26: Multiple AFDX cable loss
Other Specific Failures

There are some specific double switch faults which, although occurring simultaneously, do not degrade performance enough to cause a No-GO. Such
combinational failures will be specified in the AMM.
53
PART 66 CAT B2
Combining Technologies
General
As we have seen, conventional avionics (LRUs) exist alongside the new technology (IMA) avionics. The LRUs also have to dialogue with the new technology
Applications, via non-AFDX methods.
Figure 19.27: AFDX and non-AFDX subscribers communicating with the CPIOM
54
PART 66 CAT B2
Common Remote Data Concentrator (CRDC)

The CRDCs collect, convert and exchange data between the ADCN and LRUs that do not have the AFDX technology and that are mostly installed out of the
avionics compartment.
Figure 19.28: Non-AFDX to AFDX converting resource
55
PART 66 CAT B2
Figure 19.29: LRUs with AFDX capability and LRUs with no AFDX capability
56
PART 66 CAT B2
Example Implementation – Fuel Measurement and Management System on the Airbus A380
The Airbus A380 features an Integrated Modular Avionics (IMA) suite comprising a number of Central Processor Input/Output Modules (CPIOM) units
interconnected by an Avionics Full Duplex (AFDX) switched Ethernet digital data bus to both operate and communicate between the numerous aircraft
systems that include the Fuel Measurement and Management System.
Figure 19.30: Fuel Measurement and Management System (FMMS) architecture overview.
57
PART 66 CAT B2
The CPIOMs are arranged in pairs to form computing lanes. Each lane is configured with one CPIOM designated as the 'Command' (COM) channel while the
other CPIOM designated as the 'Monitor’ (MON) channel. Each of the two fuel system computing lanes is capable of performing all of the system functions
with one of the two lanes designated as the 'Primary' lane controlling the system while the other lane operates as a 'Standby'. The functional health of each
lane is continually assessed by the BITE software within each MON channel and should the health of the primary lane deteriorate to a level below that of
the standby lane, control of the system is switched over to the standby lane.
Each lane interfaces with the two Fuel Quantity Data Concentrators (FQDCs) which interface with the in-tank equipment.
The four CPIOMs interconnect with the data concentrators (FQDCs) and the Integrated Refuel Panel (IRP).
58
PART 66 CAT B2
Figure 19.31: Fuel Measurement and Management System avionics architecture
59
PART 66 CAT B2
Each pair of fuel system CPIOMs within the IMA suite execute FMMS software with the COM and MON functions partitioned. The fuel system supplier is
responsible for the functionality of the embedded software in the CPIOMs.
Figure 19.32: CPIOM software partitioning
60

Module 13.20 Integrated Modular Avionics (Ata 42)

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Module 13.20 Integrated Modular Avionics (Ata 42)

Uploaded by

Copyright:

Available Formats

PART 66 CAT B2

MODULE 13 AIRCRAFT AERODYNAMICS, STRUCTURES & SYSTEMS (AVIONICS)

MODULE 13.20: INTEGRATED MODULAR AVIONICS (ATA

Module 11.19/13.20 Integrated Modular Avionics (ATA 42) __________________________________________________________________________ 1

Aircraft Data Networks _____________________________________________________________________________________________________ 10

IMA General Layout ________________________________________________________________________________________________________ 12

The Controller Area Network (CAN) Bus ________________________________________________________________________________________ 15

Avionics Data Communication Network (ADCN) _________________________________________________________________________________ 18

Core System ______________________________________________________________________________________________________________ 24

CPIOM Variations _______________________________________________________________________________________________________ 29

Combining Technologies _______________________________________________________________________________________________________ 54

Module 11.19/13.20 Integrated Modular Avionics (ATA 42)

Integrated Modular Avionics (IMA) Concept

The Need for IMA

Avionics Full-Duplex Switched Ethernet (AFDX)

Figure 19.1: Traditional federated architecture approach

Figure 19.2: Modular avionics approach

Aircraft Data Networks

Aircraft Data Network (ADN) Characteristics

IMA General Layout

CPIOMs and IOMs are Line Replaceable Modules (LRMs).

This technology is called Avionics Full DupleX switched Ethernet (AFDX).

The Controller Area Network (CAN) Bus

Each node requires a:

• CAN controller (hardware with a synchronous clock) –

Use of CAN bus on the Airbus A380

Avionics Data Communication Network (ADCN)

On the A380, the subscribers can communicate at 10 or 100 Mbits/s bitrates.

Figure 19.5: Avionics Data Communication Network (ADCN)

The Virtual Link (VL)

Figure 19.6: Virtual links (VLs)

Figure 19.7: The Virtual Link philosophy

Core Processing Input/Output Modules (CPIOMs)

Each type hosts avionics applications:

A CPIOM is composed of various components, which are:

Figure 19.8: CPIOM Internal components

Figure 19.9: The sections of a CPIOM

CPIOM - Avionics Partitions

CPIOM Basic Software

• The Airbus API is based on the ARINC 653 Standard.

Figure 19.10: CPIOM Applications

• The Weight and Balance Backup Computation (WBBC).

Example CPIOM Interface with an Aircraft System

Figure 19.11: CPIOM interface with the air conditioning system

Input / Output Modules (IOM)

The “Mirror” IOM Principle

Figure 19.12: “Mirror” IOM principle

Figure 19.13: IOM internal components

Figure 19.14: CPIOM failure

Single IOM Loss

Figure 19.15: Single loss of IOM

Multiple "Non-Mirror" IOMs Loss

Figure 19.16: Multiple “Non-Mirror” IOM Loss

Multiple "Mirror" IOMs Loss

Figure 19.17: Multiple “Mirror” IOM loss

Figure 19.18: Avionics Data Communication Network (ADCN) interfaces

Data Transmission using ADCN

Figure 19.19: Data transmission using ADCN

AFDX Switch Components

Figure 19.20: AFDX Switch internal components

AFDX Switch Software

Single AFDX Switch Loss

Figure 19.21: Single AFDX switch loss