ATC Human Factors Involved in RPAS Contingency Management in Non-Segregated Airspace

Abstract

Objectives: The overall approach towards Remotely Piloted Aerial System integration into a non-segregated airspace is that the unmanned vehicles should be able to fit into the current air traffic management system, thus meeting all the technical and regulatory requirements to be treated similar to any other airspace user. Such a requirement implies that unmanned aircraft operations should behave as close as possible to manned aviation or at least generate the most negligible possible negative impact on the system. From the air traffic management point of view, this implies that air traffic controllers should be capable of effectively handling different types of RPAS operating in a nominal state but also when suffering a potential contingency. This paper aims to analyse how air traffic controllers involved in managing unmanned aircraft integration into non-segregated airspace are impacted when an unmanned vehicle suffers a contingency. Participants: Six air traffic controllers were the test subjects, complemented by one RPAS pilot and several pseudo-pilots controlling the simulated manned traffic. The project collected real-time simulation data to develop specific indicators to determine how the controllers’ workload increases while managing complex traffic scenarios, including a single RPAS. Study Method: We conducted exhaustive traffic flight simulations, recreating complex airspace scenarios, including various RPAS types and mission-oriented trajectories. The involved RPAS were subjected to two of the most relevant contingencies: loss of the command-and-control link and engine failure. The experiments were evaluated in different operational scenarios, including using autonomous communication technologies to help air traffic controllers track the RPAS operation. Findings: The results indicate that the air traffic controller’s perception and workload are not affected beyond reason by the introduction of an unmanned aircraft as a new element into the non-segregated airspace, even when that aircraft suffers a contingency. The flight-intent technology increases situational awareness, leading to more efficient and safe airspace management. Additional simulations may need to be performed to evaluate the impact on airspace capacity, safety, and workload when various unmanned vehicles are simultaneously inserted.

1. Introduction

Remotely Piloted Aerial Systems (RPASs) refer to aircraft systems that operate without a human pilot on board. The whole RPAS includes not only the aircraft but also the supporting ground control station and the communication infrastructure. The introduction of RPASs as a new element in the current air traffic control environment requires exploring novel ways to improve the RPAS pilot situational awareness, sensory awareness, and simplicity of operation through the intelligent use of automation and advanced human–machine interfaces (HMI). In addition to the RPAS pilot, human factors associated with air traffic controllers managing the airspace are also affected by a potential increase in the workload and the need to adapt to the new type of interaction.

RPAS pilot-in-command (PiC) and Air Traffic Controller (ATCO) performance have been studied at various psychological, behavioural, and physical levels [1,2]. Additionally, some researchers have evaluated human factor system interfaces from RPASs and compared them with approaches traditionally used to evaluate manned air vehicles, such as [3,4], where the authors identify differences between manned aircrafts and RPASs focusing on the fact that the pilot in command is physically remote from the aircraft. Furthermore, ongoing research investigates whether a simulated, unexpected, and manned flight event can be startling and explores differences in human responses between expected and unexpected manned flight events [5]. In [6], the authors evaluate the differences in separation management in airspaces classes from D to G and the role of Air Traffic Control (ATC) in maintaining safety, while in [7] a similar study was conducted for RPAS flying in TMA. Both used human-in-the-loop simulations and assessed the human performance of ATCO. However, there is still a lack of research on human factor approaches to integrate unmanned and manned flights in non-segregated controlled airspace safely.

This study hypothesises that allowing an RPAS to operate into non-segregated airspace does not excessively increase the ATCO workload in surveillance-oriented operations, particularly in the case of unexpected RPAS contingencies. It is also assumed that at the initial phase of the RPAS introduction, the number of simultaneous RPAS in an airspace sector would be limited to a single vehicle (defined as the maximum RPAS capacity of a sector). It is therefore argued that if the workload increase remains within the capacity of the ATCO, a single RPAS insertion would be safe and the ATCO should be capable of managing the nominal RPAS mission operation but also a potential contingency. Thereafter, the rest of the manned traffic operating in the same sector must remain safe.

It is well understood that managing any aircraft contingency using an ATCO would imply an increased workload. Moreover, depending on the complexity of the contingency, it may even occur that such an ATCO could be relieved from the duty of controlling other aircrafts to focus on the contingency aircraft entirely. Other ATCOs managing adjacent sectors or just some support ATCOs may assume that role for the contingency duration. This analysis is expected to prove that the ATCO workload increase would remain reasonable; therefore, RPAS contingencies can be safely managed.

To validate our hypothesis, a set of complex operational scenarios has been created and evaluated in an extensive collection of real-time exercises. Active duty ATCOs have been tasked with managing realistic sets of manned traffic intermixed with a mission-oriented RPAS that may eventually suffer a contingency.

Additional technology may improve the sharing of information between the RPAS and ATCO, thus increasing the overall situational awareness of both the ATCO and the RPAS pilot. Automatic Dependent Surveillance (ADS) technologies are surveillance technologies for tracking aircrafts and improving situational awareness. They are automatic because aircraft-related surveillance data are sent to the ATC controller without any action by the pilot. ADS technologies are dependent because, in contrast with other surveillance sensors such as radar, the surveillance data are obtained from the onboard sensors. Two different approaches have been designed: ADS-Broadcast (ADS-B) and ADS-Contract (ADS-C). Among others, ADS-C can provide the aircraft-projected intent, a set of 4-dimensional points describing the aircraft’s predicted flight trajectory. The flight-intent mechanism seems to be the perfect way for the RPAS to inform the ATC controller about its whereabouts. The flight intent can even support the lost-link contingency, as the lost-link per se does not imply the failure of the onboard FMS or ADS-C equipment.

This research combines different subjective and objective performance ratings to accurately measure the ATCO workload impact when managing contingencies potentially supported by information exchange systems. Under the umbrella of the Evaluation of the RPAS-ATM Interaction in Non-Segregated Airspace project (ERAINT) [8], we created flight trajectories, missions, interfaces, and flight operations to measure the ATC human factor impact in an environment where RPASs operate while intermixed with other manned aircrafts within a realistic air traffic management simulation environment.

The ATCO performance and the evaluation of unreasonable workload increases have been performed in two steps. First, RPAS operations were inserted in a high-density non-segregated airspace. Once it was observed that the workload levels did not rise beyond unreasonable levels, a second iteration expanded the complexity of the scenarios by evaluating the workload increases in the case of RPAS contingencies. A contingency is any situation in which an aircraft suffers an unexpected situation affecting the normal development of the flight. In extreme cases, a contingency may develop into an emergency declaration by the pilots, which grants them special priority status and the full attention of the ATC system.

This paper reports the analysis strategy and results achieved when evaluating the ATCO workload increases while managing RPAS contingencies. In order to perform our evaluation, we identified several relevant human factors that may affect the ATCO workload when an RPAS flies across the ATC sector within nominal conditions but also when the RPAS is in an emergency state. Among all the possible situations, two relevant contingencies have been selected as the most representative: (a) loss of the command-and-control link and (b) failure of the RPAS engine as a case of urgent flight termination.

The paper is structured as follows: Section 1 briefly shows the main human factor evaluation methods used in the aviation domain and details the specific human factor concerns in current RPAS operations, including two different kinds of RPAS contingencies. Section 3 outlines the simulation setup, information flows, human–machine interfaces involved in the actuation of the system, and general RPAS operational scenarios. The section will also detail the experiments that were carried out and the involved procedures to measure the ATCO task load and workload. Section 4 features the results. Finally, Section 5 discusses the attained experimental results.

2. Method

2.1. Human Factor Evaluation Methods in the Aviation Domain

Analysing the human factors in the air traffic environment helps to distribute tasks optimally and to perform a better estimation of sector capacity, as well as to identify safety-critical tasks, possible sources of error and failure, and the cognitive demands from human–computer interactions.

Four main broad techniques are involved in the human factor evaluations [9]: (a) Subjective assessments require the subject to assess his/her own state through questionnaire-based feedback such as rating scales or structured interviews. (b) Task-based metrics that measure the subject’s performance. Within task-based measures, there are accuracy metrics (absolute error, root-mean-square error, error rate, percentage error, deviations, false alarm rate, etc.), time-related metrics (detection time, reaction time, time to complete, glance duration, etc.), and behavioural measures (activity logging, mouse movements, etc.). (c) Analytical techniques that predict or diagnose specific aspects of human factors, typically related to human reliability and human cognition, through models developed from a combination of theoretical/expert knowledge, as well as empirical data. Some methodologies employing task analysis techniques that are applied to aviation are used to diagnose the causes of human error in aircraft accidents and incident investigation. (d) Psycho-physiological measures employ sensors for collecting the subject’s physiological data, which are then translated into measures of workload using analytical models. A continuous stream of data collection can be used across a broad range of tasks. Psyco-physiological techniques do not require active input from human operators; however, some current sensors that need to be worn by operators are intrusive and require the development of noise-filtering algorithms. In addition, it is necessary to calibrate the system and extensive validation is required through statistical techniques.

Table 1. Human factor rating scales in the aviation domain.

Rating Scale	Kind of Evaluation	Evaluation Area
NASA Task Load Index [10]	Subjective assessments	Workload
Instantaneous Self-assessment [11]	Subjective assessments	Workload
Cognitive Architecture for Safety Critical Task Simulation (CASCaS) [12]	Analytical techniques	Advanced flight interfaces
Air-Man-Machine Integration Design and Analysis System (Air-MIDAS) [13]	Analytical techniques	ATC handoff tasks and ATM free flight concept
Modified Bedford [14]	Subjective assessments	Flight handling qualities
Modified Cooper-Harper [15]	Subjective assessments	Flight handling qualities
Subjective Workload Assessment Technique (SWAT) [16]	Subjective assessments	Workload
Situational Awareness Rating Technique (SART) [17]	Subjective assessments	Situational awareness
Situational Awareness Subjective Workload Dominance (SA-SWORD) [17]	Subjective assessments	Situational awareness
Situational Awareness Supervisory Rating Form [17]	Subjective assessments	Situational awareness
Adaptive Control of Thought-Rational (ACT-R) [18]	Cognitive architectures	ATC human–machine interactions
Situation Awareness Global Assessment Technique (SAGAT) [19]	Task-based metrics	Situational awareness of pilots and ATM operators
Situation Present Assessment Method (SPAM) [19]	Task-based metrics	Situation awareness in air traffic control tasks
Capacity analysis methodology (CAPAN) [20]	Task-based metrics	ATC workload and sector capacity

shows different human factor rating scales in the aviation domain.

2.2. Human Factor Concerns in RPAS Operations

Working with any kind of autonomous system would face various human-factor related challenges. Comparing manned aircrafts with autonomous unmanned systems, the RPAS exhibits unconventional flight characteristics: they fly at lower cruise speeds and have limited climb and descent performance, but, at the same time, are capable of flying at higher altitudes and for more extended periods. Furthermore, unmanned aircrafts are primarily employed on surveillance missions, such as security monitoring, search and rescue, etc., generally involving mission-oriented flight plans, including extensive scanning and loitering, rather than the typical point-to-point trajectories employed in commercial aviation. This specific type of trajectory requires new considerations for wake vortex, separation, and visual/radar detection, as well as an improvement in the prediction of trajectories (e.g., flight-intent technology proposed in [8]). Due to such flight characteristics, RPAS management and operation may also induce an increased workload for their remote pilots and air traffic controllers.

The extensive duration of RPA operations causes it to be difficult for pilots to maintain vigilance due to the inactivity associated with the low task load and lack of interaction with the system for long periods of the mission. On the other hand, when the workload increases, operators are required to allocate their attention among multiple tasks effectively. Generally, automation tends to shift operators from autonomous controllers of work activities to the passive monitors of technologies. Such tasks may elicit passive fatigue in operators, implying a risk of task disengagement that may be exacerbated by fatigue. This is relevant not only for the RPA piloting but also for its interaction with air traffic controllers.

Figure 1 depicts the Yerkes-Dodson Law, where performance varies with arousal. Performance quality is expected to decline when arousal is too high or too low and tunnel vision is symptomatic of attention narrowing. Conversely, moderate workload levels over prolonged periods can prompt operators to learn to adapt and adjust.

In some circumstances, high-workload RPAS missions may produce active fatigue, which may induce a more significant state of distress in operators. Although RPAS operation may be exempt from some of the major stressors afflicting traditional pilots, such as fear of physical injury, it may be more psychologically intense and fatiguing. In [22], the authors propose a set of human factor guidelines to avoid RPAS operator fatigue.

We identify a set of RPAS flight characteristics that may affect ATCO and pilot’s performances when an RPAS is operating in non-segregated airspace:

(a)

Dissimilar RPAS flight performance and mission trajectory. ATCO expects certain aircraft performance levels in the airspace system in order to orchestrate traffic safely, efficiently, and under an acceptable workload. Although the training of ATCO prepares them to safely manage aircrafts that cannot meet the expected performance due to emergencies, RPAS may be especially disruptive due to their highly dissimilar performance characteristics. Besides this, RPAS may require increased controller monitoring, with necessary clearance amendments issued to move manned traffic around it (increasing fuel burn) or to decelerate traffic (leading to delays) [23]. In addition, compared to typical point-to-point operations, an increase in mission-oriented flight trajectories may also increase the controllers’ workload.

(b)

Loss of natural sensing. Without a rich set of sensory cues related to RPAS, operations may decrease the situational awareness of the PiC. For example, RPAS pilots cannot accept instructions from air traffic controllers to acquire and separate from other aircrafts visually. ATCO requires positive acknowledgement that one pilot has the other aircraft in sight. These visual operations are beneficial to the controller in high-workload situations. ATCO should manage the airspace, including some RPAS missions, in a comparable way to situations where the flight of a conventional aircraft proceeds under instrumental meteorological conditions.

(c)

Human-machine interface issues. Air traffic controllers need to use the proper HMI interfaces to access specific flight data about the traffic they monitor and control and RPAS may introduce further information requirements. Using those new interfaces must prevent the ATCO from becoming confused about the automation’s current and future status (i.e., operating mode), thus avoiding incorrect interactions. For example, controllers may have access to information such as aircraft identification, aircraft type, and specific on-board equipment for manned aircrafts. However, it is still unclear what additional information controllers would require properly supervising RPAS operations properly; flight-intent technology may be a mechanism that could increase ATCO situational awareness. However, at the same time, such new interfaces may increase the ATCO workload by requiring the operation of a new source of information. From an opposite perspective, early standardisation discussions emphasised transparency so that controllers would not necessarily know if an aircraft is manned or unmanned. However, it may seem obvious that there are unique aspects to RPAS operations and that controllers may need to be aware of those RPAS-specific characteristics to maintain safety, efficiency, and an acceptable workload level.

(d)

Communication issues. Ineffective communication and other communication-related factors are the underlying causes of most ATCO workload increases. In a controlled airspace, communication between PiC and ATCO may occur through the relay of traditional very-high-frequency radio transmitted through the unmanned vehicle. However, such a relay may introduce significant latencies, especially if implemented via satellite links that may be sufficient to disrupt verbal communication. Besides this, there are common mistakes in radio use associated with operational factors, such as using the wrong phraseology or the incorrect understanding of the required commands.

2.3. Nominal RPAS Conditions and Contingencies into Non-Segregated Airspace

The International Civil Aviation Organization (ICAO) establishes that RPASs need to demonstrate an Equivalent Level of Safety (ELOS) to that of manned aircrafts, operate in compliance with existing aviation regulations, and appear transparent to other airspace users. In order to fulfil the ICAO requirements, it is necessary to define the flight plans properly for RPAS missions by specifying the RPAS behaviour along the whole nominal route (see Section 4.1), including the case of contingency and emergency events (see Section 4.2 and Section 4.3) to be the most predictable and compliant with the expected requirements for Instrumental Flight Rules (IFR).

2.3.1. Nominal and Contingency Flight Plans

An RPAS mission process starts by defining the target mission, the RPAS airframe, and the flight scenario. Next, it is necessary to define the services and types of payload (communication, computation, sensors, batteries, etc.) to accomplish the mission. The payload must be organised in the airframe, services assigned to computation payload modules, and an operational flight plan defined.

As part of the ERAINT project, we developed a software architecture that supports reproducing the whole RPAS operational process. The system includes a flight plan manager service framework that processes the RPAS flight plan as a collection of mission stages (take-off, landing, en-route, arrival, taxi, and approach), with each stage as a sequence of legs (portions of flights plans) and translates them into waypoints. The sequence of waypoints involved in all the stages of the RPAS mission defines the whole nominal route that the RPAS onboard autopilot should fly.

However, at any point in the mission execution, an unexpected event may occur. We call contingencies the unforeseen events that may place the RPAS operation at risk. To mitigate the effect of unexpected RPAS behaviour, we introduce contingency management functions into RPAS, which means providing the onboard flight management system with the ability to handle alternatives that mitigate safety risks. The nominal flight plan incorporates additional alternative routes and landing sites to support the response to potential emergencies.

Once an RPAS is in flight, its operation should be continuously monitored to check whether its behaviour is maintained within a nominal status; otherwise, an emergency alternative may need to be executed. Contingency flight plans are partial plans that aim to provide alternative flight trajectories when an emergency occurs. Given that an emergency may occur at any point within a mission, several contingency flight plans may be necessary and each one may require initiation at different points of space, also called initial legs. The selected leg to initiate a contingency plan would be the one best suited to the current RPAS location and, depending on the type of contingency; there is a set of predefined reactions, going from partial cancellation of the mission to complete cancellation of the flight.

2.3.2. Loss of the Command-and-Control Link Contingency

One of the main characteristics of an RPAS is that the aerial vehicle is remotely controlled by a communication system based on the C2-Link. If there is a failure in the communication link, then there is a lack of ability to transmit guidance to the RPAS and receive feedback regarding the state of the vehicle and its location. Eventually, the link may be regained after some time or become a total loss if the failure remains for the rest of the flight.

Given that the C2-Link is independent of the other communication links, voice communication may still be relayed through the RPAS or ground infrastructure and ATC may still be able to see the mode-S or other transponder information from the RPAS. Those datalinks may remain fully operative as they depend on a separate infrastructure; rather, they operate on a broadcast configuration (ADS-B) or point-to-point through an alternative ground/satellite infrastructure (ADS-C). The failure of the ADS-B/ADS-C infrastructure would reduce the surveillance of the RPAS to basic radar surveillance (PSR/SSR) and render the pilot blind concerning the RPAS’s whereabouts.

In the event of a total loss of the C2-Link, the RPAS flight management system should still be able to detect that contingency and revert the vehicle’s operation into a fully autonomous mode. Such contingency trajectories should be anticipated to ensure the safety of all airspace users. The loss of C2-Links may not necessarily imply a degradation of the RPAS airworthiness, but such a state implies an immediate declaration of an emergency.

From an ATC perspective, either the loss of the C2-Link or the loss of the remote pilot to the ATC link is managed in an equivalent way. In both cases, the lack of ability to transmit clearances to the RPAS and receive appropriate feedback about the state of the flight is considered equivalent to a case of a total loss of communications in a manned aircraft. As a result, the command-and-control link loss would be treated accordingly, with a procedure based on ICAO Annex 10 “Loss of communications procedure” [23].

Under these circumstances, completing the full RPAS flight plan, including the mission segment, may be in doubt, but the initially planned landing site must remain the primary objective. The ICAO procedures for loss of radio should be strictly maintained. Full flight plan completion is assumed in airliner operations. However, in the specific case of RPAS operations, it becomes a big discussion point whether the targeted mission should be cancelled earlier, especially considering that some missions for high-performance RPAS platforms may last more than 24 h.

When considering the mission cancellation and return routes, it should be noted that a certain margin of time is advisable before the RPAS performs any actual action. The RPAS pilot should use this buffer time to try to regain the C2-Link and the ATC to make the proper traffic arrangements to absorb the impact of the new situation. Hence, an RPAS under loss link should maintain the last assigned speed and level for a minimum of a few minutes before initiating any further manoeuvre.

A final factor to consider is how the RPAS would descend to landing altitude. Again, two alternatives may be employed according to the ATC criteria or other context factors: (1) The RPAS may descend from a predefined top of descend point until the holding position associated with the landing Initial Approach Fix (IAF). The RPAS should wait there for 30 min as prescribed by ICAO procedures and then proceed to land. (2) The RPAS may remain at its last cleared altitude, flying to the selected IAF following the intended flight plan. Once over, the IAF at cruise altitude, the RPAS could continuously descend until the prescribed IAF altitude is reached. If more than 30 min were employed while descending, the landing could be initiated immediately. If not, the RPAS should hold for the remaining time and then initiate the landing procedure. According to the need to pre-plan the RPAS reaction to a potential C2 lost-link situation, three different operational aspects need to be determined:

Airport Selection: The whole area of the RPAS operation includes the selection of a landing area in case the RPAS suffers an emergency contingency. RPAS should use its nominal airport base as a return location where the IAF hold could be employed as a safe location to attempt the re-acquisition of the C2-Link before landing. Alternative airports for early termination of the mission must be used in case the C2 lost-link contingency degenerates into any other contingency that degrades the airworthiness of the RPAS.

Alternative trajectories: Given that a lost command-and-control link does not immediately imply a failure of the FMS system, RPAS should be operated under the assumption that once the contingency happens, the vehicle retains the capability to safely operate autonomously as pre-planned. Following ICAO standard procedures, the lost-link contingency should be considered a basic radio failure. That procedure implies that the initial flight plan must be completed, bringing the RPAS to its intended destination airport. RPAS operations, however, may not entirely fit in that standard scheme due to two factors:

• Mission duration: the RPAS may operate over an area of interest for an extremely long time. In that case, executing an early termination of the mission may be advisable, cancelling that part of the mission. However, that cancellation may require moving directly from the departure or mission part of the operation to the return trajectory.
• Mission extension: the RPAS may execute an extremely extensive mission. Cancelling the mission may require the RPAS to operate thousands of miles in the outbound trajectory and return to the intended destination airport. Under that scenario, it becomes unclear if completing that extensive round trip with the RPAS suffering a communication failure is advisable. Therefore, early mission cancellation would require using pre-established turnaround points that have been adequately coordinated with the ATC authorities.

Table 2. Flight-specific procedures for a C2 lost link or general loss of communications.

The RPAS on-board system must check for further vehicle degradation and redirect the lost-link trajectory to the closest pre-planned airfield to minimize the total RPAS flight time. An ADS-B-equipped aircraft having radio communication failure must set up its transponder and ADS-B into emergency mode (Mode-A Code 7600). An aircraft equipped with other communication systems (including ADS-C) must indicate the loss of air-to-ground communication by all available means. The RPAS operator must carry out all checks to attempt to recover the link (maintaining the last assigned speed and level for a period of 7 min). Lost-link contingency will be confirmed after a 2 min period has elapsed. Then, the RPAS should follow the pre-planned manoeuvre to re-join the originally planned return flight plan route and altitude. Afterwards, the RPAS should proceed to the designated IAF that serves as the destination aerodrome. The RPAS should complete a standard instrument approach procedure and land after 30 min of holding time at the IAF.

describes the operational procedure we define in the case of C2 lost-link contingency [24].

2.3.3. RPAS Engine Failure Contingency

Engine failure is a critical emergency as most RPAS have just a single engine and the electric generator coupled with that engine would leave the RPAS entirely dependent on its internal batteries without any auxiliary power unit available. So, the capability of the RPA to remain airborne would depend on its gliding capacity, the altitude at the time of the failure, and the vehicle’s capacity to remain controllable when operating under battery power. This type of emergency should tackle the closest airport or at least within gliding distance, sometimes requiring off-airport landings or even terminating the flight by controlled grounding, ditching, parachute descent, or other methods. The PiC and ATCO should be in continuous contact in order to achieve a safe gliding and emergency landing without endangering the surrounding traffic.

In case of engine failure contingency, the pre-programmed operational procedure is activated through the following three steps.

(a)

Airport selection: Assuming an engine contingency, the safest line of action is to determine the available landing locations safely accessible within the gliding capabilities of the RPAS. Low-traffic secondary airports/airfields would be a priority, with further alternatives being flat fields, waterways, etc. The PiC may determine if the safest action is to divert to a more distant airfield instead of the nearest airfield, taking into account not only the pre-planned trajectories but also the actual vehicle state, wind direction, weather conditions, etc. Airfields and airports should have preliminary agreements with the ATM authority to specify if the RPAS is accepted in case of emergency conditions. In this sense, airports should be able to manage potential runway accidents and remove the RPAS after a successful landing, crash landing, or failure of taxi capabilities. Some airports may have an alternative area to perform controlled RPAS crashes to avoid damage to people or properties. As a final factor, on each landing site, some waypoints must be assigned to guide the landing procedure, such as the Initial and Final Approach Fix. Figure 2 depicts the emergency airport selected in one of our engine failure contingency experiments. Note that a small portion of the northwest trajectory has no viable coverage; thus, additional contingency landing sites may need to be included.

(b)

Alternative trajectories: In case of RPAS engine failure, any change in the predefined trajectories must consider the area of operation, gliding capabilities, and traffic volume. We assume that the RPAS flight range is limited by its gliding ratio, disregarding other factors such as battery life and limitations in the actuators. The collection of alternative trajectories must provide early and late flight termination alternatives. Early flight termination should be employed in the case of range/performance limitations or any other operational airport or ATCO requirement when the contingency occurs. Late alternates should be available when meteorology or operational restrictions change along the contingency procedure, rendering the initially planned emergency landing location unfeasible. Alternative trajectories should avoid overflying populated zones or highly elevated areas such as mountains. The ATCO must have available alternative routes to achieve predictable behaviour in case of needing to modify the RPAS nominal route at flight time. The new trajectory should minimise interaction with other airports, particularly with the controlled traffic region near the selected landing airfields. In addition, trajectories near the landing site could require extensive descent. Potential external factors, such as wind direction, could become an operation initially deemed feasible into unfeasible.

(c)

RPAS pilot-ATC communication: The RPAS notifies engine failure emergencies through standard radio procedures, declaring the emergency and indicating the targeted airfield and route. During emergency procedures, the RPAS pilot should keep up to date with the ATCO and indicate whether the RPAS would reach the intended airfield or need to divert to a closer alternative aerodrome or a designated termination area. The process should be as much as possible equivalent to those employed by airliners or instrumented flight rules aircraft.

Table 3. Flight-specific procedures for urgent flight termination contingency.

The RPAS pilot must select the intended airport that complies with the requirements to perform a safe landing (weather conditions, feasibility of the approximation, fire protection, and any circumstance at the pilot’s discretion that can affect safety, such as people or ground infrastructures). The pilot-in-command may determine if diverting to a more distant airport instead of the nearest airport is the safest course of action. The safest course of action typically requires the earliest possible descent and landing, but other alternatives may also be feasible given the RPAS gliding capabilities. In case, during the gliding process, the landing cannot be performed, then flight termination must be executed. The RPAS pilots should immediately share an update decision with the ATC controller: call sign, aircraft type (emphasizing that the aircraft is an RPAS), current position, speed, altitude, updated situation, and updated plan. If the engine failure occurs close to an alternative landing site, then it may be necessary to increase the descent rate, or even circle close to the airfield to lose altitude before starting final descent.

shows the operational procedure that we define in the event of failure of the RPAS engine as an urgent flight landing or termination [24].

3. Experiments

Introducing RPAS into non-segregated airspace should occur within the current air traffic control procedures, although new specific procedures or technologies could be necessary to address the potential increase in the ATC workload due to RPAS traffic. Such a foreseen increase in workload would depend on several variables that may affect the ATC RPAS-related tasks, such as the type of RPAS mission, the surrounding traffic complexity, the use of support technologies such as flight intent, if the RPAS is en route to/from the mission area or at the mission area, etc.

This section describes the experiments being carried out as part of the ERAINT Project to evaluate human factors that affect the ATC when an RPAS operates within their sectors of responsibility. The evaluation exclusively focuses on how both main RPAS contingencies, lost link and engine failure, may impact the ATC managing the RPAS operation. The section also details the participants and the data collection tools used to create the simulation environment and all the human-machine interfaces involved in the real-time simulation experiments.

3.1. Pre-Planned RPAS Flight Trial Scenarios

The experiments contemplate six pre-planned flight trial scenarios that use actual sectorization with various levels of traffic density and the RPAS operating within those sectors. The six scenarios are:

Scenario (a). This scenario does not have an RPAS operating in the area of interest. This scenario is our baseline to compare the results of scenarios that include RPAS flights. The DDR2 database provided the traffic samples operating in the intended mission area, which were slightly randomised to avoid exact repetitions.

Scenario (b). Traffic samples are the same as the baseline scenario (a) but with an RPAS operating nominally over the mission area without suffering any contingency. Only transponder and primary ADS-B data are available to the ATC. Voice communications are the primary mode of communication between the RPAS pilot and the ATCO. The communication latency changed according to the distance between the RPAS and its ground segment (LOS/BLOS communication infrastructure).

Scenario (c). The traffic samples and RPAS operating over the mission area as in scenario (b). In this scenario, an RPAS suffers an engine failure that requires immediate recovery procedures to avoid a crash.

Scenario (d). The traffic samples and RPAS operating over the mission area as in scenario (b). In this scenario, an RPAS suffers an engine failure that requires immediate recovery procedures to avoid a crash. The RPAS has flight-intent support and datalink capabilities along with contingency management, allowing it to provide intentions and request alternative trajectories through a datalink infrastructure.

Scenario (e). The traffic samples and RPAS operating over the mission area as in scenario (b). In this scenario, RPAS suffers a C2 communication failure that requires a non-urgent recovery procedure to avoid extensive negative impact on the ATM system. Other systems (flight management system, ADS-B, and transponder) remain operative and flight data are available to the ATC. The RPAS planned trajectory is available to the ATC, including agreed recovery routes (equivalent to the radio loss in manned aviation).

Scenario (f). The traffic samples and RPAS operating over the mission area as in scenario (b). In this scenario, the RPAS suffers a C2 communication failure with the pilot-in-command that requires a non-urgent recovery procedure to avoid an extensive negative impact on the ATM system. The flight management system, ADS-B, and flight-intent capabilities allow the RPAS to provide flight data and intentions and to request an alternative trajectory to the ATC via a datalink infrastructure. The flight intent and/or datalink communication is autonomously generated while the RPAS is in lost link.

Table 4. Communication technologies per scenario.

Scenario ID	Description	Pilot-ATC Communications
Scenario (a)	Baseline. No RPAS operating	Radiotelephone
Scenario (b)	RPAS operating. No contingency. With the support of flight-intent technology	Radiotelephone
Scenario (c)	RPAS operating. Engine failure contingency. Without the support of flight-intent technology	Radiotelephone
Scenario (d)	RPAS operating. Engine failure contingency. Support of flight-intent technology	Radiotelephone/ADS-C datalink
Scenario (e)	RPAS operating. Lost-link contingency. Without the support of flight-intent technology	Radiotelephone
Scenario (f)	RPAS operating. Lost-link contingency. Support of flight-intent technology	Radiotelephone/ADS-C datalink

shows the type of RPAS-ATC communication mechanism available for each of the five scenarios.

3.2. Real-Time Simulation Experiments

Within the ERAINT project, 100 successful simulations were carried out, covering more than 90 h of flight time, of which almost 47 h corresponded to the flight time in which the simulated RPAS was under active control by a human ATC in one of the active sectors selected for the simulation exercise under consideration.

Within the contingency management study, 52 simulations with 42 flight hours were conducted over thirty months distributed among the selected scenarios (a and c–f), which included several missions that contemplated using flight-intent technology and RPAS contingencies.

Table 5. Resume table of the contingency-related RPAS/ATC real-time simulations (Run1).

Scenario	MQ-9					RQ-4					TOTAL
	LECBNW2		LECBNE		Total Time	EDYYHOL		EKDCUC		Total Time	Num	Time [RPAS]	Time [Total]
	Num	Time [RPAS]	Num	Time [RPAS]		Num	Time [RPAS]	Num	Time [RPAS]
a	1	0	1	0	52	2	0	0	0	91	3	0	143
c	2	51	1	9	71	6	140	2	6	261	8	206	332
d	2	66	2	6	79	1	13	1	12	45	3	97	123
e	2	53	2	13	74	3	13	3	45	78	5	124	152
f	2	65	2	26	91	2	8.5	2	30	56	4	130	147
											23	557	897

and

Table 6. Resume table of the contingency-related RPAS/ATC real-time simulations (Run2).

Scenario	MQ-9					RQ-4					TOTAL
	LECBNW2		LECBNE		Total Time	EDYYHOL		EKDCUC		Total Time	Num	Time [RPAS]	Time [Total]
	Num	Time [RPAS]	Num	Time [RPAS]		Num	Time [RPAS]	Num	Time [RPAS]
a	1	0	2	0	121	3	0	3	0	166	4	0	287
c	0	0	0	0	0	0	0	0	0	0	0	0	0
d	5	189	5	19	291	7	158	7	46	376	12	411	667
e	0	0	0	0	0	0	0	0	0	0	0	0	0
f	5	184	5	30	272	8	51	8	104	366	13	369	638
											29	780	1593

show the total number of simulations and the RPAS flight time distribution that we conducted oriented to the evaluation of contingency management. The exercises were conducted in two separate flight campaigns (referred to as Run1 and Run2) carried out a few months apart. The simulation times are reported in minutes, indicating the time in which RPAS is active within each sector and the total simulation time. In addition, the total number of simulations for each scenario is specified, indicating the number of times an ATCO has actively manned each sector.

During the simulations, the predefined contingency events were planned, which triggered the corresponding tasks according to the sector operating and the simulation events specified to occur in each sector. The most common events are: a manned or RPAS flight enters or exits an ATC sector requiring coordination, an aircraft requires climb/descent according to their transition to/from an airport, the separation between aircrafts needs to be maintained by vectoring or altitude changes, an RPAS declares an emergency, etc. Hence, each ATC working position performs several tasks unknown to the controller at the beginning of the simulation.

Additionally, a collection of 37 simulation exercises, covering approximately 18.5 h of flight time, would be employed as a further reference for the baseline scenarios a-b. Those simulations include nominal mission-oriented operations mostly executed with the MQ-9 RPAS.

We also study the use of flight-intent technology. The flight intent is aircraft-derived data describing its imminent future trajectory. Flight intent can be calculated by the FMS (Flight Management System) onboard the aircraft and broadcast through the ADS-B/ADS-C out communication technology. It was proposed by EUROCONTROL [25] to improve the ATC tasks related to conflict detection. Pasaoglu et al. [26] demonstrated that RPAS autopilots could also calculate and share the flight intent to be used as a valuable input to support ground-based collision avoidance systems. Flight-intent functionality is added to our simulation environment because it is expected to reduce the uncertainty of the trajectory prediction in the short term by providing ATC with the most accurate calculation of the following legs to fly [8].

In this research, the group of control is the ATC behaviour in a baseline scenario (where no RPAS is flying within the ATC sector) and the treatment group is the ATC behaviour when there is an RPAS within its sector of responsibility. The scenarios of the Group of Control and the Treatment Group are explained in detail in Section 3.1. Pre-planned RPAS flight trial scenarios. The dependent variable is the ATC workload and the independent variable is the presence or non-presence of the RPAS within the ATC sector (in nominal conditions or under an emergency) with or without intent technology being employed.

3.3. Participants

Two types of ATCO were involved in the project. Three Spanish ATCOs were constantly involved in the simulations and members of the IFACTA ATC organisation and partners of the project were also involved. In addition, three additional sporadic ATCOs participated in some of the experiments, each from a different ATC organisation (Italy, Germany, and Portugal). We also had a pilot-in-command of the RPAS and up to ten additional people who participated in support of the experiments assuming the role of manned aircraft pilots (they were not part of the statistical analysis).

While the RPAS pilot was always the same person (45–55 years old, expert in the operation of the RPAS simulation system), the ATCOs were rotating their duties, most times having in each run two active sectors manned by different ATCO’s every time. All were 30–45-years-old ATCO males with more than ten years of experience but without previous experience interacting with the type of RPAS profile employed in the exercises.

3.4. Data Collection

In order to establish a realistic environment for the RPAS’s insertion into non-segregated airspace, we have defined two realistic scenarios, employing context information such as the airspace description, representative airspace routes, flight plans, traffic volume, and aircraft performance; all of this was extracted from the Eurocontrol DDR2 database [27] for 30 August 2013, which was one of the busiest days of the decade. Two high-performance RPASs have been employed, using realistic aircraft performance data [28,29] and different equipment levels according to the five different evaluation scenarios.

To estimate the workload impact, we employed the NASA-TLX, extended with our own general workload questionnaire (see

Table 7. Contingency analysis general workload questionnaire.

Contingency Analysis—General Workload Questions
Scale: Variable depending on question
Q1. What is your estimate of your overall workload during the last run?
Q2. How great a part did radio and telephone communications play overall during the last run?
Q3. How great a part did the complexity and/or load of the traffic play in your overall workload during the last run?
Q4. How great a part did problems with procedures play in your overall workload during the last run?
Q5. How great a part did problems with the HMI (such as a sticking mouse, slow response times, label overlapping, unclear airspace presentation, etc.) play in your overall workload during the last run?
Q6. Did you feel that the number of system inputs required was:
Q7. Did you feel that the number of R/T transmissions required was:
Q8. Was the amount of monitoring of labels and RPS required:
Q9. Was the amount of coordination required:
Q10. What is your estimate of your overall situation awareness (clear picture of the situation) during the last run?
Q11. What was your level of stress during the last run?
Q12. What was your level of fatigue just after having finished the last run?
Q13. How easy/difficult was it for you to maintain standard separations between aircrafts during the last run?
Q14. How easy/difficult was it for you to sequence the traffic and/or monitor the sequence order and aircraft spacing during the last run? (if applicable)
Q15. How much did the ISA prompt interfere with your controlling activities?
Q16. Do you believe the number of conflicts in the exercise was:
Q17. Was the detection of long-term conflicts:
Q18. Was the detection of short-term conflicts:
Q19. Was the resolution of long-term conflicts:
Q20. Was the resolution of short-term conflicts:
Q21. Did you have the feeling that you were ahead of the traffic, able to predict the evolution of the traffic?
Q22. Did you have the feeling that you were able to plan and organize your work as you wanted?
Q23. Have you been surprised by an event that you were not expecting (such as an aircraft call)?
Q24. Did you have the feeling of starting to focus too much on a single problem and/or area of the sector?
Q25. Did you forget something important (such as transfer an aircraft on time or communicate a change to an adjacent sector)?
Q26. Did you have any difficulty in finding an item of information?
Q27. Were there any instances where you felt you provided instructions later than you should have?
Q28. Were you surprised by an action performed by one of your colleagues that you were not expecting?

) as a post-exercise tool. Each question was considered through the five considered evaluation scenarios (described in Section 3.1) and the two missions on a Likert Scale of 1–5 in questions Q1–Q20 and on a scale from 0 (never) to 6 (always) in questions Q21–Q28. In order to have a broader perspective of the ATCs’ perception in the specific context of having an RPAS in their sectors, we design a set of questionnaires to evaluate different operational aspects that affect the ATC performance, see

Table 8. Contingency analysis: operation questionnaire.

Contingency Analysis—Operation Questionnaire
Scale: Variable depending on question
Q1. Which mechanism has employed the RPAS to communicate the contingency to the ATC controller?
Select more than one if needed (Voice comm, Transponder setting, Datalink, None)
Q2. Was the RPAS pilot able to communicate the contingency to the ATC controller in an accurate way?
Q3. Was the RPAS able to complete the contingency procedure as initially agreed with the ATC?
Q4. Was the RPAS able to successfully manage the contingency employing a non-expected or non-pre planned procedure agreed with the ATC on-the-fly?
Q5. Contingency procedures have been designed and pre-evaluated to be 100% feasible. If they are not properly executed during the contingency needs to be investigate the main cause?
Please specify the cause: (RPAS malfunction, RPAS pilot error, ATC interaction, Other)
Q6. Which mechanism has employed the RPAS to update the development of the contingency procedure to the ATC controller?
Select more than one if needed (Voice comm, Transponder setting, Datalink, Radar track, None)
Q7. Was the RPAS pilot accurately communicating with the ATC updating the RPAS contingency state and responding to the ATC request?
Q8. If a datalink was employed by the RPAS, was the information provided to the ATC accurately updating the RPAS intentions?
Q9. Was the ATC aware of the RPAS capabilities and operational envelops so that they maintained situational awareness with respect the RPAS intentions?
Q10. How important for the proper development of the contingency was the fact that the ATC controller had a full understanding of the RPAS operational envelop and performance?
Q11. Was the ATC accurately communicating with the RPAS pilot and responding to RPAS requests?
Q12. Was the RPAS operation negatively impacted by the interaction with the ATC?
Q13. Was the RPAS accurately flying the predefined contingency trajectory? The level of accuracy depends on the type of contingency, with the requirements for lost link being much stricter than those required for engine failure. Accuracy will be agreed during the pre-briefing.
Q14. Was the RPAS ADS-B/transponder properly indicating its contingency state? The question is employed to keep track of potential malfunctions of that element during the simulations.
Q15. Was the RPAS flight intent properly provided and accurate with the actual trajectory? The question is employed to keep track of potential malfunctions of that element during the simulations.
Q16. Did the flight intent improve the overall situational awareness of the ATC with respect to the RPAS contingency operation and beyond the existing awareness available through the mission pre-planning?
Q17. Was the RPAS impact on the traffic performance excessive; i.e., the surrounding traffic was impacted negatively from their desired trajectories?
Q18. Was the RPAS impact on the ATC workload excessive with respect to the workload induced by similar contingencies in manned aviation?

. Except for those requiring enumerative answers, the rest was rated from 0 to 5, with 0 indicating the non-applicability of the question.

In addition, the Instantaneous Self-Assessment (ISA) mechanism was implemented to capture the immediate subjective ratings of work demands during the operation of ATC [28,29]. Each ATC rated his experienced workload level from one (underused) to five (excessively busy) every two minutes while on duty. The system also recorded the response time to each ISA query. Figure 3 shows the ISA management interface implemented in ERAINT, in which simulation recording events are set up, ATC operators are assigned to each sector, current simulations can be supervised in real-time, and previous simulations can be reviewed. The questioning of the ATC was set to occur every 120 s with an open window to answer for 30 s. The ATC query is performed via mobile devices connected to the ISA service deployed on a private cloud. The interface also allows for recording key events such as aircraft coordination and notifications.

3.5. Systems and Human–machine Interfaces in the ERAINT Project

In the context of manned aviation, a “machine” primarily relates to an aircraft flown by pilots and to work stations used by air traffic controllers. However, the concept of “machine” more broadly encompasses any device that the pilots and controllers are interfacing with, be it a mobile phone, laptop computer, RPAS system, etc.

Interfacing with a machine is mastering the physical interface between the human user and the system and the mental model implemented in the machine’s architecture and logic. If the machine’s design has been well thought out and user-centred, this should mirror the user’s mental model. In order to interface with/supervise an RPAS, the ERAINT project [24] provides a set of HMI and simulation environments such as the ATC traffic interface, the ATC-RPAS pilot communication system, and the command-and-control system of the RPAS, etc.

The simulation environment comprises two main components, the RPAS simulation system and the ATM simulation system. The RPAS simulation architecture includes both the simulation of the RPA air vehicle and its onboard components and the provision of a ground control station for the PiC that supports real-time interactions.

The real-time manned traffic and ATC control within the selected airspace was carried out by the Early Demonstration and Evaluation Platform (eDEP) provided by Eurocontrol [30]. eDEP provides real-time air traffic management simulation tools, air traffic controllers positions, and pseudo-pilot positions per sector with a model of controller behaviour and a replay mechanism to record simulation data.

Airspace sectorization, structure, and historical manned traffic were extracted from the Eurocontrol’s Network Strategic Tool (NEST) [31], which also helps to analyse the traffic density and the sector capacity. NEST is a Eurocontrol stand-alone desktop application that combines dynamic Air Traffic Flow with airspace design and capacity planning analysis functionalities. We implemented changes to the original NEST dataset to model operational traffic and the RPAS in the shared airspace. The traffic was extracted from the planned flights instead of the actual flights to avoid including the actual ATCO interventions in the simulations. Then, we add a random schedule time to avoid participating ATCOs to memorise repeated conflicts.

To analyse the task load, we employed a task-based metric from Eurocontrol called the Capacity Analyser method (CAPAN) [20]. With CAPAN, we evaluated the task load of the operational controllers at the air traffic control by identifying the most relevant events that occur along the operation (sector coordination, separation provision, changes in altitudes and speeds, etc.). Each one of these events has an assigned time duration (statistically known by the day-to-day operation of the ATCO), which, combined with using the CAPAN methodology, provides a measure of the task load of the controller positions for a given actual traffic sample in different ATM scenarios (see in Section 3.1).

The task load should be confronted by the actual ATCO workload estimated by several mechanisms such as TLX, ISA, number of aircraft per controller/scenario/sector, percentage of time a controller spends to handle aircraft, issuing instructions, and receiving read-back/requests from the pilot-in-command (from voice recording), etc.

The interface between the RAISE [8] simulation component and eDEP component is designed to be as realistic as possible. The RPAS exchanges Mode-S and ADS-B Out data with the ATM system. The RPAS can detect the surrounding traffic via ADS-B In positioning flows. The RPAS also has the capability to send flight-intent data directly to the ATM system via a simulated ADS-C link. The flight intent is generated as a short-term prediction of the RPAS trajectory computed by the onboard FMS. The RPAS can exchange its intent with ground control systems through the dedicated C2-Link and to the ATM system via the ADS-C datalink. Figure 4 describes the main subsystems and data flows involved in the real-time simulation framework of the ERAINT project [24].

3.6. Airspace Sectors, RPAS, and Selected Missions

Airspace is divided into volumes called sectors and air traffic controllers are responsible for the safety of flights within their sector. Most times, sectors are single-person managed by an executive controller and equipped with one controller working position. The controllers’ workloads determine the maximum number of flights they can safely handle in their sector within a specified time.

When measuring the ATC controller workload, we must identify when an RPAS is within one of the manned sectors. For that reason, we record a start event (sector entry) and an end event (sector exit) that delimit the time ATC manages the RPAS. Similarly, the events are recorded to measure the start and end of a contingency situation as well as other relevant events associated with manned traffic coordination and the provision of the separation service.

Two high-performance RPAS vehicles were selected to operate during the real-time simulation. A civil-oriented high-altitude long-endurance Global Hawk RQ-4A, under NASA’s livery and configuration, can reach a 65,000 ft ceiling with cruise speeds between 280 and 340 kt. The second vehicle is a medium-altitude long-endurance General Dynamics MQ-9, also under NASA’s livery and configuration, which can reach a 40,000 ft ceiling with cruise speeds between 180 and 240 kt.

We defined two different missions to perform the analysis: a Frontex (EU External Frontier project, now the European Border and Coast Guard) surveillance mission performed by an MQ-9 Reaper and a volcanic ash monitoring mission performed by an RQ-4A Global Hawk. Both missions simulate traffic involving all aircrafts crossing the selected airspace during the RPAS mission period.

• MQ-9 Frontex Surveillance mission: This mission simulates the surveillance of the European Border and Coast Guard Agency for ship detection/identification. The trajectory, shown in Figure 2, has an initial standard airways/fixpoints part from the San Javier airport (LELC) to the selected mission area and a return trajectory through Valencia airport. The mission area is over the Mediterranean Sea close to the Balearic Islands and the surveillance trajectory occurs within a non-segregated airspace but not following standard airways/fixpoints. The simulation area partially intersects sectors LECBNW2-CSX and LECBNE-CS. Both sectors form part of the six sectors of Barcelona FIR: the sector LECBNW2-CSX is in charge of the northern arrivals to the main Balearic airports and the sector LECBNE-CS is in charge of the departures from the same airports. In particular, the RPAS mission consists of a flight from the north to the south of the Balearic Islands.
• RQ-4A Volcano Surveillance mission: The RPAS has a volcanic ash surveillance mission departing from Hamburg Finkenwerder airport (EDHI) up to Iceland and then back to the same original airport, crossing multiple portions of non-segregated airspace over Germany, Denmark, and the North Sea. The surveillance occurs once it is over the Iceland area, but only the departure and arrival portions of the flight (see Figure 5) are considered during the evaluation. The RPAS flight plan of this mission crosses two different regions: Sector EKDKCUC in the southernmost flight information region of Koebenhavn, Denmark, and Sector EDYYHOL in the northernmost region of Hannover, Germany.

As an example of the complete mission description, we detail the contingency plans of the RQ-4A Volcano Surveillance mission. For instance, in case of engine failure, Figure 5 depicts the initial selection of contingency airfields. The diagram shows a 350 NM radius around each airfield, indicating the maximum distance the RQ-4A can glide once at the cruise altitude. Additional airports should be necessary if 100% coverage of the mission route would be required. The selected airfields include:

• EDHI Hamburg Finkenwerder Airport, with two operative runways (Runway 05 and Runway 23) and a dimension of 3183 × 45 m.
• EDXJ Husum Schwesing Airport, with two operative runways (Runway 03 and Runway 21) and a dimension of 1450 × 30 m.
• EKTS Thisted Airport, with two operative runways (Runway 10 and Runway 28) and a dimension of 1600 × 45 m.
• EKEB Esbjerg Airport, with two operative runways (Runway 08 and Runway 26) and a dimension of 2600 × 45 m.
• ENHD Haugesund Karmoy Airport, with two operative runways (Runway 14 and Runway 32) and a dimension of 2120 × 45 m.

4. Results

In this research, the human factors related to the ATC were assessed by data collected by means of (a) TLX post-exercise questionnaire filled in by each controller at the end of each run, (b) our own general workload and operational questionnaires shown in Table 7 and Table 8, (c) ISA assessment responded to during the exercises, (d) CAPAN task load measurements, (e) questions in interviews and debriefings, and (f) employing observations and recorded voice communications collected during the exercises.

4.1. Results of the NASA-TLX and the Significance Test

The average results of the TLX responses are shown in Figure 6 on a scale from 1 to 10 (1 very low and 10 very high). We can observe that the scenarios from (b) to (f) are more demanding than (a), with an increase in mental, physical, and temporal demand. Additionally, a slight decrease in performance from (b) to (f) can be observed. The trends align with the expected results, in which an ATCO would suffer an increase in workload once an RPAS operates in their sector and higher if the RPAS suffers a contingency. Scenarios (d) and (f), with intent, have a higher demand for ATCO than those without intent but also achieve higher performance.

The responses of the NASA-TLX have been used to test our hypothesis about the statistically significant differences between scenarios using the t-test statistic with a p value = 0.05. First, we have analysed scenarios (a) and (b) to check if adding the RPAS affects the ATCO’s workload. The results can be seen in

Table 9. t-test statistical analysis for each of the six TLX categories.

TLX Category	Null Hypothesis	Statistic	p-Value
Mental demand	H0RPAS	−1.911015	0.0637736
	H0contingency	−2.359384	0.02035207
Physical demand	H0RPAS	−0.802929	0.42700899
	H0contingency	−1.931829	0.05632923
Temporal demand	H0RPAS	−1.705852	0.09619784
	H0contingency	−2.466407	0.01542096
Performance	H0RPAS	0.7513499	0.45707032
	H0contingency	2.7804155	0.00652202
Effort	H0RPAS	−1.431552	0.16044591
	H0contingency	−2.613374	0.01039295
Frustration	H0RPAS	−0.218248	0.82840352
	H0contingency	−2.961887	0.00384499

, first row (H0RPAS). Then, a second statistical analysis compares scenario (b) with the rest of the scenarios (c, d, e, and f) to check the effect of contingencies on the ATCO’s workload. The results are shown in Table 9 on the second row (H0contingency).

As a result of the statistical analysis, we can assume that the null hypothesis is true for the H0RPAS. This means that the workload of the ATCOs has no significant difference when introducing one RPAS mission integrated with the air traffic compared with the same traffic without the RPAS.

The second null hypothesis, H0contingency, can be rejected for almost all the TLX categories (shown in red in Table 9). The only exception is the physical demand, which does not show significant differences. Overall, the results show that when an RPAS is introduced in the ATC sector and suffers a contingency (engine or lost-link failures), the mental demand, the temporal demand, the effort, and the frustration show a significant increase and the performance of the ATCOs decreases.

4.2. Results of the Operational and Workload Questionnaires

Additional questions introduced in the workload and operation subjective questionnaires (see Table 7 and Table 8, respectively) should allow us to better perceive the workload increase experienced by the ATC controllers. Figure 7 provides the results associated with the workload questionaries.

Q1 provides similar results as those recorded in the TLX questionnaire, with minor increases between scenarios (a) and (b), with more significant ones between (b) and the rest. Questions Q11 and Q12 reproduce similar results for stress and fatigue, with very low levels and minor increases when managing RPAS contingencies. Q10 indicates a minor reduction in situational awareness when managing RPAS contingencies, while the simple presence of the RPAS does not imply a reduction in awareness.

Questions Q13 and Q14 evaluate the capability of the ATCO to perform some of the required functions: traffic sequencing and separation management. The results show that those functions could be implemented with relative ease, but no correlation is shown between scenarios. The implementation of both functions seems to depend more on the actual flow of traffic than on the scenario.

Questions Q21 and Q22 evaluate the capacity of the ATCO to organise the functions to be performed, stay ahead of potential conflicts, and correctly plan the actions to be performed. In both cases, the ATCO felt they were well ahead of the tasks to be performed, with significant increases when flight intent was used.

Finally, questions Q24 and Q27 address the situations in which the ATCO starts to become overloaded and, thus, it is late in its reactions or becomes too focused on a single task. The results clearly show that such a situation does not occur in any scenario. The ATCO never becomes overloaded or too focused.

Overall, the ATCOs exhibit an increase in workload when managing RPAS contingencies. However, the TLX analysis demonstrates that such an increase is minimum and the workload questionnaire supports that ATCOs can maintain their operational capacities, efficiently implementing the assigned functions with the required performance.

4.3. Results of the Instantaneous Self-Assessment

Table 10. ISA data recording for the MQ-9 contingency simulations.

		Full Simulation				RPAS in Sector
		ISA Workload		Response Time		ISA Workload		Response Time
MQ-9		Avg	Max	Avg	Max	Avg	Max	Avg	Max
Run1	a	1.29	2.00	2.92	17.50
	c	1.66	3.50	4.23	20.29	1.41	3.50	2.02	14.75
	d	1.64	3.00	2.84	13.27	1.48	2.00	2.60	13.27
	e	2.07	3.50	2.89	7.85	2.02	3.50	3.13	5.21
	f	2.29	3.50	2.36	5.11	2.64	3.50	3.04	2.11
Run2	a	1.27	2.50	2.67	11.81
	d	1.98	3.80	2.20	2.00	1.99	3.80	2.20	7.43
	f	2.06	3.60	2.94	13.73	2.15	3.60	3.44	13.73

and

Table 11. ISA data recording for the RQ-4A contingency simulations.

		Full Simulation				RPAS in Sector
		ISA Workload		Response Time		ISA Workload		Response Time
RQ-4		Avg	Max	Avg	Max	Avg	Max	Avg	Max
Run1	a	1.95	3.00	3.30	7.85
	c	2.31	5.00	3.55	11.79	1.61	3.20	1.61	5.72
	d	2.20	3.00	3.17	18.59	2.25	3.00	2.81	8.04
	e	2.06	3.00	4.12	17.53	2.42	2.67	4.05	9.13
	f	2.23	4.00	2.90	10.52	2.41	3.00	2.94	5.18
Run2	a	1.92	2.50	2.46	9.52
	d	1.93	3.00	2.86	9.25	2.25	2.83	3.04	8.76
	f	2.07	2.83	2.85	10.08	2.33	2.83	3.80	8.12

show average and maximum ISA values along the whole contingency simulation period and within the period in which the RPAS was actively controlled by an ATCO (scenarios from (c) to (f)). ISA values corresponding to the baseline scenario (a) can also be observed in those tables, being complemented by previous results for scenarios (a) and (b) depicted in

Table 12. ISA data recording for the MQ-9 nominal simulations.

		Full Simulation				RPAS in Sector
		ISA Workload		Response Time		ISA Workload		Response Time
MQ-9		Avg	Max	Avg	Max	Avg	Max	Avg	Max
Run1	a	2.22	4.00	3.66	17.69
	b	2.36	4.00	2.94	22.76	2.51	3.40	2.77	9.66
Run2	a	1.98	3.00	2.46	9.53
	b	1.73	3.21	2.52	9.38	1.87	3.14	2.57	7.75

. The ISA values represent the ATCO self-assessed workload perception recorded during the simulation. Note that, in addition to the ISA values, the aforementioned tables also report the ATCO reaction time from when it was queried to report the ISA value to the time it responded.

The ISA reported values show that the ATCO controllers worked with normal, low, or very low workload levels. In all cases, the contingency-related scenarios (c)–(f) have acceptable workload levels, with a 2.64 average maximum in scenario (f) and values for the rest of the scenarios between 1.4 and 2.4.

Three factors support the conclusion that the ATCO workload increase while managing RPAS contingencies remains within an acceptable range. First, the average ISA values when the RPAS is in the managed sector show minimal increases over the whole average values (limited to around 0.2–0.3 points). Just in one case, the workload when the RPAS was in the sector was smaller than the average value. Second, the maximum registered ISA values when the RPAS was in the sector were not much larger than the average values and, in some cases, they were even smaller than the maximum values registered for the whole simulation. Finally, if we compare with the baseline values in Table 12, we can observe that the recorded contingency-related ISA values are not significantly larger than those baseline values.

The ISA values in Table 12 also show that for baseline scenario (b) and for the periods in which the RPAS was actively managed, the Run1 average values are larger than the Run2 values. Moreover, those Run1 values are much larger than those later attained in the scenarios from (c) to (f). This ISA decrease is mainly attributed to the familiarisation of the ATCO with the system interfaces and especially to the operational traffic flows employed in the simulation sectors. Note that familiarisation with traffic should not be considered a negative factor; on the contrary, the ATCOs need to train in their assigned sectors to understand the existing traffic flows and become proficient in their management.

A secondary factor to be considered is the ATCO response time, which shows the short average and maximum response times. Even further, the response times recorded for the whole duration of the simulations show longer response times than when the RPAS is suffering a contingency. Even though long response times are not necessarily associated with high-workload situations, observing short response times seem to indicate that the workload levels remain reasonable.

4.4. Results of the Task-Load Impact from RPAS Integration in Non-Segregated Airspace

CAPAN task-load metrics have been employed in the design of the ERIAINT project scenarios, as the task load provides an initial indication of the expected workload to be faced by an ATC when managing nominal operations. Unfortunately, the authors do not know any methods to determine the task load associated with contingency management.

Table 13. CAPAN task load measures associated with the MQ-9 contingency simulations.

		Full Simul.		RPAS in Sector		RPAS Contrib.
Run1		Max. Taskload	Av. Taskload	Max. Taskload	Av. Taskload	Max. Taskload	Av. Taskload
LECBNW2	a	31.00	17.28
	c	41.50	20.99	41.00	28.43	3.50	1.96
	d	38.00	20.69	38.00	28.04	5.00	2.13
	e	33.50	18.65	33.50	26.05	2.00	0.59
	f	45.00	19.96	41.50	22.58	4.50	1.55
LECBNE	a	17.00	5.87
	c	26.00	10.43	21.00	16.17	2.50	1.46
	d	23.00	8.79	9.00	7.67	3.00	1.33
	e	26.50	9.58	26.50	21.70	2.50	1.75
	f	24.00	7.20	24.00	16.29	2.50	1.21
Run2		Max. Taskload	Av. Taskload	Max. Taskload	Av. Taskload	Max. Taskload	Av. Taskload
LECBNW2	a	33.50	14.35	47.00
	d	47.40	19.64	43.00	29.25	5.20	2.48
	f	43.00	19.39	10.67	28.23	5.20	2.55
LECBNE	a	20.00	4.28	21.75
	d	26.20	5.88		9.73	3.33	1.56
	f	20.60	5.07		18.16	3.00	1.58

depicts the CAPAN values calculated for all the contingency scenarios executed during the Run1 and Run2 simulations of the MQ-9 scenario. The CAPAN values indicate the percentage of time during which the ATC would be busy managing some of its assigned tasks. Each row represents the average value of all the executions performed for that particular run and scenario. The maximum task load is determined as the maximum value computed at any instant of the simulations and for any of the exercises in that particular scenario. The average task load is computed throughout the whole simulation and for all the simulations in that scenario. The RPAS contribution to the complexity of the exercise is computed as the difference between the second and the first set of columns.

When comparing the task load values between different scenarios, it is essential to realise that once an ATCO interacts with any manned or unmanned aircraft, its trajectory or timing may be affected to a certain extent, thus potentially changing its future interactions with other vehicles and, therefore, modifying the task load associated with the scenario. Even though the initial base traffic for all the MQ-9 simulations was precisely the same, the randomisation process performed before the execution and the ATCO impact on the traffic generated a noticeable variation in task load values. One of the extreme cases can be observed in Run1, sector LECBNE, scenario d, in which the resulting task load when the RPAS is in the sector was significatively smaller than in the other scenarios.

These variations have undoubtedly impacted the workload perceived by the ATCOs, thus introducing an additional complexity factor when comparing self-assessed TLX or ISA measures. Furthermore, precisely repeating the same traffic set leads to ATC over training; thus, variations in the task load become completely unavoidable from the start. Unfortunately, the authors have not identified any mechanism to compensate the task load variations from the self-assessed workload recorded in the simulations.

Figure 8 shows an example of computed CAPAN task load for sector LECBNE-CSX, coupled with the recorded ISA. This diagram allows for visual inspection of the task load variations through the exercises and how those task load values correlate to ISA recordings. The CAPAN computation provides the total task load and the RPAS contribution once the RPAS enters the sector, displayed as the area shown in dark grey. The CAPAN increase is indicated as the red dotted line over the task load induced by manned traffic.

4.5. RPAS-TC Communication

Communication between ATCO and RPAS is supported via two separate mechanisms: directly via the voice radiotelephony channel and indirectly via the ADS-C datalink exchanging the RPAS flight intent. When employing the radiotelephony channel, the PiC should switch frequencies, as each control centre has a dedicated frequency. On the contrary, the ADS-C datalink operates automatically, sending the flight-intent data stream to the appropriate ATCO control console.

To communicate an emergency state of the RPAS and to update the development of the contingency, the PiC would employ the assigned frequency and should change the employed frequency as it crosses from one sector to another. In case of a lost link, it has been assumed that no further communication between PiC and ATCO can be maintained and only the flight intent may be available to the ATCO.

Figure 9 shows the results of the operative questionnaires. The quality of the PiC-ATCO communications was evaluated throughout the operative questionnaire in Q2 and Q14; the functionality of the flight-intent information was evaluated in Q8.

The results of Q2 indicate that the RPAS pilot can maintain a high-quality communication dialogue with the ATCO in the engine failure contingency scenarios. However, during the lost-link scenario, the efficiency in the communication was reduced, especially in the RQ4 mission, where there was no flight-intent support. In addition, for that particular question, its inconsistency was later uncovered, as some ATCO assumed that it was referring to the quality of communications after the lost link, while others only up until the moment the contingency occurred. Thus, a wide dispersion of results was observed. Q14 provides contradictory results related to the status of the transponder setup. The non-intent scenarios indicate that the transponder identifying the contingency state worked adequately, while intent scenarios provided mediocre ones. Upon consultation, ATCO indicated that they were expecting specific details of the consistency being present (not included at the time), thus producing low ratings.

Q8 indicates that the ATCO perceived the use of datalink to update the RPAS flight intent as a positive tool that provided relevant information. The flight intent was valued in a highly positive way in the MQ-9 evaluation. However, the ratings were reduced in the RQ-4A mission evaluation. After discussion with the participating ATCO, it was identified that the RQ-4A mission involved a return to the origin airport from a high altitude. That return implied a long descent, crossing a wide range of altitudes. The designed flight intent did not provide ATCO with intermediate altitude reference points, which ATCO identified as extremely important to manage the conflicting traffic. Thus, they evaluated the flight intent as a powerful tool that required some level of refinement in its definition.

4.6. Compliance with Contingency Procedures

The collected data during the simulations demonstrate that, most of the time, the RPAS could adequately execute the contingency procedures as initially agreed with the ATC. Q3 indicates that, in most cases, the contingency procedures were carried out as initially planned; they were close to 4 points in all the scenarios. Strangely, the lost-link contingency scenarios incorporating flight intent show more variability than when no intent was available. This could be attributed to the complexity of the scenario (RPAS crossing multiple altitude layers) and the unsatisfied expectation by ATCO (flight intents not providing intermediate altitude references). No such unsatisfied expectancy occurred in the scenarios in which no flight intent was available.

Q13 offers a clear view of the capacity of the RPAS to stick to the predefined contingency trajectories, both in case of a loss of engine or a lost link, with high-rank values close to 5. On the contrary, both Q15 and Q16 indicate that the flight intent was a key factor in managing the contingency for the MQ-9 scenario but not for the RQ-4A scenario. As previously discussed, the RQ-4A scenario highlighted that better altitude prediction information should be attached to the intent information, as this is critical for efficiently managing altitude conflicts between aircrafts.

Q17 provides an alternative vision of the problem, as it can be observed that the absence of flight intent produced a significant perceived impact on the way ATCs managed the traffic flow. In particular, for the MQ-9 mission, the traffic efficiency was impacted when no radio communication nor intent was available. The MQ-9 traversed two highly occupied arrival and departure routes in that particular scenario. Such interference required the ATC to fully reroute all the traffic for safety reasons, as the controllers did not have access to any relevant information about the immediate RPAS intentions. Either voice communication by the PiC or the availability of the flight intent would alleviate that situation, allowing ATCs to perform a more efficient rerouting of the commercial traffic around the RPAS.

5. Discussion

This paper intended to complement the existing research on the human factors associated with the air traffic controller’s performance when managing the insertion of RPAS in a non-segregated airspace. The research specifically addressed the definition of operational concepts and flight-intent technology to support RPAS suffering the most relevant flight contingencies, which are the failure of its engine and the loss of the command-and-control link with its remote pilot.

We have analysed how the ATC workload is affected by introducing an RPAS operating within airspace sectors where traditional manned traffic is also flying. The ATC is responsible for allowing the RPAS operation and managing its potential contingencies while keeping the surrounding traffic safe.

Besides using tools such as the NASA Task Load Index, Instantaneous Self-Assessment, and some aviation performance measurement tools, we have developed questionnaires to subjectively measure the ATC perception of the operational performance and workload variations when the RPAS is being managed.

The results of our extensive real-time simulation campaigns allowed us to determine that: (1) the controller’s workload is not significantly affected by the introduction of the RPAS within its airspace sector; (2) unexpected RPAS contingencies induce reasonable increases in the ATC workload values with respect to the baseline scenarios (no RPAS flying in the ATC sector/RPAS flying in nominal conditions); (3) ATC perceived the increase in workload as manageable, not endangering and only introducing limited efficiency penalties on the surrounding traffic; and (4) ATC perceives the use of the flight-intent technology as an important support tool to improve the safety and efficiency of operations. Furthermore, required improvements in the flight intent were identified, as well that, as in any new tool, it induces some additional workload until users become fully trained in its operation.

Further research is needed to determine the RPAS characteristics that have more impact on the ATC workload and if appropriate human–machine interfaces can help to maintain workload levels into a low-medium threshold. More studies need to be conducted to know if the increasing RPAS vehicles or the increasing number of contingencies could negatively affect the workload and stress of the ATC and other involved humans such as the pilot-in-command.