11.19 integrated modular avionics

Module 11A

Turbine Aeroplane Aerodynamics,

Structures and Systems

11.19 Integrated Modular Avionics (ATA 42)

19-2 Module 11.19 Integrated Modular Avionics (ATA 42) AFAQ Institute of Aviation Technology © Copyright 2012

Issue 2 – October 2012

Intentionally Blank

19-3Module 11.19 Integrated Modular Avionics (ATA 42)

Issue 2 – October 2012 AFAQ Institute of Aviation Technology

© Copyright 2012

Copyright Notice © Copyright. All worldwide rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form by any other means whatsoever: i.e. photocopy, electronic, mechanical recording or otherwise without the prior written permission of AFAQ Institute of Aviation Technology.

Knowledge Levels — Category A, B1, B2, B3 and C Aircraft Maintenance Licence Basic knowledge for categories A, B1, B2 and B3 are indicated by the allocation of knowledge levels indicators (1, 2 or 3) against each applicable subject. Category C applicants must meet either the category B1 or the category B2 basic knowledge levels. The knowledge level indicators are defined as follows:

LEVEL 1 A familiarisation with the principal elements of the subject.

Objectives: The applicant should be familiar with the basic elements of the subject. The applicant should be able to give a simple description of the whole subject, using common words and

examples. The applicant should be able to use typical terms.

LEVEL 2 A general knowledge of the theoretical and practical aspects of the subject. An ability to apply that knowledge.

Objectives: The applicant should be able to understand the theoretical fundamentals of the subject. The applicant should be able to give a general description of the subject using, as appropriate, typical

examples. The applicant should be able to use mathematical formulae in conjunction with physical laws describing the

subject. The applicant should be able to read and understand sketches, drawings and schematics describing the

subject. The applicant should be able to apply his knowledge in a practical manner using detailed procedures.

LEVEL 3 A detailed knowledge of the theoretical and practical aspects of the subject. A capacity to combine and apply the separate elements of knowledge in a logical and comprehensive

manner. Objectives: The applicant should know the theory of the subject and interrelationships with other subjects.

The applicant should be able to give a detailed description of the subject using theoretical fundamentals and specific examples.

The applicant should understand and be able to use mathematical formulae related to the subject. The applicant should be able to read, understand and prepare sketches, simple drawings and schematics

describing the subject. The applicant should be able to apply his knowledge in a practical manner using manufacturer's

instructions. The applicant should be able to interpret results from various sources and measurements and apply

corrective action where appropriate.



Intentionally Blank



© Copyright 2012

Table of Contents

Module 13.20 Integrated Modular Avionics (ATA 42) _______________________________ 9 Terminology ______________________________________________________________ 9 Integrated Modular Avionics (IMA) Concept ___________________________________ 11

The Need for IMA________________________________________________________ 11 Avionics Full-Duplex Switched Ethernet (AFDX) ________________________________ 12 AFDX Applications _______________________________________________________ 13 IMA Advantages_________________________________________________________ 13 Manufacturer’s Approaches ________________________________________________ 16

Aircraft Data Networks ____________________________________________________ 17 Aircraft Data Network (ADN) Characteristics ___________________________________ 17 Emergence of AFDX _____________________________________________________ 17 AFDX Characteristics _____________________________________________________ 18

IMA General Layout _______________________________________________________ 19 The Controller Area Network (CAN) Bus ______________________________________ 23 Avionics Data Communication Network (ADCN) _______________________________ 25

General _______________________________________________________________ 25 The Virtual Link (VL) _____________________________________________________ 27

Core System ____________________________________________________________ 31 Core Processing Input/Output Modules (CPIOMs) ______________________________ 31 CPIOM Components _____________________________________________________ 31 CPIOM Variations _______________________________________________________ 35 Systems Integration ______________________________________________________ 36 Example CPIOM Interface with an Aircraft System ______________________________ 38 Input / Output Modules (IOM)_______________________________________________ 39 Component Failures ______________________________________________________ 42

Network Components _____________________________________________________ 47 General Description ______________________________________________________ 47 AFDX Switch Components ________________________________________________ 50 AFDX Switch Software ____________________________________________________ 50 ADCN failures __________________________________________________________ 51

Combining Technologies __________________________________________________ 58 General _______________________________________________________________ 58 Common Remote Data Concentrator (CRDC) __________________________________ 59

Example Implementation – Fuel Measurement and Management System on the Airbus A380 ___________________________________________________________________ 61



Intentionally Blank



© Copyright 2012

Module 11.19 Enabling Objectives and Certification Statement Certification Statement These Study Notes comply with the syllabus of EASA Regulation (EC) No.2042/2003 Annex III (Part-66) Appendix I, as amended by Regulation (EC) No.1149/2011, and the associated Knowledge Levels as specified below:

Objective Part-66 Reference

Licence Category A B1.1

Integrated Modular Avionics (ATA 42) 11.19 1 2 Functions that may be typically integrated in the Integrated Modular Avionic (IMA) modules are, among others: Bleed Management, Air Pressure Control, Air Ventilation and Control, Avionics and Cockpit Ventilation Control, Temperature Control, Air Traffic Communication, Avionics Communication Router, Electrical Load Management, Circuit Breaker Monitoring, Electrical System BITE, Fuel Management, Braking Control, Steering Control, Landing Gear Extension and Retraction, Tyre Pressure Indication, Oleo Pressure Indication, Brake Temperature Monitoring, etc.;

Core System; Network Components.



Intentionally Blank



© Copyright 2012

Module 11.19 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 a 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. 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.



© Copyright 2012

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.



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. 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



© Copyright 2012

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.

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 buses 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.

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.



© Copyright 2012

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.



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.



© Copyright 2012

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. 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.



© Copyright 2012

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).



Figure 19.3: The functional domains of Open IMA system communicate with the ADCN



© Copyright 2012

Figure 19.4: Conventional LRUs are replaced by software “Applications” loaded onto the CPIOMs



Intentionally Blank



© Copyright 2012

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. 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.

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.



© Copyright 2012

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.



Figure 19.5: Avionics Data Communication Network (ADCN)



© Copyright 2012

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. 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

Figure 19.6: Virtual links (VLs)



© Copyright 2012

Figure 19.7: The Virtual Link philosophy



Intentionally Blank



© Copyright 2012

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. 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



© Copyright 2012

Figure 19.9: The sections of a CPIOM

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.

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



© Copyright 2012

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



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 OverHeat 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: ATA 21 applications:

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: ATA 22 applications:

The Flight Control Unit (FCU) backup, 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).



© Copyright 2012

CPIOM-E The 2 CPIOM-E computers host the energy applications, which are: ATA 24 applications:

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: ATA 28 applications:

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: ATA 32 applications:

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.



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



© Copyright 2012

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 to the 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.



Figure 19.12: “Mirror” IOM principle



© Copyright 2012

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.)

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.



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.



© Copyright 2012

Figure 19.15: Single loss of IOM



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



© Copyright 2012

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. 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.17: Multiple “Mirror” IOM loss



Intentionally Blank



© Copyright 2012

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.



Figure 19.18: Avionics Data Communication Network (ADCN) interfaces



© Copyright 2012

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



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

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.



© Copyright 2012

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. It is a class 4 fault. If this failure is not repaired prior to 1000 flight hours, it becomes a class 1 level 1fault. 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.



Figure 19.21: Single AFDX switch loss



© Copyright 2012

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)



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)



© Copyright 2012

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



Single AFDX Cable Loss In case of a single AFDX cables loss, the non-degraded network is transmitting 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 Master Minimum Equipment List (MMEL) this failure is a GO with a specified rectification interval.

Figure 19.25: Single AFDX cable loss



© Copyright 2012

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. It is a class 1 level 1 fault. 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.



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



© Copyright 2012

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



Figure 19.29: LRUs with AFDX capability and LRUs with no AFDX capability



© Copyright 2012

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. 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).

Figure 19.31: Fuel Measurement and Management System avionics architecture 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.



Intentionally Blank

11.19 integrated modular avionics

Engineering