9th March 2016

RPAS ATM INTEGRATION CONCEPTTHE ERAINT PROJECT

ICARUS RESEARCH GROUPTECHNICAL UNIVERSITY OF CATALONIA (UPC)

WORLD ATM CONGRESS 2016

Project Overview and Strategy

• Goal of the ERAINT project:– Investigate the practical implications/limitations of a

RPAS operating under an IFR-ATM environment, and the benefits that technology and automation could bring to both the pilot and the ATC.

• Strategy:– Reproduce in real-time / fast-time simulation, RPAS

operational scenarios as close as possible to a foreseen non-segregated airspace.

• Development:– Three iterations: integration & separation / contingencies

/ dynamic RPAS mission management.

2

Project Methodology

Project Methodology:• Reproduce RPAS operations in real-time, under laboratory

conditions:– Airspace structure, traffic, available systems, comm latency, etc.– Define experimental CoOps for the RPAS insertion.– Analyze ATC subjective workload and taskload (CAPAN - ISA) under

various scenarios.

• Analyze the same scenarios with fast time tools (NEST):– Compare and confirm consistency of workload/taskload results.

• Project focuses on:– Unrestricted access to all airspace, full non-segregated operation.– Reproduce the whole RPAS mission process: from design, to

negotiation and approval, real-time operation and evaluation.– Separation, contingencies, comm latency, lost-link, ATC workload and

impact on airspace efficiency.– NOT ON: collision avoidance, airport operations, VFR.

3

Project Development

Spiral development:• Step-A: Integration and en-route

separation management with open instructions and mission-oriented active RPAS operation (12 months).

• Step-B: Contingency management withautomatic/autonomous operation by theRPAS (engine failure, lost-link) with RPAS-ATC negotiation of routes (12 months).

• Step-C: Strategies to access non-segregated controlled airspace executing highly dynamic missions including reference trajectory changes during execution(6 months).

4

Infrastructure and evaluation strategyReal-time simulation infrastructure:• RPAS, RPAS-GC, C3-datalink, eDEP ATC and pseudo-pilots.

5

Infrastructure and evaluation strategyMultiple vehicles available:• MQ-9, RQ-4A, Sierra, Sky-Y, Heron-HF, Penguin-B, A320-UF

6

Infrastructure and evaluation strategyExtensible environment:• Two ATC / pseudo-pilot, RPAS (as necessary), voice infrastructure.

7

ERAINT Integration Objectives

1. Confirm that the level of realism of the RPAS-ATC evaluation environment is significant and confirm its usability for the whole ERAINT project.

2. Confirm the feasibility of mission-oriented fully non-segregated RPAS operation of both MALE and HALE vehicles.

3. Evaluate how the ATC workload is impacted by the RPAS insertion.

4. Evaluate the feasibility of the separation provision when RPAS operate fully non-segregated with IFR traffic.

5. Evaluate if the inferior RPAS performance has negative impact on the separation provision.

6. Evaluate if data-link technology employed by the RPAS (ADS-B and ADS-C EPP) may help to facilitate the integration or even the separation provision.

8

RPAS MALE Surveillance Mission

9

RPAS HALE Volcano Mission

10

RPAS HALE Volcano Mission

11

RPAS MALE SAR Mission

12

• Shipping traffic in the Baltic Sea area.

RPAS MALE SAR Mission

13

• RPAS proceeds from nominal mission area to SAR area requesting trajectory change during execution.

ERAINT Execution ResultsStep-A/B/C total number of simulations and flight time per scenario.

14

Scenario Simulations RPAS Time(min)

Simulation Time(min)

Step‐A VP101 4 40 235Step‐A VP102 Run1 9 284 586Step‐A VP102 Run2 24 781 1345Step‐B VP201/202 Run1 23 557 897Step‐B VP201/202 Run2 29 786 1664Step‐C VP301 11 347 756Total (min) 100 2795 5483Total (hr) 46.6 91.4

ERAINT Execution ResultsTaskload evaluation through CAPAN, and Workload evaluation through ISA. RPAS impact is separated from other vehicles. Periods within active sectors are also indicated.

15

Integration ConclusionsViability of the Mission Operation• The development of the RPAS operations individually managed is

viable and resulting into limited ATC workload impact whenimplemented under a reasonable concept of operation (mission,altitude and turn requests).

• Further investigation is required to identify in which areasintegration should start, being TMA at the far end.

RPAS may have priority most times• RPAS performance impacts the way ATC manage separation, most

times giving RPAS priority.• Track extension before turns or track cancellations are the most

common situations in which RPAS got diverted during surveillance.

16

Integration Conclusions

ATC Tools and Intent exploitation:• ATC don’t have the tools to manage the surveillance areas

requested by the RPAS.• Flight intent could be used as a way to provide ATC with the

information required to understand the RPAS objectives.• RPAS operative and requested intent: variable detail• Could be effectively implemented through ADS-C EPP message

17

Integration ConclusionsIntent does not reduce workload but reduces uncertainty:• Workload increase remained similar when exploiting RPAS intent, but

ATC expressed an increased confidence on the RPAS operation.

Flight Object could be used to share RPAS-related state/trajectory information:• RPAS mission operation and contingency response introduce more

complex air-ground trajectory synchronization issues.

Separation management is not the issue:• ATC can effectively and safely manage the RPAS separation. Workload

increases, but may be acceptable.• Other factors identified seen as more problematic:

– Flight efficiency: determine the level of delays induced to other trafficthat may be acceptable.

– Characterize the ATC workload and taskload: when managingRPAS may need to be characterized if operations become extensive.

18

ERAINT Contingency Objectives

1. General RPAS management capabilities by the ATC; i.e. is the ATC able to properly manage the contingency without risking the RPAS recovery?

2. Contingency pre-planning should facilitate awareness and acceptance by the ATC.

3. Validate that the RPAS suffering a contingency can be kept free of separation conflicts at all times.

4. Validate that the RPAS contingency can be performed in a satisfactory way.

5. Validate that contingency management can be improved if both the RPAS and the ATC cooperate through data link systems.

19

RPAS Operator InterfacesInterfaces for automatic/autonomous respond:

20

Pre‐selection among pre‐planned trajectories.

Autonomous response after deadline: lost‐link but others also.

Manual selection among pre‐planned trajectories.

RPAS Pre-planning Examples

Engine failure & lost-link execution during departure as seen through data-link.

21

Contingency ConclusionsViability of the Contingency Operation• The development of contingency RPAS operations individually

managed is viable and resulting into limited ATC workload impactwhen implemented under a reasonable concept of operation.

• Further investigation is required to evaluate coupled or chainedcontingencies, especially those related to the loss of the commandand control link.

RPAS Flight Intent Availability• Flight intent has demonstrated as a key mechanism to improve the

understanding of the ATC with respect the way the RPAS will respondto the flight contingency.

RPAS Contingency Conops• The proposed experimental contingency response concept of

operation is considered to be sound to cope with non-coupled non-chained contingencies.

• Further investigation is necessary to cover those additional aspects ofthe contingency response.

22

Contingency ConclusionsRPAS 4D Trajectory Prediction• Flight trajectory predictors and the supporting performance models are

necessary to allow all ATM actors maintain a consistent view of theRPAS performance behaviour and peculiarities.

– BADA3 / BADA4 performance modelling

– Out of the standard envelope modelling for RPASpeculiarities and contingency support

– Created BADA3 models for MQ-9 and RQ-4A in cooperationwith EEC, but not satisfied with some modes (e.g. cruise climb,gliding).

– Support for STCA / MTCD / Ground Trajectory Prediction.

Both RQ-4A and MQ-9 BADA3 models implemented and made available in collaboration with EEC.

All simulation trajectories will be made publicly available after project close-out.

23

Hotspot detection

Jellyfish Observation

Radioactivity measurements

Thank you for your attention

27