MASTER OF SCIENCE IN EMBEDDED SYSTEMS DESIGN
REQUIREMENTS ENGINEERING
REPORT ON
INTEGRATED MODULAR AVIONICS
(DO-297/ED-124)
Under the Guidance of
Prof. Dr.-Ing. Karsten Peter
Submitted by
NAME OF THE CANDIDATE(S)
MATRICULATION NO.
1. NIKHIL UMESH DANTKALE
36199
2. SATHEESH KUMAR RAJU KONDURU
36207
3. GOVARDHANA REDDY CHILAKALA
36213
Date of submission: 23rd November 2018
WS - 2018-19
TABLE OF CONTENTS
1
INTRODUCTION ............................................................................................................... 11
2
AIRCRAFT AVIONIC SYSTEMS.................................................................................... 11
2.1
Communications Systems .............................................................................................. 11
2.2
Navigation Systems ........................................................................................................ 11
2.3
Monitoring systems ........................................................................................................ 12
2.4
Aircraft flight-control systems ....................................................................................... 12
2.5
Collision-avoidance systems .......................................................................................... 12
2.6
Flight recorders systems ................................................................................................. 12
2.7
Weather systems ............................................................................................................. 12
2.8
Aircraft management systems ........................................................................................ 13
2.9
Transitioning from Federated Avionics Architectures to Integrated Modular Avionics 13
2.10 Architectural differences between FEDERATED and IMA Systems ........................... 13
2.11 Benefits of Transitioning to Integrated Modular Avionics (IMA) ................................. 14
3
2.11.1
IMA Optimizes the Allocation of Spare Computing Resources ............................. 14
2.11.2
IMA Optimizes Physical Equipment Weight and Power Consumption ................. 15
2.11.3
IMA Consolidates Development Efforts ................................................................ 15
2.11.4
IMA Architectures Increases Development Efficiency and Market Competition .. 15
INTRODUCTION TO DO-297 .......................................................................................... 16
3.1
Integrated Modular Avionics Overview ......................................................................... 16
3.1.1
IMA Design Terminology....................................................................................... 17
3.1.2
IMA Certification Terminology.............................................................................. 18
3.2
Architectural Considerations .......................................................................................... 19
3.3
Key Characteristics ........................................................................................................ 20
3.3.1
Shared Resources .................................................................................................... 20
3.3.2
Robust Partitioning ................................................................................................. 21
3.3.3
Application Programming Interface (API) ............................................................. 21
3.3.4
Health Monitoring and Fault Management ............................................................. 21
3.4
Stakeholders ................................................................................................................... 22
3.4.1
Certification Authority ............................................................................................ 22
3.4.2
Certification Applicant............................................................................................ 22
3.4.3
IMA System Integrator ........................................................................................... 22
Integrated Modular Avionics (IMA)
Page |1
4
3.4.4
Platform and Module Suppliers .............................................................................. 22
3.4.5
Application Supplier ............................................................................................... 23
3.4.6
Maintenance Organization ...................................................................................... 23
GENERAL DEVELOPMENT CONSIDERATIONS...................................................... 23
4.1
IMA System Development Process................................................................................ 24
4.1.1
IMA Platform Development Process ...................................................................... 24
4.1.2
Hosted Application Development Process.............................................................. 25
4.1.3
IMA System Development Process ........................................................................ 25
4.2
IMA Resource Allocation Activities .............................................................................. 25
4.3
Aircraft Safety and Security ........................................................................................... 26
4.4
Development Assurance and Tool Assurance ................................................................ 26
4.5
Partitioning and Resource Management Activities ........................................................ 26
4.5.1
Design of Robust Partitioning................................................................................. 27
4.5.2
Partitioning Analysis ............................................................................................... 28
4.6
Health Monitoring and Fault Management .................................................................... 28
4.6.1
Components and Aspects to be monitored.............................................................. 28
4.6.2
Health determination of each Application .............................................................. 28
4.6.3
Health Determination of the IMA System as a Whole ........................................... 29
4.6.4
Response to Each Type of Failure .......................................................................... 29
4.6.5
Flight Crew Annunciation and Messaging ............................................................. 29
4.6.6
Control of Maintenance Actions and Reporting ..................................................... 29
4.6.7
Redundancy Management ....................................................................................... 30
4.6.8
Single Event Upset (SEU) faults............................................................................. 30
4.7
IMA System Configuration Management ...................................................................... 30
4.7.1
Configuration Data.................................................................................................. 31
4.8
Guidance on use of shared databases ............................................................................. 31
4.9
Master Minimum Equipment List (MMEL) .................................................................. 31
4.9.1
Design Considerations for MMEL.......................................................................... 32
4.9.2
Approval Considerations for an MMEL ................................................................. 32
4.10 Human Factors Considerations ...................................................................................... 32
5
CERTIFICATION TASKS ................................................................................................ 33
5.1
Overview of the certification process............................................................................. 33
5.2
Module Acceptance (Task 1) ......................................................................................... 33
Integrated Modular Avionics (IMA)
Page |2
5.2.1
Module Acceptance Objectives .............................................................................. 34
5.2.2
Module Acceptance Data ........................................................................................ 34
5.2.3
Module Acceptance Plan (MAP) ............................................................................ 34
5.2.4
Module Requirements Specification (MRS) ........................................................... 35
5.2.5
Module Validation and Verification (V&V) Data .................................................. 35
5.2.6
Module Quality Assurance (QA) Records .............................................................. 35
5.2.7
Module Configuration Index (MCI) ....................................................................... 35
5.2.8
Module Acceptance Accomplishment Summary (MAAS) .................................... 35
5.2.9
Module Acceptance Data Sheet (MADS) ............................................................... 36
5.3
5.3.1
Application Acceptance Objectives ........................................................................ 36
5.3.2
Application Acceptance Data ................................................................................. 36
5.4
IMA System Acceptance (Task 3) ................................................................................. 36
5.4.1
IMA System Acceptance Objectives ...................................................................... 36
5.4.2
IMA System Acceptance Data ................................................................................ 37
5.4.3
IMA System Configuration Index (IMASCI) ......................................................... 37
5.5
Aircraft Integration of IMA system (Including V&V) (Task 4) .................................... 37
5.5.1
Aircraft Integration Objectives ............................................................................... 37
5.5.2
Aircraft Level IMA System Compliance Data ....................................................... 38
5.5.3
Aircraft Level IMA Validation & Verification Plan............................................... 38
5.5.4
Aircraft Level IMA System Configuration Index (IMASCI) ................................. 38
5.6
Change (Task 5) ............................................................................................................. 38
5.6.1
Changes to IMA System Modules, Resources and Applications ........................... 38
5.6.2
Change Objectives .................................................................................................. 38
5.6.3
Change Management Process ................................................................................. 38
5.6.4
Change Impact Analysis (CIA) ............................................................................... 39
5.6.5
Change Data ............................................................................................................ 39
5.7
6
Application Acceptance (Task 2) ................................................................................... 36
Reuse of Modules or Applications (Task 6)................................................................... 39
5.7.1
Objectives of the Reuse Process ............................................................................. 39
5.7.2
Reuse of a Software Module or Application........................................................... 40
5.7.3
Reuse of a Complex Electronic Hardware Module or Application ........................ 40
5.7.4
Reuse of Environmental Qualification Test Data ................................................... 40
INTEGRAL PROCESSES.................................................................................................. 40
Integrated Modular Avionics (IMA)
Page |3
6.1
Responsibilities of the Certification Applicant .............................................................. 41
6.2
Responsibilities of the IMA System Integrator .............................................................. 41
6.3
Responsibilities of the IMA Platform Supplier .............................................................. 41
6.4
Responsibilities of the Application Supplier.................................................................. 42
6.5
Safety Assessment Activities ......................................................................................... 42
6.5.1
Functional Hazard Assessment (FHA) ................................................................... 42
6.5.2
Preliminary System Safety Assessment (PSSA)..................................................... 42
6.5.3
System Safety Assessment (SSA) ........................................................................... 43
6.5.4
Common Cause Analysis for IMA Systems ........................................................... 44
6.5.5
Failure Mode Analysis ............................................................................................ 44
6.5.6
Fault Management, Health Monitoring, and Redundancy Management ................ 45
6.5.7
Partitioning Analysis ............................................................................................... 45
6.5.8
Network Security .................................................................................................... 45
6.6
System Development Assurance .................................................................................... 46
6.6.1
Software Guidance .................................................................................................. 46
6.6.2
Electronic Hardware Guidance ............................................................................... 46
6.6.3
Integration Tool Qualification ................................................................................ 46
6.7
Validation ....................................................................................................................... 46
6.8
Verification..................................................................................................................... 47
6.9
Configuration Management (CM).................................................................................. 47
6.10 Quality Assurance (QA) ................................................................................................. 48
6.11 Certification Liaison ....................................................................................................... 48
6.12 Development Life Cycle Data ........................................................................................ 48
6.13 Certification Liaison Process When Changes are Made ................................................ 49
6.14 Certification Liaison Process for Reuse of Modules ...................................................... 49
7
8
CONSIDERATIONS FOR CONTINUED AIRWORTHINESS OF IMA SYSTEMS . 49
7.1
Training .......................................................................................................................... 50
7.2
Maintenance ................................................................................................................... 50
7.3
Post-Certification Modifications .................................................................................... 51
COMMUNICATION BUS PROTOCOLS FOR AVIONIC SYSTEMS........................ 51
8.1
ARINIC 429 Specification Overview ............................................................................ 52
8.2
Cable Characteristics ...................................................................................................... 53
8.3
Transmission Characteristics.......................................................................................... 53
Integrated Modular Avionics (IMA)
Page |4
9
8.4
Waveform Parameters .................................................................................................... 55
8.5
Word Formats ................................................................................................................. 55
8.5.1
Parity ....................................................................................................................... 56
8.5.2
Sign/Status Matrix .................................................................................................. 56
8.5.3
Data ......................................................................................................................... 57
8.5.4
Source/Destination Identifier .................................................................................. 57
8.5.5
Label ....................................................................................................................... 57
8.6
Protection from interference........................................................................................... 58
8.7
Design Assurance Level (DAL) for ARINIC 429 ......................................................... 58
8.8
Pros and Cons of ARINC 429 ........................................................................................ 59
MIL-STD-1553 ..................................................................................................................... 60
9.1
Introduction .................................................................................................................... 60
9.2
MIL-STD-1553 Characteristics...................................................................................... 60
9.3
Hardware Elements ........................................................................................................ 61
9.4
Bus Topology ................................................................................................................. 62
9.5
Coupling ......................................................................................................................... 63
9.6
Word Formats ................................................................................................................. 65
9.7
Bus Protocols.................................................................................................................. 66
9.8
Error Management.......................................................................................................... 68
9.9
Fault Isolation................................................................................................................. 69
9.10 MIL-STD-1553 Test Procedures .................................................................................... 69
9.11 MIL-STD-1553 Test Plans ............................................................................................. 70
9.12 Design Assurance Level (DAL) for MIL-STD-1553..................................................... 70
10 AFDX/ARINC664 ................................................................................................................ 71
10.1 AFDX/ARINC 664 Antecedents .................................................................................... 71
10.2 AFDX/ARINC 664 Introduction.................................................................................... 71
10.2.1
Avionics Subsystem ................................................................................................ 72
10.2.2
AFDX End System (End System)........................................................................... 72
10.2.3
AFDX Interconnect:................................................................................................ 72
10.3 Ethernet .......................................................................................................................... 73
10.3.1
Ethernet Introduction .............................................................................................. 73
10.3.2
Ethernet Frame format ............................................................................................ 73
10.3.3
Half-duplex mode Switched Ethernet ..................................................................... 74
Integrated Modular Avionics (IMA)
Page |5
10.3.4
Full-duplex Switched Ethernet ............................................................................... 74
10.4 AFDX vs. ARINC 429 Architecture .............................................................................. 75
10.4.1
End Systems and Avionics Subsystems .................................................................. 76
10.4.2
AFDX Communications Ports ................................................................................ 77
10.5 Virtual Links: Packet Routing in AFDX ........................................................................ 78
10.6 Message Flows ............................................................................................................... 79
10.7 Redundancy Management .............................................................................................. 80
10.8 Virtual Link Isolation ..................................................................................................... 82
10.8.1
Choosing the BAG and Lmax for a Virtual Link ................................................... 83
10.9 Virtual Link Scheduling ................................................................................................. 83
10.10
Jitter ............................................................................................................................ 84
10.11
AFDX Message Structures ......................................................................................... 85
10.12
Pros and Cons of AFDX ............................................................................................. 86
11 AVIONICS COMPUTING ................................................................................................. 87
11.1 The Nature of an Avionics Computer ............................................................................ 88
11.2 CPIOMs .......................................................................................................................... 90
11.2.1
CPIOMs Introduction.............................................................................................. 90
11.2.2
CPIOMs Physical Arrangement .............................................................................. 92
11.3 Implementation Example: Airbus A380 ........................................................................ 93
11.4 Design Assurance Level (DAL) for CPIOMs ................................................................ 96
12 CONCLUSION .................................................................................................................... 97
REFERENCES ............................................................................................................................ 98
Integrated Modular Avionics (IMA)
Page |6
LIST OF FIGURES
Figure 1: Comparison of an Example Federated and IMA Architecture ...................................... 14
Figure 2: Chapters and their relationships .................................................................................... 16
Figure 3: Relationships of IMA Design Terms............................................................................. 18
Figure 4: Example of typical design highlighting potential shared resources .............................. 23
Figure 5 : IMA system certification tasks illustration .................................................................. 33
Figure 6 : Life Cycle data for IMA Systems................................................................................. 49
Figure 7: ARINC 429 Bus Topology ............................................................................................ 52
Figure 8: ARINC 429 Cable Characteristics ................................................................................ 53
Figure 9: ARINC 429 Signal Encoding ........................................................................................ 54
Figure 10: ARINC 429 Signal Waveform Parameters ................................................................. 55
Figure 11: ARINC 429 Word Format ........................................................................................... 56
Figure 12: ARINC 429 Data Format ............................................................................................ 57
Figure 13: ARINC 429 Label Bit Structure .................................................................................. 57
Figure 14: ARINC 429 IP Core on FPGA .................................................................................... 59
Figure 15 : Data Bus Architecture ................................................................................................ 62
Figure 16: Single Level Bus Topology ......................................................................................... 63
Figure 17 : Multi Level Bus Topology ......................................................................................... 63
Figure 18 : Direct Coupling .......................................................................................................... 64
Figure 19 : Transformer Coupling ................................................................................................ 65
Figure 20 : Word Format ............................................................................................................. 66
Figure 21 : BC to RT transaction protocol.................................................................................... 67
Figure 22 : RT to BC transaction protocol.................................................................................... 67
Figure 23 : RT to RT transaction protocol .................................................................................... 68
Figure 24: AFDX Network ........................................................................................................... 72
Figure 25: Ethernet Local Area Network...................................................................................... 73
Figure 26: Ethernet Local Area Network...................................................................................... 74
Figure 27: Full-Duplex, Switched Ethernet Example ................................................................... 75
Figure 28: AFDX vs. ARINC 429 Architecture ........................................................................... 76
Figure 29: End Systems and Avionics Subsystems Example ....................................................... 77
Figure 30:Sampling port at receiver ............................................................................................. 78
Figure 31: Queuing port at receiver .............................................................................................. 78
Figure 32: Format of Ethernet Destination Address in AFDX Network ...................................... 79
Figure 33: Format of Ethernet Destination Address in AFDX Network ...................................... 79
Figure 34: Message Sent to Port 1 by the Avionics Subsystem ................................................... 80
Figure 35: Ethernet Frame with IP and UDP Headers and Payloads ........................................... 80
Figure 36: A and B Networks ....................................................................................................... 81
Figure 37: AFDX Frame and Sequence Number .......................................................................... 81
Figure 38: Receive Processing of Ethernet Frames ...................................................................... 82
Figure 39: Three Virtual Links Carried by a Physical Link ......................................................... 82
Figure 40: Virtual Link Scheduling .............................................................................................. 84
Figure 41: Role of Virtual Link Regulation .................................................................................. 85
Figure 42: Message Structure ....................................................................................................... 86
Integrated Modular Avionics (IMA)
Page |7
Figure 43: Typical Computer Architecture ................................................................................... 89
Figure 44: Airbus A380 avionics architecture .............................................................................. 90
Figure 45: CPIOM architecture .................................................................................................... 91
Figure 46: Airbus A380 CPIOM physical arrangement ............................................................... 92
Figure 47: Airbus A380 CPIOM responsibilities ......................................................................... 93
Figure 48: Airbus A380 utilities domain IMA implementation ................................................... 94
Figure 49: Top view of CPIOM topology..................................................................................... 95
Figure 50 : Design Assurance Levels (DAL) ............................................................................... 96
LIST OF TABLES
Table 1: ARINC 429 Signal states ................................................................................................ 54
Table 2 : ARINC 429 signal waveform parameters...................................................................... 55
Table 3:Sign/Status Matrix Encoding ........................................................................................... 56
Table 4: Characteristics of MIL-STD-1553 .................................................................................. 61
Table 5 : Test Plans ....................................................................................................................... 70
Table 6: Comparison between Communication bus protocols ..................................................... 97
Integrated Modular Avionics (IMA)
Page |8
LIST OF ABBREVIATIONS AND ACRONYMS
AC
ADN
AFDX
AMOC
AMJ
APP
API
ARINC
ARP
ASTC
ATC
ATM
BIT(E)
CCA
CEH
CIA
CM
CMA
CNS
COTS
CPU
CRC
CS
DO
EUROCAE
EASA
ED
e.g.
EQTP
EQT
ETSO
FAA
FAR
FHA
FLS
FM
GPS
HAS
HF
HIRF
HM
H/W
ICAO
ICAW
Advisory Circular
Aircraft Data Network
Avionics Full Duplex Switched Ethernet
Acceptable Means of Compliance
Advisory Material - Joint
Application
Application Programming Interface
Aeronautical Radio Incorporated
Aerospace Recommended Practice
Amended Supplemental Type Certificate
Amended Type Certificate
Air Traffic Management
Built-In Test (Equipment)
Common Cause Analysis
Complex Electronic Hardware
Change Impact Analysis
Configuration Management
Common Mode Analysis
Communication, Navigation and Surveillance
Commercial Off-The-Shelf
Central Processing Unit
Cyclic Redundancy Check
Certification Specification
RTCA Document
European Organization for Civil Aviation Equipment
European Aviation Safety Agency
EUROCAE Document
For example
Environmental Qualification Test Plan
Environmental Qualification Test
European Technical Standard Order
Federal Aviation Administration
Federal Aviation Regulation
Functional Hazard Assessment
Field-Loadable Software
Fault Management
Global Positioning System
Hardware Accomplishment Summary
High Frequency
High Intensity Radiated Field
Health Monitor
Hardware
International Civil Aviation Organization
Instructions for Continued Airworthiness
Integrated Modular Avionics (IMA)
Page |9
IEEE
IEL
IMA
IMAS
IMASAS
IMASCI
IMASCMP
IMASCP
IMASQAP
I/O
JAA
JAR
LRU
MAP
MMEL
MMU
MAAS
MADS
MRS
MTTR
MTFF
OS
PHAC
PSAC
PSSA
QA
RSC
RTCA
SAE
SATCOM
SAS
SCI
SEU
SI
SSA
STC
S/W
TC
TSO
UMS
V&V
WAAS
Institute of Electrical and Electronic Engineers
Indirect Effects of Lightning
Integrated Modular Avionics
Integrated Modular Avionics System
Integrated Modular Avionics System Accomplishment Summary
Integrated Modular Avionics System Configuration Index
Integrated Modular Avionics System Configuration Management Plan
Integrated Modular Avionics System Certification Plan
Integrated Modular Avionics System Quality Assurance Plan
Input and/or Output
Joint Aviation Authority
Joint Aviation Requirement
Line Replaceable Unit
Module Acceptance Plan
Master Minimum Equipment List
Memory Management Unit
Module Acceptance Accomplishment Summary
Module Acceptance Data Sheet
Module Requirements Specification
Mean Time To Repair
Mean Time to First Failure
Operating System
Plan for Hardware Aspects of Certification
Plan for Software Aspects of Certification
Preliminary System Safety Assessment
Quality Assurance
Reusable Software Component
Radio Technical Commission for Aeronautics
Society of Automotive Engineers
Satellite Communication
Software Accomplishment Summary
Software Configuration Index
Single Event Upset
System Integrator
System Safety Assessment
Supplemental Type Certification
Software
Type Certification
Technical Standard Order
User-Modifiable Software
Validation and Verification
Wide Area Augmentation System
Integrated Modular Avionics (IMA)
P a g e | 10
1 INTRODUCTION
Avionics is the cornerstone of modern aircraft. More and more, vital functions on both military
and civil aircraft involve electronic devices. After the cost of the airframe and the engines,
avionics is the most expensive item on the aircraft, but well worth every cent of the price.
Many technologies emerged in the last decade that will be utilized in the new millennium. After
proof of soundness in design through ground application, advanced microprocessors are finding
their way onto aircraft to provide new capabilities that were unheard of a decade ago. The Global
Positioning System has enabled satellite-based precise navigation and landing, and
communication satellites are now capable of supporting aviation services. Thus, the aviation
world is changing to satellite-based communications, navigation, and surveillance for air traffic
management. Both the aircraft operator and the air traffic services provider are realizing
significant benefits.
In this report, we are about to explain the Integrated Modular Avionics (IMA), Guidelines and
Certification of IMA Systems as per DO-297/ED-24, Core Processing Input/output Module
(CPIOMs) and communication buses like ARINC 429, MIL-STD-1553, AFDX/ARINC664.
2 AIRCRAFT AVIONIC SYSTEMS
The cockpit of an aircraft is a typical location for avionic equipment, including control,
monitoring, communication, navigation, weather, and anti-collision systems. The majority of
aircraft power their avionics using 14- or 28-volt DC electrical systems. However, larger, more
sophisticated aircraft (such as airliners or military combat aircraft) have AC systems operating at
400 Hz, 115 volts AC. The major Avionic systems in Aircrafts are as follows:
2.1 Communications Systems
Communications connect the flight deck to the ground and the flight deck to the passengers.
On‑board communications are provided by public-address systems and aircraft intercoms. The
VHF aviation communication system works on the air band of 118.000 MHz to 136.975 MHz.
Each channel is spaced from the adjacent ones by 8.33 kHz in Europe, 25 kHz elsewhere. VHF is
also used for line of sight communication such as aircraft-to-aircraft and aircraft-to-ATC.
Aircraft communication can also take place using HF (especially for trans-oceanic flights) or
satellite communication.
2.2 Navigation Systems
Air navigation is the determination of position and direction on or above the surface of the Earth.
Avionics can use satellite navigation systems (such as GPS and WAAS), ground-based radio
navigation systems or any combination thereof. Navigation systems calculate the position
automatically and display it to the flight crew on moving map displays. Older avionics required a
pilot or navigator to plot the intersection of signals on a paper map to determine an aircraft's
location; modern systems calculate the position automatically and display it to the flight crew on
moving map displays.
Integrated Modular Avionics (IMA)
P a g e | 11
2.3 Monitoring systems
The first hints of glass cockpits emerged in the 1970s when flight-worthy cathode ray
tube (CRT) screens began to replace electromechanical displays, gauges and instruments. A
"glass" cockpit refers to the use of computer monitors instead of gauges and other analog
displays. Aircraft were getting progressively more displays, dials and information dashboards
that eventually competed for space and pilot attention.
2.4 Aircraft flight-control systems
Aircraft have means of automatically controlling flight. The first simple commercial auto-pilots
were used to control heading and altitude and had limited authority on things
like thrust and flight control surfaces. In helicopters, auto-stabilization was used in a similar way.
The first systems were electromechanical. The advent of fly by wire and electro-actuated flight
surfaces (rather than the traditional hydraulic) has increased safety. As with displays and
instruments, critical devices that were electro-mechanical had a finite life. With safety critical
systems, the software is very strictly tested.
2.5 Collision-avoidance systems
To supplement air traffic control, most large transport aircraft and many smaller ones use
a traffic alert and collision avoidance system (TCAS), which can detect the location of nearby
aircraft, and provide instructions for avoiding a midair collision. Smaller aircraft may use
simpler traffic alerting systems such as TPAS, which are passive (they do not actively interrogate
the transponders of other aircraft) and do not provide advisories for conflict resolution.
To help avoid controlled flight into terrain (CFIT), aircraft use systems such as ground-proximity
warning systems (GPWS), which use radar altimeters as a key element. One of the major
weaknesses of GPWS is the lack of "look-ahead" information, because it only provides altitude
above terrain "look-down". In order to overcome this weakness, modern aircraft use a terrain
awareness warning system (TAWS).
2.6 Flight recorders systems
Commercial aircraft cockpit data recorders, commonly known as "black boxes", store flight
information and audio from the cockpit. They are often recovered from an aircraft after a crash to
determine control settings and other parameters during the incident.
2.7 Weather systems
Weather systems such as weather radar (typically ARINC 708 on commercial aircraft)
and lightning detectors are important for aircraft flying at night or in instrument meteorological
conditions, where it is not possible for pilots to see the weather ahead. Heavy precipitation (as
sensed by radar) or severe turbulence(as sensed by lightning activity) are both indications of
strong convective activity and severe turbulence, and weather systems allow pilots to deviate
around these areas. Lightning detectors like the Storm scope or Strike finder have become
inexpensive enough that they are practical for light aircraft. In addition to radar and lightning
detection, observations and extended radar pictures (such as NEXRAD) are now available
through satellite data connections, allowing pilots to see weather conditions far beyond the range
Integrated Modular Avionics (IMA)
P a g e | 12
of their own in-flight systems. Modern displays allow weather information to be integrated with
moving maps, terrain, and traffic onto a single screen, greatly simplifying navigation.
2.8 Aircraft management systems
There has been a progression towards centralized control of the multiple complex systems fitted
to aircraft, including engine monitoring and management. Health and usage monitoring systems
(HUMS) are integrated with aircraft management computers to give maintainers early warnings
of parts that will need replacement. The integrated modular avionics concept proposes an
integrated architecture with application software portable across an assembly of common
hardware modules. It has been used in fourth generation jet fighters and the latest generation of
airliners.
2.9 Transitioning from Federated Avionics Architectures to Integrated Modular Avionics
Airframers are working harder than ever to reduce the weight and power consumption for their
new aircraft. The market is challenging them to accomplish this with reduced development
expenses and design cycle times. These objectives are being sought while system complexity is
increasing as part of the race to achieve competitive advantage. Avionics architectures are no
exception to this industry trend. By adding an extra stage of complexity through architectural
optimization mechanisms, the suite of avionics systems on an aircraft can be made to achieve
these objectives. An IMA architecture is a solution that allows the airframer to optimize their
avionics implementations to achieve reduced weight and power targets.
IMA is a shared set of flexible, reusable, and interoperable hardware and software resources that,
when integrated, form a platform that provides services, designed and verified to a defined set of
safety and performance requirements, to host applications performing aircraft functions.
2.10
Architectural differences between FEDERATED and IMA Systems
IMA architectures provide a shared computing, communications, and I/O resource pool that is
partitioned for use by multiple avionics functions. The avionics functions that are hosted on the
IMA platform can consist of differing design assurance criticalities due to the robust partitioning
mechanisms that are inherent to the architecture. In contrast, federated avionics architectures
implement independent collections of dedicated computing resources (computing processor,
communications and I/O) for each avionics function typically contained in separate Line
Replaceable Units (LRUs) or Line Replaceable Modules (LRMs).
Figure 1 depicts an example federated and IMA architecture. The fundamental difference
between the two architectures is the ability for an IMA system to optimize the total set of
computing resources. Consider this example of a simple system that consists of a user interface
defined by controls, a display, and a graphical processing unit (GPU). This user interface is used
to control an effector based upon feedback collected from a sensor. In a federated environment,
these are developed as three separate units connected by dedicated communication channels. As
shown in the IMA example, the optimized set of shared computing resources uses fewer physical
resources when compared to the federated system that hosts an equivalent set of functions. The
Integrated Modular Avionics (IMA)
P a g e | 13
quantity of Central Processing Units (CPUs) is reduced from three to one. The communication
interfaces are reduced from five to four. Finally, the number of physical communication channels
is reduced from four to one.
Figure 1: Comparison of an Example Federated and IMA Architecture
2.11
Benefits of Transitioning to Integrated Modular Avionics (IMA)
An IMA architecture allows the system integrator to optimize the total set of computing
resources. The benefits to IMA are rooted in these optimization capabilities.
2.11.1 IMA Optimizes the Allocation of Spare Computing Resources
Within an IMA architecture, the shared computing resources are allocated to the Hosted
Functions using configuration tables. These shared resources include the computing processor(s),
common communications network, and common I/O unit(s). During the allocation process, the
system integrator maintains the flexibility to dynamically manage spare resources through the
manipulation of the configuration tables. The system integrator could allocate spare resources to
each individual Hosted Function, which is akin to the spare allocation process for the federated
environment. IMA adds the additional capability to reserve a spare resource pool that can be
allocated to any Hosted Function that is sharing the resource. This gives the system integrator the
Integrated Modular Avionics (IMA)
P a g e | 14
dynamic ability to increase or decrease the resource allocation for a given Hosted Function in the
future, or to add a new Hosted Function without adding new computing resources. Typically, the
system integrator will allocate a nominal resource spare to each Hosted Function, which may be
less than would be allocated in the federated environment. Then the system integrator would
reserve a resource pool that can later be allocated (in part or whole) to any Hosted Function.
2.11.2 IMA Optimizes Physical Equipment Weight and Power Consumption
Since IMA makes use of shared computing resources, the circuitry that once was contained
within each federated LRU/LRM is now contained within a common IMA platform. Computing
processors that were duplicated in each federated LRU/LRM are replaced by a common set of
IMA processors (and the associated infrastructure such as power, cooling, and redundancy
mechanisms). Dedicated communication channels are replaced with a common communication
channel (and the associated wiring). Dedicated I/O interfaces are replaced with a common I/O
interface (and the associated wiring).
Separate LRU/LRMs can still exist in an IMA environment, but they only contain unique
resource capability that cannot be provided by the IMA computing platform in most cases. The
computing functionality can be removed at the LRU/LRM level. The LRUs/LRMs essentially
become “dumb terminals” that provide extensions to the standard IMA computing capabilities.
The consolidation of the hardware and associated cooling and wiring translates to a reduction in
the required physical resources. Reduced physical resources translate to weight and power
savings for the overall aircraft.
2.11.3 IMA Consolidates Development Efforts
Consolidation of hardware leads to the consolidation of development efforts, which saves time,
money, and program risk. Developers of an avionics function no longer need to spend time
developing their computing resources. In the simplest case, consider a Hosted Function
developer in a federated environment that was responsible for developing a computer processor
architecture and its associated operating system, as well as a software development/test
environment to host their software enabled avionics function. In an IMA environment, this same
developer relies upon a common processor and does not need to develop a separate processor
architecture. In this example, the developer can focus wholly on their hosted software, which not
only eases their development burdens, but also their certification efforts. All of these savings
translate to reduced development expenses and design cycle times. The same benefits of
consolidation exist for the users of the common I/O modules and the common communication
network.
2.11.4 IMA Architectures Increases Development Efficiency and Market Competition
Open IMA architectures provide additional efficiency in the development effort. The distinction
of “Open IMA” indicates that the architecture takes advantage of “open” system interfaces
whose specifications are available and accepted by the suppliers that participate in the public
domain. Open system architectures foster competitive, cost-effective development efforts by
capitalizing on existing industry experience with nonproprietary interfaces and portable IMA
elements developed for these open interfaces. The open systems interface provides an
Integrated Modular Avionics (IMA)
P a g e | 15
environment where multiple organizations can work simultaneously to achieve an overall
reduced development expense and a reduced time-to-market.
3
INTRODUCTION TO DO-297
The use of Integrated Modular Avionics (IMA) is rapidly expanding and is found in all classes of
aircraft. DO-297 was prepared jointly by RTCA Special Committee (SC-200) and EUROCAE
Working Group 60 and approved by the RTCA Program Management Committee (PMC) on
November 8, 2005. The European Organization for Civil Aviation Equipment (EUROCAE) has
designated the document as ED-124. Any reference in this chapter to DO-297 also infers ED124. As of press time ED-124 has not been approved by the EUROCAE Council and has not
been released by it. DO-297, however, is available. This document contains guidance for
Integrated Modular Avionics (IMA) developers, application developers, integrators, certification
applicants, and those involved in the approval and continued airworthiness of IMA systems in
civil certification projects. The guidance describes the objectives, processes, and activities for
those involved in the development and integration of IMA modules, applications, and systems to
incrementally accumulate design assurance toward the installation and approval of an IMA
system.
DO-297 contains six chapters (see figure 2):
Figure 2: Chapters and their relationships
3.1 Integrated Modular Avionics Overview
It provides a description of an IMA system. It introduces terminology that applies to IMA and
describes the relationship of terms. It has both IMA Design and Certification terminology.
Integrated Modular Avionics (IMA)
P a g e | 16
3.1.1 IMA Design Terminology
Aircraft Function – The capability of the aircraft that may be provided by the hardware and
software of the systems on the aircraft. Functions include flight control, autopilot, braking, fuel
management, flight instruments, etc. IMA has the potential to broaden the definition of avionics
to include any aircraft function.
Application - Software and/or application-specific hardware with a defined set of interfaces that,
when integrated with a platform, performs a function.
Component - A self-contained hardware part, software part, database, or combination thereof
that is configuration controlled. A component does not provide an aircraft function by itself.
Core Software - The operating system and support software that manage resources to provide an
environment in which applications can execute. Core software is a necessary component of a
platform and is typically comprised of one or more modules.
IMA System – Consists of an IMA platform(s) and a defined set of hosted applications.
Interoperable – The capability of several integrated modules to operate together to accomplish a
specific goal or function. This requires defined interface boundaries between the modules and
allows the use of other interoperable components. To describe this concept in physical terms, an
IMA platform may include interoperable modules and components such as physical devices
(processor, memory, electrical power, Input/Output(I/O) devices), and logical elements, such as
an operating system, and communication software.
Module – A component or collection of components that may be accepted by themselves or in
the context of IMA. A module may also comprise other modules. A module may be software,
hardware, or a combination of hardware and software, which provides resources to the IMAhosted applications. Modules may be distributed across the aircraft or may be co-located.
Partitioning - An architectural technique to provide the necessary separation and independence
of functions or applications to ensure that only intended coupling occurs. The mechanisms for
providing the protection in an IMA platform are specified to a required level of integrity.
Platform - Module or group of modules, including core software, that manages resources in a
manner enough to support at least one application. IMA hardware resources and core software
are designed and managed in a way to provide computational, communication, and interface
capabilities for hosting at least one application. Platforms, by themselves, do not provide any
aircraft functionality. The platform establishes a computing environment, support services, and
platform-related capabilities, such as health monitoring and fault management. The IMA
platform may be accepted independently of hosted applications.
Resource - Any object (processor, memory, software, data, etc.) or component used by an IMA
platform or application. A resource may be shared by multiple applications or dedicated to a
specific application. A resource may be physical (a hardware device) or logical (a piece of
information).
Integrated Modular Avionics (IMA)
P a g e | 17
Reusable - The design assurance data of previously accepted modules and applications may be
used in a subsequent aircraft system design with reduced need for redesign or additional
acceptance.
The relationship between terminology is shown in figure 3.
Figure 3: Relationships of IMA Design Terms
3.1.2 IMA Certification Terminology
A primary purpose of this document is to provide a means of compliance for IMA systems
seeking acceptance, approval, and certification of their installation on an aircraft. To accomplish
this, it is important to understand the certification terminology. The primary certification terms
relevant to IMA are defined below:
Certification - Legal recognition by a certification authority that a product, service, organization,
or person complies with the requirements. Such certification includes the activities of technically
checking the product, service, organization, or person, and a formal recognition of compliance
with the applicable regulations and airworthiness requirements by issuance of a certificate,
license, approval, or other documents as required by national laws and procedures. Certification
of a product includes:
Integrated Modular Avionics (IMA)
P a g e | 18
a. the certification applicant process of assessing the design of a product and demonstrating
to the certification authority that it complies with the applicable regulations and a set of
standards applicable to that type of product to demonstrate an acceptable level of safety.
b. the process of assessing products to ensure they conform with the approved type design
for that product.
c. the certification authority process of finding compliance and the issuance of a certificate
required by national laws to declare that compliance and/or conformity has been found
with standards in accordance with items a or b above.
TSO Authorization - Legal recognition by the certification authority that a system, equipment, or
part satisfies the TSO requirements and minimum specification applicable for that equipment.
This term is equally applicable to European TSO (ETSO) authorizations.
Acceptance – Acknowledgement by the certification authority that the module, application, or
system complies with its defined requirements. Acceptance is recognition by the certification
authority (typically in the form of a letter or stamped data sheet) signifying that the submission
of data, justification, or claim of equivalence satisfies applicable guidance or requirements.
Approval – The act or instance of giving formal or official acknowledgement of compliance with
regulations. In the context of IMA there are typically two forms of approval:
a. approval of submitted life cycle data by the certification authority (usually demonstrated
by issuance of a stamped and signed data item or a letter),
b. installation approval by the issuance of an aircraft or engine type certificate and/or
airworthiness certificate.
Incremental acceptance - A process for obtaining credit toward approval and certification by
accepting or finding that an IMA module, application, and/or off-aircraft IMA system complies
with specific requirements. This incremental acceptance is divided into tasks. Credit granted for
individual tasks contributes to the overall certification goal. Incremental acceptance provides the
ability to integrate and accept new applications and/or modules, in an IMA system, and maintain
existing applications and/or modules without the need for re-acceptance.
3.2 Architectural Considerations
An IMA system architecture is composed of one or more platforms and includes interfaces to
other aircraft systems and users (for example, flight crew, maintenance personnel, etc.). The
allocation of aircraft functions should be addressed in the IMA system architecture to ensure that
applicable availability, integrity, and safety requirements are satisfied. Some of the primary
considerations are listed and described below:
a. Availability considerations


Functional performance – allocation of hosted aircraft functions to the IMA
system architecture.
Resource management – allocation of IMA platform resources, control of shared
and dedicated resources, and protection of IMA platform resources used by
multiple hosted aircraft functions or applications.
Integrated Modular Avionics (IMA)
P a g e | 19


Reliability and maintainability – impact on Master Minimum Equipment List
(MMEL), aircraft dispatchability, repair, replacement, and ease of performing
maintenance activities to ensure continued airworthiness.
Health monitoring – monitoring the condition of the system and operational and
maintenance concerns
b. Integrity considerations

Design assurance, IMA safety and protection features, fault detection and
partitioning - ability to protect hosted functions and applications to ensure
independence and to prevent unintended interactions while using shared
resources.
c. Safety considerations

Safety assessment - ensure appropriate architecture, design assurance, failure
protection, address common mode and impact of combinational failures of aircraft
functions, and airworthiness
d. Fault management, fault reporting, and recovery actions – detecting and identifying
faults, failures and anomalous behavior, and providing appropriate responses.
e. Composability considerations


An IMA platform is composable if integration of a new application will not
invalidate any verified requirements of an already integrated application.
In a composable architecture, system requirements follow from requirements
allocated to IMA applications. An IMA platform with well-defined interface
boundaries may be composable with respect to partial acceptance of integrated
applications.
3.3 Key Characteristics
The key characteristics of IMA platforms and hosted applications influence the IMA system
architecture, the detailed system design, and, ultimately, the IMA platform and system
acceptance process. Sections 3.3.1 through 3.3.4 summarize the characteristics of IMA platforms
that affect the certification process.
3.3.1 Shared Resources
IMA systems may host several applications that share resources. For example, resources may be
shared by the method of access time. This applies to processing resources and hardware. Each
shared resource has the potential to become a single point failure that can affect all applications
using that resource. Accordingly, appropriate mitigation techniques should be applied as
determined by the system safety assessment process.
Integrated Modular Avionics (IMA)
P a g e | 20
Processing resource refers to a physical element that may contain Central Processing Unit(s)
(CPU), memory and associated interfaces. Memory can store machine-readable computer
programs and associated data. The IMA hosted applications will communicate using shared
resources provided by the IMA platform (for example, I/O devices, data buses, shared memory,
etc.). A resource or portion of a resource can be allocated per unit time (for example, processor
cycles or communication bandwidth). The IMA platform provides resource management
capabilities for shared resources, as well as health monitoring and fault management capabilities
to support the protection of shared resources.
3.3.2 Robust Partitioning
Robust partitioning is a means for assuring the intended isolation of independent aircraft
functions and applications residing in IMA shared resources in the presence of design errors and
hardware failures that are unique to a partition or associated with application specific hardware.
If a (different) failure can lead to the loss of robust partitioning, then it should be detectable and
appropriate action taken. The objective of robust partitioning is to provide the same level of
functional, if not physical, isolation and protection as a federated implementation. This means
robust partitioning should support the cooperative coexistence of core software and applications
hosted on a processor and using shared resources, while assuring unauthorized or unintended
interference is prevented. Robust partitioning should meet the following information guidelines:
a. A software partition should not be allowed to contaminate the code, I/O, or data storage
areas of another partition.
b. A software partition should be allowed to consume shared processor resources only
during its allocated time.
c. A software partition should be allowed to consume only its allocation of shared I/O
resources.
d. Failures of hardware unique to a software partition should not cause adverse effects on
other software partitions.
The platform robust partitioning protection mechanisms are independent of any hosted
applications, that is, applications cannot alter the partitioning protection provided by the
platform.
3.3.3 Application Programming Interface (API)
An API defines the standard interfaces between the platform and the hosted applications and
provides the means to communicate between applications and to use I/O capabilities. ARINC
653 Parts 1 and 2 provide an avionics standard for an application programming interface and the
related services.
3.3.4 Health Monitoring and Fault Management
Health monitoring and fault management (HM/FM) functions deserve special attention due to the
integration of multiple applications and resource sharing. IMA systems manage platform faults,
hardware failures, partitioning violations, and errors and anomalous behavior of hosted
applications, including common mode faults and cascading failures. The methods used to
manage platform faults are independent of the hosted applications. Fault management consists of
Integrated Modular Avionics (IMA)
P a g e | 21
detecting faults, failures and errors, correctly identifying them when they occur and performing
the appropriate response. The IMA platform provides health monitoring and fault management
capabilities for the platform and hosted applications. The IMA system may have to provide
higher level (aircraft function) health monitoring and fault management capabilities to support
availability and integrity requirements.
3.4 Stakeholders
The assignment of roles and responsibilities is necessary and should address the entire IMA
system life cycle from conceptual design to retirement. These assignments may be based on the
underlying IMA system architecture and should include the responsibility for selecting and
providing tools. These assignments should be stated in the IMA system project plans, such as the
IMA System Certification Plan and supporting lower-level plans.
3.4.1 Certification Authority
The certification authority is the organization(s) granting approval on behalf of the state(s)
responsible for aircraft and/or engine certification.
3.4.2 Certification Applicant
The applicant is responsible for demonstrating compliance to the applicable aviation regulations,
and is seeking a Type Certificate (TC), Amended TC (ATC), Supplemental Type Certificate
(STC) or Amended STC (ASTC). The applicant is responsible for generating and validating all
aircraft-level requirements and their allocation to subsystems, providing installation instructions
for the configured IMA system, integrating it with other aircraft systems, and, where appropriate,
installing it on the aircraft. The applicant is ultimately responsible for ensuring that the installed
IMA system and the aircraft comply with applicable regulations and are airworthy. The applicant
will perform the necessary development activities to define aircraft-level functions to be
implemented and the necessary V&V activities on the system after it is installed in the aircraft.
The applicant is also responsible for continued airworthiness.
3.4.3 IMA System Integrator
The IMA system integrator performs the activities necessary to integrate the platform(s) and
hosted applications to produce the IMA system. Typical data developed during IMA system
integration includes:
a. The system configuration consisting of the number, type, and specific versions of
modules and hosted applications.
b. The shared resource allocation and configuration tables for the integrated IMA system.
c. Results of IMA system V&V, including performance data for the IMA system, consistent
with the allocated requirements.
3.4.4 Platform and Module Suppliers
The IMA platform and module suppliers provide the processing hardware and software
resources, including the core software. Development and configuration tools are provided to
support use of the IMA platform or module. Typical data developed during platform and module
development includes:
a. Specification of the interfaces to the IMA platform and modules.
Integrated Modular Avionics (IMA)
P a g e | 22
b. Specification of the shared resource allocation and configuration tables.
c. Required resources and configuration data for the IMA platform, including core
software.
d. Results of module and/or platform V&V, including performance data, consistent with
allocated requirements.
3.4.5 Application Supplier
The application supplier develops the hosted application and verifies it on the IMA platform. The
application supplier should ensure that any hardware or software resources that are unique to the
hosted application meet the integrity and availability requirements consistent with the assigned
failure condition classification, as determined by the aircraft safety assessment. Typical data
developed during application development includes:
a. Specification of external interfaces required by the application.
b. Required resources and configuration data for the hosted application.
c. Results of application/platform integration V&V, including performance data, consistent
with allocated requirements.
3.4.6 Maintenance Organization
The maintenance organization follows the approved procedures received from the certification
applicant to keep the IMA system and the aircraft in an airworthy condition.
4 GENERAL DEVELOPMENT CONSIDERATIONS
The development of an IMA system is based on an IMA platform containing hardware and
software that are common and can be shared by the hosted applications. Figure 4 shows an
example of a typical design highlighting potential shared resources. The shaded areas identify the
modules that may be shared.
Figure 4: Example of typical design highlighting potential shared resources
Integrated Modular Avionics (IMA)
P a g e | 23
An IMA development process should ensure the following:
a. Aircraft functions allocated to a specific IMA system are consistent with the design of the
system
b. Aircraft safety and security requirements allocated to a specific IMA system are
identified and have been satisfied by the IMA system design.
c. Behavior of any hosted application is prevented from adversely affecting the behavior of
any other application or function by the design of the IMA platform.
d. Health monitoring, failure reporting process, and fault management functions are
provided for the platform to meet specified requirements of the hosted applications and
IMA system.
e. Configuration management for the IMA platform, applications, integrator, and
certification applicant are established and maintained.
f. Human factors requirements pertaining to the IMA system are implemented and verified.
4.1 IMA System Development Process
The overall development process for an IMA system should follow a structured process, such as
ARP 4754/ED-79. The IMA system development process should consider the primary
characteristics of IMA which are flexible, reusable, and interoperable. These characteristics
influence the development process which should address,
a. The IMA platform – Definition of reusable, sharable modules and resources
b. The hosted applications – Definition of the interfaces and system contracts to allow a
given hosted application to reside on the given platform
c. The IMA system – Integration of the specific set of hosted applications onto a given IMA
platform(s)
The following terms will be used when outlining the development process
a. IMA platform consists of the IMA modules and core software without any aircraft
functions or applications installed
b. IMA platform architecture refers to the means of structuring, connecting and
combining IMA modules to support the requirements of the hosted applications and
aircraft functions
c. IMA system consists of the IMA platform(s) and the hosted applications
d. IMA system architecture consists of the IMA platform(s), connections and components
required to meet the requirements of all the hosted applications and aircraft functions
4.1.1 IMA Platform Development Process
The IMA platform may be defined and developed separately from the specific aircraft functions
and the hosted applications. One of the primary goals of IMA is to develop an IMA platform that
can be reused on different aircraft and with different hosted applications. A reusable IMA
platform should be developed using the process objectives described below.
a. Plan and Define the IMA platform
b. Define the IMA platform requirements, including
Integrated Modular Avionics (IMA)
P a g e | 24
c. Develop and implement the IMA platform design. The software and hardware
development processes should follow DO-178/ED-12and DO-254/ED-80 respectively.
Additionally, common cause analysis (CCA) should be performed and qualitative failure
analysis for the various top-level events defined for the platform should be developed.
d. Verify and validate the IMA platform.
4.1.2 Hosted Application Development Process
Development of hosted applications follows the same development processes used in non-IMA
systems, but should contain these objectives
a. Identify IMA platform resources to be used
b. Quantify required IMA platform resources
c. Map hosted application safety assessment to IMA platform safety assessment and
capabilities (i.e., Preliminary System Safety Assessment (PSSA), Functional Hazard
Assessment (FHA), and Common Cause Analysis (CCA)).
d. Define HM/FM requirements for the hosted application and define interactions with IMA
platform HM/FM functions.
e. Identify dedicated resources peripheral to the IMA platform.
f. Specify environmental qualification level for dedicated resources.
g. Integrate application onto the platform and perform software/platform integration testing.
h. Assess human factors requirements against IMA platform performance
4.1.3 IMA System Development Process
a. Identify aircraft functions, including functional, performance, safety, availability, and
integrity requirements.
b. Allocate IMA platform resources to the aircraft functions considering the aircraft level
FHA, resource requirements (interface specifications), safety capabilities of the IMA
platform, and MMEL considerations
c. Develop the IMA system architecture
d. Implement the IMA system
e. Integrate, validate, verify, and obtain acceptance of the IMA system (off aircraft).
f. Where appropriate, integrate, validate, verify, and obtain acceptance of the IMA system
installed on the aircraft.
4.2 IMA Resource Allocation Activities
The aircraft functional and performance requirements influence the allocation of IMA hosted
functions. In addition to the specific aircraft functions, several issues may need to be addressed
including provisions for computing resource availability, application-specific I/O resources,
network bandwidth, and meeting the safety, integrity and reliability requirements.
a. Processing throughput for an IMA system should address the required execution time of
the applications, the context switch times, the platform overhead, and the overall
processing requirements.
Integrated Modular Avionics (IMA)
P a g e | 25
b. The amount of computing resource and network bandwidth should address overhead
(including partitioning enforcement, processing, and data bus jitter and traffic) associated
with context switching, data scheduling, and other constraints.
c. Satisfying the safety requirements for the aircraft, the IMA platform and hosted
applications define the integrity and availability requirements of the functions allocated
and the configuration of the IMA system.
4.3 Aircraft Safety and Security
Safety requirements should be addressed in the IMA system requirements. These requirements
drive the system configuration and the allocation of functions and hosted applications to IMA
resources, and establish the independence, availability, and integrity requirements for those
hosted applications contributing to the aircraft functions. Requirements derived from the safety
assessment and the security analyses are distinguished from functional requirements. Security
requirements should be addressed at the aircraft-level safety assessment. IMA mechanisms may
be used to address security concerns.
4.4 Development Assurance and Tool Assurance
The IMA system and components should be designed and developed to the highest assurance
levels needed to support the safety, integrity, and availability requirements of the aircraft
functions and hosted applications intended for the IMA system as determined by the IMA system
safety assessment. This may be difficult to determine for a “general purpose” IMA platform
intended to be used on multiple aircraft types with unknown sets of aircraft functions and hosted
applications. Therefore, to reduce the risk for a specific aircraft type and configuration of hosted
applications, the IMA system developer may want to develop their system to a specific assurance
level.
4.5 Partitioning and Resource Management Activities
A primary goal of IMA is to integrate and host multiple aircraft functions and applications on
one or more computing platform(s) while ensuring that any one aircraft function is not able to
affect another function in an undefined or unacceptable way. Furthermore, failures of the
mechanisms that enforce and maintain this independence should be detectable and mitigated to
ensure the required levels of safety and integrity.
Partitioning within an IMA system should allow independent applications to share resources
without any unintended interactions. While the concept of partitioning is used in many
commercial computer-based systems, the usual implementations would not provide the degree of
protection needed in safety-related systems. Thus, “robust partitioning” is defined to distinguish
partitioning for IMA systems.
The characteristics of robust partitioning are:
a. The partitioning services should provide adequate separation and isolation of the aircraft
functions and hosted applications sharing platform resources.
Integrated Modular Avionics (IMA)
P a g e | 26
b. The ability to determine in real-time, with an appropriate level of confidence, that the
partitioning services are performing as specified consistent with the defined level of
safety.
c. Partitioning services should not rely on any required behavior of any aircraft function or
hosted application
Partitioning analysis and design should conform to two principles.
a. Dedicated resources assigned to one partition can never be affected by or affect the
operation of an application or application function in any other partition.
b. The use of shared resources by one partition cannot unacceptably affect, as shown by a
safety assessment, the operation of an application or application function in any other
partition sharing that resource.
An IMA execution environment should ensure that all hosted applications operate in a manner
equivalent to operation in federated system architecture. The inability of the IMA system to
guarantee partitioning in the presence of hardware failures or software errors may require
specific flight crew action or maintenance action. In some cases, an IMA system developer may
provide specific safety properties independent of any application, such as fail-passive or failoperational architectures, providing additional constraints and protection that could simplify the
overall system safety assessment, verification of robust partitioning and other protection features,
and demonstration of compliance.
4.5.1 Design of Robust Partitioning
The design for partitioning in an IMA platform is an iterative process. If deficiencies are
detected, then the architecture should be revised until the criteria can be shown to be satisfied.
While the approaches used will be dependent on the specific implementation, some generic
guidelines are provided here.
a. All the dedicated and shared resources should be identified.
b. All propagation paths to those resources where any unintended interaction may occur
should be determined. These propagation paths may be the result of hardware failures,
hardware design errors, or software design errors. They may also be the result of normal
execution.
c. Once propagation paths have been determined, containment boundaries should be
established and validated to prevent undesirable interaction between partitions through
these propagation paths.
Robust partitioning services should provide the protection of the dedicated and shared resources.
Failure of these partition services may lead to the generation of unintended failure propagation
paths. In some cases, more than one containment boundary may be needed for a given
propagation path. In others, a single containment boundary may protect more than one
propagation path. Partitioning mechanisms should be consistent with IMA system integrity,
availability and reliability requirements.
Integrated Modular Avionics (IMA)
P a g e | 27
4.5.2 Partitioning Analysis
A partitioning analysis should demonstrate that no application or sub-function in a partition
could affect the behavior of a sub-function or application in any other partition in an adverse
manner. All propagation paths between partitions should be identified. The effects of each
propagation path should be documented. Fault tree analysis, formal methods, and other
techniques may be employed. The partitioning analysis should be addressed in the context of the
aircraft system safety assessment to include any probability of multiple failure requirements.
Partitioning analysis should address plans, procedures and requirements for how the partitioning
and other protection schemes will be verified and validated.
4.6 Health Monitoring and Fault Management
Health monitoring and fault management (HM/FM) functions should be provided with
recognition that the IMA platform may support a collection of diverse aircraft functions. The
IMA platform should provide basic health monitoring and fault management capabilities for
IMA platform modules. These capabilities should be independent of the hosted applications.
Health monitoring should address both operational and maintenance concerns.
4.6.1 Components and Aspects to be monitored
Health monitoring is that part of the IMA platform responsible for detecting, isolating,
containing, and reporting failures that could adversely affect applications using the IMA
platform resources, or the resources themselves. This function should detect faults in the shared
resources used by the hosted applications. However, some resources dedicated to applications
may also be monitored by the IMA platform. For example, memory dedicated to an application
partition may be monitored by the IMA platform rather than the application.
Faults in the shared resources could adversely impact all the applications using those resources.
The system architecture should be designed to promote the detection of faults at the lowest
possible architectural level, ideally at the component level. Faults are generally detected by their
symptoms potentially leaving some ambiguity about which component failed. The smaller the
ambiguity group is for a fault, the easier it is to define policies for resolving it safely at the IMA
system level. Sound architectural choices can frequently reduce the ambiguity to a single
isolation region. Failures of these services can directly affect the ability to maintain that
separation and independence.
4.6.2 Health determination of each Application
The application supplier should identify potential failure modes of the application. In particular,
any application failure modes which require action by the platform should be identified. For
example, this may include partition restart, shutdown, or other platform specific actions. HM
facilities to record, monitor, and manage failures affecting the platform should be provided. This
includes the facilities for applications to record and announce maintenance conditions and
failures. The application supplier may also provide application-level health monitoring capability
Integrated Modular Avionics (IMA)
P a g e | 28
specific to their application. This information, independent of the approach used, should be
identified and integrated into the overall IMA system health monitoring strategy
4.6.3 Health Determination of the IMA System as a Whole
The health determination for the IMA system should address IMA platform-level failure
conditions and the potential for partitioning failures and application failure modes that are not
addressed within the application. An integrated HM strategy should be defined and documented.
This strategy should be coordinated with the IMA system safety assessment.
The integrated HM strategy should also define:
a. The means to identify systemic failures and report the conditions to the hosted
applications and other platform services.
b. Rules governing partition restart and shutdown.
c. Rules for degraded operations, if applicable.
d. IMA system health status reporting, content and frequency.
4.6.4 Response to Each Type of Failure
In addition to detection and isolation of faults, the ability to report and contain faults is needed.
Reporting refers to internal logging, indicating to hosted applications and platform services,
indicating to the flight crew, and indicating to the maintenance crew the existence of the fault or
failure. All detectable faults within an IMA platform should have a response determined.
4.6.5 Flight Crew Annunciation and Messaging
In general, IMA systems should be treated no differently than traditional federated systems with
respect to flight crew annunciation and messaging. Within the framework of flight alerts and
maintenance message systems, the focus for the flight crew is function availability. Although
maintenance systems provide information on aircraft maintenance aspects, it is the responsibility
of the flight alert/warning systems to provide the primary source of information to assist the
flight crew in their decision-making process. This is achieved through systems monitoring with
respect to a centralized alerting and warning function.
However, given the status of the IMA system as a whole, and the individual components and
hosted applications, certain types of status may need to be annunciated to the crew with respect
to system degradation. Flight alert/warning systems may selectively inhibit some warnings to
reduce the effects from cascading failures; typically, however, all failures and system
degradation and reconfiguration actions are reported. The appropriate faults, failures, and errors
to be logged, reported, or displayed to the flight crew should be determined. Displayed messages
and aural alerts should be provided in a clear and prioritized manner to the crew.
4.6.6 Control of Maintenance Actions and Reporting
Maintenance personnel need to be able to analyze health monitoring data, identify system
components that have failed or exhibited anomalous behavior, and determine the most
appropriate maintenance actions (e.g., defer, test, repair, replace, etc.). The level of integration,
interdependency, and complexity of an IMA system may result in unique and more numerous
Integrated Modular Avionics (IMA)
P a g e | 29
potential failure modes (for example, all functions affected by the loss of a single shared
resource) than federated system architectures. Power supply transients, cascading failures, or
failures affecting shared resources can result in multiple functions and hosted applications failing
simultaneously, and multiple failures, warning alert or caution messages being logged and
annunciated to the flight crew. Although many of the features described can be attributed to
traditional federated systems, particular emphasis should be placed on fault correlation with
respect to Built-In Test Equipment (BITE) fault reporting within IMA systems to reduce fault
propagation and distinguish between platform-related versus application-related issues.
4.6.7 Redundancy Management
Redundancy is used to improve both the reliability and availability of an aircraft function. An
IMA platform and/or system may include mechanisms to support management of redundancy for
hosted applications. Where possible, redundancy should be managed independent of the hosted
applications to support separate analysis and development of applications and platforms. Some
hosted applications may require application-specific redundancy management. For these the
IMA system should provide correct and consistent information about the health of the platform
resources, as well as the health of other modules with which the application interacts.
4.6.8 Single Event Upset (SEU) faults
IMA systems host aircraft functions and applications in a computer environment using shared
resources, such as electrical power, computer processing, memory, and data buses. This means
there is a potential for an SEU in a shared resource to adversely affect multiple different aircraft
functions, applications, and partitions. The IMA platform design and fault management strategy
should address the potential for SEU and provide appropriate recovery capabilities.
4.7 IMA System Configuration Management
The certification applicant should provide a robust and easily maintainable configuration
management system for the operator of the aircraft. The IMA platform developer should provide
capabilities and means for the certification applicant to determine the configuration of the IMA
system, platform, modules, resources, functions and hosted applications and databases. The IMA
system is composed of multiple, general-purpose, shared resources that may be labeled in a
traditional manner or using electronic part numbering. The role and actions of the operator in
maintaining the configuration of the aircraft and IMA system should be simple and verifiable.
Issues to be addressed:
a. Extent of configuration data required for IMA system software and hardware part
numbers.
b. Coherence among configuration data.
c. User-modifiable hardware, databases, and software without certification authority
oversight.
d. The ability to retrieve part numbers from modules and applications for conformity
inspections.
e. Multiple, selectable configurations (option selectable modules).
f. Field-loadable modules (hardware, software, databases).
g. Maintenance of configuration data after modification.
Integrated Modular Avionics (IMA)
P a g e | 30
4.7.1 Configuration Data
Both the IMA system and the hosted applications should maintain configuration data in the
system. These configuration data should be shown to be traceable to the application or module
requirements from which they were derived.
4.7.1.1 IMA System Configuration Data
There are configuration data unique to IMA systems that are subject to specific certification
guidance. Configuration data described and discussed here is used by the IMA system to:
a. Define or select the correct configuration for the aircraft IMA system in its installation.
b. Enable configuration control and support conformity inspection of the IMA system,
platform, modules, resources and applications.
c. Activate or deactivate modules, resources, or functions, e.g., adaptation of the software to
several aircraft configurations using option-selectable software or data.
d. Define the allocation of IMA system resources to the hosted applications.
e. Define the allocation and characteristics of inter-partition communication ports.
f. Define other parameters that affect the integrated system (e.g., schedule, performance,
module part numbers)
4.7.1.2 Application Configuration Data
Other types of configuration data may be used by the hosted applications on the IMA system to:
a. Activate or deactivate functions or application-specific resources
b. Adapt the application to the aircraft configuration.
c. Provide data to the hosted applications.
4.8 Guidance on use of shared databases
Databases are included in aircraft systems to provide static read-only data to the applications.
IMA systems may require read-write databases. These databases may be installed as a shared
resource or dedicated to a specific application. IMA system hosted databases may be functionally
identical to the databases used with traditional federated systems. The industry accepted
guidance for satisfying airworthiness requirements for aeronautical databases are provided in
existing documents, such as DO- 200/ED-76 and DO-201/ED-77 Shared databases may be
viewed as another shared resource managed by the IMA platform. Corruption of shared
databases should be addressed by the IMA system health monitoring and fault management
function.
4.9 Master Minimum Equipment List (MMEL)
IMA systems may host and interface with many aircraft systems. With the introduction of these
highly integrated systems, the traditional approach of independently addressing aircraft systems,
LRUs, or functions is more difficult and may not be possible. The highly integrated nature of an
IMA system results in failure modes, resource management, health monitoring, fault
management, and other design considerations which may be very different from typical federated
system architecture and strategies.
Integrated Modular Avionics (IMA)
P a g e | 31
4.9.1 Design Considerations for MMEL
The MMEL, where required, should be part of the IMA system design and requirements so that
fault management and redundancy management can be analyzed and incorporated into the IMA
system design. MMEL allowances should be determined with appropriate consideration given to
the criticality of IMA system functions and applications, and the effects of the failures upon
these systems, functions and shared resources. MMEL allowances should be based on the
aircraft-level functional hazard assessment and system safety assessment and should consider
any impact on other functions that share resources with the failed component, resource or
function. Any proposed MMEL allowance should continue to demonstrate compliance with the
applicable regulations.
4.9.2 Approval Considerations for an MMEL
The maintenance and operational requirements for dispatching the aircraft under MMEL
allowance should include the appropriate safety justification and procedures that are based
on the design considerations of Section 3.9.1. The MMEL should be submitted to the
applicable regulatory authority with the supporting data, justifications, and procedures.
4.10
Human Factors Considerations
The increased level of integration and complexity introduced by IMA systems has the potential
to introduce different interdependencies and interactions between aircraft systems and the flight
crew and maintenance personnel than exist in traditional federated system architectures. Human
factors issues should be addressed in the IMA system design, with particular emphasis on the
identification of performance requirements, functional interactions, pilot interface, displayed
information, fault management and crew alerting, degraded operational modes, and the potential
for cascading failures. Similarly, the human factors aspects for the continued airworthiness
process should be addressed in IMA system design.
A plan to address human factors requirements should be developed early in the program and
should include the corresponding methods for complying with those requirements. The human
factors requirements for an IMA system may be developed by analyzing the tasks that will be
performed by the users (flight crew and maintenance personnel), and the resulting user interfaces
to perform those tasks. Analyses used to validate that the design will meet flight crew and
maintenance personnel requirements and help system designers meet those user needs may
include prototyping, human-in-the-loop testing, user validation, and other methods. The user
performance requirements (e.g., response times, duration, load, feedback, etc.) that will be
experienced by the flight crew under normal, abnormal, and emergency conditions should be
identified and addressed in the design of an IMA system. Design features of the IMA system
may need to be modified based upon the results of the human factors analysis of tasks and user
interface issues.
Integrated Modular Avionics (IMA)
P a g e | 32
5 CERTIFICATION TASKS
This section addresses the IMA system certification considerations with regard to compliance
with the applicable regulations, and the functional, performance, and safety requirements defined
for the system.
5.1 Overview of the certification process
Typical development processes are divided into six tasks that define the incremental acceptance
activities for the certification process for IMA systems(see figure 5):
Task 1Task 2Task 3Task 4Task 5Task 6-
Module Acceptance
Application software/hardware acceptance
IMA system acceptance
Aircraft integration of IMA system (including validation and verification)
Change of modules or applications
Reuse of modules or applications
Figure 5 : IMA system certification tasks illustration
5.2 Module Acceptance (Task 1)
The purpose of module acceptance within the overall certification process is to demonstrate the
module characteristics, performance and interfaces to obtain incremental acceptance of the
module. This is accomplished by providing documented evidence (acceptance and/or compliance
data) for the benefit of the other IMA system acceptance tasks and for potential reuse. The
module acceptance process allows an applicant to gain incremental acceptance for individual
components of the IMA platform (e.g., processing module, core software services (e.g.,
operating system, health monitoring function, fault management function), power module,
interface module). The platform itself may also be accepted as a module, which typically
contains multiple other modules.
Integrated Modular Avionics (IMA)
P a g e | 33
5.2.1 Module Acceptance Objectives
a. Plan the acceptance tasks to meet all of the applicable certification requirements.
b. Develop specifications for the module and demonstrate compliance with the Module
Requirements Specification (MRS) (where the module supplier may develop the MRS
based on assumptions for the intended use).
c. Demonstrate compliance of resource intrinsic properties, such as time and space
partitioning, fault management, health monitoring, other safety features, determinism,
latency, resource management, resource configuration, and application parameters.
d. Verify compliance of resource properties with established requirements in terms of the
MRS, such as performance, interfaces, services, safety, fault management, and robustness
(fault tolerance).
e. Develop the core software (e.g., operating system, API, and core services) and/or
hardware, as relevant to the module and show compliance to the applicable guidance and
regulations.
f. Develop and make available the module acceptance data for certification authority
acceptance.
g. Provide users of the module with the necessary information to properly use integrate and
interface with the module (e.g., user’s guide, module data sheet and interface
specifications) and also configuration of the module (e.g., physical part number),
electronic part number/version, core software identifiers, and when that module has
changed.
h. Implement quality assurance, configuration management, integration, validation,
verification, and certification liaison for the module acceptance.
i. Define, specify, assess, and qualify, as needed, module supporting tools to be provided to
and used by module users.
j. If reuse is a desired outcome for the module development, reuse should be addressed
during the development of the module
5.2.2 Module Acceptance Data
The module acceptance process should follow a systematic approach. There should be plans,
requirements, and evidence of compliance with these plans and requirements.
5.2.3 Module Acceptance Plan (MAP)
The MAP is the primary means used by the module developer to present to the certification
authority their plan for obtaining incremental acceptance for their module. It should address all
aspects relevant for their specific module, including module development, verification,
configuration management, quality assurance, and demonstration of compliance.
The MAP should address:
a. System overview (if applicable)
b. Module overview
c. Acceptance criteria
d. Module life cycle
e. Module life cycle data
f. Schedule
g. Module reuse
Integrated Modular Avionics (IMA)
P a g e | 34
5.2.4 Module Requirements Specification (MRS)
The Module Requirements Specification (MRS) defines the requirements and design criteria for
the module that will be integrated into an IMA system. This MRS should include the following
types of information:
a. Description of the module requirements, with attention to safety-related requirements,
protection requirements, and potential failure conditions
b. Functional and operational requirements under each mode of operation
c. Fault management and health monitoring requirements
d. Resource management.
e. Scheduling procedures and inter-processor/inter-task communication mechanisms,
including time-rigid sequencing, preemptive scheduling, and interrupts.
f. Requirements for robust partitioning
5.2.5 Module Validation and Verification (V&V) Data
Module V&V data is the evidence of the completeness, correctness, and compliance of the
module with its requirements, as defined in the MRS. Module V&V includes at least the
following data:
a. Module V&V plan, which may be part of the MAP and/or the IMA system V&V plan.
b. Software verification cases, procedures, and results (as per DO-178/ED-12).
c. Module integration V&V cases and procedures, when modules are integrated.
5.2.6 Module Quality Assurance (QA) Records
The results of the module QA process activities are recorded in QA records. These may include
QA review or audit reports, meeting minutes, records of authorized process deviations, and
conformity review records.
5.2.7 Module Configuration Index (MCI)
The MCI identifies the configuration of the module and the module life cycle environment. This
index should include:
a. Each component of the module at the next lower level of assembly.
b. Previously developed modules, if used.
c. Module life cycle data, including module acceptance data and module compliance data.
d. Identification of the test environment used to verify the module.
5.2.8 Module Acceptance Accomplishment Summary (MAAS)
The MAAS for the module is the primary data item for showing compliance with the MAP. The
MAAS should include:
a. Same information as in the MAP and any deviations from the MAP (if any).
b. Module characteristics
c. Module identification
d. Change history
e. Compliance statement
Integrated Modular Avionics (IMA)
P a g e | 35
5.2.9 Module Acceptance Data Sheet (MADS)
The MADS is provided to users, integrators, certification applicants, and certification authorities.
It should include the Module description and intended use and functionality, Module part
number(s), Software level(s) and hardware design assurance level(s), Size and weight,
Limitations, Continued airworthiness information.
5.3 Application Acceptance (Task 2)
An application is software and/or application-specific hardware with a defined set of logical
interfaces that, when integrated with a platform, performs an aircraft function or part thereof.
Software and/or hardware applications intended for future reuse should be developed using
available guidance such as AC 20-148.
5.3.1 Application Acceptance Objectives
a. Demonstrate that the application performs its intended function and satisfies applicable
regulations while properly utilizing the appropriate platform resources and interfacing
with other modules and/or applications.
b. Define and verify the platform resources required by the application.
c. Ensure that other acceptance and approval activities are addressed as appropriate.
d. Develop the necessary application life cycle data.
e. Validate and verify the operation of the application when integrated on its target IMA
platform.
5.3.2 Application Acceptance Data
The application acceptance process will typically involve compliance with DO-178/ED-12 and
DO-160/ED-14. If reuse of the application is desired, the Plan for Software Aspects of
Certification (PSAC) or the Plan for Hardware Aspects of Certification (PHAC) for the
application should address the following aspects:
a. Justification for reuse suitability, what aspects of the application make it suitable for
reuse.
b. Development of data to support reuse.
c. Applicable guidance for the reusable application.
5.4 IMA System Acceptance (Task 3)
The main goal of IMA system acceptance is to demonstrate that the integrated modules, hosted
applications, and the platform continue to perform their intended functions and do not adversely
affect other hosted applications or modules. For off-aircraft activities, a major goal is to perform
V&V activities that can be applied toward the overall aircraft certification effort.
5.4.1 IMA System Acceptance Objectives
a. Plan the IMA platform and system activities with the intent of using the integration,
validation, and verification for aircraft-level certification credit.
b. Consolidate the resource requests from applications
c. Verify proper interaction between all applications, modules, and platform resources
Integrated Modular Avionics (IMA)
P a g e | 36
d. Demonstrate that the configuration of IMA system is correct and approved processes are
followed.
e. Perform integration and V&V activities on the IMA system.
f. Develop IMA system acceptance and compliance data.
5.4.2 IMA System Acceptance Data
The IMA acceptance process should use a structured approach. The acceptance process for the
IMA system should be documented in an IMA System Certification Plan (IMASCP) and an IMA
system V&V plan (IMASVVP).
5.4.3 IMA System Configuration Index (IMASCI)
a. Identification of the physical location within the IMA system of hardware and software
components.
b. Configuration identification of each IMA system component.
c. Operational or maintenance procedures and limitations that is integral to the IMA system.
d. Any system design features or capabilities provided to establish IMA system safety under
the applicable regulations should be identified.
5.5 Aircraft Integration of IMA system (Including V&V) (Task 4)
The final IMA system installation, integration, and V&V activities are similar to those that
would be conducted on a federated system architecture, demonstrating that each aircraft function
and hosted application functions as intended, supports the aircraft safety objectives, and complies
with the applicable regulations. However, during the installation activities, the interactions
between hosted applications relative to the provided aircraft functions should be verified and
validated during aircraft ground and flight testing. Also, the interactions, interfaces, and
connections between the IMA system and other aircraft systems should be verified and validated.
5.5.1 Aircraft Integration Objectives
a. Plan the activities for installation, integration, validation, and verification of the IMA
system on the aircraft.
b. Demonstrate compliance with intended functionality and requirements, using laboratory,
appropriate analyses, ground, and flight tests.
c. Verify IMA system resource management, fault tolerance and management, health
monitoring, degraded modes, and reversion capabilities.
d. Evaluate repercussion of specific anomalies, such as a loss or malfunction of multiple
applications or of entire shared resources.
e. Perform V&V activities to address module failure modes affecting several hosted
applications (intra-module analysis)
f. Address human factors issues
g. Perform High Intensity Radiated Fields (HIRF) and Indirect Effects of Lightning (IEL)
testing with regard to multiple aircraft functions failure and anomalous behavior, as
required.
h. Verify proper interaction and interfaces between all IMA platforms
i. Verify the failure effects of each IMA module and resource affecting more than one
hosted application in the IMA system safety assessment.
Integrated Modular Avionics (IMA)
P a g e | 37
5.5.2 Aircraft Level IMA System Compliance Data
IMA system approval on the aircraft should use a structured approach. The aircraft-level
IMASCP should be developed as a high-level document that provides the certification
basis and proposed means of compliance for the installation of the IMA system on the
aircraft, demonstration of compliance with the regulations, and approval of the installation
and certification of the aircraft.
5.5.3 Aircraft Level IMA Validation & Verification Plan
a. Address single and multiple common mode failures which could effect continued safe
operation of the aircraft.
b. Actions to measure the aircraft and flight crew responses to abnormal operational
conditions, degraded modes, and failure modes.
c. Actions to verify and validate the intended functions of the aircraft.
d. Actions to verify and validate that the IMA system does not perform unintended
functions.
5.5.4 Aircraft Level IMA System Configuration Index (IMASCI)
The aircraft-level IMASCI should include the same type of information as listed in Section 3.4.5,
plus any other data needed for the installation, integration, validation, and verification of the
IMA system on the aircraft.
5.6 Change (Task 5)
5.6.1 Changes to IMA System Modules, Resources and Applications
Changes to IMA system components will likely occur throughout the life cycle of the IMA
system. A change may involve modification to resources, modules or hosted applications,
including addition, deletion, repair, or modification of IMA system components. There are a
variety of types of changes that may occur, such as a new application being hosted on the IMA
platform, modification to an existing hosted application, new supporting software and processing
hardware, a modification to existing supporting software or hardware, or addition of new
network infrastructure. Changes will require reacceptance or approval by the certification
authority.
5.6.2 Change Objectives
A primary objective of the IMA system development and acceptance process is to minimize the
impacts of an IMA system component change on the IMA system and aircraft certification. The
main goal of the change process within the IMA system is to bound changes in such a way that
their effects are known and can be fully verified and validated.
5.6.3 Change Management Process
The change management process should be documented at all appropriate levels (aircraft, IMA
system, platform, application, and module) with identification of interrelationships between
different levels. The process should address,
a. Propose changes.
Integrated Modular Avionics (IMA)
P a g e | 38
b.
c.
d.
e.
f.
g.
h.
Perform an initial change impact analysis
Develop an implementation strategy
Implement the changes to the agreed implementation strategy.
Implement change control and problem reporting
Verify the changes.
Integrate the changed item
Finalize the change impact analysis.
5.6.4 Change Impact Analysis (CIA)
When a change is made to the IMA system a change impact analysis should be performed and
should include an evaluation of the impact of the change on the original system safety
assessment and aircraft-level safety. The change impact analysis should determine whether the
change could adversely affect safe operation of the system or product, and other components
impacted by the change. Changes to any software or hardware should be reflected in the
appropriate life cycle data affected by the change and verification activities conducted to assure
that no adverse effects are introduced during the change.
5.6.5 Change Data
The module developer, application developer, integrator, and/or applicant should obtain approval
or acceptance of the following data for a changed module or application
a. Change Impact Analysis (CIA)
b. Change management plan. The change management plan may be included in an updated
MAP, PSAC, PHAC, and associated software or hardware plans
c. V&V plan, records, and results to demonstrate appropriate regression analysis and
testing.
d. Modified life cycle data.
e. Maintenance and change history records.
5.7 Reuse of Modules or Applications (Task 6)
IMA systems are composed of modules and applications that can be used in many
different configurations. Reuse involves the use of certification credit (i.e., full, partial, none) for
modules and/or applications in a subsequent installation. The goal is to reuse acceptance data
without reassessing the data itself but rather to assess its suitability for and integration into the
new installation.
5.7.1 Objectives of the Reuse Process
a. Ensure that the module or application life cycle data is unchanged from what was
previously accepted.
b. Ensure that the limitations, assumptions, etc.
c. Analyze the suitability of the module or application
d. Evaluate any open problem reports of the module or application to ensure that the
problem does not adversely impact safety, functionality, performance, or operations.
Integrated Modular Avionics (IMA)
P a g e | 39
5.7.2 Reuse of a Software Module or Application
If the module to be reused is software only, the original acceptance should have documented
which objectives of DO-178/ED-12 were satisfied fully, partially, or not at all. Objectives that
are not satisfied by the software developer should be completed by the platform integrator,
system integrator, or certification applicant.
5.7.3 Reuse of a Complex Electronic Hardware Module or Application
If the module to be reused is Complex Electronic Hardware (CEH) that was required to satisfy
the objectives of DO-254/ED-80 were satisfied fully, partially, or not at all. Objectives that are
not met by the hardware developer should be completed by the platform integrator, system
integrator, or certification applicant.
5.7.4 Reuse of Environmental Qualification Test Data
If the module to be reused is hardware, either complex or simple, the reuse of environmental
qualification test data (DO-160/ED-14) should be evaluated. The similarity of the environment
and module usage should be evaluated to determine if it can be reused or what additional testing
(if any) will be needed. Environmental qualification data may be reused when it is shown to be
appropriate to the new installation environment and configuration.
6
INTEGRAL PROCESSES
Due to the high level of integration inherent in IMA systems, it is recommended that applicants
use ARP 4754/ED-79 (Ref. [7]) and ARP 4761 (Ref. [8]), or acceptable alternatives. The process
should consider the following, as a minimum:
h. Isolation, separation, and independence to prevent interference to safety-critical functions
by functions of lower failure conditions severity (e.g., partitioning, resource management,
fault management, and containment).
i. Protection to prevent single failures and foreseeable combinations of failures that could
adversely affect multiple functions simultaneously (e.g., independence, redundancy,
health monitoring and fault management, and safety monitoring).
j. A preliminary FHA should be performed at the aircraft and IMA system levels to assess
the intended functionality, characteristics, and capabilities of the IMA architecture.
k. Examination of the architectural design and safety-related capabilities of the IMA
platform and the constraints imposed on the aircraft functional allocation and hosted
applications. For example, requirements for application independence, partitioning,
protection, redundancy, resource needs, interface communications, performance, network
access, and/or dedicated links to aircraft sensors and actuators will be produced. The
result of this examination should be an IMA PSSA.
Integrated Modular Avionics (IMA)
P a g e | 40
l. Examination of the behavioral issues of the IMA platform. This includes details such as a
health monitoring, resource management, and fault management capabilities provided by
the platform and the types of available failure recovery or containment.
m. Examination of the performance details within the IMA platform to ensure it will satisfy
the performance requirements of the hosted application(s).
While a single stakeholder may be able to perform all of the activities described above, it is
anticipated that these will be distributed among multiple stakeholders. A typical allocation of
responsibilities is provided in the following sections.
6.1 Responsibilities of the Certification Applicant
The certification applicant is responsible for aircraft-level system safety assessment processes
and ensuring that the IMA system, platform, modules, and hosted applications will satisfy the
aircraft safety, integrity, and reliability requirements. The certification applicant will be
responsible for the consolidation of the results of IMA system safety assessment performed by
the IMA system integrator, platform and module developers, and application developers; and
ensuring their SSA results are consistent with the aircraft safety assessment.
The certification applicant should address:
a. Single failures and combination of failures between the IMA system and other aircraft
systems.
b. Common cause and cascading failures
c. The impact of the IMA-specific SSA results on demonstration of compliance with the
applicable regulations, operations, and the continued airworthiness of the aircraft.
d. Network security.
e. Any other relevant safety data.
6.2 Responsibilities of the IMA System Integrator
The IMA system integrator will be responsible for consolidation of the results of system safety
assessments performed by the IMA platform, module, and application suppliers; and ensuring
their SSA results are consistent and compatible with the IMA SSA. As part of the integration and
V&V processes, the IMA system integrator should ensure that the behavior and safety-related
properties of the IMA system components are consistent with the IMA SSA requirements. This
process should include verifying the PSSA/SSA results with testing of the resource management,
health monitoring, fault management, and other protection features of the platform and system
(e.g., redundancy management, cross channel comparators, reversion strategies), and should be
performed at multiple levels of integration.
6.3 Responsibilities of the IMA Platform Supplier
The IMA platform supplier should perform a detailed platform safety assessment. These analyses
should examine IMA platform-specific features and capabilities to support the hosted
applications, IMA system, and aircraft installation that include robust partitioning, resource
Integrated Modular Avionics (IMA)
P a g e | 41
management, health monitoring, fault management, input/output (network communications),
performance, and other architectural and protection features provided by the platform.
The IMA platform supplier will be responsible for the common mode failure analysis of the IMA
platform. This common mode failure analysis should be coordinated with the application
developers and the IMA system integrator to support the IMA system and aircraft-level safety
assessments. Platform safety assessment data, resource management guarantees, and fault
management and health monitoring features should be made available to other stakeholders for
their use in the application safety assessment, the IMA system safety assessment, and the aircraft
safety assessments. The platform supplier may need to gather input from multiple components or
module developers in order to complete the IMA platform safety assessment tasks.
6.4 Responsibilities of the Application Supplier
The application supplier should perform a detailed PSSA for the application, and specify the
safety features, performance, and interface requirements for that application. As part of the PSSA
they should also specify assumptions that the application is making regarding the platform on
which the application will be hosted, and their needs for resource management, health
monitoring, fault management, failure responses, etc. The subsequent IMA system-level and
aircraft-level safety assessments will verify these assumptions and requirements as part of their
activities. The PSSA results will be used in the consolidation, evaluation, and integration
activities. The application supplier should ensure that the behavior and properties of the
application are consistent with specific system and aircraft safety requirements.
6.5 Safety Assessment Activities
The following safety assessment activities should be addressed during the various phases of the
IMA system development.
6.5.1 Functional Hazard Assessment (FHA)
The intended functions of the IMA system should be identified and evaluated for their impact on
aircraft safety. A FHA should be conducted at the aircraft and system levels to determine and
classify the failure conditions and effects associated with both the loss and malfunction of each
function provided by the IMA system. The hazards associated with the simultaneous loss or
malfunction of multiple functions provided by the IMA system should also be identified and
classified. In addition, the loss and malfunction of functions provided by the IMA system should
be addressed in combination with the loss and malfunction of related functions provided by other
aircraft and engine systems to ensure that common mode failures are addressed (see Section 6.1
of ARP-4754/ED-79).
6.5.2 Preliminary System Safety Assessment (PSSA)
a. Based on the failure condition classifications determined by the FHA, the proposed
design and architecture of the IMA system components should be evaluated by a PSSA to
determine that the system development assurance level and safety requirements identified
in the FHA will be achieved.
Integrated Modular Avionics (IMA)
P a g e | 42
b. The PSSA should establish the number (redundancy), isolation and independence
features, software levels, hardware design assurance levels, and reliability of each
component of the IMA system, including the power supplies, communication interfaces,
displays, and controls that are required to protect the aircraft from the effects of random
hardware failures. The system development assurance levels necessary to protect the
aircraft and engine from failures and combinations of failures, and design errors in the
hardware and software of each component should be determined.
c. The software levels should be determined for all platform-provided software and hosted
software applications in compliance with the FHA requirements.
d. The hardware design assurance levels should be determined for all platform-provided and
application-specific hardware devices in compliance with the FHA requirements.
e. PSSA should identify specific safety requirements for hardware and software components
including failure containment, partitioning, independence, redundancy, health
monitoring, etc. and specific verification strategies (see Section 6.2 of ARP- 4754/ED79).
6.5.3 System Safety Assessment (SSA)
A systematic, comprehensive evaluation of the applications hosted by the IMA system as
installed in the aircraft should be conducted to show that the relevant safety requirements
identified in the PSSA have been met. This evaluation may include bench, ground, and flight
tests to ensure assumptions made in the PSSA are correct and validated. The SSA combines the
results of several different analyses and tests to verify the safety of the overall system, as
installed.
A typical SSA includes:
a.
b.
c.
d.
e.
f.
g.
A system description, including functions and interfaces.
A list of failure conditions.
The classification of each failure condition.
Qualitative analysis of each failure condition.
Quantitative analysis of each failure condition, as required.
The results of common-cause analyses.
Confirmation that any cascading failures and/or single failure affecting multiple systems
have been addressed.
h. Laboratory, simulator, and aircraft test procedures and results, as appropriate, that
substantiate flight crew recognition and response to failure conditions.
i. Verification that any failure modes of lower integrity functions that could adversely
affect higher integrity (more critical) functions are prevented.
j. Confirmation that all software has been developed to the appropriate software level
identified in the PSSA.
Integrated Modular Avionics (IMA)
P a g e | 43
6.5.4 Common Cause Analysis for IMA Systems
For IMA systems, where resources are shared between multiple aircraft-level functions and
hosted applications which are conceptually independent, Common Cause Analysis (CCA) at the
aircraft level is required because a single causal event can directly (or indirectly) contribute to
simultaneous adverse effects. Additionally, cascading failures should be part of this analysis. The
methods of the CCA need not change from the traditional one, but it should be applied at a
higher level in the hierarchy of aircraft systems. It should now be applied to the collection of
systems (and the aircraft functions they perform) that are implemented by an IMA system and its
components. This may mean that the analysis needs to be performed by the certification
applicant, rather than by the IMA system integrator, platform developer, or application
developer. It should be performed when the configuration of the IMA system is finalized and
may need to be repeated if functions are added to the IMA system following initial certification.
It may also include traditional analyses of redundant systems, which are implemented in whole
or in part by the IMA
system.
6.5.5 Failure Mode Analysis
This section discusses analyses of generic IMA platform components, the types of data expected
to be produced by these analyses, and the integration of results at the application, platform, IMA
system integration, and aircraft levels. These integration activities are required to demonstrate
the safety of the IMA system. The higher levels of analyses should be based upon the results of
the lower levels.
a. IMA Components Failure Mode Analysis
The analyses of IMA components (modules, platforms, resources) determine what effects
component failure modes will have on the hosted applications, other IMA modules, the platform,
the IMA system, and the aircraft and/or engine. In order to accomplish this failure of the
components should be identified and how these failures manifest themselves should be
determined. In other words, under known failure conditions or causal events, how does the
component deviate from its required operation and intended function(s), and what is the impact
on other modules, hosted applications, the IMA system and aircraft functions.
b. IMA Platform Failure Mode Analysis
In analyzing the IMA platform, the IMA modules and components are combined in the absence
of applications. The failure modes and effects of the individual IMA components are now
analyzed within the context of the platform architecture and interfaces to determine how they
manifest themselves at the platform boundaries. As with the component analyses, the focus is on
how the platform may vary from its defined behavior.
c. Applications Failure Mode Analysis
Integrated Modular Avionics (IMA)
P a g e | 44
The application failure mode analyses consider each individual application. If there is any
hardware that is not part of the platform, but is used to support a hosted application, this
hardware should be analyzed. The only difference is that hosted applications typically have
portions of the aircraft FHA associated with them (at least those providing an aircraft-level
function) and a better analysis of the severity of the failure effects for these components can be
determined.
d. IMA System Failure Mode Analysis
This activity analyzes the failure modes of an IMA system, considering the previous analyses
(for the components, modules, platform, and applications) as input. The results of the analysis
become an input to the aircraft-level failure mode analysis. The IMA system failure mode
analysis considers the hosted application interactions and couplings with other applications and
shared resources of the platform(s), and the IMA system. Application interactions should address
both normal and unintended interference between applications and shared resources. Single and
multiple failures of applications and resources should be examined, and IMA system-level
failure effects are determined. If an IMA system consists of multiple platforms, potential
interactions between these platforms should also be addressed and failure modes determined.
e. Aircraft Level Failure Mode Analysis
The component, hosted application, IMA platform, and IMA system failure mode analyses
results are used in the aircraft-level failure mode analysis. It is this analysis that finally
consolidates all the predicted failure effects and modes from the lower level analyses and
confirms that they are appropriate for the IMA system(s) installation and operation on the
aircraft. Any erroneous assumptions of the lower level analyses should be detected and corrected
during the aircraft-level failure mode analysis. Additionally, interactions with other aircraft
systems should be addressed at the aircraft-level.
6.5.6 Fault Management, Health Monitoring, and Redundancy Management
The fault management, health monitoring, and redundancy management considerations should be
implemented in the design and considered in the safety assessment process. Failure modes of
these capabilities should be addressed in the failure mode analyses for the platform and system,
and possibly for the aircraft.
6.5.7 Partitioning Analysis
A partitioning analysis should be provided as input to the failure analyses, and the failure modes
of partitioning violations addressed in the failure mode analyses for the platform and system.
6.5.8 Network Security
A breach in IMA system network security may adversely impact aircraft safety. Therefore,
failure modes of the IMA system network security should be addressed as part of the aircraftlevel safety assessment. Examples of threats to network security are: data content integrity
(alteration of data value contents), data source integrity (impersonation), and data latency and
other denial-of-service attacks.
Integrated Modular Avionics (IMA)
P a g e | 45
6.6 System Development Assurance
This section describes key areas of system development assurance, which include software
guidance, hardware design assurance, shared design assurance, IMA system configuration
management, and environmental qualification.
6.6.1 Software Guidance
Software used in IMA systems should be developed using the guidance of DO-178/ED-12 (Ref.
[2]) or another acceptable means of compliance to the appropriate software level(s). Certification
policy and guidance should be addressed when considering key IMA system software aspects of
certification, such as software reuse, user-modifiable software, field loadable software, and
database integrity. In addition, specific aircraft programs may have additional software policy or
guidance that is applicable for the IMA system to be installed.
6.6.2 Electronic Hardware Guidance
If the IMA system contains CEH (Complex Electronic Hardware) devices whose functions
cannot feasibly be comprehensively verified by test and/or analysis, the CEH devices should be
developed using the guidance of DO-254/ED-80 (Ref. [4]) or other acceptable means of
compliance to the appropriate level of hardware design assurance. Certification policy and
guidance should be addressed when considering key IMA system hardware aspects of
certification, such as field-loadable hardware, environmental qualification testing, hardware
module acceptance, aircraft personality modules, hardware configuration files, etc. In addition,
specific aircraft programs may have additional hardware policy or guidance that is applicable for
the IMA system to be installed.
Field-modifiable hardware may be used within an IMA system; for example, programmable
logic devices may be modified through external means. Since DO-254/ED- 80 (Ref. [4]) does not
currently contain guidance for such implementations, the current guidance on field-loadable
software (for example, Section 2.4 and 2.5 of DO-178B/ED- 12B, Ref. [2]) may be applied.
6.6.3 Integration Tool Qualification
DO-178/ED-12 (Ref. [2]) and DO-254/ED-80 (Ref. [4]) provide guidance on verification and
development tools used for software and hardware development, respectively. An integration
tool should be evaluated to determine if it is a development tool (produces an item that will be
implemented in the IMA system) or a verification tool (verifies an item that will be implemented
in the IMA system). If the tool output is not fully verified, it may need to be qualified. The tool
qualification approach should be based on DO-178/ED-12 (Ref. [2]) Section 12.2.
6.7 Validation
The validation process should ensure that the IMA system requirements are correct and
complete. This section provides a framework for IMA system validation and supplements.
The objectives of validation are to:
Integrated Modular Avionics (IMA)
P a g e | 46
a. Ensure the completeness and correctness of all levels of the IMA system requirements,
including modules, hosted applications, platform(s), and IMA system requirements. Each
level of requirements within the hierarchy should be validated prior to validating the next
lower level.
b. Evaluate the IMA system architecture and functional allocation of hosted applications.
c. Ensure that the partitioning protection is robust, in terms of processor throughput time
and usage, memory allocations, I/O devices and buses, and other shared resources.
Ensure redundancy, resource management, health monitoring, and fault management
requirements are correct and complete for the overall IMA system.
d. Ensure compatibility with safety, integrity, and reliability requirements of each
application hosted on the IMA system.
e. Evaluate data coupling and control coupling between modules and applications.
f. Ensure both normal and degraded operations are considered, and their potential impact on
aircraft safety identified.
6.8 Verification
The verification process should ensure that the implementations of specified requirements for the
IMA system have been met. This section provides a framework for IMA system verification and
supplements ARP4754/ED-79.
The objective of verification is to ensure that all levels of requirements are properly and
completely implemented, and that the means to ensure this are correct. The verification process
ensures that all levels of requirements are complete, traceable, accurate, verifiable, and
unambiguous. Verification may initially be performed in a simulated representative target
computer and environment (usually during development to ensure it will work when the platform
becomes available); however, the activity cannot be completed without verification on the target
platform. In a situation where application and platform are developed concurrently, it is
recognized that initial application verification process described by DO-178/ED-12 (Ref. [2])
may be performed in a “host” computer (simulated representative) environment prior to the
availability of the target platform. In this circumstance, partial acceptance credit may be granted
for completion of those processes, if the developer can substantiate that those verification
procedures and results are valid for the target computer and environment.
6.9 Configuration Management (CM)
This section addresses configuration management (CM) of the IMA system life cycle data and
life cycle environment.
The IMA system life cycle should manage and maintain:
a. Configuration of components, modules, resources, platforms, hosted applications, and
IMA systems;
b. Life cycle data; and
c. Tools and environments used to develop, verify, and validate the IMA system.
Integrated Modular Avionics (IMA)
P a g e | 47
6.10
Quality Assurance (QA)
Highly integrated and complex systems like IMA systems present many opportunities for
development errors and undesirable, unintended effects. At the same time, it is not practical to
develop a finite test suite for IMA systems which conclusively demonstrates that there are no
development errors present. Since these errors are generally not measurable and suitable numeric
methods for characterizing them are not available, other qualitative means should be used to
establish that the IMA system can satisfy regulations and safety and functional requirements with
minimal likelihood of design errors causing unacceptable events. Thus, for highly integrated and
complex systems development assurance is relied upon to reduce the likelihood of errors in the
system.
6.11
Certification Liaison
The certification liaison process establishes communication and understanding between the
applicant and the certification authority throughout the IMA system life cycle to assist in the
acceptance and certification process.
Typical contents of life cycle data have been described throughout this document. However, it
should be noted that life cycle data may be packaged and titled as appropriate for the project but
should still address the contents prescribed in this document. If alternate titles or packaging is
used, the stakeholder should develop a document mapping to demonstrate that all the applicable
data is available.
6.12
Development Life Cycle Data
Throughout the development of the IMA system and installation on the aircraft life cycle data
will be developed. These data should be made available to the certification authority upon
request:
a. Module Acceptance Data, including all MRSs, module V&V results, module QA records,
module CM records, module problem reports, and additional Module Acceptance Data
b. Hosted Application data, IMA system data.
c. Aircraft-IMA system integration data.
Figure 6 provides an overview of the life cycle data for an IMA system. All data should
be available to certification authority.
Integrated Modular Avionics (IMA)
P a g e | 48
Figure 6 : Life Cycle data for IMA Systems
6.13
Certification Liaison Process When Changes are Made
When a change to an approved module or hosted application is proposed, a change impact
analysis (CIA) should be performed. The CIA and other planning documents that address the
change should be submitted to the certification authority as early as possible to obtain agreement.
Changes should not be implemented until agreement is obtained. All data affected by the change
should be updated in compliance with the plans.
6.14
Certification Liaison Process for Reuse of Modules
When a module or hosted application acceptance package is proposed for reuse, as described in
Section 5.7.2, the data identified in Section 5.7.3 should be submitted to the certification
authority.
7
CONSIDERATIONS FOR CONTINUED AIRWORTHINESS OF IMA SYSTEMS
This section provides guidance for continued airworthiness of IMA systems related to training,
maintenance, and post-certification modifications of aircraft with IMA systems installed.
Although this guidance is not specific only to an IMA system, the increased level of integration,
Integrated Modular Avionics (IMA)
P a g e | 49
interdependency, and complexity has the potential to introduce new areas of concerns when
maintenance and modification procedures are conducted. Therefore, the guidance for continued
airworthiness becomes of greater concern than in a federated system architecture and should be
thoroughly addressed in the initial design of an IMA system, as well as in the continued
airworthiness process.
7.1 Training
To maintain the continued airworthiness of an IMA system, maintenance personnel and
appropriate flight operations personnel should receive training for the specific IMA system.
During the development of an IMA system, a human factors assessment should be performed to
address the practicalities of operations with the system in normal and degraded configurations
and in recovery situations. Training should ensure that flight operations personnel understand the
effects of degraded mode operations, cascading failures, multiple messages, and aural alerts.
Cascading failures in an IMA system have the potential to hide the primary cause of failure, and
the required flight crew actions may not always be obvious. Therefore, training for the flight
crew of well-defined processes for failure identification, recovery actions (if appropriate), and
failure reporting is required.
Due to the increased integration, interdependency, complexity, and potential for latent and
cascading failures (which can be very difficult to isolate and may not always be obvious to
determine by traditional methods), the training of maintenance personnel is very important to the
continued airworthiness of an IMA system. The information and procedures provided to the
maintenance personnel (i.e., instructions, fault diagnosis, repairs, verification, confirming the
IMA configuration after maintenance work, etc.) should be well planned, accurate, complete, and
easy to understand. For example, identification and diagnosis of faults or failures in an IMA
system may be difficult due to cascading or latent failures, which may hide the primary cause of
failure. Therefore, the training required for fault identification and correction should be thorough
and comprehensive and may be more encompassing for an IMA system than for a federated
system architecture.
7.2 Maintenance
For continued airworthiness, flight operations, and maintenance, the IMA system should be
capable of displaying the status, version, and currency of the loaded software and data. The
configuration of the components of the IMA system should be available to make repairs and
perform any tests or inspections to determine conformance of the system to the approved type
design. Since software can be loaded independently from hardware on the aircraft, the operator
should establish a process for maintaining and recording the IMA system configuration
(identification and revision status of hardware and software components and modules). This
information should be current and maintained as part of the aircraft records.
When loading field-loadable hardware or software, there should be a robust process established
to ensure correct and complete loading, to confirm the hardware or software loaded is approved,
and to verify the upload has not been corrupted (e.g., verification with an appropriate data
transfer integrity check). This process should include checks before and after loading into the
IMA system and to annunciate any failures of the loading. The operator should also be able to
Integrated Modular Avionics (IMA)
P a g e | 50
confirm the compatibility and inter mixability of hardware and software loads with other
components.
7.3 Post-Certification Modifications
Modifications to an IMA system after initial certification should reference the design data and
certification criteria established by the certification applicant. This also applies where the
applicant is not the original certification applicant.
Due to the increased level of integration, interdependency, and complexity of an IMA system,
post-certification modifications should be developed and accomplished with consideration to the
impact on the aircraft safety assessment, IMA system safety assessment, and aircraft certification
basis. When a modification is proposed, a change impact analysis should be performed. This
change impact analysis should determine whether the proposed change could adversely affect
safe operation and continued airworthiness of the IMA system, aircraft, or engine. An area of
concern with an IMA system is when there is a failure that results in numerous failures or alert
messages being displayed and/or aural alerts occurring simultaneously. These messages should
be displayed in a clear and prioritized manner. The priority of aural alerts should be established
(i.e., status, caution, warning, immediate pilot action). In a post-certification modification, these
prioritization hierarchies should be analyzed for continued airworthiness compliance and to
minimize flight crew workload. Under no circumstances should a flight crew be expected to
determine the priority of these messages and alerts and the order in which they should be
addressed, because this could lead to an unacceptable delay in dealing with failures and may
result in an unacceptable safety of flight situation.
8
COMMUNICATION BUS PROTOCOLS FOR AVIONIC SYSTEMS
A number of new and existing data buses are being proposed for use by aircraft manufacturers
and system suppliers. A data bus provides numerous physical and logical configurations for
avionics architecture, data units/packets, protocols, message traffic, and so forth. This allows
considerable design flexibility for system or subsystem suppliers. Flexibility can make it
extremely difficult to establish a type design, to determinate compliance, and to maintain
continued airworthiness. This report gives a comparative overview of data bus protocols targeted
for aerospace controls that should be considered by implementers when developing, selecting, or
integrating aerospace control systems in the context of aerospace projects.
Current developments and future trends are having enormous effects on the aerospace industry.
While the life cycle of aircraft is increasing, the life cycle of their electronic components is
decreasing. As more and more electric applications are finding their way into airplanes, the
complexity of the overall system is growing. But all-electric aircraft require higher levels of
safety, reliability and availability. Additionally, the cost pressure for development and operation
is constantly rising. This calls for reusability of software and hardware components and its
certification basis across several aircraft projects – both commercial and military.
Integrated Modular Avionics (IMA)
P a g e | 51
8.1 ARINIC 429 Specification Overview
The ARINC 429 digital data bus became the first standard data bus to be applied in civil
aircrafts, e.g., in Airbus A300/310, A318 and A340-500 / 600, and Boeing 757 and 767. Before
the development of ARINC 629 and ARINC 664/ AFDX, it was the most widely used means for
communication between controllers or controllers and smart peripheral devices. The ARINC 429
Specification establishes how avionics equipment and systems communicate on commercial
aircraft. The specification defines electrical characteristics, word structures and protocol
necessary to establish bus communication. ARINC 429 utilizes the simplex, twisted shielded pair
data bus standard Mark 33 Digital Information Transfer System bus.
ARINC 429 defines both the hardware and data formats required for bus transmission. Hardware
consists of a single transmitter or source connected to from 1-20 receivers or sinks on one
twisted wire pair. Data can be transmitted in one direction only – simplex communication – with
bi-directional transmission requiring two channels or buses. The devices, line replaceable units
or LRUs, are most commonly configured in a star or bus-drop topology( see figure 7). Each LRU
may contain multiple transmitters and receivers communicating on different buses. This simple
architecture, almost point-to-point wiring, provides a highly reliable transfer of data.
Figure 7: ARINC 429 Bus Topology
A transmitter may ‘talk only’ to several receivers on the bus, up to 20 on one wire pair, with each
receiver continually monitoring for its applicable data, but does not acknowledge receipt of the
data. A transmitter may require acknowledgement from a receiver when large amounts of data
have been transferred. This handshaking is performed using a word style, as opposed to a hardIntegrated Modular Avionics (IMA)
P a g e | 52
wired handshake. When this two-way communication format is required, two twisted pairs
constituting two channels are necessary to carry information back and forth, one for each
direction. Transmission from the source LRU is comprised of 32-bit words containing a 24-bit
data portion containing the actual information, and an 8-bit label describing the data itself. LRUs
have no address assigned through ARINC429, but rather have Equipment ID numbers which
allow grouping equipment into systems, which facilitates system management and file transfers.
ARINC 429 uses a self-clocking, self-synchronizing data bus protocol (Tx and Rx are on
separate ports). The physical connection wires are twisted pairs carrying balanced differential
signaling. Data words are 32 bits in length and most messages consist of a single data word.
Messages are transmitted at either 12.5 or 100 kbps to other system elements that are monitoring
the bus messages. The transmitter constantly transmits either 32-bit data words or the NULL
state (0 Volts). A single wire pair is limited to one transmitter and no more than 20 receivers.
The protocol allows for self-clocking at the receiver end, thus eliminating the need to transmit
clocking data.
8.2 Cable Characteristics
The transmission bus media uses a 78  shielded twisted pair cable. The shield must be
grounded at each end and at all junctions along the bus (see figure 8).
Figure 8: ARINC 429 Cable Characteristics
The transmitting source output impedance should be 75  ± 5  divided equally between Line A
and Line B. This balanced output should closely match the impedance of the cable. The
receiving sink must have an effective input impedance of 8k  minimum. Maximum length is
not specified, as it is dependent on the number of sink receivers, sink drain and source power.
Most systems are designed for under 150 feet, but conditions permitting, can extend to 300 feet
and beyond.
8.3 Transmission Characteristics
ARINC429 specifies two speeds for data transmission. Low data rate operation is stated at 12.5
kbps, with an actual allowable range of 12 to 14.5 kbps. High data rate operation is 100 kbps ±
1% allowed. These two data rates cannot be used on the same transmission bus. Data is
Integrated Modular Avionics (IMA)
P a g e | 53
transmitted in a bipolar, Return-to-Zero format. This is a tri-state modulation consisting of
HIGH, NULL and LOW states.
Transmission voltages are measured across the output terminals of the source. Voltages
presented across the receiver input will be dependent on-line length, stub configuration and the
number of receivers connected. The following (see table 1) voltage levels indicate the three
allowable states:
TRANSMIT
+10.0 V ± 1.0 V
STATE
HIGH
RECEIVE
+6.5 to 13 V
0 V ± 0.5V
NULL
+2.5 to -2.5 V
-10.0 V ± 1.0 V
LOW
-6.5 to -13 V
Table 1: ARINC 429 Signal states
In bipolar, Return-to-Zero or RZ format, a HIGH (or 1) is achieved with the transmission signal
going from NULL to +10 V for the first half of the bit cycle, then returning to zero or NULL. A
LOW (or 0) is produced by the signal dropping from NULL to –10 V for the first half bit cycle,
then returning to zero. With a Return-to-Zero modulation format, each bit cycle time ends with
the signal level at 0 Volts, eliminating the need for an external clock, creating a self-clocking
signal.
An example of the bipolar, tri-state RZ signal is shown in figure 9:
Figure 9: ARINC 429 Signal Encoding
Integrated Modular Avionics (IMA)
P a g e | 54
8.4 Waveform Parameters
Pulse rise and fall times are controlled by RC circuits built into ARINC429 transmitters. This
circuitry minimizes overshoot ringing common with short rise times. Allowable rise and fall
times are shown in figure 10 for both bit rates. Bit and ½ bit times are also defined in table 2.
Figure 10: ARINC 429 Signal Waveform Parameters
High Speed
100 kbps ± 1%
10 msec ± 2.5%
5 msec ± 5%
1.5 msec ± 0.5 msec
1.5 msec ± 0.5 msec
Bit Rate
1-bit time
½ bit time
Rise Time
Fall Time
Low Speed
12 – 14.5 kbps ± 1%
(1/Bit rate) msec ± 2.5%
(1-bit time/2) ± 5%
10 msec ± 5 msec
10 msec ± 5 msec
Table 2 : ARINC 429 signal waveform parameters
8.5 Word Formats
ARINC429 protocol uses a point-to-point format, transmitting data from a single source on the
bus to up to 20 receivers. The transmitter is always transmitting, either data words or the NULL
state. Most ARINC messages contain only one data word consisting of either Binary (BNR),
Binary Coded Decimal (BCD) or alphanumeric data encoded using ISO Alphabet No. 5. File
data transfers that send more than one word are also allowed.
ARINC429 data words are 32-bit words made up of five primary fields(see figure 11):
 Parity – 1 bit
 Sign/Status Matrix (SSM) – 2 bits
Integrated Modular Avionics (IMA)
P a g e | 55



Data – 19 bits
Source/Destination Identifier (SDI) – 2 bits
Label – 8 bits
Figure 11: ARINC 429 Word Format
8.5.1 Parity
ARINC429 defines the Most Significant Bit (MSB) of the data word as the Parity bit. ARINC
uses odd parity as an error check to insure accurate data reception. The number of Logic 1s
transmitted in each word is an odd number, with bit 32 being set or cleared to obtain the odd
count. ARINC429 specifies no means of error correction, only error detection.
8.5.2 Sign/Status Matrix
Bits 31-30 are assigned as the Sign/Status Matrix field or SSM. Depending on the words Label,
which indicates which type of data is being transmitted, the SSM field can provide different
information. This field can be used to indicate sign or direction of the words data, or report
source equipment operating status and is dependent on the data type.
SSM
Data Dependent SSM Encodings:
Bit
31
Bit
30
Sign/Status Matrix for BCD
Data
Status Matrix for
BNR Data
Status Matrix for
Discrete Data
0
0
Plus, North, East, Right, To,
Above
Failure Warning (FW)
Verified Data, Normal
Operation
0
1
No Computed Data (NCD)
No Computed Data
(NCD)
No Computed Data
(NCD)
1
0
Functional Test (FT)
Functional Test (FT)
Functional Test (FT)
1
1
Minus, South, West, Left,
From, Below
Normal Operation
(NO)
Failure Warning (FW)
Table 3:Sign/Status Matrix Encoding
Integrated Modular Avionics (IMA)
P a g e | 56
8.5.3 Data
ARINC429 defines bits 11-29 as those containing the word’s data information. Formatting of the
data bits, indeed the entire ARINC429 word, is very flexible. When transmitting data words on
the ARINC bus, the Label is transmitted first, MSB first, followed by the rest of the bit field,
LSB first. Bit transmission order looks like this:
Figure 12: ARINC 429 Data Format
The Label is always transmitted first, in reverse order to rest of the ARINC word – a
compensation for compatibility with legacy systems. The receiving LRU is responsible for data
translation and regrouping of bits into proper order.
Data types available in ARINC429 are:





Binary – BNR – Transmitted in fractional two’s complement notation
Binary Coded Decimal – BCD – Numerical subset of ISO Alphabet No.5
Discrete Data – Combination of BNR, BCD or individual bit representation
Maintenance Data and Acknowledgement – Requires two-way communication
Williamsburg/Buckhorn Protocol – A bit-oriented protocol for file transfers
8.5.4 Source/Destination Identifier
The Source/Destination Identifier – SDI – utilizes bits 9-10 and is optional under the ARINC429
Specification. The SDI can be used to identify which source is transmitting the data or by
multiple receivers to identify which receiver the data is meant for. For higher resolution data, bits
9-10 may be used instead of using them as an SDI field. When used as an Identifier, the SDI is
interpreted as an extension to the word Label.
8.5.5 Label
Bits 1-8 contain the ARINC label known as the Information Identifier. The Label is expressed as
a 3-digit octal number with receivers programmed to accept up to 255 Labels. The Label’s Most
Significant Bit resides in the ARINC word’s Least Significant Bit location.
Figure 13: ARINC 429 Label Bit Structure
Integrated Modular Avionics (IMA)
P a g e | 57
The Label is used to identify the word’s data type (BNR, BCD, Discrete, etc) and can contain
instructions or data reporting information. Labels may be further refined by utilizing the first 3
bits of the data field, Bits 11-13, as an Equipment Identifier to identify the bus transmission
source. Equipment IDs are expressed in hexadecimal values.
For example, BNR Label 102 is Selected Altitude. This data can be received from the Flight
Management Computer (Equipment ID 002Hex), the DFS System (Equipment ID 020Hex) or
the FCC Controller (Equipment ID 0A1Hex). The Label is always sent first in an ARINC
transmission and is a required field, as is the Parity bit. Labels are transmitted MSB first,
followed by the rest of the ARINC word, transmitted LSB first.
8.6 Protection from interference
Avionics systems are required to meet environmental requirements, usually stated as RTCA DO160 environmental categories. ARINC 429 employs several physical, electrical, and protocol
techniques to minimize electromagnetic interference with on-board radios and other equipment,
for example via other transmission cables. Its cabling is a shielded 78 Ω twisted-pair. ARINC
signaling defines a 20Vp differential between the Data A and Data B levels within the bipolar
transmission (i.e. 10V on Data A and -10V on Data B would constitute a valid driving signal),
and the specification defines acceptable voltage rise and fall times.
ARINC 429's data encoding uses a complementary differential bipolar return-to-zero (BPRZ)
transmission waveform, further reducing EMI emissions from the cable itself.
8.7 Design Assurance Level (DAL) for ARINIC 429
ARINC 429 is a serial protocol used in most commercial aircrafts for connecting between the
aircraft’s avionics systems. DO-254 is a formal safety standard that applies to complex aircraft
hardware. It provides guidance for the design and development of electronic hardware for
airborne systems. DO-254 defines five design assurance levels (DALs) of compliance, which
determines the effect a failure of the hardware will have on the operation of the aircraft. Level A
is the most severe, defined as "catastrophic" (e.g. loss of the aircraft), while a failure of Level E
hardware will not affect the safety of the aircraft.
The main regulations which must be followed are requirements capturing and tracking
throughout the design and verification process. Meeting DAL-A compliance for complex
electronic hardware requires a much higher level of verification and validation than DAL-E
compliance. Any software that commands, controls, and monitors safety-critical functions should
receive the highest DAL - Level A. DO-178C, Software Considerations in Airborne Systems and
Equipment Certification is the primary document by which the certification authorities such as
FAA and EASA approve all commercial software-based aerospace systems.
Integrated Modular Avionics (IMA)
P a g e | 58
Figure 14: ARINC 429 IP Core on FPGA
Now, ARINC 429 soft IP core for Tx and Rx channels ( see figure 14) that can be certified with
DO-254 DAL-A through DAL-E.
8.8 Pros and Cons of ARINC 429
The ARINC 429 data bus operates in a single-source-to-multiple-sinks unidirectional mode so
that each sender can transmit a message to different receivers but for replying to the sender
separate data busses are required (one for each sender). Thus, collision avoidance is inherent.
Security issues and access rights have not been considered in the ARINC 429 standard because
the data bus is only intended for static networks of mechanically integrated controllers and
peripheral equipment.
Summarizing, the pros and cons of ARINC 429 are:
a. Pros:






standardized labels
Digital data bus helps to reduce the wiring needed to connect different controllers
single-source-to-multiple-sinks mode means that it is well suited for inter
controller and controller-to-actuator communication that often distributes one
information to many receivers.
unidirectional mode determines the roles of sender and receivers but can result in
additional data busses for acknowledgments or replies
small ARINC data packages support guaranteed real-time behavior
not for dynamic open networks but very reliable for static networks
Integrated Modular Avionics (IMA)
P a g e | 59
b. Cons
 single-source-to-multiple-sinks mode also means that it is not suited for sensor-tocontroller communication because the wiring reduction seems to be negligible
(although only one data bus is needed to transmit the status information to
redundant controllers)
 single-source data bus means that each piece of equipment needs as many input
ports as the number of sources it expects to receive data from.
 small payload may lead to low throughput, i.e., ARINC 429 cannot be used for
audio or video transmission
9
MIL-STD-1553
9.1
Introduction
MIL-STD-1553 is a serial data bus that has been used as the primary command and control
interconnect in military aircraft for the past three decades. It is a military standard published by
United States department of defense that defines the mechanical, electrical and functional
characteristics of serial data bus. The first draft of a standard was published by SAE (Society of
Automotive Engineers) in 1968 and was adopted in 1973 by the US Air force, the Mil-Std1553A was released in 1975 and the B version was adopted in 1978. In the beginning it was a
bus used in military planes but soon after, its utilization extended to aerospace and to another
field.
Since its inception in 1973 and in subsequent revisions during the ensuing years, MIL-STD-1553
has evolved into the predominant, internationally accepted networking standard for the
integration of military platforms. Today, the standard has expanded beyond its traditional domain
of US Air Force and Navy aircraft to encompass applications for combat vehicles, ships,
satellites, missiles, and the International Space Station Program. More recently MIL-STD-1553
has been selected for use in the primary flight control system for a commercial aircraft.
All of these applications share common requirements for a reliable, fault tolerant data bus that
will operate in relatively harsh environments such as lightning immunity, wide temperature
range, high vibration, and high electromagnetic interference (from sources such as radar). MILSTD-1553 was explicitly designed to operate in these demanding environments.
9.2
MIL-STD-1553 Characteristics
Characteristics of MIL-STD-1553 is listed in tabular form (Table 4)
Data Rate
Word Length
Data Bits/ Word
Message length
Transmission Technique
Operation
Encoding
Integrated Modular Avionics (IMA)
1 MHZ
20 bits
16 bits
Maximum 32 data words
Half- duplex / Semi - duplex
Asynchronous
Manchester II bi- phase
P a g e | 60
Protocol
Fault tolerance
Command/Response
Typically, Dual Redundant, second bus in “Hot
Backup” status
Message Formats
 Bus controller to Remote terminal (BCRT)
 Remote Terminal to Bus Controller
(RT-BC)
 Remote Terminal to Remote Terminal
(RT-RT)
 Broadcast Protocol
Number of Remote Terminals
Maximum of 31
Transmission Media
Twisted shielded pair
Coupling
Transformer and Direct
Terminal Types
 Remote Terminal
 Bus Controller
 Bus Monitor
Table 4: Characteristics of MIL-STD-1553
9.3
Hardware Elements
Bus Controller (BC)
The bus controller’s main function is to provide data flow control for all transmissions on the
bus. In this role, the bus controller is the sole source of communication. The system uses a
command response method which means the BC sends a command to the RTs, which reply with
a response.
Bus Monitor (BM)
The bus monitor listens to all messages, and subsequently collects data from the data bus without
it being a part of the communication processes. The data to be recorded can be set, which is an
important instrument for troubleshooting. The BM is a passive device that collects data for realtime or post capture analysis. The BM can store all or portions of traffic on the bus, including
electrical and protocol errors. BMs are primarily used for instrumentation and data bus testing.
Remote Terminal (RT)
The remote terminal (RT) is a device designed to interface various subsystems with the 1553
data bus. The interface device may be embedded within the subsystem itself, or be an external
interface to tie a non-1553 compatible device to the bus. As a function of the interface
requirement, the RT receives and decodes commands from the BC, detects any errors and reacts
to those errors. The RT must be able to properly handle both protocol errors (missing data, extra
words, etc.) and electrical errors (waveform distortion, rise time violations, etc.). RTs are the
largest segment of bus components.
Characteristics of Remote terminal include:
Integrated Modular Avionics (IMA)
P a g e | 61


Up to 31 remote terminals can be connected to the data bus
No remote terminal shall speak unless spoken to first by the bus controller and
specifically commanded to transmit
Data bus / Transmission Media
The transmission media, or data bus, is defined as a twisted shielded pair transmission line
consisting of the main bus and a number of stubs. Shielding limits signal interference from
outside sources and the twisted pair maintains message integrity through noise canceling. Bus
controller and the Remote terminals are connected to the line through stubs and couplers. MILSTD-1553B specifies that all devices in the system will be connected to a redundant pair of
buses, providing an alternate data path in the event of damage or failure of the primary bus path.
Bus messages only travel on one of the buses at a time, determined by the bus controller (see
Figure 15).
Figure 15 : Data Bus Architecture
9.4
Bus Topology
Bus topology refers to the physical layout and connections of each device attached to the data
bus. Single level topologies are the most basic, easy to design and widely implemented layouts
with all terminal devices connected to a single bus(see Figure 16).
Integrated Modular Avionics (IMA)
P a g e | 62
Figure 16: Single Level Bus Topology
Multiple level topologies are designed by interconnecting single level buses so data from one bus
can be transferred on another bus. Buses interconnected in a multiple level topology can have
equal control over data flow, which helps retain autonomy for each bus with the greatest
isolation between them. A hierarchical format between multiple level buses establishes local
(subordinate) buses and global (superior) buses with the global bus having control over local,
subordinate buses(see Figure 17).
Figure 17 : Multi Level Bus Topology
9.5
Coupling
Coupling connects a terminal device to the main data bus via interconnecting buses called stubs.
MIL-STD-1553B allows two methods of coupling terminal devices to the main bus
Integrated Modular Avionics (IMA)
P a g e | 63
a. Direct Coupling
b. Transformer Coupling
Direct Coupling
Direct coupling connections are wired directly to the bus cabling. The isolation resistors and
transformer are internal to the terminal device, not requiring additional coupling hardware.
Direct coupling connections can only be used with stub lengths of less than 1 foot(see Figure
18).
Figure 18 : Direct Coupling
Transformer Coupling
Transformer coupling utilizes a second isolation transformer, located external to the terminal
device, in its own housing with the isolation resistors(see Figure 19). Transformer coupling
extends the stub length to 20 feet and provides electrical isolation, better impedance matching
and higher noise rejection characteristics than direct coupling.
Integrated Modular Avionics (IMA)
P a g e | 64
Figure 19 : Transformer Coupling
9.6
Word Formats
Three-word formats are present in MIL-STD-1553. These formats can be seen from figure 20.
Command Word
A command word shall be comprised of a sync waveform, remote terminal address field,
transmit/receive (T/R) bit, Sub address/mode field, word count/mode code field, and a parity
(P) bit.
Data Word
A data word shall be comprised of a sync waveform, data bits, and a parity bit
Status word:
A status word comprises five bits to identify the responding remote terminal, and a series
of bits to indicate the remote terminal status.
Integrated Modular Avionics (IMA)
P a g e | 65
Figure 20 : Word Format
9.7
Bus Protocols
Bus controller to Remote terminal (BC-RT) protocol
The RT to BC transaction is shown in Figure 21. The BC issues a receive command identifying
within it the bus address of the RT which is to receive data, the data packet (sub-address mode)
to be received, and the number of data words in the packet. The BC then immediately appends
the data packet (with no gap). After a brief time gap (4–12μs) the receiving RT responds with its
status, advising the BC that it has correctly received the message (or not). This completes the BC
to RT command/response transaction handshake. After a short inter-message gap (>4 μs but
typically <8μs) the BC can commence the next transaction.
Integrated Modular Avionics (IMA)
P a g e | 66
Figure 21 : BC to RT transaction protocol
Remote terminal to Bus controller protocol (RT-BC) Protocol
The RT to BC transaction is shown in Figure 22. The remote terminal to bus controller (RT-BC)
message is referred to as a transmit command. The bus controller issues only a transmit
command word to the remote terminal. The terminal, on validating the command word, transmits
its status word followed by the number of data words requested by the command word. The BC
of course knows whether it has received the data packet correctly or not, so it has no need to
issue a status word.
Figure 22 : RT to BC transaction protocol
Remote Terminal to Remote Terminal (RT-RT) Protocol
The RT to RT transaction is shown in Figure 23. It is a composite of the RT-BC and BC-RT
transactions. The BC first issues a receive command to make ready the RT designated to receive
the data, then secondly issues a transmit command to the RT that is to transmit the data. After a
short response time gap, the transmitting RT responds first with its status immediately followed
by its data packet. After a short response time gap the receiving RT responds with its status. This
completes the RT to RT transaction handshake, and after a further short inter-message gap the
BC can then commence the next transaction.
Integrated Modular Avionics (IMA)
P a g e | 67
Figure 23 : RT to RT transaction protocol
Broadcast Protocol
The broadcast transaction is a command plus data issued by the BC to all RTs. The MIL-STD
advises that it is to be used infrequently. Typically, it is used at start-up to synchronize all RTs
before bus transactions begin. There can be no status words issued in response to a broadcast
command, since if there were, all RTs would respond at the same time. So the BC is unaware
of any transaction errors, hence the reason that this command is to be used advisedly.
9.8
Error Management
There are a wide range of error management strategies possible in MIL-STD-1553B. The bus
controller knows the status of every transaction message. The standard does not mandate any
particular strategy; it is up to the bus designer to implement the most appropriate strategy for his
bus implementation to meet his availability, integrity and temporal response (latency)
requirements. To design a particular implementation, the bus designer compiles a list of all of the
messages with all the RTs on the bus. From this he compiles an execution list called a transaction
table. The bus controller sequentially executes the transaction table until all transactions are
complete, then after any retries the process repeats (usually at a fixed repetition rate). Thus it can
be seen that the process is highly deterministic and the high degree of error detection and
correction affords high integrity.
Typical error management strategies include:




Immediately retry the faulty transaction on the same bus;
Retry the faulty transaction on the reversionary/alternate bus;
Retry the faulty transaction when all other transactions are complete (at the end of the
major cycle);
Build a fault log associated with each RT and cease communication with a faulty RT if a
threshold fault rate is exceeded.
Integrated Modular Avionics (IMA)
P a g e | 68
9.9
Fault Isolation
MIL-STD-1553 provides the benefit of fault isolation through the use of series resistors in the
path between stubs and the main bus. The fault isolation resistors will allow the network to
continue operating even in the presence of a short circuit on one of the stub connections.
9.10 MIL-STD-1553 Test Procedures
Testing of a MIL-STD-1553 terminal or system is a not a trivial task. There are a large number
of options available. A few of these include message formats, mode commands, status word bits,
and coupling methodology. For years, the Air Force provided for testing of MIL-STD-1553
terminals and components. Today, this testing is the responsibility of industry. The SAE, in
conjunction with the government, has developed a series of Test Plans for all 1553 elements.
Testing MIL-STD-1553B components validate the functional capability of the bus design.
Testing the design of a bus requires testing message formats, mode commands, status word bits
and coupling techniques as they apply to each remote terminal, bus controller and monitor
device. Five levels of testing have been developed to verify MIL-STD-1553B bus design
compliance.
a.
b.
c.
d.
e.
Development Testing
Design Verification
Production Testing
System Integration Testing
Field/Operational Testing
Development Testing
Developmental Testing is implemented at the circuit level to determine operational capability of
the circuit design. Standard test techniques also validate operating characteristics over the
required environmental operating range – i.e. temperature, humidity, vibration, etc.
Design Verification
Design Verification is carried out on pre-production prototypes to insure 1553 compliance as
well as systems specifications on the design unit itself. This testing level verifies hardware/
software requirements before production begins.
Production Testing
Production Testing is performed on production equipment as a final Quality Assurance check or
during the production process on subassembly items. Often applying a subset of the design
verification tests, Production Testing verifies circuit operation and proper sequence operations
such as error message validation and mode code operation.
Integrated Modular Avionics (IMA)
P a g e | 69
System Integration Testing
Systems Integration Testing is applied while integrating bus components into a system and
insures interoperability of the joined components. During Systems Integration Testing, network
hardware and software are combined and assessed to insure proper data flow control.
Field/Operational Testing
Field/Operational Testing is implemented as a final design test of the system under actual
operating conditions. Known as Developmental Test (DT) /Operational Test (OT) – this level of
testing verifies operational integrity of the components/system in installed, fully functional
bus networks.
9.11 MIL-STD-1553 Test Plans
For years, the Air Force provided for testing of MIL-STD-1553 terminals and components.
Today, this testing is the responsibility of industry. The SAE, in conjunction with the
government, has developed a series of test plans for all 1553 elements. These test plans are listed
in Table 4.
Document Number
ML-HDBK-1553
ML-HDBK-1553A
SAEAS4112
SAEAS4113
SAEAS4114
SAEAS4115
SAEAS4116
SAEAS4117
Test Plan
Remote Terminal Validation Test Plan Notice 1
Remote Terminal Validation Test Plan Section 100
Remote Terminal Production Test Plan
Bus Controller Validation Test Plan
Bus Controller Production Test Plan
Data Bus System Test Plan
Bus Monitor Test Plan
Bus Components Test Plan
Table 5 : Test Plans
9.12 Design Assurance Level (DAL) for MIL-STD-1553
MIL-STD-1553 overall bus possesses DAL C when used in military aircraft (BC is DAL C).
Although MIL-STD-1553 was originally designed for use with military avionics, due to its
robustness and safety it has recently become increasingly considered for use in commercial
aircraft. MIL-STD-1553 has caught the attention of commercial aircraft manufacturers, such as
Airbus, who seek to capitalize upon 1553 inherent reliability, robustness, maturity, and superior
EMI performance. Airbus has selected MIL-STD-1553 components from Data Device
Corporation for use in critical primary flight control systems on the A350 XWB. Another
important consideration influencing Airbus choice was that few organizations (e.g.: DDC (Data
Device Corporation)) products facilitate achieving RTCA/DO-254 Level A certification, a
significant factor in the avionics industry.
Integrated Modular Avionics (IMA)
P a g e | 70
10
AFDX/ARINC664
Avionics Full-Duplex Switched Ethernet (AFDX) is a data network, patented by international
aircraft manufacturer Airbus for safety-critical applications that utilizes dedicated bandwidth
while providing deterministic quality of service (QoS). AFDX is a worldwide registered
trademark by Airbus. The AFDX data network is based on Ethernet technology using
commercial off-the-shelf (COTS) components. The AFDX data network is a specific
implementation of ARINC Specification 664 Part 7, a profiled version of an IEEE 802.3
network, which defines how commercial off-the-shelf networking components will be used for
future generation Aircraft Data Networks (ADN). The six primary aspects of an AFDX data
network include full duplex, redundancy, determinism, high speed performance, switched and
profiled network.
10.1 AFDX/ARINC 664 Antecedents
Moving information between avionics subsystems on board an aircraft has never been more
crucial, and it is here that electronic data transfer is playing a greater role than ever before. Since
its entry into commercial airplane service on the Airbus A320 in 1988, the all-electronic fly-bywire system has gained such popularity that it is becoming the only control system used on new
airliners.
But there are a host of other systems inertial platforms, communication systems, and the like on
aircraft that demand high-reliability, high-speed communications. As well Control systems and
avionics in particular rely on having complete and up-to-date data delivered from source to
receiver in a timely fashion. For safety-critical systems, reliable real-time communications links
are essential. That is where AFDX comes in. Initiated by Airbus in the evolution of its A380
Aircraft, they coined the term AFDX for Avionics Full Duplex switched Ethernet. AFDX brings
a number of improvements such as higher-speed data transfer and with regard to the host
airframe significantly less wiring, thereby reducing wire runs and the attendant weight. It is
currently used on the Airbus A380, A350, A400M, Boeing 787 Dreamliner, the COMAC ARJ21
and the Sukhoi Super-jet 100, and is likely to become the standard communications network on
most future civil transport aircraft.
10.2 AFDX/ARINC 664 Introduction
Avionics Full Duplex Switched Ethernet (AFDX) is a standard that defines the electrical and
protocol specifications (IEEE 802.3 and ARINC 664, Part 7) for the exchange of data between
Avionics Subsystems. One thousand times faster than its predecessor, ARINC 429, it builds upon
the original AFDX concepts introduced by Airbus. One of the reasons that AFDX is such an
attractive technology is that it is based upon Ethernet, a mature technology that has been
continually enhanced, ever since its inception in 1973. In fact, the commercial investment and
advancements in Ethernet have been huge compared say, to ARINC 429, MIL-STD-1553, and
other specialized data-communications technologies.
Integrated Modular Avionics (IMA)
P a g e | 71
Figure 24: AFDX Network
As shown in Figure 24, an AFDX system comprises the following components:
10.2.1 Avionics Subsystem
The traditional Avionics Subsystems on board an aircraft, such as the flight control computer,
global positioning system, tire pressure monitoring system, etc. An Avionics Computer System
provides a computational environment for the Avionics Subsystems. Each Avionics Computer
System contains an embedded End System that connects the Avionics Subsystems to an AFDX
Interconnect.
10.2.2 AFDX End System (End System)
Provides an “interface” between the Avionics Subsystems and the AFDX Interconnect. Each
Avionics Subsystem the End System interface to guarantee a secure and reliable data interchange
with other Avionics Subsystems. This interface exports an application program interface (API) to
the various Avionics Subsystems, enabling them to communicate with each other through a
simple message interface.
10.2.3 AFDX Interconnect:
A full-duplex, switched Ethernet interconnect. It generally consists of a network of switches that
forward Ethernet frames to their appropriate destinations. This switched Ethernet technology is a
departure from the traditional ARINC 429 unidirectional, point-to-point technology and the
MIL-STD-1553 bus technology.
As shown in the in Figure 24, two of the End Systems provide communication interfaces for
three avionics subsystems and the third End System supplies an interface for a Gateway
application. It, in turn, provides a communications path between the Avionics Subsystems and
the external IP network and typically, is used for data loading and logging.
Integrated Modular Avionics (IMA)
P a g e | 72
10.3 Ethernet
Ethernet is a way of connecting computers together in a local area network or LAN. It has been
the most widely used method of linking computers together in LANs since the 1990s. The basic
idea of its design is that multiple computers have access to it and can send data at any time in
form of packets.
10.3.1 Ethernet Introduction
AFDX was designed as the next-generation aircraft data network. Basing on standards from the
IEEE 802.3 committee (commonly known as Ethernet) allows commercial off-the-shelf
hardware to reduce costs and development time. AFDX is one implementation of deterministic
Ethernet defined by ARINC Specification 664 Part 7. AFDX adopted concepts such as the token
bucket from the telecom standards, asynchronous transfer mode (ATM), to fix the shortcomings
of IEEE 802.3 Ethernet. By adding key elements from ATM to those already found in Ethernet,
and constraining the specification of various options, a highly reliable full-duplex deterministic
network is created providing guaranteed bandwidth and quality of service (QoS). Through the
use of full-duplex Ethernet, the possibility of transmission collisions is eliminated. The network
is designed in such a way that all critical traffic is prioritized using QoS policies, so delivery,
latency, and jitter are all guaranteed to be within set parameters.
The Ethernet communication protocol is referred to as “CSMA/CD” (Carrier Sense, Multiple
Access, and Collision Detection). Carrier Sense means that the hosts can detect whether the
medium (coaxial cable) is idle or busy. Multiple Access means that multiple hosts can be
connected to the common medium. Collision Detection means that, when a host transmits, it can
detect whether its transmission has collided with the transmission of another host (or hosts). The
original Ethernet data rate was 2.94Mbps.
Figure 25: Ethernet Local Area Network
10.3.2 Ethernet Frame format
As Figure 25 illustrates, IEEE 802.3 defines the format of an Ethernet transmission to include a
7-byte Preamble, a Start Frame Delimiter (SFD), the Ethernet frame itself, and at end Inter
Frame Gap (IFG) consisting of at least 12 bytes of idle symbols. The Ethernet frame begins with
the Ethernet header, which consists of a 6-byte destination address, followed by a 6-byte source
address, and a type field. The Ethernet payload follows the header. The frame concludes with a
Integrated Modular Avionics (IMA)
P a g e | 73
Frame Check Sequence (FCS) for detecting bit errors in the transmitted frame, followed by an
IFG. The length of an Ethernet frame can vary from a minimum of 64 bytes to a maximum of
1518 bytes.
Figure 26: Ethernet Local Area Network
10.3.3 Half-duplex mode Switched Ethernet
Half-duplex Mode Ethernet is another name for the original Ethernet Local Area Network
discussed earlier. As we explained, there is an issue when multiple hosts are connected to the
same communication medium as is the case with coaxial cable, depicted in Figure 27, and there
is no central coordination. It is possible for two hosts to transmit “simultaneously” so that their
transmissions “collide”. Thus, there is a need for the hosts to be able to detect transmission
collisions. When a collision occurs (two or more hosts attempting to transmit at the same time),
each host has to retransmit its data. Clearly, there is a possibility that they will retransmit at the
same time, and their transmissions will again collide. To avoid this phenomenon, each host
selects a random transmission time from an interval for retransmitting the data. If a collision is
again detected, the hosts selects another random time for transmission from an interval that is
twice the size of the previous one, and so on. This is often referred to as the binary exponential
back off strategy. Therefore, in half-duplex mode it is possible for there to be very large
transmission delays due to collisions. This situation is unacceptable in an avionics data network.
So, what was required (and what was implemented in AFDX) was an architecture in which the
maximum amount of time it would take any one packet to reach its destination is known. That
meant ridding the system of contention.
10.3.4 Full-duplex Switched Ethernet
To do away with contention (collisions), and hence the indeterminacy regarding how long a
packet takes to travel from sender to receiver, it is necessary to move to Full-duplex Switched
Ethernet. Full-duplex Switched Ethernet eliminates the possibility of transmission collisions like
the ones that occur when using Half-duplex Based Ethernet. As shown in Figure 27, each
Avionics Subsystem autopilot, heads-up display, etc. is directly connected to a Switch over a
full-duplex link that comprises two twisted pairs one pair for transmit (Tx) and one pair for
receive (Rx). (The switch comprises all the components contained in the large box.) The switch
is able to buffer packets for both reception and transmission.
Integrated Modular Avionics (IMA)
P a g e | 74
Figure 27: Full-Duplex, Switched Ethernet Example
The Rx and Tx buffers in the switch are both capable of storing multiple incoming/outgoing
packets in FIFO (first-in, first out) order. The role of the I/O processing unit (CPU) is to move
packets from the incoming Rx buffers to the outgoing Tx buffers. It does this by examining each
arriving packet that is next in line in the Rx buffer to determine its destination address (virtual
link identifier) and then goes to the Forwarding Table to determine which Tx buffers are to
receive the packet. The packet is then copied into the Tx buffers, through the Memory Bus, and
transmitted (in FIFO order) on the outgoing link to the selected Avionic Subsystem or to another
switch. This type of switching architecture is referred to as store and forward. Consequently,
with this full-duplex switch architecture the contention encountered with half-duplex Ethernet is
eliminated, simply because the architecture eliminates collisions. Theoretically, a Rx or Tx
buffer could overflow, but if the buffer requirement in an avionics system are sized correctly,
overflow can be avoided. There are no collisions with full-duplex switched Ethernet, but packets
may experience delay due to congestion in the switch. Instead of collisions and retransmissions,
switching architecture may result in jitter, due to the random delay introduced by one packet
waiting for another to be transmitted. The extent of jitter introduced by an End System and
Switch must be controlled if deterministic behavior of the overall Avionics System is to be
achieved.
10.4 AFDX vs. ARINC 429 Architecture
In addition to the enhancements, AFDX delivers some additional benefits, compared to ARINC
429. Figure 28 shows some distinctions between ARINC 429 and AFDX. In ARINC 429, a
twisted pair must link every device that receives the azimuth signal form the inertial platform.
The point to- multi-point and unidirectional properties of ARINC 429 means that the avionics
system must include an ARINC 429 bus for each communication path. In a system with many
end points, point-to-point wiring is a major overhead. This can lead to some huge wiring
harnesses, with the added weight that goes along with them.
Integrated Modular Avionics (IMA)
P a g e | 75
Figure 28: AFDX vs. ARINC 429 Architecture
But in the case of AFDX, as shown in Figure 28, each signal is connected to the switch only
once so that no matter how many subsystems require the azimuth signal from the inertial
platform, they need not be connected individually to the inertial platform. With ARINC 429, a
transmitter can fan out to only 20 receivers. With AFDX, the number of fan-outs from the
inertial platform is limited only by the number of ports on the switch. Also, by cascading
switches, the fan-out can be easily increased as needed.
10.4.1 End Systems and Avionics Subsystems
Avionics computer system connects to the AFDX network through an End System. In general, an
Avionics computer system is capable of supporting multiple Avionics subsystems. Partitions
provide isolation between Avionics subsystems within the same Avionics computer system. This
isolation is achieved by restricting the address space of each partition and by placing limits on
the amount of CPU time allotted to each partition. The objective is to ensure that an errant
Integrated Modular Avionics (IMA)
P a g e | 76
Avionics subsystem running in one partition will not affect subsystems running in other
partitions.
Figure 29: End Systems and Avionics Subsystems Example
Avionics applications communicate with each other by sending messages using communication
ports. The specification of an operating system API for writing portable avionics applications can
be found in ARINC 653. In particular, ARINC 653 defines two types of communications ports –
sampling and queuing ports. Accordingly, it is necessary that End Systems provide a suitable
communications interface for supporting sampling and queuing ports. The AFDX ports, defined
in ARINC 664, Part 7, include sampling, queuing and SAP ports. The AFDX sampling and
queuing ports correspond to ARINC 653 sampling and queuing ports, respectively. AFDX
introduces a third port type called a Service Access Point (SAP) port. SAP ports are used for
communications between AFDX system components and non- AFDX systems .
End Systems are identified using two 8-bit quantities: A Network ID and an Equipment ID.
These may be combined into a single 16-bit quantity. As we shall see, the End System
identification is used in forming source MAC addresses and unicast IP addresses.
10.4.2 AFDX Communications Ports
Avionics subsystems use communications ports to send messages to each other. Communication
ports, which are typically part of the operating system API, provide a programming mechanism
for sending and receiving messages. Two types of communications ports play a role in Avionics
subsystems: sampling and queuing ports.
Integrated Modular Avionics (IMA)
P a g e | 77
Sampling and queuing ports differ mainly in reception. A sampling port has buffer storage for a
single message; arriving messages overwrite the message currently stored in the buffer. Reading
a message from a sampling port does not remove the message from the buffer, and therefore it
can be read repeatedly. Each sampling port must provide an indication of the freshness of the
message contained in the port buffer. Without this indication, it would be impossible to tell
whether the transmitting Avionics subsystem has stopped transmitting or is repeatedly sending
the same message.
Figure 30:Sampling port at receiver
Figure 31: Queuing port at receiver
A queuing port has enough storage for a fixed number of messages (a configuration parameter),
and new messages are appended to the queue. Reading from a queuing port removes the message
from the queue (FIFO). Typical programming interfaces for sending and receiving messages are
as follows:
a. Send_Msg (port ID, message)
b. Recv_Msg (port ID, message)
The port ID identifies the communication port, and the message argument points to a buffer that
either contains the message to be sent or is available to receive a new message from the port.
10.5 Virtual Links: Packet Routing in AFDX
In a traditional Ethernet switch, incoming Ethernet frames are routed to output links based on the
Ethernet destination address. In AFDX, a 16-bit value called a Virtual Link ID is used to route
Ethernet frames in an AFDX network. Figure 32 provides the format of the Ethernet destination
address in an AFDX network.
Integrated Modular Avionics (IMA)
P a g e | 78
Figure 32: Format of Ethernet Destination Address in AFDX Network
The switches in an AFDX network are “configured” to route an incoming Ethernet frame to one
or more outgoing links. An important property of an AFDX network is that Ethernet frames
associated with a particular Virtual Link ID must originate at one and only one, End System. The
AFDX switches are configured to deliver frames with the same Virtual Link ID to a
predetermined set of End Systems. Thus, a virtual link originates at a single End System and
delivers packets to a fixed set of End Systems; this is analogous to an ARINC 429 multi-drop
bus.
Figure 33: Format of Ethernet Destination Address in AFDX Network
In the example in Figure 33, when the Source End System (1) sends an Ethernet frame with a
Virtual Link ID (VLID) = 100 to the network, the AFDX switches deliver the frame to a
predetermined set of destination End Systems (2 and 3). More than one virtual link can originate
at an End System, and each virtual link can carry messages from one or more communication
ports.
10.6 Message Flows
When an application sends a message to a communications port, the source End System, the
AFDX network, and the destination End Systems are configured to deliver the message to the
appropriate receive ports. Figure 34 shows a message M being sent to Port 1 by the Avionics
subsystem. End System 1 encapsulates the message in an Ethernet frame and sends the Ethernet
frame to the AFDX Switched Network on Virtual Link 100 (the Ethernet destination address
specifies VLID 100). The forwarding tables in the network switches are configured to deliver the
Ethernet frame to both End System 2 and End System 3. The End Systems that receive the
Ethernet frame are configured so that they can determine the destination ports for the message
Integrated Modular Avionics (IMA)
P a g e | 79
contained in the Ethernet frame. In the case shown in Figure 34, the message is delivered by End
System 2 to port 5 and by End System 3 to port 6.
Figure 34: Message Sent to Port 1 by the Avionics Subsystem
The information used by the destination End System to find the appropriate destination port for
the message is contained in headers within the Ethernet payload. Figure 15 shows the headers
that make up the Ethernet payload. The Ethernet payload consists of the IP packet (header and
payload). The IP packet payload contains the UDP packet (header and payload), which contains
the message sent by the Avionics subsystem. An important function of the IP header is to
provide fragmentation control for large UDP packets. The IP header contains a destination End
System Identification and multicast address. In the latter case, the IP destination address contains
the Virtual Link ID (the Virtual Link ID in the Destination Ethernet address).
Figure 35: Ethernet Frame with IP and UDP Headers and Payloads
10.7 Redundancy Management
There are two independent switched networks in an AFDX system, the A and B Networks. Each
packet transmitted by an End System is sent on both networks. Therefore, under normal
operation, each End System will receive two copies of each packet (see Figure 36).
Integrated Modular Avionics (IMA)
P a g e | 80
Figure 36: A and B Networks
End Systems need a way to identify corresponding packets (replicas) that arrive on the A and B
networks. In AFDX, all packets transmitted over virtual link are provided with a 1-byte sequence
number field. The sequence number field appears just before the FCS field in the Ethernet frame.
This means that, in AFDX, one less byte is available to the IP/UDP payload. The sequence
numbers start with 0, continue to 255, and then roll over to 1. The sequence number 0 is reserved
for End System Reset. Sequence numbers are provided on a per-Virtual Link basis. An Ethernet
frame with an embedded sequence number is referred to as an AFDX frame.
Figure 37 applies when the UDP payload is between 17 and 1471 bytes. If the UDP payload is
smaller than 17 bytes, then a Pad field is introduced between the UDP Payload and the Sequence
Number fields.
Figure 37: AFDX Frame and Sequence Number
On a per-virtual link and per-network port basis, the receiving End System checks that the
sequence numbers on successive frames are in order. This is referred to as “Integrity Checking.”
After Integrity Checking is complete, the End System determines whether to pass the packet
along or drop it because its replica has already been sent along. This is called Redundancy
Management. Figure 38 summarizes the process.
Integrated Modular Avionics (IMA)
P a g e | 81
Figure 38: Receive Processing of Ethernet Frames
10.8 Virtual Link Isolation
As mentioned previously, the 100 Mbps link of an End System can support multiple virtual links.
These virtual links share the 100 Mbps bandwidth of the physical link. Figure 19 shows three
virtual links being carried by a single 100 Mbps physical link. The figure also shows that the
messages sent on AFDX Ports 1, 2, and 3 are carried by Virtual Link 1. Messages sent on AFDX
Ports 6 and 7 are carried by Virtual Link 2, and messages sent on AFDX Ports 4 and 5 are
carried by Virtual Link 3.
Figure 39: Three Virtual Links Carried by a Physical Link
Just as partitions are used to isolate Avionics subsystems from one another, a similar mechanism
is required to isolate individual virtual links, in order to prevent the traffic on one virtual link
from interfering with traffic on other virtual links using the same physical link. This is done by
limiting the rate at which Ethernet frames can be transmitted on a virtual link and by limiting the
size of the Ethernet frames that can be transmitted on a virtual link.
Integrated Modular Avionics (IMA)
P a g e | 82
Each virtual link is assigned two parameters:
a. Bandwidth Allocation Gap (BAG), a value ranging in powers of 2 from 1 to 128
milliseconds.
b. Lmax, the largest Ethernet frame, in bytes, that can be transmitted on the virtual link.
The BAG represents the minimum interval in milliseconds between Ethernet frames that are
transmitted on the virtual link. For example, if a virtual link with VLID 1 has a BAG of 32
milliseconds, then Ethernet packets are never sent faster than one packet every 32 milliseconds
on VLID 1. If VLID 1 has an Lmax of 200 bytes, then the maximum bandwidth on VLID 1 is
50,000 bits per second (200*81000/32).
10.8.1 Choosing the BAG and Lmax for a Virtual Link
The choice of BAG for a particular virtual link depends on the requirements of the AFDX ports
that are being provided link-level transport by the virtual link. For example, suppose an Avionics
subsystem is sending messages on three AFDX communications ports that are being carried by
the same virtual link. Let’s assume the message frequencies on the ports are 10 Hz, 20 Hz, and
40 Hz, respectively. The total frequency of the combined messages (they will be combined on
the same virtual link) is 70 Hz. The average period of the message transmissions is 14.4ms.
Accordingly, to provide adequate bandwidth on the virtual link, we should select a BAG that is
less than 14.4 ms. The first available BAG is 8 ms, which corresponds to a frequency of 125 Hz.
With a BAG of 8 ms, we are guaranteed that the virtual link is able to transport the combined
messages from the three ports without any backlog.
The source End System is required to enforce BAG restrictions for each outgoing virtual link. A
number of virtual link scheduling algorithms can be used by the End System. Lmax should be
chosen to accommodate the largest Ethernet frame to be transmitted by these ports on the virtual
link.
10.9 Virtual Link Scheduling
Each sending AFDX communication port is associated with a virtual link. Messages sent to the
communication port are encapsulated within UDP, IP, and Ethernet headers and placed in the
appropriate virtual link queue for transmission. The transmission of Ethernet frames in a virtual
link queue is scheduled by the End System’s Virtual Link Scheduler. The Virtual Link Scheduler
is responsible for scheduling transmissions of all the virtual links originating with this End
System.
Figure 40 summarizes the Virtual Link Scheduling scenario. The Virtual Link Scheduler is
responsible for ensuring that each virtual link conforms to its assigned bandwidth limitation. Not
only must the Virtual Link Scheduler ensure the BAG and Lmax limitations for each virtual link,
but it is also responsible for multiplexing all of the virtual link transmissions so that the amount
of jitter introduced by the multiplexing is within acceptable bounds.
Integrated Modular Avionics (IMA)
P a g e | 83
Figure 40: Virtual Link Scheduling
Once a frame is selected from a virtual link queue for transmission, the per-VL sequence number
is assigned and the frame is sent to the Redundancy Management Unit for replication (if
necessary) and transmission on the physical link(s). The sequence numbers are not assigned to
AFDX frames sooner than actual virtual link scheduling because of the sub- VL mechanism. If a
virtual link has more than one sub-VL, the sequence number cannot be assigned to an AFDX
frame until it is actually chosen by the Virtual Link Scheduler for transmission.
10.10 Jitter
Virtual Link scheduling consists of two components: packet regulation and multiplexing. Figure
41 shows the role of the Virtual Link Regulators in pacing the frames from the virtual link
queues to create zero-jitter output streams. The Virtual Link Scheduler is also responsible for
multiplexing the regulator outputs into the Redundancy Management Unit for replication and
transmission on the physical links.
Integrated Modular Avionics (IMA)
P a g e | 84
Figure 41: Role of Virtual Link Regulation
The outputs of the Regulator consist of regulated streams of Ethernet frames. Jitter is introduced
when the Regulator outputs are combined by the Virtual Link Scheduler MUX; Ethernet frames
arriving at input to the MUX at the same time will experience queuing delay (jitter).
10.11 AFDX Message Structures
Avionics subsystem designers are reasonably free to choose the message structure that bests suits
the Avionics application. The messages are contained in the payload of the UDP packet. In
general, the interpretation of the messages is determined by agreement between the Avionics
applications.
ARINC 664, Part 7, identifies two types of message structures: explicit and implicit. Explicit
message structures include format information that enables the receiver to correctly interpret the
Integrated Modular Avionics (IMA)
P a g e | 85
data. Implicit message structures do not contain any descriptive information to aid the receiver in
interpreting the data; consequently, they use network bandwidth more efficiently.
This following section discusses the ARINC 664 Implicit Message Structure formats. Since there
is no explicit format information contained in an implicit message structure, the Avionics
application needs a way to identify the message format of the received data. This is
accomplished by associating implicit message structures with an AFDX receive port. The
application associates the message structure based on the UDP port number where the message is
received.
Figure 42: Message Structure
The first 4 bytes of the message structure are reserved. After this, the basic message structure
consists of a 4-byte word called the Functional Status Set, followed by up to four data sets. The
basic message structure can be repeated an arbitrary number of times to form the message
structure. Figure 30 depicts message structures. It consists of two data sets, Data Set 1 and Data
Set 2. The Functional Status Set has two functional status bytes, FS1 and FS2, which correspond
to the Data Sets 1 and 2, respectively.
The functional status of each data set is encoded in the corresponding Functional Status byte.
There are four possible states: No Data, Normal Operation, Functional Test, and No Computed
Data. Clearly, the data must be grouped into data sets so that the functional status applies to all
the data in the data set.
10.12 Pros and Cons of AFDX
Pros:
a. Protocols and basic transmission technology based on open world technology and
protocols.
Integrated Modular Avionics (IMA)
P a g e | 86
b. Well- suited for all types of network domains since the maximum frame is length is
8Kbytes.
c. High data rate of 100Mbit/s for the data bus and guarantee bandwidth and latency per VL
(if a legal configuration is used).
d. The use of COTS components for switches and end system technology is possible (if
complying with the specific requirements of AFDX), which helps reduce development
and purchase costs.
e. Multiple transmitters are inherently allowed.
f. Multiple receivers are possible using the Means of the link layer multicast.
g. AFDX receives ARINC 429 labels as AFDX messages (as a result of sending single-label
messages and multiple-label messages).
h. AFDX payload formatting as Functional Data Sets possible which provides information
on each data set; the grouping is carried out according to functional and application
reasons almost without considering the Resulting message size.
i. Connection to open world networks (i.e., passenger owned devices domain, internet) and
less safety critical network domains (i.e., the airline information services domain and
passenger information and entertainment services domain) is easy to realize since the
implementation of AFDX is based on Ethernet and UDP / IP.
Cons:
a. Format and content of payloads is not standardized by ARINC 664 and has to be done by
the aircraft manufacturers (most likely because of the novel technology used in the
aircraft).
b. Switch it and end systems have to be configured to achieve deterministic performance,
consistency and correctness (according to the available and required bandwidth) of
configuration tables has to be analyzed and adds additional verification tasks Which are
not Necessary for ARINC 429and ARINC 629 networks.
11
AVIONICS COMPUTING
Avionics I/O computers deliver outstanding performance on the ground and in the air. They are
routinely deployed on helicopter, fixed wing, and ground mobile platforms. They include
standard data bus protocol interfaces including MIL-STD-1553, ARINC 429, ARINC 664, CAN,
Serial, discrete I/O, Ethernet, and USB.
Integrated Modular Avionics (IMA)
P a g e | 87
11.1 The Nature of an Avionics Computer
An avionics computer is a task-oriented computer or an embedded system. It performs specific
avionics functions in real time in accordance with application software stored within it and preloaded into its application memory on the ground. An avionics computer may take a variety of
forms. Some main processing computers such as flight management computers, flight control
computers and display management computers may resemble what we expect a traditional
computer to look like, a box in an avionics rack not that dissimilar to a personal computer under
a desk, except that its dimensions are different. Other avionics equipment may not look like
computers but in fact have similar computing hardware within them to perform the
computational element of the item, such as multifunction displays, control panels, remote data
concentrators, inertial reference units, and so on.
a. A power supply: This converts the 115 VAC 400 Hz aircraft power to conditioned and
stabilized power for the internal electronics (typically +5 V for semiconductor devices).
b. Central processing units (CPUs) with application and data memory: This executes the
application software to perform the desired avionics function.
c. I/O interfacing: these interfaces real-world sensors and effectors to the digital world of
the CPU.
d. Data bus communications interface: to connect the avionics computer to the avionics data
bus network.
Integrated modular avionics architecture has the same elements but distributed differently. The
Airbus A380 implements avionics computing in central processor input/output modules
(CPIOMs) with standardized, common processors and a range of standardized I/O interfaces.
The Boeing 787 implements I/O interfacing in separate remote data concentrators (RDCs) which
communicate via the aircraft data network to centralized processors in a common computing
resource
(CCR)
rack.
Whether a federated architecture or an integrated modular avionics architecture, the
computational core has a similar architecture, although the implementation has evolved as
computer architecture technology has evolved. The computational core comprises a central
processing unit which executes application software held in its memory. As discussed in later
paragraphs in this chapter, the central processor comprises an arithmetic logic unit which
performs mathematical and logical operations in binary arithmetic; the memory comprises two
elements, a read-only area of memory which contains the application software, and a read/write
area of memory for computational variables.
Integrated Modular Avionics (IMA)
P a g e | 88
Figure 43: Typical Computer Architecture
As indicated in Figure 43, the core processing architecture is very similar to that of a desktop
personal computer and so today it is not surprising to see many of the same components and
technologies used in avionics computing. The use of commercial off-the-shelf (COTS)
technology components brings with it some interesting challenges and disciplines which must be
addressed in terms of both the selection and the qualification of components that will be suitable
for the avionics application intended. A significant issue is the management of obsolescence.
Technology turnover in the COTS world is significantly shorter than the service life of an
aircraft (or even the development program), and so an obsolescence strategy must recognize that
through its life, some components will need to be replaced as new parts supersede them.In most
applications the avionics computer is the computational element of a control system, and at a
system level can be thought of as a control element with inputs, outputs and feedback. The
avionics computer acquires input data from a range of aircraft sensors, computes and delivers
outputs to aircraft effectors in accordance with the transfer function algorithms of its application
software, and measures aircraft response in its feedback loop to provide stable and precise
control of aircraft functions. Some control systems are obvious closed-loop systems, such as the
autopilot and fuel management. Other control systems are open loop and the operator (pilot)
closes the loop, such as the air data computer and the primary flight display. In both cases the
stability criteria for a control system apply.
Integrated Modular Avionics (IMA)
P a g e | 89
11.2 CPIOMs
The CPIOM is a high-performance computer which provides processing capability to host
multiple segregated applications on one computer. A standard ARINC 653 application
programmer interface enables clear independence of the application towards the computing
device. The flexible core software is fully configurable by the seamless Tool Suite. The CPIOM
is connected to the Avionic Full Duplex Switched Ethernet (AFDX) aircraft bus using Diehl
Aerospace's AFDX End System.
11.2.1 CPIOMs Introduction
Airbus introduced a different concept of avionics systems integration with the A380. The basis
of this architecture was the adoption of a packet-switching technology using fast switched
Ethernet twin copper wire buses. At the center of the architecture is a dual redundant AFDX
switched network, comprising AFDX switches operating at 100 Mbps. In Figure 44 the AFDX
switching network is shown centrally and consists of eight pairs of switches arranged according
to their avionics domain of interest. The dual redundant switch network is distributed
longitudinally throughout the aircraft and also comprises left/right elements.
Figure 44: Airbus A380 avionics architecture
Integrated Modular Avionics (IMA)
P a g e | 90
The avionics function in each domain area is implemented in a set of computer processor
input/output modules (CPIOMs). The general architecture of the CPIOM, for illustrative
purposes, is shown in Figure 45. It comprises a general-purpose processing function and a set of
I/O interface functions.
The implementation uses current generation PowerPC processor architectures and memory
technologies with respect to hardware and the operating system and application software are
loaded on aircraft into the onboard non-volatile Flash memory and uploaded into the RAM
memory. Partitioning is assured by context switching the application software at run-time.
Longer-term storage of configuration and maintenance data is provided non-volatile RAM
(NVRAM). A peripheral component interconnects (PCI) bus interfaces the I/O devices to the
CPU main system bus. The network interface is provided by an ARINC 664 end-system PCI
Mezzanine Card (PMC) which mounts onto a second (PCI) socket on the CPU board.
Figure 45: CPIOM architecture
Integrated Modular Avionics (IMA)
P a g e | 91
11.2.2 CPIOMs Physical Arrangement
The CPIOM physical arrangement is shown in Figure. It comprises four circuit boards contained
in an ARINC 600 3MCU enclosure. The CPU circuit board and I/O common board are common
to all CPIOMs; the other I/O boards are domain-specific. Interconnections between the CPU
board and the I/O boards are via the internal PCI bus. The AFDX end-system is housed on a
PMC mezzanine board mounted on the CPU board.
Figure 46: Airbus A380 CPIOM physical arrangement
In the A380 architecture there are a total of 22 CPIOMs of seven different types in which the
central computing core is common and the personality of each CPIOM variant is determined by
the input/output (I/O) and henceforth by the intended system function. These CPIOMs are
utilized across a number of functional domains featuring the flight deck, cabin, energy and
utilities. In the utility domain, four CPIOMs–Fuel (CPIOM–F) and four CPIOMs–Gear
(CPIOMs–G) provide the computing core for the fuel and landing gear functions respectively. A
major advantage of this concept is that common development tools and software languages may
be used across all CPIOM variants.
Integrated Modular Avionics (IMA)
P a g e | 92
Figure 47: Airbus A380 CPIOM responsibilities
In the A380 architecture, system-specific remote data concentrators (RDCs) are provided by the
major subsystem supplier. For example, two fuel quantity management system (FQMS) RDCs
provide the fuel system-specific interface, while three landing gear RDCs provide the interface to
the landing gear and braking systems. A similar system concept was adopted for the A400M
central avionics core.
In the case of the A350, which followed several years later, a similar concept has been used. The
central AFDX switching network is unchanged, but dedicated subsystem RDCs have been
replaced by 29 multipurpose common remote data concentrators (CRDCs) of two types. While
the number of CPIOMs variants has been substantially reduced from seven to two, the total
number of CPIOMs remains virtually the same (see Figure 47). The outcome of this further
hardware consolidation gives rise to the following issues:
a. Reduced hardware variability.
b. Increased hardware content for the Airbus partners at the expense of the subsystem
supplier.
c. An increase in the burden of aircraft-level configuration control, as overall system
configuration is largely dictated by the CRDC configuration.
11.3 Implementation Example: Airbus A380
A380 CPIOM structure implements a common core processor board with an ARINC 664-P7 end
system mezzanine card and a set of I/O cards in a single 3MCU line-replaceable unit. Different
domain optimizations of the I/O modules result in seven variants of the CPIOM, each with a
common processor/ARINC 664-P7 mezzanine card. The A380 CPIOM I/O cards interface
directly with function (domain)-specific sensors and effectors. In some domains (including the
landing gear domain) the I/O capability is augmented with local domain-specific RDCs that
Integrated Modular Avionics (IMA)
P a g e | 93
aggregate sensor/effector signals close to their source in order to minimize aircraft wiring,
improve signal quality and reduce EM interference. Some domain-specific RDCs (e.g. the fuel
system RDCs) include local processing to reduce network bandwidth requirements and IMA core
processor load.
Figure 48: Airbus A380 utilities domain IMA implementation
The Airbus A380 IMA architecture does not implement the concept of an IMA rack. However,
we can consider the architecture as two ‘open’ racks pair of CPIOMs implement the command
monitor function of Side 1, while the right-hand pair of CPIOMs implement the command:
monitor function of Side 2. All four CPIOMs are identical; the architectural function
implemented in each CPIOM is determined by the application software loaded into it. The
command pair in Lane A and Lane B executes the measurement and management applications of
the command channel; the monitor pair in Lane A and Lane B executes the monitoring and builtin-test applications. Consolidation of the command and monitoring lanes is implemented in the
I/O sections of the CPIOMs.
The Airbus A380 IMA implements common modular avionics platform resource architecture
(hardware, I/O, network and RTOS); however, the IMA platform resources are strongly assigned
on a system-by-system domain basis more closely aligned to a more traditional federated
Integrated Modular Avionics (IMA)
P a g e | 94
architecture approach. A strong physical segregation exists between domains. This is illustrated
in Figure 49 which shows the high-level mapping of the fuel system (CPIOM Type F) and the
landing gear system (CPIOM Type G) functions within the utilities domain. Each function (fuels
and landing gear) have their own set of CPIOMs and dedicated RDCs. The four fuel system
CPIOMs are identical to each other but are different to the four landing gear CPIOMs by virtue
of a different set of interface cards optimized to the fuel system sensor and effector signals
requirements.
The following figure shows the top view of CPIOM topology and how it looks physically.
Figure 49: Top view of CPIOM topology
Integrated Modular Avionics (IMA)
P a g e | 95
11.4 Design Assurance Level (DAL) for CPIOMs
DO-254 is a formal safety standard that applies to complex aircraft hardware. It provides
guidance for the design and development of electronic hardware for airborne systems. DO-254
defines five design assurance levels (DALs) of compliance, which determines the effect a failure
of the hardware will have on the operation of the aircraft (see figure:50). Level A is the most
severe, defined as "catastrophic" (e.g. loss of the aircraft), while a failure of Level E hardware
will not affect the safety of the aircraft.
Figure 50 : Design Assurance Levels (DAL)
The main regulations which must be followed are requirements capturing and tracking
throughout the design and verification process. Meeting DAL-A compliance for complex
electronic hardware requires a much higher level of verification and validation than DAL-E
compliance. Any software that commands, controls, and monitors safety-critical functions should
receive the highest DAL - Level A. DO-178C, Software Considerations in Airborne Systems and
Equipment Certification is the primary document by which the certification authorities such as
FAA and EASA approve all commercial software-based aerospace systems.
Integrated Modular Avionics (IMA)
P a g e | 96
12
CONCLUSION
We have discussed different Avionic systems and found that Federated avionic systems are
needed more space and power consumption. Integrated Modular Avionics is the best replacement
for Federated Avionic systems. We have discussed DO-297/ED-124 which provides guidance
and certification consideration for Integrated Modular Avionics (IMA) development. The most
popular Communication buses such as ARINC 429, MIL-STD-1553 and AFDX/ARINC664
have been discussed and the comparison between them has been tabulated as shown in table 6.
The CPIOMs, which mainly provides the computational processing for Avionics subsystems and
responsible for interfacing of Input/output modules have been analyzed.
ARNIC 429
AFDX/ARNIC664
MIL-STD-1553
Max. Frame
Length
Duplex
32 bits
1518 Bytes
20 bits
Simplex
Full-Duplex
Half-Duplex
Max. bit rate
100 kbps
100 Mbps
1 Mbps
Max. bus
length
Latency
~ 65 m
<100 m
~6m
Protocol
Features
Very-small; Only
Depends on network load
Controller dependent
Predominant
Flexible and Used to support
commercial Aircraft AIRBUS A350/A380
data bus standard
Very-small
Highly Deterministic,
Robust and Reliable
Table 6: Comparison between Communication bus protocols
Integrated Modular Avionics (IMA)
P a g e | 97
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
RTCA DO-297 / EUROCAE ED-124, Integrated Modular Avionics (IMA) Development
Guidance and Certification Considerations
RTCA DO-178 / EUROCAE ED-12, Software Considerations in Airborne Systems
and Equipment Certification.
Avionics:Development and Implementation (The Avionics Handbook, Second Edition)
by Cary R. Spitzer
RTCA DO-254 / EUROCAE ED-80, Design Assurance Guidance for Airborne
Electronic Hardware.
https://www.army-technology.com/contractors/electronic/sital
databus/pressreleases/pressarinc-certification-documentation/
https://www.abaco.com/download/afdxarinc-664-protocol-tutorial ( All containt and Pictures)
civil avionics systems by Ian Moir, Allan Seabridge, Malcolm Jukes, 2nd edition
George Los, “Safety in civil airplanes via DO-254 certifiable MIL-STD-1553 interfaces”,
Data Device Corporation
MIL-STD-1553 Tutorial by AIM GmbH
Tobias Schneider, “Civil Certification of the MIL-STD-1553B”, 31st Digital Avionics
System Conference, 2012.
Integrated Modular Avionics (IMA)
P a g e | 98