FUNCTIONAL HAZARD ANALYSIS FOR HIGHLY INTEGRATED AEROSPACE SYSTEMS

P J Wilkinson1, T P Kelly2

1 2
Performance and Control Systems Department Rolls-Royce Systems and Software Engineering
Rolls-Royce Commercial Aero Engines Ltd. University Technology Centre
P O Box 31 Department of Computer Science
Derby DE24 8BJ University of York
Heslington
York YO1 5DD
Tel: (01332) 247935 Tel: (01904) 434728
Fax: (01332) 244225 Fax: (01904) 432708
E-mail: phil.p.j.wilkinson@rolls-royce.btx400.co.uk E-mail: tim.kelly@cs.york.ac.uk

1. Introduction
Evidence of comprehensive hazard identification is a crucial component of any aerospace certification
argument. Historically, in the early stages of the aerospace safety assessment process, hazard identification
has been performed through use of hazard checklists – derived from lists of previously identified or
experienced hazards. The arguments used in support of this approach are predominantly based upon the
amount of accumulated experience (i.e. to a large extent we know how aerospace systems fail) and the
stability of the underlying domain (i.e. aerospace systems don’t change a great deal from instance to
instance). However, this is a reactive rather than pro-active approach to identifying hazards. Also, when
looking at complex and highly integrated subsystems of an aircraft (such as a single engine controller), the
lower-level hazardous failure modes are less well understood and not as stable. Completeness of the hazard
identification process for such subsystems is therefore a concern.
Functional Hazard Assessment (FHA) is being increasingly recommended (e.g. by the Aerospace
Recommended Practice - ARP 4754 [SAE94]) as a means of performing hazard identification. However,
many of the available example applications of this approach (including that given in ARP 4761 [SAE95]) are
illustrated either for aircraft-level functions or sub-system functions with obvious and visible functional
effects. Our experience is that it can be difficult to apply FHA for lower level aircraft systems (specifically at
the level of the engine controller) where, due to the level of complexity and integration with other systems,
the overall effects of functional failure are far from obvious. In this paper, we describe the problems we have
encountered when applying FHA and the (partial) solutions we have proposed in order to overcome these
problems.
2. Principles of FHA
Functional Hazard Assessment in defined as one of the preliminary activities in the safety assessment process
outlined by ARP4754 [SAE94] (shown in Figure 1). FHA is first carried out for the whole aircraft – working
from a description of aircraft functions. Then, following allocation of functions to aircraft systems, FHA is
performed again for each subsystem.
 Aircraft Level Aircraft Level
Aircraft
FHA Functions
Requirements
6.1
Functional Interactions Failure Condition, Effects,
Classification, Safety Objectives
Allocation of
System Level System
Aircraft Functions
Failure
FHA Sections Functions to Systems
Conditions
& Effects Failure Condition, Effects,
Classification, Safety Objectives

Development
Architectural
of System
PSSAs Requirements Architecture
Separation
6.2 System
CCAs Requirement
Architecture
6.4
Allocation of
Item Req.,
Safety Objectives,
Requirements to
Analyses Required Item Requirements Hardware &
Software

SSAs System
6.3
Implementation
Separation Implementation
Verification
Results
Physical System

Certification

Safety Assessment Process System Development Process

Figure 1 - ARP4754 Safety Assessment Process Model

FHA is a predictive technique that attempts to explore the effects of functional failures of parts of a system.
The primary aim of conducting a FHA is to identify hazardous function failure conditions.
The underlying method of FHA is relatively straightforward:
• From a suitable representation, select functions in turn
• Define purpose and behaviour of function
• Consider hypothetical failure modes, e.g. ‘Loss of function’, ‘Function provided when not required’,
‘Incorrect operation of function (high, low …)’
• Determine effects
• Determine, record (and justify) associated risk factors (i.e. severity and probability budget)
FHA results are usually recorded in a table, such as that shown in Figure 2.

Function Failure Condition Phase Effect Class Verification

Figure 2 – Typical FHA Record Format

3. Problems Experienced when attempting FHA
The principles and method of FHA appear deceptively simple. However, when attempting to apply FHA to
an engine controller, we encountered the following problems:
Defining Functions(!)
We found it hard to identify functions at the right level of abstraction from the available requirements
documentation – particularly, separating functions from implementation detail. Expressing functions at too
abstract a level, we found that we became ‘divorced from reality’ (i.e. the engineering knowledge) about how
the controller operated and therefore that we were unlikely to identify ‘real’ new hazardous failure modes. At
the other extreme, if functions were expressed at too detailed a level we found that the FHA process took too
long, too much information was generated, and that we were turning FHA into a design / bottom-up (e.g.
Failure Modes and Effects Analysis style) activity.
Determining ‘Effect’
For systems such as the controller, that are several layers removed from the system ó environment boundary,
determining the effect of function failure can be difficult. Figure 3 illustrates this problem: In order to work
out the effect of a controller function failure we must be able to determine its effect on the engine, the single
engine effect on the overall aircraft propulsion (i.e. multiple engines), and then the propulsion effect on the
aircraft.

Aircraft

Propulsion

Engine

Controller

Figure 3 - Propagation of 'Effect' Through Sub-system Layers

This problem is glossed-over in the standards by illustrating the technique on subsystems (e.g. wheel brake
systems in ARP4761 [SAE95]) where the effect of failure can, to some extent, be considered obvious. It is
much harder, e.g. for the controller, to determine the effect of failure of the ‘Control IP turbine rotor tip
clearances’ function. In order to understand this failure we clearly require substantial design context and
rationale underlying this function.
Coupling / Integration
At the controller level, the functions are heavily interdependent. FHA works best for independent functions.
There is no support or structure in the technique for addressing functional dependencies. However, we were
aware of critical combinations of functional failures, e.g. loss of fuel temperature control coupled with loss of
communication to airframe.
The controller functions are also heavily dependent on engine / aircraft mode (e.g. Ground Idle | Take-off |
Climb | Cruise | Approach | Landing). Again, there is no explicit support or structure in the technique for
addressing the effect of state on functional failure.
We recognised that to consider all combinations of functions, phases etc. would be prohibitively time
consuming. We therefore needed a way of focussing attention on critical combinations.
4. Our approach to performing FHA
To address the problems described in section 3 and FHA of the engine controller a workable and worthwhile
activity we adopted the following approach:
• Strict avoidance of design terminology in defining functions
• Grouping functions by type to simplify analysis
• Identifying critical function & mode interactions to limit scope of analysis
• Having a function-flow model of consequences to help determine failure effect
Avoidance of Design Terminology
We were strict in eliminating implementation detail (and therefore design terminology) from our description
of engine functions. In this way we found we arrived at the correct level of abstraction for performing the
FHA. For example, defining a function as ‘Control Engine Surge Margin’ rather than ‘Control Engine
Airflow’ – a particular means of controlling the surge margin.
Grouping Functions
In examining the list of controller functions we recognised a number of distinct function types. We grouped
the functions according to these types, as illustrated in Figure 4. For example, some functions continuously
controlled a particular engine parameter; some functions were concerned with particular engine events and
some functions were concerned with communication to the airframe.
Control Thrust Value
Continuous
Control Engine Surge Margin
Control
Control Fuel Temperature within limits
Start Engine
Re-light Engine Event
Shutdown Engine
Annunciate Turbine Overheat to A/C
Annunciate Oil Temp. and Pressure to A/C Comms
Annunciate Engine Thrust

Figure 4 - Grouping of Functions by Type

We then associated different types of failure condition with each failure type, e.g.
• Control:
Value too high, Value too low, Value Early, Value Late
• Event:
Inadvertent initiation, Failure to initiate
• Comms:
False high, False low, Total failure
Using these failure types the FHA process was directed to relevant and applicable concerns, whilst being
abstract enough to possibly identify new ones. The benefits of using these failure types are similar to using
those gained by using guidewords in a HAZOP [MoD96] activity.
Scoping the Assessment
Prior to conducting the FHA, to scope the assessment we have proposed the use of a cross function chart,
such as that shown in Figure 5, to identify particular couplings of interest.
 Functions Modes

Control Event Comms Idle T/off

Control Fuel
Temperature
within limits

Comms

Temperature
Annunciate
Fuel
Functions

Event
Control

Figure 5 - Scoping Interactions of Interest for FHA

As shown in Figure 5 the chart can be used both to describe function-to-function and function-to-mode
couplings that should be addressed. Not all functions interact with other functions and not all modes are
relevant to all functions. Using a chart such as this, we can direct the FHA process to particular ‘hot-spots’ of
interest.
Consequence Loops
In order to determine the effect of a functional failure we found we needed a functional model that shows the
flow of control / consequences, such as that shown in Figure 6.
Flow Measurement

Thrust Fuel
Request Demand Fuel Fuel

Meter Monitor Comb'n

Controller
Fuel Flow Chamber
Pilot
Gas Energy

Power Observable:
Gearbox Turbine Rotation
Supply Speed
Electrical Power
Mechanical Energy Mechanical Energy

Figure 6 - 'Consequence Loop' functional model for Engine Controller

Figure 6 shows how (the flow of control), and through what mechanisms (fuel flow, mechanical energy etc.),
the functional areas of the engine controller interact. It also shows feedback cycles that exists and where the
‘observable’ effects will emerge. Using such a model, for any particular function, we can reason about the
downstream observable and feedback effects of failure.
5. Conclusions
FHA can be hard to apply. More accurately, FHA can be hard to apply well – in a way that means we are not
simply generating reams of meaningless tables, but instead are gaining a better understanding of the effect of
failures and therefore a more complete list of hazardous failure modes.
Identifying and defining functions at the right level of abstraction can be a non-trivial exercise. Care must be
taken when extracting functions from requirements documentation to remove premature implementation
detail.
Existing FHA works best as a technique for functions that are entirely independent. However, when talking
about highly integrated feedback systems, the functions are far from independent. Both function-to-function
and function-mode interactions must be addressed. However, FHA size must be managed. It is necessary to
clearly scope and direct the FHA process.
It can be difficult to determine the end-effect of low-level subsystem functional failures. It is useful to have a
model of the ‘consequence’ chain that clearly identifies how functions interact and their relationship to
effects that are observable at the higher levels of the system.
6. References
[SAE94] ARP4754: Certification Considerations for Highly-Integrated or Complex Aircraft
Systems
SAE Systems Integration Requirements Task Group AS-1C, ASD.
Society of Automotive Engineers, Inc., December 1994
[SAE95] ARP4761: Guidelines and methods for conducting the safety assessment process on civil
airborne systems and equipment
SAE Committee S-18
Society of Automotive Engineers, Inc., August 1995
[MoD96] Interim Defence Standards 00-58 Issue 1: HAZOP Studies on Systems Containing
Programmable Electronics
UK Ministry of Defence, July 1996