Control Engineering Practice 19 (2011) 524–539

Contents lists available at ScienceDirect

Control Engineering Practice

journal homepage: www.elsevier.com/locate/conengprac

AIRBUS state of the art and practices on FDI and FTC in flight control system
Philippe Goupil n
Flight Control System, Airbus Operations S.A.S. 316, Route de Bayonne 31060 TOULOUSE Cedex 09, France

a r t i c l e i n f o a b s t r a c t

Article history: This paper deals with industrial practices and strategies for Fault Tolerant Control (FTC) and Fault
Received 3 November 2009 Detection and Isolation (FDI) in civil aircraft by focusing mainly on a typical Airbus Electrical Flight
Received in revised form Control System (EFCS). This system is designed to meet very stringent requirements in terms of safety,
17 November 2010
availability and reliability that characterized the system dependability. Fault tolerance is designed into
Accepted 15 December 2010
Available online 17 April 2011
the system by the use of stringent processes and rules, which are summarized in the paper. The strategy
for monitoring (fault detection) of the system components, as a part of the design for fault tolerance, is
Keywords: also described in this paper. Real application examples and implementation methodology are outlined.
Aircraft Finally, future trends and challenges are presented.
Flight control system
This paper is a full version of the invited plenary talk presented by the author on the 1st July 2009 at
Fault detection and isolation
the 7th IFAC Symposium Safeprocess ’09, Barcelona.
Fault tolerant control
& 2011 Elsevier Ltd. All rights reserved.

1. Introduction
The Electrical Flight Control System (EFCS, also known as
Fly-By-Wire (FBW)) was first developed in the 1960s by Aerospatiale
and installed on Concorde (1969) as an analog system. Much later,
digital EFCS was introduced first on the Airbus A310 (1982), on the
spoilers, slats and flaps only, and then was generalized on all control
surfaces (3 axis) on the A320 (1987). This was rapidly followed by
installation of EFCS on the A340 aircraft, certified at the end of 1992
(Brie re, Favre, & Traverse, 1995). The first Boeing EFCS aircraft was
the B777, certified in April 1995 (Yeh, 1996). The FBW systems now
constitute an industrial standard for commercial applications (Favre,
1994). These systems are of course used on the famous A380 but are
also well adapted to military transport aircraft, like the A400M.
A considerable progress was made possible by the progressive
introduction of digital technology allowing direct benefits of the
integrated system such as weight saving, improvement of the aircraft
natural flying qualities, increased reliability and safety and improved
maintenance strategies to be realized. The EFCS provides more
sophisticated control of the aircraft and flight envelope protection
functions (Traverse, Lacaze, & Souyris, 2004). The main character-
istics are that high-level control laws in normal operation allow all
control surfaces to be controlled electrically and that the system is
designed to be available under all possible external disturbances. The
EFCS is designed to meet very stringent requirements in terms of
safety and availability. Most, but not all, of these requirements come
n
Tel.: +33 561183803; fax : + 33 561939410.
E-mail address: philippe.goupil@airbus.com
directly from the Aviation Authorities (for example FAA, EASA, for
details see the reference FAR/CS 25).
However, in parallel of the EFCS development, the number of
failure cases to be considered in the design of an aircraft is
considerably increasing because of the growing complexity of
equipments and systems. Similarly, the introduction of EFCS led
to a number of interactions with flight physic disciplines involved
in the design of an aircraft, in particular in case of failures. These
interactions must be taken into account very early in the concep-
tion of an aircraft and all along its development process. This is
why fault tolerance and fault detection are key points in the design
of a safety-critical EFCS built to meet very stringent requirements.
The compliance to these requirements is crucial to obtain
the certification that is to have the right to use an aircraft in a
civil environment in complete safety. The state-of-practice for an
aircraft manufacturer to diagnose and to tolerate faults, and then to
obtain full flight envelope protection under all possible external
disturbances, is to provide high levels of hardware redundancy. As
explained in more details in this document, relying on this strong
redundancy, fault detection is mainly performed by cross checks,
consistency tests, voting mechanisms and built-in test techniques
of varying sophistication (although analytical redundancy is used
for the detection of a very specific failure case in the A380 EFCS, see
Goupil, 2010). Fault tolerance relies mainly on hardware redun-
dancy, stringent safety analysis, dissimilarity, physical installation
segregation and hardware/software reconfiguration. Reconfigura-
tion means an automatic management following a failure. These
standard industrial practices fit into the current aircraft certifica-
tion processes.
This paper is organized as follows: in Section 2, the aircraft
development process is described using the V-cycle. Section 3

0967-0661/$ - see front matter & 2011 Elsevier Ltd. All rights reserved.
doi:10.1016/j.conengprac.2010.12.009
 P. Goupil / Control Engineering Practice 19 (2011) 524–539 525

Nomenclature FCDC Flight Control Data Concentrator

FDI Fault Detection and Isolation
ADIRU Air Data and Inertial Reference Unit FTC Fault Tolerant Control
AFDX Avionics Full DupleX switched Ethernet FWC Flight Warning Computer
CDS Control and Display System MON MONitoring channel
CMS Centralized Maintenance System MTBF Mean Time Between Failure
COM COMmand channel OFC Oscillatory Failure Case
DFDR Digital Flight Data Recorder PFD Primary Flight Display
EASA European Aviation Safety Agency RAT Ram Air Turbine
EBHA Electrical Backup Hydraulic Actuator SAO Computer-Aided Specification (‘‘Spécification Assistée
ECAM Electronic Centralized Aircraft Monitoring par Ordinateur’’)
EFCS Electrical Flight Control System SCADE Safety-Critical Application Development Environment
EHA Electro-Hydrostatic Actuator SIB System Integration Bench
FAA Federal Aviation Administration SSA Safety System Analysis
FADEC Full Authority Digital Engine Control THS Trimmable Horizontal Stabilizer
FBW Fly-By-Wire V&V Verification and Validation

describes in some details the ‘‘golden rules’’ used for designing a
Fault Tolerant EFCS. The general strategy for monitoring (fault
detection) and diagnosis of the system components, as a part of
the design for fault tolerance, is described in Section 4. Section 5
outlines the practices for real-time software implementation and
shows how the dedicated process contributes to the EFCS Fault
Tolerant design. It also presents some industrial limitations and
constraints in real-time environment. Section 6 discusses some
aspects of the system validation and verification in the frame of
the Fault Tolerant design. Section 7 proposes some examples of
real application and implementation, illustrating the methods
described in earlier sections. Future trends and challenges are
discussed in Section 8 before providing concluding remarks.
2. The aircraft development process
This section describes the aircraft development process that is
depicted in the V-cycle (Fig. 1). Strictly following this cycle
achieves Fault Tolerance assurance. The first branch of the V-cycle
is the development phase. It starts with the aircraft specification
corresponding to the ‘‘top level requirements’’: the definition of the
needs, the choice of concepts, control laws, technologies, etc. The
aircraft is decomposed into sub-parts, called systems, which are
specified in the next step. The systems are decomposed in sub-
parts called ‘‘equipment’’ (e.g. a computer), which are then speci-
fied. For instance, the software of the Flight Control Computers is
specified thanks to a specific graphical language (see Section 5). At
this step, this specification can be used in a desktop simulator
(Fig. 15) to fly the aircraft in its environment to check that it
satisfies the performance and safety requirements before the
associated code is even implemented in the equipment. This
specification is also used in a development simulator, a real cockpit
where everything is simulated. After equipment specification, the
corresponding code is generated and implemented inside the
equipment. The second part of the V-cycle can then start. This
integration phase consists of a severe validation campaign on
different test benches (see Section 6 for more details and Fig. 15
for some illustrations), from the simplest ones (an actuator bench)
to more complete ones (the ‘‘Iron Bird’’). The validation phase ends

Certification

Aircraft Programme launch

Aircraft
specification
Flight tests
Development simulator
(“Aircraft –1”)
System
specification Integration simulator
(“aircraft 0”)
“Iron Bird”
Desktop
Equipment simulator
Development Phase specification
Integration Phase
System
Integration
Simulation code Bench

Equipment +
code

Fig. 1. V-cycle representing the aircraft development process.

526 P. Goupil / Control Engineering Practice 19 (2011) 524–539
with the flight tests. The V-cycle ends with the certification process
(see Section 6).
3. Some ‘‘golden rules’’ for designing a highly dependable
system
The EFCS is a critical system in the sense that significant
consequences may result from its failures, the combination of which
could lead to the following events: control surface runaway (e.g.
rudder or Trimmable Horizontal Stabilizer (THS)), loss of control on
the pitch axis, lack of control after an engine burst or an undetected
oscillatory failure at a frequency critical to the structure (Oscillatory
Failure Cases or OFC, see Section 7). The detection of all related
failures is therefore a very important point to be considered in the
aircraft design. All the aforementioned events must be extremely
improbable, i.e. with a probability of less than 10 9 per flight hour,
and must be considered under qualitative requirements (FAR/CS
25.1309). Specifically for flight controls, FAR/CS 25.671 requires that
a catastrophic consequence must not be due to a single failure or a
control surface jam or a pilot control jam. This qualitative require-
ment is on top of the probabilistic assessment.
In order to be compliant with Airworthiness requirements for
aircraft certification and to design a fault-tolerant aircraft, Airbus
uses a number of ‘‘golden rules’’ (Traverse et al., 2004; Goupil,
2010, 2006) outlined below:
– A Safety System Assessment (SSA) to assess the effect of each
functional failure on the system. The SSA is a kind of fault tree
that studies all the possible combinations of failures to
determine the probability of occurrence of an event. The
probability of each elementary failure is given by the manu-
facturer of the equipment concerned and is re-evaluated or
confirmed by experience. This safety analysis can lead to a
modification of the flight control architecture (e.g. degree of
redundancy) and thus contributes to the design of a more fault
A340
RAT
Fig. 2. Power sources redundancy for control surface actuation, including the Ram Air Turbine.
tolerant system, compliant with the safety requirements in the
regulations.
– A stringent development process, based on the following guide-
lines: ARP 4754/ED79 (1996) for aircraft system development,
DO178B/ED12 (1992) for software development and DO254/
ED80 (2000) for hardware development. For instance, for soft-
ware development, the dedicated guidelines do not concern the
content of the software, but rather the development process to
comply with (planning, development, verification, configuration
management, quality assurance issues, etc.) in order to obtain
the aircraft certification.
– Hardware redundancy: for example the use of multiple FBW
computers (5 on an A330/A340, and 6 on an A380), and the use of
different power sources for control surface actuation. Three
hydraulic sources are used on the A320/A340. Four power sources
are used on A380 (2 hydraulics and 2 electrics). The engine power
allows to pressurize the hydraulic circuits and to supply the
electric network. Furthermore, as a last backup, in an emergency
situation, a Ram Air Turbine (RAT) provides enough energy to
pressurize one of the hydraulic circuits and/or to supply the
electric network (Fig. 2). Multiple and identical sensors also
provide air data and inertial information to other systems through
dedicated, separate but identical redundant units.
– Monitoring: all the components of the flight control system are
monitored in real-time, for example sensors, actuators and
probes. All the inputs/outputs of computers are strictly mon-
itored. The computers exchange a lot of information and this
communication must also be monitored. For example there is
a master computer that sends the servoloop command to the
others and it must be checked that this information is correctly
sent and correctly received.
– Reconfiguration: meaning automatic management following a
failure. This is a key point in the design of a fault-tolerant
aircraft. There are two levels of reconfiguration:
J First level, system reconfiguration: consider a control sur-
face with two actuators (Fig. 3). The first one is in active
E1 ES E2
Electrical RAT
A380
 P. Goupil / Control Engineering Practice 19 (2011) 524–539 527

mode and is servo-controlled by computer P1. The second J Second level, flight control law reconfiguration: in normal
one is in passive mode (it follows the movement of the conditions, with the EFCS the aircraft is protected against
active actuator) and is associated with a second computer critical events (Traverse et al., 2004). The corresponding
P2, in stand-by mode. If a failure is detected on the active flight control law is called the ‘‘normal law’’. It requires a
actuator, then it changes to passive mode and the passive high level of integrity and redundancy of the computers,
one becomes active. There is a switch-over: P2 becomes the peripherals (i.e. sensors, actuators and servoloop), and
active and controls its associated actuator while P1 changes the hydraulics. Operation under normal laws provides flight
to stand-by mode. P1 loses its functionality on this envelope protection against excessive load factors, over-
actuator but not all the others functionalities (control of speed, stall, extreme pitch attitude and extreme bank angle
other actuators, flight control law calculations, etc.). This (Fig. 4). However some protection can be lost following
reconfiguration is clearly based on hardware redundancy failures, for example the loss of a control surface, IRS
(computers and actuators). (Inertial Reference System), ADR (Air Data Reference) or a
Flight Control Computer type (e.g. all primary computers,
see next point on dissimilarity). As a result of the loss of
protection, there is a reversion to low-level laws, called
Position servoloop in P1 ‘‘alternate laws’’. Flight is still possible, but full protection
of flight envelope is no longer guaranteed. The last level law
command is the ‘‘direct law’’ where there is no protection. Manual
Control Suface trim of the aircraft is required. The probability of reverting
to a low-level law is very small. This reconfiguration is a
way to be fault tolerant and is due to a loss of hardware
Position servoloop in P2
redundancy.
command – Dissimilarity: this is also a very important point to ensure fault
tolerance. All Airbus aircraft have at least two types of
computer: a primary and a secondary computer. Their hard-
ware and software are different, and they are not developed by
the same teams. The system reconfiguration (switch-over)
described above uses primary and secondary computers
CONTROL SURFACE (Fig. 3). The secondary computer is simpler than the primary
computer. The dissimilarity also concerns actuators. On the
G Y A380, two types are used (Fig. 5): the conventional hydraulic
actuator and a new generation of electrically powered
P1 P2
actuators—the Electro-Hydrostatic Actuator (EHA). EHA has
S1 S2 been developed mainly for reducing the number of hydraulic
systems, generating significant weight and cost savings, and
Active / Stand by
providing additional dissimilarity (Van den Bossche, 2006).
Fig. 3. System reconfiguration. Electrical Backup Hydraulic Actuators (EBHA) are also used on

Bank angle

Load factor Pitch

attitude
-66°/66°

Peripheral flight envelope

-1g/+2.5g
-15°/30°
Normal flight envelope
Overspeed
α max Angle of attack
Protections not activated
Low speed
AutoPilot (AP) domain (approximately)

Manual flight in this domain is possible and

indicated by effort on the controls

Stick released or AP active

will not fly beyond this limit If exceptional upset brings the
aircraft in this domain, protections
Manoeuvring aircraft will fly are deactivated and full authority is
at this safe limit with restored
controls on stops

Fig. 4. flight domain protections.

528 P. Goupil / Control Engineering Practice 19 (2011) 524–539
Fig. 5. Two adjacent dissimilar actuators for moving a single control surface on
the A380. On the left hand side, an EHA, and on the right hand side a conventional
hydraulic actuator.
PRIM1-SEC1
2500 VU
PRIM3-SEC3- PRIM2-SEC2-
CPIOMC1 CPIOMC2
2100 VU 2200 VU
Fig. 6. Physical installation segregation of the Flight Control Computers in
the A380.
the A380. An EBHA can be viewed as an actuator with two
modes: a conventional hydraulic one that can switch to an
EHA backup mode in case of failure.
– Installation segregation: computers are not physically
installed at the same place on the aircraft, to avoid total loss
in the case of any damage (Fig. 6). Such an event could
be for example an engine rotor-burst that cuts the electrical
wires supplying the computers. The same reasoning leads to
segregation of hydraulic and electrical routes.
– Flight Control Computer architecture (Fig. 8): this is divided into
two dissimilar parts, a command channel (COM) and a monitor-
ing channel (MON). Each channel monitors the other but each
channel has a specific task. The COM channel provides the main
functions allocated to the computer (flight control law computa-
tion and the servo-control of moving surfaces). The MON
channel ensures (mainly) the permanent monitoring of all the
components of the flight control system (sensors, actuators, other
computers, probes, etc.). It is designed to detect failure cases and
to trigger reconfiguration by signaling the failure detection to the
COM channel and to the other computers.
– A perfect robustness for software and system equipment: e.g.
no monitoring false alarms, protection against ElectroMagnetic
Interference (EMI) and severe lightning strikes, no upset in the
case of total air cooling loss, etc.
A synthetic view to represent the hardware redundancy, the
dissimilarity and the system reconfiguration is the EFCS architecture
depicted in Fig. 7. It shows the example of the A340 EFCS, where at
the top the two wings are represented with the inboard and
outboard ailerons and the spoilers. At the middle, the two elevators
and the THS are depicted. At the bottom the rudder is represented,
here with an electrical structure (‘‘Enhanced’’ version contrary to the
‘‘Basic’’ version equipped with a mechanical system).
The non-critical control surfaces like the spoilers are actuated
with only one actuator while more critical control surfaces are
associated with two or even three actuators. Each actuator is
associated with one hydraulic circuit represented by a color (Y for
Yellow, etc.). ‘‘P’’ represents the primary computer and ‘‘S’’ the
secondary computer. For control surfaces with redundant actuators,
the arrows show the reconfiguration logic. For example, on the left
elevator, the primary computer P1 is the master computer on the
active green actuator and P2 the stand-by computer on the passive
blue actuator. In case of failure on P1 or on the green actuator or on
the green hydraulic circuit, a switch-over reconfigures P2 as the
master computer on the now active blue actuator (the green one
reverts in passive mode). The next possible reconfigurations are from
P2 to S1 and from S1 to S2. As can been seen in Fig. 7, the secondary
computers are rather used as a second line of redundancy.
4. General strategy for fault detection and diagnostic in EFCS
4.1. Actuator and sensor monitoring
The industrial state of the art for failure detection and diagnosis
in the EFCS are by a large majority sensor-based concepts (although
basic analytical redundancy is used to monitor the A340 THS, angle
of attack and aircraft speed estimators have been developed for
anemometry monitoring and more recently open-loop analytical
redundancy is used for the detection of a very specific failure case in
the A380, Goupil, 2010). Threshold logics are mainly used. The
general principle of these threshold-based monitorings is to test if
the whole logical condition ‘‘if a signal is greater than a threshold
AND if the monitoring is authorized’’ remains true during a given
time then the fault detection is confirmed and a reconfiguration is
triggered. The threshold can be constant or variable. The confirma-
tion time is generally constant but it can be increased in some
degraded cases. The pair {threshold/confirmation time} can be
dissimilar from one computer to another, for the same monitoring.
The authorization is given by a Boolean signal. Indeed it is not
necessary to monitor all the time. For example if a sensor is not
electrically supplied the monitoring will certainly trigger while there
is no fault (false alarm).
Each sensor is also monitored by checking that the measure-
ment signal does not exceed specific limit thresholds (e.g. the
voltage delivered by the sensor must remain inside predeter-
mined limits) or that there is no wire cut. The power supply is
also monitored. Threshold-based concepts are also used for these
sensor monitorings.
As explained above in Section 3, the typical Airbus Flight Control
Computer COM/MON architecture is composed of two dissimilar
channels: the COM channel (command) and the MON channel
(monitoring). The flight control laws are computed separately in
each channel thanks to dedicated sensors (Fig. 8). Each channel also
 P. Goupil / Control Engineering Practice 19 (2011) 524–539 529

(6 1) SPOILERS SPOILERS (1 6)

Y G Y B B G G B B Y G Y
AILERONS S1 P1 P2 S2 P3 P3 P3 P3 S2 P2 P1 S1 AILERONS
OUTBOARD INBOARD INBOARD OUTBOARD

Y G G B G B Y G
P3 S1 P1 P2 P1 P2 S2 P3
THS Actuator
S1 S2 S1 S2

B Y

LEFT ELEVATOR RIGHT ELEVATOR

B G G Y
Mechanical
P2 P1 P1 P2

S2 S1 S1 S2
1 2 3 DEMs
P1 P2 P3

P2 B

P1 S1 G

P3 Y

Back-up Control
BCM Module

BPS
Pedal Feel Trim
B Y Back-up power
supply
PFTU Unit
S1 S2

Fig. 7. A340 EFCS architecture.

COMmand

Flight Actuator
Control K
Law (Command)

Flight
Control MONitoring
Law

Fig. 8. An example of the COM/MON-based monitoring.

receives a dedicated control surface or actuator position. It is then
possible to compute in a dissimilar way the same signal in each
channel. The signal computed in COM channel is sent to the MON
channel via an internal dedicated bus and a threshold-based
monitoring is applied to detect any possible fault due to a channel,
a sensor or a computer input/output for example.
4.2. Flight parameter choice and monitoring
One of the main tasks dedicated to the Flight Control Computer is
to calculate the Flight Control Laws. The result is the commanded
control surface deflection, which, in manual control, is computed
based on the pilot command and the aircraft motion and air data
sensor information. The actuator drives the control surface to the
commanded position. The corresponding aircraft response is again
sensed by the motion and air data sensors and fed back to the
computers (Fig. 9). The processing of anemometric and inertial data
in the Flight Control Computers is thus a significant step. These data
are sensed in dedicated identical redundant computers called ADIRU
(Air Data and Inertial Reference Units). A Flight Control Computer
generally receives 3 redundant values of each Air and Inertial Data
from the ADIRUs and calculates unique flight parameters required
for the Flight Control Laws computation. This specific processing,
called ‘‘consolidation’’ or ‘‘Triplex’’, is classically built in two steps
530 P. Goupil / Control Engineering Practice 19 (2011) 524–539
Flight Control Computer
Objectives Flight Control Law
Command computation
Fig. 9. General principle of flight control laws computation.
ADIRU1
ARINC “consolidation” Flight Control Law
ADIRU2
Choice
ARINC
ADIRU3 Flight control
ARINC laws
Monitoring
computation
A/D
Fig. 10. ADIRU monitoring principle and localization in the Flight Control Computer.
(Fig. 10): firstly, from the 3 sources, selection of one unique and
accurate parameter and secondly, monitoring of each of the 3 inde-
pendent sources to discard any failed source and to ensure that the
selected value is correct. This overall ‘‘consolidation’’ processing
allows choosing unique reliable flight parameters with the required
accuracy by discarding any possible failed redundant source. It also
ensures that all the Flight Control Computers receive the same input
value. A majority voting scheme is generally used and is considered
as a proven technology in modern FBW systems (Rosenberg, 1998).
4.3. Diagnostic in the EFCS
In addition to the dissimilar Flight Control Computers, two Flight
Control Data Concentrator (FCDC) computers are in charge of
the system maintenance and warnings, cautions and indications
(Fig. 11). The FCDCs acquire from the primary and secondary
computers mainly the results of the different monitorings imple-
mented in the MON channels. The FCDCs compute some logics to
generate warning messages towards the alarm system computer
(FWC). These messages are displayed in the cockpit through a
dedicated screen (ECAM). The FCDCs generate messages towards
the maintenance system (CMS), concentrate and transmit specific
data to be recorded in the black boxes (DFDR). Finally, the FCDCs
concentrate and transmit data via the Control and Display System
(CDS) to generate the Flight Control page and to display some
information on the Primary Flight Display (PFD). For example, if
Servo control
(PI controller)
actuator
probes, ADIRS,…
aircraft state
A/D
-
+ K A/D
SERVOLOOP
several failures are detected on the same control surface, leading to
its loss, then this information must be displayed in the cockpit for
the awareness of the pilots. The FCDC also acquire general informa-
tion on the flight phase and different data on the kind of aircraft
used, the engines, dating information, etc. All these data are sent to
dedicated and relevant computers.
The diagnostic is thus a high-level one, elaborated by combin-
ing different information sent by the Flight Control Computers.
There is not a low-level diagnostic allowing, for example, to find a
faulty component inside an actuator. In some cases, some specific
monitoring focuses on a component (e.g. servo valve) and incri-
minates de facto the faulty component. There is no high-level
monitoring with a large cover allowing to isolate the faults. The
state of the art rather consists in the multiplication of the
monitorings. As can be seen in Fig. 11, the Human-Machine
Interface is of primary interest and a lot of redundant computers
are dedicated to provide clear messages to the pilot and to store
messages for maintenance tasks.
5. AIRBUS practices for real-time EFCS software
implementation
5.1. Flight control computer functional specification
The specification of a computer includes, on the one hand, an
‘‘equipment and software development’’ technical specification used
 P. Goupil / Control Engineering Practice 19 (2011) 524–539 531

FWC

Alarms
Flight Control Display
Fault detection
Flight Warning
Computer
ECAM

FCDC
PRIM

CDS

AFDX Display
PFD
Control and Display System

CMS
SEC

printer

Boolean information
Centralized Maintenance System
(via AFDX)
Primary Flight Display
DFDR

Digital Flight Data Recorder

Fig. 11. Fault diagnosis in the A380 flight control system via the FCDC computers.

to design the hardware and partly the software. On the other hand, a
functional specification accurately defines the functions implemented
by the software. The main specified functions are: sensor acquisition
and monitoring, flight control laws, monitoring functions, slaving of
control surfaces and reconfigurations. In the first step (Fig. 12), a
graphical tool allows specification of these functions (computer-aided
specification). A limited set of graphical symbols (adder, filter,
integrator, look-up tables, etc.) is used to describe each part of the
algorithm in dedicated ‘‘functional specification sheets’’. If a specific
processing is often used, a dedicated functional block could be
developed (as with classical programming languages). Two software
are generally used: SAO (Airbus software, Computer-Assisted Speci-
fication) or SCADETM (Safety-Critical Application Development Envir-
onment). The use of a formal specification language also allows parts
of the specification to be used from one aircraft program to another.
This specification is under the control of a configuration management
tool and its syntax is partially checked automatically. In a second
step, an automatic generation tool produces the code to be directly
implemented in the flight control computer. Such a tool has as input
the functional specification sheets, and a library of software packages,
one package for each symbol used. The automatic programming tool
links together the symbol packages (Traverse et al., 2004).
The SAO tool was first developed by Aerospatiale for A320
development requirements. For most recent aircraft development
(e.g. A340-500/600, A380), the SCADETM software suite is also
used. These tools use different automatic generation tools and
different libraries of software packages.
The use of such tools is part of the Fault Tolerant design of the
EFCS and thus has a positive impact on safety. An automatic tool
ensures that a modification to the specification can be coded
easily even if this modification needs to be embodied rapidly
(situation encountered during the flight test phase for example).
In case of a new specification standard, ‘‘non-regression’’ tests are
performed very early into the design process to check the validity
and the absence of errors possibly due to the modifications. These
tests are performed as early as possible to minimize the debug-
ging efforts along the development phase.
Fig. 13 shows an example of a functional sheet used for
specifying the servo-control of a control surface. In this case, only
very basic symbols are used: adders, gains, a limiter, an ‘‘OR’’ logic
gate and a switch. Inputs are Boolean conditions (triangle shape)
and real signals (command, position, etc.). Outputs are real signals
and hardware analogic outputs toward the actuator (black out-
put). The logic describes the servo-control of a given control
surface in a common proportional-integral (PI) scheme. The
command (the desired control surface position) is compared to
the real control surface position measured by a dedicated sensor
inside the actuator. The resulting control loop error is multiplied
by an appropriate gain to provide a first current. To compensate
any possible bias at the actuator level, an appropriate compensa-
tion current (integral part of the PI controller) is added to the first
current to provide the current signal that is sent to the actuator.
The computation of this bias is specified in another functional
sheet and is not shown in Fig. 13. The servo-valve receives the
total current and converts it in a hydraulic fluid movement inside
the actuator chambers to finally move the actuator rod, which is
linked to the control surface. A functional sheet is also defined by
a set of information like the aircraft type, the kind of computer,
the function specified, the sampling period, the sheet version
(number of modifications), the name of the designer, etc. To give
an example of the computational burden, the A380 primary
computer is entirely specified by about 5000 functional sheets
and the secondary computer by about 2500 sheets. It could also
be required to ‘‘sequence’’ (to sort) the functional sheets in order
to compute one sheet just after another one, to minimize the
delay between signals.
532 P. Goupil / Control Engineering Practice 19 (2011) 524–539
Functional specification sheet writing (SCADETM)
Fig. 12. Synopsis of the software implementation in the Flight Control Computer.
boolean_1
boolean_2
Bias (compensation current)
gain
K
command
+ K1
+ +
- LIM
position K L
K2
gain
boolean_3
Fig. 13. An example of a functional specification sheet (control surface servo-control).
5.2. Industrial limitations and constraints
On a large civil aircraft, the flight control computer computing
capacities are low compared to other classical non-critical applica-
tions (e.g. multimedia). Proven and robust processors must be used
for critical applications. For example, the current A340 primary
computer processor is an AMD 486 DX4, at 32 MHz, representing
about 19 Millions of instructions per second (see Fig. 14 for other
examples of Airbus computers capacities). Consequently, it is very
difficult to use advanced processing with a high computational
burden, like an on-line optimization algorithm or even wavelet
or Fourier transforms. For instance, the matrix triangularization
involved in many nonlinear filtering techniques is difficult to
implement and all elementary operations involved in this case must
be detailed at a low level. A complex algorithm must be developed
with as much simplifications as possible to be implemented, by
deleting all needless operations and redundancy. In general, a loss of
performance occurs after such simplifications and typically a trade-
off between complexity and performance must be found.
The typical Airbus Flight Control Computer architecture consists
of two separate independent channels (see Section 3), each with its
own clock. Consequently, there is a time asynchronism between
both units. Some data are recorded in one unit but not in the other:
for instance (Fig. 8), the MON channel acquires dedicated position
sensors that measure the position of some control surfaces in
degrees (these sensors are located inside the control surfaces). If a
design is implemented in COM channel and if it requires a MON
data, then this data must be sent from MON to COM via a dedicated
bus and there is an additional time asynchronism to take into
account. Moreover, the Flight Control Computers are multi-rate time
Software library
Configuration Automatic
Management Code
Tool Generation
(syntax checked)
current_ano
A
+
current_c
+ current
current
+L1
-L1
triggered, which means that all data are not processed with the
same sampling period, even in the same unit. For example, some
data are produced every 40 ms. An algorithm computed every 10 ms
requiring a data at 40 ms must adapt this latter data to this faster
sampling time, by using for example some prediction filter. This can
have a serious impact on a design. Similarly, some useful data like
the air and inertial information are sent by other dedicated
computers with different sampling periods. These data received in
the Flight Control Computer also present an asynchronism to take
into account. Some designs could be sensitive to all these asyn-
chronisms and should be able to deal with it.
Two last general remarks are given below, not directly linked
to the software implementation itself but to be considered as
strong industrial limitations and constraints for real-time imple-
mentation in critical systems.
From the perspective of implementing any designs, a low false
alarm rate is required in order not to degrade the flight safety and
the operational reliability. Indeed, the operational consequence
induced by a false alarm is, for example, the removal of a healthy
computer, a costly operation that requires the grounding of the
aircraft. The false alarm rate must be lower than the Flight Control
Computer Mean Time Between Failure (MTBF, i.e. the arithmetic
mean time between failures of a system). Similarly, a low non-
detection rate is required on a critical system as the consequences
of a failure might be significant. All failures with potentially a
catastrophic consequence must be demonstrated to be extremely
improbable to obtain certification: that is with a probability less
than 10 9 per flight hour. Thus, the product of the probability of
occurrence of the failure to be detected by the probability of non-
detection should be less than 10 9 per flight hour.
 P. Goupil / Control Engineering Practice 19 (2011) 524–539 533

PRIMary computer : AMD 486 DX4 (32 MHz), ≈19 MIPS

A340 SECondary computer : Sharc ADSP (40 MHz)

Flight Management and Guidance and Envelope Computers

(FMGEC) Intel 286 (16 MHz)

Primary computer : Power PC755 (66 MHz→ →98MHz)

(Flight Control & Guidance Computer)
A380

Secondary computer : DSP Sharc (40 MHz)

Fig. 14. Comparison of A340 and A380 Flight Control Computer features.

In the perspective of using innovative and advanced designs an
easy tuning is required for possible use on different control surfaces
and different aircraft. If the tuning of some important parameters is
too difficult, or requires too specific expertise, then it will not be
useful for an industrialist. For instance, the initial tuning of Q and R
matrices (the covariance matrices of the process noise and the
measurement noise in a state space representation) is a crucial issue
for nonlinear filtering (e.g in an Extended Kalman Filter). A bad
choice could lead to diverging behavior. The use of simple
approaches with restricted high-level parameters, which are easy
to tune is also very important to reduce the test phase during
the certification procedure. Due to the constraints of a critical
system, the convergence and the stability of the designs must
be proven to avoid any diverging behavior that can potentially
degrade the availability of the flight control system (a false alarm
leads to a system reconfiguration and degrades the hardware
redundancy level and potentially the flight envelope protection
level). Diverging behavior could also lead to a numeric overflow
entailing an automatic switch-off of the related Flight Control
Computer.
6. System validation and verification, certification
Significant verification and validation (V&V) is performed all
along the V-cycle. The verification objective is to get assurance that
the product (system/equipment) is compliant to its specification. The
validation objective is, on the one hand, to get the assurance that the
specifications are correct and complete, and on the other hand, to get
the assurance that the final product is compliant with the customer
needs. Consequently, the V-cycle is not a fixed process but rather an
iterative process due to the verification and validation activities that
can lead to changes in some system/equipment specifications all
along the cycle.
Aviation Authorities regulations (see reference ‘‘FAR/CS 25’’) are
requirements and part of the aircraft specification. Hence verifica-
tion and validation need to demonstrate aircraft compliance to these
requirements in order to obtain certification, that is to obtain the
right to use the aircraft in operational and commercial conditions
by ensuring and preserving the safety of the public, either on
the ground or in the air. As a consequence, certification may be
considered as a sub-process of the validation and verification
process but with more formalism (certification sheets, reviews,
etc.) and a particular point of view (safety oriented).
More precisely, early in the development cycle of a new
aircraft, a verification and validation plan is defined. The main
purposes are:
– To establish a strategy, to define the process and the sharing of
responsibilities between stakeholders and to foresee the activities,
– To define as soon as possible the test means to implement (see
details below),
– To provide at a given time the status of the achieved validation
and verification activities, by the mean of matrices (V&V
formal deliverables),
– To serve as an input for the writing of a document summariz-
ing all the V&V activities (‘‘V&V summary’’) performed during
the aircraft development.
– To respond to certification process request.
The interest of the two first points is, while satisfying the final
objective, to optimize the development process in order to reduce
associated costs and duration.
These activities shall not forget to consider the risks and
constraints on the product development and on the design
novelties as well as experience feedback of previous problems
in operation. These elements will guide the determination of
coverage objectives and V&V activities.
The V&V final objectives are:
– Certification of the aircraft type: to produce an aircraft
compliant with safety and airworthiness requirements.
– Verification of the product: verification of the final and inter-
mediate products against requirements.
534 P. Goupil / Control Engineering Practice 19 (2011) 524–539
– Validation of requirements: validation of the specified require-
ments against the user needs (implicit and explicit), the
requirements being the expression of the user needs, this
activity is to ensure that the specifications at each level are
sufficiently correct and complete so that the resulting products
will satisfy the user needs. Validation of the final product
against the implicit user needs, the validation against the
explicit ones being covered by previous activity.
– Service ready at first flight: guarantee a sufficient level of
maturity for the first flight by avoiding retrofit of equipment as
far as possible.
The system validation and verification proceeds through
several steps:
– Peer review of the specifications, and their justification. This is
done in light of the lessons learned by scrutinizing incidents
that occur in airline service or the lessons learned during flight
tests of the previous aircraft programmes.
– Automatic check of the specification syntax with a configura-
tion management tool, before automatic coding.
– Analysis, in particular the SSA (see Section 3), which, for a
given failure condition, checks that the monitoring and recon-
figuration logic allow the fulfilment of the quantitative and
qualitative objectives, also analysis of system performance,
and integration with the structure.
– Tests on a desktop simulator using the automatically produced
software coupled to a rigid aircraft model (Fig. 15 a).
– Tests on a System Integration Bench (SIB), a test bench used
particularly to tune the servo-control of a given control sur-
face, with simulated inputs and observation of computer
internal variables (Fig. 15 b). This bench offers the possibility
of validating degraded configurations: e.g. low hydraulic
pressure and high aerodynamic loads (simulated with torsion
bars, from zero to the stop load) on the control surface.
– Tests on the ‘‘Iron Bird’’ (Fig. 15 c): a test bench that is a kind of
very light aircraft, without the fuselage, the structure, the
Fig. 15. AIRBUS ground test facilities. (a) Desktop simulator, (b) A380 elevator SIB, (c) A380 Iron Bird and (d) A380 flight simulator.
seats, etc, but with all system equipment installed and pow-
ered as on an aircraft (e.g. hydraulic and electric circuits).
– Tests on a flight simulator (Fig. 15 d): a test bench with a real
aircraft cockpit, Flight Control Computers and coupled to a
rigid aircraft model. The Iron Bird can also be coupled to the
flight simulator.
– Flight tests, on several aircraft, fitted with ‘‘heavy’’ flight test
instrumentation. More than 10,000 flight control parameters
are permanently monitored and recorded. Aircraft in flight
tests also include ‘‘Early Long Flight’’ (mostly to validate the
cabin and systems upgrade configuration) and ‘‘Route Proving’’
(certification exercise, which aims at accumulating dozens of
hours of typical airline continuous operation).
7. Examples of real application
7.1. Abnormal aircraft configuration compensation by flight control
laws
Inside normal flight envelope, FBW flight control laws provide
an instinctive piloting, which means the same flying techniques
as on a conventional aircraft, with accurate and comfortable
control. In particular, they must provide enhanced stability and
maneuverability and must be able to compensate aircraft config-
uration changes. In manual control, the general principle is to
convert the sidestick and rudder pedals inputs (measured by
dedicated sensors) in piloting objectives. These objectives are
then compared to the real state of the aircraft, which is measured
by dedicated sensors (inertial, anemometric, probes, etc.), in order
to compute a command (position order) to servo-control each
moving surface (Fig. 9).
The Flight Control Laws are split into longitudinal and lateral
control laws. The longitudinal control laws are split into an outer
loop (guidance, i.e. control of the trajectory of the aircraft center of
gravity), an inner loop (piloting, control of the aircraft movement
 P. Goupil / Control Engineering Practice 19 (2011) 524–539
around its center of gravity) and an auto-thrust control loop. The
longitudinal objective is a vertical load factor command. The outer
loop computes this load factor demand, which is achieved via the
inner loop by controlling the elevators and the THS. The lateral
control laws are split into an outer loop and an inner loop. The
lateral objective is a roll rate and a sideslip order, which is achieved
via the inner loop by controlling the rudder and roll surfaces.
Some EFCS failures, like for example a control surface runaway
or an incorrect lateral centering of the aircraft (fuel imbalance),
may generate an aircraft dissymmetry. In case of a control surface
runaway or jamming, if the unwanted deflection is sufficiently
high, the dedicated monitoring will trigger and a system reconfi-
guration (switch-over toward the safe redundant actuator) will
allow eliminating the dissymmetry after a short transient phase.
However, if the spurious deflection is too small to be detected
then the dissymmetry will be compensated in flight either by the
Autopilot or by the pilot in manual control by moving the relevant
control surfaces (Fig. 16). Any failure leading to an aircraft
dissymmetry has the following effect: a roll (respectively a yaw
and a pitch) movement compensated by the control surfaces of
the roll (respectively a yaw and a pitch) axis. Due to the coupling
between different axes, control surfaces of several axes can be
used for compensation. The direction and the intensity of the
control surface deflection used to compensate the failure depend
on the side of the dissymmetry, on the kind of failure and on the
failure amplitude.
The example of an engine asymmetry or failure on the A380 is
now detailed to illustrate the Flight Control Law compensation.
On a conventional aircraft, such a failure results in constant
sideslip and roll rate with an extremely diverging heading. Before
A380, FBW Airbus lateral normal laws bring a correction and
stabilize the aircraft in a steady state of constant bank angle and
sideslip, with slowly diverging heading. With A380 lateral law,
the lateral asymmetry is automatically compensated (passive
fault tolerance): sideslip is maintained close to zero, with a
remaining roll angle of few degrees. Because of this automatic
compensation, pilots might miss the engine failure; therefore, a
specific mean to alert pilots that an engine failure occurred shall
be designed (audio warning or dedicated display).
However, during the A380 flight test campaign, there was a
need expressed by pilots to detect an engine failure through an
aircraft movement and not only through a warning or a simple
display in the cockpit. So, it has been chosen to simulate the effect
of the engine failure through the lateral law by commanding a
sideslip in the same sense as the one resulting of the engine
failure: thus, the engine failure is felt by pilots like on any other
aircraft, but sideslip is smaller and much better controlled. On the
A380, the lateral law is called the ‘‘Y* law’’. On this aircraft,
V
<0 X X
Failed control
surface
Φ>0
Fig. 16. Effect of the dissymmetry (left hand side) and control surfaces used to compensate (right hand side).
535
a dedicated sensor measures the sideslip information whereas on
other Airbus aircraft it is estimated. As illustrated on Fig. 17, one
of the Y* specificity is to use a hybrid between sideslip measure
and estimation and to have an integrator lane between pilot’s
command (sideslip command) and feedback (hybrid sideslip):
this integrator insures a better control of the sideslip, compared
to other aircraft, including previous FBW Airbus. Rudder and
ailerons deflections are calculated in order to minimize the drag
while keeping enough maneuverability to safely continue the
flight.
This example is a good illustration of the necessity for an
efficient awareness of the pilots about the aircraft state through-
out a movement or a dedicated interface in the cockpit. Another
point to highlight is that a pilot in the loop is essential during the
design, in close cooperation with the designers. This corresponds
to a concrete industrial practice.
7.2. A380 oscillatory failure case detection
As previously mentioned, the EFCS is a critical system designed
to meet very stringent requirements in terms of safety and avail-
ability. The detection of all related failures is therefore a very
important point to be considered in the aircraft design. In particular,
in the context of overall aircraft optimization and their increasing
size, system design objectives originating from structural load
design constraints are more and more stringent. The main issue is
weight saving to improve the aircraft performance (e.g. fuel con-
sumption, noise, range). Consequently, for system failures impacting
the aircraft structure, the performance of detection methods must
be improved, while retaining perfect robustness.
EASA regulations CS 25.302 used for aircraft certification state
that the system must be designed so that it cannot produce
hazardous loads on the aircraft. EFCS-failure cases having an
influence on structural loads are mainly runaway or jamming of
a control surface, the loss of limitations (e.g. rudder deflection
limitation as a function of aircraft speed) combined with man-
oeuvres, loss of an EFCS special function to reduce structural
design loads (e.g. Load Alleviation Function) or degradation of
deflection rates. Some EFCS failures may also result in unwanted
control surface oscillations, generating loads on the structure
when located within the actuator bandwidth. This failure case is
called an Oscillatory Failure Case (OFC) (Besch, Giesseler, &
Schuller, 1996). These failures may lead to unacceptably high
loads or vibrations, when coupled with the aeroelastic behavior of
the aircraft. The worst case corresponds to resonance phenomena
with the aircraft natural modes. This is very improbable as the
OFC frequencies are uniformly distributed. But one cannot prove
V
Control surfaces used
for compensation
Φ<0
536 P. Goupil / Control Engineering Practice 19 (2011) 524–539

 Lateral control
law
+
Gain + Gain
Global
commanded wings
bank angle Σ surfaces
command
Φ Gain

p Gain

r Gain

βhybrid Gain Rudder

Σ deflection
Gain command
-
LIM Gain
++

Fig. 17. A380 Y* flight control law synopsis.

that it is impossible, so this case has to be covered. OFC amplitude

must be contained by the system design within an envelope
function of the frequency. The ‘‘usual’’ monitoring techniques
cannot guarantee staying within an envelope with acceptable
robustness and a specific OFC detection must be used. The ability
to detect these failures is very important because it has an impact
on the structural design of the aircraft since the load envelope
constraints must be respected. More precisely, if an OFC of given
amplitude cannot be detected and passivated, this amplitude
must be considered in the load computations. The result of this
computation can lead to reinforcement of the structure. In order
to avoid reinforcing the structure and consequently to save
weight, low amplitude OFCs must be detected in time. Only OFCs
located in the servo-loop control of the moving surfaces are
considered, that is, between the Flight Control Computer and
the control surface, including these two elements.
Two kinds of OFC have to be considered: ‘‘liquid’’ and ‘‘solid’’
failures. The liquid failure is a spurious oscillatory signal adding to
the normal signal (additive failure, inside the control loop) while t0
the solid failure substitutes the normal signal (a.k.a interference,
also inside the control loop). Fig. 18 illustrates the two kinds
of failures, liquid and solid. At time t0, an additive (resp. an
interference) faulty signal occurs on the nominal signal. The OFC
detection methodology must take into account the specifics of
these two different cases. ‘‘Liquid’’ and ‘‘solid’’ is a peculiar
terminology to AIRBUS. To refer to a widely used terminology,
the reader is invited to consult (Isermann, 2006) where the IFAC-
SAFEPROCESS terminology for fault detection and diagnosis has
been published, as well as principles of fault-tolerant systems. t0
To detect an OFC on the A380, the concept of analytical
redundancy is used. This is a conventional approach well known Fig. 18. The two kinds of OFC to detect. The faulty signal occurs at time t0
in the Fault Diagnosis community (Chen and Patton, 1999; Frank, (a) nominal signal, (b) liquid OFC and (c) solid OFC.

1990; Zolghadri, Goetz, Bergeon, & Denoise 1998; Patton, 1991,

1995; Patton, Frank, & Clark 2000). Applications on aircraft systems
have already been published, like for example a model-based fault
detection and diagnosis for a cabin pressure actuator (Moseler,
Heller, & Isermann 1999; Isermann, 2005). The principle consists
of comparing the real functioning of the monitored control surface
with an ideal functioning expected in the absence of failure, in order
to exhibit the failure. For OFC detection, a nonlinear knowledge-
based model of the actuator is used to provide this ideal functioning,
in an open-loop scheme. The overall method is usually built in two
steps (Goupil, 2010): residual generation and residual evaluation.
First, a residual is generated by comparing the real position p of the
control surface (obtained by a sensor) with an estimated position p^
produced by the actuator model. The input of the model is the flight
control law (the command used in the servo-control of the control
surface). Then secondly, the residual is decomposed in several
spectral sub-bands. In each sub-band, counting oscillations of the
filtered residual performs the OFC detection. The overall method is
summarized in Fig. 18. Specific counting is applied in parallel for
each failure type (liquid and solid). In this approach, the flight
control law is considered as fault-free. All its oscillations are
calculated in order to compensate for any normal perturbation
 P. Goupil / Control Engineering Practice 19 (2011) 524–539 537

(e.g. an external disturbance such as turbulence). The hypothesis of
a fault-free command is justified because the flight control law is
also monitored by dedicated techniques.
For further details, the reader can refer to (Goupil, 2010). This
model-based method is currently used on the A380 and gives
highly satisfactory results in term of robustness and detection and
permits very stringent load requirements to be met (Fig. 19).
7.3. FDI/FTC examples in engines
The engines are completely controlled by a redundant digital
computer called the FADEC (Full Authority Digital Engine Control).
The FADEC computer controls the engine in response to thrust
command inputs from the aircraft, regulates the fuel flow and
provides information for cockpit display. The FADEC system consists
mainly of one computer, the Electronic Engine Control (EEC), which
contains the most important functions. On the most recent aircraft,
there is a second computer, the Engine Monitoring Unit (EMU). The
EMU has two functions: engine vibration monitoring and enhanced
health monitoring. However, some detection functions are also
implemented in the EEC, dedicated for example to over-speed or
over-thrust threats. EEC integrity and reliability also relies on
hardware redundancy as it is composed of 2 channels, namely
channel A and channel B, each containing its own power supply unit
and inputs/outputs. Both channels transmit the same data. The two
channels are sufficiently isolated to protect against the worst-case
single failure and to prevent fault propagation between them. One
channel controls all outputs while the other channel is in stand-by
mode (except for over-speed and over-thrust functions where both
channels are in control).
Command u (n)
(Flight Control Law)
rod sensor
position pr(n) Baseline
Controller
Actuator Actuator &
control surface
model
Control
surface
real control estimated control
surface position p(n) surface position pˆ (n)
+ -
residual r (n)
Subband
Filtering
Solid failure detection Liquid failure detection
On previous Airbus programmes (except A380), the engine
thrust is indicated to the flight crew through either pressure ratio
(e.g. Engine Pressure Ratio, EPR) or low-pressure compressor
rotation speed N1. Although these parameters indicate engine
thrust, they are not only dependent on thrust but are also
affected by secondary factors such as air data parameters (alti-
tude, temperature, airspeed, humidity, etc.). Therefore, Airbus has
introduced on the A380 a cockpit indication of engine thrust,
called Airbus Cockpit Universal Thrust Emulator (ACUTE), which
is only a different manner to display parameters, and does not
affect in any way the engine control laws or the auto-throttle.
This new display refers to the engine maximum thrust capability.
The traditional engine parameters are still available in the cockpit
as secondary indications, for certification requirements. With this
concept, thrust indications are displayed in the cockpit as ‘‘per-
centage of maximum thrust’’ using reference levels between
0 and 100. The parameters used by ACUTE system to compute
the actual thrust of the engine are the classical engine control
parameters (EPR, N1), the bleed status (ON or OFF) and the air
data. As an erroneous air data impacts the display, but also the
engine thrust, it is necessary to have redundant measurements
and to use a dedicated logic to select a reliable and accurate value.
The air data come mainly from two independent sources: the
aircraft sensors and the FADEC sensors. The aim of the air data
selection logic is to compare the FADEC’s redundant inputs and to
select an accurate value. In this purpose, each of EEC receives,
through the AFDX network, pressure (P0, Ptotal) and temperature
(TAT) measurement from three redundant and independent air-
craft dedicated units (namely ADIRU). The FADEC system acquires
its own anemometric data (P0, Ptotal, TAT) from sensors located
on the engine, and also sends them to the ADIRUs. These engine
sensors may be dual or single depending on the architecture. The
FADEC system compares its own values with the ones provided by
the ADIRU. As the ADIRUs receive engine sensor data from each
engine (4 on the A380), they are able to inform the FADEC about
agreement with others engines to help in the choice of the most
appropriate source, in case of a failure. Thus, the air data selection
logic relies a lot on hardware redundancy and used check
consistency (e.g. vote) between these parameters or between
other values derived from these parameters.
An example of such architecture is given on Fig. 20. The
three redundant and independent ADIRUs send through AFDX
bus the pressure and temperature measurements. The pressure
P0 is measured by a single transducer located in the engine
and transmitted to the EEC channel B. This information is
provided to channel A via cross communication channel, giving
each channel a P0 signal. A specific engine pressure P20 is
measured by a single transducer, which is directly connected
to channel A of the EEC. This information is provided to channel B
via cross communication channel, giving each channel a P20
signal. Two resistance temperature devices also measure tem-
perature on engine. These sensors are wired one to each channel
of the EEC. Thus, each channel A and B can process separately
the same parameters delivered by redundant and dissimilar
sources.

− pˆ (n) 0 8. Future trends and challenges, conclusion

Oscillation counting A big civil aircraft is a very complex industrial product the
Oscillation counting development of which implies a lot of interactions between a big
number of equipments and systems. This document focuses on
Reconfiguration if
Residual Energy > TE flight control system (some different practices could be applied in
OFC detected
during tconf other systems). The general principles have been presented and
should allow to understand the philosophy of the fault detection
Fig. 19. Synopsis of OFC detection by analytical redundancy. and fault tolerance: it relies a lot on hardware redundancy, it uses
538 P. Goupil / Control Engineering Practice 19 (2011) 524–539
aircraft engine
ADIRU 1
ADIRU 2
ADIRU 3
P0
Ptotal
TAT
P20_A
P0_A
P20_B
AFDX
Air data selection Air data selection
Channel A
Fig. 20. Air data selection in A380 engine computers.
simple (compared to the academic designs described in the
literature) but robust algorithms and the diagnostic is performed
through dedicated computers that deliver high-level diagnostic
information. Basic analytical redundancy has been used in the
past (to monitor the A340 THS), and a more advanced one is
currently used on the A380 (for the detection of a very specific
failure case, OFC) and for anemometry monitoring (angle of attack
and aircraft speed estimators).
Concerning the future trends, as previously mentioned in Section
7, system design objectives originating from structural loads design
constraints become more and more stringent. Satisfying the newer
societal imperatives towards an environmentally friendlier aircraft
(quieter, cleaner, smarter and more affordable aircraft) has become
indeed the stake of current research works. Highlighting the link
between aircraft sustainability and fault detection, it can be demon-
strated that improving the performances of fault diagnosis in EFCS
allows to optimize the aircraft structural design (weight saving) and
then to improve the aircraft performances decreasing de facto its
environmental footprint (e.g. less fuel consumption and noise).
Consequently, for system failures impacting the aircraft structure,
like control surface runaway, jamming or like OFC, performance of
detection methods must be improved, while retaining a perfect
robustness. In the case of OFC detection, this means that it could be
required to detect earlier less important OFC amplitude. This is the
topic of current works where closed-loop approaches are investi-
gated (Alcorta-Garcı́a, Zolghadri, & Goupil, 2009; Alcorta-Garcı́a,
Zolghadri, Goupil, Lavigne, & Simon, 2009; Lavigne, Zolghadri,
Goupil, & Simon, 2008) in order to improve the open-loop scheme
used on the A380. Detection of the jamming of a control surface at
smaller and smaller positions is also a challenging problem for
improving aircraft performances. Another interesting challenge is a
better isolation of the detected failure. Considering the actuator case,
it could be clearly interesting to fix the failure source location in the
control loop in order to ease the maintenance task. Similarly,
predictive maintenance, instead of scheduled inspection, is a long-
term objective related to the capability and viability of modern FDI
techniques with a strong application in the flight control system.
P20
P0
P0_B
EEC
Channel B
Safety is clearly the top priority of an aircraft manufacturer.
This can be done by adding more and more software monitoring,
sustained by supplementary sensors, probes, etc. Due to these
additional equipments, there could be a negative impact on the
aircraft weight, and so a negative impact on the cost and
performances. It could then be required to rationalize the whole
flight control architecture. One possibility is to use reliable flight
parameter estimations instead of additional sensors. This will add
dissimilarity conditionally that the estimations are accurate and
reliable enough. The other advantage of using estimations con-
cerns the maintenance, as software is easier to control and inspect
than hardware. Another challenging aspect concerns the reduc-
tion of the pilot workload. As an answer to airworthiness regula-
tions, Airbus recommends crosschecking by the pilots of some
flight parameters displayed in the cockpit. This crosschecking
could be improved, in the sense of a decreased workload, by a
better upstream selection and monitoring of the flight para-
meters, especially that there is no increase in value when a
human makes this checking. Use of flight parameter estimations
by analytical redundancy, in addition to redundant physical
sensors, could also ease the selection of a relevant measure.
Safety is the first priority: in service experience has shown that the
Airbus EFCS is safe, and even features safety margins. For future
and upcoming programs, in particular in the context of aircraft overall
optimization, more stringent requirements will be demanded.
Consequently, news solutions should be studied. The examples given
in this paper show that Airbus is continuously improving, in an
innovative way, the Fault Tolerant design of its aircraft. The Airbus
Flight Control System division has been involved in research group
like GARTEUR Flight Mechanics Action Group FMAG (16) on
Fault Tolerant Flight Control (www.garteur.org). This division is also
currently involved in the French project SIRASAS (https://extrane-
t.ims-bordeaux.fr/External/SIRASAS/), which deals with innovative
and robust technologies that could significantly increase spacecraft
autonomy. It addresses the model-based Fault Detection, Identifica-
tion and Recovery (FDIR) challenges for Guidance and Control. The
ADDSAFE FP7 European project (addsafe.deimos-space.com/), where
 P. Goupil / Control Engineering Practice 19 (2011) 524–539
Airbus is a key partner, will address the fault detection and diagnosis
challenges arising from ‘filling the gap’ between the scientific
methods proposed by the academic and research communities and
the technological solutions demanded by the aircraft industry to
satisfy the newer societal imperatives for environmentally-friendlier
air transport. In all these projects, the collaborative work done with
academic world is a good chance for an industrial to study the
capabilities and viability of novel FTC and FDI techniques applied to a
realistic, nonlinear design problem and to assess their contribution to
the aircraft global optimization.
References
Alcorta-Garcı́a, E., A. Zolghadri, & P. Goupil (2009). A novel non-linear observer-
based approach to oscillatory failure detection. In Proceedings of the european
control conference, Budapest, 23–26th August 2009.
Alcorta-Garcı́a, E., A. Zolghadri, P. Goupil, L. Lavigne, & P. Simon (2009). Nonlinear
observer-based OFC detection for A380 aircraft. In Proceedings of safepro-
cess’09, Barcelona, 30th June–3rd July, 2009.
ARP 4754/ED79, 1996. Certification considerations for highly-integrated or complex
systems, published by SAE, no. ARP4754, and EUROCAE, no. ED79.
Besch, H. M., H. G. Giesseler, & J. Schuller (1996). Impact of electronic flight control
system (efcs) failure cases on structural design loads. AGARD Report 815, Loads
and Requirements for Military Aircraft.
Brie re, B., Favre, C., & Traverse, P. (1995). A family of fault-tolerant systems :
Electrical flight controls, from A320/330/340 to future military transport
aircraft. Micoprocessors and Microsystems, 19, 2.
Chen, J., & Patton, R. J. (1999). Robust model-based fault diagnosis for dynamic
systems. Kluwer Academic Publishers.
DO178B/ED12, 1992. Software considerations in airborne systems and equipment
certification, published by ARINC, no. DO178B, and EUROCAE, no. ED12.
DO254/ED80, 2000. Design assurance guidance for airborne electronic hardware,
published by ARINC, no. DO254, and EUROCAE, no. ED80.
FAR/CS 25, Airworthiness standards: Transport category airplane, published by FAA,
title 14, part 25, and Certification Specifications for Large Aeroplanes, pub-
lished by EASA, CS-25.
539
Favre, C. (1994). Fly-by-wire for commercial aircraft: The airbus experience.
International Journal of Control, 59(1), 139–157.
Frank, P. M. (1990). Fault diagnosis in dynamic systems using analytical and
knowledge-based redundancy: A survey and some new results. Automatica,
26(3), 459–474.
Goupil, P. (2006). AIRBUS overview of fault tolerant control. GARTEUR Action Group
FM-AG(16) Mid-Term Workshop, 4–5 April, Toulouse.
Goupil, P. (2010). Oscillatory failure case detection in the A380 electrical flight
control system by analytical redundancy. Control Engineering Practice, 18(9),
1110–1119.
Isermann, R. (2005). Model based fault detection—Status and applications. Annual
Review in Control, 29, 71–85.
Isermann, R. (2006). Fault diagnosis systems. Berlin: Springer-Verlag.
Lavigne, L., A. Zolghadri, P. Goupil, & P. Simon, 2008. Robust and early detection of
oscillatory failure case for new generation airbus aircraft. AIAA-2008-7139, AIAA
Guidance, Navigation and Control Conference.
Moseler, O., T. Heller & R. Isermann 1999. Model-based fault detection for an
actuator driven by a brushless DC motor. In Proceedings of the 14th IFAC-World
Congress, Beijing, China.
Patton, R. J. (1995). Robustness in model-based fault diagnosis: The 1995 situation.
Annual Reviews in Control, 21, 101–121. doi:10.1016/S1367-5788(97)00020-5.
Patton, R. J. (1991). Fault detection and diagnosis in aerospace systems using
analytical redundancy. IEE Computing & Control Engineering Journal, 2(3),
127–136.
Patton, R. J., Frank, P. M., & Clark, R. N. (2000). Issues in fault diagnosis for dynamic
systems. Springer.
Rosenberg, K., 1998. FCS architecture definition (issue 1), Deliverable 3.4, BE97–
4098 ADFCS.
Traverse, P., I. Lacaze & J. Souyris (2004). Airbus fly-by-wire: A total approach
to dependability. In Proceedings of the 18th IFIP World Computer Congress
(pp. 191–212), Toulouse, France.
Van den Bossche, D., 2006. The A380 flight control electrohydrostatic actuators,
achievements and lessons learnt. In Proceedings of the 25th Congress of the
International Council of the Aeronautical Sciences, Hamburg, Germany.
Yeh, Y. C. (1996). Triple-triple redundant 777 primary flight computers. In
Proceedings of the IEEE Aerospace Applications Conference (pp. 293–307), Aspen,
CO, USA, 3rd–10th February 1996.
Zolghadri, A., C. Goetz, B. Bergeon, & X. Denoise (1998). Integrity monitoring of
flight parameters using analytical redundancy. In Proceedings of the UKACC
International Conference on Control (CONTROL ’98) (pp. 1534–1539), Swansea,
UK.