PHARE Advanced Tools (PATs)

1. PHARE Advanced Tools (PATs) by I. Wilson, PATs Project Leader EUROCONTROL

2. Introduction • Overview of Advanced Tools • Technical concepts of the tool-set • Very brief description of each tool • Tools used in the PHARE Demonstrations • Then I will discuss some of the issues raised and lessons learnt

3. PHARE Advanced Tools (PATs) • Arrival manager AM (DLR then NATS) • Conflict probe CP (NLR) • Cooperative tools CT (CENA) • Departure manager DM (CENA) • Flight path monitor FPM (NLR) • Negotiation manager NM (NATS) • Problem solver HIPS (EEC) • Tactical load smoother TLS (EEC) • Trajectory predictor TP (DERA then NATS)

4. Tools Concept • The aircraft defines its most efficient trajectory • The ground systems apply constraints for deconfliction and sequencing. • The trajectory used by the ground system shall wherever possible be the trajectory generated by the aircraft Flight Management System. • Trajectories shall be generated taking into account constraints for the entire flight. • Planner controllers take deconfliction actions as far ahead as possible • Sector - Sector transfer of control is automated and ‘silent’

5. Tools Technical Concept • Tools are not standalone • Tools provide services to each other • In the PHARE CMS Architecture ‘Server’ tools provide information to ‘client’ tools using ‘events’ alerting the client tool to the information • One event such as a new trajectory can cause a cascade of events through the system

6. Trajectory Predictor (TP) • Primary tool in the system • Based on EFMS trajectory predictor • Generates trajectory for modelling by tools and controller • Trajectory generated using aircraft state data, performance data and route and profile constraints • Possibly too accurate.

7. Conflict Probe (CP) • Activates every time there is a new trajectory • Compares active trajectories • Compares ‘alternate trajectories’ with active trajectories • Reports conflicts-found and conflict-cleared to the other tools • Uses ‘geometric’, ‘nominal path’ and ‘probabilistic’ detection algorithms

8. Negotiation Manager (NM) • Manages trajectory negotiation • Sends constraint list to aircraft when negotiation requested by other tools • Checks downlinked aircraft trajectory • Up-links accept after controller agreement if necessary • Activates down-linked trajectory and trajectories of non-datalink aircraft • Initiates and manages inter controller co-ordination • Must allow multiple users (multi-threaded)

9. Departure Manager (DM) • On receipt of the initial trajectory sequences traffic for runways. This involves: • Using the CFMU slots and other requests for departures set a departure rate (passed to a ‘runway sequence object’) • Choosing the most optimal sequence based on least delays and best runway utilisation and no conflicts on the SIDs • Imposing push-back time and Scheduled Time of Departure based on sequence and taxi time from gate to runway • Accepts controller input for runway, sequencing or STD changes

10. Arrival Manager (AM) • On receipt of the initial trajectory sequences traffic for runways. This involves: • Using the controller set ‘base flow rate’ (this could come from Departure Manager and ‘runway sequence object’) • Choosing the most optimal sequence based on least delays and best runway utilisation • Imposing gate time constraint for Scheduled Time of Arrival. • Accepts controller input for runway, sequencing or STA changes • Identifies holding aircraft and creates appropriate Stack Constraints for safe separation

11. Co-operative Tools (CT) • Purpose to provide an ‘automated controller assistant’ • Think like a controller • Filter PROSITs which include problems as well as conflicts • Provide a simple Look-ahead function • Provide an agenda function • Allow close co-operation between PC and TC

12. Problem Solver (PS) • Purpose to provide interactive graphical capability to solve conflicts in all dimensions • Highly interactive closely coupled to HMI • Concept issues • Trajectories were edited on screen but ‘constraints’ were passed to Trajectory Predictor • Trajectory being edited for 10 minutes in future was overlaid over current radar picture with potential for temporal confusion

13. Flight Path Monitor (FPM) • Checks each radar position report against the 4D trajectory for that flight • Reports deviation from trajectories in all dimensions to other tools and controllers • Accepts designation of ‘significant points’ from controllers and tools and signals when each point is passed

14. Tactical Load Smoother (TLS) • Purpose to identify heightened levels of ‘complexity’ or workload ahead of time • Allow Multi-Sector Planner to reduce forecast sector workload to within capability • Produced a ‘coefficient of complexity’ • Essential tool in an exception management environment

15. Tools Hierarchy Cooperative Tools Tactical Load Smoother Arrival Manager Departure Manager Problem Solver Negotiation Manager Flight Path Monitor Conflict Probe Trajectory Predictor

16. Tools in PD/1 Problem Solver Flight Path Monitor Conflict Probe Trajectory Predictor

17. Tools in PD/2 Arrival Manager Deconflictor Negotiation Manager Flight Path Monitor Conflict Probe Trajectory Predictor

18. Tools in PD/2+ Arrival Manager Problem Solver Negotiation Manager Flight Path Monitor Conflict Probe Trajectory Predictor

19. Tools in PD/3 CENA Cooperative Tools Departure Manager Problem Solver Negotiation Manager Flight Path Monitor Conflict Probe Trajectory Predictor

20. Tools PD/3 EEC Cooperative Tools Tactical Load Smoother Arrival Manager Departure Manager Problem Solver Negotiation Manager Flight Path Monitor Conflict Probe Trajectory Predictor

21. Tools PD/3 NLR Arrival Manager Problem Solver Stack Manager Negotiation Manager Flight Path Monitor Conflict Probe Trajectory Predictor

22. Conceptual Issues (1) • Systems Analysis and Design rule: “Automate the FUNCTION not the Procedure” • In ATM procedure is an overused term - for a controller a procedure is made up of a set of tasks • SIDs, STARs and Airways are also procedures • Should these controller and airspace procedures be automated? • The function required is to provide safe, orderly, economic and expeditious ATM with sufficient capacity • Automate the required functions not the existing procedures designed for the manual function

23. Conceptual Issues (2) • Letters of Agreement - Standing Agreements - Standard Levels etc. Used to avoid ‘surprising’ the adjeacent controller. Not required when there is access to a trajectory. • Controller Roles - all partners thought they had the same PC/TC concept, but they did not • Temporal Splits in Layered Planning affects what was ‘team approach’ to problem solving • ‘Operational Gap’ of PD/3 due to temporal split

24. Conceptual Issues (3) • What is a conflict ?- the ‘snitch patch’ mentalitycollision avoidance vs separation maintenance what are the separation standards for ? • Trajectory prediction ‘errors’ and guidance ‘errors’ and uncertainties • Every constraint on a flight has a cost for both ground and air

25. Architecture • Architecture exports its ‘world-view’ to the Applications • Legacy systems based on ‘Servers’ tend to be less scalable, and unsuited to ‘intelligent’ controller workstations automated tools • Real Object Oriented Design based systems are better suited to the distributed intelligence. • Performance and scalability requirements should be given a higher priority in choice of architectures

26. Performance Issues • Tool Performance in most cases was not a problem. BUT • Trajectory Predictor was too slow (possibly too accurate) • Arrival Management re-sequencing had to be limited • Without exception, ALL simulations and demonstrations had performance problems. • Architectures suited to systems without automated support will almost certainly not be capable of the performance required with the implementation of automated tools • Operational system implementers of distributed intelligent systems MUST learn from this issue

27. Automation Issues • Automated tools can only reduce controller workload if the controller lets them do some of the work. • Controllers who do not let the tools do some of the work have more work than without the tools • Restrictive or prescriptive automation - unwelcome • Permissive or assisting automation - welcome • Not De-skilling - Re-skilling - automated tools are more powerful and require careful and correct use. Misuse can have rapid and wide impact

28. System Trust • Legal liability is an issue that is a concern - but controllers will still feel responsible for any incidents • Trust on 3 levels • Is the System Really right ? • Will the System fail ? • What do I do when it fails or goes wrong ?

29. Is the System Really right? • System behaviour unlike a controller’s undermines trust • Intermittent performance undermines trust • Lack of ‘picture’ information undermines trust • Mismatching conflict detection destroys trust

30. Will the System fail ? • Experience with personal computers and monolithic legacy systems -Computer crashes regular occurrence • Well designed distributed systems should not experience such total failures • With layered planning - conflicts are cleared well ahead of current time - more stability and time to recover from minor failures.

31. What do I do when it fails? • The assumption must be that any system will fail • Future research will need to identify the acceptable loading of an ATM System that relies on automated support to raise capacity above that of an unsupported controller

32. Areas for Research • Better linking of algorithms at conceptual level especially trajectory generation and conflict detection • More efficient operational System architectures - not just use of ‘buzz-words’ • Data-link and Trajectory Negotiation • Controller techniques for use of automated tools • Metrics for exception management systems • REAL LIVE TRIALS - lack of trust in simulations - there is nothing more convincing or testing than a live flight trial of an advanced system

33. Summary • The tools defined in 1989- 1992 made a complete tool-set, nobody has identified a missing tool • The tools all worked although they showed the mismatching concepts of the partners • Architecture has a profound affect - it exports its view of the function to the applications • Advanced systems have to be trustworthy to become trusted.

34. PHARE Advanced Tools (PATs) by I. Wilson, PATs Project Leader EUROCONTROL next