Aircraft Systems Integration Overview

AIRCRAFT SYSTEMS INTEGRATION OVERVIEW
Author: ANGEL RODRGUEZ CASTAO

UNIV. SEVILLE / SYSTEMS ENGINEERING & AUTOMATION
TABLE OF CONTENTS
Introduction
Systems architecture
Buses and integration protocols

Introduction
ARINC 429
MIL STD 1553B
AFDX
CANaerospacel
Master GSC & AIO 2011-2012

GLOBAL SUPPLY CHAIN & AERONAUTICAL INDUSTRIAL OPERATIONS
Module 2: AIRCRAFT SYSTEMS INTEGRATION OVERVIEW
AIRCRAFT SYSTEMS INTEGRATION OVERVIEW
Author: ANGEL RODRGUEZ CASTAO
UNIV. SEVILLE / SYSTEMS ENGINEERING & AUTOMATION
TABLE OF CONTENTS
Standards overview
Introduction
RTCA/DO-178B
RTCA/DO-254
RTCA/DO-160F
EXAMPLES
Case study: Integration of ADS-B

REFERENCES
STANDARDS. Vance Hilderman and Tony Baghai. AVIONICS

CERTIFICATION: A COMPLETE GUIDE TO DO-178
(SOFTWARE) AND DO-254(HARDWARE). Avionics
Communication Inc., 2007.
STANDARDS. European Space Agency (ESA) Board of Inquiry.

ARIANE 5, FLIGHT 501 FAILURE REPORT. ESA, 1996.
AIRCRAFT SYSTEMS. Ian Moir and Allan Seabridge. AIRCRAFT

SYSTEMS: MECHANICAL, ELECTRICAL AND AVIONICS
SUBSYSTEMS INTEGRATION. Wiley, 2008.
AIRCRAFT SYSTEMS DESIGN. John R. Newport. AVIONIC

SYSTEMS DESIGN. CRC Press, 1994.

GLOBAL SUPPLY CHAIN & AERONATICAL INDUSTRIAL OPERATIONS
REFERENCES
BUSES AND INTEGRATION PROTOCOLS. Olaf Pfeiffer, Andrew Ayre,

Christian Keydel. EMBEDDED NETWORKING WITH CAN AND
CANOPEN. RTC Books, 2003.
BUSES AND INTEGRATION PROTOCOLS. Condor Engineering. MIL-

STD-1553 TUTORIAL (1600100-0028). 2000.
BUSES AND INTEGRATION PROTOCOLS. Condor Engineering.

ARINC PROTOCOL TUTORIAL (1.03). 1999.
BUSES AND INTEGRATION PROTOCOLS. AVIONICS FULL DUPLEX

SWITCHED ETHERNET, CES White Paper on AFDX. 2003.

INTRODUCTION
One of the challenges faced by aeronautical companies during the

development and production of modern aircraft is the on-board integration
of multiple systems.
The field of Aircraft Systems Integration is highly multidisciplinary and

requires a deep knowledge of:
Technologies
Functions
Requirements
Project and management tools
Testing procedures

INTRODUCTION
Technologies: electrical, mechanical, hydraulic, electronic, optical,

software,
Functions: flight dynamics and control, navigation, communications,

surveillance,
Requirements: legal framework, civil and military standards, safety and

flight regulations,
Project and management tools: planning, statement of work, work

breakdown structure,
Testing procedures: flight tests, verification, validation, certification,
As well as the mutual interactions among all of them.

INTRODUCTION

INTRODUCTION

INTRODUCTION

SYSTEMS ARCHITECTURE
Traditional architectures are federated. That is, a unique box hosts each
major subsystemnavigation, display generation, and flight management,
for example. Each box requires a mounting rack, power supply, interfaces,
and cabling. Each will have unique maintenance procedures and require
stockpiles in depots.
From a stand-alone reliability perspective, its a convenient solution:

failure of one box is unlikely to propagate to another except when they
share resources such as external power. Preventing failure propagation
via federation mechanisms is well understood.
However, when you consider life cycle costs, federation is expensive.

Each depot needs parts, and the added weight and power of single boxes
can be significant.

Integrating functionality can significantly reduce such overhead.

Integration can take the form of shared computing, power, and
communication resources (hardware). Sharing software libraries, tools,
displays, and information (databases, for example) are also integration
strategies.
Modular rather than monolithic
The limit of integration is a monolithic systemthat is, one piece of

hardware and one large software program that supports all necessary
functions.
Although a monolithic system might be attractive from a purely operational

cost in terms of size, weight, and power, easy maintainability is unlikely.

Modular rather than monolithic ()
One facet of a system that affects maintainability is its ability to adapt to

change and the testing each change requires. Testing sufficient to
achieve FAA certification can cost tens of millions of dollars for large
applications. If a single applicationfor instance, a pilot display and
interaction menuwithin a monolithic suite undergoes change, it might be
necessary to recertify the whole suite.
Facing such testing overhead, developers resist change, knowing that

each small change could incur major costs. That would make minor
increments and tests more difficult to justify and could impede safety
enhancements. Therefore, while we want an integrated architecture, we
also want a modular one, so that components and applications can be
inserted and activated as necessary.

Modular integration isnt a new concept. A typical desktop computer

manages it to some extent. However, such a computer is also prone to
failures and interference between applications. In aircraft systems,
performance and predictability of interaction must be garanteed.
One example is the Boeing 777, in which functions such as flight

management, display, and various communications and data recording
applications all reside in a single cabinet. A second cabinet acts as a live
spare. Each cabinet has a single data backplane that provides
communication to the various processing and communications elements
in the cabinet. Each processing element in the cabinet hosts multiple
functions of varying criticality. This approach allowed to cut significant
size, weight, and power from the airplane, including external cabling. At
the same time, components of varying criticality can be mixed and
changes can be made without retesting applications unaffected by the
change.

This integrated, modular system architecture provides the ability to host

multiple, diverse applications in a convenient environment. Such a system
allows for change and expansion without incurring the overhead of
federation and avoiding the costs of systemwide recertification for every
change.
This means that new functionalities can be added or modified as time

goes on without rewiring or new hardwareall you need is a software
load to upgrade functionality.
These systems are already operational on several commercial aircrafts.

BUSES AND INTEGRATION PROTOCOLS: INTRODUCTION
CANaerospace: Higher layer protocol based on CAN (Controller

Area Network).
ARINC 429: Aeronautical Radio Inc. Specification 429 Digital

Information Transfer System.
ARINC 629: Further development of ARINC 429. Extension to

multi-transmitter. Especially designed for the Boeing 777.
MIL-STD-1553B: Military (MIL) Standard (STD) which defines

both the Mechanical, Electrical, and Functional characteristics.
MIL-STD-1773: Fiber version of MIL-STD-1553
AFDX: Avionics Full Duplex Switched Ethernet.

BUSES AND INTEGRATION PROTOCOLS: ARINC 429
Point-to-point.
2-wire Bi-Polar Return-to-Zero signal.
32 bit data.
100K or 12.5K bit rate.
May use Williamsburg Protocol, which transferred blocks of data.
Similar to ARINC 575.
20 receivers max.


Bipolar , Return to Zero
TRANSMIT STATE RECEIVE

+10.0 V 1.0 V HIGH +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

32 bit format -> Word
Parity: 1bit
SSM (Sign / Status Matrix): 2 bits
Data: 19 bits
SDI (Source Destination Identifier): 2 bits
Label: 8 bits
Data types:
BNR
BCD
Discrete

BCD Data Encoding
BCD (Binary Coded Decimal): 4 bits allocated for each decimal digit
A generalized BCD message contains up to 5 sub-fields; the most
significant sub-field contains only 3 bits.
SSM codes for BCD data:

BCD message example
DME distance is 25786 with positive sign
Specific equipment, numeric scale and location of decimal point are a

function of the label.

Examples of BCD Labels

BNR Data Encoding
BNR (Binary): data encoded as binary number (negative numbers

using twos complement)
Bit 29 is the sign: 1 negative (or South, West, Left, From, Below), 0
positive (or North, East, Right, To, or Above.
SSM codes for BNR data:

Examples of BNR Labels
03C: Tire Pressure Monitoring System 029: ADDCS and EICAS

002: Flight Management Computer 0A1: FCC Controller
020: DFS System 004: Inertial Reference System
038: ADIRS 005: Attitude & Heading Reference System
BNR message example
Label 103: Selected Airspeed. Scale: 512. Bits: 29-20. Resolution: 1.0.
Value is obtained multipliying the resolution by the numeric data.
0100001100 = 268 x 1.0 = 268 Knots

Message scheduling and timing
Typically, messages are sent repetitively.
The least significant bit of each byte except the label is transmitted first,
and the label is transmitted ahead of the data in each case. The order of
the bits transmitted is: 8, 7, 6, 5, 4, 3, 2, 1, 9, 10, 11, 12, , 32
Example:

Message scheduling and timing: example
Choose target transmit intervals that are the approximate averages of

the minimum and maximum transmit intervals given in the specification.
At low speed (12.5Kbps) a bit-time is 0.08ms, and at high speed
(100Kbps) it is 0.01ms, so each word takes either 2.56ms or 0.32ms
Interword gap: 4 bit times
Find a Transmit Schedule that meets the timing requirements.

BUSES AND INTEGRATION PROTOCOLS: MIL-STD-1553B

Terminal types:
Remote Terminals: All terminals not operating as the Bus Controller or as

a Bus Monitor.
Bus Controller: word controller, message controller, frame controller.
Bus Monitor: recorder for testing or back up bus controller.

Word types:
Command Words (CW)
Data Words
Status Words

Message format: data transfer

Message format: data broadcast

BUSES AND INTEGRATION PROTOCOLS: AFDX
The AFDX interface is more Network than data bus, with types of devices
Switches and End Systems.
The AFDX network operates at full-duplex 10Mbits/s or 100MBit/s.
AFDX is ARINC 664, Part 7.
AFDX uses one set of twisted pair copper wire or fiber optic cable for
transmit and another pair for receiving data. Star Quad cable (based on 100
Base-TX especially designed for avionics.
However AFDX uses a dual-port with both ports transmitting or receiving

the same data.
Although AFDX is based on Ethernet, the protocol is different.

Full Duplex Switched Ethernet

AFDX Network Architecture

Virtual Links
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.
Format of the Ethernet destination address in an 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.
Topology comparison with ARINC 429

BUSES AND INTEGRATION PROTOCOLS: CANaerospace
CANbus Connection:
CANbus Access:
The CAN protocol uses a modified version of the Carrier Sense Multiple
Access/Collision Avoidance (CSMA/CA) technique used on Ethernet.
Should two messages determine that they are both trying to send at the
same time then instead of both backing off and re-trying later as is done with
Ethernet, in the CAN scheme, the transmitters detect which message has
the highest priority and only the lower priority message gets delayed. This
means that a high priority message is sure of getting through.

CANbus major characteristics:
Effective data rate max. 576 kBit/s (<= 40m bus length)
-> adequate for most realtime control systems
No overhead for bus arbitration, known response times even for high bus loads
-> bus performance independant of number of participants
Extremely low probability of undetected data corruption (~ 1*10-13 per transmission)
-> suitable for safety critical applications
Very low chip cost, easy and straightforward application programming

-> even small systems can benefit from network technology
CANbus Applications:
NH90 helicopter: Audio system intercommunication
A380: Environmental control system databus, cockpit cursor control device/
MFD communication bus, electric power supply control databus

CANaerospace
The CAN specification itself does not cover issues like data representation, station
addressing or connection-oriented protocols.
Using CAN networks in aerospace demands a standard targeted to the specific

requirements of flight or mission critical airborne applications.
CANaerospace is a slim software layer that turns CAN into an easy-to-handle data
bus meeting the specific requirements of avionic systems.
CANaerospace is used and supported by some major European aerospace

companies (EADS, Eurocopter, Aero Vodochody, Rotax-Bombardier, ....).
CANaerospace networks are installed in several aircraft since 1998 and have
demonstrated excellent reliability in a harsh environment.

CANaerospace
Democratic network: No master/slave relationships for normal operation.
Self-identifying message format: Information about data type and transmitting
station.
Message numbering: Support for coherent data processing in redundant systems.
Message status code: Continous integrity monitoring support.
Emergency event signalling mechanism: Information about CBIT detected failures.
Node service mechanism: Addressing of specific stations for integrity monitoring,
data download, time synchronisation, .....
Identifier assignment: Proposed default identifier distribution (similar to ARINC429).
Ease of implementation: Reduction of work required for certification.
Openness to extensions: Minimum of fixed definitions to provide flexibility
STANDARDS OVERVIEW
Software Considerations in Airborne Systems and Equipment

RTCA/DO-178
Certification
Design Assurance Guidance for Airborne Electronic Hardware RTCA/DO-254
Environmental Conditions and Test Procedures for Airborne
RTCA/DO-160
Equipment

RTCA/DO-178B: SOFTWARE
Software Considerations in Airborne Systems and Equipment

Certification
Issued 12-1-92. Supersedes DO-178A. Errata Issued 3-26-99. Prepared by
SC-167.
The rapid increase in the use of software in airborne systems and

equipment used on aircraft and engines in the early 1980s resulted in a
need for industry-accepted guidance for satisfying airworthiness
requirements. DO-178, "Software Considerations in Airborne Systems and
Equipment Certification," was written to satisfy this need.
This document, revised in the light of experience, provides the aviation

community with guidance for determining, in a consistent manner and with
an acceptable level of confidence, that the software aspects of airborne
systems and equipment comply with airworthiness requirements.

The purpose of this document is to provide guidelines for the production of

software for airborne systems and equipment that performs its intended
function with a level of confidence in safety that complies with airworthiness
requirements. These guidelines are in the form of:
Objectives for software life cycle processes.
Descriptions of activities and design considerations for achieving

those objectives.
Descriptions of the evidence that indicate that the objectives have

been satisfied.
Although widely referred to as a safety standard, it almost exclusively deals

with the development of software

The Design Assurance Level (DAL) is determined from the safety

assesment process and hazard analysis by examining the effects of a
failure condition in the system. The failure conditions are categorized by
their effects on the aircraft, crew, and passengers.
Level Description
A Failure will cause or contribute to a catastrophic failure of the aircraft.
B Failure will cause or contribute to a hazardous/severe failure condition.
C Failure will cause or contribute to a major failure condition.
D Failure will cause or contribute to a minor failure condition.
E Failure will have no effect on the aircraft or on pilot workload.

Processes, activities and documents:
Planning: Software Development Plan (SDP), Software Verification Plan (SVP), Software
Quality Assurance Plan (SQAP), Software Design Standards (SDS), Software Code
Standards (SCS),
Development: divided into sub-processes (requirements, design, code, integration).

Software Requirements Data (SRD), Software Design Description (SDD).
Verification: Software Verification Cases and Procedures (SVCP), Software Verification

Results (SVR).
Configuration Management: Software Configuration Index (SCI), Software Life Cycle

Environment Configuration Index (SECI).
Quality Assurance: Software Quality Assurance Records (SQAR), Software Conformity

Review (SCR), Software Accomplishment Summary (SAS).

Other related documents:
DO-297 Integrated Modular Avionics (IMA) Development Guidance and Certification

Considerations
Issued 11-08-05, Prepared by SC-200.
DO-278 Guidelines for Communication, Navigation, Surveillance, and Air Traffic Management
(CNA/ATM) Systems Software Integrity Assurance
Issued 3-5-02. Prepared by SC-190/EUROCAE WG-52.
DO-248B Final Annual Report For Clarification Of DO-178B Software Considerations In Airborne
Systems And Equipment Certification
Issued 10-12-01. Prepared by SC-190/EUROCAE WG-52.

RTCA/DO-254: HARDWARE
Design Assurance Guidance for Airborne Electronic Hardware

Issued 4-19-00. Prepared by SC-180.
RTCA DO-254/EUROCAE ED-80 provides a standard for the

development and certification of Programmable Logic Devices (PLDs) for
civil aerospace applications. The use of PLDs is becoming increasingly
prevalent in military and commercial systems. RTCA DO-254 has been
given recognition for civil aerospace applications by the FAA (Federal
Aviation Administration) as a result of Advisory Circular 20-152.
This provides the certification requirements (and hence development) of

PLDs such as FPGAs (Field Programmable Gate Arrays), CPLDs
(Complex Programmable Logic Devices) and ASICs (Application Specific
Integrated Circuits).

Design Assurance Guidance for Airborne Electronic Hardware

Issued 4-19-00. Prepared by SC-180.
The document is intended to help aircraft manufacturers and the

suppliers of aircraft electronic systems assure that electronic airborne
equipment safely performs its intended function.
The document identifies design life cycle processes for hardware that
includes line replaceable units, circuit board assemblies, application
specific integrated circuits (ASICs), programmable logic devices, etc.
It also characterizes the objective of the design life cycle processes and
offers a means of complying with certification requirements.

The are five levels of compliance, A-E, depending of the effect that a
hardware failure will have on the operation of the aircraft.
Level Description Affected area
A Failure will cause or contribute to a catastrophic failure of Display unit, switch systems,
the aircraft. airborne computing
B Failure will cause or contribute to a hazardous/severe Back-up power,
failure condition. heads-up display
C Failure will cause or contribute to a major failure condition. Any
D Failure will cause or contribute to a minor failure condition. Any
E Failure will have no effect on the aircraft or on pilot Any

workload.
Meeting level A compliance for complex electronic hardware requires a

much higher level of validation and verification than level E compliance.

Hardware design life cycle: design and verification done independently.
Processes:
Planning
Design: requirements capture, conceptual design, detailed design
Development
Validation: hardware item derived requirements are correct and

complete with respect to system requirements
Verification: hardware item implementation meets all of the hardware

requirements, including derived requirements.
Configuration management
Quality assurance
Certification considerations

RTCA/DO-160F: ENVIRONMENT AND TEST
Environmetal Conditions and Test Procedures for Airborne Equipment
DO-160F. Issued 12-06-07. Superseded DO-160E. Prepared by SC-135

DO-160E. Issued 12-09-04. Superseded DO-160D. Prepared by SC-135
DO-160D. Issued 07-29-97. Superseded DO-160C. Prepared by SC-135
DO-160C. Issued 12-04-89. Superseded DO-160B. Prepared by SC-135
DO-160B. Issued 07-20-84. Superseded DO-160A. Prepared by SC-135
DO-160A. Issued 01-25-80. Superseded DO-160. Prepared by SC-135
Standard procedures and environmental test criteria for testing airborne

equipment for the entire spectrum of aircraft from light general aviation
aircraft and helicopters through the Jumbo Jets and SST categories of
aircraft.

Mdulo 10: AIRCRAFT SYSTEMS
The document includes 26 Sections and three Appendices. Examples

of tests covered include vibration, power input, radio frequency
susceptibility, lightning, and electrostatic discharge. Coordinated with
EUROCAE, RTCA/DO-160D and EUROCAE/ED-14D are identically
worded.
The document defines a series of minimum standard environmental

test conditions (categories) and applicable test procedures. The
purpose of these tests is to provide a laboratory means of determining
the performance characteristics of airborne equipment in
environmental conditions representative of those which may be
encountered in airborne operation of the equipment.

Section 4, Temperature and Altitude Section 16, Power Input

Section 5, Temperature Variation Section 17, Voltage Spike
Section 6, Humidity Section 18, AF Conducted Susceptibility
Section 7, Operational Shocks and Crash Section 19, Inducted Signal Susceptibility
Safety Section 20, Radiated and Conducted Susceptibility
Section 8, Vibration Section 21, Radiated and Conducted Emissions
Section 22, Lightning Testing; Indirect Effects
Section 9, Explosion Proofness
(Single Stroke, Multi-stroke and Multi-burst
Section 10, Waterproofness waveforms)
Section 11, Fluids Susceptibility Section 23, Lightning Direct Effects
Section 12, Sand and Dust Section 25, ESD
Section 13, Fungus Resistance Section 24, Icing
Section 26, Fire, Flammability
Section 14, Salt Spray
Section 15, Magnetic Effects

Section 15: Magnetic Effect

This "MC" (for "Magnetic Compatibility" as opposed to "EMC" for Electromagnetic
Compatibility) test is performed to determine to what extent the equipment-under-
test (EUT) will deflect a compass needle, or will affect the indication from a compass
sensor, also known as a "Flux Gate".
A standard compass that has a large enough dial to read one degree of needle
deflection is the only test equipment required. The EUT is simply moved closer to
the compass on an East-West line until one degree of deflection away from
magnetic North is observed. The separation distance is then measured and the
"Equipment Category" is determined.
Equipment Classes
There are five equipment categories (Y, Z, A, B, and C) that apply to installation
separation distances between the EUT and compass (or compass sensor) of less
than 30 centimeters to more than 300 centimeters.

Fungus Test
In hot and humid environments, fungus can cause equipment

damage and create a health liability. This environmental testing
requires 24/7 oversight to insure that the proper test conditions
are maintained. Control samples are included in all
environmental tests to ensure that proper conditions have been
maintained to grow the mold spores.
Salt Spray & Salt Fog
Accelerated corrosion atmospheres for the effects of salt

are applied to items. Other contaminants can be added
according to desired environmental testing conditions.

CASE STUDY: INTEGRATION OF ADS-B
ADS-B is a new technology that is redefining the paradigm of

COMMUNICATIONS-NAVIGATION-SURVEILLANCE in Air Traffic Management
today.
Already proven and certified as a viable low cost replacement for conventional
radar, ADS-B allows pilots and air traffic controllers to "see" and control aircraft
with more precision, and over a far larger percentage of the earth's surface, than
has ever been possible before.
Automatic Its always ON and requires no operator intervention

Dependent It depends on an accurate GNSS signal for position data
Surveillance It provides radar-like surveillance services
Broadcast It continuously broadcasts aircraft position and other data to any
aircraft or ground station equipped to receive ADS-B

Far different from radar, which works by bouncing radio waves from fixed
terrestrial antennas off of airborne targets and then interpreting the reflected
signals, ADS-B uses conventional Global Navigation Satellite System (GNSS)
technology and a relatively simple broadcast communications link as its
fundamental components. Also, unlike radar, ADS-B accuracy does not seriously
degrade with range, atmospheric conditions, or target altitude and update
intervals do not depend on the rotational speed or reliability of mechanical
antennas.
The 978 MHz Universal Access Transceiver ("UAT") variant is also bi-directional
and capable of sending real-time Flight Information Services ("FIS-B"), such as
weather and other data to aircraft. In some areas, conventional non-ADS-B radar
traffic information ("TIS-B"), can also be uplinked as well.
ADS-B is also a relatively inexpensive technology, with costs for equivalent radar
coverage running in the 0.1 to 0.05 range. Also, unlike radar, both the footprint
and power requirements for ADS-B are quite small, allowing an ADS-B ground
station to be installed in even the most remote areas.

In a typical applications, the ADS-B capable aircraft uses an ordinary GNSS

(GPS, Galileo, etc) receiver to derive its precise position from the GNSS
constellation, then combines that position with any number of aircraft discretes,
such as speed, heading, altitude and flight number. This information is then
simultaneously broadcast to other ADS-B capable aircraft and to ADS-B ground,
or satellite communications transceivers which then relay the aircraft's position
and additional information to Air Traffic Control centers in real time.


Aircraft Systems Integration Overview - AIRBUS

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Aircraft Systems Integration Overview - AIRBUS

Caricato da

Copyright:

Formati disponibili

Author: ANGEL RODRGUEZ CASTAO

Buses and integration protocols

Master GSC & AIO 2011-2012

Case study: Integration of ADS-B

Master GSC & AIO 2011-2012

STANDARDS. Vance Hilderman and Tony Baghai. AVIONICS

STANDARDS. European Space Agency (ESA) Board of Inquiry.

AIRCRAFT SYSTEMS. Ian Moir and Allan Seabridge. AIRCRAFT

AIRCRAFT SYSTEMS DESIGN. John R. Newport. AVIONIC

Master GSC & AIO 2011-2012

BUSES AND INTEGRATION PROTOCOLS. Olaf Pfeiffer, Andrew Ayre,

BUSES AND INTEGRATION PROTOCOLS. Condor Engineering. MIL-

BUSES AND INTEGRATION PROTOCOLS. Condor Engineering.

BUSES AND INTEGRATION PROTOCOLS. AVIONICS FULL DUPLEX

Master GSC & AIO 2011-2012

One of the challenges faced by aeronautical companies during the

The field of Aircraft Systems Integration is highly multidisciplinary and

Master GSC & AIO 2011-2012

Technologies: electrical, mechanical, hydraulic, electronic, optical,

Functions: flight dynamics and control, navigation, communications,

Requirements: legal framework, civil and military standards, safety and

Project and management tools: planning, statement of work, work

Testing procedures: flight tests, verification, validation, certification,

As well as the mutual interactions among all of them.

Master GSC & AIO 2011-2012

Master GSC & AIO 2011-2012

Master GSC & AIO 2011-2012

Master GSC & AIO 2011-2012

From a stand-alone reliability perspective, its a convenient solution:

However, when you consider life cycle costs, federation is expensive.

Master GSC & AIO 2011-2012

Integrating functionality can significantly reduce such overhead.

Modular rather than monolithic

The limit of integration is a monolithic systemthat is, one piece of

Although a monolithic system might be attractive from a purely operational

Master GSC & AIO 2011-2012

Modular rather than monolithic ()

One facet of a system that affects maintainability is its ability to adapt to

Facing such testing overhead, developers resist change, knowing that

Master GSC & AIO 2011-2012

Modular integration isnt a new concept. A typical desktop computer

One example is the Boeing 777, in which functions such as flight

Master GSC & AIO 2011-2012

This integrated, modular system architecture provides the ability to host

This means that new functionalities can be added or modified as time

These systems are already operational on several commercial aircrafts.

Master GSC & AIO 2011-2012

CANaerospace: Higher layer protocol based on CAN (Controller

ARINC 429: Aeronautical Radio Inc. Specification 429 Digital

ARINC 629: Further development of ARINC 429. Extension to

MIL-STD-1553B: Military (MIL) Standard (STD) which defines

MIL-STD-1773: Fiber version of MIL-STD-1553

AFDX: Avionics Full Duplex Switched Ethernet.

Master GSC & AIO 2011-2012

Master GSC & AIO 2011-2012

Master GSC & AIO 2011-2012

Bipolar , Return to Zero

TRANSMIT STATE RECEIVE

Master GSC & AIO 2011-2012

32 bit format -> Word

Master GSC & AIO 2011-2012