Professional Documents
Culture Documents
Andrew R Evans
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
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!
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.
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.
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.
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.
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.
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.
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].
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.
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.
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.
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.
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).
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
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.
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.
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.
30
requirement in [CAA04]) require security of systems to detect and counter all attempts
to corrupt critical systems and data before / during / after loading.
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.
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.
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 **.
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.
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 .
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?
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.
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].
o The extended critical boundary (for elements such as the Ground Control System
(GCS) and mission planning?).
o The people and procedural elements.
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).
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.
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.
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:
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).
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.
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])
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.
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.
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):
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:
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
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:
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.
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.
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.
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.
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. 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.
Currently, it is proposed that the guidance within ARP 4761 will be suitable for UAVS
application, for this aspect.
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.
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
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).
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
manual
Override -
NEC
remote
Control
piloting
Datalink Path
Monitor Via Satellite?
Mission Manage
Progress DataLink
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
2.6 Sensitive
2.5 Terrain Area Avoidance
Avoidance (E) (Danger &
Populated
areas) (E) - as
2.6.1-3
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
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?
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)
Broadcast
Collision
Avoidance fail
STOP &
Broadcast
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.
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
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.
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.
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:
This suggests that the FFA has identified about 90% of the total hazards for manned /
unmanned aircraft integration.
Four SWIFT hazards remain that cannot be explained in this way, and these are shown
below.
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:
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.
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
Table 4.1.2(i) – Satisfaction matrix for development of HazID methodology
Requirement (Section 2.1) Proposed design solution Evaluation
Safety Objectives -
Reflect airworthiness safety UAVS Airworthiness failure condition severities Application of airworthiness safety criteria was straightforward (3.2.5 –
criteria descriptions related to (Section 2.2.1 - Table 2.2.1(i)) ‘classification of failure effects)
UAV potential occurrences;
Reflect UAV variety (in Derive UAV kinetic equivalence (based on Annex Derivation of airworthiness safety objectives was straightforward.
lethality); B); compare with aircraft classes in Table (3.2.1)
2.2.1(iii); hence determine probability objectives.
(2.2.1)
Reflect ‘Total safety’ threats Dual-criteria system: Airworthiness criteria (as Consideration against duel criteria was straightforward. Application of
through ATM / operating above) plus ATM-focussed separation / collision ATM separation safety criteria was easy in most occasions with a few
occurrences safety criteria (2.2.1 – Table 2.2.1(ii) exceptions. Most failures analysed had duel airworthiness / ATM effect
(3.2.5)
FHA-levels –
Address the (internal) Extend ‘Aircraft-level FHA’ to become ‘UAVS- UAVS-level FHA was effective in identifying system inter-relations for
complexity of the system; level FHA’ (2.2.2) subsequent analysis (3.2.3)
Address the external interfaces Rich Context Diagram to draw out interactions Rich Context Diagram proved very useful in identifying SoS
of the SoS. between UAVS and the wider SoS. (2.2.2) interactions. The application would have been improved in practice
with stakeholder review. (3.2.2)
Function Identification –
Source data requirements to Additions: URD or specification; Simple design / No URD or formal documentation available to assess. However,
cover the complex UAVS architecture representation; Rich Context simple Case Study documentation proved quite effective. (3.2.3)
structure and interfaces; Diagram; simple Concept of Operations. (2.2.3)
Internal Functions list to reflect Consider UAVS functions overall; Consider Simple design architecture diagram was useful to identify system
UAVS structure; functions determined by the UAVS internal elements – helpful to take ‘views’ on each element to derive internal
structure (behaviour, control, information, utility); functions. Flight phases helped to identify additional functions. (3.2.3)
Consider the effects of Flight Phases. (2.2.3)
Exchanged Functions list to Consider each Rich Context Diagram interaction Rich Context Diagram very good at drawing out interactions – each
reflect the wider System of for implied functions on the UAVS (behaviour, was then assessed for exchanged functions. Could find no need to
Systems; control, information, utility). (2.2.3) keep Internal and Exchanged functions list separate, so they were
consolidated into a common Functions Tree. (3.2.3)
81
Requirement (Section 2.1) Proposed design solution Evaluation
Additional functions were needed for key emergency conditions – this
required an initial definition of emergency procedures. (3.2.4)
Flight Phases to reflect UAVS Review mission types and parameters to identify Derivation and consideration of flight phases was a useful ‘mind jogger’
mission complexity & variety the various flight phases. (2.2.3) for additional functions. (3.2.3)
Identification of Failure Conditions –
Expansion on UAVS Review UAVS domains: Weather; Overflown Domain review list provided a good structure for derivation. Non-
environmental conditions; terrain; Electrical; Mission; Air Traffic specification aspects required care: here, definition of mission
environment. May use scenarios (see ‘Identifying scenarios proved useful. (3.2.4)
and managing …’ below). (2.2.4)
Expansion on UAVS Revised ‘starter list’ suggested. (2.2.4) Review of list highlighted need for additional, emergency functions (see
emergency configurations above). (3.2.4)
- Failure condition determination: Not UAVS FFA structure worked well. Care was needed with: pseudo-continuous
specific, but FFA structure proposed as good functions; implied sub-functions; functions crossing system boundaries.
practice, considering: function not provided; (3.2.4)
provided when not required; incorrect operation of
function. (2.2.4)
Ensure credible combinations Assessment of initial design architecture for Inherently built-in by setting up specific functions, expected in the event
of multiple functional failures common causes; Assessment where operation of of a system failure; mitigating function in an emergency. These were
are considered. a function mitigates another, critical functional then analysed for additional failures.
failure.
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’)
Identifying and managing the effects of failure conditions –
Establish significance of the Expanded consideration of mission, Established context information was adequate for most failures
UAVS mission, environmental environmental range and ATM environment built- analysed (as expected).
and ATM context in evaluating in to establishing functions (see above);
Some complex effects were analysed against scenarios: text-based
consequences
Use of scenarios for complex situations, including scenarios were not effective; graphical mission scenarios worked well
environment, mission, airspace context. (2.2.5) to present mission, terrain and ATM information and allow ‘what-ifs’.
(3.2.5 – ‘use of scenarios…’)
82
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.
83
• Public perception of UAV safety
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.
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
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.
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'.
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
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.
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.
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).
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.
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?
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.
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.
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.
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.
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 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)
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
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;
C-3
[TCAS not included on grounds of weight and no intent of using
controlled airspace]
TacU
• Positioned with field commanders, can obtain payload data direct from
UAV.
• Limited control of UAV payload sensors, to optimise data collection.
NEC
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.
• 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]
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.
D-3
ATM Separation / Collision based 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
[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?
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)
Broadcast
Collision
Avoidance fail
STOP &
Broadcast
D-8
System interactions view [See Individual function maps for each system element] – Derived from initial design assumptions over system elements and
interactions
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
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
manual
Override -
NEC
remote
Control
piloting
Datalink Path
Monitor Via Satellite?
Mission Manage
Progress DataLink
D-10
Data
download /
storage
Distribute
payload data
Sensor / Data
requests
NEC
Launch UAV
Pre Flight
preparations Locate UAV
Refuel /
recharge
consumables
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
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?
HIRF Sources Direct EM Interference with UAVS > [Non Functional Requirement]
Non-Cooperative Air < Detect traffic and sense relative track Collision avoidance – detect traffic – non co-
Traffic (Class F-G op; co-op.
Airspace)
Determine traffic relative track
< Maintain separation (normal action Maintain traffic separation (ROA)
according to Rules of the Air)
< Emergency Collision avoidance (evasion) Collision Emergency evasion
See and avoid > Conspicuity to air traffic (visual, RF)
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
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
2.6 Sensitive
2.5 Terrain Area Avoidance
Avoidance (E) (Danger &
Populated
areas) (E) - as
2.6.1-3
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
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.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)
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)
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.7 Emergency
Broadcast
actions (E)
D-17
FAILURE ANALYSIS
Failure Condition (Hazard Description) – (a) Loss of Function; (b) Uncommanded Function; (c)
Incorrect Function
Failure Conditions
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
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
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)
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
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)
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
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
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-
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-
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
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
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"
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