Anda di halaman 1dari 27

f4~

~,

140

CO
O"

0-

O"

O"
CO
~r
O4
O"

O"
.
O"
O~
O"

rr"

'

O"

O4

2"~

o-

~r

~r

"~

r,

~-

.,5

Automatic flight control system design considerations

.=_

171

172

Flightcontrolsystems

projects. At the end of this phase a contract is awarded to the successful


candidate for the design and development of the AFCS and the supply of the
e q u i p m e n t to support the programme

5.1.2 Interface definition


The selection of a vendor for the AFCS will probably take place slightly ahead
of, or in parallel with, the selection of other suppliers for the supporting
sensor equipment. Once contractual arrangements are established with all of
the other vendors, a full definition of the AFCS interfaces may be
commenced. This task is critical if system design pitfalls are not to be
e n c o u n t e r e d downstream, requiring considerable attention to both the
sensor characteristics and electrical interfaces to ensure that the AFCS
receives and transmits acceptable operating data.

5.1.3 System definition


At the same time as the interfaces are being developed, system-definition
documentation will be compiled, including the partitioning of the AFCS
functional requirements and resulting in the high-level architecture. The
system design considerations will be addressed during this phase of the
programme which is the foundation for the successful implementation of the
AFCS. The control laws will also be developed now.

5.1.4 Software design and code


Following the interface, systems and control law definition, the software
which provides the AFCS implementation is partitioned within the hardware
architecture and segregated into higher and lower integrity software tasks, as
appropriate. A major consideration is that there is a consistent theme within
the AFCS development concerning the verification and validation of the
operational design. This will be addressed in more detail later in the
Chapter.

5.1.5 Hardware design and development


The AFCS will be partitioned into a n u m b e r of line-replaceable units (LRU)
which will perform the interface, control and actuator drive as c o m m a n d e d
by the e m b e d d e d operational flight programme (OFP). Each LRU comprises
a n u m b e r of modules such as input/output, central processor unit, power
supply and conditioning units etc. The hardware design and development
task addresses all of these modules with the aim of providing the prototype
units upon which the software-based control laws will be ultimately tested.

5.1.6 System integration and test


The hardware and software are integrated together incorporating progressively more and more functionality until the whole system is tested in a

Automaticflight controlsystemdesign considerations

173

specially designed system rig. This provides a closed-loop environment which


enables the system design team to simulate the aircraft dynamics and control
them using the AFCS.

5.1.7 Qualification testing


Qualification testing is used to determine the flightworthiness of the LRUs
which comprise the AFCS. A n u m b e r of tests are undertaken, such as
vibration, temperature/altitude variation, humidity, electromagnetic interference, crash/shock testing, contamination and fungus-resistance growths,
plus others d e p e n d e n t on the application. This testing uses selected units
identical to the type which will ultimately fly and is c o n c e r n e d with proving
that the performance of the hardware will not degrade when in a typical
aircraft environment.

5.1.8 Preliminary (final) declaration of design and performance


(PDDP/FDDP)
T h e PDDP and FDDP are documents which.draw together the documentation
for the LRUs and the system in order to make a declaration of the testing
which has been undertaken, together with the associated results which prove
that the e q u i p m e n t is flightworthy. The PDDP contains a subset of the testing
and is used to allow flight testing to commence in parallel with longer
duration testing or verification exercises which are d o c u m e n t e d in the
FDDP.

5. I. 9. Flight testing
The aircraft manufacturer will perform a series of tests to prove the
airworthiness of the airframe and the AFCS. There will be a parallel exercise
undertaken by the AFCS vendor to implement modifications or rectifications
during this activity, if needed.

5.1.10 Certification
T h e data that has been compiled and d o c u m e n t e d during all phases of the
AFCS project will be presented to the appropriate airworthiness authorities,
which certify that the AFCS/aircraft is fit for flight operations when they are
satisfied that the design pedigree is acceptable.

5.1.11 Design reviews


Reviews will occur at various stages of the development programme to ensure
that one phase of design is completed and the next phase can be commenced,
see Figure 5.2. Generally, the AFCS customer will request a minimum o f two
contractual reviews namely, the preliminary design review (PDR) and the
critical design review (CDR) which address the design concept and design

174

Flight control systems


system and
sonware
specification

Arcs
integration
and test

systems
review

rereleasedesign
view

flight-control
computer level
integration test

software
requirements

software
req.uirements
review

prerelease design
review

I s9ftware-design

microprocessor
level
integration test

ogcumentation
microprocessor
level

pre!iminary design \
review
\

prerelease design
review
software task
level
integration test

ScrOocftWare-design
umentation
task level

prerelease design
review

crit!calrevlew
design
software
module
specification

software
module
test
prerelease design
review

revlewPrerelease
design
software
module
code

Figure 5.2

The V diagram of requirements' decomposition and testing composition


with associated design reviews

detail, respectively. These are shown at salient points on the development


programme.
5.2 R e q u i r e m e n t s definition a n d verification
5.2.1 Introduction
There are two primary considerations that must be satisfied by the AFCS
design team which are:
that the equipment fulfils the requirements specified by the customer/

Automatic flight control system design considerations 175


airframe supplier n e e d e d for a product which is fit for purpose;
that the e q u i p m e n t is certified as safe to fly.
Both of these considerations result in the design team adopting a n u m b e r of
measures in order that they may be satisfied. Broadly speaking, these
measures fall into one (or both) of two groups:
overall design methodology and testing;
specific design considerations to implement necessary safety features or
satisfy specific requirements.
This section will address the overall design methodology and testing
philosophy used in a typical AFCS development. The next section will look at
the specific design considerations made on an AFCS development.

5. 2.2 Design and test methodology


Each AFCS is different, tailored to the airframe which it will control and the
overall mission of the aircraft. The complexity of the AFCS is to a great extent
d e t e r m i n e d by the a m o u n t of systems, software or hardware functionality
which is included to provide the necessary redundancy within the system in
order to satisfy the safety and availability considerations. The development
methodology is c o m m o n for all types of AFCS, it is merely the a m o u n t of
design, testing and documentation activity which varies in order to fully satisfy
the verification criteria used to sign off the system.
Figure 5.2 presents the V diagram which is used as the basis for the
development of many aerospace products. It operates on the simple principle
o f progressive breakdown of the functional requirements during the design
phase followed by progressive build up of the testing of these requirements
during the proving phase. Design reviews are held at the transitions between
levels on the diagram. The left side of the V follows design decomposition, the
bottom of the V is the implementation of the software code and the righthand side the progressive build up of testing. The diagram is equally valid for
the development and testing of hardware. This is achieved by equating the
software module to an element of an electrical circuit card design which
would be progressively tested at higher and higher levels of functionality.
T h e r e are two key items that must be addressed within this methodology
and these are:
traceability;
configuration control.

5.2. 2.1 Traceability


It is o f p a r a m o u n t importance that a high-level requirement can be traced
down through the design to the lower-level requirements which evolve during
the functional decomposition, and then back through the various levels of
testing to prove that it has been fully satisfied. One way of ensuring that

176

Flightcontrol systems

traceability is satisfied is to compile a large matrix. This takes all of the


references of the requirements in the higher-level specification together with
those derived in the lower levels of documentation so that the paths of design
and testing can be followed.
This is completed when all the design and test activity is finished and used
to aid the flightworthiness sign off. Figure 5.3 illustrates the design and
verification process which includes the production of the traceability
matrices, the software-accomplishment summary and culminates in the issue
o f the final DDE

5.2.2.2 Configuration control


All of the design documentation, software and hardware building blocks of
the AFCS need to be retained u n d e r configuration control. This is to ensure
that correct and compatible software and hardware build standards which are
fully tested are used for flight.
In the event of any anomaly requiring further investigation, the AFCS
configuration could be replicated and subjected to the appropriate level of
testing.
During the development phase, the primary purpose of configuration
control is to ensure that formally controlled design changes are implemented
into the system and that all associated documentation and testing completed
before the change is signed off.

5.2.3 Safety considerations


Safety during flight is the primary consideration that must be achieved within
an AFCS design. The next section will address methods by which the AFCS is
made more robust and available to the pilot in the event of failure. This
section is c o n c e r n e d with the use of hazard assessments and failure-modeeffect criticality analysis in order to assess the severity and likelihood of a
failure.
The AFCS design team will identify the hazards at a systems level which may
occur as a result of a failure of some part of the AFCS. These are then
categorised d e p e n d e n t on the severity and investigated using a detailed
failure-mode-effect criticality analysis (FMECA). The FMECA traces the
causes of the possible failures through the system and the individual LRUs
using fault-tree analysis. The probable rate of occurrence of the identified
high-level failures is derived from the arithmetic combination of the failure
rates of the components which make up the overall circuit or part of the
system. The data is derived from data handbooks and the failure rates must be
aligned with the categorisation of the hazards to ensure that the rate of
occurrence is commensurate with the achievement of safety of flight over the
life of the aircraft. If this is not satisfied, further design analysis is required to
investigate the failure which may result in a systems modification.

Automatic flight control system design considerations

~
~

._o

177

=~

u_

g.~ 8 ~

,o~1,

,o I~.oo~I~ I I~o. o o

~.~, ,,~i~.=_o~.i~
I I~..~o~I-~,'5"o

~r~I

I ~.~1

.- -- --

L__J

',

"9 ,~-~ ~

.~E~EI.~

.~
~

'

~"o

mo

,-=,
15

"1 ~ R

I f
nO

~h
E

178

Flightcontrol systems

5.3 System design considerations


Figure 5.4 illustrates the design considerations that flow from the overall
consideration which is to achieve automatic flight control. The list of
considerations may not be exhaustive and probably could be grouped or
segregated u n d e r different headings. However, the reader can gain a basic
understanding of how the considerations grow and become i n t e r d e p e n d e n t
as the design is decomposed.
The interdependency between levels is emphasised by the databus notation
rather than connecting individual boxes which would have resulted in a
confusing diagram.

5.3.1 Primary considerations


T h e primary considerations from which others are derived as a consequence
are listed below:

aircraft dynamics;
safety;
h u m a n interface;
performance;
environment;
physical constraints;
logistics support;
cost.

T h e effect of each of these is discussed below.

5.3.1.1 Aircraft dynamics


The resultant considerations influence the design of the flight control
computer in the areas of processing power, the speed and authority of
actuators and the speed of execution of control laws and the associated
actuator drives. The aircraft dynamics have a direct impact on the stability,
determining whether the pilot can fly the aircraft without the AFCS engaged.
Highly agile fighter aircraft, such as Eurofighter, are designed to be unstable
without the influence of the AFCS in order to achieve the manoeuvrability
that is required. In this case a loss of the AFCS function has a catastrophic
effect.

5.3.1.2 Safety
T h e AFCS design is greatly influenced by the results of the hazard assessment.
This may r e c o m m e n d levels of redundancy and dissimilarity in either the
system or sensor elements to eliminate common-mode failures. Additionally,
the control laws may be segregated on an axis-by-axis basis across processor
modules or flight control computer units necessitating mode logic and voting
strategies to effect a change or a system reconfiguration. This has the

II~_ll~l~

._(2

8 i ~~
E

.~i
EN

~o

"-'-

>

]r lr 1i lJ

Automatic flight control system design considerations

-~ iNIl~ll'~

m.~

~~ ~

.-

fl flflfl
fl
_I..EE ]1 If E If lr ]..[ lflZlf
-

~'~~i
o'~
N~

--

""o

w ~

~r

~i_

.~

,1,

"5

3- ~ ~ 57
--I-Fl-r- ]E tf tf ~f ?ill- . . . . . . . . . . . . .
~
~

179

.B

180

Flight control systems

Amp_TEST

error.log

7 N= 2-9

tS= coz

ROLL

Figure 5.5 AFCS pilots' control unit


undesirable effect of making the system m o r e sophisticated, complex and
costly which must be traded off against the increase in fault tolerance.

5.3.1.3 H u m a n interface
T h e h u m a n interface to the AFCS is one of the areas that receives severe
scrutiny. T h e r e is the need to minimise the workload of the pilot, maximise
the information which he receives and ensure that he can take simple,
p r o m p t action in the event of fault conditions being enunciated.
T h e display of events, the pilot aircraft interface, the position and
configuration of AFCS control units b e c o m e major design considerations.
T h e repeatability of the system behaviour and outputs is i m p o r t a n t to the
pilot who may have to react quickly to certain warnings in order to avoid a
hazardous situation. Figure 5.5 shows the AFCS pilot control unit (PCU) in
use with the EH101 helicopter.
T h e PCU has a n u m b e r of design features which have been included to

Automatic flight control system design considerations 181


assist the pilot and minimise the workload. The autostabiliser channels are
engaged by depressing the engage button at the top of the unit. To the left of
this is the test button to actuate built-in test and the couple button to display
the flight-director bars on the electronic instrument system. A display of
actuator positions is provided in the top right-hand corner of the unit which
is selectable by using the knob u n d e r n e a t h to choose the axis of interest. The
eight buttons to the left of the actuator position display can be used to
individually engage/disengage actuators in the appropriate areas of the
autostabiliser. Below these buttons is the means of activating the autopilot
functions of:
*

B A R - - b a r o m e t r i c altitude hold;
RAD--radar-altitude hold;
VS--vertical speed hold;
IAS--indicated air speed hold;
H D G - - h e a d i n g hold;
NAV--Steering from an external navigation computer;
APPR, BC, G A - - s e l e c t i o n of an approach, back course or go around at an
airport.

Displays of selected targets for hover height, radar height and airspeed are
provided, with each target being adjusted using a dedicated knob. Each knob
is designed to provide a different tactile feedback to the pilot to avoid errors
when wearing gloves. Finally, the bottom face of the unit has space allocated
for selecting some of the modes specific to the military version of the EH101
which are automatic transition up and down (TDN, TUP) to target altitudes
or speeds and hover modes.
The switches light up to provide the pilot with information on the
appropriate action to take. The displays are colour-coded amber to provide a
warning and green to confirm correct operation.
The equivalent PCU for a fixed-wing aircraft would not include the actuator
position display, have four axes or the hover modes. The principle of
operation using buttons to actuate modes and knobs to select targets would
be very similar.

5.3.1.4 Performance
The performance of the AFCS in achieving the required stability or autopilot
operations is specified by the airframe manufacturer as a result of analysing
the overall mission requirements. The AFCS performance is a function of the
airframe dynamics, the equipment architecture, sensor configuration and the
actuation of the control surfaces.
The choice of sensor plays a major role in achieving the performance
criteria which can require particular accuracies to be achieved in certain
manoeuvres. Signal content/accuracy, noise suppression and latency are all
items that the AFCS designer must consider. The choice of sensor for any

182

Flightcontrolsystems

particular application is often best achieved by a combined approach between


the airframe manufacturer and AFCS designer.

5.3.1.5 Environment~physical constraints


The physical constraints on the size, weight, power consumption of the
equipment, coupled with the specification for the operating environment,
can influence the architecture almost as much as the aircraft dynamics and
safety aspects. In helicopter applications, where weight and space are at a
premium, it is highly improbable that a quadruplex/triplex architecture will
be installed.
The AFCS could be duplex or simplex and may have multiple processing
paths with monitoring to achieve the necessary safety standard. If the
equipment needs to operate in a high-vibration, high-temperature installation
with the possibility of air contaminated with sand, salt or sea water, then the
design must accommodate this while still ensuring maximum reliability.
Key considerations in this case include the mechanical design, the
component technology to be used, the segregation of electronically clean
areas from dirty areas to minimise electromagnetic interference and the
method of cooling.
The packaging of the modules required to ensure adequate redundancy
within a flight control computer without contravening weight, size and power
consumption and ensuring adequate cooling is a particularly demanding
design compromise to achieve.

5.3.1.6 Logistic support


The support of any avionics equipment when it is operating on a fleet of
aircraft is a major consideration for all suppliers. The concepts of reliability,
maintainability, testability and manufacturability all have to be addressed as
part of the AFCS design.
Reliability figures are usually included as part of the AFCS performance
specification in terms of maximum number of failures per thousands of
operating or flight hours. The hardware design must therefore use
components which support the required reliability figures. Maintainability
must be relatively simple and easy to accomplish by a trained operator. The
end user of the aircraft will specify the requirements which may vary from
returning the AFCS units to the supplier for repair or using internal
maintenance staff to perform levels of repair before this stage is reached.
Testability is the concept of being able to diagnose the existence of faults by
external or internal testing of the equipment. It is generally specified in terms
of percentage coverage of the equipment. The AFCS hardware and software
design team will be tasked with the development of external special-to-type
test equipment, module test equipment and built-in test software to be
executed in the AFCS units. A testability analysis will be performed to confirm
the satisfaction of the specification requirements.

Automatic flight control system design considerations 183


160

/
120

/
/

O
O

"~ 8O

/
/

e-.

40

design

code

integration

rig test

flight test

certification

phase in which change is implemented

Figure 5.6 The rising cost of design changes with project phase
Manufacturability refers to the capability to make a particular design under
the conditions of high-volume factory production techniques. The transition
from hand-built prototype modules by the design engineer to automatically
assembled production modules by a skilled operator requires multidisciplined teamwork. This must address the technology which is being used, the
manufacturing techniques which will be applied, the availability of general
purpose factory test equipment, component obsolescence, applicationspecific integrated circuits and supplier management. Before the equipment
is delivered, it is normally subjected to vibration and temperature cycling in
an environmental chamber to burn-in the components to detect infant
mortality. The automatic testing and control of this procedure will be one of
the considerations of the hardware design team.

5.3.1.7 Cost
Cost is always a major consideration in all aspects of our daily life.
In an AFCS design where safety of flight is of paramount importance, the
most cost-effective solutions must be applied to ensure that fitness for
purpose is achieved. Figure 5.6 illustrates the effect on the cost of
implementing a design change at different phases of the AFCS design and
development. Clearly a logical well-controlled design phase geared to a rightfirst-time philosophy will minimise the number of late changes and the
associated additional cost. The more sophisticated the AFCS design, the more
important it is to design the test methodology at an early point in the

184

Flightcontrolsystems

programme so that omissions can be detected and manual testing minimised.


Anything that is planned to be included in an AFCS to enhance safety
which cannot be easily tested and fully verified is itself a potential cause for
concern. The AFCS must provide a compromise between achieving all o f the
performance and safety requirements and operating so actively that it is in
danger of wearing out the actuators in response to small perturbations. In this
respect, the actuator lifecycle cost driver must be traded off against the
bandwidth of the overall AFCS.

5.4 AFCS architecture

5. 4.1 Introduction
The AFCS provides inner-loop stabilisation as shown in Figure 5.7 by
undertaking the signal processing necessary to convert the data received from
attitude sensors, autopilot mode selections and manual pilot inputs to
actuator drive commands. These, in turn, act upon the mechanical interface
between the actuator and the control surface to counter any perturbations.

5. 4.2 AFCS flying control interfaces


An example of the AFCS and the flying-controls interface for a helicopter is
presented in Figure 5.8. It is notable that the AFCS directly drives the shortterm high-dynamic actuators which are in series with the power controls,
together with long-term trim actuators. These act in parallel to the short-term
actuators and adjust the trim datum so that the high-dynamic actuators can
compensate perturbations about the new baseline. This diagram illustrates
the mixing of the axis controls which are necessary for the correct operations
of a helicopter. The arrangements of similar interfaces on fixed-wing or
highly agile jet aircraft is d e p e n d e n t on the inherent stability of the airframe
and the operating requirements for the vehicle.

5.4.3 AFCS system interfaces


Figure 5.9 provides a typical AFCS interface with the sensors and other
systems on the aircraft. The n u m b e r of sensors, the complexity and m o d e of
operation may be different from aircraft, but all AFCS will have similar
interfaces. The motion and navigation sensors will provide attitudes,
acceleration and rates for stabilisation purposes. The air data computer or
transducers will provide altitudes and airspeed for control law gain scheduling
and autopilot control laws.
The radar altitude is used in precision low-level mission control such as
hover in a helicopter. The landing-system and navigation-aid data will support

Automatic flight control system design considerations

ii

o)
t.-

o
o

oO

.~_
eiJ

,!

m
m
m
m
m

"o
..
-

o o

r.-~

"o

"~o~

Q.

T t
woe-

01

i
i

185

186

Flight control systems

Jo}oJ u!~w

"8

8u!x!w ,~Jew!Jd

Ou!x!w ,~Jepuooas

~7o ~

09
(,9
LL
,

LL

U-

0
<

.~

i
o

-,

(/)
~)

Ii

0
0

"--'~
0
0

U_

Automatic flight control system design considerations 187

.~_E ~ E

e-

~EE

188

Flightcontrolsystems

autopilot modes associated with the terminal and enroute sections of a flight
plan. Electrical power is necessary to drive the pilot's interface unit and flight
control computers. The input from the central dimming system is used to dim
the blacklight legends on keys on the pilot's interface/control unit at night.
Two-way interfaces are maintained with a n u m b e r of other systems such as
a flight or aircraft m a n a g e m e n t system which can c o m m a n d the AFCS to fly
p r e d e t e r m i n e d routes or manoeuvres. The aircraft displays will receive output
data from the AFCS to display warnings, flight-direction information and
other system datums. The AFCS will automatically respond to requests from
the display controllers to modify the content of the output data.
T h e r e are interfaces with the aircraft controls, the trim system and the drive
actuators. There is also a safety-critical interface with a hard-wired central
warning system which will light attention getters should the AFCS detect and
enunciate a failure. Generally, the pilot must acknowledge warnings before
they are cancelled and the fault condition acted upon, or a subsequent
warning may be generated.

5.4.4. AFCS configurations


T h e system configuration for the AFCS installed on the GKN Westlands
Merlin EH101 helicopter, supplied by Smiths Industries Aerospace, is shown
in Figure 5.10. This system comprises five line-replaceable units, namely, a
pilot's control unit, two flight control computers, a dynamic sensor unit used
to increase the availability of attitude data and a hover-trim controller for the
military variants of this helicopter.
Figure 5.11 illustrates how the level of redundancy can be increased in an
AFCS by using progressively more flight control computers. After the first
miscomparisons between two flight control computers in a duplex configuration, the system must either shut down or the pilot arbitrate. In the EH101
configurations there are dual computing paths in each of the FCCs using
dissimilar microprocessors. This significantly increases the level of redundancy and makes the system tolerant of two failures, see Section 5.4.5.8.
Clearly, a triplex or quadruplex AFCS will have significantly more
redundancy than a simplex or duplex configuration, but there are trade-offs
which must be considered. A quadruplex/triplex configuration requires
more LRUs, space inside the aircraft, more power, more complex testing and
is significantly more expensive. The voting strategies with the synchronisation
required across the system is a significant overhead. A highly r e d u n d a n t
system is extremely fault tolerant which means that the testing required to
release the equipment back on to the aircraft following repair must be
exhaustive and require special equipment. The simplex AFCS is easy to repair
and generally tends to be the older analogue design. It is used on airframes
where the pilot can fly home, or land, following a failure without a major
concern.

Automaticflight controlsystemdesign considerations 189


power 1
aircraft management
computer & electronic
flight instruments 1

inputs from
aircraft sensors.
and discretes
flight- ~
control
computer
#1
~1
~

HTC test
power 1

[ ]DSU tes

se
uni,or I I 'FC(:te' ~ l l l l
(DSU)
dat~
bus

hover trim
control
unit
(military)

'

~ ~P] series actuator


n I- lane 1 demand
YJ~.~signals
v l_ parallel actuator
}, R.~demand signals

L
~-[
I~
actuatorParallel"
pilots
reversion
control
,
unit

(-

power
1

~_ po~ter

I [

[ _

power 1

},

flightcontrol
con~P2uter

-~ Y] parallel actuator
~, CJ- demand signals
lit

inputs from [ ~
aircraft sensors-~
and discretes /

ttt

series
lane 2 actuator
demand
signals
aircraft management
computer & electronic
flight instruments 2

power 2

Figure 5.10 EHI01AFCS configuration


5.4.5 Flight control computer data processing
The major activity of the A r c s is to process data from sensors and derive
actuator commands. The intelligence for the system is contained within the
flight control computer and is achieved through a combination of hardware
and software. Figure 5.12 provides a schematic of the FCC in terms of the
software activities, and will be used to discuss the basic functions surrounding
the A r c s control laws.

5.4.5.1 Start-up processing


When power is applied to the Arcs, each LRU must determine whether or
not it is undertaking a cold start or has suffered a short power interruption.

Flight control systems

190

lane 1

,,

lane 1

simplex
lane 1

lane2

l-I-

lane2

I--"-I
I m I .system
I ~ I -shutdown
A

duplex

lane
voter --,,- shutdown

lane3
triplex

b
I

lane 1

lane 2

lane 3

lane
voter -,-- shutdown

lane 4

Figure 5. I 1 AFCS architectures to increase the level of redundancy


a Simplex, Duplex, Triplex
b Quadruplex

In the event of a cold start, as d e t e r m i n e d from discretes 1 provided by the


power supplies, the FCC will proceed through a start-up routine initialising
data areas and will enter a built-in test task which is used to d e t e r m i n e the
validity of the overall computer.

5.4.5.2 Power-interrupt processing


In the event of a short-term power interrupt of less than 50 milliseconds, for
example, this software will restore data from m e m o r y and continue
processing from the last recorded point. The detection of the power failing by
certain discretes provided by the power supplies will be flagged to the failureanalysis modules.
1A discrete involvesthe setting of a flag which is dependent on the relevant voltage transient.

Automatic flight control system design considerations

,. E

o-

~-~

-~~

191

E1 ~-

~~

3.._~

"=R,~E

~E
~,)(E

~o

eE

e-'~

o.
o

O4
E

192

Flightcontrolsystems

5.4.5.3 Built-in test


The FCC will contain built-in test (BIT) software and hardware circuitry. This
will be used to test out the validity of each of the subsystems within the FCC
so that faults may be flagged.
Generally, BIT will be segregated into the following areas:
power-up BIT;

run-time BIT;
requested BIT.
Power-up BIT will operate after a cold start and check out basic circuitry of
the FCC.
Run-time BIT will operate continuously while the unit is running using
spare capacity in the processing cycle when other tasks are not scheduled by
the operating system. The results of run-time BIT will be used to reconfigure
the system or provide warnings in the event of a fault being detected.
Requested BIT is a long-term activity taking up to five minutes to complete
and will be used by the maintenance groundcrew. It will be inhibited in the air
and will perform exhaustive wrap-around testing of the modules within the
FCC, exercise the processor units, check the memory-protection facilities,
check out the actuator drives and finally output a data log for the
groundcrew.

5.4.5.4 Failure analysis


Failure analysis uses the results derived from BIT, power-interrupt processing
and sensor management to determine failure situations. These may cause the
disengagement of actuators and warnings to be displayed to the pilot.

5.4.5.5 Sensor management


The sensor m a n a g e m e n t p e r f o r m e d by an FCC typically has to determine the
validity of the data source and then condition or mix the data with similar
signals from other sources.
The key design considerations in sensor management are:

sampling frequency;
latency of data;
rapid determination of the failure of a sensor;
mixing of data to avoid transient effects.

These are addressed below.

Sampling frequency
As the FCC will operate using a discrete frame time of a set n u m b e r o f
milliseconds and the majority of m o d e r n aircraft operate using digital sensor
outputs, it is important that the data sampled does not become aliased. This

Automatic flight control system design considerations 193


is achieved by a correct choice of sampling frequency coupled by anti-aliasing
or noise-suppression filters.
It is possible to have contamination of the aircraft accelerations, rates and
altitudes by structural vibration which may be caused by interaction with a
helicopter main or tail rotor. In this case, filters are employed to minimise this
noise and will be tuned to match the vibration source, i.e. the rotor
frequencies.

Data latency
Latency in data must be minimised to avoid excessive phase lag within both
the sensor and the FCC. The AFCS designer may choose to use applicationspecific integrated circuits in the FCC to rapidly sample and decode data used
within the autostabiliser control laws. The AFCS designer will need to work
closely with the airframe manufacturer and sensor supplier to ensure that
latency is minimised within the dynamic sensors on the aircraft.

Determination of sensor failures


Each FCC will receive digital data which usually includes some status bits set
to indicate the failure status as d e t e r m i n e d by the BIT software within the
sensor. This is used to exclude the data from this sensor when a fault
condition is displayed. Generally, analogue sensors do not provide any
indication of failure, and so the signals need to be mixed and the data
equalised to minimise sudden transients which can then be used to d e t e r m i n e
a voltage condition.

Sensor-data mixing
T h e AFCS will usually have multiple sources of dynamic data and algorithms
are used to mix or condition this data to exclude sudden fault transients.
Typical examples of mixing are averaging the two middle signals from four
sources or selecting the middle signal from three. Sometimes, the difference
of each signal from the consolidated signal is retained and used to correct the
raw data for a limited period after a sensor fault is detected. This reduces the
effect of a sudden fault transient in the data source.

5.4.5.6 Mode logic


Each FCC must d e t e r m i n e the m o d e in which it believes the AFCS is being
asked to operate. All available data is used and includes aircraft switches,
autopilot control-unit button presses, autostabiliser e n g a g e m e n t status, sensor
status and the view of the outside world as seen by other microprocessors or
flight control computers. The general theme followed is one of only allowing
a m o d e to be available if fully supported by the necessary sensors and voted
for by the majority of the microprocessors/flight control computers.
T h e design and development of AFCS m o d e logic is a complex but

194

Flight control systems

10
datum
roll
attitude,
deg
0

attitude
time, secs

0
/rate

roll.

I ua"' I

velocityterm
positiveterm +~

Ii

actuator
position ~ )

attitude ,'<2'_11 ~-"1


attitude
datum

t--I gain }~1


II I

integrator

integral

term

Figure 5.13 Attitude response with position-plus-velocity-plus-integral control

_..]~

J
J
Figure 5.14 Building blocksfor signal blending in control laws
unavoidable task facing the systems engineer. The output of mode logic is
directly visible to the pilot, therefore, it must be logical and repeatable.

5.4.5. 7 Control laws


The control laws are the central feature of the FCC and are simply illustrated
in Figure 5.13 which shows the typical response to a step change in roll

Automatic flight control system design considerations 195


attitude using a proportional-plus-velocity-plus-integral controller. This section will not address the methodology used in AFCS control law design apart
from stressing that simplicity allows easy implementation, testing and
validation.
A n u m b e r of basic building blocks will be implemented in software and
configured together to provide the desired control laws for a particular
application, such as an airspeed hold by controlling the pitch channel by
blending together all sources of available data in that axis. An example of
some of these building blocks is shown in Figure 5.14 with typical i n p u t /
o u t p u t responses.

5. 4.5.8 Actuator drive


The primary objective of the control laws is to c o m m a n d the drive to the
actuation system. This is always in a closed-loop configuration with the
position (or velocity) of the actuator being fed back into the FCC so that the
c o m p u t e d error may be driven to zero.
Figure 5.15 presents a typical actuator drive and monitoring circuit which
combines the output from the control laws in processor 1 and processor 2 to
drive one of the actuators on the aircraft. Data is used from the drive to the
actuator from another FCC to compare the drive signals and isolate a fault
condition which may exist between the two processors. The faulty drive may
then be excluded. A comparison is made between the actuator output and
that predicted by a model of the actuator. In the event of this comparison
failing, the actuator is disengaged. Other similar configurations can be found
with differences which d e p e n d upon the application and the AFCS
architecture.

5.4.5.9 Output routines


The FCC includes software to control the required outputs to other systems in
the aircraft d e p e n d e n t on the selected mode.

Smiths Industries plc, 2000. Published with permission of the


copyright owner.

196

Flight control systems


.ff

~_E
O~

f
Q

o
e~

ECI.
I1) E