THE HAZARDS OF UNMANNED AIR VEHICLE

INTEGRATION INTO UNSEGREGATED AIRSPACE

Andrew R Evans

This report is submitted to satisfy the project requirements of the

Master of Science in Safety Critical Systems Engineering
at the Department of Computer Science

September 2006

Number of words = 43,176, as indicated by the Microsoft Word ‘word count’ tool. The count includes
the title page, preliminaries, report body, and Annex F, but not the Bibliography. Annexes A – E
contain supporting evidence and contextual information for the reader, and have not been included in
the word count.
ABSTRACT
There is strong interest in expanding Unmanned Air Vehicle Systems (UAVS) usage.
Potential military and civil tasks will need them to operate in the same airspace as manned
aircraft and over the general public. While they are currently segregated because of
concerns for safety, what are the real safety risks and can they be addressed?
A broad literature review has highlighted a range of safety-related issues. In particular:
• The root hazards associated with UAVS integration are not well understood.
• Can a EASA CS.23/25.1309 type safety assessment approach be taken, to identify
the hazards and support clearance into unsegregated airspace?
A hazard identification methodology has been developed based on ARP4761 (an accepted
framework for satisfying EASA CS.23/25.1309). Functional Hazard Assessment (FHA)
elements have been modified to be UAVS-applicable, with a UAVS-level assessment,
consideration of the wider system of systems, and techniques to draw out UAVS
peculiarities. The method has been applied to a Tactical UAVS case study to derive a
hazard listing.
The project has concluded that:
• There are a broad range of safety issues to be overcome, to allow UAVS integration
into unsegregated airspace – some relating to the differences of UAVS as ‘disruptive
technology’; others to the manned airspace environment struggling to accommodate UAVS.
• The hazard identification method developed provides a strong supplement to
ARP4761, allowing the combined framework to be used for UAVS safety assessment.
• In the test application, the method identified around 90% of hazards related to
integrating UAVS into unsegregated airspace. This should improve further in a real
application, through peer review, stakeholder involvement, and the use of the follow-on
safety assessment techniques that make up ARP4761.

i
ACKNOWLEDGMENTS
The completion of this project would not have been possible, without the support of many
people.
I would like to thank Peter Moores and JRA Aerospace Ltd, for their support and
sponsorship; and my JRA colleagues Dan Warnes and Mike Shilling for acting as ‘sounding
boards’ (or sounding bored?) of my developing ideas.
I would like to thank my project supervisor, Mark Nicholson, for his guidance, advice and
humour throughout the conduct of the project.
I would like to thank Patrick Mana and Mike Strong (EUROCONTROL) for their advice on Air
Traffic Management approaches to safety and Unmanned Air Vehicles.
I would like to thank the many people of the UAVS industry with whom I had discussions –
too many to mention in full, but a few key personalities being Dr Sue Wolfe (Parc Aberporth),
Andre Clot and Mike Lake (the UAVS Association), and Ingo Massey (Remote Aviation Ltd) –
their unwavering enthusiasm and belief that UAVs will become integrated with manned
airspace was infectious.
Finally, I would like to thank my wife, Caroline, my family and friends for their love, support
and preaf-rooding. Yes, I promise that I won’t do any more educational ‘challenges’. Well, for
a long while, at least.

ii
TABLE OF CONTENTS
Abstract...................................................................................................................................i
Acknowledgments .................................................................................................................. ii
Table of Contents .................................................................................................................. iii
List of Tables..........................................................................................................................v
List of Figures........................................................................................................................ vi
Introduction ........................................................................................................................... 1
PART 1 – Literature Review .................................................................................................. 4
Overview of Unmanned Aerial Vehicle Systems............................................................. 4
Issues Relating to UAV Safety and Access to Integrated Airspace................................. 7
Note on UAV Classification ............................................................................................ 7
1.1 Safety Issues Relating to UAVs as 'Disruptive Technology'.......................................... 8
1.1.1 Impact of the Variety, Roles and Performance of UAVs......................................... 8
1.1.2 The complex system boundary for UAVs............................................................... 9
1.1.3 UAV autonomy - technology, predictability, complexity........................................ 11
1.1.4 Accident rates and reliability - UAV airworthiness................................................ 15
1.2 Safety Issues Relating to the Manned Airspace Environment 'Coming to Terms' with
UAVs ............................................................................................................................... 18
1.2.1 Regulation, Certification and the Drive for Standards .......................................... 18
1.2.2 ATM interaction ................................................................................................... 23
1.2.3 Collision avoidance.............................................................................................. 27
1.2.4 Security and safety .............................................................................................. 30
1.2.5 The Human Element............................................................................................ 31
1.2.6 Public perception of UAV safety .......................................................................... 33
1.3 Summary of UAVS Safety Issues............................................................................... 35
PART 2 - Design and Build: Moving forward in UAVS HazID............................................... 40
2.1 Assessment of ARP4761 Usability for UAVS HazID................................................... 40
2.1.1 Introduction .................................................................................................... 40
2.1.2 Safety Objectives ........................................................................................... 40
2.1.3 'Aircraft Level' and 'System Level' FHA .......................................................... 41
2.1.4 FHA Process:................................................................................................. 41
2.1.5 Overall Applicability of ARP4761 for UAVS use.............................................. 42
2.2 Modifying ARP 4761 FHA for UAVS Use ................................................................... 43
2.2.1 Derivation of Safety Criteria and Objectives for UAVS Application....................... 43
2.2.2 FHA Levels to Address System Complexities ...................................................... 49
2.2.3 Function Identification.......................................................................................... 51
2.2.4 Identification and Description of Failure Conditions ............................................. 54

iii
 2.2.5 Identifying and Managing the Effects of the Failure Conditions............................ 57
2.2.6 Summary of Amended FHA Process ................................................................... 59
PART 3 - Test and Evaluation ............................................................................................. 61
3.1 Test Methodology ...................................................................................................... 61
3.2 Evaluation of the Modified HazID Method through Trial Application ........................... 63
3.2.1 Derivation of Safety Criteria and Objectives for UAVS Application....................... 63
3.2.2 FHA Levels to Address System Complexities ...................................................... 64
3.2.3 Function Identification.......................................................................................... 65
3.2.4 Identification and Description of Failure Conditions ............................................. 67
3.2.5 Identifying and Managing the Effects of the Failure Conditions............................ 69
3.3 Evaluation of Hazards Identified by the Modified HazID Method ................................ 75
PART 4 – Conclusions and Further Work ............................................................................ 78
4.1 Findings, Related to Satisfaction of the Project's Aims............................................... 78
4.1.1 Identifying Current Concerns over UAVS Safety ............................................ 78
4.1.2 A Framework for Considering Safety Risks Related to Integrating Unmanned
Vehicles into Unsegregated Airspace ........................................................................... 80
4.2 Recommendations for Further Work .......................................................................... 83
4.2.1 UAVS Safety, generally.................................................................................. 83
4.2.2 UAVS Hazard Identification Methodology and Application of ARP4761
Framework ................................................................................................................... 84
Bibliography ........................................................................................................................ 85
Abbreviations & Acronyms................................................................................................... 88
Annex A Review of ARP 4761, to support ARP 4758, CS 25.1309 etc for UAV
application…………………………………………………………………………………………. A-1
Annex B Extract from [CAA02] - A Method for Setting Design Standards for New Kinds of
Aircraft, Including Unmanned Air Vehicles……………………………………………………..B-1
Annex C 'Guard Dog' - generic TUAV Case Study……………………………………………C-1
Appendix C1 Guard Dog Mission Scenario (Coastal Route)………………………………..C-6
Appendix C2 Guard Dog Mission Scenario (Inland Route)…………………………………..C-7
Annex D FHA for 'Guard Dog' TUAV System (extracts)……………………………………...D-1
Annex E SWIFT Assessment for Comparison (extract of hazards)…………………………E-1
Annex F Listing of Hazards for Integration of UAVS into Unsegregated Airspace (From TUAV
Case Study)……………………………………………………………………………………….F-1

iv
LIST OF TABLES
Table 2.2.1(i) - Airworthiness Failure Condition Severities (after [SAE96], with additions from [UTF04]
as noted) ..........................................................................................................................................44
Table 2.2.1(ii) - EUROCONTROL ATM-Focused Separation / Collision Safety Criteria (from [EUR04])
.........................................................................................................................................................46
Table 2.2.1(iii) - Airworthiness Safety Objectives - probabilities per Flying Hour (from [SAE96], drawn
from [FAA88] and compared with [FAA99])........................................................................................48
Table 3.2.1(i) - Airworthiness Failure Condition Severities for ‘Guard Dog (drawn from Table 2.2.1(i))63
Table 3.2.4(i) – Example of ‘Loss of Function’ for pseudo-continuous function...................................68
Table 3.2.4(ii) – Example of ‘Uncommanded Function’ ......................................................................69
Table 3.2.4(iii) – Example of ‘Incorrect Function’ for a cross-system function .....................................69
Table 3.2.4(iv) – Example of failure identification for a warning function.............................................69
Table 3.2.5(i) Examples of analysis of the effects of failure conditions, from the ‘Guard Dog’ FFA.....70
Table 4.1.2(i) – Satisfaction matrix for development of HazID methodology .......................................81
Table A(i) - Safety Objective, from ARP 4761 (drawn in turn from CS.25.1309)……………….……..A-3
Table A(ii) - Severity Criteria as defined in ESARR4 by EUROCONTROL…………………….………A-4
Table D(i) - Airworthiness Failure Condition Severities (from Table 2.2.1(i))………………….………D-3
Table D(ii) - Airworthiness Safety Objectives…………………………………………………….………..D-3
Table D(iii) – ATM Separation / Collision Safety objectives…………………………………….………..D-4
Table D(iv) – Flight phases view of functions……………………………………………………….……D-12
Table D(v) – External interactions and derived UAVS functions………………………………….……D-14
Table D(vi) – Functional Failure Conditions for Guard Dog UAVS……………………………….……D-18
Table D(vii) – Failure Effects for (a selection of) Guard Dog failure conditions………………………D-30
Table E(i) – SWIFT hazards identified for Guard Dog case study………………………………………E-2
Table F(i) –Hazards identified for Guard Dog case study, using the proposed modifications to
ARP4761 FHA technique…………………………………………………………………………………….F-2

v
LIST OF FIGURES
Figure 1a - AQM-34 derivative showing the improving reliability of 'high end' UAV systems [Wes05] ...5
Figure 1b - Aerosonde Laima Crosses the Atlantic (taken from
www.aa.washington.edu/research/afsl/background.shtml)...................................................................5
Figure 1c - Spectrum of current UAV military types [Wei04] .................................................................6
Figure 1.1.3a - Autonomy level variation with required flexibility of mission / environment and certainty
of information....................................................................................................................................12
Figure 1.1.3b Optimising autonomy level to suit operator's [mission] needs .......................................12
Figure 1.1.3c varying the UAVS autonomy level to suit the required level of operator authority for a
situation ............................................................................................................................................13
Figure 1.1.3d 'Agent' View of the UAVS assets and mission decision-making environment (for a multi-
UAV scenario)...................................................................................................................................14
Figure 1.2.1a - EASA / EUROCONTROL 'Total System' vision for aircraft / UAVS regulation............20
Figure 2.2.2a – Example of decomposition of high level policy to lower level agents or cases [Hall05]
.........................................................................................................................................................50
Figure 2.2.2b - Example of Rich Context Diagram (taken from [RQE05, unit 20])...............................51
Figure 2.2.3a – Modified ‘V’ to ‘Y’ model safety assessment process [Jos05].....................................53
Figure 2.2.6a - ARP 4761 FHA Process, with modifications overlaid for UAVS applicability ...............60
Figure 3.1a - "Capture - Recapture" analysis method, to measure the effectiveness of hazard
identification processes.....................................................................................................................62
Figure 3.1b - Overview of Guard Dog UAVS case study ....................................................................63
Figure 3.2.2a - Rich Context Diagram for Guard Dog UAVS and the System of Systems...................64
Figure 3.2.3a – Example of use of mind-map to consider each system element’s view of functions...65
Figure 3.2.3b – Example of derived Functions Tree for ‘Guard Dog’ UAVS........................................67
Figure 3.2.4a – Example of outline Emergency Procedures, to derive functions.................................68
Figure 3.2.5a – Example of mini scenario for consideration of failure effects......................................74
Figure 3.2.5b – Example of graphical scenario ‘MS1 Routine Take-off and climb out’ ........................74
Figure A-1 - ARP4761 Process for an Aircraft-level FHA…………………………………...……….……A-8
Figure B-1 – Unpremeditated Descent Scenario……………………………………………...…….……..B-5
Figure B-2 – Loss of Control Scenario…………………………………………………………...…………B-6
Figure C-1 – Overview of Guard Dog Case Study…………………………………………………………C-2
Figure C1-1 Flight Plan – Westerly Route (to maximize over-water flight)……………….....................C-6
Figure C2-1 - Flight Plan – Easterly Route (to maximise overland / ATC interaction…………...……..C-7
Figure D-1 Rich Context Diagram for Guard Dog UAVS and the System of Systems around it…......D-5
Figure D-2 - Outline Emergency Recovery Procedures……………………………………....................D-8
Figure D-3a – UAV Centred view of functions…………………………………………………………......D-9
Figure D-3b – GCS centred view of functions…………………………………………………………….D-10
Figure D-3c TACU and Field Recovery / Launch Unit centred views of functions…………...……….D-11
Figure D-4a – Guard Dog Functions Tree (part 1 of 3)……………………………… …………..……..D-15
Figure D-4b – Guard Dog Functions Tree (part 2 of 3)………………………………… ………..……..D-16
Figure D-4c – Guard Dog Functions Tree (part 3 of 3)………………………………… ………..……..D-17

vi
INTRODUCTION
Background
Unmanned Air Vehicles (UAVs), from quiet beginnings alongside manned aviation as targets
and Remotely Piloted Vehicles (RPVs), have been gradually growing in use. In particular,
their use by military forces in operational areas such as the Balkans, Afghanistan and Iraq
has started to catch the public eye. Now, with a drive for ‘homelands security’, and with
increasing environmental and financial pressure in carrying out ‘dull, dangerous and dirty’
tasks with larger, manned aircraft, interest is growing to expand the use of UAVs in military
and civil applications. This requires that they be integrated into unsegregated airspace,
alongside manned aircraft and over the general public. However, important questions remain
over how they can be cleared to operate safely, in airspace infrastructures developed and
regulated for safe manned flight.
This report is aimed at safety professionals who may become involved in the assessment
and clearance of UAV Systems (UAVS). It is also intended to be of use to UAVS developers,
operators and regulators, as they face the many issues to be overcome to allow safe,
integrated flight.
Objectives and Motivation for the Project
There is strong interest in expanding the use of UAVs. Currently, their operation is
segregated from civilian airspace because of safety concerns, but to allow them to reach
their potential, they need to be integrated into unsegregated airspace. What, then, are the
real safety issues that must be overcome? In particular, it is unclear how they can be
integrated safely with manned aircraft and conventional air traffic control. Partly, without
prior experience of integrating such systems, the types of hazards involved are not
adequately understood. Without a clear framework of UAVS hazards, it is therefore difficult to
operate a risk-based safety assessment process.
This project aims to:
• Identify the current concerns over UAVS safety, in relation to the existing manned
airspace infrastructure;
• Hence, derive a framework for considering the safety risks related to integrating
unmanned vehicles into unsegregated airspace. The intent is that this, as part of a
robust safety assessment and certification programme, will assist in the eventual
clearance of UAVS, to operate routinely alongside manned aircraft.
Project Scope (and Limitations)
There is a large amount of documentation available in the public domain, relating to UAVS
and their integration. With the pace of technological advance being high, the project has
focussed on the later information as being most relevant (significantly, some issues have not
advanced in recent times, even with this ‘push’).
The first part of the project has thus involved a significant effort, to identify the current
concerns over safety.
Having established as part of this research that there is a place for a risk-based safety
analysis process, the project has had to remain focussed on the hazard identification frame-
work as the main goal. Hence, while there are suggestions for a complete safety
assessment framework for UAVS development, the project is not intended to provide a ‘one
stop shop’ for the safety professional involved in UAVS assessment. It does not provide
detailed safety analysis methods for further down the design and implementation path.
The project is intended, however, to provide a robust start to such a safety assessment
process, with a sound hazard identification methodology based on the civil standard of ARP

1
4761. It is noted that other forms of hazard identification do exist, and they might also prove
UAVS-friendly, but this project has strived to ensure that the hazard identification method
would be compatible with existing requirements of the regulatory bodies for civil aviation.
Without their consensus, the safety assessment method will not support clearance into civil
skies. ARP4761 is an accepted standard and, if it can be made UAVS-applicable, it can
support civil clearance.
In order to assess the hazard identification framework, a case study has been used, featuring
a generic Tactical UAV System. This provides a good benchmark for the applicability of the
method and the hazards it produces. However, as is discussed in section 1.1.1, UAVSs
differ significantly in size, performance and role. Due to limitations of time, it has not been
possible to assess the framework against all of these varieties. Instead, the Tactical UAVS
was chosen as having broad applicability which may have significant read across to many of
the other configurations. That said, the method should be reviewed for its applicability before
its use with the more extreme configurations of UAVS.
Report Structure and Layout
This report presents the research, analysis, development, evaluation, conclusions and
recommendations for the project and is structured as follows:
• Part 1 presents the literature review. A broad review has been carried out, to
establish the context for UAV Systems, and this provides an important introduction to the
characteristics of such systems for those not overly familiar. The review then focusses on
the safety-related issues, identifying those inherent in the UAVS as ‘disruptive technology’,
and those due to the manned airspace environment trying to come to terms with that
disruption.
• Part 2 represents the ‘design and build’ activity for the project. Here, the ARP4761
civil safety assessment process is assessed for its UAVS applicability. Then, a hazard
identification framework is derived, to address the identified gaps and hence provide a
robust, UAVS-friendly methodology.
• Part 3 assesses how robust the new hazard identification methodology is. The
framework is evaluated using a Tactical UAV case study, and the results analysed for
practicality of application and robustness of hazard identification.
• Part 4 presents the conclusions and recommendations from the project, assessed
against the project aims. It also suggests areas of potential further work, identified during the
conduct of the project.
The annexes to the report provide supplementary material as context and evidence for the
main report body:
• Annex A provides a more detailed review of ARP4761, used to derive the ‘design
requirements’ for the UAVS-friendly Functional Hazard Assessment (FHA) hazard
identification method.
• Annex B provides an extract from a Civil Aviation Authority paper on a method for
comparing UAVSs against manned aircraft, using kinetic energy criteria. This is used, in
part, within the hazard identification method.
• Annex C provides useful contextual information on the Tactical UAVS case study
used throughout the project.
• Annex D contains extracts from the results of applying the hazard identification
methodology to the case study system. The full results could not be practically annexed due
to document size, so elements have been extracted pertinent to the evaluation in Part 3.

2
• Annex E contains a summary of the hazards identified using Structured What-If
technique (SWIFT) as an alternative identification method. The results allow comparison of
the robustness of the hazard identification from both methods.
• Annex F provides a listing of the hazards identified using the UAVS-friendly FHA
method, as applied to the Tactical UAVS case study. This is provided as a ‘starter list’ to aid
the assessment of other UAV Systems, and is not intended as being a complete list for all
varieties of UAVS.

3
PART 1 – LITERATURE REVIEW

Overview of Unmanned Aerial Vehicle Systems

What is an Unmanned Aerial Vehicle System (UAVS)?
Let us start with a narrower question - what is an Unmanned Aerial Vehicle, or UAV, as this
tends to be the 'business end' of the overall system? This can be surprisingly complex to
define, but the Civil Aviation Authority (CAA) take a nice, broad view in their definition as:
“An aircraft which is designed to operate with no human pilot on board.” [CAA04, section
2.1].

This definition is both short and subtle, in that it is inclusive of all flying vehicles that would
usually be considered under a wide remit as 'aircraft', and covers all aspects of pilotage and
control from the fully autonomous vehicle to those under direct ground-based pilot control.
There are more complex definitions, such as that proposed by the United States Department
of Defense (DoD) for "A powered, aerial vehicle that does not carry a human operator, uses
aerodynamic forces to provide vehicle lift, can fly autonomously or be piloted remotely, can
be expendable or recoverable, and can carry a lethal or non-lethal payload. Ballistic or semi-
ballistic vehicles, cruise missiles, and artillery projectiles are not considered unmanned aerial
vehicles." [DeG04, section 1.1]. While this is admirable from a legalistic viewpoint, it does not
make for easy reading or general use, so we will stick with the more inclusive CAA definition.
What this does indicate is the lack of consensus between agencies involved in gaining
airspace access for UAVs, and hence the basic levels of difficulties that will have to be
overcome.
What, then, of the UAVS? This is the broader system, which includes not only the UAV itself
but also all the other necessary elements to operate the vehicle. There are the 'hard'
elements in use during the actual real-time mission, such as the Ground Control Station
(GCS) and its Datalink with the UAV, and any hardware required to launch and recover the
UAV. Then there are less real-time but still significant aspects such as Mission Planning. The
'system' can also include softer aspects, such as the organisation that operates the UAV, its
personnel and their competence, and the procedures for operation of the system. All of
these have significance for the safe operation of the UAV.
Brief History of UAVs
The early story of UAVs lies almost solely with military efforts, to alleviate pilots from the 'dull,
dangerous and dirty' jobs. The earliest significant attempt was perhaps the Sopwith AT in
1916, which was proposed as an 'aerial target' but was actually intended to air intercept /
ground attack under remote control. Unfortunately it never flew, being damaged in its hangar
and subsequently abandoned.
As might be expected, the major developments occurred in line with the requirements of war,
and WWII gave real impetus. The first large numbers of Radio Controlled targets appeared in
the mid-late 1930s, to allow the growing population of air gunners to practice - in the UK, the
Queen Bee (from where the term 'drone' emanates) and in the US the Radioplane RP-4 (or
'Denny Drones'), which was the first sub-scale target (and hence showed the potential for
miniaturisation) [Wes05]. Meanwhile, Germany developed the V1 and V2 weapon systems -
not UAVs as such but contributing significantly to the technology required for guidance and
autonomous control. [DeG04]. In the late 1940s, the US began to broaden the role from
targets, using RC aircraft such as pilotless P-61s for thunderstorm meteorological data
collection, and even large QB-17 Fortresses for Bikini Atoll atomic tests [Wes05]. The Korea
and Vietnam wars saw major US development, introducing the AQM-34 Firebee and its
derivatives [Wes05]. Flying over 3,400 missions (in Vietnam) this system introduced several

4
new developments of the role and capability of UAVs: photo reconnaissance, Electronic
Intelligence (ELINT), decoy, Electronic Counter-Measures (ECM), even weapon delivery
including torpedoes and 500lb iron bombs; and technology improvements such as long-
range navigation (using LORAN) and datalinks for image data download. An example of
these more sophisticated UAVs is shown in Figure 1a.

Figure 1a - AQM-34 derivative showing the improving reliability of 'high end' UAV
systems [Wes05]
In the 1980s and 90s, US funding receded in 'low-end' UAV systems, and instead switched
into higher performance systems such as Predator and Global Hawk. Other
countries continued to see the value of low cost reconnaissance systems as 'force
multipliers' in dangerous situations. In this period, Israeli, French and UK systems (Phoenix)
saw service in the Balkans, Afghanistan and Iraq. The military requirement for UAVs was
now well established.
The 1990s finally saw some peaceful civilian uses for UAVs, such as NASA Pathfinder and
Helios, for environmental monitoring. In 1998, a 13kg Australian system (Aerosonde Laima)
crossed the Atlantic, opening the door for long endurance civil systems with fully autonomous
navigation (using GPS) (see Figure 1b). UAVs are here and cannot be ignored!

Figure 1b - Aerosonde Laima Crosses the Atlantic (taken from

www.aa.washington.edu/research/afsl/background.shtml)

5
Current and Future Directions
New technology is accelerating the pace of UAV development, and hence increasing the
'push' into the market-place. As Willbond notes [Wil05], not only has the aviation industry
seen major developments, such as in avionics, fault tolerant flight controls and stronger /
lighter composite materials, but the world overall is being changed by disruptive technologies
such as Global Positioning navigation, faster / more flexible communications links and the
incredible speed of development in computing power ('per pound' of hardware required to
perform it). These changes are allowing UAV Systems themselves to develop as a
disruptive technology - like the jet engine when it emerged among the piston-engined fleets
of the 1950s, they do not just evolve from previous technology but completely revolutionise
what can be achieved.
What is less certain at the moment is the directions of the 'pull' into the market-place - what
do people want UAVs to do for them? As before, the military have more established
requirements, based on the UAVs perceived unique capabilities:
o They can perform jobs that are too 'dull, dangerous or dirty' to be undertaken by
manned aircraft.
o However, they also have capabilities beyond those of manned aircraft - in particular
to undertake tasks at extreme altitude, or incredible endurance. They can also
launch and recover from areas that manned aircraft (even helicopters) cannot get into
or out from.
o With their relative low cost (compared to manned aircraft and helicopters), using
several UAVs can perform some persistent tasks more cost-effectively than the few
manned aircraft that could be deployed for the same resource.

Several military customers have published 'roadmaps' showing their requirements for UAVs,
from the current situation out to quite extended timescales in some circumstances. What
these declare is a vision, of how they see UAV types and their operational capabilities
developing. As Figure 1c shows (fairly typically), there is a wide spectrum of UAV types
required, from micro (such as the Black Widow) costing a few hundred dollars and easily
man-portable for operational-level deployment, up to large scale High Altitude / Long
Endurance (HALE) type UAVs (such as Global Hawk) costing millions of dollars but
delivering strategic-level capability.

Figure 1c - Spectrum of current UAV military types [Wei04]

6
Potential civil applications are held back from deployment in most nations, primarily because
of the lack of certification and safe integration into the general airspace that this report
explores ([Wil05]). Civil applications cannot, routinely, fit into a segregated range or battle
area. Hence there are not, currently, many civil UAVs outside of experimental development
and use. There are, however, many intended uses once the barrier of integration has been
surmounted, such as [Okr05]:
o Environmental monitoring tasks, such as pollution patrolling, earthquake warning,
animal population tracking, weather forecasting...
o Catastrophe management, allowing operation management, situation assessment, or
direct action such as fire-fighting
o Patrolling low-population areas, for tasks such as Search and Rescue, or border
security patrol (very useful as part of the US Homelands Security initiative)...
o Survey tasks such as geological surveys, pipeline / cable surveying...

Rather like the Laser once was described, the civil UAV is a solution waiting for a problem,
and uses will multiply once they have gained access to the necessary airspace.

Issues Relating to UAV Safety and Access to Integrated Airspace

In order to gain this routine access to airspace, UAVS designers, operators and regulators
will have to address a number of significant safety issues, and these are discussed below.
The issues identified from the Literature Search fall roughly into two areas:
o Those issues which derive from the UAVs own disruptive technology;
o Those caused by the UAVs developing, not in a vacuum (as manned aerospace did
in its first years) but in an already established manned airspace environment, which
must come to terms with how to handle the newcomers.

These aspects are discussed in the following sections.

Note on UAV Classification

As discussed in CAP 722 [CAA04, Chapter 1], there are several ways of classifying UAVs in
order to apply some common principle, such as by weight, kinetic energy, operating domain
or mission type (and we look briefly at the issues this creates in section 1.1.1). However,
when discussing the need to integrate UAVs into manned airspace, it is very useful to
classify UAVs by the type of airspace they will operate within. On this basis (as proposed in
[CAA04] and the corresponding UK military publications set of Joint Service Publication
(JSP) 550) an appropriate classification, which shall be used elsewhere in this report, may be
considered as:
Group 1 - Those intended to be flown in permanently or temporarily segregated airspace
(normally a Danger Area) over an unpopulated surface (normally the sea following 'clear
range' procedure).
Group 2 - Those intended to be flown in permanently or temporarily segregated airspace
(normally a Danger Area) over a surface that may be permanently or temporarily inhabited by
humans.
Group 3 - Those intended to be flown outside Controlled Airspace (Class F&G) in the United
Kingdom Flight Information Region (UK Flight Information Region (FIR)).

7
Group 4 - Those intended to be flown inside Controlled Airspace (Class A-E) in the United
Kingdom Flight Information Region and United Kingdom Upper Information Region (UK FIR
and UK UIR).
Group 5 - Those intended to be flown in all airspace classifications.

1.1 Safety Issues Relating to UAVs as 'Disruptive

Technology'
Some issues with potential safety impact stem from the differences UAVs pose, compared to
their manned predecessors. Some inherent issues are due to the very nature of their
disruptive technology, whether or not there was an existing system to clash with. These
aspects are discussed here (though some, inevitably, cause knock-on issues for the existing
manned airspace environment and cross-references are given where appropriate).

1.1.1 Impact of the Variety, Roles and Performance of UAVs

Breadth of Scope of UAV System (UAVS) Varieties
The initial problem in discussing safety of UAVSs is the sheer breadth of scope of such
systems. It is difficult to pin down generalities for a range of systems that embrace the palm-
sized / Line of Sight (LOS) controlled micro UAV right up to the Boeing 737-sized HALE
controlled via satellite datalink. This range is a challenge for the regulators - possibly more
so than their manned counterparts, and we shall look more into this when we discuss issues
of legislation and certification (section 1.2.1). Nelson and DeGarmo [Nel04] paint a
fascinating set of 7 scenarios for UAV operations in 2020, ranging from a stratospheric
airship acting as a telecommunications relay, to a team (swarm?) of UAVs on border patrol,
and on to a 'media and traffic reporting' UAV operating under Visual Flight Regulations (VFR)
in an urban environment.
At this point, while it may not necessarily be a direct safety issue, the fact that authorities
cannot classify UAVs (or even model aircraft [Deg04]) consistently shows the extent to which
they challenge regular thinking. The Swedish Aviation Safety Authority believe it is
necessary to define at least 5 classifications of UAV in order to arrive at suitably granular
understanding of requirements [Wik03]; the military tend to classify based on altitude and
endurance, or sometimes on operational characteristics; other schemes by civilian authorities
consider kinetic energy (i.e. mass and speed), or mass alone, or range, or operating airspace
type, or potentially some measure of the level of autonomy. The FAA cannot even arrive at a
consistent definition of what constitutes a UAV [DeG04, paragraph 2.4.1].
My concern is that these attempts to pigeon-hole UAVs into existing categories (or
something similar) and manage them accordingly, shows a limited understanding of the
nature of UAVSs and the safety risks they may pose: the accent is on trying to keep the
status quo rather than address the rich differences that UAVSs present. This concern will
reappear regularly throughout this report.
UAV Performance
UAVs can perform differently to their manned counterparts, in part due to their different size
and sometimes unusual planform. Sometimes the performance is possible primarily because
they are unmanned and aren't limited by human frailties. The fact that they perform
differently means that they can be difficult to slot into a stream of manned aircraft
traffic. Degarmo [DeG04,] in particular notes the variation in performance capabilities of
different UAV systems. Some will operate very slowly, with limited manoeuvrability, while
others may be faster and more agile than their neighbours. Relative differences in velocity
and manoeuvrability introduce potential conflict which must be managed.

8
UAV Roles and Mission Profiles
If UAVs lack performance commonality with manned ac, they also lack predictability of flight
path, with their roles and missions introducing unusual flight behaviour. DeGarmo again
[DeG04, paragraph 2.3] discusses how UAV types of mission are rarely 'point to point' but
instead have variations of patterned flight, loitering, tracking and orbit activity. There is even
the possibility of planned flight termination, with the vehicle potentially suddenly entering
a 'falling leaf' or parachute recovery in the path of other traffic - while this was not discussed
in the literature reviewed, it would be an obvious concern in traffic. [DeG04] does propose
the establishment of designated flight recovery areas, where UAVs could go to 'die' (flight
terminate) assuming that power and control was still available. In the CRS Report for
Congress [Bol05] there is the interesting prospect of swarms of UAVs operating mutually
under a common human controller, on border patrol. This introduces the potential for the
UAVs mutual interference, as well as constituting a widespread hazard for other aircraft and
ground-based population (see 'increased traffic' in section 1.2.2).
Before getting too excited over these differences, though, perhaps we should consider
whether parallels may be drawn with the capabilities, roles and flight patterns of helicopters:
the fixed wing fraternity has managed to accommodate these vehicles, so perhaps there is
fair hope for UAV integration.
Launch and Recovery
In [DeG04, paragraph 2.3] DeGarmo discusses the UAVs' next trick - the capability to launch
and recover from almost anywhere (in ac terms). While it is true that large UAVs will
generally operate from airfields (itself something of an issue - see 'airfield operations' in
section 1.2.2 of this report), smaller UAVs are designed to operate not just from runways but
also from ships, open country, even buildings and urban environments. The implication (not
explicit in the text) is the safety risk associated with the UAVs sudden and unexpected
insertion into manned traffic, as it rises from below. Conversely, the UAV may perform
a sudden change of vector, not expected by manned traffic on a parallel point-to-point flight,
as it turns into a recovery pattern. However, as for the discussion over roles and mission
profiles, the literature does not draw any parallel with the introduction of helicopters into fixed
wing aviation, and I feel that there could be useful aspects to draw from the experience
gained with this, in the cause of UAV integration.

1.1.2 The complex system boundary for UAVs

Extended System Criticality
Several sources recognise the criticality of the UAVS overall, and not just the vehicle.
Certainly, the ground support environment plays its role in manned aviation, but in UAVSs
there are a number of direct causal links that can affect safety in real time.
The Joint UAV Task force (UTF) [UTF04, sections 7.2 and 7.3] recognised this criticality
when they proposed extending the usual definitions of 'airworthiness' to include all safety
critical elements of the system, such as Ground Control System, datalink, Flight Termination
System etc. They then took this further to suggest that some of these elements (and others
such as Flight Control / Flight Management System, the Control Station and Launch /
Recovery equipment) should themselves be subject to Type Certification (discussed more in
section 1.2.1 of this report). DeGarmo [DeG04, section 2.3.3] extends the boundary further to
consider the information and data systems used by the UAVS, including those derived from
wider sources. He suggests that we need to consider the data being passed around the
system internally, such as navigation and position data, telemetered parameters. Then, to
look further out to consider the mission planning / retasking from the ground station; and then
further still to consider the data sources feeding the GCS, such as terrain databases,
weather databases / live links, and possibly dynamic Air Traffic Management (ATM) data
such as time-dependent clearance blocks. DeGarmo goes on to discuss US plans for an

9
ATM information network, but whatever the implementation, the UAVS, vehicle and GCS will
inevitably have to interface with various proprietary wide-area networks and even internet
based information networks.
None of the documents agree entirely on what the critical elements are. The CAA offer a
useful maxim of "Where any function of a UAVS is essential to, or can prejudice, continued
safe flight and landing of the UAV...have to comply with the applicable airworthiness
requirements" - this allows some flexibility to identify the critical elements pertinent to the
system under consideration, but without saying what those applicable airworthiness
requirements might be.
It is clear that the overall 'system' is extended even within those elements in control of the
UAV organisation. If we consider all the system elements that could affect safety, we have a
very extended critical system. In effect, we can view this as a particularly interesting 'System
of Systems', with varying levels of coupling between the different system elements.
Command Datalink
A key integrating element of the extended system is presented by the Datalink. It links the
UAV with its Ground Control System for guidance and telemetry, plus a host of other system-
specific possibilities. Being the system 'glue' in this way makes it a critical element of the
extended system, a fact not missed among the literature.
Reliability: Schneider [Sch04] notes the need for dependable, Over the Horizon datalinks to
be developed, possibly using dual redundant Satellite Communications (SatComms) (an
important feature for the US current trend for large, long range UAV systems). In [UTF04],
reliability requirements are developed further, with proposals that no single failure within the
system (uplink or downlink) should affect normal control of the system, and the need for
Electro-magnetic Interference (EMI) hardening to protect the datalink. They also highlight the
need for link data (such as signal strength or coverage limitations) to be displayed to the
UAV pilot (UAV-p), to ensure that he can monitor its continuing reliability. But no matter how
reliable command datalinks will prove to be, the requirement to deal with loss of datalink will
remain as a particular risk to be addressed, and regulators will demand Standard Operating
procedures (SOPs) to deal with the occurrence (see section 1.2.2). [UTF04], [CAA04] and
many others repeat this requirement many times.
Spectrum availability: [Sch04] starts the analysis by initially stating that manned aircraft
operators were bemoaning the rate that UAVs would eat up available frequency spectrum;
but then he offsets this by suggesting that, in a networked environment, the presence of
UAVs will allow information to be shared more easily and hence reduce the number of other
airborne sensors needing bandwidth. Somehow, I suspect that this gentle balancing of
systems is unlikely to occur in reality, but instead the airborne sensors will also grow in
number and compete for spectrum. This view is shared by CAA's Mettrop [Met05], not just
because of the number of UAVs but because of the growth in the number of sensors and
command frequencies required by both manned and unmanned systems. His paper looking
at the difficulties of trying to negotiate international agreements through the International
Telecommunications Union (ITU) paints a fairly bleak picture, and raises the likelihood of
Radio Frequency (RF) interoperability and interference between systems due to sheer
density of vehicles or simple differences in allowed frequency between countries. DeGarmo
[DeG04, 2.3.4] also believes things will be tight, but suggests that, in the future, innovative
solutions may come to light such as flexible frequency use: although nearly all the civil
frequencies are allocated, only 2% are actually in use at any one time, so there could
potentially be plenty to 'share' - this may be tricky to align with the need for dependability of a
command datalink, but perhaps other uses (such as voice communications (‘comms’) or non-
priority sensors) could be re-allocated to use this technology and free-up spectrum.
Connection path: Current, small UAVs generally use VHF / UHF datalinks, giving direct
Line-of-Sight capability. This can cause problems with terrain masking (as noted in [UTF04],
briefly) and affect the possibility for low-level operations. [DeG04] discusses other options:

10
The US has made use of commercial and military SatCom links [Sch04] and potentially there
is access via Iridium Low Earth Orbit (LEO) satellites. Each of these potential connection
paths changes the system boundary, which returns us neatly to the opening statements of
this section - the UAV and its extended system criticality.

1.1.3 UAV autonomy - technology, predictability, complexity

Tim Willbond [Wil05] in his keynote speech at the Royal Aeronautical Society (RAeS)
conference in 2005, talked about the two-edged sword of autonomy in UAVs: on one hand, it
is a key enabling technology, allowing flexibility to the UAV, capability to the human
operator and providing fall-back options if the datalink goes down; on the other hand, it will
be a major hurdle to prove its dependability to allow integrated operation in manned
airspace. To consider its hazards, we need to understand a little of what autonomy may be
like 'in service'.
Autonomy level factors
When we talk about autonomy levels, we are talking about a continuum of system authority:
at the one extreme, where the system has no autonomy, the human operator has full control
of the system at the most basic level, making inputs to the direct control actuators of the
vehicle. At the other extreme, with full autonomy, the system is able to exercise its own
control, make its own decisions, learn new tactics and shape the mission, without even
informing the human operator. Most likely, systems in the near future will exist somewhere in
between.
The military have traditionally used a simple linear scale (usually 1 - lowest to 10 - highest) to
describe a UAVS level of autonomy. However, Huang [Hua04, 2] suggests that the answer
is more complex. He proposes that a number of factors provide the real indicator of
the autonomy level: difficulty of the environment; complexity of the mission; and operator
interaction (inversely proportional - less interaction is more autonomous). For our
consideration of safety, each of these axes would give us a series of issues to be
considered. Is the UAV autonomy appropriate to the situation it finds itself in? What if one of
these factors changes?
Platt [PlJ05] takes a broader, less constrained view, and says that Autonomy of a system is a
function of: the operator's interaction and its context; the types of reasoning about the
environment that the system employs; and the types of knowledge that the system has
available or can gather. Figure 1.1.3a, below does two things: it gives a view of how the
environment and mission context might drive the required level of autonomy; but, again, it
indicates how these axes could become safety issues, if our UAVS equipped to a certain
level of autonomy gets pushed beyond its intended model.

11
 Figure 1.1.3a - Autonomy level variation with required flexibility of mission /
environment and certainty of information
Autonomy v Ground Control:
The Joint UAV Task Force [UTF04, section 7.9] propose that the Human Machine Interface
will be a critical area of autonomy design and regulation, with the need for a careful trade
between autonomy level and the capability of operator intervention. While the spirit of this is
clear, it may represent (again) a too black-and-white mental model of autonomy and human
interchange. Walan [Wal03] instead suggests that the situation changes between different
mission types and even during the same mission. Periods of intense action such as mission
planning and sensor operation may be interspersed by long periods of boredom and lapses
of operator awareness, and this would be much increased for an operator responsible for
multiple UAVs in a package. What he offers is a model for variable autonomy, what he calls
"sharing control rather than trading control" - "Sharing control means that the human and the
computer control different aspects of the system at the same time . . . Trading control means
that either the human or the computer turns over control to the other"
Platt [PlJ05] supports this view. In Figure 1.1.3b, Platt suggests that the scope of an
operator's inputs to and desired outputs from the UAVS can be modelled at different scopes -
from direct system control (Tier 1) through tactical system management of the vehicle
configuration (Tier 2), up to strategic overall mission management (Tier 3). Figure 1.1.3.c
then shows how the autonomy / authority can be varied to suit the operator's needs for a
given situation.

Figure 1.1.3b Optimising autonomy level to suit operator's [mission] needs

12
 Figure 1.1.3c varying the UAVS autonomy level to suit the required level of operator
authority for a situation
Whilst debating the required share of autonomous functions, note should be made that some
autonomous behaviour will be demanded by the regulators and ATM providers, primarily for
actions in the event of emergency situations - section 1.1.2 refers.
Reliability and predictability
Autonomous behaviour will demand a safety critical consideration of its reliability. As
Schneider notes [Sch04] "Conflict avoidance, especially in a fully autonomous, lost link
situation, will be the Achilles heel challenge for the FAA to prove" - he demands an
Equivalent Level of Safety (ELOS) for UAVs with autonomous vehicle operation.
What makes an autonomous system hard to trust? Platt [PlJ05] proposes two general
reasons: the gulf of execution - does the system take actions that correspond to the
intentions of the operator; and the gulf of evaluation - can you monitor the state of the system
and what is the difference in state from that intended. When we get to considering autonomy
for high level functions (Tier 3 in the above discussion), Platt assumes that these will most
likely be controlled using 'agent based' methods (see Figure 1.1.3d below). These introduce
three areas of uncertainty:
o These are a novel application in air vehicles and hence there will be issues of
expertise, trust and clearance
o They require accurate capture and specification of the 'agent' behaviours beforehand
giving issues of knowledge acquisition (and requirements elicitation - see York
module on Requirements Engineering (RQE)).
o There will probably more be than one 'Artificial Intelligence' method used to
implement the decision making, and these will introduce new issues of architecture
and integration

13
 Figure 1.1.3d 'Agent' View of the UAVS assets and mission decision-making
environment (for a multi-UAV scenario)
Platt echoes the old cry of "It's only software!" and the issues of predictability that entails (see
York Computers and Software (CAS) course). He proposes that the challenging issue will be
in trying to ensure clear distinction is made between safety critical and mission critical
functionality such that inevitable changes to the mission critical aspects can not impact on
the safety critical aspects.
UAV 'Airmanship'
In section 1.2.2, we look at issues of ATM interaction and the need for 'transparency', i.e. the
ability of the UAV to behave in the same way as manned aircraft, and (for highly autonomous
systems) this function will fall to the vehicle autonomy. Behaviours and judgments such as
applying rules of the air, navigating, sensing and responding to weather conditions fall into
this vague category of 'airmanship' and are difficult to describe, let alone specify - in some
cases, behaviour should be absolutely predictable (such as generally within an airspace
corridor) and in others, instantaneously flexible (such as in collision avoidance). Airmanship
is both planning for expected events, plus reacting (predictably but swiftly) to external
events. Marsters and Sinclair [Sin03, section 4] say that "The precision and repeatability of
technological solutions notwithstanding, the knowledge, judgment and skill (sometimes called
'airmanship') of the on-board pilot will be difficult to emulate."
DeGarmo [DeG04] looks at various airmanship issues, such as how the UAVS detects and
responds to weather systems and conditions - in some cases coping with the conditions, but
in others deciding how to route to avoid them. This may be quite an issue, especially for
smaller UAVs more sensitive to weather (see section 1.1.1). He also looks at how UAVS
decision making matches the expectation of Air Traffic Control (ATC) decision making tools
(such as used to effect Traffic alerting & Collision Avoidance System (TCAS) manoeuvres).
A critical aspect of UAV autonomy will be the vehicle response in the event of command
datalink failure (as noted elsewhere, in sections 1.1.2 and 1.2.2). DeGarmo [DeG04], for
example, calls for pre-programmed actions, diversionary sites / flight termination areas and
procedures to be defined - what this implicitly calls for is that, in the event of datalink failure,
the UAV can successfully analyse the situation (including external factors such as weather
conditions), decide on the course of action, and navigate its way there predictably and

14
dependably. Such functions are identified in a number of other documents, including the
CAA in CAP722 [CAA04].

1.1.4 Accident rates and reliability - UAV airworthiness

This section looks at the accident rates and reliability of current UAV systems, related to
achieving safety levels acceptable for flight in unsegregated airspace / terrain. It discusses
the inherent safety levels for UAVS, rather than the demands for legislation, standardisation
and regulation to achieve such levels, which are covered in section 1.2.1.
The Catastrophic failure rate is too high (currently)
Indications are that the failure rate for UAVs is currently too high. DeGarmo [Deg04, 2.1]
quotes US DoD analyses that show the UAV catastrophic failure rate (in terms of vehicles
lost rather than induced fatalities ) at around 50 times that of an F16 (itself held to be a fairly
risky platform), and around 100 times that of more general aviation. Another statistic
compares an accident rate of 0.06 per million flying hours for U.S. commercial aircraft in U.S.
airspace to a rate of 1,600 per million flying hours for the Global Hawk. Clearly such figures,
if read across to UAV operation in unsegregated airspace and larger UAV fleets, would not
seem tenable. Part of the problem is the data - all of it, currently, is sourced from military
UAVS which have often been rushed from research into service (e.g. Predator use in
Afghanistan); have been employed in fairly high-risk operations; and come from a very small
sample, compared to the manned fleet they are being compared with [DeG04,
2.1.2]. Nonetheless, such figures would not currently support integration.
If the situation is to improve, we need to understand the causes for the poor safety record.
This is not easy: as Williams [Wil04] notes in his review of UAV Human Factors issues, there
is a lack of good, reported UAV accident data, even in the military: until recently, the US
Army and Navy classified UAVs as 'vehicles', and treated accident investigation similarly to
damage to ground vehicles. The US Air Force did carry out more detailed investigations but
would not release information into the public domain. As a result, most UAV accident
'statistics' are based on aggregated information or single sentence entries - it is thus difficult
to derive significant causal analysis. DeGarmo [DeG04, 2.1.2] tries to pick through what is
available, quoting DoD analyses again to state that around 75-85% of the failures were due
to equipment failure (37% propulsion, 26% flight control, 11% communications link; 17%
human factors, 9% miscellaneous). He states that such figures are not unexpected: as we
noted above, the current generation of UAVS stem from research programmes, and/or have
been 'thrown' together to satisfy high risk operations at low cost, thus redundancy and
reliability have not been high priorities. It is not stated, but we can presume that military
programmes have also assumed a higher acceptable risk level, combined with operation
over unfriendly territory, so concerns over ground or air collisions have also been pretty low -
we are not assessing the record of systems designed for operation in integrated airspace
over 'friendly' populated areas! Schneider [Sch04] concurs, providing a little more detail on
the equipment failings:
o Propulsion system unreliability relates to the search for a reliable 'heavy fuel' engine
that can cope with the extended endurance requirements, at temperatures and
altitudes not generally experienced.
o The flight control failures, on the other hand, relate to the use of COTS actuators,
some drawn from commercial non-aviation sources (hence not intended for this level
of criticality) and often being used outside their intended environment.

Schneider concludes that, while current UAVSs could have been designed, fabricated and
maintained to manned aircraft levels, this had clearly not been the case so far.

15
Bolkcom [Bol05] also highlights the problems due to evolving technology in this generation of
UAVSs, but says that the equipment issues are heightened because the UAV-p is removed
from the event: rather than being a direct Human Factors accident, instead an equipment
failure develops into an avoidable accident because the UAV-p is less able to diagnose and
correct problems; he lacks the 'seat of the pants' sensory inputs. There is further discussion
of Human Factors safety-related issues, in section 1.2.5.
What is acceptable Safety Risk?
DeGarmo [DeG04] says that, to gain acceptance, UAVS will have to prove that they have an
Equivalent Level of Safety (ELOS) to manned aircraft. But defining this 'equivalence' in
terms of actual safety requirements is very difficult. The CAA echo this general requirement
[CAA04], saying that UAVs operating in the UK “…must not present or create a hazard to
persons or property in the air or on the ground greater than that attributable to the operations
of manned aircraft of equivalent class or category”. [UTF04] also starts with a general
principle of equivalence, that requirements should be no less demanding than those currently
applied to comparable manned aircraft, but does then try to achieve fairness that such
requirements should not penalise UAV Systems with higher standards simply because
technology permits. This gives us a concept of balanced safety requirements, but how could
we define such requirements?
The Swedish Aviation Safety Authority in [Wik03] takes a fairly pragmatic view. They are
content to allow a higher accident risk per flight hour for UAVs during the earlier development
period, provided that this is balanced by a low number of flights / UAVs to ensure that the risk
to the overflown public or manned aircraft remains acceptably low. As the number of UAVs
increase, the reliability of systems must increase sharply to keep the individual risk low.
They consider an overall balanced target of no more than 1 death on the ground per 50 year
period; and in the air, UAV systems shall not give rise to more near collisions, calculated per
flight (or flight hour) than manned aircraft have caused during the most recent ten-year
period. [Wik03] refers in turn to [Mar03] to calculate the allowable critical failure rate per
UAV flight hour. This they derived by reckoning the overall target against the number of flight
hours per annum, the population density (assuming flight over a low density area in the early
years) and the 'lethal swathe' area determined by the expected crash mode of the system - a
horizontal crash creating a longer, bigger swathe than a vertical dive. In this way, they say,
by controlling the number of allowed flight hours, the failure rate for a given system can be
allowed to be higher in the early stages.
Weibel and Hansman [Wei04] take a slightly different approach to achieving balanced safety
targets, in their attempts to identify required levels of reliability to avoid ground and air
collisions. For ground collisions, they start with the FAA requirement for a 'hazardous' event
(assuming that the number of fatalities in any event will be small, hence not catastrophic) to
occur less than 1x10-7 per operating hour. From the National Transportation Safety Board
(NTSB) records they found the actual number of ground fatalities per operating hour to be
2x10-7 per flying hour; and then set a target level of safety a magnitude higher at 1x10-8
ground fatalities per hour in recognition that, to gain acceptance, UAVs will need a greater
level of safety than manned aircraft. For air collisions, the FAA target of less than 1x10-9
collisions per hour was taken, for ELOS. In calculating the required levels of reliability,
[Wei04] goes into more depth (than [Mar03]) in assessing the risk, taking into account the
UAV mass and barriers to actual fatalities. For ground collisions, these barriers are
proposed as: population density, shelter afforded by buildings, and likelihood of fatal
penetration. For air collisions, they propose the 'collision volume' of the UAV and manned
aircraft (their near-miss area extruded along their intended flight route), the size, length and
traffic densities within controlled airspace, and finally a probability that the collision may not
actually cause fatalities - the latter does not accord with the CAA view that 'nearly all
collisions result in fatalities' but does allow for the fact that birdstrikes etc are usually
survivable, and we are discussing a wide spectrum of UAV sizes and masses. Interesting
(but maybe not unexpected) conclusions from the study are that high mass, high altitude

16
UAVs in controlled airspace will have to achieve a much higher level of safety (because of
their kinetic energy capability) than smaller vehicles in less dense airspace; but that the
former would be more able to meet such levels from inclusion of redundant systems and co-
operative collision avoidance technology, because of their size and sophistication.
Achieving Airworthiness
Marsters [Mar03] is clear that "It is very important that the overall safety-assurance for UAV
operations outside reserved airspace be based upon the design, development and
maintenance of highly reliable air vehicles." He presses on that UAV reliability and their
contingent catastrophic failure rate must be acceptable by civil aviation standards, and this
can only be achieved by adopting a stringent system-safety design regime for UAVs. What
he proposes is to incorporate a 'FAR 1309-type' philosophy in the UAV flight-critical system
safety design, and refers to ARP 4761 [SAE96] as a suitable approach for safety analyses.
The Swedish Aviation Safety Authority [Wik03] also place great faith in airworthiness through
design, but note that there will also be requirements for operator and maintenance standards
(of which more in section 1.2.1). The paper looks at JAR 25.1309 and JAR 23.1309 required
analyses for manned ac, and briefly compares the applicability of such analyses to UAVSs. It
concludes that targets such as allowable failure rates should be adopted, but that the
methodology may be amended to suit the differences in UAVS. For example, where the
Joint Airworthiness Requirements (JARs) make an assumption of 100 critical systems for
large aircraft, and 10 critical systems for small single-engined aircraft, the UAVS designer
may apportion required reliability more pertinent to the UAVS system breakdown, provided
that the overall demanded reliability is thus achieved. This does seem to be a sensible
proposition, and a suitable way of establishing 'equivalence' with manned systems in terms
of reliability, while duly noting the differences that exist for UAVSs.

17
1.2 Safety Issues Relating to the Manned Airspace
Environment 'Coming to Terms' with UAVs
Some safety issues are evident, not so much because of the nature of UAVSs, but because
they are having to fit in and around an already established environment. When manned
aerospace was at a similar point of development, the skies were empty - now the skies are
full of manned aircraft and the monolithic environment of Air Traffic Control, procedures,
regulations and so on that has been established over time to keep them safe. This section
looks at those issues where the environment is struggling to come to terms with UAVSs and
their nature.

1.2.1 Regulation, Certification and the Drive for Standards

Elsewhere in this report we look at characteristics of the UAVS such as airworthiness, safety
requirements (section 1.1.4), operations (1.2.5), collision avoidance (1.2.3) and ATM
interaction (1.2.2). The aerospace community's approach to try and ensure the safety of
these characteristics is to derive regulations, certification and standards that must be
applied. In this section, we look at the safety issues emerging from this 'must-do' philosophy.
Regulation
Manned airspace is a highly regulated environment, and it is worth a brief review of what this
entails for the UAVS. At the top of the regulatory 'tree' is the Chicago convention, specifically
Article 8 which states that "... no aircraft capable of being flown without a pilot shall be flown
without a pilot over the territory of a Contracting State without special authorisation by that
State" [CAA04]. The push for regulators is currently to find international agreement on how
to open up the skies to unmanned aircraft.
The CAA provide an overview of how regulation is flowed down from the Chicago Convention
for aircraft generally, both manned and unmanned, in CAP 722 [CAA04, chapter 2]:
o European Aviation Safety Agency (EASA) regulation EC 1592/2002 applies generally
to all aircraft in the European Union, for airworthiness certification and continuing
airworthiness (maintenance and modification);
o This excludes 'state aircraft' (military, police, customs), research craft and those
under 150Kg, to which national regulations must apply.
o Equipment requirements, operational rules, personnel licensing, aerodrome
regulation and regulation of air traffic services are not (yet) dealt with by European
Regulations and so are matters for national regulation for all categories of aircraft.
The UK covers these (for non-military aircraft) under the Air Navigation Order 2000
and Rules of the Air Regulations 1996. Aircraft must have a Certificate of
Airworthiness (Design and maintenance), a Permit to Fly (Operations) and Licensed
Aircrew (for airspace and meteorology / visibility conditions).

CAP 722 then goes on, chapter by chapter, to try and state how general aircraft regulation
(civil and military) should be applied to UAVSs. But there are many areas where the
regulation becomes vague and stops fairly quickly after demanding 'equivalence' in terms of
performance, safety levels, certification, interaction et al, without guidance on what the
equivalence is to, or how the UAV differences may be resolved in this environment.
The Australian Civil Aviation Safety Authority (CASA) have similarly moved to apply existing
regulation, and published their Civil Aviation Safety Regulations Part 101 [CAS04] to define
how that was to be done. 'Define' is perhaps too strong a word - while the text appears
definitive at first, this is predominantly for application to small and micro UAVs: once the

18
regulation reaches larger UAV systems and operation, it basically refers the reader back to
CASA, to establish written agreements on what can be flown, where and how. Perhaps its
major contribution is that it allows small UAVs fairly good access, even to controlled
airspace. This will allow building of experience for designers, operators, and ATC personnel
and hence inform the wider use of UAVS.
DeGarmo [DeG04, section 2.4.3] discusses this worldwide move to try and apply existing
manned regulation - he declares that it is good in principle, to apply existing regulation
wherever possible, because it avoids developing new, specific regulation that might
ultimately prejudice a developing area of UAV operation. Hence, he notes that this
approach currently forms the backbone of the US development of a UAV 'roadmap' towards
integrated airspace (and its equivalent can be found in most of the international roadmaps in
development). However, he goes on to note that the wide variety of UAVs could make
this universal application difficult to apply (as we discuss in section 1.1.1).
In their Joint UAV Task Force report [UTF04], Joint Aviation Authority (JAA) /
EUROCONTROL provide a useful discussion of their philosophy for regulatory development
for UAVs, and this has been flowed on through EASA into their provisional regulation under
Advance – Notice of Proposed Amendment (A-NPA) No.16-2005 ([EAS05]). Their guiding
principles are that regulation should establish:
o Fairness - between competing UAV systems and with existing manned aircraft:
hence the principle is to apply existing regulation wherever possible (in accord with
DeGarmo, above).
o Equivalence - regulation covering UAVs should be no less, but also no more
demanding than expected for manned aircraft systems: this they break down into
equivalence of risk (see 1.1.4) and in operations (to meet the expectations of other
airspace users). Few clues are provided on what to establish the equivalence to!
o Responsibility / accountability - clear demarcation of the organisation requirements
for: design, manufacture, operation and maintenance of UAVS. The report notes the
importance for maintaining the accountability chain in the event of extended UAV
operations causing responsibility to be passed between personnel and organisations,
even nations as an operation proceeds.
o Transparency - especially for ATM: this does not seem so much a guideline as a
pretty hard-line requirement, the fairness and applicability of which is discussed in
section 1.2.2.

Eventually, EASA / EUROCONTROL settle down to consider regulation aimed at controlling

their "5 pillars of safety and security": Airworthiness & Certification; Operations &
Maintenance & Licensing; Security; Air Traffic management; and Airports. However, they go
on to reiterate that, currently, EASA only regulate airworthiness and environment, and they
propose that a 'Total System' approach is required in the long run ([EAS05, IV-4-b]) as hinted
at in [CAA04] above. A graphical representation is shown in Figure 1.2.1a, below.

19
 Figure 1.2.1a - EASA / EUROCONTROL 'Total System' vision for
aircraft / UAVS regulation
Certification
For the UAVS itself, certification literature falls broadly into two areas: that for the UAVS
design, and that covering the operation of the system.

Design Certification

The first issue for regulators is to establish the basic strategy for certifying UAVS designs.
For manned aircraft, civil regulators have generally followed a standards-based approach
and assume an independence from the operational considerations, while military certification
authorities have followed a mix of standards and safety target / safety case methods in order
to focus on eventual satisfaction of specific missions and uses. How then, to certify UAVS?
DeGarmo [DeG04] discusses a CAA study in 2002 [CAA02], which assessed two
approaches - safety targets (where, potentially, design requirements could be traded against
operating requirements, such as operation over unpopulous areas to offset initial reliability
concerns) and certification design requirements (standards). While the former was proposed
as being easiest to apply, the CAA decided that this was "not consistent with International
Civil Aviation Organisation (ICAO) ... legislation". The study went on to say that "the second
approach, one that is requirements-based, was seen as more practical in that it is familiar to
the aviation industry, it facilitates the development of common standards, and there are no
special, type-specific, operating restrictions to address airworthiness uncertainties, therefore
offering greater operational freedom". Degarmo suggests that this will be the way most
regulators will opt for, inspite of his earlier observation that there are no established
standards for UAV systems.
The Joint UAV Task Force report [UTF04, 6.3.1.1] considered the same two options for
certification. Again, they suggest that, given the current unknowns about the differences
between UAV systems, the safety target approach would be easiest for UAVS application,
but that the standards approach must be followed for the following reasons:
o In order to accept a safety case approach, the regulator needs to be closely linked to
the operational acceptance side as well, in order to understand and apply controls.
While this is possible for military systems, it is not for civil regulators - EASA, as noted
before, do not have control of operations, personnel, airfields etc. Even if the
regulator could control operating aspects, it could still prove unfeasible: if a safety

20
 case for a system was accepted on a risk-basis underpinned by assumptions of
mission length and frequency, it would be difficult to enforce this generalised
assumption to specific missions and tasks on a daily basis. Civil standards-based
certification separates the design from the operation and enforces minimum
standards.
o The separation of design and operation will ease the certification process in the
longer term, to allow UAVSs to be used by a wider variety of operators and for a wide
range of missions. It also facilitates export of systems and operation across national
borders.
o In order to support fair competition for civil contracts, designers and operators need to
face a 'level playing field' of certification, in order that one system under a particular
regulator is not unfairly advantaged.
o The build up of civil standards has delivered manned aircraft systems that have
safety levels accepted by the public, and the same should be expected for UAVSs.
Also, civil aircraft manufacturers are comfortable with the standards-based approach,
and it ensures clarity that, provided the minimum standard is complied with, the
system will get certified.

Some of the above sounds like "it's worked for us on civil manned aircraft, therefore it must
work for civil UAVs" and there is still the problem of finding applicable standards (see
below). I feel it is very difficult to separate the UAV from its mission, in the same way that the
military have recognised the inter-relationship, and the Joint European Task Force has
already pushed the need for a 'total systems' approach (see above). There are still the vast
differences between UAVSs to be dealt with (see 1.1.1). The glimmer of hope within
[UTF04] and the related EASA proposed regulation of [EAS05] is that, apart from blunt-
edged minimum standards, a safety objective approach based on CS.25 / 23.1309 type
requirements should be established and followed. This at least means that system
differences, safety risk assessment and the application of novel technology within the design
may be identified and dealt with appropriately. This approach, and related literature
discussing it, has already been discussed in section 1.1.4.
The CAA [CAA02] provides some assistance in the issue of deciding the equivalence of
manned and UAV systems. Briefly, the method involves the consideration of two scenarios:
i) impact with the surface at a velocity appropriate to an emergency landing under control
and, ii) impact at a velocity resulting from loss of control at altitude. The kinetic energy for
each case is calculated and then compared with the results of similar calculations as applied
to a sample of the existing manned aircraft fleet. Consideration of the results gives a first
order approximation, to look at the indicated certification requirements (such as EASA
CS.23) and draw out relevant aspects for the system under consideration. Where
necessary, different sources can be merged to give the best mix of requirements for the new
system.
The next issue is that we need to be clear on what design aspects need to be addressed,
and this is critical if the standards route is to be followed. Degarmo suggests that most of the
usual manned aircraft design requirements will apply, such as for structural integrity,
performance, reliability, stability and control, but would need to extend to certification of the
wider system elements such as the ground control station, data link, data security, launch
and recovery mechanisms, and the autonomous systems and software integrated into the
vehicle and ground elements. The extended aspects of 'System-of-systems' safety criticality
have been discussed in section 1.1.2 - these would all need to be addressed for
requirements, while recognising the different criticality of sub-systems between different UAV
systems - this will be a major challenge.

21
Operations Certification
Marsters [Mar03] provides the overall context of operations certification. He suggests that
any operator of UAVs wishing to routinely undertake missions in unsegregated airspace will
apply for a UAV Operating Certificate from the relevant regulating authority, and that this
application will provide "documented evidence of organisational competence and system
safety", entailing:
o a description of the applicant organization, including relevant qualifications of
competent technical and operational staff;
o a full safety history of the vehicles to be used and of the fleet of this same type;
o a global safety analysis for the combined vehicle - mission types;
o a full description of the design standards used for all flight-critical UAV systems (see
Part 4, below);
o manufacturer's Flight Manual and manufacturer's Maintenance and Inspection
Manual (see Part 5); and -
o A Flight Operations Manual for the operating organization, including specification of
the required qualifications and levels of training and proficiency for crew members
(see Part 3, below).

This seems to provide the overall basis for a safety argument for the system in its intended
use - while not as fully integrating as a safety case would be, elements such as the 'global
safety analysis' mentioned above should help to bridge the gap between the bounded design
certification discussed above and the actual usage of the system.
The Joint UAV Task Force [UTF04] took a fresh look at operations certification. Their review
included: a brainstorming of particular aspects of UAVs that might not have a parallel in
existing regulations for manned aircraft; a review of existing JAR (now EASA CS) regulations
on operations, maintenance and licensing; and where available a review of EASA regulatory
material. Once again, their standpoint is that existing certification requirements should be
applied wherever possible - but then they identify many areas where this is not possible! For
licencing of personnel, they proposed that it would be possible to modify existing
requirements. But for operating aspects, EASA OPS-1 did not seem to offer equivalent types
of operation (aerial work such as filming, agriculture, customs and police work are all
excluded); similarly for maintenance operations EASA CS145, 147 and 66 did not always fit
easily with UAV operators providing continuing airworthiness for systems undertaking the
type and variety of work expected. The study concluded by reiterating that existing
requirements should be used wherever possible - a not wholly useful conclusion, but it might
be assumed that the intent is to use the existing requirement as a start point and extend it to
cover appropriate UAV characteristics and operations. The CAA [CAA04] do not get much
beyond this principle, suggesting it apply across the board to maintenance and continuing
airworthiness, organisation and personnel licensing, and approval to operate.
Standards
DeGarmo ([DeG04] section 2.4.2) takes a broad look at the current initiatives on standards,
and some of these are discussed below. He notes activities by US DoD and North Atlantic
Treaty Organisation (NATO), the American Institute of Aeronautics and Astronautics (AIAA),
ASTM International, the UK UAV Safety Subcommittee (Ministry of Defence (MoD) and
industry group) and RTCA; but he voices concern that there is a competitive spirit between
these schemes, and while the current lack of standards makes regulation difficult, a plethora
of different standards would not help either. He identifies that the US government have
mandated that global, consensus-based standards should be adopted wherever available,
rather than developing government specific requirements.

22
ASTM International (originally the American Society for Testing and Materials) are one of the
groups trying to establish suitable consensus based standards for UAVs. In [AST04], their
Statement on the role of ASTM International committee F38, they discuss the intent to raise
standards to cover: Airworthiness; Flight Operations; Operator Qualifications. In line with the
US Government requirement (and also, as discussed above, with EASA and CAA principles),
these standards are to be established on the prioritised principle of: Adopt; else Modify;
else Create as appropriate to suit UAVs. As they note in their review of the US DoD 2005
Roadmap for UAV development [AST05-1], standards play a major role within the roadmap -
without standards it is difficult to build regulation. One of F38's first priorities was to establish
requirements for Sense and Avoid capability (see 1.2.3)
RTCA Incorporated (originally the Radio Technical Commission for Aeronautics) is another
American society aiming to produce consensus-based standards, but is perhaps closer to the
federal government (without being an actual government body). This is particularly true for
UAV standards activities of Special Committee SC-203, as it was set up with duel
sponsorship from the Aircraft Owners and Pilots Association (AOPA) and the Federal
Aviation Authority (FAA), to consider the standards required to support UAV operations
within the National Air-space (NAS). In the terms of reference for SC-203 [RTC05], their
objective is set out to produce key supporting standards documents:
o A. Guidance Material and Considerations for Unmanned Aircraft Systems (UAS) – to
provide a definition of UASs, the NAS environment, and taxonomy of UAS
terminology.
o B. Minimum Aviation System Performance Standards (MASPS) for Unmanned
Aircraft Systems - containing quantitative performance standards with specific focus
on UAS level operational performance.
o C. MASPS for Command, Control and Communication Systems for Unmanned
Aircraft Systems - recommended standards for command, control and communication
systems used in conjunction with UAS operations: addressing (but not limited to):
Human Factors; Reliability; Data Links.
o D. MASPS for Sense and Avoid Systems for Unmanned Aircraft Systems -
recommended standards and procedures for UAS sense and avoid systems,
providing a safety level equivalent to that for manned aircraft operations. This will
address: Reliability Factors; Traffic Avoidance; Data/Communication Links;
Operational Safety Considerations (see section 1.2.3 in this paper).

The Terms of Reference note that SC-203 is not a joint committee with the European
Organisation for Civil Aviation Electronics (EUROCAE), but does at least indicate that they
will liaise. EUROCAE has recently formed its own Working Group (WG-73) to provide
support to introducing UAVS safely into integrated airspace, and ensure compatibility with
existing infrastructure and systems. In particular, it is to help bridge the gap between existing
and necessary regulation and standards, to allow integration. WG-73 will look at a broad
spectrum of issues, including: Operations; ATM; Airworthiness and Safety; Test and
Maintenance. The working group is intended to draw together the various international
initiatives (European and US) and includes setting up joint activity with RTCA. Perhaps this
will help to establish a more joint approach to regulation and standards than is currently the
case.

1.2.2 ATM interaction

This section looks at the safety issues relating to interoperability of UAVs with Air Traffic
Management (ATM) - particularly the personnel and technical systems. As DeGarmo notes
[DeG04 section 2.3.1] a key part of understanding the concern this aspect causes is that,
because of current segregation, very few UAVs have interacted with Air Traffic Control

23
(ATC) and the ATM system, it is difficult to predict what the real impacts might be. He
postulates that it may be more an issue of uncertainty than any specific technical challenge.
As I suggested previously (section 1.1.1), when people are faced with the unknown, they
seek to impose their existing understanding and regulations upon it. Let’s look at some of
the specific issues.
The Requirement for 'Transparency'
The CAA's CAP722 Guidance for UAV Operation in UK Airspace [CAA04] sets the tone that
is common to a lot of other authorities: "UAV operation is expected to be transparent to Air
Traffic Service (ATS) providers. The UAV-p will be required to comply with any air traffic
control instruction or a request for information made by an ATS unit in the same way and
within the same timeframe that the pilot of a manned aircraft would." I.e. that the only
difference an Air Traffic Controller would notice would be the 'UAV identifier' on his screens.
But is this level of transparency feasible? We have already looked at some ways that UAVs
are basically different from manned aircraft (section 1.1.1), so what are the implications for
mixing them with the existing ATM elements?

ATC Systems

ATM in most developed countries has well established technical systems to assist ATC to
track aircraft, request information from and pass instructions to the pilots of manned aircraft.
How well can UAVs fit with these systems? Marsters & Sinclair [Mar03 part 3] in 2003 was
suggesting a requirement for Transponder Mode S in Canadian domestic airspace, to allow
ATC to interrogate / track UAVs; and the CAA [CAA04] and EUROCONTROL [UTF04] both
specify an impressive list of required equipage, to be consistent with existing levels for
manned aircraft in particular types of airspace. But UAVs (particularly the smaller types) will
struggle to comply because of limitations of space, payload or even the available power.
DeGarmo [DeG04 section 2.3.5] takes up this issue of equipage, but focusses on the
navigational requirements. With incoming Area Navigation ('RNAV') procedures, regulations
generally state that aircraft must "retain the capability to navigate relative to ground-based
navigational aids" such as Very High Frequency (VHF) Omni-Directional Range (VOR) for
certain airspace types. However, most UAVs use GPS in isolation, and would not be able to
carry VOR fit. It may be that UAVs will need the eventual back up of the European Galileo
and Russian GLONASS systems to provide the required reliability to satisfy the authorities
on navigational reliability in controlled airspace [Bon05] (i.e. Group 4 and 5 UAVs as defined
in section 1.1).
[DeG04 section 2.3.1] extends this discussion to consider the Air Traffic Controller's display
information. Because UAVs have different characteristics (see Section 1.1.1 of this report),
he suggests that it is likely that they will need some specialized attention - hence unique ID
or symbol on display. He takes this first simple idea further by proposing that it may also
prove valuable for ATC to know if the UAV is under manual or autonomous control; maybe
even the need for a separate location / registration for the GCS, in case ATC need to speak
directly with the pilot (while it is not discussed, I would propose that this would be even more
crucial if the same GCS has control of several UAVs - the need for ATC to talk to the 'control
node' if one or more of the associated UAVs acts out of turn).
[DeG04 section 2.3.2] also turns around the issue of ATM system integration in noting the
need to ensure not just system compatibility but also interoperability - that UAV and ATM
systems do not interfere with each other. In section 1.1.2, we considered the issues
around datalinks spectrum availability, but there are broader EMI effects due to the high-
power nature of some of the ATM ground based systems (such as Precision Approach
Radar) that the system will need to be proofed against.

24
Voice Commands
In Marster's suggested flight approval process, put forward in 2003 [Mar03 part 3],
he suggested the requirement for 2 way communications between ATC and 'vehicle
commander', to allow flights in domestic Canadian airspace. Most proposed regulation since
[e.g. UK in CAA04, Australia in CAS04] has similarly stipulated or assumed direct voice
communications between ATC and the UAV pilot or controller. DeGarmo, once again
[DeG04 section 2.3.4], takes up the practicalities of this proposed requirement, noting the
need for ATC compatible VHF radios for voice comms. This is quite an overhead, as the
UAV has to carry two radios (usually) to allow receiving of the voice comms from ATC (say)
and simultaneous onward transmission to the GCS (and vice versa). DeGarmo suggests
that in the long run, it would be useful have ATC comms 'split' with both an air transmission
and a ground relay direct to the GCS - but while this would improve reliability (less
transmitters and receivers than needed at present) it would require significant resource to
build up such an infrastructure, and it is hard to see how cash-strapped ATM services would
jump to provide this until the requirement on them was made explicit.
All of the writers above have made an implicit assumption of the system - that voice comms
must be relayed to the ground pilot. However Schneider [Sch04, chapter 6] takes a different
view and instead urges the US to push research to allow UAV autonomy, through airspace
situational awareness and speech recognition of ATC voice commands. Particularly where a
single GCS has overall management of a number of UAVs but each has a measure of its
own autonomous control, this must be the eventual approach, with each UAV having the
ability to understand and communicate in speech, just as it will have in other information
forms.

The expectations of the Air Traffic Controller

Lets turn to look at the human side of the ATM system, and especially how the ATC expects
the UAVS to react in a 'transparent' manner. As we noted above in the introduction to 'The
Requirement for Transparency', there are some aspects of UAV behaviour and
characteristics that are plainly different to manned aircraft - how can these truly be absorbed
into the existing ATM system? Some aspects we have discussed elsewhere, in particular the
ATC expectations with regard to UAV characteristics (see 1.1.1), Airmanship (see 1.1.4),
and Collision Avoidance (see 1.2.3). Here we look more generally at ATC expectations of
UAVSs.
Marsters and Sinclair [Mar03 part 3] proposed that UAV operators would need a suite of
Standard Operating Procedures covering all normal and abnormal flight conditions: the
review and approval of these procedures by the ATM authorities would then form the basis
for approval of that operator to conduct UAV flights. The CAA [CAA04] follows this
approach, with similar requirements for a suite of procedures to foster planning and
authorisation. This seems to be the general civil way, and we have already looked into this
in section 1.2.1. DeGarmo [DeG04 section 2.3.1] looks more specifically into the procedures
and expectations for conduct of flight in controlled airspace (such as might affect a Group 4
or 5 UAV). He suggests that where there are existing ATM procedures and routes (e.g. for
Instrument Flight Regulations (IFR) ascent through airspace), these will have been built
around the expected performance capabilities of manned aircraft - some UAVs will fit in this
envelope, but others won't: thus, the ATM will either have to exclude them (not optimum for
our vision of integrated airspace), or develop new routes / procedures to accommodate these
specifically. DeGarmo's study also considers a UAV specific hazard, due to their sensitivity
to wake turbulence (particularly the lighter wing loading of Long Endurance UAVs); current
vertical separation minima may be inadequate for these UAVs, hence they could require
special treatment in order to fly safely along existing corridors.
While most regulators are busy hammering home their requirement for transparency from the
start, the Swedish Aviation Safety Authority seem more willing to take a practical approach in

25
these early days of integration. In the paper proposing the Swedish approach until the EASA
regulations mature, Wiklund [Wik03, section 3] proposes that, initially, it will be useful for
'special Air Traffic Controllers' to be lent to UAV programmes, to provide specific attention to
separation of UAVs from other traffic - in this way, experience can be built for both UAV
operators and the Controllers. This approach seems ideal as an answer to DeGarmo's point
noted at the very beginning of this section that most issues may be due to inexperience and
uncertainty, rather than hard technical concerns.
The Demands of Increased Traffic
Even without the addition of UAVs, ATM systems are facing the problem of trying to reduce
aircraft accidents while the number of manned aircraft looks set to increase significantly over
the coming years. How will UAVs add to this? DeGarmo [DeG04 section 2.3.8] says the
answer is... that we don't know! We need to study the effect of UAVs on airspace (and
controller) capacity, including simulation of UAV numbers and looking at how different types
of UAV and their varying performance characteristics affect the balance (see section 1.1.1 of
this report). Factors such as the incredible endurance of some types (from 30 hours up to
months at a time) mean that there aren't just more aircraft (with UAVs) but they are airborne
and loading the system for much longer.
Emergency Procedures
ATM systems set particular store in contingency planning, especially how to handle particular
risks associated with aircraft, such as propulsion failure or communications loss. How will
UAVSs and ATMs interact for UAV emergencies?
Marsters [Mar03 part 3] suggests that UAV operators establish procedures for dealing with
Loss of Control Datalink - flight profiles, recovery areas, diversionary airfields if appropriate.
Other critical failures that could require Abort and Flight Termination procedure (a UAV
unique feature discussed in 1.1.1) need to be established and briefed to ATC. He also states
that the UAVS should have the capability to allow the UAV commander to squawk an
emergency code independent of the vehicle itself, to allow independent broadcast of the
emergency state to ATC and all potentially affected traffic. This seems like a good idea at
first, but perhaps should be reflected on after consideration of the particular failures that
might affect a specific system - e.g. a highly autonomous UAV could fly on perfectly safely,
perhaps, without the need to 'frighten the locals' in the event of a communications failure. I'm
not sure if DeGarmo is hinting at this [DeG04 section 2.3.1] when he states that "The
procedures to be taken by the vehicle will need to be communicated or predictable to the
controller." I take this to mean that the procedures may be specific to a particular UAVS and
its capabilities, provided that they are then made clear to ATC personnel who may interact
with it. DeGarmo does try and standardise some of the emergency procedural aspects of
UAVs [DeG04 section 2.3.7] by suggesting that aspects such as designated flight termination
areas be declared and coded into available ATM databases, to ensure all are aware and plan
accordingly. This would go a long way to make the common elements of UAV emergency
procedures become second nature to operators and ATC alike.
Airfield Operations
A significant aspect of ATM interaction can occur before the UAV even leaves the ground.
How does the 'unmanned ground vehicle' cope with taxiing, braking, etc in a ground
controlled environment such as a shared airfield? DeGarmo [DeG04 section 2.3.9] suggests
that because taxiing requires precise ground movements and the ability to search for
obstacles, most current UAVs lack this and so are towed out to the Take-off position / back
from the landing position. While simple for the UAV, this must increase the risk to the
ground-crew and slow down operations - future UAVs will have taxiing capability, there can
be little doubt. Part of the problem is for the UAV to recognise visual signals such as traffic
lights for manoeuvring, as noted by the Joint European UAV Task Force [UTF04 section
7.18]. They suggested that UAVs need a Ground Operator to interpret for the UAV and
intervene. In a telephone call with Parc Aberporth Operations Manager, it was confirmed

26
that recent UAV operations had been achieved by towing the vehicle out to the launch point,
thus avoiding the issue, but that proposed UAVs had a taxiing capability and that it was
considered that a Ground Operator would look after the vehicle in the confines of the airfield
(on the ground or on Take-off up to 50ft) then hand over to the main GCS for the remainder
of the sortie. In the longer run, it is perceived that new UAVs will require autonomous ground
operations to maintain the airfield movement tempo at busier airfields - this may even prove
safer than manual control, as some high profile manned aircraft accidents (such as at
Tenerife) have unfortunately shown.
The paragraph above noted that current UAVs generally use manual take-off and landing. In
the very near future, automatic TO/L systems are expected to be introduced. [DeG04] and
others suggest that Differential GPS (DGPS) will be a key technology, as plain GPS will not
be precise enough.
One last aspect of UAV airfield operations concerns landing at diversionary airfield - will they
be able to cope? The ASTM [AST05, 2], in their study noted the lack of standards to define
how airports should deal with UAVs, in the event that they became an unexpected
diversionary. Suddenly, an airfield might find themselves having to cope with the various
issues noted above. Again, I suspect that this is really an issue of inexperience: in most
cases, operators will file a flight plan and declare the diversionary airfields that they may
have to use. Just as a civil Boeing 737 operator would only nominate a known 737-
compatible airfield, the same would surely be true of a UAV operator, and part of planning
will be to liaise and agree on diversionary procedures and facilities (as noted in 'Emergency
procedures' above).

1.2.3 Collision avoidance

The reader might wonder why there is a specific section on 'collision avoidance', when it
seems that the majority of the other sections have already focused on safety issues relating
to potential collisions. The reason is that, as Platt implies in his paper [PlP05], international
regulators have followed a philosophy of layered defences to avoid collision risks. Platt talks
of three layers that must be provided and prove independently effective (i.e. faults in one
layer cannot be offset intentionally by dependence on another layer):
1. The outermost layer - strategic conflict management - is achieved through the overall
structuring of airspace by type (to separate aircraft classes and capabilities) and use
of ATM to maintain efficient flows and manage the overall traffic structure.
2. The middle layer is separation provision. This layer exists to ensure that separation
minima are maintained if strategic management has been compromised. This is
achieved through declared separation minima (to ensure adequately low risks),
regulated Rules of the Air for flight planning and Rights of Way for airmanship, and
specified equipment lists to ensure navigational accuracy and aircraft detection.
3. The innermost layer is collision avoidance. At this point, safe minima have been
breached, and the successful outcome is simply to achieve a miss through
emergency action. This is (currently) achieved for manned aircraft through visual
lookout and gradual introduction of assisting systems such as Traffic Alert & Collision
Avoidance Systems (TCAS).

Layer 1 is strongest (i.e. it is mandatory) in controlled airspace (class A-E in the UK FIR - see
'Note on UAV classification' in the introduction to the Literature Review), and is advisory
where available in Class F airspace. In Class G, the home of most General Aviation, conflict
management relies on layer 2 initially, and if this breaks down, then layer 3 is required to
independently maintain safety. UAVS issues pertinent to strategic conflict management and
separation provision are discussed in the other sections of this report. This section mainly
focusses on collision avoidance as defined above.

27
Ground Collision Avoidance
Ground collision avoidance (or terrain avoidance) is somewhat the 'poor man' of UAVS
literature, and not a lot is said about it in any detail. Perhaps this is because it is considered
to be better understood, with more easily identifiable criteria drawn from manned aviation.
The CAA in CAP722 [CAA04] merely state that an approved method of assuring terrain
clearance is required, but do not give specifics. We could assume that the requirement is
for 'equivalence' with methods in use in manned aircraft. This is supported by the
EUROCONTROL position in [UTF04], which implies this by reference to existing Ground
Proximity Warning Systems (GPWS).
The Australian and Swedish regulations ([CAS04] and [Wik03] respectively) do not go into
detail about terrain avoidance so much as population avoidance. Both establish restrictions
for flight over populous areas; the Swedes justify this position with details of their calculations
for acceptable levels of ground fatalities (see section 1.1.4).
Most literature tries to lump ground collision avoidance into what they consider is the bigger
problem of air-air collision avoidance. Whittaker [Whi05], DeGarmo [DeG04] and Platt
[PlP05] infer that ground avoidance will be solved as part of the wider 'sense and avoid'
debate (see below). I suggest that this is somewhat simplistic, because down in the detail,
characteristics for ground / obstacle target detection will be very different from point air
targets, and the technical solutions and airmanship requirements will be likewise quite
different. Fairly simple ground collision avoidance may be achieved, for example, through
GPS and terrain database use (such as existing GPWS) - and this may be achieved in the
UAV, or possibly in the GCS by relating the UAV's telemetered position. Some discussion
over the acceptability of such solutions is presented in section 1.2.2, under ATC Systems.
Air-Air Collision Avoidance

Airmanship & Situation Awareness

We have already mentioned the role of procedures and regulations in the layered approach
to conflict management, and this continues into the collision avoidance inner layer. The Joint
European Task Force review the arrangements in [UTF04] - these are summarised here as:
ICAO establish basic Rights of Way (RoW) for aircraft depending on their class, airspace and
attitude; pilots are expected to respect these RoW using airmanship, in order to either stand
on or take avoiding action as appropriate to the RoW. In the last-ditch event that the
appropriate aircraft does not take action, the stand-on aircraft must take emergency evasive
action anyway, to suit the particular collision situation. This implies that, in order to respect
the RoW, the UAVS must be aware of its situation in terms of the factors that determine who
has right of way, and be able to react accordingly.
In CAP722 [CAA04], the CAA list a number of factors that affect the outcome in any
particular collision avoidance scenario. The situation will vary depending on: whether all
involved aircraft comply fully and correctly with the Rules of the Air; the controllability and
manoeuvrability of each aircraft and their respective flight performance; the level of
autonomy of operation and control (in terms of the involvement (or not) of a ground pilot). In
general, these aspects for UAVs are discussed in sections 1.2.1, 1.1.1 and 1.1.3
respectively, but it is important to note their implications at this safety critical situation.

Conspicuity - being seen

In order that other aircraft may respect the UAV's position to the RoW, they need to be able
to see the vehicle and its attitude. This issue is identified by the Swedish Aviation Safety
Authority [Wik03]. Will other traffic be able to see the UAV? Will the UAV carry enhancing
equipment (e.g. transponder, warning lights)? DeGarmo [DeG04] also identifies this

28
issue. Many UAVs are fairly small making them tricky to see, and even if seen can prove
difficult for the other pilot to judge their distance and closure rate.

Seeing and Reacting - Detect / Sense & Avoid

The Rules of the Air set requirements for aircraft pilots to See and Avoid other aircraft
according to the established RoW, as discussed above. Here is the crux of the issue - it is
generally believed that the UAV-p cannot adequately provide this function, as he will not
have the required field of view and because of the complexity of the data link and control
latency ([LeT02]). Currently, there are no approved collision avoidance systems suitable for
'Sense and Avoid' (the non-human equivalent of See and Void) and no accepted criteria
against which to develop such technology, and this is the main impediment to UAV
integration into manned airspace ([Ste05]). The issues that lead to this state of affairs are
discussed below.
In CAP722 [CAA04], the CAA provide a list of 'Sense and Avoid' (S&A) factors, most of
which are generally applicable to UAVS operation in all layers of conflict management. The
document sets the requirement for a 'Method of sensing other airborne objects' but then goes
on to say that it is not possible to define suitable criteria for a Sense and Avoid system, until
suitable technologies and their capabilities start to emerge in more detail. The best that they
can currently suggest is to seek an Equivalent Level of Safety as for current manned aircraft.
Schneider [Sch04] on the other hand, pushes the US government to support development
and validation of robust 'Detect, See and Avoid' (DSA) requirements first, before trying to
develop technology solutions. Personally, I feel these things must happen in parallel -
requirements for specific classes of UAVs could be worked up through modelling, but need to
be tailored with the art of the possible, as development of possible technologies yields
information on likely sensor performance. In this way, an effective sense & avoid capability
might be achieved by using a combination of methods, rather than coming purely from a
requirement or single technology focus. More is discussed on criteria, below.
Marsters, in his earlier attempt at defining UAV regulatory requirements [Mar03], notes the
problems with setting the baseline as 'ELOS' to manned aircraft, due to the examples where
this has gone catastrophically wrong in the past. He calls for UAVs to be equipped with the
emerging technologies of the day - TCAS and GPS-based Automatic Dependence
Surveillance - Broadcast (ADS-B). But this is only part of the problem solved. DeGarmo
[DeG04 section 2.1.1] notes that such existing systems can help detect co-operative aircraft,
i.e. those carrying the required systems and transmitters to make their whereabouts known:
but to be allowed into all classes of airspace, UAVs will need to be able to sense and
avoid non co-operative objects, such as most general aviation, microlights, even birds and
ground obstacles such as masts. DeGarmo notes the activities of ASTM and RTCA to try
and establish suitable criteria for such non co-operative S&A systems, to provide ELOS to
manned aircraft (see section 1.2.1). The paper looks at some developing technologies,
discussing aspects such as field of view, detection ranges, false alarms, and performance in
reduced visibility (though how does this compare with the human pilot's capability in such
conditions?). Conversely, it notes that, if the Sense & Avoid is not entirely provided on-board
but requires interaction with the GCS, then there may be issues with decision making and
data latency.
This is a timely point to discuss the shortcomings of manned See & Avoid. As noted by
Marsters, in his paper with Sinclair [Sin03], there is a useful consideration of manned See &
Avoid, and reference to work on the shortcomings of the unaided pilot. Marsters and Sinclair
argue that UAV Detect & Avoid (or Sense & Avoid) must outperform human equivalence to
ensure safety - though a fair portion of this may come from the fact that technical systems
will provide constant scan, rather than being distracted as the pilot often is. In their review of
a number of studies, results were showing that the performance of an 'alerted pilot' averaged
about 1.6nm detection range, while modelling of Global Hawk closing speeds,

29
manoeuvrability and datalink lags was suggesting a required detection range of ~7nm. This
will vary considerably depending on the UAVS and whether the avoidance manoeuvre is
initiated by the vehicle itself or by manned intervention, but show that a simple ELOS will
pose some difficulties.

1.2.4 Security and safety

There is no doubting the increased awareness over security issues that affects aviation
generally, since the events of '9/11' in 2001. But some suggest that UAVs potentially pose an
increased risk, due to vulnerabilities that we will look at below. Some have even
suggested that UAVs have an added 'attractiveness' for malicious terrorist use, because of
their unmanned nature [UTF04, 7.15]. Whether these suggestions are realistic or not, the
fact is that security is a critical issue that UAVs will have to prove they have mastered, before
being allowed into potential threat areas.
The suggested areas of concern all stem from the expanded system boundary that
encompasses the UAVS as a whole (which we have already discussed in section 1.1.2). Let
us now look at the impact of the external, malicious world on the system of systems.
Jamming of Navigation Systems
Although talking primarily about military applications, the Defense Science Board study
[Sch04] raises the valid point that most current generation UAVs use GPS based navigation,
and urges the fitting of jam-resistant GPS as a matter of course. Unless suitably hardened,
civil UAVs could likewise suffer loss of their sole position fixing capability, with potentially
critical consequences.
Communications Signal Security
As the Joint European UAV Task Force note in [UTF04, 7.15], UAVs are currently (and for
the foreseeable future) dependent on the integrity of the command datalink (see discussion
at section 1.1.2). Maintaining integrity from blunt jamming tactics down to more subtle
spoofing or stealing of control will have to be addressed. DeGarmo [DeG04, 2.2.2] suggests
that modern encryption techniques and user authentication methods can help with the latter,
but would not be able to assist against high-power jamming. He also suggests (sensibly) that
UAVs will benefit from other signal-based industries which are working to obtain secure
communications techniques.
None of the papers reviewed discussed the basic visibility of the signal to unwanted parties -
an aspect of security can be to use specific frequencies to minimise 'broadcast' of the UAVS
operation, or frequency-agile systems that both minimise possibility of detection, and reduce
the effect of jamming to those frequency segments in-band.
Ground Infrastructure
This aspect relates to the simple physical security of the ground-based elements, of which
there may be many in an extended system of systems. DeGarmo [DeG04, 2.2.1] states that
this has seen little interest shown by UAV operators to date, but could be a major and direct
way to affect or overthrow the control of the UAV. This would be particularly true for mobile
systems (having less opportunity for fixed barrier based security); and for distributed systems
with control elements located at various points around the world (such as recent US Predator
operations in Iraq, controlled via datalink from Nevada but with Iraq-local control elements
involved also).
Flight Planning and Data Security
DeGarmo [DeG04 2.2.3] goes on to consider the security implications of the data elements of
the UAVS. All manner of digital data is involved in a successful UAV operation, from the
databases used to plan missions and avoid terrain, to the specified flight plan itself,
the coding of ground and UAV control functions, etc. The US (and UK CAA repeat the

30
requirement in [CAA04]) require security of systems to detect and counter all attempts
to corrupt critical systems and data before / during / after loading.

1.2.5 The Human Element

There are human aspects cutting across many of the other issues we highlight - in ATM
(section 1.2.2), collision avoidance (1.2.3), security (1.2.4), and notably in our discussions
over UAV accident rates (1.1.4) and the man / machine boundary of autonomy (1.1.3). In
this section we focus specifically on the human element of the UAVS. From very general
Human Factors issues, we extend the discussion to cover organisational issues and then
personnel qualification and skill levels.
Human factors

We have already looked at UAV accident rates, in section 1.1.4. There, we noted
DeGarmo's assessment [DeG04, 2.1.3] that Human Factors (HF) accounted for some 17% of
the UAV accidents where information was available. He commented that this was lower than
the comparable figure for manned aircraft (~80%) and seemed to be proportional to
automation levels and (where responsibility lay with the UAV-p) the datalink update rates.
The dominant Human / Machine Interface (HMI) aspects related to: the ground 'cockpit'
environment; the available cues from the UAV and displays; the UAV-p skill levels; levels of
situational awareness and a suggestion that the low personal risk to the UAV-p removed him
somewhat from trying to recover difficult situations. Schneider [Sch04, chapter 3] suggests
that the majority of UAV mishaps were due to the relatively low experience level of operators
& maintainers, and LaFranchi [LaF05-2] echoes this with his account of Canadian Army
experience with deploying the Sperwer system in Afghanistan. After only a short training
course, they found themselves having to adapt their training to a new and hostile
environment. In the second of 2 crashes (in 3 months), the GCS took manual control on
approach to land and flew the vehicle into a ridge, in spite of a ground proximity alarm
sounding for some 30 seconds before impact, and there being 4 personnel in the GCS
including a certified manned aircraft pilot.

The JAA / EUROCONTROL Task Force cover HF as a specific discussion topic, focusing on
the HMI ([UTF04, section 7.10]). They saw issues with the lack of physical (and particularly
visual) cues that allow the pilot on board to recognize some failure scenarios and to decide
the suitable decisions and actions to take. They were also concerns at the current shortage
of experience in civil UAV operations, which compares well with Schneider's and LaFranchi's
concerns noted above.

However, Williams [Wil04] believes that it is difficult to draw general Human Factors
conclusions, because the HMI is so very different between systems. He could not find
consistent HF causes between the US military accidents that he analysed (see more general
discussion in section 1.1.4). He does, though, raise two interesting points at different ends of
the human factors / automation / airmanship spectrum:

o Predator is a UAV which acts very much as an RPV - it is 'flown' by a pilot using
cockpit-type controls from the GCS, using a camera in the UAV to present a 30
degree forward view to the pilot. Predator suffered the highest percentage HF
accidents (~65%) of the 5 systems he analysed.
o Global Hawk is another US Air Force UAVS but is very automated with the UAV-p
merely monitoring the aircraft progress. Global Hawk had relatively low HF accidents
(~30%). However, the system is automated through fully pre-programmed missions
from take-off to landing (rather than autonomous decision making) and the planning
for a mission can take up to 270 days to achieve. Hence there have been HF

31
 accidents caused by small but significant errors buried within the complex mission
planning.

Human Factors is a tricky issue for UAVS, due to the complex system boundary, and in
particular due to the growing influence of autonomy. In part, this is necessary to offload the
pilot and allow aspects such as multiple UAV operation (see 'autonomy v ground control'
in 1.1.3). Nevertheless, we should not forget that accidents can occur when the human
operator does not understand what the highly automated system is doing, and tries to
override it with disastrous consequences. This key issue is discussed in several York
Advanced MSc course modules (Human Factors Engineering (HFE) and Foundations of
Safety Engineering (FSE) especially).
Organisation
In section 1.2.1 (Regulation etc), we noted the EASA drive [EAS05] for 'Total safety' as
shown in Figure 1.2.1a. This clearly indicates the involvement of the operating organisation
and personnel, in the safe maintenance and operation of the UAVS. In 1.2.1 we discussed
the push for 'equivalence' with manned aircraft based regulation, where here we try to
discuss the inherent safety issues.
Marsters [Mar03] assumes that an applicant for a UAV clearance will have already obtained
a UAV Operating Certificate covering global activities for his system, with an approved
organisation and competent staff / operators, vehicle safety history and analysis, design
standards, operating manuals, etc. He does not explicitly discuss why these are required.
EASA and the Joint European Task Force discuss organisations [UTF04 section 6.3.3.3] but
do not get beyond the requirement for equivalence to manned systems and application of
licencing regulations. The CAA likewise in [CAA04] state requirements against existing
regulation.
The Swedish Aviation Safety Authority also discuss organisational requirements [Wik 03],
initially suggesting parity between UAV and manned aircraft organisations, but then
suggesting that there could be flexibility - the UAV system operation organisation
requires proportionality with the UAV system complexity and operating conditions - simpler
systems and environments would allow simpler organisations. Wiklund suggests that the
organisation will probably vary at different stages of a project. "During the design stage the
emphasis may for example be on technical competence with advisory operational
competence, while in the test stage further practical operational competence will be added
and in the operational stage the emphasis will be on practical operating competence." It is
clear that the drive here is for competence within the organisation, with experience, to be
able to recognise and resolve the safety issues arising at that point in the programme.
Schneider [Sch04] sees the organisation playing a key role in addressing the HF safety
issues noted above, due to low experience among UAVS maintainers and operators. He
pushes the US government that operator and maintenance organisations should explicitly
plan for the recruitment, training, career development of personnel to improve retention of the
experience necessary to operate UAVS safely. Schneider suggest that military organisations
currently do the very opposite, by forced posting and promotion of experienced operators out
of the organisation.
From the literature reviewed, there did not seem to be specific organisational issues related
to UAV operation and maintenance, other than that noted by Schneider, above. Else, the
literature was driven by the requirement for equivalence with manned aircraft, on the read-
across assumption that a competent organisation (with competent personnel and appropriate
procedures and plans) supports the overall aims for safe UAV operation and maintenance.
However, from our discussion over aspects such as ATM (1.2.2) and the complex system
boundary (1.1.2), I would propose that there could be issues related to the transfer of data
between organisations, to support accurate mission planning, establishment of appropriate

32
emergency procedures, etc. What is a safety issue is thus the complex organisational
interfaces within the overall system of systems.
Suitably Qualified and Experienced Personnel

Experience levels among personnel are clearly an issue, as noted in both sub-sections
above. Here we discuss the qualification aspect of their necessary competence.

The CAA in CAP722 [CAA04] discuss the UAVS 'crew' consisting of a UAV commander and
(potentially) one or more UAV pilots (UAV-p). While the UAV-p is a qualified person who is
actively exercising remote control of a non-autonomous UAV flight, or monitoring an
autonomous UAV flight, the commander is the person charged with overall responsibility to
the CAA: he assumes the same operational and safety responsibilities as the captain of a
piloted aircraft performing a similar mission in similar airspace. Hence the commander must
be qualified to meet manned aircraft equivalents for the airspace and meteorological rules
that the UAV will operate within, while the UAV-p may be less stringently qualified to meet
the training, experience and currency requirements set out by the organisation. This would
allow UAV operation in accordance with current military training regimes, where the UAV is
controlled by an operator who may not have manned aircraft qualifications but who can direct
the UAV to a specific location (rather than fly it manually using traditional controls) - but
would require an overall commander to oversee and ensure safe operation in accordance
with the Rules of the Air. The Australian Civil Aviation Safety Regulations in CAS 101
[CAS04] have rolled out a similar view of pilot certification. The issue here might be how
many UAV-p could safely operate under one commander, while ensuring safe operations.
The issue is heightened when a single UAV-p could conceivably be controlling more than
one UAV, due to the apparent simplicity of the interface. DeGarmo [DeG04, section 2.4.5]
picks up on these aspects. He says that UAV-p certification is not simple, because of the
variation in UAVS and their operating intent: simple UAVs may act like model aircraft, staying
within visual contact; others will be operated beyond Line of Sight, possibly in swarms of
multiple UAVs; some will require direct pilot-like input as RPVs; others will have automated
systems requiring only location designation, or even be operating near-fully autonomously.
While the UAV design will force part of the training regime, predominant factors might be the
outside world, e.g. the operational environment (other traffic, ATC, etc). DeGarmo suggest
that a similar licencing system could be operated to that currently for aircraft pilots, where
specific ratings are earned appropriate to the type of aircraft being flown and the type of
operation to be undertaken. This would, he says, require extensive tailoring to suit UAV
differences (as discussed in 1.1.1). DeGarmo finishes with a discussion of the role of the
UAV-p compared to the commander (or controller as he calls it). While this is a potential
solution to the training / skills issue, he implies that it is another interface that would need
careful implementation.

1.2.6 Public perception of UAV safety

As we touched on briefly in Section 1 under 'Current and Future Directions', the pull of the
market for civil use is still uncertain, and gaining public acceptance of the safety of UAVs will
be an important part of any success. So what is the public perception?
The CAA has, so far, taken a 'gut instincts' view that the perception is at best neutral and at
worst fearful / mistrusting. Whittaker in [Whi05] looks briefly at potential ground and air
collisions featuring UAVs: in the former, he contrasts the manned aircraft ground collision
headlines ("AIRCRAFT CRASHES NEAR SCHOOL - Pilot swerves into trees to avoid risk to
children") with those for a UAV ("TERROR AS GUIDED MISSILE ALMOST HITS SCHOOL -
Shocked parents demand Public Inquiry"). For collisions in the air between UAV and
manned aircraft, he takes the view that such occurrences are seldom survivable for the
people involved, and the unmanned aircraft will doubtless be blamed by the public, no matter

33
what the reality of the situation. In essence, he is talking about a media led onslaught, (mis-)
informing a public with no alternative positive views of the benefits of UAVs.
DeGarmo [DeG04, Section 2.5.2] takes a broader view. He proposes that the public can be
courted with a reasoned debate over the benefits that can be gained (i.e., greater security,
improved information, more services, lower costs) versus the potential costs (i.e., increased
noise, pollution, privacy concerns, safety risks, delays) and that this 'marketing' will be a key
requirement to gain acceptance and enable market forces. However, he also notes that such
a build up of trust will take time and be fragile, as it would be easily damaged by any high
profile accident. He quotes a public opinion survey of air users in 2003, which stated that
68% were happy with the idea of UAVs for cargo and commercial use, but only a small
percentage would be happy to allow unmanned passenger-flying aircraft. While this, at face
value, suggests that people might be happy with the risk associated with UAVs flying
overhead, to me it implies that, as soon as the risk might actually impinge on them, their
acceptance drops massively.
In the end, then, DeGarmo under the microscope brings us to the same conclusion: that in
the event of an accident, the media will hold sway over any expert discussion over the
significance of risks posed by UAVs to the public, be they in the air or on the ground. UAVs
will have to prove themselves 'safer than safe' or face a similar bad press over safety as the
rail industry, say. However, there is some hope that the public will have been educated
beforehand, and the perceived benefits of UAVs will ultimately help restore confidence more
quickly.

34
1.3 Summary of UAVS Safety Issues
1.3.1 Review of current UAVS safety issues relating to integration into unsegregated
airspace
Sections 1.1 and 1.2 have covered a lot of issues with respect to UAV safety, and it is worth
summarising these here, before proceeding further. Note that ** indicates an issue that has
been taken forward in this project, as discussed in ‘Focus for Project Development’.
(1.1.1) Impact of the Variety, Roles and Performance of UAVs
1. UAV differences may introduce additional, unexpected hazards, for regulators trying
to pigeon-hole them into manned aircraft categories **.
2. UAV performance differences from manned aircraft make them difficult to manage in
a stream of manned aircraft traffic **.
3. UAV roles and missions make their behaviour unpredictable for manned aircraft traffic
/ ATC **.
4. UAV 'ad hoc' launch sites cause unexpected insertion into manned traffic.

(1.1.2) The complex system boundary for UAVs

1. Confusion over what the safety critical elements of a UAVS are (and then how to
regulate them, if not currently covered by manned systems): elements such as
datalinks, GCS, data flow around the UAVS, data sources outside the UAVS push
beyond current manned aircraft experience.
2. The need for reliable datalinks (including Over the Horizon), teamed with the
requirement to deal safely with datalink failure / corruption.
3. UAV sensors, datalinks, will compete for limited RF spectrum availability or face
interoperability / interference problems.
4. Use of Beyond Line of Sight datalinks to overcome terrain masking extends the
system boundary and hence the number of critical systems incorporated within the
UAV system of systems.

(1.1.3) UAV autonomy - technology, predictability, complexity

1. Current in-use definitions of autonomy level are over simplistic; but there is confusion
over what factors give a better indication of system authority. Some are very broad,
making it difficult to arrive at a clear indication (clear indication of autonomy level is
called for in various papers, to give visibility over who is in charge of the UAV in case
of emergency action being required).
2. Environment and mission context are proposed as drivers for required levels of
autonomy - how will the system respond if pushed outside its parameters?
3. Autonomy level should be varied ("traded") to suit the operator's needs throughout
the mission - will the operator know the extent of his control? Will the needs of the
operator align with the needs of the regulators to enforce human control?
4. 'Agent Based' autonomous control introduces new areas of uncertainty:
a. These are novel application in air vehicles and hence there will be issues of
expertise, trust and clearance
b. They require accurate capture and specification of the 'agent' behaviours
beforehand - issues of knowledge acquisition (and requirements elicitation -
see York module on RQE).

35
 c. There will probably more be than one 'AI' method used to implement the
decision making, and these will introduce new issues of architecture and
integration.
5. Autonomy through software will entail solving the usual issues over system
predictability. In particular, there may be difficulties trying to clearly separate safety
critical elements from other functionality.
6. The knowledge, judgment and skill ('airmanship') necessary to fly predictably and yet
flexibly to react to changing situations (such as weather) may be difficult to automate,
or even specify.
7. UAV autonomous decision making must somehow be matched to expectation of ATC
decision making tools (such as used to effect TCAS).
8. UAV actions in the event of datalink failure need to be predictable and dependable
(for ATM interaction), yet airmanship demands the ability of flexible response **.

(1.1.4) Accident rates and reliability - UAV airworthiness

1. The catastrophic failure rate for UAVs is currently too high.
2. There is little reliable accident data for UAVS occurrences - none sourced outside
military programs, research-based systems, in high risk (non-civil) usage, and even
that data is from a small sample compared to manned aviation data availability.
3. UAVs lack available, reliable system components (they currently have to use
research-standard equipment or COTS items operating outside their intended
environment).
4. UAVSs have not currently been designed, fabricated and maintained to manned
aircraft levels **.
5. It is difficult to define what the 'Equivalent Level of Safety' or balanced safety targets
should be for UAVSs.
a. Difficulties in identifying the equivalent class.
b. Differences in the lethality of UAVSs, from manned aircraft, and between
different UAV classes.
6. To improve airworthiness, there are suggestions to apply FAR 1309-type philosophy
to UAV flight-critical system safety design, and referrals to ARP 4761 as a suitable
approach for safety analyses, but that these may require some amendment to suit
differences in UAVSs **.

(1.2.1) Regulation, Certification and the Drive for Standards

1. Current UAV regulation demands 'equivalence' to manned systems, without being
able to address UAV differences.
2. There are proposals that a 'total system' approach is required to address UAV-related
regulation, but that airworthiness is currently regulated separately (by EASA) from
operations, maintenance, ATM and airports (by national bodies such as CAA) **.
3. How to certify UAVSs? Studies suggest that, while a 'safety targets' [safety case]
approach would be easiest to apply, it is necessary to apply a standards /
requirements based approach to be consistent with ICAO rules, and because
different regulators [see ‘2’ above] force separate consideration of design from
operation - but can the UAVS design and operation be cleanly separated without
missing potential safety risks?

36
 4. EASA suggest application of a .1309 safety assessment philosophy, to address novel
aspects of UAVS design [refer with 1.1.4 item 6, above] **.
5. To apply standards-based certification requires standards to be defined for clear,
safety critical design aspects, but these are difficult to define for UAVS [refer to 1.1.2
item 1, above].
6. Regulators wish to apply existing certification for operations (such as maintenance,
flight operations) 'wherever possible', but their own studies show that many aspects of
UAVS operations are not adequately covered, mainly because the scope of UAV
work lies far outside the aspects that the regulation was intended to cover.
7. Several international organisations are pushing to establish consensus-based
standards, but there is currently a competitive spirit between them, which may lead to
several conflicting standards.

(1.2.2) ATM interaction

1. Because of current segregation of traffic, very few UAVs have interacted with Air
Traffic Control (ATC) and the ATM system; hence it is difficult to predict what the real
impacts might be**.
2. Regulators and ATM providers demand that UAV operation will be 'transparent' to
ATM services, that UAVs will "...comply with any air traffic control instruction or a
request for information made by an ATS unit in the same way and within the same
timeframe that the pilot of a manned aircraft would." Yet there are many ways in
which UAVs will react differently from manned aircraft [see 1.1.1 items 2, 3, 4 above,
as well as the following items].
3. Regulators require specific lists of equipage for flight in controlled airspace, but
(most) current UAVs lack the available space, payload or power to carry them all.
4. ATC controllers may require additional data feeds to inform them of UAV specific
status (such as autonomy level), which conflicts with the drive for ATM transparency.
5. How will ATC controllers handle potential 'swarms' of UAVs under a common control
node?
6. High powered ATM RF equipment may pose interoperability problems for some
UAVSs [especially with reference to the crowded spectrum in 1.1.2 item 3].
7. UAVs will ultimately require capability for speech recognition and voice response as
part of their autonomous behaviour.
8. Existing ATM routes and procedures have been built around manned aircraft: it is
suggested that, for UAVs that don't fit the pattern, they will either have to be excluded
(and forced into general airspace) or have new routes / procedures to accommodate
them.
9. For lighter UAVs subject to wake turbulence, current vertical separation minima may
be inadequate to allow safe flight.
10. The impact of UAVs (their numbers and long endurance) on air traffic, and its effect
on ATC controllers and systems overall, has not been adequately modelled thus far.
11. ATM procedures want to hard-define procedures and flight termination areas to deal
with UAV particular risks and emergencies, but the actual procedures may need to be
varied to best suit specific systems (e.g. highly autonomous systems may be safer to
fly on, rather than flight terminate, in response to the particular risk of datalink failure).
12. There are concerns over UAV operations on the ground, on shared airfields -
associated with taxiing into obstructions / other aircraft, and being able to recognise
and respond to visual signals that are used in airfield operations**.

37
 13. Diversionary airfields may pose additional problems for UAVs, if the airfield is not
adequately prepared to handle UAV traffic, or appropriate navigation facilities (such
as D-GPS) are not available to provide sufficient accuracy for auto-land systems .

(1.2.3) Collision avoidance

1. 'Approved' methods of terrain avoidance have yet to be identified for UAVSs.
2. Most literature sources imply that terrain avoidance will be solved as part of the
airborne collision avoidance / Sense & Avoid effort - but characteristics for ground /
obstacle target detection will be very different from point air targets, and the technical
solutions and airmanship requirements will be likewise quite different.
3. In order to respect the Rights of Way, the UAVS must be aware of its situation in
terms of the factors that determine who has right of way, and be able to react
accordingly. But each situation will be different depending on: whether all involved
aircraft comply fully and correctly with the Rules of the Air; the controllability and
manoeuvrability of each aircraft and their respective flight performance; the level of
autonomy of operation and control (in terms of the involvement (or not) of a ground
pilot) [refer to autonomy specification, in 1.1.3 item 6 above].
4. Due to the size, role and performance of UAVs, will manned aircraft pilots be able to
spot them in order to respect the Rights of Way?
5. Some authorities believe that it is not possible to set criteria for Sense & Avoid
systems - they must develop once the available technology performance and UAV
systems definition become clearer. But others believe that the technologies for
Sense & Avoid should not be developed until the necessary criteria are defined.
Currently, there are no defined criteria.
6. Current technologies such as TCAS cannot be relied on, as they require all traffic to
co-operate in carrying interrogating equipment. UAVs in general airspace must have
Sense & Avoid that can detect non-cooperative traffic (which manned aircraft
currently attempt to do using the pilot's visual acuity).
7. The nearest thing to S&A criteria is currently to establish 'equivalent level of safety' to
manned aircraft. But high profile accidents have shown the fallibility of human visual
collision avoidance. Also, initial modelling has indicated that human eye perception
ranges fall short of the required detection range to avoid collisions.

(1.2.4) Security and safety

1. UAVS dependent on GPS based navigation may be susceptible to jamming unless
jam-resistant systems can be fitted.
2. The command datalink significantly extends the responsibility to ensure safe control
of the UAV, and practical solutions to avoid jamming, spoofing or stealing of the
datalink need to be found.
3. The use of ground-based control elements (some distributed globally) extends the
need for physical security of the system, beyond the airframe considerations of
manned systems.
4. The data elements of the UAVS present a key security issue, to avoid corruption of
mission planning, airspace and terrain databases, flight programmes, GCS functions
etc.

38
(1.2.5) Human factors, Suitably Qualified & Experienced Personnel (SQEP) and
organisations
1. Human / Machine Interface (HMI) aspects affecting UAV flight safety exist relating to:
the ground 'cockpit' environment; the available cues from the UAV and displays; the
UAV-p and maintainers skill levels; levels of situational awareness and a suggestion
that the low personal risk to the UAV-p removed him somewhat from trying to recover
difficult situations.
2. Human factors issues are difficult to analyse for UAVSs, due to the wide variety of
HMI currently in use, and big questions over the interaction between the human
operator and the autonomous level of the system [refer to 1.1.3 item 3 above]
3. There is a huge assumption that a UAV Operating Certificate covering global
activities for the UAVS system, with an approved organisation and competent staff /
operators, vehicle safety history and analysis, design standards, operating manuals,
etc, will provide the main route to a safe UAVS operating within manned airspace. Is
this tenable?
4. Current military organisations force regular rotation of personnel, so that there is not
adequate build up of UAVS operating experience within the organisations.
5. The complex network of organisations, running the UAVS system of systems, control
safety-involved data interfaces for the UAVS. This network is not adequately
discussed or understood in the literature reviewed.
6. Where several UAV-ps (with lesser skills) may be under control of an officially
recognised UAV Commander, what issues influence how many may be safely
controlled without compromise? How does this vary with UAVS complexity / role /
interface / autonomy levels? While regulators depend on the skills and experience of
the UAV Commander, how does the interface between Commander and Pilot(s)
affect the efficacy?

(1.2.6) Public perception of UAV safety

1. CAA perspective is that airborne collisions are seldom survivable, but other agencies
are pursuing UAV characteristics (such as frangible materials) such that collisions
may not be so catastrophic. Is this approach practical in terms of safety, and could it
influence public opinion sufficiently?
2. How do media perspectives of UAV safety compare with actual public opinion, and
with achievable levels of safety for UAV systems?

1.3.2 Focus for project development

From a review of the issues above, and the overall aims of the project, several options
existed to take this particular study forward. After much reflection, it was decided that there
was a common core of issues that could be addressed, related to the need for:
A. A better understanding of what the root hazards associated with UAVS integration
are. [Predominantly 1.1.1 issues 1-3; 1.2.2 issues 1 and 12]
In exploring this aspect, the project would need a robust Hazard Identification
(HazID) methodology, and understanding of the system(s) being assessed. Thus, it could
also contribute to other, related aspects along the way, in particular:
B. Can a .1309 / ARP4761 safety assessment approach be used for UAVS, to identify
hazards for solution during design / manufacture / operation? [Relating to 1.1.4 issue 6,
1.2.1 issue 4]
This approach thus relates to a number of the issues shown above - these are indicated with
a double asterisk **. Along the way, it was hoped that the study would also provide useful
information on other aspects, such as those on system complexity in section 1.1.2, but these
would not be the primary focus.

39
PART 2 - DESIGN AND BUILD: MOVING FORWARD IN
UAVS HAZID
The intent of Part 2 is to identify a robust method for Hazard Identification (HazID), based on
ARP 4761. This would be used in Part 3 to assess a UAVS case study and hence
investigate the root hazards of integrating UAVS into manned airspace.
This part of the project can be likened to Design and Build for a product-based project. We
require a clear set of Design Requirements, to which a sound methodology can then be
built.
o In general, the design requirements were outlined at the end of section 1.3, but there
was a need to define the full requirement list more robustly. Section 2.1 assesses the
existing ARP 4761HazID methodology for its usability for UAVS assessment, and
hence establishes where improvements are required.
o Section 2.2 then works through the requirements, to establish a proposed improved
methodology for UAVS HazID.

2.1 Assessment of ARP4761 Usability for UAVS HazID

2.1.1 Introduction
ARP 4761 [SAE96] has the following scope:
"This document describes guidelines and methods of performing the safety
assessment for certification of civil aircraft. It is primarily associated with showing
compliance with FAR/JAR 25.1309. The methods outlined here identify a systematic
means, but not the only means, to show compliance. A subset of this material may be
applicable to non-25.1309 equipment. The concept of Aircraft Level Safety
Assessment is introduced and the tools to accomplish this task are outlined. The
overall aircraft operating environment is considered.”
Clearly, the current intent is to support safety assessment of civil (predominantly heavy
transport) aircraft. In has been reviewed for its applicability in supporting safety assessment
for UAVS certification, primarily for the Hazard Identification elements at this stage. The full
review is at Annex A to this report; a summary of the issues identified is presented below. At
this point, the focus has been on hazard identification through Functional Hazard Analysis
(FHA); only a cursory look has been taken at the lower-level Preliminary System Safety
Analysis (PSSA) and System Safety Analysis (SSA) elements.

2.1.2 Safety Objectives

Safety objectives and criteria are drawn in from FAR / JAR 25.1309 (becoming EASA
CS.25.1309 in Europe). These talk in terms that are focused on manned, large aircraft
airworthiness - for example, a Catastrophic consequence is defined as "All failure conditions
which prevent continued safe flight and landing" with a target probability of better than 1 in
10-9 per flying hour.
For airworthiness considerations for UAVs, criteria need to reflect the variety of UAV systems
at least in terms of their lethality, such as the variation between transport and smaller aircraft
in 25.1309 and 23.1309 from 1 in 10-9 to 1 in 10-6 per flying hour for catastrophic
occurrences.

40
Criteria descriptions need to reflect UAV potential occurrences, such as those proposed by
the JAA / EUROCONTROL Joint Task Force in [UTF04 chapter 7.5] - for example, they
suggested modifying the catastrophic definition to "UAV’s inability to continue controlled flight
and reach any predefined landing site".

For 'total system safety' as required by EASA (see section 1.2.1), rather than just
airworthiness, the criteria need to reflect occurrences that compromise safety through ATM
or operational context. EUROCONTROL have established related (but different!) criteria that
they insist are applied where an occurrence could affect the ATM environment, through
EUROCONTROL Safety Regulatory Requirement 4 (ESARR 4) [EUR01].

2.1.3 'Aircraft Level' and 'System Level' FHA

[SAE96]proposes that Functional Hazard Assessment (FHA) be carried out at what it calls
the 'Aircraft-Level', then lower-level 'System-Level' assessment once the design work starts
in earnest.
If the 'Aircraft Level' is to equate to the UAVS, then care / guidance is needed to address the
complexity of the system:

o The extended critical boundary (for elements such as the Ground Control System
(GCS) and mission planning?).
o The people and procedural elements.

How should the System of Systems or 'super-system' elements be considered? There is

some reference to looking at 'exchange functions' (see below) but not in sufficient detail to
define and address these critical interfaces for the UAVS.

2.1.4 FHA Process:

[SAE96] describes how "The FHA process is a top down approach for identifying the
functional failure conditions and assessing their effects. This assessment is made in
accordance with the following processes.” [Square brackets refer to further discussion of
each aspect in later paragraphs]:

1. "Identification of all the functions associated with the level under study (internal
functions and exchanged functions).” [Function Identification]
2. "Identification and description of failure conditions associated with these functions,
considering single and multiple failures in normal and degraded environments.”
[Identification of Failure Conditions]
3. "Determination of the effects of the failure condition.” [Identifying and Managing
Effects]
4. "Classification of failure condition effects on the aircraft (Catastrophic, Severe-
Major/Hazardous, Major, Minor and No Safety Effect). [Identifying and Managing
Effects]
5. "Assignment of requirements to the failure conditions to be considered at the lower
level.” [FHA Outputs]
6. "Identification of the supporting material required to justify the failure condition effect
classification.” [FHA Outputs]
7. "Identification of the method used to verify compliance with the failure condition
requirements." [FHA Outputs]

41
Function Identification:
o Source data requirements for input to the 'aircraft level' FHA assume a single,
homogenous aircraft.
o This does not reflect the more complex UAVS structure.
o It does not draw out the more complex interfaces with the wider SOS.
o The 'Aircraft level' Internal Functions list guidance does not reflect the more complex
UAVS structure. These may vary with the initial design assumptions over the UAVS
overall architecture.
o The aircraft-level Exchanged Functions list assumes a simple interaction with the
outside world - this area requires careful guidance for the UAVS to ensure that the
interfaces with the wider System of Systems (SoS) are adequately assessed for
exchanged functions.
o Flight Phases need guidance to ensure they are adequately defined for the UAVS.
UAVS missions are more complex and variable than those for transport aircraft
(around which [SAE96]is based).

Identification of Failure Conditions:

o New and different Emergency and Environmental Conditions are likely to be required
for UAVS considerations.
o Environmental conditions and events may come from the more extreme
climatic or mission conditions they experience, due to the unusual
performance and roles they undertake.
o Particular Emergency conditions will be applicable, from both regulatory and
system architecture sources, such as datalink failure response.
o There will be new types of single functional failure, but potentially many new multiple
failure conditions to consider, due to the extended system and the wider SoS. More
care will be required to ensure all credible combinations are considered.

Identifying and Managing the Effects of the Failure Conditions:

o For UAVS, Flight Phases and other sources of mission context will be critical in
evaluating the consequential effects of failures on other airspace users or the
overflown public. The loss of the UAV itself is not as significant as hull loss for a
transport aircraft; instead, it is the second tier effect on other persons that is crucial,
and that is dependent on where the UAV is and what it does when the failure occurs.
ARP 4761 does not adequately support the significance of establishing this mission /
environmental / ATM context.

FHA Outputs:
o [SAE96]proposed outputs seem appropriate at this point, but would need to be tested
more thoroughly through actual input to the PSSA process.

2.1.5 Overall Applicability of ARP4761 for UAVS use

The intent of ARP4761 to support the safety assessment (and hence clearance) of novel
aircraft systems remains good. If the issues identified above can be addressed, then the
revised framework should equally support safety assessment and clearance of UAVS.

42
2.2 Modifying ARP 4761 FHA for UAVS Use
Each of the areas of ARP 4761 FHA requiring modification has been worked through in turn,
to arrive at a justified, proposed revised HazID methodology. Key elements of the proposed
methodology are shown in bold, italicised text.
It is worth including a note here on the use of Functional Failure Analysis for FHA. Other
forms of FHA are available, such as HazOp, Structured What If technique (SWIFT) et al (see
[HRA03 session 12] for further guidance). However, it was decided to continue on the basis
of Functional Failure Analysis (FFA), in order to conform with the basic process behind ARP
4761. It is a sound method for initial hazard investigation, where the design is still in its
infancy but its purpose can be identified; and it is an accepted method recognised for
certification through previous use of ARP 4761 and ARP 4754. To abandon FFA for another
method at this stage would have required strong reasons – and none were identified at this
early stage of investigation.

2.2.1 Derivation of Safety Criteria and Objectives for UAVS

Application
Safety Criteria

We need to define suitable safety criteria in order to assess the effects and consequences of
potential UAVS hazards. It is important to note that safety criteria have been separated from
safety objectives - the latter are considered later in this section. Our focus here is how
hazardous effects are to be defined.

The first consideration is "who is likely to be affected by the UAVS". A quick review of
existing airworthiness criteria such as in AC 23.1309 [FAA99] leads us to the following
traditional parties:

o Passengers of the vehicle? NO, this should not be an issue for a UAV.
o Flight crew - NO (but possibly indirect effects on UAVS operators?).
o The air vehicle itself

ARP 4761, looking to support ARP 4754 (and hence EASA CS.25.1309) focuses on this list,
to give a set of airworthiness criteria. It can be argued that, if the aircraft is kept safely in the
air, then the safety of the 3rd parties on the ground is necessarily protected. As noted in
section 2.1 of the report, EUROCONTROL suggested modifications to these criteria to make
them more UAVS applicable. Hence a modified set of airworthiness criteria has been
drawn together as shown in Table 2.2.1(i) below:

43
Failure Condition FAA Minor Major Severe Major Catastrophic
Severity Classification
JAA Minor Major Hazardous Catastrophic
Existing Failure - Slight reduction in - Significant reduction in safety margins or - Large reduction in safety margins - All failure conditions which
Condition Effect safety margins functional capabilities or functional capabilities prevent continued safe
criteria flight and landing
- Slight increase in crew - Significant increase in crew workload or - Higher workload or physical
( FAA & JAA / EASA) workload in conditions impairing crew efficiency distress such that the crew could
not be relied on to perform tasks
- Some inconvenience - Some discomfort to occupants accurately or completely
to occupants
- Adverse effects upon occupants

Proposed UAVS - Slight reduction in - Significant reduction in safety margins - Controlled loss of the UAV over UAV's inability to continue
criteria (taken from UAV safety margins (e.g. (e.g., total loss of communication with an unpopulated emergency site, controlled flight and reach
Task Force [UTF04]) loss of redundancy) autonomous flight and landing on a using Emergency Recovery any predefined landing site
predefined emergency site) procedures where required.

Table 2.2.1(i) - Airworthiness Failure Condition Severities (after [SAE96], with additions from [UTF04] as noted)

44
While it was tempting to modify the criteria further, such as to include factors for UAVS
operators’ workload under ‘Major’ and ‘Severe Major’, it was decided to leave the criteria
alone at this stage. The baseline FAA / JAA criteria are well established to support regulated
requirements; similarly, the UAV Task Force criteria were arrived at by a multi-national team
and, it is assumed, have reached a high level of consensus. With this in mind, it was felt
better to try out the criteria first, so that if proposed changes were found necessary, they
would be underpinned by a demonstrable need to overcome specific shortcomings. The
domain is slow to change (as we have seen evidence for, throughout section 1).

That said, the criteria above do provide a very airworthiness-centric view. Looking at a wider
requirement for safety leads us to the following affected parties, additionally:

o 3rd parties on the ground - the overflown public.

o 3rd parties in other aircraft - in the air or on the ground at airfields.
o ATM personnel

It could be argued that, in providing criteria aimed at keeping the aircraft reliably in the air,
the requirements of the overflown public are met (especially as the [UTF04] criteria include
consideration of whether the vehicle can reach an unpopulated site) - this is consistent with
the view that UAVS must meet an Equivalent Level of Safety to that for manned aircraft, and
the criteria above are set for manned aircraft. What then should be done about the second
two parties, other aircraft occupants and ATM personnel, where the criteria currently say little
specifically applicable?

As noted in section 2.1, EUROCONTROL are insistent that their criteria must be applied in
all instances where the ATM environment may be affected. Although the criteria are
focussed on applications for ATM system developments, it can be seen that they would be
applicable for a UAVS and particular concerns over manned aerospace integration. The
criteria are shown in Table 2.2.1(ii) below:

45
Failure Severity 5 - No Severity 4 - Minor Severity 3 - Significant Incidents Severity 2 - Major Incidents Severity 1 - Accidents
Condition Immediate Effect Incidents
Severity on Safety
Classification
Failure Condition - No hazardous - Increasing workload of - Large reduction (e.g., a separation of - Large reduction in separation - One or more catastrophic
Effect condition i.e. no the air traffic controller or less than half the separation minima) (e.g., a separation of less than accidents
immediate direct [UAVS] crew, or slightly in separation with [UAVS] crew or half the separation minima),
or indirect impact degrading the functional ATC controlling the situation and able without [UAVS] crew or ATC - One or more mid-air
on the operations capability of the enabling to recover from the situation. fully controlling the situation or collisions
CNS System. able to recover from the
- Minor reduction (e.g., a separation of situation. - One or more collisions on
- Minor reduction (e.g., a more than half the separation minima) the ground between two
separation of more than in separation without [UAVS] crew or - One or more aircraft deviating aircraft
half the separation minima) ATC fully controlling the situation, from their intended clearance,
in separation with [UAVS] hence jeopardising the ability to so that abrupt manoeuvre is - One or more Controlled
crew or ATC controlling the recover from the situation (without the required to avoid collision with
Flight Into Terrain
situation and fully able to use of collision or terrain avoidance another aircraft or with terrain
recover from the situation. manoeuvres). (or when an avoidance action
would be appropriate). - Total loss of flight control.

- No independent source of
recovery mechanism, such
as surveillance or ATC
and/or [UAVS] crew
procedures can reasonably
be expected to prevent the
accident(s).

Note: my substitution of [UAVS] for flight crew references.

Table 2.2.1(ii) - EUROCONTROL ATM-Focused Separation / Collision Safety Criteria (from [EUR04])

46
First thought was to try and combine these criteria with those previously, e.g. to add the
'Severity 1' criteria to those for 'Catastrophic'. However, on further consideration, this was
rejected:

o The criteria are specifically separation and collision focussed, and do not map well
onto airworthiness criteria.
o The criteria introduce issues which may have no airworthiness causes - particularly in
the way they consider effects on ATM personnel and 'flight crew' (or UAVS operators
in our case). Looked at another way, they provide a means to assess hazards that
are caused by ATM personnel and UAVS operators, and start to address the
personnel issues within the System of Systems.
o The associated probability targets required by EUROCONTROL under the ESARR 4
regulation do not line up directly with those for airworthiness under CS.23.1309 or
CS.25.1309; hence the requirements for a merged category would be out of step. It
was felt clearer to maintain the different severity titles in order to dissuade readers’
instinctive attempts to merge the safety objectives (see below).

What is arrived at is a dual-criteria system, to satisfy different hazard types and regulatory
bodies. This might seem unwieldy, but should be fairly simple to apply in practice:

o For hazards and potential accidents where the UAV comes to ground - affecting the
overflown population and / or the UAV itself: apply the Airworthiness safety
criteria. These will be predominantly due to airworthiness and reliability causes, and
the effect will vary with the system size and speed (see Safety Objectives below).
They will also fit within the airworthiness occurrence reporting regime.
o For hazards and potential accidents where the UAV could conflict with other manned
aircraft: apply ATM Separation / Collision safety criteria. These may have a
system reliability / airworthiness cause, but could also be due to failures within the
wider System of Systems, including personnel and procedural issues. They will also
fit within the ATM occurrence reporting regime.
o If a situation arises with potential overlap, i.e. it could cause both an airworthiness
and collision risk, what then? It is not so easy to say ‘pick the highest severity’ as the
different criteria have different safety targets (see below) and hence a high
airworthiness severity might indicate a lower risk overall. A different view is that such
situations will need the different criteria at different times (e.g. a failure in control
causes a UAV to wander off through controlled airspace first, before ultimately
crashing to the ground). Hence my proposal is to split the potential hazard into its
airworthiness and collision components, and apply each criterion to the applicable
component.

Airworthiness-based Safety Objectives

Safety Objectives, in terms of acceptable probabilities, from ARP 4761 are predominantly
aimed at heavy transport aircraft. This is in line with FAA / JAA Part 25.1309 (now EASA
CS.25.1309 in Europe) and defined in [FAA88]. For smaller manned aircraft, CS.23.1309
would usually apply - this refers in turn to AC 23.1309 [FAA99] for guidance on showing
compliance. Both refer to ARP 4761 for guidance on carrying out suitable safety analyses,
but AC 23.1309 notes the need to amend the safety objectives. To this end, Safety
Objectives for CS.23 and CS.25 aircraft for acceptable probabilities per flying hour are
compared in Table 2.2.1(iii) below:

47
 Severity of Outcome Minor Major Hazardous Catastrophic
Category of Aircraft:
CS.23.1309 Class I: Single Reciprocating <10-3 <10-4 <10-5 <10-6
Engine (SRE) / under 6000lbs
CS.23.1309 Class II: SRE and Multi- <10-3 <10-5 <10-6 <10-7
Reciprocating Engine (MRE) / under 6000lbs
CS.23.1309 Class III (1): SRE, MRE, Single <10-3 <10-5 <10-7 <10-8
Turbine Engine (STE), Multi-Turbine Engine
(MTE) >= 6000lbs
CS.23.1309 Class IV (2): Commuter Category <10-3 <10-5 <10-7 <10-9
CS.25.1309 Heavy Transport <10-3 <10-5 <10-7 <10-9

Notes:

(1) Aeroplanes in the normal, utility and aerobatic categories that have a seating configuration,
excluding the pilot seat(s), of nine or fewer and a maximum certificated take-off weight of 5670
kg (12 500 lb) or less.

(2) Propeller-driven twin-engine airplanes in the commuter category that have a seating
configuration, excluding the pilot seat(s), of nineteen or fewer and a maximum certificated take-
off weight of 8618 kg (19 000 lb) or less.

Table 2.2.1(iii) - Airworthiness Safety Objectives - probabilities per Flying Hour (from
[SAE96], drawn from [FAA88] and compared with [FAA99])

If we wished to apply these variations to UAVs airworthiness safety objectives, we would

need to identify the equivalent class of vehicle. While we could not consider the seating
aspects, it would seem sensible to take the engine configuration and mass into account, and
thus arrive at a practical equivalent. However, it is worth noting that the CAA [CAA02] push
for a kinetic energy equivalence to be determined in deciding which certification criteria to
apply (see section 1.2.1), and this should be considered for the safety objectives too. In
most cases, the comparison will probably come out about the same - e.g. a 500Kg UAV,
powered by a Single Reciprocating Engine, with stalling speed (Vs) of 40kts and maximum
operating speed (Vmo) of 100kts would indicate as a Class I by either criteria. Unfortunately,
this is not always the case - Global Hawk could be considered similar to a CS.23 Class III
manned aircraft, but through kinetic energy considerations indicates as a CS.25 class
aircraft. With the likely public sensitivity to UAVs entering the media eye (see section 1.2.6)
it would seem sensible to take the higher indicated safety objectives.

In summary, for UAVS Airworthiness-based safety objectives, it is proposed:

o To determine the UAV kinetic equivalence to manned aircraft (using the method
extracted from [CAA02] and shown in Annex B to this report)
o Review the applicable objectives for that class of vehicle (as presented in Table
2.2.1(iii) above) and hence establish the airworthiness objectives for the UAVS.

ATM Separation / Collision based Safety Objectives

It is important to note that the ATM separation / collision based safety objectives will not
change with the class of vehicle. The acceptable probability of a Severity 1 accident remains
fixed by ESARR 4 [EUR04] at 1.55 x 10-8 per flight/hour.

48
2.2.2 FHA Levels to Address System Complexities
Currently, ARP 4761 calls for Aircraft Level then deeper System level Functional Hazard
Analyses (FHAs), in order to identify significant hazards (see discussion at section 2.1). What
levels are appropriate for assessment of a UAVS?
Dealing with the UAV System boundary & complexity
As noted in section 1.1.2 of this report, there were concerns over the 'airworthiness'
boundary for the UAVS. It was clear that the critical elements extended beyond just the UAV
itself, and probably included elements such as the GCS, the Datalink, the Flight Termination
System (FTS) (if used), but did it include wider aspects such as mission planning systems
and so on? The boundary was unclear.
However, if we consider that the aim of the Aircraft Level FHA in ARP 4761 is to explore the
critical functions that lie within the designer's control, then the boundary does not really
matter at this stage. The bulk of functionality within the planned UAVS is to replace those
taken for granted in manned systems. Thus, by extending the Aircraft Level FHA to be a
UAVS Level FHA, looking at all functions of the UAVS within the designer's control, then the
outcome would be an identification of all the functions that are critical to the safe behaviour of
the system and the consequences of their breakdown.
These would then flow down into the System level FHA, et al, as described in the ARP, to be
analysed as functional sub-systems within the UAVS.
In section 2.1, it was suggested that the extended criticality criteria should consider people
and procedural aspects of system, as these were not specifically addressed by the ARP.
However, in the early stages of UAVS design, the specific nature of these elements may not
be known. Instead, I would propose that it is important to understand the role they play
rather than the details - essentially to understand the functions they might perform. In this
way, after having performed the UAVS-level FHA, the designer would use the results to
inform decisions on where to partition functions between the hardware, software and human
elements of the system. By doing this, a proactive approach can be taken to ensure that the
human and procedural elements are well designed and part of an integrated approach to
safety, rather than just dumping ad hoc safety monitoring tasks there in order to keep the
system simple (as has been the way in the past with some system designs). Further
guidance on the human elements of safety and designing for human factors can be found in
the York University HFE course [HFE05].
Dealing with the System of Systems around the UAVS
As was discussed in sections 1.1.2, UAVS operate within a wide System of Systems (SoS),
and in section 2.1 it was noted that [SAE96] was not strong in analysing these relationships.
One consideration was to introduce a 'Super-system' level FHA to the process, to assess the
functions of the wider SoS. However, this was not felt to be practical for the UAVS designer
to attempt: while he wishes to understand the SoS to the extent that it affects his system, he
can control only a (relatively) small element of it and a full analysis would take excessive
resources. On reflection, this level of analysis might be useful for a wider SoS player such
as EUROCONTROL or EASA to conduct, and provide resulting information to inform system
designers.
A research area of interest is the work ongoing towards decomposition of safety policy, for
Systems of Systems. This is discussed by Hall-May and Kelly in [Hall05], looking at how
policy (that is, permitted and required behaviours) can be flowed down from top-level goals
for different agents, or different situational cases, within a SoS. An example from the paper
is shown in Figure 2.2.2a, below.

49
 Figure 2.2.2a – Example of decomposition of high level policy to
lower level agents or cases [Hall05]
Such decomposition causes (usually implicit) assumptions over the context behind such
policies to be made explicit. It also requires the policy setter to understand (even at a fairly
simple level) a model of expectations, over how the agents can behave – e.g. glider pilots
cannot be expected to climb to satisfy policy. If EUROCONTROL or EASA (say) were to
develop such a policy model, this would be of great use: both for UAVS designers to
understand explicitly what was required (and hence allocate suitable functions for safety
analyses – see 2.2.3); and for EUROCONTROL / EASA to better understand how UAVS and
other novel systems may / should behave within their wider SoS. It would also allow areas of
policy failure to be explored, to determine where the SoS overall may be sensitive to single-
point breakdown.
The UAVS designer's interest is to achieve a better understanding of the interactions
between the UAVS and the SoS. This suggested that parallels could be drawn with
Requirements Engineers, trying to understand the 'problem domain' and how the World and
their potential Machine interface. From a review of their methodologies in [RQE05], it is
proposed that a Rich Context Diagram could provide a suitable visual model to help draw
out complexities and interactions. An example is shown in Figure 2.2.2b below, for a Train
Control System.
The Rich Context diagram as proposed assists by:
o Helping to gather domain information - we can use it to establish the existing context
through: observed behaviour (as functions of the systems and people elements);
processes (people); data (systems).
o Helping to define the machine / world boundary - the world is all that we cannot
control; the system is all that we can control. Note that there are occasions where the
boundary can be negotiated, but many where it cannot (such as over ATM system
interfaces, for example).
o Establishing the problem context - identifying the relevant parts of the world; their
interactions with each other and the machine.

50
 Figure 2.2.2b - Example of Rich Context Diagram (taken from [RQE05, unit 20])
This latter point is a key element of how Rich Context Diagrams differ from the traditional
Context Diagram: In the traditional form, only direct interactions with the machine are
identified, so in the example, the driver would not be shown. It was felt that this would be a
major shortcoming to understanding the SoS, as the bulk of the 'world' has already been set
up for manned aircraft, and it was suspected that there were key interactions between
existing elements that would need to be understood.
Thus to summarise for this section:
o FHA levels should be established at UAVS-level (rather than Aircraft Level), and
subsequently down into system-level as per the ARP.
o Instead of a Super-System FHA, establish a Rich Context Diagram, to ensure that the
SoS and its interactions with the UAVS are suitably understood, to inform the UAVS-
level FHA.

2.2.3 Function Identification

Our analysis method needs a robust identification of functions, as these are the building
blocks for the hazard identification. We do not want to miss out vital functions (and thus
areas of hazard analysis and design requirement) due to assumption or error, which will later
be found to have critical safety implications for the system in-service. ARP 4761 provides a
little guidance on function identification aimed at Aircraft Level FHA, but what is there
is aimed at a primarily unitary overall system. This guidance needs to be built upon, to
ensure a more structured approach for a UAVS made up of several system elements and
working within a wider SoS.

ARP 4761 Annex A starts by looking at Source document requirements, but we will return to
this once the needs for information to support the functional identification have been explored
(see below).

51
ARP 4761 also suggests an 'Aircraft Level generic hazard list' to help get started. As was
noted in ‘Focus for project development’ at section 1.3.2, such a list would be useful to
develop for UAVS-level assessments and so would a starter list of generic UAVS functions,
to act as a catalyst for assessment of new UAVSs.

Internal Functions

The ARP [SAE96] suggests that, for the Aircraft Level "...these are main functions of the
aircraft and functions exchanged between the internal systems of the aircraft." Our concern
here is to ensure that the identification adequately explores the complexity of the UAVS, both
in its overall capabilities and in its internal interactions (see sections 1.1.1, 1.1.2 and 2.1). To
achieve this, the following structured approach has been developed, to identify the Functions
List (or Functions Tree as preferred):

1. Consider UAVS functions overall:

a. Ideally, there will be an established User Requirement Document or similar
specification to draw upon.
2. Consider functions determined by the UAVS internal structure:
a. Is there a simple representation of the initial design concept? These could be as
formal as Yourdon diagrams or Functional Block Diagrams (as discussed in
[HRA03]), or could be a simple architectural model (like an internal Context Diagram)
showing interactions between the UAV, the GCS, use of the datalink etc.
b. Consider each major element of the structure and identify any additional internal
functions - it may help to consider each as a transform mechanism, that is to consider
the inputs and the resultant modified set of outputs, in order to determine what
functions that element needs to perform the transformation:
(i) Does the element have particular behaviour functions - e.g. does it react
physically to inputs?
(ii) Does it have control functions - does it monitor and/or control the behaviour of
other elements?
(iii) Does it have information functions - does it generate information or process data,
to be used elsewhere?
(iv) Does it have utility functions - such as power generation, needed to provide
support elsewhere in the system?
c. Care will be needed to balance what is sensible to achieve at the UAVS level
analysis, and what can be left to the more in-depth System-Level analyses. The
balance may be self-imposed by the limited design information available at the early
stages of the project.
3. Consider the effect of flight phases, as UAVS usually have a broader mission profile
than the transport aircraft that [SAE96] was intended for originally:
a. See ‘Flight Phases’ below for discussion on identifying flight phases.
b. Review the function list (so far) for each proposed flight phase and mission variation,
to identify any additional functions or sub-functions.

At this point, some concern was felt over how complete the function list could be, and could
there be improvement possible through use of more formal modelling of the system through
Unified Modelling Language (UML) or similar specification tools. A further review of literature
showed that there is a developing theme for model-based safety analyses. Joshi and
Heimdahl [Jos05] for instance, discuss application of Simulink modelling tools to transfer a

52
design representation of the ARP 4761 Wheel Braking System example into the SCADE
Design Verifier tool, and from there progress through automated FHA into Fault Tree
Analyses and Failure Mode Effects Analysis generation. This work is very promising for
UAVS application in terms of: developing formal system models; formalizing fault conditions;
automated analysis and verification (including assessing multiple failures – see 2.2.4 below);
and developing formal methods to ensure completeness of assessment. However, this
approach needs a detailed model of the system design, and [Jos05] notes that it is intended
to fit into the bottom of the system / safety ‘V’ (to make it a system / safety ‘Y’ and hence
improve the efficiency of developing and integrating the system safely). Thus, it will
ultimately be more suited to the later stages of the safety assessment, through detailed
PSSA and SSA. – see figure 2.2.3a, below.

Figure 2.2.3a – Modified ‘V’ to ‘Y’ model safety assessment process [Jos05]
Exchanged Functions

[SAE96] suggests that, for the Aircraft Level "...these are functions that interface with other
aircraft or with ground systems." As discussed earlier (sections 2.1 and 2.2.2), more
guidance is needed to ensure that the interactions with the wider SoS are identified, hence
the following additional advice is proposed:

1. Using the Rich Context Diagram identified in section 2.2.2:

a. Consider each element in turn that the UAVS will interact with.
b. Consider each Rich Context Diagram interaction for implied functions on the
UAVS. Again it may help to consider the UAVS as a transform mechanism:
(i) Are there particular behaviour functions - e.g. does it react physically to inputs?
(ii) Are there control functions - does it monitor and/or control the behaviour of other
elements?
(iii) Are there information functions - does it generate information or process data, to
be used elsewhere?

53
 (iv) Are there utility functions - such as power generation, needed to provide support
elsewhere in the system?

Flight Phases

Flight phases can be somewhat more exotic for UAVs than the transport aircraft originally
considered by ARP 4761 (as discussed in section 1.1.1). It is important that all phases are
identified, for the main mission and also any variations (e.g. a UAV might act as a sensor
gathering target information, but might also be able to act as a datalink relay for another
UAV). For this reason, the following modification is proposed to supplement the HazID
method:

1. Mission types and parameters should be reviewed to identify the various flight
phases possible, for main and alternate mission types.
a. This could be gleaned from the User Requirement Document (URD), or maybe there
is a simple Concept of Operation (ConOps) that can be used

UAVS-Level FHA Source Data Input Requirements

From the work above, there are obvious additions to the initial list of source documents
for the UAVS-Level assessment. The proposed list would now read:

1. List of generic UAVS functions (when available).

2. The UAVS objectives and customer requirements
a. Ideally from a URD or similar specification.
3. Initial design decisions or constraints (e.g. size and type of UAV, scope of GCS, scope of
Datalink)
a. Perhaps a simple design representation, such as Yourdon or Functional Block
Diagram
b. Or an initial architectural representation of the system elements (such as an 'internal'
Context Diagram).
4. A representation (such as a Rich Context Diagram) showing the interactions of the UAVS
with the outside world (the SoS) and any critical interactions between those external
elements (such as between ATM and other, manned aircraft).
5. Initial mission types or constraints.
a. From a simple ConOps for the system.

From the above input data, it should prove feasible to draw up a suitably robust Function List
or Function Tree, and hence get the FHA off on a sound basis.

2.2.4 Identification and Description of Failure Conditions

ARP 4761 proposes that identification and description of failure conditions for a particular
function begins with definition of an Environment and Emergency Configuration list (in order
to understand 'normal' and 'degraded' aspects of operation), before going on to consider
failure conditions in depth. Each of these aspects is discussed below - note that it is
proposed to separate the environment and emergency configurations into two lists, in order
to make them more manageable.

54
Environment List

[SAE96]starts with suggestions of weather, High Intensity Radio Frequency (HIRF) and
volcanic ash as examples pertinent to transport aircraft.

For UAVS, the list of possible environments to consider needs to grow. As noted in section
1.1.1, UAVs may operate in a very different environment from manned aircraft, due to a
combination of their performance and role / mission differences.

1. The Environment List should be defined from a review of appropriate domains:

a. Weather aspects - e.g. temperature, icing, precipitation, winds, visibility...
b. Overflown terrain aspects - this may raise additional 'weather' aspects, such as
wind-shear, sand and dust storms. It may also indicate other aspects such as for
landing and take-off, or communications masking.
c. Electrical environment - in particular, man-made or natural RF fields such as High
Intensity Radio Transmission Areas (HIRTAs), and perhaps aspects of limited or
overlapping spectrum, where problems can be foreseen.
d. Mission environment - such as personnel shift-changeovers (for long endurance
missions), or action of hostile forces for military uses, or use in day or night.
e. Air traffic environment - such as the classes of airspace that may be flown through
or nearby, and the levels and types of traffic.
2. Some of these aspects might already have come to light from creation of the Rich
Context Diagram (section 2.2.2). However, in order to define this list adequately, it may
prove necessary to extend the assessment through use of a series of simple scenarios or
vignettes, to define typical situations - more is proposed on this aspect under section
2.2.5.

Emergency Configuration List

Consider any specific emergency or 'expected' abnormal flight conditions that may
occur. Some will be defined in regulation (see section 1.2.2, under Emergency Procedures),
others might be necessary due to initial design choices. A preliminary listing of aspects
of regulation and guidance from material discussed in the Literature Review (Part 1) has
been identified below, though it is not proposed as being complete in all respects:

1. Single failure of the UAV communication link, and/or control link (uplink and/or downlink,
depending on implementation)
2. Operation of Flight Termination System (if fitted)
3. Else, conduct of other Emergency Recovery procedures due to loss of critical system(s)
a. With UAV-p control
b. Without UAV-p control (i.e. autonomous)
4. Emergency landing due to loss of thrust
5. Collision avoidance with co-operative and non-cooperative aircraft
a. Including evasive manoeuvre
6. Terrain avoidance
7. Interception by military aircraft
8. Failure of onboard Sense and Avoid equipment

55
9. Operation with degraded systems
10. Degradation of weather conditions
11. Security threats to upload data, commands and transmissions

Items 1-8 are drawn from [UTF04]; items 1, 3, 6,7, 9 - 11 from [CAA04]. Clearly the intent of
these sources is to try and mitigate what are seen as the inherent hazards of UAVS: it will be
interesting to see if the list is appropriate and complete.

Failure Condition Determination

[SAE96]suggests that single failures may be determined by "examining the original

[functions] list created in the previous steps and, in addition, applying an analysis of the
concept design created in the initial design process". While not UAVS specific, it is proposed
that the Functional Failure Analysis advice contained in [HRA03, session 12] provides
valuable guidance, to help structure the determination of failure conditions. This proposes
three categories of failures to assess:

1. Function not provided – this is fairly easy to interpret for responsive functions, but care is
required with continuous or periodic functions, to ensure that variations are assessed:
single failure; periodic failure; complete loss.
2. Function provided when not required – obviously, this is not applicable to continuous
functions.
3. Incorrect operation of function – this can be a tricky catch-all, which needs care to ensure
completeness. Examples include: asymmetry; substitution; partial; timing.

One aspect of interest is that ARP 4761 implies that there can be significant
differences whether failures are annunciated or unannunciated. This is worth noting for
the UAVS analysis, and it may be more interesting when we consider whom of the various
stakeholders (from our Rich Context Diagram) the failures would / could / should be
annunciated to.

To identify multiple failures, [SAE96]suggests that "...this process is aided by an

understanding of the aircraft and system architecture. Multiple failures have to be
considered, especially when the effect of a certain failure depends on the availability of
another system". To apply some structure to this, we should consider multiple failure
conditions:

1. Through assessment of the initial design architecture (perhaps represented by our

internal context diagram). In particular consider any elements that could suffer some
common cause for failure (such as EMI affecting both navigation and communications
functions).
2. Where mitigation for a critical function failure is expected by the successful
operation of another function. Here, we should reconsider the criticality of that
function, and review 'what if' that function failed also, to give us a more rounded
assessment overall.

In part, some of this multiple failure analysis will occur through application of the Emergency
Condition list, where regulation and guidance has already highlighted some expected areas
of criticality such as datalink and propulsion functions. Application of the method will need
care to ensure that variables caused by design implementation (as it develops) are suitably
identified and assessed.

56
2.2.5 Identifying and Managing the Effects of the Failure Conditions

From ARP 4761, this covers the following elements of the FHA process:

1. "Classification of failure condition effects on the aircraft (Catastrophic, Severe-

Major/Hazardous, Major, Minor and No Safety Effect)."
2. "Assignment of requirements to the failure conditions to be considered at the lower level."
3. "Identification of the supporting material required to justify the failure condition effect
classification."
4. "Identification of the method used to verify compliance with the failure condition
requirements."

Identification and Classification of failure condition effects

For UAVS, as noted in section 2.1, it is not the effect of a failure on the UAVS that matters, it
is predominantly the end effect on other stakeholders, such as airspace users or the
overflown public, so our method needs to ensure that the mission / environmental / ATM
context is adequately understood. There is already some foundation in the methodology
proposed so far, with definition of the Rich Context diagram (section 2.2.2), Flight Phases
(2.2.3) and Environment and Emergency Condition list (2.2.4). This is supplemented further,
through the following proposed elements:

1. For the majority of failure conditions assessed, it is proposed that the existing
contextual information (as noted above) will be sufficient. However, as mentioned in
section 2.2.4 (in defining environmental conditions), there may be some cases where this
is not sufficient. Our existing contextual information is trying to cover the broad scope of
variations and generally applicable parameters, in essence defining the outer envelope of
how the system will be used.
2. For more complex failure conditions, use of scenarios is proposed to supplement
the assessment. When used in Human Factors Engineering (as discussed in [HFE05,
unit 3]), scenarios are suggested as "episodes in which the [system] is used" - instead of
being general applications, each scenario (for HFE) is put forward as a scripted, specific
situation for use of the system, with concrete conditions, events and actors. A scenario
thus provides a more detailed representation of a situation within the broader envelope
defined in our other contextual representations. We could not hope to cover the whole
envelope of environments and usage with scenarios, but used selectively as
supplements, they could help draw out some of the complexities of key situations and (in
particular) how conditions and events might come together to affect the UAVS.

Drawing parallels from scenario use for HFE, scenarios could be selected for specific
situations of interest, from the following:

1. (Initially) 'routine' mission stages - all was going well, just like every other day, until...
2. Exceptional circumstances - perhaps extremes of climate, weather or unusual terrain, or
variations of mission type...
3. Disadvantaged or extraordinary users - e.g. operation at the end of a shift (fatigue) or
after shift change (unfamiliarity); under extreme workload (such as busy airspace)...
4. Accident or failure - e.g. specific instances of system failure (e.g. multiple failure
conditions); or expected crisis procedures such as Emergency Recovery, weather
diversion...

57
Also from a manipulation of the HFE application in [HFE05], a scenario should consist of the
following elements:

1. Scenario name
2. Rationale - why is this scenario of interest?
3. Agents - who is involved (including agents from the wider SoS)?
4. Situation and environment context - physical situation and narrative of the environmental
conditions (including weather, climatic and overflown terrain considerations, where
pertinent).
5. Mission context - replacing 'task context' for our use. i.e. what was the system doing /
intended to be doing? What are the goals of the UAVS user?
6. Airspace context - this additional element is added to ensure that the ATM domain is
considered, e.g. for airspace type and traffic conditions.
7. System context - what condition is the system in during the scenario (e.g. degraded
systems)?
8. Actions? - For HFE, this would describe a linear path of actions and events through to
some conclusion. However, for our use, we may be interested in using the same
scenario for analysing a number of different action sequences. As such, it may be more
useful to leave the scenario as a defined 'starting situation' using the fields above, and
then describe the different outcomes and consequences separately in the analysis of
each appropriate functional failure condition.

Note that it is not intended to subvert the need for specific HFE activities - those will still be
required in their own right, for detailed design. The intent here is to co-opt a HFE technique
to help analyse complex conditions for functional failure effects.

For the overall classification of the functional failure, the appropriate severity table will need
to be applied, as discussed in section 2.2.1. To recap:

o For hazards and potential accidents where the UAV comes to ground - affecting the
overflown population and / or the UAV itself: apply the Airworthiness safety criteria.
o For hazards and potential accidents where the UAV could conflict with other manned
aircraft: apply ATM Separation / Collision safety criteria.

Assignment of requirements to the failure conditions

ARP 4761 discusses the application of appropriate probability requirements, in order to

assure adequate safety levels for the system overall. All that needs to be noted here is that
the requirement will need to be appropriate to the severity criteria applied, i.e. as pertinent to
Airworthiness or ATM Separation / Collision safety targets (as discussed in section 2.2.1).

Supporting material required to justify the failure condition effect classification

Currently, it is proposed that the guidance within ARP 4761 will be suitable for UAVS
application, for this aspect.

Verification method for certifying requirements compliance

As above, it is proposed that the guidance within ARP 4761 will be suitable for UAVS
application, for this aspect.

58
2.2.6 Summary of Amended FHA Process
This section pulls together the various modifications to the ARP 4761 FHA process,
proposed in order to apply the method more readily to UAVS safety assessment and
certification. The proposed changes are summarised thus:
1. In section 2.2.1, a duel set of safety criteria is proposed, to satisfy both airworthiness
requirements (where the UAV may come to ground and affect the overflown population)
and ATM separation / collision requirements (where the UAV might affect other airspace
users). The airworthiness criteria and targets may vary with class of UAV according to
CAA kinetic equivalence criteria (reproduced in this report at Annex B). The ATM
separation / collision requirements do not vary, being fixed by EUROCONTROL.
2. In section 2.2.2, it was concluded that the complexities of the extended system could be
addressed by carrying out [SAE96]'Aircraft Level' FHA as a 'UAVS-Level FHA'. To bring
in consideration of the wider System of Systems, the use of a Rich Context Diagram is
proposed, as too much lies out of the UAVS designer's remit or resource for a ‘System of
Systems’ level FHA.
3. Sections 2.2.3 to 2.2.5 go on to consider the conduct of the UAVS-Level FHA. These
activities are summarised in Figure 2.2.6a, below. This figure is based heavily (in style)
on the original 'Aircraft Level FHA' Figure A1 in ARP 4761 [SAE96], in order to ensure
recognition by experienced users and regulators - the ARP 4761 figure is reproduced in
Annex A to this report (Figure A-1), as part of the more detailed critique of that document
for UAVS application.

59
Figure 2.2.6a - ARP 4761 FHA Process, with modifications overlaid for UAVS
applicability

60
PART 3 - TEST AND EVALUATION
This part of the report seeks to answer the following vital questions, relating to the proposed
way forward in HazID for UAVS as put forward in Part 2:
o Does the Revised ARP 4761 HazID Method Work? That is, is it practical to apply and
does it robustly identify hazards for UAVS?
o If so, then what are the hazards of manned and unmanned aircraft integration, and
how does our listing compare to expectations?

Section 3.1 describes the test and evaluation methodologies used. Section 3.2 looks at the
first question, evaluating the practicality of application. Section 3.3 considers the second
question, evaluating the derived hazard listing.

3.1 Test Methodology

Test Method Selection
In order to determine the practicability of the revised HazID method, it needed to be trialled.
To do this, the modified ARP FFA process has been applied to a 'typical' UAVS case study
(see description, below). While not possible in this project to consider its application for all
types of UAVS (see section 1 and 1.1 for the diversity among current UAVS), it was possible
to choose a 'mid-range' system with broad applicability that will soon be facing the prospect
of integration into manned airspace. In the longer term, it would be useful to check the wider
applicability, by trialling against case studies at the more extreme ends of the UAVS
spectrum such as HALE and micro-UAVs. The results are presented in Annex D, and
discussed in Section 3.2.
If the method proved practicable, then the HazID should produce a hazard listing. How could
we test the robustness of our HazID method, to ensure that the hazard listing is sound?
Caseley of the Defence Science Technology Laboratory (DSTL), in [dst04], discusses use of
the "Capture - Recapture" method, a technique borrowed from the Ministry of
Agriculture, Fisheries and Food (MAFF). In MAFF use, a pool is trawled for fish, and all
caught are tagged and released; then the pool is trawled again, and the proportion of fish
recaptured compared to the number newly caught gives an indication of the total fish in the
pool. DSTL used this method to provide a rough comparison of the efficiency of hazard
identification by two separate agencies for the same project, and to identify coarsely how
many hazards had gone unfound. A graphical view of the method is shown in Figure 3.1a,
below. Caseley quotes the following example figures, to show simple factors of confidence:
o Agency A found 20 hazards, Agency B found 30, with 15 common hazards
between the two groups.
o The proportion of hazards captured was estimated as 15/30 = 0.5
o The possible total number of hazards was estimated at 20/0.5 = 40

61
 Figure 3.1a - "Capture - Recapture" analysis method, to measure the effectiveness of
hazard identification processes
Obviously, there are many statistical assumptions and simplifications inherent in this method
(including a major assumption that the methods are truly independent), but as a simple
measure it gives reasonable first order results, and should suffice for our purposes. With this
in mind, it was decided to commission a separate FHA for the case study, but using a
Structured What If Technique (SWIFT) for diversity of method, and using different personnel
for independence of analysis. SWIFT takes a technology, flow or procedural assessment,
using structured categories and key words for hazard elicitation, which (with separate
personnel for different thought processes) is proposed as ensuring adequate independence
of assessment. The SWIFT results are presented in Annex E; the hazard listing from the
modified FFA process is presented in Annex F, and the results are jointly evaluated in
Section 3.3.
Case Study Description
The 'Guard Dog' case study has been defined based on a number of current and near-future
Tactical UAV Systems. While intended for over battle-field use, the Armed Forces need to
train in their use, and with extended range and duration, they are keen to operate outside
segregated range area boundaries. The case study considered a generic Tactical UAV
(TUAV) operating out of a 'UAV friendly' airfield and out into integrated general (not
controlled) airspace, in order to reach a range area for payload operation. The case study
introduced aspects of interest relating to the performance and operation of the system, as
well as the need to integrate it into a varied terrain and airspace environment. The
background to the case study is shown in Annex C to this report, while a graphic overview of
the system is shown in Figure 3.1b, below.

62
 Figure 3.1b - Overview of Guard Dog UAVS case study

3.2 Evaluation of the Modified HazID Method through Trial

Application
This section looks at the actual application of the proposed FFA method, and evaluates its
practicability of use. Extracts from the FFA are shown below as examples, while a fuller
listing is shown at Annex D.

3.2.1 Derivation of Safety Criteria and Objectives for UAVS

Application
Deriving airworthiness safety criteria using the [UTF04] suggested definitions in Table 2.2.1(i)
was straight forward at this stage – more questions were expected in their application (see
Section 3.2.5).
Minor Major Severe Major / Hazardous Catastrophic
- Slight reduction in - Significant reduction in safety - Controlled loss of the UAV UAV's inability to
safety margins margins (e.g., total loss of over an unpopulated continue controlled
(e.g. loss of communication with autonomous emergency site, using flight and reach any
redundancy) flight and landing on a predefined Emergency Recovery predefined landing site
emergency site) procedures where required.

Table 3.2.1(i) - Airworthiness Failure Condition Severities for ‘Guard Dog (drawn from
Table 2.2.1(i))

63
Defining safety objectives proved almost as straightforward. Using both the CS.23.1309
definitions shown in Table 2.2.1(iii) (Single Reciprocating Engine (SRE) / under 6000lbs),
and the CAA kinetic energy method (shown in Annex B), both arrived at the same conclusion
of CS.23.1309 Class 1 probability criteria.
ATM separation criteria were already fixed, in accordance with Table 2.2.1(ii) (as they do not
change with vehicle class).

3.2.2 FHA Levels to Address System Complexities

At this stage it was not possible to pronounce on the success of a ‘UAVS-level’ FFA – more
is said of this in Section 3.2.3
What did prove very useful was the derivation of a rich context diagram to model the System
of Systems – see Figure 3.2.2-1 (a larger scale version is shown in ‘landscape’ at Figure D-1
in Annex D).

Figure 3.2.2a - Rich Context Diagram for Guard Dog UAVS and the System of Systems
It took quite a while to arrive at a result that seemed satisfactory, but this was a measure of
the complexity of interactions rather than any difficulty of method.
The figure shown is the result of a one-man application. It would have been very useful at
this stage, to use the diagram as a focus for discussion with key stakeholders, in order to
draw out any more interactions.

64
3.2.3 Function Identification
Internal Functions
As the case study was intended to be generic, there was no formal documentation such as a
User Requirement Document, or Yourdon diagrams, only the brief outline of the Case Study
(Annex C). The function derivation was thus from first principles.
The simple representation of initial design architecture (Figure 3.1b / Figure C-1) was useful,
to help break the system down to manageable pieces (while still being able to consider the
overall system). It helped to be able to look at each element in turn, to draw out functions
from that view. In considering each element, a ‘mind map’ was drawn for each element to
pick out its related functions, then resolve / consolidate any overlaps between different
elements under higher level function. For example, ‘Manage Datalink’ was a function picked
out to cover aspects pertinent to both UAV and GCS viewpoints. Care was needed to not
become too ‘object’ focused (we still wanted to keep a system-level overview). An example
of one of the mind maps is shown in Figure 3.2.3a.

Download Distribute
payload data payload data Prioritise
sensor / data
requests from
Users

Plan Route
Direct sensors
Manage
Payload

Mission
Change Planning Upload
Mission Plan Mission Plan

Control UAV? via next GCS?

GCS

manual
Override -
NEC
remote
Control
piloting
Datalink Path
Monitor Via Satellite?
Mission Manage
Progress DataLink

D/L Fail Emgy

Status of UAV Action Via UAV
Actual path v Relay?
mission route Monitor Data
link condition

GCS Centred view

Figure 3.2.3a – Example of use of mind-map to consider each
system element’s view of functions
The discipline of making a check of behaviour, control and information functions was also
useful, though it was less easy (inappropriate?) to consider utility functions at this stage –
that would perhaps prove more useful at the next level of sub-system FHA. These types
helped draw out extra aspects: for example, it was initially thought that there wasn’t much to
the field recovery / launch team element, but the list drew out information and utility aspects
such as mission upload and replenishing consumables.

65
The derivation and consideration of flight phases also proved useful as a mind jogger: while
the initial listing had found 56 functions, consideration of flight phases gained 5 more relating
to internal functions.
It was difficult to not get too pulled into design, especially over aspects such as autonomy.
Positive effort was needed to stay up at system level, i.e. not to try and partition functions
into whether they were performed by the UAV or GCS / UAV-p. This proved to have been a
good discipline, when it came to considering failure effects later on (see ‘Multiple Failures’, in
section 3.2.5).
At this stage, it was becoming evident that the UAVS-level FHA was proving quite effective,
in being able to identify (and hence analyse) system interrelations and complexities.
Exchanged Functions
As hoped, the rich context diagram proved very handy for drawing out exchanged functions.
A table (Table D(v) in Annex D) was used to list each interaction, then focus on what the
UAVS needed to provide to make the interaction work.
Some ‘functions’ were included that might not strictly be functions (perhaps characteristics?),
but they had clear potential safety aspects. For example, ‘Conspicuity to Air Traffic’ is a fairly
passive function but important to make ‘see and avoid’ work for non-cooperative air traffic.
The rich context diagram was, again, supportive of drawing out such necessary
characteristics.
What became evident later on was the need to define basic behavioural functions, to handle
key emergency conditions – this is discussed in section 3.2.4 under ‘Emergency
Configurations.
Consolidation
From these functional views, 103 functions overall were identified (at all levels). 56 were
extracted from internal views; 42 from the external context; and 5 new from looking at Flight
Phases.
There seemed to be no real need for a separation of internal and external functions, and
many were interrelated (see below), so they were combined into a single Functions Tree,
ready for consideration in failure identification. Part of the tree is shown in Figure 3.2.3b.
The tree in full can be seen in Figures D-4a, b and c at Annex D.
In trying to rationalise these functions into a tree, the interaction between functions grew
apparent. E.g. ‘Auto Take-off and Landing’ has lower level functions to determine runway
and landing characteristics for particular wind speed and direction, but functions under
‘Monitor weather for changes’ would affect the wind speed determination, and functions
under ‘Stability and Control’ provide the actual take-off rotation or landing flare. There were
‘building block’ functions that, perhaps, higher order functions across the tree would make
use of. These would be considered carefully when looking at functional failures and multiple
failures.

66
 UAVS Function Tree
UAVS
[PartFunction
1 of 3] Tree
[Part 1view
(I) Internal of 3]
(I) Internal
(F) Flight phase view
view
(F) Flight
(E) External phase view
context view
(E) External context view

1. Stability & 3. Control on the

2. Air Navigation
Control Ground
(I)
(I) (I)

2.1 Position, 3.1 Control 3.2 Control

1.1 Determine 1.2 Stabilise 2.2 Store /
Heading & Speed on the Position on the
attitude, perturbations (I) Update Mission
Altitude ground (I) ground (I)
orientation and Route
Awareness
speed (I) (I)
(I)

2.1.1 Determine 2.1.2Determine

3.1.1 Determine 3.2.1 Determine
1.4 Manual Position, Nav Data 3.1.2 Controlled 3.2.2 Ground
1.3 Manoeuvre speed on ground position
Override - Heading & accuracy Ground thrust (I) steering (I)
UAV ground (I) & heading (I)
Remote Piloting Altitude (I)(F)
(I)
(I) (I)

2.4 Auto Take 3.1.3 Controlled 3.2.3 Determine 3.2.4 Monitor /

1.5 Field T/O 1.6 Control 2.3 Monitor / off & Landing Ground Braking Airfield layout / correct actual v
Launch Control Flight Path Correct actual v (I)(F) (I) required ground required ground
(I)(F) (I) planned route route (F)(E) route (F)
(I)

2.4.2 Determine 3.2.5 Determine 3.2.6 Determine

2.4.1 Determine
High accuracy Air / Ground Ground
Airfield T/O
1.6.1 Control 1.6.2 Control transition (F) obstacles (F)(E)
Climb-out Position,
Airspeed Altitude & Rate
profile (F)(E) heading &
(I) (I)
Altitude
(F)
3.2.6.1 Detect
1.6.3 Control 2.4.3 Determine mobile
Heading Airfield 2.4.4 High obstacles (F)(E)
(I) Approach, Hold, Accuracy
Circuit, R/W monitor / correct
profile (F)(E) actual v planned 3.2.6.2 Fixed
profile (F)(E) obstacles
awareness
2.4.5 Determine (F)(E)
Windspeed &
direction v R/W
and landing
characteristics
(F)

2.6 Sensitive
2.5 Terrain Area Avoidance
Avoidance (E) (Danger &
Populated
areas) (E) - as
2.6.1-3

2.5.1 Awareness 2.5.2 Maintain

& flight path separation
proximity (E) (ROA) (E)

2.5.3 Emergency
evasion (E)

2.8 Variable
2.7 Controlled
Danger Areas
Airspace
(NOTAMS)
avoidance (E) -
Avoidance (E) -
as 2.6.1-3
as 2.6.1-3

Figure 3.2.3b – Example of derived Functions Tree for ‘Guard Dog’ UAVS

3.2.4 Identification and Description of Failure Conditions

Environment List
The domain-review list provided a good structure for derivation of the environment list.
Weather aspects were fairly easy to pick out, from UAVS overall specification (based on
world-wide operation).
Aspects such as overflown terrain were trickier to complete, as they are not a usual
specification item. Looking at the map examples for scenarios (discussed in section 3.2.5)
helped significantly. These also helped with extracting the range of electrical / mission / ATC
environments. It was useful to define a number of potential missions (see Appendices C1
and C2) and use these to define typical scenarios (see 3.2.5), to get a better feel of likely
environments. Looking at maps for areas of operation (and training in more domestic climes)
teased-out a wide variety of such aspects.
Emergency Configurations
Guard Dog started with the list as initially proposed in section 2.2.4. However, consideration
of this list quickly highlighted a need to consider what the UAVS intent would be in event of
such emergencies, especially for system failures. Hence, a useful source document would

67
be an initial definition of emergency procedures, as part of the ‘initial design considerations’.
The Guard Dog example is shown in Figure 3.2.4a below, or in bigger scale as Figure D-2 in
Annex D.
These considerations spawned additional functions (to be added to the tree), to be assessed
for further functional failures (part of multiple failures consideration).

YES

Regain D/L NO
Hold
DATA LINK Signal Loss Signal?

DATA LINK System Fail (total) Broadcast Control

Datalink Fail

DIVERT to
DATA LINK System Fail (single) identified
diversion
NORMAL FLIGHT airfield
FLIGHT CRITICAL SYSTEM SIngle (Redundant) Failure
Determine best diversion and
ID between GCS and UAV (May COMMUNICATIONS Failure
be home or destination)

Maintain flight path over 'safe'

AIR NAVIGATION Failure
terrain and airspace YES
(inc. height, speed, position & route control) Able to Maintain Safe YES External Nav
Altitude? Asistance?

FLIGHT CRITICAL SYSTEM Total Fail

Broadcast
COLLISION AVOIDANCE Failure NO NO
Mayday &
EMERGENCY
GROUND CONTROL Failure LANDING

Broadcast
Collision
Avoidance fail

STOP &
Broadcast

Figure 3.2.4a – Example of outline Emergency Procedures, to derive functions

Failure Conditions Determination
With a significant number of functions, care was needed to ensure that all failure
characteristics had been considered. In this, the FFA structure proposed worked well, as
discussed below. Some failure conditions are shown below, but all identified can be viewed
in full at Table D(vi) in Annex D.
‘Loss of function’ - could be tricky to assess, for continuous functions (i.e. to search deeper
than just ‘loss of [function X]’). Some interesting conditions were found where a function
could be pseudo-continuous. For example, ‘Terrain Awareness’ being made on a regular but
not truly continuous basis (function 2.5.1 – see Table 3.2.4(i)): a potential failure condition
was for sharp terrain to appear in the event horizon, if the update rate was not high enough.
FFA Function (a), (b), Failure Condition (Hazard Description)
ID (c)
2.5 Terrain Avoidance (E)
F2.5A 2.5.1 Awareness & flight path (a) Unaware of surrounding terrain
proximity (E)
F2.5B (a) Unaware of proximity of surrounding terrain to
flight path
F2.5C (a) Terrain proximity determined at low sampling rate
Table 3.2.4(i) – Example of ‘Loss of Function’ for pseudo-continuous function
‘Uncommanded function’ – Some care was needed not to dismiss functions as ‘continuous’.
For example, Function 1.6.1 ‘control airspeed’ is indeed continuous overall, but has some
implied sub-functions such as to change airspeed intermittently when required, hence the
potential uncommanded sub-function to change airspeed up or down when not required.
(See Table 3.2.4(ii)

68
 FFA ID Function (a), (b), (c) Failure Condition (Hazard Description)
F1.6C 1.6.1 Control Airspeed (I) (b) Airspeed runaway up
F1.6D (b) Airspeed runaway down
Table 3.2.4(ii) – Example of ‘Uncommanded Function’
‘Incorrect function’ – as expected, this category generated the widest variety of issues, and it
could be hard to determine that all had been identified. Some of the most interesting failures
were where a function potentially crossed system boundaries. For example, handover of
control between 2 GCS (function 4.2.1) led to several variations of end result (see Table
3.2.4(iii)
FFA Function (a), (b), Failure Condition (Hazard Description)
ID (c)
F4.2C 4.2.1 Handover to next (c) Datalink control hand over from current GCS, but next GCS
GCS (I)(F) unable to take control
F4.2D (c) Datalink control hand over from current GCS, but next GCS
unaware it has control
F4.2E (c) Datalink control taken over by next GCS, without current GCS
being aware
F4.2F (c) Datalink control hand over to next GCS, but current GCS also
retains control (dual control)
F4.2G (c) Datalink attempted control hand over to next GCS, but neither
GCS retains control
Table 3.2.4(iii) – Example of ‘Incorrect Function’ for a cross-system function
At this stage, hazards weren’t all identified with separate annunciated and unannunciated
versions, as this would have led to a ‘failure condition melt-down’. Instead, each would be
evaluated for consequences in the next phase. That said, there were functions where
warning was a specific aspect, and these were assessed directly. For example, in broadcast
of warnings such as for function 9.7 (see Table 3.2.4(iv)).
FFA Function (a), (b), Failure Condition (Hazard Description)
ID (c)
F9.7A 9.7 Emergency Broadcast Actions (E) (Coll (a) Unable to broadcast – “Collision Avoidance
aware fail; D/L fail; Mayday) Fail”
F9.7B (a) Unable to broadcast – Data Link Fail
F9.7C (a) Unable to broadcast – Mayday
F9.7D (b) Broadcast ‘Collision awareness fail’ when not
required
F9.7E (b) Broadcast ‘Data Link fail’ when not required
F9.7F (b) Broadcast ‘Mayday’ when not required
F9.7G (c) Broadcast incorrect emergency message
compared to that actually required
Table 3.2.4(iv) – Example of failure identification for a warning function
As usual with FFA, there was a lot of output. The initial 105 functions gave rise to about
520 failure conditions. Care was needed to bring this to a manageable number of hazards
at a similar level, to assist hazard management.

3.2.5 Identifying and Managing the Effects of the Failure Conditions

Table 3.2.5(i) shows some examples of the analysis of effects of failure conditions, extracted
from the fuller analysis shown in Table D(vii) in Annex D. These examples are used to
illustrate the discussion of the analysis, contained in this section.

69
 Table 3.2.5(i) Examples of analysis of the effects of failure conditions,
from the ‘Guard Dog’ FFA
FFA Failure Flight Effect of Failure Classification Justification
ID Condition Phases1 Condition2 - (1) AW; (2)
ATM
F1.2A Loss of UAV Tax, TO A, (1) Unstable UAV leads (1) Catastrophic [Critical safety
stability TO F, to overall loss of control – (2) Severity 1 requirements will be set, if
Tran, unable to continue the Relay role is to be
Hand, Tran controlled flight viable in unsegregated
S, Sens, Knock-on for Relay UAV airspace.]
App, Land would be loss of data link
A, Land F, for Sensor UAV
Rel
F1.2B Undamped / TO A, TO (1) Significant reduction (1) Hazardous
poorly F Land A, in safety margins during (2) Severity 2
damped Land F T/O or landing, due to
manoeuvres Tran, oscillations. Potential for
or speed Hand, Tran ground impact close to
S, Sens, T/O or landing area
App, Rel (2) Severe oscillations
could cause height bust,
deviation from clearance
on approach, or reduced
separation
F1.3I Manoeuvre TO A, TO (1) UAV break up – (1) Catastrophic AW issue, as vehicle
capability F, Tran, unable to continue break up takes it out of
exceeds Hand, Tran controlled flight the ATM environment
vehicle S, Sens,
structural App, Land
strength A, Land F,
Rel
F1.4A Unable to Taxi, TO A, No immediate effect, As for the most Manual override is
take manual TO F, UNLESS a coincident severe of other intended as mitigation for
control of Tran, functional failure occurs functions 1-10: many other failure modes.
UAV Hand, Tran (in functions 1-10 inc) (1) Catastrophic Safety requires
S, Sens, requiring manual (2) Severity 1 independence from other
App, Land intervention failure forms (EITHER -
A, Land F, autonomy in case of
Rel manual failure, OR - use
of an independent 3rd
option such as Flight
Termination System to
give a safe outcome, if
critical functions are
provided on a common
datalink with manual
control from the GCS)
F2.1A Unable to TO A, TO In isolation – position can In extreme AW severity assumes
determine F, Tran, be approximated from cases: need to make blind
position Hand, Tran heading, speed etc. (1) Catastrophic emergency landing at last
S, Sens, In common failure with (2) Severity 2 ‘known’ position (MS7
App, Land F2.1B or F1.1B – emergency landing
A, Land F, requires external means scenario shows that small
Rel to identify position inaccuracies could cause
(functions 9.3 En-route impact on village location,
ATC communications as lesser evil to flying on
and 9.4 Tracking and possibly crashing in
‘visibility’ major population area
Without these, system ATM severity assumes
faces emergency landing that function 10 Collision
(function 7.3.2) in avoidance remains active
unknown terrain, or flight – need to beware of
path through unknown potential common mode
airspace failures.
Knock-on for Relay UAV

70
 FFA Failure Flight Effect of Failure Classification Justification
ID Condition Phases1 Condition2 - (1) AW; (2)
ATM
would be loss of data link
for Sensor UAV
F2.5A Unaware of Tran, (1) UNDETECTED – (1) Catastrophic Assumes TO and Land
surrounding Hand, Tran Controlled flight into covered by functions 2.4
terrain S, Sens, terrain – ensure no combined
App, Rel DETECTED – climb to functionality / common
safe height and divert mode failure
F4.3A D/L fail action TO A, TO IF UAV does not take No action: (1) No action - Represents a
(hold then F, Land A, necessary autonomous Catastrophic failure of a critical
divert) not Land F, action, then effect as autonomous response, to
taken when Tran, F4.3C [UAV will Continues pre- get the UAV down safely
required Hand, Tran eventually run out of fuel planned in event of D/L failure
S, Sens, and crash land] actions: (2) Continue previous action
App, Rel IF UAV continues on its Severity 3 – degrades ATM safety,
pre-planned path but but continuing autonomy
without diverting, may gets the UAV down safely
cause concern to ATM
(prolonged exposure to
UAV without manned
override capability) but
should act safely if
functional
F9.7A Unable to TO A, TO (2) Failures under F10 for (2) Severity 1 [see functions 10,
broadcast – F, Tran, Collision avoidance Collision Avoidance, for
“Collision Hand, Tran system, following function safety-related functions
Avoidance S, Sens, 7.3.1 to divert would be where this function is
Fail” App, Land UNDETECTED by ATM intended as mitigation]
A, Land F, and other air traffic – they
Rel would proceed as if UAV
would respect Rules of
the Air, in extreme
allowing collision
F9.7C Unable to TO A, TO (2) Failures requiring (2) Severity 1 Classified as severity 1,
broadcast – F, Tran, function 7.3.2 Emergency on basis that it could
Mayday Hand, Tran Landing would be make a bad situation
S, Sens, UNDETECTED by ATM (Severity 2) much worse
App, Land and other air traffic. by not being able to send
A, Land F, Controlled emergency assistance rapidly to the
Rel landing would not be scene.
affected, but could affect [Difficult to classify, with
ability of ATM to alert criteria as listed]
emergency services to
the site.
Notes:
1. Flight Phases – (Pre) Pre-flight; (Tax) Taxiing; (TO A) Take-off – from airfield; (TO F) Take off – ramp
launch from field; (Tran) Transit under control of GCS; (Hand) Hand over control to second GCS; (Tran S) Transit
with GCS relay via satellite; (Sens) On Task – using sensor payload; (Rel) On task - on station to relay TCDL to
reach sensor UAV; (App) Approach; (Land A) Landing – at airfield; (Land F) Landing – rough field.
2. Effect of Failure Condition – (1) AW – effect on UAV, safety margins, continued & controlled flight; (2)
ATM – effect on UAV Crew, ATCO, other Traffic

Identification of Failure Effects

In general, it was fairly simple to identify the broad effects of potential failures. This was
particularly true of the ‘building block’ functional failures (as mentioned in section 3.2.3, in
‘consolidation’): when these failed, the effects were pretty direct. An example is shown in
Table 3.2.5(i) with failure F1.2A “Loss of UAV stability”.
Some effects were worse in particular flight phases and this was noted in deriving the effects.
One point of note was the crucial effect on the UAV system overall, when a failure occurred

71
to a vehicle in Relay flight phase (as noted in F1.2A). The criticality of the UAV in this role will
set very high safety requirements if this role is to be cleared in unsegregated airspace, and
perhaps it may only be cleared for training with a viable alternative datalink path always
available (so as not to be a critical dependency).
Most failures had both airworthiness and ATM separation effects. An example is shown in
Table 3.2.5(i) for F1.2B “Undamped / poorly damped manoeuvres or speed”, where both
an immediate airworthiness effect could be identified, and a slightly longer term ATM
separation effect if the airworthiness effect was not immediately realised.
A few failures indicated an airworthiness effect only, such as F1.3I “Manoeuvre capability
exceeds vehicle structural strength” in Table 3.2.5(i). The airworthiness effect here was
usually so cataclysmic that there was little likelihood of further ATM effect.
A few others, such as F9.7A “Unable to broadcast – “Collision Avoidance Fail” ” in
Table 3.2.5(i), indicated an ATM effect only. These were usually directly related to ATM
procedural or traffic separation functions.
Some functions had already been added in as emergency ‘warning’ functions, in response to
early consideration of the effects of ‘annunciated’ vs ‘unannunciated’ failures. However, all
failures were considered for the differences with the failure being annunciated detected or
not. F2.5A “Unaware of surrounding terrain” shows a particular example, where detection
would allow a much safer effect than the alternative, and this would help set particular safety
requirements on the system to improve detection.
Classification of (Airworthiness and ATM) failure effects
The safety criteria discussed already in section 3.2.1 proved useful, and usually easy to
apply. This was especially true of the airworthiness criteria, and (usually) of the ATM
separation criteria.
There were a few exceptions with the ATM separation criteria, where the classification in
terms of ATC workload, traffic separation or collisions could not easily be applied. Here,
classification came down to a judgment on the level of ‘loss of control’ by ATM and UAV-p
and the effective reduction in safety margins. An example is shown in F9.7C “Unable to
Broadcast ‘Mayday’” in Table 3.2.5(i), where there is no further airworthiness effect, but there
is an ATM / UAV-p effect, as ATC can’t be alerted to apply their procedures to call
emergency services to the site.
Multiple failures
Some key multiple failures had already been considered, by creating emergency intent
functions (mentioned in section 3.2.4 Emergency Configurations) and then analysing failures
in these follow-on functions (e.g. F9.7A “Unable to broadcast – “Collision Avoidance
Fail” ”, already mentioned above). Others were derived from key aspects of the initial
system architecture, such as the datalink between GCS and UAV.
While not many more ‘failures on failures’ were analysed in detail, there were some failures
where the criticality of certain other functions remaining effective (for mitigation) were noted.
Here, the main drive was to identify safety requirements to ensure effective mitigation,
particularly the need to establish independence of such functions and avoid common mode
failures. A specific example (among many) is F2.1A “Unable to determine position”,
where the potential effect is not so bad, provided that other key functions such as Collision
Avoidance functionality remain operational. If there was a common system factor (such as
some datalink dependence for these functions) then the effects would be much worse.
This brings us to a particular issue drawn out by consideration of multiple failures. Up to this
point, the analysis had avoided partitioning functionality between the UAV, GCS and UAV-p
(i.e. making decisions on autonomy levels). Now it was possible to set requirements on
critical functionality. The primary concern was the need to make safety critical functions
independent of the datalink. Safety is thus a driver for increased capability (and

72
assurance) in autonomy for those functions. There are endless examples where dual failure
with datalink would be Catastrophic / Severity 1, but a couple from Table 3.2.5(i) are
discussed below.
This issue of autonomy v datalink was first noted in the FFA during consideration of F1.4A
“Unable to take manual control of UAV”. Here, the effect was not serious provided that
the system had adequate autonomy to carry out necessary safety actions such as collision
avoidance, terrain avoidance, air navigation and conducting emergency procedures. This
was later backed up by consideration of specific datalink function failures, where the knock-
on effect of not carrying out those functions was noted – especially examples such as F4.3A
“D/L fail action (hold then divert) not taken when required”. For this, the effect of failure
was proposed as:
“If the UAV does not take the necessary autonomous action, then the effect is as F4.3C
[UAV will eventually run out of fuel and crash land]. IF the UAV continues on its pre-
planned path but without diverting, this may cause concern to ATM … but should act
safely if functional.”
UAVS thus need careful use of autonomy, to provide the necessary independence of safety
functions. As a minimum (for smaller systems perhaps, where the public would be less
alarmed), the use of a Flight Termination System would be an alternative, independent
means of assuring a ‘safe’ outcome.
Use of Scenarios to Aid Effects identification
For the majority of failures analysed, scenarios weren’t necessary, and consideration against
more general contextual information was appropriate.
Where they were necessary, the initial guidance led to scenarios that were almost too
specific. Text based scenarios (as proposed) needed a fair number of words to get the
situation across, and still seemed to be lacking necessary information. An example is shown
in Figure 3.2.5a.
An alternative was tried, with better results. This approach was to plan actual missions over
typical terrain, on air maps. Using this, the user got a better idea, more quickly, of the type
and range of challenges – terrain, airspace, obstructions, HIRTAs etc. It was vital to actually
plan the route on paper, not just look at the maps, in order to think into actual mission-type
situations. For example, identifying where to place a GCS to achieve datalink along full
length of route; or how to respect airways minimum heights, while being pushed by terrain to
maintain minimum separation – airmanship-type decisions. The map could be annotated
with other conditions of interest, such as the possible range of weather.
The same proved true when looking at emergency situations. For instance: what if the
weather closes out the planned route here; or propulsion fails there; or satellite datalink
becomes unavailable when ground GCS range is marginal.
Overall, it seemed that graphical mission scenarios were more user friendly and encouraged
creative thinking. They contained more information and felt more ‘real’ than just broad
specification envelopes; but not too specific – they allowed ‘what ifs’ to be raised and
assessed quickly, some of the what-ifs being driven by the map terrain and airspace content.
An example of a graphical mission scenario is shown in Figure 3.2.5b, comparable to the
textual scenario shown in Figure 3.2.5a.

73
Scenario : Routine Take-off
Rationale: Applying general take-off to realistic situation, at ‘UAV-Friendly’ Parc Aberporth
Agents: UAVS and UAV-p; Aberporth ATC and ground traffic; Cardigan Bay danger area controller
Situation and environment context: Day VFR weather fine. Onshore breeze from the sea, 20kts.
Take off and climb out planned over sea (away from Aberporth village at foot of significant hills), then
turn out over sea for first leg. Several wind farms on coast, and steep terrain.
Mission context and goals: Start of a routine training mission. Intent is to taxi and take off safely,
respecting airfield ATC and ground / circuit traffic. Main goal is to get established on first leg of fly out,
at start of a long training mission.
Airspace context: Parc Aberporth is a UAV-friendly airfield, used to UAV activities. Some light
manned aircraft traffic in circuit, including military aircraft incoming from / outbound to the danger area
(range).
Danger area is a sea range, for aircraft and ships weapon trials (closed to traffic during attack runs).
First leg to Talybont, crosses under Airway A (at 6,500 ft, under airway starting at 16,500 ft)
System context: Full system functionality, as checked during pre-flight and taxi checks
Actions: UAV-p contacts airfield ATC for clearance to taxi – this is given and UAV taxis out to stop at
Hold ‘CHARLIE’. After other traffic clears, ATC clears UAV onto runway 26 for take off. UAV applies
power and takes off, correcting for slight cross-wind. After clearing obstruction height and reaching
2000ft, UAV told to switch to danger area controller frequency.
Danger area controller clears UAV to the north, commanding to keep clear of south end of range
where ships are operating on range. UAV heads onto northerly track, climbing until reaching 6,500ft.
As it leaves the danger area, UAV switches to Holyhead Airspace Controller and requests Flight
Information Service for transit to Spadeadam.
Figure 3.2.5a – Example of mini scenario for consideration of failure effects

Figure 3.2.5b – Example of graphical scenario ‘MS1 Routine Take-off and climb out’

74
The scenarios were used in a few analyses of the effects of failures. This was usually as
follow-on to trying to assess the effect with broader information, to check and improve on the
justification behind an effect analysis. For failures like F4.2F “Datalink control hand over
to next GCS, but current GCS also retains control (dual control)” (in table 3.2.5(i)) this
was useful, where the impact is not clearly apparent on first analysis.
Occasionally, they were used to help ‘put flesh on the bones’ behind an analysis, to ensure
that the ensuing classification was suitably robust. Failures such as F2.1C “Unable to
determine altitude” show such a use, where the effect was already felt to be quite severe,
but the emergency landing scenario provided an alternative context to re-assess the
classification.

3.3 Evaluation of Hazards Identified by the Modified HazID

Method
The functional failures (in Annex D) produced by the FFA process have been reviewed by
the author, in order to determine a list of hazards at a common, appropriate level. This
hazard listing is shown at Annex F to this report. Some 88 hazards are listed in all, with
references to the functional failures that spawned them.

Numerical assessment
How robust is this hazard listing and (accordingly) the FFA HazID process that has been
used? As discussed in Section 3.1, a SWIFT technique was commissioned to provide a
comparison, with the overall results shown in Annex E. Both Annexes E and F cross refer to
the appropriate comparable hazard(s) identified in the alternative technique.

The comparison of techniques is interesting, if not straightforward. Our FFA method

produced 88 hazards, while SWIFT produced 77. Of these, 48 were in close agreement.
Using the MAFF ‘capture / recapture’ method as discussed in Section 3.1, this would
indicate, initially, the following metrics:

Initial metrics for hazard capture confidence:

‘Proportion of hazards captured’ = 48 / 88 = 0.55

‘Possible total number of hazards’ = 77 / 0.55 = 140

This was not overly inspiring of confidence in the results, so further investigation was made
to see if they were overly pessimistic. From the first pass comparison, 29 SWIFT hazards
did not directly match FFA hazards. However, the comparison was not always made on a
level footing:

• Several of the SWIFT hazards (10) were related to ground personnel, whereas the
FFA focus was on operating hazards more relevant to manned / unmanned aircraft
integration. The ARP 4761 process would eventually draw these out through complementary
analyses such as Operating & Support Hazard Analysis.
• About 10 of the SWIFT hazards were more causal than directly hazardous, related to
system implementation. These (through ARP4761) would be considered under Fault Tree
Analysis at the UAVS level, or FHA and FMEA for lower level systems. A further 2 were
related to uncontained engine failure and fuel fire, and would be considered under Particular
Risk Analysis with the [SAE96] process.

75
• A further 3 SWIFT hazards related to general procedural aspects, covered by
regulation, such as maintenance policy and crew training.

Having removed these hazards (for now) to achieve a common level, a revised comparison
could be made. SWIFT now had identified 52 hazards, with 48 agreeing with the FFA:

Revised metrics for hazard capture confidence:

‘Proportion of hazards captured’ = 48 / 88 = 0.55

‘Possible total number of hazards’ = 52 / 0.55 = 95

This suggests that the FFA has identified about 90% of the total hazards for manned /
unmanned aircraft integration.

Subjective assessment of differences

As noted above, the SWIFT had already identified some ground-based and causal hazards
that the FFA (at this stage) had not – we can propose that these would be identified by
subsequent stages of the ARP4761 process.

Four SWIFT hazards remain that cannot be explained in this way, and these are shown
below.

• S13 Inadvertent launch

• S25 Poor preparation of launch site (inadequate runway quality)
• S41 Loss of GCS communications
• S48 Pilot fatigue (long endurance shifts)
These indicate two issues with the FFA. Firstly, the FFA is only as good as the initial
function tree, and this application had missed out a small number of functions – e.g. ‘Inter
GCS Communications’. A peer review of the Rich Context Diagram and Functions Tree
might have picked these (and maybe more) out. Second, in spite of the intent to pick out
functions including human issues, it was still difficult for the FFA to consider and draw
hazards out of high level human factors, such as the resource issue of long endurance shifts.
This is why it is still important to ensure that Human Factors are adequately assessed and
designed for, in their own right.

The FFA of our proposed method had, in turn, identified 38 additional hazards relating to
integration of UAVs into unsegregated airspace – these are shown below:

• A4 Flight instrumentation (attitude and speed) errors

• A5 Inability to identify flight instrumentation errors
• A9 Unable to transfer to autonomous UAV control
• A10 Conflicting authority between UAV controllers (manual / autonomous or different
ground controllers)
• A11 Control mode error (where control laws differ with phase of flight)
• A13 Asymmetric thrust / power
• A16 High accuracy navigation instrumentation errors (altitude, position, heading; for taxi,
take off, approach, landing)
• A17 Inability to identify navigation instrumentation errors
• A19 Planned mission route not achievable by UAVS (not capable within performance)
• A20 Planned mission route not safe (by Rules of the Air)
• A25 Minimum terrain separation (i.a.w. Rules of the Air) not maintained
• A26 Terrain separation / emergency evasion triggered when not required / appropriate

76
 • A27 Separation from sensitive areas (danger areas / populated areas / NOTAMS areas)
not maintained
• A29 Incorrect type / identifier of controlled airspace determined (if cleared for controlled
airspace operations)
• A35 Incorrect airfield layout / ground taxi route determined
• A36 Inability to determine ground / air transition clearly
• A37 Unable to correctly determine position of fixed / mobile ground obstacles
• A38 Inability to accurately determine command datalink signal strength
• A39 Incorrect status of command datalink system serviceability determined
• A41 Command datalink handed to GCS, but GCS unaware it has control
• A43 Command datalink lags via satellite / relay
• A45 satellite / relay UAV passes control datalink commands to incorrect UAV
• A47 Command Datalink jammed
• A49 Valid command datalink rejected as jammed / stolen
• A52 Inability to monitor initial / changing weather conditions along the mission route
• A53 Bad weather re-routing infringes sensitive airspace / overflown areas
• A54 Bad weather re-routing exceeds UAV capability (performance)
• A58 Diversionary airfield / route not communicated between UAV and GCS (UAV not
aware of appropriate action to take, or GCS not aware what action the UAV will take)
• A62 GCS moding initiates ground mode displays and controls (e.g. mission planning),
when in-flight monitoring / control required
• A68 UAV centre of gravity adversely affected by fuel charge
• A70 Different mission plans loaded - UAV; relay UAV; first GCS; other GCS in mission
• A72 inability to correctly detect, interpret and respect airfield visual signals
• A77 Radio frequency changed in error (e.g. to emergency frequency)
• A78 UAV does not correctly comply with Airfield ATC procedures: ground movement
(clearance & direction); enter runway; take-off; climb out direction and final height; approach
direction; circuit direction; runway allocation; hold height & direction; landing clearance; exit
runway clearance
• A79 UAV does not correctly comply with en-route airspace ATC procedures: Climb /
descend and final cruising altitude; heading change; hold position, height and direction;
diversion
• A80 UAV complies with Airfield or En-route ATC procedure intended for another aircraft
• A81 Unable to correctly broadcast emergency message: “Collision Avoidance Fail”; Data
link fail"; "Mayday"
• A82 Emergency broadcast made when none necessary
• A88 UAV resembles other aircraft types of different size or performance
This list seems eclectic, and it is awkward to pick out particular aspects where the FFA
method might have been ‘better’ than SWIFT. Overall, the longer listing was due to the
rigour applied to identifying functions, especially using the Rich Context Diagram to identify
external functions (the SWIFT perhaps focussed on the internal). The FFA also performed
well in identifying hazards related to the operating environment and their airworthiness
implications, such as in collision and terrain avoidance, and in airmanship through airspace
and airfield environments.
Summary of Hazard Identification Robustness
In all, the FFA performed well in hazard identification, identifying around 90% of hazards
relating to integration of UAVS into non-segregated airspace even as a one-man technique
carried out in isolation. With team input and peer review, this would improve further.
However, it is important to remember that FFA is just the first part of the ARP4761 process,
and subsequent causal and sub-system analyses are important to draw out all pertinent
hazards. Additionally, techniques such as Operation & Health Safety Analysis and especially
Human Factors Engineering will be necessary, to ensure all potential hazards are identified
and managed.

77
PART 4 – CONCLUSIONS AND FURTHER WORK
This part of the report aims to pull together the key findings of the project, and relate them to
the original aims. It also provides a ‘shopping list’ of recommendations for further work, in
order to advance the cause of UAVS integration.

4.1 Findings, Related to Satisfaction of the Project's Aims

The overall motivation for the project was to assist the process of integration of UAVS into
unsegregated airspace, by addressing the lack of understanding of the safety issues and
hazards involved. More specifically, the following aims were identified:
• To identify the current concerns over UAVS safety, in relation to the existing manned
airspace infrastructure;
• Hence, to derive a framework for considering the safety risks related to integrating
unmanned vehicles into unsegregated airspace. The intent is that this, as part of a
robust safety assessment and certification programme, will assist in the eventual
clearance of UAVS, to operate routinely alongside manned aircraft.
Each of the reports key findings is considered below, in relation to these aims. Conclusions
are numbered 1-14 in this section.

4.1.1 Identifying Current Concerns over UAVS Safety

Part 1 went somewhat further than the initial intent of identifying current concerns in relation
to the existing manned airspace infrastructure. Because of the complex, interrelated nature
of UAVs, a more complete view of safety concerns was taken, which included the airspace
infrastructure but also covered design airworthiness, operations, airmanship and the inherent
‘differences’ introduced by UAVSs. As a result, a broad range of safety issues was
identified, in two main areas:
Safety issues relating to UAVs as ‘disruptive technology’
UAVs have some vital differences from the current general experience with manned aviation,
and these introduce some potential safety issues to be overcome:
1. UAVS come in wide varieties, in terms of shape size and performance, and the types of
roles they undertake. This makes them difficult to ‘pigeon-hole’, and means that they
may be difficult to manage or predict, among manned traffic. (Section 1.1.1).
2. The UAVS system boundary is much broader (and less well understood) than for manned
aviation, with inclusion of additional critical aspects such as datalinks, Ground Control
Systems, data flows, data sources etc. This leads to questions of airworthiness as a
complex system, reliability of datalinks, and availability of RF spectrum for critical links.
(Section 1.1.2).
3. Vehicle autonomy creates several issues, starting with its definition! Clear indication is
needed of ‘who is in control’, especially when emergency action is required. There is a
dichotomy between requiring a predictable response (especially for ATM decision
making), yet needing flexibility of response to achieve a safe outcome. New technologies
such as agent-based control could provide the necessary flexibility, but introduce
questions of expertise, trust and software clearance – they also require strong
specification of required behaviour, when this is not explicitly defined for manned
aviation. (Section 1.1.3)

78
4. The ‘headline’ catastrophic failure rate for UAVs is currently too high for acceptance into
a manned environment. This is due to: poor accident data gathering; the experimental /
military roles they are currently undertaking; lack of reliable purpose-built components;
and not applying appropriate design, fabrication and maintenance processes to build in
safety (as per their manned counterparts). While it is difficult to define ‘equivalent levels
of safety’ between UAVs and manned systems, it is suggested that FAR 1309 / ARP
4761 type safety processes could be applied to the design and certification of novel,
safety critical aspects, with suitable amendments. (Section 1.1.4)

Safety issues relating to the manned airspace environment coming to terms with
UAVs
5. While it is agreed that a ‘safety targets’ (Safety Case) approach would be easiest to apply
for UAVS, standards and certification must be applied to achieve international
acceptance. Hence, regulation, certification and standards are critical to integration of
UAVS into unsegregated airspace, but are currently struggling to achieve consensus
between different bodies. Thus, while there are proposals for a ‘total system’ approach to
safety, currently airworthiness, operations and ATM are managed by different regulators.
What little current regulation exists is very generic, demanding equivalence to manned
systems but without addressing UAV differences. (Section 1.2.1)
6. Because of current segregation of traffic, very few UAVs have interacted with ATM
systems, and so it is difficult to predict the real implications. Because the nature of ATM
change is ‘monolithic’, ATM suppliers demand no change, i.e. that UAVS operations must
be transparent, while there are numerous ways in which UAVs will react differently from
manned aircraft. There are issues of equipage, traffic levels, RF interoperability, voice
communications, even basic routes and procedures that have been built around manned
aircraft and their performance expectations. (Section 1.2.2)
7. Collision avoidance from terrain and, more difficult, from other aircraft is a big issue for
UAVS integration, and UAVs will require a non-cooperative Sense & Avoid capability to
match their manned counterparts. It is difficult to define equivalent levels of safety to
manned aircraft, as human visual performance is so fallible, hence regulators and
designers cannot agree on which should come first – the technology to provide Sense
and Avoid, or the criteria that it must meet. (Section 1.2.3)
8. UAVS navigation, datalinks and ground systems vulnerabilities to jamming or malicious
take-over must be addressed to ensure security of operation. (Section 1.2.4)
9. For a system ‘unmanned’ in the air, there are significant Human Factors issues to be
overcome. Some revolve around the ground cockpit environment, the cues to the UAV-p,
the organisation of pilots and commanders, and the interaction with variable autonomous
systems. Others involve the experience / competence levels of the pilots, maintainers
and operating organisations, plus the extended human network that provides critical data
to the UAVS. (Section 1.2.5)
10. As with all safety critical systems, public opinion over safety levels may not match the
actuality. However, UAVSs are expected to face a more critical media and public
response in the event of a safety occurrence, because of their unmanned nature.
(Section 1.2.6)

79
4.1.2 A Framework for Considering Safety Risks Related to
Integrating Unmanned Vehicles into Unsegregated Airspace
At the end of Part 1, the focus for the project development was set out in order to satisfy the
study aims, as follows:
A. A better understanding of what the root hazards associated with UAVS integration are.
B. Can a .1309 / ARP4761 safety assessment approach be used for UAVS, to identify
hazards for solution during design / manufacture / operation?
Each of these sub-goals is reviewed in the following paragraphs, to provide a structure to
assess whether the main aim has been achieved. The order of the sub-goals has been
changed, to reflect the design (Part 2) and test (Part 3) order of the project.
Can a .1309 / ARP4761 safety assessment approach be used for UAVS, to identify
hazards for solution during design / manufacture / operation?
Part 2 has reviewed ARP4761 (which is based on satisfaction of 23.1309 and 25.1309
requirements) to see where it might fall short, in its applicability to UAVS. The concluding
statement from Section 2.1 was “The intent of ARP4761 to support the safety assessment
(and hence clearance) of novel aircraft systems remains good. If the issues identified above
can be addressed, then the revised framework should equally support safety assessment
and clearance of UAVS.”
The focus for Part 2 of the project has thus been to address these issues with a modified
hazard identification methodology, to supplement ARP4761 and thus provide a safety
assessment framework suitable for UAVS application. The identified ‘issues’ from Section
2.1 formed the ‘requirements’ for ‘design and build’ in Part 2, Section 2.2.
In order to pull together and relate the conclusions for build of the hazard identification
methodology, Table 4.1.2(i) has been created (see following pages). This shows the
development of conclusions, from the assessment of requirements in Section 2.1, through
design and build in Section 2.2. To complete the picture, the conclusions from test and
evaluation of the proposed method have been placed alongside (Part 3, section 3.2).
11. In summary, it is concluded that the development of the hazard identification
methodology, using a modified functional failure analysis, has resulted in a practicable
approach that addresses the gaps in ARP4761 previously identified. As such, the HazID
methodology supplements ARP4761 to allow the combined safety assessment
framework to be used for UAVS, to identify hazards for solution during design,
manufacture and/or operation.

80

Requirement (Section 2.1)
Safety Objectives -
Reflect airworthiness safety
criteria descriptions related to
UAV potential occurrences;
Reflect UAV variety (in
lethality);
Reflect ‘Total safety’ threats
through ATM / operating
occurrences
FHA-levels –
Address the (internal)
complexity of the system;
Address the external interfaces
of the SoS.
Function Identification –
Source data requirements to
cover the complex UAVS
structure and interfaces;
Internal Functions list to reflect
UAVS structure;
Exchanged Functions list to
reflect the wider System of
Systems;
Table 4.1.2(i) – Satisfaction matrix for development of HazID methodology
Proposed design solution
UAVS Airworthiness failure condition severities
(Section 2.2.1 - Table 2.2.1(i))
Derive UAV kinetic equivalence (based on Annex
B); compare with aircraft classes in Table
2.2.1(iii); hence determine probability objectives.
(2.2.1)
Dual-criteria system: Airworthiness criteria (as
above) plus ATM-focussed separation / collision
safety criteria (2.2.1 – Table 2.2.1(ii)
Extend ‘Aircraft-level FHA’ to become ‘UAVS-
level FHA’ (2.2.2)
Rich Context Diagram to draw out interactions
between UAVS and the wider SoS. (2.2.2)
Additions: URD or specification; Simple design /
architecture representation; Rich Context
Diagram; simple Concept of Operations. (2.2.3)
Consider UAVS functions overall; Consider
functions determined by the UAVS internal
structure (behaviour, control, information, utility);
Consider the effects of Flight Phases. (2.2.3)
Consider each Rich Context Diagram interaction
for implied functions on the UAVS (behaviour,
control, information, utility). (2.2.3)
81
Evaluation
Application of airworthiness safety criteria was straightforward (3.2.5 –
‘classification of failure effects)
Derivation of airworthiness safety objectives was straightforward.
(3.2.1)
Consideration against duel criteria was straightforward. Application of
ATM separation safety criteria was easy in most occasions with a few
exceptions. Most failures analysed had duel airworthiness / ATM effect
(3.2.5)
UAVS-level FHA was effective in identifying system inter-relations for
subsequent analysis (3.2.3)
Rich Context Diagram proved very useful in identifying SoS
interactions. The application would have been improved in practice
with stakeholder review. (3.2.2)
No URD or formal documentation available to assess. However,
simple Case Study documentation proved quite effective. (3.2.3)
Simple design architecture diagram was useful to identify system
elements – helpful to take ‘views’ on each element to derive internal
functions. Flight phases helped to identify additional functions. (3.2.3)
Rich Context Diagram very good at drawing out interactions – each
was then assessed for exchanged functions. Could find no need to
keep Internal and Exchanged functions list separate, so they were
consolidated into a common Functions Tree. (3.2.3)
Requirement (Section 2.1)
Flight Phases to reflect UAVS
mission complexity & variety
Identification of Failure Conditions –
Expansion on UAVS
environmental conditions;
Expansion on UAVS
emergency configurations
- Failure condition determination: Not UAVS
Ensure credible combinations
of multiple functional failures
are considered.
Identifying and managing the effects of failure conditions –
Establish significance of the
UAVS mission, environmental
and ATM context in evaluating
consequences
Proposed design solution
Review mission types and parameters to identify
the various flight phases. (2.2.3)
Review UAVS domains: Weather; Overflown
terrain; Electrical; Mission; Air Traffic
environment. May use scenarios (see ‘Identifying
and managing …’ below). (2.2.4)
Revised ‘starter list’ suggested. (2.2.4)
specific, but FFA structure proposed as good
practice, considering: function not provided;
provided when not required; incorrect operation of
function. (2.2.4)
Assessment of initial design architecture for
common causes; Assessment where operation of
a function mitigates another, critical functional
failure.
Expanded consideration of mission,
environmental range and ATM environment built-
in to establishing functions (see above);
Use of scenarios for complex situations, including
environment, mission, airspace context. (2.2.5)
82
Evaluation
Additional functions were needed for key emergency conditions – this
required an initial definition of emergency procedures. (3.2.4)
Derivation and consideration of flight phases was a useful ‘mind jogger’
for additional functions. (3.2.3)
Domain review list provided a good structure for derivation. Non-
specification aspects required care: here, definition of mission
scenarios proved useful. (3.2.4)
Review of list highlighted need for additional, emergency functions (see
above). (3.2.4)
FFA structure worked well. Care was needed with: pseudo-continuous
functions; implied sub-functions; functions crossing system boundaries.
(3.2.4)
Inherently built-in by setting up specific functions, expected in the event
of a system failure; mitigating function in an emergency. These were
then analysed for additional failures.
Analysis of failures highlighted where specific safety requirements
would be needed to ensure independence of safety-related functions.
In particular, because of the pivotal datalink, this drives the
requirement for autonomy, to ensure a safe outcome if the datalink
becomes degraded. (3.2.5 – ‘multiple failures’)
Established context information was adequate for most failures
analysed (as expected).
Some complex effects were analysed against scenarios: text-based
scenarios were not effective; graphical mission scenarios worked well
to present mission, terrain and ATM information and allow ‘what-ifs’.
(3.2.5 – ‘use of scenarios…’)
A better understanding of what the root hazards associated with UAVS integration are.
The hazard identification method, designed in Part 2, was assessed in Part 3 against a
generic Tactical UAVS. From this application, a listing of potential hazards has been
developed (Annex F).
Part 3, section 3.3 evaluated the hazards identified, using an alternative hazard identification
technique and personnel. From this, the following conclusions have been reached:
12. The proposed HazID method, using a modified ARP4761 FFA approach) has identified
around 90% of the likely hazards associated with integrating a (generic) Tactical UAV
system into unsegregated airspace.
The shortfall is likely to be due to:
• the functional analysis being a ‘one-man’ effort, which would benefit from peer
review;
• the difficulty in drawing out high-level Human Factors issues with FFA, and the
importance of Human Factors Engineering to address such issues;
• FFA being just part of the ARP4761 framework – additional sub-system
analyses such as FTA, FMEA, Common Cause Analysis etc would draw out further
hazards.
13. The proposed method was strong in identifying hazards related to the external System of
Systems, especially in areas such as the operating environment, in airmanship concerns,
and interfacing with airfield and ATM environments. In these respects, it is proposed that
the hazard listing has contributed to the understanding of UAVS integration hazards.
14. It should be borne in mind that the hazard listing is specific to the generic Tactical UAVS
used for the case study. However, as has been stated (in the introduction and in Section
3.3), the results should have good read across for specific Tactical UAVS, and broad
applicability for other types of UAVS, but should be assessed carefully for applicability to
particular systems.

4.2 Recommendations for Further Work

4.2.1 UAVS Safety, generally
This project has addressed only a few of the safety aspects identified that currently stop
UAVS from being integrated into unsegregated airspace. The list at Section 1.3 provides a
rich seam of safety issues that require further work:
• Impact of the Variety, Roles and Performance of UAVs
• The complex system boundary for UAVs
• UAV autonomy - technology, predictability, complexity
• Accident rates and reliability - UAV airworthiness
• Regulation, Certification and the Drive for Standards
• ATM interaction
• Collision avoidance
• Security and safety
• Human factors, Suitably Qualified & Experienced Personnel (SQEP) and
organisations

83
• Public perception of UAV safety

4.2.2 UAVS Hazard Identification Methodology and Application of

ARP4761 Framework
This project has shown that it should be practicable to apply the hazard identification
methodology, as part of an ARP4761 framework approach to safety assessment for a UAVS.
However, several areas for further work exist, to provide confidence in the framework overall:
• The project focussed on the hazard identification aspects of ARP4761. It would be
useful to extend assessment to look more closely at the follow-on safety assessment
activities of ARP4761, including sub-system analyses, PSSA and SSA.
• The evaluation work looked at a generic tactical UAV, a broad area in the middle of
potential UAVS types. Because of the wide range of UAVS types, it would be beneficial to
evaluate application nearer the ends of the spectrum, perhaps for a HALE / UCAV system,
and a Micro / Urban system.
• The evaluation was also a one-man application to a generic system. Further
confidence would be built through documented application to an actual system in
development. This could seek to use team / stakeholder involvement to improve the context
and functional identification; and apply the revised ARP4761 framework through to
certification.
• An ATM environment-level FHA (including principles for integration of UAVS) could
be undertaken, with involvement of EUROCONTROL, the CAA and/or other regulators. This
could aid the development of UAVS policy and (perhaps through decomposition of such
policy using methods such as discussed in [Hall05]) support satisfaction of such policy as
input to the UAVS-level FHA by the system developers.
• A key finding was the suspected criticality of autonomy to the effects of failure. It
would be useful to apply the FFA to a known system, but looking at the effects of varying the
UAV autonomy level, for each failure.

84
BIBLIOGRAPHY
[AST04] “ASTM International Support to the U.S. Unmanned Air Vehicle Systems Industry
- Position Statement”, 2004, ASTM International
[AST05-1] “Role of standards in the latest OSD UAS Roadmap”, May 2005, ASTM
International
[AST05-2] “Roadmap for Unmanned Aircraft Standards”, May 2005, ASTM International
[Bol05] “CRS Report for Congress: Homeland Security: Unmanned Aerial Vehicles and
Border Surveillance”, RS21698, Bolkcom C., Feb 2005, Congressional Research
Service, Library of Congress
[Bon05] “Global Satellite Navigation Systems: Advantages and Vulnerability”, Bonnor N,
Feb 2005, Royal Institute of Navigation (RAeS Conference proceedings)
[Bow05] “Unmanned Aerial Vehicle Flights in UK Airspace”, 8AP/15/19/02, Bowker, Lt Cdr
GN, May 2005, Civil Aviation Authority - Directorate of Airspace Policy
[CAA02] “Aircraft Airworthiness Certification Standards for Civil UAVs”, Haddon DR &
Whittaker CJ, Aug 2002, Civil Aviation Authority - Directorate of Airspace Policy
[CAA04] “Unmanned Aerial Vehicle Operations in UK Airspace – Guidance”, CAP722 (2nd
Edition), Nov 2004, Civil Aviation Authority - Directorate of Airspace Policy
[CAS04] “Civil Aviation Safety Regulations - Part 101 Unmanned aircraft and rocket
operations”, CASR Part 101, Dec 2004, [Australian] Civil Aviation Safety Authority
[CSI04] “MSc in Safety Critical Engineering -Computers, Software & ISA”, CAS,
McDermid J & Pumfrey D, Apr 2004, The University of York, Department of
Computer Science
[DeG04] “Issues Concerning Integration of Unmanned Aerial Vehicles in Civil Airspace”,
MP 04W0000323, DeGarmo MT, Nov 2004, Mitre Corporation - Center for
Advanced Aviation System Development
[dst04] “Applying Safety Process Measures”, Caseley P, Jun 2004, DSTL (through Safety
Critical Systems Club Seminar 'Life Saving Second Opinions')
[EAS05] “Advance - Notice of Proposed Amendment - Policy for Unmanned Aerial Vehicle
Certification”, A-NPA No 16-2005, 2005, EASA
[EUR01] “EUROCONTROL Safety Regulatory Requirement 4 - Risk Assessment and
Mitigation in ATM”, ESARR 4, Apr 2001, EUROCONTROL
[FAA88] “Advisory Circular: Transport Category Airplanes, Federal Aviation Regulations -
System Design and Analysis”, AC 25.1309-1A, Jun 88, Federal Aviation Authority
[FAA99] “Advisory Circular: Normal, Utility, Aerobatic and Commuter Category Aeroplanes
- Equipment, Systems, and Installations In Part 23 Airplanes”, AC 23.1309-1C,
Mar 1999, Federal Aviation Authority
[Hall05] “Defining and Decomposing Safety Policy for Systems of Systems”, SAFECOMP
2005/ LNCS 3688/ pp. 37-51, Hall-May M & Kelly T, 2005, University of York Dept
of Computer Science
[HFE05] “MSc in Safety Critical Engineering - Human Factors Engineering”, HFE, Wright
P, Feb 2005, the University of York Department of Computer Science

85
[HRA03] “MSc in Safety Critical Engineering - Hazard & Risk Assessment”, HRA, Kelly T et
al, Nov 2003, The University of York, Department of Computer Science
[Hua04-1] “Autonomy Levels for Unmanned Systems (ALFUS) Framework - Volume I:
Terminology (Version 1.1)”, NIST Special Publication 1011, Huang HM, Sep
2004, National Institute of Standards and Technology
[Hua04-2] “Autonomy Measures For Robots: Proceedings of IMECE”, IMECE2004-61812,
Huang et al, November 2004, International Mechanical Engineering Congress
[Jos05] “Model-Based Safety Analysis of Simulink Models Using SCADE Design Verifier”,
Joshi A & Heimdahl M, 2005, University of Minnesota Department of Computer
Science & Engineering
[LaF05-1] “Mapping A Future”, LaFranchi P, March 2005, Flight Magazine (Reed Business
Information)
[LaF05-2] “Crash Course”, LaFranchi P, March 2005, Flight Magazine (Reed Business
Information)
[LeT02] “VFR General Aviation Aircraft and UAV Flights Deconfliction”, AIAA-2002-3422,
Le Tallec C, 2002, ONERA Long-term Design and Systems Integration
Department
[Man06] Meeting with Patrick Mana to discuss EUROCONTROL safety criteria, Apr 2006
[MaP05] “EADS Current UAV Programmes”, MacPherson W, Feb 2005, EADS / RAeS
Conference proceedings
[Mar03] “Suggested Flight Approval Process for Unmanned Air Vehicles (UAVS)”,
Marsters GF & Sinclair M, 2003, AeroVations Associates
[McD03] “Extending PSSA for Complex Systems”, McDermid J & Nicholson M, 2003,
University of York
[Met05] “UAV Access to UK Airspace - Spectrum Availability”, Mettrop J, Feb 2005, CAA /
RAeS Conference Proceedings
[Nel04] “Prospective UAV operations in the future NAS”, Case#04-0936, DeGarmo M
and Nelson G, 2004, Mitre Corporation - Center for Advanced Aviation System
Development
[Okr05] “25 Nations for an Aeronautics Breakthrough”, Okrent M, Feb 2005, UAVNET /
RAeS Conference proceedings
[PlJ05] “Approach to Autonomy”, Platts J, Feb 2005, QinetiQ / RAeS Conference
proceedings
[PlP05] “UAVs and ATM - A Holistic Approach”, Platt P, Feb 2005, QinetiQ / RAeS
Conference proceedings
[RQE05] “MSc in Safety Critical Engineering - RQE: Requirements Engineering”, RQE,
Luettgen G & Stepney S, Oct 2005, the University of York Department of
Computer Science
[RTC05] “Special Committee 203 Minimum Performance Standards for Unmanned Aircraft
Systems and Unmanned Aircraft - Terms of Reference, revision 1”, RTCA Paper
No. 006-06/PMC-438, Dec 2005, RTCA
[SAE96] “Guidelines and Methods for Conducting the Safety Assessment Process on Civil
Airborne Systems and Equipment”, ARP 4761, 1996, SAE
[Sch04] “Defense Science Board Study on UAVs and UCAVs”, Schneider W (Chairman),
Feb 2004, DSB for Secretary of Defense

86
[Sin03] “Integrating UAVs With Conventional Air Operations: Some Regulatory Issues”,
Marsters GF & Sinclair M, Mar 2003, AeroVations Associates
[Ste05] “UAV Access to UK Airspace”, Stenson J, Feb 2005, CAA / RAeS Conference
proceedings
[UTF04] “UAV Task Force Final Report”, JAA / EUROCONTROL, May 2004, EASA
[Wal03] “Application Of Manoeuvre-Based Control In Variable Autonomy Unmanned
Combat Aerial Vehicles”, AFIT/GAE/ENY/03-09, Walan Capt AM, March 2003,
[US] Air Force Institute of Technology
[Wei03] “Safety Considerations for Operation of Small Unmanned Aerial Vehicles in Civil
Airspace”, Weibel R & Hansman RJ, Oct 2003, MIT International Centre for Air
Transportation
[Wei04] “Safety Considerations for Operation of Different Classes of UAVs in the NAS”,
AIAA-2004-6421, Weibel RE and Hansman RJ, Sep 2004, American Institute of
Aeronautics and Astronautics
[Wes05] “Meggitt Aerial Target Services - History, Utility and the Future”, Westlake-Toms
S, Feb 05, Meggitt / RAeS Conference Proceedings
[Whi05] “Aircraft Airworthiness Standards for Civil Unmanned Aerial Vehicle Systems”,
Whittaker C, Feb 2005, CAA / RAeS Conference proceedings
[Wik03] “Flying with Unmanned Aircraft (UAVs) In Airspace Involving Civil Aviation Activity
- Air Safety and the Approvals Procedure”, Wiklund E, March 2003, Swedish
Aviation Safety Authority
[Wil04] “A Summary of Unmanned Aircraft Accident/Incident Data: Human Factors
Implications”, DOT/FAA/AM-04/24, Williams K, 2004, Federal Aviation Authority
[Wil05] “Keynote Address to the RAeS 2nd FEBRUARY 2005”, Willbond T, Feb 2005,
RAES / UAVSA

87
ABBREVIATIONS & ACRONYMS
Autonomy (A) The condition or quality of being self-governing. (B) A [UAV's] own ability of sensing,
perceiving, analyzing, communicating, planning, decision-making, and acting, to achieve
its goals as assigned by its human operator(s) through designed HRI. Autonomy is
characterized into levels by factors including mission complexity, environmental difficulty,
and level of HRI to accomplish the missions. [Hua04-1]
A-NPA Advance – Notice of Proposed Amendment EASA advance issue of a document,
advising of proposed changes to regulation and inviting comment from stakeholders
AOPA Aircraft Owners & Pilots Association
ASTM American Society for Testing and Materials US society for development of
consensus based standards.
ATC Air Traffic Control Relates to the interaction with (or inputs to) the aircraft, as
defined by the Air Traffic Controller - Output of the ATM
ATS Air Traffic Service
ATM Air Traffic Management The wider ground, personnel and procedural system that
provides Air Traffic Control as its output

BLOS Beyond Line Of Sight Long range guidance and command datalinks, where signals
must be bounced, bent or relayed to reach beyond terrain or earth's curvature masking.
See also OTH.

Chicago Convention The Convention on International Civil Aviation set out that "...the undersigned
governments having agreed on certain principles and arrangements in order that
international civil aviation may be developed in a safe and orderly manner and that
international air transport services may be established on the basis of equality of
opportunity and operated soundly and economically."
CAA Civil Aviation Authority Where not otherwise qualified, refers to the UK authority
CCA Common Cause Analysis Generic term encompassing Zonal Analysis,
Particular Risks Analysis and Common Mode Analysis. In these methods, analysis is
made of common modes of failure, which could affect a number of elements otherwise
considered to be independent. [SAE96]
C4 Command, Control, Communications, Computers Description of military
command elements pertinent to a system. May refer to C2, C3 etc as applicable to the
system under consideration.
Comms Communications Usually referring to technology or infrastructure
ConOps Concept of Operations Documentation describing how a system is intended to be
used in-service.

DoD Department of Defense (United States)

DSA Detect, Sense and Avoid US terminology for S&A
dstl Defence Science & Technology Laboratory UK MoD centre of scientific
excellence, providing scientific advice to the Armed Forces.

EASA European Aviation Safety Agency The European Aviation Safety Agency is the
organ of the European Union to set strategy for aviation safety. While national
authorities continue to carry out the majority of operational tasks… the Agency ensures
common safety and environmental standards at the European level."
ELINT Electronic Intelligence
ECM Electronic Counter-Measures
EMC Electro-Magnetic Compatibility
EMI Electro-Magnetic Interference
EU European Union
EUROCAE European Organisation for Civil Aviation Electronics European regulatory body,
advising EUROCONTROL and EASA

FAA Federal Aviation Authority US government organisation for the advancement,

safety and regulation of civil aviation
FAR Federal Aviation Regulations Aviation regulations as issued by the FAA

88
FHA Functional Hazard Assessment A systematic, comprehensive examination of
functions to identify and classify Failure Conditions of those functions according to their
severity - see also PSSA and SSA [SAE96]. The intent is to be predictive of system
failure conditions, to allow safety targets to be set for system component reliabilities, in
order to achieve an acceptable overall platform safety level once the design is realised.
FFA Functional Failure Analysis A technique which is part of FHA. Applies a
systematic review of system functions to determine the ways in which failure may occur;
then analyses these failures for potential accident consequences. Can be used to
determine the criticality of each function (and failure mode) and set appropriate Safety
Integrity or Design Assurance Levels, or more specific reliability requirements.
FIR Flight Information Region As in the UK FIR, describes the majority of airspace
covered by advisory rather than mandatory Air Traffic Control.
FMEA Failure Modes and Effects Analysis Safety analysis to determine hazard effects
of lower level system and component failures – part of SSA and PSSA
FTA Fault Tree Analysis Subsequent safety analysis to determine contributory causes
for potential hazards – part of SSA and PSSA
FTS Flight Termination System System that (usually small) UAVs may be fitted with,
to ensure that the vehicle can be commanded to ‘stop flying’ safely, in the event of some
other critical system failure. Such systems include parachute retrieval, and control hard-
over.

Galileo European / US / ICAO supported civilian controlled GNSS

GCS Ground Control System Ground-based system elements that allow the UAV-p to
control the UAV
GLONASS Global'naya Navigatsiomaya Sputnikova Sistema Russian GNSS
GNSS Global Navigation Satellite System Generic name for GPS
GPS Global Positioning System Navigation system set up by the DoD, using 24
orbiting satellites to transmit timing information and allow receiving systems to calculate
their position by triangulation and measured signal timing differences (pseudo-ranges)

HALE High Altitude, Long Endurance UAV type characterised by its intended operating
altitude and endurance. See also MALE
HazID Hazard Identification Collection of safety assessment techniques that enable the
hazardous characteristics of a system under study to be identified early on, in a reliable
and systematic manner.
HF Human Factors
HIRF High Intensity Radio Frequency HIRF transmitters have the potential to cause EMI
with the UAV or its datalink with the GCS. Usually refers to actual sources of HIRF, such
as high-power transmitters for radio, radar, telecomms etc
HIRTA High Intensity Radio Transmission Area HIRF transmitter of known location, identified
on maps to alert pilots (and hence to avoid them)
HMI Human / Machine Interface See HRI
HRI Human-Robot Interaction / Interface Also known as Human Interaction, Operator
Interaction (or more generally as Human / Machine Interface). The activity by which
human operators engage with [UAVs] to achieve the mission goals. [Hua04-1]. As an
interface, term is an extension of earlier considerations of 'Man-Machine Interface' and
'Human-Computer Interface'.

ISTAR Intelligence, Surveillance, Targeting and Reconnaissance

ICAO International Civil Aviation Organisation The International Civil Aviation Organization,
a UN Specialized Agency, is the global forum for civil aviation. See web site at
www.icao.int
IFR Instrument Flight Regulations Set of specific regulations that a pilot / aircraft must
comply with (including required equipment) in order to fly when defined visibility criteria
for VFR are not met

JAA Joint Aviation AuthorityAdvisory group consisting of the various European civil
aviation authorities. Now superceded by EASA
JAR Joint Airworthiness Requirement Airworthiness requirement issued by JAA.
Now superceded by EASA CS regulations

89
MAFF Ministry of Agriculture, Fisheries and Food UK government ministry
MALE Medium Altitude, Long Endurance UAV type characterised by its intended
operating altitude and endurance. See also HALE.
MASPS Minimum Aviation System performance Standards UAV standards being
developed by RTCA
MoD Ministry of Defence (United Kingdom)
Mode S / Mode S ELS Mode Selective / Mode Selective Elementary Surveillance Mode S is a
modification to SSR that permits selective interrogation of aircraft by means of a unique
address, thus avoiding the risk of mis-identification due to overlapping signals. Mode S
ELS is the elementary implementation for aircraft under 5,700 Kg and 250kts capability.
It responds with a unique Aircraft Identification code, and limited other information, most
notably aircraft altitude.
MP Mission Planning The process to generate tactical goals, a route (general or
specific), commanding structure, coordination, and timing for one or teams of UAVs. The
mission plans can be generated either in advance [and pre-loaded to the UAV before
flight] or in real-time by the onboard, distributed software systems. [Hua04-1]

NAS National Air Space Term covering airspace under US regulatory control
NATO North Atlantic Treaty Organisation Military organisation originally set up by
western countries forces, to counter the threat from the Soviet bloc.
NEC Network Enabled Capability UK MoD approach to ensure that all Systems can be
linked into a military command and control network, for sharing of information.
nm Nautical Miles
NTSB National Transportation Safety Board US Federal agency that investigates civil
transportation accidents (including aviation), conducts safety studies, and issues safety
recommendations to prevent future accidents.

OTH Over The Horizon Long range guidance and control datalinks - see BLOS also

PSSA Preliminary System Safety Assessment A systematic evaluation of a proposed

system architecture and implementation based on the Functional Hazard Assessment
and failure condition classification to determine safety requirements for all items - see
also FHA and SSA [SAE96]

RC Remote Control See RPV

RF Radio Frequency
RoW Right of Way Agreed principles for aircraft rights of way (who has
precedence), in accordance with ICAO and national Rules of the Air.
RNAV Area Navigation
RPA Remotely Piloted AircraftSee RPV
RPV Remotely Piloted Vehicle Usually indicates a UAV with virtually no autonomy, in that its
flight controls are directed manually (and continually) by a ground-based pilot.
RTCA Radio Technical Commission for Aeronautics US society for production of
consensus based standards

Sensor Equipment that detects, measures, and/or records physical phenomena, and indicates
objects and activities by means of energy or particles emitted, reflected, or modified by
the objects and activities. [Hua04-1]
S&A Sense and Avoid Function / technology that allows a UAV to match / improve
upon a manned aircraft pilot's ability to See conflicting traffic and take avoiding action.
Intended as a last defence, when other formal barriers such as ATC segregation (by
airspace, flight level, instruction etc) and co-operative technologies such as TCAS have
proved ineffective for a particular situation.
SCADE Safety Critical Application Development Environment
SOP Standard Operating Procedures Defined procedures to be manually followed, in the
event of expected normal or emergency arisings.
SoS System of Systems Where a tightly-coupled system under consideration can be
shown to be part of a wider, more loosely-coupled set of systems, each affecting each
other with potential safety implications.

90
SQEP Suitably Qualified and Experienced Personnel Term used to reflect the need for
personnel to be competent to perform safety-related duties
SSA System Safety Assessment A systematic, comprehensive evaluation of the
implemented system to show that the relevant requirements are met - see also FHA and
PSSA [SAE96]
SSR Secondary Surveillance Radar ATM system where aircraft fitted with transponders
are interrogated by the ground radar, and are indicated on the controller's radar screen
at the calculated bearing and range. An aircraft without an operating transponder may
still be observed by primary radar, but without an identifying tag. See also ‘Mode S’.
SWIFT Structured 'What If' Technique FHA method assessing system physical elements,
flows and procedures, using structured categories and key words to help draw out
potential hazards.

TAWS Terrain Awareness & Warning System [See also GPWS]

TCAS Traffic awareness & Collision Avoidance System Co-operative system, based
on transponder responses from equipped aircraft - each aircraft in a potential collision
path is given a mutually compatible avoidance manoeuvre to fly, to avert the risk.
TUAV Tactical UAV UAV type characterised by the scope of its operations for
gathering military intelligence

UAV Commander A suitably qualified person responsible for the safe operation of a UAV System
during a particular flight and who has the authority to direct a flight under her/his
command [CAA04].
UAV Operator The legal entity operating a UAV System.[CAA04]
UAS Unmanned Aerial System See UAVS
UAV Unmanned Aerial Vehicle Usually refers to the flying vehicle itself (see UAVS
below). CAA definition is 'An aircraft which is designed to operate with no human pilot on
board.' [CAA04]
UAV-p UAV Pilot Person directly in control of the UAV, under command of the UAV
Commander.
UAVS Unmanned Aerial Vehicle System Includes all aspects of the system (including
ground elements such as the GCS and sometimes even the 'soft' elements such as the
operating organisation and procedures). Sometimes referred to as UAS - Unmanned
Aerial System.
UCAV Unmanned Combat Air Vehicle UAV designed and intended to deliver weapons
against other air vehicles or ground targets. The definition is usually intended to cover a
system that has some level of autonomy (not purely under manual guidance), and that
can return (i.e. not just a guided weapon)
UK United Kingdom ...of Great Britain and Northern Ireland
UML Unified Modelling Language A standardised language for specifying, visualizing,
constructing, and documenting the artefacts of complex systems (usually but not
necessarily software), using graphical notation.
URD User Requirement Document High level requirement document, setting out the
user-focused requirements for a system (i.e. what the end-user must be able to achieve
with a system, rather than how it is to be achieved).
US United States ...of America
UTF UAV Task Force Joint task force between JAA and EUROCONTROL, to explore
UAV integration and implications for ATM.

VFR Visual Flight RegulationsAirmanship regulations that must be followed by pilots /

aircraft, when visibility and weather conditions conform to required criteria.
VHF Very High Frequency Radio Frequency range used for ATC communications
VOR VHF Omni-directional Range Ground beacon-based navigation system
Vmo Maximum Operating Speed Defined velocity criteria for an aircraft design. The
speed that the design cannot exceed, without damage to the airframe or loss of control
Vs Stalling Speed Defined velocity criteria for an aircraft design. The speed that
the design cannot fly below, without stalling (losing lift and possibly control).

www World Wide Web

91
 ANNEX A
REVIEW OF ARP 4761, TO SUPPORT ARP 4758, CS
25.1309 ETC FOR UAV APPLICATION

A-1
Reference: [SAE96] - ARP 4761 Issue 1996-12

INTRODUCTION TO REVIEW
SAE International - "the Engineering Society for advancing mobility - Land, Sea, Air, Space"
publish various ARPs (Aerospace Recommended Practice) to aid industry in achieving
required standards. ARP4761 [SAE96] provides "Guidelines And Methods For Conducting
The Safety Assessment Process On Civil Airborne Systems And Equipment": it is a
companion to ARP 4754 which is aimed at the certification methods for complex airborne
systems, but both are intended to provide a systematic means by which satisfaction of FAR
25.1309 [FAA88] and its JAR (now EASA CS) equivalent can be shown, for civil aircraft.
The comments below discuss the applicability of the guidelines and methods in terms of
assessment for a UAV System. In particular, the review looks at the hazard identification
aspects (predominantly the Functional Hazard Assessment (FHA) proposed by ARP 4761).

SECTION 1. SCOPE
This sets the scope for 'aircraft level safety assessment' - this would need to be developed
for the broader UAVS scope (or System of Systems (SoS) scope - see section 1.1.2).

SECTION 2. REFERENCES
The references to standards would need to be revised in light of the standards being
adopted, adapted and created for UAVS applicability (see section 1.2.1).

SECTION 3. SAFETY ASSESSMENT PROCESS

Section 3.1 Safety Assessment Overview
This section draws in the safety objectives from FAR / JAR 25.1309 (becoming EASA
CS.25.1309), as shown below:

Table A(i) - Safety Objective, from ARP 4761 (drawn in turn from CS.25.1309)

A-2
On initial review, it can be seen that the criteria are driven to the most demanding, as
required for EASA and FAA requirements at the '25.1309' heavy-end of the vehicle spectrum.
As noted in [Wik03], in section 1.1.4 of this report, there is a spectrum of requirements
pertinent to the scale of the vehicle - 10-9 per fg hr for a heavy transport increases to 10-6
per fg hr for a single engine aircraft under 6000lbs.
It can also be seen that these criteria are lacking in their UAVS applicability, such as having
no occupants, the remote / autonomous nature of their crew, and (implicit) differences in
system arrangements. These aspects were noted by the JAA / Eurocontrol UAV Task Force
- in their report [UTF04, chapter 7.5], they suggested modifications to the criteria, as follows:
o The worst UAV Hazard Event designated as 'Catastrophic' or Severity I Event may be
defined as the UAV's inability to continue controlled flight and reach any predefined
landing site, i.e. an UAV uncontrolled flight followed by an uncontrolled crash,
potentially leading to fatalities or severe damage on the ground.
o The overall (qualitative) Safety Objective for UAV System may subsequently be "to
reduce the risk of UAV Catastrophic Event to a level comparable to the risk existing
with manned aircraft of equivalent category".
o Quantitative safety objective for the individual UAV 'Catastrophic' or 'Severity I'
conditions and/or for the sum of all failure conditions leading to a UAV Severity I
Event should be set, per UAV category, considering:
o The probability level for catastrophic failure conditions that is considered as
acceptable by the airworthiness requirements applicable to manned aircraft of
"equivalent class or category".
o The historical evidence and statistics related to manned aircraft 'equivalent
class or category', including, where relevant, consideration of subsequent
ground fatalities.
o Categories lower than Severity I could be defined as follows.
o Severity II would correspond to failure conditions leading to the controlled loss
of the UAV over an unpopulated emergency site, using Emergency Recovery
procedures where required.
o Severity III would correspond to failure conditions leading to significant
reduction in safety margins (e.g., total loss of communication with autonomous
flight and landing on a predefined emergency site)
o Severity IV would correspond to failure conditions leading to slight reduction in
safety margins (e.g. loss of redundancy)
o Severity V would correspond to failure conditions leading to no Safety Effect.
o The quantitative probability ranges required for lower severities should be derived
from the quantitative required objective for the worst severity.

While these suggestions clarify the qualitative aspects of the criteria, care would be
needed where a quantitative assessment was to be applied. Some of the issues associated
with this are discussed in this report at section 1.1.4.
In the above, what do the Severity I-V categories refer to? Discussion with Patrick Mana of
EUROCONTROL [Man06] clarified their concern that the ARP 4761 criteria reflected an
airworthiness-focused accident consequence (i.e. loss of the aircraft with its occupants and /
or harm to personnel on the ground). In order to focus safety management within ATM
system development, EUROCONTROL considered that further criteria were required to deal
with the effects on the ATM environment. For this reason, they have published their risk
management regulations (at system level) in EUROCONTROL Safety Regulatory
Requirement 4 (ESARR 4) [EUR01]. These criteria covered:

A-3
 o Effect of hazard on air crew, (E.g., workload, ability to perform his/her functions);
o Effect of hazard on the Air Traffic Controllers, (E.g., workload, ability to
perform his/her functions);
o Effect of hazard on the aircraft functional capabilities;
o Effect of hazard on the functional capabilities of the ground part of the ATM System;
o Effect of hazard on the ability to provide safe Air Traffic Management Services; (E.g.,
magnitude of loss or corruption of Air Traffic Management Services/functions).

The discussion with Patrick concluded that, to support EASA's requirement for total system
safety, and EUROCONTROL's particular requirements for air collision risk, a UAV-focussed
safety process would need to accommodate both cs.1309 airworthiness criteria and,
somehow, the ATM criteria. These are reproduced in Table A-2 below from [EUR01] for
comparison. Note that, unlike the FAA / EASA ‘airworthiness’ requirements of 25.1309 and
23.1309, these requirements are absolute and do not vary with the size or category of the
aircraft. Also, EUROCONTROL have only identified one end of the risk spectrum: Severity 1
accidents must not occur more than 1.55 x10-8 per fg hr.

Table A(ii) - Severity Criteria as defined in ESARR4 by EUROCONTROL

Section 3.2 Functional Hazard Assessment (FHA)

The usual route proposed by ARP4761 is to carry out an Aircraft Level FHA, a high level,
qualitative assessment of the basic functions of the 'aircraft' as defined at the beginning of
aircraft development. This is then followed with a System Level FHA, which is iterative in
nature and becomes more defined and fixed as the system evolves. It considers a failure or
combination of system failures that affect an aircraft function. The intent is to work towards
identification of the appropriate Development Assurance Level (DAL) for each aircraft
function and the system functions that affect it. These in turn help to identify the level of
development, qualification and certification activity required to provide adequate assurance
that each function has been safely implemented. The output from the aircraft and system
level FHAs is used to set the safety requirements for the detailed design process, so it is vital
that all pertinent safety hazards have been identified by this point. A number of questions
emerge at this point, in trying to apply this process to UAVS:
o Is an 'aircraft level' FHA appropriate as the start point for UAVS assessment?
ARP4761 propose this as the highest level for consideration, but for UAVS there is

A-4
 the 'super-system', the SoS whose support is critical to mission (and safety)
assurance.
o How is the integration of systems best handled, to ensure all hazards are identified?
In particular, integration of the people and procedural systems, as well as the
extended system technical elements?

Here, ARP4761provides comment over the integration of systems:

"The safety assessment process for integrated systems should take into account any
additional complexities and interdependencies which arise due to integration. In all
cases involving integrated systems, the safety assessment process is of fundamental
importance in establishing appropriate safety objectives for the system and
determining that the implementation satisfies these objectives."
As noted in section 1.1.2 of this report, this is particularly pertinent (and challenging) for
UAVS and the extended boundary of the System of Systems (SoS). The section goes on to
discuss the role of Functional Hazard Assessment (FHA) at the beginning of the
development process, to set appropriate safety objectives and requirements. One of the
problems I foresee is that, because of the loose and fluid nature of the UAVS system
boundary, the complex interaction with the SoS, and the variable nature of where functions
are controlled (through autonomy), there may be a whole mess of 'exchanged functions' that
will be difficult to identify and assess, until at least initial UAVS high-level architectures are
outlined. The ARP does suggest that the FHA is reviewed once the functions begin to be
allocated to systems, but this could prove to be a significant part of the assessment for a
UAVS. The follow-on work for Preliminary System Safety Assessment (PSSA) and System
Safety Assessment (SSA) could draw out such interactions, especially through work
elements such as Common Cause Analysis (CCA), but the ideal would be to identify these
hazards early on, before the system architecture begins to 'harden-up' in the development
process, and change becomes more difficult. Also, these latter analyses are aimed more at
identifying and mitigating causes for the potential hazards already identified, rather than
identification of new hazards.

Section 3.3 and on: Preliminary System Safety Assessment (PSSA), System
Safety Assessment (SSA)

This report will not look in any detail at the PSSA-onwards part of the process, as the ARP
assumes that all hazards have (in the main) been identified during FHA, and our focus is on
hazard identification. As ARP4761 describes this aspect:
"A PSSA is used to complete the failure conditions list [i.e. the causes of hazards]
and the corresponding safety requirements. It is also used to demonstrate how the
system will meet the qualitative and quantitative requirements for the various hazards
identified. The PSSA process identifies protective strategies, taking into account fail
safe concepts and architectural attributes which may be needed to meet the safety
objectives. It should identify and capture all derived system safety requirements (e.g.,
protective strategies such as partitioning, built-in-test, dissimilarity, monitoring, safety-
related tasks and intervals, etc.). The PSSA outputs should be used as inputs to the
SSA and other documents, including, but not limited to, system requirements,
hardware requirements and software requirements."
What is useful to consider here, is that other reviewers have found aspects of ARP4761 that
need bolstering, in order to apply PSSA to complex systems and SoS. McDermid and
Nicholson [McD03] proposed that some extensions to the guidelines and methods were
necessary to deal with (in particular) the people, processes and software that characterise
such complex systems and their interactions with other systems. [McD03] focuses on the
design-centred PSSA part of the cycle, where the comments will, of course, be especially

A-5
applicable for UAVS. However, the comments could apply equally to the up-front FHA
aspects, especially where the UAVS will have to fit into an existing SoS with pre-defined
equipment and people elements (such as ATM and, perhaps, common mission planning and
GCS systems). The paper suggests that additional hazard identification methods are
required to deal with software-rich and people-centred aspects - elements of this could be
brought forward into FHA for UAVS assessment, where pre-existing systems have to be
integrated with, or could be adapted to help deal with the system interactions known to exist
at the FHA stage.
For the SSA stage, the assessment requires a defined design to be validated against the
developed safety requirements - this is not the focus for our report, but there could be
interesting questions over use of traditional safety analyses such as Failure Modes and
Effects Analysis (FMEA) in people- and software-rich systems, and interactions across
complex SoS.

SECTION 4. SAFETY ASSESSMENT ANALYSIS

METHODS
The ARP describes a number of useful PSSA and SSA related safety assessment
techniques, and little needs to be said here. However, there are some aspects of interest
relating to Common Cause Analyses (CCA) that should be touched on here, perhaps as
pointers for future studies:
o Zonal Hazard Analyses - the question here is over the definition of zones. With the
extended UAVS and SoS, potentially zone definition needs to be extended likewise.
For example, the SoS includes critical navigation elements in space (if using GPS),
and datalinks transmitting through a common RF environment with other transmitters.
o Particular Risk Analysis - the suggested list could be extended to consider particular
risks specific to UAVS, such as datalink failure.

APPENDIX A - FUNCTIONAL HAZARD ASSESSMENT

A fair amount has already been said about FHA above, relating to UAVS. Here, we will only
discuss new aspects that become pertinent from the ARP text.
In A.1, the ARP again sets the intent to conduct the FHA at ‘Aircraft’ and ‘System’ levels –
this we have discussed above, with the complications for UAVS of the complex system
boundary, and the system of systems interactions.
The section goes on to suggest that "It is desirable to establish an aircraft level general
hazard list to be used on future projects so that known hazards are not overlooked." This
would be a useful step forward, provided that it is not used to limit the application to a new
UAVS, where additional and different hazards might exist.
A.3 introduces the ARP-proposed FHA process. The suggested process for conducting the
Aircraft level FHA is reproduced below in Figure A-1 (a separate figure is presented in the
ARP for the System-level FHA, but does not differ significantly, for our purposes).

Section A3.1 Function Identification

A3.1.1 provides guidance on source data for the FHA. For the Aircraft-level, a fairly simple
list is proposed:
• The list of the top-level aircraft functions (e.g., lift, thrust, etc.)
• The aircraft objectives and customer requirements (e.g., number of
passengers, range, etc.)

A-6
 • Initial design decisions (e.g., number of engines, conventional tail, etc.)
This is based on an assumption of simple interfaces between the ‘aircraft’ and the external
world, because the ARP provides a much more detailed list for the System-level FHA, where
interfaces between system elements, and initial design decisions are critical. For our
consideration of the UAVS being part of a complex System-of-Systems, the listing for the
system-level FHA (or similar) might be more appropriate? We will touch more on this later, as
we look at the FHA process and its needs.

Figure A-1 - ARP4761 Process for an Aircraft-level FHA

A-7
Following the process model outlined in Figure A-1 above, A.3.1.2 looks at creation of the
function list.
• A.3.1.2a refers to ‘internal’ functions, which are the main high-level functions
of the aircraft, and the functions assumed to exchange internally within the aircraft
system (presumably from initial design assumptions). For our UAVS with its complex
system boundary (even when just looking internally, with the UAV, the GCS and
immediate high-level system assumptions), the list of ‘typical’ internal functions would
need to grow considerably – and guidance needs to be given on defining what is the
high-level system (as discussed in this report at section 1.1.2). These internal
functions might vary with our initial design assumptions over the UAVS architecture,
and it will be difficult to keep our view to the overall system (e.g. not to dive down into
system design, or discussions of autonomy, but to cover all functions within the
system ‘bag’ together).
• A.3.1.2b refers to ‘exchanged’ functions, put simply as functions that interface
with other aircraft or ground systems. This is where our SoS would really take effect,
and needs careful guidance on how to ensure no functions are missed. Perhaps this
is where the scope of the ARP application extends beyond the airworthiness it was
originally intended for, into the total safety approach desired by EASA / Joint
European UAV Task Force.
The A.3.1.2 process box in Figure A-1 also refers to identification of flight phases, though
little guidance is given in the text. Where flight phases for an airliner might be fairly simple to
define (ground handling; take-off; climb-out; etc…) for a typical operation, the problem with
UAVS will be the variety of mission types (as discussed in this report at section 1.1.1). Also,
within aerial work mission types, the mission may be made up of several different phases, or
have optional phases, rather than the predominant cruise-phase in transport flying. These
flight phases are required to help draw out the ‘aircraft’ functions and also to understand the
consequences of functional failures (see A.3.2.2 below), so it is important that they are well
explored for the UAVS. A problem here might also be the lack of suitably experienced
personnel with expertise in such operations for UAVSs, to support the analysis.

Section A.3.2 - Identification and Description of “Failure Conditions”

A.3.2.1 discusses the creation of a list of Environmental and Emergency Configurations, to

add to the consideration of failure effects. Environmental aspects may require more detailed
definition, as UAVs may operate in significantly different environments from manned aircraft,
due to their performance or role. For example, a HALE type UAV will operate at extremely
high altitudes, where environment effects such as icing, Jetstream winds, or even obscure
phenomena such as gravity waves might have an effect. Small, low level UAVs used for
(say) pipeline surveying may be susceptible to terrain induced turbulence or wind shear. In
general, UAVs are more sensitive to climatic effects than their manned counterparts
([DeG04, para 2.1.4]). UAV roles and performance may also introduce other peculiar
environmental events, such as personnel change-over during long endurance missions.
For the emergency configurations, some may need to be specified from regulatory sources
(such as the particular risk for data-link loss); others may come from the initial assumptions
over the UAV performance, role, or overall architecture.
A.3.2.2 considers how failures could occur singly, or combine into multiple failures. This may
be tricky to achieve sensibly for the UAVS because of the wide SoS: the potential for multiple
failures exists from so many sources.

A-8
Section A.3.3 to A.3.8 – Identifying and Managing the Effects of Failure
Conditions

The remainder of A.3 looks at how the effects of failure conditions are determined then
flowed down into safety objectives for lower level design and safety analyses.
What is not stated here, but is discussed in A.3.1.2 and is implied from the process chart, is
that flight phases provide a key input in determining the severity of effects. In fact, because
UAVs have no occupants and hence less generic airworthiness concerns, the context of
where they are and what they are doing when failure occurs, is critical in determining the
consequential effect on other airspace users or overflown populations. ARP 4761 seems to
lack the necessary direction to establish this mission / environmental / ATM context in which
to place the UAVS failure.

Section A.4 – FHA Outputs

A.4 looks at the outputs from aircraft and system FHAs, into the remaining PSSA and SSA
processes. Without going in depth into the implications of UAVS analysis for these
processes, the requirements seem fairly valid, but would need further validation to support
actual use. What is encouraging is the message to document the process thus far, not just
to support the further analyses but also to improve the knowledge base for when the next
FHA analyses are required. UAVS lack the overall expertise and experience that has grown
over the years for manned aircraft, and concerted efforts are required to build the knowledge
base of available information, to save future engineers having to develop such experience
themselves in real-time!

ANNEXES B – L
Annexes B to K cover more in depth safety analyses aimed at implementing the safety
requirements identified herein, and are not covered in this review. Annex L provides a
worked example that is pertinent to the manned aircraft, and again is not covered here.

A-9
 ANNEX B
EXTRACT FROM [CAA02] - A METHOD FOR SETTING
DESIGN STANDARDS FOR NEW KINDS OF
AIRCRAFT, INCLUDING UNMANNED AIR VEHICLES

B-1
 Extracted from [CAA02]
This [document] describes a method for obtaining a first outline of the airworthiness
standards which should be applied to aircraft of novel design. The method compares the
hazard presented by the new aircraft with that of existing conventional aircraft to obtain an
indication of the appropriate level of requirements which should be applied. The most
significant feature of the proposal is that it relies on a comparison with existing conventional
aircraft design requirements which contribute to a currently accepted level of safety, and
avoids controversial assumptions about future contributions to that level of safety from
operational, environmental or design factors.

COMPARISON CRITERIA
The capability of a vehicle to harm any third parties is broadly proportional to its kinetic
energy on impact. For the purposes of the comparison method it is assumed that there are
only two kinds of impact; either the impact arises as a result of an attempted emergency
landing under control, or it results from complete loss of control. More precisely, the two
impact scenarios are defined as:
1. Unpremeditated Descent Scenario
- A failure (or a combination of failures) occurs which results in the inability to maintain a safe
altitude above the surface. (e.g. loss of power, WAT limits etc).
2. Loss of control scenario - A failure (or a combination of failures) which results in loss of control
and may lead to an impact at high velocity.
Unpremeditated Descent Scenario:
For many air vehicles the likelihood of the unpremeditated descent will be dominated by the
reliability of the propulsion systems. For the calculation of kinetic energy at impact the mass
is the maximum take-off mass and the velocity used is the (engine-off) approach velocity. i.e.
For aeroplanes V = 1.3 X Stalling Speed (Landing configuration, MTOW)
For Rotorcraft V = Scalar value of the auto-rotation velocity vector,
For Airships/Balloons V = The combination of the terminal velocity resulting from the static
heaviness, and the probable wind velocity.
Loss of Control Scenario:
For the calculation of kinetic energy at impact for the loss of control case the mass is the
maximum take-off mass and the velocity used is the probable terminal velocity. i.e.
For aeroplanes V = 1.4 X Vmo (the maximum operating speed)
For Rotorcraft V = Terminal velocity with rotors stationary.
For Airships/Balloons V = Terminal velocity with the envelope ruptured or deflated to the extent
that no lifting medium remains.
For each scenario the kinetic energy has been calculated for a selection of 28 different civil
aircraft; (21 aeroplanes, and 7 rotorcraft). The results are shown in Figures [B-1] and [B-2].
On each Figure the “applicability region” for each of the existing aeroplane and rotorcraft
codes is shown. These regions have been established using practical constraints based
upon the sample of the existing fleet, plus any weight and speed limitations specified in the
applicability criteria of the codes of airworthiness requirements.

METHOD OF COMPARISON
To obtain the indication of the level of requirements appropriate to a novel kind of aircraft the
following steps are carried out:

B-2
 1. Calculate the kinetic energy of the new aircraft for each scenario.
2. Using these values and Figures [B-1] and [B-2] separately, determine the appropriate code to be
applied with the intent of preventing the occurrence of each scenario. i.e:
Figure 1 will provide an indication of the standards to be applied to any feature of the design
whose failure would affect the ability to maintain safe altitude above the surface.
Figure 2 will provide an indication of the standards to be applied to any feature of the design
whose failure would affect the ability to maintain control, (particularly rate of descent). Clearly,
this must include primary structure.
If it is found that the aircraft fits within the region for more than one code then this would indicate
that it may be appropriate to apply a combination of standards. (e.g. JAR-25 with reversions to
JAR-23 in some areas, or JAR-23 with Special Conditions taken from JAR-25).
3. Construct a certification basis which addresses the same aspects of the design as the existing
codes and to the level indicated by the kinetic energy comparison. Clearly, Special Conditions
will need to be considered for any novel features of the design not addressed by the existing
codes. However, the extent of such special conditions should be comparable with the general
level of airworthiness identified.
Note: In addition, operational requirements may dictate the inclusion of particular design
features which may in-turn necessitate the inclusion of additional certification requirements.
For example, the Rules of the Air specify that an aircraft operating over a congested area
must be able to maintain a safe altitude following the failure of one power unit.

WORKED EXAMPLES

Application to Global Hawk

Global Hawk is a High Altitude Long Endurance (HALE) UAV produced by Northrop
Grumman in the USA with a primary role of reconnaissance/surveillance. Global Hawk is
powered by a single turbofan engine. Its estimated characteristics are: a gross weight of
25,600lbs (11,600kg), a maximum operating speed (VMO) of 345kts and a stall speed (VS) of
95kts. Using these parameters gives energy levels of 0.177 (unpremeditated descent
scenario) and 3.53 (Loss of control). These are illustrated in Figures [B-1 & B-2] and indicate
that JAR-25 standards are applicable throughout.

Application to Predator
The RQ-1A Predator UAV from General Atomics is a Medium Altitude Long Endurance
(MALE) UAV which has seen extensive operational experience within the military. Powered
by a single piston-engine, the estimated parameters for Predator are: MTOW of 1,900lbs
(855kg), Vmo of 120kts and Vs in the region of 56kts. For the “unpremeditated descent”
scenario, this equates to energy levels of 0.0046 (JAR-23 single-engine) and for the “loss of
control” scenario 0.024 (JAR-23 single-engine). The certification basis for the Predator would
therefore be JAR 23.

Application to Hunter
Hunter from IAI is a short range UAV which was/is operated by the armies of USA, Israel,
Belgium and France. The Hunter comes in both standard and endurance versions and is
powered by 2 Motto-Guzzi engines. The two versions of the aircraft have gross weights of
726 kg and 952 kg respectively. The values for each version and each scenario are shown in
Figures [B-1 and B-2]. Although there is a small overlap with JAR-VLA in one case, it can be
seen that the guideline standard is JAR-23 for both versions of the aircraft.

B-3
Application to StratSat
StratSat is an unmanned communications airship intended for long duration missions
stationed above population centres. For this aircraft the “unpremeditated descent” analysis
indicates that a standard equivalent to JAR-23 as applied to single-engine aeroplanes would
be appropriate. This is convenient as the existing UK requirements for airships, BCAR
Section Q, provide a standard which is equivalent to JAR-23. The “loss of control descent”
analysis indicates that standards equivalent to a combination of JAR-25 and JAR-23
Commuter Category should be applied to reduce the probability of such an event. Thus the
basis for civil certification of this aircraft should be BCAR Section Q supplemented as
necessary by requirements from JAR-25 and JAR-23 Commuter.

CONCLUSIONS
A method of comparing novel aircraft with existing manned aircraft is presented together with
examples of its application to specific UAV projects. It is appreciated that no simple method
can give a complete answer to the definition of the certification bases, and the conventional
processes using judgment and debate will still be required. However, the method presented
provides a useful tool for anticipating the general level of airworthiness requirements to be
set.

B-4
[Velocity = 1.3 x Vstall]
Figure B-1 – Unpremeditated Descent Scenario

B-5
[Velocity =1.4 x Vmax operating]
Figure B-2 – Loss of Control Scenario

B-6
 ANNEX C
'GUARD DOG' - GENERIC TUAV CASE STUDY

C-1
This annex provides the system overview and operational background for the Guard Dog
case study. Appendices C1 and C2 provide two potential operational routes for the system,
in order to exercise its integration with airfields, terrain and airspace.

SYSTEM DESCRIPTION

Overview:
The Guard Dog UAV system is intended to provide imagery and intelligence (as well as
target designation) for land and sea commanders, across the spectrum of conflict:
Intelligence, Surveillance, Target Acquisition and Reconnaissance (ISTAR)

Figure C-1 – Overview of Guard Dog Case Study

The system comprises: The Unmanned Air Vehicles (UAV); the Ground Control Station(s)
(GCS); the Tactical Units (TacU) positioned with field commanders; the Field Teams for take-
off and recovery other than from prepared airfields.
The system interfaces (on a mission basis) with the battlefield network provided through
Network Enabled Capability (NEC). Other interfaces are envisioned to deal with training
operations in a peacetime, civilian environment!
In operational use, the system will operate under military jurisdiction within the battle-space.
However, to facilitate peacetime training, the system will need to be able to operate in Class
F & G civilian airspace (uncontrolled airspace – a Group 3 UAV iaw CAP722 [CAA04]). It is
not intended to operate in Class A-E airspace (controlled airspace – Group 4 and 5 UAVs,
requiring an extensive equipment list to be compliant).

C-2
Unmanned Air Vehicle:

KEY PARAMETERS
Wingspan 10m
MTOW 500Kg
Speed Max: 100kts

Cruise: 70kts

Stall: 40kts
Rate of Climb 900 fpm
Altitude Max: 20,000 ft

Operating: 10-18,000 ft
Endurance 20 hrs
Take-off / Landing (TO/L): Conventional: Short prepared strip or airfield, using
wheeled undercarriage

Field: Robonic launcher (pneumatic ramp) / prepared strip

Engine 1 x 50HP Petrol, driving fixed 2 blade prop

EQUIPMENT
Actuation Redundancy of cabling and actuators
Power Supply Redundancy in case of single failure; and reserve (battery) power in
event of engine failure
Data-link LOS: Dual redundant TCDL, controllable from any GCS;

Relay for onward Tx / Rx to other UAV

[Option for satellite link, but key cost / weight driver]

Navigation Dual Global Positioning System (GPS) receivers
Controller High Integrity, Dual redundant; Pre-programmable for autonomous
mission; re-directable by operator from ground
Sensors Variable EO/SAR/ESM
Automatic TO/L Using GPS from satellite and Differential GPS (DGPS) error
correction signal from ground station
(ATO/L)
Target Laser
Designation
Flight Emergency Recovery Capability [iaw UTF04]
Termination?
Collision Air: Sense & Avoid system [TBD] (Non-cooperative)
Avoidance

C-3
 [TCAS not included on grounds of weight and no intent of using
controlled airspace]

Ground: DTED used for mission planning; RadAlt on board

ATC Systems Mode S Transponder (for position on RADAR);

Twin V/UHF radio for voice comms relay to GCS

Ground Control Station:

Dual redundant operator consoles, provide:
• Mission planning
GCS
• Payload control, data analysis and NEC distribution
• Pilot control (to redirect autonomous mission / take manual
command)
NEC
• GCS can hand-over control to any other GCS
• GCS can control up to 3 UAVs
Tactical Common Data-Link (TCDL):
• Payload data downlink; telemetry downlink; command & control uplink
• Line-of-Sight (LOS) - Range 200km; 10.7Mbps payload data, 200kbps command link
• Dual redundant
• Option for Satellite link for Beyond LOS (BLOS).
• Data link can be relayed to a UAV beyond LOS range, by another UAV.

TacU

• Positioned with field commanders, can obtain payload data direct from
UAV.
• Limited control of UAV payload sensors, to optimise data collection.
NEC

Field Recovery Team

For deployed operations, UAV can be launched from pneumatic launcher, and
recovered onto flat ground / prepared strip, hence avoiding need for formal
airfield.

Operational Scenario

• Tactical UAV to be launched from a ‘UAV friendly’ civil airfield such as that at Parc
Aberporth, but not with the intention of using the oversea range nearby.
• Instead, TUAV turns inland, and follows a specified route overland from Aberporth, to
exercise the system / operators in navigation over representative distances.
• The route leads out to a land range such as Spadeadam, where the system /
operators exercise the sensor & information gathering capabilities.

C-4
• The TUAV then returns via the same (or a different) route, to re-enter the controlled
airspace at Parc Aberporth.
• Potentially, a number of TUAVs could be operated in parallel / series, to simulate the
near-continuous operational tempo situation.

Alternative Operational Scenarios

• GCS has to control a second UAV, on station to relay TCDL to reach sensor UAV
• Initial GCS hands over control to a second GCS for furthest part of the mission
• GCS has to relay TCDL via satellite to reach sensor UAV
[Emergency conditions and configurations]
• Loss of GPS / drift in GPS accuracy
• Loss of TCDL
• Weather effects – cloud / precipitation / lighting
• Diversion (for propulsion / non-propulsion failures; weather conditions etc)
• Incursion of GA aircraft

C-5
 APPENDIX C1
GUARD DOG MISSION SCENARIO (COASTAL ROUTE)

Figure C1-1 Flight Plan – Westerly Route (to maximize over-water flight)

C-6
 APPENDIX C2
GUARD DOG MISSION SCENARIO (INLAND ROUTE)

Figure C2-1 - Flight Plan – Easterly Route (to maximise overland / ATC interaction

C-7
 ANNEX D
FHA FOR 'GUARD DOG' TUAV SYSTEM (EXTRACTS)

D-1
 ‘GUARD DOG’ UAVS FUNCTIONAL HAZARD ANALYSIS
FHA conducted to ARP 4761 with UAVS modifications as report section 2.

CONTENTS OF ANNEX D
System Description ............................................................................................................D-2
Safety Criteria.....................................................................................................................D-3
Airworthiness Safety Criteria and objectives................................................................D-3
ATM Separation / Collision based safety Objectives....................................................D-4
System Context [In Accordance with report section 2.2.2] ..................................................D-5
Derivation of Functions.......................................................................................................D-6
Flight Phases ..............................................................................................................D-6
Environment List..........................................................................................................D-6
Emergency Configurations List....................................................................................D-7
System interactions view [See Individual function maps for each system element] –
Derived from initial design assumptions over system elements and interactions .........D-9
Failure Analysis ................................................................................................................D-18
Effects Consideration .......................................................................................................D-30
Scenarios for Effects Consideration...........................................................................D-39

SYSTEM DESCRIPTION
[See Guard Dog Case Study document]

D-2
 SAFETY CRITERIA
[Drawn from method at report section 2.2.1]

Airworthiness Safety Criteria and objectives

Minor Major Severe Major / Hazardous Catastrophic

- Slight reduction in safety - Significant reduction in safety margins (e.g., total loss - Controlled loss of the UAV over an UAV's inability to continue
margins (e.g. loss of of communication with autonomous flight and landing unpopulated emergency site, using Emergency controlled flight and reach any
redundancy) on a predefined emergency site) Recovery procedures where required. predefined landing site

Table D(i) - Airworthiness Failure Condition Severities (from Table 2.2.1(i))

Safety Objectives: A 500Kg UAV, powered by a Single Reciprocating Engine, with stalling speed (Vs) of 40kts and maximum operating speed (Vmo)
of 100kts indicates as a Class I using both CAA kinetic energy criteria from Annex B of the report, and the established definition of Class I aircraft
from CS.23.1309.

Severity of Outcome Minor Major Hazardous Catastrophic

Category of Aircraft:
CS.23.1309 Class I: Single Reciprocating Engine (SRE) / under 6000lbs <10-3 per op hr <10-4 per op hr <10-5 per op hr <10-6 per op hr
Table D(ii) - Airworthiness Safety Objectives

D-3
 ATM Separation / Collision based safety Objectives

[Drawn from Table 2.2.1(ii)]

Severity 5 - No Severity 4 - Minor Incidents Severity 3 - Significant Incidents Severity 2 - Major Incidents Severity 1 - Accidents
Immediate Effect
on Safety
- No hazardous - Increasing workload of the air - Large reduction (e.g., a separation of less - Large reduction in separation (e.g., - One or more catastrophic
condition i.e. no traffic controller or [UAVS] crew, than half the separation minima) in separation a separation of less than half the accidents
immediate direct or or slightly degrading the with [UAVS] crew or ATC controlling the separation minima), without [UAVS]
indirect impact on functional capability of the situation and able to recover from the crew or ATC fully controlling the - One or more mid-air collisions
the operations enabling CNS System. situation. situation or able to recover from the
situation. - One or more collisions on the
- Minor reduction (e.g., a - Minor reduction (e.g., a separation of more ground between two aircraft
separation of more than half the than half the separation minima) in separation - One or more aircraft deviating from
separation minima) in without [UAVS] crew or ATC fully controlling their intended clearance, so that - One or more Controlled Flight
separation with [UAVS] crew or the situation, hence jeopardising the ability to abrupt manoeuvre is required to
Into Terrain
ATC controlling the situation recover from the situation (without the use of avoid collision with another aircraft
and fully able to recover from collision or terrain avoidance manoeuvres). or with terrain (or when an
the situation. avoidance action would be - Total loss of flight control.
appropriate).
- No independent source of
recovery mechanism, such as
surveillance or ATC and/or
[UAVS] crew procedures can
reasonably be expected to
prevent the accident(s).

Table D(iii) – ATM Separation / Collision Safety objectives

ATM separation / collision based safety objectives will not change with the class of vehicle. The acceptable probability of a Severity 1 accident
remains fixed by ESARR 4 [EUR04] at 1.55 x 10-8 per flight/hour.

D-4
SYSTEM CONTEXT [IN ACCORDANCE WIT H REPORT SECT ION 2.2.2]

Figure D-1 Rich Context Diagram for Guard Dog UAVS and the System of Systems around it

D-5
DERIVATION OF FUNCTIONS
Flight Phases

• Pre-flight
• Taxiing
• Take-off – from airfield
• Transit
• On Task – using sensor payload
• Approach
• Landing – at airfield
Alternative Phases:
• Take off – ramp launch from field
• On task - on station to relay TCDL to reach sensor UAV
• Hand over - Initial GCS hands over control to a second GCS
• Transit with satellite link - GCS has to relay TCDL via satellite to reach sensor UAV.
• Landing – rough field

Environment List

a. Weather aspects
(i) Temperature +55 / -45°C (with altitude)
(ii) Altitude Sea Level / 20,000ft
(iii) Rain, hail, snow, sand, dust
(iv) icing accretion after take off (de-icing before)
(v) lightning
(vi) Visibility - intended to be VMC (i.e. before take-off), occasional IMC onset during
mission
(vii) Wind-speeds usually temperate (to 30kts intended for launch & landing), but up
to 100kts onset in extremis.
b. Overflown terrain aspects
(i) Oversea – sea state flat to mountainous
(ii) Overland covering worldwide extremes – flat lands, swamps, desert, jungle,
mountainous, urban areas (operationally, not intentionally in training).
(iii) Sensor performance ensures no need to operate below 1000ft AGL.
(iv) Obstructions include masts, wind farms, gas platforms, pylons and cables…
c. Electrical environment
(i) Operationally, in high RF environment of battlefield
(ii) In training, in busy UHF/VHF communications environment (see Air Traffic below),
and with several identified HF/VHF/UHF/ milli-metric HIRTAS in locality
d. Mission environment
(i) Includes day or night usage
(ii) Potential for crew changeover due to extended ‘on station’ times (15-20 hrs total
flight time)
(iii) Potential for non-aircrew personnel to operate the system directly, under certified
pilot-in-command as supervisory

D-6
 e. Air traffic environment
(i) Primarily, flight within general airspace (Class F&G)
(ii) Over several military Areas of Intense Aerial Activity (AIAA) – occasionally
entering AIAA (with permission) to facilitate route around more stringent airspace
(such as TMA, CTA)
(iii) Under / next to Airways
(iv) Close to Terminal Manoeuvre Areas (TMA) at airway intersections near major
airports, and under the Control Terminal Area (CTA) for major airports
(v) Into civil and military airfields with UAV clearance
(vi) Into military Danger Areas to exercise sensors

Emergency Configurations List

Single failure of the UAV communication link, and/or control link

Operation of Flight Termination System (None fitted) - Instead, conduct of Emergency
Recovery Procedures due to loss of critical system(s) - With UAV-p control; Without UAV-p
control (i.e. autonomous)
Emergency landing due to loss of thrust
Collision avoidance with co-operative and non-cooperative aircraft - Including evasive
manoeuvre
Terrain avoidance
Interception by military aircraft
Failure of onboard Sense and Avoid equipment
Operation with degraded systems
Degradation of weather conditions
Security threats to upload data, commands and transmissions
PLUS: Loss of GPS / drift in GPS accuracy

[As part of defining the emergency configurations, and identifying related functions, it was
found necessary to define some outline Emergency Recovery Procedures, as shown below:

D-7
 YES

Regain D/L NO
Hold
DATA LINK Signal Loss Signal?

DATA LINK SystemFail (total) Broadcast Control

Datalink Fail

DIVERT to
DATA LINK System Fail (single) identified
diversion
NORMAL FLIGHT airfield
FLIGHT CRITICAL SYSTEMSIngle (Redundant) Failure
Determine best diversion and
ID between GCS and UAV (May COMMUNICATIONS Failure
be home or destination)

Maintain flight path over 'safe' AIR NAVIGATION Failure

terrain and airspace (inc. height, speed, position & route control) External Nav YES
Able to Maintain Safe YES
Altitude? Asistance?

FLIGHT CRITICAL SYSTEM Total Fail

Broadcast
COLLISION AVOIDANCE Failure NO NO
Mayday &
EMERGENCY
GROUND CONTROL Failure LANDING

Broadcast
Collision
Avoidance fail

STOP &
Broadcast

Figure D-2 - Outline Emergency Recovery Procedures

D-8
System interactions view [See Individual function maps for each system element] – Derived from initial design assumptions over system elements and
interactions

Telemeter Determine Redundant

UAV systems systems
parameters status control?

Degraded
systems
Payload data
emergency
download Determine Air /
Manage Flight actions?
Systems Ground Determine
Monitor
transition ground speed
mission
Sensor control
progress
Manage
Payload Control speed
on the ground Ground thrust
control

Relay D/L to
other UAV Control on Ground
Ground braking
Manage
Control Datalink
handover
between Control Determine
GCSs position on actual ground
the ground location &
Determine heading
Ramp T/O - Ground
Launch obstacles
control Ground
Monitor / steering
correct actual
Determine Air navigation
UAV Stability v planned
Altitude, & Control ground route
Orientation &
Speed
Monitor /
correct actual
Stabilise Manual v planned
perturbations Override - Auto T/O & route
Manoeuvre remote Land Position,
UAV piloting heading &
Control Flight Store / update Altitude
Path Mission Route awareness
Determine T/O,
climb out,
High Accuracy
approach, land
position, hdg, alt High acc'y
profiles Determine Determine
awareness monitor / correct
position accuracy
position, hdg, alt

UAV Centred view

D-9
 Figure D-3a – UAV Centred view of functions

Download Distribute
payload data payload data Prioritise
sensor / data
requests from
Users

Plan Route
Direct sensors
Manage
Payload

Mission
Change Planning Upload
Mission Plan Mission Plan

Control UAV? via next GCS?

GCS

manual
Override -
NEC
remote
Control
piloting
Datalink Path
Monitor Via Satellite?
Mission Manage
Progress DataLink

D/L Fail Emgy

Status of UAV Action Via UAV
Actual path v Relay?
mission route Monitor Data
link condition

GCS Centred view

Figure D-3b – GCS centred view of functions

D-10
 Data
download /
storage

Distribute
payload data
Sensor / Data
requests

NEC
Launch UAV

TACU Centred view Pre flight test

Pre Flight
preparations Locate UAV

Refuel /
recharge
consumables

Field Recovery / Launch Unit Centred view

Figure D-3c TACU and Field Recovery / Launch Unit centred views of functions

D-11
Flight Phases view
[Additional possible functions derived from mission phases –merged with functions from system
interactions view].
Mission Phase System Function (1st Level) (2nd Level?)
Pre-flight System Test
Load Mission Plan
Taxiing Controlled Taxiing Ground obstacle sensing?
Airfield pattern awareness
Correct steering to planned layout
Take-off Airfield Take-Off Climb-out profile
[Auto / Manual?]
Position & Direction Sensing Accuracy
Collision Avoidance
Terrain Avoidance
Field Take-Off Launch control
Climb-out
Transit
Position & Direction Sensing accuracy - normal
Collision Avoidance
Terrain Avoidance
Monitor weather for changes
On Task
(As Transit +)
Relay TCDL
[when acting as airborne relay for 2nd UAV]
Handover between GCSs
Approach Approach Control Determine wind speed & direction
(As Transit +) Determine landing strip direction
Determine circuit height & direction
Determine glide-slope pattern
Fly pattern (correct v planned pattern)
Landing Controlled Landing Detect air / ground transition
(As Transit +)
Table D(iv) – Flight phases view of functions

External context view

[Derived from external rich context diagram interactions]
UAVS Interacts with…
Agent Nature of Interaction Additional Derived Function?
Airfield Airfield ATC instruction > Understand / reply to airfield ATC - Voice
Airfield ATC Visual Signals > Observe / respect airfield visual signals
Airfield layout for taxiing > [3.2.3]
Airfield Runway profile / Take Off > [2.4.1]
Airfield Climb out profile / obstacle [2.4.1]
clearance
Approach and Hold procedures > [2.4.3]
Airfield Circuit direction / procedures > [2.4.3]
Airfield Runway / arrestor layout / Land and [2.4.5][3.2]
recover >
Airfield RF systems Interoperability > [Characteristic of system – Non Functional
Req’t]

ATM En-Route < Communication > Understand / reply to En Route ATC – Voice,
Digital
Track UAV > Provide tracking signal
< Comply with advice Comply with ATC – confirm, act
< Select appropriate radio frequency Manage ATC Frequency Selection

D-12
UAVS Interacts with…
Agent Nature of Interaction Additional Derived Function?

ISTAR Data Users < Direct Payload data feed [5]

< NEC data feed [5]
Data requests > [5]

Malicious Threats < Break Data Link D/L Anti jamming

< Steal Data Link Verify / encrypt D/L
< Hack GCS via NEC – affect mission Defend / verify mission plan, planning data,
planning; planning source data; output output data
payload data

Mission Target < Identify target ID Target

< Gather reconnaissance data Gather recce data
< Designate target for attack Designate target

HIRF Sources Direct EM Interference with UAVS > [Non Functional Requirement]

Mission planning – awareness of HIRF

locations
Noise affects LOS Command Link signal
strength >

Non-Cooperative Air < Detect traffic and sense relative track
Traffic (Class F-G
Airspace)
< Maintain separation (normal action
according to Rules of the Air)
< Emergency Collision avoidance (evasion)
See and avoid >
Collision avoidance – detect traffic – non co-
op; co-op.
Determine traffic relative track
Maintain traffic separation (ROA)
Collision Emergency evasion
Conspicuity to air traffic (visual, RF)

Ground Terrain / < Terrain Awareness Terrain avoidance – terrain awareness

Obstructions

< Route Planning [add to 8.1]

< Terrain Avoidance (Rules of the Air) Maintain Terrain separation (ROA)

Terrain emergency evasion

LOS calculations > Monitor Datalink – LOS to terrain (and 8.1
also)

Fixed Ground Danger < Awareness Danger areas / populated areas avoidance -
areas / Populated areas awareness
< Route planning [add to 8.1]
< Avoid overflight (Rules of the Air) Maintain danger area / populated area
separation (ROA)
Emergency redirection in event of incursion Danger area / populated area emergency
> incursion action

Controlled Airspace < Awareness Controlled airspace avoidance - awareness

(Class A-E)
< Route planning [add to 8.1]
< Avoid through flight (Rules of the Air) Maintain controlled airspace separation
(ROA)
Emergency redirection in event of incursion Controlled airspace emergency incursion
> action

Variable Danger areas < Awareness NOTAMS avoidance - awareness

(NOTAMS)
< Route planning [add to 8.1]
< Avoid through flight (Rules of the Air) Maintain NOTAMS separation (ROA)
Emergency redirection in event of incursion NOTAMS emergency incursion action
>
D-13
UAVS Interacts with…
Agent Nature of Interaction Additional Derived Function?

Satellite Data Link Availability > [4, 4.2]

(Option)
Signal strength >
Security of extended data link > [4.x – defend d/l]

GNSS Satellite position and time > [2.1.1]

Navigation accuracy / errors > [2.1.1]

DGPS Reference Station DGPS error correction > [2.4.2]

Weather < Awareness Manage for Weather – weather conditions

awareness – precip’n, icing, lightning, w/s &
dir, visibility
[add to 8.1 also]

Modify route > Assess proximity to route and effect on UAV

Determine separation route

Force diversion for landing > Determine diversionary airfield

Determine diversionary route

Affect LOS command signal strength >
< Respect VMC / IMC Flight Rules (Rules (as above)
of the Air)
Gusts > [1.2]
Precipitation / Icing > (affects [1], [1.6.2], [4.1.1])
Lightning > (Non functional requirement
Table D(v) – External interactions and derived UAVS functions

D-14
Resulting Functions Tree for Guard Dog UAVS
UAVS Function Tree
UAVS[PartFunction
1 of 3] Tree
(I) Internal of 3]
[Part 1view
(I) Internal
(F) Flight phase view
view
(F) Flight
(E) External context view
phase view
(E) External context view

1. Stability & 3. Control on the

2. Air Navigation
Control Ground
(I)
(I) (I)

2.1 Position, 3.1 Control 3.2 Control

1.1 Determine 1.2 Stabilise 2.2 Store /
Heading & Speed on the Position on the
attitude, perturbations (I) Update Mission
Altitude ground (I) ground (I)
orientation and Route
Awareness
speed (I) (I)
(I)

2.1.1 Determine 2.1.2Determine

3.1.1 Determine 3.2.1 Determine
1.4 Manual Position, Nav Data 3.1.2 Controlled 3.2.2 Ground
1.3 Manoeuvre speed on ground position
Override - Heading & accuracy Ground thrust (I) steering (I)
UAV ground (I) & heading (I)
Remote Piloting Altitude (I)(F)
(I)
(I) (I)

2.4 Auto Take 3.1.3 Controlled 3.2.3 Determine 3.2.4 Monitor /

1.5 Field T/O 1.6 Control 2.3 Monitor / off & Landing Ground Braking Airfield layout / correct actual v
Launch Control Flight Path Correct actual v (I)(F) (I) required ground required ground
(I)(F) (I) planned route route (F)(E) route (F)
(I)

2.4.2 Determine 3.2.5 Determine 3.2.6 Determine

2.4.1 Determine
High accuracy Air / Ground Ground
Airfield T/O
1.6.1 Control 1.6.2 Control transition (F) obstacles (F)(E)
Climb-out Position,
Airspeed Altitude & Rate
profile (F)(E) heading &
(I) (I)
Altitude
(F)
3.2.6.1 Detect
1.6.3 Control 2.4.3 Determine mobile
Heading Airfield 2.4.4 High obstacles (F)(E)
(I) Approach, Hold, Accuracy
Circuit, R/W monitor / correct
profile (F)(E) actual v planned 3.2.6.2 Fixed
profile (F)(E) obstacles
awareness
2.4.5 Determine (F)(E)
Windspeed &
direction v R/W
and landing
characteristics
(F)

2.6 Sensitive
2.5 Terrain Area Avoidance
Avoidance (E) (Danger &
Populated
areas) (E) - as
2.6.1-3

2.5.1 Awareness 2.5.2 Maintain

& flight path separation
proximity (E) (ROA) (E)

2.5.3 Emergency
evasion (E)

2.8 Variable
2.7 Controlled
Danger Areas
Airspace
(NOTAMS)
avoidance (E) -
Avoidance (E) -
as 2.6.1-3
as 2.6.1-3

Figure D-4a – Guard Dog Functions Tree (part 1 of 3)

D-15
 UAVS Function Tree
UAVS
[PartFunction
2 of 3] Tree
(I) Internal of 3]
[Part 2view
(I) Internal
(F) Flight phase view
view
(F) Flight
(E) External context view
phase view
(E) External context view

4. Manage 5. Manage 6. Monitor Mission 7. Manage Flght

Datalink Payload progress Systems
(I) (I) (I) (I)

4.1 Monitor 6.1 Telemeter 6.2 Telemeter 7.1 Determine 7.2 Redundant
4.2 Control 5.1 Sensor 5.2 Payload data
datalink S&C params to Air Nav params flight systems systems
Datalink path (I) control (I) download (I)
condition (I) GCS (I) to GCS (I) status (I) control? (I)

5.4 Prioritise 6.3 Telemeter 6.4 Telemeter 7.3 Degraded

5.3 Distribute
4.1.2 D/L 4.2.1 Handover Users' Payload Ground Control Flight Systems systems
4.1.1 Signal 4.2.2 Route via Payload data (I)
Equipment to next GCS requests (I) params to GCS status to GCS (I) emergency
strength (I) Satellite (I)(F)
status (I) (I)(F) (I) actions (I)

6.5 Monitor
4.2.3 Relay Weather for
between UAVs changes (F)(E) 7.3.1 Divert
(I)(F)

4.3 Datalink Fail 4.4 Defend D/L 6.5.1 Weather 6.5.2 Assess Wx
7.3.2 Emergency
Emergency (Jamming, awareness en- proximity to
Landing
Action(I) stealing) (E) route (E) planned route
(E)

[Precipitation,
4.3.1 Single D/L icing,
4.3.2 Complete
fail / windspeed /
D/L fail /
degradation direction,
degradation
action (I) visibility VMC /
action (I)
IMC]
6.5.4 Determine
4.5 Monitor 6.5.3 Determine
nearest, Wx
Terrain Wx separation
safe,
proximity to route around (E)
diversionary
LOS (E)
airfield & route
(E)

Figure D-4b – Guard Dog Functions Tree (part 2 of 3)

D-16
 UAVS Function Tree
UAVS[PartFunction
3 of 3] Tree
(I) Internal of 3]
[Part 3view
(I) Internal
(F) Flight phase view
view
(F) Flight
(E) External context view
phase view
(E) External context view

9. Manage
8. Pre Flight 10. Collision
Communication
Preparations (I) Avoidance (F)(E)
s (E)

9.1 Understand / 9.2 Detect &

10.1 Detect 10.2 Determine
8.1 Mission 8.2 T/O / Launch reply to Airfield respect airfield
Traffic (Co-op; traffic relative
Planning (I) Preparation (F) ATC voice visual signals
Non Co-op) (E) track (E)
comms (E) (E)

9.3 Understand / 9.4 Provide 10.3 Maintain

10.4 Collision
reply to En- Tracking traffic
8.1.2 HIRF 8.2.1 Refuel / emergency
8.1.1 Plan Route ATC 'visibility' separation
Location recharge evasion (E)
mission route (I) advice - voice / (signal, visual) (ROA) (E)
awareness (E) consumables (I)
digital (E) (E)

9.5 Manage ATC 9.6 Comply with 10.5 Conspicuity

8.1.4 Danger
8.2.2 Pre flight Frequency ATC procedures to Air Traffic
8.1.3 Terrain Area / populated
systems test selections (E) (E) (visual, RF) (E)
Awareness (E) area awareness
(I)(F)
(E)

8.1.5 Controlled 8.2.3 Upload 9.6.1 Determine 9.6.2 Confirm

8.1.6 Weather
Airspace Mission Plan required manoeuvre with
awareness (E)
awareness (E) (I)(F) manoeuvre from ATC (E)
ATC comms (E)

9.7 Emergency
Broadcast
actions (E)

Figure D-4c – Guard Dog Functions Tree (part 3 of 3)

D-17
FAILURE ANALYSIS

Preliminary notes on columns:

Failure Condition (Hazard Description) – (a) Loss of Function; (b) Uncommanded Function; (c)
Incorrect Function

Failure Conditions

Table D(vi) – Functional Failure Conditions for Guard Dog UAVS

FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
1. Stability & Control (I)
F1.1A 1.1 Determine attitude and speed (a) Unable to determine UAV roll, pitch or yaw attitude
(I)
F1.1B (a) Unable to determine UAV airspeed
(b) (not applicable – continuous function)
F1.1C (c) Accuracy error in measured attitude or speed
F1.1D (c) Measured attitude or speed freezes at last reading
F1.1E (c) Measured attitude or speed goes to maximum scale
F1.1F (c) Measured attitude or speed goes to minimum scale
F1.1G (c) Transient spikes in measured attitude or speed
F1.2A 1.2 Stabilise perturbations (I) (a) Loss of UAV stability
(b) (continuous function)
F1.2B (c) Undamped / poorly damped manoeuvres or speed
F1.2C (c) Over damped manoeuvres or speed
F1.2D (c) Phase lag drives oscillations
F1.3A 1.3 Manoeuvre UAV (I) (a) Unable to manoeuvre UAV at all when demanded
F1.3B (a) Unable to manoeuvre UAV in certain axes, when demanded
F1.3C (b) Undemanded manoeuvre
F1.3D (c) Asymmetric manoeuvre control – demand in one axis causes
uncontrollable manoeuvre in another axis
F1.3E (c) Transient control deflections
F1.3F (c) Manoeuvre control restriction – limited manoeuvre
F1.3G (c) Manoeuvre control jams – unable to stop manoeuvre
F1.3H (c) Excessive manoeuvre control deflections
F1.3I (c) Manoeuvre capability exceeds vehicle structural strength
F1.3J (c) Manoeuvre control time delay (lag)
F1.4A 1.4 Manual Override - Remote (a) Unable to take manual control of UAV
Piloting (I)
F1.4B (b) Unable to fly UAV with autonomy
F1.4C (c) Conflicting authority between manual and autonomous control
F1.4D (c) Conflicting authority between separate ground sources for
manual control
F1.5A 1.5 Field T/O Launch Control (I)(F) (a) Launch control not provided during ramp t/o
F1.5B (a) Launcher fails to reach necessary speed
F1.5C (b) Launch control initiated during other flight phase
F1.5D (c) Launch speed excessive
1.6 Control Flight Path (I)
F1.6A 1.6.1 Control Airspeed (I) (a) Airspeed cannot be increased when necessary
F1.6B (a) Airspeed cannot be decreased when necessary
F1.6C (b) Airspeed runaway up
F1.6D (b) Airspeed runaway down
F1.6E (c) Asymmetric thrust (power) causing uncontrollable yaw or roll
(depending on propulsion configuration)

D-18
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
F1.6F (c) Incorrect airspeed achieved – too high
F1.6G (c) Incorrect airspeed achieved – too low
F1.6H 1.6.2 Control Altitude & Rate (I) (a) Altitude cannot be increased when required
F1.6I (a) Altitude cannot be decreased when required
F1.6J (b) Altitude runaway up
F1.6K (b) Altitude runaway down
F1.6L (c) Incorrect altitude achieved – too high
F1.6M (c) Incorrect altitude achieved – too low
F1.6N (c) Altitude achieved at incorrect climb / descent rate
F1.6O 1.6.3 Control Heading (I) (a) Heading not variable
F1.6P (b) Heading changes without demand
F1.6Q (b) Heading runaway
F1.6R (c) Incorrect heading achieved

2. Air Navigation (I)

2.1 Position, Heading & Altitude
Awareness (I)
F2.1A 2.1.1 Determine Position, Heading (a) Unable to determine position
& Altitude (I)
F2.1B (a) Unable to determine heading
F2.1C (a) Unable to determine altitude
(b) (continuous function)
F2.1D (c) Accuracy error in measured position, heading or altitude
F2.1E (c) Lag in position, heading or altitude data measurement (phase
shift)
F2.1F (c) Measured position, heading or altitude freezes at last reading
F2.1G (c) Measured position, heading or altitude goes to maximum scale
F2.1H (c) Measured position, heading or altitude goes to minimum scale
F2.1I (c) Transient spikes in measured position, heading or altitude
F2.1J 2.1.2Determine Nav Data accuracy (a) Unable to determine Nav data accuracy
(I)(F)
(b) (continuous function)
F2.1K (c) Nav data erroneously determined as accurate
F2.1L (c) Nav data erroneously determined as inaccurate
F2.2A 2.2 Store / Update Mission Route (I) (a) Loss of stored mission route
F2.2B (a) Unable to update / change route once stored
F2.2C (b) Mission route changed without demand
F2.2D (c) Mission route stored / updated with incorrect data elements
(stale / zero / default / random data)
F2.2E (c) Mission route stored / updated partially – elements missing
F2.2F (c) Mission route not achievable (performance)
F2.2G (c) Mission route not safe (ROA)
F2.3A 2.3 Monitor / Correct actual v (a) Unable to determine route error
planned route (I)
F2.3B (a) Unable to determine route correction
(b) (Continuous function)
F2.3C (c) Erroneous route error or correction determined
2.4 Auto Take off & Landing (I)(F)
F2.4A 2.4.1 Determine Airfield T/O Climb- (a) Airfield T/O (runway) profile lost
out profile (F)(E)
F2.4B (a) Airfield climb-out profile lost
F2.4C (b) Climb out profile initiated in other phase
F2.4D (c) Airfield T/O (runway) profile for wrong airfield / runway
F2.4E (c) Airfield climb-out profile for wrong airfield / runway

D-19
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
F2.4F (c) Airfield climb out profile corrupted (spikes, dips, truncated,
capped)
F2.4G 2.4.2 Determine High accuracy (a) Unable to determine high accuracy position
Position, heading & Altitude (F)
F2.4H (a) Unable to determine high accuracy heading
F2.4I (a) Unable to determine high accuracy altitude
F2.4J (b) High accuracy data presented in other phases
F2.4K (c) Incorrect position determined
F2.4L (c) Inaccurate position determined
F2.4M (c) Incorrect heading determined
F2.4N (c) Inaccurate heading determined
F2.4O (c) Incorrect altitude determined
F2.4P (c) Inaccurate altitude determined – too high
F2.4Q (c) Inaccurate altitude determined – too low
F2.4R 2.4.3 Determine Airfield Approach, (a) Airfield approach lost
Hold, Circuit, R/W profile (F)(E)
F2.4S (a) Airfield hold lost
F2.4T (a) Airfield circuit lost
F2.4U (a) Airfield R/W profile lost
F2.4V (b) Airfield approach, hold, circuit initiated in other phase
F2.4W (c) Airfield approach, hold, circuit runway profile for wrong airfield /
runway
F2.4X (c) Airfield approach, hold, circuit runway profile corrupted (spikes,
dips, truncated, capped)
F2.4Y 2.4.4 High Accuracy monitor / (a) Unable to determine T/O path error / correction
correct actual v planned profile
(F)(E)
F2.4Z (a) Unable to determine landing path error / correction
(b) (Continuous function)
F2.4AA (c) Erroneous T/O path error or correction determined
F2.4AB (c) Erroneous landing path error or correction determined
F2.4AC 2.4.5 Determine Wind speed & (a) Not possible to determine W/S or direction
direction v R/W and landing
characteristics (F)
(b) (continuous function)
F2.4AD (c) Incorrect w/s determined – too high
F2.4AE (c) Incorrect w/s determined – too low
F2.4AF (c) Incorrect wind direction determined
F2.4AG (c) Noisy, oscillating wind direction
2.5 Terrain Avoidance (E)
F2.5A 2.5.1 Awareness & flight path (a) Unaware of surrounding terrain
proximity (E)
F2.5B (a) Unaware of proximity of surrounding terrain to flight path
F2.5C (a) Terrain proximity determined at low sampling rate
(b) (continuous function)
F2.5D (c) Incorrect surrounding terrain determined
F2.5E (c) Incorrect distance to terrain determined – lower than actual
F2.5F (c) Incorrect distance to terrain determined – higher than actual
F2.5G 2.5.2 Maintain separation (ROA) (E) (a) Terrain separation (minimum) not maintained
F2.5H (b) Terrain separation driven down / up to minimum
F2.5I (c) Terrain separation maintained but below ROA requirement
(highest point +1000ft)
F2.5J (c) Flight profile to maintain terrain separation exceeds vehicle
climb performance
F2.5K 2.5.3 Emergency evasion (E) (a) Need for emergency terrain evasion not determined
F2.5L (a) Need for emergency terrain evasion determined late

D-20
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
F2.5M (b) Emergency evasion manoeuvre triggered when not necessary
F2.5N (c) Required emergency evasion manoeuvre exceeds vehicle
manoeuvre performance
F2.5O (c) Incorrect emergency evasion manoeuvre identified
2.6 Sensitive Area Avoidance
(Fixed Danger & Populated areas)
(E)
F2.6A 2.6.1 Awareness & flight path (a) Unaware of Sensitive Area
proximity (E)
F2.6B (a) Unaware of proximity of Sensitive Area to flight path
(b) (continuous function)
F2.6C (c) Incorrect Sensitive Area determined
F2.6D (c) Incorrect distance to Sensitive Area determined – nearer than
actual
F2.6E (c) Incorrect distance to Sensitive Area determined – further than
actual
F2.6F 2.6.2 Maintain separation (ROA) (E) (a) Sensitive Area separation (minimum) not maintained
(b) (continuous function)
F2.6G 2.6.3 Emergency incursion action (a) Need for emergency evasion not determined
(E)
F2.6H (a) Need for emergency evasion determined late
F2.6I (b) Emergency evasion manoeuvre triggered when not necessary
F2.6J (c) Incorrect emergency evasion manoeuvre identified
2.7 Controlled Airspace avoidance
(E)
F2.7A 2.7.1 Awareness & flight path (a) Unaware of Controlled Airspace
proximity (E)
F2.7B (a) Unaware of proximity of Controlled Airspace to flight path
(b) (continuous function)
F2.7C (c) Incorrect Controlled Airspace determined
F2.7D (c) Incorrect distance to Controlled Airspace determined – nearer
than actual
F2.7E (c) Incorrect distance to Controlled Airspace determined – further
than actual
F2.7F 2.7.2 Maintain separation (ROA) (E) (a) Controlled Airspace separation (minimum) not maintained
(b) (continuous function)
F2.7G 2.7.3 Emergency incursion action (a) Need for emergency evasion not determined
(E)
F2.7H (a) Need for emergency evasion determined late
F2.7I (b) Emergency evasion manoeuvre triggered when not necessary
F2.7J (c) Incorrect emergency evasion manoeuvre identified
2.8 Variable Danger Areas
(NOTAMS) Avoidance (E)
F2.8A 2.8.1 Awareness & flight path (a) Unaware of NOTAMS Area
proximity (E)
F2.8B (a) Unaware of proximity of NOTAMS Area to flight path
(b) (continuous function)
F2.8C (c) Incorrect NOTAMS Area determined
F2.8D (c) Incorrect distance to NOTAMS Area determined – nearer than
actual
F2.8E (c) Incorrect distance to NOTAMS Area determined – further than
actual
F2.8F 2.8.2 Maintain separation (ROA) (E) (a) NOTAMS Area separation (minimum) not maintained
(b) (continuous function)
F2.8G 2.8.3 Emergency incursion action (a) Need for emergency evasion not determined
(E)
F2.8H (a) Need for emergency evasion determined late

D-21
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
F2.8I (b) Emergency evasion manoeuvre triggered when not necessary
F2.8J (c) Incorrect emergency evasion manoeuvre identified

3. Control on the Ground (I)

3.1 Control Speed on the ground (I)
F3.1A 3.1.1 Determine speed on ground (a) Unable to determine speed on the ground
(I)
F3.1B (b) Attempt to determine ground speed while in the air
F3.1C (c) Ground speed inaccuracy - too high
F3.1D (c) Ground speed inaccuracy – too low
F3.1E 3.1.2 Controlled Ground thrust (I) (a) Unable to increase ground thrust
F3.1F (a) Unable to decrease ground thrust
F3.1G (b) Ground thrust increases without demand – runaway up
F3.1H (b) Ground thrust decreases without demand – runaway down
F3.1I (c) Ground thrust change lags demand
F3.1J (c) Excessive ground thrust change for required demand (scale
error)
F3.1K (c) Inadequate ground thrust change for required demand (scale
error)
F3.1L (c) Ground thrust asymmetry (roll or yaw depending on propulsion
configuration)
F3.1M 3.1.3 Controlled Ground Braking (I) (a) Unable to apply / increase ground braking
F3.1N (a) Unable to decrease / release ground braking
F3.1O (b) Ground braking increases / on without demand
F3.1P (b) Ground braking decreases / releases without demand
F3.1Q (c) Ground braking change lags demand
F3.1R (c) Excessive ground braking for required demand (scale error)
F3.1S (c) Inadequate ground braking for required demand (scale error)
F3.1T (c) Ground braking asymmetry
3.2 Control Position on the ground
(I)
F3.2A 3.2.1 Determine ground position & (a) Unable to determine ground position
heading (I)
F3.2B (a) Unable to determine ground heading
F3.2C (b) Attempt to determine ground position / heading while in the air
F3.2C (c) Ground position or heading inaccurate
F3.2D 3.2.2 Ground steering (I) (a) Ground steering not available – steering fixed
F3.2E (a) Ground steering not available – steering free
F3.2F (b) Ground steering when not on the ground
F3.2G (c) Incorrect sense ground steering applied
F3.2H (c) Excessive ground steering applied
F3.2I (c) Inadequate ground steering applied
F3.2J (c) Ground steering lags demand
F3.2K 3.2.3 Determine Airfield layout / (a) Unable to determine airfield layout / required ground route
required ground route (F)(E)
F3.2L (b) Ground route identified when not on the ground
F3.2M (c) Incorrect airfield identified
F3.2N (c) Incorrect ground route (at correct airfield) identified
F3.2O 3.2.4 Monitor / correct actual v (a) Unable to determine ground route error
required ground route (F)
F3.2P (a) Unable to determine ground route correction
(b) (Continuous function on the ground)
F3.2Q (c) Erroneous ground route error or correction determined
F3.2R 3.2.5 Determine Air / Ground (a) Unable to determine air / ground transition
transition (F)
(b) (continuous function)
D-22
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
F3.2S (c) Air to ground transition erroneously determined
F3.2T (c) Ground to air transition erroneously determined
F3.2U (c) Air / ground transition identified during transient ground contact
F3.2V (c) Air / ground transition not identified during transient ground
contact
F3.2W 3.2.6 Determine Ground obstacles (a) Unable to determine position of fixed ground obstacles
(F)(E) (Fixed or mobile)
F3.2X (a) Unable to detect mobile ground obstacles
F3.2Y (b) Attempt to identify ground obstacles while not on the ground
F3.2Z (c) Ground obstacle identified where there is none
F3.2AA (c) Ground obstacle not identified where there is
F3.2AB (c) Ground obstacle identified position inaccurate
F3.2AC (c) Mobile ground obstacle identified but speed / direction not
4. Manage Datalink (I) Classification of datalink functional failures is critically
dependent on level of autonomy of UAV in event of failure, in
reaching a safe outcome.
4.1 Monitor datalink condition (I)
F4.1A 4.1.1 Signal strength (I) (a) Unable to determine datalink signal strength
F4.1B (b) (continuous function)
F4.1C (c) Datalink signal strength erroneously indicated too high
F4.1D (c) Datalink signal strength erroneously indicated too low
F4.1E (c) Datalink signal strength very noisy – high / low oscillation
F4.1F 4.1.2 D/L Equipment status (I) (a) Datalink equipment status not available
(b) (continuous function)
F4.1G (c) Datalink equipment status shown ‘no fail’ with actual single fail
F4.1H (c) Datalink equipment status shown ‘no fail’ with actual total fail
F4.1I (c) Datalink equipment status shown ‘single fail’ when actually no
fail
F4.1J (c) Datalink equipment status shown ‘total fail’ when actually no fail
F4.1K (c) Datalink equipment status oscillates between fail / no fail status
4.2 Control Datalink path (I)
F4.2A 4.2.1 Handover to next GCS (I)(F) (a) Datalink control cannot hand over from current to next GCS
F4.2B (b) Datalink attempts control hand over from current GCS without
demand
F4.2C (c) Datalink control hand over from current GCS, but next GCS
unable to take control
F4.2D (c) Datalink control hand over from current GCS, but next GCS
unaware it has control
F4.2E (c) Datalink control taken over by next GCS, without current GCS
being aware
F4.2F (c) Datalink control hand over to next GCS, but current GCS also
retains control (dual control)
F4.2G (c) Datalink attempted control hand over to next GCS, but neither
GCS retains control
F4.2H 4.2.2 Route via Satellite (I)(F) (a) Unable to route datalink via satellite
F4.2I (b) Datalink routed via satellite without demand
F4.2J (c) Datalink routed via wrong satellite
F4.2K (c) Datalink ‘cross talk’ with other satellite traffic
F4.2L (c) Satellite link saturates with other satellite traffic – datalink drop
outs
F4.2M (c) Satellite link saturates with other satellite traffic – datalink
delays
F4.2N (c) Satellite link fails totally
F4.2N 4.2.3 Relay between UAVs (I)(F) (a) Unable to route datalink to 1st UAV via relay UAV
F4.2O (b) Datalink routed via relay UAV without demand
F4.2P (c) Datalink routed via wrong relay UAV

D-23
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
F4.2Q (c) Datalink routed via relay UAV to wrong 1st UAV
F4.2R (c) Relay Datalink ‘cross talk’ with RF noise
F4.2S (c) Datalink command confusion between those meant for relay
UAV and those for 1st UAV
F4.2T (c) Relay datalink drop outs
F4.2U (c) Relay datalink delays
F4.2V (c) Relay link fails totally
F4.3A 4.3 Datalink Fail / Degrade (a) D/L fail action (hold then divert) not taken when required
Emergency Action(I)
(see function 7.3.1 for divert
function failures)
F4.3B (b) D/L fail action (hold then divert) taken without demand
F4.3C (c) D/L fail action partially taken – UAV remains in hold
F4.3D (c) D/L fail action partially taken – UAV diverts immediately
F4.3E (c) D/L fail action partially taken – D/L fail broadcast not issued
F4.4A 4.4 Defend D/L (Jamming, stealing) (a) Datalink jammed
(E)
F4.4B (a) Datalink stolen
(b) (continuous function)
F4.4C (c) Valid datalink control rejected as jamming / stealing
F4.5A 4.5 Monitor Terrain proximity to (a) Fail to monitor terrain proximity to control LOS
LOS (E)
(b) (continuous function)
F4.5B (c) Terrain proximity inaccuracy – judged closer than actual
F4.5C (c) Terrain proximity inaccuracy – judged further than actual
5. Manage Payload (I)
F5.1A 5.1 Sensor control (I) [including (a) Unable to direct sensor at point of interest [including forwards,
visual sensor] for flight assistance]
F5.1B (b) Sensor slews off point of interest without demand
F5.1C (c) Sensor not stabilized on point of interest (subject to flight
motion / noise)
F5.1D (c) Sensor field of view / zoom incorrect – too wide
F5.1E (c) Sensor field of view / zoom incorrect – too narrow
5.2 Payload data download (I)
[including visuals]
5.3 Distribute Payload data (I)
5.4 Prioritise Users' Payload
requests (I)

6. Monitor Mission progress (I)

F6.1A 6.1 Telemeter S&C params to GCS (a) Unable to telemeter S&C parameters to GCS
(I)
(b) (continuous function)
F6.1B (c) Inaccurate S&C parameters telemetered
F6.1C (c) Other parameters telemetered as S&C
F6.2A 6.2 Telemeter Air Nav params to (a) Unable to telemeter Air Nav parameters to GCS, at all
GCS (I)
(b) (continuous function)
F6.2B (c) Inaccurate Air Nav parameters telemetered
F6.2C (c) Other parameters telemetered as Air Nav
F6.3A 6.3 Telemeter Ground Control (a) Unable to telemeter Ground Control parameters to GCS, at all
params to GCS (I)
(b) (continuous function)
F6.3B (c) Inaccurate Ground Control parameters telemetered
F6.3C (c) Other parameters telemetered as Ground Control
F6.4A 6.4 Telemeter Flight Systems status (a) Unable to telemeter Flight Systems status to GCS, at all
to GCS (I)
D-24
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
(b) (continuous function)
F6.4B (c) Inaccurate Flight Systems status telemetered
F6.4C (c) Other parameters telemetered as Flight Systems status
6.5 Monitor Weather for changes
(F)(E)
F6.5A 6.5.1 Weather awareness en-route (a) Unaware of weather conditions en route
(E) [Precipitation, icing, windspeed /
direction, visibility VMC / IMC]
F6.5B (a) Unaware of wind speed or direction en route
(b) (continuous function)
F6.5C (c) Erroneous indication of precipitation, icing or visibility conditions
en route – better than actual
F6.5D (c) Erroneous indication of precipitation, icing or visibility conditions
en route – worse than actual
F6.5E (c) Inaccurate indication of wind speed or direction en route
F6.5F 6.5.2 Assess Wx proximity to (a) Unable to determine Wx proximity to planned route
planned route (E)
(b) (continuous function)
F6.5G (c) Wx proximity inaccurately determined nearer than actual
F6.5H (c) Wx proximity inaccurately determined further than actual
F6.5I (c) Wx movement inaccurately predicted – slower than actual
F6.5J (c) Wx movement inaccurately predicted – faster than actual
F6.5K 6.5.3 Determine Wx separation (a) Unable to determine a separation route around the weather –
route around (E) [to reach final UAVS failure
destination]
F6.5L (a) Unable to determine a separation route around the weather –
weather close out
F6.5M (a) Flight path not modified to avoid bad Wx
F6.5N (b) Unnecessary route around inserted in flight path
F6.5O (c) Revised bad Wx route does not avoid the weather
F6.5P (c) Revised bad Wx route exceeds range capability of vehicle
F6.5Q (c) Revised bad Wx route infringes other separation zones
F6.5R 6.5.4 Determine nearest (a) Unable to determine a diversionary airfield
diversionary airfield & route (E)
F6.5S (a) Unable to determine a route to the diversionary airfield
(b) (continuous function)
F6.5T (c) Incorrect diversion airfield determined – at increased flight
distance
F6.5U (c) Incorrect diversion airfield determined – weather close out
F6.5V (c) Diversion airfield determined only periodically (i.e. not
continuous function)
F6.5W (c) Diversion airfield not communicated between UAV and GCS,
immediately after determination
F6.5X (c) Diversion route not communicated between UAV and GCS,
immediately after determination

7. Manage Flight Systems

(I)
F7.1A 7.1 Determine flight systems status (a) Unable to determine flight critical systems status
(I)
(b) (continuous function)
F7.1B (c) Flight critical system indicates a single fail, incorrectly
F7.1C (c) Flight critical system indicates a total fail, incorrectly
F7.1D (c) Flight critical system single fail not indicated
F7.1E (c) Flight critical system total fail not indicated
F7.1F (c) Incorrect flight system shown as having failure
7.2 Redundant systems control? (I) [leave to system level FHA]

D-25
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
7.3 Degraded systems emergency
actions (I)
F7.3A 7.3.1 Divert (E) (a) Failure to divert when expected
F7.3B (b) Divert carried out when not necessary
F7.3C (c) Divert carried out to different divert airfield than determined
F7.3D (c) Divert carried out on different route to that determined
F7.3E (c) (Divert demanded but no airfield or route available)
F7.3F (c) (Divert due to Collision Avoidance failure partially carried out –
without broadcast )
F7.3G (c) (Divert carried out when Emergency Landing should be )
F7.3H (c) (Emergency Landing carried out when divert should be)
F7.3I 7.3.2 Emergency Landing (E) (a) Failure to carry out controlled Emergency Landing, when
necessary
F7.3J (b) Emergency Landing carried out when not necessary
F7.3K (c) (Emergency landing carried out partially – without MAYDAY
broadcast)
F7.3L (c) Emergency landing attempted in populated area

8. Pre Flight Preparations (I)

8.1 Mission Planning (I)
F8.1A 8.1.1 Plan mission (I) (a) Unable to plan mission
F8.1B (a) Mission plan completed but not retained and loaded
F8.1C (b) (Mission planning initiated when not required?)
F8.1D (c) Mission plan partially complete
F8.1E (c) Mission plan partially in error – random error
F8.1F (c) Mission plan partially in error – stale information from earlier
mission
F8.1G (c) Mission plan for incorrect mission loaded
F8.1H (c) Mission plan confuses ident of UAVS system elements (UAVs;
GCSs)
F8.1I (c) Mission plan completed but not within capability of UAVS
performance
F8.1J 8.1.2 HIRF Location awareness (E) (a) Unaware of HIRF locations for mission planning
(b) (continuous function)
F8.1K (c) Not all HIRF locations known for mission planning
F8.1L (c) Some HIRF locations incorrect for mission planning
F8.1M (c) Some HIRF height / range information incorrect for mission
planning
F8.1N (c) Some HIRF types incorrect for mission planning
F8.1O 8.1.3 Terrain Awareness (E) (a) Unaware of terrain for mission planning
(b) (continuous function)
F8.1P (c) Not all terrain known for mission planning
F8.1Q (c) Some terrain positions incorrect for mission planning
F8.1R (c) Some terrain heights incorrect for mission planning
F8.1S (c) Some terrain types incorrect for mission planning
F8.1T 8.1.4 Danger Area / populated area (a) Unaware of Danger / populated areas for mission planning
awareness (E)
(b) (continuous function)
F8.1U (c) Not all Danger / populated areas known for mission planning
F8.1V (c) Some Danger / populated areas locations incorrect for mission
planning
F8.1W (c) Some Danger / populated areas height information incorrect for
mission planning
F8.1X 8.1.5 Controlled Airspace (a) Unaware of Controlled Airspace for mission planning
awareness (E)
(b) (continuous function)

D-26
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
F8.1Y (c) Not all Controlled Airspace known for mission planning
F8.1Z (c) Some Controlled Airspace locations incorrect for mission
planning
F8.1AA (c) Some Controlled Airspace height information incorrect for
mission planning
F8.1AB (c) Some controlled airspace types incorrect
F8.1AC 8.1.6 Weather awareness (E) (a) Unaware of current weather conditions
F8.1AD (a) Unaware of predicted weather conditions
(b) (continuous function)
F8.1AE (c) Weather conditions incorrect - optimistic
F8.1AF (c) Weather conditions incorrect - pessimistic
F8.1AG (c) Weather conditions incorrect – location or path
(c) (also as function 6.5)

8.2 T/O / Launch Preparation (F)

F8.2A 8.2.1 Refuel / recharge (a) Unable to refuel / recharge consumables
consumables (I)
F8.2B (b) (Refuel / recharge at incorrect phase?)
F8.2C (b) Refuelling / recharging still underway at launch
F8.2D (c) Partially refuelled / recharged
F8.2E (c) Fuelled / charged with incorrect consumables
F8.2F (c) Fuel / charge contaminated
F8.2G (c) Fuelled asymmetrically (fore / aft; left / right)
F8.2H 8.2.2 Pre flight systems test (I)(F) (a) Unable to pre-flight systems test
F8.2I (b) (Pre-flight systems test at incorrect phase?)
F8.2J (b) Still in pre-flight test at launch
F8.2K (c) Partial pre-flight systems test carried out
F8.2L (c) Pre-flight systems test returns incorrect pass for critical system
F8.2M (c) Pre-flight systems test returns incorrect fail for critical system
F8.2N (c) Pre-flight systems test confuses Ident of systems test results
F8.2O 8.2.3 Upload Mission Plan (I)(F) (a) Unable to upload mission plan
F8.2P (b) (Upload mission plan at incorrect phase?)
F8.2Q (b) Still uploading mission plan at launch
F8.2R (c) Partial upload of mission plan carried out
F8.2S (c) Mission plan uploaded but not retained – no plan
F8.2T (c) Mission plan uploaded but not retained – stale plan retained
F8.2U (c) Incorrect mission plan uploaded – UAV differs from GCS
F8.2V (c) Incorrect mission plan uploaded – both UAV and GCS
F8.2W (c) Incorrect mission plan uploaded – current and next GCS differ
F8.2X (c) Incorrect mission plan uploaded – both current and next GCS
F8.2Y (c) Mission plan corrupted during upload
F8.2Z (c) Mission plan upload confuses ident of UAVs (relay / sensor
UAVs)
9. Manage Communications (E)
F9.1A 9.1 Understand / reply to Airfield (a) Unable to hear ATC airfield voice comms at all
ATC voice comms (E)
F9.1B (a) Unable to hear ATC airfield voice comms intermittently
F9.1C (a) Unable to understand airfield ATC voice comms
F9.1D (a) Unable to reply to airfield ATC voice comms
F9.1E (b) Transmit on ATC airfield comms channel when not intended
F9.1F (b) Comply with / reply to airfield ATC message intended for
another aircraft
(b) (Comply with / reply to airfield ATC message from incorrect
airfield)
F9.1G (c) Misunderstand ATC airfield comms

D-27
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
F9.1H (c) Delay responding to airfield ATC comms
F9.1I (c) Incorrect message transmitted to airfield ATC comms
F9.2A 9.2 Detect & respect airfield visual (a) Unable to detect or respect airfield visual signals
signals (E)
F9.2B (b) Detect / respect airfield visual signals that are not pertinent to
UAV position (incorrect signal detected / respected)
F9.2C (c) Misinterpret airfield visual signal
F9.3A 9.3 Understand / reply to En-Route (a) Unable to detect ATC en-route comms at all
ATC advice - voice / digital (E)
F9.3B (a) Unable to detect ATC en-route comms intermittently
F9.3C (a) Unable to understand en-route ATC comms
F9.3D (a) Unable to reply to en-route ATC comms
F9.3E (b) Transmit on en-route ATC comms channel when not intended
F9.3F (b) (Comply with / reply to en-route ATC message from incorrect
ATC service)
F9.3G (b) Comply with / reply to en-route ATC message intended for
another aircraft
F9.3H (c) Misunderstand en-route ATC comms
F9.3I (c) Delay responding to en-route ATC comms
F9.3J (c) Incorrect message transmitted to en-route ATC comms
F9.4A 9.4 Provide Tracking 'visibility' (a) UAV not visible to ATC for transponder tracking
(signal, visual) (E)
F9.4B (a) UAV not visible to ATC for RADAR tracking by RF signature
F9.4C (a) UAV not visible to ATC for tracking visually
(b) (RF signature / visual are continuous functions)
F9.4D (b) Provide transponder response when not required
F9.4E (c) Provide transponder response late when interrogated
F9.4F (c) Provide incorrect Aircraft Identifier when interrogated
F9.4G (c) Provide incorrect aircraft altitude when interrogated
F9.5A 9.5 Manage ATC Frequency (a) Unable to change ATC frequency selection
selections (E)
F9.5B (a) Unable to hold required ATC frequency
F9.5C (b) ATC frequency changed when not required
F9.5D (c) ATC frequency changed to incorrect frequency (not in use
frequency)
F9.5E (c) ATC frequency changed to incorrect frequency (in-use
frequency)
F9.5F (c) ATC frequency changed to emergency frequency in error
9.6 Comply with ATC procedures Possible range of procedures constrained to following:
(E) Airfield – ground movement (clearance & direction); enter
runway; take-off; climb out direction and final height; approach
direction; circuit direction; runway allocation; hold height &
direction; landing clearance; exit runway clearance
En-route – Climb / descend and cruising altitude; heading
change; hold position, height and direction; diversion
F9.6A 9.6.1 Determine required (a) Unable to determine required manoeuvre from ATC comms
manoeuvre from ATC comms (E)
F9.6B (b) Manoeuvre determined from ATC comms, where none was
requested
F9.6C (c) Incorrect manoeuvre determined from ATC comms and carried
out
F9.6D (c) ATC required Manoeuvre partially completed
F9.6E 9.6.2 Confirm manoeuvre with ATC (a) Unable to confirm initiating manoeuvre with ATC
(E)
F9.6F (a) Unable to confirm completing manoeuvre with ATC
F9.6G (b) ATC manoeuvre ‘confirmed’ when none was requested
F9.6H (c) Incorrect ATC manoeuvre ‘confirmed’ to ATC (compared to that
being actually carried out)
D-28
FFA ID Function Failure Condition (Hazard Description)
(a),
(b),
(c)
F9.7A 9.7 Emergency Broadcast Actions (a) Unable to broadcast – “Collision Avoidance Fail”
(E) (Coll aware fail; D/L fail;
Mayday)
F9.7B (a) Unable to broadcast – Data Link Fail
F9.7C (a) Unable to broadcast – Mayday
F9.7D (b) Broadcast ‘Collision awareness fail’ when not required
F9.7E (b) Broadcast ‘Data Link fail’ when not required
F9.7F (b) Broadcast ‘Mayday’ when not required
F9.7G (c) Broadcast incorrect emergency message compared to that
actually required

10. Collision Avoidance (F)(E)

F10.1A 10.1 Detect Traffic (E) (a) Unable to detect ‘co-operative’ traffic
F10.1B (a) Unable to detect ‘non co-operative’ traffic
F10.1C (b) Traffic detected when not present
F10.1D (c) Traffic detected late
F10.1E (c) Traffic detected in incorrect position
F10.1F (c) Traffic detected at incorrect height
F10.2A 10.2 Determine traffic relative track (a) Unable to determine traffic relative track
(E)
F10.2B (a) Traffic relative track determined at low update rate
(b) (continuous function when traffic detected)
F10.2C (c) Traffic relative track incorrectly indicated as converging
F10.2D (c) Traffic relative track incorrectly indicated as not converging
F10.3A 10.3 Maintain traffic separation (a) Failure to manoeuvre (adequately) to maintain traffic separation
(ROA) (E) i.a.w. Rules of the Air (right of way / minimum separation)
F10.3B (b) Traffic separation manoeuvre initiated when UAV should
maintain current track (right of way)
F10.3C (c) Incorrect traffic separation manoeuvre initiated (turn direction)
F10.4A 10.4 Collision emergency evasion (a) Failure to manoeuvre (adequately) for collision emergency
(E) evasion
F10.4B (a) Collision emergency evasion manoeuvre initiated late
F10.4C (b) Collision emergency evasion manoeuvre initiated when
unnecessary
F10.4D (c) Incorrect collision emergency evasion manoeuvre initiated (turn
direction / height change)
F10.4E (c) Collision emergency evasion manoeuvre successful but UAV
affected by aircraft wake turbulence
F10.5A 10.5 Conspicuity to air traffic (a) Unable to be detected by ‘co-operative’ traffic
(visual, RF) (E)
F10.5B (a) Unable to be seen by other air traffic
F10.5C (a) UAV RF (Radar) Conspicuity varies significantly with
observation aspect
F10.5D (a) UAV visual conspicuity varies significantly with observation
aspect
(b) (continuous function for civil operation – i.e. not switchable
stealth)
F10.5E (c) UAV resembles other aircraft types of different size or
performance

D-29
EFFECTS CONSIDERATION

Preliminary Notes:

A number (but not all) of the failures identified in Table D(vi) have been analysed for failure effects and classification. Safety objectives and
verification requirements have not been set at this stage, but would follow the guidance of ARP 4761 and use the criteria set in Table D(i), D(ii) and
D(iii).
Flight Phases – (Pre) Pre-flight; (Tax) Taxiing; (TO A) Take-off – from airfield; (TO F) Take off – ramp launch from field; (Tran) Transit under control of
GCS; (Hand) Hand over control to second GCS; (Tran S) Transit with GCS relay via satellite; (Sens) On Task – using sensor payload; (Rel) On task -
on station to relay TCDL to reach sensor UAV; (App) Approach; (Land A) Landing – at airfield; (Land F) Landing – rough field.
Effect of Failure Condition – (1) AW – effect on UAV, safety margins, continued & controlled flight; (2) ATM – effect on UAV Crew, ATCO, other Traffic
Table D(vii) – Failure Effects for (a selection of) Guard Dog failure conditions
FFA Failure Condition Flight Effect of Failure Condition - (1) AW; (2) ATM Classification Justification
ID Phases
1. Stability & Control (I); 1.2 Stabilise perturbations (I)

F1.2A Loss of UAV stability Tax, TO A, TO (1) Unstable UAV leads to overall loss of control – unable (1) Catastrophic [Critical safety requirements will be set, if the
F, Tran, Hand, to continue controlled flight (2) Severity 1 Relay role is to be viable in unsegregated
Tran S, Sens, Knock-on for Rel UAV would be loss of data link for Sens airspace.]
App, Land A, UAV
Land F, Rel
F1.2B Undamped / poorly TO A, TO F (1) Significant reduction in safety margins during T/O or (1) Hazardous
damped manoeuvres or Land A, Land landing, due to oscillations. Potential for ground impact (2) Severity 2
speed F close to T/O or landing area
Tran, Hand, (2) Severe oscillations could cause height bust, deviation
Tran S, Sens, from clearance on approach, or reduced separation
App, Rel
F1.2C Over damped TO A, TO F, (1) Significant reduction in safety margins during T/O or (1) Hazardous
manoeuvres or speed Tran, Hand, landing, due to control effect delay. Potential for ground (2) Severity 2
Tran S, Sens, impact close to T/O or landing area
App, Land A, (2) Severe control lag could cause height bust, deviation
Land F, Rel from clearance on approach, or reduced separation
F1.2D Phase lag drives TO A, TO F, (As F1.2B) (1) Hazardous
oscillations Tran, Hand, (2) Severity 2
Tran S, Sens,
App, Land A,
Land F, Rel

D-30
 FFA Failure Condition Flight Effect of Failure Condition - (1) AW; (2) ATM Classification Justification
ID Phases
1. Stability & Control; 1.3 Manoeuvre UAV (I)

F1.3A Unable to manoeuvre TO A, TO F, (1), (2) Eventually, UAV will impinge on terrain or (1) Catastrophic (dependent on knock-on effect failure being
UAV at all when Tran, Hand, controlled airspace (2) Severity 1 realised)
demanded Tran S, Sens, (Knock on effect – a cause of F2.5G terrain separation fail;
App, Land A, F2.6F controlled airspace separation fail; F2.7F danger /
Land F, Rel populated area separation fail; F10.3A Traffic separation
fail)
F1.3B Unable to manoeuvre TO A, TO F, (1) Limited control available from secondary effects (see (1) Hazardous
UAV in certain axes, Tran, Hand, F1.3D below), sufficient to effect controlled loss of the (2) Severity 2 Scenarios for typical missions justify likely
when demanded Tran S, Sens, UAV over an unpopulated site ATM effect
App, Land A, (2) Likely to cause infringement of controlled airspace, but
Land F, Rel some control to minimise effect (i.e. maintain limited traffic
separation)
F1.3C Undemanded TO A, TO F, (1) In extreme, at critical flight condition (TO or Landing) (1) Catastrophic
manoeuvre Tran, Hand, loss of control (2) Severity 1
Tran S, Sens, (2) Could be a cause for separation minima being
App, Land A, breached – in extreme, (among traffic) cause collision
Land F, Rel
F1.3D Asymmetric manoeuvre TO A, TO F, (1) In extreme, at critical flight condition (TO or Landing) (1) Catastrophic Some secondary effects of controls are Ok
control – demand in Tran, Hand, loss of control (2) Severity 1 (and normal aerodynamic effect), provided
one axis causes Tran S, Sens, (2) Could be a cause for separation minima being there is sufficient control authority to
uncontrollable App, Land A, breached – in extreme, (among traffic) cause collision counteract them.
manoeuvre in another Land F, Rel Potential mitigation for F1.3B
axis
F1.3E Transient control TO A, TO F, (as F1.3C)
deflections Tran, Hand,
Tran S, Sens,
App, Land A,
Land F, Rel
F1.3F Manoeuvre control TO A, TO F, (as 1.3B)
restriction – limited Tran, Hand,
manoeuvre Tran S, Sens,
App, Land A,
Land F, Rel
F1.3G Manoeuvre control TO A, TO F, (as F1.3C)
jams – unable to stop Tran, Hand,
manoeuvre Tran S, Sens,
App, Land A,
Land F, Rel

D-31
 FFA Failure Condition Flight Effect of Failure Condition - (1) AW; (2) ATM Classification Justification
ID Phases
F1.3H Excessive manoeuvre TO A, TO F, (as F1.2B)
control deflections Tran, Hand,
Tran S, Sens,
App, Land A,
Land F, Rel
F1.3I Manoeuvre capability TO A, TO F, (1) UAV break up – unable to continue controlled flight (1) Catastrophic AW issue, as vehicle break up takes it out of
exceeds vehicle Tran, Hand, the ATM environment
structural strength Tran S, Sens,
App, Land A,
Land F, Rel
F1.3J Manoeuvre control time TO A, TO F, (as F1.2C and D)
delay (lag) Tran, Hand,
Tran S, Sens,
App, Land A,
Land F, Rel
1. Stability & Control; 1.4 Manual Override - Remote Piloting (I)

F1.4A Unable to take manual Taxi, TO A, No immediate effect, UNLESS a coincident functional As for the most Manual override is intended as mitigation for
control of UAV TO F, Tran, failure occurs (in functions 1-10 inc) requiring manual severe of other many other failure modes.
Hand, Tran S, intervention functions 1-10: Safety requires independence from other
Sens, App, (1) Catastrophic failure forms (EITHER - autonomy in case of
Land A, Land (2) Severity 1 manual failure, OR - use of an independent 3rd
F, Rel option such as Flight Termination System to
give a safe outcome, if critical functions are
provided on a common datalink with manual
control from the GCS)
F1.4B Unable to fly UAV with TO A, TO F, Higher workload on UAV-p initially. As for F1.3A: Autonomous flight / manual override need to
autonomy Tran, Hand, Critical effect IF datalink fails coincidently (effectively (1) Catastrophic be independent, as either / or is required for
Tran S, Sens, coincident with F1.4A) – UAV then reacts as F1.3A (2) Severity 1 successful continuing safe flight
App, Land A,
Land F, Rel
F1.4C Conflicting authority TO A, TO F, (as F1.4A and F1.4B)
between manual and Tran, Hand,
autonomous control Tran S, Sens,
App, Land A,
Land F, Rel

D-32
 FFA Failure Condition Flight Effect of Failure Condition - (1) AW; (2) ATM Classification Justification
ID Phases
F1.4D Conflicting authority TO A, TO F, DETECTED: GCSs may communicate, to resolve conflict (1) Catastrophic DETECTED – assumes GCSs have inter-
between separate Tran, Hand, and leave appropriate one in control (2) Severity 1 communication, independent of the UAV
ground sources for Tran S, Sens, UNDETECTED: GCSs (UAV-ps) struggle to retain control
manual control App, Land A, and perceive as UAV autonomous action – hence as UNDETECTED – MS7(a) emergency landing
Land F, Rel F1.4A and F1.4B scenario (low altitude) indicates lack of full
control may lead to uncontrolled crash in
villages rather than controlled emergency
landing in clear unpopulated area
1. Stability & Control; 1.6 Control Flight Path (I); 1.6.1 Control Airspeed (I)

F1.6A Airspeed cannot be TO A, TO F, (1) T/O: Unable to reach take-off speed – Reject TO – (1) Hazardous Speed control on approach drives
increased when Tran, Hand, reduction in safety margins but remain in control classification. Assumes have adequate speed
necessary Tran S, Sens, App: Difficult to maintain height profile on approach (as to remain in control and carry out emergency
App, Land A, F1.6H) – possibility of controlled loss of UAV, short of landing. MS8 routine approach to Aberporth
Land F, Rel runway supports classification, as approach is usually
over low / no population route
F1.6B Airspeed cannot be TO A, TO F, (1) Flight phases: Airspeed exceeds structural limit if (1) Catastrophic
decreased when Tran, Hand, manoeuvre has to be pulled (as F1.3I)
necessary Tran S, Sens, Land: UAV unable to decelerate adequately, overruns
App, Land A, runway / field
Land F, Rel
F1.6C Airspeed runaway up TO A, TO F, (as F1.6B) (1) Catastrophic
Tran, Hand,
Tran S, Sens,
App, Land A,
Land F, Rel
F1.6D Airspeed runaway TO A, TO F, (1) Flight phases: unable to maintain altitude / reach (1) Catastrophic
down Tran, Hand, stalling speed – loss of control
Tran S, Sens, Knock-on for Rel UAV would be loss of data link for Sens
App, Land A, UAV
Land F, Rel
F1.6E Asymmetric thrust TO A, TO F, As F1.3D: (1) Catastrophic Some secondary effects of controls are Ok
(power) causing Tran, Hand, (1) In extreme, at critical flight condition (TO or Landing) (2) Severity 1 (and normal aerodynamic effect), provided
uncontrollable yaw or Tran S, Sens, loss of control there is sufficient control authority to
roll (depending on App, Land A, (2) Could be a cause for separation minima being counteract them.
propulsion Land F, Rel breached – in extreme, (among traffic) cause collision Potential mitigation for F1.3B
configuration)
F1.6F Incorrect airspeed TO A, TO F, (as F1.6C)
achieved – too high Tran, Hand,
Tran S, Sens,
App, Land A,
Land F, Rel
D-33
 FFA Failure Condition Flight Effect of Failure Condition - (1) AW; (2) ATM Classification Justification
ID Phases
F1.6G Incorrect airspeed TO A, TO F, (as F1.6D)
achieved – too low Tran, Hand,
Tran S, Sens,
App, Land A,
Land F, Rel
2. Air Navigation (I); 2.1 Position, Heading & Altitude Awareness (I); 2.1.1 Determine Position, Heading & Altitude (I)

F2.1A Unable to determine TO A, TO F, In isolation – position can be approximated from heading, In extreme cases: AW severity assumes need to make blind
position Tran, Hand, speed etc. (1) Catastrophic emergency landing at last ‘known’ position
Tran S, Sens, In common failure with F2.1B or F1.1B – requires external (2) Severity 2 (MS7 emergency landing scenario shows that
App, Land A, means to identify position (functions 9.3 En-route ATC small inaccuracies could cause impact on
Land F, Rel communications and 9.4 Tracking ‘visibility’ village location, as lesser evil to flying on and
Without these, system faces emergency landing (function possibly crashing in major population area
7.3.2) in unknown terrain, or flight path through unknown ATM severity assumes that function 10
airspace Collision avoidance remains active – need to
Knock-on for Rel UAV would be loss of data link for Sens beware of potential common mode failures.
UAV
F2.1B Unable to determine TO A, TO F, (as F2.1A)
heading Tran, Hand,
Tran S, Sens,
App, Land A,
Land F, Rel
F2.1C Unable to determine TO A, TO F, If DETECTED - Could manage by increasing altitude (from Detected: MS8 routine approach to Aberporth over
altitude Tran, Hand, previous safe altitude) and steering where ground known (1) Major terrain assessed; MS5 emergency recovery
Tran S, Sens, to be lower (2) Severity 4 under Dav CTA assessed.
App, Land A, UNDETECTED - as F2.5G Unable to maintain safe Undetected:
Land F, Rel altitude over terrain (1) Catastrophic Undetected ATM severity assumes function 10
ATM – if DETECTED, call ATC and declare PAN PAN (2) Severity 2 Collision avoidance remains active – need to
PAN. If UNDETECTED, unable to maintain safe vertical beware of potential common mode failures.
separation below controlled airspace (as F2.7F)
F2.1D Accuracy error in TO A, TO F, (as F2.1A,B,C)
measured position, Tran, Hand,
heading or altitude Tran S, Sens,
App, Land A,
Land F, Rel
F2.1E Lag in position, heading TO A, TO F, (as F2.1A,B,C)
or altitude data Tran, Hand,
measurement (phase Tran S, Sens,
shift) App, Land A,
Land F, Rel

D-34
 FFA Failure Condition Flight Effect of Failure Condition - (1) AW; (2) ATM Classification Justification
ID Phases
F2.1F Measured position, TO A, TO F, (as F2.1A,B,C)
heading or altitude Tran, Hand,
freezes at last reading Tran S, Sens,
App, Land A,
Land F, Rel
F2.1G Measured position, TO A, TO F, (as F2.1A,B,C)
heading or altitude Tran, Hand,
goes to maximum scale Tran S, Sens,
App, Land A,
Land F, Rel
F2.1H Measured position, TO A, TO F, (as F2.1A,B,C)
heading or altitude Tran, Hand,
goes to minimum scale Tran S, Sens,
App, Land A,
Land F, Rel
F2.1I Transient spikes in TO A, TO F, Manageable, if spikes allow trend in position and altitude
measured position, Tran, Hand, to be assessed adequately. Else, treat as F2.1A,B,C
heading or altitude Tran S, Sens,
App, Land A,
Land F, Rel
2.5 Terrain Avoidance (E); 2.5.1 Awareness & flight path proximity (E)

F2.5A Unaware of Tran, Hand, (1) UNDETECTED – Controlled flight into terrain (1) Catastrophic Assumes TO and Land covered by functions
surrounding terrain Tran S, Sens, DETECTED – climb to safe height and divert 2.4 – ensure no combined functionality /
App, Rel common mode failure
F2.5B Unaware of proximity of Tran, Hand, (1) UNDETECTED - CFIT (1) Catastrophic
surrounding terrain to Tran S, Sens,
flight path App, Rel
F2.5C Terrain proximity Tran, Hand, (1) UNDETECTED – Steep Terrain encroaches into safe (1) Catastrophic May be a cause for F2.5B – system believes
determined at low Tran S, Sens, maneuvering zone – as F2.5G terrain separation terrain is being monitored, unaware of
sampling rate App, Rel (minimum) not maintained. In extreme, CFIT as F2.5B deficiency in measurements
F2.5D Incorrect surrounding Tran, Hand, Causes F2.5G, F2.5K, F2.5M (terrain separation (caused by F2.1D positional inaccuracy, or
terrain determined Tran S, Sens, breached; emergency evasion not triggered; emergency F2.2D incorrect mission data elements)
App, Rel evasion triggered unnecessarily)
Knock-on for Rel UAV could be loss of data link for Sens
UAV
F2.5E Incorrect distance to Tran, Hand, (causes F2.5M emergency evasion triggered when not
terrain determined – Tran S, Sens, necessary)
lower than actual App, Rel

D-35
 FFA Failure Condition Flight Effect of Failure Condition - (1) AW; (2) ATM Classification Justification
ID Phases
F2.5F Incorrect distance to Tran, Hand, (causes F2.5G, F2.5K)
terrain determined – Tran S, Sens,
higher than actual App, Rel
4. Manage Datalink (I); 4.2 Control Datalink path (I); 4.2.1 Handover to next GCS (I)(F)
Classification of datalink functional failures is critically dependent on level of autonomy of UAV in event of failure, in reaching a safe outcome.

F4.2A Datalink control cannot Hand (1) Detected: maintain control with current datalink, keep (1) Minor Mitigating functions – confirm no possibility of
hand over from current UAV within GCS range common mode failures
to next GCS UNDETECTED: function 4.1.1 should determine falling
signal strength. If not, potential for datalink fail emergency
actions – see function 4.3
nd
F4.2B Datalink attempts TO A, TO F, Detected: if there is a 2 GCS in range, then OK; if there
control hand over from Land A, Land is not, then as F4.2C
st
current GCS without F, Tran, Hand, UNDETECTED: 1 GCS sees loss of datalink without
demand Tran S, Sens, expected emergency action (i.e. expects function 4.3, but
App, Rel effect is as F4.2D)
F4.2C Datalink control hand Hand As F4.2A if 1st GCS retains control; as F4.2G if 1st GCS
over from current GCS, loses control
but next GCS unable to
take control
F4.2D Datalink control hand Hand (1) UNDETECTED: potential for CFIT, but UAV should As for the most [See F1.4A for discussion of manual control]
over from current GCS, follow current mission plan until manual control required severe of other
but next GCS unaware (as F1.4A, F1.4D) functions 1-10:
it has control (2) UNDETECTED: potential for controlled airspace (1) Catastrophic
infringement (F (2) Severity 1
F4.2E Datalink control taken Hand , TO A, (2) Current GCS sees effect as loss of datalink, without (2) Severity 4 UAV maintained in safe control by 2nd GCS,
over by next GCS, TO F, Land A, appropriate emergency action. Unnecessary ATM unknown to 1st GCS
without current GCS Land F, Tran, emergency actions initiated
being aware Hand, Tran S,
Sens, App, Rel
F4.2F Datalink control hand Hand (as F1.4D conflicting authority between GCS manual (1) Catastrophic DETECTED – assumes GCSs have inter-
over to next GCS, but controls) (2) Severity 1 communication, independent of the UAV
current GCS also
retains control (dual UNDETECTED – MS7(a) emergency landing
control) scenario (low altitude) indicates lack of full
control may lead to uncontrolled crash in
villages rather than controlled emergency
landing in clear unpopulated area

D-36
 FFA Failure Condition Flight Effect of Failure Condition - (1) AW; (2) ATM Classification Justification
ID Phases
F4.2G Datalink attempted Hand (function 4.3 should take effect – emergency actions in
control hand over to event of data link fail / degradation)
next GCS, but neither
GCS retains control
4.3 Datalink Fail / Degrade Emergency Action (I)
(see function 7.3.1 for divert function failures)

F4.3A D/L fail action (hold TO A, TO F, IF UAV does not take necessary autonomous action, then No action: (1) No action - Represents a failure of a critical
then divert) not taken Land A, Land effect as F4.3C Catastrophic autonomous response, to get the UAV down
when required F, Tran, Hand, IF UAV continues on its pre-planned path but without safely in event of D/L failure
Tran S, Sens, diverting, may cause concern to ATM (prolonged exposure Continues pre- Continue previous action – degrades ATM
App, Rel to UAV without manned override capability) but should act planned actions: safety, but continuing autonomy gets the UAV
safely if functional (2) Severity 3 down safely
F4.3B D/L fail action (hold TO A, TO F, (2) Nuisance action, causing ATM disruption (as F9.7E (2) Severity 3 Classified on basis of ATM disruption and
then divert) taken Land A, Land broadcast ‘datalink fail’ when not required), but no direct workload, with potential for ATM safety levels
without demand F, Tran, Hand, safety effect overall to be degraded during the emergency
Tran S, Sens, activity.
App, Rel
F4.3C D/L fail action partially TO A, TO F, (1) If D/L not re-established, UAV will eventually run out of (1) Catastrophic (Implementation dependent hazard)
taken – UAV remains in Land A, Land fuel and crash land Represents a failure of a critical autonomous
hold F, Tran, Hand, response, to get the UAV down safely in event
Tran S, Sens, of D/L failure
App, Rel
F4.3D D/L fail action partially TO A, TO F, (2) UAV loses opportunity to re-establish D/L, but should (Implementation dependent hazard)
taken – UAV diverts Land A, Land follow divert function safely – see function 7.3.1 Assumes UAV has autonomous safe response
immediately F, Tran, Hand, in case of D/L failure
Tran S, Sens,
App, Rel
F4.3E D/L fail action partially TO A, TO F, [see function 9.7]
taken – D/L fail Land A, Land
broadcast not issued F, Tran, Hand,
Tran S, Sens,
App, Rel
9. Manage Communications (E); 9.7 Emergency Broadcast Actions (E) (Coll aware fail; D/L fail; Mayday)

F9.7A Unable to broadcast – TO A, TO F, (2) Failures under F10 for Collision avoidance system, (2) Severity 1 [see functions 10, Collision Avoidance, for
“Collision Avoidance Tran, Hand, following function 7.3.1 to divert would be UNDETECTED safety-related functions where this function is
Fail” Tran S, Sens, by ATM and other air traffic – they would proceed as if intended as mitigation]
App, Land A, UAV would respect Rules of the Air, in extreme allowing
Land F, Rel collision

D-37
 FFA Failure Condition Flight Effect of Failure Condition - (1) AW; (2) ATM Classification Justification
ID Phases
F9.7B Unable to broadcast – TO A, TO F, (2) Failures under F4.3 for datalink, requiring function (2) Severity 3 [Assumes that UAV autonomous divert
Data Link Fail Tran, Hand, 7.3.1 to divert, would be UNDETECTED by ATM and other remains functional, and collision avoidance
Tran S, Sens, air traffic. Provided Collision Avoidance still active, UAV system functionality – need to establish
App, Land A, should make its way safely to diversion, but possibly independence from data link failure]
Land F, Rel cause consternation to ATM if route changes Assumes that function 2.7 Controlled Airspace
unexpectedly (and especially through controlled airspace). avoidance not functioning, hence allowing
Could cause air traffic to deviate from their intended incursion.
clearance (as collision avoidance is a later stage of traffic ATM criteria assume that air traffic may be
separation) forced to change course, as UAV follows ‘right
of way’ as if in general airspace, but collision
avoidance system maintains at least half-
required separation minima.
F9.7C Unable to broadcast – TO A, TO F, (2) Failures requiring function 7.3.2 Emergency Landing (2) Severity 1 Classified as severity 1, on basis that it could
Mayday Tran, Hand, would be UNDETECTED by ATM and other air traffic. make a bad situation (Severity 2) much worse
Tran S, Sens, Controlled emergency landing would not be affected, but by not being able to send assistance rapidly to
App, Land A, could affect ability of ATM to alert emergency services to the scene.
Land F, Rel the site. [Difficult to classify, with criteria as listed]
F9.7D Broadcast ‘Collision TO A, TO F, (2) Nuisance warning causes ATM to alert / redirect other (2) Severity 3 Classified as such on basis of upheaval to
awareness fail’ when Tran, Hand, air traffic unnecessarily. Overall affect on safety low, as ATM, possibly causing degraded safety of the
not required Tran S, Sens, systems still operational ATM overall in having to redirect aircraft ‘ad
App, Land A, hoc’ to avoid UAV locality
Land F, Rel
F9.7E Broadcast ‘Data Link TO A, TO F, (2) Nuisance warning causes ATM to alert / redirect other (2) Severity 3 Classified as such on basis of upheaval to
fail’ when not required Tran, Hand, air traffic unnecessarily. Overall affect on safety low, as ATM, possibly causing degraded safety of the
Tran S, Sens, systems still operational ATM overall in having to redirect aircraft ‘ad
App, Land A, hoc’ to avoid UAV locality
Land F, Rel
F9.7F Broadcast ‘Mayday’ TO A, TO F, (2) Nuisance warning causes ATM to alert / redirect other (2) Severity 3 Classified as such on basis of upheaval to
when not required Tran, Hand, air traffic unnecessarily. Overall affect on safety low, as ATM, possibly causing degraded safety of the
Tran S, Sens, systems still operational ATM overall in having to redirect aircraft ‘ad
App, Land A, hoc’ to avoid UAV locality
Land F, Rel
F9.7G Broadcast incorrect TO A, TO F, (2) If intent is to divert, but ‘mayday’ broadcast, then as
emergency message Tran, Hand, F9.7A and B.
compared to that Tran S, Sens, If intent is to make emergency landing, but ‘divert’ type
actually required App, Land A, message broadcast, then as F9.7C
Land F, Rel

D-38
Scenarios for Effects Consideration

(1) Consider broad effects of environment and emergency configurations

(2) Consider the following graphical mini-scenarios (appended to route plan maps):
• MS1 – Routine take-off from Aberporth and transit danger area
• MS2 – Airspace pinch point, between floor of Airway B3 (3500ft) and above Liv
HPZ (2000ft) (over gas rigs)
• MS3 – GCS handover, 20nm band where Aberporth GCS and Spadeadam GCS
both have datalink range
• MS4 – UAV Relay duty, in area between Colwyn Bay and Liv HPZ
• MS5 – Emergency Recovery, under Daventry CTA divert into Calton Moor military
airfield (next to E Mids CTA)
• MS6 – Airmanship conflict, to maintain separation under Man TMA (3500ft) forces
flight below safe altitude over terrain + mast (2490ft)
• MS7(a) – Emergency landing, East of Burnley, from low altitude (2800ft due to
Man TMA)
• MS7(b) – Emergency landing, Teesdale, from high altitude (6000ft) but over steep
terrain and valleys
• MS8 – Routine approach and landing into Aberporth, coming in over terrain, wind
farms and villages

D-39
 ANNEX E
SWIFT ASSESSMENT FOR COMPARISON (EXTRACT
OF HAZARDS)

E-1
This annex provides the summarised results of a Structured What If Technique (SWIFT)
hazard identification of the Guard Dog case study.
SWIFT was applied in ‘quick and dirty’ fashion by a group of 3 safety engineers with UAV
assessment experience, independently from the Functional Failure Analysis carried out to
apply the method defined in the body of this report. The intent was to provide a cross-check
of hazards, to determine how well the FFA had identified hazards and whether, overall, there
were still hazards left unidentified by either method. The evaluation of the two methods is
covered in section 3.3 of the report.
The results of the SWIFT are shown below, along with an indication where the FFA may
have identified the same / similar hazard.
Table E(i) – SWIFT hazards identified for Guard Dog case study
SWIFT ID What If / Hazard indicated Comment w.r.t. FFA
UAVS level Comparable
assessment Hazard
Pre-flight / launch (up
to and including
engine start)
S1 Manual handling Ground hazard -
OHSA
S2 Incorrect assembly Causal – FTA or
system FHA
S3 Undetected prior damage Causal – FTA
S4 Miss-matched program / mission A63
S5 Corrupted mission data A18
S6 Incorrect fuel-type / mixture A67
S7 Incomplete program / mission A18
S8 Incorrect fuel load A65
S9 Inadequate pre-flight checks A69
S10 Fuel fire Particular Risk
Analysis
S11 Electrocution by electrics Ground hazard -
OHSA
S12 Propeller strike Ground hazard –
OHSA
S13 Inadvertent launch
S14 Uncontained engine failure Particular Risk
Analysis
S15 Poor launch site information A22
(incomplete recce)
S16 Structural failure of pneumatics Causal – FTA or
(of launcher) system FHA
Launch (field take off)
to clear of launch
S17 Unable to reach launch velocity A12
S18 Unable to reach controlled flight A12, A1, A2
S19 Structural break up A7
S20 Obstacle clearance A22, A14
S21 Launch out of wind limits A24
S22 Engine failure A14, A6
S23 Flight control system failure A1, A2, A3
S24 Incorrect flight mode A8, A9
(autonomous or manual control)
Airfield launch (As above plus:)
S25 Poor preparation of launch site
(inadequate runway quality)

E-2
SWIFT ID What If / Hazard indicated Comment w.r.t. FFA
UAVS level Comparable
assessment Hazard
Flight
S26 Deviation from flight plan A21
S27 Flight into controlled airspace A28
(when not allowed)
S28 Avionics failure (e.g. Nav system) A15
S29 Loss of positional information A51
from UAV to GCS
S30 Failure of transponder A75, A76
S31 Low Radar signature A74
S32 Bird strike Causal – FTA or
system FHA
S33 EMC / EMI from transmission A42
masts
S34 General Aviation threat (collision A83, A84
avoidance system malfunctions)
S35 Weather extremes (e.g. lightning, A55
turbulence etc)
S36 Icing A55
S37 Loss of power supply to GCS Causal – FTA or
system FHA
S38 Incorrect / corrupted signal from Causal – FTA or
GCS system FHA
S39 Unable to handover to next GCS A40
S40 Unable to relay info to furthest A44
UAV
S41 Loss of GCS communications
S42 Loss of GPS A15
S43 RF Radiation Hazard to GCS Ground hazard –
occupants OHSA
S44 Uncommanded collision A85
avoidance
S45 Digital terrain / obstacle database A64
not current
S46 Loss of communications with ATC A71, A73
S47 Failure to respect VFR / IFR rules A56
S48 Pilot fatigue (long endurance
shifts)
S49 Flying 2 UAVs and inadvertently Causal – FTA or
commanding the wrong one system FHA
S50 Spurious system monitoring A59
signal from UAV to GCS
S51 Lasing / identifying the wrong Ground hazard -
target OHSA
S52 EMI between UAVS internal Causal – FTA or
systems system FHA
S53 Incompetent pilot Causal – FTA or
system FHA
S54 Security risk – control by terrorist A48
S55 Flight into aircraft wake A86
S56 Navigation visibility lights failure A87
Approach and
Landing
S57 Approach / land too fast A23, A6
S58 Approach / land too slow A23, A6
S59 Approach / land too high A23, A14

E-3
SWIFT ID What If / Hazard indicated Comment w.r.t. FFA
UAVS level Comparable
assessment Hazard
S60 Approach / land too low A23, A14
S61 Incorrectly aligned with runway A23, A24
S62 Landing out of wind limits A24
S63 Terrain masking during approach A50
S64 Loss of control after landing A31, A32, A33,
(speed or direction) A34
Maintenance
S65 COSHH assessment Ground hazard –
OHSA
S66 Maintenance error Causal – FTA or
system FHA
S67 Lack of maintenance policy / Procedural,
philosophy regulatory
S68 Radiation hazards Ground hazard –
OHSA
S69 Electrical hazards Ground hazard –
OHSA
S70 Stored energy Ground hazard –
OHSA
S71 Inadequate in-service support Procedural,
e.g. logistics, airworthiness, regulatory
configuration control, spares
S72 Incompetent maintainers Procedural,
regulatory
S73 Disposal aspects Ground hazard -
OHSA
Emergency Actions
S74 Incursion into airspace A30
S75 Crash landing A60, A61
S76 Datalink Out of range A46
S77 Diversion A57

E-4
 ANNEX F
LISTING OF HAZARDS FOR INTEGRATION OF UAVS
INTO UNSEGREGATED AIRSPACE (FROM TUAV
CASE STUDY)

F-1
This annex provides the summarised hazard listing, after review of the FHA results from
applying the modified ARP4761 method to the Guard Dog case study.
The results are, obviously, based on a specific consideration, but the case study was
intended to be a generic Tactical UAVS (TUAVS), so there should be good read across to
other TUAVS applications and, perhaps, fair read across to broader UAVS types. It is
suggested that there is enough read across for the list to provide a ‘starter’ for other systems,
to be added to by more specific application of the proposed HazID method.
The listing also indicates where there is commonality with the hazards identified using the
SWIFT analysis (see Annex E to this report).

Table F(i) –Hazards identified for Guard Dog case study, using the proposed
modifications to ARP4761 FHA technique
ID UAVS Hazard indicated Relating to UAVS Relating to
FHA Functional SWIFT
Failures Comparable
Hazard
A1 Flight control instability F1.1-, F1.2-, F1.5A S18, S23
A2 Inability to control (external) perturbations F1.2A S23
A3 Inability to manoeuvre / maintain UAV on required F1.3-, F1.6O-R, F2.3- S23, S26
flight path , F6.5B
A4 Flight instrumentation (attitude and speed) errors F1.1-

A5 Inability to identify flight instrumentation errors [derived from F2.1-

and assessment of
effects - detected and
undetected]
A6 Inability to achieve, maintain and control required F1.6- S22, S57, S58
airspeed
A7 Lack of structural integrity F1.3H, F1.5D S19
A8 Unable to take manual control of the UAV (UAV-p) F1.4A S24

A9 Unable to transfer to autonomous UAV control F1.4B

A10 Conflicting authority between UAV controllers (manual F1.4C,D, F4.2F
/ autonomous) (different ground controllers)

A11 Control mode error (where control laws differ with F1.5C
phase of flight)
A12 Launcher fails to provide correct take-off speed F1.5B S17, S18
A13 Asymmetric thrust / power F1.6E
A14 Unable to achieve / maintain / control required altitude F1.6- S20, S22
or rate
A15 Navigation instrumentation errors (altitude, position, F2.1 S28, S42
heading; for general air navigation)
A16 High accuracy navigation instrumentation errors F2.4C-AB
(altitude, position, heading; for taxi, take off, approach,
landing)
A17 Inability to identify navigation instrumentation errors F2.1-

A18 Planned mission route stored with errors F2.2- S5, S7

A19 Planned mission route not achievable by UAVS (not F2.2F, F6.5B, F6.5N,
capable within performance) F8.1I

F-2
ID UAVS Hazard indicated Relating to UAVS Relating to
FHA Functional SWIFT
Failures Comparable
Hazard
A20 Planned mission route not safe (by Rules of the Air) F2.2G

A21 UAV deviates from planned route without correction F2.3- S26

A22 Correct airfield and runway take-off and climb-out F2.4A-F S15, S20
pattern data not used
A23 Correct airfield and runway approach, hold, circuit and F2.4R-X S57, S58, S61
landing data not used
A24 Inability to determine correct wind-speed and direction F2.4AC-AG S21, S62
in relation to runway (take-off or landing)
A25 Minimum terrain separation (i.a.w. Rules of the Air) not F2.5A-O
maintained
A26 Terrain separation / emergency evasion triggered F2.5M
when not required / appropriate
A27 Separation from sensitive areas (danger areas / F2.6-, F2.8-
populated areas / NOTAMS areas) not maintained

A28 Separation from controlled airspace not maintained F2.7- S27, S75
(when not equipped / cleared for controlled airspace
operations)
A29 Incorrect type / identifier of controlled airspace [outside scope of
determined (if cleared for controlled airspace TUAV case study, but
operations) extrapolated

A30 Incorrect emergency incursion action taken (for ROA) F2.7I,J S74
if controlled airspace entered in error
A31 Inability to control ground speed F3.1A-J S64
A32 Excessive braking when not required F3.1N, F3.1R S64
A33 Asymmetric braking F3.1T S64
A34 Inability to provide controlled ground steering F3.2A-J S64
A35 Incorrect airfield layout / ground taxi route determined F3.2K-Q

A36 Inability to determine ground / air transition clearly F3.2R-V

A37 Unable to correctly determine position of fixed / mobile F3.2W-AC

ground obstacles
A38 Inability to accurately determine command datalink F4.1A-E
signal strength
A39 Incorrect status of command datalink system F4.1F-K
serviceability determined
A40 Command datalink lost during attempt to hand over F4.2A-G S39
between GCS stations
A41 Command datalink handed to GCS, but GCS unaware F4.2D
it has control
A42 Command Datalink suffers from EMI 'cross talk' with F4.2K,R S33
other RF traffic
A43 Command datalink lags via satellite / relay F4.2M,U
A44 Command datalink drop outs via satellite / relay F4.2L,N,T,V S40

F-3
ID UAVS Hazard indicated Relating to UAVS Relating to
FHA Functional SWIFT
Failures Comparable
Hazard
A45 satellite / relay UAV passes control datalink F4.2Q
commands to incorrect UAV
A46 Failure to take correct emergency recovery action if F4.3- S76
command datalink fails
A47 Command Datalink jammed F4.4A
A48 Command Datalink stolen F4.4B S54
A49 Valid command datalink rejected as jammed / stolen F4.4C

A50 Inability to accurately determine terrain proximity to F4.5- S63

command datalink line of sight
A51 Inability to telemeter accurate UAV parameters F6.1-,F6.2-,F6.3- S29
(control parameters, navigation parameters, flight ,F6.4-
system status) to GCS
A52 Inability to monitor initial / changing weather conditions F6.5A-J, F8.1AC-AG
along the mission route
A53 Bad weather re-routing infringes sensitive airspace / F6.5Q
overflown areas
A54 Bad weather re-routing exceeds UAV capability F6.5P
(performance)
A55 Weather effects on UAV - icing, precipitation, dust, [implied from S35, S36
sand functional
consideration to avoid
bad weather and
F6.5M,O]
A56 UAV flight in reduced visibility / IFR conditions [implied from S46
functional
consideration to avoid
bad weather and
F6.5M,O]
A57 Unable to determine a valid diversionary airfield (for F6.5K,L,R-V S77
emergency / bad weather recovery)
A58 Diversionary airfield / route not communicated F6.5W,X
between UAV and GCS (UAV not aware of
appropriate action to take, or GCS not aware what
action the UAV will take)
A59 Unable to accurately determine the status of critical F7.1- S50
flight systems
A60 Incorrect emergency action taken - no action / divert / F7.3A-K S75
emergency landing
A61 Emergency landing attempted in populated area F7.3L S75
A62 GCS moding initiates ground mode displays and F8.1C
controls (e.g. mission planning), when in flight
monitoring / control required
A63 Incorrect mission plan completed / loaded F8.1A-H S4
A64 Incomplete / incorrect supporting data available for F8.1K-AB S45
mission planning (e.g. HIRF locations, terrain, danger
areas, controlled airspace)
A65 Consumables not fully refuelled / recharged prior to F8.2A,D S8
take-off / launch

F-4
ID UAVS Hazard indicated Relating to UAVS Relating to
FHA Functional SWIFT
Failures Comparable
Hazard
A66 Consumables still being refuelled / recharged at F8.2B S13
launch (or other inappropriate flight phase)
A67 Consumables refuelled / recharged with incorrect or F8.2E,F S6
contaminated materials
A68 UAV centre of gravity adversely affected by fuel F8.2G
charge
A69 pre-flight systems test returns incomplete / incorrect F8.2H-N S9
system status
A70 Different mission plans loaded - UAV; relay UAV; first F8.2U-X
GCS; other GCS in mission
A71 Inability to correctly understand and reply to airfield F9.1-, F9.5- S46
ATC communications
A72 inability to correctly detect, interpret and respect F9.2-
airfield visual signals
A73 Inability to correctly understand and reply to en-route F9.3-, F9.5- S46
ATC communications (e.g. advisory Flight Information
Service)
A74 UAV poor Radar visibility for tracking by ATC F9.4B,C S31
A75 Transponder failure to squawk or squawks incorrect F9.4A,D-F S30
identifier
A76 Transponder returns incorrect altitude to ATC (if Mode F9.4G S30
S / Mode C)
A77 Radio frequency changed in error (e.g. to emergency F9.5-
frequency)
A78 UAV does not correctly comply with Airfield ATC F9.6-
procedures: ground movement (clearance & direction);
enter runway; take-off; climb out direction and final
height; approach direction; circuit direction; runway
allocation; hold height & direction; landing clearance;
exit runway clearance

A79 UAV does not correctly comply with en-route airspace F9.6-
ATC procedures: Climb / descend and final cruising
altitude; heading change; hold position, height and
direction; diversion
A80 UAV complies with Airfield or En-route ATC procedure F9.6C
intended for another aircraft
A81 Unable to correctly broadcast emergency message: F9.7A-G
“Collision Avoidance Fail”; Data link fail"; "Mayday"

A82 Emergency broadcast made when none necessary F9.7D-F

A83 Inability to maintain correct, normal traffic separation , F10.1-, F10.2-, F10.3- S34
i.a.w. Rules of the Air 'Right of Way'
A84 Inability to carry out appropriate emergency evasive F10.4A-D S34
manoeuvre for collision avoidance
A85 Collision avoidance emergency evasion manoeuvre F10.4C S44
carried out when not appropriate

F-5
ID UAVS Hazard indicated Relating to UAVS Relating to
FHA Functional SWIFT
Failures Comparable
Hazard
A86 UAV susceptibility to wake turbulence from other F10.4E S55
aircraft
A87 UAV inconspicuous to other aircraft by RF or visual F10.5A-D S56
means (all round visibility, or when viewed from
particular aspects)
A88 UAV resembles other aircraft types of different size or F10.5E
performance

F-6