CIVIL AIRWORTHINESS FOR A UAV CONTROL STATION Chris J. Hodson

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 2008

Number of words = 48,510 as indicated by the Microsoft Word ‘word count’ tool. The count includes the title page, preliminaries, report body, and the references. Appendixes A – E contain supporting evidence and contextual information for the reader and have not been included in the word count.

Abstract Much interest is taken in Unmanned Air Vehicles (UAV) but not so much in the Control Station (CS) that controls the UAV. The aim of this project is to examine airworthiness issues concerning CS. Although military airworthiness was considered for UAV certification, for compatibility with manned civil aircraft civil UAV certification is seen as the way to proceed. Airworthiness certification covers anything that affects the operational safety of the UAV therefore this includes the CS. The aspects of civil airworthiness covered in this project are organisation, product integrity and product operation. The literary survey examined each of the civil airworthiness aspect with respect to CS and in doing so identified several outstanding issues. The project uses the ICAO Safety Management Manual (SMM) Safety Cycle as the framework on which an adapted ARP 4761 Safety Assessment Diagram is applied to develop a handover (H/O) procedure as part of a Standard Operating Procedure (SOP) required to fly the UAV in a commercial operation. The left hand side of the Safety Assessment Diagram identified the hazards corresponding to functions needed to fly the UAV, also the data needed by the UAV pilot (UAVp) to control the UAV and the data needed by the UAV and receiving CS for the H/O. The result of the hazard analysis is a set of H/O Requirements that can be used to assess a handover procedure, and a proposed H/O Procedure that could be used as the baseline for an actual H/O. The right hand side is there to evaluate the handover procedure. This has been partially implemented by the evaluation of the developed H/O Requirements and H/O Procedure against the established STANAG 4586 standard. The further evaluation required is that of the evaluation of the H/O Procedure as part of the CS SOP which is out of scope of the project. In the evaluation the H/O Requirements and H/O Procedure stood up well against STANAG 4586 with the requirements and the procedure matching with the standard in most areas. However there were deficiencies identified with STANAG 4586, the main deficiency being that the handover cannot be aborted if the handover is not completed correctly.

Statement of Ethics Ethics in Student Projects [UoY, 2008] identifies the basic principles as: 1) Do no harm; 2) Informed consent of human participants in project; 3) Confidentiality of data held on individuals. To do no harm to anybody taking part in the project they should not be put in a position of physical danger or asked to do anything which is illegal or against their best interests. The project is theoretical and examines UAV control station civil airworthiness and UAV control handover between control stations. Therefore nobody is put in a position of danger, illegality or against their best interest.

As there are no active participants in the project and as it is theoretical, no informed consent is required, no data has been taken regarding active participants and so confidentiality of data is not an issue.

Page ii

Acknowledgments I would like to thank the following people without whose help and encouragement I would not have completed the Safety Critical Systems Engineering course let alone the project. I would like to thank my parents Len and Flo for the encouragement they gave me over the years. I would like to thank Ian Presland who inspired me to take up Safety Engineering and provided me with the opportunity to do so. I would like to thank Alec Ayliffe for his support when I was finding it difficult to get hold of particular reference documents I needed. I would like to thank my project supervisor Mark Nicholson not only for the guidance, advice and encouragement that he has provided during the development of the project, but also throughout the years I have known him during the time I was completing the SCSE course modules. Finally I would like to thank my wife, Janet and my children Samantha, Corinne and Matthew for their love, support and allowing me the many hours I needed to produce the assessments and finally this project.

Page iii

List of Contents Abstract

ii

Statement of Ethics

ii

List of Contents

iv

Abbreviations and Acronyms

vii

1

Introduction 1.1 Background 1.2 Objectives and Motivation for the Project 1.3 Project Scope and Limitations 1.4 Report Structure

2

Literature Overview 2.1 Overview 2.2 A Brief History of UAV 2.3 Functions of a CS 2.4 Airworthiness Certification 2.5 UAV Operations 2.6 Situational Awareness 2.7 CS Design 2.8 Summary 2.9 Focus for Project Development

3 3 3 5 7 8 16 17 36 37

3

UAV Handover Between Control Stations 3.1 Scope of Assessment 3.2 Assumptions 3.3 Types of CS Considered 3.4 Types of Handover 3.5 When and Where 3.6 SMS 3.7 H/O Analysis 3.8 Functional Failure Analysis & FHA 3.9 CS Boundary 3.10 Part 1 Analysis – ‘Fly – H/O – Fly’ 3.11 Part 2 Analysis: H/O Sequence 3.12 Handover Procedure 3.13 Generic Checklist 3.14 Summary 3.15 Further Work

38 38 38 39 39 39 39 41 41 42 43 53 57 61 63 64

4

Case Study – Comparison of Handover Requirements and Procedure to STANAG 4586 4.1 Introduction 4.2 Scope 4.3 Assumptions 4.4 STANAG 4586 messages 4.5 Handover Requirements

65 65 65 65 65 67

Page iv

1 1 1 1 2

4.6 4.7 4.8 4.9 4.10 4.11

STANAG 4586 Fulfilment of Handover Requirements STANAG 4586 Handover Handover Procedure Requirement Fulfilment by STANAG 4586 Problems with the Theoretical Model Conclusions

73 74 76 85 86 87

5

Conclusions and Further Work 5.1 Findings, Related to Satisfaction of the Project’ Aims 5.2 Project’s Fulfilment of the Project’s Original Aims 5.3 Conclusions 5.4 Recommendations for Further Work

88 88 88 89 90

6

References

91

Appendixes A

CAA CAP 722

95

B

Situational Awareness B.1 Situational Awareness B.2 Human-UAV Interaction Awareness

97 97 97

C

Severity Criteria C.1 Airworthiness Failure Condition Severities C.2 ATM-Focused Separation / Collision Safety Criteria

103 103 104

D

Consolidated FFA Hazards

105

E

Consolidated HAZOPS Recommendations E.1 Part 1 Analysis: ‘Fly – H/O – Fly’ Recommendations E.2 Part 2 Analysis: H/O Sequence Recommendations

108 108 109

Figures Figure 2-1; Exo / Ego Centric Artificial Horizons Figure 2-2; PACT Framework Figure 2-3; STANAG 4586 Interfaces Figure 3-1; Safety Cycle [ICAO, 2006] Figure 3-2; ARP 4761 Safety Assessment Diagram [SAE, 1996] Figure 3-3; Adapted ARP 4761 Safety Assessment Diagram Figure 3-4; Control Station Functional Block Diagram (Part 1 of 2) Figure 3-5; Control Station Functional Block Diagram (Part 2 of 2) Figure 3-6; Sneak Topogram Figure 3-7; Control Station Handover State Diagram Figure 4-1; STANAG 4586 Message Wrapper Figure 4-2; STANAG 4586 Message Data Header

20 30 35 40 40 42 44 45 47 54 73 74

Page v

Tables Table 2-1; UAV Type Rating Topics Comparison Table 2-2; Relative Advantages / Disadvantages of the Types of Control Systems Table 2-3; UAV Accidents per US Armed Services Table 2-4; UAV EP Takeoff / Landing Accidents Table 2-5; UAV Automated Takeoff / Landing Accidents Table 3-1; Handover Assumptions Table 3-2; SHARD Guidewords Table 3-3; Handover Requirements Table 4-1; Fulfilment of Handover Requirements by STANAG 4586 Table 4-2; STANAG 4586 Messages Used to Implement H/O Table B-1; Comparison of Aircraft Detection Sensors

Page vi

14 19 28 28 28 38 49 53 72 75 100

Abbreviations and Acronyms AAIB AdatP-3 ADT AMS ANO ASTRAEA ATC ATO ATPL AW BBM BLOS C4I CAA CAP CCI CCISM CFIT CoG CPL CRD CS 3D DEF STAN DGA D/L DLI DoD EASA EC EP EU FAA FCL FFA FHA FHA FL FOV ft GDT GCS GPS HAL

Air Accident Investigation Board Allied Data Publication-3 Air Data Terminal Aero Medical Section Air Navigation Order Autonomous Systems Technology Related Airborne Evaluation & Assessment Air Traffic Control Air Tasking Order Airline Transport Pilot Licence AirWorthiness Break Before Make Beyond Line Of Sight Command, Control, Communications, Computers and Intelligence Civil Aviation Authority Civil Aviation Publication Command and Control Interface Command and Control Interface Specific Module Controlled Flight Into Terrain Centre of Gravity Commercial Pilots Licence Common Route Definition Control Station Three Dimension DEFence STANdard (Délégation générale pour l’Armement) – French Ministry of Defence procurement agency Data Link Data Link Interface Department of Defence European Aviation Safety Agency European Community External Pilot European Union Federal Aviation Administration Flight Crew Licensing Functional Failure Analysis Functional Hazard Analysis Functional Hazard Assessment (ARP 4761) Flight Level Field Of View feet Ground Data Terminal Ground Control Station Global Positioning System Hardware Abstraction Layer

Page vii

HAZOPS HCI HDD HF HMI H/O HQ HRA HUD ICAO ICD ID IFR IMC IP IR JAA JAR kg kJ km kts L&R LOS m MAC MAV MBB MBC MBE Met MoD ms N/A NASA NATO nm NOTAM NPA NPPL OML PACT PBS PD PPL RAM RPM Page viii

HAZard OPerability Studies Human Computer Interface Head Down Display Human Factors Human Machine Interface Hand Over HeadQuarters Hazard and Risk Assessment Head Up Display International Civil Aviation Organisation Interface Control Document IDentification Instrument Flight Rules Instrument Metrological Conditions Internal Pilot Instrument Rating Joint Aviation Authorities Joint Aviation Requirements kilogram kilo Joule kilometre knots Launch & Recovery Line Of Sight metre Mid Air Collision Micro Air Vehicle Make Before Break Management By Consent Management By Exception Meteorological Ministry of Defence milli-second Not Applicable National Aeronautics and Space Administration North Atlantic Treaty Organisation nautical mile NOtice To Airmen Notice of Proposed Amendment National Private Pilots Licence Operation Multi-crew Limitation Pilot Authorization and Control of Tasks Public Broadcasting Service Pilot’s Discretion Private Pilots Licence Random Access Memory Revolutions Per Minute

RPV RT RTCA s S&A S&P SA SAE SATCOM SHARD SID SMM SMS SOP SPIC SSA STANAG STAR TALS TBD TCAS VFR UAV UAVp UAVS UCS US USA USAF USAR UTC VFR VOIP VSM VTUAV

Remotely Piloted Vehicle Radio Telephony Radio Technical Commission for Aeronautics (known as RTCA Inc) second Sense & Avoid Stick & Pedals Situational Awareness Society of Automotive Engineers Satellite Communications Software Hazard Analysis & Resolution in Design Special Instrument Departure Safety Management Manual Safety Management System Standard Operating Procedure Student Pilot In Command System Safety Analysis STANdardisation AGreement STandard instrument ARrival Tactical Automated Landing System To Be Determined Traffic Collision and Avoidance System Visual Flight Rules Unmanned Air Vehicle UAV Pilot Unmanned Air Vehicle System UAV Control System United States United States of America United States Air Force UAV Systems Airworthiness Requirements Universal Coordinated Time Visual Flight Rules Voice Over Internet Protocol Vehicle Specific Module Vertical Takeoff and Landing Tactical Unmanned Aerial Vehicle

Page ix

This page is intentionally blank

Page x

1

Introduction

1.1

Background

The development of Unmanned Air Vehicles (UAV) has been going on for many years, recognisably as we will see later from the 1930s. The main development of UAV has been for military usage, initially for target drones and for surveillance. Today, not only is there interest in military but also civil applications. One of the biggest users of UAV for civil purposes, such as agriculture, is Japan. In the UK the main use of civil UAVs has been limited, by legislation and lack of standards to sport flying by the hobbyist and aerial photography / film work. Current legislation and standards only allows for UAVs outside military ranges to be flown a short distance from the UAV pilot (UAVp). The main use for UAVs is to carry out the dull, dirty and dangerous work that people are unable / unwilling to do. However to allow this to happen UAVs need to be integrated into un-segregated airspace and fly within the same rules as manned aircraft. Currently UAVs are only allowed to fly in segregated airspace (Danger Areas) as defined by Civil Aviation Authority (CAA) CAP 722 [CAA, 2004] as Group 1 and Group 2. Groups 3, 4 and 5 cover the airspace flown by civil manned air traffic. To allow for the integration of manned and unmanned flights within these groups, the issues of how UAVs can be cleared to fly and the infrastructure to support them needs to be addressed. 1.2

Objectives and Motivation for the Project

The roles in which UAVs are used for civil applications are expanding. In future there will be the need not just for UAV tasks local to its Control Station (CS) but for long distance flights Beyond Line Of Sight (BLOS) and for endurance station keeping duties. In both cases the UAV will need to be handed over to another UAVp. In the first case the UAVp is in another CS closer to the area the UAV is to carry out its task. In the second case the UAV will be flying for many hours in which case the UAV is handed over to another UAVp in the same CS to allow the first UAVp a break or to leave at the end of their shift. The project aims to:

• •

Identify safety issues regarding CS airworthiness;

•

Identify from a hazard / safety perspective;

Identify the safety issues regarding the handover (H/O) of a UAV to another UAVp; −

The data that needs to be passed between the UAV pilots;

−

The co-ordination that needs to be implemented between the UAVps. The two cases are: − UAVp1 to UAVp2 in the same CS; − CS1 UAVp to CS2 UAVp. Where the CS that is handing over the UAV, is referred to as CS1, the CS receiving the UAV referred to as CS2. For UAVps, UAVp1 is the UAVp handing over control of the UAV; UAVp2 is the UAVp to receive control of the UAV. 1.3

Project Scope and Limitations

This report considers commercial UAVs that do not meet the limitations of CAP 722 [CAA, 2004] thus requiring civil airworthiness certification. Airworthiness certification needs to assess not only the UAV but any part of the system that has an impact on the UAV at any phase of flight. Most papers concentrate on the UAV with little regard to the object of this project, the CS, although as necessary aspects of the UAV will be considered. Airworthiness must not only consider the UAV or the UAV System (UAVS), which covers the CS and other elements necessary to enable flight, but also the supporting operations that support airworthiness. The literature survey looks at both supporting infrastructure and

Page 1

CS issues. Supporting Operations covers the selection and training of UAVps, also touched on is the importance of UAV maintenance and data maintenance to support continuing airworthiness. The nature of UAVs is such that UAV Systems come in all shapes and sizes, from very large aircraft such as Global Hawk [Williams, 2004] to micro air vehicles, each having their role to fulfil. Micro and small air vehicles systems using radio control transmitters as used for sport flying as the only means of control or systems that meet CAP 722 [CAA, 2004] are not covered by this report. 1.4

Report Structure

1.4.1

The next four sections cover each of the following topic areas: •

Section 2: This section covers the literature survey. This covers both the selection / training of UAVp and also CS Human Computer Interface (HCI) issues. This is a general overview of CS issues.

•

Section 3: UAV Handover between Control Stations. This section covers Application of ARP 4761 [SAE, 1996] as part of ICAO Safety Management Manual [ICAO, 2006] to address the UAV H/O of control from one CS to another resulting in the generation of H/O Requirements and a proposed H/O Procedure.

•

Section 4: Application of Handover Requirements and comparison of the proposed H/O Procedure to STANAG 4586.

•

Section 5: This section presents the conclusion and recommendations from the project assessed against the project aims. In addition, the areas of further work that have been identified.

Page 2

2

Literature Overview

2.1

Overview

Throughout the report the designation of UAVp for UAV pilot has been used in line with CAP 722 [CAA, 2004] as “the person in direct control of the UAV”. In many papers the term UAV “Operator” is used to signify the UAVp. This is incorrect; CAP 722 defines UAV Operator as “The legal entity operating a UAV System”. In terms of the Joint Aviation Authorities (JAA) the organisation made up of the European member Civil Aviation Authorities an “Operator” or more correctly the “Air Operator” is the organisation that runs the commercial air transportation operation e.g. British Airways is an Air Operator. Airworthiness not only covers UAVs but also the UAV System where UAVS is defined by European Aviation Safety Agency (EASA) [EASA, 2005] as the following, (CAP 722 definition is very similar in nature): UAV System: A UAV System comprises individual UAV System elements consisting of the flight vehicle (UAV), the “Control Station” and any other UAV System Elements necessary to enable flight, such as a “Communication link” and “Launch and Recovery Element”. There may be multiple UAVs, Control Stations, or Launch and Recovery Elements within a UAV System. “Flight” is defined as also including taxiing, takeoff and recovery/landing. The CS is sometimes known as a Ground Control Station (GCS), but this is a limitation as a CS can be on an aircraft or on a ship. For development projects a CS can be just a laptop linked to a transmitter / receiver or a more elaborate configuration with UAVp and camera controller stations linked to multiple communication data links. In both cases the UAVp is monitoring data from the UAV and providing control data to the UAVs. 2.2

A Brief History of UAV

The story of UAV starts prior to that of the invention of the aircraft. The Public Broadcasting Service (PBS) Time Line of UAVs [PBS, 2007] provides an insight into the early days of unmanned aviation of which the photo clips are from PBS unless otherwise noted. The UAV chosen highlight the progress in the development of the UAV, the modern UAV chosen represent a steps forward in developing civil UAV. 2.2.1

Perley's Aerial Bomber (USA) 1863 Two years after the start of the American Civil War, Charles Perley designed a hot-air balloon that could carry a basket laden with explosives attached to a timing mechanism. The timer would trip the balloon's hinged basket, and the explosives would drop out, igniting a fuse in the process. The design proved just as dangerous to those controlling the balloon as to the enemy. Both sides of the conflict were known to have used the balloons.

2.2.2

Douglas Archibald 1883

In 1883 used a camera mounted on a large kite to take the first successful aerial photographs but these pictures were only sold as novelties.

Page 3

2.2.3

Corporal William Eddy 1898 During the Spanish-American War of 1898, Corporal Eddy used a kite with a similar rig to that of Archibald’s. Using a camera with a long shutter release triggered by a cord from the ground, he took the first aerial reconnaissance photographs of enemy positions and fortifications. This was the first time an unmanned air vehicle had been used for surveillance.

2.2.4

Dr Peter Cooper and Elmer Sperry 1917 In 1917 Cooper and Perry invented the first gyroscopic stabiliser to keep an aircraft flying straight and level. They had it fitted to a US Navy Curtis N-9 trainer aircraft and created the first radio controlled UAV. It had several successful test flights and flew 50 miles carrying a 300lb bomb but was never used in combat.

2.2.5

Fairey DH.82B ‘Queen Bee’ 1931

In 1935 the aircraft company Fairey created the ‘Queen’ radio controlled target from the Fairey IIIF float plane and followed that initial experiment by creating the famous ‘DH.82B Queen Bee’ derived from a de Havilland Tiger Moth Biplane trainer. The radio controlled Queen Bees were the first returnable and reusable UAVs and were used as targets and is supposedly the origin of the term ‘Drone’ for radio controlled pilot-less aircraft. The second picture shows the ‘Ground Station for the Queen Bee’ [RPAV, 2002] 2.2.6

Radioplane Company 1939 In 1939, Englishman and Hollywood actor Reginald Denny formed the Radioplane Company (Northrop/Grumman today) in Los Angeles, developing large, remote-controlled aeroplanes. In the ensuing years they succeeded in producing a series of highly successful UAVs called OQ Targets. The U.S. Air Force ordered thousands of Radioplane's radio-controlled OQ drones, which took off via a large slingshot and landed with the aid of a 24-foot parachute. The U.S. Army and Navy used OQ Targets, to train a whole generation of anti-aircraft gunners.

Page 4

2.2.7

NASA Helios. Late 1990’s NASA’s Helios powered by solar panels established an altitude record of approximately 96,863 ft in August 2001. Photo: [Williams, 2006]

2.2.8

AEROSONDE Laima 1998 In 1998, a 13 kg Australian system called Aerosonde Laima crossed the Atlantic, with fully autonomous navigation (using GPS) on only 1.5 gallons of automotive petrol opening the door for long endurance civil systems. Photo: [Marsters, 2003]

2.2.9

BAE Systems HERTI 1A 2005

On 18th August 2005 the first fully autonomous mission of a CAA approved unmanned aircraft in UK airspace. Photo: [Kane, 2007]

2.3

Functions of a CS

For a civil aircraft pilot to fly the author has identified the following activities he must undertake:

• • • • •

Use map data to plan the flight route the aircraft is to take;

•

Check the route to ensure that no obstacles whether terrain, or man made features at the altitude aircraft is intending to fly;

•

Include diversion airfields within planning (in case of emergency or bad weather);

• • •

Calculate fuel needed plus contingency allowance for safety;

• • •

Transponder squawk codes to be used on route;

Allow for any aircraft limitations (climb rate etc); Make adjustments to allow for weather conditions; Adjust flight route due to NOTice To Air Men (NOTAM) notices; Add any special takeoff procedures such as noise abatement or Special Instrument Departure (SID) procedures for the departure airport. Also any special arrival procedures such as STandard instrument ARrival (STAR);

Aircraft takeoff weight and centre of gravity are within the safe limits; Frequencies needed to contact the Air Traffic Control (ATC) centres at the departure and arrival airfields and on route; Create flight plan; Check flight plan is as was intended, achievable – tanks large enough to take required fuel;

• Interface to ATC to submit flight plan. The above actions by a civil pilot would be just the same for a UAVp. The UAVp uses the CS to plan the UAV route so it can be uploaded to the UAV. In addition to the above the UAVp, if flying more than just a short distance from the CS, must check if the UAV could Page 5

get BLOS or out of signal range. If so, a handover to another CS is required and a hand back at some stage (on the assumption that UAVs are operated from a ‘home’ maintenance base) is to be planned for. Also emergency planning to provide the UAV with instructions to follow in an emergency (system failure) or loss of data link is required. Once planning is complete the additional actions the UAVp has to do is to collate the data, initiate data validation to check the data for errors such as flying too low or asking the UAV to implement actions outside its operational capabilities. Once this is done the flight plan data has to be loaded into the UAV. Checks at this stage would also be made to ensure that the data has been loaded correctly. Prior to flight a pilot would check the aircraft is airworthy:

• Landing gear OK; • Check fuel tanks are filled; • Check control surfaces (free movement and in correct direction); • Check instruments. The UAVp as would any pilot check the UAV assuming the UAVp is in fact in the vicinity of the UAV. The UAVp may of course not be at the airfield the UAV is to fly from. To address this some systems have internal and external pilots, with the external pilot responsible for the takeoffs and landings. Then the internal UAVp is totally dependent on the external pilot / ground crew to carry out the pre-flight checks and authorising the UAV fight. Even if the UAVp was in the locality he would need the ground crew’s feedback to check that the control surfaces were moving in the correct direction. Prior to takeoff the pilot would:

• Contact ATC to obtain weather and runway information; • Set pressure altimeter to setting provided by ATC; • Gain clearances from ATC to start engines and to taxi to holding point. For the UAVp after obtaining the altimeter settings, assuming the UAV used a barometric altimeter, the UAV would need to be sent the updated settings. In the long term for the UAV to be practicable it needs to be able to operate from an airfield. It is assumed for airfield operations that the visibility afforded the pilot / sense and avoid sensors on the UAV provide the pilot with the ability to navigate from the apron to the airstrip (this is of course further work). In doing so, the UAVp must not only be able to read the airfield signs but also to avoid any unforeseen obstacles during the taxi out. For routine civil operations from an airfield, it is impractical to have a ground crew tow the UAV to the runway or to recover it after it has landed. Until these issues are addressed the UAV’s alternatives are limited. The UAV has to takeoff from a private airstrip after being manually aligned or launched via a launcher from a field. Takeoff / Flight: • ATC Clearance to takeoff;

• Taxi to start of runway, set flaps and increase to full engine power; • Takeoff and fly the plane following the filed flight plan. Takeoff / flight and landing are where the issues arise for UAV flight. Taking the pilot out of the aircraft and placing him in the CS raises several issues, that of: • Sensory depravation; • Dependency on the data link; • Latency of the data link and the effect on the controllability of the UAV; • The level of automation. These issues are covered later in the report in greater depth.

Page 6

2.4

Airworthiness Certification

2.4.1

Introduction to Airworthiness

The essential requirements for airworthiness for an aircraft to be flown in Europe are provided by the EASA Regulation (EC Regulation 216/2008) [EC, 216, 2008] Annex I. The regulation breaks down airworthiness into the following aspects: 1) 2) 3)

Product integrity; Product operation; Organisation.

Product integrity is about assuring that the aircraft can handle all anticipated flight conditions for the operational life of the aircraft. Compliance to requirements shown by assessment or analysis, supported where necessary by tests. The design to meet airworthiness includes consideration of structures / materials, propulsion plus systems and equipment. Product integrity also covers continuing airworthiness; this includes the inspection / maintenance of the aircraft plus providing the supporting manuals to support maintenance activities. Product operation is showing that the aircraft is operated to ensure a satisfactory level of safety for those onboard (not applicable for a UAV) or on the ground during the operation of the aircraft. The application manufacture or required scope considered to airworthiness. 2.4.2

of airworthiness also encompasses the organisations undertaking design, maintenance to ensure the organisation has the means necessary for the of work. In addition, the organisation’s management systems are also ensure continuing compliance with the essential requirement for

CAP 722 and Airworthiness

CAA CAP 722 [2004] is provided as guidance to enable a UAV to be exempt from the EASA Regulation [EC, 216, 2008] (which repeals [EC, 1592, 2002] identified in CAP 722) and Air Navigation Order (ANO) CAA CAP 393 [2006] airworthiness requirements. CAP 722 applies the same limitations to civil UAVs as are applied to sport model aircraft flyers. UAVs flown solely in the UK and under 150 kg are subject to UK national regulation, over 150 kg are subject to EASA regulations. An overview of CAP 722 in provided in Appendix A. The limitations placed on UAVs under the provisions of CAP 722 relate to the mass of the UAV, the speed, the height and distance from the UAVp at which the UAV can be flown. In addition, limitations are placed on how close the UAV can be flown to built up areas or to people. Limiting the UAV to operation within 500m range and 400 ft high relative to the pilot also to achieve a 95 kJ kinetic energy limit to be able to attain an airworthiness exemption. This greatly limits the usefulness of such UAVs. The UAV to have any sort of payload, carry the avionics equipment it needs to be able to fly, navigate and communicate as well have any sort of endurance will find it difficult to come in under 150 kg. These limits are too restrictive and impractical for commercial applications, other than very basic aerial film work. The only practical solution for commercial operations is by airworthiness certification. For a UAV to fly over cities or crowds, limitations similar to manned civil aircraft would be applied. If the UAV is only flying over a city or a crowd, the exposure to risk is small as it is transitory and it would be required to be flying at a minimum altitude to enable it to glide out of the area or have a minimum of 2 engines. In the case of UAVs used for crowd surveillance purposes, exposure to the risk of the UAV coming down is much higher. In which case, a kinetic energy limit for the UAV may be applied and / or that surveillance cannot be from overhead but from a distance away; as well as a minimum altitude restriction. Under airworthiness certification anything that affects the operational safety of the UAV would be covered by airworthiness requirements. Therefore as the CS affects the airworthiness of the UAV and for that matter if a launcher were used then this would also be covered by airworthiness requirements.

Page 7

2.4.3

Civil or Military Route to Airworthiness Certification

Haddon et al [2002] studied the case for safety targets as per Military or requirements as per current manned civil aviation. His conclusion was that although it would be easier to implement military targets, it would not be seen as comparable with manned civil airworthiness. EASA as part of the proposed amendment to the policy for UAV Certification EASA [2005] also considered a Target or a conventional requirement approach to airworthiness. EASA concluded that: “the existing civil regulatory system has delivered continually improving safety levels whilst being flexible enough to cope with the relentless evolution and development in aircraft design over the last half century”. Addressing safety from a purely aircraft airworthiness aspect is not enough as safety must be addressed holistically. EASA Regulation EC 216/2008 [EC, 216, 2008] identifies three aspects of airworthiness: product integrity, product operation and organisation. With this in mind, the International Civil Aviation Organisation (ICAO) has issued Safety Management Manual (SMM) [ICAO, 2006] which addresses the organisational aspect of airworthiness. Safety is defined in SMM as: “Safety is the state in which the risk of harm to persons or of property damage is reduced to, and maintained at or below, an acceptable level through a continuing process of hazard identification and risk management”. The role of ICAO SMM is for a proactive approach to safety by establishing a Safety Management System (SMS) defined by ICAO as: “An organised approach to managing safety, including the necessary organizational structures, accountabilities, policies and procedures”. To ensure compliance with the essential requirements for airworthiness, the aim is for continuous improvement of the system. The SMM is a framework from which an operator can build a SMS. The SMM Safety Cycle which is a circular framework to identify hazards, assess risks, implement the actions, to monitor and if necessary revisit. This has been used to address an aspect of UAV operations in the form of the development of an operating procedure, specifically UAV control Hand Over (H/O) which is covered in section 3. On civil manned aircraft product integrity aspect of airworthiness is implemented by the application of complementary standards ARP 4754 [EUROCAE, 1996] and ARP 4761 [SAE, 1996]. ARP 4754 addresses the certification aspects of highly-integrated or complex systems installed on aircraft. ARP 4761 addresses the methodologies for safety assessment processes. Evans [2006] adapted and applied ARP 4761 Functional Hazard Analysis (FHA) to a broad approach to UAVS. Section 3 of this report follows on from Evans and adapts ARP 4761 Safety Assessment Diagram for use with the SMM Safety Cycle framework above to implement the H/O Requirements and H/O Procedure for a H/O between CSs as part of the CSs Standard Operating Procedures. Evans also examined the application of ARP 4761 severity classification / effect and modified the effect definition to apply to UAVs. This report has applied the work by Evans on severity classification in the hazard analysis of the CS and the H/O of UAVs. 2.5

UAV Operations

2.5.1

Overview

Airworthiness not only applies to the UAV and the CS that controls the UAV but also the overall operation that supports the airworthiness of the system. Civil Aviation Authorities of certain European countries including the United Kingdom have come together under Joint Aviation Authorities (JAA) / EASA to agree common Joint Aviation Requirements (JAR) across member states. These requirements form the regulations covering operational, medical and Flight Crew Licensing (FCL). To fly commercially in the UK then the JAR administered by the UK CAA must be adhered to.

Page 8

2.5.2

UAVp Licensing

If the UAVS meets the criteria laid down by CAA CAP-722 [2004] as shown in Appendix A no pilot licence is required. This is however somewhat limiting as noted above. To use the UAV in controlled airspace then the UAVp has to be a licensed pilot and the UAVS accredited with a certificate of airworthiness. The types of pilot licences are:

• •

National Private Pilots Licence (NPPL); JAR FCL: − Private Pilots Licence (PPL); − Commercial Pilots Licence (CPL); − Airline Transport Pilot Licence (ATPL).

A NPPL is a UK airspace only licence which is less onerous than the JAR FCL PPL. However, neither of these licences allows the pilot to fly for monetary gain. To fly commercially the pilot must be either a CPL or an ATPL. To be qualified to ATPL level is somewhat over qualified to fly a UAVS. Operation of a UAVS requires the use of Radio Telephony (RT) whether directly from the CS or via UAV. To operate a radio in an aircraft/UAV the pilot is required to pass the Flight Radiotelephony Operators Licence. This is a required qualification for a commercial pilot. As part of the licence come Class and Type Ratings. Aircraft Class Ratings are defined by JAR-FCL 1.215 [JAA, FCL1, 2006] and cover the class of single pilot aircraft, not requiring a Type Rating such as

• Single-engine piston, land or sea; • Single engine turbo-prop, land or sea; • Multi-engine piston, land or sea. Type Rating criteria for aeroplanes is defined by JAR-FCL 1.220 [JAA, FCL1, 2006] as the consideration of: • Airworthiness Type Certificate; • Handling Characteristics; • Certified minimum flight crew complements; • Level of technology. In addition, an Instrument Rating will be required to fly under Instrument Flight Rules. This is a requirement if the aircraft is to fly in Class A, B or C airspace. The above assumes a conventional aircraft, but to fly commercially in un-segregated airspace a UAVp would need equivalent licensing. To a certain extent this is dependent on the type of UAVS. At one extreme is Predator [Williams, 2004], which is flown conventionally and at the other Global Hawk [Williams, 2004] which is programmed but requires its mission parameters updating by the crew to adapt to changing circumstances such as instructions from ATC or changing weather conditions. In the case of pilot licensing to fly Predator, being single engine piston in theory would only require a Class Rating. However, the control of the UAV via the CS will in all probability require a Type Rating. Operation of Global Hawk would automatically require a Type Rating as it is powered by a jet engine. If Global Hawk were a civil and not a military operation, the mission planner or the person with overall responsibility for the flight would have to be a qualified commercial pilot. When Global Hawk is in flight the ‘pilots’ are there to monitor the flight and modify the mission on instructions from ATC, otherwise Global Hawk flies its programmed mission. At no time can the pilots override the system and take control and fly the UAV.

Page 9

2.5.2.1

CS Types

CS types are introduced here as a precursor to discussions later in the text. There are basically three types of CS:

•

Type 1: Stick & Pedals is where the UAVp can fly or override the autonomy of the UAV and fly the UAV as in Predator and Pioneer [Wiliams, 2004] respectively (Note Pioneer is normally landed by an External Pilot (EP)).

•

Type 2: Knobs & Switch HCI controls the UAV via outer loop control to update headings and altitudes via the autopilot but cannot be overridden as in Hunter [Williams, 2004].

•

Type 3: Point & Click is where the UAVp does not fly the UAV directly but via updates to the mission, updated using a mouse and keyboard HCI and sent to the UAV as a mission update for the UAV to fly as in the case of Global Hawk. UAV Pilot Ratings

2.5.2.2

DO-304 [RTCA, 2007] suggests the UAVp rating be based on, as with manned aircraft on Class or Category of the aircraft but also for the UAVp rating on UAV size, complexity and flight phases of the UAV. DO-304 suggests that for phase of flight the UAVp rating could be across the full range of operations or limited to either en-route operations or alternatively to takeoff and landing operations only. Basing the UAVp rating on size and complexity would be akin to the JAR-FCL Class and Type rating and is not unreasonable. On the face of it having a pilot licensed for the inflight or takeoff and landing segments only and not the full operation seems odd. One case is where an EP is used to directly control the UAV for takeoffs and landings. Specialist skill is needed to be able to control the UAV both when it heading towards the EP and away as it lands (see section 2.7.4 Internal Pilots vs. External Pilots). If the EP is looking after the takeoffs and landings then the Internal Pilot (IP) looks after the in-flight segment which would include bringing in the UAV, following all airfield procedures to within visual range of EP for him then to land the UAV. One other scenario is that instead of the IP handing over to an EP, the UAV is equipped with an auto takeoff and land system which cannot be overridden. Again the UAV pilot is only responsible for the in-flight segment. Flying a UAVS requires skills that are common to flying a manned aircraft but also requires other skills that are different. It is therefore assumed that flying a UAVS is not a Class Rating but a Type Rating and a specific UAVS type rating for specific types of UAVS. 2.5.2.3

Observer

DO-304 [RTCA, 2007] suggests the role of an Observer is to assist with detect, sense, and avoid, particularly during taxi, takeoff and landings and be trained in general airspace knowledge airport operations etc. Having a specific role of Observer seems of limited use. Basically he is only the pilot’s helper who can’t take over so the pilot can take a break. Nor can he take over in an emergency. A commercial airliner does not employ an observer to look out for other aircraft; airline cockpits have a co-pilot and occasionally a flight engineer, though this is rare these days. The role of the observer could be taken by that of the payload controller where a specific skill is required equivalent to the flight engineer on airliners. An example of a payload controller would be a radio network manager or camera controller. Unless the role of payload controller is required throughout or the majority of the flight in its own right, then this role should be taken by one of the UAVps leaving the other to fly the UAV. 2.5.3

Medical Requirements

Why is there a need for a medical? “The reason for establishing medical standards is to protect the public from occupations where public safety is a potential risk”. [Williams, 2007]. A UAV has no souls on board, but the UAV could endanger other airspace users or 3rd parties on the ground from either being directly hit or as a consequence of debris resulting from a collision with another aircraft due to the UAVp incapacity.

Page 10

What level of medical is required for a UAVp? In the USA the FAA have three levels of medicals: • First Class for Airline Transport Pilots;

• •

Second Class – Commercial Pilots; Third Class – Private Pilots.

In the UK the types pilot medicals as covered by the requirements of JAR-FCL 3 (Medical) [JAA, FCL3, 2006] are: • Class 1 – Airline Transport and Commercial;

• •

Class 2 – JAA-FCL Private Pilot; NPPL medical, NPPL is only valid to fly in the UK and has less stringent requirements than the JAA-FCL PPL.

A new type of medical for UAV pilots was raised by Williams [2007] but he discounted this on the grounds of the cost it would take to set up. Another suggestion would be to have the UAVp medical equivalent to that of Air Traffic Controllers. However Williams [2007] discounts this as in the USA, an ATC has to meet a Second Class medical as per a commercial pilot. This is also true in the UK, an ATC has to meet a Class 1 medical as per CAA CAP 493 [2007] Section 8 Chapter 2 para 2.1(a). For a FAA first or second class medical must have the following vision in each eye with or without correction:

• • •

Distant vision 20/20 or better visual acuity (or 6/6 metric); Near vision 20/40 or better visual acuity (or 6/12 metric); Intermediate vision 20/40 or better visual acuity.

Is there a need for a UAVp to have distant 20/20 visual acuity? This level of visual acuity would only be required for an external pilot. For an internal pilot distance vision is of no consequence as the UAVp is operating from the CS. Setting a lower level of visual acuity to be met by a UAV IP would have no impact on the cost of a medical. DeGarmo [2004] suggested that “some pilots unable to fly due to medical conditions, or perhaps even a retired pilot may find that flying UAVs offers a new opportunity”. A pilot with a medical condition which would prevent him flying as an airline pilot may not stop him being a UAV pilot. Firstly under requirement JAR-FCL3 [JAA, FCL3, 2006] 3.040 Operation Multi-crew Limitation (OML), allowance is made for where a pilots medical certificate does not fully meet Class 1. It allows the pilot to act as pilot or co-pilot as long as the other pilot is qualified, not over 60 and also not subject to OML. Also, that the pilot is considered to be within an accepted risk of incapacitation by the Aero Medical Section (AMS). As noted in DO-304 [RTCA, 2007] medical emergencies during UAVS operations should be less critical than with manned aviation. This is for several reasons. In the first instance, medical assistance can be easily sort as the CS is on the ground. In the second instance, either the second pilot can takeover flying and / or UAV is flying autonomously. Williams [2007] equates lost data link where the pilot cannot transmit commands to the aircraft to be functionally equivalent to pilot incapacitation. This does not stand to reason. On lost link the UAV will recognise the link has been lost and follow a set of preprogrammed actions until the data link is restored. If the pilot is controlling the UAV when he becomes incapacitated, the UAV has no way of knowing this and will follow whatever instructions are being transmitted, even if this is to fly under control into terrain. If however a pilot is subject to an OML and does become incapacitated, the second pilot should notice and be able to take command. Williams [2007] proposed setting the medical requirements to that required of (FFA) Second Class commercial pilot, but allow every pilot who is unable to meet the requirements to be able to apply for ‘Special Issuance’ of a medical certificate, such as for a pilot fitted with a pacemaker which would ground him. Other medical conditions are considered by Williams [2007]. Under the requirements of JAR-FCL 3 Flight Crew

Page 11

Licensing (Medical) [JAA, FCL3, 2006] 3.125 allow a ‘Special Issuance’ assessment route for pilots who would not meet a (JAA) Class 1 medical. For potential UAVps with Musculoskeletal limitations, JAR-FCL3 [JAA, FCL3, 2006] 3.200 allows the assessment under JAR-FCL3 Appendix 9 by the AMS. Using “medical flights or flight simulator testing” the AMS paying “particular attention to emergency procedures and evacuation” may provide a fit assessment but limited to demonstration aircraft or to specified types. In the case of ‘evacuation’ this would only apply to being able to get out of the CS promptly. So for a UAVS as long as the UAVp can show that the UAVS can be safety controlled, disability should not be a problem. However, the person’s licence would have limited UAVS type rating in accordance with the medical certificate. DeGarmo [2004] suggested that as well as medically restricted pilots as noted above, retired pilot may find that flying UAVs offers a new opportunity. A UK pilot aged between 60 and 65 of an aircraft engaged in Commercial Air Transport can only be part of multi pilot crew. At 65 in the UK a pilot has to cease being a pilot engaged in Commercial Air Transport operations. In some countries such as France, Italy and Portugal it is at the age of 60. Commercial Air Transport is defined by JAR-1 Definitions and Abbreviations [JAA, JAR1, 2004] as the transportation of air passengers, cargo or mail for remuneration or hire. EU-OPS1 [EC, 1899, 2006], which now replaces JAR-OPS1 [JAA, OPS1, 2007] applies to Commercial Air Transport but not to aerial work activity. Aerial activity work is defined by JAR-1 [JAA, JAR1, 2004] as ‘an aircraft operation in which an aircraft is used for specialised services such as agriculture, construction, photography, surveying, observation and patrol, search and rescue, aerial advertisement, etc.’ The description of ‘Aerial work’ fit the various intended roles of the UAVS like a glove. Therefore the restrictions on pilots over the age of 65 to cease being a pilot do not apply. So, as long as the pilot can pass the JAA Class 1 medical, with or without restrictions he may continue to fly. However, as noted in DO-304 [RTCA, 2007] to ensure safe return of property, insurers and Operators may choose to impose their own medical restrictions. One role suggested for a UAV is that of station keeping acting as a telecoms base station. This would require carrying the telecoms equipment as cargo, therefore this would constitute Commercial Air Transport and the age restrictions would then apply. As identified by DeGarmo [2004] that for some pilots with medical conditions or at an age that would exclude them from flying Commercial Air Transport flights, under current medical regulations there are procedures in place that could allow these pilots, and also pilots with disabilities to fly UAVs for the purpose of aerial activity work. 2.5.4

Recruitment and Training

In the future, UAV pilots will have to be recruited and trained to fly UAVs. Do you take qualified pilots with PPLs and provide crossover training to fly UAV or recruit novices and train them from scratch? 2.5.4.1

Military precedent

Recruitment by the US military varies between the services. USAF requires instrument rated pilots to be trained as UAVps, Marine Corps use enlisted men with PPLs, while the Army has no aviation rating requirement and uses enlisted personnel who undergo ground school training. DeGarmo [2004] notes that the use of licensed pilots and non-pilots does not provide a definitive link as to one being better than the other. Also, the autonomous technologies used are lessening the role of traditional piloting skills and shifting the emphasis to monitoring and collaborative decision making skills. Ideally, using an already trained pilot to fly a UAV means that the pilot would need a lot less training. However pilots are used to flying ‘by the seat of their pants’, using the old colloquialism, i.e. getting sensory input from their environment. UAVps do not normally get these stimuli but are in sensory deprivation and dependent on the UAV sensor inputs to the CS. For the military does it make complete sense to take a pilot who is highly trained at great cost who would much rather be flying an aircraft and place him in a CS? The Wall Street Journal [WSJ, 2002] reported the story “Top Guns Grounded, Pilots Fume at Duty on Unmanned Craft” which focussed on discontent felt by fighter pilots seconded to fly

Page 12

Predator. In the civil world, you can’t order a pilot to go and fly a UAV, it is by mutual consent. So unless a pilot cannot get a job due to medical grounds or just a shear lack of jobs available, a trained pilot is unlikely to want to fly a UAV. Therefore, it is better to train a UAVp from the outset for that role. In section 2.5.3 consideration is given to Medical Certification Requirements. Handicapped people who would otherwise be unable to meet the requirements of a JAA Class 1 medical to fly an aircraft could potentially fly a UAV. A person who was paraplegic could, depending on the CS HCI have the ability to fly the UAVS he is applying to train for. An applicant should not be turned away unnecessarily. Worse still is for the Operator who is paying to train these potential UAVps to find that a person chosen does not have the physical ability to control the UAVS. To try and ‘weed out’ unsuitable candidates before the start of training Goldfinger [2006] advocates pre-selection of trainees by the use of aptitude tests, physical examinations and psychomotor testing. Pedersen et al [2006] recalled such a situation on Pioneer when a UAVp trainee was found to have difficulty in controlling the training UAV. This was due to a farming accident as a child when his fingers were reattached after being severed. No one noticed this and so money was wasted on training. 2.5.4.2

Training Syllabus

The question was raised by Hottman et al [2006]. “What skills and knowledge are needed by UAVp to be a rated UAV pilot”? DO-304 [RTCA, 2007] states that “Training, knowledge, skills and abilities must be appropriate to the performance capabilities of the UAVS being operated, and for all locations and airspaces within which it will be operated”. The training to be given depends on three factors:

• •

What type of CS HCI i.e. stick and pedal or point and click;

•

A pilot to be trained as an internal pilot, who is responsible for in-flight segments, or as an external pilot who is only responsible for takeoffs and landings, or a general aviator who can control the UAV from takeoff to landing.

Where the UAV is to be flown, whether low level in a local area not requiring interaction with ATC or at the other extreme operating in controlled airspace;

What is expected of a commercial pilot? Why should anything less be expected of a UAVp. To be recognised as commercial pilot, the training pilots receive has to be accredited by the JAA as meeting the requirements of JAR-FCL 1 (aeroplane pilots) [JAR-FCL1, JAA, 2007], (Part 2 covers helicopter pilots). The theoretical knowledge to be covered for the Commercial Pilot licence under JAR-FCL1 is: • Air Law;

• • • • • • • •

Aircraft General Knowledge; Flight Performance and Planning; Human Performance; Meteorology; Navigation; Operational Procedures; Principles of flight; Communications.

There are subjects that are not applicable to a UAVS such as for example, under aircraft general knowledge there is the ‘Oxygen System’. The course should be taught purely for UAVp with more of an emphasis placed on UAV applicable areas. The Unmanned Aerial Vehicle Systems Association (UAVS) and DO-304 [RTCA, 2007] suggest that the following UAV Type Rating topics should be covered:

Page 13

A UK Industrial View: The Skills and Qualifications [UAVS, 2000]

DO-304 [RTCA, 2007]

• • • • • • •

• • • • • • •

• • • •

Air Vehicle Envelope; Command & Control Mechanisms; Communications; Crew Management; Emergency Procedures; Ground Handling; Instrument Metrological Conditions (IMC) Rating; Launch & Recovery; Mission Systems; Navigation; Systems Performance.

Mission Planning; Pre-flight Procedures; Takeoff and Transit to Operations Area; Flight Operations; Recovery and Landing; Post-flight Procedures; Emergency Procedures and Contingency Operations; • Maintenance Procedures.

Table 2-1; UAV Type Rating Topics Comparison 2.5.4.3

CPL Flight Training

Flying training requirements of the various versions of the CPL(A) (Aeroplane) course are covered in JAR-FCL1 [JAA, FCL1, 2006] Subpart D, Appendix 1 to JAR-FCL 1.160 & 165 (a) (1,2,3 &4). Training as Student Pilot In Command (SPIC) includes a cross country flight totalling 540 km with 2 full stop landings at different aerodromes. Unless the UAV is operating via satellite flying a 540 km cross country when limited by line of sight communications would be tortuous for the UAVp to fly. In addition a UAVp who flies a system that requires an external pilot to takeoff and land would not meet the requirements of this test. 2.5.4.4

Instrument Rating Training

To fly in Class A airspace and airways an instrument rating is required in manned aircraft. Subpart E, Appendix 1 to JAR-FCL 1.205 [JAA, FCL1, 2006] not only covers the theory as outlined in Subpart J of JAR-FCL [JAA, FCL1, 2006] but also the skill aspect to both fly manoeuvres under Instrument Flight Rules (IFR) to high tolerances and demonstrate the procedural operations required. Flying training covers:

• •

Procedures and manoeuvre for basic instrument flight without visual cues; Procedural Instrument flying for IFR flights.

JAR-FCL [JAA, FCL1, 2006] Subpart E Appendix 1 & 2 to JAR-FCL 1.205 lays down what has to be demonstrated and what flight test tolerances on such things as height, heading and speed for example are required to be demonstrated by the student pilot during the test flight. As part of basic training, a pilot is expected to learn how to recognise the onset of a stall and be able to deal with a stall and also how to execute a high bank turn. On a UAVS which is point and click, the pilot will not be able to demonstrate these manoeuvres. Even on a stick and pedal system the UAVp may not be allowed to get into such conditions by the UAV flight control laws. This is when the demonstration in an aircraft to the students would be useful. To address the different types of UAVS and the different roles taken by the different types of UAVp, the CPL needs to be modular. It is not unreasonable for a UAVp to fly the UAV as an IR UAVp but have an external pilot land the UAV. The CPL rating should then reflect aspects of the flight (i.e. takeoff and land, in-flight, IR, direct control) much like a driving licence that allows a person to take a test in an automatic car and be qualified to drive that car but if they want to drive a manual shift then this requires a re-test on a manual shift. 2.5.4.5

The Use of Aircraft and Flight Simulation as Part of Training

Flying the UAV is the aim of the training to build up the skill needed to handle the UAV. In training pilots to fly aircraft, simulators are used to provide scenarios that would be dangerous or difficult if not impossible to implement in an operational aircraft. As the CS provides its data externally, there should be no difficulty sourcing simulated data for training purposes. However, what is the benefit to the UAVp to fly an aircraft? Would flying an

Page 14

aircraft be mandatory for a trainee UAVp? As noted in section 2.5.3 medically a handicapped person could be quite capable of controlling the UAVS he is training for as this would have been assessed prior to being accepted for training. However, being unable because of the handicap to get to the aircraft or controlling it would therefore lead to failure of the course or rule the person out in the first place because of the need to fly an aircraft. There is as expanded on in section 2.7.2, the use of non-standard instruments and nonstandard layouts of instruments in certain UAVS. Pedersen [2006] identifies the mismatch between the manned aircraft instruments and those in Global Hawk leading to negative transfer of skills to that learnt on flying manned aircraft. 2.5.4.6

Licence Maintenance

Pilots whether aircraft or UAV periodically have to have their licence ratings revalidated. Pilots go through checks to ensure their skills are still up to date, usually in a simulator to practice emergency procedures, which of course they would not implement in their normal duties. In addition, if due to bad weather or have just been unable to get their required flying hours in over a period are able have a proficiency check. UAVps of automated UAVS in which the UAV could be overridden but would not unless there was a problem are not maintaining their flying skills. This is especially true where automatic landing systems are routinely used to land the UAV and a UAVp would be expected to land the UAV only if there was a problem. If so, how often should the UAVp routinely take over from the autonomous system and land the UAV or only takeover the UAV when flying the simulator? 2.5.5

UAV Maintenance

Airworthiness is not just about getting a UAVS certified and that’s it! Airworthiness has to be maintained and it must be shown that it is being done correctly by competent and trained engineers. Hobs et al [2006] notes: “That system reliability may be emerging as a greater threat to UAVs than it currently is to conventional aircraft. This trend may serve to increase the criticality of maintenance, particularly given the limited system redundancy in most small UAVs”. The reliability of UAVs is nowhere near that of manned aircraft for several reasons. UAVs have been lost due to the types of missions being flown and to human error, examples of which can be found in section 2.7.3. Many of the UAVs being flown are prototypes using off the shelf components for which the reliability is unknown. As with any new technology, there are always high initial losses until the technology matures, also the UAV ground / CS crew and maintainers gain experience with the UAVS. The subject of UAVS maintenance is an important subject in its own right but has been no more than touched on in this report. 2.5.6

Data Maintenance

Another important area which is also only touched on is data maintenance. UAVS are data driven; dependant on up to date navigation data including maps, NOTAMS, air-lane, Navaids etc and Met data. UAVS need this data in digital form so mission / flight plans can be generated, verified and loaded on the UAV. Processes must be shown to be in place to ensure that all updates are installed to keep the data current. Also that the data is correctly correlated into a mission / flight plan and correctly loaded into the UAV. 2.5.7

Summary of Operational Issues

2.5.7.1

Licensing

As discussed in section 2.5.2, to be able to fly for gain pilots have to be licensed, a UAVp should be no different. Also what is expected of commercial pilot should be no different for a commercial UAVp. Commercial pilots have type ratings on their licences allowing them to fly specific aircraft types. UAVps should be licensed in a similar way but based on both the CS and the UAV. This is however further complicated by the fact that unlike an aircraft pilot, a UAVp may be an IP and never lands the UAV or an EP who is only responsible for landing the UAV. Therefore phase of flight must be included as part of the rating.

Page 15

2.5.7.2

Medical

For equality with commercial aircraft pilots, commercial UAVp should also need a class 1 medical. However a UAVp IP doesn’t need 20/20 distant vision although an EP would. Setting a lower level of visual acuity to be met by UAV IP would not constitute a massive increase in the cost of a medical. Pilots with medical conditions or at an age that would exclude them from flying Commercial Air Transport flights may be able to fly UAVs. Under current medical regulations, there are procedures in place that could allow these pilots, and also pilots with disabilities, to fly UAVs for the purpose of aerial activity work.

2.5.7.3

Initial Training

Current commercial pilot training syllabus covers topics that are not applicable to UAVS. The UAVp training syllabus needs to include subjects that are specific to UAVS. The subjects required is also affected by the types of CS and the role the UAVp takes i.e. whether an IP or as an EP. If as an IP the UAVp is expected to fly the UAV in controlled airspace or alternatively as an EP who is responsible for takeoffs and landings they will require a different emphasis on the subjects they require. Therefore the UAVp’s syllabus must be modular to cater for the diverse combination of UAV operational needs and allow students to top-up on modules when their role or that of the UAV they control changes. For a CPL a pilot is expected to execute a cross country flight of 540km with two full stop landings at two different aerodromes. A UAVp would have difficultly in implementing the distance requirement with most UAVS when a UAV is limited by LOS control. In addition a UAVp who flies a system that requires an external pilot to takeoff and land would not meet the requirements of the test. What constitutes a reasonable cross country exercise depends on the type of CS. What is taught and later examined in terms of basic practical flying skills required of a UAVp to gain a UAV CPL will depend on the type of CS being used to fly the UAV. To fly an aircraft to IFR, a pilot requires an IR. To achieve an IR a pilot has to demonstrate the procedures and can fly the aircraft on instruments to perform manoeuvres to within limits of height and airspeed etc. This can be only done on a type 1 CS, types 2 and 3 do not allow the UAVp direct control of the UAV. Therefore, the IR must take into account and include limitations based on the CS the UAVp is to fly.

2.5.7.4

Licence Maintenance

To keep their flying skills current, aircraft pilots have to fly a number of hours each month. A pilot also takes off and lands the aircraft each time. In the case of the IP who flies UAVs where automatic landing systems are routinely used to land the UAV and the IP would be expected to land the UAV if there was a problem. If so how often should the IP routinely take over from the autonomous system and land the UAV or only when flying the simulator? 2.6

Situational Awareness

Various aspects of Situational Awareness (SA) appear in the following section on CS design section. Therefore SA is introduced here to define what SA is with regards to UAV control. Dury et al [2006] defines SA in regards to UAV control as: Given one human and one UAV working together, human-UAV interaction awareness consists of the understanding that the human has of the:

•

• Page 16

3D spatial relationship between… −

The UAV and points on the earth;

−

The UAV and other aircraft;

−

The UAV and terrain;

−

The UAV and any targets.

Predicted 3D spatial relationships;

UAV’s mission; • • UAV’s progress towards completing the mission; • Degree to which the UAV can be trusted; • Weather near the UAV; • Health of the UAV; • Status of the UAV; • Logic of the UAV. In the human-UAV interaction the UAV has the knowledge of: • Human’s commands necessary to direct a UAV; • Human-delineated constraints that may require a modified course of action or command non-compliance – e.g. fails safe modes (return home). The above are only sub-headings in Dury’s definition of SA. The definition for the sub headings are expanded on in the text of Appendix B – Situational Awareness. Note: Under the Appendix B heading of ‘The UAV and any targets’ discusses the reasons why the UAVp should not be doing the searching but a separate camera operator. Where an EP controls the UAV remotely, visually at distance much in the way a hobbyist controls a model plane, the EP has SA. He can see where the UAV is relative to himself and to other obstacles such as trees or even other aircraft around him. In the case of a pilot of a manned aircraft, in Visual Flight Rules (VFR) conditions he can look out of the front and side windscreens and spot other aircraft in the vicinity. Also he can judge how far he is from different landmarks and get a mental fix of his position. From a UAVp’s (IP’s) prospective this is not so easy: “Piloting … is an intensely visual task. Gone are the large field of regard, the subtle ‘seat-of-the-pants’ inputs and numerous clues which allow … better Situational Awareness”. “It’s like driving your car with paper towel tubes over your eyes…”. Draper et al [2005]. The IP has a two dimensional screen to see the UAV viewpoint of the world, connected to a camera with a limited FOV which may or may not be able to be panned and/or zoomed i.e. Predator has a fixed camera 30 degrees FOV facing forwards. Even for a pilot who can look out of the windscreen where there are few if any distinct landmarks, a pilot can easily become disoriented especially if one landmark is mistaken for another. The situation is even worse for a UAVp looking at the world via a small 2D screen. 2.7

CS Design

2.7.1

Introduction

Why have a UAV at all? The reason is that certain tasks are better suited to a UAV. In general terms, the dirty, the dull and the dangerous tasks suit a UAV. However taking the pilot out of the cockpit and into a CS creates its own problems. CS come in various forms, usually ground based, and may be fixed, transportable or mobile. The US military have used aircraft based CS but this has the added complication of providing kinaesthetic / vestibular cues to the UAVp that are nothing to do with the UAV with the high probability of inducing motion sickness in the UAVp. Kinesthesic cues are sensed by receptors in the muscles, tendons joints and cutaneous (skin) tissue of movement and position of our limbs. The vestibular cues are motion picked up by the vestibular system of the inner ear which consists of two sensor types, the semicircular canals and the otoliths, which are sensitive for angular and linear acceleration, respectively. For attitude perception and control, the dynamics of the semi-circular canals are of direct importance. Placing the pilot in a CS puts the pilot into an environment of sensory depravation, dependent on the UAV’s sensors and the down data link between the CS and

Page 17

UAV to provide the UAV data. The kinaesthetic / vestibular senses are used by the pilot in an aircraft to ‘feel’ what the aircraft is doing continuously colloquially known as ‘flying by the seat of your pants’ which is what the UAVp is deprived of. Vibration can be a warning of turbulence but also of something mechanically wrong with the aircraft. The other senses lost are audio and smell. A sudden noise, a change in pitch or volume could be a precursor that something is wrong providing a warning before it’s picked up if at all by the instrumentation. Smell also can play a part warning the pilot that something is overheating / burning. All these inputs are lost by moving the pilot into the CS. There are however some advantages of having a pilot in the CS apart from safety from injury if the aircraft does crash. There are mishaps due to oxygen starvation, pressure, and temperature due to life support systems failing or a hull breach. Also smoke from a failure of a non essential aircraft system is not going to cause breathing difficulties or obscured vision. Of course a fire could breakout in the CS itself or in the building housing the CS. In which case, lost link procedures would operate allowing the UAV to follow pre-planned instructions and the UAVp to evacuate the CS / building. The UAVp is dependent on the aircraft sensors for situational awareness, navigational data (i.e. altitude, heading, attitude and indicated airspeed) and system status (engine rpm, fuel level, alert and warnings). Video input provides the SA of the UAV spatially relative to features in the environment the UAV is flying in but also relative to other aircraft in the vicinity (assuming not segregated airspace). The quality of the visual input is dependent on the bandwidth of the UAV data downlink which as well as video data has to carry other UAV sensor data and systems status data. Predator has a 30 deg field of view from flight camera displayed on the Head Up Display (HUD). This is a very narrow field of view providing no peripheral vision. Predator is landed by the UAVp using the HUD. Pedersen [2006] reported that Predator landings are difficult as no sense of ground in periphery and that Predator has steep glide slope on landing. Landing was described as “look down the runway and hope for the best on touchdown’ and noted ‘not surprisingly mishap rates are high”. The update rate of the video image to the UAVp is important as this is the feedback path if the video link is being relied on to land the aircraft. Low latency data links not only in the uplink proving the commands from the UAVp to the UAV but also the down link proving the feed back of the UAVp commands are vital. This is expanded on in section 2.7.5. 2.7.1.1

Controls

There are three types of CS as noted in section 2.5.2.1. Hunter and Pioneer systems both use EPs who use what looks like a hobbyist’s transmitter to control the UAV for takeoff and landing but use internal pilot’s controls for the in-flight segment. Hunter and Pioneer differ from each other in that although the internal pilots both input data via knobs and switches to set altitude and airspeed for example for the autopilot, the Pioneer internal pilot has the option to use a stick to control the UAV making it a Type 1. Hunter does not have this option therefore Pioneer UAVS can be categorized as a Type 2. The author identifies the relative advantages and disadvantages of the control system types in Table 2-2.

Page 18

System Category

Type 1

Type 2

Advantages

Disadvantages

UAVp can take over if UAV has a problem.

Requires a skilled pilot to be able to fly UAV.

UAVp can take over from UAV to quickly execute ATC instruction.

Requires UAVp to fly UAV or simulator to refresh flying skills.

UAV could in theory be landed by UAVp.

Tiring if flown under UAVp control for long periods (Predator).

Can react to changing ground events.

Requires low latency high bandwidth data link to be able to control.

UAVp can manoeuvre aircraft as required (within limitation of control laws).

UAVp could execute a manoeuvre resulting in the loss of the UAV.

UAVp provides supervisory control of UAV, autopilot looks after flying the UAV.

UAVp cannot manoeuvre UAV as may be required demonstrate IR handling manoeuvres.

UAVp can update UAV autopilot to quickly execute ATC instruction.

UAV cannot be landed by UAVp.

Autopilot controls UAV to within small tolerances. Data link latency and bandwidth not as crucial Stick & Pedal (S&P) systems.

Type 3

UAVp provides supervisory control of UAV, autopilot looks after flying the UAV.

UAVS cannot instantly react to ATC instructions as updates to mission have to be uploaded to UAV.

Autopilot controls UAV to within small tolerances.

UAVp cannot take over is case of a problem.

Data link latency and bandwidth not as crucial S&P systems as mission uploaded.

UAVS cannot instantly react to changing situations.

No requirement for UAVp to be a skilled pilot as he does not fly the UAV.

UAVp cannot manoeuvre UAV in-flight as required as is dependent on autopilot.

UAVp cannot instruct UAV to execute a manoeuvre which would endanger UAV. Table 2-2; Relative Advantages / Disadvantages of the Types of Control Systems 2.7.2

CS Human Computer Interface Design

The basic design criteria of a CS HCI as defined by Goldfinger [2006] are:

•

Ergonomics of the CS must provide a form and fit to the human body such that seating design and environment (temperature and lighting) are comfortable. Also the configuration of displays and control layout, input devices (e.g. buttons, switches, etc) are easily accessible to the crew and reduce the effects of physical fatigue.

•

HCI provides for the safe, efficient and effective control of the UAVS, minimising the mental and physical fatigue by the intuitive operation of displays and controls plus the appropriate placement, size, colour and font of text.

Page 19

Ciavarelli [2001] defines basic principles in which displays and controls should operate whether on an aircraft or in a UAVS CS. Some of these principles are:

•

Displays and controls should operate in accordance with the documentation and in a way that represents an operator’s ‘intuitive’ understanding;

•

Standardization of controls / displays facilitates learning and transfer of operational skill between various systems. Possible ‘negative learning transfer’ can result if controls are non-standard;

•

Controls and displays that have different functions but similar arrangements are potentially hazardous. Display formats must be distinguishable from one another to clearly assess flight status data;

•

Logical grouping of controls/displays helps reduce instrument scan time and lowers operator workload.

The standard primary flight instruments in an aircraft are the artificial horizon, airspeed indicator, altimeter and heading indicator. These instruments are grouped logically together in a ‘T’ configuration with the artificial horizon at the centre of the ‘T’ with the airspeed indicator to the left, altimeter to the right and the heading indicator below. They are arranged in this way for optimum scan time and for instrument flying so these primary instruments are scanned in succession always sweeping via the artificial horizon. With today’s glass cockpits pilots can arrange what they want to see on what screen and some displays are shown as a combination of analogue and digital read out displays. The use of analogue, digital readout, a combination of both or another form of graphical readout such as bar graph must be intuitive. Each have their advantages, analogue/graphical displays are easily scanned and can show the trend of constantly changing data. Digital readouts provide a precise readout. One of the basic principles noted by Ciavarelli [2001] is that standardization of controls / displays facilitates learning and transfer of operational skill between various systems. In the Global Hawk CS the artificial horizon works in the opposite sense to a manned aircraft. In an aircraft the pilot has an egocentric view; the artificial horizon mirrors this by having the symbol representing the aircraft fixed horizontally while the artificial horizon moves relative to the real world from pilot’s perspective. Global Hawk’s artificial horizon is taken from an exocentric (external) point of view as if being viewed from behind the UAV. The horizon is fixed horizontally and the symbol for the UAV rotates relative to the horizon. Figure 2-1 shows both types of artificial horizon displaying what would be displayed by the UAV / manned aircraft executing a 45 degree bank to the left. There is a problem with Global Hawk as identified by Pedersen [2006] in that the roll attitude marks are inaccurate, 30 degrees is shown closer to 70 degrees and so does not provide a true representative roll angle of the UAV. Training a UAVp from scratch using the exocentric artificial horizon is not a problem. Only when UAVps are trained on aircraft or trained pilots fly the UAVS who are used to the egocentric view artificial horizon does this become an issue.

Figure 2-1; Exo / Ego Centric Artificial Horizons Negative transfer of skills learnt from flying manned aircraft will be carried across leading to the UAVp putting in the correction in the wrong direction in the heat of the moment potentially leading to the loss of the UAV. It doesn’t mean pilots must never fly a UAV, just

Page 20

that training will be needed to ensure the pilots adapt to non-standard instrumentation. Global Hawk is not the only system with HCI issues. Other UAVS also have HCI issues and some have more issues than others. 2.7.2.1

Predator HUD

First there is the Head-Up-Display (HUD) by which the UAVp lands the Predator. As noted previously has 30 degrees Field Of View (FOV), which Pedersen [2006] noted previously makes landing difficult as there is no sense of ground in periphery and has a steep glide slope on landing. In addition Pedersen notes that aircraft cockpit design principles are not carried over to Predator:

•

Sliding side bars that do not resemble those in manned aircraft and the symbology is not intuitive;

•

HUD red graphics on sky blue background problem of ‘chromostereopsis’ and eye fatigue.

Chromostereopsis: is a phenomenon of visual perception, different wavelengths of light focus at slightly different depths in the eye. Thus, it is difficult to focus on an image that combines two colours because each colour is fuzzy when the other colour is in focus. This is especially a problem for images with red and blue.

Is this easy to read ? This problem can be avoided by creating an image without both colours side-by-side, by using black or white boundaries, and by increasing the contrast between the two colours. [usabilityfirst, 2007] 2.7.2.2

Logical grouping of displays

The main role of the UAVp on an automated UAVS is supervisory control and sampling of the instrumentation in front of him, looking for anything out of the ordinary. Wickens2 et al [2003] identifies the following key features of supervisory monitoring as: 1. 2. 3. 4.

The operator is supervising a continuously evolving series of dynamic processes; The operator is more concerned with noticing events; Measuring the proportion of visual attention allocated to different regions of the visual field, and the tasks supported by that attention; The operator is as much concerned with when to look as with where to look.

Wikens2 [2003] went on to identify four factors that drive the allocation of visual attention: 1. Salience; 2. Effort; 3. Expectancy; 4. Value. Salience – making events prominent, stand out from their environment on displays so the UAVp can easily find the pertinent information. Effort – moving attention from one area to another. Sanders [1970] described three general regions into which visual stimuli can fall during a monitoring task: a. b. c.

Within foveal vision (0 – 2 degrees); Requiring eye movement (2 – 30 degrees); Requiring head movement (30+ degrees).

Where foveal vision is the area viewed by the fovea of the eye (near the centre of the retina) and is the area responsible for sharp central vision. Obviously the further apart data that has to be gathered from displays the more effort is required. Martin-Emerson et al [1992] analyzed visual angle separations and found a significant increase in event response time and tracking error for separations greater than

Page 21

6.4 degrees, with no performance decrements in either response time or tracking for visual angles below 6.4 degrees. Andre et al [1993] found a linear increase in tracking error for increasing visual angle, with a large drop-off in performance in the head field (>56 degrees). Expectancy: Defined by Wickens1 et al [2003] to be allocation of attention to be proportional to the event expectancy. Value: Carbonell et al [1966] described this as the impact of expected value, or the importance of an information channel multiplied by the operator’s expectancy that something will occur in that channel. 2.7.2.3

Predator HDD:

The Head-Down-Display (HDD) on the Predator also does not escape criticism. Tvaryanas [2004] identifies failings of the Predator HDD including:

• • • •

Too many levels of pages to manoeuvre through to access information; Unintuitive manner of information display; Critical commands were unprotected or un-emphasized; Operational ranges of values were inconsistent within the display.

The lack of protection for critical commands was a key feature in one mishap of Predator where the internal Random Access Memory (RAM) of the aircraft was erased during a flight. 2.7.2.4

Predator Keyboard Functions

Hoffman [2004] identifies that the function keystrokes to control lights are almost the same as to cut engine, according to Pedersen [2006] the keys are next to each other. This is definitely a hazard, having what is essentially a normal function to switch the lights on and off in close proximity to the engine kill, which is effectively the self destruct button, is a fundamental human factors error. 2.7.2.5

Predator Alerts and Alarms

Tvaryanas [2004] identifies the following deficiencies of Predator alerts and alarms:

• • • • •

Alerts do not command attention; Audio warnings were insufficient or absent; Information provided was inadequate or poorly prioritized; Information was invalid; Data that needs to be compared is not always co-located on the same display page.

Alarms are a fundamental system safeguard to alert the UAVp to problems in the system that needs his attention. In the past there has been the problem of alarm overload with the pilot being inundated with multiple alarms of varying severity. Billings [1996] identifies a 1991 incident report that due to a fire the alert system reported one after another alert messages, 42 in total and also 12 caution / warning indications. One problem was the crew were being inundated with alerts, each reporting a specific symptom each supposedly unconnected, without any prioritisation. The main problem was that nothing identified to the crew that the cause of the messages they were getting was a fire. Predator, it would seem from the reports has an alert system that is totally ineffectual in both raising the alarm and prioritising. Just as bad is providing invalid information. Nelson et al [2006] identifies Automation bias – over trust and under trust:

•

Over trust: ‘Automation complacency’ – on highly reliable system operator believes the system so occasional malfunctions go un-noticed;

•

Under trust: Warnings or alerts are ignored or switched off as seen as a nuisance of excessive false alarms.

Page 22

In this case Predator falls into the second case under trust, if the system is providing incorrect data it s not going to be believed. 2.7.2.6

Automation

Predator has an autopilot so the pilot does not have to continually fly UAV throughout the whole mission. There is however, what could be called basic/fundamental design flaws with the autopilot sub-system. Tvaryanas [2004] identifies the following problems with the Predator autopilot:

• •

There is no indication on the HUD of the status of the autopilot;

•

The UAVp must navigate through four separate menus on the HDD to deactivate the autopilot. This requires approximately 7 sec on average to accomplish;

•

Autopilot functionality does not fully consider the capabilities of the aircraft, which results in the commanding of extreme manoeuvres (unusual attitudes) and the possible overstressing of the aircraft by the autopilot;

•

Autopilot functionality does not conform to Air Force standards, using pitch to adjust airspeed instead of power. This could result in the pilot not being fully aware of what changes were being made by the autopilot during manoeuvring.

The flight controls cannot control the aircraft while the autopilot is engaged (i.e., no override capability);

If this autopilot was intended for a manned aircraft, it wouldn’t and shouldn’t have got further than the preliminary design stage. How it got on a UAV of any kind is surprising. Tvaryanas [2004] comments regarding the ability of the UAVp to erase Predator’s internal RAM in-flight, suggests there is a relatively ad hoc software development process occurring for these systems. The design problems with the autopilot bare this out. Another automation problem identified is with Shadow but is not of the same magnitude as Predator although does show a lack of forethought. To land Shadow, the UAVp passes control over to the landing system, called the Tactical Automated Landing System (TALS). Williams [2004] notes that the CS crew have no visual or sensor input from sensors onboard Shadow to know when it has landed. The UAVp is dependent on external observer to tell him when UAV has landed so he can cut the engine. 2.7.2.7

Ergonomics

“Ergonomics is generally accepted to mean fitting the person to the job and fitting the job to the person”, Ergonomics Society [ES, 2003]. A good ergonomic design aims to minimise the UAVp physical fatigue by design. The photograph shows a UAVp using a Predator CS, note how the UAVp is holding the controls, not by the grips but by the connecting storks. If he were holding the grips then his arms would be in unsupported causing fatigue if held for an extended periods. Photo: [Pedersen, 2006].

The photograph shows Elbit Systems’ CS and shows good ergonomic design by supporting the UAVp’s arm while holding the control grip. Photo: [Goldfinger, 2006].

Page 23

2.7.2.8

The Future

As noted previously the UAVp in the CS is in sensory isolation. Various researchers e.g. McCarley et al [2004], Calhoun et al [2006], Wilson [2002] have looked at different ways the UAVp can be helped to over come this sensory isolation and also methods of improving /enhancing the CS HCI. For instance Calhoun [2006] and McCarley [2004] have shown interfaces such as synthetic augmented views to increase situational awareness and also speech based input to ease UAVp input of commands have been shown to be successful. Other interfaces such as haptic (touch) input and head mounted displays either provided minimal improvement or an adverse affect on the task being executed by the crew member. 2.7.3

UAV Accidents

The US Army [1994] identifies the causes of accidents and categorise them as human, material or environmental factors. Human causal factors relate to human errors. Material causes being the result of equipment failure and damage as a result of design flaws, component or system failure etc such that the system becomes inoperable. Environmental factors include noise, illumination, and weather conditions (e.g., precipitation, temperature, humidity, pressure, wind, and lightning, etc.), which can adversely affect performance. A study by the Department of Defence [DoD, 2001] put human error as a causal factor in 20% of all UAV accidents. Williams [2004] identifies for various UAVs, the types of accidents and what percent of the accidents can be put to the various causes. For example Williams [2004] shows that for Predator accidents: 67% were Human Factors (HF) issues, 42% Aircraft issues and 17% maintenance issues. Of HF issues 75% procedural errors, 25% display design errors, 13% Landing errors and 13% Alerts & Alarms. Many accidents can be categorised under more than one heading. For example missing a step from a checklist is a procedural error but can also be classed as a display design error. Each of the UAV accidents noted below has been taken from Williams [2004] except where noted otherwise. Williams [2004] correlates the accidents to each of the particular UAV examined. 2.7.3.1

Piloting errors

Both the Hunter and Pioneer systems use an EP to takeoff and land the UAV, while the IP in the CS controls the in-flight segment. The EP effectively uses a hobbyist’s transmitter which uses joysticks to directly control the UAV control surfaces. Williams [2004] provides the follow statistics for the Hunter and Pioneer UAVS:

•

Hunter: 47% of accidents related to HF issues, of these HF related accidents 47% were due to the difficulty experienced by EP during landings and an additional 20% of accidents were due to EP errors during takeoff;

•

Pioneer: 28% of accidents related to HF issues, of these HF related accidents 68% were due to the difficulty experienced by EP during landings and an additional 10% of accidents were due to EP errors during takeoff.

These results are not unsurprising considering the difficulty the EP has landing the UAV by line of sight. From the author’s personal experience of flying model helicopters, flying a UAV, be it a helicopter or an aeroplane is difficult to fly towards you. When the UAV is flying towards the UAVp, from this prospective, the joystick controlling the ailerons using aircraft nomenclature to turn the UAV left or right are reversed from when it is being flown away from the UAVp. Or in other words there is an ‘inconsistent mapping between the movement of the joystick and the response of the aircraft’. The failure of a flight control to perform consistently (from the perspective of the pilot) is a violation of the human factors principle of motion compatibility; [McCarley 2005]. This reversal of controls is an issue that an aircraft pilot nor for that matter an IP has to contend with. For a UAVp to take the role of the EP training and practice are required. Not every UAVp may have the aptitude to do it which is costly in terms of training and in the loss of the UAV when it goes wrong. This is one of the reasons why UAVS other than for small UAVS have gone away from depending on an EP to land the UAV. To be able to remove the need for an EP from the UAVS then either an auto takeoff and land system has

Page 24

to be provided or the IP is given visual information and the means to control the UAV to be able to safely takeoff and land. Further discussion of the issues of IP and EP are covered in section 2.7.4. 2.7.3.2

HCI design errors

HCI design errors not only make the UAVS difficult to fly but can also be the root cause of an accident. Examples of where design errors have resulted in an accident are: a. b. c.

Hunter: Autopilot toggled off by ground crew and not reset, no indication to pilot; Shadow: Commands not identified for particular UAV and status of command not shown. See Procedural Error below; Predator: Pilot erased onboard RAM in flight.

In case a, the autopilot was switched off. This was not noticed by the EP nor would be as the EP does not use the autopilot to fly the UAV but directly controls the surfaces via the joystick controller. Only when the UAV was handed over to the IP did the IP find he couldn’t control it via the HCI which used knobs to select altitude, airspeed and heading etc. Hunter does not provide the IP with a stick and pedal interface so had no way of controlling the UAV. In case b, there are procedural, HCI and system design errors. As a result of the first Shadow to crash a second Shadow also crashed. The TALS failed causing the first Shadow to crash. The UAVp sent the command to kill engine, as this first Shadow had a damaged receiver or transmitter and so did not acknowledge the command. The CS was tasked to take over the second Shadow; the displays did not warn the UAVp that there was an unacknowledged / outstanding command – HCI issue. The UAVp didn’t reset the system for the second Shadow – Procedural Issue. The second Shadow responded to the outstanding kill engine intended for the first Shadow resulting in the second crash – system issue. It’s a systems issue in that if commands had been tagged with the id (i.e. the tail number) of the UAV it was intended for, then the second Shadow would have ignored the unintended kill engine command and continued to land instead of crashing. In case c, a bad HCI design allowed the UAVp to inadvertently activate a program that erased Predator’s internal RAM while in-flight via the Head Down Display. This is a systems error; this in-flight program should have been inaccessible to the UAVp. 2.7.3.3

Procedural errors

Manning et al [2004] explores and analyses the many causes of human error in accidents and the reasons for them. “Pilot error” is often given as the reason for an accident. However, Manning [2004] notes human error almost always has underlying causes, which are often the real reason for an accident. These causes can include high (or low) workload, fatigue, poor SA, inadequate training, lack of crew coordination and poor ergonomic design. One or all of these causes can degrade performance, leading to accidents. Pilot errors can be slips/lapses, mistakes, errors of misconception or decision errors. There are also violations, which Manning [2004] describes as wilful errors; examples include violating training rules, performing an over aggressive manoeuvre and intentionally exceeding mission constraints. The different types of errors as described by the University of York Human Factor Engineering Course are:

• • • • • • •

Slips / Lapses: Action that occurs is not as intended; Mistake: Action that occurs was intended but didn’t succeed in meeting goal; Error of Omission: Omits task step(s) or entire task; Error of Commission: Substitutes an incorrect action for correct action; Error of Sequence: Correct actions in the wrong order; Quantitative error: Too much or too little; Time error: Too early or too late.

Page 25

Manning [2004] describes the following errors:

•

Decision errors: Using the wrong procedure, misdiagnosing an emergency, and performing an incorrect action;

•

Perceptual errors: Errors due to the presence of visual illusions and spatial disorientation.

The following procedural accidents are identified by Williams [2004]: a. b. c. d.

e.

Hunter: Pilot in command is overridden by other personnel; Hunter: Improper start of backup CS interferes with primary data link; Hunter: EP had not correctly set up the controls to take over from IP to land the Hunter UAV; Shadow: TALS (autopilot) failed causing first UAV to crash, UAVp sends message to kill engine, command not acknowledged as first UAV damaged. CS tasked to take second UAV but didn’t clear command. Second UAV cuts engine as instructed and crashes. Also see section 2.7.3.2 HCI Design b, above; Predator: Failure to complete all checklist actions in proper order on handover resulting in turn off of engine and stability augmentation system resulting in uncommanded dive and crash.

In case a, the pilot in-command’s authority was superseded by other personnel in the area. This violates the principle that the pilot of the aircraft has the final decision and resulted in the loss of the Hunter UAV. In case b, this is a time error in that the correct actions were made but were carried out at an inappropriate time (too early). In case c, this is an error of omission, the EP failed to correctly set up the controls. In case d, this is both an HCI design error and a procedural error. The HCI design error aspect is covered previously in HCI Design Errors b/ above. The procedural aspect is again an error of omission in that the procedure to reset the system was not carried out before the control of the second Hunter UAV was taken on. In case e, is both an error omission and of sequence in that the actions were not completed nor completed in the correct sequence. This resulted in killing the engine which on its own may have been recoverable but also turned off the stability augmentation. Williams [2006] noted that when an Altair, (a Predator derivative) due to a checklist error by the crew also killed the engine but were able to restart it in mid-air. 2.7.3.4

Automation errors

To overcome the need for a UAVp to fly the UAV, systems such as Global Hawk automate the UAV. This supposedly removes the problems of having an EP taking off and landing the UAV and the associated HF errors as noted above, also having to provide an IP with flight instrumentation plus a visual display that provides a field of view better than that provided for Predator. One approach is to Automate the UAVS so the UAVp controls the outer loop (supervisory control) providing the waypoints to fly to at what altitude and airspeed, while the UAV looks after the inner stability loop. Global Hawk is totally automated; all aspects of a mission are programmed from takeoff to landing and are loaded prior to the flight. Williams [2004] notes that it takes 270 days to program a Global Hawk mission. Whether the system is fully automated / programmed as per Global Hawk or by supervisory control such as Hunter, when things go wrong the UAVp does not have the HCI to be able to override the automated system and take control of the situation.

Page 26

Case 1: Global Hawk Global Hawk suffered an in-flight failure so made an unscheduled landing at alternate airport. Global Hawk was commanded to start taxiing. The mission planning software had been programmed to set the descent speed to 155 knots. Any time that two consecutive waypoints varied in altitude by more than a specified amount, the software set the speed to be established between those waypoints at 155 knots. What was not anticipated by the software developers however were two consecutive taxi waypoints on the ground differing by more than the specified amount in altitude. The software, performing as designed, had inserted an airspeed of 155 knots between the waypoints. The aircraft accelerated to the point where it was unable to negotiate a turn and ran off of the runway, collapsing the nose gear and causing extensive damage to the aircraft. [Williams, 2006]. Case 2: Fire Scout [Williams, 2006] Fire Scout is a Navy-owned Vertical Takeoff and Landing Tactical Unmanned Aerial Vehicle (VTUAV) (a.k.a. a helicopter). The Fire Scout sustained damage through human error during ground handling damaging its antennas for the radar altimeter making it miss read. Fire Scout was reading 2ft when it was at 500ft. It was instructed to land, it descended the 2ft it thought it was off the ground (actually 498ft above ground level). The Control system interpreted this as Fire Scout was on the ground, did what it was programmed to do and cut the engine causing the aircraft to descend very quickly and crash. [Williams, 2006]. Williams [2006] makes the observation that “developers of the automation were unable to predict all possible contingencies. This led to situations in which the automation performed as designed but not as anticipated”. Both Global Hawk and Fire Scout did what they were programmed to do. Both are good examples of systematic errors, which when the right conditions manifested themselves resulted in an accident. As both these systems were automated there was nothing the UAVp could do, no alternative way to take over in case of emergency. In the case of global hawk, if the system had direct UAVp control could have immediately cut the engine as soon as it started to throttle up when it should have been equivalent to ‘ticking over’ to taxi. In case 2/ Fire Scout, 500 ft is a long way to drop it would seem, however this distance would if a UAVp could have taken control had a chance of auto-rotating the UAV, something that all, even manned helicopters can do to control the decent. In an autorotation, as the helicopter descends air passing over the blades causes them to rotate. The energy stored in the rotating blades is then used as the helicopter nears the ground, if executed correctly to slow the helicopter down to safely land with no damage done. To do this requires height and / or speed to get the blades rotating, in the case of Fire Scout, height to give him chance to recognise what was happening and it were possible to take over and auto-rotate so 500 ft is better than 50 ft. A crash from 500 ft or 50 ft is still going to cause extensive damage to the aircraft. 2.7.4

Internal Pilots vs. External Pilots

For UAV Systems to become commercially viable they will have to operate out of commercial airfields, so having an EP as part of a commercial UAV System would not seem practical. UAV Systems Airworthiness Requirements (USAR) has been compiled by the DGA [2005] (Délégation générale pour l’Armement) – French Ministry of Defence procurement agency albeit for military UAVS. The airworthiness requirements were based on EASA Certification Specifications CS-23 for Normal, Utility, Aerobatic, and Commuter Category Aeroplanes. USAR DGA [2005] has the following requirement with particular reference to 11b: USAR.11 UAV crew (a) A UAV crew is made up of one or several qualified people in charge of monitoring the flight path and flight status of the UAV in the remote control station considering USAR.1 (d).

Page 27

(b) A UAV System that needs for normal operation the presence of an external pilot that directly controls the UAV using a control box in sight of the air vehicle is not compliant with USAR. [DGA, 2005] However USAR DGA [2005] is to be superseded by USAR STANAG 4671 Edition 1 NATO1 [2007], (currently in draft form) which steps away from this issue and no longer covers requirements for piloting from an external or internal control box. Several UAVS such as Hunter and Pioneer use External Pilots to takeoff and land. As noted in 2.7.3.1 the roll controls for the EP operate in the opposite direction when the UAV is flying towards the EP than when it is flying away. William [2004] notes this as a difficult skill to learn. This is something an IP does not have to contend with. Because of this difficulty an EP requires extra training to gain this skill. Human factors accidents for the various UAVS are covered in section 2.7.3 UAV Accidents. The analysis of UAV accidents is covered by Williams [2004]. A summary of this data is shown below: Service

Accidents

Dates

Total No UAV flights between dates

Army

74

1989 – 2004

Not provided

Navy

239

1986 – 2002

Not provided

Air Force

15

1999 – 2003

Not provided

Table 2-3; UAV Accidents per US Armed Services The results below for Hunter and Pioneer systems are assumed to be for the periods 1989 to 2004 and 1988 to 2002 respectively from Table 2-3. The total number of flights over these periods is unknown therefore the probability of an accident per flight is unknown, so a proper comparison cannot be made. UAV

Takeoff / Landing accidents

Total HF Accidents

Army – Hunter

7 Landing 3 Takeoff

15

Navy – Pioneer

46 Landing 7 Takeoff

68 Table 2-4; UAV EP Takeoff / Landing Accidents

Automating landing for Shadow did eliminate EP related accidents however due to an imperfect landing system did not eliminate landing accidents altogether. The number of flights this was over is unknown. UAV

Takeoff / Landing accidents

Army – Shadow – Auto land (TALS)

6 Landing 0 Launcher T/O Table 2-5; UAV Automated Takeoff / Landing Accidents

If a commercial operation chose a UAVS that required an EP to takeoff and land some impracticalities / operating restrictions are associated with this. Any airfield that the UAV can fly to, or be diverted to, has to have an EP on standby who is licensed and qualified to land the UAV. If through even a minor failure the UAV cannot make the designated airfield or an airfield where an EP is available then there is no alternative but to ditch the UAV. Emergency landing (ditching) areas must always be designated as part of the flight plan that can be glided to in an emergency. These areas need to be set aside where the public are excluded so there will be no lives lost if a UAV has to be brought down at short notice. However a very expensive piece of hardware will

Page 28

have been lost due to possibly something minor. In addition, another loss of a UAV makes the statistics look bad and does nothing for public confidence in the burgeoning UAV industry. There is also the practicality and hazard of having an EP on the side of an active runway even in a portable ‘control tower’ while bringing the UAV into land. There is also the complication that if the landing has to be aborted for some reason and a go-around executed then the EP has to be able to handover the UAV back to the IP at short notice with the UAV relatively close to the ground. Once the UAV has landed, unless the UAV has stopped fairly close to the EP and can taxi in visual range of the EP then a ground crew is needed to retrieve the UAV from the active runway / taxiway. For an active commercial airport would not be viable for a ground crew to go out on to the active runway / taxi way to retrieve a UAV when the next commercial flight is on its way in. There is nothing wrong in having an EP as an expert, flying the UAV directly via his control box during the training of IPs or during test and development of a UAVS as the last line of defence to take over if things are going wrong. However providing the IP the means of landing the UAV by either improving the visibility and control of the IP or a reliable automatic landing system enabling the UAV to land at any airfield would be a better solution. 2.7.5

Latency & Need for Automation

For a UAVp to directly control a UAV a high bandwidth, low latency data link is required. It is well understood in control engineering that by taking a well behaved system and introducing ever increasing latency into the feedback loop the system will become less stable until it reaches a point where it becomes unstable. In the UAVS there are two paths where latency can be induced, in the UAVp’s control inputs via the uplink to the UAV and the response of the UAV via the down link to the UAVp’s instruments and video display. This doubles the effect of the latency in the control loop. Mouloua et al [2001] describe the affect as creating temporal and spatial uncertainty for UAVps. As the frequency and immediacy of transmitted images decreases, the UAVp’s ability to directly control the vehicle diminishes. At some point, the operator’s delayed responses become so inappropriate that it is impractical to control the vehicle directly. This is just as true for the payload /sensor controller using a joystick to manoeuvre a camera. Latency of 1 or more seconds in a system will be introduced if satellite communications are used to control the UAV, noticeable latency could also be introduced if to provide the data link an intermediate UAV was used to provide the control link to the distant BLOS UAV. Oron-Gilad et al [2006] describes the effect of delays:

• • •

Compensatory tracking performance degrades with a latency of about 300 ms;

•

Over actuation is common when system delay is unpredictable.

When latency is over 1 s, UAVp switches to a ‘move and wait’ control strategy; Placement task performance degrades when standard deviation of latency is above 82ms;

In controlling an aircraft there are inner and outer control loops. The inner loop is responsible for the stability of the aircraft and ensuring the aircraft is following the desired heading (which way the aircraft in pointing) and altitude. The outer loop is responsible for supervisory control. When the UAVp is solely responsible for both the inner and outer loop as in a Remotely Piloted Vehicle (RPV) such as a hobbyist’s model plane or Predator, as latency increases the UAV becomes more difficult to control. In the event of loss of the data link, the UAVp is no longer in control of the UAV leading to the loss of the UAV with a high probability of an unacceptable catastrophic event. Going to the other extreme is to provide fully automated control. This cuts the UAVp out of both the inner and outer control loops. He is solely there to monitor what is effectively a cruise missile. The UAVp has no way to intervene even to implement ATC instructions.

Page 29

The UAVp is totally dependent on the ATC keeping other traffic away from this UAV which is unacceptable in un-segregated airspace. Taking one step back from fully automated control is automated control allowing the UAVp to update the outer loop control of the UAV. The UAV autonomously controls inner loop, leaving the UAVp with only a supervisory / monitoring role allowing the UAV’s route to be updated due to ATC instructions or worsening weather conditions by sending updates to UAV’s programmed mission. This takes time to make the change to the mission and then send the changes up to the UAV, so any ATC instruction cannot be instantly executed but requires time to implement. An advantage of this level of automation is that latency is not a problem as the UAV is autonomous and looks after it’s stability it’s self, also if the data link should be lost, it has it’s instructions as part of it’s mission programming on what to do in that situation. The role of the UAVp is still mainly one of monitoring the UAV. One of the things humans do well that machines do not is to resolve unplanned situations by taking the necessary steps to work around the problem. One way of taking the UAVp out of the inner loop control and control of the outer loop is by compiling an update and transmitting it up to the UAV. This means that if something goes wrong the UAVp has little if any opportunity to rescue the situation. The ideal solution is to take a mixed or Hybrid Control solution allowing the UAVp to select a level of automation the UAV is to be under. 2.7.5.1

Levels of Automation

The PACT framework (Pilot Authorization and Control of Tasks) was developed by Taylor et al [2001] and Bonner et al [2000] for the fast jet environment but can just as easily applied to UAVs. This provides the UAVp with 6 levels (0 – 5) of control from full control to UAV autonomy.

Figure 2-2; PACT Framework Giving the UAVp the ability to select the level of autonomous control allows the UAVp to monitor the system and if a failure mode, a situation or the environment the UAV is flying through changes the UAVp can select a level of control authority that is appropriate. For instance the UAV asks for permission for action (PACT Level 3) or taking action unless it is revoked within a limit by the UAVp (PACT Level 4), Cummings et al [2006] describes this as Management By Consent (MBC) or Management By Exception (MBE) respectively. 2.7.5.2

Automation

Automation of a UAVS brings its advantages including being able to offload control of the UAV and in the process overcome the problems of data link latency. A study by Dixon et al [2003] found that allocation of flight control to an autopilot freed attentional resources and improved performance on a concurrent visual target and system fault detection tasks. However with the advantages come the potential pitfalls:

Page 30

“It is apparent that rather than eliminating human error; some of the new technology has simply resulted in creation of entirely new opportunities and entirely new categories of human error to occur” [Lauber, 1987]. Ciavaralli [2001] provides a Summary of Automation Problems:

• • • • • • •

Requires increased monitoring / watch keeping;

•

Minor input errors (i.e. mode error) with serious consequences.

Requires crew to spend more “head down” time; Induces complacency and dependency on automated system; May induce some loss of situation awareness; May result in an erosion of physical flying skills/proficiency; Automation Complacency, failure to monitor progress of flight; Diminished failure detection probability and possible increase in response error recovery;

The summary above is aimed at the automation of aircraft cockpits not UAV Control Stations but is still applicable. In Ciavaralli’s summary above “Induces complacency and dependency on automated system” is also noted by Nelson [2006] as “Automation bias”, as not only “over trust” but also as “under trust” as noted in 2.7.2.5. Ciavaralli’s [2001] summary identifies “Minor input errors (mode error)” this is also known as ‘Mode Confusion’. One such pitfall of highly automated systems is pilot Mode Confusion. Where the UAVp interacts with highly automated flight systems, if the UAVp does not hold a good mental model of what mode the system is in during each phase of the flight there is a high probability of mistakenly believing that the system is one mode when it is in fact in another. This is compounded when the display for one mode looks distinctly like another and there is little to inform the UAVp which mode the system is in. The consequences of mode confusion have resulted in numerous catastrophic airline accidents during the 1990’s when a pilot has entered the wrong data for the mode the system was in. The following infamous accident of Air Inter Flight 148 [Wikipedia, 2008] / [Cummings, 2006] is identified as an example of mode confusion:

•

On 20th January 1992, scheduled airline flight Air Inter Flight 148 crashed into the Vosges Mountains while circling to land at Strasbourg Airport. Flight 148 crash is believed to be caused by the pilots’ unfamiliarity with the Airbus A320 sophisticated computer system. It is believed the cause of the crash is that the pilots inadvertently left the autopilot in vertical speed mode (instead of the intended flight path angle mode) and then entered ‘3.3’ for 3.3o descent angle. This was actually interpreted by the flight computer as a rate of decent of 3,300 feet/minute.

This was something the system designers had not foreseen and so had not guarded against. 2.7.6

Control of Multiple UAVs

For a UAVp to fly multiple UAVs the following must be considered:

• • • • • 2.7.6.1

Is the CS capable of controlling and monitoring a number of UAVs; Is the environment the UAVs are to operate in suitable; Are the UAVs suitable; Are the tasks the UAV are executing suitable; Is the UAVp workload going to spiral out of control. CS Capabilities

In a CS that controls a single UAV, there is no confusion as the controls, the displays and alarms are all for the one UAV. However when controlling / monitoring more than one UAV

Page 31

there is the hazard that a UAVp controlling a different UAV to the one he believes he is controlling resulting in the loss of a UAV. Alarms also must not be a source of confusion for the UAVp. The UAV, the alarm or other warning is being raised against must be easily identifiable. STANAG 4671 Edition 1 (draft) NATO1 [2007] has two specific requirements concerning the control of multiple UAV; these are UAV Systems Airworthiness Requirements (USAR).1883 and 1887, 1883 also makes reference to USAR.1704. The text of these requirements are as follows: USAR.1883. Command and control of multiple UAV: Where a UCS is designed to command and control multiple UAV, the following requirements apply: a.

The minimum UAV crew must be established so that it is sufficient for safe operation of each vehicle in compliance with USAR.1704 and emergency conditions; b. The UAV data shall be displayed in the UCS in a manner that prevents confusion and inadvertent operation; c. The UAV controls must be available to the UAV crew for each UAV of which it has command and control in a manner that prevents confusion and inadvertent operation; d. All indicators and warnings must be available to the UAV crew for each UAV in a manner that prevents confusion and inadvertent operation. USAR.1887 Multiple UAV monitoring: Where the UCS is designed to monitor multiple UAV, there must be a means to clearly indicate to the UAV crew the UAV over which it has command and control. USAR.1704 Minimum UAV crew: The minimum UAV crew must be established so that it is sufficient for safe operation considering: a.

The workload on individual UAV crew members taking into account at least the following tasks: 1. Operation and monitoring of all essential UAV System elements; 2. Navigation; 3. Flight path control; 4. Communications; 5. Compliance with airspace, air traffic, and air traffic control requirements; 6. Command decisions including Crew resource management.

b. The accessibility and ease of operation of necessary controls. With the commercial goal to have 1 UAVp to many UAV, STANAG USAR 1883 (b)(d) and 1887 should be able to be met by a CS without any problems. To meet USAR 1883(c) for a single UAVp then the CS controls must be multiplexed so the UAV selected is clearly identified to the UAVp before any control input is made by the UAVp. 1883 (a) Safe Operation is covered below under Task Suitability and also UAVp Workload. 2.7.6.2

Operating Environment Suitability

What does not seem to be clearly addressed by the USAR requirements is that the UAVp must be able maintain, via the CS, SA of where the UAVs are relative to each other, the terrain and if there is any other traffic in the area. The result of not knowing where other UAVs not under your control are is shown by Dury [2006] who identified a multi-UAV, multioperator night flight as an exercise where two Shadow UAVs were flown in the same area. Each Shadow CS can only control and know where it’s own UAV is. This led to much confusion with the crew from each CS shouting/running across the room multiple times to avoid in-flight and landing collisions. Neither UAVp had the spatial relationships, the progress, the activity of each of the UAVs and that of any other UAV that, if it were not segregated airspace could also be operating in the area.

Page 32

McCarley [2005] identifies some research that has demonstrated the possibility of single pilot-multiple UAV (1-to-many). However the research pre-supposes three circumstances: 1. 2. 3.

Closely coordinated and correlated activities among the multiple UAVs. [Cummings, 2004]; Operation in a disturbance free (closed) environment, such as very high altitudes; High levels of reliable automation. [Dixon, 2004].

McCarley [2005] adds that when any of these three characteristics are not in force, and, in particular, when one UAV enters a failure mode, the ability of the pilot to monitor others in a 1-to-many configuration is severely compromised. Having closely co-ordinated UAV activities checked for confliction in a closed, segregated environment is ideal. Could this restriction be relaxed for a low traffic area and all traffic operating in the area had reliable sense and avoid capabilities and knew to expect UAV activity in the area? 2.7.6.3

UAV Suitability

Considering the UAV being operated it is imperative that the UAVs are reliable. However the consequences of a failure are dependent on the UAVp task being executed and by how much the failure increased the UAVp’s workload. UAVp tasks and workload are further explored later in this section. On the assumption that the UAVp’s normal task is to monitor the UAV so his workload is not high, he would be expected to cope with the failure of one UAV. However a failure of a second system in the same mission would leave the UAVp not able to cope especially if the UAVp is also required to take control of the second UAV which of course he would be unable to do. Such scenarios must be shown to be improbable. In the case of loss of any of the data links then each of the UAVs are to have defined emergency procedures. 2.7.6.4

Task Suitability

For certain tasks the UAV can execute such as searching for a target requires both the skills of the UAVp and that of a camera controller as covered in section 2.6 Situational Awareness. The cognitive workload of the UAVp is taken up by monitoring both the UAV systems and maintaining SA. The camera controller is there to execute the search. There are other tasks however where the tasks for the UAV is that of station keeping to provide a high altitude communications platform which provides a relay link for another UAV. Under these circumstances then the UAVp would have little to do. However there is another factor that must be considered, that is the area the UAV are sitting in. The UAVp has to have an overall SA of where each UAV is relative to each other and any traffic in the areas they are operating in and there is no confliction between them. 2.7.6.5

UAVp Workload

The number of UAV that one UAVp can be in control of is covered by STANAG 4671 NATO1 [2007] USAR.1883 Command and control of multiple UAV. a.

The minimum UAV crew must be established so that it is sufficient for safe operation of each vehicle in compliance with USAR.1704 and emergency conditions. Where ‘USAR.1704 Minimum UAV Crew’, is shown at the beginning of this section, which provides a list of the different tasks that need to executed for the safe but normal operation of the UAVS. When things go wrong showing the workload placed on the UAVp is not going to spiral beyond what the UAVp can handle will have to be shown. How much the UAVp’s workload is going to increase by is dependent on the nature of the emergency condition. Wikens1 [2003] identifies three workload models these are

• • •

Single Chanel Theory; Single Resource Theory; Multiple Resource Theory.

Page 33

Single Chanel Theory concludes that the UAVp can only execute one task at a time. Single Resource Theory concludes that cognitive resource is the limitation and allows for parallel processing / concurrent tasks where resources allocated to different tasks. Multiple Resource Theory concludes tasks that use different resources can be performed more efficiently than two tasks using the same resource such as driving and listening to the radio is easier than driving while reading the same information in print. The results of the experiments documented by Wikens1 [2003] leads to the conclusion that different aspects of all three theories account for some part of the data generated. So dependent on what type and the number of tasks that have to be executed by the UAVp to handle the emergency governs how well or overloaded the UAVp is in doing so. What of the future, when UAV become autonomous and with proven good reliability both DeGarmo [2004] and DO-304 RTCA [2007] believe that the duties of a UAVp controlling multiple UAV will be akin to that of an air traffic controller than that of a UAVp controlling a single UAV. That is DO-304 RTCA [2007] adds with the proviso that as long as there is backup for certain situations. 2.7.7

Interoperability

Up to now UAV Systems were assumed to be bespoke not only in how the UAVp interfaced with the CS but also how the CS communicated with the UAV. Communications in terms of the types of data links but also the communication protocols and message formats used by these data links. For this reason operations involving UAVs were a problem for NATO as they had to be nation centric as only the nation owning the UAV could control it. Also the information gathered by the UAV had to be transmitted back to the CS then converted before it could be disseminated to the people who needed the information. To get over this problem NATO proposed ‘Network Centric Operations’; also known as Network Centric Warfare concept, to enable not only direct sharing of data but also the collaboration of the use of UAVs between nations. NATO developed and is continuing to develop STANAG 4586: Standard Interfaces of UAV Control System (UCS) for NATO UAV Interoperability NATO2 [2007]. STANAG 4586 defines these standard interfaces. Although STANAG 4586 a military standard, there is no reason why it should not be adopted to provide interoperability for civil UAVS. There are some aspects of these standard interface messages intended specifically for the military such as the control of weapons that are of course of no interest. However the other messages specified are just as applicable to civil UAVS as they are to military UAVS. The diagram below is from STANAG 4586 NATO2 [2007] identifying the system but slightly modified to highlight the two main interfaces that this standard defines. These are the Data Link Interface (DLI) and the Command and Control Interface (CCI).

Page 34

AV LAUNCH & RECOVERY SYSTEM

UCS

VSM DLI

CORE UCS

HCI

UAV Pilot

CCI

CCI

CCISM

C4I SYSTEM

Where: C4I CCI CCISM UCS DLI HCI VSM

C4I SYSTEM

Command, Control, Communications, Computers and Intelligence Command and Control Interface Command and Control Interface Specific Module UAV Control System Data Link Interface Human Computer Interface Vehicle Specific Module Figure 2-3; STANAG 4586 Interfaces

DLI is provided by a defined set of messages used to pass UAV and payload control data from the CS (UCS in the diagram) and also pass status data from the UAV and its payload back. CCI is provided by a defined set of messages used to pass data between the CS and the Command, Control, Communications, Computers and Intelligence (C4I) in military terms, for civil operations the control centre. 2.7.7.1

Vehicle Specific Module

The Vehicle Specific Module (VSM) provides the UAV specific and real time functionality. The VSM is equivalent to the Hardware Abstraction Layer (HAL) of a computer operating system that provides a hardware specific interface for the operating system functions. In this case the VSM provides a hardware interface to a specific UAV or type of UAV for the DLI messages. STANAG 4586 [NATO2, 2007] identifies the VSM as providing:

•

Unique / proprietary communication protocols, interface timing, and data formats that the respective UAV require;

•

any necessary “translation” of the DLI protocols and message formats to the unique air vehicle requirements.

Since the VSM may be unique to each air vehicle, the air vehicle manufacturer / Design Organisation would generally provide it. The VSM function can be hosted on the CS or UAV. However if implemented as part of the UAV, as noted by STANAG 4586 NATO2 [2007] then specific functions such as Launch and Recovery (L&R) and unique data link functions will, due to latency and bandwidth considerations will need to be hosted in the CS. In addition to L&R if the UAVp controls the UAV so is responsible for the inner loop control, then this would be implemented by the VSM as shown by the dashed line in Figure 2-3 above.

Page 35

2.7.7.2

Command and Control Interface Specific Module

As seen with the DLI requiring the VSM to implement proprietary or non-STANAG 4586 interfaces so too with CCI. In this case Command and Control Interface Specific Module (CCISM) will be required to communicate with systems which are not compatible with STANAG 4586 standards and protocols. 2.7.7.3

Areas not covered by STANAG 4586

STANAG 4586 only lays down the mandatory functional requirements that the CS must comply with. How the functions and displays are implemented is up to the Design Organisation. There are no design requirements on how the HCI is to be implemented so the HCI can still be implemented with the problems noted in section 2.7.2 CS Human Computer Interface Design. 2.8

Summary

Section 2 has covered several areas concerned with UAV CSs. Airworthiness The Initially CAP 722 was examined as an alternative to CS airworthiness certification but was discounted for other than flying small UAVs as it placed impractical restrictions on commercial operations. With this established whether the military or civil airworthiness model was to be followed was addressed. Although the use of military safety targets was considered to be easier to implement, compatibility with manned civil aviation airworthiness certification for UAVS is seen as the way forward. UAVp Licensing Airworthiness includes having properly trained and licensed personnel. To fly for gain a pilot of a manned aircraft requires at least a CPL. Currently there is no equivalent commercial UAVp licence i.e. a UAV CPL. UAVp Training As there is no UAV CPL, there is no formal training defined for this licence. The basic classroom syllabus for UAVps which would include subjects such as air law etc would be the same as for the pilot of a manned aircraft but the syllabus will need to be tailored to include subjects applicable to UAV flight. Due to the types of CS, the roles the UAVp can take i.e. IP or EP and the phases of flight they are responsible for training requirements will have to be flexible. An integral part of the manned CPL training is the cross country flight requirement for a cross country flight totalling 540km with two full stop landings. Unless the UAV is controlled via satellite then the UAVp is limited by LOS communications requiring a tortuous route to enable this distance to be achieved. In addition a UAVp who flies a CS as an IP requiring an EP to land the UAV would not meet the criteria of the cross country flight test. This must be addressed when the requirements for a UAVp CPL are considered. As part of a manned aircraft CPL an IR is usually required allowing the holder to fly in Class A airspace, airways and IFR therefore it would also be expected that it would also be required for a UAVp CPL. To gain an IR under current regulations a pilot has to demonstrate the procedures and fly manoeuvres to high degree of competence. Only a type 1 CS enables a UAVp directly control of the UAV to demonstrate these manoeuvres. The IR must have provisions for CS types 2 and 3 where UAVps do not have manual control of the UAV. Licence Maintenance Pilots of manned aircraft have to ensure there skills are current. For UAV IP who flies a UAV where automatic landing systems are routinely used to land the UAV and the UAVp would be expected to land the UAV if there was a problem. The question was raised of how often should the UAVp routinely take over from the autonomous system and land the UAV or only when flying the simulator.

Page 36

Use of an External Pilot in Commercial Operations There are practical considerations that must be considered for a commercial UAV operation in requiring an EP to land the UAV. If a UAV has to be diverted there must be an EP qualified to land the UAV at the airfield. Alternatively the UAV has to be ditched even for something relatively minor. This is costly in terms of the damage to / loss of the UAV but also makes the statistics look bad and does nothing for public confidence. To be commercially viable UAVS will have to operate out of commercial airfields. It is impractical and hazardous to have an EP on the side of an active runway even in a portable control tower. Once the UAV is on the ground a ground crew is needed to recover the UAV from the active runway. This is also impractical and hazardous. The role for an EP is as an expert flying the UAV directly during training of IPs or during test and development of UAVS as the last line of defence. Control of Multiple UAVs From a commercial prospective it would be ideal to have one UAVp controlling / monitoring several UAVs. In practice several factors have to be considered. The CS must be capable of safely handling multiple UAVs. The operating environment has to be closely coordinated between UAVs operating in a disturbance free (closed) area. The UAVs need to be highly automated and reliable. UAV tasks cannot individually tax the UAVp cognitive workload as the UAVp is there to monitor and keep an overall SA of the UAVs. In an emergency the UAVp workload must not spiral beyond what the UAVp can handle. All the above criteria have to be shown to have been met for an application employing multiple UAVs. Interoperability In a commercial operation flexibility is the key. NATO has developed an interoperability standard, namely STANAG 4586 which provides the required flexibility. Although STANAG 4586 is a military standard this can also be applied to civil UAVS. STANAG 4586 provides the interface via defined messages between the CS and UAV to allow a CS using STANAG 4586 messages to fly a UAV designed interface for this interface even from different manufactures. The STANAG 4586 standard interface messages not only covers UAV control but also payload control. 2.9

Focus for Project Development

The topics covered in section 2 are too wide to carry forward to develop a proposal. The proposal is to apply the SMM Safety Cycle, which is a circular safety framework touched on in section 2.4.3. The aim is as part of this framework to adapt ARP 4761 Safety Assessment Diagram to implement the H/O Requirements and H/O Procedure for a H/O between UAVps as part of the CSs Standard Operating Procedures. The adapted ARP 4761 Safety Assessment Diagram is used to identify the analyses most suited to identify the hazards associated with the UAVp in the CS initially flying the UAV and then handing over the UAV to another UAVp. The results of the analyses are to be the H/O Requirements that must be met when considering a H/O and also a theoretical H/O Procedure, that covers the left side of the diagram. The right side of the ‘V’ shaped adapted ARP 4761 Safety Assessment Diagram covers the testing of the H/O procedure and the integration with other procedures to form the CS’s Standard Operating Procedures required to fly commercially. The right side of the diagram although shown will not be executed, this is further work outside the scope of this report.

The analyses identified and used employ the severity classifications identified by Evans [2006] from both an airworthiness failure condition and an ATM focused separation / collision standpoint.

Page 37

3 UAV Handover Between Control Stations In section 2 the literature survey examined some of the issues concerned with UAV Control Stations. There are limits to how far a UAV can be controlled from a Control Station (CS) due to loss of line of sight or degradation of the data link signal due to distance away the UAV is from the CS. Before this happens control of the UAV should be handed over to another CS. The intent of this section is to examine the issues of handing a UAV from one CS to another. A UAV Hand Over (H/O) is analogous to a relay race. The athletes have to make the baton H/O within a certain distance (the H/O window). With a Make Before Break (MBB) Data Link (D/L) the baton (the UAV) is passed to the receiving athlete and is not let go of until the receiving athlete has a good grip, then the passing athlete can let go for the receiving athlete to run with it. With a Break Before Make (BBM) D/L the baton leaves the passing athlete hands before being caught by the receiving athlete i.e. it’s thrown over. If the receiving athlete has not got a good grip they can throw it back. However if the baton is dropped the race is over. In handing over a UAV from one CS to another, there are interactive steps of a procedure that both the CS that is handing over the UAV, which will be referred to as CS1 and the CS receiving the UAV referred to as CS2 have to follow. In handing over the UAV between the CSs there are hazards and therefore safety risks associated with the hazards. As part of a safety process, the intent is to identify the hazards involved with the handover of a UAV between two control stations and provide mitigation to reduce the risk. 3.1

Scope of Assessment

The scope of the assessment is to cover the H/O of control and therefore responsibility for the UAV from the CS1 UAVp to the CS2 UAVp. Handover of payload control between CSs or even to or between outside agencies is considered to be a separate procedure not executed by the UAVp. In addition, the loss of payload control would probably mean the end of the mission but it is assumed to have no effect on the airworthiness of the UAV carrying the payload. To clarify this statement, where the payload is a communications link to extend the range of another UAV, loss of payload control would not affect the UAV carrying the payload but would be a safety issue for the UAV being controlled. For these reasons payload H/O is not considered as part of this project. Once the H/O Procedure is generated it would be assessed from a Human Factors (HF) prospective. This is considered to be out of scope for this project. Another area which is out of scope of this report is that of security in terms of the UAV, the D/L which includes the commands / data carried by it and the physical security of the CS from being taken over. 3.2

Assumptions

The following assumptions have been made within the report: ID

Assumption

1

UAV is fully working at time H/O or any problems with the UAV are known prior to H/O.

2

Payload and UAV control are independent and can be controlled separately by different CSs.

3

A CS can only control one UAV at a time (i.e. must handover UAV control or land the UAV before taking control of another UAV).

4

A CS is not restricted to the control of one type of UAV but to as many UAV types that it is cleared by the relevant authorities to control.

5

H/O can be between CSs of different types.

6

UAV flies at or above 3000ft altitude (except when taking off and landing). Table 3-1; Handover Assumptions

Page 38

Note: Altitude is the distance the UAV is flying above mean sea level. distance above the ground the UAV is flying. 3.3

Height is the

Types of CS Considered

In section 2.5.2.1 of this report the three basic types of CS were identified namely: • Type 1: Stick & Pedals;

• Type 2: Knobs & Switch HCI; • Type 3: Point & Click. There is no reason a CS of any of the above types if set up to fly the UAV could not H/O to a CS of a different type. For UAVs used over long distances requiring several H/Os for example a Type 1 CS is used for takeoffs and landings, Type 2 and 3 for the flight segments in between. 3.4

Types of Handover

There are two types of H/O, the first between CSs when the UAV is to be flown out of range of what can be flown by CS1 so the H/O is to CS2. The second type of H/O is between two UAVps in the same CS to provide UAVp1 with a break or release him at the end of his shift. Where UAVp2 takes over from UAVp1 it is assumed that this H/O is not by hot seating i.e. UAVp2 takes over UAVp1’s control desk. Therefore the H/O is between control desks in the same CS. Apart from initialising the D/L and switching it over the same condition apply whether switching between CSs or between control desks. The control desk has to be configured and controls initialised by UAVp2, then UAVp2 informs UAVp1 he is ready to take over the UAV. Prior to the H/O UAVp1 must update UAVp2 with any problems with the UAV or SA issues. The assumption has to be that UAVp2 has just walked in and must be brought up to speed of what the mission is, what happening and what is coming up prior to the H/O taking place. The H/O takes place, UAVp2 checks his control desk instruments and controls are working OK before accepting the UAV H/O. The H/O between UAVps in the same CS is simple in that it would be arranged to be executed during the period when the UAV is well within the CS’s control zone, and things are quiet. Quiet in that no actions by the UAVp in command are impending and there is no reason to inform ATC that UAVps in the same CS are changing over. As a result the more involved H/O between CSs is the procedure that is going to be developed here. The H/O procedure developed would be simplified for the handover between UAVps in the same CS, the generic checklist used to check the instruments and controls are working correctly will be identical for both types of H/O. 3.5

When and Where

A UAV H/O has to be pre-planned as part of the Mission Plan and co-ordinated between the two CS UAVps and also with the same ATC so the ATC knows what is about to take place, just in case the H/O goes wrong. Coordination between the UAVps is vital, especially when the D/L to the UAV is lost so the communications link between the UAVps cannot be via the UAV D/L and the link to the ATC also cannot be via the UAV. The H/O must take place in an area or ‘window’ where both CSs have adequate signal strength to the UAV throughout the window. The most efficient H/O is where the UAV flies straight and level on route to the next way point. Once it has been shown that UAV H/Os can be executed as a matter of course without any problems on route then they could be executed in an air-lane. Until then H/O will be executed in designated areas well away from other traffic until the relevant authorities are confident that enough uneventful H/O have been completed. 3.6

SMS

Great leaps in reducing in the number of accidents have been made over the years since the early days of aviation. This has been achieved by ever more stringent airworthiness requirements placed on aircraft. It has also been shown that it is not always the failure of the aircraft but the supporting infrastructure and systems that are at fault, e.g. the case of the BAC One-Eleven accident at Didcot 1990 [AAIB, 1992]. To improve on the current

Page 39

levels of safety then the operational infrastructure must also be addressed. ICAO has brought in their Safety Management Manual (SMM) ICAO [2006] as: “an organised approach to managing safety, including the necessary organizational structures, accountabilities, policies and procedures”. The SMM addresses many topics from understanding safety, basics of safety management right up to chapter 19 on Aircraft Maintenance. The SMM is the framework from which an operator can implement a Safety Management System (SMS). The SMS is about having the safety infrastructure and procedures in place but also having the mechanisms in place to enable proactive safety management strategies to look for safety problems and not react to them after the accident has happened. Much of the SMM is about looking for and identifying problems with existing procedures and correcting them as an ongoing process of improvement. As part of the SMM there is the Safety Cycle as shown below.

Figure 3-1; Safety Cycle [ICAO, 2006] The Safety Cycle is a framework. How the hazards are identified and the risks assessed are undefined. More structure and detail is required. To this affect it is proposed to apply the principles of ARP 4761 [SAE, 1996] in the form of the Safety Assessment Diagram to the handover process. The ARP 4761 [SAE, 1996] diagram (Figure 3-2 below) displays the standard aircraft system phases effectively as a time line across the top of the diagram and applies the standard development V life-cycle in terms of the safety analyses that would be applied in that phase of the system / V cycle phase.

Figure 3-2; ARP 4761 Safety Assessment Diagram [SAE, 1996]

Page 40

In the case of the controlled H/O of a UAV between CSs then the procedures / checklists are developed as part of this report. 3.7

H/O Analysis

To H/O a UAV there are two things to be considered, the ‘what’ and the ‘when’. The ‘what’ is what has to be done to H/O a UAV; the ‘when’ is the coordination of the H/O. To H/O a UAV the UAVp must be flying the UAV so the overall sequence must be ‘fly – H/O – fly’. Therefore the ‘what’ has to consider the functions and data needed to fly the UAV as well as H/O the UAV. The first part of the analysis covers this ‘fly – H/O – fly’ aspect of the H/O. The results of this analysis produce the majority of the H/O Requirements. With the ‘what’ in place the H/O will still fail if the ‘when’ component of the H/O is not in place. The ‘what’ components H/O have to be coordinated so they happen in the correct sequence. The second part of the analysis is to analyse the proposed H/O sequence, which is based on the handshaking principle and is described by a state diagram. The analysis of the H/O sequence will also yield further H/O requirements to be included with the H/O requirements from the part 1 analysis to create the overall H/O Requirements. The combination of the H/O Requirements and H/O State Diagram will enable the H/O Procedure to be generated. The H/O Requirements and H/O Procedure are to be the outputs from this section of the project. 3.8

Functional Failure Analysis & FHA

Functional Failure Analysis (FFA) is a top down approach for identifying functional failure conditions and assessing their effects. FFA is described in ARP 4761 [SAE, 1996] but is named Functional Hazard Assessment (FHA). In this report the convention used in the University of York Hazard and Risk Assessment (HRA) module is to continue to use FHA to describe the family of analyses and FFA to refer to the specific analysis technique. The exception to this is where FHA is used when quoting from ARP 4761 [SAE, 1996]. The HRA module describes Functional Hazard Analysis (FHA) as the name given to a group of analyses which: • are predictive target setting;

•

explore effects of failures of system components.

The analysis techniques that are grouped under the FHA heading are:

•

Functional Failure Analysis (FFA) – Studies the predicted failure modes of system functions. Applied to the functions of the CS needed to fly the UAV;

•

Sneak Analysis – Looks for unintended paths within a system. Used as inputs to the HAZOPS (Hazard Operability Studies) analysis as situations that must be considered as part of the analysis;

•

HAZOPS – Based around deviation from intended behaviour of components and data flows. Used both on data needed by the CS to fly the UAV but also on the H/O command structure. The principles of ARP 4761 are to be applied in the development of UAV handover procedures using the FHA analysis techniques noted above. How the FHA is to be applied w.r.t. ARP 4761 is shown in Figure 3-3 below:

Page 41

CS Functional Requirement Identification

Data Requirement Identification

Command Structure Identification

H/O H/O Procedure Procedure Implementation Validation

Procedure Integration

UAV Trial Formal CS Verification Verification

Formal Observed UAV Procedures

FFA Sneak Analysis

Range Trial of UAV Procedures

HAZOPS – Flight + H/O Data

Simulator Trial of UAV Procedures Using Test Scenarios

Derive H/O Requirements

Integration of H/O Procedure with other flight procedures

H/O Command Structure

UAV H/O Procedure Tests Using Test H/O Scenarios

HAZOPS - H/O Commands

Derive H/O Requirements

H/O Procedure validation against established standard

Generate H/O Procedure (Including UAVp Checklist)

Figure 3-3; Adapted ARP 4761 Safety Assessment Diagram In the proposed adapted ARP 4761 Safety Assessment diagram (Figure 3-3) the left side of the diagram the analysis techniques are applied to generate the H/O Requirements and H/O Procedure which is implemented in section 3. The Checklist noted at the bottom of the diagram (Figure 3-3) is part of the H/O Procedure but is split out and referenced by the Procedure. The purpose of the Checklist is for the CS2 UAVp use to check that his displays / controls are working correctly and if not what to do about it. Going up the right side of the diagram are the various stages of evaluation and integrating the H/O procedure with other procedures. Validation of the H/O Procedure is against an applicable established standard. This is then followed by initial testing of the H/O procedure by the use H/O scenarios to test that the H/O procedure meets the requirements. On completion of testing the H/O Procedure would then be integrated with other procedures to form the CS’s Standard Operating Procedures (SOP) needed by the CS to fly the UAV operationally. Testing of the SOP would be implemented initially using simulators before flight trials are used to fly the SOPs using an actual UAV on a range. The first step of the right side of the diagram, the evaluation of the H/O Procedure and derived H/O requirements against an established standard is considered in section 4 of this project. The other steps of the right hand side of the diagram are out of scope of the project and considered further work. 3.9

CS Boundary

The boundary for the system is considerably limited to that considered by Evans [2006]. The CS system boundary to be covered is:

•

CS systems – it is assumed that ancillaries such as power supplies to the CS are adequate and reliable. It is also assumed the CS computing power is more than adequate and reliable to cover the needs of the CS;

•

CS and UAV D/L dishes enable CS and UAV to maintain the D/L communications;

• •

Communications link between CS1 and CS2;

Page 42

Communications links from CS1 and CS2 are to the same ATC.

In addition to the system boundary the UAV flight phase also has to be defined. The UAV flight phase interest is when the UAV is in-flight under the control of CS1 just prior to UAV H/O to completion of UAV H/O to CS2. 3.10

Part 1 Analysis – ‘Fly – H/O – Fly’

3.10.1

Block Diagram

To enable FFA to be executed the functions of the system to be analyzed need to be identified. For a real CS the functions would be defined by functional or reliability block diagram or other such documentation. In the case of the generic theoretical CS covered by this project the functional block diagram and the data flows that have been generated are based on the author’s flying experience gained by attaining a light aircraft PPL. The functional block diagram generated shows the functions expected of a CS, which is shown in Figure 3-4 and Figure 3-5. Many of the functions of a CS are common whether the CS is a type 1, 2 or 3. What makes the CS types different is the Human Machine Interface (HMI) via which the UAV is controlled or provided with an updated flight plan. Each of these HMI types is covered by the breakdown of block 1 of the CS Block Diagram as shown in Figure 3-4. The other blocks that make up the CS Block diagram are considered to be generic across all the CS types.

3.10.2

Functional Failure Analysis

Evans [2006] assessed ARP 4761 FHA for the assessment of UAV Systems (UAVS). Evans [2006] adapted and applied ARP 4761 FHA to a broad approach to UAVS. Based on the Evans work ARP 44761 FHA (FFA) is applied to the CS. For each function that is identified for FFA failure conditions a set of three failure categories are considered. These are:

•

Omission – function not provided. Where the function is continuous or periodic loss could mean a singe occurrence, a periodic loss or total loss of the function. In general unless noted otherwise omission is considered to be total loss;

•

Commission – function provided when not required, not applicable to continuous functions;

•

Incorrect operation of function – this is the catchall and depends on the function FFA is applied to. For each of the above failure categories the resulting failure condition, the consequence of failure and the severity classification of the consequence are recorded. The FFA results are available on request, the consolidated FFA Hazards are shown in Appendix D.

Page 43

Figure 3-4; Control Station Functional Block Diagram (Part 1 of 2)

Page 44

Figure 3-5; Control Station Functional Block Diagram (Part 2 of 2)

Page 45

3.10.3

Severity Classification

ARP 4761 provides failure condition severity classification and also failure condition effect. Evans [2006] examined the application of ARP 4761 severity classification / effect and modified the effect definition to apply to UAVs. However as noted by Evans, ARP 4761 perspective is purely from an airworthiness standpoint and does not consider the Air Traffic Management environment. Evans modified ESARR4 [EUROCONTROL, 2004] ATM focused separation / collision criteria by substituting UAV crew for flight crew as shown below in Appendix C.2. As noted by Evans the ARP 4761 airworthiness criteria do not map well to the separation / collision focused ESARR criteria. This resulted in a dual-criteria system. Evans noted that for hazards where the UAV comes to ground – affecting the over flown population and/or the UAV itself the Airworthiness Criteria is used as shown in Appendix C.1. Where the UAV is in potential conflict with other manned aircraft then severity of the consequences of any hazard identified has to be considered in terms of airworthiness as shown in Appendix C.1 but also in terms of ATM Separation / Collision safety criteria as shown in Appendix C.2. As well as the severity classification being considered both in terms of airworthiness and ATM, the consequence of the failure is also considered in these terms. The FFA results for each of the blocks in the CS Block Diagram shown in Figure 3-4 and Figure 3-5 are available on request. The failure conditions which are the functional hazards for the system have been consolidated with references back to source functional hazards identified by the FFA is provided in Appendix D. The consolidated hazards are used in section 3.10.6 to generate the H/O requirements.

3.10.4

Sneak Analysis

The analysis method known as Sneak Analysis was originally known as Sneak Circuit Analysis was devised after Mercury Redstone Rocket launch accident in 1961. The accident was due to an unexpected ‘sneak’ circuit being made on launch when the tail plugs disconnected in a particular sequence. This sequence allowed a momentary circuit to be made to the abort coil which resulted in the motor shutting down and the rocket crashing on the launch pad. Sneak Analysis, defined by Parts 1 & 2, with Part 1 Method and Procedure [ECSS, 1997] being the most useful as applied to the H/O procedure. The aim of Sneak Analysis is to look for unintended paths (flows) within a system. Sneak Analysis [ECSS, 1997] provides the following definitions:



Source – An item of a system which contains mass, energy or data; Target – An item of a system the unwanted activation or inhibition of which can trigger an undesired event.

University of York System Safety Analysis (SSA) module notes provide the following concise overview of Sneak Analysis:





Sneak Paths include:
Simple path – unintended route between source and venerable target;
Diversion path – unintended diversion or drain on intended path;
Converging path – two agents with hazard potential when combined find unintended routes to common target;
Obstruction path – intended path obstructed. Sneak Types include:
Sneak path – creation of unintended path or diversion;
Sneak opens – breaking an intended path, or introduction of an obstruction;
Sneak timing – an unintended path is created at the wrong time;

Page 46







Sneak indications – operators are given false or misleading information about the state of the system;
Sneak labels – items have false or misleading labels. As noted by the SSA module: Sneak indications and labels above are clues to how sneak may arise.

Applying Sneak Analysis the paths from source to target can be shown as a circuit or ‘Topogram’, which can be built up. First, the normal intended paths are identified, then using the sneak paths and types as ‘clues’ unintended paths can be identified and documented. The normal sources are CS1 and CS2, the target is the UAV. These have been used to create circuit diagram Figure 3-6. An unintended source and target i.e. CS other and UAV other have also been added.

SW1 = CS1 CS1

CS2

CS other

SW2 = CS2 SW3 = CS other

SW1

SW2 A3

SW3

A1

A2

UAV1

UAV other

A1, 2, 3 = Data link path connections

Figure 3-6; Sneak Topogram Note: Other connections than those being analysed in each case are assumed to be open circuit. In Figure 3-6 switches SW1, 2 and 3 are closed when the respective CS is operating. D/L connections are via A1, 2 and 3. In the case of D/L connection A3, this is an unintended connection and is made due to atmospheric conditions to create a Converging Sneak Path from CS other to UAV1 and also the other way from CS1/CS2 to CS other. As both sneak paths are essentially the same only the Converging Sneak Path from CS other to UAV1 is considered. CS other path to UAV1 could be considered as a Simple Sneak Path but as CS1 or CS2 should be controlling UAV1 already then this is a Converging Sneak Path. If however UAV1 was autonomous and listening out to reconnect the D/L and made the unintended connection with CS other then this would be a Simple Sneak Path. Intended connections:






SW1, A1; SW2, A1; SW3, A2; SW1, A1, SW3, A2; SW2, A1, SW3, A2.

Unintended Connections:




SW1, A3, A2; SW2, A3, A2; SW3, A3, A1.

Another converging path is that of SW1, SW2 and A1 i.e. CS1 and CS2 are both controlling or trying to control UAV1. This can happen in two ways. The first is that both CS1 and CS2 are trying to regain control of UAV1 after the D/L was broken. The procedure of how the CSs should coordinate to try to regain the D/L to the UAV is further work and out of scope Page 47

of this report. The second way that both CS1 and CS2 have connections to the UAV is due to the type of D/L connection used. The two types of D/L connection are Break Before Make (BBM) and Make Before Break (MBB). For a BBM connection both CS cannot be connected at the same time. However for MBB both CS1 and CS2 can be connected at the same time, but this is not a problem as long as it is managed that only one CS is in control at a time and both CS know who is in control. MBB would allow CS1 to monitor the UAV and to take back control from CS2 if CS2 was not in full control of the UAV. Therefore the MBB D/L must be considered as an intended path but also as a Sneak Timing Type when the intended path is created at the wrong time. Sneak Obstruction / Open path would result in the failure in the D/L path. Such a failure was considered as part of the FFA resulting from the failure or incorrect positioning of the CS or UAV dishes. Two Sneak Types not evident in the circuit diagram Figure 3-6 above are Sneak Indication and Sneak Labels. Sneak Indications provide misleading information to the UAVp such as data being displayed in the wrong units e.g. feet instead of metres when the UAVp is expecting metres. Sneak Indications are an obvious error, Sneak Labelling, the mislabelling of accurate data which misleads the UAVp is a little less obvious. However an example of something close to this is provided by Air Inter Flight 148 described in section 2.7.5.2. It could be argued that the cause of the crash of Air Inter Flight 148 was mode confusion by the pilots. However it can also be argued that if the autopilot modes were distinguishable and / or what was being put in was properly labelled then it would have been obvious to the pilots how what was being entered was going to be interpreted by the flight computer. Sneak Paths, Indications and Labelling situations identified as part of Sneak Analysis are incorporated into the HAZOPS analysis of the CS data the results of which are available on request, the consolidated HAZOPS recommendations are shown in Appendix E.1.

3.10.5

HAZOPS

HAZOPS was developed by ICI in the mid 1960s as a hazard identification technique for process plants. Having its origins in the petrochemical industry HAZOPS was about analysing product flows between components. HAZOPS uses guide words as prompts to identify the consequences of too much or too little chemical ‘A’ mixing with chemical ‘B’. As well as the consequences, plausible causes are also identified and actions identified to stop the hazards arising. HAZOPS has since been found to be a very useful analysis technique that can be generally applied to any kind of flow including data flow. HAZOPS is normally a team activity which includes designers, users and subject matter experts with specific roles for team members. Roles include a leader to coordinate the meeting and a person to keep track and record the findings. In this respect HAZOPS has not been followed. HAZOPS is fully described by DEF STAN 00-58, MoD [1996] this has now been withdrawn by the MoD. In its ‘classic’ form HAZOPS provides a table of guidewords with their generic descriptions. As the guidewords are process based, an applicable selection would be made and when used how the guideword is applied is recorded. An analysis method known as SHARD which stands for Software Hazard Analysis & Resolution in Design is a software analysis method based on HAZOPS developed by Fenelon et al [1999]. SHARD being based on HAZOPS and also uses guidewords but provides a minimal set tailored for software applications as shown in Table 3-2 below.

Page 48

Guideword

Description

Omission Commission Early Late Value

Service not delivered. Service delivered when not required. Service delivered, but early. Service delivered, but late. Service delivered, but with incorrect value. Table 3-2; SHARD Guidewords

It was noted in the HRA module that detectability must be considered, but was not built into the guidewords (e.g. Value (detectable), Value (undetectable)) as it was felt to be too case specific. Within the HAZOPS analysis where applicable under the consequence heading and severity heading, ‘detected’ and ‘undetected’ have been used to identify the consequences of a UAVp detecting or not detecting the error. The use of guidewords ‘Commission’ and ‘Early’ have been combined within the HAZOPS analysis as the effect of a data item received when not expected equates to the same as early.

3.10.5.1

HAZOPS Application

In the application of HAZOPS to CS it has been used to analyse the data which is:







Required to fly the UAV; Required by UAV to establish D/L with CS2; Required by CS2 to establish D/L with UAV; UAV sourced flight data required by CS2 to fly UAV; CS2 data required to be set-up prior to H/O; CS2 sourced UAV data.

The results of the HAZOPS analysis of the data flows are available on request, the consolidated HAZOPS recommendations are shown in Appendix E.1.

3.10.6

Handover Requirements

The H/O Requirements have been generated from the Consolidated FFA Hazards (Appendix D) denoted by C# where # is a numeric value and the Consolidated HAZOPS Recommendations for the fly – H/O – fly analysis (Appendix E.1) are denoted by R#. ID

Description

1 1.1

UAV Handling The UAV H/O shall be aborted if the UAV is controllable only by secondary effects of other flight controls. UAVp to abort H/O immediately. The UAV H/O shall be aborted if it is found that the UAVp is unable to change UAV flight path. The UAV H/O shall be aborted it is found that the UAV is uncontrollable due to excessive or incorrect control surface response. If the UAV is exhibiting noticeable control glitches then the UAV H/O shall be aborted. UAV with no or inadequate rudder control can be accepted for H/O at receiving UAVp’s discretion. UAV Control Cut engine command shall be executed when weight on wheels is achieved or be confirmed by UAVp before cut engine is executed. If the CS has the capability to directly control the UAV throttle then the UAVp shall only accept the H/O if the UAVp is able to smoothly change the engine speed from min to max. The UAV H/O shall be aborted if UAVp commanded inputs result in excessive or incorrect response to airspeed, altitude or heading. The UAV H/O shall be aborted if UAVp commanded inputs result in no or minimal response in airspeed, altitude or heading. When UAV control is only by mission / waypoint update (no direct CS control) and UAV does not respond to updates then UAV H/O shall be rejected.

1.2 1.3 1.4 1.5 2 2.1 2.2

2.3 2.4 2.5

Hazards R1, C2 C1, C4 R2, C6 R5, C3 R6

R7 R8

R9 R10 R11, C10

Page 49

ID

Description

Hazards

2.6 2.7

If D/L is via BBM, UAV H/O in manual control shall not to be attempted. If D/L is via MBB, UAV H/O in manual control can be executed if CS2 UAVp is ready and setup to take manual control of the UAV. For MBB D/L and UAV H/O is via manual control then the CS1 and CS2 D/L signal quality / strength shall be monitored. UAV shall not be under control of CS with low D/L signal quality / strength. For MBB D/L and UAV H/O is via manual control then the CS1 and CS2 D/L signal quality/strength shall be monitored. If D/L signal quality / strength for both CS start to become low then H/O is to be aborted. CS1 to bring UAV back into area with higher signal strength. CS shall not command either by manual control or by mission / flight planning that is not possible for the UAV to achieve. The UAV H/O shall not be initiated while D/L signal strength is low or fluctuating at a low level. Only one CS shall be in control of the UAV at a time. CS1, if in contact with UAV be able to take back control by issuing a H/O abort command. UAV Configuration UAVp shall, when in control of the UAV be able to change UAV configuration when commanded. During H/O using BBM D/L, while changing over D/L from CS1 to CS2 UAV shall fly autonomously following stored mission/flight plan. UAV Messages All messages shall identify who they are for and from. Any commands not meant for UAV or CS is to be ignored by receiving system.

R13 R13

2.8

2.9

2.10 2.11 2.12 2.13 3 3.1 3.2 4 4.1

4.2

Messages shall be checked for corruption.

4.3

Incoming messages shall be checked for corruption and if found to be corrupt rejected.

4.4

Where continuity across a series of messages is required then a missing or corrupted message is be resent. Where a series of part messages or message sequence are required to be sent then a method of identifying that all the parts or sequence have been received, are not corrupt and are in the right order before execution shall be employed. CS1, as part of the H/O initiation message shall send the UAV dish coordinates for CS2 along with communication frequencies and the CS ID. If CS2 is not responding to CS1 H/O commands promptly, or there is a possibility of D/L to UAV may be lost before H/O is completed then CS1 UAVp shall abort H/O. Displays If flight instruments continue to be blank or frozen after D/L is established during H/O then the H/O is to be aborted. A clear indication to UAVp when UAV autopilot is engaged or disengaged. UAV with no or unusable UAV video can be accepted for H/O at receiving UAVp’s discretion. Position data for the incoming UAV may be displayed prior to handing off current UAV. If so shall be clearly identified as the incoming UAV and not the current UAV. The UAV H/O will be aborted unless extenuating circumstances exist at receiving UAVp’s discretion as to why an accurate position for the UAV is not critical to the safe operation of the UAV (e.g. fly on visuals to land UAV). Mission is to be aborted and UAV landed at earliest opportunity. The UAV H/O will be aborted unless extenuating circumstances exist at receiving UAVp’s discretion as why an accurate altitude for the UAV is not critical to the safe operation of the UAV (e.g. fly on visuals to land UAV). Mission is to be aborted and landed at earliest opportunity.

4.5

4.6 4.7

5 5.1 5.2 5.3 5.4

5.5

5.6

Page 50

C78

C78

C9 C32 C66, C77 C66, C77

C7 C67, C68

R3, C35, C64, C73, C77, C78 R4, C34, C38 R4, C33, C34, C38, C39 R4 C36, C79, C80, C81, C82 C41 C55

C12 R14 R18, C16 R21

R20, C13

R22, C13

ID

Description

Hazards

5.7

If UAVp aware that data display error is due to display mislabelling or incorrect scaling then UAVp’s discretion if UAV H/O accepted or rejected. Mission is to be aborted and UAV landed at earliest opportunity. If airspeed is not provided or incorrect then the mission is be aborted and the UAV landed at earliest opportunity. UAVp’s discretion if UAV H/O accepted or rejected as airspeed can be estimated from other flight instruments. If heading is not provided or incorrect then the mission is be aborted and the UAV landed at earliest opportunity. UAVp’s discretion if UAV H/O accepted or rejected as heading can be estimated from other flight instruments. The UAV H/O will be aborted unless extenuating circumstances exist at receiving UAVp’s discretion as to why an accurate attitude for the UAV is not critical to the safe operation of the UAV (e.g. fly on visuals to land UAV). Mission is to be aborted and landed at earliest opportunity. If engine RPM is not provided or incorrect then the mission is be aborted and the UAV landed at earliest opportunity. UAVp’s discretion if UAV H/O accepted or rejected as engine RPM can be estimated throttle position and airspeed. If UAV system status (fuel, engine etc) not provided then UAVp to accept UAV H/O but mission shall be aborted and UAV landed at landed at earliest opportunity. If mission map display continues to be blank or frozen after D/L is established during H/O then the H/O is to be aborted. If other air traffic position and track are available then they shall be displayed on the mission map. If fuel available display continues to be blank or frozen after D/L is established during H/O then the H/O is to be aborted and UAV landed at landed at earliest opportunity. If UAV system status display continues to be blank or frozen after D/L is established during H/O then the H/O is to be aborted and UAV landed at landed at earliest opportunity. If D/L signal strength display continues to be blank or frozen after D/L is established during H/O then the H/O is to be aborted and UAV landed at landed at earliest opportunity. The scaling and display units normally used for individual flight data parameters shall be used as default when flight data is displayed. UAVp shall be informed by the CS when the UAV is under their control. If D/L is switched back to CS1 due to failure at some stage of the H/O, CS1 shall be informed UAV is under CS1 control and reason D/L returned. Monitoring Track and altitude of UAV shall monitored by the UAVp throughout the period the UAV is in his charge. UAVp shall monitor the UAV to check that the UAV is achieving commanded mission targets. UAVp shall monitor the mission map display periodically against the real world and UAV to check that the mission map is providing an accurate picture. If other air traffic position and tracks are displayed on the mission map they are to be maintained and monitored. Fuel available to be monitored by UAVp and checked against mission / flight plan estimates. If fuel available is low then the UAV landed at landed at earliest opportunity. Data No UAV H/O shall be executed if the UAV tail ID is either not provided or does not match that identified in the flight/mission plan. No UAV H/O shall be executed until CS1 has provided / confirmed the UAV type. The UAV H/O shall be aborted if UAV type identified in the initial UAV message does not match that expected by the receiving H/O CS. UAV shall not to be flown without flight plan / mission loaded in the UAV that covers the H/O to landing the UAV.

R23, C14, C23

5.8

5.9

5.10

5.11

5.12

5.13 5.14 5.15

5.16

5.17

5.18 5.19 5.20 6 6.1 6.2 6.3 6.4 6.5

7 7.1 7.2 7.3 7.4

R24, C13

R25, C13

R26, C13

R27, C13

R28

C17 C19 C21

C22

C30

C37 C62, C64 C74

R12, C20 C9 C18 C19 C21

R15 R16 R17 R19, C61, C67, C68, C71, C72

Page 51

ID

Description

Hazards

7.5

The position data for next UAV if received before current UAV is dealt with shall be stored separately, away from current UAV data. CS Set-up CS2 UAVp shall as part of the mission/flight plan be allowed reasonable time to reconfigure and initialise the CS. CS2 UAVp shall follow a checklist to fully reconfigure and initialise CS. Co-pilot shall be used (if applicable) to double check checklist actions by the pilot to reconfigure and initialise CS. Mission map display shall be initialised with the map loaded at the correct scale and positioned for the next UAV mission as part of the CS initialization prior to UAV H/O. CS Alert / Warning annunciation shall be checked as part of the CS initialization prior to UAV H/O. UAV related Alert / Warnings set to CS1 shall be passed to CS2 electronically and/or orally prior to start of H/O. CS2 shall preset the ATC frequencies as part of the CS initialization prior to UAV H/O. CS1 and CS2 shall not operate without Standard Operating Procedures (SOP) resident in the CS and that cover the UAVs that are to be handled. CS2 UAVp shall check any data provided by CS1 for errors and consistency. Communications CS1 and CS2 shall initiate communications with ATC to inform them that a UAV H/O is about to take place and to get an update on the weather and traffic in the area. CS1 and CS2 shall use their respective call-signs, UAV call-sign and that of the ATC in any communication with ATC. If CS1 and CS2 do not have clear communications with ATC and with each other then the UAV H/O shall not be initiated.

R21

8 8.1 8.2 8.3 8.4

8.5 8.6 8.7 8.8 8.9 9 9.1

9.2 9.3

9.4 9.5 9.6 9.7 9.8 9.9

10 10.1 10.2 10.3 10.4

When CS1 or CS2 are communicating with ATC and each other it shall be obvious to the CS transmitting when they are transmitting. During H/O any emergency involving UAV shall be coordinated by CS1. CS1 shall follow SOP when declaring an emergency to ATC. CS UAVp gains control of UAV shall inform the other CS UAVp of this. When D/L to UAV has been lost during H/O, CS1 and CS2 shall follow SOP to regain D/L coordinated by CS1. If CS2 D/L is found to have and continues to have over a period (TBD) poor signal quality / strength such that the messages are received but the data is corrupt then the D/L shall be switched back to CS1. H/O Coordination UAV H/O shall follow a coordinated sequence documented by a common SOP to both CS UAVps and is understood by both UAVps. If CS2 is unable to take the UAV then CS1 must coordinate with ATC to loiter UAV until CS2 is ready or land UAV at pre-planned alternative landing area. If H/O continues on outside H/O window then CS2 UAVp is in control of UAV as CS1 will be out of range. CS2 shall still confirm acceptance of H/O to UAV and CS2 even if H/O continues outside of H/O window effectively giving UAV control by default.

R29 R30 R30 C17

C24 C29 C44, C46 C57 C56 C45, C51

C46, C50, C52 C47, C48, C53, C58, C70 C49, C54 C58, C59 C60 C65 C67, C68, C71, C72 C74

C61, C62 C63 C69 C69

Out of Scope UAV issue (not CS) UAV structural integrity shall be capable of meeting demands placed upon it. UAV configuration shall not change until commanded by CS in control to change UAV configuration. Alarm system Alarm system checks other than annunciator check not possible to check as part of H/O.

Page 52

C6 C8

C25, C26, C27, C28

ID

Description

Hazards

Signal strength D/L Apart from no D/L strength reading UAVp unable to tell if signal strength is misreading. Dish alignment is out of scope.

C31, C32 C40, C42, C43

Table 3-3; Handover Requirements 3.11

Part 2 Analysis: H/O Sequence

3.11.1

Handover Sequence

The author’s proposal for the UAV control H/O sequence from CS1 to CS2 is shown in Figure 3-7 below. It is based on the premise of handshaking between CS1 and CS2 and relies on good communications between the two. It is assumed that the link between CS1 and CS2 is not via the UAV D/L, if the D/L is lost then this is the time at which communications are needed the most.

Page 53

3.11.2

Proposed CS UAV Handover Sequence

Figure 3-7; Control Station Handover State Diagram

Page 54

3.11.2.1

Start to Stage 2

The H/O sequence starts with either CS1 UAVp sending CS1_Ready to CS2 UAVp when the UAV is coming up the start of the H/O window. Alternatively CS2 UAVp sending CS2_Ready to CS1 UAVp signifying that CS2 is initialised and ready to proceed with the H/O.

3.11.2.2

Stage 2 to 5

Once both CS UAVps have signalled that they are ready to proceed, the process of H/O begins at the state noted as Stage 2 in the diagram. CS1 UAVp starts the H/O process by sending CS1_Start _HO, CS2 UAVp acknowledges this by sending CS2_Ackn. Up to stage 4 was making sure both UAVp are ready, CS2 UAVp could have been ready and waiting some time for CS1 UAVp to have the UAV in place. Now the H/O starts with CS1 UAVp sending the message CS1_Initiate_HO, which includes the data needed by the UAV to setup the D/L with CS2. Assuming that the D/L is BBM, the UAV D/L to CS1 will be broken so that the D/L to CS2 can be made. If CS1 UAVp wishes to stop the H/O then CS_Abort_HO has to be issued by stage 5 before the UAV breaks the D/L.

3.11.2.3

Stage 5 to 6

At stage 5 the UAV has been commanded to start the H/O, the UAV acknowledges this with UAV_Link_Change to CS1 before changing the D/L frequency and communications dish position for CS2. On initial contact with CS2, UAV would send to CS2 via the D/L the message UAV_Link_Estb providing CS2 with the data identifying the UAV id and type. If no connection was established within a set period the D/L is switched back to CS1 and warning message UAV_DL_Init_Fail sent to CS1.

3.11.2.4

Stage 6 to 7

At stage 6, initial contact has been made from UAV to CS2. From the data provided by the UAV, CS2 has to check that this is the UAV it is expecting and is the type expected. If this is the UAV CS2 expects, CS2 transmits CS2_DL_Estb to confirm the D/L with the UAV. If the UAV is not the one expected, CS2 would not reply. Either the expected CS makes contact with the UAV in this case or if no D/L is established within a time out period the D/L is switched back by the UAV to CS1 and the warning message CS2_DL_Estb_Fail sent to CS1.

3.11.2.5

Stage 7

The D/L between the UAV and CS2 has now been established. If the UAV type provided by the UAV was not as expected, the H/O would be immediately aborted by CS2 as this must be correct for CS2 to be able to monitor and control the UAV. The D/L abort sent to the UAV would result in the D/L being returned to CS1 with the CS_Abort_HO warning message set to CS1. On the D/L being established data is passed between the UAV and CS2. At this stage most of the data will be coming from the UAV to drive the CS2 displays; however CS2 also needs to send messages up to the UAV so the UAV knows that CS2 is still in contact. As the UAV H/O has not as yet been accepted by CS2, if the D/L is not maintained the UAV switches the D/L back to CS1 and issues warning message UAV D/L Maintain Failed (UAV_DL_Mnt_Fail). If the D/L to CS2 has failed then CS2 would not have received the message anyway. As CS1 is responsible for the UAV until CS2 has accepted the H/O any lost link procedure would be coordinated by CS1. The CS2 UAVp would have a short period of time to assess whether CS2 is fully working, can control the UAV and to run through a checklist such as that provided in section 3.13 to ensure that all the required checks are made. Initially flight instruments and UAV system status (fuel, engine, parameters etc), D/L strength and status are checked that they are within expected tolerances. When the UAV is flying straight and level then there will be little change in reading (unless UAV going through turbulence). Now flight data is being provided by the UAV the UAVp can disengage the UAV autopilot and take manual control of the UAV. This serves two purposes; the first that the UAVp has control over the UAV Page 55

which is not excessive, ineffective or wrong (e.g. inverted) and that the UAVp can take control when required. The second purpose is to show the instruments are being updated and responding correctly to the control inputs being applied to the UAV. The HAZOPS analysis of the data needed by CS2 is available on request, the consolidated HAZOPS recommendations are shown in Appendix E.1. In many of the HAZOPS analysis lines the recommendation is clear cut and is abort the H/O. In aborting the H/O the UAV is to go back to autopilot if in manual control and return the D/L to CS1 as CS2 cannot safety control the UAV. In other places the recommendations in not clear cut and is at CS2 UAVp’s discretion to accept or reject the H/O. This is because it depends on the situation at the time of the H/O. An example of this is given in D.4.1.A, UAV Position – Omission. A UAVp would not normally be expected to accept a UAV for which an accurate position was not being provided especially when the UAV is navigating cross country (UAVs don’t tend to have VOR etc but rely on GPS). Where this would not be critical is when the UAV is being brought in to land visually either by the CS UAVp or by an external UAVp. So acceptance is at pilot’s discretion depending on circumstances. The problems are assumed to arise at H/O but the problems may occur prior to the H/O, in which case CS1 UAVp shall inform CS2 UAVp of any UAV problems prior to H/O.

3.11.2.6

CS2 HO Acceptance

In multi pilot cockpits such as in airliners H/O is by an announcement by one pilot to the other that he, the pilot in control, is handing over control. The co-pilot then acknowledges he has control and that is it. For MBB D/L something similar can be achieved. As CS1 UAVp maintains the D/L while CS2 UAVp checks the controls and CS1 UAVp has the option to take back control by issuing CS_Abort_HO if necessary if CS2 UAVp has problems. When CS2 UAVp is satisfied he accepts control and therefore responsibility for the UAV by issuing CS2_HO_Accept. For a BBM D/L H/O it is not so straight forward. When CS1 UAVp initiates the H/O he loses the D/L, the UAV flies autonomously for a short period until the D/L is made with CS2. If CS2 gets into problems the UAVp has to abort and then the UAV should then switch back to CS1. If however the UAV ends up in a ditch due to loss of control, who is responsible for the UAV as CS2 has not formally accepted control. Also if CS2 does not accept control but flies out of range of CS1 (accepting control stops UAV searching for CS1 on temporary loss of D/L). It was considered using a time out by which time CS2 UAVp had to accept the H/O or the D/L returned to CS1. This when examined using HAZOPS was found at best to be a nuisance and at worst either forcing CS2 accepting the UAV when he shouldn’t or breaking the D/L but CS1 is out of range resulting in the loss of the D/L and UAV acting autonomously. Passing over control of the aircraft but the other pilot does not formally accept control is not something airline pilots have to worry about. Who is responsible for the UAV during H/O? The author believes that while ever the CS1 UAVp can monitor the UAV and take back control then CS1 UAVp is responsible for the UAV as in the case of MBB D/L. For BBM D/L when the D/L is established to CS2, at that point CS2 UAVp is responsible for the UAV as CS1 cannot monitor and has no control over the UAV. If H/O is aborted and D/L is reestablished to CS1 then CS1 is again responsible for the UAV. This leaves the D/L switch over period which should be brief where the UAV is autonomous. As D/L has not been made to CS2 then CS1 UAVp has to be responsible for the UAV until the D/L is made to CS2.

3.11.3

HAZOPS application to Handover Sequence

A second HAZOPS analysis to that implemented for the Part 1 Analysis this time on the H/O Sequence messages shown in the state diagram. This has been done to both evaluate the H/O sequence of events and to identify any additional H/O Requirements. The HAZOPS guidewords used previously as shown in Table 3-2 were once again used. Under the guideword ‘Omission’ the consequence of both a message not being sent and for the message implemented but not sent i.e. the sender believes the message has been sent but the intended recipient did not receive it were considered. Guidewords ‘Commission’ and ‘Early’ have been considered to be equivalent and analysed collectively. Page 56

Guideword ‘Incorrect’ has been interpreted as being where a message is issued that is not applicable to the current stage of the H/O State Diagram. Each of the messages shown in the H/O State Diagram Figure 3-7 has been analysed and the results of the H/O Sequence HAZOPS analysis are available on request. The consolidated HAZOPS recommendations for the H/O Sequence analysis can be found in Appendix E.2. The results of the H/O Sequence HAZOPS identified recommendations but also showed the proposed H/O Sequence based on the premise of handshaking between CS1 and CS2 to be a workable solution for the sequencing of the H/O.

3.11.4

Additional H/O Requirements

As a result of the H/O Sequence HAZOPS Recommendations shown in Appendix E.2 the following changes were made to the H/O Requirements. Requirement 4.1 below remains unchanged but now includes HAZOPS Recommendation R34. The other HAZOPS Recommendations have resulted in the three new H/O Requirements shown below. ID

Description

4 4.1

UAV Messages All messages shall identify who they are for and from. Any commands not meant for UAV or CS is to be ignored by receiving system.

5 5.21 5.22

Displays System H/O stage shall be displayed to UAVps. System shall inform UAVp if incorrect or inappropriate command has been entered. CS Set-up CS1 / CS2 comms shall not be via the UAV. When communications to the UAV is lost this is the time when inter UAVp communications is most needed.

8 8.10

3.12

Hazards

R3, R34, C35, C64, C73, C77, C78 R31 R32

R33

Handover Procedure

The H/O Sequence shown in H/O State Diagram Figure 3-7 can be used for either a BBM or a MBB H/O as both types of H/O were included in the part 1 and 2 analysis. However the Proposed H/O Procedure is for a BBM H/O as this is the more awkward implement but only requires the UAV to maintain a single D/L between it and the controlling CS. BBM is more awkward because only one CS can communicate with the UAV at a time so this path cannot be used as a way to coordinate the H/O. The Proposed H/O Procedure is generated from the H/O State Diagram (Figure 3-7) framework. In addition the H/O Procedure also fulfils the H/O Requirements generated in the Part 1 Analysis for the ‘fly – H/O – fly’ sequence shown in section 3.10.6 as well as the additional H/O Requirements from the Part 2 Analysis of the H/O sequence. The pre-H/O part of the Procedure (section 3.12.1) documents first the steps the CS1 and CS2 UAVps follow. For the actual H/O (section 3.12.2) the procedure documents the steps the UAV and CS2 UAVp follow. Included in the H/O Procedure is a call-out to the UAVp Checklist (section 3.13) that the CS2 UAVp uses when the D/L has been made to the UAV to check that the CS displays are working correctly and that he has full control over the UAV. After going through the Checklist the UAVp has to decide if he is willing or not to accept and take over responsibility for the UAV or abort the H/O to pass the UAV back to CS1 UAVp. Assuming the CS2 UAVp accepts the H/O then the post H/O (section 3.12.3) part of the procedure documents the completion of the H/O where the UAVp is free to upload any mission / flight plan amendments as required.

Page 57

3.12.1

Pre-Handover

CS1 Actions

CS1 H/O Commands

CS2 Actions Close D/L with landed or handed over UAV (if applicable). Close comms with ATC and CS associated with previous UAV (if applicable). Check / clear command buffers for any commands meant for previous UAV. Log then clear errors relating to previous UAV (if applicable).

Establish comms with CS2. Confirm UAV Tail_No and Type_ID with CS2. Confirm Mission_ID and version with CS2. If CS2 has not got latest mission version transfer latest version. CS1 declares any problems with the UAV to CS2. Transfers any relevant UAV error/failure data to CS2. Provide CS2 with latest UAV position, altitude, heading and estimated time to start of H/O window. The H/O window is defined by the mission plan. This is in terms of the start position of the window the H/O can start to the end of the window at which the H/O must be completed by before the UAV reaches this position. Contact ATC to inform of H/O and for an update of the traffic in the area.

Calculate UAV dish position for CS2 based on UAV at start of H/O window. Transmit to the UAV the following: a) CS2’s unique ID (equivalent of the UAV’s tail number); b) Frequencies for CS2 D/L command /video link/ payload; c) UAV D/L dish position to be used for CS2 on initiation of H/O.

Check for errors / failures relating to CS and correct if possible. Decision to be made by UAVp if any errors / faults not cleared whether these will prohibit handover acceptance of UAV. Establish comms with CS1. Confirm Tail_No and Type_ID of UAV to be handed over. Confirm mission / flight plan Mission_ID and version, if not latest get from CS1. Checks UAV error/failure data transferred from CS2.

Configure CS w.r.t. UAV Type_ID (load VSM corresponding to UAV_Type). Get mission updates from other sources (e.g. HQ). Get Met data for mission area and time period. Amend mission w.r.t. mission updates and predicted weather for mission segment UAVp is to be responsible for. Translate mission ready for uploading to UAV (executed when H/O completed and CS2 has full control of UAV).

Load mission data into CS system to provide e.g. H/O window, UAV expected track and altitude etc.

Page 58

CS2 H/O Commands

CS1 Actions

CS1 H/O Commands

CS1 may provide on request from CS2 the current UAV status.

Set UAV in autopilot if not already in this mode ready for H/O.

UAV in position at start of H/O window. CS1 is ready sent to CS2. CS1 starting H/O sent to CS2.

CS1_Ready

CS1 transmits initiate H/O to UAV and CS2. Note: Break Before Make (BBM) or a Make Before Break (MBB) D/L can be used. If BBM D/L has been used, after this point (state 4) in the diagram CS1 can no longer take back control from CS2 if anything goes wrong. If MBB D/L is used CS1 can use the unbroken D/L between CS1 and UAV to issue CS_Abort_HO to take back control up to the point when CS2 issues a CS2_HO_Accept at which point it is in sole control of the UAV. No other commands other than CS_Abort_HO is to be accepted from CS1 while CS2 maintains control.

CS1_Initiate_HO

CS2 Actions

CS2 H/O Commands

Set CS switches for UAV configuration (pitot heat, de-icing, navigation lights, required mode (e.g. UAV autopilot on) etc). If applicable, check stick / pedal controls for full and free movement. Set controls for UAV for straight and level flight. Trims mid position, flaps 0 degrees, undercarriage up. Throttles set for cruise. If applicable, knobs and switches set for handover altitude, airspeed, heading and next waypoint. Set frequency for ATC, also frequencies for D/L command /video link/ payload. Calculate CS D/L dish position based on start of window. Position D/L dish. Set transponder setting. Load maps for moving map display. Confirm expected track displayed in expected position. Check displays are displayed with expected units and map displays are at the correct scale. Set altimeter pressure altitude. Contact ATC to inform of H/O and for an update of the traffic in the area. CS2 initialisation and set-up complete. CS2 is ready sent to CS1.

CS2_Ready

CS2 acknowledges start of H/O.

CS2_Ackn

CS1_Start_HO

Page 59

3.12.2

Handover

UAV Actions Acknowledgement of link change transmitted to CS1. UAV transmits link establish to CS2.

If UAV does not get a response from CS2 or D/L is rejected then D/L returned to CS1. UAV link to CS2 now established. UAV starts down loading UAV flight data (altitude, heading, airspeed, position etc).

UAV H/O Commands UAV_Link_Change (to CS1) UAV_Link_Estb

CS2 Actions

CS2 checks that the message is from UAV expected. If message is from the expected UAV to CS2, CS2 responds to UAV by transmitting D/L established to UAV. However if UAV is not the UAV expected message sent to UAV to reject D/L. If the message received is not for CS2 (i.e. CS_ID is not that of CS2) message is ignored.

If CS2 UAVp rejects H/O or D/L to CS2 fails before CS2 accepts H/O then D/L re-established with CS1.

Post Handover

CS2 Actions H/O complete, CS2 UAVp in full control of UAV. UAVp can upload any mission updates as required.

Page 60

CS2_DL_Estb

CS2 flight displays now displaying UAV supplied data.

CS2 UAVp is to execute checklist (see section 3.13) to establish if H/O is to be accepted or rejected. CS2 UAVp has limited time to complete the H/O before the UAV reaches the end of the H/O window. If CS2 UAVp accepts control of UAV by transmitting acceptance to UAV and CS1. If however CS2 UAVp finds problems with the control of UAV or flight displays rejects the H/O and transmits rejection to UAV and CS1.

3.12.3

CS2 H/O Commands

UAV Actions

CS2_HO_Accept CS_Abort_HO

3.13

Generic Checklist

This Checklist is used by CS2 UAVp on receiving the UAV to check that the flight displays and controls are functioning and what to do if they are not. In relation to the H/O state diagram Figure 3-7 the Checklist is executed at Stage 7 as documented in section 3.11.2.5 where CS2 UAVp has to accept or reject the UAV H/O. The Checklist is called up as part of the H/O part of the H/O Procedure shown in sections 3.12.2 and 4.8.7 and was developed as part of the H/O Procedure from the H/O requirements. The break out of this checklist is to save space as it referenced from two locations as noted above. Action If Failed (column 4) Codes PD Pilots Discretion whether to accept H/O. MA Mission Aborted if UAV accepted – UAV to be landed at earliest opportunity. ABORT Abort H/O immediately. N/A Not applicable. ID

Description

1/. 1.1 1.2 1.3 1.4 1.5

Flying Instrument Displays Attitude correct – straight + level. Pressure Altitude – correct setting displayed. Altitude correct - displayed with correct units (ft). Heading correct. Airspeed correct – displayed correct units.

1.6 2/. 2.1 2.2 2.3 2.4 2.5 3/. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8

Engine RMP correct and is being updated. Visual Display UAV providing display from UAV. Display not constantly freezing / pixilation/ blanking. Zoom / pan available (if applicable). Display at correct level of zoom (apply correction if applicable). Camera pan pointing forward (apply correction if applicable). SA – Moving Map display Map displaying correct area. Map at correct scale. UAV position – Lat/Long agrees with moving map position. UAV position on map is being updated. UAV expected track correctly positioned on map. UAV position is on track. UAV actual altitude agrees with expected altitude. Map prominent reference feature is identified at expected position in real world on visual. UAV Status Engine Temperature – in correct units and within limits. Oil Pressure – in correct units and within limits. Fuel Level – within expected limits (expected minimum). Estimated fuel usage to destination provided and is less than current fuel available.

4/. 4.1 4.2 4.3 4.4

Pass / Fail

Action If Failed

ABORT PD MA PD MA PD MA PD MA PD MA PD PD PD PD PD PD PD PD PD PD PD PD PD

MA MA MA MA MA MA MA MA

PD PD PD PD

MA MA MA MA

4.5

CS switch settings for UAV translate to UAV ancillary systems on/off.

PD

4.6 4.7 5/. 5.1 5.2 6A/. 6A.1

D/L Signal level provided and is being updated. D/L system status is OK. UAV Error Log If new errors - check for Alerts - if so reject H/O. Alert and Warning annunciations tested and working. Manual Control: Stick& Pedal Ensure stick / pedals / trims central, throttle set for cruise.

PD MA PD ABORT PD MA N/A

Page 61

ID

Description

6A.2

Disengage UAV autopilot – UAV flying straight and level (check flight instruments and visual). UAV continues to fly straight and level (check flight instruments and visual) or minor deviation from. If UAV deviation cannot be trimmed or corrected by small control input then re-engage autopilot and reject H/O. Confirm using initially small inputs one at a time in pitch & roll (stick) and yaw (pedals) have an effect but not excessive effect on UAV (check flight instruments and visual). Larger but normal control inputs to be entered to show UAV is handling correctly. Check flight instruments and visuals to see that the inputs have an effect but not excessive effect on UAV. Set flight controls for straight and level flight. Change throttle by small increment and decrement. Check engine RPM readout that throttle inputs are reflected in RPM change. Put throttle back to original setting. Re-engage UAV autopilot. Note: Change to mission not checked as this would take UAV off track. If mission update is not working it has been shown that the UAV could be manually diverted. Note: It is assumed any change to the mission that is required is executed after the H/O has taken place. Manual Control: Switch / Knob or Point / Click Control Set flight control settings to match with current UAV altitude / airspeed / heading. (assumption: throttle controlled automatically). Disengage UAV autopilot – UAV flying straight and level (check flight instruments and visual). UAV continues to fly straight and level (check flight instruments and visual) or minor deviation from. If UAV deviation cannot be trimmed or corrected by small control input then re-engage autopilot and reject H/O. Initially small then larger but normal change in altitude has an effect but not excessive effect on UAV (check flight instruments and visual). Reset altitude to original setting. Initially small then larger but normal change in airspeed has an effect but not excessive effect on UAV (check flight instruments and visual). Reset altitude to original setting. Initially small then larger but normal change in heading has an effect but not excessive effect on UAV (check flight instruments and visual). Reset altitude to original setting. Re-engage UAV autopilot. Note: Change to mission or waypoint not checked as this would take UAV off track. If mission/waypoint update is not working it has been shown that the UAV could be manually diverted. Note: It is assumed any change to the mission that is required is executed after the H/O has taken place.

6A.3

6A.4

6A.5

6A.6 6A.7

6A.8

6B/. 6B.1 6B.2 6B.3

6B.4

6B.5

6B.6

6B.7

Page 62

Pass / Fail

Action If Failed ABORT ABORT

ABORT

ABORT

N/A ABORT

PD MA

N/A ABORT ABORT

ABORT

ABORT

ABORT

PD MA

3.14

Summary

The H/O procedure developed is that for a H/O of UAV control between two CSs as opposed to H/O between UAVps in the same CS but at different control desks. Although some aspects are common between the types of H/O such as the control desk in both cases has to be initialised, switching between CSs is more complicated as the DL switchover has to be coordinated among other things. For this reason the CS H/O Requirements and Procedure has been developed. The control desk H/O Requirements and Procedure would be a tailored version of CS version but this has not been implemented and is considered as further work. The Generic Checklist referenced as part of the H/O procedure would also be used unchanged for the control desk H/O in the CS. Section 3 of this project followed the left side of the proposed adapted ARP 4761 Safety Assessment diagram (Figure 3-3) to derive the H/O safety requirements. In doing so it examined what is required to H/O a UAV from CS1 to CS2. To H/O a UAV the CS UAVp has to have the capability to fly the UAV. UAV takeoffs and landings are out of scope for this project. To H/O a UAV from CS1 to CS2, firstly CS2 must be initialised and ready to take on the UAV. To H/O the UAV, CS1 must know CS2 is ready and then initiate controlled H/O of the UAV. If for some reason the H/O fails or CS2 is unable monitor and control the UAV, the control is to be returned to CS1. The functional block diagram Figure 3-4 and Figure 3-5 describes the functionality that is required to enable a UAVp to fly the UAV and was the basis on which the FFA was implemented. Most of the functionality required to fly a UAV is common to the CS types, only the HMI input of the CS types 1, 2 and 3 are what makes the functionality different. The FFA identified the hazards when the functions are not provided, provided when not required or provided incorrectly. The FFA identified numerous hazards associated with the CS functionality and were consolidated to remove multiple examples of hazards as show in Appendix D and used as part of the development of the CS requirements. As well as considering CS functionality, the data needed to fly and to H/O a UAV were analysed using HAZOPS analysis. As an input to HAZOPS analysis, Sneak Analysis was used. The results of the Sneak Analysis identified sneak paths e.g. the UAV making D/L connection to an unintended CS and also the incorrect display and labelling of data. The HAZOPS analysis was then used to derive the H/O requirements. HAZOPS analysis was used to analyse the data needed to fly a UAV both in terms of command and flight display to identify the consequences of data omission; commission; early; late or in error. From these consequences recommendations were identified and were consolidated to remove the multiple recommendations as shown in Appendix E.1. The consolidated hazards from the FFA (Appendix D) and the consolidated HAZOPS recommendations (Appendix E.1) were used to generate the requirements shown in section 3.10.6. To achieve a H/O a sequence of events must occur. The state diagram shown in section 3.11.2 was used to describe the H/O which was based on the handshake principle between CS1 and CS2. As well as for the CS data, HAZOPS analysis was also used to analyse the H/O sequence, the consolidated recommendations shown in Appendix E.2 were also used to generate additional CS requirements. For a H/O there are two types of D/L connections BBM and MBB that could be used, both of which were include in the analysis. Both types of connection have there hazards but BBM H/O is more awkward to implement but only requires the UAV to maintain a single D/L between it and the controlling CS. BBM is more awkward because only one CS can communicate with the UAV at a time so this path cannot be used as a way to coordinate the H/O. For this reason the H/O procedure based on BBM D/L was chosen. The BBM H/O procedure could also be used if required for MBB or be updated to take advantage of MBB multi communications paths but this is further work. Using the requirements and the proposed H/O state diagram a H/O Procedure shown in section 3.11.2.1 was generated describing the steps and coordinating messages CS1, CS2 and the UAV would need to pass between them to achieve a H/O. Referenced as part of this H/O Procedure is the Generic Checklist shown in section 3.13 generated as part of the Page 63

H/O Procedure to be used by CS2 UAVp to check the displays and controls are functioning correctly before accepting the UAV. The left hand side of the ‘V’ of the proposed adapted ARP 4761 Safety Assessment diagram (Figure 3-3) has therefore been achieved by the production of the H/O Requirements and H/O Procedure including the UAVp Checklist. A modified version of ARP 4761 has been used to define the process to identify the hazards, assess the risks, derive the safety requirements and produce the H/O Procedure to the point of acceptance into the SOP for the UAVS. However the SMM Safety Cycle goes further, ARP 4761 is about producing the product, the Safety Cycle is about continuing to monitor the efficacy of the procedure and improve / correct when necessary. Improvements to procedures can only be made after they start to be use under full operating conditions. The next stage of the project is to see how well the proposed H/O Requirements and H/O Procedure work when compared with an existing standard. The standard to be examined touched on in section 2.7.7 namely STANAG 4586 Ed 2.5. [NATO2, 2007]. Initially STANAG 4586 Ed 2.0 [NATO, 2005] was to be applied but Ed 2.5 [NATO2, 2007] became available so this later version has been used instead. However references to Ed 2.0 are made in section 4. 3.15

Further Work

In the proposed adapted ARP 4761 Safety Assessment diagram (Figure 3-3) the left side of the ‘V’ diagram has been achieved by the project as noted above. Going up the right side of the ‘V’ diagram are the various stages of testing and integrating the H/O procedure with other procedures. Initial testing of the H/O procedure is by using H/O scenarios to test the H/O procedure meets the requirements. On completion of testing the H/O procedure would be integrated with other procedures that will be required such as the H/O lost link procedure. The H/O lost link procedure would coordinate CS1 UAVp, CS2 UAVp and the UAV actions required to enable the D/L to be re-established with one of the CSs and not both. These and other procedures will form the CS’s Standard Operating Procedures (SOP). Once the procedure are integrated and tested then testing would continue using CS simulator trial of the procedures. On successful simulator trials the procedures would then be used using a UAV but under range trial conditions. Only on successful range trial testing would the procedures go on to be formally observed. What limitations would be placed on such procedures would depend on the UAV and where it would be allowed to fly. Getting the H/O procedure from the bottom of the ‘V’ diagram through the stages just described all comes under the category of future work for this project.

Page 64

4 Case Study – Comparison of Handover Requirements and Procedure to STANAG 4586 4.1

Introduction

In section 3 the H/O Requirements and H/O Procedure were developed. In this section the aim is to evaluate the developed H/O Requirements and H/O Procedure against an established standard. This standard is STANAG 4586 Ed 2.5 [NATO2, 2007], which was introduced in section 2.7.7 as a way providing a standard although military interoperability between UAVS. This will allow validation of the proposed procedure and assessment of the capabilities of the STANAG against the safety requirements identified in sections 3.10.6 and 3.11.4. 4.2

Scope

The overall scope of section 3 of the project covering the CS requirements covers a wider scope than that covered by STANAG 4586. Therefore there will be requirements that are out of scope of STANAG 4586. Some of the requirements that are out of scope of STANAG 4586 have been considered to be CS implementation specific. Other CS requirements also not covered by STANAG 4586 have been those classed as being covered by Standard Operating Procedures (SOP) which includes checklists that would be required and used by the crew while flying the UAV. Each UAV type/sub-type that the CS is certified to fly must have a SOP to cover that that UAV type/subtype. All UAV SOPs the CS is certified for must be available, whether only the SOPs needed for the day’s flying are to be carried by the CS or all the SOPs is a question for the regulators. However the UAVp must check that the SOPs for the UAVs to be flown are readily at hand in the CS. In section 2 of the project the pilot’s video display was switched as part of the H/O. This is out of scope of STANAG 4586 and so is not considered in section 4. UAV payload control is out of scope of the H/O procedure and so no STANAG 4586 messages concerned with payload are shown. 4.3

Assumptions

For H/O to be achieved there must be good communications link between CS1 and CS2 UAVps. This communications may be via Radio Telephony (RT) and or via the CCI data link including Voice Over Internet Protocol (VOIP). CS1 and CS2 UAVps both have RT comms with the ATC that covers the area that the UAV H/O is to take place. 4.4

STANAG 4586 messages

STANAG 4586 defines the messages used to communicate between the CS and the UAV these are the DLI messages but there are also the Command and Control Interface (CCI) messages. The CCI messages provided by STANAG 4586 provide a standard interface to a C4I system for the military command centre. For civil applications this is just as relevant in providing co-ordination and management of the CS operating and also providing ATC data. STANAG 4586 Edition 2.5 [NATO2, 2007] summarises the CCI data types as follows:

•

Tasking – UAV tasking messages as received from the appropriate tasking authority;

•

Air Traffic Control (ATC) – Data that should be sent or received from civil or military aviation authorities if the UAV has to pass through civil airspace;

•

Collateral Data – Supporting information that is required for the planning and execution of UAV missions, and which is not defined in the other data areas. This includes the tactical situation, target database, previously exploited imagery and environmental data; Page 65

• • • •

Mission Plan – As generated for a tasked mission; Mission Progress – Status as the UAV mission is in progress; Resource Availability – Status of the sub components of the UAV system; Payload/Sensor Data – Data received from the UAV payload(s), may be raw, processed or exploited;

• Target Data – Near real time target location data for targeting purposes; • Mission Reporting – Information on the outcome of a mission. The previous STANAG 4586 Edition 2.0 [NATO, 2005] in addition to the CCI data types noted above also included ‘Handover Control’ for handing over control of the air vehicle and/or payload to another CS the following but has now been removed for Edition 2.5. From this omission it must be concluded that the committee responsible for updating the STANAG believe no specific handover data messages are required. As H/O co-ordination between CS1 and CS2 UAVps is obviously required then the author can only assume that coordination is to be implemented purely by RT between the two UAVps. Some of the CCI data noted above is of a military nature but some of the information would be as applicable to civil use as it would be for military use or can be adapted. The types of CCI data messages are identified by STANAG 4586. Many of the messages identified are UCS Allied Data Publication-3 (AdatP-3) messages and are defined by STANAG 5500 [NATO, 5500, 2006] and STANAG 7149 [NATO, 7149, 2006]. A brief description of these and other CCI messages is provided by STANAG 4586, checking the applicability for civil application is considered as further work to be addressed. Other messages include ATC messages defined by ICAO Procedures for Air Navigation Services — Air Traffic Management [ICAO, 1996] and Mission Plan messages. From a civil operations point of view the CCI provides not only visibility of where your UAV assets are, their availability and the ability to re-task a UAV using standard CCI AdatP3 messages. It makes a lot of sense to be able to take a predefined infrastructure and use it negating the need to develop one from scratch. Ensuring CS2 UAVp has the latest version of the Mission / Flight Plan is essential, it may have been updated due to weather or ATC instructions since CS2 UAVp received the original mission / flight plan. Identified in the H/O Procedure in section 3 is a need to be able to pass the latest mission planning data from one CS to another. STANAG 4586 provides DLI the 800 series messages to update the UAV mission data. This does not provide the full picture. STANAG 4586 [NATO2, 2007] defines a mission plan as requiring a route plan, payload plan, data link plan, and emergency recovery plan. Currently there is no international standard agreed upon that fully defines these four elements of a mission / flight plan. However, there is an ongoing US initiative to specify a Common Route Definition (CRD). Currently the CRD ICD referenced by STANAG 4586 [NATO2, 2007] as version 2.0.2.0 but as yet has not been made a STANAG. 4.4.1

STANAG 4586 Message Used in Requirement Fulfilment

DLI messages in the following H/O requirement table are denoted by #No ‘DLI message title’. CCI ‘MISREP’ is the AdatP-3 Mission Report, which is a standard CCI message containing the UAV’s position among other data. Content of MISREP can be found in STANAG 5500 [NATO, 5500, 2006]. CCI ‘ATO’ is the AdatP-3 Air Tasking Order which is a standard CCI message from used to task or update a UAV’s mission the data from which is used to update the mission / flight plan. Where CCI #No is used signifies a standard DLI message is transmitted / broadcast on the CCI. The precedent for this can be found in STANAG 4586 Ed 2.0 [NATO, 2005] as part of Handover Control. Handover Control has been removed in STANAG 4586 Ed 2.5 [NATO2, 2007].

Page 66

4.5

Handover Requirements

The H/O Requirements generated in section 3 are shown below in column 2, column 3 provides how the H/O requirement is fulfilled or not by STANAG 4586. ID 1

Requirement Description UAV Handling

STANAG 4586 fulfilment of section 3 derived requirements

1.1

The UAV H/O shall be aborted if the UAV is controllable only by secondary effects of other flight controls. UAVp to abort H/O immediately.

1.2

The UAV H/O shall be aborted if it is found that the UAVp is unable to change UAV flight path. The UAV H/O shall be aborted it is found that the UAV is uncontrollable due to excessive or incorrect control surface response. If the UAV is exhibiting noticeable control glitches then the UAV H/O shall be aborted. UAV with no or inadequate rudder control can be accepted for H/O at receiving UAVp’s discretion. UAV Control Cut engine command shall be executed when weight on wheels is achieved or be confirmed by UAVp before cut engine is executed. If the CS has the capability to directly control the UAV throttle then the UAVp shall only accept the H/O if the UAVp is able to smoothly change the engine speed from min to max. The UAV H/O shall be aborted if UAVp commanded inputs result in excessive or incorrect response to airspeed, altitude or heading.

UAV handling properties are out of scope of STANAG 4586. However there is no message to abort the H/O and hand control back to CS1. The only other alternative is flight termination implemented by message #46 Flight Termination Command. As above.

1.3 1.4 1.5 2 2.1 2.2

2.3

2.4

The UAV H/O shall be aborted if UAVp commanded inputs result in no or minimal response in airspeed, altitude or heading.

2.5

When UAV control is only by mission / waypoint update (no direct CS control) and UAV does not respond to updates then UAV H/O shall be rejected. If D/L is via BBM, UAV H/O in manual control shall not to be attempted. If D/L is via MBB, UAV H/O in manual control can be executed if CS2 UAVp is ready and setup to take manual control of the UAV. For MBB D/L and UAV H/O is via manual control then the CS1 and CS2 D/L signal quality / strength shall be monitored. UAV shall not be under control of CS with low D/L signal quality / strength.

2.6 2.7 2.8

As above. As above. UAV handling properties are out of scope of STANAG 4586.

Engine cut logic is CS implementation specific, but is executed by message #45 Engine Command. Engine control is implemented by message #45 Engine Command, actual engine speed control depend on CS implementation on how message #45 Engine Command, field 5 is interpreted. Airspeed, altitude and heading inputs via message #43 Vehicle Steering Command, initial configuration via message #1301 Field Configuration Double Response. No H/O Abort available. Airspeed, altitude and heading inputs via message #43 Vehicle Steering Command, initial configuration via message #1301 Field Configuration Double Response. No H/O Abort available. Mission updated by message #800 Mission Upload Command, No H/O Abort available. SOP. SOP. SOP. Message #501 Data Link Status Report provides a measure of a combination of signal quality and strength.

Page 67

ID 2.9

2.10 2.11 2.12 2.13 3 3.1

3.2 4 4.1 4.2 4.3 4.4

4.5

4.6 4.7

Requirement Description For MBB D/L and UAV H/O is via manual control then the CS1 and CS2 D/L signal quality/strength shall be monitored. If D/L signal quality / strength for both CS start to become low then H/O is to be aborted. CS1 to bring UAV back into area with higher signal strength. CS shall not command either by manual control or by mission / flight planning that is not possible for the UAV to achieve. The UAV H/O shall not be initiated while D/L signal strength is low or fluctuating at a low level. Only one CS shall be in control of the UAV at a time. CS1, if in contact with UAV be able to take back control by issuing a H/O abort command. UAV Configuration UAVp shall, when in control of the UAV be able to change UAV configuration when commanded. During H/O using BBM D/L, while changing over D/L from CS1 to CS2 UAV shall fly autonomously following stored mission/flight plan. UAV Messages All messages shall identify who they are for and from. Any commands not meant for UAV or CS is to be ignored by receiving system. Messages shall be checked for corruption. Incoming messages shall be checked for corruption and if found to be corrupt rejected. Where continuity across a series of messages is required then a missing or corrupted message is to be resent.

Where a series of part messages or message sequence are required to be sent then a method of identifying that all the parts or sequence have been received, are not corrupt and are in the right order before execution shall be employed. CS1, as part of the H/O initiation message shall send the UAV dish coordinates for CS2 along with communication frequencies and the CS ID. If CS2 is not responding to CS1 H/O commands promptly, or there is a possibility of D/L to UAV may be lost before H/O is completed then CS1 UAVp shall abort H/O.

Page 68

STANAG 4586 fulfilment of section 3 derived requirements SOP.

UAV limits built into VSM also Mission Planning to take into account UAV operational limitations. SOP. Message #501 Data Link Status Report provides a measure of a combination of signal quality and strength. VSM via message #1 CUCS Authorisation Request provides the control so only one CS in control of UAV. CS1 could take back control via message #1 CUCS Authorisation Request via Override Control option. Implementation specific, No specific message to control U/C, flaps etc but can monitor via message #104 Vehicle Operating States. Assumed implemented via vehicle specific messages #2000 - #2399. SOP to ensure UAV is on auto pilot during H/O.

Achieved by message header. See section 4.6. Achieved by message wrapper See section 4.6. CS implementation specific. Resend achieved by using message #1400 Message Acknowledgement to acknowledge each message block sent where push / pull message pairs are not used. For frequently sent messages missing the odd message would be unlikely of any consequence. Achieved by message wrapper (see section 4.6), instance of message noted and also if in a sequence the sequence number noted and if last in sequence Achieved by message #600 Vehicle Data Link Transition Coordination but CS2 position sent to UAV not the coordinates. STANAG 4586 doesn’t cover H/O coordination. If H/O is not achieved within set time period as set by #600 Vehicle Data Link Transition Coordination, D/L switched back to CS1.

ID 5 5.1 5.2 5.3 5.4

5.5

5.6

5.7

5.8

5.9

5.10

5.11

5.12

Requirement Description Displays If flight instruments continue to be blank or frozen after D/L is established during H/O then the H/O is to be aborted. A clear indication to UAVp when UAV autopilot is engaged or disengaged. UAV with no or unusable UAV video can be accepted for H/O at receiving UAVp’s discretion. Position data for the incoming UAV may be displayed prior to handing off current UAV. If so shall be clearly identified as the incoming UAV and not the current UAV. The UAV H/O will be aborted unless extenuating circumstances exist at receiving UAVp’s discretion as to why an accurate position for the UAV is not critical to the safe operation of the UAV (e.g. fly on visuals to land UAV). Mission is to be aborted and UAV landed at earliest opportunity. The UAV H/O will be aborted unless extenuating circumstances exist at receiving UAVp’s discretion as why an accurate altitude for the UAV is not critical to the safe operation of the UAV (e.g. fly on visuals to land UAV). Mission is to be aborted and landed at earliest opportunity. If UAVp aware that data display error is due to display mislabelling or incorrect scaling then UAVp’s discretion if UAV H/O accepted or rejected. Mission is to be aborted and UAV landed at earliest opportunity. If airspeed is not provided or incorrect then the mission is be aborted and the UAV landed at earliest opportunity. UAVp’s discretion if UAV H/O accepted or rejected as airspeed can be estimated from other flight instruments. If heading is not provided or incorrect then the mission is be aborted and the UAV landed at earliest opportunity. UAVp’s discretion if UAV H/O accepted or rejected as heading can be estimated from other flight instruments. The UAV H/O will be aborted unless extenuating circumstances exist at receiving UAVp’s discretion as to why an accurate attitude for the UAV is not critical to the safe operation of the UAV (e.g. fly on visuals to land UAV). Mission is to be aborted and landed at earliest opportunity. If engine RPM is not provided or incorrect then the mission is be aborted and the UAV landed at earliest opportunity. UAVp’s discretion if UAV H/O accepted or rejected as engine RPM can be estimated throttle position and airspeed. If UAV system status (fuel, engine etc) not provided then UAVp to accept UAV H/O but mission shall be aborted and UAV landed at landed at earliest opportunity.

STANAG 4586 fulfilment of section 3 derived requirements There is no message to abort the H/O and hand control back to CS1. CS implementation specific, state of autopilot provided by message #106 Vehicle Operating Mode Report. Out of STANAG 4586 scope. CS implementation specific, achievable by the use of CCI MISREP or CCI #101 Inertial States transmitted from CS1 to CS2. SOP.

SOP.

SOP. CS implementation specific.

SOP.

SOP.

SOP.

SOP.

SOP.

Page 69

ID 5.13 5.14 5.15

5.16

5.17

5.18

Requirement Description If mission map display continues to be blank or frozen after D/L is established during H/O then the H/O is to be aborted. If other air traffic position and track are available then they shall be displayed on the mission map. If fuel available display continues to be blank or frozen after D/L is established during H/O then the H/O is to be aborted and UAV landed at landed at earliest opportunity. If UAV system status display continues to be blank or frozen after D/L is established during H/O then the H/O is to be aborted and UAV landed at landed at earliest opportunity. If D/L signal strength display continues to be blank or frozen after D/L is established during H/O then the H/O is to be aborted and UAV landed at landed at earliest opportunity. The scaling and display units normally used for individual flight data parameters shall be used as default when flight data is displayed.

5.19

UAVp shall be informed by the CS when the UAV is under their control.

5.20

If D/L is switched back to CS1 due to failure at some stage of the H/O, CS1 shall be informed UAV is under CS1 control and reason D/L returned.

5.21

System H/O stage shall be displayed to UAVps.

5.22

System shall inform UAVp if incorrect or inappropriate command has been entered. Monitoring Track and altitude of UAV shall monitored by the UAVp throughout the period the UAV is in his charge. UAVp shall monitor the UAV to check that the UAV is achieving commanded mission targets. UAVp shall monitor the mission map display periodically against the real world and UAV to check that the mission map is providing an accurate picture. If other air traffic position and tracks are displayed on the mission map they are to be maintained and monitored.

6 6.1 6.2 6.3 6.4

Page 70

STANAG 4586 fulfilment of section 3 derived requirements SOP. CS implementation specific. CS implementation specific, achievable by the use of CCI MISREP or CCI #101 Inertial States broadcast from other CS. SOP.

SOP.

SOP.

CS implementation specific, generic flight displays provided in specific units, UAV specific displays can be configured with different display units. CS implementation specific, data provide by message #21 VSM Authorisation Response. STANAG 4586 doesn’t cover H/O coordination. Switch back to CS1 only if D/L not established within timeout set by #600 Vehicle Data Link Transition Coordination. Result of H/O whether pass or fail provided by message #700 Handover Status Report. How this is presented to UAVp is CS implementation specific. CS implementation specific. STANAG 4586 doesn’t cover H/O coordination. CS implementation specific.

SOP. SOP. SOP. Monitoring is SOP. CS implementation specific, is achievable by the use of CCI MISREP or CCI #101 Inertial States broadcast from other CS.

ID 6.5

7 7.1

Requirement Description Fuel available to be monitored by UAVp and checked against mission / flight plan estimates. If fuel available is low then the UAV landed at landed at earliest opportunity. Data No UAV H/O shall be executed if the UAV tail ID is either not provided or does not match that identified in the flight/mission plan.

7.2

No UAV H/O shall be executed until CS1 has provided / confirmed the UAV type.

7.3

The UAV H/O shall be aborted if UAV type identified in the initial UAV message does not match that expected by the receiving H/O CS.

7.4

UAV shall not to be flown without flight plan / mission loaded in the UAV that covers the H/O to landing the UAV. The position data for next UAV if received before current UAV is dealt with shall be stored separately, away from current UAV data. CS Set-up CS2 UAVp shall as part of the mission/flight plan be allowed reasonable time to reconfigure and initialise the CS.

7.5 8 8.1

8.2 8.3 8.4

8.5 8.6 8.7 8.8

CS2 UAVp shall follow a checklist to fully reconfigure and initialise CS. Co-pilot shall be used (if applicable) to double check checklist actions by the pilot to reconfigure and initialise CS. Mission map display shall be initialised with the map loaded at the correct scale and positioned for the next UAV mission as part of the CS initialization prior to UAV H/O. CS Alert / Warning annunciation shall be checked as part of the CS initialization prior to UAV H/O. UAV related Alert / Warnings received by CS1 shall be passed to CS2 electronically and/or orally prior to start of H/O. CS2 shall preset the ATC frequencies as part of the CS initialization prior to UAV H/O. CS1 and CS2 shall not operate without Standard Operating Procedures (SOP) resident in the CS and that cover the UAVs that are to be handled.

STANAG 4586 fulfilment of section 3 derived requirements SOP.

To enable H/O to be executed UAV ID required. Message #20 Vehicle ID correlates UAV ID to Tail No. SOP to check UAV data from CS1 and mission / flight plan before H/O takes place. To enable H/O to be executed UAV ID required. Message #20 Vehicle ID correlates UAV ID to Tail No. SOP for CS2 UAVp to check UAV data from CS1 and mission / flight plan before H/O takes place. If UAV ID incorrect for intended UAV then D/L would not be established. Message #20 Vehicle ID correlates UAV ID to UAV type/subtype and Tail No. SOP for CS2 UAVp to check UAV data from CS1 and mission / flight plan before H/O takes place. If UAV ID incorrect for intended UAV then D/L would not be established and D/L switched back to CS1 after timeout period. SOP for mission / flight plan to cover whole mission but could be updated during mission to reflect changing circumstances. CS implementation specific.

SOP to plan time for CS2 UAVp to initialise CS. SOP for CS2 UAVp to follow checklists before requesting control of UAV. Examples in section 2 where this has been broken resulting in UAV incident. SOP and also CS implementation specific. SOP. SOP and also CS implementation specific.

SOP and also CS implementation specific. CCI #1100 Subsystem Status Alert Message and /or CCI #1101 Subsystem Status Report. SOP and also CS implementation specific. SOP contained in Operations Manual and /or Flight Manual see note at end of table.

Page 71

ID 8.9 8.10

Requirement Description CS2 UAVp shall check any data provided by CS1 for errors and consistency. CS1 / CS2 comms shall not be via the UAV. When communications to the UAV is lost this is the time when inter UAVp communications is most needed.

9 9.1

Communications CS1 and CS2 shall initiate communications with ATC to inform them that a UAV H/O is about to take place and to get an update on the weather and traffic in the area. CS1 and CS2 shall use their respective call-signs, UAV call-sign and that of the ATC in any communication with ATC. If CS1 and CS2 do not have clear communications with ATC and with each other then the UAV H/O shall not be initiated. When CS1 or CS2 are communicating with ATC and each other it shall be obvious to the CS transmitting when they are transmitting. During H/O any emergency involving UAV shall be coordinated by CS1. CS1 shall follow SOP when declaring an emergency to ATC CS UAVp gains control of UAV shall inform the other CS UAVp of this. When D/L to UAV has been lost during H/O, CS1 and CS2 shall follow SOP to regain D/L coordinated by CS1. If CS2 D/L is found to have and continues to have over a period (TBD) poor signal quality / strength such that the messages are received but the data is corrupt then the D/L shall be switched back to CS1. H/O Coordination UAV H/O shall follow a coordinated sequence documented by a common SOP to both CS UAVps and is understood by both UAVps.

9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9

10 10.1

10.2 10.3 10.4

If CS2 is unable to take the UAV then CS1 must coordinate with ATC to loiter UAV until CS2 is ready or land UAV at pre-planned alternative landing area. If H/O continues on outside H/O window then CS2 UAVp is in control of UAV as CS1 will be out of range. CS2 shall still confirm acceptance of H/O to UAV and CS2 even if H/O continues outside of H/O window effectively giving UAV control by default.

STANAG 4586 fulfilment of section 3 derived requirements SOP to check UAV data and mission / flight plan from CS1. Latency constraint of 250 ms as per RTCA DO-225, however use of D/L for ATC comms is not precluded. STANAG 7085 allows for audio channel. SOP.

SOP to use UAV call-sign but also to use CS call-sign as UAV independent of CS. CS call-sign is not part of STAG 4586. SOP. CS implementation specific. H/O instantaneous, coordination by whoever has or had UAV last. SOP – CS but not necessarily CS1, whoever was responsible for UAV. SOP. SOP. Message #600 Vehicle Data Link Transition Coordination provides the function to switch D/L to CS1 only if D/L is not established within timeout set. CS1 and CS2 may not necessarily be of the same type. Although the intent of SOP is to be common to both CS, adjustments to respective SOPs may be required to cover particular CS configuration. SOP. In terms of STANAG 4586, as soon as D/L established CS2 UAVp is in control and responsible for UAV. In terms of STANAG 4586, as soon as D/L established CS2 UAVp is in control and responsible for UAV.

Table 4-1; Fulfilment of Handover Requirements by STANAG 4586 Note: SOP defined by either Operations Manual or contained in separate flight manual. Under CAP 393 Air Navigation Order article 38(2)I ‘each flight every member of the crew has access to a copy of every part of the operations manual which is relevant to his duties on the flight’. SOPs to be defined by the UAV Operator coving both normal and abnormal conditions under which the CS crew may find themselves under. SOPs to be provided to CAA under article 38.

Page 72

4.6

STANAG 4586 Fulfilment of Handover Requirements

This section provides a fuller explanation of how STANAG 4586 fulfils the H/O Requirements than was practicable within the table in section 4.5. 4.6.1

STANAG Message Structure

H/O requirement in section 4 ‘UAV Messages’ of the above table places the requirements on the messages passed between the CS and UAV. Message requirement 4.1 requires that messages identify who they are from and who they are for. Message requirements 4.2 and 4.3 require checks for corruption. Message requirements 4.4 and 4.5 require being able to detect if a message has not been received. These requirements are met by STANAG 4586 section 3.3 in the following way. For transmission the message data is incorporated into a ‘wrapper’ structure. This structure is made up of a header, the message data, and finally a checksum as shown below in Figure 4-1:

IDD Version Msg Instance ID Message Type Message Length

Interface Definition Document Version that defines the structure (STANAG 4586 version) Instance Number Number of bytes in body

Stream ID

Unique stream for each source/destination pair

Packet Seq #

Reassembly sequence number

Message Data Checksum

STANAG 4586 [NATO2, 2007]

Figure 4-1; STANAG 4586 Message Wrapper In addition to the checksum, the header includes other features to detect corruption or loss of a message or part of a message: • The instance of a message of a given type for a given stream is tracked. This allows dropped messages of a message type to be identified. Identifying the message stream assumes that there can be more then one message steam which is a future capability of STANAG 4586;

•

The message length identifies the number of bytes in the message data part of the structure;

•

Where a message is made up of parts the packet sequence identifies as the name suggests the position of this instance of the message in the sequence. The last message in the sequence is identified as such by making the sequence number negative. If a message is lost it is identified when another message turns up and is out of sequence. Ideally knowing how many messages makes up the sequence and if not received within a time period then it can be requested to be resent. It should be obvious that a message is missing assuming there is a near continuous / regular stream of data being passed between the CS and UAV and visa versa. Some of the STANAG 4586 messages elicit a response, in effect an acknowledgement of the original message. STANAG DLI messages are labelled as ‘Push’ or ‘Pull’ type of messages. Push messages are broadcast either periodically or based on some event, but do not require a request to result in sending a message. Pull messages are generated in response to a request. Message #1401 is used to configure the VSM or CS to acknowledge a message where push/pull message pairs are not implemented; message #1400 is then used to acknowledge the message. No STANAG 4586 message has been identified to directly initiate a message resend of a missing or corrupted message. Page 73

All messages are time stamped as part of the Message Data Header as shown in Figure 4-2 below using Universal Coordinated Time (UCT) which is the time in seconds since January 1st 1970. Therefore it can bee seen if the same message is received twice. Requirement 4.1 is fulfilled by the message data header shown below in Figure 4-2 which provides the UAV and CS ID so determining, depending from who it is being sent (i.e. CS or UAV), how the CS and UAV IDs are interpreted:

Time Stamp Vehicle ID CS ID

At the top of all message data

● ● VSM ID

In applicable messages

Data Link ID

STANAG 4586 [NATO2, 2007]

Figure 4-2; STANAG 4586 Message Data Header The UAV, CS, VSM and also each Data Link are given unique IDs with respect to there type. In theory, although STANAG 4586 does not advise it, a CS controlling a UAV via a D/L could have the same ID number. The ID as noted above is unique in that it applies to the type e.g. the UAV. The ID in each case is of 2 parts: • The standard NATO country code of origin;

•

Unique code assigned at commissioning time by country of origin. In theory if the country of origin sold on say the UAV then the UAV would be assigned a new ID w.r.t. the new owners. With respect to requirement 4.1 who the message is for and who its from has been satisfied, the second part of keeping quiet if the message received is not for the system receiving would be an implementation issue. 4.6.2

Providing UAV Position Data

Requirement 5.4 covers the display of the incoming UAV’s position prior to H/O, also requirement 5.16 covers the display of the position of other traffic in the area. In both cases it is to aid the UAVp’s SA. This can be achieved by the use of the AdatP-3 message F031MISREP; this is the Mission Report message providing among other items of UAV data the position of the UAV. Alternatively message #101 Inertial States which also includes UAV position could be transmitted on the CCI the precedent for this is noted in section 4.4.1. If the CSs on the CCI connected network regularly issue MISREP or #101 messages this would provide the raw data to enable requirements 5.4 and 5.16 to be met. 4.7

STANAG 4586 Handover

The STANAG 4586 implementation of the H/O Procedure shown in section 4.8 is based on the STANAG 4586 Implementation Guideline Document [IGL, 2004] CUCS VSM Connection Sequence and the Non-Positive Transfer Procedure. This is for a BBM D/L transfer. The Positive Transfer Procedure in STANAG 4586 Implementation Guideline Document [IGL, 2004] would be that implemented for a MBB D/L. 4.7.1

Assumptions

The H/O is via a BBM D/L which therefore does not allow CS2 to interrogate the UAV prior to H/O. UAV payload control is out of scope of this H/O procedure and so no STANAG 4586 messages concerned with payload are shown. For H/O to be achieved there must be good communications link between CS1 and CS2 UAVps. This communications may be via RT and or via the CCI data link including VOIP. CS1 and CS2 UAVps both have RT comms with the ATC that covers the area that the UAV H/O is to take place. Page 74

4.7.2

STANAG 4586 Message Used in Requirement Fulfilment

DLI messages in the following H/O requirement table are denoted by #No ‘DLI message title’. CCI ‘MISREP’ is the AdatP-3 Mission Report, which is a standard CCI message containing the UAV’s position among other data. Content of MISREP can be found in STANAG 5500 [NATO, 5500, 2006]. CCI ‘ATO’ is the AdatP-3 Air Tasking Order which is a standard CCI message from used to task or update a UAV’s mission the data from which is used to update the mission / flight plan. Where CCI #No is used signifies a standard DLI message is transmitted / broadcast on the CCI. The precedent for this can be found in STANAG 4586 Ed 2.0 [NATO, 2005] as part of Handover Control. Handover Control has been removed in STANAG 4586 Ed 2.5 NATO [2007]. STANAG 4586 Messages Used to Implement H/O Msg # 1 20 21 42 43 100 100 101 103 104 400 401 402 403 404 500 501 502 503 600 700 800 1200 1201 1202 1203 1300 1301 1302 1303 1304 1400 1401

Description CUCS Authorisation Request. Vehicle ID. VSM Authorisation Response. Vehicle Operating Mode Command. Vehicle Steering Command. Vehicle Configuration. Vehicle Configuration. Inertial States. Body-Relative Sensed States. Vehicle Operating States. Data Link Set Up Message. Data Link Control Command. Pedestal Configuration Message. Pedestal Control Command. Data Link Assignment Request. Data Link Configuration/Assignment Message. Data Link Status Report. Data Link Control Command Status. Pedestal Status Report. Vehicle Data Link Transition Coordination. Handover Status Report. Mission Upload Command. Field Configuration Request. Display Unit Request. CUCS Resource Report. Configuration Complete. Field Configuration Integer Response. Field Configuration Double Response. Field Configuration Enumerated Response. Field Configuration Command. VSM Services Report Message. Message Acknowledgement. Message Acknowledge Configuration.

Table 4-2; STANAG 4586 Messages Used to Implement H/O Page 75

4.8

Handover Procedure

The H/O Procedure developed in section 3 is the baseline from which STANAG 4586 messages are interleaved as inserted tables into the H/O Procedure to implement procedure actions for example to set up the D/L. CS1 sourced STANAG 4586 message tables have been shown left justified, CS2 sourced STANAG 4586 messages tables have been shown right justified. 4.8.1

Pre-Handover Procedure

CS1 Actions

CS1 H/O Commands

CS2 Actions

CS2 H/O Commands

Close D/L with landed or handed over UAV (if applicable). Close comms with ATC and CS associated with previous UAV (if applicable). Check / clear command buffers for any commands meant for previous UAV. Log then clear errors relating to previous UAV (if applicable).

Establish Comms with CS2. Confirm UAV Tail_No and Type_ID with CS2. Confirm Mission_ID and version with CS2. If CS2 has not got latest mission version transfer latest version. CS1 declares any problems with the UAV to CS2. Transfers any relevant UAV error/failure data to CS2. Provide CS2 with latest UAV position, altitude, heading and estimated time to start of H/O window. The H/O window is defined by the mission plan. This is in terms of the start position of the window the H/O can start to the end of the window at which the H/O must be completed by before the UAV reaches this position.

Page 76

CCI + RT comms established CS2 CCI #20 Vehicle ID CS2 CCI Mission Plan CS2 CCI #1100 Subsystem Status Alert (if any) CS2 CCI MISREP CS2 Or CCI #101 Inertial States CCI #102 Air and Ground Relative States CS2

Check for errors / failures relating to CS and log. Correct any errors if possible. Decision to be made by UAVp if any errors / faults not cleared whether these will prohibit handover acceptance of UAV. Establish comms with CS1. Confirm Tail_No and Type_ID of UAV to be handed over. Confirm mission / flight plan Mission_ID and version, if not latest get from CS1. Checks UAV error/failure data transferred from CS2. CS2 UAVp provides CS1 UAVp with estimate for time when ready for UAV H/O.

CCI + RT comms established CS1

CS1 Actions

CS1 H/O Commands

Contact ATC to inform of H/O and for an update of the traffic in the area.

RT

4.8.1.1

ATC

CS2 Actions Configure CS w.r.t. UAV Type_ID (load VSM corresponding to UAV_Type).

CS2 H/O Commands See 4.8.1.1 below

STANAG 4586 Configuration of CS2 User Interface

The VSM is selected to provide the STANAG DLI interface to UAV. One selected VSM provides the CS configuration data to allow the controls generic flight instruments to be setup. In addition VSM identifies the D/L ID to allow the CS D/L to be configured (implemented in section 4.8.2.1). CS2 #1 CUCS Authorisation Request Broadcast Request – (optional) If the VSM ID is not known CS2 UAVp broadcasts a request to all VSM modules on the network CS2 is connected to for the VSM(s) covering the UAV type/subtype to be flown.

VSM

#21 VSM Authorisation Response Broadcast Response Applicable VSM(s) on system respond with #21 indicating the UAV(s) that can be controlled by VSM. UAV in question is currently being flown by CS1 so CS2 is not allowed to control unless overrides CS1 or CS1 releases UAV. #1200 Field Configuration Request VSM required is identified; CS2 requests configuration data from selected VSM to enable CS2 to configure the displays. #1203 Configuration Complete The CS transmits Message #1203 to identify that it has sent all configuration requests to the VSM for the specified vehicle/ vehicle type. General Configuration Response Messages #1300 Field Configuration Integer Response #1301 Field Configuration Double Response #1302 Field Configuration Enumerated Response #1303 Field Configuration Command VSM provides the configuration data to allow the CS generic flight instruments to be setup. UAV specific displays can only be setup once H/O is established. Specific Configuration Messages #20 Vehicle ID #100 Vehicle Configuration Messages #20 and #100 provide what VSM selected knows about UAV it is to control (no link to UAV established at this point).

Page 77

CS2

4.8.2

Pre-Handover Procedure – Continued 1.

CS1 Actions

CS1 may provide on request from CS2 the current UAV status.

Page 78

VSM #500 Data Link Configuration VSM identifies its Data link configuration to the CS. #1203: Configuration Complete VSM reports to the CS after all configuration message reports have been transmitted.

CS1 H/O Commands

CCI MISREPCS2

CS2 Actions UAVp is to check the UAV information provided by the VSM against that received from CS1 UAV data and mission / flight plan. Get mission / flight plan updates from other sources (e.g. HQ) via CCI ATO (Air Tasking Order) or other CCI tasking messages updating current mission / flight plan. Get Met data for mission area and time period. Amend mission / flight plan w.r.t. updates and predicted weather for mission / flight plan segment UAVp is to be responsible for. Translate mission ready for uploading to UAV (mission/flight plan uploaded when H/O completed). Set CS switches for UAV configuration (pitot heat, deicing – UAV specific message), navigation lights (#44 Air Vehicle Lights), UAV autopilot on (#42 Vehicle Operating Mode Command) initiated on H/O. If applicable, check stick / pedal controls for full and free movement. Set controls for UAV for straight and level flight. Trims mid position, flaps 0 degrees, undercarriage up. Throttles set for cruise – initiated on H/O (#43 Vehicle Steering Command). Check alert / warning annunciator operation. If applicable, knobs and switches set for handover altitude, airspeed, heading and next waypoint.

CS2 H/O Commands

CCI ATO

Get Met Data

CS1 Actions

Set UAV in autopilot if not already in this mode ready for H/O.

4.8.2.1

CS1 H/O Commands

CS2 Actions

CS2 H/O Commands

CCI #1101 Subsystem Status Report CS2 #42 Vehicle Operating Mode Command

Set frequency for ATC, also frequencies for D/L command /video link/ payload.

Configure D/L – see 4.8.2.1 below Set dish (pedestal) position – see 4.8.2.1 below

Calculate CS D/L dish position based on start of H/O window. Position D/L dish.

STANAG 4586 Configuration of the CS2 Data Link

CS2 requests VSM to setup D/L parameters and pedestal (dish) position. CS2 #404. Data Link Assignment Request CS requests a D/L assignment for controlling the AV.

VSM

#500 Data Link Configuration The VSM assigns a D/L to the CS for control. #400 Data Link Setup Message #401 Data Link Control Command #402 Pedestal Configuration Message #403 Pedestal Control Command CS2 sends messages to the VSM to configure the D/L Ground Data Terminal (GDT) and set pedestal position for H/O. #501: Data Link Status Report #502: Data Link Control Command Status #503: Pedestal Status Report VSM reports status of the GDT and pedestal.

4.8.3

Pre-Handover Procedure – Continued 2.

CS1 Actions

CS1 H/O Commands

CS2 Actions

CS2 H/O Commands

Set transponder setting (#1500 IFF Code Command) initiated on H/O. Note only mode 3/A catered for, no Mode S included in STANAG 4586. Load maps for moving map display. Confirm expected track displayed in expected position.

Page 79

CS1 Actions

CS1 H/O Commands

CS2 Actions Check displays are displayed with expected units and map displays are at the correct scale. Set altimeter pressure altitude (#43 Vehicle Steering command) initiated on H/O. Contact ATC to inform of H/O and for an update of the traffic in the area. CS2 initialisation and set-up complete.

CS2 H/O Commands RT  ATC

The following part of the procedure is not implemented by STANAG 4586 but could be implemented aurally between the CS UAVps. Original procedure not implemented by STANAG 4586 CS2 is ready sent to CS1. UAV in position at start of H/O window. CS1 is ready sent to CS2.

4.8.4

CS2_Ready

CS1_Ready

Pre Handover Summary

In the Pre Handover section of the H/O Procedure it has been shown that STANAG 4586 provides the messages to allow the UAVp to identify and select the correct interface (VSM) for the UAV to be flown. DLI messages provided by the VSM also allow CS2 to configure and initialise the controls, flight displays and the D/L ready for the H/O to take place. STANAG 4586 does not provide any UAVp pre-H/O coordination; this must be provided along with ATC coordination as part of an associated H/O Procedure such as the above. Due to how STANAG 4586 operates there is a change from the original H/O procedure shown in section 3.12.1, in the original procedure CS2’s ID, D/L frequencies and the UAV’s dish coordinates for the D/L are sent prior to the initiation of the H/O. In the STANAG 4586 version this data is sent to the UAV at the initiation of the H/O via message #600. The other difference is that message #600 sends CS2’s position to the UAV for it to work out the D/L dish coordinates, which is a better solution. 4.8.5

Initiation of H/O

At this point in the H/O Procedure CS2 is ready to accept control of the UAV. This is where STANAG 4586 and the H/O Procedure differ. In STANAG 4586 CS2 initiates a request to take over the UAV and waits for CS1 to release the UAV. In the H/O Procedure CS1 initiates a hand shake with CS2 to ensure CS2 was ready. CS1 then provides the UAV with the information it needs to switch over the D/L to CS2. If D/L failed after some undefined period then the D/L is switched by the UAV back to CS1. In STANAG 4586 Ed 2.0 under CCI Handover Control had a provision to provide handover control and acknowledgement but this has now been removed in Ed.2.5. Using message #600 as shown in section 4.8.6.1 below, provides the facility to pass over to UAV CS2’s parameters; set a timeout period for the H/O and initiate the H/O. Message #600 equates to the CS1_Initiate_HO command. See Control Station UAV H/O State Diagram Figure 3-7 for the CS1_Initiate_HO command.

Page 80

4.8.5.1

STANAG 4586 CS2 Request to Take Over UAV Control

CS2 requests and therefore is ready to take control of UAV, corresponding message #21 is received when CS1 releases control and CS2 has control. CS2 has to be waiting for H/O before CS1 releases UAV otherwise UAV is flying autonomously. This command would be equivalent to CS2_Ready in the proposed procedure but is not sent to CS1; there is no equivalent to CS1_Ready. CS2 .#1: CUCS Authorization Request CS requests control over a specific Vehicle/ Vehicle type.

4.8.6

Handover Procedure.

CS1 Actions CS1 starting H/O sent to CS2 Transmit to the UAV the following: a) CS2’s unique ID (equivalent of the UAV’s tail number); b) Frequencies for CS2 D/L command /video link/ payload; c) CS2’s position to allow UAV to calculate dish position to enable comms to be established to CS2 on initiation of H/O. CS1 transmits initiate H/O to UAV and CS2

4.8.6.1

VSM

CS1 H/O Commands CS1_Start_HO Implemented as part of #600. See section 4.8.6.1 below.

CS2 Actions

CS2 H/O Commands

CS2 acknowledges start of H/O.

CS2_Ackn (equivalent to #700). See section 4.8.6.1 below.

CS1_Initiate_HO (equivalent to #600). See section 4.8.6.1 below.

STANAG 4586 CS1 Release of UAV

Message #600 not only releases CS1’s control of the UAV but also provides the UAV with the following data: a) CS2’s unique ID (equivalent of the UAV’s tail number); b) CS2’s position to allow UAV to calculate dish position to enable comms to be established to CS2 on initiation of H/O; c) CS2’s comms parameters; d) Timeout (seconds) by which H/O is be established or control returned to CS1. This is equivalent to the UAV_DL_Init_Fail shown in Control Station UAV H/O State Diagram Figure 3-7.

Page 81

Message #700 provides the feed back to CS1 that that the H/O of control has been successful effectively providing the equivalent of UAV_Link_Change to CS1 in State Diagram Figure 3-7. CS1 #600 Vehicle Data Link Transition Coordination CS1 releases UAV but also provides UAV with CS2 position and D/L parameters.

VSM (CS1)

#700 Handover Status Report Confirmation of H/O status to CS1.

4.8.7

Handover Procedure – Continued 1.

As noted above UAV_Link_Change is effectively implemented by message #700. Once the D/L between the UAV and CS2 is established message #21 informs CS2 it has control which effectively implements command CS2_DL_Estb. UAV Actions Acknowledgement of link change transmitted to CS1. UAV transmits link establish to CS2.

4.8.7.1

UAV H/O Commands UAV_Link_Change (to CS1) UAV_Link_Estb

CS2 Actions

CS2 checks that the message is from UAV expected. If message is from the expected UAV to CS2, CS2 responds to UAV by transmitting D/L established to UAV. However if UAV is not the UAV expected message sent to UAV to reject D/L. If the message received is not for CS2 (i.e. CS_ID is not that of CS2) message is ignored.

CS2 H/O Commands

CS2_DL_Estb

STANAG 4586 Confirmation of UAV Control by CS2

CS2 informed that it is now in control of UAV. CS2

Page 82

VSM #21: VSM Authorization Response (CS2) VSM grants CUCS control over specified vehicle/ Vehicle Type.

4.8.7.2

STANAG 4586 Initialisation of UAV Specific Displays

VSM provides configuration data to initialise the UAV specific displays. CS2 Setup vehicle specific displays #1201 Display Unit Request #1202 CUCS Resource Report Vehicle specific displays are setup once the D/L to UAV has been established. The message provides the VMS with the remote display resources the CS has available to display UAV specific information.

4.8.8

VSM #1304 VSM Services Report Message This message provides the CS with the address of the VSM homepage and FTP addresses for remote display services provided by the VSM.

Handover Procedure – Continued 2

CS2 UAVp Provided With Flight Data and Control of UAV. UAV Actions UAV link to CS2 now established. UAV starts down loading UAV flight data (altitude, heading, airspeed, position etc).

4.8.8.1

UAV H/O Commands See section 4.8.8.1.

CS2 Actions CS2 flight displays now displaying UAV supplied data.

CS2 H/O Commands See section 4.8.8.1.

STANAG 4586

Transfer of control data and flight display data from CS2 and UAV respectively via STANAG 4586 messages. CS2 CS Command Messages -> #42 Vehicle Operating Mode Command #43 Vehicle Steering Command …etc. CS controls the UAV / payload.

VSM