civil airworthiness for a uav control …mark/projects/cjh507_project.pdf · civil airworthiness...

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.

Page ii

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 iii

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 iv

List of Contents Abstract ii

Statement of Ethics ii

List of Contents iv

Abbreviations and Acronyms vii

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

2 Literature Overview 3 2.1 Overview 3 2.2 A Brief History of UAV 3 2.3 Functions of a CS 5 2.4 Airworthiness Certification 7 2.5 UAV Operations 8 2.6 Situational Awareness 16 2.7 CS Design 17 2.8 Summary 36 2.9 Focus for Project Development 37

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

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

Page v

4.6 STANAG 4586 Fulfilment of Handover Requirements 73 4.7 STANAG 4586 Handover 74 4.8 Handover Procedure 76 4.9 Requirement Fulfilment by STANAG 4586 85 4.10 Problems with the Theoretical Model 86 4.11 Conclusions 87

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

6 References 91 Appendixes

A CAA CAP 722 95

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

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

D Consolidated FFA Hazards 105

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

Figures

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

Page vi

Tables

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

Page vii

Abbreviations and Acronyms AAIB Air Accident Investigation Board AdatP-3 Allied Data Publication-3 ADT Air Data Terminal AMS Aero Medical Section ANO Air Navigation Order ASTRAEA Autonomous Systems Technology Related Airborne Evaluation &

Assessment ATC Air Traffic Control ATO Air Tasking Order ATPL Airline Transport Pilot Licence AW AirWorthiness BBM Break Before Make BLOS Beyond Line Of Sight C4I Command, Control, Communications, Computers and Intelligence CAA Civil Aviation Authority CAP Civil Aviation Publication CCI Command and Control Interface CCISM Command and Control Interface Specific Module CFIT Controlled Flight Into Terrain CoG Centre of Gravity CPL Commercial Pilots Licence CRD Common Route Definition CS Control Station 3D Three Dimension DEF STAN DEFence STANdard DGA (Délégation générale pour l’Armement) – French Ministry of Defence

procurement agency D/L Data Link DLI Data Link Interface DoD Department of Defence EASA European Aviation Safety Agency EC European Community EP External Pilot EU European Union FAA Federal Aviation Administration FCL Flight Crew Licensing FFA Functional Failure Analysis FHA Functional Hazard Analysis FHA Functional Hazard Assessment (ARP 4761) FL Flight Level FOV Field Of View ft feet GDT Ground Data Terminal GCS Ground Control Station GPS Global Positioning System HAL Hardware Abstraction Layer

Page viii

HAZOPS HAZard OPerability Studies HCI Human Computer Interface HDD Head Down Display HF Human Factors HMI Human Machine Interface H/O Hand Over HQ HeadQuarters HRA Hazard and Risk Assessment HUD Head Up Display ICAO International Civil Aviation Organisation ICD Interface Control Document ID IDentification IFR Instrument Flight Rules IMC Instrument Metrological Conditions IP Internal Pilot IR Instrument Rating JAA Joint Aviation Authorities JAR Joint Aviation Requirements kg kilogram kJ kilo Joule km kilometre kts knots L&R Launch & Recovery LOS Line Of Sight m metre MAC Mid Air Collision MAV Micro Air Vehicle MBB Make Before Break MBC Management By Consent MBE Management By Exception Met Meteorological MoD Ministry of Defence ms milli-second N/A Not Applicable NASA National Aeronautics and Space Administration NATO North Atlantic Treaty Organisation nm nautical mile NOTAM NOtice To Airmen NPA Notice of Proposed Amendment NPPL National Private Pilots Licence OML Operation Multi-crew Limitation PACT Pilot Authorization and Control of Tasks PBS Public Broadcasting Service PD Pilot’s Discretion PPL Private Pilots Licence RAM Random Access Memory RPM Revolutions Per Minute

Page ix

RPV Remotely Piloted Vehicle RT Radio Telephony RTCA Radio Technical Commission for Aeronautics (known as RTCA Inc) s second S&A Sense & Avoid S&P Stick & Pedals SA Situational Awareness SAE Society of Automotive Engineers SATCOM Satellite Communications SHARD Software Hazard Analysis & Resolution in Design SID Special Instrument Departure SMM Safety Management Manual SMS Safety Management System SOP Standard Operating Procedure SPIC Student Pilot In Command SSA System Safety Analysis STANAG STANdardisation AGreement STAR STandard instrument ARrival TALS Tactical Automated Landing System TBD To Be Determined TCAS Traffic Collision and Avoidance System VFR Visual Flight Rules UAV Unmanned Air Vehicle UAVp UAV Pilot UAVS Unmanned Air Vehicle System UCS UAV Control System US United States USA United States of America USAF United States Air Force USAR UAV Systems Airworthiness Requirements UTC Universal Coordinated Time VFR Visual Flight Rules VOIP Voice Over Internet Protocol VSM Vehicle Specific Module VTUAV Vertical Takeoff and Landing Tactical Unmanned Aerial Vehicle

Page x

This page is intentionally blank

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 the safety issues regarding the handover (H/O) of a UAV to another UAVp;

• Identify from a hazard / safety perspective;

− 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

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.

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.

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.

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;

• 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);

• 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;

• 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;

• Transponder squawk codes to be used 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

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.

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) Product integrity; 2) Product operation; 3) 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 of airworthiness also encompasses the organisations undertaking design, manufacture or maintenance to ensure the organisation has the means necessary for the required scope of work. In addition, the organisation’s management systems are also considered to ensure continuing compliance with the essential requirement for airworthiness.

2.4.2 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.

2.4.3 Civil or Military Route to Airworthiness Cert ification

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.

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.

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.

2.5.2.2 UAV Pilot Ratings

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 in-flight 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.

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 pre-programmed 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

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

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;

• 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;

• 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.

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:

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 a s 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

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 non-standard 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, Nav-aids 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.

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:

• 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 semi-circular 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

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.

System Category 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.

Type 1

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.

Type 2

Data link latency and bandwidth not as crucial Stick & Pedal (S&P) systems.

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.

Type 3

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.

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

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. The operator is supervising a continuously evolving series of dynamic processes;

2. The operator is more concerned with noticing events; 3. Measuring the proportion of visual attention allocated to different regions of the

visual field, and the tasks supported by that attention; 4. 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. Within foveal vision (0 – 2 degrees); b. Requiring eye movement (2 – 30 degrees); c. 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

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.

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 flight controls cannot control the aircraft while the autopilot is engaged (i.e., no override capability);

• 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.

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].

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

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. Hunter: Autopilot toggled off by ground crew and not reset, no indication to pilot;

b. Shadow: Commands not identified for particular UAV and status of command not shown. See Procedural Error below;

c. 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.

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. Hunter: Pilot in command is overridden by other personnel; b. Hunter: Improper start of backup CS interferes with primary data link; c. Hunter: EP had not correctly set up the controls to take over from IP to land

the Hunter UAV; d. 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;

e. Predator: Failure to complete all checklist actions in proper order on handover resulting in turn off of engine and stability augmentation system resulting in un-commanded 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.

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 auto-rotation, 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).

(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 betwee n 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

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;

• 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;

• Over actuation is common when system delay is unpredictable.

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.

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:

“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;

• 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;

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

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:

• 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.

2.7.6.1 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

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, multi-operator 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.

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. Closely coordinated and correlated activities among the multiple UAVs. [Cummings, 2004];

2. Operation in a disturbance free (closed) environment, such as very high altitudes;

3. 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.

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).

Where: C4I Command, Control, Communications, Computers and Intelligence CCI Command and Control Interface CCISM Command and Control Interface Specific Module UCS UAV Control System DLI Data Link Interface HCI Human Computer Interface VSM 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.

UCS

AV

VSM

CCISM

CORE UCS

HCI

C4I SYSTEM

C4I SYSTEM

LAUNCH & RECOVERY

SYSTEM

UAV Pilot

CCI CCI

DLI

2.7.7.2 Command and Control Interface Specific Modu le

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.

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.

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

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

3.3 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

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]

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:

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;

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

CS Functional

Requirement

Identification

Data

Requirement

Identification Identification

H/O Procedure

Implementation

UAV Trial

Verification

Formal CS Verification

FFA

HAZOPS – Flight + H/O Data

Sneak Analysis

HAZOPS - H/O Commands

H/O Command Structure

Generate H/O Procedure

(Including UAVp Checklist)

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

Formal Observed UAV Procedures

Range Trial of UAV Procedures

Simulator Trial of UAV Procedures Using

Test Scenarios

Derive H/O Requirements

Command Structure

Validation

Integration of H/O Procedure with other flight procedures

Procedure Integration

Derive H/O Requirements

H/O Procedure validation against established standard

H/O Procedure

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.

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

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

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;

� 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.

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

UAV other UAV1

SW1 SW2 SW3

A1 A2

A3

SW1 = CS1

SW2 = CS2

SW3 = CS other

A1, 2, 3 = Data link path connections

CS1 CS2 CS other

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.

Guideword Description

Omission Service not delivered. Commission Service delivered when not required. Early Service delivered, but early. Late Service delivered, but late. Value 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 Hazards

1 UAV Handling 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. R1, C2

1.2 The UAV H/O shall be aborted if it is found that the UAVp is unable to change UAV flight path.

C1, C4

1.3 The UAV H/O shall be aborted it is found that the UAV is uncontrollable due to excessive or incorrect control surface response.

R2, C6

1.4 If the UAV is exhibiting noticeable control glitches then the UAV H/O shall be aborted.

R5, C3

1.5 UAV with no or inadequate rudder control can be accepted for H/O at receiving UAVp’s discretion.

R6

2 UAV Control 2.1 Cut engine command shall be executed when weight on wheels is achieved or

be confirmed by UAVp before cut engine is executed. R7

2.2 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.

R8

2.3 The UAV H/O shall be aborted if UAVp commanded inputs result in excessive or incorrect response to airspeed, altitude or heading.

R9

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

R10

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.

R11, C10


2.6 If D/L is via BBM, UAV H/O in manual control shall not to be attempted. R13 2.7 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. R13

2.8 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.

C78

2.9 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.

C78

2.10 CS shall not command either by manual control or by mission / flight planning that is not possible for the UAV to achieve.

C9

2.11 The UAV H/O shall not be initiated while D/L signal strength is low or fluctuating at a low level.

C32

2.12 Only one CS shall be in control of the UAV at a time. C66, C77 2.13 CS1, if in contact with UAV be able to take back control by issuing a H/O abort

command. C66, C77

3 UAV Configuration 3.1 UAVp shall, when in control of the UAV be able to change UAV configuration

when commanded. C7

3.2 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.

C67, C68

4 UAV Messages 4.1 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. R3, C35, C64, C73, C77, C78

4.2 Messages shall be checked for corruption. R4, C34, C38

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

R4, C33, C34, C38, C39

4.4 Where continuity across a series of messages is required then a missing or corrupted message is be resent.

R4

4.5 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.

C36, C79, C80, C81, C82

4.6 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.

C41

4.7 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.

C55

5 Displays 5.1 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. C12

5.2 A clear indication to UAVp when UAV autopilot is engaged or disengaged. R14 5.3 UAV with no or unusable UAV video can be accepted for H/O at receiving

UAVp’s discretion. R18, C16

5.4 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.

R21

5.5 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.

R20, C13

5.6 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.

R22, C13


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.

R23, C14, C23

5.8 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.

R24, C13

5.9 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.

R25, C13

5.10 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.

R26, C13

5.11 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.

R27, C13

5.12 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.

R28

5.13 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.

C17

5.14 If other air traffic position and track are available then they shall be displayed on the mission map.

C19

5.15 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.

C21

5.16 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.

C22

5.17 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.

C30

5.18 The scaling and display units normally used for individual flight data parameters shall be used as default when flight data is displayed.

C37

5.19 UAVp shall be informed by the CS when the UAV is under their control. C62, C64 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. C74

6 Monitoring 6.1 Track and altitude of UAV shall monitored by the UAVp throughout the period

the UAV is in his charge. R12, C20

6.2 UAVp shall monitor the UAV to check that the UAV is achieving commanded mission targets.

C9

6.3 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.

C18

6.4 If other air traffic position and tracks are displayed on the mission map they are to be maintained and monitored.

C19

6.5 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.

C21

7 Data 7.1 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. R15

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

R16

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.

R17

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.

R19, C61, C67, C68, C71, C72


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.

R21

8 CS Set-up 8.1 CS2 UAVp shall as part of the mission/flight plan be allowed reasonable time to

reconfigure and initialise the CS. R29

8.2 CS2 UAVp shall follow a checklist to fully reconfigure and initialise CS. R30 8.3 Co-pilot shall be used (if applicable) to double check checklist actions by the

pilot to reconfigure and initialise CS. R30

8.4 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.

C17

8.5 CS Alert / Warning annunciation shall be checked as part of the CS initialization prior to UAV H/O.

C24

8.6 UAV related Alert / Warnings set to CS1 shall be passed to CS2 electronically and/or orally prior to start of H/O.

C29

8.7 CS2 shall preset the ATC frequencies as part of the CS initialization prior to UAV H/O.

C44, C46

8.8 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.

C57

8.9 CS2 UAVp shall check any data provided by CS1 for errors and consistency. C56 9 Communications 9.1 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.

C45, C51

9.2 CS1 and CS2 shall use their respective call-signs, UAV call-sign and that of the ATC in any communication with ATC.

C46, C50, C52

9.3 If CS1 and CS2 do not have clear communications with ATC and with each other then the UAV H/O shall not be initiated.

C47, C48, C53, C58, C70

9.4 When CS1 or CS2 are communicating with ATC and each other it shall be obvious to the CS transmitting when they are transmitting.

C49, C54

9.5 During H/O any emergency involving UAV shall be coordinated by CS1. C58, C59 9.6 CS1 shall follow SOP when declaring an emergency to ATC. C60 9.7 CS UAVp gains control of UAV shall inform the other CS UAVp of this. C65 9.8 When D/L to UAV has been lost during H/O, CS1 and CS2 shall follow SOP to

regain D/L coordinated by CS1. C67, C68, C71, C72

9.9 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.

C74

10 H/O Coordination 10.1 UAV H/O shall follow a coordinated sequence documented by a common SOP

to both CS UAVps and is understood by both UAVps. C61, C62

10.2 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.

C63

10.3 If H/O continues on outside H/O window then CS2 UAVp is in control of UAV as CS1 will be out of range.

C69

10.4 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.

C69

Out of Scope

UAV issue (not CS) UAV structural integrity shall be capable of meeting demands placed upon it. C6 UAV configuration shall not change until commanded by CS in control to change

UAV configuration. C8

Alarm system Alarm system checks other than annunciator check not possible to check as part

of H/O. C25, C26, C27, C28


Signal strength D/L Apart from no D/L strength reading UAVp unable to tell if signal strength is

misreading. C31, C32

Dish alignment is out of scope. 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.

3.11.2 Proposed CS UAV Handover Sequence

Figure 3-7; Control Station Handover State Diagram

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

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 re-established 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.

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.



meant for UAV or CS is to be ignored by receiving system. R3, R34, C35, C64, C73, C77, C78

5 Displays 5.21 System H/O stage shall be displayed to UAVps. R31 5.22 System shall inform UAVp if incorrect or inappropriate command has been

entered. R32

8 CS Set-up 8.10 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. R33

3.12 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.

3.12.1 Pre-Handover

CS1 Actions CS1 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).

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 CS2. Establish comms with CS1. Confirm UAV Tail_No and Type_ID with CS2. Confirm Tail_No and Type_ID of UAV to be handed over.

Confirm Mission_ID and version with CS2. If CS2 has not got latest mission version transfer latest version.

Confirm mission / flight plan Mission_ID and version, if not latest get from CS1.

CS1 declares any problems with the UAV to CS2. Transfers any relevant UAV error/failure data to CS2.

Checks UAV error/failure data transferred from 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.

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. Calculate UAV dish position for CS2 based on UAV at start of H/O window.

Amend mission w.r.t. mission updates and predicted weather for mission segment UAVp is to be responsible for.

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.

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.



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.

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

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.

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

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 UAV in position at start of H/O window. CS1 is ready sent to CS2.

CS1_Ready

CS1 starting H/O sent to CS2. CS1_Start_HO CS2 acknowledges start of H/O. CS2_Ackn CS1 transmits initiate H/O to UAV and CS2. CS1_Initiate_HO 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.

3.12.2 Handover

UAV Actions UAV H/O Commands


Acknowledgement of link change transmitted to CS1. UAV_Link_Change (to CS1)

UAV transmits link establish to CS2. UAV_Link_Estb 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_DL_Estb

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).

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.

CS2_HO_Accept

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.

CS_Abort_HO

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

3.12.3 Post Handover

CS2 Actions UAV Actions

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

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 Pass / Fail

Action If Failed

1/. Flying Instrument Displays 1.1 Attitude correct – straight + level. ABORT 1.2 Pressure Altitude – correct setting displayed. PD MA 1.3 Altitude correct - displayed with correct units (ft). PD MA

1.4 Heading correct. PD MA 1.5 Airspeed correct – displayed correct units. PD MA

1.6 Engine RMP correct and is being updated. PD MA

2/. Visual Display 2.1 UAV providing display from UAV. PD 2.2 Display not constantly freezing / pixilation/ blanking. PD 2.3 Zoom / pan available (if applicable). PD 2.4 Display at correct level of zoom (apply correction if applicable). PD 2.5 Camera pan pointing forward (apply correction if applicable). PD 3/. SA – Moving Map display 3.1 Map displaying correct area. PD MA 3.2 Map at correct scale. PD MA 3.3 UAV position – Lat/Long agrees with moving map position. PD MA 3.4 UAV position on map is being updated. PD MA 3.5 UAV expected track correctly positioned on map. PD MA 3.6 UAV position is on track. PD MA 3.7 UAV actual altitude agrees with expected altitude. PD MA 3.8 Map prominent reference feature is identified at expected position

in real world on visual. PD MA

4/. UAV Status 4.1 Engine Temperature – in correct units and within limits. PD MA 4.2 Oil Pressure – in correct units and within limits. PD MA 4.3 Fuel Level – within expected limits (expected minimum). PD MA 4.4 Estimated fuel usage to destination provided and is less than

current fuel available. PD MA

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

PD

4.6 D/L Signal level provided and is being updated. PD MA 4.7 D/L system status is OK. PD 5/. UAV Error Log

5.1 If new errors - check for Alerts - if so reject H/O. ABORT 5.2 Alert and Warning annunciations tested and working. PD MA 6A/. Manual Control: Stick& Pedal

6A.1 Ensure stick / pedals / trims central, throttle set for cruise. N/A

ID Description Pass / Fail

Action If Failed

6A.2 Disengage UAV autopilot – UAV flying straight and level (check flight instruments and visual).

ABORT

6A.3 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.

ABORT

6A.4 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).

ABORT

6A.5 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.

ABORT

6A.6 Set flight controls for straight and level flight. N/A 6A.7 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.

ABORT

6A.8 Re-engage UAV autopilot. PD MA 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.

6B/. Manual Control: Switch / Knob or Point / Click Cont rol 6B.1 Set flight control settings to match with current UAV altitude /

airspeed / heading. (assumption: throttle controlled automatically). N/A

6B.2 Disengage UAV autopilot – UAV flying straight and level (check flight instruments and visual).

ABORT

6B.3 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.

ABORT

6B.4 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.

ABORT

6B.5 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.

ABORT

6B.6 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.

ABORT

6B.7 Re-engage UAV autopilot. PD MA 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.

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

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.

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;

• 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 Fulfi lment

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].

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 Requirement Description STANAG 4586 fulfilment of section 3 derived require ments 1 UAV Handling

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.

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.

1.2 The UAV H/O shall be aborted if it is found that the UAVp is unable to change UAV flight path.

As above.

1.3 The UAV H/O shall be aborted it is found that the UAV is uncontrollable due to excessive or incorrect control surface response.

As above.

1.4 If the UAV is exhibiting noticeable control glitches then the UAV H/O shall be aborted.

As above.

1.5 UAV with no or inadequate rudder control can be accepted for H/O at receiving UAVp’s discretion.

UAV handling properties are out of scope of STANAG 4586.

2 UAV Control 2.1 Cut engine command shall be executed when weight on wheels is achieved or

be confirmed by UAVp before cut engine is executed. Engine cut logic is CS implementation specific, but is executed by message #45 Engine Command.

2.2 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.

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.

2.3 The UAV H/O shall be aborted if UAVp commanded inputs result in excessive or incorrect response to airspeed, altitude or heading.

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.

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

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.

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.

Mission updated by message #800 Mission Upload Command, No H/O Abort available.

2.6 If D/L is via BBM, UAV H/O in manual control shall not to be attempted. SOP. 2.7 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. SOP.

2.8 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.

SOP. Message #501 Data Link Status Report provides a measure of a combination of signal quality and strength.

ID Requirement Description STANAG 4586 fulfilment of section 3 derived require ments 2.9 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.

SOP.

2.10 CS shall not command either by manual control or by mission / flight planning that is not possible for the UAV to achieve.

UAV limits built into VSM also Mission Planning to take into account UAV operational limitations.

2.11 The UAV H/O shall not be initiated while D/L signal strength is low or fluctuating at a low level.

SOP. Message #501 Data Link Status Report provides a measure of a combination of signal quality and strength.

2.12 Only one CS shall be in control of the UAV at a time. VSM via message #1 CUCS Authorisation Request provides the control so only one CS in control of UAV.

2.13 CS1, if in contact with UAV be able to take back control by issuing a H/O abort command.

CS1 could take back control via message #1 CUCS Authorisation Request via Override Control option.

3 UAV Configuration 3.1 UAVp shall, when in control of the UAV be able to change UAV configuration

when commanded. 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.

3.2 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.

SOP to ensure UAV is on auto pilot during H/O.


meant for UAV or CS is to be ignored by receiving system. Achieved by message header. See section 4.6.

4.2 Messages shall be checked for corruption. Achieved by message wrapper See section 4.6. 4.3 Incoming messages shall be checked for corruption and if found to be corrupt

rejected. CS implementation specific.

4.4 Where continuity across a series of messages is required then a missing or corrupted message is to be resent.

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.

4.5 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.

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

4.6 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.

Achieved by message #600 Vehicle Data Link Transition Coordination but CS2 position sent to UAV not the coordinates.

4.7 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.

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 Requirement Description STANAG 4586 fulfilment of section 3 derived require ments 5 Displays 5.1 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. There is no message to abort the H/O and hand control back to CS1.

5.2 A clear indication to UAVp when UAV autopilot is engaged or disengaged. CS implementation specific, state of autopilot provided by message #106 Vehicle Operating Mode Report.

5.3 UAV with no or unusable UAV video can be accepted for H/O at receiving UAVp’s discretion.

Out of STANAG 4586 scope.

5.4 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.

CS implementation specific, achievable by the use of CCI MISREP or CCI #101 Inertial States transmitted from CS1 to CS2.

5.5 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.

SOP.

5.6 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.

SOP.

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.

SOP. CS implementation specific.

5.8 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.

SOP.

5.9 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.

SOP.

5.10 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.

SOP.

5.11 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.

SOP.

5.12 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.

SOP.

ID Requirement Description STANAG 4586 fulfilment of section 3 derived require ments 5.13 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. SOP. CS implementation specific.

5.14 If other air traffic position and track are available then they shall be displayed on the mission map.

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

5.15 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.

SOP.

5.16 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.

SOP.

5.17 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.

SOP.

5.18 The scaling and display units normally used for individual flight data parameters shall be used as default when flight data is displayed.

CS implementation specific, generic flight displays provided in specific units, UAV specific displays can be configured with different display units.

5.19 UAVp shall be informed by the CS when the UAV is under their control. CS implementation specific, data provide by message #21 VSM Authorisation Response.

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.

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.

5.21 System H/O stage shall be displayed to UAVps. CS implementation specific. STANAG 4586 doesn’t cover H/O coordination.

5.22 System shall inform UAVp if incorrect or inappropriate command has been entered.

CS implementation specific.

6 Monitoring 6.1 Track and altitude of UAV shall monitored by the UAVp throughout the period

the UAV is in his charge. SOP.

6.2 UAVp shall monitor the UAV to check that the UAV is achieving commanded mission targets.

SOP.

6.3 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.

SOP.

6.4 If other air traffic position and tracks are displayed on the mission map they are to be maintained and monitored.

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

ID Requirement Description STANAG 4586 fulfilment of section 3 derived require ments 6.5 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.

SOP.

7 Data 7.1 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. 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.

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

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.

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.

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.

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.

SOP for mission / flight plan to cover whole mission but could be updated during mission to reflect changing circumstances.

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.


8 CS Set-up 8.1 CS2 UAVp shall as part of the mission/flight plan be allowed reasonable time

to reconfigure and initialise the CS. 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.

8.2 CS2 UAVp shall follow a checklist to fully reconfigure and initialise CS. SOP and also CS implementation specific. 8.3 Co-pilot shall be used (if applicable) to double check checklist actions by the

pilot to reconfigure and initialise CS. SOP.

8.4 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.

SOP and also CS implementation specific.

8.5 CS Alert / Warning annunciation shall be checked as part of the CS initialization prior to UAV H/O.


8.6 UAV related Alert / Warnings received by CS1 shall be passed to CS2 electronically and/or orally prior to start of H/O.

CCI #1100 Subsystem Status Alert Message and /or CCI #1101 Subsystem Status Report.

8.7 CS2 shall preset the ATC frequencies as part of the CS initialization prior to UAV H/O.


8.8 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.

SOP contained in Operations Manual and /or Flight Manual see note at end of table.

ID Requirement Description STANAG 4586 fulfilment of section 3 derived require ments 8.9 CS2 UAVp shall check any data provided by CS1 for errors and consistency. SOP to check UAV data and mission / flight plan from CS1. 8.10 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. 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.

9 Communications 9.1 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.

SOP.

9.2 CS1 and CS2 shall use their respective call-signs, UAV call-sign and that of the ATC in any communication with ATC.

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.

9.3 If CS1 and CS2 do not have clear communications with ATC and with each other then the UAV H/O shall not be initiated.

SOP.

9.4 When CS1 or CS2 are communicating with ATC and each other it shall be obvious to the CS transmitting when they are transmitting.


9.5 During H/O any emergency involving UAV shall be coordinated by CS1. H/O instantaneous, coordination by whoever has or had UAV last. 9.6 CS1 shall follow SOP when declaring an emergency to ATC SOP – CS but not necessarily CS1, whoever was responsible for UAV. 9.7 CS UAVp gains control of UAV shall inform the other CS UAVp of this. SOP. 9.8 When D/L to UAV has been lost during H/O, CS1 and CS2 shall follow SOP to

regain D/L coordinated by CS1. SOP.

9.9 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.

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.

10 H/O Coordination 10.1 UAV H/O shall follow a coordinated sequence documented by a common SOP

to both CS UAVps and is understood by both UAVps. 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.

10.2 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.

SOP.

10.3 If H/O continues on outside H/O window then CS2 UAVp is in control of UAV as CS1 will be out of range.

In terms of STANAG 4586, as soon as D/L established CS2 UAVp is in control and responsible for UAV.

10.4 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.

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.

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:

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.

Packet Seq #

Message Data

Instance Number

Reassembly sequence number

Checksum

IDD Version

Msg Instance ID

Message Type

Message Length

Stream ID

Number of bytes in body

Unique stream for each source/destination pair

STANAG 4586 [NATO2, 2007]

Interface Definition Document Version that defines the structure (STANAG 4586 version)

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:

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 F031-MISREP; 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.

CS ID

Vehicle ID

At the top of all message data

●

●

In applicable messages Data Link ID

VSM ID

Time Stamp

STANAG 4586 [NATO2, 2007]

4.7.2 STANAG 4586 Message Used in Requirement Fulfi lment

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 # Description 1 CUCS Authorisation Request.

20 Vehicle ID.

21 VSM Authorisation Response.

42 Vehicle Operating Mode Command.

43 Vehicle Steering Command.

100 Vehicle Configuration.

100 Vehicle Configuration.

101 Inertial States.

103 Body-Relative Sensed States.

104 Vehicle Operating States.

400 Data Link Set Up Message.

401 Data Link Control Command.

402 Pedestal Configuration Message.

403 Pedestal Control Command.

404 Data Link Assignment Request.

500 Data Link Configuration/Assignment Message.

501 Data Link Status Report.

502 Data Link Control Command Status.

503 Pedestal Status Report.

600 Vehicle Data Link Transition Coordination.

700 Handover Status Report.

800 Mission Upload Command.

1200 Field Configuration Request.

1201 Display Unit Request.

1202 CUCS Resource Report.

1203 Configuration Complete.

1300 Field Configuration Integer Response.

1301 Field Configuration Double Response.

1302 Field Configuration Enumerated Response.

1303 Field Configuration Command.

1304 VSM Services Report Message.

1400 Message Acknowledgement.

1401 Message Acknowledge Configuration.

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

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).

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 CS2. CCI + RT comms established �CS2

Establish comms with CS1. CCI + RT comms established �CS1

Confirm UAV Tail_No and Type_ID with CS2. CCI #20 Vehicle ID �CS2

Confirm Tail_No and Type_ID of UAV to be handed over.

Confirm Mission_ID and version with CS2. If CS2 has not got latest mission version transfer latest version.

CCI Mission Plan �CS2

Confirm mission / flight plan Mission_ID and version, if not latest get from CS1.

CS1 declares any problems with the UAV to CS2. Transfers any relevant UAV error/failure data to CS2.

CCI #1100 Subsystem Status Alert (if any) �CS2

Checks UAV error/failure data transferred from 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.

CCI MISREP �CS2 Or CCI #101 Inertial States CCI #102 Air and Ground Relative States �CS2

CS2 UAVp provides CS1 UAVp with estimate for time when ready for UAV H/O.

CS1 Actions CS1 H/O Commands CS2 Actions CS2 H/O Commands


RT �ATC Configure CS w.r.t. UAV Type_ID (load VSM corresponding to UAV_Type).

See 4.8.1.1 below

4.8.1.1 STANAG 4586 Configuration of CS2 User Inter face

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 VSM #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.

#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).

CS2 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.

4.8.2 Pre-Handover Procedure – Continued 1.



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.

CCI ATO

Get Met data for mission area and time period. Get Met Data 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, de-icing – 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. CS1 may provide on request from CS2 the current UAV status.

CCI MISREP�CS2 If applicable, knobs and switches set for handover altitude, airspeed, heading and next waypoint.

4.8.2.1 STANAG 4586 Configuration of the CS2 Data L ink

CS2 requests VSM to setup D/L parameters and pedestal (dish) position.

4.8.3 Pre-Handover Procedure – Continued 2.



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.



CCI #1101 Subsystem Status Report �CS2

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

Configure D/L – see 4.8.2.1 below

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

#42 Vehicle Operating Mode Command

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

Set dish (pedestal) position – see 4.8.2.1 below

CS2 VSM #404. Data Link Assignment Request CS requests a D/L assignment for controlling the AV.

#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.



Check displays are displayed with expected units and map displays are at the correct scale.

RT � ATC

Set altimeter pressure altitude (#43 Vehicle Steering command) initiated on H/O.


CS2 initialisation and set-up complete. The following part of the procedure is not implemented by STANAG 4586 but could be implemented aurally between the CS UAVps.

4.8.4 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.

Original procedure not implemented by STANAG 4586

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

CS1_Ready

4.8.5.1 STANAG 4586 CS2 Request to Take Over UAV Co ntrol

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 VSM .#1: CUCS Authorization Request CS requests control over a specific Vehicle/ Vehicle type.

4.8.6 Handover Procedure.



CS1 starting H/O sent to CS2 CS1_Start_HO 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.

Implemented as part of #600. See section 4.8.6.1 below.

CS2 acknowledges start of H/O. CS2_Ackn (equivalent to #700). See section 4.8.6.1 below.

CS1 transmits initiate H/O to UAV and CS2 CS1_Initiate_HO (equivalent to #600). See section 4.8.6.1 below.

4.8.6.1 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.

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 VSM (CS1) #600 Vehicle Data Link Transition Coordination CS1 releases UAV but also provides UAV with CS2 position and D/L parameters.

#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.



Acknowledgement of link change transmitted to CS1.

UAV_Link_Change (to CS1)

UAV transmits link establish to CS2. UAV_Link_Estb 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_DL_Estb

4.8.7.1 STANAG 4586 Confirmation of UAV Control by CS2

CS2 informed that it is now in control of UAV. CS2 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 VSM 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.

#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.

4.8.8 Handover Procedure – Continued 2

CS2 UAVp Provided With Flight Data and Control of UAV.



UAV link to CS2 now established. UAV starts down loading UAV flight data (altitude, heading, airspeed, position etc).

See section 4.8.8.1.

CS2 flight displays now displaying UAV supplied data. See section 4.8.8.1.

4.8.8.1 STANAG 4586

Transfer of control data and flight display data from CS2 and UAV respectively via STANAG 4586 messages.

CS2 VSM CS Command Messages -> #42 Vehicle Operating Mode Command #43 Vehicle Steering Command …etc. CS controls the UAV / payload.

<- VSM Status Messages/ Configuration updates. VSM reports status of the AV i.e.; #101 Inertial States #103 Body-Relative Sensed States #104 Vehicle Operating States …etc. VSM updates Vehicle Configuration with message #1303. Field Configuration Command.

4.8.9 Handover Procedure – Continued 3



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.

CS2_HO_Accept

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.

CS_Abort_HO

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

Under STANAG 4586 once H/O is established that is it CS2 is in control, there is no mechanism for the UAVp to reject/abort the H/O this is further discussed in 4.8.11 below. In addition, if the D/L has failed to be established and is returned to CS1, CS2 is stuck waiting for #21, which is not going to happen. There is no apparent way for CS2 to cancel the command. It is expected that under STANAG 4586, CS2 UAVp is to implement the Checklist (section 3.13) to check that his displays and controls are functioning correctly.

4.8.10 Post Handover

CS2 Actions UAV Actions

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

4.8.11 Summary

STANAG 4586 H/O provides the mechanism to H/O control between CS1 and CS2 and is completed as soon as CS2 UAVp has control of the UAV. The H/O Procedure works on the proposition that on H/O CS2 UAVp checks out the displays and controls then either accepts control of the UAV or aborts the H/O back to CS1. Under STANAG 4586 CS2 does not have this option. If CS2 UAVp has to relinquish control he could go through the H/O procedure to hand back to CS1. CS1 could if allowed by the implementation override CS2 and take back control. Alternatively CS2 could release the UAV to let it fly autonomously to re-establish control later when the problem requiring control to be relinquished is resolved.

4.9 Requirement Fulfilment by STANAG 4586

The project in section 3 developed the H/O Requirements and Procedure. In this section the Requirements and Procedure have been applied to STANAG 4586 Ed 2.5 [NATO2, 2007]. There are areas where STANAG 4586 fully meets the Requirements and fits into the Procedure. In other areas the requirements are not met but there is a feasible workaround by adapting STANAG 4586 existing messages. Then there are areas that STANAG 4586 doesn’t meet and are in scope. An area that was catered for in STANAG 4586 Ed 2.0 [NATO, 2005] that is H/O control coordination is no-longer included in the current Ed 2.5. H/O coordination, which is part of the developed H/O Procedure is assumed for STANAG 4586 to be coordinated aurally between the two UAVps.

The areas of STANAG 4586 that meets the H/O Requirements or provides the functionality expected by the H/O Procedure are as follows:

• D/L is returned to CS1 if D/L fails to be established;

• H/O control allows only one CS in charge of UAV at a time;

• Message to/from provided by all message headers;

• Message corruption / loss can be identified by message wrapper via checksum, sequence No, message instance;

• Loss of message is identified by the use of push / pull message pairs;

• Where no corresponding pull message, message #14 can be setup to provide service;

• CS2 coordinates sent to UAV not dish position as assumed;

• CS configuration data provided by VSM;

• CS provided with initialisation UAV data from VSM prior to H/O;

• Unless UAV ID, CS ID and DL ID all match then the D/L is not going to be established making it improbable that a D/L is going to be established to an unintended UAV;

• Messages: CS2_Ready, CS1_Initiate_HO, UAV_DL_Init_Fail, UAV_DL_Init_Fail, UAV_Link_Change, CS2_DL_Estb used in State diagram Figure 3-7 implemented by STANAG 4586 message.

The areas of functionality that are in the H/O requirements but are not directly supported by STANAG 4586 but could be achieved via a workaround:

• There is no message to control basic functions i.e. flaps, U/C but they can be monitored. It is therefore assumed control is via the vehicle specific messages;

• Providing UAV position data etc to CS2 in theory possible using DLI messages transmitted on CCI. Concept suggested by STANAG 4586 Ed 2.0 for H/O control (removed in Ed 2.5) alternative is CCI MISREP – includes UAV position but unknown what else;

• As above but providing SA to UAVp by providing positional data of other traffic by DLI messages on CCI or CCI MISREP;

• To confirm UAV prior to H/O, CS1 could send #20 to CS2 via CCI as above;

• Send UAV status and errors passed to CS2 via CCI as above using #1100 and #1101.

The areas of STANAG 4586 functionality that do not meet the H/O Requirements or provide the functionality expected by the H/O Procedure are as follows:

• No H/O Abort command;

• No Cancel command;

• No error message for inappropriate / incorrect command;

• No command to request resend of corrupted or missing message;

• No standard format and CCI message for transmission of mission / flight plan;

• IFF mode command doesn’t include transponder mode S. STANAG 4586 does not include a H/O abort command. If there is a problem with the H/O CS2 UAVp is going to know that the H/O has failed to correctly establish full monitoring and control functionality. CS2 UAVp needs to be able to abort the UAV straight back to CS1 UAVp who had control of the UAV. CS2 UAVp only has the options to:

• Try to H/O control back to CS1;

• Release control so the UAV files autonomously for D/L to be established later when problems are sorted out;

• Get CS1 to override CS2 control and take back UAV control (if allowed by implementation – security issue).

When CS2 is waiting for CS1 to H/O the UAV but that H/O fails for whatever reason there is no apparent way for CS2 UAVp to cancel the request for UAV control. The result is that CS2 is hanging on for #20 to say CS2 has control that is not going to come.

There is no message to inform the UAVp his command was inappropriate or incorrect. This is probably dependent on CS implementation but is not addressed by STANAG 4586.

There is no recognised standard format for mission / flight planning data to be passed electronically in a form that contains the additional data required to allow the mission / flight plan to be updated. An ongoing US initiative known as the Common Route Definition specification (CRD) (CRD ICD 2.0.2.0) is still under development. A CRD mission plan documented by STANAG 4586 contains route planning, payload planning, data link planning (including frequency planning), and UAV emergency recovery planning (rules of safety) for a UAV flight. In theory the mission / flight plan could be passed between CS1 and CS2 using the #800 series messages via CCI or proprietary Mission Planning files between CS’s with the same type of MP systems.

The IFF Code Command message includes fields for setting civil transponder Mode C but doesn’t allow for Mode S.

The following are not directly part of STANAG 4586 but are issues that have arisen. • Use of D/L to relay RT comms to ATC to increase range;

• Use of CS call-sign. Use of the D/L to the UAV for RT comms to ATC to get range is identified as out of scope in STANAG 4586. However the STANAG 4586 Implementation Guidelines [IGL, 2004] recommends the use of the STANAG 7085 Audio channel to provide voice comms over the D/L but only warns of latency constraint of 250 ms. Use of D/L comms should be strongly discouraged. The D/L is a single point of failure and when lost is when you need ATC communications the most.

In the past pilots identified themselves when using RT via the aircraft’s call-sign. The CS used to fly the UAV is independent of the UAV and can switch to another UAV at any time. The use of CS call signs is therefore required. This is really a regulatory issue more than a STANAG 4586 issue but has been included here as a non compliance.

4.10 Problems with the Theoretical Model

This evaluation of the theoretical H/O model proposed in section 3 has highlighted problems. The model was based on the principle that handshaking between the UAVps is

a good premise to work too. However the H/O model worked on the principle that the initial handshaking was by message passing between the UAVps which is an over complication when an aural handshake between the two UAVps would have been adequate. The second problem with the H/O model proposed is with the last stage of the H/O. The state diagram Figure 3-7 shows the last stage of the H/O with CS2 UAVp formally accepting the UAV after checking it over. STANAG 4586 does not do this, once the H/O is made then CS2 is in charge. Formal acceptance of the UAV, which the UAVp may forget to do now seems an unnecessary complication.

A minor change was made to the pre-handover part of the original H/O Procedure 3.12.1 which passed the data that the UAV needed to make the H/O prior to H/O initiation. In STANAG 4586 this data is passed as part of message #600 which initiates the H/O. In addition message #600 sends the UAV CS2’s position for it to work out the D/L coordinates; in the original H/O estimated dish coordinates were sent to the UAV. The STANAG 4586 solution would seem a better solution initiating the H/O with the data required and letting the UAV work out its own D/L dish coordinates. However from a military / security standpoint message #600 gives away the position of the acquiring CS.

4.11 Conclusions

The evaluation of the theoretical H/O Requirements and Procedure proposed in section 3 has stood up well against STANAG 4586. Many of the procedural steps correlated over to STANAG 4586. What areas of the proposed H/O Requirements and H/O Procedure meet or follow STANAG 4586 functionality; achieved via STANAG 4586 workaround or STANAG 4586 does not provide, the full details of which can be found in section 4.9. The proposed H/O Procedure worked well with the STANAG 4586 Implementation Guidelines [IGL, 2004] procedure which was interleaved with the H/O Procedure to provide the functionality called up by the procedure. There were areas where the procedures did not fit. STANAG 4586 does not provide pre-H/O coordination, this is assumed to be implemented aurally between the UAVps. Where the proposed H/O Procedure and STANAG 4586 procedure differ is that the proposed H/O Procedure allows CS2 UAVp to check that the H/O has been successful and to either accept the H/O or to reject the H/O and abort the UAV back to CS1. For STANAG 4586, when the H/O has been made CS2 UAVp has got the UAV, there is no accepting or rejecting the H/O. In the proposed H/O Procedure having the UAVp formally accept the H/O is an unnecessary complication. It has been assumed that prior to the H/O the UAV was working OK for CS1 UAVp or the H/O would not have taken place. On completion of the H/O CS2 UAVp should soon know if the flight displays and UAV control are working correctly or not. If the H/O has not been correctly executed, in the proposed H/O the UAVp has the ability to abort the H/O and hand the UAV straight back to CS1 where the UAV was operating correctly. STANAG 4586 does not provide this facility to abort the H/O and hand the UAV back. This is one important safety feature that STANAG 4586 does not include.

5 Conclusions and Further Work The aim of this section is to show that the aims of the project have been met. In addition to this to identify recommendations for further work.

5.1 Findings, Related to Satisfaction of the Projec t’ Aims

The primary motivation for the project was to identify the issues of handing over Unmanned Air Vehicle (UAV) control from one UAV pilot (UAVp) to another. The project aims to:

1. Identify safety issues regarding Control Station (CS) airworthiness; 2. Identify the safety issues regarding the handover of a UAV to another UAVp; 3. Identify from a hazard / safety perspective:

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

− The co-ordination that needs to be implemented between the CSs. 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. Bullet point 1/ above was fulfilled by the literary survey implemented in section 2 which looked at airworthiness issues regarding CSs. The first issue was that of the use of CAP 722 as an alternative airworthiness certification. This was shown to be impractical for civil operations. The choice for UAV and therefore CS airworthiness certification was either via a civil or military route. For compatibility with civil manned aircraft airworthiness, civil airworthiness instead of military airworthiness was seen as the best route to follow.

Airworthiness from civil prospective is broken down into the following aspects; organisational, product operation and product integrity. Each of the aspects was examined which highlighted issues some of these issues are highlighted in the following paragraphs.

For the organisational aspect of airworthiness the International Civil Aviation Organisation (ICAO) Safety Management Manual (SMM) [2006] is seen as the framework on which a UAV operator can build their own Safety Management System (SMS) required by civil aviation authorities.

From the operational aspect of airworthiness several issues were identified, these included the lack of a civil UAVp licence and the specific training that will be required to allow the UAVp to fly UAVs using the different types of CS identified.

From the product integrity aspect of airworthiness several issues were identified. From a CS design prospective issues included the impracticality of using External Pilots (EPs) for commercial operations, considerations for the control of multiple UAVs and also the need for UAV interoperability to provide a practical and flexible capability suitable for commercial operations.

5.2 Project’s Fulfilment of the Project’s Original Aims

Bullet points 2 and 3 have been fulfilled by the project. The project has applied the SMM Safety Cycle framework and built on this framework by the use of ARP 4761 [SAE, 1996]. ARP 4761 is a standard used by civil manned aircraft for product integrity aspect of airworthiness. As part of the Safety Cycle framework the ARP 4761 Safety Assessment Diagram was adapted and developed to implement the Hand Over (H/O) Requirements and H/O Procedure.

The two types of H/O considered were between UAVps in the same CS and the H/O between UAVps in different CSs. A H/O between UAVps in the same CS was seen as a simpler subset of the H/O between UAVps in different CSs as the change over of the Data Link (D/L) also has to be considered for the CS H/O. Therefore only the H/O between CSs was considered in the analysis. The type of D/L H/O is a complication as there are two types of D/L H/O, Break Before Make (BBM) and Make Before Break (MBB). Both types of

D/L H/O have been considered in the analysis. However BBM being the more awkward type of D/L H/O is the one used for the H/O Procedure.

ARP 4761 Safety Assessment Diagram was the process used but adapted from being aircraft system oriented safety assessment to that of CS System. Both the left and right hand side of the Safety Assessment Diagram was developed; the left side identified the analysis techniques used to identify the hazards associated with a H/O and to develop the requirements by which a H/O can be assessed. In addition to this a theoretical H/O Procedure based on the H/O State developed from the H/O Requirements was developed. The right hand side of the ARP Safety Assessment Diagram is about validation and testing the H/O Procedure and once satisfied integrating the procedure with other flight procedures followed by further testing to create the CS Standard Operating Procedure (SOP) required for commercial operation of the CS. So far ARP 4761 has been used to implement the SMS Safety Cycle but this is where ARP 4761 stops as it has produced a working SOP. The Safety Cycle is a circular framework, once the CS SOP has been developed and is being used; the Safety Cycle is used to monitor the SOP for efficacy. If a procedure of the SOP is found not to be totally fulfilling its purpose the Safety Cycle can go through another cycle to assess and correct the error(s).

The analysis techniques selected for the left hand side of the ARP 4761 Safety Assessment diagram were Functional Failure Analysis (FFA), Sneak Analysis and HAZOPS. Part 1 of the analysis covered the ‘fly – H/O – fly’ aspect of the H/O used FFA, Sneak and HAZOPS analysis. FFA was used to identify the functional hazards associated with flying the UAV. The consolidated FFA hazards were used as one of the inputs to the derived H/O Requirements. Sneak analysis was selected to identify the unintended H/O D/L paths and also identified misleading display issues. The results of the Sneak Analysis were used by HAZOPS as conditions to be considered as part of the analysis. HAZOPS was primarily used to analyse the data that must be passed between the CS and the UAV for the UAVp to be able to fly the UAV, also the data needed by the UAV and CS2 for the H/O to take place. The consolidated HAZOPS recommendations were used as an input to the derived H/O Requirements. Part 2 of the analysis examined the sequencing of the H/O. HAZOPS was used to analyse the H/O sequence documented by H/O state diagram which provided additional safety requirements. The consolidated HAZOPS recommendations from the sequencing analysis were used to generate additional H/O Requirements. From the H/O Sequence and the application of the H/O Requirements the H/O Procedure was then generated.

5.3 Conclusions

The theoretical H/O Requirements and H/O Procedure stood up well against STANAG 4586. Many of the procedural steps correlated over to STANAG 4586. The full details of what areas of the proposed H/O Requirements and H/O Procedure meet STANAG 4586 functionality, achieved via STANAG 4586 workaround or STANAG 4586 does not provide can be found in section 4.9. One important safety feature which is included in the H/O procedure noted in section 4.9 that STANAG 4586 does not provide is the facility to abort the H/O and hand the UAV back to CS1 if the H/O is not completed correctly.

Other issues that have arisen but not directly connected to STANAG 4586 issues, these are:

• Use of D/L to relay Radio Telephony (RT) comms to Air Traffic Control (ATC) to increase range;

• Use of CS call-sign.

The use of the D/L to the UAV to enable increased range for RT to ATC should be strongly discouraged. The D/L is a single point of failure, when the D/L is lost the UAV is no longer under UAVp control. This is when the UAVp needs RT to ATC however the RT channel was lost when the D/L was lost.

The use of call-signs is a regulatory issue. The use of a CS call-sign is required as the CS and UAV are independent of each other and so should be identified independently.

As a result of the analysis in section 3, the contribution of this project to Safety Critical Systems Engineering is the H/O Requirements that have been generated that can be used

to assess any H/O Procedure that is developed. Also a theoretical H/O Procedure has been generated that can be used as the baseline from which a H/O procedure can be easily developed for an actual CS. In addition the comparison of the H/O Requirements and H/O Procedure has highlighted deficiencies in STANAG 4586.

5.4 Recommendations for Further Work

5.4.1 Development of procedures to form SOP for Ope rational Use

In section 3 of the project ARP 4761 safety assessment diagram was adapted for development of standard operating procedures. The left hand side to derive the H/O Requirements and to develop a H/O Procedure. This is as far in terms of the ARP 4761 adapted safety assessment diagram has been taken. The right side of the diagram requires further development to examine Human Factors (HF) input to the testing of the H/O Procedure and other operating procedures, then the integration of the procedures to form the SOP capable of being flown by UAVps operationally.

5.4.2 H/O of UAV Control Between Cellular Transmitt ers

The project has looked at the conventional ideas of handing control from one CS to another in a chain to get a UAV all the way from A to B because the UAV requires being in line of sight to be controlled.

It would be better if the UAVp could take the UAV all the way from A to B without having to pass the UAV on to another UAVp. It is possible to do this via Satellite Communications (SATCOM) but for a commercial operation the expense of a SATCOM link would be prohibitively expensive. Instead of a series of CSs doted around the country a cellular network of transmitters could be used instead where the H/O is not between UAVps but between transmitters instead. This is the principle on which the cellular mobile phone network is built allowing handsets to roam and still send and receive calls. The mobile network covers most of the UK, yes there are areas which are not covered but this is due to the topography of the area shadowing the signal from the transmitter or else is very remote. A UAV flying at 300ft + should still have LOS to the local transmitter. 2G (second generation) networks are established with 3G (third generation) networks offering higher bandwidth are being rolled out across the UK.

A project to examine the feasibility, safety and security implications of using an already established cellular network that provides mobile voice and data network to be used for the control of UAVs .

5.4.3 Airworthiness issues of the Maintenance of UA Vs

The maintenance of UAVs is a very important airworthiness area. Currently the reliability of UAVs is nowhere near that of manned aircraft due to not only the types of missions flown by UAVs and that UAVs are quite often prototypes but also to maintenance procedure errors. Maintenance of UAVs is a prime area where a project could be undertaken.

5.4.4 Control of UAV on the Ground

In section 2.3 it was noted that for commercial operations UAVs must be able to operate out of commercial airfields. This means the UAVp being able to control the UAV from its location on the apron and navigate the UAV along the taxi ways avoiding unforeseen obstructions, follow instructions from ground control plus being able to see and follow airport signage to the runway for takeoff. On landing to follow ATC instructions where to leave the active runway and again navigate as before but in reverse back to the apron. This is an area where a project could be undertaken to identify the needs of the UAVp to be able to control the UAV and identify the safety risks to other airfield users and to the UAV.

6 References [AAIB, 1992] AAIB, ‘Air Accident Report 1/92 (EW/C1165), Report on the accident to

BAC One-Eleven, G-BJRT over Didcot, Oxfordshire on 10 June 1990’, 1992.

[Andre, 1993] Andre A. D, Cashion P. A, ‘Visual scanning in the functional visual field’, Society for Information Display International Symposium Digest of Technical Papers, 1993.

[Army, 1994] Department of the Army, ‘Army accident investigation and reporting. Army Pamphlet 385-40’, Department of the Army, Washington, DC, 1994.

[Billings, 1996] Billings C. E, ‘Human-Centered Aviation Automation: Principles and Guidelines, NASA Technical Memorandum 110381, NASA, 1996

[Bonner, 2000] Bonner M, Taylor R. M, Miller C, ‘Tasking interface manager: Affording pilot control of adaptive automation and aiding’, McCabe, Hanson, Robertson (Eds) Contempory Ergonomics 2000, pp70-74, London: Taylor and Francis, 2000.

[CAA, 2004] CAA, ‘CAP 722 Unmanned Air Vehicle Operations in UK Airspace – Guidance’, CAA, 2004.

[CAA, 2006] CAA, ‘CAP393, Air Navigation Order’, CAA, 2006. [CAA, 2007] CAA, ‘CAP 493 Manual of Air Traffic Services Part 1’, CAA, 2007. [Calhoun, 2005] Calhoun G.L, Draper M.H, Abernathy M.F, Delgado F, Patzek M,

‘Synthetic vision system for improving UAV operator situational awareness’, Proc SPIE Vol 5802 p219-230 Enhanced and Synthetic Vision, 2005.

[Calhoun, 2006] Calhoun G. L, Draper M. H, ‘Multi-Sensory Interfaces for Remotely Operated Vehicles’, Book: Advances in Human Performance and Cognitive Engineering Research Vol 7: Elsevier, ISBN: 978-0-7623-1247-4, 2006.

[Carbonnell, 1968]

Carbonnell J. F, Ward J. L, Senders J. W, ‘A queuing model of visual sampling: Experimental validation’, IEEE Transactions on Man Machine Systems, MMS-9, 82-87, 1968.

[Ciavarelli, 2001] Ciavarelli A, ‘Cockpit Control and Display Design Hazard Analysis’, School of Aviation Safety Naval Postgraduate School 2001

[Cummings, 2004]

Cummings M. L, Guerlain S, ‘Developing operator capacity estimates for supervisory control of autonomous vehicles’, 2004.

[Cummings, 2006]

Cummings M. L, Kirschbaum A. R, Sulmistras A, Platts J. T, ‘STANAG 4586 Human Supervisory Control Implications’, Air and Weapon Systems Dept, Dstl Farnborough & the Office of Naval Research, 2006.

[DeGarmo, 2004] DeGarmo M. T, ‘Issues Concerning Integration of Unmanned Air Vehicles in Civil Airspace’, 2004

[DGA, 2005] DGA (Délégation générale pour l’Armement), ‘UAV Systems Airworthiness Requirements (USAR)’, DGA, 2005.

[DoD, 2001] Department of Defense, ‘Unmanned aerial vehicles roadmap, 2000-2025’, Washington, DC: Office of the Secretary of Defense, 2001.

[Dixon, 2003] Dixon S. R., Wickens C.D, ‘Control of Multiple-UAVs: A Workload Analysis’, University of Illinois, 2003.

[Dixon, 2004] Dixon S. R, Wickens C. D, ‘Reliability in automated aids for unmanned aerial vehicle flight control: Evaluating a model of automation dependence in high workload’, University of Illinois, 2004.

[Draper, 2005] Draper M.H, Calhoun G. L, Patzek M. J, Feitshans G. L, ‘UAV Human Factors Research within AFRL/HEC’, CERICI, 2nd Annual Human Factors of UAV Workshop, Mesa, AZ, 2005.

[Dury, 2006] Dury J. L, Riek L, Rackliffe N, ‘A Decomposition of UAV-Related Situational Awareness’, Mitre Corp, 2006.

[EASA, 2005] EASA, ‘Advance-NPA No 16/2005, Policy for Unmanned Aerial Vehicle (UAV) Certification’, 2005.

[EC, 216, 2008] European Union, ‘EC Regulation EC 216/2008 on common rules in the field of civil aviation and establishing a European Aviation Safety Agency, EC Regulation EC 216/2008, 2008.

[EC, 1592, 2002] European Union, EC Regulation 1592/2002, 2002. [EC, 1899, 2006] European Union, ‘EC-OPS 1, Commercial Air Transportation

(Aeroplanes)’, EC Regulation 1899/2006, 2006. [ECSS, 1997] European Cooperation for Space Standardization (ECSS), ’Space

Product Assurance: Sneak Analysis – Part 1: Method and Procedure ECSS-Q-40-04A’, European Space Agency (ESA) – ESTEC, 1997.

[ES, 2003] The Ergonomics Society, ‘Ergonomics definition’, Retrieved ‘http://www.ergonomics.org.uk/ergonomics.htm’, 2003.

[EURO, 2001] EUROCONTROL, ‘ESARR 4 – Risk Assessment and Mitigation in ATM’, 2001.

[EUROCAE, 1996]

EUROCAE, ‘ARP 4754 Certification Considerations for Highly-Integrated or Complex Aircraft Systems’, 1996.

[Evans, 2006] Evans A, ‘The Hazards of Unmanned Air Vehicle Integration into Unsegregated Airspace’, 2006.

[Fenelon, 1994] Fenelon P, McDermid J. A, Nicholson M, Pumfrey D. J, ‘Towards Integrated Computer Safety Analysis and Design’, ACM Computing Reviews, Vol. 2, No. 1, p. 21-32, 1994.

[Goldfinger, 2006]

Goldfinger J, Humans Factors of Unmanned Aviation: CERICI Workshop, 2006.

[Haddon, 2002] Haddon D. R, Whittaker C. J, ‘Aircraft Airworthiness Certification Standards for Civil UAVs’, CAA, 2002.

[Hobs, 2006] Hobbs A, Herwitz S. R, ‘Human Challenges in the Maintenance of Unmanned Air Systems’, NASA AMES Research Center, 2006.

[Hottman, 2006] Hottman S. B, Sortland K, ‘UAV Operators, Other Airspace Users, and Regulators: Critical Components of an Uninhabited System’, Book: Advances in Human Performance and Cognitive Engineering Research Vol 7: Elsevier, ISBN: 978-0-7623-1247-4, 2006.

[ICAO, 1996] ICAO, ’Procedures for Air Navigation Services: Rules of the Air and Air Traffic Services’, DOC 4444-RAC/501, Thirteenth Edition, 1996.

[ICAO, 2006] ICAO,’ Safety Management Manual (SMM)’, 2006. [IGL, 2004] NATO, ‘Volume 1 STANAG 4586 Implementation Guideline Document’

Draft, AEP-57, 2004. [JAA, FCL1, 2006]

JAA, ‘JAR-FCL 1 Flight Crew Licensing (Aeroplane)’, JAA, 2006.

[JAA, FCL3, 2006]

JAA, ‘JAR-FCL 3 Flight Crew Licensing (Medical)’, JAA, 2006.

[JAA, JAR1, 2004]

JAA, ‘JAR-1 Definitions and Abbreviations’, JAA, 2004.

[JAA, OPS1, 2007]

JAA, ‘JAR-OPS1 Commercial Air Transportation (Aeroplanes)’, JAA, 2007.

[Kane, 2007] Kane M, ‘Autonomous Systems and Future Capability’, BAE Systems, 2007.

[Mayer, 2007] Meyer J, Altenkirch D, Knorr R, Lenz A, Schattel T, ‘Sense & Avoid for UAVs’, 22nd Bristol UAV Systems Conference, 2007.

[McCarley, 2004] McCarley J. S, Wickens C. D, ‘Human Factors Concerns in UAV Flight, Institute of Aviation, Aviation Human Factors Division, University of Illinois, 2004.

[McCarley, 2005] McCarley J. S, Wickens C. D, ‘Human Factors Implications of UAVs in the National Airspace’, FAA, 2005.

[Manning, 2004] Manning S. D, Rash C. E, LeDuc P. A, Noback R. K, McKeon J, ‘The Role of Human Causal Factors in U.S. Army Unmanned Aerial Vehicle Accidents’, U. S. Army Aeromedical Research Laboratory, 2004.

[Marsters, 2003 Marsters G. F, ‘Ummmm. So Where Does the Pilot Sit?’, Canadian Aeronautics and Space Institute, 2003.

[Martin-Emerson, 1992]

Martin-Emerson R, Wickens C. D, ‘The vertical visual field and implications for the head-up display’, Proceedings of the Human Factors Society 36th Annual Meeting (pp. 1408-1413). Santa Monica, CA: Human Factors Society, 1992.

[MoD, 1996] Ministry of Defence, ‘HAZOP Studies on Systems Containing Programmable Electronics, Part 1: Requirements, Part 2: General Application Guidance’, Issue 1 July 1996.

[Mouloua, 2001] Mouloua M, Gilson R, Daskarolis-Kring E, Kring J, Hancock P, ‘Ergonomics of UAV/UCAV Mission Success: Considerations for Data Link, Control, and Display Issues’, Proceedings of the Human Factors and Ergonomics Society 45 Annual Meeting, 2001.

[NATO, 2004] NATO, ‘STANAG 7085: Interoperable Data Links for Imaging Systems’, Edition 2, NATO, 2004.

[NATO, 2005] NATO, ‘STANAG 4586 – Standard Interfaces of UAV Control System (UCS) for NATO UAV Interoperability’ Edition 2, 2005.

[NATO, 5500, 2006]

NATO, ‘STANAG 5500 NATO Message Text Formatting System (FORMETS) ADatP-3 Build 11’, 2006.

[NATO, 7149, 2006]

NATO, ‘STANAG 7149 NATO Message Catalogue (NMC) – APP 11’, Edition 1, 2006.

[NATO1, 2007] NATO, ‘STANAG 4671 (Draft) UAV Systems Airworthiness Requirements (USAR) for North Atlantic Treaty Organisation (NATO) Military UAV Systems (Edition 1)’, NATO, 2007.

[NATO2, 2007] NATO, ‘STANAG 4586 – Standard Interfaces of UAV Control System (UCS) for NATO UAV Interoperability’ Edition 2.5, 2007.

[Nelson, 2006] Nelson W. T, Bolia R. S, ‘Supervisory Control of Uninhabited Combat Air Vehicles From an Airborne Battle Management Command and Control Platform: Human Factors Issues’, Book: Advances in Human Performance and Cognitive Engineering Research Vol 7: Elsevier, ISBN: 978-0-7623-1247-4, 2006.

[Oron-Gilad, 2006]

Oron-Gilad T, Chen J. Y. C, Hancock P. A, ‘Remotely Operated Vehicles (ROVs) from the Top-Down and the Bottom-Up’, Book: Advances in Human Performance and Cognitive Engineering Research Vol 7: Elsevier, ISBN: 978-0-7623-1247-4, 2006.

[PBS, 2007] Public Broadcasting Service ‘Time Line of UAVs’, website www.pbs.org/wgbh/nova/spiesfly/uavs.html, 2007.

[Pedersen, 2006] Pedersen H. K, Cooke N. J, Pringle H. L, Connor O, ‘UAV Human Factors: Operator Perspectives’, Book: Advances in Human Performance and Cognitive Engineering Research Vol 7: Elsevier, ISBN: 978-0-7623-1247-4, 2006

[Riek, 2006] Riek l, Drury J, ‘Situational Awareness Issues and Approaches for Human-Technology Teams’, Mitre Corp, 2006.

[RPAV, 2002] Remote Piloted Aerial Vehicles, ‘The Aerial Target and Aerial Torpedo in Britain’, http://www.ctie.monash.edu.au/hargrave/rpav_britain.html, 2002.

[RTCA, 2007] RTCA, ‘DO-304 Considerations for Unmanned Aircraft Systems’, RTCA, 2007.

[SAE, 1996] SAE, ‘ARP 4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment’, 1996.

[Sanders, 1970] Sanders, A.F, ‘Some aspects of the selective process in the functional visual field’, Ergonomics, 13, 101-117, 1970.

[Taylor, 2001] Taylor R. M, Abodi S, Dru-Drury R, Bonner M. C, ‘Cognitive cockpit systems: information requirements analysis for pilot control of cockpit automation’, Ch 10, p81-88 in Engineering psychology and cognitive ergonomics Vol 5, Aerospace and transportation systems Ed Harris, pub Ashgate, Aldershot, 2001.

[Tvaryanas, 2004]

Tvaryanas A. P, ‘USAF UAV mishap epidemiology, 1997-2003’, Presented at the Human Factors of Uninhabited Aerial Vehicles First Annual Workshop, Phoenix, AZ, May 24-25, 2004.

[UAVS, 2000] Unmanned Aerial Vehicle Systems Association, ‘A UK Industrial View: The Skills and Qualifications required for the control of UAV Systems in Civil Managed Airspace’, UAVS, 2000.

[usabilityfirst, 2007]

Chromostereopsis ‘http://www.usabilityfirst.com/glossary/term_425.txl’, 2007.

[UoY, 2008] University of York, ‘Ethics in Student Projects’, Department of Computer Science website, 2008

[UTF, 2004] JAA / EUROCONTROL, ‘UAV Task Force Final Report’, EASA, May 2004 [Wickens1, 2003] Wikens C.D, Dixon S, Chang D, ‘Using Interference Models to Predict

Performance in a Multiple-Task UAV Environment - 2 UAVs’, University of Illinois, 2003

[Wickens2, 2003] Wickens C. D, Helleberg J, Horrey W, Goh J, Talleur D, ‘Attentional models of multi-task pilot performance using advanced display technology. Human Factors’, 2003

[Weibel, 2005] Weibel R. E, Hansman R. J, ‘Safety Considerations for Operation of Unmanned Aerial Vehicles in National Airspace System’, MIT International, 2005

[Wikipedia, 2008] Wikipedia, ‘Air Inter Flight 148’, http://en.wikipedia.org/wiki/Air_Inter_Flight_148, May 2008.

[Williams, 2004] Williams K. W, ‘A Summary of Unmanned Aircraft Accident/Incident Data: Human Factors Implications’, FAA, 2004

[Williams, 2006] Williams K. W, ‘Human Factors of Unmanned Aircraft Accidents: Flight-Control Problems’, FAA, 2006

[Williams, 2007] Williams K. W, ‘Unmanned Aircraft Pilot Medical Certification Requirements’, FAA, 2007

[Wilson, 2002] Wilson J, R, ‘UAVs and the Human Factor’, Aerospace America, 2002 [WSJ, 2002] Wall Street Journal, ‘Top Guns Grounded: Pilots Fume at Duty on

Unmanned Craft’, April 29, 2002

A CAA CAP 722 Under CAP 722 UAV are categorised according to mass and whether for recreational or commercial use.

Recreational Use

Commercial Use (Aerial Work)

<7 kg

Small Aircraft' under ANO Art 129 • Minimum operational constraints • No airworthiness standards

'Small Aircraft' under ANO Art 129 • Minimum operational constraints • No airworthiness standards

7-20 kg

'Small Aircraft' under ANO Art 129 • Operational constraints required by ANO Art 87(2)(a) – (d) (See Note 1) • No airworthiness standards

'Small Aircraft' under ANO Art 129 • Operational constraints required by ANO Article 87(2) (a) – (d) (See Note 1) • CAA Permission required under ANO Art 87(2)(e) which is subject to additional constraints as the CAA thinks fit (See Notes 2 and 3) • No airworthiness standards

20-150 kg

• Exemption required against ANO incorporating constraints as the CAA thinks fit (See Notes 1 and 2) • LMA recommendation (or equivalent) in lieu of airworthiness standards

• Exemption required including constraints at Notes 1, 2 and 3 • Impact kinetic energy must be determined to be not more than 95 kJ (See Note 4 ) • Airworthiness recommendation from accredited body (See note 5)

>150 kg

N/A • Existing national operating rules • EASA airworthiness standards

CAP 722 [CAA, 2004]

Note 1: Limits the UAV to among other things to a ceiling of 400 ft.

Note 2: To: • A maximum of 500m;

• Within 150m of any congested area or a city town or settlement;

• Within 50m, of any person, vessel, vehicle or structure not under the control of the aircraft operator except that during the takeoff or landing an aircraft to which this subparagraph applies;

• Shall not fly within 30m of any person other than the person in charge of the said aircraft or a person in charge of any other small aircraft or a person necessarily present in connection with the operation of such an aircraft.

Note 3: Among other things a maximum achievable steady speed in level flight of 70 kts.

Note 4: Kinetic energy limit of 95 kJ – where the kinetic energy of the UAV is a function of mass and speed the example given in CAP 722 that under free fall a UAV of 150 kg the maximum airspeed would be 49 kts.

Note 5: An accredited body to make recommendations for exemptions for the need for an airworthiness certificate.

The CAP 722 approval to operate is being applied to the UAV. However anything that affects the operational safety of the UAV would be covered by airworthiness requirements. Therefore as the Ground Control Station (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. As the CS is part of the airworthiness of the UAV as a system, for the CS to handle.

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 a UAV that can meet these limitations. The UAV to have any sort of payload and endurance never mind the avionics equipment it needs to carry to

be able to fly, navigate and communicate will find it difficult to come under 150 kg. If the UAV is 150 kg then to meet the 95 kJ kinetic energy limit the maximum speed has to be.

B Situational Awareness B.1 Situational Awareness

Dury [2006] defines situational awareness 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:

• 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 sub-headings in Dury’s definition of situational awareness are expanded upon in following text.

B.2 Human-UAV Interaction Awareness

Desert Hawk UAV Photo: [Dury, 2006]

Dury [2006] provides examples of Situational Awareness incidents w.r.t. Desert Hawk UAV: For each human m of all M humans, and for each UAV n of all N UAVs working together on a synchronous task.

ID Incident Type Description SA Component m’s awareness of….

1 Crash. Winds caused loss of aircraft stability too quickly for pilot to take control.

n’s weather.

2 Stuck in orbit. Operator unaware UAV was stuck in an orbit.

Mission progress of n.

3 Multi-UAV, multi-operator night flight confusion.

Both m1 and m2 shouted/ran across the room multiple times to avoid in-flight and landing collisions.

� Activities of M; � Spatial relationships between

n1 and n2; � Mission progress of n1 and n2;

4 Landing Zone Selection.

Prior to flight, m selected a landing zone atop a building due to zooming in too much on the map. (Map was too pixilated).

� Spatial relationships; o between n and points on

earth; o between n and terrain;

� Predicted spatial relationships.

Note: In ID 3, two Desert Hawks, each with their own control station were being flown simultaneously. The position of each other’s UAV was not shown on their respective displays.

Leaving the UAV’s actual 3D spatial relationships aside for the moment, looking at the UAVp’s understand of the different aspects of Dury’s [2006] definition of situational awareness:

B.2.1 Predicted 3D spatial relationships

Dury [2006] describes this as that the UAVp must understand where the UAV will be flying in the near future, and where it will be with respect to points on the earth, other aircraft, terrain and (if necessary) targets. This predictive knowledge is necessary if the operator is to have enough warning to take any corrective or evasive action that might be necessary.

B.2.2 UAV’s mission

The UAV’s mission is pre-planed by the UAVp or if not then checked and accepted by the UAVp as he has the responsibility for the UAV in his charge. The UAVp must have a mental model of what the UAV is to achieve in the mission from the plan and that it is achievable.

B.2.3 UAV’s progress towards completing the mission

When a mission is planned, the route is planned and the expected time at that location is estimated also if loitering or search is planned and how long can the UAV can stay on station so the fuel load can be calculated. The pilot therefore has to know where the UAV is supposed to be and how much fuel / battery life should have been used or can be used while in a search area.

B.2.4 Degree to which the UAV can be trusted

The UAVp as noted in Dury [2006] needs to understand the probability that commands sent to the UAV will be correctly executed, and that the data sent back from the UAV is accurate. There is however as identified by Nelson [2006] over-trust and also under-trust of systems as noted in 2.7.2.5. Over-trust of highly automated systems where the UAVp believes the systems so the occasional malfunction goes unnoticed. Under-trust is where warnings or alerts are ignored or switched off as seen as nuisance excessive false alarms.

B.2.5 Weather near the UAV

This is the weather system the UAVp believes the UAV is currently flying through and what is up ahead. This is from met reports and what can be detected by onboard sensors, turbulence (sudden movement of camera, artificial horizon), icing – onboard temperature sensors, precipitation/ storm clouds – camera. With knowledge of the weather conditions the UAV is flying in / into then the UAVp can make the decision to divert away from the adverse conditions.

B.2.6 Health of the UAV

UAV health status parameters providing the UAVp with such parameters as engine temperature and system alerts warnings should they arise. On the UAVp being alerted to an adverse system condition can make the decision to reconfigure the system to overcome the problem or take emergency action to land at the nearest landing area.

B.2.7 Status of the UAV

UAVp can see and comprehend the UAVS parameters besides the UAVS health parameters such as signal strength, position, fuel level etc.

B.2.8 Logic of the UAV

UAVp has a mental model of how the UAVS works and understands for example what the UAV is programmed to do when the data link is lost. The aspects of Dury’s [2006] situational awareness are satisfied by the understanding of the UAV system, the planned mission, the data from the UAV and incoming weather reports.

B.2.9 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.

A pilot of a manned aircraft can look out of the windscreen and can see.

B.2.9.1 The UAV and points on the earth

The UAVp must know the location of where the UAV is. Knowing this, as part of the mission planning knows how far from the final destination the UAV is, but importantly where the nearest emergency landing area is and that it reachable on engine failure. In addition to this, that the instructions the UAV has on data link failure does not have the UAV trying reach a destination (home) it would not have the fuel for near the end of a flight. UAV which are flown out of normal visual range usually navigate by Global Positioning System (GPS). Passing the UAV’s position back to the CS as part of the normal message data allows the UAV’s position to be displayed on the pilot’s digital moving map display. Using this type of display allows the pilot to compare the UAV’s track against the planned track.

As noted above by a Predator UAVp “It’s like driving your car with paper towel tubes over your eyes…” [Draper, 2005]. With a 30 degree FOV would look similar to the picture below, providing very little context to what the camera is looking at.

This is why even with moving map showing the location of the UAV, the picture below left if presented to the UAVp makes it difficult to relate to the real world.

Photos: [Dury, 2006]

Adding computer generated graphics constructed from databases (terrain, features, maps etc) enables the controller to see the camera’s view within in computer generated graphical prospective effectively giving the UAV’s camera a much wider field of view. In addition where the video imagery is poor due to environmental conditions (dusk, dawn, and weather conditions or data link quality) the computer generated graphics can aid the interpretation of the imagery provided by the camera.

B.2.9.2 The UAV and other aircraft

In segregated airspace there would be no other aircraft unless by arrangement. However in un-segregated airspace (Class A – G) there will be all types of aircraft flying in the different classes of airspace flying in under either VFR or IFR. To be able to fly in all classes of airspace the UAV must be able to sense and avoid other aircraft, both co-operative and uncooperative aircraft. Weibel [2005] identifies co-operative traffic as being capable of broadcasting its position through a transponder (Note: specifically Traffic

Collision and Avoidance System (TCAS), Mode S requires ATC advisory control), and non-cooperative as not broadcasting a transponder signal.

Weibel [2005] reports that NASA in 2003 performed flight testing of various surveillance technologies. Radar mounted on the UAV to detect non-cooperative targets was found to have a limited range of 4 miles, which did not detect targets with enough time to manoeuvre and avoid a collision. In comparison the test pilots reported that their effective range for picking up an aircraft was 1-1.5 nm.

Mayer [2007] Table B-1 compares different types of sensor that could be used to detect non-cooperative aircraft.

LADAR (Laser RADAR)

RADAR Video IR (Infra Red)

Detection range Small Very large Large Moderate Size/mass Heavy Heavy Light Light Adverse Weather Moderate Good Very Bad Bad Electrical Power High High Low Low Complexity High High Low Moderate Night use Yes Yes No / Yes Yes

Table B-1; Comparison of Aircraft Detection Sensors

Mayer [2007] chose to use a combination of both RADAR and Video for flight testing because of the capabilities of RADAR but with high complexity and power consumption vs. Video’s simplicity and low power consumption. No details are given on the detection ranges achieved. Sense and Avoid is a major topic in its own right and is more of a UAV topic than a CS topic so is no more than touched on in this report.

B.2.9.3 The UAV and terrain

The UAVp must now where UAV is in respect to terrain or any other obstacle that the UAV can hit and be destroyed. As part of the navigation planning process will identify terrain or obstacles to be cleared or avoided by a pre-defined safety margin. The pilot’s moving map display will confirm the UAV is maintaining the required track. If while flying, at some point on the planned track the UAV loses the data link. Then as part of UAV’s planned emergency actions to re-establish the data link and / or fly to the designated landing site must allow for terrain and not fly what would seem the shortest route unless a gain in height if feasible.

B.2.9.4 The UAV and any targets

UAVp operator must understand where the UAV is with respect to the target. However, should the UAVp be the one doing the searching for the target?

For a search mission the camera is used to search for, identify and lock on to a target. To effectively search the camera requires being able to be panned up, down, left and right as well as zoomed. To actively search, the camera needs to provide real time images that need to be visually processed and further investigated if a possible sighting of the target is seen.

The role of the UAVp is to monitor aircraft parameters for abnormalities in addition maintain the aspects that together are know as situational awareness as noted above. The UAVp is there to safeguard the UAV. The UAVp could put the UAV into an automatic loiter mode assuming the UAVS had such a mode and then control the camera to carry out the search. While the UAVp is searching for the target he becomes so engrossed in the search, in the mean time the situational awareness of what is happening around the UAV is quickly deteriorating. In addition, the UAV is also not being monitored for problems, nor is the loiter manoeuvre being monitored for drift.

Wickens1 [2003] describes that “flying the UAV, the pilot is using all four stages of the human information processing system (sensory input, perception/cognition, selection of action, execution of action), involving both cognitive and physical requirements. Pilots must understand the data they are receiving, memorize and be able to recall those data, make

decisions based on those data, and when course changes are required, respond by physically using their hands to manipulate the aircraft”.

Wickens1 goes on to also describe the processing need to target search, the task can again require all four stages of the human information processing systems, along with potentially high demands on spatial working memory, especially when a potential target has been found. With the aircraft flying at 60 knots over a variety of terrain, it is often difficult to pick out exactly what is on the ground below. Visual scanning difficulties can be compounded by wide visual angles of the areas to be scanned, clutter, and non-salient targets, all features common to the UAV mission.

The roles of the UAVp and camera controller are both cognitively demanding. The role of camera controller therefore needs to be separate from that of UAVp and be solely responsible for control of the camera to pan and zoom, visually processing the images coming in searching for the target and when found communicated back to base. The camera operator would not work in isolation from the UAVp but provide input to the UAVp to direct the UAV over to another area for a closer look.

Combining the roles of camera controller with that of UAVp will lead to UAVp overload quite quickly. For the UAVp to carryout both roles then neither is going be done effectively.

It is important for the Camera Controller to comprehend what he is seeing from the video display from the camera. As noted above, adding computer generated graphics enables the controller to see the camera’s detailed view within the computer generated graphical prospective effectively giving the camera a much wider field of view showing where the camera is pointing relative to the UAV. Photo: [Riek, 2006]

.

Further enhancement is achieved by adding selectable overlays identifying landmarks and reference points, to aid the camera controller especially in a highly cluttered visual scene. Calhoun [2005] identifies this concept of using computer-generated overlays to appear to ‘co-exist’ with real objects in the imagery, to highlight points and regions of interest as ‘augmented reality’. An example of which is shown left. Photo: [Calhoun, 2005]

This page is intentionally blank

C Severity Criteria C.1 Airworthiness Failure Condition Severities

Airworthiness Failure Condition Severities (after [SAE, 1996], with additions from [UTF, 2004] as noted)

Failure Condition Severity Classification

FAA Minor Major Severe Major Catastrophic

JAA Minor Major Hazardous Catastrophic Existing Failure Condition Effect criteria. (FAA & JAA / EASA).

- Slight reduction in safety margins. - Slight increase in crew workload. - Some inconvenience to occupants.

- Significant reduction in safety margins or functional capabilities. - Significant increase in crew workload or in conditions impairing crew efficiency. - Some discomfort to occupants.

- Large reduction in safety margins or functional capabilities. - Higher workload or physical distress such that the crew could not be relied on to perform tasks accurately or completely. - Adverse effects upon occupants.

- All failure conditions which prevent continued safe flight and landing.

Proposed UAVS criteria (taken from UAV Task Force [UTF, 2004]).

- Slight reduction in safety margins (e.g. loss of redundancy).

- Significant reduction in safety margins (e.g., total loss of communication with autonomous flight and landing on a predefined emergency site).

- Controlled loss of the UAV over an unpopulated emergency site, using Emergency Recovery procedures where required.

UAV's inability to continue controlled flight and reach any predefined landing site.

Airworthiness Failure Condition Severities (after [SAE, 1996], with additions from [UTF, 2004] as noted).

C.2 ATM-Focused Separation / Collision Safety Crite ria

EUROCONTROL ATM-Focused Separation / Collision Safe ty Criteria (from [EURO, 2001])

Failure Condition Severity Classification

Severity 5 - No Immediate Effect on Safety

Severity 4 - Minor Incidents

Severity 3 - Significant Incidents

Severity 2 - Major Incidents Severity 1 - Accidents

Failure Condition Effect.

- No hazardous condition i.e. no immediate direct or indirect impact on the operations.

- Increasing workload of the air traffic controller or [UAVS] crew, or slightly degrading the functional capability of the enabling CNS System. - Minor reduction (e.g., a separation of more than half the separation minima) in separation with [UAVS] crew or ATC controlling the situation and fully able to recover from the situation.

- Large reduction (e.g., a separation of less than half the separation minima) in separation with [UAVS] crew or ATC controlling the situation and able to recover from the situation. - Minor reduction (e.g., a separation of more than half the separation minima) in separation without [UAVS] crew or ATC fully controlling the situation, hence jeopardising the ability to recover from the situation (without the use of collision or terrain avoidance manoeuvres).

- Large reduction in separation (e.g., a separation of less than half the separation minima), without [UAVS] crew or ATC fully controlling the situation or able to recover from the situation. - One or more aircraft deviating from their intended clearance, so that abrupt manoeuvre is required to avoid collision with another aircraft or with terrain (or when an avoidance action would be appropriate).

- One or more catastrophic accidents. - One or more mid-air collisions. - One or more collisions on the ground between two aircraft. - One or more Controlled Flight Into Terrain. - Total loss of flight control. - No independent source of recovery mechanism, such as surveillance or ATC and/or [UAVS] crew procedures can reasonably be expected to prevent the accident(s).

Note: Evans [2006] substitution of [UAVS] for flight crew references

EUROCONTROL ATM-Focused Separation / Collision Safety Criteria from [EURO, 2001].

D Consolidated FFA Hazards ID Hazard Related FHA

IDs C1 UAVp unable to manoeuvre UAV when commanded. 1.1.1.A, 1.1.2.B C2 UAVp unable to manoeuvre UAV in one or more axes when commanded. 1.1.1.B

C3 Flight control instability. 1.1.1.C, 1.1.1.D, 1.1.1.E, 1.1.2.C, 1.1.3.C, 1.1.3.F

C4 UAVp inability to control UAV sufficiently to fly intended course. 1.1.1.F, 1.1.1.G, 1.1.1.H, 1.1.2.E, 1.1.2.G, 1.1.2.H, 1.1.3.H, 1.1.3.I

C5 Significant lag between commanded manoeuvre and execution. 1.1.1.I, 1.1.2.I, 1.1.3.J

C6 UAV structural integrity unable to meet demands placed upon it. 1.1.1.J, 1.1.2.J, 1.1.3.K

C7 UAVp unable to change UAV configuration. 1.1.2.A, 1.1.3.A C8 Uncommanded change to UAV configuration. 1.1.2.D, 1.1.3.D

C9 Commanded input is not achievable by UAV. 1.1.2.F, 1.1.3.G C10 UAVp unable to make mission changes when required. 1.1.3.B C11 Wrong or unintended mission correction sent to UAV. 1.1.3.E C12 All flight instruments blank/frozen denying UAVp the ability control UAV. 2.1.A C13 Single UAV flight instrument is frozen forcing UAVp to derive data from

other sources. 2.1.B

C14 Flight instrument(s) display incorrect data or labelled in wrong units providing misleading data to UAVp.

2.1.C, 4.2.2.C

C15 Significant lag between UAVp input and flight instrument(s) registering change making UAV control difficult.

2.1.D, 2.2.C

C16 UAV video display frozen, blank, broken up or inappropriate zoom level denying UAVp the ability to maintain SA.

2.2.A, 2.2.B, 2.2.D

C17 UAV mission map display frozen, blank or at an inappropriate scale denying UAVp the ability to maintain SA.

2.3.1.A, 2.3.1.B, 2.3.1.C

C18 UAV mission map display provides misleading data resulting in UAVp not knowing where UAV actually is.

2.3.1.D, 2.3.1.E, 2.3.1.F, 2.3.2.A, 2.3.2.B, 2.3.2.C, 2.3.2.D, 2.3.2.E

C19 Air traffic is not displayed, frozen or incorrectly positioned providing misleading SA information to UAVp.

2.3.3.A, 2.3.3.B, 2.3.3.C, 2.3.3.D, 2.3.3.E

C20 UAV actual track position / altitude vs. expected position / altitude not displayed, frozen or incorrectly positioned providing misleading SA information to UAVp.

2.3.4.A, 2.3.4.B, 2.3.4.C

C21 UAV fuel estimation for destination /diversion frozen or significantly under estimated misleading the UAVp to believe UAV has enough fuel.

2.3.5.A, 2.3.5.B

C22 UAV system status display blank or frozen for significant period denying UAVp visibility of any system errors /failures.

2.4.A, 2.4.B

C23 UAV system parameter data frozen, incorrectly displayed or labelled in wrong units providing misleading information to UAVp.

2.4.C, 2.4.D

C24 Failure of alarm system to notify the crew of system errors / failures. 3.1.A, 4.1.2.A C25 Alarm system provides false Alert /Warning (A/W) resulting in UAVp

distrusting the alarm system. 3.1.B, 3.2.B, 3.2.E, 4.1.2.C, 4.1.2.D

C26 Alarm system incorrectly identifies or fails to identify what A/W is for misleading UAVp.

3.1.C, 3.2.A, 3.2.C,3.2.D, 4.1.2.B

C27 Alarm system fails to prioritise errors / failures. 3.1.D, 3.2.F, 4.1.2.E

ID Hazard Related FHA IDs

C28 UAVp unable to reset / silence alarm system masking further error /failures. 3.1.E

C29 UAV related A/W sent to CS1 not passed electronically or orally to CS2 UAVp at handover.

3.1.F

C30 D/L signal strength display is blank or frozen denying UAVp visibility of any errors /failures.

4.1.1.A

C31 D/L display provides incorrect signal strength / status data misleading UAVp.

4.1.1.B

C32 D/L signal noisy / level wildly fluctuating so difficult to read so not providing the UAVp with the required visibility of the D/L status.

4.1.1.C

C33 D/L message data is not translated resulting in loss of communications between CS and UAV.

4.2.1.A

C34 D/L message data is incorrectly translated or corrupted messages translated.

4.2.1.B, 4.2.1.E, 4.2.3.A

C35 D/L message data meant for other CS or UAV is translated. 4.2.1.C C36 Message received is out of sequence or previous messages missing. 4.2.1.D C37 Message data not converted or incorrectly converted to intended data

units. 4.2.2.A, 4.2.2.B

C38 Corrupted message identified but no resend request sent. 4.2.3.B C39 D/L messages incorrectly discarded as corrupt and resend requested. 4.2.3.C

C40 CS dish alignment control is unable to maintain D/L with UAV. 4.3.1.A, 4.3.1.B, 4.3.1.C, 4.3.1.D, 4.3.1.E, 4.3.1.F, 4.3.1.G, 4.3.1.H, 4.3.1.I

C41 UAV dish alignment position for CS2 handover not sent to / received by UAV.

4.3.2.A, 4.3.3.A

C42 Uncommanded dish position adjustment sent to / applied by UAV. 4.3.2.B, 4.3.3.B C43 Incorrect UAV dish alignment for CS2 handover sent to / applied by UAV. 4.3.2.C, 4.3.2.D,

4.3.3.C C44 UAVp is unable change ATC frequency selection. 5.1.A C45 UAVp is unable to communicate with ATC as unable to maintain frequency

selected. 5.1.B, 5.1.C

C46 UAVp communicates with an unintended ATC on an unintended or emergency frequency.

5.1.D, 5.1.E, 5.2.H

C47 CS1 or CS2 UAVp is unable to clearly hear / understand area ATC comms. 5.2.A, 5.2.B, 5.2.C, 5.2.G

C48 CS1 or CS2 UAVp is unable to communicate with area ATC. 5.2.D C49 CS unintentionally transmits on ATC channel. 5.2.E C50 CS UAVp complies with / replies to instruction meant for other A/C. 5.2.F C51 ATC confused as talking to two different pilots about same aircraft. 5.2.I C52 UAVp unintentionally provides wrong information to ATC. 5.2.J C53 UAVp in one CS is unable to clearly hear / understand the UAVp in the

other CS. 5.3.A, 5.3.B, 5.3.C, 5.3.E

C54 Unintended communication between CS1 and CS2. 5.3.D C55 Excessive delay in UAVp response to other CS. 5.3.F C56 UAVp unintentionally provides wrong information to other CS UAVp. 5.3.G C57 No emergency procedures in place or procedures do not cover current

situation. 5.4.A

C58 UAVp unable communicate with ATC to declare an emergency. 5.5.A C59 UAVp declares an emergency to ATC when not required. 5.5.B C60 UAVp declares wrong type emergency to ATC. 5.5.C C61 H/O has not been co-ordinated between the two CS UAVps. 6.1.A C62 Uncommanded D/L switchover puts CS2 in control of UAV. 6.1.B C63 CS1 is ready and needs to handover but CS2 is not ready nor in a position

to take control. 6.1.C

C64 CS1 hands over UAV but CS2 or other CS is unaware it now has control. 6.1.D

C65 CS2 has control of the UAV but CS1 is unaware CS2 has control. 6.1.E

ID Hazard Related FHA IDs

C66 CS2 has control of the UAV but CS1 also has control (dual control). 6.1.F C67 CS1 has released control of the UAV but CS2 has not taken control (no

control). 6.1.G

C68 CS1 has lost data link but CS2 has not taken control (no control). 6.1.H C69 Handover continues outside window allocated for handover (both time and

area handover to take place). 6.1.I

C70 UAVp is unable to coordinate handover of UAV from CS1 to CS2 with ATC. 6.2.A

C71 No connection re-established to UAV after D/L break during handover. 6.3.1.A C72 D/L connection broken during handover when not expected with no

connection made. 6.3.1.B

C73 Connection re-established to UAV after D/L break during handover but to other unintended CS.

6.3.1.C

C74 Poor signal quality / strength on new D/L connection to CS. 6.3.1.D, 6.3.1.E C75 Intended frequency for D/L to UAV already in use by other CS or D/L

equipment. 6.3.1.F, 6.3.1.G

C76 Unexpected D/L connection made during handover (make before break) between UAV and other CS (not CS2).

6.3.2.B

C77 D/L connection made during handover (make before break) results in UAVps for both CS1 and CS2 in control of UAV (dual control).

6.3.2.F

C78 Low, fluctuating signal strength on both D/L connections (make before break) between the CSs and the UAV resulting in no UAV control.

6.3.2.G

C79 Addition MBB D/L results in command and /or data race condition resulting in changing the intent of a set of message.

6.3.3B

C80 MBB D/L channels provide different data (one channel corrupted or both but corrupted differently).

6.3.3C

C81 MBB D/L channels out of synch resulting in different message parts merged resulting in the corruption and misinterpretation of the message.

6.3.3D

C82 MBB D/L channels out of synch resulting in messages incorrectly compared and discarded resulting in loss of D/Ls.

6.3.3E

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

ID Recommendation R1 Where UAV is controllable but only by secondary effects of other flight controls. UAVp to

abort H/O immediately. R2 Where UAV is uncontrollable due to excessive or incorrect control surface response then

UAVp is to abort H/O immediately. R3 All commands must identify who they are for and from. Any commands not meant for UAV

or CS to be rejected by receiving system. R4 Corrupt messages to be identified, rejected and a request for the message to be resent. R5 Where UAV control glitches are experienced by UAVp, UAVp H/O acceptance or rejection

due to magnitude of control glitches is at UAVp's discretion. R6 UAV with no rudder control is flyable in flight, but cannot be landed in a crosswind.

UAVp's discretion if UAV H/O accepted or rejected depending on method used to land UAV or landing can be arranged to be head to wind.

R7 Cut engine command requires confirmation of UAVp or weight on wheels before cut engine executed.

R8 Where UAVp does not have full throttle control (which includes lack or excessive control) then H/O is to be rejected.

R9 Excessive or incorrect response to UAVp commanded changes in airspeed, altitude or heading the H/O is to be rejected immediately.

R10 No or minimal response to UAVp commanded changes in airspeed, altitude or heading the H/O is to be rejected immediately.

R11 When UAV control is only by mission / waypoint update (no direct CS control) and UAV does not respond to updates H/O to be rejected.

R12 Track and altitude of UAV to be monitored by UAVp throughout the period the UAV is in his charge.

R13 H/O in manual control is not to be attempted if D/L is BBM. If D/L is MBB H/O only to attempted if CS2 UAVp knows and is ready to take immediate control on H/O.

R14 Clear indication to UAVp when UAV autopilot is engaged / disengaged. R15 No H/O if UAV tail ID is not provided or does not match that identified in mission plan. R16 No H/O is to take place until CS1 has provided UAV_Type. R17 If UAV_Type provided by CS1 does not match that provided by UAV, D/L to be rejected

immediately. R18 UAVp's discretion if UAV H/O accepted or rejected if UAV video is not available. R19 UAV not to be flown without flight plan / mission, may be updated after H/O. R20 H/O to be rejected unless extenuating circumstances exist 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). UAVp's discretion if UAV H/O accepted or rejected.

R21 Position data for incoming UAV may be displayed but clearly identified as the next UAV to provide UAVp with the SA of how far the next UAV is away and an ETA. The position data for next UAV if received before current UAV is dealt with shall be stored separately, away from current UAV data.

R22 H/O to be rejected unless other extenuating circumstances exist as to 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). UAVp's discretion if UAV H/O accepted or rejected.

R23 If UAVp aware of reason for data display error is due to display mislabelling or incorrect scaling then UAVp's discretion if UAV H/O accepted or rejected.

R24 If airspeed not provided can be estimated from other flight instruments. UAVp's discretion if UAV H/O accepted or rejected.

R25 If heading not provided or incorrect then can be estimated from tracked position. UAVp's discretion if UAV H/O accepted or rejected.

R26 H/O to be rejected unless other extenuating circumstances exist 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). UAVp's discretion if UAV H/O accepted or rejected.

ID Recommendation R27 RPM can be estimated from throttle position and airspeed, UAV flyable. UAVp's discretion

if UAV H/O accepted or rejected. R28 If UAV system status (fuel, engine etc) not provided. UAVp to accept UAV H/O but mission

aborted and UAV landed at the nearest available airfield. R29 CS2 UAVp shall be allowed as part of the mission plan reasonable time to reconfigure and

initialise the CS. R30 CS2 UAVp to follow checklist to fully reconfigure and initialise CS without taking

unauthorised shortcuts. Co-pilot used (if applicable) to double check checklist actions have been correctly executed.

E.2 Part 2 Analysis: H/O Sequence Recommendations

ID Recommendation R31 System H/O stage needs to be identified to UAVps. R32 System to inform UAVp if incorrect or inappropriate command entered. R33 CS1 / CS2 comms must not be via D/L. If D/L to UAV lost is when inter UAVp comms

most needed. R34 All commands must identify who they are for and from. Any commands not meant for UAV

or CS to be rejected by receiving system.

civil airworthiness for a uav control …mark/projects/cjh507_project.pdf · civil airworthiness...

Documents