THE HAZARDS OF UNMANNED AIR VEHICLE INTEGRATION INTO UNSEGREGATED AIRSPACE Andrew R Evans
This report is submitted to satisfy the project requirements of the Master of Science in Safety Critical Systems Engineering at the Department of Computer Science
September 2006
Number of words = 43,176, as indicated by the Microsoft Word ‘word count’ tool. The count includes the title page, preliminaries, report body, and Annex F, but not the Bibliography. Annexes A – E contain supporting evidence and contextual information for the reader, and have not been included in the word count.
ABSTRACT There is strong interest in expanding Unmanned Air Vehicle Systems (UAVS) usage. Potential military and civil tasks will need them to operate in the same airspace as manned aircraft and over the general public. While they are currently segregated because of concerns for safety, what are the real safety risks and can they be addressed? A broad literature review has highlighted a range of safety-related issues. In particular: •
The root hazards associated with UAVS integration are not well understood.
• Can a EASA CS.23/25.1309 type safety assessment approach be taken, to identify the hazards and support clearance into unsegregated airspace? A hazard identification methodology has been developed based on ARP4761 (an accepted framework for satisfying EASA CS.23/25.1309). Functional Hazard Assessment (FHA) elements have been modified to be UAVS-applicable, with a UAVS-level assessment, consideration of the wider system of systems, and techniques to draw out UAVS peculiarities. The method has been applied to a Tactical UAVS case study to derive a hazard listing. The project has concluded that: • There are a broad range of safety issues to be overcome, to allow UAVS integration into unsegregated airspace – some relating to the differences of UAVS as ‘disruptive technology’; others to the manned airspace environment struggling to accommodate UAVS. • The hazard identification method developed provides a strong supplement to ARP4761, allowing the combined framework to be used for UAVS safety assessment. • In the test application, the method identified around 90% of hazards related to integrating UAVS into unsegregated airspace. This should improve further in a real application, through peer review, stakeholder involvement, and the use of the follow-on safety assessment techniques that make up ARP4761.
i
ACKNOWLEDGMENTS The completion of this project would not have been possible, without the support of many people. I would like to thank Peter Moores and JRA Aerospace Ltd, for their support and sponsorship; and my JRA colleagues Dan Warnes and Mike Shilling for acting as ‘sounding boards’ (or sounding bored?) of my developing ideas. I would like to thank my project supervisor, Mark Nicholson, for his guidance, advice and humour throughout the conduct of the project. I would like to thank Patrick Mana and Mike Strong (EUROCONTROL) for their advice on Air Traffic Management approaches to safety and Unmanned Air Vehicles. I would like to thank the many people of the UAVS industry with whom I had discussions – too many to mention in full, but a few key personalities being Dr Sue Wolfe (Parc Aberporth), Andre Clot and Mike Lake (the UAVS Association), and Ingo Massey (Remote Aviation Ltd) – their unwavering enthusiasm and belief that UAVs will become integrated with manned airspace was infectious. Finally, I would like to thank my wife, Caroline, my family and friends for their love, support and preaf-rooding. Yes, I promise that I won’t do any more educational ‘challenges’. Well, for a long while, at least.
ii
TABLE OF CONTENTS Abstract...................................................................................................................................i Acknowledgments .................................................................................................................. ii Table of Contents .................................................................................................................. iii List of Tables..........................................................................................................................v List of Figures........................................................................................................................ vi Introduction ........................................................................................................................... 1 PART 1 – Literature Review .................................................................................................. 4 Overview of Unmanned Aerial Vehicle Systems............................................................. 4 Issues Relating to UAV Safety and Access to Integrated Airspace................................. 7 Note on UAV Classification ............................................................................................ 7 1.1 Safety Issues Relating to UAVs as 'Disruptive Technology'.......................................... 8 1.1.1 Impact of the Variety, Roles and Performance of UAVs......................................... 8 1.1.2 The complex system boundary for UAVs............................................................... 9 1.1.3 UAV autonomy - technology, predictability, complexity........................................ 11 1.1.4 Accident rates and reliability - UAV airworthiness................................................ 15 1.2 Safety Issues Relating to the Manned Airspace Environment 'Coming to Terms' with UAVs ............................................................................................................................... 18 1.2.1 Regulation, Certification and the Drive for Standards .......................................... 18 1.2.2 ATM interaction ................................................................................................... 23 1.2.3 Collision avoidance.............................................................................................. 27 1.2.4 Security and safety .............................................................................................. 30 1.2.5 The Human Element............................................................................................ 31 1.2.6 Public perception of UAV safety .......................................................................... 33 1.3 Summary of UAVS Safety Issues............................................................................... 35 PART 2 - Design and Build: Moving forward in UAVS HazID............................................... 40 2.1 Assessment of ARP4761 Usability for UAVS HazID................................................... 40 2.1.1
Introduction .................................................................................................... 40
2.1.2
Safety Objectives ........................................................................................... 40
2.1.3
'Aircraft Level' and 'System Level' FHA .......................................................... 41
2.1.4
FHA Process:................................................................................................. 41
2.1.5
Overall Applicability of ARP4761 for UAVS use.............................................. 42
2.2 Modifying ARP 4761 FHA for UAVS Use ................................................................... 43 2.2.1 Derivation of Safety Criteria and Objectives for UAVS Application....................... 43 2.2.2 FHA Levels to Address System Complexities ...................................................... 49 2.2.3 Function Identification.......................................................................................... 51 2.2.4 Identification and Description of Failure Conditions ............................................. 54 iii
2.2.5 Identifying and Managing the Effects of the Failure Conditions............................ 57 2.2.6 Summary of Amended FHA Process ................................................................... 59 PART 3 - Test and Evaluation ............................................................................................. 61 3.1 Test Methodology ...................................................................................................... 61 3.2 Evaluation of the Modified HazID Method through Trial Application ........................... 63 3.2.1 Derivation of Safety Criteria and Objectives for UAVS Application....................... 63 3.2.2 FHA Levels to Address System Complexities ...................................................... 64 3.2.3 Function Identification.......................................................................................... 65 3.2.4 Identification and Description of Failure Conditions ............................................. 67 3.2.5 Identifying and Managing the Effects of the Failure Conditions............................ 69 3.3 Evaluation of Hazards Identified by the Modified HazID Method ................................ 75 PART 4 – Conclusions and Further Work ............................................................................ 78 4.1 Findings, Related to Satisfaction of the Project's Aims............................................... 78 4.1.1
Identifying Current Concerns over UAVS Safety ............................................ 78
4.1.2 A Framework for Considering Safety Risks Related to Integrating Unmanned Vehicles into Unsegregated Airspace ........................................................................... 80 4.2 Recommendations for Further Work .......................................................................... 83 4.2.1
UAVS Safety, generally.................................................................................. 83
4.2.2 UAVS Hazard Identification Methodology and Application of ARP4761 Framework ................................................................................................................... 84 Bibliography ........................................................................................................................ 85 Abbreviations & Acronyms................................................................................................... 88 Annex A Review of ARP 4761, to support ARP 4758, CS 25.1309 etc for UAV application…………………………………………………………………………………………. A-1 Annex B Extract from [CAA02] - A Method for Setting Design Standards for New Kinds of Aircraft, Including Unmanned Air Vehicles……………………………………………………..B-1 Annex C 'Guard Dog' - generic TUAV Case Study……………………………………………C-1 Appendix C1 Guard Dog Mission Scenario (Coastal Route)………………………………..C-6 Appendix C2 Guard Dog Mission Scenario (Inland Route)…………………………………..C-7 Annex D FHA for 'Guard Dog' TUAV System (extracts)……………………………………...D-1 Annex E SWIFT Assessment for Comparison (extract of hazards)…………………………E-1 Annex F Listing of Hazards for Integration of UAVS into Unsegregated Airspace (From TUAV Case Study)……………………………………………………………………………………….F-1
iv
LIST OF TABLES Table 2.2.1(i) - Airworthiness Failure Condition Severities (after [SAE96], with additions from [UTF04] as noted) ..........................................................................................................................................44 Table 2.2.1(ii) - EUROCONTROL ATM-Focused Separation / Collision Safety Criteria (from [EUR04]) .........................................................................................................................................................46 Table 2.2.1(iii) - Airworthiness Safety Objectives - probabilities per Flying Hour (from [SAE96], drawn from [FAA88] and compared with [FAA99])........................................................................................48 Table 3.2.1(i) - Airworthiness Failure Condition Severities for ‘Guard Dog (drawn from Table 2.2.1(i))63 Table 3.2.4(i) – Example of ‘Loss of Function’ for pseudo-continuous function...................................68 Table 3.2.4(ii) – Example of ‘Uncommanded Function’ ......................................................................69 Table 3.2.4(iii) – Example of ‘Incorrect Function’ for a cross-system function .....................................69 Table 3.2.4(iv) – Example of failure identification for a warning function.............................................69 Table 3.2.5(i) Examples of analysis of the effects of failure conditions, from the ‘Guard Dog’ FFA.....70 Table 4.1.2(i) – Satisfaction matrix for development of HazID methodology .......................................81 Table A(i) - Safety Objective, from ARP 4761 (drawn in turn from CS.25.1309)……………….……..A-3 Table A(ii) - Severity Criteria as defined in ESARR4 by EUROCONTROL…………………….………A-4 Table D(i) - Airworthiness Failure Condition Severities (from Table 2.2.1(i))………………….………D-3 Table D(ii) - Airworthiness Safety Objectives…………………………………………………….………..D-3 Table D(iii) – ATM Separation / Collision Safety objectives…………………………………….………..D-4 Table D(iv) – Flight phases view of functions……………………………………………………….……D-12 Table D(v) – External interactions and derived UAVS functions………………………………….……D-14 Table D(vi) – Functional Failure Conditions for Guard Dog UAVS……………………………….……D-18 Table D(vii) – Failure Effects for (a selection of) Guard Dog failure conditions………………………D-30 Table E(i) – SWIFT hazards identified for Guard Dog case study………………………………………E-2 Table F(i) –Hazards identified for Guard Dog case study, using the proposed modifications to ARP4761 FHA technique…………………………………………………………………………………….F-2
v
LIST OF FIGURES Figure 1a - AQM-34 derivative showing the improving reliability of 'high end' UAV systems [Wes05] ...5 Figure 1b - Aerosonde Laima Crosses the Atlantic (taken from www.aa.washington.edu/research/afsl/background.shtml)...................................................................5 Figure 1c - Spectrum of current UAV military types [Wei04] .................................................................6 Figure 1.1.3a - Autonomy level variation with required flexibility of mission / environment and certainty of information....................................................................................................................................12 Figure 1.1.3b Optimising autonomy level to suit operator's [mission] needs .......................................12 Figure 1.1.3c varying the UAVS autonomy level to suit the required level of operator authority for a situation ............................................................................................................................................13 Figure 1.1.3d 'Agent' View of the UAVS assets and mission decision-making environment (for a multiUAV 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 framework as the main goal. Hence, while there are suggestions for a complete safety assessment framework for UAVS development, the project is not intended to provide a ‘one stop shop’ for the safety professional involved in UAVS assessment. It does not provide detailed safety analysis methods for further down the design and implementation path. The project is intended, however, to provide a robust start to such a safety assessment process, with a sound hazard identification methodology based on the civil standard of ARP 1
4761. It is noted that other forms of hazard identification do exist, and they might also prove UAVS-friendly, but this project has strived to ensure that the hazard identification method would be compatible with existing requirements of the regulatory bodies for civil aviation. Without their consensus, the safety assessment method will not support clearance into civil skies. ARP4761 is an accepted standard and, if it can be made UAVS-applicable, it can support civil clearance. In order to assess the hazard identification framework, a case study has been used, featuring a generic Tactical UAV System. This provides a good benchmark for the applicability of the method and the hazards it produces. However, as is discussed in section 1.1.1, UAVSs differ significantly in size, performance and role. Due to limitations of time, it has not been possible to assess the framework against all of these varieties. Instead, the Tactical UAVS was chosen as having broad applicability which may have significant read across to many of the other configurations. That said, the method should be reviewed for its applicability before its use with the more extreme configurations of UAVS. Report Structure and Layout This report presents the research, analysis, development, evaluation, conclusions and recommendations for the project and is structured as follows: • Part 1 presents the literature review. A broad review has been carried out, to establish the context for UAV Systems, and this provides an important introduction to the characteristics of such systems for those not overly familiar. The review then focusses on the safety-related issues, identifying those inherent in the UAVS as ‘disruptive technology’, and those due to the manned airspace environment trying to come to terms with that disruption. • Part 2 represents the ‘design and build’ activity for the project. Here, the ARP4761 civil safety assessment process is assessed for its UAVS applicability. Then, a hazard identification framework is derived, to address the identified gaps and hence provide a robust, UAVS-friendly methodology. • Part 3 assesses how robust the new hazard identification methodology is. The framework is evaluated using a Tactical UAV case study, and the results analysed for practicality of application and robustness of hazard identification. • Part 4 presents the conclusions and recommendations from the project, assessed against the project aims. It also suggests areas of potential further work, identified during the conduct of the project. The annexes to the report provide supplementary material as context and evidence for the main report body: • Annex A provides a more detailed review of ARP4761, used to derive the ‘design requirements’ for the UAVS-friendly Functional Hazard Assessment (FHA) hazard identification method. • Annex B provides an extract from a Civil Aviation Authority paper on a method for comparing UAVSs against manned aircraft, using kinetic energy criteria. This is used, in part, within the hazard identification method. • Annex C provides useful contextual information on the Tactical UAVS case study used throughout the project. • Annex D contains extracts from the results of applying the hazard identification methodology to the case study system. The full results could not be practically annexed due to document size, so elements have been extracted pertinent to the evaluation in Part 3.
2
• Annex E contains a summary of the hazards identified using Structured What-If technique (SWIFT) as an alternative identification method. The results allow comparison of the robustness of the hazard identification from both methods. • Annex F provides a listing of the hazards identified using the UAVS-friendly FHA method, as applied to the Tactical UAVS case study. This is provided as a ‘starter list’ to aid the assessment of other UAV Systems, and is not intended as being a complete list for all varieties of UAVS.
3
PART 1 – LITERATURE REVIEW Overview of Unmanned Aerial Vehicle Systems What is an Unmanned Aerial Vehicle System (UAVS)? Let us start with a narrower question - what is an Unmanned Aerial Vehicle, or UAV, as this tends to be the 'business end' of the overall system? This can be surprisingly complex to define, but the Civil Aviation Authority (CAA) take a nice, broad view in their definition as: “An aircraft which is designed to operate with no human pilot on board.” [CAA04, section 2.1]. This definition is both short and subtle, in that it is inclusive of all flying vehicles that would usually be considered under a wide remit as 'aircraft', and covers all aspects of pilotage and control from the fully autonomous vehicle to those under direct ground-based pilot control. There are more complex definitions, such as that proposed by the United States Department of Defense (DoD) for "A powered, aerial vehicle that does not carry a human operator, uses aerodynamic forces to provide vehicle lift, can fly autonomously or be piloted remotely, can be expendable or recoverable, and can carry a lethal or non-lethal payload. Ballistic or semiballistic 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 longrange navigation (using LORAN) and datalinks for image data download. An example of these more sophisticated UAVs is shown in Figure 1a.
Figure 1a - AQM-34 derivative showing the improving reliability of 'high end' UAV systems [Wes05] In the 1980s and 90s, US funding receded in 'low-end' UAV systems, and instead switched into higher performance systems such as Predator and Global Hawk. Other countries continued to see the value of low cost reconnaissance systems as 'force multipliers' in dangerous situations. In this period, Israeli, French and UK systems (Phoenix) saw service in the Balkans, Afghanistan and Iraq. The military requirement for UAVs was now well established. The 1990s finally saw some peaceful civilian uses for UAVs, such as NASA Pathfinder and Helios, for environmental monitoring. In 1998, a 13kg Australian system (Aerosonde Laima) crossed the Atlantic, opening the door for long endurance civil systems with fully autonomous navigation (using GPS) (see Figure 1b). UAVs are here and cannot be ignored!
Figure 1b - Aerosonde Laima Crosses the Atlantic (taken from www.aa.washington.edu/research/afsl/background.shtml)
5
Current and Future Directions New technology is accelerating the pace of UAV development, and hence increasing the 'push' into the market-place. As Willbond notes [Wil05], not only has the aviation industry seen major developments, such as in avionics, fault tolerant flight controls and stronger / lighter composite materials, but the world overall is being changed by disruptive technologies such as Global Positioning navigation, faster / more flexible communications links and the incredible speed of development in computing power ('per pound' of hardware required to perform it). These changes are allowing UAV Systems themselves to develop as a disruptive technology - like the jet engine when it emerged among the piston-engined fleets of the 1950s, they do not just evolve from previous technology but completely revolutionise what can be achieved. What is less certain at the moment is the directions of the 'pull' into the market-place - what do people want UAVs to do for them? As before, the military have more established requirements, based on the UAVs perceived unique capabilities: o
They can perform jobs that are too 'dull, dangerous or dirty' to be undertaken by manned aircraft.
o
However, they also have capabilities beyond those of manned aircraft - in particular to undertake tasks at extreme altitude, or incredible endurance. They can also launch and recover from areas that manned aircraft (even helicopters) cannot get into or out from.
o
With their relative low cost (compared to manned aircraft and helicopters), using several UAVs can perform some persistent tasks more cost-effectively than the few manned aircraft that could be deployed for the same resource.
Several military customers have published 'roadmaps' showing their requirements for UAVs, from the current situation out to quite extended timescales in some circumstances. What these declare is a vision, of how they see UAV types and their operational capabilities developing. As Figure 1c shows (fairly typically), there is a wide spectrum of UAV types required, from micro (such as the Black Widow) costing a few hundred dollars and easily man-portable for operational-level deployment, up to large scale High Altitude / Long Endurance (HALE) type UAVs (such as Global Hawk) costing millions of dollars but delivering strategic-level capability.
Figure 1c - Spectrum of current UAV military types [Wei04]
6
Potential civil applications are held back from deployment in most nations, primarily because of the lack of certification and safe integration into the general airspace that this report explores ([Wil05]). Civil applications cannot, routinely, fit into a segregated range or battle area. Hence there are not, currently, many civil UAVs outside of experimental development and use. There are, however, many intended uses once the barrier of integration has been surmounted, such as [Okr05]: o
Environmental monitoring tasks, such as pollution patrolling, earthquake warning, animal population tracking, weather forecasting...
o
Catastrophe management, allowing operation management, situation assessment, or direct action such as fire-fighting
o
Patrolling low-population areas, for tasks such as Search and Rescue, or border security patrol (very useful as part of the US Homelands Security initiative)...
o
Survey tasks such as geological surveys, pipeline / cable surveying...
Rather like the Laser once was described, the civil UAV is a solution waiting for a problem, and uses will multiply once they have gained access to the necessary airspace.
Issues Relating to UAV Safety and Access to Integrated Airspace In order to gain this routine access to airspace, UAVS designers, operators and regulators will have to address a number of significant safety issues, and these are discussed below. The issues identified from the Literature Search fall roughly into two areas: o
Those issues which derive from the UAVs own disruptive technology;
o
Those caused by the UAVs developing, not in a vacuum (as manned aerospace did in its first years) but in an already established manned airspace environment, which must come to terms with how to handle the newcomers.
These aspects are discussed in the following sections.
Note on UAV Classification As discussed in CAP 722 [CAA04, Chapter 1], there are several ways of classifying UAVs in order to apply some common principle, such as by weight, kinetic energy, operating domain or mission type (and we look briefly at the issues this creates in section 1.1.1). However, when discussing the need to integrate UAVs into manned airspace, it is very useful to classify UAVs by the type of airspace they will operate within. On this basis (as proposed in [CAA04] and the corresponding UK military publications set of Joint Service Publication (JSP) 550) an appropriate classification, which shall be used elsewhere in this report, may be considered as: Group 1 - Those intended to be flown in permanently or temporarily segregated airspace (normally a Danger Area) over an unpopulated surface (normally the sea following 'clear range' procedure). Group 2 - Those intended to be flown in permanently or temporarily segregated airspace (normally a Danger Area) over a surface that may be permanently or temporarily inhabited by humans. Group 3 - Those intended to be flown outside Controlled Airspace (Class F&G) in the United Kingdom Flight Information Region (UK Flight Information Region (FIR)).
7
Group 4 - Those intended to be flown inside Controlled Airspace (Class A-E) in the United Kingdom Flight Information Region and United Kingdom Upper Information Region (UK FIR and UK UIR). Group 5 - Those intended to be flown in all airspace classifications.
1.1 Safety Issues Relating to UAVs as 'Disruptive Technology' Some issues with potential safety impact stem from the differences UAVs pose, compared to their manned predecessors. Some inherent issues are due to the very nature of their disruptive technology, whether or not there was an existing system to clash with. These aspects are discussed here (though some, inevitably, cause knock-on issues for the existing manned airspace environment and cross-references are given where appropriate).
1.1.1 Impact of the Variety, Roles and Performance of UAVs Breadth of Scope of UAV System (UAVS) Varieties The initial problem in discussing safety of UAVSs is the sheer breadth of scope of such systems. It is difficult to pin down generalities for a range of systems that embrace the palmsized / Line of Sight (LOS) controlled micro UAV right up to the Boeing 737-sized HALE controlled via satellite datalink. This range is a challenge for the regulators - possibly more so than their manned counterparts, and we shall look more into this when we discuss issues of legislation and certification (section 1.2.1). Nelson and DeGarmo [Nel04] paint a fascinating set of 7 scenarios for UAV operations in 2020, ranging from a stratospheric airship acting as a telecommunications relay, to a team (swarm?) of UAVs on border patrol, and on to a 'media and traffic reporting' UAV operating under Visual Flight Regulations (VFR) in an urban environment. At this point, while it may not necessarily be a direct safety issue, the fact that authorities cannot classify UAVs (or even model aircraft [Deg04]) consistently shows the extent to which they challenge regular thinking. The Swedish Aviation Safety Authority believe it is necessary to define at least 5 classifications of UAV in order to arrive at suitably granular understanding of requirements [Wik03]; the military tend to classify based on altitude and endurance, or sometimes on operational characteristics; other schemes by civilian authorities consider kinetic energy (i.e. mass and speed), or mass alone, or range, or operating airspace type, or potentially some measure of the level of autonomy. The FAA cannot even arrive at a consistent definition of what constitutes a UAV [DeG04, paragraph 2.4.1]. My concern is that these attempts to pigeon-hole UAVs into existing categories (or something similar) and manage them accordingly, shows a limited understanding of the nature of UAVSs and the safety risks they may pose: the accent is on trying to keep the status quo rather than address the rich differences that UAVSs present. This concern will reappear regularly throughout this report. UAV Performance UAVs can perform differently to their manned counterparts, in part due to their different size and sometimes unusual planform. Sometimes the performance is possible primarily because they are unmanned and aren't limited by human frailties. The fact that they perform differently means that they can be difficult to slot into a stream of manned aircraft traffic. Degarmo [DeG04,] in particular notes the variation in performance capabilities of different UAV systems. Some will operate very slowly, with limited manoeuvrability, while others may be faster and more agile than their neighbours. Relative differences in velocity and manoeuvrability introduce potential conflict which must be managed.
8
UAV Roles and Mission Profiles If UAVs lack performance commonality with manned ac, they also lack predictability of flight path, with their roles and missions introducing unusual flight behaviour. DeGarmo again [DeG04, paragraph 2.3] discusses how UAV types of mission are rarely 'point to point' but instead have variations of patterned flight, loitering, tracking and orbit activity. There is even the possibility of planned flight termination, with the vehicle potentially suddenly entering a 'falling leaf' or parachute recovery in the path of other traffic - while this was not discussed in the literature reviewed, it would be an obvious concern in traffic. [DeG04] does propose the establishment of designated flight recovery areas, where UAVs could go to 'die' (flight terminate) assuming that power and control was still available. In the CRS Report for Congress [Bol05] there is the interesting prospect of swarms of UAVs operating mutually under a common human controller, on border patrol. This introduces the potential for the UAVs mutual interference, as well as constituting a widespread hazard for other aircraft and ground-based population (see 'increased traffic' in section 1.2.2). Before getting too excited over these differences, though, perhaps we should consider whether parallels may be drawn with the capabilities, roles and flight patterns of helicopters: the fixed wing fraternity has managed to accommodate these vehicles, so perhaps there is fair hope for UAV integration. Launch and Recovery In [DeG04, paragraph 2.3] DeGarmo discusses the UAVs' next trick - the capability to launch and recover from almost anywhere (in ac terms). While it is true that large UAVs will generally operate from airfields (itself something of an issue - see 'airfield operations' in section 1.2.2 of this report), smaller UAVs are designed to operate not just from runways but also from ships, open country, even buildings and urban environments. The implication (not explicit in the text) is the safety risk associated with the UAVs sudden and unexpected insertion into manned traffic, as it rises from below. Conversely, the UAV may perform a sudden change of vector, not expected by manned traffic on a parallel point-to-point flight, as it turns into a recovery pattern. However, as for the discussion over roles and mission profiles, the literature does not draw any parallel with the introduction of helicopters into fixed wing aviation, and I feel that there could be useful aspects to draw from the experience gained with this, in the cause of UAV integration.
1.1.2 The complex system boundary for UAVs Extended System Criticality Several sources recognise the criticality of the UAVS overall, and not just the vehicle. Certainly, the ground support environment plays its role in manned aviation, but in UAVSs there are a number of direct causal links that can affect safety in real time. The Joint UAV Task force (UTF) [UTF04, sections 7.2 and 7.3] recognised this criticality when they proposed extending the usual definitions of 'airworthiness' to include all safety critical elements of the system, such as Ground Control System, datalink, Flight Termination System etc. They then took this further to suggest that some of these elements (and others such as Flight Control / Flight Management System, the Control Station and Launch / Recovery equipment) should themselves be subject to Type Certification (discussed more in section 1.2.1 of this report). DeGarmo [DeG04, section 2.3.3] extends the boundary further to consider the information and data systems used by the UAVS, including those derived from wider sources. He suggests that we need to consider the data being passed around the system internally, such as navigation and position data, telemetered parameters. Then, to look further out to consider the mission planning / retasking from the ground station; and then further still to consider the data sources feeding the GCS, such as terrain databases, weather databases / live links, and possibly dynamic Air Traffic Management (ATM) data such as time-dependent clearance blocks. DeGarmo goes on to discuss US plans for an 9
ATM information network, but whatever the implementation, the UAVS, vehicle and GCS will inevitably have to interface with various proprietary wide-area networks and even internet based information networks. None of the documents agree entirely on what the critical elements are. The CAA offer a useful maxim of "Where any function of a UAVS is essential to, or can prejudice, continued safe flight and landing of the UAV...have to comply with the applicable airworthiness requirements" - this allows some flexibility to identify the critical elements pertinent to the system under consideration, but without saying what those applicable airworthiness requirements might be. It is clear that the overall 'system' is extended even within those elements in control of the UAV organisation. If we consider all the system elements that could affect safety, we have a very extended critical system. In effect, we can view this as a particularly interesting 'System of Systems', with varying levels of coupling between the different system elements. Command Datalink A key integrating element of the extended system is presented by the Datalink. It links the UAV with its Ground Control System for guidance and telemetry, plus a host of other systemspecific 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 nonpriority sensors) could be re-allocated to use this technology and free-up spectrum. Connection path: Current, small UAVs generally use VHF / UHF datalinks, giving direct Line-of-Sight capability. This can cause problems with terrain masking (as noted in [UTF04], briefly) and affect the possibility for low-level operations. [DeG04] discusses other options: 10
The US has made use of commercial and military SatCom links [Sch04] and potentially there is access via Iridium Low Earth Orbit (LEO) satellites. Each of these potential connection paths changes the system boundary, which returns us neatly to the opening statements of this section - the UAV and its extended system criticality.
1.1.3 UAV autonomy - technology, predictability, complexity Tim Willbond [Wil05] in his keynote speech at the Royal Aeronautical Society (RAeS) conference in 2005, talked about the two-edged sword of autonomy in UAVs: on one hand, it is a key enabling technology, allowing flexibility to the UAV, capability to the human operator and providing fall-back options if the datalink goes down; on the other hand, it will be a major hurdle to prove its dependability to allow integrated operation in manned airspace. To consider its hazards, we need to understand a little of what autonomy may be like 'in service'. Autonomy level factors When we talk about autonomy levels, we are talking about a continuum of system authority: at the one extreme, where the system has no autonomy, the human operator has full control of the system at the most basic level, making inputs to the direct control actuators of the vehicle. At the other extreme, with full autonomy, the system is able to exercise its own control, make its own decisions, learn new tactics and shape the mission, without even informing the human operator. Most likely, systems in the near future will exist somewhere in between. The military have traditionally used a simple linear scale (usually 1 - lowest to 10 - highest) to describe a UAVS level of autonomy. However, Huang [Hua04, 2] suggests that the answer is more complex. He proposes that a number of factors provide the real indicator of the autonomy level: difficulty of the environment; complexity of the mission; and operator interaction (inversely proportional - less interaction is more autonomous). For our consideration of safety, each of these axes would give us a series of issues to be considered. Is the UAV autonomy appropriate to the situation it finds itself in? What if one of these factors changes? Platt [PlJ05] takes a broader, less constrained view, and says that Autonomy of a system is a function of: the operator's interaction and its context; the types of reasoning about the environment that the system employs; and the types of knowledge that the system has available or can gather. Figure 1.1.3a, below does two things: it gives a view of how the environment and mission context might drive the required level of autonomy; but, again, it indicates how these axes could become safety issues, if our UAVS equipped to a certain level of autonomy gets pushed beyond its intended model.
11
Figure 1.1.3a - Autonomy level variation with required flexibility of mission / environment and certainty of information Autonomy v Ground Control: The Joint UAV Task Force [UTF04, section 7.9] propose that the Human Machine Interface will be a critical area of autonomy design and regulation, with the need for a careful trade between autonomy level and the capability of operator intervention. While the spirit of this is clear, it may represent (again) a too black-and-white mental model of autonomy and human interchange. Walan [Wal03] instead suggests that the situation changes between different mission types and even during the same mission. Periods of intense action such as mission planning and sensor operation may be interspersed by long periods of boredom and lapses of operator awareness, and this would be much increased for an operator responsible for multiple UAVs in a package. What he offers is a model for variable autonomy, what he calls "sharing control rather than trading control" - "Sharing control means that the human and the computer control different aspects of the system at the same time . . . Trading control means that either the human or the computer turns over control to the other" Platt [PlJ05] supports this view. In Figure 1.1.3b, Platt suggests that the scope of an operator's inputs to and desired outputs from the UAVS can be modelled at different scopes from direct system control (Tier 1) through tactical system management of the vehicle configuration (Tier 2), up to strategic overall mission management (Tier 3). Figure 1.1.3.c then shows how the autonomy / authority can be varied to suit the operator's needs for a given situation.
Figure 1.1.3b Optimising autonomy level to suit operator's [mission] needs 12
Figure 1.1.3c varying the UAVS autonomy level to suit the required level of operator authority for a situation Whilst debating the required share of autonomous functions, note should be made that some autonomous behaviour will be demanded by the regulators and ATM providers, primarily for actions in the event of emergency situations - section 1.1.2 refers. Reliability and predictability Autonomous behaviour will demand a safety critical consideration of its reliability. As Schneider notes [Sch04] "Conflict avoidance, especially in a fully autonomous, lost link situation, will be the Achilles heel challenge for the FAA to prove" - he demands an Equivalent Level of Safety (ELOS) for UAVs with autonomous vehicle operation. What makes an autonomous system hard to trust? Platt [PlJ05] proposes two general reasons: the gulf of execution - does the system take actions that correspond to the intentions of the operator; and the gulf of evaluation - can you monitor the state of the system and what is the difference in state from that intended. When we get to considering autonomy for high level functions (Tier 3 in the above discussion), Platt assumes that these will most likely be controlled using 'agent based' methods (see Figure 1.1.3d below). These introduce three areas of uncertainty: o
These are a novel application in air vehicles and hence there will be issues of expertise, trust and clearance
o
They require accurate capture and specification of the 'agent' behaviours beforehand giving issues of knowledge acquisition (and requirements elicitation - see York module on Requirements Engineering (RQE)).
o
There will probably more be than one 'Artificial Intelligence' method used to implement the decision making, and these will introduce new issues of architecture and integration
13
Figure 1.1.3d 'Agent' View of the UAVS assets and mission decision-making environment (for a multi-UAV scenario) Platt echoes the old cry of "It's only software!" and the issues of predictability that entails (see York Computers and Software (CAS) course). He proposes that the challenging issue will be in trying to ensure clear distinction is made between safety critical and mission critical functionality such that inevitable changes to the mission critical aspects can not impact on the safety critical aspects. UAV 'Airmanship' In section 1.2.2, we look at issues of ATM interaction and the need for 'transparency', i.e. the ability of the UAV to behave in the same way as manned aircraft, and (for highly autonomous systems) this function will fall to the vehicle autonomy. Behaviours and judgments such as applying rules of the air, navigating, sensing and responding to weather conditions fall into this vague category of 'airmanship' and are difficult to describe, let alone specify - in some cases, behaviour should be absolutely predictable (such as generally within an airspace corridor) and in others, instantaneously flexible (such as in collision avoidance). Airmanship is both planning for expected events, plus reacting (predictably but swiftly) to external events. Marsters and Sinclair [Sin03, section 4] say that "The precision and repeatability of technological solutions notwithstanding, the knowledge, judgment and skill (sometimes called 'airmanship') of the on-board pilot will be difficult to emulate." DeGarmo [DeG04] looks at various airmanship issues, such as how the UAVS detects and responds to weather systems and conditions - in some cases coping with the conditions, but in others deciding how to route to avoid them. This may be quite an issue, especially for smaller UAVs more sensitive to weather (see section 1.1.1). He also looks at how UAVS decision making matches the expectation of Air Traffic Control (ATC) decision making tools (such as used to effect Traffic alerting & Collision Avoidance System (TCAS) manoeuvres). A critical aspect of UAV autonomy will be the vehicle response in the event of command datalink failure (as noted elsewhere, in sections 1.1.2 and 1.2.2). DeGarmo [DeG04], for example, calls for pre-programmed actions, diversionary sites / flight termination areas and procedures to be defined - what this implicitly calls for is that, in the event of datalink failure, the UAV can successfully analyse the situation (including external factors such as weather conditions), decide on the course of action, and navigate its way there predictably and
14
dependably. Such functions are identified in a number of other documents, including the CAA in CAP722 [CAA04].
1.1.4 Accident rates and reliability - UAV airworthiness This section looks at the accident rates and reliability of current UAV systems, related to achieving safety levels acceptable for flight in unsegregated airspace / terrain. It discusses the inherent safety levels for UAVS, rather than the demands for legislation, standardisation and regulation to achieve such levels, which are covered in section 1.2.1. The Catastrophic failure rate is too high (currently) Indications are that the failure rate for UAVs is currently too high. DeGarmo [Deg04, 2.1] quotes US DoD analyses that show the UAV catastrophic failure rate (in terms of vehicles lost rather than induced fatalities ) at around 50 times that of an F16 (itself held to be a fairly risky platform), and around 100 times that of more general aviation. Another statistic compares an accident rate of 0.06 per million flying hours for U.S. commercial aircraft in U.S. airspace to a rate of 1,600 per million flying hours for the Global Hawk. Clearly such figures, if read across to UAV operation in unsegregated airspace and larger UAV fleets, would not seem tenable. Part of the problem is the data - all of it, currently, is sourced from military UAVS which have often been rushed from research into service (e.g. Predator use in Afghanistan); have been employed in fairly high-risk operations; and come from a very small sample, compared to the manned fleet they are being compared with [DeG04, 2.1.2]. Nonetheless, such figures would not currently support integration. If the situation is to improve, we need to understand the causes for the poor safety record. This is not easy: as Williams [Wil04] notes in his review of UAV Human Factors issues, there is a lack of good, reported UAV accident data, even in the military: until recently, the US Army and Navy classified UAVs as 'vehicles', and treated accident investigation similarly to damage to ground vehicles. The US Air Force did carry out more detailed investigations but would not release information into the public domain. As a result, most UAV accident 'statistics' are based on aggregated information or single sentence entries - it is thus difficult to derive significant causal analysis. DeGarmo [DeG04, 2.1.2] tries to pick through what is available, quoting DoD analyses again to state that around 75-85% of the failures were due to equipment failure (37% propulsion, 26% flight control, 11% communications link; 17% human factors, 9% miscellaneous). He states that such figures are not unexpected: as we noted above, the current generation of UAVS stem from research programmes, and/or have been 'thrown' together to satisfy high risk operations at low cost, thus redundancy and reliability have not been high priorities. It is not stated, but we can presume that military programmes have also assumed a higher acceptable risk level, combined with operation over unfriendly territory, so concerns over ground or air collisions have also been pretty low we are not assessing the record of systems designed for operation in integrated airspace over 'friendly' populated areas! Schneider [Sch04] concurs, providing a little more detail on the equipment failings: o
Propulsion system unreliability relates to the search for a reliable 'heavy fuel' engine that can cope with the extended endurance requirements, at temperatures and altitudes not generally experienced.
o
The flight control failures, on the other hand, relate to the use of COTS actuators, some drawn from commercial non-aviation sources (hence not intended for this level of criticality) and often being used outside their intended environment.
Schneider concludes that, while current UAVSs could have been designed, fabricated and maintained to manned aircraft levels, this had clearly not been the case so far.
15
Bolkcom [Bol05] also highlights the problems due to evolving technology in this generation of UAVSs, but says that the equipment issues are heightened because the UAV-p is removed from the event: rather than being a direct Human Factors accident, instead an equipment failure develops into an avoidable accident because the UAV-p is less able to diagnose and correct problems; he lacks the 'seat of the pants' sensory inputs. There is further discussion of Human Factors safety-related issues, in section 1.2.5. What is acceptable Safety Risk? DeGarmo [DeG04] says that, to gain acceptance, UAVS will have to prove that they have an Equivalent Level of Safety (ELOS) to manned aircraft. But defining this 'equivalence' in terms of actual safety requirements is very difficult. The CAA echo this general requirement [CAA04], saying that UAVs operating in the UK “…must not present or create a hazard to persons or property in the air or on the ground greater than that attributable to the operations of manned aircraft of equivalent class or category”. [UTF04] also starts with a general principle of equivalence, that requirements should be no less demanding than those currently applied to comparable manned aircraft, but does then try to achieve fairness that such requirements should not penalise UAV Systems with higher standards simply because technology permits. This gives us a concept of balanced safety requirements, but how could we define such requirements? The Swedish Aviation Safety Authority in [Wik03] takes a fairly pragmatic view. They are content to allow a higher accident risk per flight hour for UAVs during the earlier development period, provided that this is balanced by a low number of flights / UAVs to ensure that the risk to the overflown public or manned aircraft remains acceptably low. As the number of UAVs increase, the reliability of systems must increase sharply to keep the individual risk low. They consider an overall balanced target of no more than 1 death on the ground per 50 year period; and in the air, UAV systems shall not give rise to more near collisions, calculated per flight (or flight hour) than manned aircraft have caused during the most recent ten-year period. [Wik03] refers in turn to [Mar03] to calculate the allowable critical failure rate per UAV flight hour. This they derived by reckoning the overall target against the number of flight hours per annum, the population density (assuming flight over a low density area in the early years) and the 'lethal swathe' area determined by the expected crash mode of the system - a horizontal crash creating a longer, bigger swathe than a vertical dive. In this way, they say, by controlling the number of allowed flight hours, the failure rate for a given system can be allowed to be higher in the early stages. Weibel and Hansman [Wei04] take a slightly different approach to achieving balanced safety targets, in their attempts to identify required levels of reliability to avoid ground and air collisions. For ground collisions, they start with the FAA requirement for a 'hazardous' event (assuming that the number of fatalities in any event will be small, hence not catastrophic) to occur less than 1x10-7 per operating hour. From the National Transportation Safety Board (NTSB) records they found the actual number of ground fatalities per operating hour to be 2x10-7 per flying hour; and then set a target level of safety a magnitude higher at 1x10-8 ground fatalities per hour in recognition that, to gain acceptance, UAVs will need a greater level of safety than manned aircraft. For air collisions, the FAA target of less than 1x10-9 collisions per hour was taken, for ELOS. In calculating the required levels of reliability, [Wei04] goes into more depth (than [Mar03]) in assessing the risk, taking into account the UAV mass and barriers to actual fatalities. For ground collisions, these barriers are proposed as: population density, shelter afforded by buildings, and likelihood of fatal penetration. For air collisions, they propose the 'collision volume' of the UAV and manned aircraft (their near-miss area extruded along their intended flight route), the size, length and traffic densities within controlled airspace, and finally a probability that the collision may not actually cause fatalities - the latter does not accord with the CAA view that 'nearly all collisions result in fatalities' but does allow for the fact that birdstrikes etc are usually survivable, and we are discussing a wide spectrum of UAV sizes and masses. Interesting (but maybe not unexpected) conclusions from the study are that high mass, high altitude 16
UAVs in controlled airspace will have to achieve a much higher level of safety (because of their kinetic energy capability) than smaller vehicles in less dense airspace; but that the former would be more able to meet such levels from inclusion of redundant systems and cooperative collision avoidance technology, because of their size and sophistication. Achieving Airworthiness Marsters [Mar03] is clear that "It is very important that the overall safety-assurance for UAV operations outside reserved airspace be based upon the design, development and maintenance of highly reliable air vehicles." He presses on that UAV reliability and their contingent catastrophic failure rate must be acceptable by civil aviation standards, and this can only be achieved by adopting a stringent system-safety design regime for UAVs. What he proposes is to incorporate a 'FAR 1309-type' philosophy in the UAV flight-critical system safety design, and refers to ARP 4761 [SAE96] as a suitable approach for safety analyses. The Swedish Aviation Safety Authority [Wik03] also place great faith in airworthiness through design, but note that there will also be requirements for operator and maintenance standards (of which more in section 1.2.1). The paper looks at JAR 25.1309 and JAR 23.1309 required analyses for manned ac, and briefly compares the applicability of such analyses to UAVSs. It concludes that targets such as allowable failure rates should be adopted, but that the methodology may be amended to suit the differences in UAVS. For example, where the Joint Airworthiness Requirements (JARs) make an assumption of 100 critical systems for large aircraft, and 10 critical systems for small single-engined aircraft, the UAVS designer may apportion required reliability more pertinent to the UAVS system breakdown, provided that the overall demanded reliability is thus achieved. This does seem to be a sensible proposition, and a suitable way of establishing 'equivalence' with manned systems in terms of reliability, while duly noting the differences that exist for UAVSs.
17
1.2 Safety Issues Relating to the Manned Airspace Environment 'Coming to Terms' with UAVs Some safety issues are evident, not so much because of the nature of UAVSs, but because they are having to fit in and around an already established environment. When manned aerospace was at a similar point of development, the skies were empty - now the skies are full of manned aircraft and the monolithic environment of Air Traffic Control, procedures, regulations and so on that has been established over time to keep them safe. This section looks at those issues where the environment is struggling to come to terms with UAVSs and their nature.
1.2.1 Regulation, Certification and the Drive for Standards Elsewhere in this report we look at characteristics of the UAVS such as airworthiness, safety requirements (section 1.1.4), operations (1.2.5), collision avoidance (1.2.3) and ATM interaction (1.2.2). The aerospace community's approach to try and ensure the safety of these characteristics is to derive regulations, certification and standards that must be applied. In this section, we look at the safety issues emerging from this 'must-do' philosophy. Regulation Manned airspace is a highly regulated environment, and it is worth a brief review of what this entails for the UAVS. At the top of the regulatory 'tree' is the Chicago convention, specifically Article 8 which states that "... no aircraft capable of being flown without a pilot shall be flown without a pilot over the territory of a Contracting State without special authorisation by that State" [CAA04]. The push for regulators is currently to find international agreement on how to open up the skies to unmanned aircraft. The CAA provide an overview of how regulation is flowed down from the Chicago Convention for aircraft generally, both manned and unmanned, in CAP 722 [CAA04, chapter 2]: o
European Aviation Safety Agency (EASA) regulation EC 1592/2002 applies generally to all aircraft in the European Union, for airworthiness certification and continuing airworthiness (maintenance and modification);
o
This excludes 'state aircraft' (military, police, customs), research craft and those under 150Kg, to which national regulations must apply.
o
Equipment requirements, operational rules, personnel licensing, aerodrome regulation and regulation of air traffic services are not (yet) dealt with by European Regulations and so are matters for national regulation for all categories of aircraft. The UK covers these (for non-military aircraft) under the Air Navigation Order 2000 and Rules of the Air Regulations 1996. Aircraft must have a Certificate of Airworthiness (Design and maintenance), a Permit to Fly (Operations) and Licensed Aircrew (for airspace and meteorology / visibility conditions).
CAP 722 then goes on, chapter by chapter, to try and state how general aircraft regulation (civil and military) should be applied to UAVSs. But there are many areas where the regulation becomes vague and stops fairly quickly after demanding 'equivalence' in terms of performance, safety levels, certification, interaction et al, without guidance on what the equivalence is to, or how the UAV differences may be resolved in this environment. The Australian Civil Aviation Safety Authority (CASA) have similarly moved to apply existing regulation, and published their Civil Aviation Safety Regulations Part 101 [CAS04] to define how that was to be done. 'Define' is perhaps too strong a word - while the text appears definitive at first, this is predominantly for application to small and micro UAVs: once the
18
regulation reaches larger UAV systems and operation, it basically refers the reader back to CASA, to establish written agreements on what can be flown, where and how. Perhaps its major contribution is that it allows small UAVs fairly good access, even to controlled airspace. This will allow building of experience for designers, operators, and ATC personnel and hence inform the wider use of UAVS. DeGarmo [DeG04, section 2.4.3] discusses this worldwide move to try and apply existing manned regulation - he declares that it is good in principle, to apply existing regulation wherever possible, because it avoids developing new, specific regulation that might ultimately prejudice a developing area of UAV operation. Hence, he notes that this approach currently forms the backbone of the US development of a UAV 'roadmap' towards integrated airspace (and its equivalent can be found in most of the international roadmaps in development). However, he goes on to note that the wide variety of UAVs could make this universal application difficult to apply (as we discuss in section 1.1.1). In their Joint UAV Task Force report [UTF04], Joint Aviation Authority (JAA) / EUROCONTROL provide a useful discussion of their philosophy for regulatory development for UAVs, and this has been flowed on through EASA into their provisional regulation under Advance – Notice of Proposed Amendment (A-NPA) No.16-2005 ([EAS05]). Their guiding principles are that regulation should establish: o
Fairness - between competing UAV systems and with existing manned aircraft: hence the principle is to apply existing regulation wherever possible (in accord with DeGarmo, above).
o
Equivalence - regulation covering UAVs should be no less, but also no more demanding than expected for manned aircraft systems: this they break down into equivalence of risk (see 1.1.4) and in operations (to meet the expectations of other airspace users). Few clues are provided on what to establish the equivalence to!
o
Responsibility / accountability - clear demarcation of the organisation requirements for: design, manufacture, operation and maintenance of UAVS. The report notes the importance for maintaining the accountability chain in the event of extended UAV operations causing responsibility to be passed between personnel and organisations, even nations as an operation proceeds.
o
Transparency - especially for ATM: this does not seem so much a guideline as a pretty hard-line requirement, the fairness and applicability of which is discussed in section 1.2.2.
Eventually, EASA / EUROCONTROL settle down to consider regulation aimed at controlling their "5 pillars of safety and security": Airworthiness & Certification; Operations & Maintenance & Licensing; Security; Air Traffic management; and Airports. However, they go on to reiterate that, currently, EASA only regulate airworthiness and environment, and they propose that a 'Total System' approach is required in the long run ([EAS05, IV-4-b]) as hinted at in [CAA04] above. A graphical representation is shown in Figure 1.2.1a, below.
19
Figure 1.2.1a - EASA / EUROCONTROL 'Total System' vision for aircraft / UAVS regulation Certification For the UAVS itself, certification literature falls broadly into two areas: that for the UAVS design, and that covering the operation of the system. Design Certification The first issue for regulators is to establish the basic strategy for certifying UAVS designs. For manned aircraft, civil regulators have generally followed a standards-based approach and assume an independence from the operational considerations, while military certification authorities have followed a mix of standards and safety target / safety case methods in order to focus on eventual satisfaction of specific missions and uses. How then, to certify UAVS? DeGarmo [DeG04] discusses a CAA study in 2002 [CAA02], which assessed two approaches - safety targets (where, potentially, design requirements could be traded against operating requirements, such as operation over unpopulous areas to offset initial reliability concerns) and certification design requirements (standards). While the former was proposed as being easiest to apply, the CAA decided that this was "not consistent with International Civil Aviation Organisation (ICAO) ... legislation". The study went on to say that "the second approach, one that is requirements-based, was seen as more practical in that it is familiar to the aviation industry, it facilitates the development of common standards, and there are no special, type-specific, operating restrictions to address airworthiness uncertainties, therefore offering greater operational freedom". Degarmo suggests that this will be the way most regulators will opt for, inspite of his earlier observation that there are no established standards for UAV systems. The Joint UAV Task Force report [UTF04, 6.3.1.1] considered the same two options for certification. Again, they suggest that, given the current unknowns about the differences between UAV systems, the safety target approach would be easiest for UAVS application, but that the standards approach must be followed for the following reasons: o
In order to accept a safety case approach, the regulator needs to be closely linked to the operational acceptance side as well, in order to understand and apply controls. While this is possible for military systems, it is not for civil regulators - EASA, as noted before, do not have control of operations, personnel, airfields etc. Even if the regulator could control operating aspects, it could still prove unfeasible: if a safety 20
case for a system was accepted on a risk-basis underpinned by assumptions of mission length and frequency, it would be difficult to enforce this generalised assumption to specific missions and tasks on a daily basis. Civil standards-based certification separates the design from the operation and enforces minimum standards. o
The separation of design and operation will ease the certification process in the longer term, to allow UAVSs to be used by a wider variety of operators and for a wide range of missions. It also facilitates export of systems and operation across national borders.
o
In order to support fair competition for civil contracts, designers and operators need to face a 'level playing field' of certification, in order that one system under a particular regulator is not unfairly advantaged.
o
The build up of civil standards has delivered manned aircraft systems that have safety levels accepted by the public, and the same should be expected for UAVSs. Also, civil aircraft manufacturers are comfortable with the standards-based approach, and it ensures clarity that, provided the minimum standard is complied with, the system will get certified.
Some of the above sounds like "it's worked for us on civil manned aircraft, therefore it must work for civil UAVs" and there is still the problem of finding applicable standards (see below). I feel it is very difficult to separate the UAV from its mission, in the same way that the military have recognised the inter-relationship, and the Joint European Task Force has already pushed the need for a 'total systems' approach (see above). There are still the vast differences between UAVSs to be dealt with (see 1.1.1). The glimmer of hope within [UTF04] and the related EASA proposed regulation of [EAS05] is that, apart from bluntedged minimum standards, a safety objective approach based on CS.25 / 23.1309 type requirements should be established and followed. This at least means that system differences, safety risk assessment and the application of novel technology within the design may be identified and dealt with appropriately. This approach, and related literature discussing it, has already been discussed in section 1.1.4. The CAA [CAA02] provides some assistance in the issue of deciding the equivalence of manned and UAV systems. Briefly, the method involves the consideration of two scenarios: i) impact with the surface at a velocity appropriate to an emergency landing under control and, ii) impact at a velocity resulting from loss of control at altitude. The kinetic energy for each case is calculated and then compared with the results of similar calculations as applied to a sample of the existing manned aircraft fleet. Consideration of the results gives a first order approximation, to look at the indicated certification requirements (such as EASA CS.23) and draw out relevant aspects for the system under consideration. Where necessary, different sources can be merged to give the best mix of requirements for the new system. The next issue is that we need to be clear on what design aspects need to be addressed, and this is critical if the standards route is to be followed. Degarmo suggests that most of the usual manned aircraft design requirements will apply, such as for structural integrity, performance, reliability, stability and control, but would need to extend to certification of the wider system elements such as the ground control station, data link, data security, launch and recovery mechanisms, and the autonomous systems and software integrated into the vehicle and ground elements. The extended aspects of 'System-of-systems' safety criticality have been discussed in section 1.1.2 - these would all need to be addressed for requirements, while recognising the different criticality of sub-systems between different UAV systems - this will be a major challenge.
21
Operations Certification Marsters [Mar03] provides the overall context of operations certification. He suggests that any operator of UAVs wishing to routinely undertake missions in unsegregated airspace will apply for a UAV Operating Certificate from the relevant regulating authority, and that this application will provide "documented evidence of organisational competence and system safety", entailing: o
a description of the applicant organization, including relevant qualifications of competent technical and operational staff;
o
a full safety history of the vehicles to be used and of the fleet of this same type;
o
a global safety analysis for the combined vehicle - mission types;
o
a full description of the design standards used for all flight-critical UAV systems (see Part 4, below);
o
manufacturer's Flight Manual and manufacturer's Maintenance and Inspection Manual (see Part 5); and -
o
A Flight Operations Manual for the operating organization, including specification of the required qualifications and levels of training and proficiency for crew members (see Part 3, below).
This seems to provide the overall basis for a safety argument for the system in its intended use - while not as fully integrating as a safety case would be, elements such as the 'global safety analysis' mentioned above should help to bridge the gap between the bounded design certification discussed above and the actual usage of the system. The Joint UAV Task Force [UTF04] took a fresh look at operations certification. Their review included: a brainstorming of particular aspects of UAVs that might not have a parallel in existing regulations for manned aircraft; a review of existing JAR (now EASA CS) regulations on operations, maintenance and licensing; and where available a review of EASA regulatory material. Once again, their standpoint is that existing certification requirements should be applied wherever possible - but then they identify many areas where this is not possible! For licencing of personnel, they proposed that it would be possible to modify existing requirements. But for operating aspects, EASA OPS-1 did not seem to offer equivalent types of operation (aerial work such as filming, agriculture, customs and police work are all excluded); similarly for maintenance operations EASA CS145, 147 and 66 did not always fit easily with UAV operators providing continuing airworthiness for systems undertaking the type and variety of work expected. The study concluded by reiterating that existing requirements should be used wherever possible - a not wholly useful conclusion, but it might be assumed that the intent is to use the existing requirement as a start point and extend it to cover appropriate UAV characteristics and operations. The CAA [CAA04] do not get much beyond this principle, suggesting it apply across the board to maintenance and continuing airworthiness, organisation and personnel licensing, and approval to operate. Standards DeGarmo ([DeG04] section 2.4.2) takes a broad look at the current initiatives on standards, and some of these are discussed below. He notes activities by US DoD and North Atlantic Treaty Organisation (NATO), the American Institute of Aeronautics and Astronautics (AIAA), ASTM International, the UK UAV Safety Subcommittee (Ministry of Defence (MoD) and industry group) and RTCA; but he voices concern that there is a competitive spirit between these schemes, and while the current lack of standards makes regulation difficult, a plethora of different standards would not help either. He identifies that the US government have mandated that global, consensus-based standards should be adopted wherever available, rather than developing government specific requirements.
22
ASTM International (originally the American Society for Testing and Materials) are one of the groups trying to establish suitable consensus based standards for UAVs. In [AST04], their Statement on the role of ASTM International committee F38, they discuss the intent to raise standards to cover: Airworthiness; Flight Operations; Operator Qualifications. In line with the US Government requirement (and also, as discussed above, with EASA and CAA principles), these standards are to be established on the prioritised principle of: Adopt; else Modify; else Create as appropriate to suit UAVs. As they note in their review of the US DoD 2005 Roadmap for UAV development [AST05-1], standards play a major role within the roadmap without standards it is difficult to build regulation. One of F38's first priorities was to establish requirements for Sense and Avoid capability (see 1.2.3) RTCA Incorporated (originally the Radio Technical Commission for Aeronautics) is another American society aiming to produce consensus-based standards, but is perhaps closer to the federal government (without being an actual government body). This is particularly true for UAV standards activities of Special Committee SC-203, as it was set up with duel sponsorship from the Aircraft Owners and Pilots Association (AOPA) and the Federal Aviation Authority (FAA), to consider the standards required to support UAV operations within the National Air-space (NAS). In the terms of reference for SC-203 [RTC05], their objective is set out to produce key supporting standards documents: o
A. Guidance Material and Considerations for Unmanned Aircraft Systems (UAS) – to provide a definition of UASs, the NAS environment, and taxonomy of UAS terminology.
o
B. Minimum Aviation System Performance Standards (MASPS) for Unmanned Aircraft Systems - containing quantitative performance standards with specific focus on UAS level operational performance.
o
C. MASPS for Command, Control and Communication Systems for Unmanned Aircraft Systems - recommended standards for command, control and communication systems used in conjunction with UAS operations: addressing (but not limited to): Human Factors; Reliability; Data Links.
o
D. MASPS for Sense and Avoid Systems for Unmanned Aircraft Systems recommended standards and procedures for UAS sense and avoid systems, providing a safety level equivalent to that for manned aircraft operations. This will address: Reliability Factors; Traffic Avoidance; Data/Communication Links; Operational Safety Considerations (see section 1.2.3 in this paper).
The Terms of Reference note that SC-203 is not a joint committee with the European Organisation for Civil Aviation Electronics (EUROCAE), but does at least indicate that they will liaise. EUROCAE has recently formed its own Working Group (WG-73) to provide support to introducing UAVS safely into integrated airspace, and ensure compatibility with existing infrastructure and systems. In particular, it is to help bridge the gap between existing and necessary regulation and standards, to allow integration. WG-73 will look at a broad spectrum of issues, including: Operations; ATM; Airworthiness and Safety; Test and Maintenance. The working group is intended to draw together the various international initiatives (European and US) and includes setting up joint activity with RTCA. Perhaps this will help to establish a more joint approach to regulation and standards than is currently the case.
1.2.2 ATM interaction This section looks at the safety issues relating to interoperability of UAVs with Air Traffic Management (ATM) - particularly the personnel and technical systems. As DeGarmo notes [DeG04 section 2.3.1] a key part of understanding the concern this aspect causes is that, because of current segregation, very few UAVs have interacted with Air Traffic Control 23
(ATC) and the ATM system, it is difficult to predict what the real impacts might be. He postulates that it may be more an issue of uncertainty than any specific technical challenge. As I suggested previously (section 1.1.1), when people are faced with the unknown, they seek to impose their existing understanding and regulations upon it. Let’s look at some of the specific issues. The Requirement for 'Transparency' The CAA's CAP722 Guidance for UAV Operation in UK Airspace [CAA04] sets the tone that is common to a lot of other authorities: "UAV operation is expected to be transparent to Air Traffic Service (ATS) providers. The UAV-p will be required to comply with any air traffic control instruction or a request for information made by an ATS unit in the same way and within the same timeframe that the pilot of a manned aircraft would." I.e. that the only difference an Air Traffic Controller would notice would be the 'UAV identifier' on his screens. But is this level of transparency feasible? We have already looked at some ways that UAVs are basically different from manned aircraft (section 1.1.1), so what are the implications for mixing them with the existing ATM elements? ATC Systems ATM in most developed countries has well established technical systems to assist ATC to track aircraft, request information from and pass instructions to the pilots of manned aircraft. How well can UAVs fit with these systems? Marsters & Sinclair [Mar03 part 3] in 2003 was suggesting a requirement for Transponder Mode S in Canadian domestic airspace, to allow ATC to interrogate / track UAVs; and the CAA [CAA04] and EUROCONTROL [UTF04] both specify an impressive list of required equipage, to be consistent with existing levels for manned aircraft in particular types of airspace. But UAVs (particularly the smaller types) will struggle to comply because of limitations of space, payload or even the available power. DeGarmo [DeG04 section 2.3.5] takes up this issue of equipage, but focusses on the navigational requirements. With incoming Area Navigation ('RNAV') procedures, regulations generally state that aircraft must "retain the capability to navigate relative to ground-based navigational aids" such as Very High Frequency (VHF) Omni-Directional Range (VOR) for certain airspace types. However, most UAVs use GPS in isolation, and would not be able to carry VOR fit. It may be that UAVs will need the eventual back up of the European Galileo and Russian GLONASS systems to provide the required reliability to satisfy the authorities on navigational reliability in controlled airspace [Bon05] (i.e. Group 4 and 5 UAVs as defined in section 1.1). [DeG04 section 2.3.1] extends this discussion to consider the Air Traffic Controller's display information. Because UAVs have different characteristics (see Section 1.1.1 of this report), he suggests that it is likely that they will need some specialized attention - hence unique ID or symbol on display. He takes this first simple idea further by proposing that it may also prove valuable for ATC to know if the UAV is under manual or autonomous control; maybe even the need for a separate location / registration for the GCS, in case ATC need to speak directly with the pilot (while it is not discussed, I would propose that this would be even more crucial if the same GCS has control of several UAVs - the need for ATC to talk to the 'control node' if one or more of the associated UAVs acts out of turn). [DeG04 section 2.3.2] also turns around the issue of ATM system integration in noting the need to ensure not just system compatibility but also interoperability - that UAV and ATM systems do not interfere with each other. In section 1.1.2, we considered the issues around datalinks spectrum availability, but there are broader EMI effects due to the highpower nature of some of the ATM ground based systems (such as Precision Approach Radar) that the system will need to be proofed against.
24
Voice Commands In Marster's suggested flight approval process, put forward in 2003 [Mar03 part 3], he suggested the requirement for 2 way communications between ATC and 'vehicle commander', to allow flights in domestic Canadian airspace. Most proposed regulation since [e.g. UK in CAA04, Australia in CAS04] has similarly stipulated or assumed direct voice communications between ATC and the UAV pilot or controller. DeGarmo, once again [DeG04 section 2.3.4], takes up the practicalities of this proposed requirement, noting the need for ATC compatible VHF radios for voice comms. This is quite an overhead, as the UAV has to carry two radios (usually) to allow receiving of the voice comms from ATC (say) and simultaneous onward transmission to the GCS (and vice versa). DeGarmo suggests that in the long run, it would be useful have ATC comms 'split' with both an air transmission and a ground relay direct to the GCS - but while this would improve reliability (less transmitters and receivers than needed at present) it would require significant resource to build up such an infrastructure, and it is hard to see how cash-strapped ATM services would jump to provide this until the requirement on them was made explicit. All of the writers above have made an implicit assumption of the system - that voice comms must be relayed to the ground pilot. However Schneider [Sch04, chapter 6] takes a different view and instead urges the US to push research to allow UAV autonomy, through airspace situational awareness and speech recognition of ATC voice commands. Particularly where a single GCS has overall management of a number of UAVs but each has a measure of its own autonomous control, this must be the eventual approach, with each UAV having the ability to understand and communicate in speech, just as it will have in other information forms. The expectations of the Air Traffic Controller Lets turn to look at the human side of the ATM system, and especially how the ATC expects the UAVS to react in a 'transparent' manner. As we noted above in the introduction to 'The Requirement for Transparency', there are some aspects of UAV behaviour and characteristics that are plainly different to manned aircraft - how can these truly be absorbed into the existing ATM system? Some aspects we have discussed elsewhere, in particular the ATC expectations with regard to UAV characteristics (see 1.1.1), Airmanship (see 1.1.4), and Collision Avoidance (see 1.2.3). Here we look more generally at ATC expectations of UAVSs. Marsters and Sinclair [Mar03 part 3] proposed that UAV operators would need a suite of Standard Operating Procedures covering all normal and abnormal flight conditions: the review and approval of these procedures by the ATM authorities would then form the basis for approval of that operator to conduct UAV flights. The CAA [CAA04] follows this approach, with similar requirements for a suite of procedures to foster planning and authorisation. This seems to be the general civil way, and we have already looked into this in section 1.2.1. DeGarmo [DeG04 section 2.3.1] looks more specifically into the procedures and expectations for conduct of flight in controlled airspace (such as might affect a Group 4 or 5 UAV). He suggests that where there are existing ATM procedures and routes (e.g. for Instrument Flight Regulations (IFR) ascent through airspace), these will have been built around the expected performance capabilities of manned aircraft - some UAVs will fit in this envelope, but others won't: thus, the ATM will either have to exclude them (not optimum for our vision of integrated airspace), or develop new routes / procedures to accommodate these specifically. DeGarmo's study also considers a UAV specific hazard, due to their sensitivity to wake turbulence (particularly the lighter wing loading of Long Endurance UAVs); current vertical separation minima may be inadequate for these UAVs, hence they could require special treatment in order to fly safely along existing corridors. While most regulators are busy hammering home their requirement for transparency from the start, the Swedish Aviation Safety Authority seem more willing to take a practical approach in 25
these early days of integration. In the paper proposing the Swedish approach until the EASA regulations mature, Wiklund [Wik03, section 3] proposes that, initially, it will be useful for 'special Air Traffic Controllers' to be lent to UAV programmes, to provide specific attention to separation of UAVs from other traffic - in this way, experience can be built for both UAV operators and the Controllers. This approach seems ideal as an answer to DeGarmo's point noted at the very beginning of this section that most issues may be due to inexperience and uncertainty, rather than hard technical concerns. The Demands of Increased Traffic Even without the addition of UAVs, ATM systems are facing the problem of trying to reduce aircraft accidents while the number of manned aircraft looks set to increase significantly over the coming years. How will UAVs add to this? DeGarmo [DeG04 section 2.3.8] says the answer is... that we don't know! We need to study the effect of UAVs on airspace (and controller) capacity, including simulation of UAV numbers and looking at how different types of UAV and their varying performance characteristics affect the balance (see section 1.1.1 of this report). Factors such as the incredible endurance of some types (from 30 hours up to months at a time) mean that there aren't just more aircraft (with UAVs) but they are airborne and loading the system for much longer. Emergency Procedures ATM systems set particular store in contingency planning, especially how to handle particular risks associated with aircraft, such as propulsion failure or communications loss. How will UAVSs and ATMs interact for UAV emergencies? Marsters [Mar03 part 3] suggests that UAV operators establish procedures for dealing with Loss of Control Datalink - flight profiles, recovery areas, diversionary airfields if appropriate. Other critical failures that could require Abort and Flight Termination procedure (a UAV unique feature discussed in 1.1.1) need to be established and briefed to ATC. He also states that the UAVS should have the capability to allow the UAV commander to squawk an emergency code independent of the vehicle itself, to allow independent broadcast of the emergency state to ATC and all potentially affected traffic. This seems like a good idea at first, but perhaps should be reflected on after consideration of the particular failures that might affect a specific system - e.g. a highly autonomous UAV could fly on perfectly safely, perhaps, without the need to 'frighten the locals' in the event of a communications failure. I'm not sure if DeGarmo is hinting at this [DeG04 section 2.3.1] when he states that "The procedures to be taken by the vehicle will need to be communicated or predictable to the controller." I take this to mean that the procedures may be specific to a particular UAVS and its capabilities, provided that they are then made clear to ATC personnel who may interact with it. DeGarmo does try and standardise some of the emergency procedural aspects of UAVs [DeG04 section 2.3.7] by suggesting that aspects such as designated flight termination areas be declared and coded into available ATM databases, to ensure all are aware and plan accordingly. This would go a long way to make the common elements of UAV emergency procedures become second nature to operators and ATC alike. Airfield Operations A significant aspect of ATM interaction can occur before the UAV even leaves the ground. How does the 'unmanned ground vehicle' cope with taxiing, braking, etc in a ground controlled environment such as a shared airfield? DeGarmo [DeG04 section 2.3.9] suggests that because taxiing requires precise ground movements and the ability to search for obstacles, most current UAVs lack this and so are towed out to the Take-off position / back from the landing position. While simple for the UAV, this must increase the risk to the ground-crew and slow down operations - future UAVs will have taxiing capability, there can be little doubt. Part of the problem is for the UAV to recognise visual signals such as traffic lights for manoeuvring, as noted by the Joint European UAV Task Force [UTF04 section 7.18]. They suggested that UAVs need a Ground Operator to interpret for the UAV and intervene. In a telephone call with Parc Aberporth Operations Manager, it was confirmed 26
that recent UAV operations had been achieved by towing the vehicle out to the launch point, thus avoiding the issue, but that proposed UAVs had a taxiing capability and that it was considered that a Ground Operator would look after the vehicle in the confines of the airfield (on the ground or on Take-off up to 50ft) then hand over to the main GCS for the remainder of the sortie. In the longer run, it is perceived that new UAVs will require autonomous ground operations to maintain the airfield movement tempo at busier airfields - this may even prove safer than manual control, as some high profile manned aircraft accidents (such as at Tenerife) have unfortunately shown. The paragraph above noted that current UAVs generally use manual take-off and landing. In the very near future, automatic TO/L systems are expected to be introduced. [DeG04] and others suggest that Differential GPS (DGPS) will be a key technology, as plain GPS will not be precise enough. One last aspect of UAV airfield operations concerns landing at diversionary airfield - will they be able to cope? The ASTM [AST05, 2], in their study noted the lack of standards to define how airports should deal with UAVs, in the event that they became an unexpected diversionary. Suddenly, an airfield might find themselves having to cope with the various issues noted above. Again, I suspect that this is really an issue of inexperience: in most cases, operators will file a flight plan and declare the diversionary airfields that they may have to use. Just as a civil Boeing 737 operator would only nominate a known 737compatible airfield, the same would surely be true of a UAV operator, and part of planning will be to liaise and agree on diversionary procedures and facilities (as noted in 'Emergency procedures' above).
1.2.3 Collision avoidance The reader might wonder why there is a specific section on 'collision avoidance', when it seems that the majority of the other sections have already focused on safety issues relating to potential collisions. The reason is that, as Platt implies in his paper [PlP05], international regulators have followed a philosophy of layered defences to avoid collision risks. Platt talks of three layers that must be provided and prove independently effective (i.e. faults in one layer cannot be offset intentionally by dependence on another layer): 1. The outermost layer - strategic conflict management - is achieved through the overall structuring of airspace by type (to separate aircraft classes and capabilities) and use of ATM to maintain efficient flows and manage the overall traffic structure. 2. The middle layer is separation provision. This layer exists to ensure that separation minima are maintained if strategic management has been compromised. This is achieved through declared separation minima (to ensure adequately low risks), regulated Rules of the Air for flight planning and Rights of Way for airmanship, and specified equipment lists to ensure navigational accuracy and aircraft detection. 3. The innermost layer is collision avoidance. At this point, safe minima have been breached, and the successful outcome is simply to achieve a miss through emergency action. This is (currently) achieved for manned aircraft through visual lookout and gradual introduction of assisting systems such as Traffic Alert & Collision Avoidance Systems (TCAS). Layer 1 is strongest (i.e. it is mandatory) in controlled airspace (class A-E in the UK FIR - see 'Note on UAV classification' in the introduction to the Literature Review), and is advisory where available in Class F airspace. In Class G, the home of most General Aviation, conflict management relies on layer 2 initially, and if this breaks down, then layer 3 is required to independently maintain safety. UAVS issues pertinent to strategic conflict management and separation provision are discussed in the other sections of this report. This section mainly focusses on collision avoidance as defined above. 27
Ground Collision Avoidance Ground collision avoidance (or terrain avoidance) is somewhat the 'poor man' of UAVS literature, and not a lot is said about it in any detail. Perhaps this is because it is considered to be better understood, with more easily identifiable criteria drawn from manned aviation. The CAA in CAP722 [CAA04] merely state that an approved method of assuring terrain clearance is required, but do not give specifics. We could assume that the requirement is for 'equivalence' with methods in use in manned aircraft. This is supported by the EUROCONTROL position in [UTF04], which implies this by reference to existing Ground Proximity Warning Systems (GPWS). The Australian and Swedish regulations ([CAS04] and [Wik03] respectively) do not go into detail about terrain avoidance so much as population avoidance. Both establish restrictions for flight over populous areas; the Swedes justify this position with details of their calculations for acceptable levels of ground fatalities (see section 1.1.4). Most literature tries to lump ground collision avoidance into what they consider is the bigger problem of air-air collision avoidance. Whittaker [Whi05], DeGarmo [DeG04] and Platt [PlP05] infer that ground avoidance will be solved as part of the wider 'sense and avoid' debate (see below). I suggest that this is somewhat simplistic, because down in the detail, characteristics for ground / obstacle target detection will be very different from point air targets, and the technical solutions and airmanship requirements will be likewise quite different. Fairly simple ground collision avoidance may be achieved, for example, through GPS and terrain database use (such as existing GPWS) - and this may be achieved in the UAV, or possibly in the GCS by relating the UAV's telemetered position. Some discussion over the acceptability of such solutions is presented in section 1.2.2, under ATC Systems. Air-Air Collision Avoidance Airmanship & Situation Awareness We have already mentioned the role of procedures and regulations in the layered approach to conflict management, and this continues into the collision avoidance inner layer. The Joint European Task Force review the arrangements in [UTF04] - these are summarised here as: ICAO establish basic Rights of Way (RoW) for aircraft depending on their class, airspace and attitude; pilots are expected to respect these RoW using airmanship, in order to either stand on or take avoiding action as appropriate to the RoW. In the last-ditch event that the appropriate aircraft does not take action, the stand-on aircraft must take emergency evasive action anyway, to suit the particular collision situation. This implies that, in order to respect the RoW, the UAVS must be aware of its situation in terms of the factors that determine who has right of way, and be able to react accordingly. In CAP722 [CAA04], the CAA list a number of factors that affect the outcome in any particular collision avoidance scenario. The situation will vary depending on: whether all involved aircraft comply fully and correctly with the Rules of the Air; the controllability and manoeuvrability of each aircraft and their respective flight performance; the level of autonomy of operation and control (in terms of the involvement (or not) of a ground pilot). In general, these aspects for UAVs are discussed in sections 1.2.1, 1.1.1 and 1.1.3 respectively, but it is important to note their implications at this safety critical situation. Conspicuity - being seen In order that other aircraft may respect the UAV's position to the RoW, they need to be able to see the vehicle and its attitude. This issue is identified by the Swedish Aviation Safety Authority [Wik03]. Will other traffic be able to see the UAV? Will the UAV carry enhancing equipment (e.g. transponder, warning lights)? DeGarmo [DeG04] also identifies this
28
issue. Many UAVs are fairly small making them tricky to see, and even if seen can prove difficult for the other pilot to judge their distance and closure rate. Seeing and Reacting - Detect / Sense & Avoid The Rules of the Air set requirements for aircraft pilots to See and Avoid other aircraft according to the established RoW, as discussed above. Here is the crux of the issue - it is generally believed that the UAV-p cannot adequately provide this function, as he will not have the required field of view and because of the complexity of the data link and control latency ([LeT02]). Currently, there are no approved collision avoidance systems suitable for 'Sense and Avoid' (the non-human equivalent of See and Void) and no accepted criteria against which to develop such technology, and this is the main impediment to UAV integration into manned airspace ([Ste05]). The issues that lead to this state of affairs are discussed below. In CAP722 [CAA04], the CAA provide a list of 'Sense and Avoid' (S&A) factors, most of which are generally applicable to UAVS operation in all layers of conflict management. The document sets the requirement for a 'Method of sensing other airborne objects' but then goes on to say that it is not possible to define suitable criteria for a Sense and Avoid system, until suitable technologies and their capabilities start to emerge in more detail. The best that they can currently suggest is to seek an Equivalent Level of Safety as for current manned aircraft. Schneider [Sch04] on the other hand, pushes the US government to support development and validation of robust 'Detect, See and Avoid' (DSA) requirements first, before trying to develop technology solutions. Personally, I feel these things must happen in parallel requirements for specific classes of UAVs could be worked up through modelling, but need to be tailored with the art of the possible, as development of possible technologies yields information on likely sensor performance. In this way, an effective sense & avoid capability might be achieved by using a combination of methods, rather than coming purely from a requirement or single technology focus. More is discussed on criteria, below. Marsters, in his earlier attempt at defining UAV regulatory requirements [Mar03], notes the problems with setting the baseline as 'ELOS' to manned aircraft, due to the examples where this has gone catastrophically wrong in the past. He calls for UAVs to be equipped with the emerging technologies of the day - TCAS and GPS-based Automatic Dependence Surveillance - Broadcast (ADS-B). But this is only part of the problem solved. DeGarmo [DeG04 section 2.1.1] notes that such existing systems can help detect co-operative aircraft, i.e. those carrying the required systems and transmitters to make their whereabouts known: but to be allowed into all classes of airspace, UAVs will need to be able to sense and avoid non co-operative objects, such as most general aviation, microlights, even birds and ground obstacles such as masts. DeGarmo notes the activities of ASTM and RTCA to try and establish suitable criteria for such non co-operative S&A systems, to provide ELOS to manned aircraft (see section 1.2.1). The paper looks at some developing technologies, discussing aspects such as field of view, detection ranges, false alarms, and performance in reduced visibility (though how does this compare with the human pilot's capability in such conditions?). Conversely, it notes that, if the Sense & Avoid is not entirely provided on-board but requires interaction with the GCS, then there may be issues with decision making and data latency. This is a timely point to discuss the shortcomings of manned See & Avoid. As noted by Marsters, in his paper with Sinclair [Sin03], there is a useful consideration of manned See & Avoid, and reference to work on the shortcomings of the unaided pilot. Marsters and Sinclair argue that UAV Detect & Avoid (or Sense & Avoid) must outperform human equivalence to ensure safety - though a fair portion of this may come from the fact that technical systems will provide constant scan, rather than being distracted as the pilot often is. In their review of a number of studies, results were showing that the performance of an 'alerted pilot' averaged about 1.6nm detection range, while modelling of Global Hawk closing speeds,
29
manoeuvrability and datalink lags was suggesting a required detection range of ~7nm. This will vary considerably depending on the UAVS and whether the avoidance manoeuvre is initiated by the vehicle itself or by manned intervention, but show that a simple ELOS will pose some difficulties.
1.2.4 Security and safety There is no doubting the increased awareness over security issues that affects aviation generally, since the events of '9/11' in 2001. But some suggest that UAVs potentially pose an increased risk, due to vulnerabilities that we will look at below. Some have even suggested that UAVs have an added 'attractiveness' for malicious terrorist use, because of their unmanned nature [UTF04, 7.15]. Whether these suggestions are realistic or not, the fact is that security is a critical issue that UAVs will have to prove they have mastered, before being allowed into potential threat areas. The suggested areas of concern all stem from the expanded system boundary that encompasses the UAVS as a whole (which we have already discussed in section 1.1.2). Let us now look at the impact of the external, malicious world on the system of systems. Jamming of Navigation Systems Although talking primarily about military applications, the Defense Science Board study [Sch04] raises the valid point that most current generation UAVs use GPS based navigation, and urges the fitting of jam-resistant GPS as a matter of course. Unless suitably hardened, civil UAVs could likewise suffer loss of their sole position fixing capability, with potentially critical consequences. Communications Signal Security As the Joint European UAV Task Force note in [UTF04, 7.15], UAVs are currently (and for the foreseeable future) dependent on the integrity of the command datalink (see discussion at section 1.1.2). Maintaining integrity from blunt jamming tactics down to more subtle spoofing or stealing of control will have to be addressed. DeGarmo [DeG04, 2.2.2] suggests that modern encryption techniques and user authentication methods can help with the latter, but would not be able to assist against high-power jamming. He also suggests (sensibly) that UAVs will benefit from other signal-based industries which are working to obtain secure communications techniques. None of the papers reviewed discussed the basic visibility of the signal to unwanted parties an aspect of security can be to use specific frequencies to minimise 'broadcast' of the UAVS operation, or frequency-agile systems that both minimise possibility of detection, and reduce the effect of jamming to those frequency segments in-band. Ground Infrastructure This aspect relates to the simple physical security of the ground-based elements, of which there may be many in an extended system of systems. DeGarmo [DeG04, 2.2.1] states that this has seen little interest shown by UAV operators to date, but could be a major and direct way to affect or overthrow the control of the UAV. This would be particularly true for mobile systems (having less opportunity for fixed barrier based security); and for distributed systems with control elements located at various points around the world (such as recent US Predator operations in Iraq, controlled via datalink from Nevada but with Iraq-local control elements involved also). Flight Planning and Data Security DeGarmo [DeG04 2.2.3] goes on to consider the security implications of the data elements of the UAVS. All manner of digital data is involved in a successful UAV operation, from the databases used to plan missions and avoid terrain, to the specified flight plan itself, the coding of ground and UAV control functions, etc. The US (and UK CAA repeat the 30
requirement in [CAA04]) require security of systems to detect and counter all attempts to corrupt critical systems and data before / during / after loading.
1.2.5 The Human Element There are human aspects cutting across many of the other issues we highlight - in ATM (section 1.2.2), collision avoidance (1.2.3), security (1.2.4), and notably in our discussions over UAV accident rates (1.1.4) and the man / machine boundary of autonomy (1.1.3). In this section we focus specifically on the human element of the UAVS. From very general Human Factors issues, we extend the discussion to cover organisational issues and then personnel qualification and skill levels. Human factors We have already looked at UAV accident rates, in section 1.1.4. There, we noted DeGarmo's assessment [DeG04, 2.1.3] that Human Factors (HF) accounted for some 17% of the UAV accidents where information was available. He commented that this was lower than the comparable figure for manned aircraft (~80%) and seemed to be proportional to automation levels and (where responsibility lay with the UAV-p) the datalink update rates. The dominant Human / Machine Interface (HMI) aspects related to: the ground 'cockpit' environment; the available cues from the UAV and displays; the UAV-p skill levels; levels of situational awareness and a suggestion that the low personal risk to the UAV-p removed him somewhat from trying to recover difficult situations. Schneider [Sch04, chapter 3] suggests that the majority of UAV mishaps were due to the relatively low experience level of operators & maintainers, and LaFranchi [LaF05-2] echoes this with his account of Canadian Army experience with deploying the Sperwer system in Afghanistan. After only a short training course, they found themselves having to adapt their training to a new and hostile environment. In the second of 2 crashes (in 3 months), the GCS took manual control on approach to land and flew the vehicle into a ridge, in spite of a ground proximity alarm sounding for some 30 seconds before impact, and there being 4 personnel in the GCS including a certified manned aircraft pilot. The JAA / EUROCONTROL Task Force cover HF as a specific discussion topic, focusing on the HMI ([UTF04, section 7.10]). They saw issues with the lack of physical (and particularly visual) cues that allow the pilot on board to recognize some failure scenarios and to decide the suitable decisions and actions to take. They were also concerns at the current shortage of experience in civil UAV operations, which compares well with Schneider's and LaFranchi's concerns noted above. However, Williams [Wil04] believes that it is difficult to draw general Human Factors conclusions, because the HMI is so very different between systems. He could not find consistent HF causes between the US military accidents that he analysed (see more general discussion in section 1.1.4). He does, though, raise two interesting points at different ends of the human factors / automation / airmanship spectrum: o
Predator is a UAV which acts very much as an RPV - it is 'flown' by a pilot using cockpit-type controls from the GCS, using a camera in the UAV to present a 30 degree forward view to the pilot. Predator suffered the highest percentage HF accidents (~65%) of the 5 systems he analysed.
o
Global Hawk is another US Air Force UAVS but is very automated with the UAV-p merely monitoring the aircraft progress. Global Hawk had relatively low HF accidents (~30%). However, the system is automated through fully pre-programmed missions from take-off to landing (rather than autonomous decision making) and the planning for a mission can take up to 270 days to achieve. Hence there have been HF 31
accidents caused by small but significant errors buried within the complex mission planning. Human Factors is a tricky issue for UAVS, due to the complex system boundary, and in particular due to the growing influence of autonomy. In part, this is necessary to offload the pilot and allow aspects such as multiple UAV operation (see 'autonomy v ground control' in 1.1.3). Nevertheless, we should not forget that accidents can occur when the human operator does not understand what the highly automated system is doing, and tries to override it with disastrous consequences. This key issue is discussed in several York Advanced MSc course modules (Human Factors Engineering (HFE) and Foundations of Safety Engineering (FSE) especially). Organisation In section 1.2.1 (Regulation etc), we noted the EASA drive [EAS05] for 'Total safety' as shown in Figure 1.2.1a. This clearly indicates the involvement of the operating organisation and personnel, in the safe maintenance and operation of the UAVS. In 1.2.1 we discussed the push for 'equivalence' with manned aircraft based regulation, where here we try to discuss the inherent safety issues. Marsters [Mar03] assumes that an applicant for a UAV clearance will have already obtained a UAV Operating Certificate covering global activities for his system, with an approved organisation and competent staff / operators, vehicle safety history and analysis, design standards, operating manuals, etc. He does not explicitly discuss why these are required. EASA and the Joint European Task Force discuss organisations [UTF04 section 6.3.3.3] but do not get beyond the requirement for equivalence to manned systems and application of licencing regulations. The CAA likewise in [CAA04] state requirements against existing regulation. The Swedish Aviation Safety Authority also discuss organisational requirements [Wik 03], initially suggesting parity between UAV and manned aircraft organisations, but then suggesting that there could be flexibility - the UAV system operation organisation requires proportionality with the UAV system complexity and operating conditions - simpler systems and environments would allow simpler organisations. Wiklund suggests that the organisation will probably vary at different stages of a project. "During the design stage the emphasis may for example be on technical competence with advisory operational competence, while in the test stage further practical operational competence will be added and in the operational stage the emphasis will be on practical operating competence." It is clear that the drive here is for competence within the organisation, with experience, to be able to recognise and resolve the safety issues arising at that point in the programme. Schneider [Sch04] sees the organisation playing a key role in addressing the HF safety issues noted above, due to low experience among UAVS maintainers and operators. He pushes the US government that operator and maintenance organisations should explicitly plan for the recruitment, training, career development of personnel to improve retention of the experience necessary to operate UAVS safely. Schneider suggest that military organisations currently do the very opposite, by forced posting and promotion of experienced operators out of the organisation. From the literature reviewed, there did not seem to be specific organisational issues related to UAV operation and maintenance, other than that noted by Schneider, above. Else, the literature was driven by the requirement for equivalence with manned aircraft, on the readacross assumption that a competent organisation (with competent personnel and appropriate procedures and plans) supports the overall aims for safe UAV operation and maintenance. However, from our discussion over aspects such as ATM (1.2.2) and the complex system boundary (1.1.2), I would propose that there could be issues related to the transfer of data between organisations, to support accurate mission planning, establishment of appropriate
32
emergency procedures, etc. What is a safety issue is thus the complex organisational interfaces within the overall system of systems. Suitably Qualified and Experienced Personnel Experience levels among personnel are clearly an issue, as noted in both sub-sections above. Here we discuss the qualification aspect of their necessary competence. The CAA in CAP722 [CAA04] discuss the UAVS 'crew' consisting of a UAV commander and (potentially) one or more UAV pilots (UAV-p). While the UAV-p is a qualified person who is actively exercising remote control of a non-autonomous UAV flight, or monitoring an autonomous UAV flight, the commander is the person charged with overall responsibility to the CAA: he assumes the same operational and safety responsibilities as the captain of a piloted aircraft performing a similar mission in similar airspace. Hence the commander must be qualified to meet manned aircraft equivalents for the airspace and meteorological rules that the UAV will operate within, while the UAV-p may be less stringently qualified to meet the training, experience and currency requirements set out by the organisation. This would allow UAV operation in accordance with current military training regimes, where the UAV is controlled by an operator who may not have manned aircraft qualifications but who can direct the UAV to a specific location (rather than fly it manually using traditional controls) - but would require an overall commander to oversee and ensure safe operation in accordance with the Rules of the Air. The Australian Civil Aviation Safety Regulations in CAS 101 [CAS04] have rolled out a similar view of pilot certification. The issue here might be how many UAV-p could safely operate under one commander, while ensuring safe operations. The issue is heightened when a single UAV-p could conceivably be controlling more than one UAV, due to the apparent simplicity of the interface. DeGarmo [DeG04, section 2.4.5] picks up on these aspects. He says that UAV-p certification is not simple, because of the variation in UAVS and their operating intent: simple UAVs may act like model aircraft, staying within visual contact; others will be operated beyond Line of Sight, possibly in swarms of multiple UAVs; some will require direct pilot-like input as RPVs; others will have automated systems requiring only location designation, or even be operating near-fully autonomously. While the UAV design will force part of the training regime, predominant factors might be the outside world, e.g. the operational environment (other traffic, ATC, etc). DeGarmo suggest that a similar licencing system could be operated to that currently for aircraft pilots, where specific ratings are earned appropriate to the type of aircraft being flown and the type of operation to be undertaken. This would, he says, require extensive tailoring to suit UAV differences (as discussed in 1.1.1). DeGarmo finishes with a discussion of the role of the UAV-p compared to the commander (or controller as he calls it). While this is a potential solution to the training / skills issue, he implies that it is another interface that would need careful implementation.
1.2.6 Public perception of UAV safety As we touched on briefly in Section 1 under 'Current and Future Directions', the pull of the market for civil use is still uncertain, and gaining public acceptance of the safety of UAVs will be an important part of any success. So what is the public perception? The CAA has, so far, taken a 'gut instincts' view that the perception is at best neutral and at worst fearful / mistrusting. Whittaker in [Whi05] looks briefly at potential ground and air collisions featuring UAVs: in the former, he contrasts the manned aircraft ground collision headlines ("AIRCRAFT CRASHES NEAR SCHOOL - Pilot swerves into trees to avoid risk to children") with those for a UAV ("TERROR AS GUIDED MISSILE ALMOST HITS SCHOOL Shocked parents demand Public Inquiry"). For collisions in the air between UAV and manned aircraft, he takes the view that such occurrences are seldom survivable for the people involved, and the unmanned aircraft will doubtless be blamed by the public, no matter
33
what the reality of the situation. In essence, he is talking about a media led onslaught, (mis-) informing a public with no alternative positive views of the benefits of UAVs. DeGarmo [DeG04, Section 2.5.2] takes a broader view. He proposes that the public can be courted with a reasoned debate over the benefits that can be gained (i.e., greater security, improved information, more services, lower costs) versus the potential costs (i.e., increased noise, pollution, privacy concerns, safety risks, delays) and that this 'marketing' will be a key requirement to gain acceptance and enable market forces. However, he also notes that such a build up of trust will take time and be fragile, as it would be easily damaged by any high profile accident. He quotes a public opinion survey of air users in 2003, which stated that 68% were happy with the idea of UAVs for cargo and commercial use, but only a small percentage would be happy to allow unmanned passenger-flying aircraft. While this, at face value, suggests that people might be happy with the risk associated with UAVs flying overhead, to me it implies that, as soon as the risk might actually impinge on them, their acceptance drops massively. In the end, then, DeGarmo under the microscope brings us to the same conclusion: that in the event of an accident, the media will hold sway over any expert discussion over the significance of risks posed by UAVs to the public, be they in the air or on the ground. UAVs will have to prove themselves 'safer than safe' or face a similar bad press over safety as the rail industry, say. However, there is some hope that the public will have been educated beforehand, and the perceived benefits of UAVs will ultimately help restore confidence more quickly.
34
1.3 Summary of UAVS Safety Issues 1.3.1 Review of current UAVS safety issues relating to integration into unsegregated airspace Sections 1.1 and 1.2 have covered a lot of issues with respect to UAV safety, and it is worth summarising these here, before proceeding further. Note that ** indicates an issue that has been taken forward in this project, as discussed in ‘Focus for Project Development’. (1.1.1) Impact of the Variety, Roles and Performance of UAVs 1. UAV differences may introduce additional, unexpected hazards, for regulators trying to pigeon-hole them into manned aircraft categories **. 2. UAV performance differences from manned aircraft make them difficult to manage in a stream of manned aircraft traffic **. 3. UAV roles and missions make their behaviour unpredictable for manned aircraft traffic / ATC **. 4. UAV 'ad hoc' launch sites cause unexpected insertion into manned traffic. (1.1.2) The complex system boundary for UAVs 1. Confusion over what the safety critical elements of a UAVS are (and then how to regulate them, if not currently covered by manned systems): elements such as datalinks, GCS, data flow around the UAVS, data sources outside the UAVS push beyond current manned aircraft experience. 2. The need for reliable datalinks (including Over the Horizon), teamed with the requirement to deal safely with datalink failure / corruption. 3. UAV sensors, datalinks, will compete for limited RF spectrum availability or face interoperability / interference problems. 4. Use of Beyond Line of Sight datalinks to overcome terrain masking extends the system boundary and hence the number of critical systems incorporated within the UAV system of systems. (1.1.3) UAV autonomy - technology, predictability, complexity 1. Current in-use definitions of autonomy level are over simplistic; but there is confusion over what factors give a better indication of system authority. Some are very broad, making it difficult to arrive at a clear indication (clear indication of autonomy level is called for in various papers, to give visibility over who is in charge of the UAV in case of emergency action being required). 2. Environment and mission context are proposed as drivers for required levels of autonomy - how will the system respond if pushed outside its parameters? 3. Autonomy level should be varied ("traded") to suit the operator's needs throughout the mission - will the operator know the extent of his control? Will the needs of the operator align with the needs of the regulators to enforce human control? 4. 'Agent Based' autonomous control introduces new areas of uncertainty: a. These are novel application in air vehicles and hence there will be issues of expertise, trust and clearance b. They require accurate capture and specification of the 'agent' behaviours beforehand - issues of knowledge acquisition (and requirements elicitation see York module on RQE). 35
c. There will probably more be than one 'AI' method used to implement the decision making, and these will introduce new issues of architecture and integration. 5. Autonomy through software will entail solving the usual issues over system predictability. In particular, there may be difficulties trying to clearly separate safety critical elements from other functionality. 6. The knowledge, judgment and skill ('airmanship') necessary to fly predictably and yet flexibly to react to changing situations (such as weather) may be difficult to automate, or even specify. 7. UAV autonomous decision making must somehow be matched to expectation of ATC decision making tools (such as used to effect TCAS). 8. UAV actions in the event of datalink failure need to be predictable and dependable (for ATM interaction), yet airmanship demands the ability of flexible response **. (1.1.4) Accident rates and reliability - UAV airworthiness 1. The catastrophic failure rate for UAVs is currently too high. 2. There is little reliable accident data for UAVS occurrences - none sourced outside military programs, research-based systems, in high risk (non-civil) usage, and even that data is from a small sample compared to manned aviation data availability. 3. UAVs lack available, reliable system components (they currently have to use research-standard equipment or COTS items operating outside their intended environment). 4. UAVSs have not currently been designed, fabricated and maintained to manned aircraft levels **. 5. It is difficult to define what the 'Equivalent Level of Safety' or balanced safety targets should be for UAVSs. a. Difficulties in identifying the equivalent class. b. Differences in the lethality of UAVSs, from manned aircraft, and between different UAV classes. 6. To improve airworthiness, there are suggestions to apply FAR 1309-type philosophy to UAV flight-critical system safety design, and referrals to ARP 4761 as a suitable approach for safety analyses, but that these may require some amendment to suit differences in UAVSs **. (1.2.1) Regulation, Certification and the Drive for Standards 1. Current UAV regulation demands 'equivalence' to manned systems, without being able to address UAV differences. 2. There are proposals that a 'total system' approach is required to address UAV-related regulation, but that airworthiness is currently regulated separately (by EASA) from operations, maintenance, ATM and airports (by national bodies such as CAA) **. 3. How to certify UAVSs? Studies suggest that, while a 'safety targets' [safety case] approach would be easiest to apply, it is necessary to apply a standards / requirements based approach to be consistent with ICAO rules, and because different regulators [see ‘2’ above] force separate consideration of design from operation - but can the UAVS design and operation be cleanly separated without missing potential safety risks?
36
4. EASA suggest application of a .1309 safety assessment philosophy, to address novel aspects of UAVS design [refer with 1.1.4 item 6, above] **. 5. To apply standards-based certification requires standards to be defined for clear, safety critical design aspects, but these are difficult to define for UAVS [refer to 1.1.2 item 1, above]. 6. Regulators wish to apply existing certification for operations (such as maintenance, flight operations) 'wherever possible', but their own studies show that many aspects of UAVS operations are not adequately covered, mainly because the scope of UAV work lies far outside the aspects that the regulation was intended to cover. 7. Several international organisations are pushing to establish consensus-based standards, but there is currently a competitive spirit between them, which may lead to several conflicting standards. (1.2.2) ATM interaction 1. Because of current segregation of traffic, very few UAVs have interacted with Air Traffic Control (ATC) and the ATM system; hence it is difficult to predict what the real impacts might be**. 2. Regulators and ATM providers demand that UAV operation will be 'transparent' to ATM services, that UAVs will "...comply with any air traffic control instruction or a request for information made by an ATS unit in the same way and within the same timeframe that the pilot of a manned aircraft would." Yet there are many ways in which UAVs will react differently from manned aircraft [see 1.1.1 items 2, 3, 4 above, as well as the following items]. 3. Regulators require specific lists of equipage for flight in controlled airspace, but (most) current UAVs lack the available space, payload or power to carry them all. 4. ATC controllers may require additional data feeds to inform them of UAV specific status (such as autonomy level), which conflicts with the drive for ATM transparency. 5. How will ATC controllers handle potential 'swarms' of UAVs under a common control node? 6. High powered ATM RF equipment may pose interoperability problems for some UAVSs [especially with reference to the crowded spectrum in 1.1.2 item 3]. 7. UAVs will ultimately require capability for speech recognition and voice response as part of their autonomous behaviour. 8. Existing ATM routes and procedures have been built around manned aircraft: it is suggested that, for UAVs that don't fit the pattern, they will either have to be excluded (and forced into general airspace) or have new routes / procedures to accommodate them. 9. For lighter UAVs subject to wake turbulence, current vertical separation minima may be inadequate to allow safe flight. 10. The impact of UAVs (their numbers and long endurance) on air traffic, and its effect on ATC controllers and systems overall, has not been adequately modelled thus far. 11. ATM procedures want to hard-define procedures and flight termination areas to deal with UAV particular risks and emergencies, but the actual procedures may need to be varied to best suit specific systems (e.g. highly autonomous systems may be safer to fly on, rather than flight terminate, in response to the particular risk of datalink failure). 12. There are concerns over UAV operations on the ground, on shared airfields associated with taxiing into obstructions / other aircraft, and being able to recognise and respond to visual signals that are used in airfield operations**. 37
13. Diversionary airfields may pose additional problems for UAVs, if the airfield is not adequately prepared to handle UAV traffic, or appropriate navigation facilities (such as D-GPS) are not available to provide sufficient accuracy for auto-land systems . (1.2.3) Collision avoidance 1. 'Approved' methods of terrain avoidance have yet to be identified for UAVSs. 2. Most literature sources imply that terrain avoidance will be solved as part of the airborne collision avoidance / Sense & Avoid effort - but characteristics for ground / obstacle target detection will be very different from point air targets, and the technical solutions and airmanship requirements will be likewise quite different. 3. In order to respect the Rights of Way, the UAVS must be aware of its situation in terms of the factors that determine who has right of way, and be able to react accordingly. But each situation will be different depending on: whether all involved aircraft comply fully and correctly with the Rules of the Air; the controllability and manoeuvrability of each aircraft and their respective flight performance; the level of autonomy of operation and control (in terms of the involvement (or not) of a ground pilot) [refer to autonomy specification, in 1.1.3 item 6 above]. 4. Due to the size, role and performance of UAVs, will manned aircraft pilots be able to spot them in order to respect the Rights of Way? 5. Some authorities believe that it is not possible to set criteria for Sense & Avoid systems - they must develop once the available technology performance and UAV systems definition become clearer. But others believe that the technologies for Sense & Avoid should not be developed until the necessary criteria are defined. Currently, there are no defined criteria. 6. Current technologies such as TCAS cannot be relied on, as they require all traffic to co-operate in carrying interrogating equipment. UAVs in general airspace must have Sense & Avoid that can detect non-cooperative traffic (which manned aircraft currently attempt to do using the pilot's visual acuity). 7. The nearest thing to S&A criteria is currently to establish 'equivalent level of safety' to manned aircraft. But high profile accidents have shown the fallibility of human visual collision avoidance. Also, initial modelling has indicated that human eye perception ranges fall short of the required detection range to avoid collisions. (1.2.4) Security and safety 1. UAVS dependent on GPS based navigation may be susceptible to jamming unless jam-resistant systems can be fitted. 2. The command datalink significantly extends the responsibility to ensure safe control of the UAV, and practical solutions to avoid jamming, spoofing or stealing of the datalink need to be found. 3. The use of ground-based control elements (some distributed globally) extends the need for physical security of the system, beyond the airframe considerations of manned systems. 4. The data elements of the UAVS present a key security issue, to avoid corruption of mission planning, airspace and terrain databases, flight programmes, GCS functions etc.
38
(1.2.5) Human factors, Suitably Qualified & Experienced Personnel (SQEP) and organisations 1. Human / Machine Interface (HMI) aspects affecting UAV flight safety exist relating to: the ground 'cockpit' environment; the available cues from the UAV and displays; the UAV-p and maintainers skill levels; levels of situational awareness and a suggestion that the low personal risk to the UAV-p removed him somewhat from trying to recover difficult situations. 2. Human factors issues are difficult to analyse for UAVSs, due to the wide variety of HMI currently in use, and big questions over the interaction between the human operator and the autonomous level of the system [refer to 1.1.3 item 3 above] 3. There is a huge assumption that a UAV Operating Certificate covering global activities for the UAVS system, with an approved organisation and competent staff / operators, vehicle safety history and analysis, design standards, operating manuals, etc, will provide the main route to a safe UAVS operating within manned airspace. Is this tenable? 4. Current military organisations force regular rotation of personnel, so that there is not adequate build up of UAVS operating experience within the organisations. 5. The complex network of organisations, running the UAVS system of systems, control safety-involved data interfaces for the UAVS. This network is not adequately discussed or understood in the literature reviewed. 6. Where several UAV-ps (with lesser skills) may be under control of an officially recognised UAV Commander, what issues influence how many may be safely controlled without compromise? How does this vary with UAVS complexity / role / interface / autonomy levels? While regulators depend on the skills and experience of the UAV Commander, how does the interface between Commander and Pilot(s) affect the efficacy? (1.2.6) Public perception of UAV safety 1. CAA perspective is that airborne collisions are seldom survivable, but other agencies are pursuing UAV characteristics (such as frangible materials) such that collisions may not be so catastrophic. Is this approach practical in terms of safety, and could it influence public opinion sufficiently? 2. How do media perspectives of UAV safety compare with actual public opinion, and with achievable levels of safety for UAV systems? 1.3.2 Focus for project development From a review of the issues above, and the overall aims of the project, several options existed to take this particular study forward. After much reflection, it was decided that there was a common core of issues that could be addressed, related to the need for: A. A better understanding of what the root hazards associated with UAVS integration are. [Predominantly 1.1.1 issues 1-3; 1.2.2 issues 1 and 12] In exploring this aspect, the project would need a robust Hazard Identification (HazID) methodology, and understanding of the system(s) being assessed. Thus, it could also contribute to other, related aspects along the way, in particular: B. Can a .1309 / ARP4761 safety assessment approach be used for UAVS, to identify hazards for solution during design / manufacture / operation? [Relating to 1.1.4 issue 6, 1.2.1 issue 4] This approach thus relates to a number of the issues shown above - these are indicated with a double asterisk **. Along the way, it was hoped that the study would also provide useful information on other aspects, such as those on system complexity in section 1.1.2, but these would not be the primary focus. 39
PART 2 - DESIGN AND BUILD: MOVING FORWARD IN UAVS HAZID The intent of Part 2 is to identify a robust method for Hazard Identification (HazID), based on ARP 4761. This would be used in Part 3 to assess a UAVS case study and hence investigate the root hazards of integrating UAVS into manned airspace. This part of the project can be likened to Design and Build for a product-based project. We require a clear set of Design Requirements, to which a sound methodology can then be built. o
In general, the design requirements were outlined at the end of section 1.3, but there was a need to define the full requirement list more robustly. Section 2.1 assesses the existing ARP 4761HazID methodology for its usability for UAVS assessment, and hence establishes where improvements are required.
o
Section 2.2 then works through the requirements, to establish a proposed improved methodology for UAVS HazID.
2.1 Assessment of ARP4761 Usability for UAVS HazID 2.1.1 Introduction ARP 4761 [SAE96] has the following scope: "This document describes guidelines and methods of performing the safety assessment for certification of civil aircraft. It is primarily associated with showing compliance with FAR/JAR 25.1309. The methods outlined here identify a systematic means, but not the only means, to show compliance. A subset of this material may be applicable to non-25.1309 equipment. The concept of Aircraft Level Safety Assessment is introduced and the tools to accomplish this task are outlined. The overall aircraft operating environment is considered.” Clearly, the current intent is to support safety assessment of civil (predominantly heavy transport) aircraft. In has been reviewed for its applicability in supporting safety assessment for UAVS certification, primarily for the Hazard Identification elements at this stage. The full review is at Annex A to this report; a summary of the issues identified is presented below. At this point, the focus has been on hazard identification through Functional Hazard Analysis (FHA); only a cursory look has been taken at the lower-level Preliminary System Safety Analysis (PSSA) and System Safety Analysis (SSA) elements.
2.1.2 Safety Objectives Safety objectives and criteria are drawn in from FAR / JAR 25.1309 (becoming EASA CS.25.1309 in Europe). These talk in terms that are focused on manned, large aircraft airworthiness - for example, a Catastrophic consequence is defined as "All failure conditions which prevent continued safe flight and landing" with a target probability of better than 1 in 10-9 per flying hour. For airworthiness considerations for UAVs, criteria need to reflect the variety of UAV systems at least in terms of their lethality, such as the variation between transport and smaller aircraft in 25.1309 and 23.1309 from 1 in 10-9 to 1 in 10-6 per flying hour for catastrophic occurrences.
40
Criteria descriptions need to reflect UAV potential occurrences, such as those proposed by the JAA / EUROCONTROL Joint Task Force in [UTF04 chapter 7.5] - for example, they suggested modifying the catastrophic definition to "UAV’s inability to continue controlled flight and reach any predefined landing site". For 'total system safety' as required by EASA (see section 1.2.1), rather than just airworthiness, the criteria need to reflect occurrences that compromise safety through ATM or operational context. EUROCONTROL have established related (but different!) criteria that they insist are applied where an occurrence could affect the ATM environment, through EUROCONTROL Safety Regulatory Requirement 4 (ESARR 4) [EUR01].
2.1.3 'Aircraft Level' and 'System Level' FHA [SAE96]proposes that Functional Hazard Assessment (FHA) be carried out at what it calls the 'Aircraft-Level', then lower-level 'System-Level' assessment once the design work starts in earnest. If the 'Aircraft Level' is to equate to the UAVS, then care / guidance is needed to address the complexity of the system: o
The extended critical boundary (for elements such as the Ground Control System (GCS) and mission planning?).
o
The people and procedural elements.
How should the System of Systems or 'super-system' elements be considered? There is some reference to looking at 'exchange functions' (see below) but not in sufficient detail to define and address these critical interfaces for the UAVS.
2.1.4 FHA Process: [SAE96] describes how "The FHA process is a top down approach for identifying the functional failure conditions and assessing their effects. This assessment is made in accordance with the following processes.” [Square brackets refer to further discussion of each aspect in later paragraphs]: 1. "Identification of all the functions associated with the level under study (internal functions and exchanged functions).” [Function Identification] 2. "Identification and description of failure conditions associated with these functions, considering single and multiple failures in normal and degraded environments.” [Identification of Failure Conditions] 3. "Determination of the effects of the failure condition.” [Identifying and Managing Effects] 4. "Classification of failure condition effects on the aircraft (Catastrophic, SevereMajor/Hazardous, Major, Minor and No Safety Effect). [Identifying and Managing Effects] 5. "Assignment of requirements to the failure conditions to be considered at the lower level.” [FHA Outputs] 6. "Identification of the supporting material required to justify the failure condition effect classification.” [FHA Outputs] 7. "Identification of the method used to verify compliance with the failure condition requirements." [FHA Outputs] 41
Function Identification: o
Source data requirements for input to the 'aircraft level' FHA assume a single, homogenous aircraft. o
This does not reflect the more complex UAVS structure.
o
It does not draw out the more complex interfaces with the wider SOS.
o
The 'Aircraft level' Internal Functions list guidance does not reflect the more complex UAVS structure. These may vary with the initial design assumptions over the UAVS overall architecture.
o
The aircraft-level Exchanged Functions list assumes a simple interaction with the outside world - this area requires careful guidance for the UAVS to ensure that the interfaces with the wider System of Systems (SoS) are adequately assessed for exchanged functions.
o
Flight Phases need guidance to ensure they are adequately defined for the UAVS. UAVS missions are more complex and variable than those for transport aircraft (around which [SAE96]is based).
Identification of Failure Conditions: o
o
New and different Emergency and Environmental Conditions are likely to be required for UAVS considerations. o
Environmental conditions and events may come from the more extreme climatic or mission conditions they experience, due to the unusual performance and roles they undertake.
o
Particular Emergency conditions will be applicable, from both regulatory and system architecture sources, such as datalink failure response.
There will be new types of single functional failure, but potentially many new multiple failure conditions to consider, due to the extended system and the wider SoS. More care will be required to ensure all credible combinations are considered.
Identifying and Managing the Effects of the Failure Conditions: o
For UAVS, Flight Phases and other sources of mission context will be critical in evaluating the consequential effects of failures on other airspace users or the overflown public. The loss of the UAV itself is not as significant as hull loss for a transport aircraft; instead, it is the second tier effect on other persons that is crucial, and that is dependent on where the UAV is and what it does when the failure occurs. ARP 4761 does not adequately support the significance of establishing this mission / environmental / ATM context.
FHA Outputs: o
[SAE96]proposed outputs seem appropriate at this point, but would need to be tested more thoroughly through actual input to the PSSA process.
2.1.5 Overall Applicability of ARP4761 for UAVS use The intent of ARP4761 to support the safety assessment (and hence clearance) of novel aircraft systems remains good. If the issues identified above can be addressed, then the revised framework should equally support safety assessment and clearance of UAVS.
42
2.2 Modifying ARP 4761 FHA for UAVS Use Each of the areas of ARP 4761 FHA requiring modification has been worked through in turn, to arrive at a justified, proposed revised HazID methodology. Key elements of the proposed methodology are shown in bold, italicised text. It is worth including a note here on the use of Functional Failure Analysis for FHA. Other forms of FHA are available, such as HazOp, Structured What If technique (SWIFT) et al (see [HRA03 session 12] for further guidance). However, it was decided to continue on the basis of Functional Failure Analysis (FFA), in order to conform with the basic process behind ARP 4761. It is a sound method for initial hazard investigation, where the design is still in its infancy but its purpose can be identified; and it is an accepted method recognised for certification through previous use of ARP 4761 and ARP 4754. To abandon FFA for another method at this stage would have required strong reasons – and none were identified at this early stage of investigation.
2.2.1 Derivation of Safety Criteria and Objectives for UAVS Application Safety Criteria We need to define suitable safety criteria in order to assess the effects and consequences of potential UAVS hazards. It is important to note that safety criteria have been separated from safety objectives - the latter are considered later in this section. Our focus here is how hazardous effects are to be defined. The first consideration is "who is likely to be affected by the UAVS". A quick review of existing airworthiness criteria such as in AC 23.1309 [FAA99] leads us to the following traditional parties: o
Passengers of the vehicle? NO, this should not be an issue for a UAV.
o
Flight crew - NO (but possibly indirect effects on UAVS operators?).
o
The air vehicle itself
ARP 4761, looking to support ARP 4754 (and hence EASA CS.25.1309) focuses on this list, to give a set of airworthiness criteria. It can be argued that, if the aircraft is kept safely in the air, then the safety of the 3rd parties on the ground is necessarily protected. As noted in section 2.1 of the report, EUROCONTROL suggested modifications to these criteria to make them more UAVS applicable. Hence a modified set of airworthiness criteria has been drawn together as shown in Table 2.2.1(i) below:
43
- Slight reduction in safety margins (e.g. loss of redundancy)
- Significant reduction in safety margins (e.g., total loss of communication with autonomous flight and landing on a predefined emergency site)
- Controlled loss of the UAV over an unpopulated emergency site, using Emergency Recovery procedures where required.
UAV's inability to continue controlled flight and reach any predefined landing site
Catastrophic - All failure conditions which prevent continued safe flight and landing
Catastrophic
44
Table 2.2.1(i) - Airworthiness Failure Condition Severities (after [SAE96], with additions from [UTF04] as noted)
Proposed UAVS criteria (taken from UAV Task Force [UTF04])
Failure Condition FAA Minor Major Severe Major Severity Classification JAA Minor Major Hazardous Existing Failure - Significant reduction in safety margins or - Large reduction in safety margins - Slight reduction in Condition Effect functional capabilities or functional capabilities safety margins criteria - Slight increase in crew - Significant increase in crew workload or - Higher workload or physical distress such that the crew could ( FAA & JAA / EASA) workload in conditions impairing crew efficiency not be relied on to perform tasks accurately or completely - Some inconvenience - Some discomfort to occupants to occupants - Adverse effects upon occupants
While it was tempting to modify the criteria further, such as to include factors for UAVS operators’ workload under ‘Major’ and ‘Severe Major’, it was decided to leave the criteria alone at this stage. The baseline FAA / JAA criteria are well established to support regulated requirements; similarly, the UAV Task Force criteria were arrived at by a multi-national team and, it is assumed, have reached a high level of consensus. With this in mind, it was felt better to try out the criteria first, so that if proposed changes were found necessary, they would be underpinned by a demonstrable need to overcome specific shortcomings. The domain is slow to change (as we have seen evidence for, throughout section 1). That said, the criteria above do provide a very airworthiness-centric view. Looking at a wider requirement for safety leads us to the following affected parties, additionally: o o o
3rd parties on the ground - the overflown public. 3rd parties in other aircraft - in the air or on the ground at airfields. ATM personnel
It could be argued that, in providing criteria aimed at keeping the aircraft reliably in the air, the requirements of the overflown public are met (especially as the [UTF04] criteria include consideration of whether the vehicle can reach an unpopulated site) - this is consistent with the view that UAVS must meet an Equivalent Level of Safety to that for manned aircraft, and the criteria above are set for manned aircraft. What then should be done about the second two parties, other aircraft occupants and ATM personnel, where the criteria currently say little specifically applicable? As noted in section 2.1, EUROCONTROL are insistent that their criteria must be applied in all instances where the ATM environment may be affected. Although the criteria are focussed on applications for ATM system developments, it can be seen that they would be applicable for a UAVS and particular concerns over manned aerospace integration. The criteria are shown in Table 2.2.1(ii) below:
45
Severity 3 - Significant Incidents
Severity 2 - Major Incidents
Severity 1 - Accidents
46
Table 2.2.1(ii) - EUROCONTROL ATM-Focused Separation / Collision Safety Criteria (from [EUR04])
Note: my substitution of [UAVS] for flight crew references.
- 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).
- Large reduction (e.g., a separation of - Large reduction in separation - One or more catastrophic less than half the separation minima) (e.g., a separation of less than accidents half the separation minima), in separation with [UAVS] crew or ATC controlling the situation and able without [UAVS] crew or ATC - One or more mid-air fully controlling the situation or collisions to recover from the situation. 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 (or when an avoidance action recover from the situation. manoeuvres). - Total loss of flight control. would be appropriate).
Severity 5 - No Severity 4 - Minor Failure Condition Immediate Effect Incidents on Safety Severity Classification Failure Condition - No hazardous - Increasing workload of Effect condition i.e. no the air traffic controller or immediate direct [UAVS] crew, or slightly or indirect impact degrading the functional on the operations capability of the enabling CNS System.
First thought was to try and combine these criteria with those previously, e.g. to add the 'Severity 1' criteria to those for 'Catastrophic'. However, on further consideration, this was rejected: o
The criteria are specifically separation and collision focussed, and do not map well onto airworthiness criteria.
o
The criteria introduce issues which may have no airworthiness causes - particularly in the way they consider effects on ATM personnel and 'flight crew' (or UAVS operators in our case). Looked at another way, they provide a means to assess hazards that are caused by ATM personnel and UAVS operators, and start to address the personnel issues within the System of Systems.
o
The associated probability targets required by EUROCONTROL under the ESARR 4 regulation do not line up directly with those for airworthiness under CS.23.1309 or CS.25.1309; hence the requirements for a merged category would be out of step. It was felt clearer to maintain the different severity titles in order to dissuade readers’ instinctive attempts to merge the safety objectives (see below).
What is arrived at is a dual-criteria system, to satisfy different hazard types and regulatory bodies. This might seem unwieldy, but should be fairly simple to apply in practice: o
For hazards and potential accidents where the UAV comes to ground - affecting the overflown population and / or the UAV itself: apply the Airworthiness safety criteria. These will be predominantly due to airworthiness and reliability causes, and the effect will vary with the system size and speed (see Safety Objectives below). They will also fit within the airworthiness occurrence reporting regime.
o
For hazards and potential accidents where the UAV could conflict with other manned aircraft: apply ATM Separation / Collision safety criteria. These may have a system reliability / airworthiness cause, but could also be due to failures within the wider System of Systems, including personnel and procedural issues. They will also fit within the ATM occurrence reporting regime.
o
If a situation arises with potential overlap, i.e. it could cause both an airworthiness and collision risk, what then? It is not so easy to say ‘pick the highest severity’ as the different criteria have different safety targets (see below) and hence a high airworthiness severity might indicate a lower risk overall. A different view is that such situations will need the different criteria at different times (e.g. a failure in control causes a UAV to wander off through controlled airspace first, before ultimately crashing to the ground). Hence my proposal is to split the potential hazard into its airworthiness and collision components, and apply each criterion to the applicable component.
Airworthiness-based Safety Objectives Safety Objectives, in terms of acceptable probabilities, from ARP 4761 are predominantly aimed at heavy transport aircraft. This is in line with FAA / JAA Part 25.1309 (now EASA CS.25.1309 in Europe) and defined in [FAA88]. For smaller manned aircraft, CS.23.1309 would usually apply - this refers in turn to AC 23.1309 [FAA99] for guidance on showing compliance. Both refer to ARP 4761 for guidance on carrying out suitable safety analyses, but AC 23.1309 notes the need to amend the safety objectives. To this end, Safety Objectives for CS.23 and CS.25 aircraft for acceptable probabilities per flying hour are compared in Table 2.2.1(iii) below:
47
Severity of Outcome Minor Major Hazardous Catastrophic Category of Aircraft: CS.23.1309 Class I: Single Reciprocating Engine (SRE) / under 6000lbs CS.23.1309 Class II: SRE and MultiReciprocating Engine (MRE) / under 6000lbs CS.23.1309 Class III (1): SRE, MRE, Single Turbine Engine (STE), Multi-Turbine Engine (MTE) >= 6000lbs CS.23.1309 Class IV (2): Commuter Category CS.25.1309 Heavy Transport
<10-3 <10-4 <10-5
<10-6
<10-3 <10-5 <10-6
<10-7
<10-3 <10-5 <10-7
<10-8
<10-3 <10-5 <10-7 <10-3 <10-5 <10-7
<10-9 <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 takeoff weight of 8618 kg (19 000 lb) or less.
Table 2.2.1(iii) - Airworthiness Safety Objectives - probabilities per Flying Hour (from [SAE96], drawn from [FAA88] and compared with [FAA99]) If we wished to apply these variations to UAVs airworthiness safety objectives, we would need to identify the equivalent class of vehicle. While we could not consider the seating aspects, it would seem sensible to take the engine configuration and mass into account, and thus arrive at a practical equivalent. However, it is worth noting that the CAA [CAA02] push for a kinetic energy equivalence to be determined in deciding which certification criteria to apply (see section 1.2.1), and this should be considered for the safety objectives too. In most cases, the comparison will probably come out about the same - e.g. a 500Kg UAV, powered by a Single Reciprocating Engine, with stalling speed (Vs) of 40kts and maximum operating speed (Vmo) of 100kts would indicate as a Class I by either criteria. Unfortunately, this is not always the case - Global Hawk could be considered similar to a CS.23 Class III manned aircraft, but through kinetic energy considerations indicates as a CS.25 class aircraft. With the likely public sensitivity to UAVs entering the media eye (see section 1.2.6) it would seem sensible to take the higher indicated safety objectives. In summary, for UAVS Airworthiness-based safety objectives, it is proposed: o o
To determine the UAV kinetic equivalence to manned aircraft (using the method extracted from [CAA02] and shown in Annex B to this report) Review the applicable objectives for that class of vehicle (as presented in Table 2.2.1(iii) above) and hence establish the airworthiness objectives for the UAVS.
ATM Separation / Collision based Safety Objectives It is important to note that the ATM separation / collision based safety objectives will not change with the class of vehicle. The acceptable probability of a Severity 1 accident remains fixed by ESARR 4 [EUR04] at 1.55 x 10-8 per flight/hour.
48
2.2.2 FHA Levels to Address System Complexities Currently, ARP 4761 calls for Aircraft Level then deeper System level Functional Hazard Analyses (FHAs), in order to identify significant hazards (see discussion at section 2.1). What levels are appropriate for assessment of a UAVS? Dealing with the UAV System boundary & complexity As noted in section 1.1.2 of this report, there were concerns over the 'airworthiness' boundary for the UAVS. It was clear that the critical elements extended beyond just the UAV itself, and probably included elements such as the GCS, the Datalink, the Flight Termination System (FTS) (if used), but did it include wider aspects such as mission planning systems and so on? The boundary was unclear. However, if we consider that the aim of the Aircraft Level FHA in ARP 4761 is to explore the critical functions that lie within the designer's control, then the boundary does not really matter at this stage. The bulk of functionality within the planned UAVS is to replace those taken for granted in manned systems. Thus, by extending the Aircraft Level FHA to be a UAVS Level FHA, looking at all functions of the UAVS within the designer's control, then the outcome would be an identification of all the functions that are critical to the safe behaviour of the system and the consequences of their breakdown. These would then flow down into the System level FHA, et al, as described in the ARP, to be analysed as functional sub-systems within the UAVS. In section 2.1, it was suggested that the extended criticality criteria should consider people and procedural aspects of system, as these were not specifically addressed by the ARP. However, in the early stages of UAVS design, the specific nature of these elements may not be known. Instead, I would propose that it is important to understand the role they play rather than the details - essentially to understand the functions they might perform. In this way, after having performed the UAVS-level FHA, the designer would use the results to inform decisions on where to partition functions between the hardware, software and human elements of the system. By doing this, a proactive approach can be taken to ensure that the human and procedural elements are well designed and part of an integrated approach to safety, rather than just dumping ad hoc safety monitoring tasks there in order to keep the system simple (as has been the way in the past with some system designs). Further guidance on the human elements of safety and designing for human factors can be found in the York University HFE course [HFE05]. Dealing with the System of Systems around the UAVS As was discussed in sections 1.1.2, UAVS operate within a wide System of Systems (SoS), and in section 2.1 it was noted that [SAE96] was not strong in analysing these relationships. One consideration was to introduce a 'Super-system' level FHA to the process, to assess the functions of the wider SoS. However, this was not felt to be practical for the UAVS designer to attempt: while he wishes to understand the SoS to the extent that it affects his system, he can control only a (relatively) small element of it and a full analysis would take excessive resources. On reflection, this level of analysis might be useful for a wider SoS player such as EUROCONTROL or EASA to conduct, and provide resulting information to inform system designers. A research area of interest is the work ongoing towards decomposition of safety policy, for Systems of Systems. This is discussed by Hall-May and Kelly in [Hall05], looking at how policy (that is, permitted and required behaviours) can be flowed down from top-level goals for different agents, or different situational cases, within a SoS. An example from the paper is shown in Figure 2.2.2a, below.
49
Figure 2.2.2a – Example of decomposition of high level policy to lower level agents or cases [Hall05] Such decomposition causes (usually implicit) assumptions over the context behind such policies to be made explicit. It also requires the policy setter to understand (even at a fairly simple level) a model of expectations, over how the agents can behave – e.g. glider pilots cannot be expected to climb to satisfy policy. If EUROCONTROL or EASA (say) were to develop such a policy model, this would be of great use: both for UAVS designers to understand explicitly what was required (and hence allocate suitable functions for safety analyses – see 2.2.3); and for EUROCONTROL / EASA to better understand how UAVS and other novel systems may / should behave within their wider SoS. It would also allow areas of policy failure to be explored, to determine where the SoS overall may be sensitive to singlepoint 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 UAVSlevel FHA.
2.2.3 Function Identification Our analysis method needs a robust identification of functions, as these are the building blocks for the hazard identification. We do not want to miss out vital functions (and thus areas of hazard analysis and design requirement) due to assumption or error, which will later be found to have critical safety implications for the system in-service. ARP 4761 provides a little guidance on function identification aimed at Aircraft Level FHA, but what is there is aimed at a primarily unitary overall system. This guidance needs to be built upon, to ensure a more structured approach for a UAVS made up of several system elements and working within a wider SoS. ARP 4761 Annex A starts by looking at Source document requirements, but we will return to this once the needs for information to support the functional identification have been explored (see below).
51
ARP 4761 also suggests an 'Aircraft Level generic hazard list' to help get started. As was noted in ‘Focus for project development’ at section 1.3.2, such a list would be useful to develop for UAVS-level assessments and so would a starter list of generic UAVS functions, to act as a catalyst for assessment of new UAVSs. Internal Functions The ARP [SAE96] suggests that, for the Aircraft Level "...these are main functions of the aircraft and functions exchanged between the internal systems of the aircraft." Our concern here is to ensure that the identification adequately explores the complexity of the UAVS, both in its overall capabilities and in its internal interactions (see sections 1.1.1, 1.1.2 and 2.1). To achieve this, the following structured approach has been developed, to identify the Functions List (or Functions Tree as preferred): 1. Consider UAVS functions overall: a. Ideally, there will be an established User Requirement Document or similar specification to draw upon. 2. Consider functions determined by the UAVS internal structure: a. Is there a simple representation of the initial design concept? These could be as formal as Yourdon diagrams or Functional Block Diagrams (as discussed in [HRA03]), or could be a simple architectural model (like an internal Context Diagram) showing interactions between the UAV, the GCS, use of the datalink etc. b. Consider each major element of the structure and identify any additional internal functions - it may help to consider each as a transform mechanism, that is to consider the inputs and the resultant modified set of outputs, in order to determine what functions that element needs to perform the transformation: (i) Does the element have particular behaviour functions - e.g. does it react physically to inputs? (ii) Does it have control functions - does it monitor and/or control the behaviour of other elements? (iii) Does it have information functions - does it generate information or process data, to be used elsewhere? (iv) Does it have utility functions - such as power generation, needed to provide support elsewhere in the system? c. Care will be needed to balance what is sensible to achieve at the UAVS level analysis, and what can be left to the more in-depth System-Level analyses. The balance may be self-imposed by the limited design information available at the early stages of the project. 3. Consider the effect of flight phases, as UAVS usually have a broader mission profile than the transport aircraft that [SAE96] was intended for originally: a. See ‘Flight Phases’ below for discussion on identifying flight phases. b. Review the function list (so far) for each proposed flight phase and mission variation, to identify any additional functions or sub-functions. At this point, some concern was felt over how complete the function list could be, and could there be improvement possible through use of more formal modelling of the system through Unified Modelling Language (UML) or similar specification tools. A further review of literature showed that there is a developing theme for model-based safety analyses. Joshi and Heimdahl [Jos05] for instance, discuss application of Simulink modelling tools to transfer a 52
design representation of the ARP 4761 Wheel Braking System example into the SCADE Design Verifier tool, and from there progress through automated FHA into Fault Tree Analyses and Failure Mode Effects Analysis generation. This work is very promising for UAVS application in terms of: developing formal system models; formalizing fault conditions; automated analysis and verification (including assessing multiple failures – see 2.2.4 below); and developing formal methods to ensure completeness of assessment. However, this approach needs a detailed model of the system design, and [Jos05] notes that it is intended to fit into the bottom of the system / safety ‘V’ (to make it a system / safety ‘Y’ and hence improve the efficiency of developing and integrating the system safely). Thus, it will ultimately be more suited to the later stages of the safety assessment, through detailed PSSA and SSA. – see figure 2.2.3a, below.
Figure 2.2.3a – Modified ‘V’ to ‘Y’ model safety assessment process [Jos05] Exchanged Functions [SAE96] suggests that, for the Aircraft Level "...these are functions that interface with other aircraft or with ground systems." As discussed earlier (sections 2.1 and 2.2.2), more guidance is needed to ensure that the interactions with the wider SoS are identified, hence the following additional advice is proposed: 1. Using the Rich Context Diagram identified in section 2.2.2: a. Consider each element in turn that the UAVS will interact with. b. Consider each Rich Context Diagram interaction for implied functions on the UAVS. Again it may help to consider the UAVS as a transform mechanism: (i) Are there particular behaviour functions - e.g. does it react physically to inputs? (ii) Are there control functions - does it monitor and/or control the behaviour of other elements? (iii) Are there information functions - does it generate information or process data, to be used elsewhere?
53
(iv) Are there utility functions - such as power generation, needed to provide support elsewhere in the system? Flight Phases Flight phases can be somewhat more exotic for UAVs than the transport aircraft originally considered by ARP 4761 (as discussed in section 1.1.1). It is important that all phases are identified, for the main mission and also any variations (e.g. a UAV might act as a sensor gathering target information, but might also be able to act as a datalink relay for another UAV). For this reason, the following modification is proposed to supplement the HazID method: 1. Mission types and parameters should be reviewed to identify the various flight phases possible, for main and alternate mission types. a. This could be gleaned from the User Requirement Document (URD), or maybe there is a simple Concept of Operation (ConOps) that can be used UAVS-Level FHA Source Data Input Requirements From the work above, there are obvious additions to the initial list of source documents for the UAVS-Level assessment. The proposed list would now read: 1. List of generic UAVS functions (when available). 2. The UAVS objectives and customer requirements a. Ideally from a URD or similar specification. 3. Initial design decisions or constraints (e.g. size and type of UAV, scope of GCS, scope of Datalink) a. Perhaps a simple design representation, such as Yourdon or Functional Block Diagram b. Or an initial architectural representation of the system elements (such as an 'internal' Context Diagram). 4. A representation (such as a Rich Context Diagram) showing the interactions of the UAVS with the outside world (the SoS) and any critical interactions between those external elements (such as between ATM and other, manned aircraft). 5. Initial mission types or constraints. a. From a simple ConOps for the system. From the above input data, it should prove feasible to draw up a suitably robust Function List or Function Tree, and hence get the FHA off on a sound basis.
2.2.4 Identification and Description of Failure Conditions ARP 4761 proposes that identification and description of failure conditions for a particular function begins with definition of an Environment and Emergency Configuration list (in order to understand 'normal' and 'degraded' aspects of operation), before going on to consider failure conditions in depth. Each of these aspects is discussed below - note that it is proposed to separate the environment and emergency configurations into two lists, in order to make them more manageable.
54
Environment List [SAE96]starts with suggestions of weather, High Intensity Radio Frequency (HIRF) and volcanic ash as examples pertinent to transport aircraft. For UAVS, the list of possible environments to consider needs to grow. As noted in section 1.1.1, UAVs may operate in a very different environment from manned aircraft, due to a combination of their performance and role / mission differences. 1. The Environment List should be defined from a review of appropriate domains: a. Weather aspects - e.g. temperature, icing, precipitation, winds, visibility... b. Overflown terrain aspects - this may raise additional 'weather' aspects, such as wind-shear, sand and dust storms. It may also indicate other aspects such as for landing and take-off, or communications masking. c. Electrical environment - in particular, man-made or natural RF fields such as High Intensity Radio Transmission Areas (HIRTAs), and perhaps aspects of limited or overlapping spectrum, where problems can be foreseen. d. Mission environment - such as personnel shift-changeovers (for long endurance missions), or action of hostile forces for military uses, or use in day or night. e. Air traffic environment - such as the classes of airspace that may be flown through or nearby, and the levels and types of traffic. 2. Some of these aspects might already have come to light from creation of the Rich Context Diagram (section 2.2.2). However, in order to define this list adequately, it may prove necessary to extend the assessment through use of a series of simple scenarios or vignettes, to define typical situations - more is proposed on this aspect under section 2.2.5. Emergency Configuration List Consider any specific emergency or 'expected' abnormal flight conditions that may occur. Some will be defined in regulation (see section 1.2.2, under Emergency Procedures), others might be necessary due to initial design choices. A preliminary listing of aspects of regulation and guidance from material discussed in the Literature Review (Part 1) has been identified below, though it is not proposed as being complete in all respects: 1. Single failure of the UAV communication link, and/or control link (uplink and/or downlink, depending on implementation) 2. Operation of Flight Termination System (if fitted) 3. Else, conduct of other Emergency Recovery procedures due to loss of critical system(s) a. With UAV-p control b. Without UAV-p control (i.e. autonomous) 4. Emergency landing due to loss of thrust 5. Collision avoidance with co-operative and non-cooperative aircraft a. Including evasive manoeuvre 6. Terrain avoidance 7. Interception by military aircraft 8. Failure of onboard Sense and Avoid equipment 55
9. Operation with degraded systems 10. Degradation of weather conditions 11. Security threats to upload data, commands and transmissions Items 1-8 are drawn from [UTF04]; items 1, 3, 6,7, 9 - 11 from [CAA04]. Clearly the intent of these sources is to try and mitigate what are seen as the inherent hazards of UAVS: it will be interesting to see if the list is appropriate and complete. Failure Condition Determination [SAE96]suggests that single failures may be determined by "examining the original [functions] list created in the previous steps and, in addition, applying an analysis of the concept design created in the initial design process". While not UAVS specific, it is proposed that the Functional Failure Analysis advice contained in [HRA03, session 12] provides valuable guidance, to help structure the determination of failure conditions. This proposes three categories of failures to assess: 1. Function not provided – this is fairly easy to interpret for responsive functions, but care is required with continuous or periodic functions, to ensure that variations are assessed: single failure; periodic failure; complete loss. 2. Function provided when not required – obviously, this is not applicable to continuous functions. 3. Incorrect operation of function – this can be a tricky catch-all, which needs care to ensure completeness. Examples include: asymmetry; substitution; partial; timing. One aspect of interest is that ARP 4761 implies that there can be significant differences whether failures are annunciated or unannunciated. This is worth noting for the UAVS analysis, and it may be more interesting when we consider whom of the various stakeholders (from our Rich Context Diagram) the failures would / could / should be annunciated to. To identify multiple failures, [SAE96]suggests that "...this process is aided by an understanding of the aircraft and system architecture. Multiple failures have to be considered, especially when the effect of a certain failure depends on the availability of another system". To apply some structure to this, we should consider multiple failure conditions: 1. Through assessment of the initial design architecture (perhaps represented by our internal context diagram). In particular consider any elements that could suffer some common cause for failure (such as EMI affecting both navigation and communications functions). 2. Where mitigation for a critical function failure is expected by the successful operation of another function. Here, we should reconsider the criticality of that function, and review 'what if' that function failed also, to give us a more rounded assessment overall. In part, some of this multiple failure analysis will occur through application of the Emergency Condition list, where regulation and guidance has already highlighted some expected areas of criticality such as datalink and propulsion functions. Application of the method will need care to ensure that variables caused by design implementation (as it develops) are suitably identified and assessed.
56
2.2.5 Identifying and Managing the Effects of the Failure Conditions From ARP 4761, this covers the following elements of the FHA process: 1. "Classification of failure condition effects on the aircraft (Catastrophic, SevereMajor/Hazardous, Major, Minor and No Safety Effect)." 2. "Assignment of requirements to the failure conditions to be considered at the lower level." 3. "Identification of the supporting material required to justify the failure condition effect classification." 4. "Identification of the method used to verify compliance with the failure condition requirements." Identification and Classification of failure condition effects For UAVS, as noted in section 2.1, it is not the effect of a failure on the UAVS that matters, it is predominantly the end effect on other stakeholders, such as airspace users or the overflown public, so our method needs to ensure that the mission / environmental / ATM context is adequately understood. There is already some foundation in the methodology proposed so far, with definition of the Rich Context diagram (section 2.2.2), Flight Phases (2.2.3) and Environment and Emergency Condition list (2.2.4). This is supplemented further, through the following proposed elements: 1. For the majority of failure conditions assessed, it is proposed that the existing contextual information (as noted above) will be sufficient. However, as mentioned in section 2.2.4 (in defining environmental conditions), there may be some cases where this is not sufficient. Our existing contextual information is trying to cover the broad scope of variations and generally applicable parameters, in essence defining the outer envelope of how the system will be used. 2. For more complex failure conditions, use of scenarios is proposed to supplement the assessment. When used in Human Factors Engineering (as discussed in [HFE05, unit 3]), scenarios are suggested as "episodes in which the [system] is used" - instead of being general applications, each scenario (for HFE) is put forward as a scripted, specific situation for use of the system, with concrete conditions, events and actors. A scenario thus provides a more detailed representation of a situation within the broader envelope defined in our other contextual representations. We could not hope to cover the whole envelope of environments and usage with scenarios, but used selectively as supplements, they could help draw out some of the complexities of key situations and (in particular) how conditions and events might come together to affect the UAVS. Drawing parallels from scenario use for HFE, scenarios could be selected for specific situations of interest, from the following: 1. (Initially) 'routine' mission stages - all was going well, just like every other day, until... 2. Exceptional circumstances - perhaps extremes of climate, weather or unusual terrain, or variations of mission type... 3. Disadvantaged or extraordinary users - e.g. operation at the end of a shift (fatigue) or after shift change (unfamiliarity); under extreme workload (such as busy airspace)... 4. Accident or failure - e.g. specific instances of system failure (e.g. multiple failure conditions); or expected crisis procedures such as Emergency Recovery, weather diversion...
57
Also from a manipulation of the HFE application in [HFE05], a scenario should consist of the following elements: 1. Scenario name 2. Rationale - why is this scenario of interest? 3. Agents - who is involved (including agents from the wider SoS)? 4. Situation and environment context - physical situation and narrative of the environmental conditions (including weather, climatic and overflown terrain considerations, where pertinent). 5. Mission context - replacing 'task context' for our use. i.e. what was the system doing / intended to be doing? What are the goals of the UAVS user? 6. Airspace context - this additional element is added to ensure that the ATM domain is considered, e.g. for airspace type and traffic conditions. 7. System context - what condition is the system in during the scenario (e.g. degraded systems)? 8. Actions? - For HFE, this would describe a linear path of actions and events through to some conclusion. However, for our use, we may be interested in using the same scenario for analysing a number of different action sequences. As such, it may be more useful to leave the scenario as a defined 'starting situation' using the fields above, and then describe the different outcomes and consequences separately in the analysis of each appropriate functional failure condition. Note that it is not intended to subvert the need for specific HFE activities - those will still be required in their own right, for detailed design. The intent here is to co-opt a HFE technique to help analyse complex conditions for functional failure effects. For the overall classification of the functional failure, the appropriate severity table will need to be applied, as discussed in section 2.2.1. To recap: o
For hazards and potential accidents where the UAV comes to ground - affecting the overflown population and / or the UAV itself: apply the Airworthiness safety criteria.
o
For hazards and potential accidents where the UAV could conflict with other manned aircraft: apply ATM Separation / Collision safety criteria.
Assignment of requirements to the failure conditions ARP 4761 discusses the application of appropriate probability requirements, in order to assure adequate safety levels for the system overall. All that needs to be noted here is that the requirement will need to be appropriate to the severity criteria applied, i.e. as pertinent to Airworthiness or ATM Separation / Collision safety targets (as discussed in section 2.2.1). Supporting material required to justify the failure condition effect classification Currently, it is proposed that the guidance within ARP 4761 will be suitable for UAVS application, for this aspect. Verification method for certifying requirements compliance As above, it is proposed that the guidance within ARP 4761 will be suitable for UAVS application, for this aspect. 58
2.2.6 Summary of Amended FHA Process This section pulls together the various modifications to the ARP 4761 FHA process, proposed in order to apply the method more readily to UAVS safety assessment and certification. The proposed changes are summarised thus: 1. In section 2.2.1, a duel set of safety criteria is proposed, to satisfy both airworthiness requirements (where the UAV may come to ground and affect the overflown population) and ATM separation / collision requirements (where the UAV might affect other airspace users). The airworthiness criteria and targets may vary with class of UAV according to CAA kinetic equivalence criteria (reproduced in this report at Annex B). The ATM separation / collision requirements do not vary, being fixed by EUROCONTROL. 2. In section 2.2.2, it was concluded that the complexities of the extended system could be addressed by carrying out [SAE96]'Aircraft Level' FHA as a 'UAVS-Level FHA'. To bring in consideration of the wider System of Systems, the use of a Rich Context Diagram is proposed, as too much lies out of the UAVS designer's remit or resource for a ‘System of Systems’ level FHA. 3. Sections 2.2.3 to 2.2.5 go on to consider the conduct of the UAVS-Level FHA. These activities are summarised in Figure 2.2.6a, below. This figure is based heavily (in style) on the original 'Aircraft Level FHA' Figure A1 in ARP 4761 [SAE96], in order to ensure recognition by experienced users and regulators - the ARP 4761 figure is reproduced in Annex A to this report (Figure A-1), as part of the more detailed critique of that document for UAVS application.
59
Figure 2.2.6a - ARP 4761 FHA Process, with modifications overlaid for UAVS applicability
60
PART 3 - TEST AND EVALUATION This part of the report seeks to answer the following vital questions, relating to the proposed way forward in HazID for UAVS as put forward in Part 2: o
Does the Revised ARP 4761 HazID Method Work? That is, is it practical to apply and does it robustly identify hazards for UAVS?
o
If so, then what are the hazards of manned and unmanned aircraft integration, and how does our listing compare to expectations?
Section 3.1 describes the test and evaluation methodologies used. Section 3.2 looks at the first question, evaluating the practicality of application. Section 3.3 considers the second question, evaluating the derived hazard listing.
3.1 Test Methodology Test Method Selection In order to determine the practicability of the revised HazID method, it needed to be trialled. To do this, the modified ARP FFA process has been applied to a 'typical' UAVS case study (see description, below). While not possible in this project to consider its application for all types of UAVS (see section 1 and 1.1 for the diversity among current UAVS), it was possible to choose a 'mid-range' system with broad applicability that will soon be facing the prospect of integration into manned airspace. In the longer term, it would be useful to check the wider applicability, by trialling against case studies at the more extreme ends of the UAVS spectrum such as HALE and micro-UAVs. The results are presented in Annex D, and discussed in Section 3.2. If the method proved practicable, then the HazID should produce a hazard listing. How could we test the robustness of our HazID method, to ensure that the hazard listing is sound? Caseley of the Defence Science Technology Laboratory (DSTL), in [dst04], discusses use of the "Capture - Recapture" method, a technique borrowed from the Ministry of Agriculture, Fisheries and Food (MAFF). In MAFF use, a pool is trawled for fish, and all caught are tagged and released; then the pool is trawled again, and the proportion of fish recaptured compared to the number newly caught gives an indication of the total fish in the pool. DSTL used this method to provide a rough comparison of the efficiency of hazard identification by two separate agencies for the same project, and to identify coarsely how many hazards had gone unfound. A graphical view of the method is shown in Figure 3.1a, below. Caseley quotes the following example figures, to show simple factors of confidence: o
Agency A found 20 hazards, Agency B found 30, with 15 common hazards between the two groups.
o
The proportion of hazards captured was estimated as 15/30 = 0.5
o
The possible total number of hazards was estimated at 20/0.5 = 40
61
Figure 3.1a - "Capture - Recapture" analysis method, to measure the effectiveness of hazard identification processes Obviously, there are many statistical assumptions and simplifications inherent in this method (including a major assumption that the methods are truly independent), but as a simple measure it gives reasonable first order results, and should suffice for our purposes. With this in mind, it was decided to commission a separate FHA for the case study, but using a Structured What If Technique (SWIFT) for diversity of method, and using different personnel for independence of analysis. SWIFT takes a technology, flow or procedural assessment, using structured categories and key words for hazard elicitation, which (with separate personnel for different thought processes) is proposed as ensuring adequate independence of assessment. The SWIFT results are presented in Annex E; the hazard listing from the modified FFA process is presented in Annex F, and the results are jointly evaluated in Section 3.3. Case Study Description The 'Guard Dog' case study has been defined based on a number of current and near-future Tactical UAV Systems. While intended for over battle-field use, the Armed Forces need to train in their use, and with extended range and duration, they are keen to operate outside segregated range area boundaries. The case study considered a generic Tactical UAV (TUAV) operating out of a 'UAV friendly' airfield and out into integrated general (not controlled) airspace, in order to reach a range area for payload operation. The case study introduced aspects of interest relating to the performance and operation of the system, as well as the need to integrate it into a varied terrain and airspace environment. The background to the case study is shown in Annex C to this report, while a graphic overview of the system is shown in Figure 3.1b, below.
62
Figure 3.1b - Overview of Guard Dog UAVS case study
3.2 Evaluation of the Modified HazID Method through Trial Application This section looks at the actual application of the proposed FFA method, and evaluates its practicability of use. Extracts from the FFA are shown below as examples, while a fuller listing is shown at Annex D.
3.2.1 Derivation of Safety Criteria and Objectives for UAVS Application Deriving airworthiness safety criteria using the [UTF04] suggested definitions in Table 2.2.1(i) was straight forward at this stage – more questions were expected in their application (see Section 3.2.5). Minor Major Severe Major / Hazardous - Slight reduction in - Significant reduction in safety - Controlled loss of the UAV safety margins margins (e.g., total loss of over an unpopulated communication with autonomous emergency site, using (e.g. loss of redundancy) flight and landing on a predefined Emergency Recovery emergency site) procedures where required.
Catastrophic UAV's inability to continue controlled flight and reach any predefined landing site
Table 3.2.1(i) - Airworthiness Failure Condition Severities for ‘Guard Dog (drawn from Table 2.2.1(i))
63
Defining safety objectives proved almost as straightforward. Using both the CS.23.1309 definitions shown in Table 2.2.1(iii) (Single Reciprocating Engine (SRE) / under 6000lbs), and the CAA kinetic energy method (shown in Annex B), both arrived at the same conclusion of CS.23.1309 Class 1 probability criteria. ATM separation criteria were already fixed, in accordance with Table 2.2.1(ii) (as they do not change with vehicle class).
3.2.2 FHA Levels to Address System Complexities At this stage it was not possible to pronounce on the success of a ‘UAVS-level’ FFA – more is said of this in Section 3.2.3 What did prove very useful was the derivation of a rich context diagram to model the System of Systems – see Figure 3.2.2-1 (a larger scale version is shown in ‘landscape’ at Figure D-1 in Annex D).
Figure 3.2.2a - Rich Context Diagram for Guard Dog UAVS and the System of Systems It took quite a while to arrive at a result that seemed satisfactory, but this was a measure of the complexity of interactions rather than any difficulty of method. The figure shown is the result of a one-man application. It would have been very useful at this stage, to use the diagram as a focus for discussion with key stakeholders, in order to draw out any more interactions.
64
3.2.3 Function Identification Internal Functions As the case study was intended to be generic, there was no formal documentation such as a User Requirement Document, or Yourdon diagrams, only the brief outline of the Case Study (Annex C). The function derivation was thus from first principles. The simple representation of initial design architecture (Figure 3.1b / Figure C-1) was useful, to help break the system down to manageable pieces (while still being able to consider the overall system). It helped to be able to look at each element in turn, to draw out functions from that view. In considering each element, a ‘mind map’ was drawn for each element to pick out its related functions, then resolve / consolidate any overlaps between different elements under higher level function. For example, ‘Manage Datalink’ was a function picked out to cover aspects pertinent to both UAV and GCS viewpoints. Care was needed to not become too ‘object’ focused (we still wanted to keep a system-level overview). An example of one of the mind maps is shown in Figure 3.2.3a. Download payload data
Distribute payload data
Prioritise sensor / data requests from Users Plan Route
Direct sensors
Manage Payload Mission Planning
Change Mission Plan
Control UAV?
manual Override remote piloting
via next GCS?
GCS
NEC Control Datalink Path Monitor Mission Progress
Status of UAV
Upload Mission Plan
Actual path v mission route
Via Satellite?
Manage DataLink D/L Fail Emgy Action
Via UAV Relay? Monitor Data link condition
GCS Centred view
Figure 3.2.3a – Example of use of mind-map to consider each system element’s view of functions The discipline of making a check of behaviour, control and information functions was also useful, though it was less easy (inappropriate?) to consider utility functions at this stage – that would perhaps prove more useful at the next level of sub-system FHA. These types helped draw out extra aspects: for example, it was initially thought that there wasn’t much to the field recovery / launch team element, but the list drew out information and utility aspects such as mission upload and replenishing consumables.
65
The derivation and consideration of flight phases also proved useful as a mind jogger: while the initial listing had found 56 functions, consideration of flight phases gained 5 more relating to internal functions. It was difficult to not get too pulled into design, especially over aspects such as autonomy. Positive effort was needed to stay up at system level, i.e. not to try and partition functions into whether they were performed by the UAV or GCS / UAV-p. This proved to have been a good discipline, when it came to considering failure effects later on (see ‘Multiple Failures’, in section 3.2.5). At this stage, it was becoming evident that the UAVS-level FHA was proving quite effective, in being able to identify (and hence analyse) system interrelations and complexities. Exchanged Functions As hoped, the rich context diagram proved very handy for drawing out exchanged functions. A table (Table D(v) in Annex D) was used to list each interaction, then focus on what the UAVS needed to provide to make the interaction work. Some ‘functions’ were included that might not strictly be functions (perhaps characteristics?), but they had clear potential safety aspects. For example, ‘Conspicuity to Air Traffic’ is a fairly passive function but important to make ‘see and avoid’ work for non-cooperative air traffic. The rich context diagram was, again, supportive of drawing out such necessary characteristics. What became evident later on was the need to define basic behavioural functions, to handle key emergency conditions – this is discussed in section 3.2.4 under ‘Emergency Configurations. Consolidation From these functional views, 103 functions overall were identified (at all levels). 56 were extracted from internal views; 42 from the external context; and 5 new from looking at Flight Phases. There seemed to be no real need for a separation of internal and external functions, and many were interrelated (see below), so they were combined into a single Functions Tree, ready for consideration in failure identification. Part of the tree is shown in Figure 3.2.3b. The tree in full can be seen in Figures D-4a, b and c at Annex D. In trying to rationalise these functions into a tree, the interaction between functions grew apparent. E.g. ‘Auto Take-off and Landing’ has lower level functions to determine runway and landing characteristics for particular wind speed and direction, but functions under ‘Monitor weather for changes’ would affect the wind speed determination, and functions under ‘Stability and Control’ provide the actual take-off rotation or landing flare. There were ‘building block’ functions that, perhaps, higher order functions across the tree would make use of. These would be considered carefully when looking at functional failures and multiple failures.
66
UAVS Function Tree UAVS [PartFunction 1 of 3] Tree [Part 1view of 3] (I) Internal (I) Internal (F) Flight phase view view (F) Flight phase view view (E) External context (E) External context view
1. Stability & Control (I)
3. Control on the Ground (I)
2. Air Navigation (I)
1.1 Determine attitude, orientation and speed (I)
1.2 Stabilise perturbations (I)
1.3 Manoeuvre UAV (I)
1.4 Manual Override Remote Piloting (I)
1.5 Field T/O Launch Control (I)(F)
2.1 Position, Heading & Altitude Awareness (I) 2.1.1 Determine Position, Heading & Altitude (I)
1.6.1 Control Airspeed (I)
2.1.2Determine Nav Data accuracy (I)(F)
3.1.1 Determine speed on ground (I)
2.4 Auto Take off & Landing (I)(F)
2.3 Monitor / Correct actual v planned route (I)
1.6 Control Flight Path (I)
3.1 Control Speed on the ground (I)
2.2 Store / Update Mission Route (I)
2.4.1 Determine Airfield T/O Climb-out profile (F)(E)
1.6.2 Control Altitude & Rate (I)
1.6.3 Control Heading (I)
2.4.3 Determine Airfield Approach, Hold, Circuit, R/W profile (F)(E)
3.1.3 Controlled Ground Braking (I)
3.2 Control Position on the ground (I)
3.2.1 Determine ground position & heading (I)
3.2.2 Ground steering (I)
3.2.3 Determine Airfield layout / required ground route (F)(E)
3.2.4 Monitor / correct actual v required ground route (F)
3.2.5 Determine Air / Ground transition (F)
3.2.6 Determine Ground obstacles (F)(E)
3.1.2 Controlled Ground thrust (I)
2.4.2 Determine High accuracy Position, heading & Altitude (F)
2.4.4 High Accuracy monitor / correct actual v planned profile (F)(E)
2.4.5 Determine Windspeed & direction v R/W and landing characteristics (F)
2.5 Terrain Avoidance (E)
2.5.1 Awareness & flight path proximity (E)
3.2.6.1 Detect mobile obstacles (F)(E)
3.2.6.2 Fixed obstacles awareness (F)(E)
2.6 Sensitive Area Avoidance (Danger & Populated areas) (E) - as 2.6.1-3
2.5.2 Maintain separation (ROA) (E)
2.5.3 Emergency evasion (E)
2.7 Controlled Airspace avoidance (E) as 2.6.1-3
2.8 Variable Danger Areas (NOTAMS) Avoidance (E) as 2.6.1-3
Figure 3.2.3b – Example of derived Functions Tree for ‘Guard Dog’ UAVS
3.2.4 Identification and Description of Failure Conditions Environment List The domain-review list provided a good structure for derivation of the environment list. Weather aspects were fairly easy to pick out, from UAVS overall specification (based on world-wide operation). Aspects such as overflown terrain were trickier to complete, as they are not a usual specification item. Looking at the map examples for scenarios (discussed in section 3.2.5) helped significantly. These also helped with extracting the range of electrical / mission / ATC environments. It was useful to define a number of potential missions (see Appendices C1 and C2) and use these to define typical scenarios (see 3.2.5), to get a better feel of likely environments. Looking at maps for areas of operation (and training in more domestic climes) teased-out a wide variety of such aspects. Emergency Configurations Guard Dog started with the list as initially proposed in section 2.2.4. However, consideration of this list quickly highlighted a need to consider what the UAVS intent would be in event of such emergencies, especially for system failures. Hence, a useful source document would 67
be an initial definition of emergency procedures, as part of the ‘initial design considerations’. The Guard Dog example is shown in Figure 3.2.4a below, or in bigger scale as Figure D-2 in Annex D. These considerations spawned additional functions (to be added to the tree), to be assessed for further functional failures (part of multiple failures consideration).
YES Regain D/L Signal?
Hold
DATA LINK Signal Loss
NO
DATA LINK System Fail (total)
Broadcast Control Datalink Fail DIVERT to identified diversion airfield
DATA LINK System Fail (single) NORMAL FLIGHT FLIGHT CRITICAL SYSTEM SIngle (Redundant) Failure Determine best diversion and ID between GCS and UAV (May be home or destination) Maintain flight path over 'safe' terrain and airspace
COMMUNICATIONS Failure
AIR NAVIGATION Failure (inc. height, speed, position & route control)
Able to Maintain Safe YES Altitude?
External Nav Asistance?
YES
FLIGHT CRITICAL SYSTEM Total Fail NO
NO
COLLISION AVOIDANCE Failure GROUND CONTROL Failure
Broadcast Mayday & EMERGENCY LANDING
Broadcast Collision Avoidance fail STOP & Broadcast
Figure 3.2.4a – Example of outline Emergency Procedures, to derive functions Failure Conditions Determination With a significant number of functions, care was needed to ensure that all failure characteristics had been considered. In this, the FFA structure proposed worked well, as discussed below. Some failure conditions are shown below, but all identified can be viewed in full at Table D(vi) in Annex D. ‘Loss of function’ - could be tricky to assess, for continuous functions (i.e. to search deeper than just ‘loss of [function X]’). Some interesting conditions were found where a function could be pseudo-continuous. For example, ‘Terrain Awareness’ being made on a regular but not truly continuous basis (function 2.5.1 – see Table 3.2.4(i)): a potential failure condition was for sharp terrain to appear in the event horizon, if the update rate was not high enough. FFA ID
Function 2.5 Terrain Avoidance (E) 2.5.1 Awareness & flight path proximity (E)
F2.5A F2.5B F2.5C
(a), (b), (c)
Failure Condition (Hazard Description)
(a)
Unaware of surrounding terrain
(a)
Unaware of proximity of surrounding terrain to flight path Terrain proximity determined at low sampling rate
(a)
Table 3.2.4(i) – Example of ‘Loss of Function’ for pseudo-continuous function ‘Uncommanded function’ – Some care was needed not to dismiss functions as ‘continuous’. For example, Function 1.6.1 ‘control airspeed’ is indeed continuous overall, but has some implied sub-functions such as to change airspeed intermittently when required, hence the potential uncommanded sub-function to change airspeed up or down when not required. (See Table 3.2.4(ii)
68
FFA ID F1.6C F1.6D
Function 1.6.1 Control Airspeed (I)
(a), (b), (c) (b) (b)
Failure Condition (Hazard Description) Airspeed runaway up 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 ID F4.2C
Function 4.2.1 Handover to next GCS (I)(F)
(a), (b), (c) (c)
F4.2D
(c)
F4.2E
(c)
F4.2F
(c)
F4.2G
(c)
Failure Condition (Hazard Description) Datalink control hand over from current GCS, but next GCS unable to take control Datalink control hand over from current GCS, but next GCS unaware it has control Datalink control taken over by next GCS, without current GCS being aware Datalink control hand over to next GCS, but current GCS also retains control (dual control) 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 ID F9.7A
Function
(a), (b), (c) (a)
9.7 Emergency Broadcast Actions (E) (Coll aware fail; D/L fail; Mayday)
F9.7B F9.7C F9.7D
(a) (a) (b)
F9.7E F9.7F F9.7G
(b) (b) (c)
Failure Condition (Hazard Description) Unable to broadcast – “Collision Avoidance Fail” Unable to broadcast – Data Link Fail Unable to broadcast – Mayday Broadcast ‘Collision awareness fail’ when not required Broadcast ‘Data Link fail’ when not required Broadcast ‘Mayday’ when not required Broadcast incorrect emergency message compared to that actually required
Table 3.2.4(iv) – Example of failure identification for a warning function As usual with FFA, there was a lot of output. The initial 105 functions gave rise to about 520 failure conditions. Care was needed to bring this to a manageable number of hazards at a similar level, to assist hazard management.
3.2.5 Identifying and Managing the Effects of the Failure Conditions Table 3.2.5(i) shows some examples of the analysis of effects of failure conditions, extracted from the fuller analysis shown in Table D(vii) in Annex D. These examples are used to illustrate the discussion of the analysis, contained in this section.
69
Table 3.2.5(i) Examples of analysis of the effects of failure conditions, from the ‘Guard Dog’ FFA FFA ID
Failure Condition
Flight Phases1
F1.2A
Loss of UAV stability
F1.2B
Undamped / poorly damped manoeuvres or speed
Tax, TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F Land A, Land F Tran, Hand, Tran S, Sens, App, Rel
F1.3I
Manoeuvre capability exceeds vehicle structural strength
F1.4A
Unable to take manual control of UAV
F2.1A
Unable to determine position
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel Taxi, TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
Effect of Failure Condition2 - (1) AW; (2) ATM (1) Unstable UAV leads to overall loss of control – unable to continue controlled flight Knock-on for Relay UAV would be loss of data link for Sensor UAV
Classification
Justification
(1) Catastrophic (2) Severity 1
[Critical safety requirements will be set, if the Relay role is to be viable in unsegregated airspace.]
(1) Significant reduction in safety margins during T/O or landing, due to oscillations. Potential for ground impact close to T/O or landing area (2) Severe oscillations could cause height bust, deviation from clearance on approach, or reduced separation (1) UAV break up – unable to continue controlled flight
(1) Hazardous (2) Severity 2
(1) Catastrophic
AW issue, as vehicle break up takes it out of the ATM environment
No immediate effect, UNLESS a coincident functional failure occurs (in functions 1-10 inc) requiring manual intervention
As for the most severe of other functions 1-10: (1) Catastrophic (2) Severity 1
In isolation – position can be approximated from heading, speed etc. In common failure with F2.1B or F1.1B – requires external means to identify position (functions 9.3 En-route ATC communications and 9.4 Tracking ‘visibility’ Without these, system faces emergency landing (function 7.3.2) in unknown terrain, or flight path through unknown airspace Knock-on for Relay UAV
In extreme cases: (1) Catastrophic (2) Severity 2
Manual override is intended as mitigation for many other failure modes. Safety requires independence from other failure forms (EITHER autonomy in case of 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) AW severity assumes need to make blind emergency landing at last ‘known’ position (MS7 emergency landing scenario shows that small inaccuracies could cause impact on village location, as lesser evil to flying on and possibly crashing in major population area ATM severity assumes that function 10 Collision avoidance remains active – need to beware of potential common mode failures.
70
FFA ID
Failure Condition
Flight Phases1
F2.5A
Unaware of surrounding terrain
Tran, Hand, Tran S, Sens, App, Rel
F4.3A
D/L fail action (hold then divert) not taken when required
TO A, TO F, Land A, Land F, Tran, Hand, Tran S, Sens, App, Rel
F9.7A
Unable to broadcast – “Collision Avoidance Fail”
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
F9.7C
Unable to broadcast – Mayday
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
Effect of Failure Condition2 - (1) AW; (2) ATM would be loss of data link for Sensor UAV (1) UNDETECTED – Controlled flight into terrain DETECTED – climb to safe height and divert IF UAV does not take necessary autonomous action, then effect as F4.3C [UAV will eventually run out of fuel and crash land] IF UAV continues on its pre-planned path but without diverting, may cause concern to ATM (prolonged exposure to UAV without manned override capability) but should act safely if functional (2) Failures under F10 for Collision avoidance system, following function 7.3.1 to divert would be UNDETECTED by ATM and other air traffic – they would proceed as if UAV would respect Rules of the Air, in extreme allowing collision (2) Failures requiring function 7.3.2 Emergency Landing would be UNDETECTED by ATM and other air traffic. Controlled emergency landing would not be affected, but could affect ability of ATM to alert emergency services to the site.
Classification
Justification
(1) Catastrophic
Assumes TO and Land covered by functions 2.4 – ensure no combined functionality / common mode failure No action - Represents a failure of a critical autonomous response, to get the UAV down safely in event of D/L failure Continue previous action – degrades ATM safety, but continuing autonomy gets the UAV down safely
No action: (1) Catastrophic Continues preplanned actions: (2) Severity 3
(2) Severity 1
[see functions 10, Collision Avoidance, for safety-related functions where this function is intended as mitigation]
(2) Severity 1
Classified as severity 1, on basis that it could make a bad situation (Severity 2) much worse by not being able to send assistance rapidly to the scene. [Difficult to classify, with criteria as listed]
Notes: 1. Flight Phases – (Pre) Pre-flight; (Tax) Taxiing; (TO A) Take-off – from airfield; (TO F) Take off – ramp launch from field; (Tran) Transit under control of GCS; (Hand) Hand over control to second GCS; (Tran S) Transit with GCS relay via satellite; (Sens) On Task – using sensor payload; (Rel) On task - on station to relay TCDL to reach sensor UAV; (App) Approach; (Land A) Landing – at airfield; (Land F) Landing – rough field. 2. Effect of Failure Condition – (1) AW – effect on UAV, safety margins, continued & controlled flight; (2) ATM – effect on UAV Crew, ATCO, other Traffic
Identification of Failure Effects In general, it was fairly simple to identify the broad effects of potential failures. This was particularly true of the ‘building block’ functional failures (as mentioned in section 3.2.3, in ‘consolidation’): when these failed, the effects were pretty direct. An example is shown in Table 3.2.5(i) with failure F1.2A “Loss of UAV stability”. Some effects were worse in particular flight phases and this was noted in deriving the effects. One point of note was the crucial effect on the UAV system overall, when a failure occurred 71
to a vehicle in Relay flight phase (as noted in F1.2A). The criticality of the UAV in this role will set very high safety requirements if this role is to be cleared in unsegregated airspace, and perhaps it may only be cleared for training with a viable alternative datalink path always available (so as not to be a critical dependency). Most failures had both airworthiness and ATM separation effects. An example is shown in Table 3.2.5(i) for F1.2B “Undamped / poorly damped manoeuvres or speed”, where both an immediate airworthiness effect could be identified, and a slightly longer term ATM separation effect if the airworthiness effect was not immediately realised. A few failures indicated an airworthiness effect only, such as F1.3I “Manoeuvre capability exceeds vehicle structural strength” in Table 3.2.5(i). The airworthiness effect here was usually so cataclysmic that there was little likelihood of further ATM effect. A few others, such as F9.7A “Unable to broadcast – “Collision Avoidance Fail” ” in Table 3.2.5(i), indicated an ATM effect only. These were usually directly related to ATM procedural or traffic separation functions. Some functions had already been added in as emergency ‘warning’ functions, in response to early consideration of the effects of ‘annunciated’ vs ‘unannunciated’ failures. However, all failures were considered for the differences with the failure being annunciated detected or not. F2.5A “Unaware of surrounding terrain” shows a particular example, where detection would allow a much safer effect than the alternative, and this would help set particular safety requirements on the system to improve detection. Classification of (Airworthiness and ATM) failure effects The safety criteria discussed already in section 3.2.1 proved useful, and usually easy to apply. This was especially true of the airworthiness criteria, and (usually) of the ATM separation criteria. There were a few exceptions with the ATM separation criteria, where the classification in terms of ATC workload, traffic separation or collisions could not easily be applied. Here, classification came down to a judgment on the level of ‘loss of control’ by ATM and UAV-p and the effective reduction in safety margins. An example is shown in F9.7C “Unable to Broadcast ‘Mayday’” in Table 3.2.5(i), where there is no further airworthiness effect, but there is an ATM / UAV-p effect, as ATC can’t be alerted to apply their procedures to call emergency services to the site. Multiple failures Some key multiple failures had already been considered, by creating emergency intent functions (mentioned in section 3.2.4 Emergency Configurations) and then analysing failures in these follow-on functions (e.g. F9.7A “Unable to broadcast – “Collision Avoidance Fail” ”, already mentioned above). Others were derived from key aspects of the initial system architecture, such as the datalink between GCS and UAV. While not many more ‘failures on failures’ were analysed in detail, there were some failures where the criticality of certain other functions remaining effective (for mitigation) were noted. Here, the main drive was to identify safety requirements to ensure effective mitigation, particularly the need to establish independence of such functions and avoid common mode failures. A specific example (among many) is F2.1A “Unable to determine position”, where the potential effect is not so bad, provided that other key functions such as Collision Avoidance functionality remain operational. If there was a common system factor (such as some datalink dependence for these functions) then the effects would be much worse. This brings us to a particular issue drawn out by consideration of multiple failures. Up to this point, the analysis had avoided partitioning functionality between the UAV, GCS and UAV-p (i.e. making decisions on autonomy levels). Now it was possible to set requirements on critical functionality. The primary concern was the need to make safety critical functions independent of the datalink. Safety is thus a driver for increased capability (and 72
assurance) in autonomy for those functions. There are endless examples where dual failure with datalink would be Catastrophic / Severity 1, but a couple from Table 3.2.5(i) are discussed below. This issue of autonomy v datalink was first noted in the FFA during consideration of F1.4A “Unable to take manual control of UAV”. Here, the effect was not serious provided that the system had adequate autonomy to carry out necessary safety actions such as collision avoidance, terrain avoidance, air navigation and conducting emergency procedures. This was later backed up by consideration of specific datalink function failures, where the knockon 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 preplanned path but without diverting, this may cause concern to ATM … but should act safely if functional.” UAVS thus need careful use of autonomy, to provide the necessary independence of safety functions. As a minimum (for smaller systems perhaps, where the public would be less alarmed), the use of a Flight Termination System would be an alternative, independent means of assuring a ‘safe’ outcome. Use of Scenarios to Aid Effects identification For the majority of failures analysed, scenarios weren’t necessary, and consideration against more general contextual information was appropriate. Where they were necessary, the initial guidance led to scenarios that were almost too specific. Text based scenarios (as proposed) needed a fair number of words to get the situation across, and still seemed to be lacking necessary information. An example is shown in Figure 3.2.5a. An alternative was tried, with better results. This approach was to plan actual missions over typical terrain, on air maps. Using this, the user got a better idea, more quickly, of the type and range of challenges – terrain, airspace, obstructions, HIRTAs etc. It was vital to actually plan the route on paper, not just look at the maps, in order to think into actual mission-type situations. For example, identifying where to place a GCS to achieve datalink along full length of route; or how to respect airways minimum heights, while being pushed by terrain to maintain minimum separation – airmanship-type decisions. The map could be annotated with other conditions of interest, such as the possible range of weather. The same proved true when looking at emergency situations. For instance: what if the weather closes out the planned route here; or propulsion fails there; or satellite datalink becomes unavailable when ground GCS range is marginal. Overall, it seemed that graphical mission scenarios were more user friendly and encouraged creative thinking. They contained more information and felt more ‘real’ than just broad specification envelopes; but not too specific – they allowed ‘what ifs’ to be raised and assessed quickly, some of the what-ifs being driven by the map terrain and airspace content. An example of a graphical mission scenario is shown in Figure 3.2.5b, comparable to the textual scenario shown in Figure 3.2.5a.
73
Scenario : Routine Take-off Rationale: Applying general take-off to realistic situation, at ‘UAV-Friendly’ Parc Aberporth Agents: UAVS and UAV-p; Aberporth ATC and ground traffic; Cardigan Bay danger area controller Situation and environment context: Day VFR weather fine. Onshore breeze from the sea, 20kts. Take off and climb out planned over sea (away from Aberporth village at foot of significant hills), then turn out over sea for first leg. Several wind farms on coast, and steep terrain. Mission context and goals: Start of a routine training mission. Intent is to taxi and take off safely, respecting airfield ATC and ground / circuit traffic. Main goal is to get established on first leg of fly out, at start of a long training mission. Airspace context: Parc Aberporth is a UAV-friendly airfield, used to UAV activities. Some light manned aircraft traffic in circuit, including military aircraft incoming from / outbound to the danger area (range). Danger area is a sea range, for aircraft and ships weapon trials (closed to traffic during attack runs). First leg to Talybont, crosses under Airway A (at 6,500 ft, under airway starting at 16,500 ft) System context: Full system functionality, as checked during pre-flight and taxi checks Actions: UAV-p contacts airfield ATC for clearance to taxi – this is given and UAV taxis out to stop at Hold ‘CHARLIE’. After other traffic clears, ATC clears UAV onto runway 26 for take off. UAV applies power and takes off, correcting for slight cross-wind. After clearing obstruction height and reaching 2000ft, UAV told to switch to danger area controller frequency. Danger area controller clears UAV to the north, commanding to keep clear of south end of range where ships are operating on range. UAV heads onto northerly track, climbing until reaching 6,500ft. As it leaves the danger area, UAV switches to Holyhead Airspace Controller and requests Flight Information Service for transit to Spadeadam.
Figure 3.2.5a – Example of mini scenario for consideration of failure effects
Figure 3.2.5b – Example of graphical scenario ‘MS1 Routine Take-off and climb out’ 74
The scenarios were used in a few analyses of the effects of failures. This was usually as follow-on to trying to assess the effect with broader information, to check and improve on the justification behind an effect analysis. For failures like F4.2F “Datalink control hand over to next GCS, but current GCS also retains control (dual control)” (in table 3.2.5(i)) this was useful, where the impact is not clearly apparent on first analysis. Occasionally, they were used to help ‘put flesh on the bones’ behind an analysis, to ensure that the ensuing classification was suitably robust. Failures such as F2.1C “Unable to determine altitude” show such a use, where the effect was already felt to be quite severe, but the emergency landing scenario provided an alternative context to re-assess the classification.
3.3 Evaluation of Hazards Identified by the Modified HazID Method The functional failures (in Annex D) produced by the FFA process have been reviewed by the author, in order to determine a list of hazards at a common, appropriate level. This hazard listing is shown at Annex F to this report. Some 88 hazards are listed in all, with references to the functional failures that spawned them. Numerical assessment How robust is this hazard listing and (accordingly) the FFA HazID process that has been used? As discussed in Section 3.1, a SWIFT technique was commissioned to provide a comparison, with the overall results shown in Annex E. Both Annexes E and F cross refer to the appropriate comparable hazard(s) identified in the alternative technique. The comparison of techniques is interesting, if not straightforward. Our FFA method produced 88 hazards, while SWIFT produced 77. Of these, 48 were in close agreement. Using the MAFF ‘capture / recapture’ method as discussed in Section 3.1, this would indicate, initially, the following metrics: Initial metrics for hazard capture confidence: ‘Proportion of hazards captured’ = 48 / 88 = 0.55 ‘Possible total number of hazards’ = 77 / 0.55 = 140 This was not overly inspiring of confidence in the results, so further investigation was made to see if they were overly pessimistic. From the first pass comparison, 29 SWIFT hazards did not directly match FFA hazards. However, the comparison was not always made on a level footing: • Several of the SWIFT hazards (10) were related to ground personnel, whereas the FFA focus was on operating hazards more relevant to manned / unmanned aircraft integration. The ARP 4761 process would eventually draw these out through complementary analyses such as Operating & Support Hazard Analysis. • About 10 of the SWIFT hazards were more causal than directly hazardous, related to system implementation. These (through ARP4761) would be considered under Fault Tree Analysis at the UAVS level, or FHA and FMEA for lower level systems. A further 2 were related to uncontained engine failure and fuel fire, and would be considered under Particular Risk Analysis with the [SAE96] process.
75
• A further 3 SWIFT hazards related to general procedural aspects, covered by regulation, such as maintenance policy and crew training. Having removed these hazards (for now) to achieve a common level, a revised comparison could be made. SWIFT now had identified 52 hazards, with 48 agreeing with the FFA: Revised metrics for hazard capture confidence: ‘Proportion of hazards captured’ = 48 / 88 = 0.55 ‘Possible total number of hazards’ = 52 / 0.55 = 95 This suggests that the FFA has identified about 90% of the total hazards for manned / unmanned aircraft integration. Subjective assessment of differences As noted above, the SWIFT had already identified some ground-based and causal hazards that the FFA (at this stage) had not – we can propose that these would be identified by subsequent stages of the ARP4761 process. Four SWIFT hazards remain that cannot be explained in this way, and these are shown below. • • • •
S13 S25 S41 S48
Inadvertent launch Poor preparation of launch site (inadequate runway quality) Loss of GCS communications Pilot fatigue (long endurance shifts)
These indicate two issues with the FFA. Firstly, the FFA is only as good as the initial function tree, and this application had missed out a small number of functions – e.g. ‘Inter GCS Communications’. A peer review of the Rich Context Diagram and Functions Tree might have picked these (and maybe more) out. Second, in spite of the intent to pick out functions including human issues, it was still difficult for the FFA to consider and draw hazards out of high level human factors, such as the resource issue of long endurance shifts. This is why it is still important to ensure that Human Factors are adequately assessed and designed for, in their own right. The FFA of our proposed method had, in turn, identified 38 additional hazards relating to integration of UAVs into unsegregated airspace – these are shown below: • A4 Flight instrumentation (attitude and speed) errors • A5 Inability to identify flight instrumentation errors • A9 Unable to transfer to autonomous UAV control • A10 Conflicting authority between UAV controllers (manual / autonomous or different ground controllers) • A11 Control mode error (where control laws differ with phase of flight) • A13 Asymmetric thrust / power • A16 High accuracy navigation instrumentation errors (altitude, position, heading; for taxi, take off, approach, landing) • A17 Inability to identify navigation instrumentation errors • A19 Planned mission route not achievable by UAVS (not capable within performance) • A20 Planned mission route not safe (by Rules of the Air) • A25 Minimum terrain separation (i.a.w. Rules of the Air) not maintained • A26 Terrain separation / emergency evasion triggered when not required / appropriate
76
• A27 Separation from sensitive areas (danger areas / populated areas / NOTAMS areas) not maintained • A29 Incorrect type / identifier of controlled airspace determined (if cleared for controlled airspace operations) • A35 Incorrect airfield layout / ground taxi route determined • A36 Inability to determine ground / air transition clearly • A37 Unable to correctly determine position of fixed / mobile ground obstacles • A38 Inability to accurately determine command datalink signal strength • A39 Incorrect status of command datalink system serviceability determined • A41 Command datalink handed to GCS, but GCS unaware it has control • A43 Command datalink lags via satellite / relay • A45 satellite / relay UAV passes control datalink commands to incorrect UAV • A47 Command Datalink jammed • A49 Valid command datalink rejected as jammed / stolen • A52 Inability to monitor initial / changing weather conditions along the mission route • A53 Bad weather re-routing infringes sensitive airspace / overflown areas • A54 Bad weather re-routing exceeds UAV capability (performance) • A58 Diversionary airfield / route not communicated between UAV and GCS (UAV not aware of appropriate action to take, or GCS not aware what action the UAV will take) • A62 GCS moding initiates ground mode displays and controls (e.g. mission planning), when in-flight monitoring / control required • A68 UAV centre of gravity adversely affected by fuel charge • A70 Different mission plans loaded - UAV; relay UAV; first GCS; other GCS in mission • A72 inability to correctly detect, interpret and respect airfield visual signals • A77 Radio frequency changed in error (e.g. to emergency frequency) • A78 UAV does not correctly comply with Airfield ATC procedures: ground movement (clearance & direction); enter runway; take-off; climb out direction and final height; approach direction; circuit direction; runway allocation; hold height & direction; landing clearance; exit runway clearance • A79 UAV does not correctly comply with en-route airspace ATC procedures: Climb / descend and final cruising altitude; heading change; hold position, height and direction; diversion • A80 UAV complies with Airfield or En-route ATC procedure intended for another aircraft • A81 Unable to correctly broadcast emergency message: “Collision Avoidance Fail”; Data link fail"; "Mayday" • A82 Emergency broadcast made when none necessary • A88 UAV resembles other aircraft types of different size or performance
This list seems eclectic, and it is awkward to pick out particular aspects where the FFA method might have been ‘better’ than SWIFT. Overall, the longer listing was due to the rigour applied to identifying functions, especially using the Rich Context Diagram to identify external functions (the SWIFT perhaps focussed on the internal). The FFA also performed well in identifying hazards related to the operating environment and their airworthiness implications, such as in collision and terrain avoidance, and in airmanship through airspace and airfield environments. Summary of Hazard Identification Robustness In all, the FFA performed well in hazard identification, identifying around 90% of hazards relating to integration of UAVS into non-segregated airspace even as a one-man technique carried out in isolation. With team input and peer review, this would improve further. However, it is important to remember that FFA is just the first part of the ARP4761 process, and subsequent causal and sub-system analyses are important to draw out all pertinent hazards. Additionally, techniques such as Operation & Health Safety Analysis and especially Human Factors Engineering will be necessary, to ensure all potential hazards are identified and managed.
77
PART 4 – CONCLUSIONS AND FURTHER WORK This part of the report aims to pull together the key findings of the project, and relate them to the original aims. It also provides a ‘shopping list’ of recommendations for further work, in order to advance the cause of UAVS integration.
4.1 Findings, Related to Satisfaction of the Project's Aims The overall motivation for the project was to assist the process of integration of UAVS into unsegregated airspace, by addressing the lack of understanding of the safety issues and hazards involved. More specifically, the following aims were identified: •
To identify the current concerns over UAVS safety, in relation to the existing manned airspace infrastructure;
•
Hence, to derive a framework for considering the safety risks related to integrating unmanned vehicles into unsegregated airspace. The intent is that this, as part of a robust safety assessment and certification programme, will assist in the eventual clearance of UAVS, to operate routinely alongside manned aircraft.
Each of the reports key findings is considered below, in relation to these aims. Conclusions are numbered 1-14 in this section.
4.1.1 Identifying Current Concerns over UAVS Safety Part 1 went somewhat further than the initial intent of identifying current concerns in relation to the existing manned airspace infrastructure. Because of the complex, interrelated nature of UAVs, a more complete view of safety concerns was taken, which included the airspace infrastructure but also covered design airworthiness, operations, airmanship and the inherent ‘differences’ introduced by UAVSs. As a result, a broad range of safety issues was identified, in two main areas: Safety issues relating to UAVs as ‘disruptive technology’ UAVs have some vital differences from the current general experience with manned aviation, and these introduce some potential safety issues to be overcome: 1. UAVS come in wide varieties, in terms of shape size and performance, and the types of roles they undertake. This makes them difficult to ‘pigeon-hole’, and means that they may be difficult to manage or predict, among manned traffic. (Section 1.1.1). 2. The UAVS system boundary is much broader (and less well understood) than for manned aviation, with inclusion of additional critical aspects such as datalinks, Ground Control Systems, data flows, data sources etc. This leads to questions of airworthiness as a complex system, reliability of datalinks, and availability of RF spectrum for critical links. (Section 1.1.2). 3. Vehicle autonomy creates several issues, starting with its definition! Clear indication is needed of ‘who is in control’, especially when emergency action is required. There is a dichotomy between requiring a predictable response (especially for ATM decision making), yet needing flexibility of response to achieve a safe outcome. New technologies such as agent-based control could provide the necessary flexibility, but introduce questions of expertise, trust and software clearance – they also require strong specification of required behaviour, when this is not explicitly defined for manned aviation. (Section 1.1.3)
78
4. The ‘headline’ catastrophic failure rate for UAVs is currently too high for acceptance into a manned environment. This is due to: poor accident data gathering; the experimental / military roles they are currently undertaking; lack of reliable purpose-built components; and not applying appropriate design, fabrication and maintenance processes to build in safety (as per their manned counterparts). While it is difficult to define ‘equivalent levels of safety’ between UAVs and manned systems, it is suggested that FAR 1309 / ARP 4761 type safety processes could be applied to the design and certification of novel, safety critical aspects, with suitable amendments. (Section 1.1.4) Safety issues relating to the manned airspace environment coming to terms with UAVs 5. While it is agreed that a ‘safety targets’ (Safety Case) approach would be easiest to apply for UAVS, standards and certification must be applied to achieve international acceptance. Hence, regulation, certification and standards are critical to integration of UAVS into unsegregated airspace, but are currently struggling to achieve consensus between different bodies. Thus, while there are proposals for a ‘total system’ approach to safety, currently airworthiness, operations and ATM are managed by different regulators. What little current regulation exists is very generic, demanding equivalence to manned systems but without addressing UAV differences. (Section 1.2.1) 6. Because of current segregation of traffic, very few UAVs have interacted with ATM systems, and so it is difficult to predict the real implications. Because the nature of ATM change is ‘monolithic’, ATM suppliers demand no change, i.e. that UAVS operations must be transparent, while there are numerous ways in which UAVs will react differently from manned aircraft. There are issues of equipage, traffic levels, RF interoperability, voice communications, even basic routes and procedures that have been built around manned aircraft and their performance expectations. (Section 1.2.2) 7. Collision avoidance from terrain and, more difficult, from other aircraft is a big issue for UAVS integration, and UAVs will require a non-cooperative Sense & Avoid capability to match their manned counterparts. It is difficult to define equivalent levels of safety to manned aircraft, as human visual performance is so fallible, hence regulators and designers cannot agree on which should come first – the technology to provide Sense and Avoid, or the criteria that it must meet. (Section 1.2.3) 8. UAVS navigation, datalinks and ground systems vulnerabilities to jamming or malicious take-over must be addressed to ensure security of operation. (Section 1.2.4) 9. For a system ‘unmanned’ in the air, there are significant Human Factors issues to be overcome. Some revolve around the ground cockpit environment, the cues to the UAV-p, the organisation of pilots and commanders, and the interaction with variable autonomous systems. Others involve the experience / competence levels of the pilots, maintainers and operating organisations, plus the extended human network that provides critical data to the UAVS. (Section 1.2.5) 10. As with all safety critical systems, public opinion over safety levels may not match the actuality. However, UAVSs are expected to face a more critical media and public response in the event of a safety occurrence, because of their unmanned nature. (Section 1.2.6)
79
4.1.2 A Framework for Considering Safety Risks Related to Integrating Unmanned Vehicles into Unsegregated Airspace At the end of Part 1, the focus for the project development was set out in order to satisfy the study aims, as follows: A. A better understanding of what the root hazards associated with UAVS integration are. B. Can a .1309 / ARP4761 safety assessment approach be used for UAVS, to identify hazards for solution during design / manufacture / operation? Each of these sub-goals is reviewed in the following paragraphs, to provide a structure to assess whether the main aim has been achieved. The order of the sub-goals has been changed, to reflect the design (Part 2) and test (Part 3) order of the project. Can a .1309 / ARP4761 safety assessment approach be used for UAVS, to identify hazards for solution during design / manufacture / operation? Part 2 has reviewed ARP4761 (which is based on satisfaction of 23.1309 and 25.1309 requirements) to see where it might fall short, in its applicability to UAVS. The concluding statement from Section 2.1 was “The intent of ARP4761 to support the safety assessment (and hence clearance) of novel aircraft systems remains good. If the issues identified above can be addressed, then the revised framework should equally support safety assessment and clearance of UAVS.” The focus for Part 2 of the project has thus been to address these issues with a modified hazard identification methodology, to supplement ARP4761 and thus provide a safety assessment framework suitable for UAVS application. The identified ‘issues’ from Section 2.1 formed the ‘requirements’ for ‘design and build’ in Part 2, Section 2.2. In order to pull together and relate the conclusions for build of the hazard identification methodology, Table 4.1.2(i) has been created (see following pages). This shows the development of conclusions, from the assessment of requirements in Section 2.1, through design and build in Section 2.2. To complete the picture, the conclusions from test and evaluation of the proposed method have been placed alongside (Part 3, section 3.2). 11. In summary, it is concluded that the development of the hazard identification methodology, using a modified functional failure analysis, has resulted in a practicable approach that addresses the gaps in ARP4761 previously identified. As such, the HazID methodology supplements ARP4761 to allow the combined safety assessment framework to be used for UAVS, to identify hazards for solution during design, manufacture and/or operation.
80
Rich Context Diagram to draw out interactions between UAVS and the wider SoS. (2.2.2)
Address the external interfaces of the SoS.
Consider UAVS functions overall; Consider functions determined by the UAVS internal structure (behaviour, control, information, utility); Consider the effects of Flight Phases. (2.2.3)
Consider each Rich Context Diagram interaction for implied functions on the UAVS (behaviour, control, information, utility). (2.2.3)
Internal Functions list to reflect UAVS structure;
Exchanged Functions list to reflect the wider System of Systems;
81
Additions: URD or specification; Simple design / architecture representation; Rich Context Diagram; simple Concept of Operations. (2.2.3)
Source data requirements to cover the complex UAVS structure and interfaces;
Function Identification –
Extend ‘Aircraft-level FHA’ to become ‘UAVSlevel FHA’ (2.2.2)
Dual-criteria system: Airworthiness criteria (as above) plus ATM-focussed separation / collision safety criteria (2.2.1 – Table 2.2.1(ii)
Address the (internal) complexity of the system;
FHA-levels –
Reflect ‘Total safety’ threats through ATM / operating occurrences
Derive UAV kinetic equivalence (based on Annex B); compare with aircraft classes in Table 2.2.1(iii); hence determine probability objectives.
Reflect UAV variety (in lethality);
(2.2.1)
UAVS Airworthiness failure condition severities (Section 2.2.1 - Table 2.2.1(i))
Proposed design solution
Reflect airworthiness safety criteria descriptions related to UAV potential occurrences;
Safety Objectives -
Requirement (Section 2.1)
Rich Context Diagram very good at drawing out interactions – each was then assessed for exchanged functions. Could find no need to keep Internal and Exchanged functions list separate, so they were consolidated into a common Functions Tree. (3.2.3)
Simple design architecture diagram was useful to identify system elements – helpful to take ‘views’ on each element to derive internal functions. Flight phases helped to identify additional functions. (3.2.3)
No URD or formal documentation available to assess. However, simple Case Study documentation proved quite effective. (3.2.3)
Rich Context Diagram proved very useful in identifying SoS interactions. The application would have been improved in practice with stakeholder review. (3.2.2)
UAVS-level FHA was effective in identifying system inter-relations for subsequent analysis (3.2.3)
(3.2.5)
Consideration against duel criteria was straightforward. Application of ATM separation safety criteria was easy in most occasions with a few exceptions. Most failures analysed had duel airworthiness / ATM effect
(3.2.1)
Derivation of airworthiness safety objectives was straightforward.
‘classification of failure effects)
Application of airworthiness safety criteria was straightforward (3.2.5 –
Evaluation
Table 4.1.2(i) – Satisfaction matrix for development of HazID methodology
Review mission types and parameters to identify the various flight phases. (2.2.3)
Flight Phases to reflect UAVS mission complexity & variety
Revised ‘starter list’ suggested. (2.2.4)
Failure condition determination: Not UAVS specific, but FFA structure proposed as good practice, considering: function not provided; provided when not required; incorrect operation of function. (2.2.4)
Assessment of initial design architecture for common causes; Assessment where operation of a function mitigates another, critical functional failure.
Expansion on UAVS emergency configurations
-
Ensure credible combinations of multiple functional failures are considered.
Establish significance of the UAVS mission, environmental and ATM context in evaluating consequences
82
Use of scenarios for complex situations, including environment, mission, airspace context. (2.2.5)
Expanded consideration of mission, environmental range and ATM environment builtin to establishing functions (see above);
Identifying and managing the effects of failure conditions –
Review UAVS domains: Weather; Overflown terrain; Electrical; Mission; Air Traffic environment. May use scenarios (see ‘Identifying and managing …’ below). (2.2.4)
Expansion on UAVS environmental conditions;
Identification of Failure Conditions –
Proposed design solution
Requirement (Section 2.1)
(3.2.5 – ‘use of scenarios…’)
Some complex effects were analysed against scenarios: text-based scenarios were not effective; graphical mission scenarios worked well to present mission, terrain and ATM information and allow ‘what-ifs’.
Established context information was adequate for most failures analysed (as expected).
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’)
Inherently built-in by setting up specific functions, expected in the event of a system failure; mitigating function in an emergency. These were then analysed for additional failures.
(3.2.4)
FFA structure worked well. Care was needed with: pseudo-continuous functions; implied sub-functions; functions crossing system boundaries.
Review of list highlighted need for additional, emergency functions (see above). (3.2.4)
Domain review list provided a good structure for derivation. Nonspecification aspects required care: here, definition of mission scenarios proved useful. (3.2.4)
Derivation and consideration of flight phases was a useful ‘mind jogger’ for additional functions. (3.2.3)
Additional functions were needed for key emergency conditions – this required an initial definition of emergency procedures. (3.2.4)
Evaluation
A better understanding of what the root hazards associated with UAVS integration are. The hazard identification method, designed in Part 2, was assessed in Part 3 against a generic Tactical UAVS. From this application, a listing of potential hazards has been developed (Annex F). Part 3, section 3.3 evaluated the hazards identified, using an alternative hazard identification technique and personnel. From this, the following conclusions have been reached: 12. The proposed HazID method, using a modified ARP4761 FFA approach) has identified around 90% of the likely hazards associated with integrating a (generic) Tactical UAV system into unsegregated airspace. The shortfall is likely to be due to: • the functional analysis being a ‘one-man’ effort, which would benefit from peer review; • the difficulty in drawing out high-level Human Factors issues with FFA, and the importance of Human Factors Engineering to address such issues; • FFA being just part of the ARP4761 framework – additional sub-system analyses such as FTA, FMEA, Common Cause Analysis etc would draw out further hazards. 13. The proposed method was strong in identifying hazards related to the external System of Systems, especially in areas such as the operating environment, in airmanship concerns, and interfacing with airfield and ATM environments. In these respects, it is proposed that the hazard listing has contributed to the understanding of UAVS integration hazards. 14. It should be borne in mind that the hazard listing is specific to the generic Tactical UAVS used for the case study. However, as has been stated (in the introduction and in Section 3.3), the results should have good read across for specific Tactical UAVS, and broad applicability for other types of UAVS, but should be assessed carefully for applicability to particular systems.
4.2 Recommendations for Further Work 4.2.1 UAVS Safety, generally This project has addressed only a few of the safety aspects identified that currently stop UAVS from being integrated into unsegregated airspace. The list at Section 1.3 provides a rich seam of safety issues that require further work: •
Impact of the Variety, Roles and Performance of UAVs
•
The complex system boundary for UAVs
•
UAV autonomy - technology, predictability, complexity
•
Accident rates and reliability - UAV airworthiness
•
Regulation, Certification and the Drive for Standards
•
ATM interaction
•
Collision avoidance
•
Security and safety
•
Human factors, Suitably Qualified & Experienced Personnel (SQEP) and organisations
83
•
Public perception of UAV safety
4.2.2 UAVS Hazard Identification Methodology and Application of ARP4761 Framework This project has shown that it should be practicable to apply the hazard identification methodology, as part of an ARP4761 framework approach to safety assessment for a UAVS. However, several areas for further work exist, to provide confidence in the framework overall: • The project focussed on the hazard identification aspects of ARP4761. It would be useful to extend assessment to look more closely at the follow-on safety assessment activities of ARP4761, including sub-system analyses, PSSA and SSA. • The evaluation work looked at a generic tactical UAV, a broad area in the middle of potential UAVS types. Because of the wide range of UAVS types, it would be beneficial to evaluate application nearer the ends of the spectrum, perhaps for a HALE / UCAV system, and a Micro / Urban system. • The evaluation was also a one-man application to a generic system. Further confidence would be built through documented application to an actual system in development. This could seek to use team / stakeholder involvement to improve the context and functional identification; and apply the revised ARP4761 framework through to certification. • An ATM environment-level FHA (including principles for integration of UAVS) could be undertaken, with involvement of EUROCONTROL, the CAA and/or other regulators. This could aid the development of UAVS policy and (perhaps through decomposition of such policy using methods such as discussed in [Hall05]) support satisfaction of such policy as input to the UAVS-level FHA by the system developers. • A key finding was the suspected criticality of autonomy to the effects of failure. It would be useful to apply the FFA to a known system, but looking at the effects of varying the UAV autonomy level, for each failure.
84
BIBLIOGRAPHY [AST04]
“ASTM International Support to the U.S. Unmanned Air Vehicle Systems Industry - Position Statement”, 2004, ASTM International
[AST05-1] “Role of standards in the latest OSD UAS Roadmap”, May 2005, ASTM International [AST05-2] “Roadmap for Unmanned Aircraft Standards”, May 2005, ASTM International [Bol05]
“CRS Report for Congress: Homeland Security: Unmanned Aerial Vehicles and Border Surveillance”, RS21698, Bolkcom C., Feb 2005, Congressional Research Service, Library of Congress
[Bon05]
“Global Satellite Navigation Systems: Advantages and Vulnerability”, Bonnor N, Feb 2005, Royal Institute of Navigation (RAeS Conference proceedings)
[Bow05]
“Unmanned Aerial Vehicle Flights in UK Airspace”, 8AP/15/19/02, Bowker, Lt Cdr GN, May 2005, Civil Aviation Authority - Directorate of Airspace Policy
[CAA02]
“Aircraft Airworthiness Certification Standards for Civil UAVs”, Haddon DR & Whittaker CJ, Aug 2002, Civil Aviation Authority - Directorate of Airspace Policy
[CAA04]
“Unmanned Aerial Vehicle Operations in UK Airspace – Guidance”, CAP722 (2nd Edition), Nov 2004, Civil Aviation Authority - Directorate of Airspace Policy
[CAS04]
“Civil Aviation Safety Regulations - Part 101 Unmanned aircraft and rocket operations”, CASR Part 101, Dec 2004, [Australian] Civil Aviation Safety Authority
[CSI04]
“MSc in Safety Critical Engineering -Computers, Software & ISA”, CAS, McDermid J & Pumfrey D, Apr 2004, The University of York, Department of Computer Science
[DeG04]
“Issues Concerning Integration of Unmanned Aerial Vehicles in Civil Airspace”, MP 04W0000323, DeGarmo MT, Nov 2004, Mitre Corporation - Center for Advanced Aviation System Development
[dst04]
“Applying Safety Process Measures”, Caseley P, Jun 2004, DSTL (through Safety Critical Systems Club Seminar 'Life Saving Second Opinions')
[EAS05]
“Advance - Notice of Proposed Amendment - Policy for Unmanned Aerial Vehicle Certification”, A-NPA No 16-2005, 2005, EASA
[EUR01]
“EUROCONTROL Safety Regulatory Requirement 4 - Risk Assessment and Mitigation in ATM”, ESARR 4, Apr 2001, EUROCONTROL
[FAA88]
“Advisory Circular: Transport Category Airplanes, Federal Aviation Regulations System Design and Analysis”, AC 25.1309-1A, Jun 88, Federal Aviation Authority
[FAA99]
“Advisory Circular: Normal, Utility, Aerobatic and Commuter Category Aeroplanes - Equipment, Systems, and Installations In Part 23 Airplanes”, AC 23.1309-1C, Mar 1999, Federal Aviation Authority
[Hall05]
“Defining and Decomposing Safety Policy for Systems of Systems”, SAFECOMP 2005/ LNCS 3688/ pp. 37-51, Hall-May M & Kelly T, 2005, University of York Dept of Computer Science
[HFE05]
“MSc in Safety Critical Engineering - Human Factors Engineering”, HFE, Wright P, Feb 2005, the University of York Department of Computer Science
85
[HRA03]
“MSc in Safety Critical Engineering - Hazard & Risk Assessment”, HRA, Kelly T et al, Nov 2003, The University of York, Department of Computer Science
[Hua04-1] “Autonomy Levels for Unmanned Systems (ALFUS) Framework - Volume I: Terminology (Version 1.1)”, NIST Special Publication 1011, Huang HM, Sep 2004, National Institute of Standards and Technology [Hua04-2] “Autonomy Measures For Robots: Proceedings of IMECE”, IMECE2004-61812, Huang et al, November 2004, International Mechanical Engineering Congress [Jos05]
“Model-Based Safety Analysis of Simulink Models Using SCADE Design Verifier”, Joshi A & Heimdahl M, 2005, University of Minnesota Department of Computer Science & Engineering
[LaF05-1] “Mapping A Future”, LaFranchi P, March 2005, Flight Magazine (Reed Business Information) [LaF05-2] “Crash Course”, LaFranchi P, March 2005, Flight Magazine (Reed Business Information) [LeT02]
“VFR General Aviation Aircraft and UAV Flights Deconfliction”, AIAA-2002-3422, Le Tallec C, 2002, ONERA Long-term Design and Systems Integration Department
[Man06]
Meeting with Patrick Mana to discuss EUROCONTROL safety criteria, Apr 2006
[MaP05]
“EADS Current UAV Programmes”, MacPherson W, Feb 2005, EADS / RAeS Conference proceedings
[Mar03]
“Suggested Flight Approval Process for Unmanned Air Vehicles (UAVS)”, Marsters GF & Sinclair M, 2003, AeroVations Associates
[McD03]
“Extending PSSA for Complex Systems”, McDermid J & Nicholson M, 2003, University of York
[Met05]
“UAV Access to UK Airspace - Spectrum Availability”, Mettrop J, Feb 2005, CAA / RAeS Conference Proceedings
[Nel04]
“Prospective UAV operations in the future NAS”, Case#04-0936, DeGarmo M and Nelson G, 2004, Mitre Corporation - Center for Advanced Aviation System Development
[Okr05]
“25 Nations for an Aeronautics Breakthrough”, Okrent M, Feb 2005, UAVNET / RAeS Conference proceedings
[PlJ05]
“Approach to Autonomy”, Platts J, Feb 2005, QinetiQ / RAeS Conference proceedings
[PlP05]
“UAVs and ATM - A Holistic Approach”, Platt P, Feb 2005, QinetiQ / RAeS Conference proceedings
[RQE05]
“MSc in Safety Critical Engineering - RQE: Requirements Engineering”, RQE, Luettgen G & Stepney S, Oct 2005, the University of York Department of Computer Science
[RTC05]
“Special Committee 203 Minimum Performance Standards for Unmanned Aircraft Systems and Unmanned Aircraft - Terms of Reference, revision 1”, RTCA Paper No. 006-06/PMC-438, Dec 2005, RTCA
[SAE96]
“Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment”, ARP 4761, 1996, SAE
[Sch04]
“Defense Science Board Study on UAVs and UCAVs”, Schneider W (Chairman), Feb 2004, DSB for Secretary of Defense
86
[Sin03]
“Integrating UAVs With Conventional Air Operations: Some Regulatory Issues”, Marsters GF & Sinclair M, Mar 2003, AeroVations Associates
[Ste05]
“UAV Access to UK Airspace”, Stenson J, Feb 2005, CAA / RAeS Conference proceedings
[UTF04]
“UAV Task Force Final Report”, JAA / EUROCONTROL, May 2004, EASA
[Wal03]
“Application Of Manoeuvre-Based Control In Variable Autonomy Unmanned Combat Aerial Vehicles”, AFIT/GAE/ENY/03-09, Walan Capt AM, March 2003, [US] Air Force Institute of Technology
[Wei03]
“Safety Considerations for Operation of Small Unmanned Aerial Vehicles in Civil Airspace”, Weibel R & Hansman RJ, Oct 2003, MIT International Centre for Air Transportation
[Wei04]
“Safety Considerations for Operation of Different Classes of UAVs in the NAS”, AIAA-2004-6421, Weibel RE and Hansman RJ, Sep 2004, American Institute of Aeronautics and Astronautics
[Wes05]
“Meggitt Aerial Target Services - History, Utility and the Future”, Westlake-Toms S, Feb 05, Meggitt / RAeS Conference Proceedings
[Whi05]
“Aircraft Airworthiness Standards for Civil Unmanned Aerial Vehicle Systems”, Whittaker C, Feb 2005, CAA / RAeS Conference proceedings
[Wik03]
“Flying with Unmanned Aircraft (UAVs) In Airspace Involving Civil Aviation Activity - Air Safety and the Approvals Procedure”, Wiklund E, March 2003, Swedish Aviation Safety Authority
[Wil04]
“A Summary of Unmanned Aircraft Accident/Incident Data: Human Factors Implications”, DOT/FAA/AM-04/24, Williams K, 2004, Federal Aviation Authority
[Wil05]
“Keynote Address to the RAeS 2nd FEBRUARY 2005”, Willbond T, Feb 2005, RAES / UAVSA
87
ABBREVIATIONS & ACRONYMS Autonomy
A-NPA AOPA ASTM ATC ATS ATM
BLOS
(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] Advance – Notice of Proposed Amendment EASA advance issue of a document, advising of proposed changes to regulation and inviting comment from stakeholders Aircraft Owners & Pilots Association American Society for Testing and Materials US society for development of consensus based standards. Air Traffic Control Relates to the interaction with (or inputs to) the aircraft, as defined by the Air Traffic Controller - Output of the ATM Air Traffic Service Air Traffic Management The wider ground, personnel and procedural system that provides Air Traffic Control as its output Beyond Line Of Sight Long range guidance and command datalinks, where signals must be bounced, bent or relayed to reach beyond terrain or earth's curvature masking. See also OTH.
Chicago Convention The Convention on International Civil Aviation set out that "...the undersigned governments having agreed on certain principles and arrangements in order that international civil aviation may be developed in a safe and orderly manner and that international air transport services may be established on the basis of equality of opportunity and operated soundly and economically." CAA Civil Aviation Authority Where not otherwise qualified, refers to the UK authority CCA Common Cause Analysis Generic term encompassing Zonal Analysis, Particular Risks Analysis and Common Mode Analysis. In these methods, analysis is made of common modes of failure, which could affect a number of elements otherwise considered to be independent. [SAE96] C4 Command, Control, Communications, Computers Description of military command elements pertinent to a system. May refer to C2, C3 etc as applicable to the system under consideration. Comms Communications Usually referring to technology or infrastructure ConOps Concept of Operations Documentation describing how a system is intended to be used in-service. DoD DSA dstl
Department of Defense (United States) Detect, Sense and Avoid US terminology for S&A Defence Science & Technology Laboratory UK MoD centre of scientific excellence, providing scientific advice to the Armed Forces.
EASA
European Aviation Safety Agency The European Aviation Safety Agency is the organ of the European Union to set strategy for aviation safety. While national authorities continue to carry out the majority of operational tasks… the Agency ensures common safety and environmental standards at the European level." Electronic Intelligence Electronic Counter-Measures Electro-Magnetic Compatibility Electro-Magnetic Interference European Union European Organisation for Civil Aviation Electronics European regulatory body, advising EUROCONTROL and EASA
ELINT ECM EMC EMI EU EUROCAE FAA FAR
Federal Aviation Authority US government organisation for the advancement, safety and regulation of civil aviation Federal Aviation Regulations Aviation regulations as issued by the FAA
88
FHA
FFA
FIR FMEA FTA FTS
GCS GLONASS GNSS GPS
HALE HazID HF HIRF
HIRTA HMI HRI
ISTAR ICAO
IFR
JAA JAR
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. 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. Flight Information Region As in the UK FIR, describes the majority of airspace covered by advisory rather than mandatory Air Traffic Control. Failure Modes and Effects Analysis Safety analysis to determine hazard effects of lower level system and component failures – part of SSA and PSSA Fault Tree Analysis Subsequent safety analysis to determine contributory causes for potential hazards – part of SSA and PSSA 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 hardover. Galileo European / US / ICAO supported civilian controlled GNSS Ground Control System Ground-based system elements that allow the UAV-p to control the UAV Global'naya Navigatsiomaya Sputnikova Sistema Russian GNSS Global Navigation Satellite System Generic name for GPS Global Positioning System Navigation system set up by the DoD, using 24 orbiting satellites to transmit timing information and allow receiving systems to calculate their position by triangulation and measured signal timing differences (pseudo-ranges) High Altitude, Long Endurance UAV type characterised by its intended operating altitude and endurance. See also MALE 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. Human Factors 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 High Intensity Radio Transmission Area HIRF transmitter of known location, identified on maps to alert pilots (and hence to avoid them) Human / Machine Interface See 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'. Intelligence, Surveillance, Targeting and Reconnaissance International Civil Aviation Organisation The International Civil Aviation Organization, a UN Specialized Agency, is the global forum for civil aviation. See web site at www.icao.int Instrument Flight Regulations Set of specific regulations that a pilot / aircraft must comply with (including required equipment) in order to fly when defined visibility criteria for VFR are not met Joint Aviation AuthorityAdvisory group consisting of the various European civil aviation authorities. Now superceded by EASA Joint Airworthiness Requirement Airworthiness requirement issued by JAA. Now superceded by EASA CS regulations
89
MAFF MALE
Ministry of Agriculture, Fisheries and Food UK government ministry 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 NATO NEC nm NTSB
National Air Space Term covering airspace under US regulatory control North Atlantic Treaty Organisation Military organisation originally set up by western countries forces, to counter the threat from the Soviet bloc. 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. Nautical Miles 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
PSSA
Preliminary System Safety Assessment A systematic evaluation of a proposed system architecture and implementation based on the Functional Hazard Assessment and failure condition classification to determine safety requirements for all items - see also FHA and SSA [SAE96]
RC RF RoW
Remote Control See RPV Radio Frequency Right of Way Agreed principles for aircraft rights of way (who has precedence), in accordance with ICAO and national Rules of the Air. Area Navigation Remotely Piloted AircraftSee RPV Remotely Piloted Vehicle Usually indicates a UAV with virtually no autonomy, in that its flight controls are directed manually (and continually) by a ground-based pilot. Radio Technical Commission for Aeronautics US society for production of consensus based standards
RNAV RPA RPV RTCA Sensor
S&A
SCADE SOP SoS
Long range guidance and control datalinks - see BLOS also
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] 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. Safety Critical Application Development Environment Standard Operating Procedures Defined procedures to be manually followed, in the event of expected normal or emergency arisings. 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 SSA
SSR
SWIFT
TAWS TCAS
TUAV
Suitably Qualified and Experienced Personnel Term used to reflect the need for personnel to be competent to perform safety-related duties 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] 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’. 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. Terrain Awareness & Warning System [See also GPWS] Traffic awareness & Collision Avoidance System Co-operative system, based on transponder responses from equipped aircraft - each aircraft in a potential collision path is given a mutually compatible avoidance manoeuvre to fly, to avert the risk. Tactical UAV UAV type characterised by the scope of its operations for gathering military intelligence
UAV Commander A suitably qualified person responsible for the safe operation of a UAV System during a particular flight and who has the authority to direct a flight under her/his command [CAA04]. UAV Operator The legal entity operating a UAV System.[CAA04] UAS Unmanned Aerial System See UAVS UAV Unmanned Aerial Vehicle Usually refers to the flying vehicle itself (see UAVS below). CAA definition is 'An aircraft which is designed to operate with no human pilot on board.' [CAA04] UAV-p UAV Pilot Person directly in control of the UAV, under command of the UAV Commander. UAVS Unmanned Aerial Vehicle System Includes all aspects of the system (including ground elements such as the GCS and sometimes even the 'soft' elements such as the operating organisation and procedures). Sometimes referred to as UAS - Unmanned Aerial System. UCAV Unmanned Combat Air Vehicle UAV designed and intended to deliver weapons against other air vehicles or ground targets. The definition is usually intended to cover a system that has some level of autonomy (not purely under manual guidance), and that can return (i.e. not just a guided weapon) UK United Kingdom ...of Great Britain and Northern Ireland UML Unified Modelling Language A standardised language for specifying, visualizing, constructing, and documenting the artefacts of complex systems (usually but not necessarily software), using graphical notation. URD User Requirement Document High level requirement document, setting out the user-focused requirements for a system (i.e. what the end-user must be able to achieve with a system, rather than how it is to be achieved). US United States ...of America UTF UAV Task Force Joint task force between JAA and EUROCONTROL, to explore UAV integration and implications for ATM. VFR VHF VOR Vmo Vs www
Visual Flight RegulationsAirmanship regulations that must be followed by pilots / aircraft, when visibility and weather conditions conform to required criteria. Very High Frequency Radio Frequency range used for ATC communications VHF Omni-directional Range Ground beacon-based navigation system Maximum Operating Speed Defined velocity criteria for an aircraft design. The speed that the design cannot exceed, without damage to the airframe or loss of control Stalling Speed Defined velocity criteria for an aircraft design. The speed that the design cannot fly below, without stalling (losing lift and possibly control). World Wide Web
91
ANNEX A REVIEW OF ARP 4761, TO SUPPORT ARP 4758, CS 25.1309 ETC FOR UAV APPLICATION
A-1
Reference: [SAE96] - ARP 4761 Issue 1996-12
INTRODUCTION TO REVIEW SAE International - "the Engineering Society for advancing mobility - Land, Sea, Air, Space" publish various ARPs (Aerospace Recommended Practice) to aid industry in achieving required standards. ARP4761 [SAE96] provides "Guidelines And Methods For Conducting The Safety Assessment Process On Civil Airborne Systems And Equipment": it is a companion to ARP 4754 which is aimed at the certification methods for complex airborne systems, but both are intended to provide a systematic means by which satisfaction of FAR 25.1309 [FAA88] and its JAR (now EASA CS) equivalent can be shown, for civil aircraft. The comments below discuss the applicability of the guidelines and methods in terms of assessment for a UAV System. In particular, the review looks at the hazard identification aspects (predominantly the Functional Hazard Assessment (FHA) proposed by ARP 4761).
SECTION 1.
SCOPE
This sets the scope for 'aircraft level safety assessment' - this would need to be developed for the broader UAVS scope (or System of Systems (SoS) scope - see section 1.1.2).
SECTION 2.
REFERENCES
The references to standards would need to be revised in light of the standards being adopted, adapted and created for UAVS applicability (see section 1.2.1).
SECTION 3. Section 3.1
SAFETY ASSESSMENT PROCESS Safety Assessment Overview
This section draws in the safety objectives from FAR / JAR 25.1309 (becoming EASA CS.25.1309), as shown below:
Table A(i) - Safety Objective, from ARP 4761 (drawn in turn from CS.25.1309)
A-2
On initial review, it can be seen that the criteria are driven to the most demanding, as required for EASA and FAA requirements at the '25.1309' heavy-end of the vehicle spectrum. As noted in [Wik03], in section 1.1.4 of this report, there is a spectrum of requirements pertinent to the scale of the vehicle - 10-9 per fg hr for a heavy transport increases to 10-6 per fg hr for a single engine aircraft under 6000lbs. It can also be seen that these criteria are lacking in their UAVS applicability, such as having no occupants, the remote / autonomous nature of their crew, and (implicit) differences in system arrangements. These aspects were noted by the JAA / Eurocontrol UAV Task Force - in their report [UTF04, chapter 7.5], they suggested modifications to the criteria, as follows: o
The worst UAV Hazard Event designated as 'Catastrophic' or Severity I Event may be defined as the UAV's inability to continue controlled flight and reach any predefined landing site, i.e. an UAV uncontrolled flight followed by an uncontrolled crash, potentially leading to fatalities or severe damage on the ground.
o
The overall (qualitative) Safety Objective for UAV System may subsequently be "to reduce the risk of UAV Catastrophic Event to a level comparable to the risk existing with manned aircraft of equivalent category".
o
Quantitative safety objective for the individual UAV 'Catastrophic' or 'Severity I' conditions and/or for the sum of all failure conditions leading to a UAV Severity I Event should be set, per UAV category, considering:
o
o
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.
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.
The quantitative probability ranges required for lower severities should be derived from the quantitative required objective for the worst severity.
While these suggestions clarify the qualitative aspects of the criteria, care would be needed where a quantitative assessment was to be applied. Some of the issues associated with this are discussed in this report at section 1.1.4. In the above, what do the Severity I-V categories refer to? Discussion with Patrick Mana of EUROCONTROL [Man06] clarified their concern that the ARP 4761 criteria reflected an airworthiness-focused accident consequence (i.e. loss of the aircraft with its occupants and / or harm to personnel on the ground). In order to focus safety management within ATM system development, EUROCONTROL considered that further criteria were required to deal with the effects on the ATM environment. For this reason, they have published their risk management regulations (at system level) in EUROCONTROL Safety Regulatory Requirement 4 (ESARR 4) [EUR01]. These criteria covered: A-3
o
Effect of hazard on air crew, (E.g., workload, ability to perform his/her functions);
o
Effect of hazard on the Air Traffic Controllers, (E.g., workload, ability to perform his/her functions);
o
Effect of hazard on the aircraft functional capabilities;
o
Effect of hazard on the functional capabilities of the ground part of the ATM System;
o
Effect of hazard on the ability to provide safe Air Traffic Management Services; (E.g., magnitude of loss or corruption of Air Traffic Management Services/functions).
The discussion with Patrick concluded that, to support EASA's requirement for total system safety, and EUROCONTROL's particular requirements for air collision risk, a UAV-focussed safety process would need to accommodate both cs.1309 airworthiness criteria and, somehow, the ATM criteria. These are reproduced in Table A-2 below from [EUR01] for comparison. Note that, unlike the FAA / EASA ‘airworthiness’ requirements of 25.1309 and 23.1309, these requirements are absolute and do not vary with the size or category of the aircraft. Also, EUROCONTROL have only identified one end of the risk spectrum: Severity 1 accidents must not occur more than 1.55 x10-8 per fg hr.
Table A(ii) - Severity Criteria as defined in ESARR4 by EUROCONTROL
Section 3.2
Functional Hazard Assessment (FHA)
The usual route proposed by ARP4761 is to carry out an Aircraft Level FHA, a high level, qualitative assessment of the basic functions of the 'aircraft' as defined at the beginning of aircraft development. This is then followed with a System Level FHA, which is iterative in nature and becomes more defined and fixed as the system evolves. It considers a failure or combination of system failures that affect an aircraft function. The intent is to work towards identification of the appropriate Development Assurance Level (DAL) for each aircraft function and the system functions that affect it. These in turn help to identify the level of development, qualification and certification activity required to provide adequate assurance that each function has been safely implemented. The output from the aircraft and system level FHAs is used to set the safety requirements for the detailed design process, so it is vital that all pertinent safety hazards have been identified by this point. A number of questions emerge at this point, in trying to apply this process to UAVS: o
Is an 'aircraft level' FHA appropriate as the start point for UAVS assessment? ARP4761 propose this as the highest level for consideration, but for UAVS there is A-4
the 'super-system', the SoS whose support is critical to mission (and safety) assurance. o
How is the integration of systems best handled, to ensure all hazards are identified? In particular, integration of the people and procedural systems, as well as the extended system technical elements?
Here, ARP4761provides comment over the integration of systems: "The safety assessment process for integrated systems should take into account any additional complexities and interdependencies which arise due to integration. In all cases involving integrated systems, the safety assessment process is of fundamental importance in establishing appropriate safety objectives for the system and determining that the implementation satisfies these objectives." As noted in section 1.1.2 of this report, this is particularly pertinent (and challenging) for UAVS and the extended boundary of the System of Systems (SoS). The section goes on to discuss the role of Functional Hazard Assessment (FHA) at the beginning of the development process, to set appropriate safety objectives and requirements. One of the problems I foresee is that, because of the loose and fluid nature of the UAVS system boundary, the complex interaction with the SoS, and the variable nature of where functions are controlled (through autonomy), there may be a whole mess of 'exchanged functions' that will be difficult to identify and assess, until at least initial UAVS high-level architectures are outlined. The ARP does suggest that the FHA is reviewed once the functions begin to be allocated to systems, but this could prove to be a significant part of the assessment for a UAVS. The follow-on work for Preliminary System Safety Assessment (PSSA) and System Safety Assessment (SSA) could draw out such interactions, especially through work elements such as Common Cause Analysis (CCA), but the ideal would be to identify these hazards early on, before the system architecture begins to 'harden-up' in the development process, and change becomes more difficult. Also, these latter analyses are aimed more at identifying and mitigating causes for the potential hazards already identified, rather than identification of new hazards.
Section 3.3 and on: Preliminary System Safety Assessment (PSSA), System Safety Assessment (SSA) This report will not look in any detail at the PSSA-onwards part of the process, as the ARP assumes that all hazards have (in the main) been identified during FHA, and our focus is on hazard identification. As ARP4761 describes this aspect: "A PSSA is used to complete the failure conditions list [i.e. the causes of hazards] and the corresponding safety requirements. It is also used to demonstrate how the system will meet the qualitative and quantitative requirements for the various hazards identified. The PSSA process identifies protective strategies, taking into account fail safe concepts and architectural attributes which may be needed to meet the safety objectives. It should identify and capture all derived system safety requirements (e.g., protective strategies such as partitioning, built-in-test, dissimilarity, monitoring, safetyrelated tasks and intervals, etc.). The PSSA outputs should be used as inputs to the SSA and other documents, including, but not limited to, system requirements, hardware requirements and software requirements." What is useful to consider here, is that other reviewers have found aspects of ARP4761 that need bolstering, in order to apply PSSA to complex systems and SoS. McDermid and Nicholson [McD03] proposed that some extensions to the guidelines and methods were necessary to deal with (in particular) the people, processes and software that characterise such complex systems and their interactions with other systems. [McD03] focuses on the design-centred PSSA part of the cycle, where the comments will, of course, be especially A-5
applicable for UAVS. However, the comments could apply equally to the up-front FHA aspects, especially where the UAVS will have to fit into an existing SoS with pre-defined equipment and people elements (such as ATM and, perhaps, common mission planning and GCS systems). The paper suggests that additional hazard identification methods are required to deal with software-rich and people-centred aspects - elements of this could be brought forward into FHA for UAVS assessment, where pre-existing systems have to be integrated with, or could be adapted to help deal with the system interactions known to exist at the FHA stage. For the SSA stage, the assessment requires a defined design to be validated against the developed safety requirements - this is not the focus for our report, but there could be interesting questions over use of traditional safety analyses such as Failure Modes and Effects Analysis (FMEA) in people- and software-rich systems, and interactions across complex SoS.
SECTION METHODS
4.
SAFETY
ASSESSMENT
ANALYSIS
The ARP describes a number of useful PSSA and SSA related safety assessment techniques, and little needs to be said here. However, there are some aspects of interest relating to Common Cause Analyses (CCA) that should be touched on here, perhaps as pointers for future studies: o
Zonal Hazard Analyses - the question here is over the definition of zones. With the extended UAVS and SoS, potentially zone definition needs to be extended likewise. For example, the SoS includes critical navigation elements in space (if using GPS), and datalinks transmitting through a common RF environment with other transmitters.
o
Particular Risk Analysis - the suggested list could be extended to consider particular risks specific to UAVS, such as datalink failure.
APPENDIX A - FUNCTIONAL HAZARD ASSESSMENT A fair amount has already been said about FHA above, relating to UAVS. Here, we will only discuss new aspects that become pertinent from the ARP text. In A.1, the ARP again sets the intent to conduct the FHA at ‘Aircraft’ and ‘System’ levels – this we have discussed above, with the complications for UAVS of the complex system boundary, and the system of systems interactions. The section goes on to suggest that "It is desirable to establish an aircraft level general hazard list to be used on future projects so that known hazards are not overlooked." This would be a useful step forward, provided that it is not used to limit the application to a new UAVS, where additional and different hazards might exist. A.3 introduces the ARP-proposed FHA process. The suggested process for conducting the Aircraft level FHA is reproduced below in Figure A-1 (a separate figure is presented in the ARP for the System-level FHA, but does not differ significantly, for our purposes).
Section A3.1 Function Identification A3.1.1 provides guidance on source data for the FHA. For the Aircraft-level, a fairly simple list is proposed: •
The list of the top-level aircraft functions (e.g., lift, thrust, etc.)
• The aircraft objectives and customer requirements (e.g., number of passengers, range, etc.) A-6
•
Initial design decisions (e.g., number of engines, conventional tail, etc.)
This is based on an assumption of simple interfaces between the ‘aircraft’ and the external world, because the ARP provides a much more detailed list for the System-level FHA, where interfaces between system elements, and initial design decisions are critical. For our consideration of the UAVS being part of a complex System-of-Systems, the listing for the system-level FHA (or similar) might be more appropriate? We will touch more on this later, as we look at the FHA process and its needs.
Figure A-1 - ARP4761 Process for an Aircraft-level FHA
A-7
Following the process model outlined in Figure A-1 above, A.3.1.2 looks at creation of the function list. • A.3.1.2a refers to ‘internal’ functions, which are the main high-level functions of the aircraft, and the functions assumed to exchange internally within the aircraft system (presumably from initial design assumptions). For our UAVS with its complex system boundary (even when just looking internally, with the UAV, the GCS and immediate high-level system assumptions), the list of ‘typical’ internal functions would need to grow considerably – and guidance needs to be given on defining what is the high-level system (as discussed in this report at section 1.1.2). These internal functions might vary with our initial design assumptions over the UAVS architecture, and it will be difficult to keep our view to the overall system (e.g. not to dive down into system design, or discussions of autonomy, but to cover all functions within the system ‘bag’ together). • A.3.1.2b refers to ‘exchanged’ functions, put simply as functions that interface with other aircraft or ground systems. This is where our SoS would really take effect, and needs careful guidance on how to ensure no functions are missed. Perhaps this is where the scope of the ARP application extends beyond the airworthiness it was originally intended for, into the total safety approach desired by EASA / Joint European UAV Task Force. The A.3.1.2 process box in Figure A-1 also refers to identification of flight phases, though little guidance is given in the text. Where flight phases for an airliner might be fairly simple to define (ground handling; take-off; climb-out; etc…) for a typical operation, the problem with UAVS will be the variety of mission types (as discussed in this report at section 1.1.1). Also, within aerial work mission types, the mission may be made up of several different phases, or have optional phases, rather than the predominant cruise-phase in transport flying. These flight phases are required to help draw out the ‘aircraft’ functions and also to understand the consequences of functional failures (see A.3.2.2 below), so it is important that they are well explored for the UAVS. A problem here might also be the lack of suitably experienced personnel with expertise in such operations for UAVSs, to support the analysis.
Section A.3.2
- Identification and Description of “Failure Conditions”
A.3.2.1 discusses the creation of a list of Environmental and Emergency Configurations, to add to the consideration of failure effects. Environmental aspects may require more detailed definition, as UAVs may operate in significantly different environments from manned aircraft, due to their performance or role. For example, a HALE type UAV will operate at extremely high altitudes, where environment effects such as icing, Jetstream winds, or even obscure phenomena such as gravity waves might have an effect. Small, low level UAVs used for (say) pipeline surveying may be susceptible to terrain induced turbulence or wind shear. In general, UAVs are more sensitive to climatic effects than their manned counterparts ([DeG04, para 2.1.4]). UAV roles and performance may also introduce other peculiar environmental events, such as personnel change-over during long endurance missions. For the emergency configurations, some may need to be specified from regulatory sources (such as the particular risk for data-link loss); others may come from the initial assumptions over the UAV performance, role, or overall architecture. A.3.2.2 considers how failures could occur singly, or combine into multiple failures. This may be tricky to achieve sensibly for the UAVS because of the wide SoS: the potential for multiple failures exists from so many sources.
A-8
Section A.3.3 to A.3.8 – Identifying and Managing the Effects of Failure Conditions The remainder of A.3 looks at how the effects of failure conditions are determined then flowed down into safety objectives for lower level design and safety analyses. What is not stated here, but is discussed in A.3.1.2 and is implied from the process chart, is that flight phases provide a key input in determining the severity of effects. In fact, because UAVs have no occupants and hence less generic airworthiness concerns, the context of where they are and what they are doing when failure occurs, is critical in determining the consequential effect on other airspace users or overflown populations. ARP 4761 seems to lack the necessary direction to establish this mission / environmental / ATM context in which to place the UAVS failure.
Section A.4 – FHA Outputs A.4 looks at the outputs from aircraft and system FHAs, into the remaining PSSA and SSA processes. Without going in depth into the implications of UAVS analysis for these processes, the requirements seem fairly valid, but would need further validation to support actual use. What is encouraging is the message to document the process thus far, not just to support the further analyses but also to improve the knowledge base for when the next FHA analyses are required. UAVS lack the overall expertise and experience that has grown over the years for manned aircraft, and concerted efforts are required to build the knowledge base of available information, to save future engineers having to develop such experience themselves in real-time!
ANNEXES B – L Annexes B to K cover more in depth safety analyses aimed at implementing the safety requirements identified herein, and are not covered in this review. Annex L provides a worked example that is pertinent to the manned aircraft, and again is not covered here.
A-9
ANNEX B EXTRACT FROM [CAA02] - A METHOD FOR SETTING DESIGN STANDARDS FOR NEW KINDS OF AIRCRAFT, INCLUDING UNMANNED AIR VEHICLES
B-1
Extracted from [CAA02]
This [document] describes a method for obtaining a first outline of the airworthiness standards which should be applied to aircraft of novel design. The method compares the hazard presented by the new aircraft with that of existing conventional aircraft to obtain an indication of the appropriate level of requirements which should be applied. The most significant feature of the proposal is that it relies on a comparison with existing conventional aircraft design requirements which contribute to a currently accepted level of safety, and avoids controversial assumptions about future contributions to that level of safety from operational, environmental or design factors.
COMPARISON CRITERIA The capability of a vehicle to harm any third parties is broadly proportional to its kinetic energy on impact. For the purposes of the comparison method it is assumed that there are only two kinds of impact; either the impact arises as a result of an attempted emergency landing under control, or it results from complete loss of control. More precisely, the two impact scenarios are defined as: 1. Unpremeditated Descent Scenario - A failure (or a combination of failures) occurs which results in the inability to maintain a safe altitude above the surface. (e.g. loss of power, WAT limits etc).
2. Loss of control scenario - A failure (or a combination of failures) which results in loss of control and may lead to an impact at high velocity. Unpremeditated Descent Scenario:
For many air vehicles the likelihood of the unpremeditated descent will be dominated by the reliability of the propulsion systems. For the calculation of kinetic energy at impact the mass is the maximum take-off mass and the velocity used is the (engine-off) approach velocity. i.e. For aeroplanes V = 1.3 X Stalling Speed (Landing configuration, MTOW) For Rotorcraft V = Scalar value of the auto-rotation velocity vector, For Airships/Balloons V = The combination of the terminal velocity resulting from the static heaviness, and the probable wind velocity. Loss of Control Scenario:
For the calculation of kinetic energy at impact for the loss of control case the mass is the maximum take-off mass and the velocity used is the probable terminal velocity. i.e. For aeroplanes V = 1.4 X Vmo (the maximum operating speed) For Rotorcraft V = Terminal velocity with rotors stationary. For Airships/Balloons V = Terminal velocity with the envelope ruptured or deflated to the extent that no lifting medium remains.
For each scenario the kinetic energy has been calculated for a selection of 28 different civil aircraft; (21 aeroplanes, and 7 rotorcraft). The results are shown in Figures [B-1] and [B-2]. On each Figure the “applicability region” for each of the existing aeroplane and rotorcraft codes is shown. These regions have been established using practical constraints based upon the sample of the existing fleet, plus any weight and speed limitations specified in the applicability criteria of the codes of airworthiness requirements.
METHOD OF COMPARISON To obtain the indication of the level of requirements appropriate to a novel kind of aircraft the following steps are carried out: B-2
1. Calculate the kinetic energy of the new aircraft for each scenario. 2. Using these values and Figures [B-1] and [B-2] separately, determine the appropriate code to be applied with the intent of preventing the occurrence of each scenario. i.e: Figure 1 will provide an indication of the standards to be applied to any feature of the design whose failure would affect the ability to maintain safe altitude above the surface. Figure 2 will provide an indication of the standards to be applied to any feature of the design whose failure would affect the ability to maintain control, (particularly rate of descent). Clearly, this must include primary structure. If it is found that the aircraft fits within the region for more than one code then this would indicate that it may be appropriate to apply a combination of standards. (e.g. JAR-25 with reversions to JAR-23 in some areas, or JAR-23 with Special Conditions taken from JAR-25). 3. Construct a certification basis which addresses the same aspects of the design as the existing codes and to the level indicated by the kinetic energy comparison. Clearly, Special Conditions will need to be considered for any novel features of the design not addressed by the existing codes. However, the extent of such special conditions should be comparable with the general level of airworthiness identified.
Note: In addition, operational requirements may dictate the inclusion of particular design features which may in-turn necessitate the inclusion of additional certification requirements. For example, the Rules of the Air specify that an aircraft operating over a congested area must be able to maintain a safe altitude following the failure of one power unit.
WORKED EXAMPLES Application to Global Hawk Global Hawk is a High Altitude Long Endurance (HALE) UAV produced by Northrop Grumman in the USA with a primary role of reconnaissance/surveillance. Global Hawk is powered by a single turbofan engine. Its estimated characteristics are: a gross weight of 25,600lbs (11,600kg), a maximum operating speed (VMO) of 345kts and a stall speed (VS) of 95kts. Using these parameters gives energy levels of 0.177 (unpremeditated descent scenario) and 3.53 (Loss of control). These are illustrated in Figures [B-1 & B-2] and indicate that JAR-25 standards are applicable throughout.
Application to Predator The RQ-1A Predator UAV from General Atomics is a Medium Altitude Long Endurance (MALE) UAV which has seen extensive operational experience within the military. Powered by a single piston-engine, the estimated parameters for Predator are: MTOW of 1,900lbs (855kg), Vmo of 120kts and Vs in the region of 56kts. For the “unpremeditated descent” scenario, this equates to energy levels of 0.0046 (JAR-23 single-engine) and for the “loss of control” scenario 0.024 (JAR-23 single-engine). The certification basis for the Predator would therefore be JAR 23.
Application to Hunter Hunter from IAI is a short range UAV which was/is operated by the armies of USA, Israel, Belgium and France. The Hunter comes in both standard and endurance versions and is powered by 2 Motto-Guzzi engines. The two versions of the aircraft have gross weights of 726 kg and 952 kg respectively. The values for each version and each scenario are shown in Figures [B-1 and B-2]. Although there is a small overlap with JAR-VLA in one case, it can be seen that the guideline standard is JAR-23 for both versions of the aircraft.
B-3
Application to StratSat StratSat is an unmanned communications airship intended for long duration missions stationed above population centres. For this aircraft the “unpremeditated descent” analysis indicates that a standard equivalent to JAR-23 as applied to single-engine aeroplanes would be appropriate. This is convenient as the existing UK requirements for airships, BCAR Section Q, provide a standard which is equivalent to JAR-23. The “loss of control descent” analysis indicates that standards equivalent to a combination of JAR-25 and JAR-23 Commuter Category should be applied to reduce the probability of such an event. Thus the basis for civil certification of this aircraft should be BCAR Section Q supplemented as necessary by requirements from JAR-25 and JAR-23 Commuter.
CONCLUSIONS A method of comparing novel aircraft with existing manned aircraft is presented together with examples of its application to specific UAV projects. It is appreciated that no simple method can give a complete answer to the definition of the certification bases, and the conventional processes using judgment and debate will still be required. However, the method presented provides a useful tool for anticipating the general level of airworthiness requirements to be set.
B-4
[Velocity = 1.3 x Vstall]
Figure B-1 – Unpremeditated Descent Scenario
B-5
[Velocity =1.4 x Vmax operating]
Figure B-2 – Loss of Control Scenario
B-6
ANNEX C 'GUARD DOG' - GENERIC TUAV CASE STUDY
C-1
This annex provides the system overview and operational background for the Guard Dog case study. Appendices C1 and C2 provide two potential operational routes for the system, in order to exercise its integration with airfields, terrain and airspace.
SYSTEM DESCRIPTION Overview: The Guard Dog UAV system is intended to provide imagery and intelligence (as well as target designation) for land and sea commanders, across the spectrum of conflict: Intelligence, Surveillance, Target Acquisition and Reconnaissance (ISTAR)
Figure C-1 – Overview of Guard Dog Case Study The system comprises: The Unmanned Air Vehicles (UAV); the Ground Control Station(s) (GCS); the Tactical Units (TacU) positioned with field commanders; the Field Teams for takeoff and recovery other than from prepared airfields. The system interfaces (on a mission basis) with the battlefield network provided through Network Enabled Capability (NEC). Other interfaces are envisioned to deal with training operations in a peacetime, civilian environment! In operational use, the system will operate under military jurisdiction within the battle-space. However, to facilitate peacetime training, the system will need to be able to operate in Class F & G civilian airspace (uncontrolled airspace – a Group 3 UAV iaw CAP722 [CAA04]). It is not intended to operate in Class A-E airspace (controlled airspace – Group 4 and 5 UAVs, requiring an extensive equipment list to be compliant).
C-2
Unmanned Air Vehicle:
KEY PARAMETERS 10m 500Kg Max: 100kts
Wingspan MTOW Speed
Cruise: 70kts Stall: 40kts 900 fpm Max: 20,000 ft
Rate of Climb Altitude
Operating: 10-18,000 ft Endurance 20 hrs Take-off / Landing (TO/L): Conventional: Short prepared strip or airfield, using wheeled undercarriage Field: Robonic launcher (pneumatic ramp) / prepared strip 1 x 50HP Petrol, driving fixed 2 blade prop
Engine
Actuation Power Supply Data-link
EQUIPMENT Redundancy of cabling and actuators Redundancy in case of single failure; and reserve (battery) power in event of engine failure LOS: Dual redundant TCDL, controllable from any GCS; Relay for onward Tx / Rx to other UAV
Navigation Controller Sensors Automatic TO/L (ATO/L) Target Designation Flight Termination? Collision Avoidance
[Option for satellite link, but key cost / weight driver] Dual Global Positioning System (GPS) receivers High Integrity, Dual redundant; Pre-programmable for autonomous mission; re-directable by operator from ground Variable EO/SAR/ESM Using GPS from satellite and Differential GPS (DGPS) error correction signal from ground station Laser Emergency Recovery Capability [iaw UTF04] Air: Sense & Avoid system [TBD] (Non-cooperative)
C-3
[TCAS not included on grounds of weight and no intent of using controlled airspace]
ATC Systems
Ground: DTED used for mission planning; RadAlt on board Mode S Transponder (for position on RADAR); Twin V/UHF radio for voice comms relay to GCS
Ground Control Station: Dual redundant operator consoles, provide: • Mission planning • Payload control, data analysis and NEC distribution • Pilot control (to redirect autonomous mission / take manual command) NEC • GCS can hand-over control to any other GCS • GCS can control up to 3 UAVs Tactical Common Data-Link (TCDL): GCS
• • • • •
Payload data downlink; telemetry downlink; command & control uplink Line-of-Sight (LOS) - Range 200km; 10.7Mbps payload data, 200kbps command link Dual redundant Option for Satellite link for Beyond LOS (BLOS). Data link can be relayed to a UAV beyond LOS range, by another UAV.
TacU • Positioned with field commanders, can obtain payload data direct from UAV. • Limited control of UAV payload sensors, to optimise data collection. NEC
Field Recovery Team For deployed operations, UAV can be launched from pneumatic launcher, and recovered onto flat ground / prepared strip, hence avoiding need for formal airfield.
Operational Scenario • Tactical UAV to be launched from a ‘UAV friendly’ civil airfield such as that at Parc Aberporth, but not with the intention of using the oversea range nearby. • Instead, TUAV turns inland, and follows a specified route overland from Aberporth, to exercise the system / operators in navigation over representative distances. • The route leads out to a land range such as Spadeadam, where the system / operators exercise the sensor & information gathering capabilities. C-4
• The TUAV then returns via the same (or a different) route, to re-enter the controlled airspace at Parc Aberporth. • Potentially, a number of TUAVs could be operated in parallel / series, to simulate the near-continuous operational tempo situation.
Alternative Operational Scenarios •
GCS has to control a second UAV, on station to relay TCDL to reach sensor UAV
•
Initial GCS hands over control to a second GCS for furthest part of the mission
•
GCS has to relay TCDL via satellite to reach sensor UAV
[Emergency conditions and configurations] •
Loss of GPS / drift in GPS accuracy
•
Loss of TCDL
•
Weather effects – cloud / precipitation / lighting
•
Diversion (for propulsion / non-propulsion failures; weather conditions etc)
•
Incursion of GA aircraft
C-5
APPENDIX C1 GUARD DOG MISSION SCENARIO (COASTAL ROUTE)
Figure C1-1 Flight Plan – Westerly Route (to maximize over-water flight)
C-6
APPENDIX C2 GUARD DOG MISSION SCENARIO (INLAND ROUTE)
Figure C2-1 - Flight Plan – Easterly Route (to maximise overland / ATC interaction
C-7
ANNEX D FHA FOR 'GUARD DOG' TUAV SYSTEM (EXTRACTS)
D-1
‘GUARD DOG’ UAVS FUNCTIONAL HAZARD ANALYSIS FHA conducted to ARP 4761 with UAVS modifications as report section 2.
CONTENTS OF ANNEX D System Description ............................................................................................................D-2 Safety Criteria.....................................................................................................................D-3 Airworthiness Safety Criteria and objectives................................................................D-3 ATM Separation / Collision based safety Objectives....................................................D-4 System Context [In Accordance with report section 2.2.2] ..................................................D-5 Derivation of Functions.......................................................................................................D-6 Flight Phases ..............................................................................................................D-6 Environment List..........................................................................................................D-6 Emergency Configurations List....................................................................................D-7 System interactions view [See Individual function maps for each system element] – Derived from initial design assumptions over system elements and interactions .........D-9 Failure Analysis ................................................................................................................D-18 Effects Consideration .......................................................................................................D-30 Scenarios for Effects Consideration...........................................................................D-39
SYSTEM DESCRIPTION [See Guard Dog Case Study document]
D-2
Severe Major / Hazardous - Controlled loss of the UAV over an unpopulated emergency site, using Emergency Recovery procedures where required.
Catastrophic UAV's inability to continue controlled flight and reach any predefined landing site
Major
Hazardous
Catastrophic
D-3
Category of Aircraft: CS.23.1309 Class I: Single Reciprocating Engine (SRE) / under 6000lbs <10-3 per op hr <10-4 per op hr <10-5 per op hr <10-6 per op hr Table D(ii) - Airworthiness Safety Objectives
Severity of Outcome Minor
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.
Table D(i) - Airworthiness Failure Condition Severities (from Table 2.2.1(i))
Minor Major - Slight reduction in safety - Significant reduction in safety margins (e.g., total loss margins (e.g. loss of of communication with autonomous flight and landing redundancy) on a predefined emergency site)
Airworthiness Safety Criteria and objectives
[Drawn from method at report section 2.2.1]
SAFETY CRITERIA
Severity 3 - Significant Incidents
Severity 2 - Major Incidents
Table D(iii) – ATM Separation / Collision Safety objectives
- Increasing workload of the air - Large reduction (e.g., a separation of less - Large reduction in separation (e.g., traffic controller or [UAVS] crew, than half the separation minima) in separation a separation of less than half the or slightly degrading the with [UAVS] crew or ATC controlling the separation minima), without [UAVS] functional capability of the situation and able to recover from the crew or ATC fully controlling the situation or able to recover from the enabling CNS System. situation. situation. - Minor reduction (e.g., a - Minor reduction (e.g., a separation of more separation of more than half the than half the separation minima) in separation - One or more aircraft deviating from separation minima) in without [UAVS] crew or ATC fully controlling their intended clearance, so that separation with [UAVS] crew or the situation, hence jeopardising the ability to abrupt manoeuvre is required to ATC controlling the situation recover from the situation (without the use of avoid collision with another aircraft and fully able to recover from collision or terrain avoidance manoeuvres). or with terrain (or when an avoidance action would be the situation. appropriate).
Severity 4 - Minor Incidents
- 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).
- Total loss of flight control.
- One or more Controlled Flight Into Terrain
- One or more collisions on the ground between two aircraft
- One or more mid-air collisions
- One or more catastrophic accidents
Severity 1 - Accidents
D-4
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.
Severity 5 - No Immediate Effect on Safety - No hazardous condition i.e. no immediate direct or indirect impact on the operations
[Drawn from Table 2.2.1(ii)]
ATM Separation / Collision based safety Objectives
[IN ACCORDANCE WIT H REPORT SECT ION 2.2.2]
D-5
Figure D-1 Rich Context Diagram for Guard Dog UAVS and the System of Systems around it
SYSTEM CONTEXT
DERIVATION OF FUNCTIONS Flight Phases • Pre-flight • Taxiing • Take-off – from airfield • Transit • On Task – using sensor payload • Approach • Landing – at airfield Alternative Phases: • • • • •
Take off – ramp launch from field On task - on station to relay TCDL to reach sensor UAV Hand over - Initial GCS hands over control to a second GCS Transit with satellite link - GCS has to relay TCDL via satellite to reach sensor UAV. Landing – rough field
Environment List a. Weather aspects (i) Temperature +55 / -45°C (with altitude) (ii) Altitude Sea Level / 20,000ft (iii) Rain, hail, snow, sand, dust (iv) icing accretion after take off (de-icing before) (v) lightning (vi) Visibility - intended to be VMC (i.e. before take-off), occasional IMC onset during mission (vii) Wind-speeds usually temperate (to 30kts intended for launch & landing), but up to 100kts onset in extremis. b. Overflown terrain aspects (i) Oversea – sea state flat to mountainous (ii) Overland covering worldwide extremes – flat lands, swamps, desert, jungle, mountainous, urban areas (operationally, not intentionally in training). (iii) Sensor performance ensures no need to operate below 1000ft AGL. (iv) Obstructions include masts, wind farms, gas platforms, pylons and cables… c. Electrical environment (i) Operationally, in high RF environment of battlefield (ii) In training, in busy UHF/VHF communications environment (see Air Traffic below), and with several identified HF/VHF/UHF/ milli-metric HIRTAS in locality d. Mission environment (i) Includes day or night usage (ii) Potential for crew changeover due to extended ‘on station’ times (15-20 hrs total flight time) (iii) Potential for non-aircrew personnel to operate the system directly, under certified pilot-in-command as supervisory D-6
e. Air traffic environment (i) Primarily, flight within general airspace (Class F&G) (ii) Over several military Areas of Intense Aerial Activity (AIAA) – occasionally entering AIAA (with permission) to facilitate route around more stringent airspace (such as TMA, CTA) (iii) Under / next to Airways (iv) Close to Terminal Manoeuvre Areas (TMA) at airway intersections near major airports, and under the Control Terminal Area (CTA) for major airports (v) Into civil and military airfields with UAV clearance (vi) Into military Danger Areas to exercise sensors Emergency Configurations List Single failure of the UAV communication link, and/or control link Operation of Flight Termination System (None fitted) - Instead, conduct of Emergency Recovery Procedures due to loss of critical system(s) - With UAV-p control; Without UAV-p control (i.e. autonomous) Emergency landing due to loss of thrust Collision avoidance with co-operative and non-cooperative aircraft - Including evasive manoeuvre Terrain avoidance Interception by military aircraft Failure of onboard Sense and Avoid equipment Operation with degraded systems Degradation of weather conditions Security threats to upload data, commands and transmissions PLUS: Loss of GPS / drift in GPS accuracy [As part of defining the emergency configurations, and identifying related functions, it was found necessary to define some outline Emergency Recovery Procedures, as shown below:
D-7
Maintain flight path over 'safe' terrain and airspace
Determine best diversion and ID between GCS and UAV (May be home or destination)
NORMAL FLIGHT
NO
Regain D/L Signal?
NO
External Nav Asistance?
STOP & Broadcast
Able to Maintain Safe YES Altitude?
Hold
YES
NO
D-8
Figure D-2 - Outline Emergency Recovery Procedures
GROUND CONTROL Failure
COLLISION AVOIDANCE Failure
FLIGHT CRITICAL SYSTEM Total Fail
AIR NAVIGATION Failure (inc. height, speed, position & route control)
COMMUNICATIONS Failure
FLIGHT CRITICAL SYSTEMSIngle (Redundant) Failure
DATA LINK System Fail (single)
DATA LINK SystemFail (total)
DATA LINK Signal Loss
YES
Broadcast Collision Avoidance fail
Broadcast Mayday & EMERGENCY LANDING
Broadcast Control Datalink Fail DIVERT to identified diversion airfield
Ramp T/O Launch control
Stabilise perturbations
Determine Altitude, Orientation & Speed
Control handover between GCSs
Relay D/L to other UAV
Sensor control Manage Payload
Manoeuvre UAV
Monitor mission progress
Auto T/O & Land
Determine systems status
D-9
Determine position
Control Flight Store / update Path Mission Route
Determine accuracy
Ground steering
Determine actual ground location & heading
Ground braking
Ground thrust control
Determine ground speed
UAV Centred view
Monitor / correct actual v planned route
Monitor / correct actual v planned ground route
Position, heading & Altitude awareness
Determine Ground obstacles
Control position on the ground
Control speed on the ground
Determine Air / Ground transition
Control on Ground
Degraded systems emergency actions?
Air navigation
Manage Flight Systems
Redundant systems control?
Determine T/O, climb out, High Accuracy approach, land position, hdg, alt High acc'y profiles awareness monitor / correct position, hdg, alt
Manual Override remote piloting
UAV Stability & Control
Manage Datalink
Payload data download
Telemeter UAV parameters
System interactions view [See Individual function maps for each system element] – Derived from initial design assumptions over system elements and
interactions
Status of UAV
manual Override remote piloting
Change Mission Plan
Direct sensors
Distribute payload data
Actual path v mission route
Monitor Mission Progress D/L Fail Emgy Action
NEC
GCS
Prioritise sensor / data requests from Users
Monitor Data link condition
Manage DataLink
Mission Planning
D-10
GCS Centred view
Via Satellite?
via next GCS?
Via UAV Relay?
Control Datalink Path
Upload Mission Plan
Plan Route
Figure D-3b – GCS centred view of functions
Control UAV?
Manage Payload
Download payload data
Figure D-3a – UAV Centred view of functions
NEC
Pre Flight preparations
Launch UAV
Locate UAV
Field Recovery / Launch Unit Centred view
Refuel / recharge consumables
Pre flight test
Distribute payload data
D-11
Figure D-3c TACU and Field Recovery / Launch Unit centred views of functions
TACU Centred view
Sensor / Data requests
Data download / storage
Flight Phases view [Additional possible functions derived from mission phases –merged with functions from system interactions view]. Mission Phase Pre-flight Taxiing
Take-off
System Function (1st Level) System Test Load Mission Plan Controlled Taxiing
(2nd Level?)
Airfield Take-Off [Auto / Manual?] Position & Direction Sensing Accuracy Collision Avoidance Terrain Avoidance Field Take-Off
Ground obstacle sensing? Airfield pattern awareness Correct steering to planned layout Climb-out profile
Launch control Climb-out
Transit Position & Direction Sensing accuracy - normal Collision Avoidance Terrain Avoidance Monitor weather for changes On Task (As Transit +)
Approach (As Transit +)
Landing (As Transit +)
Relay TCDL [when acting as airborne relay for 2nd UAV] Handover between GCSs Approach Control
Controlled Landing
Determine wind speed & direction Determine landing strip direction Determine circuit height & direction Determine glide-slope pattern Fly pattern (correct v planned pattern) Detect air / ground transition
Table D(iv) – Flight phases view of functions
External context view [Derived from external rich context diagram interactions] UAVS Interacts with… Agent Airfield
ATM En-Route
Nature of Interaction Airfield ATC instruction > Airfield ATC Visual Signals > Airfield layout for taxiing > Airfield Runway profile / Take Off > Airfield Climb out profile / obstacle clearance Approach and Hold procedures > Airfield Circuit direction / procedures > Airfield Runway / arrestor layout / Land and recover > Airfield RF systems Interoperability >
Additional Derived Function? Understand / reply to airfield ATC - Voice Observe / respect airfield visual signals [3.2.3] [2.4.1] [2.4.1]
< Communication >
Understand / reply to En Route ATC – Voice, Digital Provide tracking signal Comply with ATC – confirm, act Manage ATC Frequency Selection
Track UAV > < Comply with advice < Select appropriate radio frequency
D-12
[2.4.3] [2.4.3] [2.4.5][3.2] [Characteristic of system – Non Functional Req’t]
UAVS Interacts with… Agent
Nature of Interaction
Additional Derived Function?
ISTAR Data Users
< Direct Payload data feed < NEC data feed Data requests >
[5] [5] [5]
Malicious Threats
< Break Data Link < Steal Data Link < Hack GCS via NEC – affect mission planning; planning source data; output payload data
D/L Anti jamming Verify / encrypt D/L Defend / verify mission plan, planning data, output data
Mission Target
< Identify target < Gather reconnaissance data < Designate target for attack
ID Target Gather recce data Designate target
HIRF Sources
Direct EM Interference with UAVS >
[Non Functional Requirement] Mission planning – awareness of HIRF locations
Noise affects LOS Command Link signal strength > Non-Cooperative Air Traffic (Class F-G Airspace)
Ground Terrain / Obstructions
Fixed Ground Danger areas / Populated areas
< Detect traffic and sense relative track
Variable Danger areas (NOTAMS)
Determine traffic relative track Maintain traffic separation (ROA)
< Maintain separation (normal action according to Rules of the Air) < Emergency Collision avoidance (evasion) See and avoid >
Collision Emergency evasion Conspicuity to air traffic (visual, RF)
< Terrain Awareness
Terrain avoidance – terrain awareness
< Route Planning < Terrain Avoidance (Rules of the Air)
[add to 8.1] Maintain Terrain separation (ROA)
LOS calculations >
Terrain emergency evasion Monitor Datalink – LOS to terrain (and 8.1 also)
< Awareness
Emergency redirection in event of incursion >
Danger areas / populated areas avoidance awareness [add to 8.1] Maintain danger area / populated area separation (ROA) Danger area / populated area emergency incursion action
< Awareness
Controlled airspace avoidance - awareness
< Route planning < Avoid through flight (Rules of the Air) Emergency redirection in event of incursion >
[add to 8.1] Maintain controlled airspace separation (ROA) Controlled airspace emergency incursion action
< Awareness
NOTAMS avoidance - awareness
< Route planning < Avoid through flight (Rules of the Air) Emergency redirection in event of incursion >
[add to 8.1] Maintain NOTAMS separation (ROA) NOTAMS emergency incursion action
< Route planning < Avoid overflight (Rules of the Air)
Controlled Airspace (Class A-E)
Collision avoidance – detect traffic – non coop; co-op.
D-13
UAVS Interacts with… Agent
Nature of Interaction
Additional Derived Function?
Availability >
[4, 4.2]
Signal strength > Security of extended data link >
[4.x – defend d/l]
GNSS
Satellite position and time > Navigation accuracy / errors >
[2.1.1] [2.1.1]
DGPS Reference Station
DGPS error correction >
[2.4.2]
Weather
< Awareness
Manage for Weather – weather conditions awareness – precip’n, icing, lightning, w/s & dir, visibility [add to 8.1 also]
Modify route >
Assess proximity to route and effect on UAV
Force diversion for landing >
Determine separation route Determine diversionary airfield
Satellite Data Link (Option)
Determine diversionary route Affect LOS command signal strength > < Respect VMC / IMC Flight Rules (Rules of the Air) Gusts > Precipitation / Icing > Lightning >
(as above) [1.2] (affects [1], [1.6.2], [4.1.1]) (Non functional requirement
Table D(v) – External interactions and derived UAVS functions
D-14
1.5 Field T/O Launch Control (I)(F)
1.3 Manoeuvre UAV (I)
1.1 Determine attitude, orientation and speed (I)
1.6.3 Control Heading (I)
1.6.1 Control Airspeed (I)
2.7 Controlled Airspace avoidance (E) as 2.6.1-3
2.5.2 Maintain separation (ROA) (E)
2.8 Variable Danger Areas (NOTAMS) Avoidance (E) as 2.6.1-3
2.6 Sensitive Area Avoidance (Danger & Populated areas) (E) - as 2.6.1-3
2.4.5 Determine Windspeed & direction v R/W and landing characteristics (F)
2.4.3 Determine Airfield Approach, Hold, Circuit, R/W profile (F)(E)
2.4.1 Determine Airfield T/O Climb-out profile (F)(E)
3.1.3 Controlled Ground Braking (I)
2.4.4 High Accuracy monitor / correct actual v planned profile (F)(E)
2.4.2 Determine High accuracy Position, heading & Altitude (F)
2.4 Auto Take off & Landing (I)(F)
3.1.1 Determine speed on ground (I) 3.1.2 Controlled Ground thrust (I)
3.1 Control Speed on the ground (I)
D-15
3.2.4 Monitor / correct actual v required ground route (F)
3.2.6 Determine Ground obstacles (F)(E)
3.2.3 Determine Airfield layout / required ground route (F)(E)
3.2.5 Determine Air / Ground transition (F)
3.2.6.2 Fixed obstacles awareness (F)(E)
3.2.6.1 Detect mobile obstacles (F)(E)
3.2.2 Ground steering (I)
3.2 Control Position on the ground (I)
3.2.1 Determine ground position & heading (I)
3. Control on the Ground (I)
Figure D-4a – Guard Dog Functions Tree (part 1 of 3)
2.5.3 Emergency evasion (E)
2.5.1 Awareness & flight path proximity (E)
2.5 Terrain Avoidance (E)
1.6.2 Control Altitude & Rate (I)
2.3 Monitor / Correct actual v planned route (I)
2.2 Store / Update Mission Route (I)
2. Air Navigation (I)
2.1.2Determine Nav Data accuracy (I)(F)
2.1 Position, Heading & Altitude Awareness (I) 2.1.1 Determine Position, Heading & Altitude (I)
1.6 Control Flight Path (I)
1.4 Manual Override Remote Piloting (I)
1.2 Stabilise perturbations (I)
1. Stability & Control (I)
UAVS Function Tree UAVS [PartFunction 1 of 3] Tree [Part 1view of 3] (I) Internal (I) Internal (F) Flight phase view view (F) Flight phase view view (E) External context (E) External context view
Resulting Functions Tree for Guard Dog UAVS
4.1.2 D/L Equipment status (I)
4.3.1 Single D/L fail / degradation action (I)
4.5 Monitor Terrain proximity to LOS (E)
4.3.2 Complete D/L fail / degradation action (I)
4.3 Datalink Fail Emergency Action(I)
4.1.1 Signal strength (I)
4.1 Monitor datalink condition (I)
4. Manage Datalink (I)
4.4 Defend D/L (Jamming, stealing) (E)
4.2.3 Relay between UAVs (I)(F)
6.5.3 Determine Wx separation route around (E)
[Precipitation, icing, windspeed / direction, visibility VMC / IMC]
6.5.1 Weather awareness enroute (E)
5.4 Prioritise Users' Payload requests (I)
5.3 Distribute Payload data (I)
6.2 Telemeter Air Nav params to GCS (I)
6.4 Telemeter Flight Systems status to GCS (I)
6.3 Telemeter Ground Control params to GCS (I)
6. Monitor Mission progress (I)
6.1 Telemeter S&C params to GCS (I)
6.5.4 Determine nearest, Wx safe, diversionary airfield & route (E)
6.5.2 Assess Wx proximity to planned route (E)
6.5 Monitor Weather for changes (F)(E)
5.2 Payload data download (I)
5.1 Sensor control (I)
5. Manage Payload (I)
D-16
Figure D-4b – Guard Dog Functions Tree (part 2 of 3)
4.2.2 Route via Satellite (I)(F)
4.2 Control Datalink path (I)
4.2.1 Handover to next GCS (I)(F)
UAVS Function Tree UAVS [PartFunction 2 of 3] Tree [Part 2view of 3] (I) Internal (I) Internal (F) Flight phase view view (F) Flight phase view view (E) External context (E) External context view
7.3.2 Emergency Landing
7.3.1 Divert
7.3 Degraded systems emergency actions (I)
7.1 Determine flight systems status (I)
7.2 Redundant systems control? (I)
7. Manage Flght Systems (I)
8.2.2 Pre flight systems test (I)(F)
8.1.4 Danger Area / populated area awareness (E)
8.1.6 Weather awareness (E)
8.1.1 Plan mission route (I)
8.1.3 Terrain Awareness (E)
8.1.5 Controlled Airspace awareness (E)
9.7 Emergency Broadcast actions (E)
9.6.1 Determine required manoeuvre from ATC comms (E)
D-17
10.4 Collision emergency evasion (E)
10.3 Maintain traffic separation (ROA) (E)
10.5 Conspicuity to Air Traffic (visual, RF) (E)
10.2 Determine traffic relative track (E)
10. Collision Avoidance (F)(E)
10.1 Detect Traffic (Co-op; Non Co-op) (E)
9.6.2 Confirm manoeuvre with ATC (E)
9.6 Comply with ATC procedures (E)
9.4 Provide Tracking 'visibility' (signal, visual) (E)
9.3 Understand / reply to EnRoute ATC advice - voice / digital (E) 9.5 Manage ATC Frequency selections (E)
9.2 Detect & respect airfield visual signals (E)
9.1 Understand / reply to Airfield ATC voice comms (E)
9. Manage Communication s (E)
Figure D-4c – Guard Dog Functions Tree (part 3 of 3)
8.2.3 Upload Mission Plan (I)(F)
8.2.1 Refuel / recharge consumables (I)
8.2 T/O / Launch Preparation (F)
8.1.2 HIRF Location awareness (E)
8.1 Mission Planning (I)
8. Pre Flight Preparations (I)
UAVS Function Tree UAVS [PartFunction 3 of 3] Tree [Part 3view of 3] (I) Internal (I) Internal (F) Flight phase view view (F) Flight phase view view (E) External context (E) External context view
FAILURE ANALYSIS Preliminary notes on columns: Failure Condition (Hazard Description) – (a) Loss of Function; (b) Uncommanded Function; (c) Incorrect Function
Failure Conditions Table D(vi) – Functional Failure Conditions for Guard Dog UAVS FFA ID
Function
Failure Condition (Hazard Description) (a), (b), (c)
F1.1A
1. Stability & Control (I) 1.1 Determine attitude and speed (I)
F1.1B F1.1C F1.1D F1.1E F1.1F F1.1G F1.2A F1.2B F1.2C F1.2D F1.3A F1.3B F1.3C F1.3D F1.3E F1.3F F1.3G F1.3H F1.3I F1.3J F1.4A
1.2 Stabilise perturbations (I)
1.3 Manoeuvre UAV (I)
1.4 Manual Override - Remote Piloting (I)
F1.4B F1.4C F1.4D F1.5A F1.5B F1.5C F1.5D F1.6A F1.6B F1.6C F1.6D F1.6E
(a)
Unable to determine UAV roll, pitch or yaw attitude
(a) (b) (c) (c) (c) (c) (c) (a) (b) (c) (c) (c) (a) (a) (b) (c)
Unable to determine UAV airspeed (not applicable – continuous function) Accuracy error in measured attitude or speed Measured attitude or speed freezes at last reading Measured attitude or speed goes to maximum scale Measured attitude or speed goes to minimum scale Transient spikes in measured attitude or speed Loss of UAV stability (continuous function) Undamped / poorly damped manoeuvres or speed Over damped manoeuvres or speed Phase lag drives oscillations Unable to manoeuvre UAV at all when demanded Unable to manoeuvre UAV in certain axes, when demanded Undemanded manoeuvre Asymmetric manoeuvre control – demand in one axis causes uncontrollable manoeuvre in another axis Transient control deflections Manoeuvre control restriction – limited manoeuvre Manoeuvre control jams – unable to stop manoeuvre Excessive manoeuvre control deflections Manoeuvre capability exceeds vehicle structural strength Manoeuvre control time delay (lag) Unable to take manual control of UAV
(c) (c) (c) (c) (c) (c) (a) (b) (c) (c)
1.5 Field T/O Launch Control (I)(F)
1.6 Control Flight Path (I) 1.6.1 Control Airspeed (I)
(a) (a) (b) (c) (a) (a) (b) (b) (c)
Unable to fly UAV with autonomy Conflicting authority between manual and autonomous control Conflicting authority between separate ground sources for manual control Launch control not provided during ramp t/o Launcher fails to reach necessary speed Launch control initiated during other flight phase Launch speed excessive Airspeed cannot be increased when necessary Airspeed cannot be decreased when necessary Airspeed runaway up Airspeed runaway down Asymmetric thrust (power) causing uncontrollable yaw or roll (depending on propulsion configuration)
D-18
FFA ID
Function
Failure Condition (Hazard Description) (a), (b), (c) (c) (c) (a) (a) (b) (b) (c) (c) (c) (a) (b) (b) (c)
Incorrect airspeed achieved – too high Incorrect airspeed achieved – too low Altitude cannot be increased when required Altitude cannot be decreased when required Altitude runaway up Altitude runaway down Incorrect altitude achieved – too high Incorrect altitude achieved – too low Altitude achieved at incorrect climb / descent rate Heading not variable Heading changes without demand Heading runaway Incorrect heading achieved
(a)
Unable to determine position
F2.1D F2.1E
(a) (a) (b) (c) (c)
F2.1F F2.1G F2.1H F2.1I F2.1J
(c) (c) (c) (c) (a)
Unable to determine heading Unable to determine altitude (continuous function) Accuracy error in measured position, heading or altitude Lag in position, heading or altitude data measurement (phase shift) Measured position, heading or altitude freezes at last reading Measured position, heading or altitude goes to maximum scale Measured position, heading or altitude goes to minimum scale Transient spikes in measured position, heading or altitude Unable to determine Nav data accuracy
F1.6F F1.6G F1.6H F1.6I F1.6J F1.6K F1.6L F1.6M F1.6N F1.6O F1.6P F1.6Q F1.6R
F2.1A
1.6.2 Control Altitude & Rate (I)
1.6.3 Control Heading (I)
2. Air Navigation (I) 2.1 Position, Heading & Altitude Awareness (I) 2.1.1 Determine Position, Heading & Altitude (I)
F2.1B F2.1C
F2.1K F2.1L F2.2A F2.2B F2.2C F2.2D F2.2E F2.2F F2.2G F2.3A
2.1.2Determine Nav Data accuracy (I)(F)
2.2 Store / Update Mission Route (I)
2.3 Monitor / Correct actual v planned route (I)
F2.3B F2.3C F2.4A F2.4B F2.4C F2.4D F2.4E
2.4 Auto Take off & Landing (I)(F) 2.4.1 Determine Airfield T/O Climbout profile (F)(E)
(b) (c) (c) (a) (a) (b) (c) (c) (c) (c) (a)
(continuous function) Nav data erroneously determined as accurate Nav data erroneously determined as inaccurate Loss of stored mission route Unable to update / change route once stored Mission route changed without demand Mission route stored / updated with incorrect data elements (stale / zero / default / random data) Mission route stored / updated partially – elements missing Mission route not achievable (performance) Mission route not safe (ROA) Unable to determine route error
(a) (b) (c)
Unable to determine route correction (Continuous function) Erroneous route error or correction determined
(a)
Airfield T/O (runway) profile lost
(a) (b) (c) (c)
Airfield climb-out profile lost Climb out profile initiated in other phase Airfield T/O (runway) profile for wrong airfield / runway Airfield climb-out profile for wrong airfield / runway
D-19
FFA ID
Function
Failure Condition (Hazard Description) (a), (b), (c) (c)
F2.4F
(a)
Airfield climb out profile corrupted (spikes, dips, truncated, capped) Unable to determine high accuracy position
(a) (a) (b) (c) (c) (c) (c) (c) (c) (c) (a)
Unable to determine high accuracy heading Unable to determine high accuracy altitude High accuracy data presented in other phases Incorrect position determined Inaccurate position determined Incorrect heading determined Inaccurate heading determined Incorrect altitude determined Inaccurate altitude determined – too high Inaccurate altitude determined – too low Airfield approach lost
F2.4S F2.4T F2.4U F2.4V F2.4W
(a) (a) (a) (b) (c)
F2.4X
(c) (a)
Airfield hold lost Airfield circuit lost Airfield R/W profile lost Airfield approach, hold, circuit initiated in other phase Airfield approach, hold, circuit runway profile for wrong airfield / runway Airfield approach, hold, circuit runway profile corrupted (spikes, dips, truncated, capped) Unable to determine T/O path error / correction
(a) (b) (c) (c) (a)
Unable to determine landing path error / correction (Continuous function) Erroneous T/O path error or correction determined Erroneous landing path error or correction determined Not possible to determine W/S or direction
(b) (c) (c) (c) (c)
(continuous function) Incorrect w/s determined – too high Incorrect w/s determined – too low Incorrect wind direction determined Noisy, oscillating wind direction
(a)
Unaware of surrounding terrain
(a) (a) (b) (c) (c) (c) (a) (b) (c)
Unaware of proximity of surrounding terrain to flight path Terrain proximity determined at low sampling rate (continuous function) Incorrect surrounding terrain determined Incorrect distance to terrain determined – lower than actual Incorrect distance to terrain determined – higher than actual Terrain separation (minimum) not maintained Terrain separation driven down / up to minimum Terrain separation maintained but below ROA requirement (highest point +1000ft) Flight profile to maintain terrain separation exceeds vehicle climb performance Need for emergency terrain evasion not determined Need for emergency terrain evasion determined late
F2.4G F2.4H F2.4I F2.4J F2.4K F2.4L F2.4M F2.4N F2.4O F2.4P F2.4Q F2.4R
F2.4Y
2.4.2 Determine High accuracy Position, heading & Altitude (F)
2.4.3 Determine Airfield Approach, Hold, Circuit, R/W profile (F)(E)
2.4.4 High Accuracy monitor / correct actual v planned profile (F)(E)
F2.4Z F2.4AA F2.4AB F2.4AC
2.4.5 Determine Wind speed & direction v R/W and landing characteristics (F)
F2.4AD F2.4AE F2.4AF F2.4AG F2.5A
2.5 Terrain Avoidance (E) 2.5.1 Awareness & flight path proximity (E)
F2.5B F2.5C F2.5D F2.5E F2.5F F2.5G F2.5H F2.5I
2.5.2 Maintain separation (ROA) (E)
F2.5J F2.5K F2.5L
(c) 2.5.3 Emergency evasion (E)
(a) (a)
D-20
FFA ID
Function
Failure Condition (Hazard Description)
F2.5M F2.5N
(a), (b), (c) (b) (c)
F2.5O
(c)
Emergency evasion manoeuvre triggered when not necessary Required emergency evasion manoeuvre exceeds vehicle manoeuvre performance Incorrect emergency evasion manoeuvre identified
(a)
Unaware of Sensitive Area
F2.6C F2.6D
(a) (b) (c) (c)
F2.6E
(c) (a) (b) (a)
Unaware of proximity of Sensitive Area to flight path (continuous function) Incorrect Sensitive Area determined Incorrect distance to Sensitive Area determined – nearer than actual Incorrect distance to Sensitive Area determined – further than actual Sensitive Area separation (minimum) not maintained (continuous function) Need for emergency evasion not determined
(a) (b) (c)
Need for emergency evasion determined late Emergency evasion manoeuvre triggered when not necessary Incorrect emergency evasion manoeuvre identified
(a)
Unaware of Controlled Airspace
F2.7C F2.7D
(a) (b) (c) (c)
F2.7E
(c) (a) (b) (a)
Unaware of proximity of Controlled Airspace to flight path (continuous function) Incorrect Controlled Airspace determined Incorrect distance to Controlled Airspace determined – nearer than actual Incorrect distance to Controlled Airspace determined – further than actual Controlled Airspace separation (minimum) not maintained (continuous function) Need for emergency evasion not determined
(a) (b) (c)
Need for emergency evasion determined late Emergency evasion manoeuvre triggered when not necessary Incorrect emergency evasion manoeuvre identified
(a)
Unaware of NOTAMS Area
F2.8C F2.8D
(a) (b) (c) (c)
F2.8E
(c) (a) (b) (a)
Unaware of proximity of NOTAMS Area to flight path (continuous function) Incorrect NOTAMS Area determined Incorrect distance to NOTAMS Area determined – nearer than actual Incorrect distance to NOTAMS Area determined – further than actual NOTAMS Area separation (minimum) not maintained (continuous function) Need for emergency evasion not determined
(a)
Need for emergency evasion determined late
F2.6A
2.6 Sensitive Area Avoidance (Fixed Danger & Populated areas) (E) 2.6.1 Awareness & flight path proximity (E)
F2.6B
F2.6F
2.6.2 Maintain separation (ROA) (E)
F2.6G
2.6.3 Emergency incursion action (E)
F2.6H F2.6I F2.6J
F2.7A
2.7 Controlled Airspace avoidance (E) 2.7.1 Awareness & flight path proximity (E)
F2.7B
F2.7F
2.7.2 Maintain separation (ROA) (E)
F2.7G
2.7.3 Emergency incursion action (E)
F2.7H F2.7I F2.7J
F2.8A
2.8 Variable Danger Areas (NOTAMS) Avoidance (E) 2.8.1 Awareness & flight path proximity (E)
F2.8B
F2.8F
2.8.2 Maintain separation (ROA) (E)
F2.8G
2.8.3 Emergency incursion action (E)
F2.8H
D-21
FFA ID
Function
F2.8I F2.8J
F3.1A F3.1B F3.1C F3.1D F3.1E F3.1F F3.1G F3.1H F3.1I F3.1J
3. Control on the Ground (I) 3.1 Control Speed on the ground (I) 3.1.1 Determine speed on ground (I)
3.1.2 Controlled Ground thrust (I)
Failure Condition (Hazard Description) (a), (b), (c) (b) (c)
Emergency evasion manoeuvre triggered when not necessary Incorrect emergency evasion manoeuvre identified
(a)
Unable to determine speed on the ground
(b) (c) (c) (a) (a) (b) (b) (c) (c)
(a) (a) (b) (b) (c) (c) (c) (c)
Attempt to determine ground speed while in the air Ground speed inaccuracy - too high Ground speed inaccuracy – too low Unable to increase ground thrust Unable to decrease ground thrust Ground thrust increases without demand – runaway up Ground thrust decreases without demand – runaway down Ground thrust change lags demand Excessive ground thrust change for required demand (scale error) Inadequate ground thrust change for required demand (scale error) Ground thrust asymmetry (roll or yaw depending on propulsion configuration) Unable to apply / increase ground braking Unable to decrease / release ground braking Ground braking increases / on without demand Ground braking decreases / releases without demand Ground braking change lags demand Excessive ground braking for required demand (scale error) Inadequate ground braking for required demand (scale error) Ground braking asymmetry
(a)
Unable to determine ground position
(a) (b) (c) (a) (a) (b) (c) (c) (c) (c) (a)
Unable to determine ground heading Attempt to determine ground position / heading while in the air Ground position or heading inaccurate Ground steering not available – steering fixed Ground steering not available – steering free Ground steering when not on the ground Incorrect sense ground steering applied Excessive ground steering applied Inadequate ground steering applied Ground steering lags demand Unable to determine airfield layout / required ground route
(b) (c) (c) (a)
Ground route identified when not on the ground Incorrect airfield identified Incorrect ground route (at correct airfield) identified Unable to determine ground route error
(a) (b) (c) (a)
Unable to determine ground route correction (Continuous function on the ground) Erroneous ground route error or correction determined Unable to determine air / ground transition
(b)
(continuous function)
F3.1K
(c)
F3.1L
(c)
F3.1M F3.1N F3.1O F3.1P F3.1Q F3.1R F3.1S F3.1T
F3.2A F3.2B F3.2C F3.2C F3.2D F3.2E F3.2F F3.2G F3.2H F3.2I F3.2J F3.2K F3.2L F3.2M F3.2N F3.2O
3.1.3 Controlled Ground Braking (I)
3.2 Control Position on the ground (I) 3.2.1 Determine ground position & heading (I)
3.2.2 Ground steering (I)
3.2.3 Determine Airfield layout / required ground route (F)(E)
3.2.4 Monitor / correct actual v required ground route (F)
F3.2P F3.2Q F3.2R
3.2.5 Determine Air / Ground transition (F)
D-22
FFA ID
Function
F3.2S F3.2T F3.2U F3.2V F3.2W
Failure Condition (Hazard Description) (a), (b), (c) (c) (c) (c) (c)
3.2.6 Determine Ground obstacles (F)(E) (Fixed or mobile)
F3.2X F3.2Y F3.2Z F3.2AA F3.2AB F3.2AC
(a)
Air to ground transition erroneously determined Ground to air transition erroneously determined Air / ground transition identified during transient ground contact Air / ground transition not identified during transient ground contact Unable to determine position of fixed ground obstacles
(a) (b) (c) (c) (c) (c)
Unable to detect mobile ground obstacles Attempt to identify ground obstacles while not on the ground Ground obstacle identified where there is none Ground obstacle not identified where there is Ground obstacle identified position inaccurate Mobile ground obstacle identified but speed / direction not Classification of datalink functional failures is critically dependent on level of autonomy of UAV in event of failure, in reaching a safe outcome.
F4.1G F4.1H F4.1I
(a) (b) (c) (c) (c) (a) (b) (c) (c) (c)
F4.1J F4.1K
(c) (c)
Unable to determine datalink signal strength (continuous function) Datalink signal strength erroneously indicated too high Datalink signal strength erroneously indicated too low Datalink signal strength very noisy – high / low oscillation Datalink equipment status not available (continuous function) Datalink equipment status shown ‘no fail’ with actual single fail Datalink equipment status shown ‘no fail’ with actual total fail Datalink equipment status shown ‘single fail’ when actually no fail Datalink equipment status shown ‘total fail’ when actually no fail Datalink equipment status oscillates between fail / no fail status
4. Manage Datalink (I)
F4.1A F4.1B F4.1C F4.1D F4.1E F4.1F
F4.2A F4.2B
4.1 Monitor datalink condition (I) 4.1.1 Signal strength (I)
4.1.2 D/L Equipment status (I)
4.2 Control Datalink path (I) 4.2.1 Handover to next GCS (I)(F)
(a) (b)
F4.2C
(c)
F4.2D
(c)
F4.2E
(c)
F4.2F
(c)
F4.2G
(c)
F4.2H F4.2I F4.2J F4.2K F4.2L
4.2.2 Route via Satellite (I)(F)
F4.2M F4.2N F4.2N F4.2O F4.2P
(a) (b) (c) (c) (c) (c)
4.2.3 Relay between UAVs (I)(F)
(c) (a) (b) (c)
Datalink control cannot hand over from current to next GCS Datalink attempts control hand over from current GCS without demand Datalink control hand over from current GCS, but next GCS unable to take control Datalink control hand over from current GCS, but next GCS unaware it has control Datalink control taken over by next GCS, without current GCS being aware Datalink control hand over to next GCS, but current GCS also retains control (dual control) Datalink attempted control hand over to next GCS, but neither GCS retains control Unable to route datalink via satellite Datalink routed via satellite without demand Datalink routed via wrong satellite Datalink ‘cross talk’ with other satellite traffic Satellite link saturates with other satellite traffic – datalink drop outs Satellite link saturates with other satellite traffic – datalink delays Satellite link fails totally Unable to route datalink to 1st UAV via relay UAV Datalink routed via relay UAV without demand Datalink routed via wrong relay UAV
D-23
FFA ID
Function
Failure Condition (Hazard Description)
F4.2Q F4.2R F4.2S
(a), (b), (c) (c) (c) (c)
F4.2T F4.2U F4.2V F4.3A
(c) (c) (c) (a)
Datalink routed via relay UAV to wrong 1st UAV Relay Datalink ‘cross talk’ with RF noise Datalink command confusion between those meant for relay UAV and those for 1st UAV Relay datalink drop outs Relay datalink delays Relay link fails totally D/L fail action (hold then divert) not taken when required
(b) (c) (c) (c) (a)
D/L fail action (hold then divert) taken without demand D/L fail action partially taken – UAV remains in hold D/L fail action partially taken – UAV diverts immediately D/L fail action partially taken – D/L fail broadcast not issued Datalink jammed
(a) (b) (c) (a)
Datalink stolen (continuous function) Valid datalink control rejected as jamming / stealing Fail to monitor terrain proximity to control LOS
(b) (c) (c)
(continuous function) Terrain proximity inaccuracy – judged closer than actual Terrain proximity inaccuracy – judged further than actual
(a)
F4.3B F4.3C F4.3D F4.3E F4.4A
4.3 Datalink Fail / Degrade Emergency Action(I) (see function 7.3.1 for divert function failures)
4.4 Defend D/L (Jamming, stealing) (E)
F4.4B F4.4C F4.5A
4.5 Monitor Terrain proximity to LOS (E)
F4.5B F4.5C F5.1A
5. Manage Payload (I) 5.1 Sensor control (I) [including visual sensor]
F5.1B F5.1C
(b) (c)
F5.1D F5.1E
(c) (c)
Unable to direct sensor at point of interest [including forwards, for flight assistance] Sensor slews off point of interest without demand Sensor not stabilized on point of interest (subject to flight motion / noise) Sensor field of view / zoom incorrect – too wide Sensor field of view / zoom incorrect – too narrow
(a)
Unable to telemeter S&C parameters to GCS
(b) (c) (c) (a)
(continuous function) Inaccurate S&C parameters telemetered Other parameters telemetered as S&C Unable to telemeter Air Nav parameters to GCS, at all
(b) (c) (c) (a)
(continuous function) Inaccurate Air Nav parameters telemetered Other parameters telemetered as Air Nav Unable to telemeter Ground Control parameters to GCS, at all
(b) (c) (c) (a)
(continuous function) Inaccurate Ground Control parameters telemetered Other parameters telemetered as Ground Control Unable to telemeter Flight Systems status to GCS, at all
5.2 Payload data download (I) [including visuals] 5.3 Distribute Payload data (I) 5.4 Prioritise Users' Payload requests (I)
F6.1A
F6.1B F6.1C F6.2A
F6.2B F6.2C F6.3A
F6.3B F6.3C F6.4A
6. Monitor Mission progress (I) 6.1 Telemeter S&C params to GCS (I)
6.2 Telemeter Air Nav params to GCS (I)
6.3 Telemeter Ground Control params to GCS (I)
6.4 Telemeter Flight Systems status to GCS (I)
D-24
FFA ID
Function
Failure Condition (Hazard Description) (a), (b), (c) (b) (c) (c)
(continuous function) Inaccurate Flight Systems status telemetered Other parameters telemetered as Flight Systems status
(a)
Unaware of weather conditions en route
F6.5C
(a) (b) (c)
F6.5D
(c)
Unaware of wind speed or direction en route (continuous function) Erroneous indication of precipitation, icing or visibility conditions en route – better than actual Erroneous indication of precipitation, icing or visibility conditions en route – worse than actual Inaccurate indication of wind speed or direction en route Unable to determine Wx proximity to planned route
F6.4B F6.4C
F6.5A
6.5 Monitor Weather for changes (F)(E) 6.5.1 Weather awareness en-route (E) [Precipitation, icing, windspeed / direction, visibility VMC / IMC]
F6.5B
F6.5E F6.5F
6.5.2 Assess Wx proximity to planned route (E)
(c) (a) (b) (c) (c) (c) (c) (a)
(continuous function) Wx proximity inaccurately determined nearer than actual Wx proximity inaccurately determined further than actual Wx movement inaccurately predicted – slower than actual Wx movement inaccurately predicted – faster than actual Unable to determine a separation route around the weather – UAVS failure
F6.5L
(a)
F6.5M F6.5N F6.5O F6.5P F6.5Q F6.5R
(a) (b) (c) (c) (c) (a)
Unable to determine a separation route around the weather – weather close out Flight path not modified to avoid bad Wx Unnecessary route around inserted in flight path Revised bad Wx route does not avoid the weather Revised bad Wx route exceeds range capability of vehicle Revised bad Wx route infringes other separation zones Unable to determine a diversionary airfield
F6.5G F6.5H F6.5I F6.5J F6.5K
6.5.3 Determine Wx separation route around (E) [to reach final destination]
6.5.4 Determine nearest diversionary airfield & route (E)
F6.5S F6.5T
(a) (b) (c)
F6.5U F6.5V
(c) (c)
F6.5W
(c)
F6.5X
(c)
F7.1A
7. Manage Flight Systems (I) 7.1 Determine flight systems status (I)
F7.1B F7.1C F7.1D F7.1E F7.1F 7.2 Redundant systems control? (I)
Unable to determine a route to the diversionary airfield (continuous function) Incorrect diversion airfield determined – at increased flight distance Incorrect diversion airfield determined – weather close out Diversion airfield determined only periodically (i.e. not continuous function) Diversion airfield not communicated between UAV and GCS, immediately after determination Diversion route not communicated between UAV and GCS, immediately after determination
(a)
Unable to determine flight critical systems status
(b) (c) (c) (c) (c) (c)
(continuous function) Flight critical system indicates a single fail, incorrectly Flight critical system indicates a total fail, incorrectly Flight critical system single fail not indicated Flight critical system total fail not indicated Incorrect flight system shown as having failure [leave to system level FHA]
D-25
FFA ID
Function
Failure Condition (Hazard Description) (a), (b), (c)
F7.3A F7.3B F7.3C F7.3D F7.3E F7.3F F7.3G F7.3H F7.3I
7.3 Degraded systems emergency actions (I) 7.3.1 Divert (E)
7.3.2 Emergency Landing (E)
(a) (b) (c) (c) (c) (c) (c) (c) (a)
F7.3J F7.3K
(b) (c)
F7.3L
(c)
F8.1A F8.1B F8.1C F8.1D F8.1E F8.1F
8. Pre Flight Preparations (I) 8.1 Mission Planning (I) 8.1.1 Plan mission (I)
(a) (a) (b) (c) (c) (c)
F8.1G F8.1H
(c) (c)
F8.1I
(c)
F8.1J
8.1.2 HIRF Location awareness (E)
F8.1K F8.1L F8.1M F8.1N F8.1O F8.1P F8.1Q F8.1R F8.1S F8.1T
8.1.3 Terrain Awareness (E)
8.1.4 Danger Area / populated area awareness (E)
(a) (b) (c) (c) (c) (c) (a) (b) (c) (c) (c) (c) (a)
F8.1U F8.1V
(b) (c) (c)
F8.1W
(c)
F8.1X
8.1.5 Controlled Airspace awareness (E)
Failure to divert when expected Divert carried out when not necessary Divert carried out to different divert airfield than determined Divert carried out on different route to that determined (Divert demanded but no airfield or route available) (Divert due to Collision Avoidance failure partially carried out – without broadcast ) (Divert carried out when Emergency Landing should be ) (Emergency Landing carried out when divert should be) Failure to carry out controlled Emergency Landing, when necessary Emergency Landing carried out when not necessary (Emergency landing carried out partially – without MAYDAY broadcast) Emergency landing attempted in populated area
Unable to plan mission Mission plan completed but not retained and loaded (Mission planning initiated when not required?) Mission plan partially complete Mission plan partially in error – random error Mission plan partially in error – stale information from earlier mission Mission plan for incorrect mission loaded Mission plan confuses ident of UAVS system elements (UAVs; GCSs) Mission plan completed but not within capability of UAVS performance Unaware of HIRF locations for mission planning (continuous function) Not all HIRF locations known for mission planning Some HIRF locations incorrect for mission planning Some HIRF height / range information incorrect for mission planning Some HIRF types incorrect for mission planning Unaware of terrain for mission planning (continuous function) Not all terrain known for mission planning Some terrain positions incorrect for mission planning Some terrain heights incorrect for mission planning Some terrain types incorrect for mission planning Unaware of Danger / populated areas for mission planning
(a)
(continuous function) Not all Danger / populated areas known for mission planning Some Danger / populated areas locations incorrect for mission planning Some Danger / populated areas height information incorrect for mission planning Unaware of Controlled Airspace for mission planning
(b)
(continuous function)
D-26
FFA ID
Function
Failure Condition (Hazard Description)
F8.1Y F8.1Z
(a), (b), (c) (c) (c)
F8.1AA
(c)
F8.1AB F8.1AC F8.1AD
8.1.6 Weather awareness (E)
F8.1AE F8.1AF F8.1AG
F8.2A F8.2B F8.2C F8.2D F8.2E F8.2F F8.2G F8.2H F8.2I F8.2J F8.2K F8.2L F8.2M F8.2N F8.2O F8.2P F8.2Q F8.2R F8.2S F8.2T F8.2U F8.2V F8.2W F8.2X F8.2Y F8.2Z
F9.1A F9.1B F9.1C F9.1D F9.1E F9.1F
8.2 T/O / Launch Preparation (F) 8.2.1 Refuel / recharge consumables (I)
8.2.2 Pre flight systems test (I)(F)
8.2.3 Upload Mission Plan (I)(F)
9. Manage Communications (E) 9.1 Understand / reply to Airfield ATC voice comms (E)
(c) (a) (a) (b) (c) (c) (c) (c)
Not all Controlled Airspace known for mission planning Some Controlled Airspace locations incorrect for mission planning Some Controlled Airspace height information incorrect for mission planning Some controlled airspace types incorrect Unaware of current weather conditions Unaware of predicted weather conditions (continuous function) Weather conditions incorrect - optimistic Weather conditions incorrect - pessimistic Weather conditions incorrect – location or path (also as function 6.5)
(a)
Unable to refuel / recharge consumables
(b) (b) (c) (c) (c) (c) (a) (b) (b) (c) (c) (c) (c) (a) (b) (b) (c) (c) (c) (c) (c) (c) (c) (c) (c)
(Refuel / recharge at incorrect phase?) Refuelling / recharging still underway at launch Partially refuelled / recharged Fuelled / charged with incorrect consumables Fuel / charge contaminated Fuelled asymmetrically (fore / aft; left / right) Unable to pre-flight systems test (Pre-flight systems test at incorrect phase?) Still in pre-flight test at launch Partial pre-flight systems test carried out Pre-flight systems test returns incorrect pass for critical system Pre-flight systems test returns incorrect fail for critical system Pre-flight systems test confuses Ident of systems test results Unable to upload mission plan (Upload mission plan at incorrect phase?) Still uploading mission plan at launch Partial upload of mission plan carried out Mission plan uploaded but not retained – no plan Mission plan uploaded but not retained – stale plan retained Incorrect mission plan uploaded – UAV differs from GCS Incorrect mission plan uploaded – both UAV and GCS Incorrect mission plan uploaded – current and next GCS differ Incorrect mission plan uploaded – both current and next GCS Mission plan corrupted during upload Mission plan upload confuses ident of UAVs (relay / sensor UAVs)
(a)
Unable to hear ATC airfield voice comms at all
(a) (a) (a) (b) (b)
Unable to hear ATC airfield voice comms intermittently Unable to understand airfield ATC voice comms Unable to reply to airfield ATC voice comms Transmit on ATC airfield comms channel when not intended Comply with / reply to airfield ATC message intended for another aircraft (Comply with / reply to airfield ATC message from incorrect airfield) Misunderstand ATC airfield comms
(b) F9.1G
(c)
D-27
FFA ID
F9.1H F9.1I F9.2A
Function
9.2 Detect & respect airfield visual signals (E)
F9.2B F9.2C F9.3A
Failure Condition (Hazard Description) (a), (b), (c) (c) (c) (a) (b)
9.3 Understand / reply to En-Route ATC advice - voice / digital (E)
(c) (a)
Delay responding to airfield ATC comms Incorrect message transmitted to airfield ATC comms Unable to detect or respect airfield visual signals Detect / respect airfield visual signals that are not pertinent to UAV position (incorrect signal detected / respected) Misinterpret airfield visual signal Unable to detect ATC en-route comms at all
F9.3B F9.3C F9.3D F9.3E F9.3F
(a) (a) (a) (b) (b)
F9.3G
(b)
F9.3H F9.3I F9.3J F9.4A
(c) (c) (c) (a)
Unable to detect ATC en-route comms intermittently Unable to understand en-route ATC comms Unable to reply to en-route ATC comms Transmit on en-route ATC comms channel when not intended (Comply with / reply to en-route ATC message from incorrect ATC service) Comply with / reply to en-route ATC message intended for another aircraft Misunderstand en-route ATC comms Delay responding to en-route ATC comms Incorrect message transmitted to en-route ATC comms UAV not visible to ATC for transponder tracking
(a) (a) (b) (b) (c) (c) (c) (a)
UAV not visible to ATC for RADAR tracking by RF signature UAV not visible to ATC for tracking visually (RF signature / visual are continuous functions) Provide transponder response when not required Provide transponder response late when interrogated Provide incorrect Aircraft Identifier when interrogated Provide incorrect aircraft altitude when interrogated Unable to change ATC frequency selection
F9.5B F9.5C F9.5D
(a) (b) (c)
F9.5E
(c)
Unable to hold required ATC frequency ATC frequency changed when not required ATC frequency changed to incorrect frequency (not in use frequency) ATC frequency changed to incorrect frequency (in-use frequency) ATC frequency changed to emergency frequency in error Possible range of procedures constrained to following: 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 Unable to determine required manoeuvre from ATC comms
9.4 Provide Tracking 'visibility' (signal, visual) (E)
F9.4B F9.4C F9.4D F9.4E F9.4F F9.4G F9.5A
9.5 Manage ATC Frequency selections (E)
F9.5F
(c) 9.6 Comply with ATC procedures (E)
F9.6A
9.6.1 Determine required manoeuvre from ATC comms (E)
(a)
F9.6B
(b)
F9.6C
(c)
F9.6D F9.6E F9.6F F9.6G F9.6H
9.6.2 Confirm manoeuvre with ATC (E)
(c) (a) (a) (b) (c)
Manoeuvre determined from ATC comms, where none was requested Incorrect manoeuvre determined from ATC comms and carried out ATC required Manoeuvre partially completed Unable to confirm initiating manoeuvre with ATC Unable to confirm completing manoeuvre with ATC ATC manoeuvre ‘confirmed’ when none was requested Incorrect ATC manoeuvre ‘confirmed’ to ATC (compared to that being actually carried out)
D-28
FFA ID
F9.7A
Function
9.7 Emergency Broadcast Actions (E) (Coll aware fail; D/L fail; Mayday)
F9.7B F9.7C F9.7D F9.7E F9.7F F9.7G
F10.1A F10.1B F10.1C F10.1D F10.1E F10.1F F10.2A
10. Collision Avoidance (F)(E) 10.1 Detect Traffic (E)
10.2 Determine traffic relative track (E)
F10.2B F10.2C F10.2D F10.3A
10.3 Maintain traffic separation (ROA) (E)
Failure Condition (Hazard Description) (a), (b), (c) (a)
(a) (a) (b) (b) (b) (c)
Unable to broadcast – Data Link Fail Unable to broadcast – Mayday Broadcast ‘Collision awareness fail’ when not required Broadcast ‘Data Link fail’ when not required Broadcast ‘Mayday’ when not required Broadcast incorrect emergency message compared to that actually required
(a) (a) (b) (c) (c) (c) (a)
Unable to detect ‘co-operative’ traffic Unable to detect ‘non co-operative’ traffic Traffic detected when not present Traffic detected late Traffic detected in incorrect position Traffic detected at incorrect height Unable to determine traffic relative track
(a) (b) (c) (c) (a)
Traffic relative track determined at low update rate (continuous function when traffic detected) Traffic relative track incorrectly indicated as converging Traffic relative track incorrectly indicated as not converging Failure to manoeuvre (adequately) to maintain traffic separation i.a.w. Rules of the Air (right of way / minimum separation) Traffic separation manoeuvre initiated when UAV should maintain current track (right of way) Incorrect traffic separation manoeuvre initiated (turn direction) Failure to manoeuvre (adequately) for collision emergency evasion Collision emergency evasion manoeuvre initiated late Collision emergency evasion manoeuvre initiated when unnecessary Incorrect collision emergency evasion manoeuvre initiated (turn direction / height change) Collision emergency evasion manoeuvre successful but UAV affected by aircraft wake turbulence Unable to be detected by ‘co-operative’ traffic
F10.3B
(b)
F10.3C F10.4A
(c) (a)
10.4 Collision emergency evasion (E)
F10.4B F10.4C
(a) (b)
F10.4D
(c)
F10.4E
(c)
F10.5A
10.5 Conspicuity to air traffic (visual, RF) (E)
(a)
F10.5B F10.5C
(a) (a)
F10.5D
(a) (b)
F10.5E
Unable to broadcast – “Collision Avoidance Fail”
(c)
Unable to be seen by other air traffic UAV RF (Radar) Conspicuity varies significantly with observation aspect UAV visual conspicuity varies significantly with observation aspect (continuous function for civil operation – i.e. not switchable stealth) UAV resembles other aircraft types of different size or performance
D-29
Undamped / poorly damped manoeuvres or speed
Over damped manoeuvres or speed
Phase lag drives oscillations
F1.2B
F1.2C
F1.2D
D-30
(1) Significant reduction in safety margins during T/O or landing, due to control effect delay. Potential for ground impact close to T/O or landing area (2) Severe control lag could cause height bust, deviation from clearance on approach, or reduced separation (As F1.2B)
(1) Significant reduction in safety margins during T/O or landing, due to oscillations. Potential for ground impact close to T/O or landing area (2) Severe oscillations could cause height bust, deviation from clearance on approach, or reduced separation
(1) Hazardous (2) Severity 2
(1) Hazardous (2) Severity 2
(1) Hazardous (2) Severity 2
(1) Catastrophic (2) Severity 1
(1) Unstable UAV leads to overall loss of control – unable to continue controlled flight Knock-on for Rel UAV would be loss of data link for Sens UAV
Loss of UAV stability
F1.2A
Tax, TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F Land A, Land F Tran, Hand, Tran S, Sens, App, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
Classification
FFA Failure Condition Flight Effect of Failure Condition - (1) AW; (2) ATM ID Phases 1. Stability & Control (I); 1.2 Stabilise perturbations (I)
[Critical safety requirements will be set, if the Relay role is to be viable in unsegregated airspace.]
Justification
Table D(vii) – Failure Effects for (a selection of) Guard Dog failure conditions
Effect of Failure Condition – (1) AW – effect on UAV, safety margins, continued & controlled flight; (2) ATM – effect on UAV Crew, ATCO, other Traffic
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.
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).
Preliminary Notes:
EFFECTS CONSIDERATION
Undemanded manoeuvre
Asymmetric manoeuvre control – demand in one axis causes uncontrollable manoeuvre in another axis Transient control deflections
Manoeuvre control restriction – limited manoeuvre
Manoeuvre control jams – unable to stop manoeuvre
F1.3C
F1.3D
F1.3F
F1.3G
F1.3E
Unable to manoeuvre UAV in certain axes, when demanded
F1.3B
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
(as F1.3C)
(as 1.3B)
(as F1.3C)
D-31
(1) In extreme, at critical flight condition (TO or Landing) loss of control (2) Could be a cause for separation minima being breached – in extreme, (among traffic) cause collision
(1), (2) Eventually, UAV will impinge on terrain or controlled airspace (Knock on effect – a cause of F2.5G terrain separation fail; F2.6F controlled airspace separation fail; F2.7F danger / populated area separation fail; F10.3A Traffic separation fail) (1) Limited control available from secondary effects (see F1.3D below), sufficient to effect controlled loss of the UAV over an unpopulated site (2) Likely to cause infringement of controlled airspace, but some control to minimise effect (i.e. maintain limited traffic separation) (1) In extreme, at critical flight condition (TO or Landing) loss of control (2) Could be a cause for separation minima being breached – in extreme, (among traffic) cause collision
Unable to manoeuvre UAV at all when demanded
F1.3A
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
Effect of Failure Condition - (1) AW; (2) ATM
FFA Failure Condition Flight ID Phases 1. Stability & Control; 1.3 Manoeuvre UAV (I)
(1) Catastrophic (2) Severity 1
(1) Catastrophic (2) Severity 1
(1) Hazardous (2) Severity 2
(1) Catastrophic (2) Severity 1
Classification
Some secondary effects of controls are Ok (and normal aerodynamic effect), provided there is sufficient control authority to counteract them. Potential mitigation for F1.3B
Scenarios for typical missions justify likely ATM effect
(dependent on knock-on effect failure being realised)
Justification
Unable to take manual control of UAV
Unable to fly UAV with autonomy
Conflicting authority between manual and autonomous control
F1.4A
F1.4B
F1.4C
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
Taxi, TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
(as F1.4A and F1.4B)
D-32
Higher workload on UAV-p initially. Critical effect IF datalink fails coincidently (effectively coincident with F1.4A) – UAV then reacts as F1.3A
No immediate effect, UNLESS a coincident functional failure occurs (in functions 1-10 inc) requiring manual intervention
Flight Effect of Failure Condition - (1) AW; (2) ATM Phases 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 exceeds vehicle Tran, Hand, 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)
Failure Condition
FFA ID F1.3H
As for F1.3A: (1) Catastrophic (2) Severity 1
Manual override is intended as mitigation for many other failure modes. Safety requires independence from other failure forms (EITHER - autonomy in case of 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) Autonomous flight / manual override need to be independent, as either / or is required for successful continuing safe flight
AW issue, as vehicle break up takes it out of the ATM environment
(1) Catastrophic
As for the most severe of other functions 1-10: (1) Catastrophic (2) Severity 1
Justification
Classification
Conflicting authority between separate ground sources for manual control
Failure Condition
Flight Phases TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel DETECTED: GCSs may communicate, to resolve conflict and leave appropriate one in control UNDETECTED: GCSs (UAV-ps) struggle to retain control and perceive as UAV autonomous action – hence as F1.4A and F1.4B
Effect of Failure Condition - (1) AW; (2) ATM
Airspeed cannot be decreased when necessary
Airspeed runaway up
Airspeed runaway down
Asymmetric thrust (power) causing uncontrollable yaw or roll (depending on propulsion configuration) Incorrect airspeed achieved – too high
F1.6B
F1.6C
F1.6D
F1.6E
F1.6F
Airspeed cannot be increased when necessary
F1.6A
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
(as F1.6C)
D-33
As F1.3D: (1) In extreme, at critical flight condition (TO or Landing) loss of control (2) Could be a cause for separation minima being breached – in extreme, (among traffic) cause collision
(1) Flight phases: unable to maintain altitude / reach stalling speed – loss of control Knock-on for Rel UAV would be loss of data link for Sens UAV
(as F1.6B)
(1) Flight phases: Airspeed exceeds structural limit if manoeuvre has to be pulled (as F1.3I) Land: UAV unable to decelerate adequately, overruns runway / field
(1) T/O: Unable to reach take-off speed – Reject TO – reduction in safety margins but remain in control App: Difficult to maintain height profile on approach (as F1.6H) – possibility of controlled loss of UAV, short of runway
1. Stability & Control; 1.6 Control Flight Path (I); 1.6.1 Control Airspeed (I)
FFA ID F1.4D
(1) Catastrophic (2) Severity 1
(1) Catastrophic
(1) Catastrophic
(1) Catastrophic
(1) Hazardous
(1) Catastrophic (2) Severity 1
Classification
Some secondary effects of controls are Ok (and normal aerodynamic effect), provided there is sufficient control authority to counteract them. Potential mitigation for F1.3B
Speed control on approach drives classification. Assumes have adequate speed to remain in control and carry out emergency landing. MS8 routine approach to Aberporth supports classification, as approach is usually over low / no population route
UNDETECTED – MS7(a) emergency landing scenario (low altitude) indicates lack of full control may lead to uncontrolled crash in villages rather than controlled emergency landing in clear unpopulated area
DETECTED – assumes GCSs have intercommunication, independent of the UAV
Justification
Unable to determine heading
Unable to determine altitude
Accuracy error in measured position, heading or altitude
Lag in position, heading or altitude data measurement (phase shift)
F2.1B
F2.1C
F2.1D
F2.1E
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
(as F2.1A,B,C)
D-34
If DETECTED - Could manage by increasing altitude (from previous safe altitude) and steering where ground known to be lower UNDETECTED - as F2.5G Unable to maintain safe altitude over terrain ATM – if DETECTED, call ATC and declare PAN PAN PAN. If UNDETECTED, unable to maintain safe vertical separation below controlled airspace (as F2.7F) (as F2.1A,B,C)
Detected: (1) Major (2) Severity 4 Undetected: (1) Catastrophic (2) Severity 2
Undetected ATM severity assumes function 10 Collision avoidance remains active – need to beware of potential common mode failures.
MS8 routine approach to Aberporth over terrain assessed; MS5 emergency recovery under Dav CTA assessed.
AW severity assumes need to make blind emergency landing at last ‘known’ position (MS7 emergency landing scenario shows that small inaccuracies could cause impact on village location, as lesser evil to flying on and possibly crashing in major population area ATM severity assumes that function 10 Collision avoidance remains active – need to beware of potential common mode failures.
In extreme cases: (1) Catastrophic (2) Severity 2
Unable to determine position
F2.1A
In isolation – position can be approximated from heading, speed etc. In common failure with F2.1B or F1.1B – requires external means to identify position (functions 9.3 En-route ATC communications and 9.4 Tracking ‘visibility’ Without these, system faces emergency landing (function 7.3.2) in unknown terrain, or flight path through unknown airspace Knock-on for Rel UAV would be loss of data link for Sens UAV (as F2.1A)
Flight Effect of Failure Condition - (1) AW; (2) ATM Classification Phases 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)
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
Justification
Failure Condition
FFA ID F1.6G
F2.5E
F2.5D
F2.5C
Incorrect distance to terrain determined – lower than actual
Unaware of proximity of surrounding terrain to flight path Terrain proximity determined at low sampling rate Incorrect surrounding terrain determined
F2.5B
Tran, Hand, Tran S, Sens, App, Rel
D-35
(1) UNDETECTED – Steep Terrain encroaches into safe maneuvering zone – as F2.5G terrain separation (minimum) not maintained. In extreme, CFIT as F2.5B Causes F2.5G, F2.5K, F2.5M (terrain separation breached; emergency evasion not triggered; emergency evasion triggered unnecessarily) Knock-on for Rel UAV could be loss of data link for Sens UAV (causes F2.5M emergency evasion triggered when not necessary)
(1) UNDETECTED - CFIT
(1) Catastrophic
(1) Catastrophic
(1) Catastrophic
Unaware of surrounding terrain
F2.5A
(1) UNDETECTED – Controlled flight into terrain DETECTED – climb to safe height and divert
Flight Effect of Failure Condition - (1) AW; (2) ATM Phases 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)
Tran, Hand, Tran S, Sens, App, Rel Tran, Hand, Tran S, Sens, App, Rel Tran, Hand, Tran S, Sens, App, Rel Tran, Hand, Tran S, Sens, App, Rel
Classification
Failure Condition
FFA ID F2.1F
May be a cause for F2.5B – system believes terrain is being monitored, unaware of deficiency in measurements (caused by F2.1D positional inaccuracy, or F2.2D incorrect mission data elements)
Assumes TO and Land covered by functions 2.4 – ensure no combined functionality / common mode failure
Justification
Classification
Justification
Datalink attempts control hand over from current GCS without demand
Datalink control hand over from current GCS, but next GCS unable to take control Datalink control hand over from current GCS, but next GCS unaware it has control
Datalink control taken over by next GCS, without current GCS being aware
Datalink control hand over to next GCS, but current GCS also retains control (dual control)
F4.2B
F4.2C
F4.2E
F4.2F
F4.2D
Datalink control cannot hand over from current to next GCS
F4.2A
Hand , TO A, TO F, Land A, Land F, Tran, Hand, Tran S, Sens, App, Rel Hand
Hand
TO A, TO F, Land A, Land F, Tran, Hand, Tran S, Sens, App, Rel Hand
Hand
D-36
(as F1.4D conflicting authority between GCS manual controls)
(1) UNDETECTED: potential for CFIT, but UAV should follow current mission plan until manual control required (as F1.4A, F1.4D) (2) UNDETECTED: potential for controlled airspace infringement (F (2) Current GCS sees effect as loss of datalink, without appropriate emergency action. Unnecessary ATM emergency actions initiated
(1) Detected: maintain control with current datalink, keep UAV within GCS range UNDETECTED: function 4.1.1 should determine falling signal strength. If not, potential for datalink fail emergency actions – see function 4.3 nd Detected: if there is a 2 GCS in range, then OK; if there is not, then as F4.2C st UNDETECTED: 1 GCS sees loss of datalink without expected emergency action (i.e. expects function 4.3, but effect is as F4.2D) As F4.2A if 1st GCS retains control; as F4.2G if 1st GCS loses control
(1) Catastrophic (2) Severity 1
As for the most severe of other functions 1-10: (1) Catastrophic (2) Severity 1 (2) Severity 4
(1) Minor
UNDETECTED – MS7(a) emergency landing scenario (low altitude) indicates lack of full control may lead to uncontrolled crash in villages rather than controlled emergency landing in clear unpopulated area
DETECTED – assumes GCSs have intercommunication, independent of the UAV
UAV maintained in safe control by 2nd GCS, unknown to 1st GCS
[See F1.4A for discussion of manual control]
Mitigating functions – confirm no possibility of common mode failures
Classification of datalink functional failures is critically dependent on level of autonomy of UAV in event of failure, in reaching a safe outcome.
Failure Condition
Flight Effect of Failure Condition - (1) AW; (2) ATM Phases 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)
FFA ID F2.5F
Failure Condition
Flight Phases Hand
D/L fail action (hold then divert) taken without demand
Unable to broadcast – “Collision Avoidance Fail”
F4.3B
F9.7A
TO A, TO F, Land A, Land F, Tran, Hand, Tran S, Sens, App, Rel
IF UAV does not take necessary autonomous action, then effect as F4.3C IF UAV continues on its pre-planned path but without diverting, may cause concern to ATM (prolonged exposure to UAV without manned override capability) but should act safely if functional (2) Nuisance action, causing ATM disruption (as F9.7E broadcast ‘datalink fail’ when not required), but no direct safety effect
(function 4.3 should take effect – emergency actions in event of data link fail / degradation)
Effect of Failure Condition - (1) AW; (2) ATM
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
D-37
(2) Failures under F10 for Collision avoidance system, following function 7.3.1 to divert would be UNDETECTED by ATM and other air traffic – they would proceed as if UAV would respect Rules of the Air, in extreme allowing collision
TO A, TO F, Land A, Land F, Tran, Hand, Tran S, Sens, 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 taken – UAV remains in Land A, Land fuel and crash land hold F, Tran, Hand, Tran S, Sens, App, Rel F4.3D D/L fail action partially TO A, TO F, (2) UAV loses opportunity to re-establish D/L, but should taken – UAV diverts Land A, Land follow divert function safely – see function 7.3.1 immediately F, Tran, Hand, 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)
D/L fail action (hold then divert) not taken when required
F4.3A
(see function 7.3.1 for divert function failures)
Datalink attempted control hand over to next GCS, but neither GCS retains control 4.3 Datalink Fail / Degrade Emergency Action (I)
FFA ID F4.2G
(2) Severity 1
(1) Catastrophic
Continues preplanned actions: (2) Severity 3 (2) Severity 3
No action: (1) Catastrophic
Classification
[see functions 10, Collision Avoidance, for safety-related functions where this function is intended as mitigation]
(Implementation dependent hazard) Assumes UAV has autonomous safe response in case of D/L failure
(Implementation dependent hazard) Represents a failure of a critical autonomous response, to get the UAV down safely in event of D/L failure
No action - Represents a failure of a critical autonomous response, to get the UAV down safely in event of D/L failure Continue previous action – degrades ATM safety, but continuing autonomy gets the UAV down safely Classified on basis of ATM disruption and workload, with potential for ATM safety levels overall to be degraded during the emergency activity.
Justification
Unable to broadcast – Mayday
Broadcast ‘Collision awareness fail’ when not required
Broadcast ‘Data Link fail’ when not required
Broadcast ‘Mayday’ when not required
Broadcast incorrect emergency message compared to that actually required
F9.7D
F9.7E
F9.7F
F9.7G
Unable to broadcast – Data Link Fail
Failure Condition
F9.7C
FFA ID F9.7B
TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
Flight Phases TO A, TO F, Tran, Hand, Tran S, Sens, App, Land A, Land F, Rel
D-38
(2) If intent is to divert, but ‘mayday’ broadcast, then as F9.7A and B. If intent is to make emergency landing, but ‘divert’ type message broadcast, then as F9.7C
(2) Nuisance warning causes ATM to alert / redirect other air traffic unnecessarily. Overall affect on safety low, as systems still operational
(2) Nuisance warning causes ATM to alert / redirect other air traffic unnecessarily. Overall affect on safety low, as systems still operational
(2) Failures requiring function 7.3.2 Emergency Landing would be UNDETECTED by ATM and other air traffic. Controlled emergency landing would not be affected, but could affect ability of ATM to alert emergency services to the site. (2) Nuisance warning causes ATM to alert / redirect other air traffic unnecessarily. Overall affect on safety low, as systems still operational
(2) Failures under F4.3 for datalink, requiring function 7.3.1 to divert, would be UNDETECTED by ATM and other air traffic. Provided Collision Avoidance still active, UAV should make its way safely to diversion, but possibly cause consternation to ATM if route changes unexpectedly (and especially through controlled airspace). Could cause air traffic to deviate from their intended clearance (as collision avoidance is a later stage of traffic separation)
Effect of Failure Condition - (1) AW; (2) ATM
(2) Severity 3
(2) Severity 3
(2) Severity 3
(2) Severity 1
(2) Severity 3
Classification
Classified as such on basis of upheaval to ATM, possibly causing degraded safety of the ATM overall in having to redirect aircraft ‘ad hoc’ to avoid UAV locality
Classified as such on basis of upheaval to ATM, possibly causing degraded safety of the ATM overall in having to redirect aircraft ‘ad hoc’ to avoid UAV locality
[Assumes that UAV autonomous divert remains functional, and collision avoidance system functionality – need to establish independence from data link failure] Assumes that function 2.7 Controlled Airspace avoidance not functioning, hence allowing incursion. ATM criteria assume that air traffic may be forced to change course, as UAV follows ‘right of way’ as if in general airspace, but collision avoidance system maintains at least halfrequired separation minima. Classified as severity 1, on basis that it could make a bad situation (Severity 2) much worse by not being able to send assistance rapidly to the scene. [Difficult to classify, with criteria as listed] Classified as such on basis of upheaval to ATM, possibly causing degraded safety of the ATM overall in having to redirect aircraft ‘ad hoc’ to avoid UAV locality
Justification
Scenarios for Effects Consideration (1)
Consider broad effects of environment and emergency configurations
(2)
Consider the following graphical mini-scenarios (appended to route plan maps): •
MS1 – Routine take-off from Aberporth and transit danger area
•
MS2 – Airspace pinch point, between floor of Airway B3 (3500ft) and above Liv HPZ (2000ft) (over gas rigs)
•
MS3 – GCS handover, 20nm band where Aberporth GCS and Spadeadam GCS both have datalink range
•
MS4 – UAV Relay duty, in area between Colwyn Bay and Liv HPZ
•
MS5 – Emergency Recovery, under Daventry CTA divert into Calton Moor military airfield (next to E Mids CTA)
•
MS6 – Airmanship conflict, to maintain separation under Man TMA (3500ft) forces flight below safe altitude over terrain + mast (2490ft)
•
MS7(a) – Emergency landing, East of Burnley, from low altitude (2800ft due to Man TMA)
•
MS7(b) – Emergency landing, Teesdale, from high altitude (6000ft) but over steep terrain and valleys
•
MS8 – Routine approach and landing into Aberporth, coming in over terrain, wind farms and villages
D-39
ANNEX E SWIFT ASSESSMENT FOR COMPARISON (EXTRACT OF HAZARDS)
E-1
This annex provides the summarised results of a Structured What If Technique (SWIFT) hazard identification of the Guard Dog case study. SWIFT was applied in ‘quick and dirty’ fashion by a group of 3 safety engineers with UAV assessment experience, independently from the Functional Failure Analysis carried out to apply the method defined in the body of this report. The intent was to provide a cross-check of hazards, to determine how well the FFA had identified hazards and whether, overall, there were still hazards left unidentified by either method. The evaluation of the two methods is covered in section 3.3 of the report. The results of the SWIFT are shown below, along with an indication where the FFA may have identified the same / similar hazard. Table E(i) – SWIFT hazards identified for Guard Dog case study SWIFT ID
What If / Hazard indicated
Comment w.r.t. UAVS level assessment
Pre-flight / launch (up to and including engine start) S1
Manual handling
S2
Incorrect assembly
S3 S4 S5 S6 S7 S8 S9 S10
Undetected prior damage Miss-matched program / mission Corrupted mission data Incorrect fuel-type / mixture Incomplete program / mission Incorrect fuel load Inadequate pre-flight checks Fuel fire
Ground hazard OHSA Causal – FTA or system FHA Causal – FTA
S11
Electrocution by electrics
S12
Propeller strike
S13 S14
Inadvertent launch Uncontained engine failure
S15
Poor launch site information (incomplete recce) Structural failure of pneumatics (of launcher)
S16 Launch (field take off) to clear of launch S17 S18 S19 S20 S21 S22 S23 S24 Airfield launch S25
Unable to reach launch velocity Unable to reach controlled flight Structural break up Obstacle clearance Launch out of wind limits Engine failure Flight control system failure Incorrect flight mode (autonomous or manual control) (As above plus:) Poor preparation of launch site (inadequate runway quality)
E-2
FFA Comparable Hazard
A63 A18 A67 A18 A65 A69 Particular Risk Analysis Ground hazard OHSA Ground hazard – OHSA Particular Risk Analysis A22 Causal – FTA or system FHA
A12 A12, A1, A2 A7 A22, A14 A24 A14, A6 A1, A2, A3 A8, A9
SWIFT ID
Flight S26 S27 S28 S29 S30 S31 S32 S33 S34 S35 S36 S37 S38 S39 S40 S41 S42 S43 S44 S45 S46 S47 S48 S49 S50 S51 S52 S53 S54 S55 S56 Approach and Landing S57 S58 S59
What If / Hazard indicated
Deviation from flight plan Flight into controlled airspace (when not allowed) Avionics failure (e.g. Nav system) Loss of positional information from UAV to GCS Failure of transponder Low Radar signature Bird strike EMC / EMI from transmission masts General Aviation threat (collision avoidance system malfunctions) Weather extremes (e.g. lightning, turbulence etc) Icing Loss of power supply to GCS Incorrect / corrupted signal from GCS Unable to handover to next GCS Unable to relay info to furthest UAV Loss of GCS communications Loss of GPS RF Radiation Hazard to GCS occupants Uncommanded collision avoidance Digital terrain / obstacle database not current Loss of communications with ATC Failure to respect VFR / IFR rules Pilot fatigue (long endurance shifts) Flying 2 UAVs and inadvertently commanding the wrong one Spurious system monitoring signal from UAV to GCS Lasing / identifying the wrong target EMI between UAVS internal systems Incompetent pilot
Comment w.r.t. UAVS level assessment
FFA Comparable Hazard A21 A28 A15 A51 A75, A76 A74
Causal – FTA or system FHA A42 A83, A84 A55 A55 Causal – FTA or system FHA Causal – FTA or system FHA A40 A44
A15 Ground hazard – OHSA A85 A64 A71, A73 A56
Causal – FTA or system FHA A59 Ground hazard OHSA Causal – FTA or system FHA Causal – FTA or system FHA
Security risk – control by terrorist Flight into aircraft wake Navigation visibility lights failure
A48 A86 A87
Approach / land too fast Approach / land too slow Approach / land too high
A23, A6 A23, A6 A23, A14
E-3
SWIFT ID
What If / Hazard indicated
S60 S61 S62 S63 S64
Approach / land too low Incorrectly aligned with runway Landing out of wind limits Terrain masking during approach Loss of control after landing (speed or direction)
Maintenance S65
COSHH assessment
S66
Maintenance error
S67 S68
Lack of maintenance policy / philosophy Radiation hazards
S69
Electrical hazards
S70
Stored energy
S71
S72
Inadequate in-service support e.g. logistics, airworthiness, configuration control, spares Incompetent maintainers
S73
Disposal aspects
Emergency Actions S74 S75 S76 S77
Incursion into airspace Crash landing Datalink Out of range Diversion
E-4
Comment w.r.t. UAVS level assessment
FFA Comparable Hazard A23, A14 A23, A24 A24 A50 A31, A32, A33, A34
Ground hazard – OHSA Causal – FTA or system FHA Procedural, regulatory Ground hazard – OHSA Ground hazard – OHSA Ground hazard – OHSA Procedural, regulatory Procedural, regulatory Ground hazard OHSA A30 A60, A61 A46 A57
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 FHA Functional Failures
A1 A2 A3
Flight control instability Inability to control (external) perturbations Inability to manoeuvre / maintain UAV on required flight path
F1.1-, F1.2-, F1.5A
Relating to SWIFT Comparable Hazard S18, S23
F1.2A
S23
F1.3-, F1.6O-R, F2.3, F6.5B
S23, S26
A4
Flight instrumentation (attitude and speed) errors
F1.1-
A5
Inability to identify flight instrumentation errors
A6
Inability to achieve, maintain and control required airspeed
[derived from F2.1and assessment of effects - detected and undetected] F1.6-
S22, S57, S58
A7 A8
Lack of structural integrity Unable to take manual control of the UAV (UAV-p)
F1.3H, F1.5D
S19
F1.4A
S24
A9 A10
Unable to transfer to autonomous UAV control Conflicting authority between UAV controllers (manual / autonomous) (different ground controllers)
F1.4B
A11
Control mode error (where control laws differ with phase of flight)
F1.5C
A12 A13 A14
Launcher fails to provide correct take-off speed Asymmetric thrust / power Unable to achieve / maintain / control required altitude or rate
F1.5B F1.6-
S20, S22
A15
Navigation instrumentation errors (altitude, position, heading; for general air navigation)
F2.1
S28, S42
A16
High accuracy navigation instrumentation errors (altitude, position, heading; for taxi, take off, approach, landing)
F2.4C-AB
A17
Inability to identify navigation instrumentation errors
F2.1-
A18 A19
Planned mission route stored with errors Planned mission route not achievable by UAVS (not capable within performance)
F2.2-
F-2
F1.4C,D, F4.2F
S17, S18
F1.6E
F2.2F, F6.5B, F6.5N, F8.1I
S5, S7
ID
UAVS Hazard indicated
Relating to UAVS FHA Functional Failures
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 pattern data not used
F2.4A-F
S15, S20
A23
Correct airfield and runway approach, hold, circuit and landing data not used
F2.4R-X
S57, S58, S61
A24
Inability to determine correct wind-speed and direction in relation to runway (take-off or landing)
F2.4AC-AG
S21, S62
A25
Minimum terrain separation (i.a.w. Rules of the Air) not maintained
F2.5A-O
A26
Terrain separation / emergency evasion triggered when not required / appropriate
F2.5M
A27
Separation from sensitive areas (danger areas / populated areas / NOTAMS areas) not maintained
F2.6-, F2.8-
A28
Separation from controlled airspace not maintained (when not equipped / cleared for controlled airspace operations)
F2.7-
A29
Incorrect type / identifier of controlled airspace determined (if cleared for controlled airspace operations)
[outside scope of TUAV case study, but extrapolated
A30
Incorrect emergency incursion action taken (for ROA) if controlled airspace entered in error
F2.7I,J
S74
A31 A32 A33 A34 A35
Inability to control ground speed Excessive braking when not required Asymmetric braking Inability to provide controlled ground steering Incorrect airfield layout / ground taxi route determined
F3.1A-J
S64
F3.1N, F3.1R
S64
F3.1T
S64
F3.2A-J
S64
A36
Inability to determine ground / air transition clearly
F3.2R-V
A37
Unable to correctly determine position of fixed / mobile ground obstacles
F3.2W-AC
A38
Inability to accurately determine command datalink signal strength
F4.1A-E
A39
Incorrect status of command datalink system serviceability determined
F4.1F-K
A40
Command datalink lost during attempt to hand over between GCS stations
F4.2A-G
A41
Command datalink handed to GCS, but GCS unaware it has control
F4.2D
A42
Command Datalink suffers from EMI 'cross talk' with other RF traffic
F4.2K,R
A43 A44
Command datalink lags via satellite / relay Command datalink drop outs via satellite / relay
F4.2M,U
F-3
Relating to SWIFT Comparable Hazard
S27, S75
F3.2K-Q
F4.2L,N,T,V
S39
S33
S40
ID
UAVS Hazard indicated
Relating to UAVS FHA Functional Failures
A45
satellite / relay UAV passes control datalink commands to incorrect UAV
F4.2Q
A46
Failure to take correct emergency recovery action if command datalink fails
F4.3-
A47 A48 A49
Command Datalink jammed Command Datalink stolen Valid command datalink rejected as jammed / stolen
F4.4A
A50
Inability to accurately determine terrain proximity to command datalink line of sight
F4.5-
S63
A51
Inability to telemeter accurate UAV parameters (control parameters, navigation parameters, flight system status) to GCS
F6.1-,F6.2-,F6.3,F6.4-
S29
A52
Inability to monitor initial / changing weather conditions along the mission route
F6.5A-J, F8.1AC-AG
A53
Bad weather re-routing infringes sensitive airspace / overflown areas
F6.5Q
A54
Bad weather re-routing exceeds UAV capability (performance)
F6.5P
A55
Weather effects on UAV - icing, precipitation, dust, sand
A56
UAV flight in reduced visibility / IFR conditions
A57
Unable to determine a valid diversionary airfield (for emergency / bad weather recovery)
[implied from functional consideration to avoid bad weather and F6.5M,O] [implied from functional consideration to avoid bad weather and F6.5M,O] F6.5K,L,R-V
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)
F6.5W,X
A59
Unable to accurately determine the status of critical flight systems
F7.1-
S50
A60
Incorrect emergency action taken - no action / divert / emergency landing
F7.3A-K
S75
A61 A62
Emergency landing attempted in populated area GCS moding initiates ground mode displays and controls (e.g. mission planning), when in flight monitoring / control required
F7.3L
S75
A63 A64
Incorrect mission plan completed / loaded Incomplete / incorrect supporting data available for mission planning (e.g. HIRF locations, terrain, danger areas, controlled airspace)
F8.1A-H
S4
F8.1K-AB
S45
A65
Consumables not fully refuelled / recharged prior to take-off / launch
F8.2A,D
S8
F-4
F4.4B
Relating to SWIFT Comparable Hazard
S76
S54
F4.4C
S35, S36
S46
S77
F8.1C
ID
UAVS Hazard indicated
Relating to UAVS FHA Functional Failures
A66
Consumables still being refuelled / recharged at launch (or other inappropriate flight phase)
F8.2B
Relating to SWIFT Comparable Hazard S13
A67
Consumables refuelled / recharged with incorrect or contaminated materials
F8.2E,F
S6
A68
UAV centre of gravity adversely affected by fuel charge
F8.2G
A69
pre-flight systems test returns incomplete / incorrect system status
F8.2H-N
A70
Different mission plans loaded - UAV; relay UAV; first GCS; other GCS in mission
F8.2U-X
A71
Inability to correctly understand and reply to airfield ATC communications
F9.1-, F9.5-
A72
inability to correctly detect, interpret and respect airfield visual signals
F9.2-
A73
Inability to correctly understand and reply to en-route ATC communications (e.g. advisory Flight Information Service)
F9.3-, F9.5-
S46
A74 A75
UAV poor Radar visibility for tracking by ATC Transponder failure to squawk or squawks incorrect identifier
F9.4B,C
S31
F9.4A,D-F
S30
A76
Transponder returns incorrect altitude to ATC (if Mode S / Mode C)
F9.4G
S30
A77
Radio frequency changed in error (e.g. to emergency frequency)
F9.5-
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
F9.6-
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
F9.6-
A80
UAV complies with Airfield or En-route ATC procedure intended for another aircraft
F9.6C
A81
Unable to correctly broadcast emergency message: “Collision Avoidance Fail”; Data link fail"; "Mayday"
F9.7A-G
A82
Emergency broadcast made when none necessary
F9.7D-F
A83
Inability to maintain correct, normal traffic separation , i.a.w. Rules of the Air 'Right of Way'
F10.1-, F10.2-, F10.3-
S34
A84
Inability to carry out appropriate emergency evasive manoeuvre for collision avoidance
F10.4A-D
S34
A85
Collision avoidance emergency evasion manoeuvre carried out when not appropriate
F10.4C
S44
F-5
S9
S46
ID
UAVS Hazard indicated
Relating to UAVS FHA Functional Failures
A86
UAV susceptibility to wake turbulence from other aircraft
F10.4E
Relating to SWIFT Comparable Hazard S55
A87
UAV inconspicuous to other aircraft by RF or visual means (all round visibility, or when viewed from particular aspects)
F10.5A-D
S56
A88
UAV resembles other aircraft types of different size or performance
F10.5E
F-6
