INVIRCAT Current State-of-the-Art and regulatory basis

INVIRCAT Current State-of-the-Art and regulatory basis

Deliverable ID: D2.1

Dissemination Level: PU

Project Acronym: INVIRCAT

Grant: 893375 Call: H2020-SESAR-2019-2 Topic: Control of IFR RPAS in the TMA Consortium Coordinator: DLR Edition date: 01 February 2021 Edition: 00.01.02 Template Edition: 02.00.02

EXPLORATORY RESEARCH

INVIRCAT CURRENT STATE-OF-THE-ART AND REGULATORY BASIS

2

Authoring & Approval

Authors of the document

Name/Beneficiary Position/Title Date

Edoardo Filippone, CIRA Project Member 28-Jul-2020

Florian Löhr, DLR Project Member 05-Oct-2020

Gunnar Schwoch, DLR Project Member 05-Oct-2020

Gabriella Duca, ISSNOVA Project Member 24-Sept-2020

Miguel-Ángel Fas-Millán, DLR Project Member 24-Sep-2020

Vittorio Sangermano, ISSNOVA Project Member 01-Oct-2020

Mariano Gómez Plaza, ISDEFE Project Member 24-Oct-2020

Giancarlo Ferrara, EUROCONTROL Project Member 20-Oct-2020

Luca Bellesia, EUROCONTROL Project Member 20-Oct-2020

Jürgen Teutsch, NLR Project Member 05-Oct-2020

Reviewers internal to the project


Mariano Gómez Plaza, ISDEFE Project Member 27-Nov-2020

Gabriella Duca, ISSNOVA Project Member 17-Nov-2020

Florian Löhr, DLR Project Member 10-Nov-2020

Miguel-Ángel Fas-Millán, DLR Project Quality Leader 26-Nov.2020

Vittorio Sangermano, ISSNOVA Project Member 27-Nov-2020

Approved for submission to the SJU By - Representatives of beneficiaries involved in the project


Edoardo Filippone, CIRA Project Member 25-Nov-2020

Mariano Gómez Plaza, ISDEFE Project Member 26-Nov-2020

Florian Löhr, DLR Project Member 25-Nov-2020

Robert Geister, DLR Project Member 25-Nov-2020

Gabriella Duca, ISSNOVA Project Member 27-Nov-2020

Luca Bellesia, EUROCONTROL Project Member 27-Nov-2020

Emmanuel Sunil, NLR Project Member 27-Nov-2020

Damiano Taurino, DBL Project Member 27-Nov-2020


3

Rejected By - Representatives of beneficiaries involved in the project


Document History

Edition Date Status Author Justification

00.00.01 28-Jul-2020 Draft ToC Edoardo Filippone Initial Draft

00.00.02 06-Nov-2020 Draft Edoardo Filippone Consolidated initial contributions

00.01.00 20-Nov-2020 Integrated document Edoardo Filippone Fully Integrated Document

00.01.01 27-Nov-2020 Final Release Edoardo Filippone Deliverable approved for submission

00.01.02 01-Feb-2021 Final Revision Riccardo Rocchio Revision after review

Copyright Statement

© – 2020 – INVIRCAT Consortium. All rights reserved. Licensed to the SESAR Joint Undertaking under conditions.


4

INVIRCAT INVIRCAT

This deliverable is part of a project that has received funding from the SESAR Joint Undertaking under grant agreement No 893375 under European Union’s Horizon 2020 research and innovation programme.

Abstract

The report represents the contractual deliverable D2.1.

The deliverable first identifies and limits the operational environment with reference to which the new CONOPS, as proposed by the INVIRCAT project, will be developed.

It further includes an analysis of the RPAS architecture addressed in the project, and then characterizes the kind of operations typically expected to be carried out by the category of RPAS identified above.

The State-of-the-art analysis then addresses the technologies enabling the RPAS operations, the humans’ (both RPAS pilots’ and Air Traffic Controllers’) roles and responsibilities with regard RPAS operations.

Regulatory and standards issuing agencies and bodies are identified in the document, and the selection of the relevant documents issued so far by those entities are listed. This list is not thought to represent a full certification or a regulatory basis for RPAS, but a sound reference material for the development of the CONOPS, by taking into account the applicable reference rules and experiences.

Further on, in order to collect and use all the activities already carried out on the topic, primarily in Europe, relevant projects will be analysed and described.


5

Table of Contents

Abstract ................................................................................................................................... 4

1 Introduction ............................................................................................................... 8

1.1 Purpose and Scope of the Document .............................................................................. 8

1.2 Structure of the Document ............................................................................................ 8

1.3 Relationship with other Documents ............................................................................... 9

2 Envelope of Operations ............................................................................................ 10

2.1 Context and Classification of IFR RPAS Operations ........................................................ 10

2.2 Operational Challenges ................................................................................................ 14

2.3 ATM / U-Space Transition and Interoperability Aspects ................................................ 15

3 State of the Art ........................................................................................................ 20

3.1 RPAS Description ......................................................................................................... 20

3.2 RPAS Operations in TMA .............................................................................................. 24

3.3 Technology Enablers .................................................................................................... 26 3.3.1 Communication ............................................................................................................................... 27 3.3.2 Navigation ....................................................................................................................................... 30 3.3.3 Surveillance ..................................................................................................................................... 34 3.3.4 Avionics ........................................................................................................................................... 35

3.4 Human Factors, Roles & Responsibilities ...................................................................... 44 3.4.1 Pilot Related Human Factors ........................................................................................................... 44 3.4.2 ATCOs related Human Factors ........................................................................................................ 48 3.4.3 Remote Pilot Role and Responsibilities ........................................................................................... 51 3.4.4 Air Traffic Controller Role and Responsibilities ............................................................................... 55

3.5 Applicable Regulations ................................................................................................ 56 3.5.1 ICAO, International Civil Aviation Organization .............................................................................. 56 3.5.2 EASA, European Aviation Safety Agency ......................................................................................... 57 3.5.3 EUROCONTROL ................................................................................................................................ 58 3.5.4 JARUS, Joint Authorities for Rulemaking on UAS ............................................................................ 59

3.6 Technical Standards ..................................................................................................... 60 3.6.1 EUROCAE, European Organisation for Civil Aviation Equipment .................................................... 60 3.6.2 RTCA, Radio Technical Commission for Aeronautics ....................................................................... 62

3.7 Interoperability ATM/U-space Aspects ......................................................................... 64 3.7.1 ICAO................................................................................................................................................. 64 3.7.2 EASA/EUROCONTROL ...................................................................................................................... 65 3.7.3 U-space ............................................................................................................................................ 65

3.8 Drone Swarms ............................................................................................................. 68 3.8.1 Drone Swarms in Airports ............................................................................................................... 70

4 RPAS Operations in TMA: Related Projects ............................................................... 72

4.1 MALE RPAS Integration (NLR/General Atomics) ............................................................ 72


6

4.1.1 General Description ........................................................................................................................ 72 4.1.2 Operational Concept under Analysis ............................................................................................... 72 4.1.3 Technologies Investigated ............................................................................................................... 74 4.1.4 Overall Findings and Conclusions .................................................................................................... 74 4.1.5 Relations with INVIRCAT ................................................................................................................. 75

4.2 SINUE and DeSIRE ........................................................................................................ 75 4.2.1 General Description ........................................................................................................................ 75 4.2.2 Operational Concept under Analysis ............................................................................................... 76 4.2.3 Technologies Investigated ............................................................................................................... 76 4.2.4 Overall Findings and Conclusions .................................................................................................... 76 4.2.5 Relations with INVIRCAT ................................................................................................................. 77

4.3 USICO .......................................................................................................................... 77 4.3.1 General Description ........................................................................................................................ 77 4.3.2 Operational Concept under Analysis ............................................................................................... 77 4.3.3 Technologies Investigated ............................................................................................................... 77 4.3.4 Overall Findings and Conclusions .................................................................................................... 78 4.3.5 Relations with INVIRCAT ................................................................................................................. 78

4.4 UFO (Unmanned Freight Operations) – Phase 1 ............................................................ 78 4.4.1 General Description ........................................................................................................................ 78 4.4.2 Operational Concept under Analysis ............................................................................................... 78 4.4.3 Technologies Investigated ............................................................................................................... 79 4.4.4 Overall Findings and Conclusions .................................................................................................... 79 4.4.5 Relations with INVIRCAT ................................................................................................................. 79

4.5 SESAR RPAS Demonstration Projects ............................................................................ 79 4.5.1 DEMORPAS ...................................................................................................................................... 80 4.5.2 INSURE............................................................................................................................................. 81 4.5.3 MEDALE ........................................................................................................................................... 83 4.5.4 TEMPAERIS ...................................................................................................................................... 85 4.5.5 ODREA ............................................................................................................................................. 86 4.5.6 CLAIRE ............................................................................................................................................. 88 4.5.7 Relations with INVIRCAT ................................................................................................................. 90

4.6 SESAR Industrial Research Projects: PJ10-05 PROSA / PJ13-ERICA ................................. 91 4.6.1 General Description ........................................................................................................................ 91 4.6.2 Operational Concept under Analysis ............................................................................................... 91 4.6.3 Technologies Investigated ............................................................................................................... 92 4.6.4 Overall Findings and Conclusions .................................................................................................... 92 4.6.5 Relations with INVIRCAT ................................................................................................................. 93

5 Conclusions .............................................................................................................. 94

6 References ............................................................................................................... 95

Appendix A .................................................................................................................... 103

A.1 Glossary of terms ........................................................................................................ 103

A.2 List of Acronyms ......................................................................................................... 104


7

List of Tables Table 1: Performance characteristics of some IFR RPAS models (Source: Wikipedia) ......................... 11

Table 2: Airspace classes and relevance to INVIRCAT ........................................................................... 12

List of Figures Figure 1 - U-space Services (Source: CORUS CONOPS) ......................................................................... 17

Figure 2 - RPAS components and C2L alternatives (Source: PJ10-05 OSED) ......................................... 21

Figure 3 - RPAS Classification ................................................................................................................ 23

Figure 4 - Flight phases .......................................................................................................................... 28

Figure 5 - RPAS communication with ATC (Source: RPAS Integration in Non-segregated Airspace: the SESAR Approach) ................................................................................................................................... 29

Figure 6 - Current Situation for Civil GNSS Based Approach & Landing ................................................ 32

Figure 7 - World Coverage of Operational or Under Development Civil SBAS ..................................... 32

Figure 8 - Control and Communication (C2) link ................................................................................... 45

Figure 9 - Phases of a lost link event (Source: Human Factors Guidelines for Remotely Piloted Aircraft System Remote Pilot Stations, 2016) .................................................................................................... 46

Figure 10 - C2 Link ATCO control ........................................................................................................... 50

Figure 11 - Responsibilities of the remote pilot (Source: Mutuel, Wargo & DiFelici, 2015) ................. 52

Figure 12 - U-space levels, from the U-space Blueprint (Source: CORUS CONOPS) ............................. 66

Figure 13 - U-space services (Source: CORUS CONOPS) ........................................................................ 67

Figure 14 - First MALE RPAS RTS Facility (MRRF) Component: NLR ATC Research Simulator (NARSIM) ............................................................................................................................................................... 73

Figure 15 - Second MALE RPAS RTS Facility (MRRF) Component: Multi UAS Supervision Testbed (MUST) ............................................................................................................................................................... 73


8

1 Introduction

1.1 Purpose and Scope of the Document

The purpose of the document is to “set the scene” for the development of concepts and to define the framework for the activities to be performed in the INVIRCAT project.1

To this aim, the document identifies the relevant aspects involved in the RPAS operations in TMA and on airports. The RPAS integration in TMA operations remains a very wide and complex issue, thus the document is intended to help to clearly define the boundaries with which the project will deal.

The state-of-the art of activities, concerned with the identified framework, is then considered as the starting point to provide all other activities the support to focalize and correctly address the efforts.

Technologies, human aspects, and applicable rules and standards are main aspects that have been identified as a most relevant elements to be assessed in the state-of the-art analyses. Together with those aspects, the activities already carried out in Europe, and with a specific focus in the SESAR context, are considered as relevant in order to correctly address new activities, building on all previous experience and results. Consequently, the analysis of past recent projects is part of the purpose of the present report.

Because of the relevance that the U-Space definition and implementation has and, more and more strongly, will have in Europe, the possible interaction with the RPAS operations is considered also in the scope of the project and analysed in the report.

1.2 Structure of the Document

Following the main relevant aspects as identified in the previous section, the document has been structured using the following organization:

1. Envelope of Operations (Chapter 2), in which the specificities of the project are clearly stated, by identifying the overall operational environment and RPAS characteristics that apply to the INVIRCAT project.

2. State-of-the-Art (Chapter 3), which in turn is structured in Technologies, Human Factors, Applicable Rules and Standards. Because of the above-mentioned relevance, a section is furthermore addressed to state the current interactions with U-Space. Finally, the possibility to consider interactions with swarm of vehicles in the proximity of airports is analysed.

Relevant Regulations and standards are listed for possible application to INVIRCAT concerned operations.

1 The opinions expressed herein reflect the author’s view only. Under no circumstances shall the SESAR Joint Undertaking be responsible for any use that may be made of the information contained herein.


9

3. Related Projects (Chapter 4), in which projects and programs relevant to the present activities, both already concluded or on-going, are described in terms of their goals and, eventually, achievements, and in terms of their relations and impact on INVIRCAT activities.

4. Conclusion (Chapter 5), which summarizes the main elements arising from the report.

5. References (Chapter 6), which lists the documentation utilized for selecting the most relevant points as reported in the document.

1.3 Relationship with other Documents

The document represents the first expected deliverable for the INVIRCAT project. It is intended to support the selection of use cases, as carried out in WP2 and described in the deliverable D2.2, the detailed description of scenarios, as expected in the deliverable D2.3, and possibly the development of the test plan (WP3).

The document could also support the Advisory Board members introduction to the deep analysis of the project activities and starting point identification.


10

2 Envelope of Operations

Remotely Piloted Aircraft Systems (RPAS) are a fairly new addition to the world of aviation and imposing great challenges to its safety and security concepts, that heavily rely on the see and avoid capabilities under VFR conditions and the interaction between ATC and pilot under IFR conditions. Until today, RPAS missions require segregated airspaces, largely restricting their operational capabilities and economic viability.

In recent years European airspaces, especially TMAs and airports, have approached their capacity limits, making them the bottleneck of the industry [2]. Even though the manned aviation business is going through a global crisis due to the Covid-19 pandemic and recent traffic forecasts indicate a prolonged recovery [1], full retrieval within the years 2022 to 2025 and further growth are to be expected [12],[14]. With respect to the rapid progress of technical solutions and the predicted market growth for RPAS, the European ATM Masterplan [24], therefore targets the full integration of RPAS (and other UAS) by 2035 in both, controlled and uncontrolled airspaces. Within this plan, the first step out of three marks the integration of RPAS in classes A-C under IFR conditions.

Following previous research within SESAR PJ.10-05 [26] that proposed a Concept of Operations (CONOPS) for RPAS under IFR conditions, INVIRCAT specifically emphasises on the operations and technical requirements within the Terminal Manoeuvring Area (TMA), including the investigation of the influence of C2 latency, to enable the full integration into busy environments with minimal impact on separation buffers. Is useful to remark that VFR operation are outside of the scope of INVIRCAT project.

2.1 Context and Classification of IFR RPAS Operations

RPAS definition, architecture and classification will be detailed in section 3.1, where general applicable information are provided. For the scope of the present section, some specific information are here below summarized.

To classify unmanned aircraft, in 2015 the European Aviation Safety Agency (EASA) proposed an operation centric, proportionate, risk- and performance-based regulatory framework, distinguishing between three classes: Open, specific and certified [8]:

‘Open’ category (low risk): safety is ensured through operational limitations, compliance with industry standards, requirements on certain functionalities, and a minimum set of operational rules. Enforcement shall be ensured by the police.

‘Specific operation’ category (medium risk): authorisation by National Aviation Authorities (NAAs), possibly assisted by a Qualified Entity (QE) following a risk assessment performed by the operator. A manual of operations shall list the risk mitigation measures.

‘Certified’ category (higher risk): requirements comparable to manned aviation requirements. Oversight by NAAs (issue of licences and approval of maintenance, operations, training, Air Traffic Management (ATM)/Air Navigation Services (ANS) and aerodrome organisations) and by EASA (design and approval of foreign organisations).

The operation of RPAS can also be classified in three altitude-based categories [3]:


11

Very High Level (VHL): Operations above FL600, currently without traffic management in most parts of the world and generally above the range of commonly used altitudes.

Instrument Flight Rules (IFR) & Visual Flight Rules (VFR): Operations between 500ft and FL600, including airspaces in proximity to airports.

Very Low Level (VLL): Operations below 500ft, within (VLOS) or beyond the visual line of sight (BVLOS).

The project’s goals are the creation of a comprehensive high-level set of operational and technical requirements and a CONOPS to safely integrate RPAS into the existing ATC procedures in TMA and airports under Instrument Flight Rules (IFR). This will include the consideration of all ATC instructions in the airport and TMA environment (e.g. headings and altitudes requests, take-off and landing clearances, and late go-around instructions) as well as taxiing and Automatic Take-Off and Landing (ATOL) procedures. Therefore, the project will focus its work on RPAS in the ‘Certified’ category, operating under IFR conditions.

Due to the large variety of RPAS models and performance figures, instead of focussing on aircraft models, EUROCONTROL [3] has introduced a classification for RPAS traffic. Whilst classes I to IV describe traffic within the VLL and class VII traffic within the VHL, classes V and VI consider traffic flying within the VFR (class V) and IFR (class VI) airspaces.

For the INVIRCAT project only aircraft that fit in the class VI traffic category are of relevance, which implies requirements as being able to fly Standard Instrument Departures (SIDs) and Standard Arrival Routes (STARs) and meeting the set performance standards for the Network, TMA and airports. The following table shows the performance figures of a selection of RPAS models that fit into the scope of the INVIRCAT project.

Table 1: Performance characteristics of some IFR RPAS models (Source: Wikipedia)

Parameter General Atomics MQ9A

IAI Heron IAI Eitan (Heron TP)

Thales Watchkeeper WK450

BAE Systems Mantis

Euro MALE

Cruise speed

169 kts - - 70 kts 200 kts 270 kts

Max Speed 260 kts 112 kts 220 kts 95 kts 300 kts -

Range 1900 km - 4700 km 300 km - -

Endurance 14 hours 52 hours 30+ hours 20 hours 30 hours -

MTOW 4763 kg 1150 kg 5400 kg 450 kg 9000 kg 11,000 kg

Ceiling FL500 FL 330 FL460 FL180 - FL450


12

Powerplant 1 × Honeywell TPE331-10 turboprop,

900 hp

1 × Rotax 914 piston

engine, 115 hp

1 × Pratt & Whitney Canada PT6-67A 1,200 hp

- 2 × Rolls-Royce

M250B-17 turboprop,

380 hp each

2 x turboprop (unknown

type)

Airspace classes are defined according to ICAO standards [15], i.e. classes A to G. Not all classes are in use in all countries2. Table 2 shows a description for each of the classes and whether it has any relevance for INVIRCAT. As the focus is only on IFR flights, uncontrolled airspace classes are not considered.

Table 2: Airspace classes and relevance to INVIRCAT

Airspace Class

Description INVIRCAT relevant

A IFR flights only, ATC services provided, separation assured by ATC

B IFR and VFR flights, ATC services provided, separation assured by ATC

C IFR and VFR flights, ATC services provided, separation IFR-IFR and IFR-VFR assured by ATC, traffic information for VFR flights regarding VFR traffic

D IFR and VFR flights, ATC services provided, separation IFR-IFR assured by ATC, traffic information for IFR regarding VFR traffic, traffic information for VFR regarding IFR and VFR traffic

E IFR and VFR flights, ATC services provided, separation IFR-IFR assured by ATC, traffic information for IFR and VFR flights regarding VFR traffic where possible

F IFR and VFR flights, separation IFR-IFR by ATC where possible, traffic information for IFR and VFR flights regarding IFR and VFR traffic where possible

G IFR and VFR flights, self-separation required, traffic information for IFR and VFR flights regarding IFR and VFR traffic where possible

Airports exist in different varieties, spanning from international hub airports with thousands of operations daily (e.g. Hartsfield Jackson Atlanta international Airport with 2,410 daily movements on

2 For example, Germany’s airspace is limited to classes C, D, E and G.


13

average in the year 2017; Amsterdam Schiphol with 1,410 daily movements on average within the same timespan) [18] to small local airfields with grass airstrips without lighting and air traffic control. Smaller airports might only have traffic information service opposed to a controlled airport.

A recent application to save maintenance of facilities and personnel is the introduction of remotely towered airfields. In this concept, an airfield is surveyed by cameras, transmitting the situation to a tower air traffic controller in another location. Screens depict the live image from this airfield, augmented by supporting features, such as labels attached to a moving object (e.g. aircraft moving on the apron, or ground-based vehicles). The workstation allows switching between different airports/towers. This way, controllers can monitor multiple airports with a small number of movements [25].

In a highly automated system, such as RPAS, the presence of issued SIDs and STARs can ease the process of integration significantly compared to airports without such. These SIDs and STARs are typically a list of waypoints (fly-over or fly-by), potentially accompanied by altitude and/or speed restrictions. These boundaries can be integrated into modern flight management systems (FMS), and the resulting trajectory can be used for automatic guidance of the aircraft within the flight envelope.

SIDs and STARS typically come with an FMS/GPS RNAV (area navigation) translation which can be used as input to an FMS. If issued SIDs and STARs are not directly convertible to machine-readable waypoints, the remote pilot has to perform an extra step during the mission planning process.

Sparsely equipped airports/airfields may not have any standard procedures for take-off and landing, but the VFR concept of a traffic circuit with mandatory and optional position reports in downwind, crosswind and upwind legs. As these traffic circuit patterns rely mostly on visual clearance and situational awareness at the airport/airfield, they are not suitable for general RPAS operations. A highly equipped RPAS with suitable sensor technology (i.e. numerous optical cameras) may however enable this concept also for certain unmanned aircraft.

Given the history of manned aviation, with the beginning in times of minimal technological assistance, the equipment on airfields differ significantly due to backwards compatibility with older aircraft and business models of airports. Older visual identifiers, such as visual approach slope indicators (VASI) or precision approach path indicators (PAPI) are available on most airports and still deemed mandatory by ICAO Annex 14 for airports with certain conditions, among them the usage of the runway by turbojet aircraft or aircraft with similar approach guidance requirements [16]. But due to integrational effort of visual image recognition for RPAS systems, visual approach identifiers do not play a role in the pursue of RPAS integration at airports.

As automatic take-off and landing capabilities are deemed necessary for broad application of IFR RPAS traffic, so is the required equipment at the airports: ILS (Instrument Landing System) CAT III. Until today in Europe only the ILS CAT III system allows a landing decision height of 0 feet above the runway and thus is ready to be used for ATOL procedures. While only 1.7 % of all airports and airfields in the navigation database AIRAC 1912 are listed as ILS CAT III capable [5], in Europe most international airports already have ILS CAT III systems in place, e.g. in Germany 15 out of 16 (Wikipedia, 2020). Smaller/regional airports mostly provide only ILS CAT I, or II systems, if they provide ILS at all.

Differential GNSS (global navigation satellite system) technologies, as ground-based augmentation systems (GBAS) or – in the further future – satellite-based augmentation systems (SBAS), can also enable required precision for automated landings of RPAS. However, current GBAS systems impose a decision height of 200 ft and visual landing afterwards, and thus are not sufficient for ATOL procedures.


14

The so-called dual constellation, a combination of two different GNSS providers (e.g., GPS and Galileo), can improve precision for landings compared to single GNSS usage [7]. Currently, GBAS is implemented on more than 100 airports [27], among them several research installations, but also Frankfurt (EDDF), Zurich (LSZH), and Newark (KEWR). In 2019 a European aviation industry alliance has formed aiming to enhance the deployment of new-generation GBAS systems that will allow CAT III approaches [17].

A higher equipage level of airports for precision navigation can be expected without targeting only IFR RPAS, as automatic landing capabilities are as well aimed for in manned aviation. As an example, Garmin Aviation has recently received certification for the first Emergency Autoland System, claiming to use GPS LPV (Localizer Performance with Vertical Guidance), or LNAV/VNAV (Lateral Navigation/Vertical Navigation) systems for the approach and landing phases up to an automated stop on the runway [11]. Even if the system is only intended to be used in emergency situations and comes with various restrictions (Garmin Aviation), it shows the trend in (manned) aviation to further automatize approach and landing using advanced GNSS technologies.

2.2 Operational Challenges

Today, manned aviation under IFR conditions are well-planned operations supported by radar technology/GNSS and managed mainly by voice communication between air traffic controllers (ATCOs) and pilots. Relatively similar aircraft designs result in similar performance figures (e.g. for airspeed, turn radius, and climb or descent rates), which allows standardized departure and arrival procedures and minimizes the air traffic control (ATC) effort to keep the aircrafts separated. Flight plans, that have to be filed prior to departure by the pilot or flight dispatcher contain the basic information of every flight (e.g. departure and arrival airports, routes, and alternate airports for emergency situations) and help the Air Navigation Service Providers (ANSPs) choreograph the air traffic in the different airspace sectors.

Despite nowadays being supported by electronic systems, e.g. the autopilot or the Airborne Collision Avoidance System (ACAS), pilots are able to take over the control of their aircraft at any time and without latencies other than their reaction time. In addition, being located inside the aircraft, pilots are capable of using human senses to identify potential hazards, e.g. sight of conflicting traffic, feeling of approaching stall, or smell of fire to respond appropriately and quickly.

These facts contribute to the extremely high safety standards in the aviation industry that must not suffer from the introduction of new participants as RPAS in the non-segregated airspaces. Therefore, the following specificities have to be considered, when RPAS are being operated in TMA/airport environments:

Aircraft performance figures of RPAS may vary significantly to the performance of commercial air transport aircraft, possibly inducing limitations to airspace capacity in the TMA due to increased separation requirements.

Latency of communication beyond the radio line of sight (via satellites) might impose higher work load for ATC and RPA pilots.

Technical limitations that rule out visual flight impose the use of automated Detect and Avoid (DAA) and ATOL systems, demanding advanced technical equipment at the airports for horizontal and lateral guidance and adapted operational procedures in contingency situations.


15

RPAS sizes, forms and shapes might reduce other aircraft pilots’ ability for visual detection, increasing the dependency on automated DAA systems.

RPAS specific contingency situations (as e.g. connectivity issues with the communication, or command and control (C2) link) require a new set of operational standards to sustain the safety requirements within aviation, whilst minimizing the additional workload of the ATCO.

To increase their situational awareness, ATCOs should be supported through their working position (CWP) with RPAS specific information (e.g. differently shaped position indicators for quick RPAS recognition and RPAS contingency specific squawk codes).

Due to the remote location of RPA pilots, a minimum standard for the communication of flight and aircraft parameters between RPA and pilot might have to be introduced to ensure their situational awareness (e.g. for approaching stall, or fire).

Introducing the concept of harbour pilots, in which dedicated pilots control the RPA only within their TMA, implies the necessity of a safe procedure for the transfer of control between the flight crews during flight.

Any new operation and procedure need to be standardized to the possible extent and clear rules need to be developed. All airspace participants need to be informed to their appropriate level and at the appropriate time through certification, additional training, and adapted documentation (e.g. creation of maps with dedicated airspace for RPAS contingency responses, or additional information in the flight plan).

2.3 ATM / U-Space Transition and Interoperability Aspects

Airspace, which is currently used by civil aviation for their operations, is managed, with different levels of services, by the established ANSPs. ANSPs are following air traffic management rules set by ICAO (Annex 11 — Air Traffic Services, Procedures for Air Navigation Services — Air Traffic Management (PANS-ATM, Doc 4444 and others) and regional/national regulations. Aviation, including ATM, has a long history during which a high level of safety has been developed and is maintained. A notable characteristic of ATM is that it functions with a well-established and proven safety management system, however its procedures and structures may not allow for quick developments and implementations.

By contrast, U-space is quite new, innovative and fast-developing. As described in the SESAR U-space Blueprint [75], U-space is a set of new services and specific procedures designed to support safe, efficient, and secure access to airspace for large numbers of drones3. These services rely on a high level of digitalisation and automation of functions, whether they are on board the drone itself, or are part of the ground-based environment. U-space provides an enabling framework to support routine drone operations, as well as a clear and effective interface to manned aviation, ATM/ANS service providers and authorities. U-space is therefore not to be considered as a defined volume of airspace, which is

3 U-space uses the term ‘drone’ for UAS mainly operating in the relevant airspace. This section adapts to this terminology.


16

segregated and designated for the sole use of drones. U-space can ensure the smooth operation of drones in all operating environments, and in all types of airspace (but not limited to very low-level airspace). It addresses the needs to support all types of missions and may concern all drone users and categories of drones.

The delivery of U-space adopts the following key principles:

To ensure the safety of all airspace users operating in the U-space framework as well as people on the ground.

To provide a scalable, flexible, and adaptable system that can respond to changes in demand, volume, technology, business models and applications, while managing the interface with manned aviation.

To enable high-density operations with multiple automated drones under the supervision of fleet operators.

To guarantee equitable and fair access to airspace for all users.

To always enable competitive and cost-effective service provision, supporting the business models of drone operators.

To minimise deployment and operating costs by leveraging, as much as possible, existing aeronautical services and infrastructure, including GNSS, as well as those from other sectors, such as mobile communication services.

To accelerate deployment by adopting technologies and standards from other sectors where they meet the needs of U-space.

To follow a risk-based and performance-driven approach when setting up appropriate requirements for safety, security (including cyber-security) and resilience (including failure mode management), while minimising environmental impact and respecting the privacy of citizens, including data protection.

The U-space framework comprises an extensive and scalable range of services relying on agreed EU standards and delivered by service providers. These services do not replicate the function of ATC, as known in ATM, but deliver key services to organise the safe and efficient operation of drones and ensure a proper interface with manned aviation, ATC, and relevant authorities. They may include the provision of data, supporting services for drone operators such as flight planning assistance and more structured services such as tracking or capacity management.

The progressive deployment of U-space is linked to the increasing availability of blocks of services and enabling technologies. Over time, U-space services will evolve as the level of automation of the drone increases, and advanced forms of interaction with the environment are enabled (including manned and unmanned aircraft) mainly through digital information and data exchange. U-space is divided in several development steps (SESAR U-space Blueprint [75], latest updated by the CORUS CONOPS [123]):

U1 (U-space foundation services): provide e-registration, e-identification and geo-awareness.


17

U2 (U-space initial services): support the management of drone operations and may include the largest portfolio of new services from mission planning and approval, including extensive environment information services and strategic conflict resolution, over tracking, airspace dynamic information, emergency management, and several monitoring services during flight to procedural interfaces with air traffic control.

U3 (U-space advanced services): support more complex operations in dense areas and may include dynamic capacity management, dynamic geofencing, assistance for tactical conflict resolution, and a collaborative interface with ATC. The availability of automated DAA functionalities, in addition to more reliable means of communication, will lead to a significant increase of operations in all environments.

U4 (U-space full services): particularly services offering integrated interfaces with manned aviation, support the full operational capability of U-space and will rely on very high level of automation, connectivity and digitalisation for both the drone and the U-space system.

U1 basic services are in place, which will facilitate many current operations and allow for new ones. In addition, it is planned to carry out some preliminary demonstrations of the U2 services.

Figure 1 - U-space Services (Source: CORUS CONOPS)

Because of its quite recent and innovative concept development, its level of safety and robustness has not been defined and completely validated yet. Accordingly, a high degree of complexity and effort is expected to integrate these two systems. In fact, the establishment of boundaries between these two systems entails not only operational and technical aspects, but also some important legal elements. As U-space is implemented, the coexistence of manned aircraft and UAS in the same airspace will create a need to identify and confirm the respective roles, responsibilities and functions of U-space and ATM in relation to airspace and traffic management.

Besides these gaps which are complicating the definition of U-space/ATM boundaries, it is clear that a proper U-space development cannot be achieved in isolation from the existing ATM system and its services. In fact, some of the identified U-space services have evident similarities with ATM services; therefore, coordination with ATM is vital. Other U-space services are complementary to ATM as service provision to airspace users is expanded in volumes of airspace where ANSPs currently provide limited or no services (e.g. FIS). Although it is likely that these services will need to interact, there must be a clear-cut definition, allowing no overlap of conflicting or incompatible services or areas of responsibility.


18

Based on the above considerations it is quite clear that interoperability is a key requirement for U-space/ATM interface. As suggested by the current implementation roadmaps [19], a two-step approach is defined for integrating IFR-capable UAS into controlled airspace, initially accommodating this type of users through FUA/AFUA techniques during ASBU Block 1 (until 2025), then fully integrating them with the necessary SARPS from ASBU Block 2 (from 2025).

It should be noticed that much of the current body of UAS regulation has been written as a reaction to market developments and to mitigate emerging risks. Therefore, a proper harmonisation has not yet been achieved, which affects the ATM perspective. In the last few years the volume of UAS operations has expanded and will now co-exist with manned aviation on a larger scale, creating the need for the definition of an ad-hoc Operational Concept that describes operations of UAS in European Airspace which are capable to meet the requirements set for each airspace, including TMAs.

Several discussions at ICAO level have already addressed scenarios, in which manned aircraft and UAS will be required to cross the boundary between U-space and ATM, whereas in other situations they will only operate in close proximity to that boundary. In both scenarios, it appears that an aircraft being managed by one system (U-space or ATM) may be at increased risk of becoming a hazard to aircraft managed by the other system.

To achieve the required level of UAS integration into the controlled airspace, ICAO specified four main requirements for U-space-ATM interoperability:

The integration of UAS shall not imply a significant impact on current users of the airspace;

UAS shall comply with the existing and future regulations and procedures laid out for manned aviation;

UAS integration shall not compromise existing aviation safety levels nor increase risk more than an equivalent increase in manned aviation would;

UAS operations shall be conducted in the same way as those of manned aircraft and shall be seen, to the greatest level possible, as equivalent by ATC and other airspace users.

Based on the above considerations, the integration of UAS within the airspace requires a fully collaborative approach between all actors with the objective of ensuring an efficient interface between U-space and ATM, as well as avoiding airspace fragmentation. An efficient U-space – ATM Interface is required to enable an adequate, robust and timely exchange of U-space information services between various U-space stakeholders such as drone operators, USPs, ATM service providers, data service providers, aeronautical data providers, and authorities. The adopted solutions are expected to have a positive impact on access and equity, enabling seamless ATM/U-space high-density automated and fully digitalised type of operations managed in close cooperation with UAS/UAM fleet operators.

Fully integrated ATM/U-space operations are required to cover seamless operations inside and outside controlled airspace, further defining the interface between ATM and U-space, as well as examining the corresponding information exchange concept and requirements. Information exchange will be critical to enable a safe interface of U-space and ATM.

It should also be noticed, that the current European ATM system is a patchwork of legacy and bespoke systems and networks connected by a number of different interfaces, often utilising national and proprietary standards. In this framework it is quite clear that the target open architecture of the


19

European ATM system, including the provision of the integrated U-space services, shall rely on an increase in interconnected systems based on modern technologies and interoperability to deliver operational improvements through a shared view of the relevant aeronautical information.


20

3 State of the Art

In this section, the current state of activities related to RPAS operations in TMA will be described, with specific reference to operations, technologies, and regulation aspects.

3.1 RPAS Description

While different definitions still apply to the identification of what ICAO stated to be defined as RPAS, Remotely Piloted Aircraft System [20], the high-level architecture of an RPAS is globally agreed in aviation community.

In fact, while UAS and, ever and ever more commonly, drone, is used as an alternative to RPAS, it is fully recognized as made up of three main elements:

the RPA, Remotely Piloted Aircraft,

the RPS, Remote Pilot Station,

the C2 link, Command and Control Link.

The RPA is the flying component of the system, thus characterized by all the subsystems required to perform a controlled flight: airframe, power plant, sensors, flight management/flight controls and communication-navigation-surveillance systems.

The RPS includes the facilities, the equipment and also the flight crew (the remote pilot) necessary to safely control the operations of the RPAS in the Airspace System.

The C2 link, or Command and Control Link, is the internal to the RPAS components interface, that is the bidirectional data-link between RPA and RPS which allows to receive information about the RPA status, and the environment and airspace conditions, while allowing to send commands and exerting the control of the flying element. The C2 link connects the RPS and the RPA for the purpose of managing the flight. It may operate in direct radio line-of-sight (RLOS) or beyond radio line-of-sight (BRLOS).

a) RLOS: refers to the situation in which the transmitter(s) and receiver(s) are within mutual radio link coverage (using direct radio frequency line); and

b) BRLOS: refers to any configuration when the transmitters and receivers are not in RLOS and, in order to communicate, other relays, such as satellite systems and terrestrial network, are used.


21

Figure 2 - RPAS components and C2L alternatives (Source: PJ10-05 OSED)

Few other elements are cited in different reference documents as composing the RPAS (or UAS), such as the launch and recovery elements, the flight termination element, the payload and the support equipment element.

Eventually, other relevant elements that can be accounted as composing the RPAS, and potentially affecting the RPAS integration, are mainly the following:

The RPAS external references, that is the communications between the air vehicle and the ATC centres, and the communications between the remote pilot and the ATC operators. When added to Command and Control (C2) link, these complementary communications are usually identified as C3 (Command, Control and Communications) link;

The RPAS Operator, that is a person, organization or enterprise engaging in or offering to engage in an aircraft operation.

Independently from the peculiarity of its structure, an RPAS is definitively an aircraft, and as such it shall be subject to airworthiness and operational rules to fly in the non-segregated airspace.

Relevant for the considerations and analyses of the INVIRCAT project result is the classification of RPAS. Many different approaches have been used in the last decade to classify RPAS, based on their performances, weight and dimensions, and operational characteristics.

A synthetic description of RPAS classification and characteristics, for the sake of completeness of the concepts here exposed, have been already reported in 2.1. The general concept of RPAS classification is described in the following.

As already stated in section 2.1, the INVIRCAT project applies the classification of EASA/EUROCONTROL [3], which refers to the basic classification of RPAS operations adopted by EASA as a risk-based classification. EASA identified three RPAS risk-based operational classes, as “Open”, “Specific” and “Certified”, as per the following figure and description:


22

‘Open’ category: No authorization is required to operate the unmanned aircraft, as long as forbidden or restricted drone zones, as defined by the national aviation authority (NAA), are respected. Safety is ensured through compliance with operational limitations, mass limitations as a proxy of energy, product safety requirements, and a minimum set of operational rules.

‘Specific’ category: Authorisation is required by a national aviation authority (NAA), following a risk assessment performed by the operator. Some standard scenarios will be published by EASA providing the evaluation of the risk of that specific operation and the list of the required mitigation measures. For certain lower risk scenarios, a simple declaration sent by the operator to the NAA, will be sufficient to start the operation.

‘Certified’ category: Requirements are comparable to those for manned aviation. Oversight by NAA (issue of licences and approval of maintenance, operations, training, ATM/ANS and aerodromes organisations) and by EASA (design and approval of foreign organisations) will be required according to a process similar to manned aviation.

Using the above classification, EASA and EURCONTROL identified seven UAS traffic classes. For the scope of the INVIRCAT project, the Class VI is the class of RPAS that will be considered.

CLASS EASA

MAPPING TRAFFIC

TYPE AIRSPACE OPERATIONS PURPOSE SPECIFICITY

VLL

I Open

Category Buy and Fly

primarily

From ground to

120m/400ft AGL in low

traffic density

areas UAS ONLY

VLOS Recreational

- Mandatory declaration of operation

- UAS must self-separate in 3D - Geofencing ensures that this

category remains separated from no-drone zones

II

Specific Operation/

Certified Category (possible

operations)

Specific/ Certified Category

From ground to

500 FT VLOS/ BVLOS

Survey, filming,

search and rescue and

other

- Has surveillance capability (4G chip or other means)

- Free flight Capability - UAS must self-separate in 3D - BVLOS shall have barometric

measurement equipage

III

Specific Operation/

Certified Category (possible

operations)

Medium/ Long haul

traffic

From ground to

500 FT

BVLOS Free Flight or

Route Structure

Mainly Transport purposes

- Mandatory authorisation for operation

- Has surveillance capability - Shall have barometric

measurement equipage

IV

Specific Category/ Certified Category

Special Operations

From ground to

500 FT VLOS/BVLOS

Highly specialised operations (civil, state or military,

etc.)

- Addressed on case by case basis

- Require special authorization - Could require surveillance

capability, depends on the mission requirements


23

IFR/ VFR

V Certified

Operations

UAS meeting pan-

European network

performance requirements

From 500 FT AGL up to

FL600, including

uncontrolled aerodromes

IFR/ VFR operating

outside the pan-

European network

Not flying SIDs and

STARs

Mainly transport or

military

- UAS operating in the environment will file a flight plan including information

such as type of UAS, planned Contingency procedure and a

contact phone number - UAS will meet CNS airspace

requirements - UAS will be able to establish

two-way communication with ATC if required

- UAS operator must be able to contact ATC (if required) in regard to special conditions

such as data link loss, emergency or controlled

termination of flight - UAS D&A capability will be

compatible with existing ACAS systems

VI Certified

Operations

UAS meeting pan-

European network

performance requirements

From 500 FT AGL up to

FL600, including

aerodromes

IFR/ VFR According to

airspace classes

requirements

Operating in the pan-

European network, including SIDs and

STARs

Any

- UAS operating in the environment will file a flight plan including information

such as type of UAS, planned Contingency procedure and a

contact phone number - UAS will meet CNS airspace

requirements - UAS will be able to establish

two-way communication with ATC

- UAS operator must be able to contact ATC (if required) in regard to special conditions

such as data link loss, emergency or controlled

termination of flight - UAS D&A capability will be

compatible with existing ACAS systems

VHL VII Certified

Operations

Very high level IFR

operations transiting

non-segregated

airspace

Above FL600,

transition through

lower airspace

IFR/ VFR

Stratospheric commercial operations (unmanned aircraft and

balloons)

- UAS must file a flight plan - UAS will meet CNS airspace

requirements - UAS must inform the responsible ATC unit in case of

emergency re-entry into controlled airspace

- UAS must inform ATC about the type of contingency procedures to be used

(balloons deflating or orbiting descent)

- A regional centralised system should have an overview of

the ongoing operations - Departure and arrival

procedures should be developed

Figure 3 - RPAS Classification


24

3.2 RPAS Operations in TMA

The integration of Remotely Piloted Aircraft System (RPAS) in non-segregated airspace is one of the most complex and demanding challenges for the aviation community in the years ahead. In fact, RPAS operation in VHL does not require higher technological developments, but it demands detailed analysis about the safety of their integration with conventional aircraft.

The beginning of RPAS integration in non-segregated airspace is expected to be reached by 2025, according to European RPAS Steering Group [115]. In this sense, one of the most advanced investigations performed to quantify the number of RPAS that can be safely integrated into non-segregated airspace [88] provide restrictions to the number of RPAS that can jointly operate with conventional aircraft. This research quantifies the number of RPAS that can be safely integrated into non-segregated airspace based on two safety metrics: average number of conflict and average conflict duration. The number of RPAS that can be safely integrated is calculated by comparing the Calculated Level of Safety (CLS) of each scenario with a fixed Target Level of Safety (TLS) depending on the current operation of conventional aircraft. According to this research, the most critical safety metric was the average conflict duration, since it implies critical restrictions to the number of RPAS. In addition, the relative influence of the RPAS decreased with a higher number of conventional aircraft. Moreover, the introduction of climbing or descending aircraft could be crucial to correctly quantify TLS with new restrictions for the integration of RPAS.

Due to its peculiar characteristics and architecture, notably the position of the pilot which is responsible of the flight, but located outside the flying component of the system, operations of the RPAS could differ relevantly from commercial aircraft operations.

Generally speaking, with respect to a normal aircraft the RPAS namely characterizes for the kind of flight profiles it could be requested to execute to achieve mission objectives. Differently from the common transport air traffic, RPAS missions can last much more time, also beyond the 18 hours of validity of a flight plan, as foreseen by the present practice. Furthermore, much of this time can be spent by loitering on short distances from the RPS, instead of flying long away from the departure location. In general, mission profiles can be classified in three types [21]:

Point-to-point trajectories

Defined trajectories

Dynamic trajectories

Anyway, for the scope of the present project, other operational aspects related to RPAS architecture and performance are more relevant.

Namely, also it is assumed that all RPAS operating in a controlled TMA shall comply with the relevant applicable requirements in the same manner as manned aircraft. This general assumption could require that an RPAS that operates in the airspace where transport aircraft normally do, similar performance is required. Actually, RPAS could present a very wide range of performance, often largely different from normal air transport aircraft, on parameters as [26]:

Speed;

Latency (related voice/DL communication and C2 link in particular during BRLOS operations);


25

Turn performance;

Climb/descent performance; and

Navigation precision.

Depending on the performance and architectural differences existing, the following operational aspects are peculiar for RPAS operations in TMA [30]

complexity and density of aircraft operations;

ground operations (e.g. taxiway width, condition, other ground traffic);

voice communication latency, including the effect of bank angle;

C2 link continuity and latency, including the effect of bank angle;

wake turbulence;

performance and capability related to take-off distance/run available and minimum obstruction climb requirements, departure procedures and any flight restricting conditions associated with operations to or from the aerodrome; and

availability of emergency recovery areas.

Depending on those issues, RPAS could be found as capable of flying SIDs and STARs, or uncapable to comply with existing standard procedures. In that last situation, additional arrival and departure procedures will have to be developed, placing a possible burden on existing operations. Operations outside the normal flows of arriving and departing traffic should therefore be designed to impose minimal and not provide additional workload.

A further important element of integration into the current ATM system will be how RPAS contingency procedures are defined.

Peculiar to RPAS is, in fact, its behaviour in emergency situations, as contingency in the event of C2 link failure. Often, the loitering on pre-defined points or flying pre-defined flight paths when C2L is lost is the approach used to manage these conditions. Anyway, depending on RPAS level of automation and its capability to fly SID/STAR/ATOL procedures, contingencies in TMA could be defined differently.

There is, eventually, one more peculiar operation that applies to RPAS, the RPS handover operation, that is the act of passing piloting control from one remote pilot station to another.

Handover considerations should include [30] :

Confirmation of the availability of a reliable voice communication link between the transferring and receiving remote pilots in the RPSs to support coordination of the handover (it is recommended that this communication is not relayed through the RPA);

Status of the receiving RPS (e.g. its readiness and availability, its software configuration and compatibility with the RPA to be handed over);

compatibility of the C2 link (e.g. IP address, frequency);


26

coordination between the respective remote pilots; and

ATC coordination (e.g. emergency contact telephone number), as necessary.

In conclusion, a set of high-level requirements for RPAS operations in TMA is listed, as a synthesis, here under:

RPAS operating in this environment will file an ICAO flight plan including:

o Type of RPAS;

o Contingency procedures;

o Planned operations (navigation, route of flight/operational area, flight level, etc.); and

o Contact phone number.

RPAS will meet Communications, Navigation & Surveillance (CNS) airspace requirements;

RPAS will be able to establish two-way communication with ATC;

RPAS will remain clear of manned aircraft or must be capable of self-separating in 3D; and

RPAS operators must be able to contact ATC (if required) concerning special conditions such as:

o data link loss;

o emergency; and

o controlled termination of flight.

In particular, for operations above 500ft outside segregated airspace, where the numbers of VFR and IFR flights are higher, RPAS must meet the IFR/VFR airspace requirements and have a solution for being visible to manned traffic, while having the ability to avoid mid-air collisions. Other aspects such as wake turbulence and separation standards also must be addressed. However, states can accommodate RPAS above 500ft, based on a decision by the competent authority, on a case-by case basis and based on a safety assessment.

3.3 Technology Enablers

Full integration of RPAS into non-segregated airspaces, and even more in such critical area like TMAs, requires the implementation of several RPAS capabilities enabling them to operate safely, even in non-normal situations such as the loss of the datalink.

In the making of this integration some specific technologies are considered “enabler” because of their important role in the process.

The enabling technologies involved in, and affected by, the RPAS integration issue span on a large number of aspects, and a categorization of those technologies could help to assess their state-of-the art. There are also different approaches to such a classification, the one used in this report is based on the categories identified in several scientific reports, such as in [89].


27

The main categories here assumed finally reflect the CNS+A categorization, which on a hand supports the identification of ATM world and, on the other hand, identifies those technologies that can be consistently affected by the ground collocation of pilot, helping to identify those changes between manned and un-manned application of the technologies.

3.3.1 Communication

Communication is one of the most relevant and impacted technology by the RPAS integration in non-segregated General Air Traffic (GAT). As described in 3.1, in fact, the communication link C2 is now part of the basic architecture of a RPAS.

As a consequence, an RPAS might be involved in different type of communication depending on the application they are used for. Regarding the introduction of RPAS in TMA the following types are considered:

Control and non-payload communication (CNPC), also known as command and control (C2) communication

Voice link communication

The C2 is dedicated to secure and reliable communication between the remote pilot ground control station and the aircraft to ensure safe and effective RPAS flight operation.

This link can be either a radio line of sight (RLOS) air-ground link between the two entities or a beyond-radio-line-of-sight (BRLOS) link using another platform such as a satellite or high-altitude platform as relay station. As described in [30], the distinction between RLOS and BRLOS mainly concerns whether any part of the architecture introduces considerable or variable delay to the communications link.

RLOS refers to the situation in which the transmitter(s) and receiver(s) are within mutual radio link coverage and thus able to either communicate directly, or through a ground network, provided that the remote transmitter is within RLOS to the RPA and transmissions are completed in a comparable timeframe.

BRLOS refers to any configuration in which the transmitters and receivers are not in RLOS. BRLOS thus includes all satellite systems and possibly any system where an RPS communicates with one or more ground stations via a terrestrial network, which cannot complete transmissions in a timeframe comparable to that of an RLOS system.

C2 communication can be, moreover, divided in 2 streams, uplink and downlink. The uplink can be used to direct the flight profile or to update a pre-flight-entered flight program. Direct operation of the alternative types of mission ‘payload’ that the UAV carries can also be required. In downlink, the aircraft can return information and images to the operators, either in real-time or on command. The information usually includes data from the payloads, status information on the aircraft’s sub-systems (housekeeping data), altitude and airspeed and terrestrial position information.

Even though C2 Link can be provided by means of different technologies, a set of requirements ought to be met in terms of communication transaction time, continuity, availability and integrity [31]. Frequency allocation and bandwidth of the C2L, on the other hand, are also under investigation and definition by appropriate bodies, and namely by the International Telecommunication Unit.


28

Moreover, as said in [32], C2 performances need to be adequate to not only allow the remote pilot to safely fly the RPA but also support other airspace performance requirements.

Regarding the voice link communication, in [32] is also specified that RPAS need to maintain continuous voice communication watch on the appropriate communication channel and establish two-way communication, as necessary, with the appropriate air traffic control unit and that the methods of communication may be via traditional air-ground very high frequency (VHF) radio or other means, such as satellite or terrestrial relays, data communications, internet-based systems, etc. or by involving third-party service providers. Which ATC communication is used must be transparent to the controllers.

Although at the current stage most of communications between RP and ATCOs are made via voice, a new data link system called controller-pilot datalink communications (CPDLC) [90] has been currently starting to connect pilots and controllers for routine communications using text messages. The objective of this system is twofold: a) voice frequencies decongestion, avoiding stepping on communications or errors; b) to automate those routine messages in the communications so that pilots and ATCOs can concentrate on other tasks. CPDLC represents the base for some services developed in the future controlled airspace (MAS) of SESAR (for example, the 4D trajectory concept is closely related with CPDLC implementation). The RPAS should be compatible with CPDLC (this could be a subsystem on board the RPA or in the RPS) but, due to the early stage of this data link system, it won’t be an assumption in INVIRCAT [91].

For the specific scope of this project, the above classification can be considered as the best suited. Aiming at RPAS integration in TMA, in fact, it is based on the distance between the RPAS and pilot or ground control station, but also on the communications range it can achieve, distinguishing between: Radio Line of Sight (RLOS) and Beyond Radio Line of Sight (BRLOS).

Figure 4 - Flight phases

According to the previous Figure, in the aerodrome area (airport), the Air Traffic Controllers (ATCO) and remote pilots can visualize the RPAS most of the time. In addition, potential communication problems are minimized by being in direct line of sight.

During the climb and approach phases, actors are not in visual contact with the RPAS which position is monitored by progress reports from the RPAS, but communication is still performed with the tower in line of sight.


29

Only once in En-route phase, apart from being out of visual contact with the RPAS, communications are conducted with a remote Area Control Centre (ACC).

Currently, in low endurance missions (RLOS) the contact between ground control station and ATC is established by direct link through ground infrastructure or by using a radio channel frequency shared with ATC. This is not a challenge since it is an external system which does not require any kind of communication with the RPAS.

The following table shows the possible ways of establishing RPAS-ATC communication depending on the distance operation of the RPAS.

Figure 5 - RPAS communication with ATC (Source: RPAS Integration in Non-segregated Airspace: the SESAR Approach)

As mentioned above, the communication link can be done directly from the ground control station to ATC, selecting the proper subchannel to allow communications.

In the other situation, in which full autonomy is important for RPAS, the communication is performed using the RPAS as relay station. The RPAS should be constantly communicating with ATC, the ATC orders should be redirected to the ground control station through RPAS or satellite communications (SATCOM). Since the RPAS are not able to change the ATC channel on their own, autonomous mechanisms and messages to perform the communication should be implemented into the RPAS, adding complexity to the system [91].

There are plenty of documentation on both RLOS and BRLOS satellite C2 system and voice communication.

General Atomics’ (GA-ASI) MQ-9A satellite communication (SATCOM) system allows, also thanks to the advanced ATOL system, to land at an alternate or “divert” airfield at which no Remote Pilot Station (RPS) is present [107].


30

In [33] an overview of the CNPC links as they may be used in 5G and satellite systems by describing basic concepts and challenges is presented. In [34] an analysis is made of ATM voice communication systems based on digital embedded Cloud Technology.

Also, very important within the studies connected to RPAS communication is the evaluation of the effects connected to delay or loss of link. Examples of these studies are presented in [35]. In [98], it is shown a clear need to mitigate or at least reduce controllers of the delay in voice communications with RPAS pilots. In [98], the communication process breaks down into components, which can help to identify potential bottlenecks and mitigation measures to reduce the total delay. More on this can be found in [99]; while standards and requirements are placed for the maximum delay of the different elements and steps of the communication process for manned aircraft, that is not the case of the new scenario of unmanned aircraft, and the impact in the communication flow expectations worsens with the variable nature of the UAS communication delays. To illustrate this, in [99] the authors provide the results of simulations where RPAS pilots received different clearances. This however, is just a basic example of a response time analysis that, to reach better conclusions should contemplate more delay drivers.

Other possible communication threats are presented in [36] where results of both Real-Time Simulations with Humans-In-the-Loop (RTS-HIL) and Flight Trails are presented considering various scenarios including C2 link security threats (spoofing, jamming).

As a synthesis, specifically with reference to the scope of this project, it is possible to identify the following communication issues that have to be considered in the development of a CONOPS for RPAS integration in TMA:

Latency, understood as any delay in the execution of a (remote) pilot command, in turn possibly requested by an air traffic controller, specifically due to the limitation of both, the C2 link and the voice communication link;

Loss of data-link, which implies that the remote pilot loses not only the control of the aircraft but also awareness of its position, attitude and evolution;

Security of the communication and control link, here identified as a specific issue, that is the threat of intentional or unintentional corruption of the command and control signals.

The benefits that a CONOPS could bring in managing such fundamental communication issues could result as highly relevant in integrating RPAS in TMA.

3.3.2 Navigation

First of all, it has to be highlighted that all the international regulatory and engineering bodies [86], even if they analysed potential Visual Operations, until now assume that all UAS-ATOL operations will be conducted under Instrument Flight Rules (IFR) to be flown on published procedures (i.e. SIDS, STARS and approaches). Approaches shall be limited to precision IFR straight in procedures (i.e. ILS, GLS). Visual approaches including “charted visual approach procedures”, arrivals and departures are not considered at the moment.

Furthermore, Navigation aspects here analysed will substantially apply to Satellite navigation systems. As derivable from [117], in fact, GNSS system based on multi-constellation solutions, will fully comply


31

with CAT III requirements starting from 2025, and then in line with the timeframe of the present project and CONOPS.

Starting from these considerations, as per manned aircrafts flying IFR TMA operations, it could be stated that navigation technologies are probably the most critical key enablers to allow precision approach and landing, as well as automatic take-off, systems for RPAS vehicles both in civil and military fields.

In particular, the ICAO Annex 6 [37] identifies the navigation system key parameters that shall be specified in order to support the precision TMA approach operations. They are

Navigation Accuracy (i.e. Navigation Error NE), as the position error of a fault-free navigation system with 95% of confidence,

Integrity, as a measure of the trust that can be placed in the correctness of the information supplied,

Availability (AV), as the ability of the navigation system to provide the required function and performance at the initiation of the intended operation, and

Continuity (CO) as the capability of the total system (comprising all elements necessary to maintain aircraft position within the defined airspace) to perform its function without interruption during the intended operation.

ICAO has also firstly defined the desired quantitative performance requirements in terms of above defined parameters, in order to support all the precision approach category until CAT-I, and recently added also requirements for CAT-II/III [38].

These quantitative NE, Integrity, AV, CO requirements are very stringent to be met by using a single navigation technology. The most popular technological approach proposed in the literature in the first decade of the 2000 consists of integrating measurements derived from different aircraft navigation systems. In particular, configurations that integrate inertial sensor measurements with GPS, altimeters, air data sensors, and magnetometers were proposed, [45][46]. As described in [47], even multisensory navigation systems are capable of reliably realizing the required performance without relying also on ground measurement, such as in this specific case a DGPS (Differential GPS) augmentation system.

The rapid evolution of the GNSS technology of the last decade made the use of navigation systems mainly based on GNSS receivers possible.

As far as the current civil applications are considered, most of the aviation GNSS receivers (>90%, as per 2015 survey of the European GNSS agency [39]) are still single frequency (GPS L1) and use Standard Positioning Service (SPS). The following picture depicts the current situation for civil GNSS assisted approach and landing that can be derived from the most recent ICAO Annex 10 amendment [38] (effective from November 2018).


32

Figure 6 - Current Situation for Civil GNSS Based Approach & Landing

Due to the current low performance of the standalone civil GNSS receivers, they need to be augmented by other systems to comply with precision approach and landing requirements. Specifically, SBAS is required for approach operations up to LPV200 and GBAS is required for operations up to CAT-IIIc. For what concerns SBAS, the RTCA-DO-229D [40] includes the specification of the GNSS unit that shall be of class Beta3 or Gamma3 to support operations up to LPV200. For GBAS, RTCA-DO-246E [41] includes the specification related to the ground equipment and Signal-in-Space (SiS) specification, while RTCA-DO-253D [42] defines the features of the airborne equipment for the global implementation of two services: a GAST-C service for operations up to CAT-I (already operational) and a GAST-D service for operation up to CAT-IIIc (validated but not yet operational). The following figure shows the global coverage of different geostationary augmentation satellites

Figure 7 - World Coverage of Operational or Under Development Civil SBAS

As far as the military application is concerned, current GNSS receivers are based solely on the NAVSTAR GPS constellation. Anyway, differently from the civil GPS receivers that use the SPS (Standard Positioning Service), the military (and NATO) GPS receivers can use PPS (Precise Positioning Service) [43]. In the following the key differences, in place since removal of the Selected Availability in 2000 are summarized:


33

A typical military GPS receiver with PPS capability exhibits increased positioning accuracy (in the order of 2m 1sigma on the pseudoranges) with respect to current civil GPS receivers.

The military receivers use encryption to avoid spoofing and the access to the service to unauthorised users. On the other hand, military GPS receivers might suffer of longer time-to-first-fix than civil GPS.

PPS receivers may access to WAGE (Wide Area GPS Enhancements) rapid ephemeris updates and corrections and therefore, when available, have even better navigation accuracy than standalone usage.

Concerning integrity monitoring, current military GPS uses a standard RAIM (Receiver Autonomous Integrity Monitoring) algorithm similar to civil standalone GPS receivers. Even though its better accuracy and integrity, the levels of performances and availability that can be guaranteed by military GPS, it is still not enough for vertical guidance during precision approach. Therefore, this receiver class can be only used for performing non-precision approach procedures, like civil standalone GPS.

Summarizing, the state-of-the-art aviation GPS receivers need augmentation systems in order to overcome the deficiencies of GPS constellations and receivers, mainly under the aspect of integrity monitoring. Specifically, for civil applications, standalone GPS receivers are used only for precision approach without vertical guidance. A SBAS or GBAS (GAST-C) is needed to comply to precision approach (PA) with vertical guidance down to 200ft decision height (i.e. LPV200 or CAT-I procedures). An improved GBAS (GAST-D) can be used until touch down (CAT-III procedures), providing that required safety levels are demonstrated for the entire aircraft with the installed navigation equipment (i.e. not only considering the navigation equipment performance).

Nevertheless, augmentation systems can only be used in selected world areas (for SBAS) and selected runways (for GBAS) and thus are not available anywhere and anytime in world. Furthermore, an aircraft cannot autonomously perform safety critical phases of flight, because it needs that a stable radio link is established (with geo-stationary satellites for SBAS and with ground stations for GBAS).

In this scenario, the current research trends for the future GNSS try to exploit the availability of multiple GNSS constellations to comply with the integrity monitoring and availability requirements of PA with vertical guidance (at least LPV250 procedures), without using any augmentation system (and thus potentially having world coverage) for both military and civil applications.

It is worth noting that such research activities are not only motivated by GNSS based PA needs. Indeed, GNSS autonomous integrity monitoring has also great importance in the recent applications related to integration in the airspace of Mini/Micro UAS and of Urban Air Mobility vehicles. These systems usually fly in harsh environment at low altitudes (urban and sub-urban) with quite small clearance from fixed obstacles and in low satellite visibility conditions that reduces the possibility of using augmentation systems.

Also, international committees working on new engineering standards for UAS systems, recognized this as priority. For example, RTCA SC 228 has to be mentioned, which in its third phase (2021-2023) [86] foresees a specific Navigation Standards Working Group aimed to enable GNSS-based UAS operations to meet navigation requirements for all phases of flight without the use of legacy ground-based navigation aids, including precision approach capability with auto-take-off and auto-land features, according to Recommendation Five from[116].


34

3.3.3 Surveillance

Surveillance is normally referred as the capability to identify aircraft position in flight and on airports, traditionally by the use of ground equipment for the separation provision and operations assistance (e.g. radar vectoring) of the air traffic controllers.

The Air Traffic Control Radar (ATC-Radar) is a ground solution that refers to all radar devices used to

secure and monitor civil and military air traffic in Air Traffic Management (ATM). ATC-Radars are

usually fixed radar systems that have a high degree of specialization. Common applications of air traffic

control radars include:

En-route radar systems, which monitor the air traffic outside the special airfield areas. En-

route radar systems usually operate in the NATO D-Band. These radars detect and determine

the position, course, and speed of air targets in a relatively large area. En-route radars are

Primary Surveillance Radars (PSR) that are coupled to a Secondary Surveillance Radar (SSR).

Air Surveillance Radar (ASR) systems, which are approach control radars used to detect and

display an aircraft's position in the terminal area. These radars operate usually in E-Band and

are capable of reliably detecting and tracking aircraft at altitudes below 25,000 feet (7,620

meters) and within 40 to 60 nautical miles (75 to 110 km) of their airport. The antennas of ASR

rotate faster than en-route radar systems, at 12 to 15 revolutions per minute to ensure the

required data renewal rate of up to 5 seconds. Modern ASR have an additional weather

channel and can clear up dangerous situations for aviation weather conditions.

Precision Approach Radar (PAR) systems, which are used to provide operational support to

aircraft landing in bad weather conditions. The guidance information is obtained by the radar

operator and passed to the aircraft by either voice radio or a computer link to the aircraft.

These radars usually operate in I-Band.

Surface Movement Radars (SMR), which scan the airport surface to locate the positions of

aircraft and ground vehicles and display them for air traffic controllers in bad weather. SMR

operate in I- to K-Band and use an extremely short pulse-width to provide an acceptable range-

resolution. The range is limited to a few kilometres and the antenna rotation speed can reach

up 60 revolutions per minute.

Special weather radars. These radars are very important for air traffic management. There are

weather-radars specially designed for air traffic safety.

Ground radars are normally complemented by airborne transponders, operating under multiple

modes, namely Mode A/C/S, which differ from each other by the amount of data they provide to the

ATC centres.

UAS are claimed to be equipped with at least a Transponder Mode S for surveillance. But, as discussed

in the previous subsection, as a consequence of the introduction of satellite positioning system as

primary mean for aircraft navigation purposes and a shift towards integrated information

management and broadcasting, the next surveillance systems will be mainly based on a dependent (in

contrast with the ground-based radar system, identified as independent) surveillance system. That


35

system is dependent on an on-board measurement aircraft position system (i.e., GPS), which

broadcasts its state vector (position and velocity information) to surrounding traffic and to the ground.

As navigation avionics will primarily be based on GNSS systems, the surveillance system of the RPASs

integrated into the ATM system are expected to use the ADS-B surveillance technique. Different

equipment will be used for ADS-B In functionality, that is the capability to receive and process

information by other ADS-B (or Mode S) equipped aircrafts, and ADS-B Out functionality, that is the

capability to send information to ground stations and other surrounding aircrafts.

Peculiar to the RPA is the need to downlink to RPS all the information received on the ADS-B In

equipment. Also, FIS-B (Flight Information System Broadcast) and TIS-B (Traffic Information System-

Broadcast) information, components of ADS-B system which are specifically made available to enhance

pilot’s situational awareness when ADS-B data are not available or strictly required, will be relayed to

the UAS Remote Pilot Station to display information on the HMI.

Both, UAT (Universal Access Transceiver, for use in USA) and 1090 ES (Extended Squitter) transponder

(selected for use in Europe) are under analysis to use in the ADS-B Out function for manned aircraft,

both using 1090 MHz frequency and usable in Class A airspace. Constraints on power, weight and space

can divert preferences from one to the other technology.

The surveillance system information is normally used to allow air traffic controllers to manage

separation of aircraft in the controlled airspace. Because of the peculiar architecture of RPAS, with the

pilot located outside the flying component of the system, RPAS integration necessarily claims a DAA

system which shall equip remotely piloted aircraft. The system is minded to both, maintain separation

and as a short-term safety net (ACAS system), and consequently, also if it covers surveillance related

components, will be presented under the RPAS avionic systems.

3.3.4 Avionics

Avionics are normally and generally identified as the electronic and equipment of an aircraft. The cockpit of an aircraft is a typical location for avionic equipment, including control, monitoring, communication, navigation, weather, and anti-collision systems.

For RPAS systems, avionics definition can differ both because part of the equipment could be located on-ground, in the RPS, and then separated from the flying component of the system, and also because the pilot remote positioning requires totally new equipment, notably for providing the remote pilot the See And Avoid capability that manned aviation pilots normally exert.

In the present section the state-of-the-art of avionics equipment of an RPAS, that is those equipments that are peculiar of RPAS and those that embeds specific characteristics because their application to remotely piloted systems, is reported.

The following systems are identified as complying with the characteristics above described: the Automatic Take-Off and Landing system, the Detect And Avoid system, the pilot interfaces and visual systems. Two further aspects are investigated in the section: the autopilot and the automation technologies.

https://en.wikipedia.org/wiki/Electronics


36

3.3.4.1 Automatic Take-Off and Landing

Landing and take-off are traditionally the most critical phases of flight. There exist different systems which can assist these manoeuvres according to runway equipment. RPAS are likely to provide a fully Automatic Take-off and Landing (ATOL) system, to minimize the need for manual flight and enhance the safety level during such critical phases. ATOL requires tight navigation and flight control system performance, functional and integrity monitoring with possible contingency manoeuvres/actions that must be designed depending on the current conditions and health status.

The ATOL capability is intended to provide RPAS with the ability to perform the operations from “CLEARED FOR TAKE-OFF” to completion of the initial climb (ICL) and from the beginning of the final approach phase (APR) to RPA stop on runway safely and efficiently.

The final aim, in the development of this technology, is to perform these operations in both non-segregated airspaces and at closed aerodromes including operations such as holding, missed approach and rejected take-off procedures in the scenario.

For EUROCAE-ED283 [100] the ATOL concept can be considered as made up of four major concept elements: RPA technical functions, RPS technical functions, rules and procedures for the two environments where the ATOL capability delivers its service by involving remote crew, ATC controllers and airfield personnel. Of these elements only the first two contain enabling technologies.

The RPA ATOL functions are airborne functions, automatically executing several tasks that are typically performed by on-board pilots in manned aviation. The RPS ATOL functions include also ground functions supporting the remote crew to track the RPA and to monitor, control and override the ATOL airborne functions. The development of an ATOL system is a highly challenging task with a complexity depending on the required performance, reliability, availability and safety.

To be able to perform automatic take-off and landing, accurate measurements and a robust trajectory must be defined and the airspeed of the vehicle must be controlled. 4D paths with different waypoints are generated to describe the trajectory suitable to onboard sensors and on-ground hardware, typically based on GNSS (Global Navigation Satellite System). Specifically, GNSS based systems have also technical standards (RTCA DO-253) of navigation units that can cover up to CAT-III automatic landing (till touch down) and for manned aircraft that can easily be adapted for the unmanned case. Unfortunately, these systems currently require that dedicated and expensive ground stations are available in the runway area and, therefore, they are not so commonly available especially in minor airports. However, future Dual Frequency Multi Constellation GNSS systems might have quite less stringent requirements on the on-ground equipment that would increase the number of supported runways.

Other possible alternatives are currently investigated, such as altitude control with vision-based tracking. In this case, an infrared (IR) camera can be used to recognize IR LEDs on the runway to determine the position and orientation of the aircraft. Moreover, laser ground tracking systems are also available that locate the aircraft with high accuracy and then send relative positioning data to the on-board system through a dedicated data link.

Regarding moving surfaces (such as ships), image-based landing techniques were proposed to track the platform in two-dimensional image space. Additional sensors attached to the moving target are needed as inertial measurement units, GNSS receivers or infrared markers. The landing trajectory must be autonomously adapted by the onboard processor in real time. The vehicle searches the pre-defined features on the landing platform to determine the position and to decide when to reduce throttle to start the landing sequence. IR computer vision techniques were also used to precisely land on a ship,


37

through an IR transmitter on the ship, which was tracked by the RPA to locate the landing platform [93]. Visual solutions are preferred since GNSS satellites can be easily interfered.

Learning-based control methods have also been studied to achieve an optimal control policy under the presence of different disturbances or uncertainties, as wind.

As far as the current development and application status of ATOL systems is concerned, in [101] a low complexity controller framework for automatic landing and take-off for general aviation aircraft without the use of any ground-based facilities is presented. Another low complexity example is shown in [102]. The work focused on adapting a control system, developed for an optionally piloted aircraft MP-02 Czajka, for piloting the aircraft in take-off and landing phases.

As it is clear from above discussion, ATOL systems can be characterized by means of the different navigation equipment (laser, GNSS, visual), the communication systems (satellite based or radio), and the type of trajectory generation and tracking algorithm.

At CIRA, since 2007 within the National Research Technology program PRORA, it was developed a DGPS/AHRS ATOL system with a radio based communication system. In [103], [104], [105] are collected a series of image-aided navigation techniques for aircraft approach and landing and in June 2020 Airbus achieved autonomous taxiing, take-off and landing of a commercial aircraft through fully automatic vision-based flight tests using on-board image recognition technology within the ATTOL project frame, as announced in [106].

In the same period, General Atomics (GA-ASI) demonstrated three expanded Automatic Take-off and Landing Capability enhancements that provide their MQ-9A with a dramatic increase in operational flexibility. As described in [107], this system is able to:

enable the MQ-9A to land at an alternate or “divert” airfield in which no Remote Pilot Station (RPS) is present, and under satellite communication (SATCOM) control,

overfly and self-survey the divert airfield’s runway using the Reaper’s multispectral electro-optical/infrared (EO/IR) sensor to obtain co-ordinates for an automatic landing

expand the cross-wind limits of the MQ-9A.

increase the maximum landing weight for normal and emergency landings.

As said, ATOL systems can also differentiate by means of the algorithm they use. The ATOL system developed by CIRA in 2007 uses a fixed path adaptive algorithm, as shown in [108]. More recently, in [109], a 4-Dimensional Trajectory optimisation algorithm is shown and updated in [110]. This algorithm is designed to avoid a variety of GNSS signal (typically, continuity and integrity performance) degradation predicted by an Avionics Based Integrity Augmentation system, with a new efficient guidance algorithm.

3.3.4.2 Detect and Avoid (DAA)

One of the systems used in RPAS to allow keeping the required separation distance of the RPAS to the rest of the traffic, IFR or VFR [30], is the DAA system.

The Detect And Avoid (DAA) terminology is the final result, as of today stated by the ICAO [20], of a number of different identifications used by different sources, but finally addressing the same concept and functionalities for the system.

The DAA system shall provide three main elements:


38

situational awareness to the remote pilot, at a suitable level for the operations to be handled;

separation provision (in terms of assistance to a RPAS flying in a managed airspace, or in terms of self-separation in an unmanaged airspace);

collision avoidance, when separation provision failed.

Principal reference for the following more detailed analysis is the description of the system and its functionalities as mainly described in the EUROCAE documents [119][120].

Both under conditions in which ATC grants the separation provision (i.e., flying in the managed airspaces), and under non-ATC unmanaged airspaces, the DAA system will progress in three stages according to EUROCAE, as already explained before in the report:

the collision alert stage, that is a warning signal is provided to the pilot, in the RPS. It shall acquire traffic, environment and weather conditions awareness and take actions to avoid the hazard;

the collision resolution stage, when the first stage failed to start pilot actions, during which the DAA system will provide also collision resolution manoeuvre or actions;

the automatic collision avoidance, when all previous stages failed in actuating some solving conflict manoeuvre. The system will override all other activities and start guiding the vehicle along a collision avoidance trajectory. The collision avoidance conditions are continuously monitored, and when resolution has been reached, the flight can recommence in its ordinary way.

A further stage, actually the first in the order of relevance, the separation provision stage, is foreseen in the DAA operating when ATC does not provide separation assurance function, but it is delegated to the pilot (or aircraft).

In order to exercise all those capabilities, the DAA system shall incorporate the following low-level functions, as described in [122]:

Sense proximity of other airspace users;

Sense terrain and obstacles;

Sense severe/adverse weather;

Assess encounter geometries for the purpose of prioritizing messages to UAS flight crew;

Build trajectories in accordance with maintaining separation and avoid collisions;

Depending on the automation level and the flight crew answer, initiate changes to RPA trajectory;

Monitor the evolution of the encounter geometries for the purpose of ensuring effectiveness of trajectory changes, and return to normal flight conditions.

A number of hardware and software components will then be part of a DAA system, such as visual and radar sensors, weather sensors and electronic terrain databases, but also advanced flight computers and pre-programmed procedures to compute suitable avoidance manoeuvre have to be integrated into the DAA system.

ATC information on surrounding traffic and weather conditions will be provided to DAA also from ATC service, mostly through ADS-B technology.


39

The system will obviously encompass on-board and on-ground components; the system components separated allocation could apply not only to the HMI components, but also to the sensing and computing components.

RPAS behaviour operations will have to be equivalent with manned aviation particularly in their interaction with air traffic control (ATC) to be handled efficiently. They would probably have similar equipment and performances to manned aviation, in order to have an expectable behaviour for the rest of the users in managed airspace (MAS). Nevertheless, in unmanaged airspace (UMAS) there is more flexibility and freedom in the operations and equipment, consequently, the autonomy of the RPA and the DAA onboard system would be of main relevance, to keep the minimum separation under any circumstance, without relying solely on the RP’s supervision.

Even if the INVIRCAT reference scenario concerns the insertion of RPAS within controlled TMA areas, where adequate spacing between vehicles depends on procedures and is upon the responsibility of ATCO, DAA systems still are a key technological enabler to guarantee the required level of safety. Indeed, the DAA technology is indicated as one of the key enablers for the full integration of RPAS into the airspace [70] by the Federal Aviation Administration (FAA) [76], the European Commission [77], the Single European Sky ATM Research-Joint Undertaking (SESAR-JU) [78], and the European Aviation Safety Agency (EASA). To this end, several bodies, such as JARUS WG4 [79], EUROCAE WG105 and RTCA SC-228 [82], are working to define the required DAA safety and performance objectives and to standardize related enabling technologies.

Besides the relevant achievements of these initiatives, the DAA technology has not yet reached the required level of maturity neither to allow unrestricted operations in non-segregated airspace [80]. In this regard it seems optimistically feasible in the short term to have a DAA system supporting RPAS in performing at least en-route IFR operations in controlled airspace (Class A to C). Such DAA systems should be still interoperable with TCASII (Traffic Alert and Collision Avoidance System II) and could rely on ADS-B coupled with TCAS-I/IFF (Identification Friend or Foe) equipment for cooperative/active traffic, and on Air-to-Air Radar only for non-cooperative intruders. This perspective seems mainly true for MALE classes of RPAS (or above), while for lower classes, the objective of RPAS integration could be envisaged for a longer term. This is mainly because available non-cooperative sensor technologies that can be integrated into such UAS classes have a too high SWaP (Size, Weight, and Power), are too expensive and/or do not meet required availability and reliability performance targets. As far as DAA performance requirements for operations in TMA are concerned, the recently published Terms of Reference (ToR) of RTA SC228 [86], foresees explicitly in its second phase 2020-2021 take-off and landing operations in Class C, D, E, and G airspace. The first step towards this general objective is the publication in March 2020 of the DO-365A [83] document including specific chapter dealing with the DAA specifications in TMA. In addition, SC228 expects that future work on this topic will lead to the development of Minimum Operational Performance Specifications (MOPS) for a ground-based non-cooperative radar, as an additional key technological enabler for DAA in TMA. Furthermore, there is currently a lack of project and standardization activities for the development of a DAA system for ground or near-to-ground operations, in view of an autonomous capability of an RPAS to manoeuvre on airports. Therefore, also due to the lack of specific performance and safety requirements, at least until few months ago, there were still few studies in the literature that address the typical problems of a DAA system in TMA operations, and namely on airports. Among these some works recently presented in


40

the latest AIAA DASC (Digital Avionics Systems Conference) 2020 have to be mentioned, addressing specific DAA issues during TMA operations, such as the DAA Terminal Area (DTA) size and switching technique for the DAA Well Clear (DWC) volume while transitioning between en-route and the terminal area [84], the derivation of the early alert threshold for RPAS terminal operations [85], and the simultaneous avoidance of conflicting traffic and fixed obstacles or forbidden areas [81].

3.3.4.3 RPAS Interfaces

The ground control stations are taking more and more relevance, becoming complete information systems where operators must be able to properly interpret what is happening at any time and make decisions quickly.

To safely perform these operations and integrate RPAS into the air traffic management (ATM) environment used for manned aviation, the development of some technologies is demanded.

3.3.4.3.1 RPS-RP Human-Machine Interface (HMI)

The HMI design is primary intended to transfer information to the RP. It has the mission to filter the non-relevant information, according to the needs of the RP in each phase of the flight.

The HMI between the RPS and the RP incorporates colour screens, drop-down menus and on-screen commands. The objective of the interface is to provide the RP with all the necessary information to have full control of the RPA at any time during the flight and under any circumstances, allowing the RP to recognize ATC instructions smoothly and quickly [91].

There are simulators, such as MUST (Multi UAV Simulated Testbed) developed by NLR [28], which provide an operational environment and reconfigurable simulation facility. This simulator can easily be adjusted to research demands and is used for research on all kind of human factors related to UAS. MUST aims to improve human (-machine) performance, to reduce human error so that RPAS flights become safer and more efficient. The ground control station consists of a fixed view outside camera display and a moving map display with an integrated pilot control input HMI.

MUST provides RPAS pilots with two control modes, namely Autopilot (AP) and Flight Management System (FMS) modes. In AP mode, RPAS heading, altitude and speed values can be adjusted and activated independently using sliders on the MUST HMI. Furthermore, AP mode allows pilots to initiate circular loiter patterns at the current position with desired speed and altitude settings. In FMS mode, the RPAS autonomously flies waypoints along predefined routes. In this case, each waypoint is defined as a latitude, longitude, speed, and altitude combination. Furthermore, pilots can select any waypoint in a route (in front of or behind the RPAS) as the next active waypoint and fly direct to it. In addition to the above control modes, MUST simulates the basic functionality of an Automatic Take-Off and Landing System (ATOL) whereby take-off and landing can be initiated by the RPAS pilot at the press of a button on the MUST HMI. This functionality automatically configures all RPAS systems (including engine(s) and flaps) to the right settings to autonomously perform take-off and landing.

At present, the MUST simulator does not have a realistic ground-taxi mode. Therefore, it does not involve any scenarios with RPAS taxiing on the ground.

3.3.4.3.2 Visual Interfaces Enhancement

The last technology considered within the enabler in the integration of RPAS in TMA is visual enhancement technology.


41

Two technologies could be particularly interesting, namely synthetic and enhanced vision.

In [19] is written that “synthetic vision capabilities will further improve flight crew awareness of own ship position, and reduce navigation errors during periods of reduced visibility, and allow for more confidence by the flight crew in the conduct of the taxi operation during periods of reduced visibility.” and moreover that “area navigation capability on the aircraft and detailed databases of aerodromes will allow for a computer-synthesized depiction of the forward visual view to be displayed in the cockpit. Integration with enhanced vision system will add integrity to this depiction. This capability reduces the impact that low visibility conditions have on the safety and efficiency of the surface operation. The depiction can be displayed on the instrument panel or on a Head-up display.”.

Regarding enhanced vision the document adds also “Additional avionics add electromagnetic sensors outside the visible light spectrum (e.g., infrared cameras, millimetre wave radar). These sensors will allow for improved navigation by visual reference, even during conditions of low-light or weather obscuration such as fog. Presentation to the flight crew may be through an instrument panel display (liquid crystal display or cathode ray tube) or via heads-up display (HUD), etc.”

This said, it is clear that visual enhancement technologies could provide both RPAS and ATC operators a crucial support in visibility critical situations and could also ease the supervision in automatic flight phases like ATOLs.

In literature there are a lot of examples of research on those objects.

In [111] new concepts applied to Synthetic Vision System (SVS) are proposed and assessed in order to increase RPA operator situation awareness taking advantage of new data sources.

In [112] a research that has focused on determining the value of combining synthetic vision data with live camera video presented on a UAV control station display is presented. This research includes information constructed from databases (e.g., terrain, cultural features, pre-mission plan, etc.), as well as numerous information updates via networked communication (e.g., weather, intel). Moreover, in this paper, pertinent human factors are assessed.

In [113] the contribution of synthetic vision is divided into two categories. The depiction of the environment and all relevant constraints contributes to the pilot's situation awareness, while the depiction of the planned path and its constraints allows the pilot to control or monitor the aircraft with high precision.

In [114] potential opportunities to UAV mission management provided by synthetic vision technology and automation are discussed.

3.3.4.4 Autonomous Operation

RPAS cannot be expected to be autonomous vehicle [20], and they can be considered as a subset of UAS. As stated in [21], the term UAS is encompassing of all aircraft flown without a pilot on board that operate as part of a larger system. This includes RPAS, autonomous aircraft and model aircraft. Autonomous aircraft differ from RPAS in that they do not permit intervention of a human pilot to fulfil their intended flight.

In the present section, aspects of autonomous flight that have to be taken into consideration for long term use and integration of autonomous operations are summarized, also if out of the scope for INVIRCAT project.


42

The concept “autonomous operation” describes a UAS that can operate without any human intervention. In other words, it can take off, carry out missions, and land completely autonomously. Therefore, in the case of autonomous UAS, communications management software coordinates missions and pilots the aircraft instead of a human.

In addition, setting regulatory requirements for remotely piloted operations has proved to be less difficult than developing requirements for operating autonomous UAS, according to the European Union Aviation Safety Agency (EASA) [118].

When talking about autonomous flight, the risk assessment of operations should ensure, as for any other operations, that the risk is mitigated to an acceptable level. Besides, it is expected that autonomous operations or operations with a high level of autonomy will be subject to authorisation and will not be covered by standard scenarios until enough experience is gained.

There are some fundamental aspects that are common to all UAS, independently from their level of automation. These aspects include the abilities of sensing and perceiving the environment, analysing the sensed information, communicating, planning and decision making, as well as acting using control algorithms and actuators. In this sense, UAS will need to improve their sensing of obstacles and subsequent avoidance. This becomes particularly important as highly automated UAS start to operate in a civil air space that is used by other aircraft.

Operating unmanned flying vehicles is useful, but it can be challenging when a RPAS interacts with the environment. This interaction could be, for instance, in the form of landing on ground or landing pads, docking to a station, approaching terrain for inspection, or approaching another aircraft for refuelling purposes. Such tasks can often be solved when it is remotely piloted, especially when the pilot has a First-Person View (FPV) of the environment. However, human control may not always be possible, for instance due to the unavailability of a suitable data link, or because of the precision and/or speed that is required for the manoeuvre, which may be outside human capabilities. Thus, it is important to find effective and flexible strategies to enable vehicles to perform such tasks autonomously. In fact, autonomous operation is something that is being worked on and that is gradually being implemented in small parts of the flight process.

Well-developed features of autonomous UAS control include, for instance, stability enhancement, waypoint flight and optimal target-oriented flight. However, new developments in the design of UAS and the emergence of new application areas demand robust and adaptive control techniques for different flight conditions, aggressive manoeuvring flight, robust disturbance rejection, obstacle avoidance, fault tolerance, formation flying (e.g. swarming drones), and the use of new sensing and perception paradigms, such as computer vision. Even when the vehicle performs tasks autonomously, the efficiency and reliability of the communication link to the ground station or other aerial vehicles is important, as the autonomous RPAS may need to send information about itself or its environment to the ground station or other vehicles, or it may need to receive updated mission parameters from the ground station, or information from other vehicles.

The focus has been set on UAS operations in the context of ATM proposed by SESAR for future operations. The SESAR ATM Target Concept is likely to be affordable and economically viable to all stakeholders only under some conditions. For this purpose, a primary mode of operation has been proposed, in which the pilot or ground control station is overseeing the operation continuously and a backup mode that allows the RPA to be in autonomous flight (in case of data link loss or other contingencies/emergencies).


43

To achieve all the ambitious requirements that an autonomous operation brings about, systematic and innovative methods for planning, navigation, decision making, control, sensing and communications are needed.

3.3.4.5 Autopilot Technologies

Autopilots allow RPAS to perform entire missions automatically without the need for manual remote control. Operators use ground control stations to set the parameters of the mission and the RPA autopilot directs the drone to complete the mission. Autopilots are generally robust units designed to guide RPAS to perform a set of operations autonomously with minimal user input.

Autopilots work by combining an array of sensors including gyros, magnetometers, and accelerometers with a GPS. In addition, they implement flight control by acquiring and processing data related to the attitude, velocity, position and heading of the RPA in order to direct the flight and operation of the vehicle according to the parameters set by the user. Other sensors may also allow the autopilot to avoid obstruction and collisions while the RPA is operating. Fully autonomous UAS can carry out entire flight plans including VTOL or runway take-offs, inflight manoeuvres, and landing. Options to pilot the RPAS manually or with an assisted manual function are also available on some autopilots in addition to the fully automated setting. Most RPAS autopilots have single or multiple redundancy systems to keep the vehicle in flight and operational in the event of a failure. Autopilots are available for all kind of RPAS, such as fixed or rotatory wings RPAS. Some manufacturers use a common set of hardware and software to operate all these vehicles by using custom flight phases and control channels. Others may use the same hardware with different software.

Applications for RPAS autopilot are largely varied, therefore, the control systems used to operate them are often highly customizable. These autopilots are usually based on custom computers or computers running Windows, Linux, or Android Operating systems. Control stations for RPAS aim to be as user-friendly as possible, allowing users to easily set flight plans and edit them mid-flight, adding in waypoints or making changes where needed. Many control units feature built-in mission simulators, as well as safety pilot modes that allow operators to take manual control of the UAVs in an emergency. Other ground control station features may include video receiving, mapping functions, payload control, and simultaneous vehicle control.

There are also autopilots whereby RPAS can navigate not only autonomously but optimally according to certain optimality criteria, such as minimum time, minimum energy consumption. In [92], CACM-RL© (Control Adjoining Cell Mapping and Reinforcement Learning) is an example of this technology, that allows controlling any dynamic system (RPAS included). CACM-RL© technology integrates system dynamic techniques and intelligent learning schemes. Relying on this technology, algorithms are designed to optimize RPAS operations. With CACM-RL© technology, not only trajectories are generated between the origin and destination, but that the time, energy or distance can be optimized. This technology has been tested in both open and closed spaces without GPS signal. Most of the tests focused on the ability to carry out surveillance missions with the CACM-RL© technology, simulating troop deployment areas, caves, abandoned facilities. The other two phases of the tests consisted of object avoidance exercises with which the 'Sense and avoid' capability was tested in which the RPA had to circumvent obstacles placed in its path.


44

3.4 Human Factors, Roles & Responsibilities

3.4.1 Pilot Related Human Factors

Remotely Piloted Aircraft have generally experienced a higher accident rate than conventionally piloted aircraft [49]. Many of these accidents appear to reflect the unique human challenges associated with piloting an RPAS, and design issues with the human/system interface [50]. Piloting air vehicles is evolving from using manual controls and cockpit instruments to using ground station instruments to fly the aircraft remotely. This aspect affects obviously the pilot mental workload, owing to the absence of the physical cues of the cockpit (e.g. vibration, sound cues and other sensory information). The focus of human factors evaluation moves from a physical signal in the cockpit, to what the pilot mentally perceives on the ground. Maintaining situational awareness is crucial, although pilot workload for an RPAS is mostly mental.

RPAS share many of the same human factors applicable to conventionally-piloted aircraft, however the points of difference have implications for RPAS design:

Loss of natural sensing;

C2 link;

Remote Pilot Station Design;

Handovers;

Unique flight characteristics of remotely piloted aircraft;

Flight termination;

Reliance on automation; and

Widespread use of interfaces based on consumer products.

3.4.1.1 Loss of Natural Sensing

When operating a RPAS, it could be more difficult for the pilot to maintain the awareness of aircraft’s state because of the loss of visual, auditory proprioceptive and olfactory perceptions. Observations of airline pilots have indicated that pilot error is relatively frequent event. But, most of errors are quickly identified and corrected [51]. In the case of RPAS pilots, they may have more difficulty to identify and correct errors because the pilot is not co-located with the RPAS. In fact, the remote pilot won’t be able to follow ATC clearances by direct visual reference in absence of an out-the-window view and must trust on alternative sources of information. However, the awareness sounds provided by an out-the-window view during the taxiing and take-off phases and approach and landing phases, may be critical for the RPAS. Perceptual distortion could occur if an onboard camera is used to assist the pilot. Camera views can produce misleading depth signal related to the loss of binocular cues (if the camera is not aligned as expected by the pilot or moves unexpectedly, there may be an illusion of yaw, or other undesired aircraft state).


45

3.4.1.2 Control and Communication (C2) Link

Figure 8 shows the C2 link connecting the RPAS with the Remote Pilot Station (RPS). The link can involve terrestrial radio or satellite links, or a combination of the two

Figure 8 - Control and Communication (C2) link

In the following lines the main link issues are described:

Control Latencies: Latencies will be particularly observable if the link is via geostationary satellite, however, also terrestrial radio systems can introduce latencies. Such latencies can determine a reduction in situational awareness which could cause, in turn, a delay between of pilot control input, and aircraft response execution, and due to the late pilot’s perception and processing the response to the pilot can be introduced by the transmission of radio signals, and the processing the delayed signals. Latencies will be particularly observable if the link is via geostationary satellite, Latencies will be particularly observable if the link is via geostationary satellite.

Voice latencies: The communication and control architecture developed for RPAS operations might involve a digital relay of remote pilot voice communications from the ground to the RPAS. The relay of communications from the RPS via the RPA will introduce a delay since the message will be converted to analogue form, and rebroadcast over VHF radio, while the transmissions of other pilots and controllers will be sent to the remote pilot using the same system. Also, in case a satellite link is involved, this delay will be most observable. Most of this latency will be owing to processing before and after signal transmission. However, it is required to ensure a continuous voice communication link with ATCOs, either via traditional VHF radio, either via satellite or broadband cellular network systems, and any other possible data communication means. The voice latencies may differ according to the architecture used: e.g. if the voice communications are transmitted via landline nearly no latency is to be expected.


46

Link management: the pilot has to manage the RPAS as well as manage and monitor the C2 link. Hence, the pilot has to be aware of the current control link status, anticipate potential changes in the link quality due to the flight progresses, and manage any sudden changes. If required, the pilot could interact with security features preventing unauthorized persons from taking the RPAS control and interfere with the control link. If a link interruption occurs, the RPAS must be able to continue flight according to the expectations of the pilot and the ATC.

Figure 9 - Phases of a lost link event (Source: Human Factors Guidelines for Remotely Piloted Aircraft System Remote Pilot Stations, 2016)

As shown in Figure 9, three phases are foreseen for a lost link event [48]: In phase 1, the link has been interrupted, and the RPAS continues to fly in accordance with the last command received from the pilot. Some link interruption will be few milliseconds, whereas others interruption link may extend for minutes or hours. Hence, a chronometer is needed to measure the duration of the interruption and activate the lost link procedure after a certain interval has spent. The time to start the lost link procedure may be different related to the area flown, for example: in the terminal area, the lost link procedure may need to start after an interruption of few seconds. Elsewhere, the RPAS may be able to safely continue along its planned flightpath, during the cruise phase, for an extended period before entering its lost link procedure. In phase 2 the lost link procedure is activated: as said before, different lost link procedures will be appropriate according to the location of the aircraft and the stage of flight. The remote pilot must remain aware of the current lost link procedure. In Stage 3, the link is re-established and the aircraft back to pilot control.

3.4.1.3 Remote Pilot Station Design

Because of the absence of abovementioned natural and sensory cues, the Remote Pilot Station (RPS), may seem like a control room rather than a cockpit. However, this aspect leads to the possibility to add displays and the possibility for the maintenance personnel to access the RPS during the flight. In fact, the RPS is more spacious than a traditional cockpit allowing the possibility to easily install additional screens. Anyway, addition of displays to the RPS should be considered a significant or minor modification for RPS design and certification.

Furthermore, RPAS maintenance personnel can access to the RPS during flight operations to fix in-flight troubleshooting (such as diagnosing and correcting console lock-ups, software problems, and problems with cable connections), having hands-on interactions with the RPS while a flight is underway. As a result, maintenance errors may have an immediate operational impact [56].


47

3.4.1.4 Handovers

Control of RPAS may be transferred during flight operations between pilots at the same RPS console, between consoles at the same RPS, or between physically separated RPS [53]. These handovers can be a risk, associated with system errors and coordination breakdowns. For example, cases of unintentional transfer of control between RPS due to controls set in error have occurred. The control of a long-endurance aircraft may be transferred multiple times during the course of a single flight [54], with each handover contributing to a cumulative level of risk.

Three types of handover are distinguished: between operators in the same RPS, like in a crew changeover due to end of shift; between RPSs, or vehicle handoff, which would be the case if there were aircrew specialized in the take-off/landing phase; and among members of the aircrew, when the task responsibility is transferred to another crew member. In the case of vehicle handover, another reason behind could be to reduce the control latency, transferring the control to an RPS closer to the aircraft. This is especially interesting during the take-off and landing, so is not only a matter of having specialized pilots (even though the convenience of such specialized pilots has been checked for proved efficiency reasons, for instance, teams with expertise in handling non-nominal situations).

3.4.1.5 Flight Characteristics of RPA

Compared to conventionally-piloted aircraft RPAS can have unconventional flight characteristics. They can fly at lower speeds, climb and descend more slowly, and fly in all the airspace rather than fly point-to-point. The human factors implications of these characteristics may involve a reduced ability to rapidly perform ATC instructions, and need for a moving map display to provide correct manoeuvres for changes of path. RPAS operations can also start and end with launch and recovery systems rather than conventional runways, changing the pilot’s task. A challenge for the designer of the RPS is to maintain the pilot’s focus during extended periods of low workload, particularly when the pilot’s role is to perform supervisory control of automation [55]. Furthermore, the pilot must be prepared for sudden increases in workload during emergencies or non-normal situations.

3.4.1.6 Flight Termination

During the emergency, the RPAS pilot, can be required to perform an off-airport landing, or terminate the flight by a controlled impact, ditching, parachute descent, or other method. Although no lives are onboard the aircraft, the pilot is still responsible for the safety of other airspace users and the protection of life and property on the ground. The RPS must provide the information needed for pilot decision-making and allow the pilot the necessary commands to the RPAS. The risk of inadvertent activation of the flight termination system must also be considered [56].

3.4.1.7 Reliance on Automation

Many conventionally-piloted aircraft have sophisticated automated systems onboard. However, the pilot of a conventional aircraft will generally have the possibility to turn-off or minimize the use of the automated systems and perform manual control of the aircraft, even in case of a fly-by-wire systems. Most current designs of advanced RPAS rely entirely on automated systems for basic flight control, and do not provide options for pilot manual control. Hence, the remote pilot is responsible for the supervisory control of the automation. Therefore, managing the automation becomes the critical issue for the RPAS pilot. The RPAS degree of automation have to be identified and examined in order to ensure that both the workstation and the operator tasks are designed to accommodate the level of control and type of control that the operator has over the RPAS. However, the introduction of automation can increase the mental workload, could determine a reduction of situational awareness


48

and skill degradation. In fact, introduction of automation could increase the mental workload, due to supervisory control of the automation and no chance to turn-off or minimize the use of these systems. Indeed, the RPAS degree of automation needs to be identified and examined in order to not increase the mental workload, loss of SA and skill degradation. List refers to the possible new types of failure introduced by automation [48]. Increased levels of automation have been observed to have induced new types of failures:

Failure to monitor;

Vigilance capacity decrement;

Late detection of problems.

3.4.1.8 Widespread Use of Interfaces based on Consumer Products

RPS designs can range from simple hand-held devices to complex, networked, multi-console configurations. Despite it can be assumed that IFR RPAS will include certified RPS, it can be observed that RPS interface could be derived from or could be influenced by consumer computer software [48]. Furthermore, observed issues, have included a heavy reliance on textual information, complicated sequences of menu selection required to perform time-critical or frequent tasks and screen displays that can be obscured behind pop-up windows or dialog boxes. Since the control and displays information can be sourced from diverse commercial providers, there is a high risk of inconsistency and other integration issues between data. This may result in increased crew training requirements, reduced efficiency, and an increased potential for operator errors.

3.4.2 ATCOs related Human Factors

Today, a large number of RPAS are requesting access to controlled airspace. The RPAS flight mode is very different compared to conventionally-piloted aircraft. In fact, the RPAs fly in all the airspace rather than flying point-to-point. It is fundamental to examine and individuate the impact on controllers related to the RPAS introduction into controlled airspace. These aspects are exacerbated by the fact that the RPAS use latitude/longitude waypoints to define their route, which increases the ATCO’s workload and can induce the delays of response for any instruction/clearance.

As described above, it is fundamental to define the key aspects affecting the RPAS impacts on the ATCO. Six major key aspects are identified:

Workload management;

RPAS flight planning and automation;

RPAS control link;

RPAS specific information and procedures;

ATC training;

RPAS interaction with the future airspace.


49

3.4.2.1 Workload Management

From the introduction of RPAS, potential changes to the workload on ATCO should be sufficiently considered and, at the same time, should not result in any unnecessary increase in workload. If an RPAS infringes into controlled airspace, an ATCO may need to close the entire airspace sector. This could increase the workload of ATCOs and pilots. Too many transponders may lead to frequency bandwidth issues and for ATCOs to the display of too many targets on surveillance displays (i.e. clutter). This could determine to the loss of surveillance for some portions of airspace, which may impact an ATCO’s workload negatively.

3.4.2.2 RPAS Flight Planning and Automation

Current RPAS operation can last days, weeks or months and the high level of automation enable an easily change of crew within the RPS. While, ATC automation is not designed to manage this operation of this duration. Furthermore, an ATCO intervention could be required in order to extend a flight plan or close and reopen a new flight plan, which causes additional workload. The RPAS use latitude/longitude waypoints to define their route rather than traditional airways, fixes and routes called by names. The controllers are not familiar with this format. Although, the purpose of traditional aircraft is to fly and reach their destination as quickly as possible, the RPAS often, has long duration missions and very different from the conventionally-piloted aircraft. This means that RPAS may not fly standard routes, they could fly using unusual pattern within sector or across sector boundaries and the purpose of RPAS pilot is to perform the mission without diversions or shortcut. These unusual operations enable the separation a big challenge for controllers.

3.4.2.3 RPAS Control Link

Figure 10 shows one of the possible communication methods used by BRLOS. The C2 link connecting the RPAS with the RPS and with ATCO. The link can involve terrestrial radio or satellite links, or a combination of the two.


50

Figure 10 - C2 Link ATCO control

Especially in the case, when the RPAS is located beyond visual line of sight and the communication with RPAS is performed through satellites, due to the relaying of the instructions, there is a potential issue with C2 link. Furthermore, from a controller’s perspective, two concerns will be considered: C2 link delay or latency, and a complete loss of link.

C2 link delay/latency can interrupt the controller’s workflow, since the RPAS response are slower than conventionally-piloted aircraft, which is a significant concern in busy sector. In addition, delay/latency communication can lead to blocked transmission, because if a new air vehicle joins into the frequency and does not hear anyone talking, begins checking in, but then steps on a communication that was initiated by a pilot a couple seconds prior. One of the most important tasks performed by controllers is frequency management, and this situation can increase the controller workload. The C2 link latencies can also introduce more difficulties to evaluate the manoeuvres to provide for the separation between the air vehicle.

When a lost link event occurs, the pilot cannot control the RPAS and the aircraft will follow a pre-scheduled procedure and then will take it to a termination flight in the safest possible way. For this reason, no clearances will be provided by the controller to the RPAS and all the other air vehicle must manoeuvre out of its way. The pre-scheduled procedure for a safe landing, is not always available and this becomes challenging for the controller and the rest of traffic.

3.4.2.4 RPAS Specific Information and Procedures

RPAS type and missions are very different from conventionally-piloted aircraft and the controllers need to receive all the information in order to help the RPAS to complete the missions, maintain the level of safety within the airspace and maintain the ATCO workload at an acceptable level. For example, the controller needs specific information such as telephone number, lost link procedure and mission-specific information. This specific information and procedures could be provided by automation,


51

manual reference, or other methods and should be easily accessible for the controller. In addition, the conventionally-piloted aircraft use standardized procedures to perform their flight, while future procedures may be developed or modified for the RPAS. Furthermore, wake turbulence categorization and associated separation minima may need to be revised for RPAS integration.

3.4.2.5 ATC Training

Today, ATC training provides general RPAS information and handling characteristics for facility operational personnel and consist in an eLearning and Management System (eLMS) training course available to all controllers. The training for controllers needs to be updated to include more details about RPAS handling (such as lost link event, lost communications, wake turbulence) compared to traditional aircraft.

3.4.2.6 Human Performance Aspects of RPAS Interaction with the Future Airspace

With the RPAS introduction, also the airspace should change in future. Because two major changes are to be considered: communications and wake turbulence. In fact, the voice infrastructure may have to be enhanced in order to accommodate the RPAS pilot, located into the RPS, to allow efficient communications, owing to the potential delays and loss of line. The big challenge for this development is to make the communication transparent to the controller. Describing the RPAS mission by voice could be very challenging, due to the high amount of information to provide to the ATC. For this reason, Controller Pilot Data Link Communications (CPDLC) could help to reduce controller workload related to the RPAS clearances.

Finally, different wake turbulence categorization may need to be established to support safer operations, since the RPAS are lighter and smaller than conventionally-piloted aircraft. Today, the wake turbulence is only a consideration in terminal airspace, but with the RPAS introduction some changes could be required on ATCO activities (e.g. new procedures, training and wake handling).

3.4.3 Remote Pilot Role and Responsibilities

Figure 11 presents a high-level model of the remote pilot responsibilities adapted from [58]. The model could be considered as a “checklist” to ensure that all areas of human-system interaction are taken into account. Many areas of responsibility are common to both, conventionally-piloted aircraft and RPAS. These include monitoring and controlling the status of radio links, control hand-offs, and flight termination.


52

Figure 11 - Responsibilities of the remote pilot (Source: Mutuel, Wargo & DiFelici, 2015)

Manage: The “Manage” category includes the overall planning, decision-making, and management responsibilities that must be accomplished by the pilot, supported by the HMI.

Aviate: These responsibilities include tactical or short-term control of the aircraft/RPAS, and the control link. In many cases, the continuous control functions needed for the maintenance of the flight, are located to onboard RPAS automation. However, the pilot is still responsible to provide supervision and control of the configuration systems. Manoeuvres to avoid collisions with other aircraft/RPAS are involved as an aspect of “Aviate.”

Navigate: The navigation responsibilities involve its ground-based equipment and strategic or longer-term control of the aircraft/RPAS. Controlling and monitoring the position and flight path of the aircraft/RPAS includes ensuring that the aircraft/RPAS flies with respect to airspace boundaries, ground separation and other considerations. The responsibility must be accomplished in the loss of an out-the-window view, necessitating reliance on a traffic situation display in the RPS. The two final responsibilities, listed under “Navigate”, are specific to RPAS. Furthermore, the pilot must maintain an awareness of the aircraft’s preprogramed lost link manoeuvre, ensuring that the manoeuvre is updated as necessary as the flight progresses. Finally, in the event of a serious in-flight anomaly, the pilot may be required to terminate the flight, possibly by directing the aircraft to a suitable location for a controlled impact or ditching, or by deploying a parachute system. In either case, the pilot must minimize risk to people and property on the ground.

Communicate: The pilot in command has to communicate with ATC, other airspace users, other members of the flight crew or support team, and ancillary services such as weather briefers. Communication and coordination (C2) within the RPAS operating team is critical and the HMI has to be designed to enable situation awareness to be achieved. The relay of pilot-ATC voice communications via the RPAS has the potential to introduce communication latencies that may be sufficient to disrupt verbal communication.


53

3.4.3.1 Aviate

The goal of “Aviate” activities is to ensure that the basic functions of the aircraft operate effectively. These responsibilities include tactical, or short-term, control of the air vehicle, the control link, and the RPS.

Monitor and Control Aircraft Systems

The control functions necessary for the control of the flight are built to onboard automation; however, the pilot is still responsible to provide supervisory control to the systems configuration. The information to perform these functions will be provided by the downlink element of the control link.

Monitor Consumable Resources

During the course of a flight, consumable resources of the RPAS can be expected to reduce. The RPS must enable the pilot to monitor the status of these resources. These resources depend on the base of the design of the RPAS, they may include fuel, oil, and battery power. The task of monitoring consumable resources may involve aspects unique to RPAS, including unconventional propulsion systems and long duration flights. Additionally, the pilot must be prepared for the possibility that a lost link procedure could introduce additional loss status on consumable resources, and the pilot may be unable to intervene while the aircraft is performing the lost link procedure.

Monitor and Configure Control Station

Management of the RPS will require the pilot or other crewmembers to monitor and configure the status of the RPS to identify and respond to abnormal conditions. This may include managing the performance of computer systems and power supplies. Unique considerations may include the need to manage uninterruptable power supplies and air conditioning required for computer systems. If a second RPS is planned to be used during the flight or is available on standby, the pilot may also need to maintain an awareness of the state of readiness of that RPS.

Manoeuvre to Avoid Collisions with Other Aircraft or Terrain

This responsibility refers to tactical manoeuvres to avoid collisions with other aircraft or obstacles on the ground. It can be seen as the final phase of Detect and Avoid (DAA) system and will only be necessary when the RPAS has failed to remain separated of other traffic or the obstacles on the ground.

Monitor and Control Status of Links

The C2 link is an integral part of the RPAS. The link can utilize a combination of technologies, including terrestrial radio, satellite radio (geostationary or low Earth orbit), and ground-based communication infrastructure. The pilot of a RPAS must maintain an awareness of the C2 link status and manage the link. Link management will be particularly critical during control handovers, lost link and link resumption, when operating towards the limits of the signal and during frequency changes.

Transfer Control

The ability to transfer control between or within RPS is one of the key differences between RPAS operations and conventionally-piloted aircraft. Special attention is required for the Handovers in order to ensure that the crews of the “receiving” and “sending” RPSs possess a shared understanding of the operational situation and that control settings are aligned between the RPSs.


54

3.4.3.2 Navigate

The navigate responsibility involves longer-term control of the RPAS. The RPAS flying task is the same as for a conventionally-piloted aircraft.

Control and Monitor Location and Flight Path of Aircraft

Controlling and monitoring the aircraft position and flight path includes the assurance that the aircraft follows its flight plan, taking into account airspace boundaries, ground separation, and other considerations. This responsibility includes ground taxiing and complying with all requirements to navigate on airport taxiways and runways.

Remain Clear of Terrain, Airspace Boundaries, and Weather

This responsibility covers the activities involved in remaining clear of undesired locations that can be identified during flight planning or during the flight. These locations may be undesired due to terrain, airspace boundaries, weather, or other operational restrictions.

Remain Well-Clear of Other Aircraft

This responsibility includes the strategic separation assurance function of DAA, in which the RPAS remains well separated of other traffic.

Review and Refresh Lost Link Mission as Necessary

The pilot must maintain an awareness of the aircraft’s status and current lost link manoeuvre, ensuring that the manoeuvre is updated as necessary related to the flight progresses. If the lost link procedure becomes “stale” the aircraft can execute an unsafe manoeuvre, such as flying towards terrain in an attempt to reach a waypoint programmed earlier in the flight.

Terminate flight

During an emergency, the remote pilot may be required to terminate the flight by a controlled impact, ditching, parachute deployment, or other method. Human factors considerations will include the information pilots will require to make this difficult decision and execute the action, as well as measures to protect against the inadvertent activation of the flight termination system.

3.4.3.3 Communicate

The pilot in command must communicate with ATC, other airspace users, other members of the flight crew or support team, and ancillary services such as weather briefers.

Communicate with ATC and other airspace users

In the conventionally-piloted aircraft the communication with ATC is generally performed via VHF, or in some cases, by the controller pilot data link (CPDL). Communications may be relayed using ground infrastructure or satellites, if the RPAS is operating far from the ground transmitter. The signal transmission and elaboration can introduce potential time delays to communications. In addition to communicating with ATC, the pilot may be required to communicate with other airspace users. The loss of standardised communication rules/phraseology for certain category operations increases the risk of misunderstanding between the remote pilot and ATCO or pilot-to-pilot. This may have consequences on pilot workload, result in delays in communication response, and even the misinterpretation of clearances.


55

Communicate with Other RPAS Flight Crew and Ground-Support Personnel

Flight crew and Ground-support personnel such as external observers, and other support personnel may be located far from the RPS. Communication and coordination within these teams requires special attention, and the RPS HMI must be designed to enable situation awareness for the entire team. Some RPAS operators use cameras to enable the pilot to monitor the aircraft status during the flight and the ground. Communication and coordination must be required between the pilots, when RPAS control is transferred in flight. This may involve voice or text communications.

Communicate with Ancillary Services

Ancillary services include weather briefers and other support personnel that provide external support to the RPAS operation.

3.4.4 Air Traffic Controller Role and Responsibilities

As said before, conventionally-piloted aircraft share many aspects. One of these aspects involve the ATC responsibilities. Remote pilots will need to communicate with ATC in order receive the instruction/clearances via voice or CPDL communications. A flight plan has to be submitted for the RPAS flight. The flight plan must comply with the all information about the flight. Each State in which the flight is operating can require additional information related to the RPAS planned operation. The flight plan will be reviewed, accepted, and modified by Air Navigation Service Providers (ANSPs) or other responsible bodies, based on the timing, requested route, and any other considerations associated with the aircraft, equipage, cargo, route, or contingency procedures in that moment. For RPAS, ATM automation may be enhanced to enable approval or modification of route requests and recognition of user requests for off-nominal airspace volumes. Each accepted flight plan should be sent to the pilot for consensus or negotiation.

3.4.4.1 Delegated Separation

In airspace where ATC provides separation services between participating aircraft, the RPAS may have the capability to separate themselves from some aircraft thanks to the automated system present onboard.

3.4.4.2 RPAS Operations in Uncontrolled Airspace

Owing to the different shapes, sizes and types of RPAS, there is a high risk that smaller RPAS may not be detected by systems onboard of the piloted aircraft. In fact, only class VI RPASs (see Figure 3) can have ‘detect and avoid’ systems installed onboard, due to current weight restrictions of unmanned aircraft. Hence, small RPAS are undetectable by pilots of conventional aircraft, which further exacerbates the risk of airborne collisions between manned and unmanned aircraft within uncontrolled airspace.

3.4.4.3 RPAS Operations in Controlled Airspace

Many human factors relating to the infringement of RPAS into controlled airspace are to be taken into account. For the RPAS pilot, this includes stress and high pressure in order to recover the RPAS from infringement. Additionally, a loss of knowledge of the controlled airspace environment can introduce a high risk of collision with conventional manned aircraft. Infringement could lead the ATCO to close the entire airspace sector, increasing the ATCO and pilot's workload.


56

3.5 Applicable Regulations

RPAS integration in the non-segregated airspace has involved, at the least in the last decade, all the civil aviation organizations, bodies, and agencies.

As an aircraft, as ICAO and the Chicago convention definitively states, to RPAS apply all the technical standards that apply to any aircraft.

Nevertheless, the pilot-in-command positioning outside the airborne component of the aircraft system introduces peculiarities that necessarily require specific regulations and changes to the current ones.

Many specific working groups have been defined inside regulatory and standard bodies, producing and issuing a long list of documents, as Operational Concepts, Guidance Materials, and so on.

The (long) list will be redundant for the State-of-the-Art of the present project. In the current section the regulation documents that express rules or provide indications on those aspects of RPAS applicable to the concept of operations and technologies will be identified.

Technical Standards, as issued expressly by standardization organizations and associations, as specifically applicable to the INVIRCAT project will be described in the following Section 3.6, in this section will be identified a set of rules and guidance material as issued by regulation agencies and organizations.

To better identify relevance, nature, and applicability of the reported documents, the section is structured, by referring the regulatory organizations and agencies.

3.5.1 ICAO, International Civil Aviation Organization

ICAO started in 2008 to coordinate and propose references to all other stakeholders acting in view of UAS integration in the civil airspace. A first steering Group (UASSG) was established in 2008 and a Panel (RPASP) has been constituted in 2015, with the aim to develop a regulatory concept, coordinating the development of SARPs, procedures and guidelines, and assisting other bodies to the development of technical specifications addressed to the UAS integration in the non-segregated airspace and at aerodromes. ICAO has published its first document, the ICAO Circular 328-UA, in March 2011. ICAO adopted last March, 15th the Standards for Annex 2-Rules of the Air, and Annex 7-Aircraft Nationality and Registration Marks, that will become applicable from next November 2020, specifically referring to RPAS applicable standards. In 2015 ICAO published the Manual on Remotely Piloted Aircraft Systems Doc 10019 AN/507. On October last year, the ICAO Concept of Operation for RPAS was drafted. The RPASP is complemented by the UAS Advisory Group (UAS-AG), relevant to UTM only, which aims to support the Secretariat in developing guidance material and develop provisions for States in issuing regulations on UAS.

ICAO Regulatory references

ICAO Circular 328

Standards for Annex 2 – Rules of the Air

Standards for Annex 7 – Aircraft Nationality and Registration Marks.


57

Standards for Annex 13 – Accident and Incident Investigation

Standard for Annex 1 – Pilot Licensing (applicable from 2022)

Standard for Annex 8 – Airworthiness of Aircraft (expected for 2019, applicable from 2024).

Manual on Remotely Piloted Aircraft Systems Doc 10019 AN/507

RPAS Concept of Operations (CONOPS) for International IFR Operations, Oct. 2017.

3.5.2 EASA, European Aviation Safety Agency

Regulation (EC) No 216/2008 mandates the Agency to regulate Unmanned Aircraft Systems (UAS) and in particular Remotely Piloted Aircraft Systems (RPAS), when used for civil applications and with an operating mass of 150 Kg or more.

Experimental or amateur built RPAS, military and non-military governmental RPAS flights, civil RPAS below 150 Kg as well as model aircraft are regulated by individual Member States of the European Union. Toys, even if capable of flying but not equipped with internal combustion engine, are subject to Directive 2009/48/EC.

The Agency is supporting the European Commission to progress a regulatory framework for unmanned aircraft. In December 2015, the Agency published a technical opinion which contains, in its section 4, an update of the roadmap published by the European RPAS Steering Group (ESRG) in 2013.

In October 2019, EASA published Guidance Material (GM), Acceptable Means of Compliance (AMC) and the first pre-defined risk assessments. They include:

a revised version of the draft AMC and GM that were published with Opinion 01/2018

the description of the risk assessment methodology called SORA (Specific Operation Risk Assessment) that is required in the “specific category”

the first pre-defined risk assessment to assist operators when applying for an authorization in the specific category for an operation:

o Over Sparsely Populated Areas

o In Uncontrolled Airspace

o At Very Low Levels

o BVLOS with Visual Air Risk Mitigation

o Using UA up to 3m characteristic dimension

Additional pre-defined risk assessments will be published in the next years to cover most common operations that will take place in the EU.

All the above material has been finally integrated into the Regulation (EU) 2019/947 and Regulation (EU) 2019/945, issued as Easy Access Rules, followed in 2020 by further Implementation Regulations and Delegated Regulations. The current EASA Rules actually apply to “open” and “specific” categories


58

of drones. Rules applicable to “certified” category are still to be issued. Nevertheless, the current EASA rules for drones are listed in the following section on EASA Regulatory references for the project.

To conclude, in the identification of a minimum regulatory basis for the project a few more EASA Rules, such as SERA, the applicable EASA Rules of the Air, AUR, laying down airspace usage requirements and operating procedures concerning performance-based navigation, and finally ADR laying down requirements and administrative procedures related to aerodromes are considered as relevant.

EASA Regulatory references

Commission Delegated Regulation (EU) 2019/945

Commission Implementing Regulation (EU) 2019/947




Commission Implementing Regulation (EU) No 923/2012 of 26/09/2012 – SERA



Commission Regulation (EU) No 139/2014

Commission Regulation (EU) 2018/401


3.5.3 EUROCONTROL

EUROCONTROL is one of the main contributors to the European Remotely Piloted Aircraft Systems (RPAS) roadmap. This roadmap presents a harmonized approach to the safe integration of RPAS technology into non-segregated airspace.

The basic principles are:

• RPAS should be as safe as manned aviation;

• RPAS operations should not exclude other airspace users;

• RPAS should be transparent to ATC and to other airspace users;

• most importantly, RPAS must adapt to ATM and to existing regulations.

In order to achieve the goals set out in the roadmap, three annexes were included to address these aspects:

• The Regulatory Approach;


59

• A Strategic Research Plan;

• A Study on the Societal Impact.

EUROCONTROL is intensely involved in the ICAO RPAS Panel (RPASP). It has been tasked with undertaking specific studies and developing provisions to facilitate the safe, secure and efficient integration of RPAS into non-segregated airspace and aerodromes, while ensuring that the safety levels for manned aviation are maintained or even improved.

EUROCONTROL is leading two working groups:

• ATM;

• C2 data link.

More recently, EUROCONTROL is fully engaged in the definition of a whole eco-system for the full exploitation of the drone operations: The U-Space system. The U-Space system aims to develop a traffic management system for UAS, and define how it will all work technically and institutionally. The overall ATM system will need to handle low-level urban drone operations, high-flying military remotely piloted aircraft systems and the traditional mix of airlines, military, business and private jets. EUROCONTROL's role is to ensure the safe integration of UAS while safeguarding the rights of all airspace users.

EUROCONTROL is leading projects, namely CORUS for the definition of the Concept of Operations for the European UTM system and PODIUM, aiming to proving operations of low-level drones with initial UAS traffic management services deployed.

EUROCONTROL is also a member of the Joint Authorities for Rulemaking on Unmanned Systems (JARUS).

EUROCONTROL Regulatory references

UAS ATM Integration Operational Concept, Ed. 1, Nov.2018

UAS ATM Flight Rules-Discussion Document, Ed 1.1, Nov. 2018

UAS ATM Airspace Assessment-Discussion Document, Ed. 1.2, Nov.2018

3.5.4 JARUS, Joint Authorities for Rulemaking on UAS

JARUS is a group of experts from the National Aviation Authorities (NAAs) and regional aviation safety organizations. Its purpose is to recommend a single set of technical, safety and operational requirements for the certification and safe integration of Unmanned Aircraft Systems (UAS) into airspace and at aerodromes. The objective of JARUS is to provide guidance material aiming to facilitate each authority to write their own requirements and to avoid duplicate efforts. At present 50 countries, as well as the European Aviation Safety Agency (EASA) and EUROCONTROL, are contributing to the development of JARUS. Since 2015, the Stakeholder Consultation Body (SCB), representing all industry communities of interest, has also been establish to provide support to all JARUS activities. JARUS recently structured in a number of Working Groups; WG6 recently published the SORA Package, that is a risk assessment package to support operations of UAS under “specific” category.


60

JARUS developed a series of documents till Nov. 2019.

JARUS Regulatory References

RPAS C2 link Required Communication Performance (C2 link RCP) concept, 2014

Licensing and competencies for personnel involved in the operation of RPAS (JARUS-FCL), FCL Recommendations, 2015,

Safety for airworthiness of RPAS (1309) and airworthiness processes, and related AMC RPAS 1309 (package), 2015

Certification specifications for light Unmanned Rotorcraft Systems, CS-LUAS, 2016

Required C2 Performance (RLP) concept, 2016

Specific Operations Risk Assessment (SORA) Guidelines and Package, 2017

3.6 Technical Standards

This section is intended to complement the previous section on Regulation, by providing Technical Standards applicable to the systems that are expected to be developed and tested in the operational concept, originally developed in the context of the INVIRCAT project itself.

For Rules on RPAS, also standardization bodies put huge effort into the development of specific standards for RPAS technologies, and this effort is still on-going. Committees have been instituted inside the principal standard bodies, and relevant documentation, in terms of high-level requirements and guidelines have been issued by those Committees.

In the present section the applicable relevant documents as prepared by two worldwide recognized standards for aviation associations, namely EUROCAE and RTCA, are identified.

3.6.1 EUROCAE, European Organisation for Civil Aviation Equipment

EUROCAE is the European leader in the development of worldwide recognised industry standards for aviation. By making specific reference to EUROCAE activities on RPAS, EUROCAE constituted several working groups and focusing different aspects of RPAS integration. Along the years, EUROCAE WG-73, WG-95 approached respectively RPAS and Small UAS guidelines for regulations and certification of UAS. Eventually, all activities concerning UAS have been collected in several study groups under the Working Group 105.

WG-105 is tasked to develop standards and guidance documents that will allow the safe operation of UAS in all types of airspace, at all times, and for all types of operations.

The work of WG-105 is organised in six Focus Teams working in a specific area. The current Focus Areas are:

• UAS Traffic Management (UAS)

• Command, Control, Communication (C3)


61

• Detect and Avoid (DAA)

• Design and Airworthiness Standards

• Specific Operations Risk Assessment (SORA)

• Enhanced RPAS Automation (ERA)

The work of the Focus Teams is coordinated by a Steering Committee ensuring consistency across their developments.

WG-105 works in coordination with RTCA SC-228 for Unmanned Aircraft Systems.

Specific to this paragraph results the EUROCAE document EUROCAE-ED-252, OSED for RPAS take-off and landing (ATOL).

The OSED document provides the basis of the operational, safety, performance and interoperability requirements for an Automatic Take-Off and Landing System for RPAS. The document aims to collect the high-level requirements from existing regulations, standards and methods related to ATOL system, both for civil and military applications, and then to derive the identification of the ATOL capability for RPAS to be integrated under IFR rules.

At the date of issue of the present document, the EUROCAE ED-283 MASPS for RPAS ATOL system, which supersedes the OSED, results under revision and approval.

Finally, EUROCAE also constituted the EUSCG (European UAS Standards Coordination Group), a joint coordination and advisory group established to coordinate the UAS-related standardisation activities across Europe, essentially stemming from the EU regulations and EASA rulemaking initiatives. The EUSCG provides a link to bridge the European activities to those at international level.

The EUSCG work ensures a better coordination and monitoring of the relevant activities affecting standardisation:

rulemaking activities under EASA responsibility,

update to the ATM Master Plan by including UAS provisions,

standardisation activities executed by the relevant standardisation bodies, including EUROCAE WG-105 work programme.

The main deliverable of the EUSCG is the European UAS Standardisation Rolling Development Plan (RDP) which will be progressively updated to reflect the current situation.

In order to fully list relevant document for the project, specific rules for airport operations are also to be taken into account for RPAS integrations in TMA and at airport, such as the Airport -CDM applicable rules.

EUROCAE Reference Standards and Documents

EUROCAE ER-004 A Concept for UAS Airworthiness Certification and Operational Approval, Nov.2010,


62

ED-271 Minimum Aviation System Performance Standard for Detect and Avoid (Traffic) in Class A-C airspaces under IFR – In Approval

ED-258 OSED for Detect & Avoid [Traffic] in Class D-G airspaces under VFR/IFR - Status: Published

ER-016 RPAS 5030-5091 MHz CNPC LOS and BLOS compatibility study - Status: Published

ED-266 Guidance on Spectrum Access Use and Management for UAS - Status: Published

ED-279 Generic Functional Hazard Assessment (FHA) for UAS and RPAS - Status: Published

ER-019 Inputs to RPAS AMC 1309 - Status: Published

ED-272 Minimum Aviation Systems Performance Standard for Remote Pilot Stations supporting IFR operations into non-segregated airspace - Status: Published

ED-252 Operational Services and Environment Definition for RPAS Automatic Take-off and Landing - Status: Published

ED-283 Minimum Aviation Systems Performance Standard for RPAS Automatic Take-off and Landing - Status: Approval

ED-251 Operational Services and Environment Definition for RPAS Automatic Taxiing - Status: Published

ED-284 Minimum Aviation Systems Performance Standard for RPAS Automatic Taxiing - Status: Approval

ED-253 OSED for Automation and Emergency Recovery - Status: Approval

ED-281 Minimum Aviation Systems Performance Standard for RPAS Automation and Emergency Recovery - Status: Published

ED-145A Airport CDM Interface Specification - Status: Draft

ED-146A Guidelines for Test and Validation Related to Airport CDM Interoperability - Status: Draft

ED-xyz Airport CDM SWIM Service Performance Specification - Status: Draft

ED-141A MASPS for Airport CDM Systems - Status: Draft

3.6.2 RTCA, Radio Technical Commission for Aeronautics

RTCA is the USA-based leading body for the development of standards in aviation. Many standards are normally coordinated between EUROCAE and RTCA, in order to assure the maximum possible interoperability of systems.


63

RTCA established a first Special Committee, SC203 on April 2010, with the objective of define the Minimum Aviation System Performance Standards (MASPS) for RPAS operations in National Airspace System (NAS). The RTCA SC-203 provided the following material, till the development of UAS MASPS:

Guidance Material for UAS, published as DO-304 on March 2007

Operational Services and Environment Definition (OSED), published as DO-320, on March 2010

Operational and Functional Requirements and Safety Objectives (OFRSO) for UAS, published as DO-344 on June 2013.

Subsequently, in May 2013, RTCA established the Steering Group SC-228, working to develop the Minimum Operational Performance Standards (MOPS) for DAA equipment and a Command and Control (C2) Data Link, establishing L-Band and C-Band solutions for C2L system. The initial phase of standards development focused on civil UAS equipped to operate into Class A airspace under IFR flight rules. The Operational Environment for the MOPS is the transitioning of a UAS to and from Class A or special use airspace, traversing Class D and E, and perhaps Class G airspace. The committee published the first of the Phase 1 documents in September of 2016 with the release of DO-362, Command and Control (C2) Data Link Minimum Operational Performance Standards (MOPS) (Terrestrial). Phase 2 of MOPS development is underway to specify DAA equipment to support extended UAS operations in Class D, E, and perhaps G, airspace, as well as Satellite-based C2 data link. Terms of Reference describing Phase 2 activities delivered in the summer of 2020.

RTCA Reference Standards and Documents

RTCA DO-304-Guidance Material and Consideration for UAS, March 2007

RTCA DO-320-OSED for UAS, June 2010

RTCA DO-344 Operational and Functional Requirements and Safety Objectives for UAS standards, June 2013

WP-1 Detect and Avoid (DAA) White Paper

WP-2 Command and Control (C2) Data Link White Paper

RTCA DO-381 MOPS FOR GROUND-BASED SURVEILLANCE SYSTEM (GBSS) FOR TRAFFIC SURVEILLANCE

RTCA DO-366A MOPS FOR AIR-TO-AIR RADAR FOR TRAFFIC SURVEILLANCE

RTCA DO-365, RTCA DO-365A MOPS FOR DETECT AND AVOID (DAA) SYSTEMS

RTCA DO-377, C2 LINK SYSTEMS MASPS

TERMS OF REFERENCE RTCA Special Committee 228 Minimum Performance Standards for Unmanned Aircraft Systems, Rev 10, RTCA Paper No. 163-20/PMC-2034, June 2020.


64

3.7 Interoperability ATM/U-space Aspects

In order to provide the reader with an overview of the current status of maturity of the ATM/UTM integration and interoperability, a high-level description of the initial work done in ICAO, EASA/EUROCONTROL and U-space is presented below.

3.7.1 ICAO

ATM systems have been developed with increasing levels of accuracy, reliability and integrity over the years. Certification of equipment, systems and data are seen as an essential element of safety management. UTM systems, on the other hand, are evolving in a very different environment [71].

As the concept of UTM matures, systems providing initial levels of capability start emerging and the demand for airspace access continues to grow, it is important to address specific challenges that must be resolved in order to realize a harmonized, safe and effective UTM system implementation. As such, like their manned aircraft and ATM counterparts, UAS and UTM systems will soon need to address problems such as determining:

the performance requirements of the UTM system and the unmanned aircraft that are managed by such systems;

how UTM system will demonstrate and achieve a level of confidence normally associated with certified aviation systems;

how UTM will be effectively integrated into aerodrome environments and activities.

To this purpose, in early 2020 ICAO launched a Request for Information (RFI) to industry [72].

As indicated in the RFI, the primary requirement remains to facilitate UAS integration in the airspace without negatively impacting the safety of manned aviation operations or the safety of persons and property on the ground, taking into account security and equal accessibility for all airspace users.

The following investigation were asked:

UA Performance Requirements in a UTM Environment – Unmanned aircraft performance requirements should be derived from performance objectives, metrics, and indicators in order to meet expectations regarding safety, security, access and equity, environmental protection, efficiency, interoperability, and cost-effectiveness.

UTM System Certification Requirements – Given the nature of the planned/projected initial capability of UTM, UTM systems may have to demonstrate and achieve a level of confidence normally found in certified aviation systems. However, it is not necessarily the case that this needs to be done using the existing, established industry standards which may be viewed as excessive or unnecessary for the intended function of UTM.

UTM Integration into Aerodrome Environments/Activities – UA may operate adjacent to or at aerodromes and blend with conventional aircraft operations. This includes controlled airports, uncontrolled airports and/or heliports and addresses air and land-side operations both on the ground and in the air. It is essential that the risks, issues and challenges of UTM/ATM interaction within the airport environment are clearly understood and addressed


65

for the industry to move forward. With an increased need for airport connectivity (i.e. passenger, cargo, urban air mobility, etc.), it is important to identify and understand the roles of various stakeholders in the entire eco system4.

3.7.2 EASA/EUROCONTROL

EASA/EUROCONTROL have produced a joint UAS ATM Integration Concept of Operations [73], aiming to describe the operational ATM environment in which manned and unmanned aircraft must co-exist safely, including the airspace below 500ft (up to 2025 and beyond).

The CONOPS also briefly describes the relation between UTM and ATM. According to the document, UTM provides services in its area of responsibility. Some of these services are similar to ATM services. Such services must have a high-level of coordination with ATM. Therefore, for these services, UTM is part of ATM.

Other services provided by UTM are instead specific and can be separately handled by UTM. These can include such things as:

flight registration to enable regulatory authorities to manage where UAs fly, including management of NDZs5 and LDZs6;

linking flight registration of all UAs, or specific categories of UA, to an authorisation management system based on the applicable regulation;

dynamic real-time processing of authorisations and restrictions through smartphone apps;

supply of geo-fencing data directly to the UA if a standard interface is available;

providing access to the appropriate authorities for legal verification etc.

3.7.3 U-space

The CORUS project defined a U-space Concept of Operation [74] for the drones in very low-level airspace. Main aim of the CONOPS is to define a set of new services and specific procedures designed to support safe, efficient and secure access to airspace for large numbers of drones. In accordance with the U-space Blueprint [75] (and shortly introduced in section 2.3), the CONOPS describes a stepwise evolution of U-space through subsequent implementation phases U1, U2, U3

4 Not addressing Counter-UAS initiatives or capabilities.

5 No drone zones (NDZ): volume of airspace in which UAS are totally prohibited unless granted special authorisation (e.g. government UAS)

6 Limited drone zones (LDZ): volume of airspace in which UAS are allowed if they meet specific requirements and/or do not exceed a defined number


66

and U4, enabled by the improving drone automation and connectivity. Each progressive step allows more efficient use of the airspace while maintaining or improving safety.

Figure 12 - U-space levels, from the U-space Blueprint (Source: CORUS CONOPS)

In the following various aspects of how the U-space concept could work in reality [123] are presented:

Preparation of the drone mission: To prepare the flight, the drone operator uses information sharing services connected to ATM via SWIM (e.g. NOTAMs, meteorological conditions and forecasts at the nearest aerodrome), combined with other U-space services, such as navigation and communication coverage services, flight planning assistance services and services providing the expected density of traffic in the mission area. Since the drone is registered, the system automatically links the elements described in the registry with elements of the flight request, in which full details of the airworthiness of the drone and its behaviour in emergency situations are described.

Submission of a flight request and reception of an acknowledgement: the planned route adheres to applicable regulation, airspace requirements (including airspace availability, temporary and permanent restricted areas), and requirements on specific drone equipment. If the flight requires an additional approval, then the request is submitted to the relevant entity and an answer is sent to the drone operator. When the drone is airborne, it receives information and alerts and might alter its original route to avoid traffic, meteorological conditions, or any changes to airspace accessibility. Throughout the flight, the drone broadcasts its unique identifier. The tracking service allows the drone flight path to be followed and supports other services like the situation awareness, which is provided, with some limitations, to a wide range of customers

Execution of the flight: the drone is equipped with a ‘detect and avoid’ (DAA) system which allows it to avoid hazards.

It is important to notice that the CORUS CONOPS focuses exclusively on VLL operations, involving all size of drones including those carrying passengers. The document also addresses VLL Operations in vicinity of airports.


67

Operations directly managed by ATC using current procedures (e.g. landing in an airport in the same way as a manned aircraft) and IFR RPAS were not considered in the scope of the CONOPS. Nevertheless, it is interesting for INVIRCAT to notice that the U-space Initial CONOPS explicitly planned for two services paving the way to UTM/ATM integration through an explicit Interface with ATC.

Figure 13 - U-space services (Source: CORUS CONOPS)

The two services described as part of this interface with ATC are:

1. A procedural interface with ATC

The procedural interface with ATC is a mechanism to coordinate an entry of a flight into controlled airspace. This service will be only offered to flights which have submitted operation plans and are entering airspace controlled by ATS. The interface works before flight.

The Operation plan processing service will invoke the interface and through it:

• ATC can accept or refuse the flight

• ATC can describe the requirements and process to be followed for the flight

2. Collaborative interface with ATC

The collaborative interface with ATC is introduced in U3 and is a service offering communication between the Remote Pilot (or the drone itself in case of automatic flight) and ATC while a drone is in a controlled area. This service will only be offered to flights which enter airspace controlled by ATS. The communication may be verbal or textual. The collaborative interface allows flights to receive instructions and clearances in a standard and efficient manner, replacing ad-hoc solutions used prior to this service being used.


68

The described procedural interface with ATC is the normal method to get approval to enter a controlled area. ATC may refuse to accept flights as they choose. The collaborative interface is not a means to avoid such approval.

The collaborative interface with ATC provides a means of communication between ATC and Remote Pilots. In addition to communications, safe operation is enabled by ATC having access to U-space surveillance data.

The CONOPS also describe a third interface with ATM in relation with the tracking service. Because of the role of tracking in the processes of conflict resolution and traffic information, the CORUS CONOPS assumes that there will be only one safety-critical instance of tracking in any location. Any instance of the tracking service receives all position reports in its area of interest. Tracks are built using a statistical process that can be assisted by having access to the operation plans of the flights, hence the tracking service will also be a client of the drone operation plan processing service. The tracking service should be able to deal with multiple sources of reports for the same flight, as well as (‘uncorrelated’) reports that do not contain the identifier of the aircraft or flight such as would come from primary radar, or that contain another (perhaps previously unknown) identifier for the flight or vehicle, such as would come from cellular telephone triangulation, or from ADS-B. When appropriate, the U-space tracks will be sent to ATM in a format acceptable to ATM.

Finally, as part of the CORUS work, a safety assessment strategy called MEDUSA7 is proposed, to identify and manage the hazards posed by drone traffic in the context of U-space. This methodology is based on the EUROCONTROL Safety Reference Material (SRM) where a broader approach to assess safety is adopted. This approach addresses both the positive contribution of U-space to aviation safety (success approach), as well as U-space’s negative effect on the risk of an accident (failure approach). The success approach is required to show whether operation under U-space is intrinsically safe, in the absence of failure. The MEDUSA process provides a holistic approach to the U-Space safety assessment incorporating different viewpoints, not only the operator perspective (which comes with SORA), but also the airspace perspective of the U-Space service provision and the interoperability of these services with the ATS/ATM. The operator perspective remains within MEDUSA with the reception of different SORA assessments, and the U-space perspective with the integration of those results in a single safety assessment. This safety assessment shall be conducted considering normal, abnormal and faulted conditions in order to derive a complete and correct set of safety requirements/mitigations to be implemented at U-space service level, at drone operators’ level and/or at non-U-space service providers’ level, such as ATS providers.

3.8 Drone Swarms

The swarm flight of drones can be included within the U-Space, since the main objective of the U-Space CONOPS is to define a set of new specific services and procedures designed to support safe, efficient, and protected access to airspace for a large number of drones. What this concept of U-Space deals with has been extensively developed in the previous section.

7 The MEthoDology for the U-Space Safety Assessment - MEDUSA


69

Although swarm flight consists of the joint flight of numerous drones, they move as one, each drone in the swarm can communicate directly with its peers at the same level in the hierarchy and with its immediate lead drones. The leading drones at the highest level of the hierarchy communicate with the server on the ground, sharing the data collected and pre-processed by the swarm and distributing the mission objectives downwards provided by the server. This is important when studying the integration of RPAS swarms in TMA under the instrument flight rules (IFR), as they could follow the rules that govern the movement of an individual drone as long as drones that are part of the swarm behave as a whole. Otherwise, individual drones should be considered.

Drone swarms, also known as distributed collaborative systems, are flocks of small unmanned aerial vehicles that can move and act as a group with limited human intervention.

The US Department of Defence made a demonstration on one of the largest micro-drone swarms in the world. It launched a flock of 103 Perdix drones into the sky over California, where they flew information and demonstrated collective decision-making without human assistance [94].

Swarming behaviour is most often observed in the wild, such as when a school of fish or a flock of birds rapidly change direction in unison, in what appears to be a series of tightly choreographed manoeuvres. Swarm systems are usually made up of individual agents (such as ants, birds, cells, or drones) that interact with each other and with their environment. Agents follow simple rules, but collective interactions between agents can lead to rather complicated and sophisticated collective behaviours, including emerging intelligence. For example, a swarm can remain in formation while changing direction multiple times.

The swarm has been defined as “a large number of scattered individuals or small groups that coordinate and fight as a coherent whole” [95]. Swarms can exhibit emergent intelligence by following simple rules that guide the behaviour of individual members of the swarm. When agents in a swarm follow these rules, complex and unified behaviours can emerge. Sensors are important because the rules used to guide swarm behaviour are often based on environmental factors outside of the swarm. Finally, the agents of an autonomous swarm must be able to communicate with each other.

These swarms’ range in size from tens to hundreds of drones. This range seems to be a sweet spot for creating swarms, because drones can be quite capable while still being much cheaper than their manned counterparts. A human pilot controls the behaviour of the swarm but does not fly individual drones; they keep their training automatically.

To address the risks of unauthorized actions due to interference or hacking that can affect command and control, drones can be programmed with predetermined rules of behaviour if they lose contact with each other or with their human supervisor.

Although right now the term "Drone swarm" is used mainly in military terms, it can be approached in another way, seeking to apply them in the TMAs of airports for the operation of RPAS. The swarm action of the RPAS would allow to cover more surface. This way of operating RPAS can bring great advantages in certain operations, such as, for example, the supervision of surfaces at airports to check that everything works as established [95]. Drones will not use airport runways, obviously, but they will complicate flight paths, especially for smaller low-flying planes.

A great advantage that swarming flight provides would be the ability for aircraft to communicate with each other and autonomously coordinate their actions. This idea could draw interest to develop


70

software and hardware to allow drones to cooperatively assign tasks and resources and plan flight routes, working together toward one common goal without the help of an operator.

Airplanes, especially airlines, have moved toward autonomy for decades as autopilot systems have increasingly taken over a pilot's job. The goal at the beginning was not autonomy, but rather that the machines would help the pilots to make better decisions. A debate that has been generated is about whether autonomous cooperation should be orchestrated by a central controller or between the aircraft companies themselves.

When using a swarm, it is possible to have 80 percent failure of people and still be 100 percent successful. A swarm has redundancy built in. But coordination problems need to be overcome.

The existing flight infrastructure can barely handle the roughly 7,000 daily flights in US airspace, and an estimated 2 million autonomous drones will join aircraft in that space once regulations for the autonomous flights are in place. NASA hopes that technology like Heron Systems' MACE software and hardware will help airplanes and drones work together to avoid accidents and work on flight paths with minimal guidance.

Heron Systems and the University of Maryland test the company's Multi-Agent Cooperative Engagement (MACE) system for teamwork with autonomous drones in June 2019 at the university's Fearless Flight Facility (F3).

3.8.1 Drone Swarms in Airports

One possible challenge for operation within TMA is posed by groups or swarms of RPAS, which would likely saturate ATM capacity if considered as separate aircraft. In this perspective, regulations are already accommodating formation flying of manned aircraft and formations of RPAS can be analogously considered as a single aircraft from the ATM perspective [97].

Drone swarms are considered to be an example of automated or remotely supervised flight [121]. U-space considers the swarm to be a single solid object and will not attempt to pass another flight through a swarm. The swarms will have a unique operating plan and this plan will include dimensions for the swarm. Swarms may be prohibited in some airspaces.

Swarm airports are introduced as a way of obtaining continuous operation in an autonomous drone swarm. An airport acts as a service station where the drones can replenish their energy autonomously. When incorporating several airports in the same system, one can operate a large drone swarm without the need for human interaction. This simplifies the use of drone swarms in applications such as surveillance and delivery. As there is little or no previous research on swarm airports, there are many issues that could have been addressed.

When it comes to getting an airport to be able to support the flight of a swarm of drones, one thing that must be considered is the drone battery change time. This is an aspect that needs to be improved, and for this the following has been proposed:

Airports with different efficiency: By implementing either airports which can take more drones at the same time or implement diversity in the efficiency will introduce another dimension when deciding an airport. It is also more likely in a real-world system that the airports have a more variable time consumption on a battery charge.


71

More advanced airports: In the existing implementation, the airports are very passive and do nothing else but change the battery when a drone arrives. Below is a list of possible ways to increase the service and general flow at the airport:

o Expanding the service done at the airports. There are more parts of the drone which needs to be changed, just not as often. This could be propellers, motors, cameras, other equipment, packages, etc. This would affect the time consumption for a service considerably, making it much more difficult to calculate when it is available. This change would also make the system even more autonomous. The airports could also have different tasks, meaning that the drones will go to another airport for a battery change compared with a motor change and a third for propeller change. The airports could also offer several services at once, where each airport has its unique combination of possible services.

o Prioritizing the drones. Based on what the system is used for the drones could have different missions, where some missions are more important than others. If this is the case, the airports could prioritize which drones that get service first based on the priority of their mission.

o Prioritizing based on payment. This idea is inspired by the priority idea in the previous point. It could be possible that the airports are not part of a specific system but operate as an airport known today. This means that drones and airports are not part of the same system and drones can use airports that are placed at known locations. When a drone arrives, it can pay for a service to be done and the airport performance. An example of such a system is grocery delivery. If all the different companies delivering groceries start delivering using drones, a third party can place service airports at several locations that all companies can use. The airport could then prioritize the incoming drones based on who pays the most [87].


72

4 RPAS Operations in TMA: Related Projects

This section describes objectives, operational concepts and important findings of RPAS8 related projects.

4.1 MALE RPAS Integration (NLR/General Atomics)

4.1.1 General Description

In May 2019, a two-day Real Time Simulation (RTS) was performed by NLR to contribute towards the development of CONOPS for integrating MALE RPAS into unsegregated European Airspace. The RTS focused mainly on contingency situations in the TMA environment. The RTS was financially supported by General Atomics-Aeronautical Systems Inc. (GA-ASI). Additionally, GA-ASI provided NLR with a 3D model of the SkyGuardian RPAS.

4.1.2 Operational Concept under Analysis

The RTS was performed using the MALE RPAS RTS Facility (MRRF) of NLR. The MRRF consists of two components. The first component is the NLR ATC Research Simulator (NARSIM) which is used to simulate air traffic and provides working positions for Air Traffic Controllers (ATCOs) and aircraft pilots (see Figure 14). The second component of the MRRF is the Multi UAS Supervision Testbed (MUST). MUST is used to simulate both the RPAS and the remote pilot Remote Pilot Station (RPS). For the purposes of this project, MUST was configured with the flight performance model of the General Atomics SkyGuardian MALE RPAS (see Figure 15). The MRRF was created by establishing a Distributed Integrated Simulation (DIS) link between NARSIM and MUST.

8 Projects may have used a different terminology at times. In this section, INVIRCAT terminology is used when confusion can be excluded.


73

Figure 14 - First MALE RPAS RTS Facility (MRRF) Component: NLR ATC Research Simulator (NARSIM)

Figure 15 - Second MALE RPAS RTS Facility (MRRF) Component: Multi UAS Supervision Testbed (MUST)


74

The RTS considered the following non-nominal scenarios within the TMA environment:

Missed-Approach / go-around

C2 Link Loss

Loss of R/T Voice Communication

Transponder Failure

Automatic Take-Off and Landing System Failure

Traffic Conflict without Detect and Avoid

Loss of Propulsion

4.1.3 Technologies Investigated

AS mentioned above, the technology investigated several special use cases for the GA-ASI SkyGuardian RPAS.

4.1.4 Overall Findings and Conclusions

After each experiment run, the experiment participants and observers discussed the events that occurred during the simulation. Using this input, as well as input from participant workload and situational awareness questionnaires, a first draft of the CONOPS for the considered contingency situations was developed. The CONOPS for these conditions is presented as a set of guidelines for ATCOs and RPAS pilots in the sub-sections below. It should be noted that the presented material needs to be validated in a second study and NLR is currently working towards such a validation.

Additional considerations need to be added about ATOL system and handling the ATC-ordered round-trip manoeuvre during a C2 loss situation. Two additional points mainly raise. First, the ATOL system aboard the RPAS does not use an instrument landing system (ILS) approach nor does it have a decision height. Therefore, as also anticipated in section 3.3.2, ATCO should not authorize the RPAS pilot for an “ILS approach”. Instead, ATCO should state: "Cleared for RPAS approach." The "RPAS approach" should be described on the airport navigation charts for clarity. Second, questions were raised about how an ATC commanded roundtrip manoeuvre could be handled during a C2 link loss situation, or if a runway incursion occurs with loss of ATOL and C2. Because C2 is lost, the pilot could not start or fly the missed approach manually, and therefore no concrete solutions could be determined during the discussion session. One potential option could be to use SkyGuardian's detection and avoidance system to autonomously perform a worst-case missed approach. However, it is not yet clear if this option is technically feasible and this scenario should be reviewed in future research.

A more detailed analysis of the different use cases is contained in an NLR document [28].

Based on the studied scenarios and conditions, the following main conclusions can be drawn:

The experiments demonstrated that civil Air Traffic Controllers (ATCOs) are capable of dealing with MALE RPAS contingency scenarios with very mild additional training. This is because MALE


75

RPAS operations are very similar to manned IFR operations, except during Command and Control (C2) link and Automatic Take-off and Landing System (ATOL) failures.

The revised MALE RPAS airspace integration CONOPS makes use of predefined emergency loiter waypoints for many contingency scenarios. Such waypoints should be specified in RPAS flight plans for all phases of flight, and should be geographically separated from prevailing traffic flows. This approach to contingency management takes advantage of the much higher endurances of MALE RPAS aircraft when compared to conventional IFR traffic. By activating a recovery mission to such waypoints, the predictability of operations can increase for both ATCOs and RPAS pilots. It also gives all ATCOs and RPAS pilots the time needed to troubleshoot problems, and make a considered decision on next steps (e.g.: continue mission, land at alternate airport, and controlled flight into terrain).

The CONOPS for ATOL failure and loss of propulsion scenarios needs to consider the phase of flight during which these failures occur. Similarly, the missed approach procedure needs two different versions depending on whether the pilot or the ATCO initiates the go-around.

During C2 link failure, the ICAO approved 7400 transponder squawk code should be adopted world-wide. This will increase ATCO recognition of C2 link loss, a situation unique to RPAS operations.

Because voice communications are essential for ATCO situational awareness during non-nominal circumstances, a secondary backup fixed-line telephone connection between the RPAS pilot and ATC is highly recommended.

ATCOs should keep in mind that MALE RPAS are always IFR traffic, even in VMC conditions. Therefore, RPAS traffic cannot be approved for visual patterns or any other procedures that are only applicable for VFR aircraft.

On a similar note, most civil ATCOs are unfamiliar with RPAS specific systems and terminology (e.g. C2 link and ATOL). Educating civil ATCOs on such RPAS specific aspects will improve their decision-making performance during contingency situations.

4.1.5 Relations with INVIRCAT

Most of the use cases that were detailed and investigated in this project will also be of importance to INVIRCAT. INVIRCAT will also make use of the MRFF platform of NLR, consisting of the NARSIM and MUST simulators.

4.2 SINUE and DeSIRE


SINUE and DeSIRE were ESA/EC funded projects aimed at testing satellite-supported guidance of unmanned aircraft in coastal regions and over the sea [22]. The projects demonstrated the capability of safe insertion of RPAS by using satellites, assessing communication latencies and identifying issues and required procedures.


76


Emergency procedures were described to mitigate loss of voice communication between ATC and remote pilot, loss of command and control link, and interruptions/high latency of communication. These emergency procedures took into consideration the following aspects:

1. Home base

Based on the scenario/use-case, the following home bases were considered:

a. Home area above sea, where the RPA would try to re-establish communication by climbing in a circular pattern

b. Definition of an emergency airport

2. Emergency route

Before the mission was executed, a route fully separated from other traffic was defined, avoiding inhabited areas and vertical layers of controlled air traffic.

3. Towards the emergency route

As emergency procedure towards the emergency route from the current position of the RPA, it was defined that the RPA should fly directly towards the closest waypoint of the emergency route, maintain altitude for two minutes. Afterwards, altitude changes were allowed to reach target altitude at that waypoint.


The project investigated BVLOS operations using satellite communication. Regular VHF radio transmission between the controller and the RPA was used, and the RPA forwarded the audio to the satellite link and to the remote pilot. A backup phone line from the controller to the remote pilot was activated.


Findings were structured in the following manner.

Separation and collision avoidance: Current separation standards for manned air traffic were applied to RPAS as well. The controllers were able to maintain separation.

Communication: Two seconds delay from satellite communication was experienced and deemed acceptable by the controllers.

ATC interface: New squawk codes were suggested, but controllers were reluctant regarding RPAS specific terminology.

Dependable emergency recovery: Defined procedures were comfortable for controllers, even in the worst possible cases.


77

Situational awareness: To highlight the appearance of RPAS in controller displays, it was suggested to use RPAS specific callsigns, symbols and/or colours. An RPAS specific painting could help controllers while visually identifying them from a tower.

Emergency procedures: To assist the controller, an RPA flying towards the emergency route should maintain a highest possible altitude (to regain communication link). Emergency routes should be visible at the controller display.

Backup phone: A landline connection from the controller to the remote pilot was deemed helpful in case of lost link.

Priority over manned traffic: Controllers assigned unmanned aircraft a lower priority than manned aircraft, comparable to small VFR traffic.

Recommendations: Party line communication with other traffic should be used when communicating with RPAS; a dedicated radio transmission is required; controllers need to be trained on emergency procedures; landline communication can be beneficial compared to communication with manned traffic.


Emergency procedures defined in DeSIRE are of limited applicability in the INVIRCAT context, as home bases will not be the first choice for emergencies in the TMA. The definition of the missed approach procedure as an emergency route in the final approach phase, however, may be applicable in the INVIRCAT CONOPS.

4.3 USICO


USICO (2009-2010) assessed the possibility to integrate UAS into the non-segregated airspace by conducting real-time man-in-the-loop ATC simulations [23] UAS were piloted from a realistic remote pilot station. Objectives were the evaluation of the RPAS integration concept in normal and emergency operations as well as the investigation of communication delay. A simulated MALE RPAS travelled from a regional airport to a mission area across two sectors, experiencing emergencies in a TMA on the way. ATC simulations used the simulation environment NARSIM of NLR and DLR’s simulator ATMOS.


Handover procedures between sectors had to be realized, and the interactions of the remote pilot with air traffic control was analysed.


Communication was realized using telephone communication between the sector controllers and an ad-hoc telephone call between the respective controller and the remote pilot. Radio telephony was simulated using wire link, with a simulated satellite link delay of 1.5 seconds.


78


No particular issues with integration of RPAS into the airspace arose during the simulations. The applied concept allowed for a similar treatment of the RPAS compared to regular manned traffic.

New transponder codes were introduced for data link/communication loss and unpredictable emergencies.

Workload of controllers increased initially after RPAS were introduced to their sector, but fell back to usual values after a while.

Landline communication with the remote pilot was deemed beneficial.


The emergency situation procedures while crossing the TMA are to be considered when drafting the CONOPS of INVIRCAT. Impact on operations when communication is delayed might have influence on findings when safety, latency and performance levels are investigated.

4.4 UFO (Unmanned Freight Operations) – Phase 1


UFO – Phase 1 has been conducted between 2014 and 2017. The central topic was the investigation of integration of unmanned freight operations into current ATC procedures. For this purpose, three relevant use-cases were selected from a large set and the resulting requirements were established. The selected use cases were a long-haul express cargo flight on a Boeing B777F, a short-haul company internal transport on a Cessna 208, and short- to medium-haul relief flights on different aircraft in a swarm formation. Concepts derived in the course of the project have been partly investigated using simulation of controller/remote pilot interaction and different levels of controller assistance at their working stations.


Relevant to INVIRCAT research questions, the following concepts for airspace operations have been identified in UFO – Phase 1 [13]:

Static and dynamic temporary segregated areas are mentioned, with a description of possible block sizes for temporary segregated areas (TSA) structures. Dynamic mobile areas (DMA) of three different types are listed, which could re-use TSA structures by activating TSA blocks on demand.

The usage of issued arrival and departure routes is proposed, while semi-automatic compliance to these routes might be enabled by the translation of routes with “inaccurate” navigation orders into a set of waypoints. Visual/ILS approaches are deemed to be possibly problematic.

Establishment of corridors in the TMA, exclusively for use of RPA, are suggested. These corridors could be located at places that are rarely used by manned aircraft (e.g. approach routes requiring high climb/descent rates or sharper turns).


79

The introduction of displaced thresholds on the runway is also proposed, exploiting the steep descent capabilities of unmanned aircraft.

Helix structures, i.e. climbing and descending in full circles until cruise altitude or a final approach is reached, are presented, which are said to require more fuel but significantly less lateral airspace compared to conventional procedures.

A short outlook on free route airspace is also given, and the question of an increase in controllers’ workload is raised due to the fact that conflicts are divided more evenly, and not only at nodes of published air traffic routes.


4D trajectories in combination with global navigation satellite systems (GNSS), such as GPS or Galileo, are described as the main enabler for efficient RPAS integration into the airspace [13]

Numerous existing technologies in terrestrial and satellite-based communication are listed, and the technologies LDACS1 and AeroMACS are derived as most suitable for RPAS communication requirements [9] Wherever possible, terrestrial communication should be preferred over satellite communication, although the latter fulfils most identified requirements.


The project UFO had the objective to elaborate a validated concept to integrate larger cargo drones into controlled airspace, esp. airport operations. Technical and operational requirements were considered, and the proposed concepts have been validated by performance of selected use cases for cargo drone operations.


UFO – Phase 1 elaborated CONOPS for controlled airspace integration of cargo RPAS. Especially considerations regarding approach and departure in the TMA will be picked up in the INVIRCAT investigations. Proposed technology might be relevant for safety, latency and performance levels in task T4.2. RPAS specific procedures (TSA, DMA, corridors) are possibly also applicable in INVIRCAT’s CONOPS.

4.5 SESAR RPAS Demonstration Projects

A number, nine to be specific, of projects have been found in the period 2013-2016 by the SESAR JU, all integrated in a Demonstration program for RPAS insertion in ATM.

Several of these nine projects dealt with aspects related to RPAS operations in TMA. Here below, the applicable projects are reported in their main aspects and conclusions that could have a relation with the INVIRCAT project.

In the following subsections all of those projects that investigated aspects related to operations in the TMA and close to the airports are summarized.


80

Taking into account that the projects are all included in an overall SESAR program, and that the global aims of the whole programs are common to the projects, all aspects concerned with the relations with INVIRCAT are reported in a final common section.

It has also to be considered that these projects anticipate standards and regulations on RPAS, and are often carried out in parallel with the issuing of preliminary guidelines and CONOPS. As such, there are no regulations and standards referred in these projects.

4.5.1 DEMORPAS

4.5.1.1 General Description

DEMORPAS’s objective was to demonstrate whether the integration of RPAS in non-segregated airspace, in a mixed environment where RPAS and manned aircraft coexist, was feasible or not, i.e. to demonstrate whether it was operational and technically feasible with considering the systems already in use.

To that purpose DEMORPAS followed a stepwise approach during two different exercises, in order to progressively increase the complexity of the demonstration. In the final exercise two a RPAS and a manned aircraft flew together sharing the same airspace while they were being provided with air traffic control.

4.5.1.2 Operational Concept under Analysis

The operational scenario included the execution of ad-hoc procedures, inspired by the ones being addressed within the SESAR Programme and the current situation where air traffic control and manned aircraft are involved. Also, considering the second exercise, where more than one aircraft was in the air simultaneously, special separation procedures were put in place, always trying to mirror what happened with manned aircraft, so that conclusions about the feasibility of using existing procedures and the need of amendments were derived.

The second scenario focused on a unique aspect of RPAS, emergency procedures, i.e. it was studied how RPAS emergencies were handled by other aircraft in the vicinity as well as by air traffic controllers.

In order to execute these scenarios, specific ATC, emergency and operational procedures were developed so that the three aircraft used in the demonstration exercises could perform the scenarios. The aircraft used were the ALO RPAS and the STEMME S-15, both owned by INTA.

All phases of flight, including take-off and landing phases, were tested in the project.

4.5.1.3 Technologies Investigated

Technologies for remote pilot situational awareness improvement and for reliability of communications was experimented in the project.

The RPAS was equipped with a communications relay so that communications between the remote pilot and air traffic control in Madrid ACC were able to maintain bidirectional communications.

As far as the surrounding traffic was concerned, in order to provide enough situational awareness to the remote pilot, additional equipment was installed on the RPS consisting of a PC connected to SINA (Air Navigation Information System). SINA is an element of SACTA system in charge of providing users external to ACC with real time radar track information as it is presented at Madrid ACC. Both, RPAS and also the other aircrafts involved into the flight trials had to be equipped with SSR transponder to


81

be represented in SINA. Since both, the RPAS and the manned aircraft used in the exercises, were equipped with SSR transponder, they could be represented in SINA.

4.5.1.4 Overall Findings and Conclusions

It has been demonstrated that a system providing the RPs with information on surrounding traffic highly improves their situational awareness, helping them to execute manoeuvres considering the rest of aircraft positions. Non-cooperative traffic should also be able to be represented, especially in those environments where air traffic control is not provided.

Communication errors, both in terms of phraseology and procedures, according to the controllers, made it more difficult to operate in the frequency as other civil traffic, because a different phraseology implied to pay special attention to what the RPs were saying. This is closely linked to the lack of RPAS crew training on ATC procedures and communications. In the same manner, ATCOs are not used to control RPAS as part of their daily activities; therefore, it is recommended that they are introduced to the particularities of RPAS either in the initial courses or in refreshing courses.

The operation of a RPAS requires the participation of different people, depending on the size and complexity of the RPAS. In this situation the Remote Pilot (RP) had a huge workload during the operation, highly increased during the initial phase of the exercise, prior to and during RPA take-off and landing.

An extremely abrupt turn rate was noticed, making very difficult for an ATCO who was used to deal with manned flights to predict the RPAS trajectory. RPAS should accommodate their turn behaviour when sharing airspace with other airspace users and not executing a mission in order to help the controllers to execute their separation responsibility.

RPAS have specific failure modes which are not common in manned aviation. For this reason, it is necessary to define specific areas and trajectories to be flown in case an emergency occurs. In the case of DEMORPAS, the use of “emergency areas” designed ad-hoc for the exercise is notable. This helped the ATCO to know where the RPAS was going to proceed in case of any type of failure and have a full situational awareness of what was happening together with the defined emergency procedures.

It is crucial that, when operating in non-segregated airspace, all the aircraft use the same units and reference standards. In this sense, it should be understood that RPAS must be able to set ATC references, using barometric systems (altitude, QNH) instead of GPS, knots instead of meters per second, and feet/flight level instead of meters.

It is important to see, that in case a full integration in non-segregated and controlled airspace not only communications relay equipment would be needed, additional equipment would need to be integrated as well to operate like manned aircraft.

4.5.2 INSURE


INSuRE’s aim was to demonstrate the operational management of one rotary wing RPAS, piloted from a fixed station on ground, evaluating its interaction with other vehicles in a non-segregated airspace, the operational aspects in implementing nominal ATCO procedures, the safety aspects to be assessed to allow safe integration in controlled airspaces, and the human factor aspects addressing both pilot and ATCOs workload and reactions.

In particular, the prime objectives of the INSuRE Demonstration were:


82

1. Demonstrate the safe integration of the RPAS in airport surface operations preliminary to take off and landing.

2. Demonstrate the integration of the RPAS in non-segregated Air Traffic Management through a demonstration campaign that can significantly test all aspects of integration from controlling procedures and verification of integrity of control link, to communication between RPAS pilot and ATCOs.

3. Demonstrate safe execution of RPAS flights using a Detect and Avoid (DAA) capability compatible with existing operating procedures, identify alternative RPAS surveillance, communications and navigation solutions.


Starting from the overall project objective above defined, with the demonstration campaign, the project consortium was able to test all aspects of integration from controlling procedures and verification of integrity of the control link (C2) for communicating between the RPAS pilot and controllers.

The campaign also demonstrated the safe execution of RPAS flights using a DAA capability compatible with existing operating procedures, while identifying alternative RPAS surveillance, communications and navigation solutions.

The demonstration overall activities included, in the INSuRE approach, both simulation and flight campaign within two different airspaces:

CTR/TMA BRNO (Czech Republic) for the real time simulations;

TARANTO Grottaglie Airport (ICAO: LIBG) for the flight trials.

Flight missions were planned and performed with respect to minimal impact on other planned operations at LKTB and CTR/TMA, especially on commercial air transport. Coordination with airport authority was necessary.

All flights were carried out in CTR and TMA LKTB (up to FL 125) to ensure full control over all operations involved. RPAS were always separated from other traffic, except agreed manned light aircraft.


Three main technology areas were investigated in the project:

To demonstrate the Detect and avoid detection, information and timing capabilities;

To demonstrate integrity of the RPAS command & control data link.

To demonstrate integrity of the ADS-B system.


The situational awareness shown by the Controllers and RPAS pilot during the simulation and flight activities has been high.

The operational procedures in place for controlling manned flight in the nominal traffic demonstrated to be adequate also for RPAS, given that the RPAS system is equipped with capabilities to provide


83

communication means with ATC and to support awareness of surrounding traffic (RADAR track input and ADS-B for cooperative traffic).

RPAS response following a specific ATCO clearance happened within reasonable time range and it could be considered comparable with the response of a manned aircraft.

Workload of pilots and controllers has been calculated and felt comparable to the workload of handling a manned aircraft in the same traffic scenario.

The communication between RPAS pilot and ATCOs follows the same rules as the communication for manned operations/clearances, given that also the RPAS pilot is trained on operational voice communication standards.

The RPAS contingency procedure as response for a data-link loss was tested successfully during the flight trial.

The RPAS fast landing as response for an emergency procedure at the operational airport site was tested successfully during the flight trial.

RPAS pilot felt more secure in controlled airspace than in non-controlled airspace; coordination offered by controllers gave pilots a greater feeling of safe operations.

It is recommended to consider a possible standardization of procedures associated with contingency RPAS operation including:

The concepts of operation for data-link loss as well as for the other types of contingencies evaluated in the relevant Safety Documentation;

The level and type of information shared between RPAS pilot and ATC during the contingency procedures’ execution.

It is recommended to train the RPAS team and the pilot in command on procedures associated with emergency at the operational site, specifically on:

Expected reaction time;

Expected communication and responses between the involved actors;

The method of providing back-up communications in the event of a communication link failure.

4.5.3 MEDALE


Using existing assets including an experimental demonstrator (Sky-Y RPAS) the MedALE Project aimed to demonstrate the validity and limits of:

the ad-hoc operational procedures to operate RPAS in non-segregated airspace;

the airworthiness rules that normally are used to “certify” an RPAS for experimental scope;

the existing technologies and systems when compared to the requirements and capabilities of the existing ATM and of the new one that SESAR is developing.


84


The MedALE Project approached two demonstration environments at different levels of complexity:

Networked Simulation, i.e. multi RPAS interaction/operation within the ATM environment that SESAR was defining, including BRLOS operations in non-segregated airspace.

Live Trial, i.e. single RPAS real flight operation in an airspace under control of the Italian Air Navigation Service Provider (ANSP), from an Italian airport. The RPAS was equipped with a cooperative suite based on ADS-B.

The Networked Simulation exercise had the main scope to assess and evaluate the impact of introduction of three classes of RPAS (MALE, MAME and Light) in a simulated non-segregated airspace. This exercise has been carried out in a realistic environment with the RPAS Pilots and the integration of two human in the loop controllers working positions: Tower Controller (Military ATCO) and TMA controller (Civil ATCO).

The live trial activity focused on the interaction between the RP and the ENAV ATC Controller in a surrogate non-segregated airspace. The ENAV ATCO was in the LIRM Tower / Radar control room. The operational environment is the Grazzanise LIRM airport. The Sky-Y RPAS landed and departed from the same airport following the GAT/OAT procedures: in the AFB a coordination between the Civil and Military ATCO.


Introduction of Collision Avoidance and Traffic Avoidance functions, and the integration on board of a dedicated ADS-B Out system was tested.


Separation standards need to be reviewed and potentially altered.

Policies must be tuned for launch and recovery methods for departing/arriving airports and for different RPAS typologies.

Communications performance requirements necessary to meet safety requirements are needed.

Standardized methods must be established for how to pass RPAS performance characteristics and mission information to ATCO.

Procedures for emergency and/or non-nominal operations should be established.

ATCOs achieved an excellent level of workload (very low / neutral) and situational awareness (very high).

RPAS procedures have to refer to current procedures applied to GAT aircraft in order to minimize the change of practices from ATCO point of view. Furthermore, ATCOs required to select and set standard / official procedures to apply to the RPAS flights, mainly during unusual situations.


85

4.5.4 TEMPAERIS


The objective of the project was to investigate the impact of RPAS integration into non-segregated airspace in a mid-traffic density environment. More specifically, the project focused on emergency procedures for RPAS, the impact on the traffic safety and regularity, as well as on controller workload.


The TEMPAERIS project investigated the following aspects of RPAS insertion in civilian air traffic in accordance with SESAR concepts:

Definition and validation of procedures in aerodrome circulation, and during SID/STAR phase of flight around the same airport

Filing of an IFR-like flight plan for RPAS

Capability to insert in the aerodrome circulation of a middle-sized commercial airport

Capability to follow SID/STAR from/to a middle-sized commercial airport

Evaluation of the acceptance by ATC of the procedures used in the case of the occurrence of non-nominal (abnormal) situations

For that purpose, the project carried out real flights and ATC simulations:

Real Flights: the main objectives in the in-flight demonstrations were twofold:

o demonstrate that RPAS can be interfaced with standard civil ATC and be processed as other commercial aircraft by civil operator

o test the acceptance by ATC of current RPAS procedures during some non-nominal situations such as communication loss or command and control loss,

Simulations: the objectives of the ATC simulations were to evaluate whether current ATC operational procedures are applicable to RPAS in a representative controlled traffic environment, both in nominal and non-nominal modes.


Technological aspects related to reliability aspects of GNSS and C2L were taken into account in the project.


RPAS behaviour was not perceived as different from the one of a small general aviation aircraft.

ATCOs considered that small RPAS shall not be integrated on airports where traffic is more than 20 movements per hour due to Wake turbulence separation for a small RPAS.

There is a need for the appropriate technology (ex: HD cameras + communication architecture) to secure the use of the «line up behind and hold» procedure (and also maybe the «see and avoid»).

The following contingency procedures: radio failure, C1/C2 Loss, GPS failure, emergency landing, have to be standardized in order to be made homogeneous at the ICAO level. However, these procedures might get adapted to each airport approach.


86

Flight plan format shall be adapted to RPAS specificity.

Proper C2 Link technology shall be developed, using the bands available for Aeronautical Mobile Service.

RPAS shall be included in the Trajectory Management Framework.

ATCOs’ HMI shall be able to present mission trajectory.

Future studies or projects shall include solutions for the Small RPAS/ VLL topics, especially specific CNS/ ATM and AIS solutions for this market segment.

Initial package shall comprise: a simple and efficient navigation system, a permanent position reporting system and a geofencing capability.

4.5.5 ODREA


The overall objective of the ODREA project was to demonstrate integration of a large RPA (Sagem’s Patroller™) into the managed traffic of a middle size commercial airport, Toulouse-Blagnac (LFBO). Moreover, RPAS specific non-nominal situations such as Detect and Avoid (DAA) as well as Command and Control (C2) link loss were addressed.

For that purpose, the project merged simulation and flight demonstration activities:

Simulations: their main objectives were to assist the definition and the validation of operational procedures managing RPAS within representative controlled traffic. Moreover, the simulation framework was used to perform deeper analysis of some situations and environments without over cost that would have resulted from actual flights though allowing assessment of human factors thanks to representative controller and remote pilot stations.

Demonstration Flights: their main objectives were twofold:

1. Demonstrate that RPAS can be interfaced with standard civil Air Traffic Control (ATC) and exchange data to be managed as other commercial aircraft by a civil operator

2. Demonstrate Detect and Avoid capabilities with respect to other traffic, both on the airport surface and in the air

Several demonstration flights were performed in order to:

Assess the impact of RPAS architecture on communication between ATC and RPAS operators, particularly the effects of data link quality, availability, latency (especially for voice signals)

Demonstrate operational procedures:

o Nominal procedures between ATC and RPAS

o Handover between different controllers (tower, approach)

o Contingencies / recovery procedures


The ODREA project was expected to investigate the following aspects of RPAS insertion in civilian airspaces:


87

Definition and validation of procedures in aerodrome circulation, including departure and arrival phases of flight,

Capability to issue an IFR-like flight plan for RPAS,

Capability to integrate a MALE RPAS into the managed air traffic of a middle-sized commercial airport,

Capability to follow adapted departure and arrival procedures from/to a middle-sized commercial airport,

Capability to conduct all three types of missions (point to point, planned and unplanned aerial work) in lower airspace, including abnormal situations.

Capability to conduct missions in lower airspace in nominal but also in abnormal situations (e.g. detect and avoid (DAA), Command & Control (C2) link loss)


Technological aspects related to reliability aspects of DAA and C2L were considered in the project.


The ODREA project fulfilled the following demonstrations and identified the following needs:

Technical and operational feasibility of integrating RPA into the traffic of a mid-size commercial airport, taking benefit of tailored trajectories and pre-defined emergency procedures

RPAS capabilities covering almost every phase of flight, the RPA being remotely piloted

Initial assessment of the impact of latency (lag) on voice communications during the approach phase

Need for standardisation on DAA

Need for further addressing DAA, communication between the controllers and the remote pilot, degraded modes as well as landing and taxiing.

Need to foster exchanges between all ATM communities and keep demystifying RPAS

Need for further studies and joint activities addressing:

o C3 developments and SESAR Concepts for RPAS,

o Design of tailored trajectories including the definition of standard protection criteria,

o Minimum requirements for RPAS routine IFR flights,

Need for high level requirements and concepts of operations.

Need to define safety figures for certification.

Need for studies on data exchange (especially related to trajectories)


88

Need for requirements on C2 data link, incl. quality of service as well as transmission schemes and supporting infrastructure.

4.5.6 CLAIRE


Project CLAIRE was aimed to examine the issues regarding ATM and flying operations associated with the introduction of RPAS into civil airspace. This was undertaken as a series of complementary and incremental demonstration exercises, which offered the opportunity to validate assumptions and further develop procedures based on their findings:

Ground and TMA RPAS operations based on a mixed-traffic medium-sized airport

En-route RPAS operations

Live RPAS flights in non-segregated airspace

The demonstration exercises were undertaken using synthetic and live environments and allowed the investigation and assessment of:

Ability of standard ATM procedures to manage unmanned RPAS operations

Interaction between RPAS Pilot and ATCOs

Interaction between ATM sectors for RPAS operations

Contingency management processes and procedures for RPAS

RPAS and ATCO workloads


In particular, the following areas were examined in relation to RPAS operations:

SESAR Compliance: All demonstrations were conducted in cognisance of the SESAR ATM methodology and focussed on the specific issues raised by the introduction of RPAS.

Regulatory & Safety: The project addressed regulatory and safety issues associated with the flight of RPAS in civil airspace through the continuation of on-going dialogue with the UK CAA. This dialogue identified the nature and scope of activities or processes required in order to achieve safe and fully regulatory compliant flight trials.

Network Integration: This addressed the effect of potentially lower performance RPAS on the Air Traffic Management service and developed procedures for use in all flight phases. This included the exchange of 4-D trajectory information between the ATCO, RPAS air vehicle and the Remote Pilot Station (RPS).

Human Factors: The demonstrations allowed an analysis of the effects of RPAS in a mixed traffic environment on the work load of ATCOs, together with an assessment of terminology and phraseology.

Command Control and Communications: This addressed the requirements to rebroadcast ATC instructions between the air vehicle and the RPS. It also addressed communications required for command and control of the air vehicle considering aspects such as timeliness, throughput, and RPAS operations in the absence of an operational control link.


89

Detect & Avoid: This considered the impact of both human-in-the-loop and automated avoidance systems and the effect this may have on the Air Traffic Management system.

Contingency Planning & Management: The operational aspects of RPAS require significant levels of contingency planning to accommodate the potential for communications or system failures where the RPAS air vehicle itself may be required to determine a course of predictable actions. This exercise addressed how contingencies could be planned and how they could be shared with the Air Traffic Management System. The demonstrations included lost-link scenarios specifically to address the effect on the Air Traffic Management system and other airspace users.

Security: This addressed requirements for physical security such as access to the ground control station, and electronic security in terms of the potential for control of RPAS to be denied, or spoofed.


AS for other projects of the program, DAA capabilities and C2L, both in nominal and emergency conditions were tested.

In addition, the exchange of data and information such as lost-link recovery locations and emergency recovery locations, between ATC and the RPAS was also included in the test activities.


Future RPAS operations could be safely integrated into non-segregated airspace using existing ATC processes and procedures.

A detect & avoid capability and compliance with European aircraft equipage requirements will be necessary for operations in all airspace. Temporary Danger Areas to protect uncontrolled airspace are not sustainable for routine operations in order to meet the principles of equivalence and transparency.

Lower performance RPAS could result in an increase in en-route and TMA ATCO workload. The practice of blocking out large altitude bands of airspace for a manned aircraft to climb or descend could result in non-optimised trajectories for other airspace users.

Communications are considered to be equivalent to manned aviation, but with additional phraseology relating to:

• Lost link - unique to RPAS

• ERL (Emergency Recovery Location) – similar to diversionary airfield

• Prefixed initial contact with ‘unmanned’

A Mode S transponder is essential to avoid surveillance issues. This is particularly important for other aircraft equipped with ACAS (TCAS). A Mode S “Enhanced” transponder capable of producing Downlinked Aircraft Parameters (DAPs) would be an advantage in busy airspace, and in emergency situations.

For operations involving handovers of control between ground stations and/or RPAS pilots, handovers should be conducted away from sector boundaries. This process is transparent to ATC.


90

In abnormal conditions, RPAS were considered to be more predictable than manned aviation. RPAS procedures can, indeed, remove doubt regarding the flight’s trajectory in these circumstances, and the ability to actually communicate with the RPAS operator directly by telephone is a further enhancement over manned aviation.

To allow for the loss of control links between the pilot and the RPAS, some form of backup communication is considered desirable, possibly based upon a ground or mobile telecoms infrastructure.

Insurance rates are currently significantly higher than manned aviation and may hamper the business case for RPAS operations. However, as RPAS operations become more common and the safety and security risks identified in this report are addressed, it is expected that the cost of insurance will be significantly reduced.

Support the development of standards to cover the minimum acceptable level of situation awareness to be provided to RPAS pilots. This should also address response times associated with ATC executive instructions.

Since RPAS pilot is remote, the feasibility of co-location of RPAS pilot and controller should be determined.

In order to achieve live unmanned flight in non-segregated airspace, it was necessary to develop and seek approval for a suitable qualification for an RPAS pilot.

It is recommended that ICAO develops additional RPAS specific phraseology for ATC communications, e.g. a dedicated suffix to the call sign for awareness or the coordination of contingency procedures.

RPAS operating characteristics should be compatible with those of the aerodrome in order to maintain runway capacity at realistic levels.


All the projects of the RPAS demonstration programs were essentially addressed to test, in real-time simulations and in flight, a wide range of operational conditions, in terms of the effects on remote pilots and ATCOs of the peculiarities of RPAS flight in unsegregated airspaces.

Technologies related to the civilian use of RPAS are assumed as preliminarily available: detect and avoid systems are in the preliminary phases of design and test of concepts. Also, C2L technologies have still to be regulated and deeply investigated.

The aspects that are much related to the current project can be found, consequently, in the effects that operationally new aspects and also envisaged enabling technologies could have on remote pilot and air traffic controllers.

Many of the considered projects dealt with totally new contingency and emergency conditions of the integration of RPAS in unsegregated TMAs.

Also, if such projects dated back to 2016, there are conclusions and recommendations for future works that have been clearly identified in that projects and that could be considered in defining the requirements for the CONOPS and for the definition of the test plan in the INVIRCAT project.


91

In the previous subsections, conclusions and recommendations were shortly summarised, to allow a selection of those more directly applicable to the present project and for deeper investigations of the applicable projects results.

Eventually, the reference to those projects help to maintain a unique and well identifiable flow of activities in the SESAR (SESAR1 SESAR2020) program development.

4.6 SESAR Industrial Research Projects: PJ10-05 PROSA / PJ13-ERICA


PROSA project solution 10‐05 “IFR RPAS Integration” was aimed at providing the procedural and technological means to safely integrate RPAS traffic in the non‐segregated controlled airspace complying with ATC instruction. Accommodation of RPAS in the current controlled environment was also encompassed by this solution as a quick goal for deployment.

PROSA-10‐05 will be continued in SESAR Wave 2 in the context of PJ13-ERICA project.

ERICA project addresses PJ13 W2 “IFR RPAS” and it is composed of the following Solutions:

Solution PJ.13-W2-111 “Collision avoidance for IFR RPAS” (actually derived from solution PJ11-A2 from CAPITO project)

Solution PJ.13-W2-115 “IFR RPAS accommodation in Airspace Class A to C”

Solution PJ.13-W2-117 “IFR RPAS integration in Airspace Class A to C”.

Specific objectives of accommodation and integration will be the development and validation of:

Concept of operations (CONOPS) both for accommodation and integration;

RPAS technical capabilities;

ATM planning tools;

ATC tools;

ATC procedural means.


All operational aspects of accommodation and integration of IFR RPAS in airspace classes A-C have been investigated and will be taken into account, respectively, in the PROSA and ERICA projects.

The primary aim of the previous project PROSA has been the development of the IFR RPAS Integration operational concept, operational environment, operating method and definition of the operational requirements, the use cases and provision of Benefit Impact Mechanism at V2 Level.

This aim has been attained primarily by identifying the roles and responsibilities among Remote Pilots (RPs), Air Traffic Controllers (ATCOs), and the other airspace users involved in the IFR RPAS integration concept. In addition, use cases and an operating method have been proposed. The operational


92

environment is based on en-route/TMA operations in line with SESAR CONOPS that provided the baseline for the operations and interactions that RPAS will have with the rest of the ATM elements and actors (which include operating aircraft of various categories, air traffic services, etc.).

A second result has been the essential requirements (operational, safety and performance requirements) of the RPAS Integration concept, defining the procedures, the required enablers (e.g. required communication, navigation and surveillance services or airborne DAA capability), the automatic functions as well as the phases of the flight and contingency situations that RPAS will have to consider for their safe and seamless integration in non-segregated ATM airspaces.

Following the project objectives and taking into account the available results up to date, the ERICA project will approach the RPAS insertion into non-segregated airspace in accordance to the:

establishment of the new concept of operation;

identification of which RPAS categories have to be considered;

necessary performances that have to be satisfied with special attention to the mandatory safety measure;

operational and technical solution that can satisfy the expected performances;

validation of the identified solutions, reaching the V3 maturity level.


While operational requirements for pilots and ATCOs have been investigated in PROSA, In the project ERICA, namely Solution 111, the development and the operational validation at V3 level of a Detect and Avoid (DAA, Collision Avoidance and Remain Well Clear functions) system for IFR RPAS operating in airspace class A-C will be carried out.


The project PROSA finally provided a V2 validated set of Safety and Performance requirements for the IFR RPAS integration, both in en-route and in TMA, together with the OSED for the RPAS IDR integration in the European controlled airspace (classes A-C).

The validation activities performed in the context of PROSA-10.05 solution gave indications that the integration of RPAS flying IFR in medium complexity en-route and TMA environment is feasible even if it may come at the expense of additional workload for the ATCOs with a consequent impact on airspace capacity. The achieved results are not fully covering a V2 maturity solution, and the activities are currently on-going under PJ13 – ERICA project.

The expense of additional workload of the ATCOs with a consequent impact on airspace capacity was encountered, especially in the non‐nominal conditions (e.g.: contingency procedures). In the future phases, improvements and clarification in both the operating methods and technical architecture will be needed. Contingency and emergency are important concepts to be well clarified. Delay in communication is a central issue for RPAS Integration, and definition of quantified requirement is expected in next phase. In contingency situation, the additional workload and the impact of a new


93

airspace user such an RPAS, has potential consequences on traffic capacity. Manned traffic may be impacted from a capacity point of view in those conditions.

Latency in the communications is a key aspect to be considered. The participants in the simulations had some reservations in terms of acceptability when high values of latency were simulated (up to 7 seconds in en-route), especially in combination with a high number of RPAS on the same frequency. With latency values from 0 to 2 seconds, as those simulated in the TMA, neither the controllers nor the remote pilots reported any issue.

When operations occurred in nominal conditions, they could be managed with a level of Safety equivalent to the current situation; non-nominal and abnormal conditions the controllers were confronted to in the simulations, raised the level of complexity and triggered some Safety relevant situations.

RPAS related contingency and emergency were deemed as very important aspects for a safe integration and the clarification of the procedure will be needed in the future activities.

This solution explored also the possibility of integrating RPAS aircraft in a non-segregated TMA (Medium Density/Medium/High Complexity) in the context of conflicting traffic with the application of DAA systems. Lost separation and collision scenarios were explored with the application of a DAA system which provides the remote pilot with situation awareness and collision avoidance functions. The general conclusion was that the collision avoidance warnings and manoeuvres performed during close encounters were deemed safe and appropriate, both from RP and ATCO perspective, as well as from a technical point of view.


The INVIRCAT project aims to explore totally new Operational Concepts for RPAS integration in TMA. PROSA, anyway, investigated many aspects of RPAS TMA integration in Real-Time simulations. Many operational aspects, and their effects on pilots and Air Traffic Controllers have been investigated and specific results and analyses could benefit to the identification and selection of use-cases and procedural aspects to be taken into account in the definition of the new concept, as far as in the identification of contingency conditions and their management.

The OSED for IFR RPAS integration (solution 117) and functionality of DAA in the TMA (solution 111) will be further investigated in the ERICA project, and it could be of considerable benefit to maintain a continuous exchange of information and data with the on-going project.


94

5 Conclusions

In the present deliverable the deep analysis of the operational context and boundaries of the present project.

The project’s goals are the creation of a comprehensive high-level set of operational and technical requirements and a CONOPS to safely integrate RPAS in the existing ATC procedures in TMA and airports under Instrument Flight Rules (IFR).

This will include the consideration of all ATC instructions in the airport and TMA environment (e.g. headings and altitudes requests, take-off and landing clearances, and late go-around instructions) as well as taxiing and Automatic Take-Off and Landing (ATOL) procedures. Therefore, the project will focus its work on RPAS in the ‘Certified’ category, operating under IFR conditions.

For the INVIRCAT project only aircraft that fit in the class VI traffic category are of relevance, which implies requirements as being able to fly Standard Instrument Departures (SIDs) and Standard Arrival Routes (STARs) and meeting the set performance standards for the Network, TMA and airports.

Current State-of-the-Art of CNS and Avionic technologies has been investigated, highlighting some open issues to be taken into account in the CONOPS development and in the definition of use-cases and scenarios for the test plan.


95

6 References

[1] EUROCONTROL. 2020. COVID19 Impact on European Air Traffic. https://www.eurocontrol.int/covid19. [Online] 30 09 2020. [Cited: 06 10 2020.] https://www.eurocontrol.int/publication/eurocontrol-comprehensive-assessment-covid-19s-impact-european-air-traffic.

[2] EUROCONTROL, 2019. Performance Review Report - An Assessment of Air Traffic Management in Europe during the Calendar Year 2018. Brussels : EUROCONTROL, 2019.

[3] EUROCONTROL. 2017. RPAS ATM Concept of Operations Edition 4.0. s.l. : European Organisation for the Safety of Air Navigation (EUROCONTROL), 2017.

[4] EUROCONTROL, 2018. UAS ATM Integration. 2018.

[5] Bianfable. 2019. Is there a list of airports with Category 3 ILS systems? - Aviation Stack Exchange. Is there a list of airports with Category 3 ILS systems? - Aviation Stack Exchange. [Online] 13 11 2019. [Cited: 21 10 2020.] https://aviation.stackexchange.com/questions/71602/is-there-a-list-of-airports-with-category-3-ils-systems.

[6] CANSO. 2020. ANSP Considerations for Unmanned Aircraft Systems (UAS) Operations. [Online] 2020. [Cited: 21 10 2020.] https://canso.org/publication/ansp-considerations-for-unmanned-aircraft-systems-uas-operations/.

[7] Deprez, Cecile and Warnant, René. 2016. Combining multi-GNSS for precise positioning. Noordwijk : NAVITEC , 2016.

[8] EASA. 2015. Advance Notice of Proposed Amendment 2015-10: Introduction of a regulatory framework for the operation of drones. s.l. : EASA, 2015.

[9] Epple, Ulrich, et al. 2016. Unmanned Freight Operations (UFO) – Constraints for CNS-Concept, HAP4-D4.3-1. Oberpfaffenhofen : DLR, 2016.

[10] Garmin Aviation. Autoland System Limitations. [Online] [Cited: 21 October 2020.] https://www.garmin.com/de-DE/legal/ALuse/.

[11] George, Fred. 2019. Aviation Week Network - Flying Garmin's New Emergency Autoland. [Online] 30 October 2019. [Cited: 21 October 2020.] https://aviationweek.com/business-aviation/flying-garmins-new-emergency-autoland.

[12] Hader, Manfred, Robert Thomson, and Holger Lipowsky. 2020. Roland Berger - How the Covid-19 Crisis is expected to impact the Aerospace Industry. [Online] 10 06 2020. [Cited: 06 10 2020.] https://www.rolandberger.com/de/Point-of-View/How-the-COVID-19-crisis-is-expected-to-impact-the-aerospace-industry.html.

[13] Helm, Stefanie, et al. 2017. Unmanned Freight Operations (UFO) – Airspace Operations, HAP3-D3.1-2. Braunschweig : DLR, 2017.


96

[14] IATA. 2020. European COVID-19 Impacts Continue to Worsen as Border Restrictions Remain. [Online] 13 08 2020. [Cited: 06 10 2020.] https://www.iata.org/en/pressroom/pr/2020-08-13-01/.

[15] ICAO. 2001. Annex 11 - Air Traffic Services. Montreal : ICAO, 2001.

[16] ICAO. 2004. Annex 14 - Aerodromes. Montreal : ICAO, 2004.

[17] Inside GNSS. 2019. GBAS Installations Will Proceed at Airports Across Europe. [Online] 24 September 2019. [Cited: 2020 October 2020.] https://insidegnss.com/gbas-installations-will-proceed-at-airports-across-europe/.

[18] International, Airports Council. 2019. 2017 Aircraft Movements - Annual Traffic Data - ACI World. [Online] 08 01 2019. [Cited: 05 10 2020.] https://aci.aero/data-centre/annual-traffic-data/aircraft-movements/2017-aircraft-movements-annual-traffic-data/.

[19] ICAO Aviation System Block Upgrades (ASBU), ICAO - 2016.

[20] ICAO Circualr 328/AN190, Unmanned Aircarft Systems, 2011.

[21] ICAO RPAS Concept of Operations (CONOPS) for International IFR Operations, Oct. 2017

[22] Schmitt, Dirk-Roger, Morlang, Frank and Hampe, Jens. 2015. Remotely Piloted Aircraft Systems Integration in Controlled Airspace. Hamburg : UASYMPEX, 2015.

[23] Schmitt, Dirk-Roger, Morlang, Frank and Hesselink, Henk H. 2013. Demonstration of Satellites Enabling the Insertion of Remotely Piloted Aircraft Systems in Europe. Linköping : 4th CEAS Air and Space Conference, 2013.

[24] SESAR Joint Undertaking. 2020. European ATM Master Plan. Luxembourg : Publications Office of the European Union, 2020.

[25] SESAR PJ05 Remote Tower. 2019. Remote Tower Final Project Report. s.l. : SESAR, 2019.

[26] SESAR PJ10 PROSA Project. 2020. PROSA Final Project Report. s.l. : SESAR, 2020.

[27] SKYbrary. 2017. GBAS Landing System (GLS) - SKYbrary Aviation Safety. GBAS Landing System (GLS) - SKYbrary Aviation Safety. [Online] 10 09 2017. [Cited: 21 10 2020.] https://www.skybrary.aero/index.php/GBAS_Landing_System_(GLS).

[28] Sunil, Emmanuel. 2019. Integration of MALE RPAS into European Airspace: Step 1 - D1.5 Simulation Report. Amsterdam : Royal Netherlands Aerospace Centre, 2019. NLR-CR-2019-304-PT-5.

[29] Wikipedia. 2020. Wikipedia - Instrumentenlandesystem. [Online] 3 September 2020. [Cited: 21 October 2020.] https://de.wikipedia.org/wiki/Instrumentenlandesystem#ILS_in_Deutschland

[30] ICAO. Doc 10019, Manual on Remotely Piloted Aircraft Systems (RPAS). International Civil Aviation Organization, Montreal, First Edition, 2015.

https://aci.aero/data-centre/annual-traffic-data/aircraft-movements/2017-aircraft-movements-annual-traffic-data/

https://aci.aero/data-centre/annual-traffic-data/aircraft-movements/2017-aircraft-movements-annual-traffic-data/


97

[31] RPAS C2 link Required Communication Performance (C2 link RCP) concept. Joint Authorities for Rulemaking of Unmanned Systems, October 2014.

[32] ICAO. Remotely Piloted Aircraft System (RPAS) Concept Of Operations (CONOPS) For International IFR Operations. International Civil Aviation Organization, 2011.

[33] N. Hosseini, H. Jamal, et.al, "UAV Command and Control, Navigation and Surveillance: A Review of Potential 5G and Satellite Systems," 2019 IEEE Aerospace Conference, Big Sky, MT, USA, 2019.

[34] I. Kabashkin, “Analysing of the Voice Communication Channels for Ground Segment of Air Traffic Management System Based on Embedded Cloud Technology”, ICIST 2016.

[35] H. Jung, W. C. Moon, “RPAS Integration in Non segregated Airspace within Comparison between Radar Vectoring and Trajectory Based Operation Using a Real Time ATC Simulation”, 2016 ATRS World Conference.

[36] E. Filippone, V. Di Vito, G. Torrano, et.al., “RPAS – ATM Integration Demonstration – Real-Time Simulation Results”, IASS 2015, November 2015 Miami, Florida, USA.

[37] ICAO, Annex 6 Operation of Aircraft

[38] ICAO, Annex 10 Volume I Radio Navigation Aids

[39] European GNSS Agency, GNSS Market Report, Issue 4, 2015

[40] RTCA-DO-229D, Minimum Operational Performance Standards for Global Positioning System/Wide Area Augmentation System Airborne Equipment, December 13 2006, SC-159

[41] RTCA-DO-246E, GNSS-based Precision Approach Local Area Augmentation System Signal-in-Space Interface Control Document (ICD), July 13 2017, SC-159

[42] RTCA-DO-253D, Minimum Operational Performance Standards for GPS Local Area Augmentation System Airborne Equipment, July 13 2017, SC-159

[43] USA DoD, Global Positioning System Precise Positioning Service Performance Standard, 1st Edition February 2007

[44] Luca Garbarino, Vittorio Di Vito, Ettore De Lellis, Carmine Marrone, Federico Corraro, A SENSOR ARCHITECTURE FOR HIGH PRECISION UAS NAVIGATION IN THE FUTURE GNSS FRAMEWORK

[45] Kaminer, I., Yakimenko, O., Dobrokhodov, V., and Jones, K., “Rapid Flight Test Prototyping System and the Fleet of UAV’s and MAVs at the Naval Postgraduate School,” AIAA-2004-6491, AIAA, 3rd “Unmanned Unlimited”Conference, Chicago IL, 2004,

[46] Johnson, E., Schrage, D., Prasad, J., and Vachtsevanos, G., “UAV Flight Test Programs at Georgia Tech,” AIAA-2004-6492, 3rd “Unmanned Unlimited”Conference, Chicago IL, 2004.

[47] Di Vito V; Corraro F.; Garbarino L.; De Lellis E.;Marrone C., "A SENSOR ARCHITECTURE FOR HIGH PRECISION UAS NAVIGATION IN THE FUTURE GNSS FRAMEWORK, Journal Coordinates Magazine, 2009


98

[48] Contractor report prepared for NASA Unmanned Aircraft Systems in the National Airspace System Project “Human Factors Guidelines for Remotely Piloted Aircraft System Remote Pilot Stations”, July 2016.

[49] Nullmeyer, R., & Montijo, G. (2009). Training interventions to reduce air force predator mishaps. Proceedings of the 15th International Symposium on Aviation Psychology, Dayton, OH.

[50] Williams, K.W. (2004). A summary of unmanned aircraft accident/incident data: Human Factors implications. Technical Report No. DOT/FAA/AM-04/24. Washington, DC: U.S. Department of Transportation, Federal Aviation Administration, Office of Aerospace Medicine.

[51] International Civil Aviation Organization (2002). Line Operations Safety Audit (LOSA). Doc 9803, AN/761. Montreal: Author

[52] Hobbs, A. and Herwitz, S. (2008). Maintenance challenges for small unmanned aircraft systems: An introductory handbook. Available at http://human-factors.arc.nasa.gov/

[53] Williams, K. W. (2006). Human factors implications of unmanned aircraft accidents: Flight control problems. In N. J Cooke, H. L. Pringle, H. K. Pedersen, & O. Connor (Eds.), Human factors of remotely operated vehicles (pp. 105–116). San Diego: Elsevier.

[54] Tvaryanas, A. P. (2006). Human factors considerations in migration of unmanned aircraft system (UAS) operator control (USAF Performance Enhancement Research Division Report No. HSW-PE-BR-TE-2006 – 0002). Brooks City, TX: United States Air Force.

[55] Waraich,Q. Mazzuchi, T. Sarkani, S. & Rico, D. (2013). Minimizing human factors mishaps in unmanned aircraft systems. Ergonomics in Design, 21, 1, 25-32.

[56] Hobbs, A. (2010). Unmanned aircraft systems. In E. Salas & D. Maurino (Eds.). Human factors in aviation (2 ed.). (pp. 505-531). San Diego: Elsevier.

[57] Kamienski, J. & Semanek, J. (2015). ATC perspectives of UAS integration in controlled airspace. 6th International Conference on Applied Human Factors and Ergonomics (AHFE 2015) and the Affiliated Conferences, AHFE 2015. McLean: Elsevier.

[58] Mutuel, L.H., Wargo, C. A. & DiFelici, J. (2015, March). Functional decomposition of unmanned aircraft systems (UAS) for CNS capabilities in NAS integration. IEEE Aerospace Conference, Big Sky, MT.

[59] ICAO, Annex 6 Operation of Aircraft

[60] ICAO, Annex 10 Volume I Radio Navigation Aids

[61] European GNSS Agency, GNSS Market Report, Issue 4, 2015

[62] RTCA-DO-229D, Minimum Operational Performance Standards for Global Positioning System/Wide Area Augmentation System Airborne Equipment, December 13 2006, SC-159

[63] RTCA-DO-246E, GNSS-based Precision Approach Local Area Augmentation System Signal-in-Space Interface Control Document (ICD), July 13 2017, SC-159

http://human-factors.arc.nasa.gov/


99

[64] RTCA-DO-253D, Minimum Operational Performance Standards for GPS Local Area Augmentation System Airborne Equipment, July 13 2017, SC-159

[65] USA DoD, Global Positioning System Precise Positioning Service Performance Standard, 1st Edition February 2007

[66] Luca Garbarino, Vittorio Di Vito, Ettore De Lellis, Carmine Marrone, Federico Corraro, A SENSOR ARCHITECTURE FOR HIGH PRECISION UAS NAVIGATION IN THE FUTURE GNSS FRAMEWORK

[67] Kaminer, I., Yakimenko, O., Dobrokhodov, V., and Jones, K., “Rapid Flight Test Prototyping System and the Fleet of UAV’s and MAVs at the Naval Postgraduate School,” AIAA-2004-6491, AIAA, 3rd “Unmanned Unlimited”Conference, Chicago IL, 2004,

[68] Johnson, E., Schrage, D., Prasad, J., and Vachtsevanos, G., “UAV Flight Test Programs at Georgia Tech,” AIAA-2004-6492, 3rd “Unmanned Unlimited”Conference, Chicago IL, 2004.

[69] Di Vito V; Corraro F.; Garbarino L.; De Lellis E.;Marrone C., "A SENSOR ARCHITECTURE FOR HIGH PRECISION UAS NAVIGATION IN THE FUTURE GNSS FRAMEWORK, Journal Coordinates Magazine, 2009

[70] M. Consiglio, J. Chamberlain, C. Munoz, and K. Hoffler, “Concept of integration for UAS operations in the NAS”, 28th Congress of the International Council of the Aeronautical Sciences (ICAS 2012), Brisbane, Australia, September 2012.

[71] https://www.unmannedairspace.info/utm-industry-leader-interview/connecting-atm-utm-presents-technical-regulatory-cultural-conflicts-leslie-cary-icao/ - November 2018. Leslie Cary is Chief, Remotely Piloted Aircraft Systems (RPAS) Section at the International Civil Aviation Organization.

[72] International Civil Aviation Organization Unmanned Aircraft System Traffic Management (UTM)Request for Information - https://www.icao.int/safety/UA/Documents/RFI%20-%202020.pdf. Due to COVID-19, the RFI has been extended until 25 Sept 2020.

[73] https://www.eurocontrol.int/sites/default/files/publication/files/uas-atm-integration-operational-concept-v1.0-release%2020181128.pdf.

[74] https://www.eurocontrol.int/project/concept-operations-european-utm-systems.

[75] SESAR Joint Undertaking: U-space Blueprint https://www.sesarju.eu/sites/default/files/documents/reports/Uspace%20Blueprint%20brochure%20final.PDF.

[76] Federal Aviation Administration, “Integration of civil unmanned aircraft systems (UAS) in the National Airspace system (NAS) roadmap”, 2nd edition, July 2018.

[77] European Commmision, “Framing the future of aviation”, Riga Declaration on RPAS, Riga, 2015.

[78] SESAR Joint Undertaking, “Demonstrating RPAS integration in the European aviation system”, Bruxelles, 2016.

https://www.unmannedairspace.info/utm-industry-leader-interview/connecting-atm-utm-presents-technical-regulatory-cultural-conflicts-leslie-cary-icao/

https://www.unmannedairspace.info/utm-industry-leader-interview/connecting-atm-utm-presents-technical-regulatory-cultural-conflicts-leslie-cary-icao/

https://www.icao.int/safety/UA/Documents/RFI%20-%202020.pdf

https://www.icao.int/safety/UA/Documents/RFI%20-%202020.pdf

https://www.eurocontrol.int/sites/default/files/publication/files/uas-atm-integration-operational-concept-v1.0-release%2020181128.pdf

https://www.eurocontrol.int/sites/default/files/publication/files/uas-atm-integration-operational-concept-v1.0-release%2020181128.pdf

https://www.eurocontrol.int/project/concept-operations-european-utm-systems

https://www.sesarju.eu/sites/default/files/documents/reports/Uspace%25

https://www.sesarju.eu/sites/default/files/documents/reports/Uspace%25


100

[79] JARUS, “Design objectives for RPAS detect and avoid”, JAR-DELWG4-08-D2, edition 1 (for internal JARUS consultation), April 2016.

[80] E. Filippone, F. Corraro, M. Ducci, and F. Tomasello, “Perspectives and ATM impact of detect and avoid integration in tactical and MALE RPAS”, RPAS Policy, Regulatory and Innovation Forum (UVSI), Bruxelles, 2017.

[81] G. Corraro et alii, "Real-Time HW and Human-in-the-Loop Simulations for the Validation of Detect and Avoid Advanced Functionalities in ATM Future Scenarios", AIAA DASC 2020

[82] RTCA/DO-365, “Minimum operational performance standard (MOPS), for detect and avoid (DAA) systems”, May, 2017.

[83] RTCA/DO-365A, “Minimum operational performance standard (MOPS), for detect and avoid (DAA) systems”, March, 2020.

[84] Sagar Kc, Devin P. Jack, "Terminal Area Size and Switching Technique Analysis for Unmanned Aircraft Systems Operations", AIAA DASC 2020

[85] Sagar Kc, Devin P. Jack, "Alert Timing Assessment for Unmanned Aircraft System Terminal Area Operations", AIAA DASC 2020

[86] TERMS OF REFERENCE RTCA Special Committee 228 Minimum Performance Standards for Unmanned Aircraft Systems, Rev 10, RTCA Paper No. 163-20/PMC-2034, June 2020

[87] A. Rønningstad. 2019. Swarm airports. Optimizing the airport selection in a drone swarm system. Master Thesis

[88] J. A. Pérez-Castán, F. Gómez, A. Rodríguez-Sanz, R. M. Arnaldo and J. F. Alonso-Alarcón. 2020. Safe RPAS integration in non-segregated airspace. Aircraft Engineering and Aerospace Technology, vol.92, no. 6.

[89] Gardi, A., S., Ramasamy, R. Sabatini and T. Kistan. 2016. CNS+A capabilities for the integration of unmanned aircraft in controlled airspace. 2016 International Conference on Unmanned Aircraft Systems (ICUAS), Arlington, VA, pp. 779-788, doi: 10.1109/ICUAS.2016.7502670.

[90] ICAO. (1999). Doc 9694 Manual Of Air Traffic Services Data Link Applications. First Edition.

[91] R. R. Cordón, F. J. Sáez, and C. Cuerno. 2014. RPAS integration in non-segregated airspace: The SESAR approach. System interfaces needed for integration. 4th SESAR Innovation Days. Technical University of Madrid, Spain.

[92] T. Arribas, S. Sánchez and M. Gómez. 2015. Optimal Control of Dynamic Systems using a New Adjoining Cell Mapping Method with Reinforcement Learning. Control and Cybernetics Journal, vol.44, no.3.

[93] Guili Xu, Xin Chen, Biao Wang, Kaiyu Li, Jingdong Wang and Xu Wei. 2011. A search strategy of UAV’s automatic landing on ship in all weathe. International Conference on Electrical and Control Engineering (ICECE).

[94] Department of Defense. 2017. Department of Defense Announces Successful Micro-Drone Demonstration. Press release number NR-008-17. https://www.defense.gov/News/News-

https://www.defense.gov/News/News-Releases/News-Release-View/Article/1044811/department-of-defense-announces-successful-micro-drone-demonstration


101

Releases/News-Release-View/Article/1044811/department-of-defense-announces-successful-micro-drone-demonstration

[95] P. Scharre. 2014. Robotics on the Battlefield Part II. The coming Swarm. Center for a New American Security.

[96] I. Lachow. 2017. The upside and downside of swarming drones. Bulletin of the Atomic Scientists.

[97] Gardi, A., Ramasamy, S., Kistan, T., & Sabatini, R. 2010. UAS in the Terminal Area: Challenges and Opportunities. Encyclopedia of Aerospace Engineering John Wiley & Sons, Ltd.

[98] Vu Influence Of UAS Pilot Communication And Execution Delay On Controller’s Acceptability Ratings Of UAS-ATC Interactions (2013).

[99] Shively, and Vu Unmanned Aircraft System Response to Air Traffic Control Clearances: Measured Response (2013).

[100] EUROCAE ED-283 MASPS for RPAS ATOL system, 2020

[101] F.Pinchetti, J. Stephan, A. Joos, W. Fichter, “FlySmart - Automatic Take-Off and Landing of an EASA CS-23 Aircraft”, Deutscher Luft- und Raumfahrtkongress 2016.

[102] T. Rogalski, D. Nowak, et.al., “Control System for Aircraft Take-off and Landing Based on Modified PID controllers, CMES’18, Kazimierz Dolny, Poland, November 2018.

[103] E. De Lellis, V. Di Vito, C. Marrone, et.al., “Flight Testing of a Fully Adaptive Algorithm for Autonomous Fixed Wing Aircrafts Landing”, Infotech@Aerospace, June 2012, Garden Grove, California.

[104] N. Genito, E. De Lellis, V. De Vito, et.al., “Autonomous Take Off System: Development and Experimental Validation”, CEAS Conference, October 2011).

[105] J. Vezinet, A. C. Escher, A. Guillet, C. Macabiau, “State of the art of image-aided navigation techniques for aircraft approach and landing”, ON ITM 2013, International Technical Meeting of The Institute of Navigation, Jan 2013, San Diego.

[106] https://www.airbus.com/newsroom/press-releases/en/2020/06/airbus-concludes-attol-with-fully-autonomous-flight-tests.html.

[107] https://www.ga-asi.com/ga-asi-demonstrates-automatic-takeoff-and-landing-enhancements.

[108] V. Di Vito, E. De Lellis, N. Genito, et.al., “UAV Free Path Safe DGPS/AHRS Autolanding: algorithm and flight tests”, Unmanned Aircraft Systems 2008, International Technical Conference and Exhibition, 10-12 June 2008 – Paris, France.

[109] A. Gardi, R. Sabatini, “Descent 4D Trajectory Optimisation for Curved GNSS Approaches”, International Conference on Unmanned Aircraft Systems (ICUAS), Miami, 2017.



https://www.airbus.com/newsroom/press-releases/en/2020/06/airbus-concludes-attol-with-fully-autonomous-flight-tests.html

https://www.airbus.com/newsroom/press-releases/en/2020/06/airbus-concludes-attol-with-fully-autonomous-flight-tests.html

https://www.ga-asi.com/ga-asi-demonstrates-automatic-takeoff-and-landing-enhancements

https://www.ga-asi.com/ga-asi-demonstrates-automatic-takeoff-and-landing-enhancements


102

[110] A. Gardi, R. Sabatini, S. Ramasamy, T. Kistan, “Real-time UAS Guidance for Continuous Curved GNSS Approaches”, Journal of Intelligent and Robotic Systems, Vol. 93, Issue 1, pp. 151-162. 2019.

[111] O. Torres, J. Ramirez, et.al., “Synthetic Vision for Remotely Piloted Aircraft in Non-Segregated Airspace”, 30th DASC, October 2011.

[112] G. L. Calhoun, M. H. Draper, et. al., “Synthetic vision system for improving unmanned aerial vehicle operator situation awareness”.

[113] J. Tadema, J. Koeners, E. Theunissen,” Synthetic Vision to Augment Sensor Based Vision for Remotely Piloted Vehicles”, SPIE, Enhanced and Synthetic Vision 2006.

[114] J. Tadema, E. Theunissen, “using synthetic vision technology and automation to provide UAV operator support”, Infotech@Aerospace 2011 2011, St. Louis, Missouri.

[115] Roadmap for the integration of civil Remotely-Piloted Aircraft Systems into the European Aviation System - Final report from the European RPAS Steering Group, June 2013.

[116] Federal Aviation Administration, Unmanned Aircraft System (UAS) Controlled Airspace Aviation Rulemaking Committee Charter, May 2019.

[117] RTCA Paper No. 168-20/PMC-2035, Terms of Reference SC-119, Navigation Equipment Using the Global Navigation Satellite System, June 11, 2020.

[118] Skybrary Aviation Safety. “Autonomous Operations Basics”. https://www.skybrary.aero/index.php/Autonomous_Operations_Basics.

[119] EUROCAE ED-271 Minimum Aviation System Performance Standard for Detect and Avoid (Traffic) in Class A-C airspaces under IFR, 2020

[120] EUROCAE ED-258 - Operational Services and Environment Description (OSED) for Detect & Avoid [Traffic] in Class D-G airspaces under VFR/IFR, 2019.

[121] U-Space Concept Operation - SESAR Joint Undertaking. https://www.sesarju.eu/sites/default/files/documents/u-space/CORUS%20ConOps%20vol2.pdf.

[122] EUROCAE, ER-0004 Volume 1, General Considerations for Civilian Operation of Unmanned Aircraft, Nov.2010.

[123] EUROCONTROL CORUS Concept of operations for European UTM systems, Oct. 2019.

https://www.skybrary.aero/index.php/Autonomous_Operations_Basics

https://www.sesarju.eu/sites/default/files/documents/u-space/CORUS%20ConOps%20vol2.pdf

https://www.sesarju.eu/sites/default/files/documents/u-space/CORUS%20ConOps%20vol2.pdf


103

Appendix A

A.1 Glossary of terms ATS surveillance system. A generic term meaning variously, ADS-B, PSR, SSR or any comparable ground-based system that enables the identification of aircraft.

Automatic dependent surveillance — broadcast (ADS-B). A means by which aircraft, aerodrome vehicles and other objects can automatically transmit and/or receive data such as identification, position and additional data, as appropriate, in a broadcast mode via a data link.

Beyond visual line-of-sight (BVLOS) operation. An operation in which the remote pilot or RPA observer does not use visual reference to the remotely piloted aircraft in the conduct of flight

Command and control (C2) link. The data link between the remotely piloted aircraft and the remote pilot station for the purpose of managing flight.

Detect and avoid (DAA). The capability to see, sense, or detect conflicting traffic or other hazards and take appropriate action.

Drone. Synonym for UAS. Any aircraft and related systems without a pilot on board, either remotely piloted or autonomous.

Ground Control Station (GCS). Ground station (software/hardware) assisting the remote pilot in piloting the RPA.

Handover. The act of passing the control of an operation from ne human operator to another. The handover could be executed between Air Traffic Control Officers (e.g. in the control transfer from one sector to another, or from ACC to APP controllers). Namely for RPAS operations, the handover refers to passing piloting control from one remote pilot station to another.

Precision Approach. A precision approach is an instrument approach and landing using precision lateral and vertical guidance with minima as determined by the category of operation, namely CAT I, CAT II, CAT III operations, each related to progressively reducing decision minima.

Remotely Piloted Aircraft (RPA). The airborne segment of an RPAS.

Remotely Piloted Aircraft System (RPAS). The combination of RPA, RPS, and C2 data link. Subset of UAS.

Remote pilot station (RPS). The component of the remote pilot aircraft system containing the equipment used to pilot the remotely piloted aircraft.

Segregated airspace. Airspace of specified dimensions allocated for exclusive use to a specific user(s).

Terminal Manoeuvring Area (TMA). Controlled airspace around an airport.

Unmanned Aircraft System (UAS). Any aircraft and related systems without a pilot on board, either remotely piloted or autonomous.


104

Visual line-of-sight (VLOS) operation. An operation in which the remote pilot or RPA observer maintains direct unaided visual contact with the remotely piloted aircraft

A.2 List of Acronyms

Acronym Definition

ACC Area Control Centre

ADS-B Automatic Dependent Surveillance - Broadcast

ADS-C Automatic dependent surveillance - Contract

A-FUA Advanced – Flexible Use of Airspace

AHRS Attitude and Heading Reference System

AMC Acceptable Means of Compliance

ANSP Air Navigation Service Provider

APR Approach

ASBU Aviation System Block Upgrade

ASR Air Surveillance Radar

ATC Air Traffic Control

ATCO Air Traffic Control Officer

ATM Air Traffic Management

ATOL Automatic Take-Off and Landing

BRLOS Beyond Radio Line-of-Sight

BVLOS Beyond Visual Line-of-Sight

C2 Command and Control

CAA Civil Aviation Authority

CDM Collaborative Decision Making

CNPC Control and Non Payload Communications

CLS Calculated Level of Safety

CNS Communication, Navigation and Surveillance

CNPC Control and Non-Payload Communication

CPDLC Controller Pilot Data Link Communications

CONOPS Concept of Operations

DAA Detect and Avoid

DGPS Differential Global Positioning System

DMA Dynamic mobile area

DTA DAA Terminal Area


105

DWC DAA Well Clear

FIS Flight information service

FMS Flight management system

GA General Aviation

GAST GBAS Approach Service Type

GAT General Air Traffic

GBAS Ground Based Augmentation System

GCS Ground Control Station

GDPR General Data Protection Regulation

GLS GBAS Landing System

GNSS Global Navigation Satellite System

GPS Global Positioning System

HIL Human-in-the-Loop

HMI Human Machine Interface

ICL Initial Climb

IFF Identification Friend or Foe

IFR Instrument Flight Rules

ILS Instrument Landing System

LPV Localizer Performance with Vertical guidance

MALE Medium altitude long endurance

MAS Managed Airspace

MOPS Minimum Operational Performance Specifications

MUST Multi UAV Simulated Testbed

NAA National Aviation Authority

NOP Network Operations Plan

NPA Notice of Proposed Amendment

OAT Operational Air Traffic

OSED Operational Services and Environment Definitions

PA Precision Approach

PAR Precision Approach Radar

PIC Pilot in Command

PPS Precise Positioning System

PSR Primary Surveillance Radar

RAIM Receiver Autonomous Integrity Monitoring


106

RLOS Radio Line of Sight

RNAV Area navigation

RP Remote Pilot

RPA Remotely Piloted Aircraft

RPAS Remotely Piloted Aircraft System

RPS Remote Pilot Station

RTS Real Time Simulation

RWC Remain Well Clear

SARP Standard And Recommended Practice

SATCOM Satellite Communication

SBAS Satellite Based Augmentation System

SCB Stakeholder Consultation Body

SERA Standardised European Rules of the Air

SID Standard Instrument Departure

SiS Signal in Space

SMR Surface Movement Radars

SPR Safety Performance Requirements

SPS Standard Positioning Service

SSR Secondary Surveillance Radar

STAR Standard Arrival Route

SVS Synthetic Vision System

SWaP Size, Weight and Power

TCAS Traffic Collision Avoidance System

TIS Traffic Information System

TLS Target Level of Safety

TMA Terminal Manoeuvring Area

TRL Technology Readiness Level

TSA (Static) temporary restricted area

TWR Tower

UAM Urban Air Mobility

UAS Unmanned Aircraft System

UHF Ultra High Frequency

USP U-Space/UTM Service Provider

UTM Unmanned Traffic Management


107

V&V Verification & Validation

V1 Take-off Decision Speed for Multi Engine Aircraft

VFR Visual Flight Rules

VHF Very high frequency

VLL/VHL Very Low Level/Very High Level

VLOS Visual Line-of-Sight

VR Rotation Speed

VTOL Vertical Take-Off and Landing

WAGE Wide Area GPS Enhancements


108

INVIRCAT Current State-of-the-Art and regulatory basis

Documents

Transcript of INVIRCAT Current State-of-the-Art and regulatory basis