Development and Evaluation Platform Reference GL/Edep/ADD/1/2.0

Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007

Development and Evaluation Platform

Architecture Design Document

eDEP ARCHITECTURE

Issue: 2.0 Author: Mike Vere Date: 13 Aug 2007 Company: Graffica Ltd

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007

Document Change Log Release Author Date of the Description of the Modifications (sections release release affected and relevant information) 1.1 Rev 6 Mike Vere 21 Jan 2002 Initial version in Configuration Control 1.4 Rev 2 Mike Vere 1.5 Rev 7 Mike Vere 1.5 Rev 7+ Steve Owen Added AMAN 1.6 Rev 4 Mike Vere 1.6 Rev 4+ Darren Smith 20 Feb 2003 1.7 Steve Owen 25 Feb 2003 Updated AMAN 1.8 Mike Vere 10 Mar 2003 PM and PWP update 1.9 Neosys 28 July 2003 Added REC component description 1.10 Neosys 19 Nov 2003 Added Ace/eDEP gateway description 1.11 Graffica (Aynsworth) 1 Dec 2003 Removed code Throughout. fragments. Referenced javadoc. Revised errors. Removed TLS section and event catalog. 1.12 Graffica(Aynsworth) 15 Dec 2003 Improved FM context Section 3.8.2 diagram 1.13 Graffica(Johnson) 23 Jan 2004 Added ACR/BADA Section 3.22 component description 1.14 RTC(Owen) 12 Feb 2004 Updated AMAN, added Sections 3.18, 3.19 EMAN 1.15 Graffica March 2004 Added Meteo component Section 3.24 description. 1.16 Graffica (Aynsworth) 1 March 2004 Added ILS description Section 3.30 1.17 Graffica (Aynsworth) 1st April 2004 Tidied version history. 1.18 Steve Owen 19th Apr 2004 Added SE component 3.25 1.19 Graffica (Cooper) 22nd Feb 2005 Added ADS-B, TIS-B and Section 1, 3.7, 3.15, 3.16, 3.26, ARTAS components. 3.27, 3.28 Updated the glossary and introduction, and the IAS, PM and CWP components. 1.20 Graffica (Owen) 22nd March Updated FM, MTCD, CS, Sections 3.8, 3.9, 3.10, 3.11 2005 TP with SPD additions. 1.21 Graffica (Kirkwood) 4th March Added ACSG component 3.29 2005 1.22 Graffica (Kirkwood) 13th May 2005 Modified IAS and ARTAS 3.7, 3.28 descriptions following ARTAS refactoring. 1.23 Graffica (Kirkwood) 17th June Updated IAS / TISB Sections 3.7.4 and 3.27 2005 descriptions following TrackReport refactoring.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 Document Change Log Release Author Date of the Description of the Modifications (sections release release affected and relevant information) 1.24 Graffica (Owen) 7th Oct 2005 Add datalink events to 3.8, 3.9, 3.12, 3.15, 3.16, 3.17 PWP and CWP. Add Conformance Monitoring and corrected some ADSB issues. 1.25 Graffica (Kirkwood) 4 April 2006 Area Proximity Warnings Section 3.13 in the STCA section. 1.26 Graffica (Moreton) 5 April 2006 Added airspace conflicts. Section 3.11 1.27 Graffica (Humphrey) 6 Dec 2006 Updated REC Section 3.21.1 component description. Replaced AEG Section 3.22 description with reference to AEG DD. 1.28 Graffica (Kirkwood) 10 Apr 2007 Updated ARTAS proxy Section 3.28. component description to include Cat-21 asterix. 1.29 Graffica (Humphrey) 4 May 2007 Added module Section 1. dependency diagram. 1.30 Graffica (Owen) 20 Jul 2007 Added Section 3.31 NetworkComponent. 2.0 Graffica (Thom) 13 Aug 2007 Version number change N/A to common Graffica standard. 2007 Q2 Release. 2.1 Graffica (Owen) 25 Jan 2008 Rewrote Coordination Section 3.9 section.

Acceptance and Reviewing Procedures Name (s) Date of acceptance/ review Date of approval

Document distribution to/cc Name Role

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 Table Of Contents 1 Introduction...... 8 2 Architectural Overview...... 12 2.1 Introduction...... 12 2.2 The eDEP Framework...... 12 2.3 Communication Between Components...... 12 2.4 Component Framework...... 13 2.5 Application Framework...... 14 3 Component Descriptions...... 16 3.1 Overview...... 16 3.2 Discovery Service...... 16 3.3 Time Service...... 19 3.4 Airspace Service...... 21 3.5 The Console...... 23 3.6 Initial Flight Plan Server...... 25 3.7 Integrated Air Survelliance...... 28 3.8 Flight Manager...... 32 3.9 Coordination...... 38 3.10 Trajectory Predictor...... 43 3.11 Medium Term Conflict Detection...... 46 3.12 Flight Path Monitor...... 49 3.13 Short Term Conflict Alert...... 51 3.14 CWP Communication service...... 54 3.15 Controller Working Position...... 55 3.16 Pilot Manager...... 57 3.17 Pilot Working Position...... 62 3.18 Arrival Manager...... 64 3.19 En-Route Manager...... 66 3.20 Traffic Editor / Profile Validation Tool...... 68 3.21 STORIA Data Recording Component...... 70 3.22 Ace eDEP Gateway...... 74 3.23 Aircraft types / Bada Server...... 74 3.24 Meteo Service...... 75 3.25 Scripted Event...... 77 3.26 ADS-B Message Proxy Server...... 78 3.27 TIS-B Message Proxy Server...... 79 3.28 ARTAS Message Proxy Server...... 81

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.29 ACSG TCAS server...... 81 3.30 Intrument Landing SubSystem...... 84 3.31 ATC Network Component (including Datalink)...... 85

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 References 1. eDEP GSDK Design Document, version 1.5 rev60, Graffica Ltd, 31 October 2002. 2. eDEP ATC Design Document, Version 1.9, Graffica Ltd, 12 March 2003 . 3. eDEP EEC Detailed Design Document, Version 1.0, Graffica Ltd, November 2006. 4. ACE / eDEP Gateway Design Document, Version 1.4, Graffica Ltd, December 2005. This document makes extensive references, via hypertext links, to the eDEP Java documentation. It is recommended that the Java documentation is generated prior to reading this document.

Glossary ADS-B Automatic Dependent Surveillance ARTAS ATM Surveillance Tracker and Server ASAS Airborne Separation Assurance System ASP Airspace – defines the eDEP Airspace server component ATC Air Traffic Control ATM Air Traffic Manager AWS Alternative Widget Set CAS Calibrated Air Speed CCS CWP Communication Service Component A basic self-contained unit of the platform producing and consuming events. Console A simple time control console for eDEP CP Conflict Probe CS Coordination Service CWP Controller Working Position DAP Downlinked Aircraft Parameters (via ADS-B) DEP Development and Evaluation Platform EULER EUROCONTROL toolKit for Experimental Research? FM Flight Manager FPM Flight Path Monitor FSM Finite State Machine GSDK Graffica System Development Kit IAS Integrated Air Surveillance IFPL Initial Flight Plan JVM Java Virtual Machine Mach Mach speed measured as a fraction of the speed of sound MTCD Medium Term Conflict Detection PM Pilot Manager PWP Pilot Working Position Resources A set of user defined substitutable named variables, containing objects of type integer,

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 Boolean, float or string, and which may be defined as lists of objects. RMI Remote Method Invocation STCA Short Term Conflict Alert STD State Transition Diagram TIS-B Traffic Information Service Toolkit A handy set of abstracted utility objects, which can be used to build more complex user specific objects as a part of a system. TP Trajectory Predictor TS Time Service

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 1 INTRODUCTION This architecture document provides a description of the components that make up the Demonstration and Evaluation Platform eDEP. These components are built using facilities provided by the Graffica System Development Kit (GSDK) class library. Each component holds an entity data store defined from the GSDK Scenario interface, a set of map data defined in the MapManager object, an interface derived from the GSDK middleware Component interface and an optional set of graphics display window shells managed by the GSDK graphics class AwsShellManager. These objects are initialised through the invocation of the methods in the user-defined implementations of the Application interface. Each implementation of the Application interface defines a distinct Java thread, running independently, and communicating through the provided component interfaces. The eDEP software is organised into modules arranged in a series of layers, with the GSDK forming the bottom layer, and higher layers containing increasingly rich ATC functionality. The following diagram illustrates the code dependencies between eDEP modules:

SPD TCAS AVT

SAT TWR ATCX SSECTOR EVP ATCLIVE

EEC_ATC VOIP ATCGRAPHICS eCOCKPIT SCC EEC ATC AEG ATCCORE

Figure 1-1 eDEP Module Dependencies There is an additional, unmarked, dependency, of test code within the EEC_ATC module, on the ATCGRAPHICS module. The following list of components defines the basic set for the eDEP platform. a. Within ATCCORE:  ACR Aircraft Performance Server  ASP Airspace Server  CCS CWP Communication Service  Console Time and System control component  IFPL Initial Flight Plan  METEO Meteorological Server  TS Time Service

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 b. Within ATC:  ADSB ADS-B Message Proxy Server  AMAN Arrival Manager  CP Conflict Probe  CS Sector Coordination and Flight Handover  CWP Controller Working Position  Datalink (DL) Datalink Server  FM Flight Manager  FPM Flight Path Monitor  IAS Integrated Air Surveillance  PM Pilot Manager  PWP Pilot Working Position  STCA Short Term Conflict Alert  TISB TIS-B Message Proxy Server  TP Trajectory Predictor  uCWP Unmanned Controller Working Position

c. Within other modules:  ARTAS ARTAS Message Proxy Server  Cockpit Cockpit Position

Figure 1-2, below, illustrates the relationship between the principal eDEP components in the ground subsystem and a simplified view of the air subsystem. Figure 1-2 Relationship between the Principal eDEP Ground Components

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 Figure 1-3, below, represents the key elements of the air subsystem with a simplified view of the links to the ground subsystem.

Figure 1-3 Relationship between the Principal eDEP Air Components Each component is defined in a package, which contains the classes specific to that component, and contains sub-packages defining the standard functional elements of a component. These sub-packages hold classes that define the server elements of the component, the client APIs, including component services and associated events, and the underlying entities, which define the component data model. If the application defines any component specific graphical items, a graphics sub-package is also included. A typical set of packages for a component is offered by the CWP component; each sub- package is defined in the following table. SUB-PACKAGE CONTENTS atc.cwp.server The internal server components providing the external serialized interface to the object, the database entity model, and the component interface controller object, which processes the external requests made through the interface atc.cwp.client The client side service objects, providing the client interface to the serialized remote component methods. The client package will also provide the client side events raised as part of the service. atc.cwp.entity The entity implementations forming the component data model. atc.cwp.graphics The CWP specific graphics classes, integrated into the GSDK AWS graphics framework, but implemented using a mixture of AWS, Java AWT and Swing components atc.cwp.CWP The object defining the CWP application thread. This object provides the required initialisation methods for mapping, database, graphics and controller interface. This object is derived from the GSDK Application interface, and is a sub-class of the GSDK ApplicationAdapter class

The interfaces for each of these components are defined in the package associated with the component under the server sub-package. Thus the time service interface is defined in the package atc.ts.server. The component interface is implemented in the corresponding controller classes in the respective component packages. The following sections show the architecture of each of these components, and the data exchanged through the public interfaces, and through the global events raised by the components.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 2 ARCHITECTURAL OVERVIEW

2.1 INTRODUCTION This section introduces the concepts that define the architectural structure of the components, which make up the eDEP platform. It provides an overview of the principle elements of a component, and describes the client/server patterns used in the platform. In particular, it identifies the server side interfaces provided by the eDEP component implementations of the GSDK interface ComponentController, and the client side eDEP service provider objects.

2.2 THE EDEP FRAMEWORK The eDEP facility uses abstract software components provided by the GSDK, and is a classical client/server facility, providing publish and subscribe functionality. The components supported by eDEP communicate through well-defined services with a mix of synchronous requests and asynchronous events. The eDEP framework comprises a series of ATM related components, each offering a set of services providing static ATM information, and temporal ATM events, which may be requested by subscription from any of the participating components. Each component is implemented as a GSDK application. Applications may be run individually in a dedicated Java Virtual Machine, or collectively as a ream of applications. Each eDEP server component provides one or more service objects, which provide the gateway into the server for a client component consuming data from the server, or making requests to the server. All classes within the client component and within the server component should refer directly to the objects defined by the ATM object model. The component controller object in the server and the service object in the client will provide the bridge between the serialised information passed between components and the pure object model defined within a component. Thus a message passed from a server to a client might refer to an object derived from the Flight class in its entity data model, and the serialised message will reference this object through its callsign string. On the client side, the service object will translate the callsign into the corresponding ATM object, which might be derived from the Aircraft class. If the object does not exist on the client side, then a new instance will be created, and any information in the message applied to the new object instance.

2.3 COMMUNICATION BETWEEN COMPONENTS The client/server model supported by the framework maintains a strict object based model within a component, with a thin interface layer converting the pure object form inside a component into serialised messages passed between components. These messages are processed in a thin software layer defined by a ComponentController object on the server side, and a service object on the client side. Thus the server offers one or more services to the client. Information is passed between components either through synchronous or asynchronous operations. The synchronous operations comprise get operations, which retrieve the latest value of the requested data structure, and set operations, which write new values into the selected item. The asynchronous mechanism uses events to communicate a change of state in an object, which can then be communicated to all interested objects, which have registered interest in the change, either locally within the component, or from an object located on a remote component. Processing in the application database or component related algorithms is de-coupled from the asynchronous message processing in the client side service object by scheduling the incoming message as an event in the synchronised event manager object.

Server X Client Event Subscribe X Register For X Component Service X Manager Event Controller Serialized Event X X Notify X Manager Database or Register For X Algorithms Database schedule X Notify X

Figure 2-4 Asynchronous Event Delivery

2.4 COMPONENT FRAMEWORK

2.4.1 Overview The component framework provides a simple ComponentController interface to define the functionality required to provide the initialisation and run-time control of distributed components. Each component requiring remote access to another component’s facilities will communicate with that component through the remote component’s ComponentController interface. An instance of the required implementation of the controller interface is returned from the user implementation of the Application method createInterface.

2.4.2 Component Controller The implementation class for the ComponentController, ComponentControllerImpl, is an abstract class that defines the baseline or default behaviour for each method. This class should be used as the base class for all user-defined component controllers. The class defines a constructor identifying the name of the component, and its thread. It also creates an instance of the SubscriptionManager class to manage remote subscriptions to the component’s services. The class also registers the component with the lookup/discovery service. When a user wishes to create a new component, this class will be extended to incorporate the component specific request functions, including get and set operations. It will also include convenience methods to make subscriptions to the specific external events produced by the component.

2.4.3 Component Controller Life Cycle Each component controller defines a simple life cycle that takes it through registration with the middleware discovery service, initialisation with remote component services, and starting the main component execution loop.

Figure 2-5 Component Life Cycle The ComponentController, ..\products\javadoc\gsdk\middleware\server\ComponentController.html, extends the Java RMI Remote interface, allowing it to be used as an RMI interface object.

2.5 APPLICATION FRAMEWORK The application framework provides a straightforward mechanism to create, initialise and execute a GSDK compliant application. The user application implementation may either be derived from the ApplicationAdapter object, which provides empty implementations of the Application interface, or provide a full implementation of the Application interface. One or more applications may be added to a single instance of the GSDK class.

Figure 2-6 GSDK Application Framework Architecture Each component developed must provide an implementation of the Application interface class. Each method of the derived application object is then invoked at the corresponding stage of the component initialisation, and any returned values are used to populate the ApplicationContext object, which holds a description of the application and its environment. The diagram in Figure 2-6 above shows the application framework architecture and the interfaces provided by the Application interface and the ApplicationContext class.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3 COMPONENT DESCRIPTIONS

3.1 OVERVIEW This section describes each of the components supported in the eDEP simulation facility. Each component is described in terms of its context, use-cases, published and subscribed events, and its external interface. The context diagram shows the external messages created and consumed by the component, including both messages sent by and received from participating components, and information provided by or sent to external devices such as files or printers. The lettered circle symbols on the connecting arrows indicate Subscription (S), Event (E), Read operations (R), and Write operations (W). The use cases show how the services provided by component are used. The produced and subscribed events define the event catalogue for the component. The interface description provides a Java interface showing the operations provided by the component.

3.2 DISCOVERY SERVICE

3.2.1 Description The Discovery Service, also known as Lookup/Discovery, abbreviated LD, provides a mechanism to enable a component to discover what services are currently being provided by the platform, and to lookup the discovered component’s interface in order to access that component’s services. When each component application is created, it will register its details with the discovery service. These details include the component name, the component’s remote interface definition, and an optional set of property values. Other components may then discover the registered components, by invoking one of discovery’s lookup methods to location the required server and its interface, and then to access The interface to the LD component is defined in the interface Discovery, which is found in the package gsdk.middleware.discovery.

3.2.2 Context The following context diagram shows how the LD provides its services to the components in the eDEP platform. The circle in the centre of the diagram indicates the limits of the LD application, and the rectangular boxes indicate other servers in the eDEP platform, with which the LD communicates, either through asynchronous lookup, or by a direct synchronous call to a remote method.

lookup( componenName ) lookup( discoveryFilter ) lookup( discoveryFilter, maxMatches ) lookup( discoveryFilter, listener ) R

register Registering Discovering LD W Component Component

W E unregister notify( DiscoveryEvent ) Figure 3-7 Lookup Discovery Context Diagram

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.2.3 Use Cases This use case shows a simple example scenario where the server components X and Y register with discovery, and client components A, B, and C lookup the service interfaces. Component C registers an event listener with LD so that any component subsequently registering or un-registering, which matches the given filter can be notified by invoking the listener.  Component X registers with LD  component A invokes lookup using the component name X  component B invokes lookup using a discovery filter identifying component X  component C invokes asynchronous lookup, registering a listener invoked when “Y” is registered  Component Y registers with LD  LD signals discovery and notifies component C of component Y’s registration.  Component X un-registers with LD

3.2.4 Published Events The discovery service publishes the DiscoveryEvent. This event is signalled each time a component registers or un-registers itself with the service. The event defines whether a register or an unregister of a component has occurred, and holds the component description details for that component.

3.2.5 Subscribed Events There are no externally subscribed events.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.2.6 Discovery Service Interface Methods are provided to notify the Discovery Service when new components are added to eDEP, and when existing components are removed from eDEP. The service provides lookup methods to access the interface (or interfaces) to a component (or components) matching the given component description specification. Calls to lookup components may be provided with a time out interval. The Discovery Service interface is detailed in the following reference ..\products\javadoc\gsdk\middleware\discovery\client\DiscoveryService.html.

3.3 TIME SERVICE

3.3.1 Description The Time Service server, abbreviated TS, provides a regular source of time updates, and nominated wake-up events for use in the eDEP platform. It comprises an application made from a scenario object defining the required timing loop and time manager object. The initial time step, time rate and start time values are set from the command line and can be reset by invoking the synchronous methods defined in the interface. Time ticks and wake-up requests are reported by events. The initial version of the TS will report time ticks at a fixed rate, but future versions will provide a filter mechanism, which will allow user defined time update rates. The interface to the TS component is defined in the interface TSController, which is found in the package atc.ts.client.

3.3.2 Context The following context diagram shows how the TS interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the TS application, and the rectangular boxes indicate other servers in the eDEP platform, which the TS communicates with, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

setStartTime setTimeRate setTimeStep WakeupEvent setPaused startClock E registerForWakeupEvent W

TS getStartTime getTimeRate getTimeStep registerForTimeTickEvent isPaused E R isStarted TimeTickEvent

Figure 3-8 Time Server Context Diagram

3.3.3 Use Cases 3.3.3.1 Configuring the Simulation Clock The time service provides synchronised facilities to set the characteristics of the simulation clock. In particular, it allows the setting of the clock update period (time-step), the rate at which time flows (time-rate), the simulation time at the start of the run, and the running state of the simulation clock between running and paused.

3.3.3.2 Regular Time Updates A client component can request regular time updates from the time service to keep the local clock synchronised with the clock in the timeserver component.  set up the system parameters to request external time, and to define the required tick interval;  create a time service object for the client component, providing a reference to the client database. This service automatically registers interest in the TimeTickMessage, setting the required interval

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.3.3.3 Request To Wakeup At A Pre-Defined Future Time A client component can request a wakeup call from the time service to stimulate the client component at the wakeup time, by invoking the supplied listener object.  create a time service object for the client component, providing a reference to the client database.  register for a WakeupMessage at the required wake-up simulation time, supplying an event listener.  At the designated wakeup time, the notify method in the supplied EventListener is invoked.

3.3.4 Published Events

Published Event Description TimeAcceleratedMessage TimeControlMessage TimeTickMessage A periodic event containing the system wide simulation time, issued to the subscribing object after a fixed time-step interval, identified in the subscription. This regular time update event is used to reset the local simulation clock on a subscribing component. WakeupMessage An event scheduled for some future time, used to wake-up the registering component at that time. The subscriber can make the event periodic with a given time interval.

3.3.5 Subscribed Events The time service does not subscribe to any external eDEP events.

3.3.6 Time Server Interface The TimeServer interface, ..\products\javadoc\atc\ts\server\TSController.html, is provided for clients of the timeserver. It presents a serialized interface to the client component, to support the inter- component messages supported by the Java RMI architecture. The client side time service object provides the client with clean access to the relevant time objects

3.4 AIRSPACE SERVICE

3.4.1 Description The Airspace server, abbreviated ASP, provides a source of ATC sectors, military sectors and other restricted areas, service volumes, airways, airports and airspace beacons for use in the eDEP facility. It also provides unit definitions and structured route information, defining standard routes, route segments, SID and STAR segments and letters of agreement. It comprises an application made from a scenario object defining each of the airspace object types. New airspace objects can be introduced at any time, and the status of existing objects may be modified in response to environmental events. The initial airspace definitions are read from a scenario file. The airspace data can be accessed through synchronous interfaces, and any changes to the airspace may be reported by event. The preliminary version of the ASP will not provide any airspace filtering mechanisms, to optimise the distribution of airspace data to participating and interested components. Instead, the baseline version will distribute the entire airspace, or the complete subset of the airspace defined by the particular request, to all subscribers, irrespective of their location. Future ASP enhancements may permit subscriber filtering to reduce network load, and the need for the subscriber to perform any filtering. The interface to the ASP component is defined in the interface ASPController, which is found in the package atc.airspace.server.

3.4.2 Context The following context diagram shows how the ASP interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the ASP application, and the rectangular boxes indicate other servers in the eDEP platform, which the ASP communicates with, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

Airspace getFixes getAirways getAirports getRunways R Sectorization Airspace getSectors Definition getUnits getRestrictedAreas ASP getServiceVolumes R

R Route Expansion getSIDs getSTARs getRoutes getAgreements

Figure 3-9 Airspace Server Context Diagram

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.4.3 Use Cases 3.4.3.1 Initialisation  register airspace component with the lookup/discovery service  read airspace definition file from ASP.SCENARIO resource name  start airspace server

3.4.4 Published Events The airspace server component does not publish any external eDEP events.

3.4.5 Subscribed Events The airspace server component does not subscribe to any external eDEP events.

3.4.6 Airspace Server Interface The Airspace Server interface, ..\products\javadoc\atc\airspace\server\ASPController.html, is provided for clients of the airspace server. It presents a serialized interface to the client component, to support the inter-component messages supported by the Java RMI architecture. The implementation class for this interface defines the airspace component controller object and generates the serialised inter-component messages, which are converted into the pure entity data model objects in the client side service object to provide clean access to the airspace objects.

3.5 THE CONSOLE

3.5.1 Description The Console component provides a pure client object to control the running state of the eDEP facility. The initial version of this component provides time control functions,, illustrated in Figure 3-10 below, which allow the platform to start its simulation clock, pause and resume the clock, and to stop the clock and close down the platform. The Console also provides a real-time display of the running simulation clock.

Figure 3-10 The Console

3.5.2 Context Diagram The Console component requires access to the eDEP time service, to update the clock in the time panel, and to send time control requests back to the timeserver to adjust the simulation clock speed, and to pause the simulation clock.

TimeTickMessage

Console E TS

setTimeRate setTimeStep setRealTime setPaused startClock Figure 3-11 Console Component Context Diagram

3.5.3 Use Cases 3.5.3.1 Basic Time Control and Display The Console provides functions to display and control the running simulation clock.  create a time service object in the Console component;  register a time tick event listener for local time update event;  on time update event, update the clock display; and  adjust the time rate and pause, then set back to real time.

3.5.4 Published Events The Console component does not publish any external eDEP events.

3.5.5 Subscribed Events Subscribed Event Description

TimeTickMessage Produced by the Time Service, this event is automatically subscribed to by the client side Time Service implementation object, to update the local clock

3.5.6 Console Interface The Console component does not provide any services, and defines no interface.

3.6 INITIAL FLIGHT PLAN SERVER

3.6.1 Description The initial flight plan server, abbreviated IFPL, is the source of flight plans used in the eDEP facility. The server reads the initial plan definitions from a supplied scenario file, identified by the resource name “IFPL.SCENARIO”. A FlightPlanEvent, is signalled to indicate the activation of a new flight plan. This event may be subscribed to by interested components. The initial flight plan definition in the scenario file may contain a set of complex route plans. These plans can be composed from standard airspace objects, which include the following items.  standard eDEParture routes out of the TMA (designated SID);  standard arrival routes into the TMA (designated STAR);  standard route segments defining the 2D plan;  user defined control points identifying any combination of plan position, profile altitude and speed;  a level preference or requested flight level, RFL. The interface to the IFPL component is defined in the interface IFPLController, which is found in the package atc.ifpl.client.

3.6.2 Context Diagram The following context diagram shows how the IFPL interfaces with other eDEP components. The circle in the centre of the diagram indicates the limits of the IFPL application, and the rectangular boxes indicate other components, with which the IFPL communicates, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

ASP TS loadAirspace TimeTickMessage E S Flight Plan Definitions subscribeTimeTickMessag e IFPL

subscribeFlightPlanMessage subscribeFlightPlanMessage S S E E FlightPlanMessage FlightPlanMessage

FM PM Figure 3-12 IFPL Server Context Diagram

3.6.3 Use Cases 3.6.3.1 Initialisation

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007  register IFPL service with Lookup/Discovery services  read flight plan details from the IFPL scenario file identified by resource IFPL.SCENARIO  subscribe to time service for regular time updates.  load airspace data to resolve airspace items in flight plan.

3.6.3.2 Sending Flight Plans to a Component This use case is illustrated in Figure 3-13 below.  Client component creates an IFPL Service object, which looks up the IFPL service  Client component subscribes to flight plan events provided through IFPL service  when flight plan is due for release, an event is signalled in IFPL and the plan distributed to all subscribing components.

3.6.3.3 Requesting a Flight Plan  component creates an IFPL Service object, which looks up the IFPL service  retrieves the flight plan using a callsign key using the flight plan service.

Figure 3-13 IFPL Flight Plan Generation Processing Sequence

3.6.4 Published Events Published Events Description

FlightPlanMessage Produced by the IFPL, this event contains a flight plan object, which defines the 2D plan of the route, in terms of the airspace objects SID, RoutePlan and STAR. The plan also defines the originating airport and the destination airport, along with the requested flight level, RFL.

3.6.5 Subscribed Events Subscribed Events Description TimeTickMessage Produced by the Time Service, this event is automatically subscribed to by the client side Time Service implementation object, to update the local clock

3.6.6 Initial Flight Plan Interface The initial flight plan service, ..\products\javadoc\atc\ifpl\server\IFPLController.html, provides methods to enable users to subscribe to new flight plans, as they become active. The initial flight plan service also provides methods to retrieve either a particular activated flight plan from the IFPL server, identified by its callsign, or to retrieve all activated flight plans from the IFPL server. It presents a serialized interface to the client component, to support the inter-component messages supported by the Java RMI architecture. The implementation class for this interface defines the IFPL component controller object and generates the serialised inter-component messages, which are converted into the pure entity data model objects in the client side service object to provide clean access to the flight plan objects.

3.7 INTEGRATED AIR SURVELLIANCE

3.7.1 Description The Integrated Air Surveillance, abbreviated IAS, provides a source of tracks for the eDEP facility, and comprises an application made from a scenario object defining aircraft flights. These flights are moved along their respective flight paths, defined by aircraft trajectories. Aircraft trajectories are received by subscribing to a Pilot Manager component, which provides the Pilot Service. Positions along this trajectory are calculated at a regular interval of typically six seconds, and the resultant set of tracks is reported as an external TrackUpdateMessage event. This event may be received by any subscribing component. The TrackUpdateMessage may contain one or more tracks for different flights, up to a maximum of about ten tracks; by grouping tracks together in this way, the network load may be moderated, by reducing the total number of messages being sent to subscribed components. The IAS receives aircraft state vectors from the eDEP platform by subscribing to the event TrajectoryUpdateMessage in the Pilot Service. The IAS offers a fly ground trajectory mode. In this case the IAS generates track vectors from the ground trajectories received from the FM rather than the air trajectories generated by the PM. This mode is useful when a controller is not required to interact with the system. The IAS also offers a Live mode, in which the ARTAS component sends StateVectors to IAS, in place of a connection to the PM. In this case, Track vectors are generated using the received Track Report information and reported to IAS as State Vectors. The IAS provides access for registered subscribers to receive DAP data provided by the PM combined with state vectors. The IAS also produces detailed Track Reports that combine the information contained in the track vectors and DAP data for registered subscribers. The preliminary version of the IAS will not provide any track filtering mechanism, to optimise the distribution of tracks to participating and interested sectors. Instead, the baseline version will distribute tracks to all subscribers, irrespective of their location. Future IAS enhancements will permit subscriber track filtering to reduce network load, and the need for the subscriber to perform any filtering. The interfaces for the IAS component are defined in the interface IASController and DAPController, which are found in the package atc.track.server.

3.7.2 Context Diagram The following context diagram shows how the IAS interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the IAS application, and the rectangular boxes indicate other servers in the eDEP platform, which the IAS communicates with, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

TS subscribeTimeTickMessage S E TimeTickMessaget TrackUpdates TrackUpdateMessage S E IAS E FM TrajectoryMessage E StateVectorMessage S subscribeStateVectorMessage PM Figure 3-14 Integrated Air Surveillance Context

3.7.3 Use Cases 3.7.3.1 Initialisation  Subscribe to time tick events from the Time Server (TS)  Subscribe to aircraft trajectory update messages from the Pilot Manager (PM)

3.7.3.2 Generating Track Updates  Update time with time ticks from the time server.  Update the tracks at the regular interval defined by the track update period.  Store the updated track details in a track update event.  When the track update event has been loaded with tracks, or it is due, send the track update message.  Generates and distributes Track Reports, from available tracks and DAP data, at a defined interval  Distribute DAP (ADS-B) data when state vectors are received from the PM.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 Figure 3-15 Integrated Air Surveillance Track Generation Processing

3.7.3.3 Receiving ARTAS State Vectors  Update position of track with position in State Vector received from the ARTAS Proxy server.  Update the tracks DAP object with the DAP in the State Vector received from the ARTAS Proxy Server.  Store the updated track details in a track update event.  When the track update event has been loaded with tracks, or it is due, send the track update message.

3.7.4 Published Events Published Events Description TrackCreationMessage The track creation message informs clients when a track has been created. TrackDeletionMessage The track deletion signals the deletion of a flight. TrackUpdateMessage The track update message defines a set of tracks produced by the IAS either in the last update period, or the set of tracks produced has reached the maximum number carried in any one TrackUpdateMessage. Track updates are grouped together to reduce the network synchronisation time between the components. DAPUpdateMessage The DAP update message provides notification of DAP information received by the IAS. The aircraft must be ADSB-equipped.

3.7.5 Subscribed Events Subscribed Events Description TimeTickMessage Produced by the Time Service, this event is automatically subscribed to by the client side Time Service implementation object, to update the local clock. StateVectorMessage Produced by the Pilot Manager component, the aircraft trajectory message provides updates of the aircraft trajectory, and is used as the basis for determining the aircraft track position at the given simulation time. May contain DAP data if the aircraft is ADSB-equipped.

3.7.6 Track Server Interface The track server interface, ..\products\javadoc\atc\ias\server\IASController.html, provides methods to enable users to subscribe to track updates, and events to signal the creation and destruction of the tracks. The track server supports methods to retrieve either the latest track for a particular flight from the server, identified by its callsign, or to retrieve all the latest tracks for all flights in the server. The track server also provides an interface to enable users to subscribe to the IAS generated track reports and a method, used by the ARTAS Proxy server, to add State Vectors to the tracks in the IAS database. It presents a serialized interface to the client component, to support the inter-component messages supported by the Java RMI architecture. The DAP server interface, ..\products\javadoc\atc\ias\server\DAPController.html, provides methods to enable users to subscribe to DAP data associated with a flight. The implementation class for these interfaces defines the IASController and DAPController component controller objects and generates the serialised inter- component messages, which are converted into the pure entity data model objects in the client side service object to provide clean access to the track objects.

3.8 FLIGHT MANAGER

3.8.1 Description The flight manager component, abbreviated FM, provides a set of functions to maintain and update the state parameters of a flight object. The flight manager defines the principle functionality of all flight objects. In particular, an implementation class of the Flight interface will provide the following facilities:  current trajectory progress;  current clearances;  current co-ordinated state;  the initial flight plan;  maintenance of current trajectories;  maintenance of current constraint lists;  creation of a set of significant point information lists.

The Flight Manager provides trajectory update events, and significant point events for the eDEP platform. The Flight Manager will initialise by fetching airspace data from the Airspace Server and subscribe to the time service and the initial flight plans generated by the flight plan service. The interface to the FM component is defined in the interface FlightService, which is found in the package atc.fm.client.

3.8.2 Context Diagram The following context diagram, Figure 3-16, shows how the Flight Manager component, FM, interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the CWP application, and the rectangular boxes indicate other servers in the eDEP platform, which the CWP component communicates with, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

setDirectTo setCFL ASP CWP setHeading setRedirect setCASspeed TS setMachSpeed TimeTickEvent GroundTrajectoryEvent W loadAirspace E E DeviationsUpdateEvent R S GroundTrajectoryEvent subscribeTimeTickEvent FPM E FM IAS S TrackUpdates subscribeGroundTrajectoryEvent Subscrib eTrajecto S subscribeFlightPlanEventryMessag setPlannedLevel E e setPlannedSpeed W E FlightPlanEvent setPlannedHeading SectorCrossing ListEvent IFPL W E TrajectoryEvent CS submitConstraints

Figure 3-16 FM Context Diagram

3.8.3 Use Cases 3.8.3.1 Initialisation  register FM with lookup/discovery service  load airspace from the airspace server  subscribe to time update service  subscribe to initial flight plans from IFPL  subscribe to trajectory updates from the TP  subscribe to deviations from the FPM.  subscribe to track updates from the IAS.

3.8.3.2 Initial Plan Processing The flight manager receives and processes the initial flight plan data to generate the initial trajectory for the system.  receive a flight plan event from the IFPL  expand the flight plan into atomic 2D constraints, to form the initial constraint list  expand the constraint list profile using control level, letters of agreement, and RFL  submit the constraint list to the trajectory predictor, with an INITIAL tag  receive and store the resultant trajectory from the trajectory update event from the TP, as both the initial trajectory and the ground trajectory

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007  distribute the ground trajectory to all subscribed components

3.8.3.3 Process Tactical Manoeuvre A tactical manoeuvre made to a flight is a consequence of an executive controller of the flight issuing a tactical clearance, namely a direct to, re-direct, level change, speed change or heading change, and then making the corresponding modification to the ground trajectory.  receive tactical clearance from the CWP  process existing ground constraint list in accordance with the manoeuvre  submit the constraint list to the trajectory predictor, with a GROUND tag  receive and store the resultant trajectory from the trajectory update event from the TP, as the ground trajectory  distribute the ground trajectory to all subscribed components

3.8.3.4 Process Planned Manoeuvre A planned manoeuvre made to a flight is a consequence of a planner controller of the flight issuing a planned constraint in level, speed or heading on the sector boundary, and then making the corresponding modification to the ground trajectory.  receive planned clearance from the CWP  process existing ground constraint list in accordance with the manoeuvre  submit the constraint list to the trajectory predictor, with a GROUND tag  receive and store the resultant trajectory from the trajectory update event from the TP, as the ground trajectory  distribute the ground trajectory to all subscribed components

3.8.3.5 Process Trajectory Update for Significant Point Lists When a new trajectory has been received from the TP, the FM will process the associated trajectory to build the significant point lists for sector crossing, unit crossing, advisories, profile points and plan points.  receive a generated trajectory from the TP  generate the sector-crossing list from the sectors read from the airspace server  generate the unit-crossing list from the units read from the airspace server  extract the advisory list from the trajectory points, identifying key manoeuvre points  extract the profile list from the trajectory points, identifying the points with defined  extract the profile points from the trajectory, identifying points with profile attributes  extract the plan points from the trajectory, identifying points with associated fix names

3.8.3.6 Flight Path Deviation The Flight Path Monitor server can be used to automatically correct for longitudinal or vertical errors while the flight progresses along its planned trajectory.  subscribe to longitudinal deviations from the FPM  on receipt of longitudinal or vertical deviation events, update the ground constraints using current aircraft location as the first constraint point  submit updated constraints to the TP for regeneration

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.8.3.7 Trajectory Edition The FM may be asked to create a WORKING trajectory based on the current GROUND trajectory. The new WORKING trajectory is given a user-defined tag that usually allows the identification of the ATC Unit and CWP that generated it. This WORKING trajectory may be modified using the normal ATC orders described in section 3.8.3.3 and a trajectory update event is sent out in the same way, picked up by the client that owns the trajectory. The FM may be asked to update this WORKING trajectory in which case the FM will re-submit the WORKING ConstraintList to the trajectory predictor again, and the resulting trajectory will be modified if any of the Constraints can't be met.  The FM creates a WORKING trajectory with a user-defined tag using the current GROUND ConstraintList  The WORKING trajectory may be modified using normal ATC Orders.  The FM updates the WORKING trajectory when requested to do so and sends out the updated ConstraintList and trajectory.  The FM may be requested to update the GROUND trajectory using the WORKING ConstraintList. Note: The Coordination server (CS) receives all WORKING trajectories generated and informs subscribers about their existence. This intermediary server allows the existence of WORKING trajectories to be controlled with relation to the priority of the ATC controllers, and the coordination state of the aircraft.

3.8.3.8 Saved SystemFlightPlans A client may save current SystemFlightPlan objects under a user-defined tag. This allows a previous ConstraintList to be re-instated at a later time after the saved SystemFlightPlan is no longer the current GROUND plan.  The client requests that a current SystemFlightPlan be saved under a particular tag  Subscribers to saved plans under that tag are told about the saved SystemFlightPlan.

3.8.3.9 SystemFlightPlan Context When creating or saving a SystemFlightPlan the FM may be given a context object. This object is attached to the SystemFlightPlan that is distributed to the client subscribers. This allows a client to know about the context under which a trajectory was generated or saved. This context info is replaced whenever a new trajectory is produced.

3.8.3.10 Order Context When giving ATC Orders the FM may be given a context object. This object is attached to the SystemFlightPlan that is distributed to the client subscribers. In this was the clients to the SystemFlightPlan can know the conditions under which the ATC Order was given.

3.8.4 Published Events Published Events Description ClearanceMessage Produced by the Flight Service, the clearance event is signalled when the FM has reset the flight level, or the speed or the heading following a request to set the clearance from a CWP. It is echoed back to all interested CWPs to confirm the change of clearance. FlightUpdateMessage The FlightUpdateMessage denotes that a trajectory has been updated. InitialFlightPlanMessage Produced by IFPL and relayed by FM, making the flight plan details available to interested components. The message will contain the raw

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 unexpanded plan and the expanded constraint list details. SectorCrossingListMessage Produced by the Flight Service, the sector crossing list event provides a list of all the crossing points from one sector into another, identifying the nearest COP. Generated after new ground trajectory installed. SFPLDeletedMessage The SFPL deleted message signals that a flight has been deleted from the system. SystemFlightPlanMessage The SystemFlightPlanMessage signals that a flight plan has been updated. TaggedTrajectoryMessage The tagged trajectory messages denotes that a specific trajectory has been updated. TrajectoryMessage Produced by the Flight Service, after processing a new set of constraints either from an IFPL, or after requesting an aircraft manoeuvre on a trajectory with a given tag. The tag is supplied in the event along with the flight callsign. UnitCrossingListMessage Produced by the Flight Service, the unit crossing list event provides a list of all the crossing points from one unit into another, identifying the nearest COP. Generated after new ground trajectory installed. SavedSystemFlightPlanMess Produced by the Flight Service when a SystemFlightPlan has been age saved under a user-defined tag. The message contains the saved SystemFlightPlan and includes any ContextObject that was supplied at the time of saving.

3.8.5 Subscribed Events Subscribed Events Description DeviationsUpdateMessage Produced by the Monitor Service, generated from the flight path monitor component, this event will contain the estimated deviations from the predicted flight plan, given the latest track information. This deviation can be used to correct any longitudinal (time late or early) deviation from the original plan. FlightPlanMessage Produced by the IFPL Service, this event contains a new flight plan definition, and will cause a new flight to be created, and the plan to be expanded into a set of constraints for submission to the trajectory predictor component. TrajectoryMessage Produced by the Trajectory Service, generated from the trajectory predictor component, this event will contain the calculated trajectory points from a previously submitted set of constraint points. The type of the trajectory (ground, proposal etc.) is identified from a tag name. TimeTickMessage Produced by the Time Service, this event is automatically subscribed to by the client side Time Service implementation object, to update the local clock.

3.8.6 Flight Server Interface The flight server interface, ..\products\javadoc\atc\fm\server\FMController.html, provides methods to enable users to subscribe to trajectory updates, and events to signal the creation and destruction of the tracks. The track server also provides methods to retrieve either the latest track for a particular flight from the server, identified by its callsign, or to retrieve all the latest tracks for all flights in the server. It presents a serialized interface to the client component, to support the inter-component messages

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 supported by the Java RMI architecture. The implementation class for this interface defines the FMController component controller object and generates the serialised inter-component messages, which are converted into the pure entity data model objects in the client side service object to provide clean access to the track objects. Note: the serializable server object PlanId ..\products\javadoc\atc\fm\server\PlanId.html, defines a simple class with public attributes holding a callsign string and a tag string identifying a flight with its specific set of constraints and associated trajectory object. Future users may need to modify this class to overcome problems with the uniqueness of the flight callsign.

3.9 COORDINATION

3.9.1 Description The Coordination server, abbreviated CS, provides functionality to support the coordination of planned flight state vector values on the sector crossing points. It also maintains the flight’s coordination state which reflects an ATC Controller's responsibility for the flight in a particular ATC Unit.  NOTIFIED – flight will enter Unit in n minutes (normally 30)  ACTIVATED – flight will shortly enter; may negotiate entry conditions with ASSUMED Unit  TRANSFERRED_IN – ASSUMED Unit has told pilot to switch to the ACTIVATED Unit's R/T frequency  ASSUMED – the ATC Controller has taken control of the flight  TRANSFERRED_OUT – the pilot has been instructed to set the R/T frequency to that of the following Unit  CONCERNED – the ATC Controller is no longer controlling the flight but the aircraft is still in the local ATC Unit's airspace.  UNCONCERNED – the flight is of no interest to the ATC Controller

Figure 3-17 Sector Handover State Transitions

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 An ATC Unit may also decide to not take control of the flight but instead pass control to the following Unit. In this case the Unit issues a SKIP instruction. If a flight is in the ACTIVATED state in a Unit and the flight's trajectory is modified such that it no longer pass through that Unit's airspace, the by-passed Unit becomes ABREGATED and the associated ATC Controller(s) must be notified.

3.9.2 Context Diagram The following context diagram shows how the Coordination component interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the Coordination application, and the rectangular boxes indicate other servers in the eDEP platform that the Coordination component communicates with.

ASP TS TimeTickEvent

CWP Airspace Data E SsubscribeTimeTickEvent S E

subscribeSectorCrossingListEvent

CLIENTS E FM CS S SectorCrossingListEvent

E S E subscribeUnitCrossingEvent UnitCrossingEvent S UCWP

Figure 3-18 Coordination Context Diagram

3.9.3 CS Server External Requirements 3.9.3.1 TS (Time Service) The CS requires the following TS subscriptions:  TimeTickEvent – for the simulation time and the event scheduler

3.9.3.2 FM Service The CS requires the following FM subscriptions:  SectorCrossingListEvent – to receive the SectorCrossingList for each flight The FM Service is also notified of XFL changes that are negotiated

3.9.3.3 FPM Service The CS requires the following FPM subscriptions:  UnitCrossingEvent – to know when a flight crosses a Unit boundary

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.9.4 CS Server Interface The CS server interface permits a user to dialogue with neighbouring ATC Units to transfer/assume control of a flight, to negotiate the flight's state (flight-level, fix, heading, etc.) at entry into an ATC Unit, and to negotiate the route of the flight with upstream and downstream Units.

/** * The ATC Coordination server interface. * * The ATC Coordination server handles the transferring of flights across ATC Unit boundaries, * managing the dialogues to agree on the crossing conditions and also the handover operation * itself. * * @author Steve Owen * Date: Nov 21, 2007 */ public interface AtcCoordinationController extends ComponentController, RouteModification { /** * Send an AgreementDialogue to the involved ATC Units in order to set a Unit crossing * agreement. * @param agreementDialogueDesc an RMI-friendly description of an AgreementDialogue * @see atc.coordination.common.dialogues.AgreementDialogue * @throws RemoteException */ void makeAgreementDialogue(AgreementDialogueDescription agreementDialogueDesc) throws RemoteException;

/** * Send a HandoverDialogue to the involved ATC Units in order to transfer a flight to the * next ATC Unit. * @param handoverDialogueDesc an RMI-friendly description of a HandoverDialogue * @see atc.coordination.common.dialogues.HandoverDialogue * @throws RemoteException */ void makeHandoverDialogue(HandoverDialogueDescription handoverDialogueDesc) throws RemoteException;

/** * Send a RouteDialogue to the involved ATC Units in order to coordinate a new route with * adjacent ATC Units. * @param routeDialogueDescription an RMI-friendly description of a RouteDialogue * @see atc.coordination.common.dialogues.RouteDialogue * @throws RemoteException */ void makeRouteDialogue(RouteDialogueDescription routeDialogueDescription) throws RemoteException;

/** * A message from an ADVANCED/ASSUMED Unit to the next ATC Unit to inform it of intended * entry. * @param flightRef the Reference of the flight involved * @param atcAuthorityDesc an RMI-friendly description of the initiating AtcAuthority * @param toUnitRef the Reference of the recipient ATC Unit * @throws RemoteException

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 */ void sendAbi(Reference flightRef, AtcAuthorityDescription atcAuthorityDesc, Reference toUnitRef) throws RemoteException;

/** * A message from an ADVANCED/ASSUMED Unit to the next ATC Unit to set the flight ACTIVATED * in the next Atc Unit. * @param flightRef the Reference of the flight involved * @param atcAuthorityDesc an RMI-friendly description of the initiating AtcAuthority * @param toUnitRef the Reference of the recipient ATC Unit * @throws RemoteException */ void sendAct(Reference flightRef, AtcAuthorityDescription atcAuthorityDesc, Reference toUnitRef) throws RemoteException;

/** * A meesage from a down-stream NOTIFIED/ADVANCED ATC Unit to request that the ATC Unit be * skipped and control passed to the following Unit. * @param flightRef the Reference of the flight involved * @param atcAuthorityDesc atcAuthorityDesc an RMI-friendly description of the initiating * AtcAuthority * @param skippedUnitRef the Reference of the ATC Unit to be skipped * @throws RemoteException */ void skipUnit(Reference flightRef, AtcAuthorityDescription atcAuthorityDesc, Reference skippedUnitRef) throws RemoteException;

/** * Register the given AtcAuthority as managing the associated ATC Units. * @param atcAuthorityDesc an RMI-friendly description of an AtcAuthority * @throws RemoteException */ void registerAuthority(AtcAuthorityDescription atcAuthorityDesc) throws RemoteException;

/** * Subscribes for transited units messages for the given ATC authority. * @param atcAuthorityDesc an RMI-friendly description of the interested AtcAuthority * @param listener the event listener for the TransitedUnitsMessage * @return the subscription id of this subscription */ SubscriptionID subscribeForTransitedUnitsMessage( AtcAuthorityDescription atcAuthorityDesc, EventListener listener ) throws RemoteException;

/** * Subscribes for unit agreement dialogue messages for the given ATC authority. * @param atcAuthorityDesc an RMI-friendly description of the interested AtcAuthority * @param listener the event listener for the AgreementDialogueMessage * @return the subscription id of this subscription */ SubscriptionID subscribeForAgreementDialogueMessage

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 ( AtcAuthorityDescription atcAuthorityDesc, EventListener listener ) throws RemoteException;

/** * Subscribes for unit route dialogue messages for the given ATC authority. * @param atcAuthorityDesc an RMI-friendly description of the interested AtcAuthority * @param listener the event listener for the RouteDialogueMessage * @return the subscription id of this subscription */ SubscriptionID subscribeForRouteDialogueMessage( AtcAuthorityDescription atcAuthorityDesc, EventListener listener ) throws RemoteException;

/** * Subscribes for handover state change messages for the given ATC authority. * @param atcAuthorityDesc an RMI-friendly description of the interested AtcAuthority * @param listener the event listener for the HandoverStateChangeMessage * @return the subscription id of this subscription */ SubscriptionID subscribeForHandoverStateChangeMessage ( AtcAuthorityDescription atcAuthorityDesc, EventListener listener ) throws RemoteException;

/** * Subscribes for unit entry messages for the given ATC authority. * @param atcAuthorityDesc an RMI-friendly description of the interested AtcAuthority * @param listener the event listener for the UnitEntryMessage * @return the subscription id of this subscription */ SubscriptionID subscribeForUnitEntryMessage( AtcAuthorityDescription atcAuthorityDesc, EventListener listener ) throws RemoteException; /** * Subscribe for handover monitoring messages from a monitoring client. * @param listener a listener for the HandoverMonitoringMessage * @param atcAuthorityDesc an RMI-friendly description of the interested AtcAuthority */ SubscriptionID subscribeForHandoverMonitoringMessage ( AtcAuthorityDescription atcAuthorityDesc, EventListener listener ) throws RemoteException;

/** * Subscribe for agreement monitoring messages from a monitoring client. * @param listener a listener for the AgreementMonitoringMessage * @param atcAuthorityDesc an RMI-friendly description of the interested AtcAuthority */ SubscriptionID subscribeForAgreementMonitoringMessage ( AtcAuthorityDescription atcAuthorityDesc, EventListener listener ) throws RemoteException;

/** * Subscribe for route monitoring messages from a monitoring client. * @param listener a listener for the RouteMonitoringMessage * @param atcAuthorityDesc an RMI-friendly description of the interested AtcAuthority */ SubscriptionID subscribeForRouteMonitoringMessage ( AtcAuthorityDescription atcAuthorityDesc,

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 EventListener listener ) throws RemoteException;

3.9.5 CS Client Requirements There are three main CS clients which have different requirements from the CS server:

3.9.5.1 The CWP Client This client has the following requirements:  receive the coordination state of all ATC Units in its controlled airspace (its AtcAuthority)  make dialogues with an adjacent AtcAuthority (via the server) to change the coordination state of an ATC Unit.  make dialogues with an adjacent AtcAuthority (via the server) to change to an aircraft state parameter at the Unit boundary.  receive Unit boundary crossing messages to know when the aircraft is in the local AtcAuthority.  receive automatic dialogues from the server for non-standard Unit entry conditions when the flight is ACTIVATED

3.9.5.1.1 Subscriptions with the CS Server The CWP client receives the following messages to maintain its internal coordination state:  TransitedUnitsMessage – contains the transited Units in the local AtcAuthority  HandoverStateChangeMessage – contains dialogues for changing the coordination state  AgreementDialogueMessage - contains dialogues for changing an aircraft state parameter  RouteDialogueMessage - contains dialogues for coordinating the route of the flight  UnitEntryMessage – contains information about a Unit boundary crossing by a flight

3.9.5.1.2 Interface to the CS Server The CWP client uses the atc.coordination.client.CoordinationService to issue handover requests and make dialogues for changing boundary conditions between Units. (see the interface class for details), or for changing the flight's route.

3.9.5.2 The Monitor client The Monitor client has the following requirements:  receive all handover dialogues, for all flights in all ATC Units  receive all dialogues that negotiate Unit entry conditions for all flights  receive all dialogue events that negotiate the route of the flight

3.9.5.2.1 Subscriptions with the CS Server The Monitor client receives the following messages to maintain its internal coordination state:  HandoverMonitoringMessage – for all handover dialogues between ATC Units  AgreementMonitoringMessage – for all dialogues regarding flight state at Unit entry  RouteMonitoringMessage – for all dialogues regarding the flight's route

3.9.5.2.2 Interface to the CS Server

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 The Monitor client does not dialogue with the CS server.

3.9.5.3 The UCWP client The UCWP client has the following requirements:  all the requirements of the Monitor client  make automatic handover dialogues with the adjacent (via the server) with the neighbouring ATC Units.  make automatic dialogues (via the server) to accept Unit entry conditions proposed by neighbouring ATC Units.  make automatic dialogues (via the server) to accept new routes proposed by neighbouring ATC Units

3.9.5.3.1 Subscriptions with the CS Server The UCWP has the same subscriptions as the Monitor client.

3.9.5.3.2 Interface to the CS Server The UCWP client uses its message receivers to dialogue directly with the server interface. See the atc.coordination.server.AtcCoordinationController for this interface.

3.10 TRAJECTORY PREDICTOR

3.10.1 Description The Trajectory Predictor server, abbreviated TP, provides a source of trajectory data structures, which have been calculated from constraint lists, for use in the eDEP platform. The TP component will usually be coupled with the Flight Management (FM) component, which controls access to trajectory generation processing in the TP, but may also be used to generate trajectories for the airborne flight manager the Pilot Manager or PM. The TP comprises an application made from a scenario object defining each of the flights for which trajectories are to be generated. New trajectories are then signalled to the eDEP platform through Trajectory Update Event. The first constraint passed to the TP will define the latest estimated location of the aircraft, including its plan position and altitude, and second order terms, heading, climb rate and the time. The TP may read aircraft operation and performance data from a scenario file to modify the TP parameters according to flight type. The TP will report its results to the subscribed components. In the case of the FM and PM components, they will interpret the context of a given trajectory type and store it for access by other components in the eDEP. The interface to the TP component is defined in the TPController interface, which is found in the package atc.tp.server.

3.10.2 Context Diagram The following context diagram, Figure 3-19, shows how the TP interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the TP application, and the rectangular boxes indicate other servers in the eDEP platform, which the TP communicates with, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

Subscribe E TimeTickMessage TimeTickMessage S

TP Performance

TrajectoryUpdateEvent E

SubmitConstraints Aircraft FM Performance Data

Figure 3-19 Trajectory Predictor Context Diagram

3.10.3 Use Cases The trajectory predictor receives constraint lists through synchronous calls, and places the request into an event, which will be processed when the request reaches the top of the processing queue. The TP

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 then uses the constraints to calculate a new trajectory, according to the parameters identified in the TP. Once the trajectory has been calculated, an event is signalled to indicate to subscribers that a new trajectory is available. The following sequence diagram shows an example of how the TP is controlled by the flight manager component:

Figure 3-20 Sequence of operations for the TP Component

3.10.3.1 Initialisation  read any aircraft performance data from the performance server.  register TP with lookup/discovery service.  subscribe to time service for regular time signals.

3.10.3.2 Asynchronous Trajectory Generation

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007  receive request to generate trajectory from a set of constraints, for a given flight and tag name. An optional context object may be supplied which will be returned in the resulting event.  store request on local event manager as an immediate event.  when event is signalled generate new trajectory from constraints.  signal a trajectory event for given flight and tag name, and distribute to subscribers

3.10.3.3 Synchronous Trajectory Generation  receive synchronous request to generate trajectory from a set of constraints  generate new trajectory from constraints  return the generated trajectory to the client

3.10.4 Published Events Published Event Description TrajectoryMessage Produced by the TP, this event contains a trajectory object, which defines the best fit 3D/4D trajectory to match the given constraint list. The event identifies the flight and the tag supplied with the original constraints.

3.10.5 Subscribed Events Subscribed Event Description TimeTickMessage Produced by the Time Service, this event is automatically subscribed to by the client side Time Service implementation object, to update the local clock

3.10.6 Trajectory Predictor Interface The trajectory predictor server interface, ..\products\javadoc\atc\tp\server\TPController.html, provides methods to enable users to submit sets of constraint points to the trajectory prediction algorithm, and to subscribe to trajectory messages created on completion of the trajectory generation request. The trajectory predictor server also provides a synchronous method to generate a trajectory from a set of constraints, and to return the generated trajectory. The passed callsign and a trajectory type tag parameters uniquely identify the constraint lists and trajectories. Each of these values is passed into the trajectory event to identify the originating flight/trajectory in the FM. The TPInterface presents a serialized interface to the client component, to support the inter-component messages generated by the Java RMI architecture. The implementation class for this interface defines the TP component controller object and generates the serialised inter-component messages. These are in turn converted into the pure entity data model objects in the client side trajectory service object to provide clean access to the trajectory objects.

3.11 MEDIUM TERM CONFLICT DETECTION

3.11.1 Description The Medium Term Conflict Detection server, abbreviated MTCD, provides a source of conflicts calculated from system trajectories for use in the eDEP platform. Two types of conflict can be calculated: aircraft conflicts and airspace conflicts. The MTCD component is provided with ground trajectory data from the Flight Manager (FM) component, which controls access to ground trajectory information. The MTCD comprises an application made from a scenario object defining each of the flights for which trajectories are available, and for which conflicts are to be generated. New conflicts are then signalled to the eDEP platform through the MTCDUpdateMessage and the AirspaceConflictUpdateMessage. The MTCD may read separation standard data from a scenario file. The MTCD will maintain a database of conflicts, and will allocate unique conflict numbers to the conflicts it detects. These conflicts are made available through synchronous calls, which in future releases can include a filtering capability for access by other components on the eDEP. Contextual traffic may be requested for a flight. These are aircraft that approach within extended separation standards of that flight. Aircraft that are planned to fly in the same vertical flight levels according to their current AFL, CFL, and XFL will be flagged as contextual aircraft if they are conflicting according to the widened lateral separation, but have not been flagged as conflicting according to the normal MTCD conflict detection algorithm. i.e an aircraft can not be conflicting AND contextual. The interface to the MTCD component is defined in the interface ConflictService, which is found in the package atc.cp.client.

3.11.2 Context Diagram The following context diagram shows how the MTCD interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the MTCD application, and the rectangular boxes indicate other servers in the eDEP platform, which the MTCD communicates with, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

MTCDUpdateMessage CWP MTCDContextualTrafficUpdateMessage AirspaceConflictUpdateMessage PVT E

subscribeTrajectoryUpdateMessage Separation AirspaceData Standards S E SystemFlightPlanMessage SFPLDeletedMessage FM ASP

Figure 3-21 – Conflict Probe Context Diagram

3.11.3 Use Cases 3.11.3.1 Initialisation  register MTCD with the lookup/discovery service

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007  subscribe to ground trajectories from the flight manager

3.11.3.2 Asynchronous Conflict Detection  receive ground trajectory update from the flight manager  schedule ground trajectory in an event for processing by the MTCD  when event fires, submit trajectory to the conflict probe algorithm  distribute any detected conflicts to subscribing clients

3.11.3.3 Synchronous Conflict Detection  receive a trajectory through a synchronous call to the MTCD.  submit trajectory to the conflict probe algorithm.  return any detected conflicts to the client from which the request was made.

3.11.3.4 Asynchronous Contextual Conflict Information  request contextual aircraft information for a Flight.  sends out a message containing the aircraft that are not conflicting with the subject aircraft but that are contextual in the sense that they infringe widened separation rules.

3.11.4 Published Events Published Event Description MTCDUpdateMessage Produced by the MTCD, this event contains a set of conflict objects, which identify the points of conflict. MTCDContextualTraffic Produced by the MTCD, when requested by a client. Identifies UpdateMessage contextual aircraft that are 'nearly' conflicting AircraftConflictUpdate Produced by the MTCD, this message contains a list of the current Message airspace conflicts, and a list of airspace conflicts that have been deleted since the last update message.

3.11.5 Subscribed Events Subscribed Event Description SFPLDeletedEvent SystemFlightPlanEvent Consumed by the MTCD to derive the points of closest approach, and the regions in which separation between two flights is lost. The ground trajectory is provided by the Flight Service.

3.11.6 MTCD Server Interface The MTCD server interface, ..\products\javadoc\atc\mtcd\server\MTCDController.html, provides methods to enable users to submit a trajectory for conflict probing synchronously against the current set of trajectories for the active flights in the simulation. Also it provides an asynchronous subscription mechanism to register interest in the generation of new aircraft and airspace conflicts when they are detected from new system trajectories from the flight manager component. The conflict probe server also provides a synchronous methods to retrieve all the current aircraft conflicts from the MTCD database, or to select all aircraft conflicts for a given flight callsign. The server permits a client to request the generation of contextual aircraft for a flight - this is returned using an event to all subscribers. The MTCDController presents a serialized interface to the client component, to support the inter-component messages generated by the Java RMI architecture. The implementation class for

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 this interface defines the MTCD component controller object and generates the serialised inter- component messages. These are in turn converted into the pure entity data model objects in the client side trajectory service object to provide clean access to the trajectory objects.

3.12 FLIGHT PATH MONITOR

3.12.1 Description The flight path monitor component, abbreviated FPM, monitors the track updates from the air traffic generator against the latest ground trajectory information from the flight manager. It may also optionally monitor values entered by the pilot which are down-linked via ADS-B and compared with the current aircraft clearance.

3.12.2 Context Diagram The following context diagram shows how the FPM interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the FPM application, and the rectangular boxes indicate other servers in the eDEP platform, with which the FPM communicates, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

registerForDAPUpdateEvent S DAPUpdateEvent WaypointPassingMessage E SectorCrossingMessage UnitCrossingMessaage DeviationUpdateMessage subscribeTrajectoryUpdateMessage

E S FPM FM E S TrajectoryUpdateMessage subscribeWaypointPassingMessage subscribeSectorCrossingMessage subscribeUnitCrossingMessaage subscribeDeviationUpdateMessage S subscribeTrackUpdateMessage E TrackUpdateMessage

Figure 3-22 Flight Path Monitor Context Diagram

3.12.3 Use Cases 3.12.3.1 Initialisation  Subscribe trajectory update messages  Subscribe track update messages.  Optionally, subscribe to DAP update messages (Downlinked Aircraft Parameters)

3.12.4 Published Events Published Events Description DeviationMessage Produced by the Monitor Service, the deviation event is signalled when the flight is calculated to be deviating by more than the allowed tolerance from its planned flight path defined by the ground trajectory. PACListMessage Produced by the Monitor Service when a new SystemFlightPlan is generated to indicate the Prepared Clearances that need to be issued to guide the aircraft on a non-cleared trajectory. PACMessage Produced by the Monitor Service a short time before the ATC Controller needs to issue the contained Prepared Clearance for the associated aircraft. SectorCrossingMessage Produced by the Monitor Service, the sector crossing event signals the point at which the flight crosses from one sector into another. It identifies the 4D location and the nearest COP. UnitCrossingMessage Produced by the Monitor Service, the unit crossing event signals the point at which the flight crosses from one unit into another. It identifies the 4D location and the nearest COP. WaypointPassedMessage Produced by the Monitor Service, the fix passing event signals the point at which the flight passes a fix point on its plan. It identifies the 4D location of the passing point, the fix passed and the next fix to pass. PilotConformanceAlertM Produced by the Monitor Service to indicate that the pilot of the essage associated aircraft is not conforming to a given ATC Clearance. Another message is subsequently issued to inform the client if the pilot starts to conform to the Clearance.

3.12.5 Subscribed Events Subscribed Events Description TrajectoryUpdateMessage Produced by the Flight Service, the ground trajectory event provides the planned path of the aircraft, against which the tracks from the IAS component will be monitored. TrackUpdateMessage Produced by the Track Service, the track update event provides a set of track positions, from which the FPM will monitor the progress of the flight against the latest ground trajectory. DAPUpdateMessage Produced by the DAPService, the message contains the DAP data downlinked by all the ADSB-equipped aircraft.

3.12.6 Flight Path Monitor Interface The flight path monitor server interface, ..\products\javadoc\atc\fpm\server\FPMController.html, provides methods to enable users to access an object holding details of the latest monitoring events to be signalled for the given flight, and to subscribe to a number of monitoring events signalled asynchronously. The FPMController presents a serialized interface to the client component, to support the inter-component messages generated by the Java RMI architecture. The implementation class for this interface defines the FPM component controller object and generates the serialised inter- component messages. These are in turn converted into the pure entity data model objects in the client side trajectory service object to provide clean access to the monitor objects.

3.13 SHORT TERM CONFLICT ALERT

3.13.1 Description The Short Term Conflict Alert server, abbreviated STCA, provides a source of STCA conflicts calculated by dead reckoning the projected flight path from track data, for use in the eDEP platform. The STCA component is provided with track data from the Integrated Air Surveillance (IAS) component, which controls access to track information. The STCA comprises an application made from a scenario object defining each of the flights for which track data is available, and for which STCA conflicts are to be generated. New STCAs are then signalled to the eDEP platform through the STCAUpdateEvent. The STCA may read separation standard data from a scenario file. The STCA component maintains a database of STCA conflicts, and allocates unique STCA numbers to the detected STCAs. These conflicts are made available through synchronous calls, which in future releases can include a filtering capability for access by other components on the eDEP. The interface to the STCA component is defined in the interface STCAService, which is found in the package atc.stca.client. The following diagram shows the main processing sequence of the STCA component:

Figure 3-23 STCA Processing Sequence

3.13.2 Context Diagram The following context diagram shows how the STCA component interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the STCA application, and the rectangular boxes indicate other servers in the eDEP platform, with which the STCA communicates, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

CWP subscribeSTCAMessage S subscribeAPWMessage E STCAMessage APWMessage STCA STCA separation parameters subscribeTrackUpdateMessage S E TrackUpdateMessage

IAS Figure 3-24 STCA Server Context Diagram

Area Proximity warnings are generated by the STCA component when a flight enters or is about to enter a restricted area. By default, this functionality is disabled and can be enabled by a user configurable resource. The distance of the restricted area (in time) ahead of the flight when an APW will be sent is also user configurable. An APWCreationEvent is sent for the start of the APW and an APWDeletionEvent is sent for the end.

3.13.3 Use Cases 3.13.3.1 Initialisation  register STCA with the lookup/discovery service  subscribe to track updates from the IAS

3.13.3.2 Asynchronous STCA Detection  receive track updates from the air traffic generator  schedule tracks in an event for processing by the STCA  when event fires, submit tracks to STCA probe algorithm  distribute any detected STCA to subscribing clients

3.13.3.3 Area Proximity Warning Detection  receive track updates from the air traffic generator  schedule tracks in an event for processing by the STCA  when event fires, submit tracks to APW algorithm  distribute any detected APW creation / deletion events to subscribing clients

3.13.4 Published Events Published Events Description ConflictUpdateMessage Produced by the STCA server, the STCA message signals the point at which one flight is predicted to lose separation from another flight on the basis of the latest track information. The STCA identifies the predicted 4D location of the point of loss of separation and the estimated point of closest approach. APWCreatedEvent Event produced when the STCA server detected that a flight has entered or is about to enter a restricted area. APWDeletedEvent Event produced when the STCA server detected that a flight has left a restricted area.

3.13.5 Subscribed Events Subscribed Events Description TrackUpdateMessage Produced by the Track Service, the track update event provides a set of track positions, from which the STCA will determine the point at which any separation infringements will occur.

3.13.6 STCA Interface The STCA server interface, ..\products\javadoc\atc\stca\server\STCAController.html, provides methods to enable users to access an object holding details of the latest monitoring events to be signalled for the given flight, and to subscribe to a number of events monitoring events signalled asynchronously. The FPMController presents a serialized interface to the client component, to support the inter-component messages generated by the Java RMI architecture. The implementation class for this interface defines the FPM component controller object and generates the serialised inter- component messages. These are in turn converted into the pure entity data model objects in the client side trajectory service object to provide clean access to the monitor objects.

3.14 CWP COMMUNICATION SERVICE

3.14.1 Description The CCS is a pure communication component, which permits CWPs, within a given unit (i.e. Planner and Tactical positions), to communicate together. This communication tends to have either a strong graphical, or a strong team-working nature. Examples of intra-unit communication include  ‘marking’ an a/c on one position causes it to be marked on another (e.g. highlighting)  delegating conflicts & workload between PC and TC positions This component is used in parallel with the CS component, which specialises in issues of inter-sector co-ordination (i.e. it embodies business logic).

3.14.2 Context Diagram The CCS’s context diagram is shown in Figure 3-25 below. E CommMessage

subscribeCommMessage CWP S CCS D

Figure 3-25 CCS Context Diagram

3.14.3 Use Cases The CCS use case is extremely simple:  CWPs subscribe to the CCS at startup, identifying their area of interest (i.e. the unit for which they work)  CWPs post Communication messages at appropriate times, and these messages are forwarded to all CWPs within the unit.

3.14.4 Published Events Published Events Description CommMessage A Communication message defining the component sender/receiver, unit (subclasses of) sender/receiver, and application message content.

3.14.5 CCS Interface The CCS interface, ..\products\javadoc\atc\ccs\server\CCSController.html, offers a generic (i.e. non ATC) set of services for  Subscribing to arbitrary event topics, with optional application-provided filter criteria  Posting Communication events to arbitrary event topics.

3.15 CONTROLLER WORKING POSITION

3.15.1 Description The Controller Working Position component, abbreviated to CWP, provides a pure client component on the eDEP. The CWP will initialise by fetching airspace data from the ASP, and flight information from the Flight Manager FM. Regular track updates, together with DAP (ADS-B) reports, will be provided by the IAS component. The CWP is provided with trajectory data from the Flight Manager (FM) The CWP comprises an application made from a scenario object defining each of the aircraft flights, the controlled sector and neighbouring sectors, airways and beacons. The aircraft coordination state is updated by subscription to Coordination events supplied by the Coordination server. The CWP can be designated as a TACTICAL (or EXECUTIVE), PLANNER, FEEDER or HYBRID type. These designations do not change the functionality of the CWP, except the HYBRID enables orders to be sent to the pilot manager. The designations can be used to configure how the division of operational procedures is split between positions controlling the same sector/unit. A FEEDER position will be allocated all procedural functions. The HYBRID CWP is described below. The CWP can also provide a combined CWP/PWP position by providing functionality associated with the Pilot Working Position (described in section 3.17) to control a flight directly. Such a CWP is described as a hybrid CWP or hCWP. The hybrid functionality is identified by the categorisation of the CWP as of type HYBRID, defined in the resources file. This CWP will subscribe to the Pilot Manager (PM), which provides aircraft trajectory information and an interface to send pilot orders to make aircraft manoeuvres (rather than manipulation of the ground plan performed by the conventional CWP). The CWP component does not define an interface, as it is implemented as a pure client component.

3.15.2 Context Diagram The following context diagram shows how the CWP component interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the CWP application, and the rectangular boxes indicate other servers in the eDEP platform, which the CWP component communicates with, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

D/L Subscribe STCA STCAMessage CCS S commMessage registerForDownlinkEvent PostCommMessage S S registerForACLTransmissions ASP E

R CoordinationMessage Config CoordinationStateMessage loadAirspace CS File S CWP

S IAS TrackUpdateMessage SubscribeFix TimeTickMessage S PassingMessage S S transferFrequency S transferFrequencyMessage TS setDirectTo SubscribeFlightPlanMessage setHeading SubscribeTrajectoryMessag setCFL FPM PM setSpeed FM

Figure 3-26 Controller Working Position Context Diagram

3.15.3 Use Cases 3.15.3.1 Initialisation  Subscribe to time tick messages  Subscribe to MTCD conflict messages  Subscribe to FPM deviation alerts.  Subscribe to Datalink downlink and transmission events (if datalink enabled)

3.15.4 Published Events The CWP does not define any external events for eDEP; the CWP is a pure client component.

3.15.5 Subscribed Events Subscribed Events Description TrackUpdateMessage Produced by the Track Service, the track update event provides a set of track positions, from which the STCA will determine the point at which any separation infringements will occur. DAPUpdateMessage The DAP update message provides notification of DAP information received by the IAS. DatalinkEvent The DatalinkEvent provides messages downlinked from the aircraft, and echoes of messages that were transmitted to the aircraft.

3.15.6 Controller Working Position Interface The CWP does not define an external interface for eDEP; the CWP is a pure client component.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.16 PILOT MANAGER

3.16.1 Description The Pilot Manager component, abbreviated to PM, provides a flight data server for the Pilot Working Position (PWP) and the ground based Integrated Air Surveillance (IAS) components on eDEP. The PM will initialise by fetching airspace data from the Airspace server (ASP). The pilot manager will provide services to allocate aircraft to subscribed PWP components. In particular, the PM will distribute aircraft on a particular frequency to one of the PWP components serving that frequency, subject to a given heuristic algorithm. By default it will simply allocate the aircraft to the PWP with the least active aircraft under its control. The PM provides services to manoeuvre aircraft and to provide reports on the progress of an aircraft both with respect to its flight plan and its clearances. The PM also provides a subscription service for DAP data generated for datalink equipped aircraft, and subscribes to receive DAP reports from cockpits connected via the ADS-B proxy server component. The PM comprises an application made from a scenario object defining each of the piloted flights. The flights are initialised from an initial flight plan supplied from the IFPL server. The interface to the PM component is defined in the interface PilotFlightService, which is found in the package atc.pm.client. The Pilot Manager also acts as a host for the platform’s datalink functionality.

3.16.2 Context Diagram The following context diagram shows how the PM component interfaces with other servers in the eDEP platform. The IFPL, CWP, TP and ASP servers will be shared with the ground subsystem and the hybrid CWP component forms an element of the ground subsystem. The circle in the centre of the diagram indicates the limits of the PM application, and the rectangular boxes indicate other servers in the eDEP platform, which the PM component communicates with, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

ASP setDirectTo TP setHeading Submit setCFL Constraints setSpeed loadAirspace transferToFrequency R R S Subscribe R TrajectoryMessage E Subscribe InitialFlightPlanMessage E S PWP PM IFPL Subscribe S E AircraftFlightPlanMessage InitialFlightPlanMessage AircraftTrajectoryMessage TimeTickMessage WaypointPassedMessage StateVectorMessage StateVectorMessage E TS FrequencyTransferMessage R S Subscribe S FrequencyTransferMessage TransferToFrequency IAS hCWP

Figure 3-27 – Pilot Manager Context Diagram The diagram in Figure 3-28 below shows how the pilot manager relates to other components in the system, forming the core of the air subsystem, but also making use of components shared with the ground subsystem, including the TP, FPM and Airspace servers. The tracks are generated as radar plots within the PM, from trajectories calculated by the component or from DAP reports received

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 from the ADS-B component. These tracks are then processed by the ground based air surveillance component, IAS, before being passed on as correlated tracks to the ground sub system. Note also that the pilot manager processes pilot orders both from the air-side pilot working position, PWP, and the ground-side hybrid controller working position, hCWP. The hybrid CWP can perform the role of a feeder unit, as well as issuing aircraft manoeuvre instructions. The FPM could be instantiated as a separate air-side component, or use a common FPM configured through the subscription requests to the component to use ground trajectories in the ground subsystem and to use aircraft trajectories in the air subsystem. The shared FPM would have to subscribe to PM state vectors rather than IAS tracks.

COMMON SUBSYSTEM

TS APS IFPL ASP FPM TP

Initial Airspace Airspace Progress Flight against Aircraft Plans ground TP Performance Data Aircraft Initial Trajectory Flight Plans

Tracks State Vectors Tracks Tracks PM IAS FM

Aircraft trajectories Pilot orders Tracks Frequency Changes Progress monitor Pilot orders Frequency changes Query orders Report requests Frequency Requests CWP CWPCWP PWP hCWP PWPPWP

AIR SUBSYSTEM GROUND SUBSYSTEM

Figure 3-28 Relationship between Air and Ground Subsystems Figure 3-29 shows the relationship between air and ground subsystems in datalink mode.

hCWP Pilot orders Frequency Changes

Tracks Tracks PM IAS FM

Aircraft trajectories Tracks Progress monitor Pilot orders PPD + Frequency changes Query orders ACLPilotRequests Report requests Frequency Requests CWP CWPCWP PWP PWPPWP

AIR SUBSYSTEM GROUND SUBSYSTEM

Figure 3-29 Relationship between Datalinked Air and Ground Subsystems

3.16.3 Use Cases 3.16.3.1 Initialisation  register PM with the lookup/discovery service  subscribe to time update events  subscribe to initial flight plans from the IFPL  subscribe to progress monitoring events against FMS prediction from FPM  subscribe to DAP report events from the ADS-B proxy server

3.16.3.2 Initial Flight Plan Processing  receive initial flight plan from the IFPL server  submit expanded aircraft constraints to the TP for trajectory generation  when trajectory event fires, receive new aircraft trajectory for the flight

 distribute new aircraft trajectory to subscribed clients, including PWP and hCWP

3.16.3.3 Process Pilot Order  receive a synchronous pilot order from a PWP or hCWP  modify the existing constraint list to fly the pilot order manoeuvre  submit the new constraint list to the TP for trajectory generation  record the pilot order in an order history for the flight  set/unset the relevant operational mode in the FlightControlUnit  update current aircraft clearance  distribute clearance to subscribed clients

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007  when trajectory event fires, receive updated aircraft trajectory for the flight

 distribute updated aircraft trajectory to subscribed clients, including PWP, FPM and hCWP

3.16.3.4 Waypoint Passed Event  generate asynchronous waypoint passed event on state vector update  update current clearance  distribute waypoint passed to subscribed clients

3.16.3.5 Processing a Frequency Change  receive a synchronous request to change frequency from the PWP currently controlling flight  reset the active frequency of the flight to the new frequency  distribute new frequency to interested PWP clients, along with current pilot order history.

3.16.3.6 DAP Report Updates  Receive DAP data from the ADS-B proxy server  Store DAP data with an associated eDEP aircraft  Generate and store DAP data for each ADSB_equipped aircraft not receiving DAP data from the ADS-B proxy server

3.16.3.7 State Vector Updates  Subscribe to regular time tick updates  determine a new aircraft position an the time tick update in the PM  create a state vector message using this new position and available DAP data (if ADSB- equipped)  distribute the state vector to subscribed PWPs, and the IAS in ground system

3.16.4 Published Events Published Event Description ClearanceMessage FrequencyTransferMessage Produced by the PM, this event identifies when the aircraft changes frequency to allow control from a different sector, and hence control from a different PWP. The PM will allocate a particular PWP to control the aircraft that is changing frequency. InitialFlightPlanMessage StateVectorMessage Produced by the PM, this event identifies positional updates made by the aircraft as it proceeds along its predicted trajectory. When a flight reaches the end of its plan, the state vectors are marked as deleted to indicate the end of the flight. May also contain DAP ADS-B data. WaypointPassedMessage Produced by the PM, this event identifies when the aircraft has passed a waypoint or beacon on its route plan. ADSBReportMessage Produced by the PM, this event identifies DAP updates generated for datalink equipped aircraft. ILSLockOnAchieved Raised when a flight locks onto the ILS.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 ILSLockOnBroken Raised when a flight has broken the ILS.

3.16.5 Subscribed Events Subscribed Event Description TrajectoryUpdateMessage The trajectory update is provided by the Trajectory Service of the TP component. InitialFlightPlanMessage The initial flight plan event is provided by the Flight Plan Service of the IFPL component. GeneratedADSBMessage The generated ADS-B message is provided by the ADS-B proxy server when a connected cockpit generates and requests transmission of DAP data to subscribers.

3.16.6 Pilot Manager Server Interface The pilot manager server interface, ..\products\javadoc\atc\pm\server\PMController.html, provides an asynchronous subscription mechanism to register interest in the generation of new and updated aircraft trajectories. It also provides of new conflicts when they are detected from new system trajectories from the flight manager component. The conflict probe server also provides a synchronous methods to retrieve all the current conflicts from the CP database, or to select all conflicts for a given flight callsign. The PMController presents a serialized interface to the client component, to support the inter-component messages generated by the Java RMI architecture. The implementation class for this interface defines the PM component controller object and generates the serialised inter-component messages. These are in turn converted into the pure entity data model objects in the client-side trajectory service object to provide clean access to the trajectory objects.

3.17 PILOT WORKING POSITION

3.17.1 Description The Pilot Working Position component, abbreviated PWP, provides an HMI that provides a set of control functions and flight order functions to simulate the actions of an aircraft pilot. The PWP subscribes to information from the Pilot Manager, (PM), the Airspace Server (ASP) and the Aircraft Performance Server (APS). The PM provides aircraft trajectory data, state vectors, flight plan progress reports and flight destruction events. The PWP comprises an application made from a scenario object defining each of the piloted flights that are controlled by this PWP position. The flights are created and destroyed as they are transferred between PWPs controlling adjacent frequencies. Thus when a flight is transferred into a PWP it is created in that PWP, and when it is transferred out of the PWP, it is destroyed. The PWP describes a pure client component and does not define an external interface.

3.17.2 Context Diagram The following context diagram shows how the PWP component interfaces with other servers in the eDEP platform. The APS and ASP servers will be shared with the ground subsystem. The circle in the centre of the diagram indicates the limits of the PWP application, and the rectangular boxes indicate other servers in the eDEP platform, which the PWP component communicates with, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

beacons Aircraft Performance ASP PWP aircraft performance data (future versions only) Server

subscribeTrajectoryEvents registerForUplinkEvent subscribeInitialFlightPlanEvents registerForACLTransmissions subscribeStateVectorEvent subscribeWaypointPassedEvents Pilot orders subscribeClearanceEvem t subscribeTransferFrequencyEvent

Figure 3-30 Pilot Working Position Context Diagram

3.17.3 Use Cases The following use cases have been identified. These relate to communication with the PM.

3.17.3.1 Initialisation Upon initialisation, the PWP shall:  input the PWP resources file;  subscribe to PilotedFlightCreation events;  subscribe to PilotedFlightDeletion events;  subscribe to datalink uplink and transmission messages (if datalink enabled); and  inform the PM of the frequencies it manages. The frequencies managed by a PWP shall be specified off-line in the PWP resources file.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.17.3.2 Piloted Flight Creation A Piloted Flight Creation event is received when either an aircraft has started its navigation or it has been transferred from another PWP. Upon receipt of a Piloted Flight Creation event, the following actions shall be performed:  The flight shall be stored in the PWP’s Piloted Flight Entity database.  The flight shall be displayed in the Flight Strips Panel. The callsign shall be displayed in the FLIGHT_STRIP_PANEL_FIELD_HIGHLIGHT1 colour.  The flight shall be displayed in the PVD.  The flight’s details shall be displayed in the Detailed Flight Information Panel, only if the pilot is not constructing an order for another flight.

3.17.3.3 Transfer Flight This use case occurs when a pilot transfers an aircraft to an adjacent PWP. The following actions shall be performed.  The flight shall be deleted from the PWP’s Piloted Flight Entity database.  The flight shall be deleted from any panels in which it is displayed.  If the flight is displayed in the PVD, it shall be removed. The PVD shall remain empty until another flight is selected.  Any orders currently under construction shall be aborted.

3.17.3.4 Piloted Flight Deletion A Piloted Flight Deletion event is received when an aircraft has reached the end of its trajectory or the supervisor kills the aircraft2. The PWP performs the actions detailed in the Transfer Flight use case.

3.17.4 Published Events The PWP does not define any external events for eDEP; the PWP is a pure client component.

3.17.5 Subscribed Events Subscribed Event Description ClearanceEvent The PWP subscribes to clearance messages to ensure that aircraft clearances are correctly displayed. InitialFlightPlanMessage The PWP subscribes to InitialFlightPlanMessages, generated by the PM, to display flights in the PWP. StateVectorMessage StateVectorMessages are used to update an aircraft’s current position. TrajectoryUpdateMessage The PWP subscribes to TrajectoryUpdateMessages to update aircraft trajectories. WaypointPassedMessage The PWP subscribes to WaypointPassedMessages, generated by the PM, to update the flight strips panel.

3.17.6 Pilot Working Position Interface The PWP does not define an external interface for eDEP; the PWP is a pure client component.

1 Green 2 There is currently no supervision position and, therefore, no method of killing an aircraft.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.18 ARRIVAL MANAGER

3.18.1 Description The AMAN (Arrival Manager) component is responsible for: a) Maintaining a list of aircraft landing on each runway. b) Allocating touch-down and take-off slots appropriate to the runway acceptance rates and aircraft separation standards. c) Exporting a RunwaySchedule object that contains the sequencing information (sequence number, relative separation distances, and time at the IAF) for a particular runway.

The AMAN computes a landing schedule for aircraft landing at each runway based on the original predicted landing time taken from the System Trajectory, and on a first-come-first served basis. From this schedule the AMAN uses the runway acceptance rates and separation standards (including wake vortex) to calculate a new time at the Initial Approach Fix that sequences the arrival aircraft as close together as possible at the destination runway. There is no optimisation such that aircraft are requested to go faster to fill slots, or re-ordered due to wake vortex problems. The sequence of arriving aircraft at a runway is encapsulated in a RunwaySchedule, which contains the aircraft callsigns, sequence numbers and the relative separation data. This information is required in the Landing List Window displayed in the CWP. The AMAN has the ability to consider other types of runways slots. Currently the AMAN is able to schedule three types of movement:  RunwayArrival  RunwayDeparture  RunwayClosure The AMAN also incorporates the notion of operational horizon to help stabilise the effect of unwanted re-sequencing of aircraft during the duration of its flight. The value of the horizon is one of: ACKNOWLEDGED; ELIGIBLE; ACTIVE; or FIXED. Aircraft are taken into account by the AMAN when they enter the ACKNOWLEDGED horizon, during which aircraft are sequenced according to their estimated time of arrival on a first-come-first-serve basis. The other states are not currently used, but are included for compatibility with the OSYRIS AMAN. It uses these states to dampen down the sequence changing as the aircraft move toward their destinations. This is not currently needed in the eDEP AMAN since the flights are loaded in advance, and the flight trajectories do not alter with time.

3.18.2 Context Diagram

The AMAN context diagram is shown in Figure 3-31 below.

WakeupMessage E S subscribeWakeupMessage

subscribeSystemFlightPlanMessage subscribeRunwayScheduleMessage S S AMAN FM E E RunwayScheduleMessage

SystemFlightPlanMessage

Figure 3-31 – AMAN Context Diagram

Published Events Description RunwayScheduleMessage Produced by the AMAN component and contains a RunwaySchedule object for a managed runway; this schedule contains a ManagedRunway (describing the destination runway separation and throughput information) and a list of RunwayMovements that have been scheduled at the runway. Each RunwayMovement contains the requested, allocated, and earliest slot times that the movement will occupy the runway. The RunwayMovement for an arrival aircraft is encapsulated in a subclass called RunwayArrival, and contains information concerning the crossing of the IAF (Initial Approach Fix), including: the initial ETO; the RTO; and the time-to-lose.

3.18.4 Subscribed Events

Subscribed Events Description SystemFlightPlanMessage Produced by the FlightManager component when there has been an update to a trajectory or a change in a unit or sector crossing list. The AMAN then needs the Trajectory, FlightPlan, and STAR objects in order to calculate a RunwaySchedule. WakeupMessage Produced by the TimeService. Used to ask for an update when the aircraft changes Horizon in the AMAN tool.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.18.5 Server Interfaces The AMAN Server Interface is defined in ..\products\javadoc\evp\aman\server\AmanController.html.

3.19 EN-ROUTE MANAGER

3.19.1 Description The EMAN (En-Route Manager) component is responsible for: a) Exporting SequenceInfo objects that contain sector exit RTO (Required Time Over) advisories for all the en-route sectors of a flight that have been configured to absorb delays requested by AMAN. The configuring of the delay that may be absorbed in each sector is stated in an airspace Agreement and loaded at simulation start-up. The EMAN also has a "notifyUnitExitPlanned" method so that a sector can declare that it has fixed its exit conditions; the remaining delay is then again shared out over the remaining en- route sectors. b) Exporting TrafficPoint objects at which traffic problems exist. These points are configured in a resource file and consist of geographical points near which traffic-load needs to be monitored in the current airspace. The TrafficPoint object contains a list of all the Flights that approach within a pre-defined distance of the associated position together with the points of nearest approach, and it is sent out each time that the flight proximity list changes. c) Exporting AlternateRoutes objects that define a set of alternate routes that a controller in a particular sector may consider for a flight exiting through a particular COP (Coordination Point) and going to a particular destination. These alternate routes are configured in a resource file. d) For each updated Flight trajectory, exports a list of the names of the TrafficPoints that are on the flight path.

Time Service Aman Service WakeUpMessage via scheduler, subscribes to:

subscribeWakeupMessage RunwayScheduleUpdateEvent

RunwayScheduleUpdateEvent FlightTrafficInfoMessage SequenceInfoMessage

TrafficPointMessage EMAN registerForSystemFlightPlanEvent registerForSFPLDeletedEvent

registerForAllHandoverEvent

Flight Service Coordination SystemFlightPlanEvent Monitor HandoverEvent SFPLDeletedEvent Service

Figure 3-32 – EMAN Context Diagram

Published Events Description SequenceInfoMessage Produced by the EMAN component; contains new advisory data for an aircraft along its flight (for an RTO at the IAF supplied by AMAN) and the landing sequence number of the aircraft for the target runway. The SequenceInfo is attached to the SequencedFlight object by the EmanService. FlightTrafficInfoMessage Produced by the EMAN component; issued for each updated aircraft trajectory in the system, and contains a list of the TrafficPoint names that the trajectory passes through. The TrafficInfo is attached to the SequencedFlight object by the EmanService. TrafficPointMessage Produced by the EMAN component; issued for a TrafficPoint whenever the list of aircraft in proximity to that point have changed. The message contains the list of flight proximities. A flight proximity contains: the name of the Flight, the trajectory tag of the trajectory, and the point of closest approach to the TrafficPoint.

3.19.4 Subscribed Events

Subscribed Events Description SystemFlightPlanMessage Produced by the FlightManager component when there has been an update to a trajectory or a change in a unit or sector crossing list. On receipt of a new SystemFlightPlan, the EMAN updates the sector advisories for meeting the AMAN time constraints at the IAF, and also the traffic information at the TrafficPoints. SFPLDeletedEvent Produced by the FlightManager component when a SystemFlightPlan is deleted. EMAN uses this event to remove unwanted data structures from the server for flights which no longer exist. RunwayScheduleUpdateEvent Produced by each of the AMAN servers when a runway schedule is updated. EMAN uses this schedule to re-calculate the sector advisories which indicate how controllers should absorb the delay resulting from the AMAN time constraints at the IAF points. HandoverEvent Produced by the Coordination server. EMAN uses this message to trigger a re-calculation of the sector exit RTO advisories for a flight as is crosses a sector boundary. WakeupMessage Produced by the TimeService. AMAN uses a regular time event in order to update the traffic at each of the TrafficPoints as the flights advance along their trajectories.

3.19.5 Server Interfaces The EMAN Server Interface is defined in ..\products\javadoc\evp\eman\server\EmanController.html.

3.20 TRAFFIC EDITOR / PROFILE VALIDATION TOOL

3.20.1 Description The eDEP Profile Validation Tool (PVT) is a data modification/validation tool which allows flight plans, trajectories, conflicts, and environment data to be viewed and modified in an off-line mode. The PVT is launched with a number of FDPS components present in the live simulator system, allowing the off-line tool to exhibit WYSIWYG (What you see is what you get) principles.

3.20.2 Context Diagram The following context diagram shows how the PVT component interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the PVT application, and the rectangular boxes indicate other servers in the eDEP platform, with which the PVT communicates, either through subscription to an event, or by a direct synchronous call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file. MTCD ACR

Subscribe ASP MTCDUpdateMessage

S R loadAirspace getAircraftTypes R

Config File FM PVT S subscribeFlightPlanMessage subscribeTrajectoryMessage subscribeSystemFlightPlanMessage

R createFlightPlan modifyFlightPlan

Figure 3- 3-33 PVT Server Context Diagram

3.20.3 Use Cases 3.20.3.1 Initialisation  register PVT with the lookup/discovery service  load airspace and aircraft types  subscribe to FM and MTCD messages

3.20.3.2 Flight Plan Edition  User edits the flight plan via the HMI  A new or modified Flight Plan is sent to the IFPL component

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007  This in turn, causes the FM and MTCD components to recompute.

3.20.4 Published Events Not applicable. The PVT is a pure client, and hence, does not publish any events.

3.20.5 Subscribed Events Subscribed Events Description subscribeMTCDUpdateMessage Produced by the MTCD when conflicts are updated subscribeSystemFlightPlanMessage Produced by the FM when the trajectory, sector & unit crossing lists change subscribeFlightPlanMessage Produced by the FM when flight plans are updated

3.20.6 PVT Interface The PVT component is a pure client, and hence offers no services. The PVT’s interface is defined in ..\products\javadoc\atc\tools\pvt\server\PVTController.html.

3.21 STORIA DATA RECORDING COMPONENT

3.21.1 Description The REC component is responsible for the recording of the following data:  Airspace  Radar tracks,  STCA Conflicts,  Pilot Orders  Trajectory Updates  Datalink Orders  Assume/Transfer Orders. The data recorder can record tracks either from the Air subsystem or from the Ground subsystem. The data recorded are written to an XML file (offline recording). This component listens to events it is interested in. It also offers a service to CWPs in order to record specific CWP data. The data recording is compliant with the STORIA XML grammar. The currently supported versions of the grammar are:  STORIA 2004Bbis  STORIA 2005A  STORIA 2005B More details on the grammar, and eDEP recordings’ compliance with it can be found in the EEC DDD [Ref. 3].

PM ASP registerForStateVectorEvent StateVectorMessage registerForTransferFrequencyEvent FrequencyTransferMessage loadAirspace registerForWaypointPassedEvent E TrajectoryMessage registerForTrajectoryEventS WaypointPassedMessage TimeTickMessage FPM SectorCrossingMessage TimeControlMessage E S registerForSectorCrossingEvent TS TimeAcceleratedMessageE subscribeTimeTickMessage S REC E HandoverMessage registerForTimeControlEvent S CS registerForShortTermConflictDestructionEvent registerForTimeAcceleratedEvent registerForShortTermConflictCreationEvent registerForAllHandoverEvent registerForShortTermConflictsEvent E InitialFlightPlanMessage S ShortTermConflictDestructionEvent TrajectoryMessage ShortTermConflictCreationEvent registerForInitialFlightPlanEvent ConflictUpdateMessage E S W S E registerForTrajectoryEvent recordCWPData FM registerForTrackUpdateEvent STCA TrackUpdateMessage CWP IAS

Figure 3-34 STORA Data Recording Component Context Diagram

3.21.3 Use Cases 3.21.3.1 Initialisation  register REC with the lookup/discovery service  load airspace  register to PM, FPM, IAS, CS, FM, STCA and TS messages  initialise data recorder

3.21.3.2 Record tracks  receive track updates from the Piloted Flight Server or the Track Server  for all tracked flights in the Piloted Flight Manager, resp. the Flight Manager, write track details in an XML String  either save the XML String in a file or send it to the STORIA API

3.21.3.3 Record pilot orders  receive pilot orders from the Piloted Flight Server  write pilot order details in an XML String  either save the XML String in a file or send it to the STORIA API

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.21.3.4 Record conflicts  receive STCA conflict updates from the Short Term Conflict Server  for each conflict, write details in an XML String  either save the XML String in a file or send it to the STORIA API

3.21.3.5 Record coordination  receive handover events from the Coordination Server  for ASSUME and TRANSFER actions only, write handover details in an XML String  either save the XML String in a file or send it to the STORIA API

3.21.3.6 Record CWP  receive recording requests from CWP  write CWP data in an XML String  either save the XML String in a file or send it to the STORIA API

3.21.4 Published Events Not applicable. The Data Recording component is a pure client, and hence, does not publish any events.

3.21.5 Subscribed Events Subscribed Events Description ConflictUpdateMessage Produced by the Short Term Conflict Service, it defines a complete set of active Short Term Conflict Alerts. FrequencyTransferMessage Produced by the Piloted Flight Service, this event identifies when the aircraft changes frequency to allow control from a different sector, and hence control from a different PWP. The PM will allocate a particular PWP to control the aircraft that is changing frequency. HandoverMessage Produced by the Coordination Service, it indicates that a flight has changed from one state into another. InitialFlightPlanMessage Produced by the Flight Service, this event contains a new flight plan definition, and will cause a new flight to be created. SectorCrossingMessage Produced by the Monitor Service, the sector crossing event signals the point at which the flight crosses from one sector into another. It identifies the 4D location and the nearest COP. ShortTermConflictCreation Produced by the Short Term Conflict Service, it indicates the creation Event of a new Short Term Conflict Alert. ShortTermConflictDestruct Produced by the Short Term Conflict Service, it indicates the ionEvent destruction of a Short Term Conflict Alert. StateVectorMessage Produced by the Piloted Flight Service, it informs the state vectors have been updated. TimeAcceleratedMessage Produced by the Time Service, it informs that the clock has been accelerated.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 TimeControlMessage Produced by the Time Service, it informs that the clock has been STARTED, FROZEN, UNFROZEN. TimeTickMessage Produced by the Time Service, this event is automatically subscribed to by the client side Time Service implementation object, to update the local clock. TrackUpdateMessage Produced by the Track Service, it informs the tracks have been updated. TrajectoryMessage Produced by the Piloted Flight Service, this event contains a trajectory update. TrajectoryMessage Produced by the FM Service, generated from the trajectory predictor component, this event will contain the calculated trajectory points from a previously submitted set of constraint points. The type of the trajectory (ground, proposal etc.) is identified from a tag name. WaypointPassedMessage Produced by the Piloted Flight Service, this event identifies when the aircraft has passed a waypoint or beacon on its route plan.

3.21.6 REC Interface The REC interface is specified in ..\products\javadoc\eec\storia\rec\server\RECController.html.

3.21.6.1 Record CWP Data Records the data passed in from a CWP.

3.22 ACE EDEP GATEWAY Full details of the ACE-eDEP Gateway (AEG) are now given in the AEG Design Document [Ref. 4].

3.23 AIRCRAFT TYPES / BADA SERVER

3.23.1 Description The Aircraft Types component is responsible for automatically detecting and modelling aircraft performance upon startup. It creates the parameters which the Trajectory Predictor uses to model aircraft flight curves. When resources dictate, it can load, parse and return data taken from BADA files. . It creates an entity list of AircraftType objects, designed for an easy transition to AircraftPerformance objects.

3.23.2 Context

loadAircraftPerformance

PVT Aircraft / R BADA data ACR

R loadAircraftPerformance TP

3.23.3 Use Cases 3.23.3.1 Initialisation  Provide full details of aircraft types to either TP or PVT to enable performance profiling

3.24 METEO SERVICE

3.24.1 Description The Meteo service (MET) provides access to current and predicted meteo information. The Meteo Service comprises an application comprising a scenario object defining Weather entities that describe weather in a volume of airspace at a point in time, that is valid for a given period. The Meteo service offers both synchronous and asynchronous methods to retrieve weather information for:  A given 4D point.  A series of 4D points, defining a route.  All weather information held in the Meteo database. In addition, the Meteo service offers subscription access to significant meteo events. The interface to the MET component is defined in the MetController interface, which is found in the package atc.meteo.server.

3.24.2 Context Diagram The following context diagram, Figure 3-35, shows how the MET interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the Meteo application, and the rectangular boxes indicate other servers in the eDEP platform that the Meteo service communicates with, either through subscription to an event, or by a direct synchronous call to a remote method. The cylindrical shape in the diagram represents the Meteo data initialisation file.

Subscribe E TimeTickMessag TimeTickMessage S e

Meteo Client GetMet(point(S)) R Meteo

SigMetEvent

Meteo E Data

Figure 3-35 Meteo Service Context Diagram

3.24.3 Use Cases 3.24.3.1 Initialisation  subscribe to time service for regular time signals.  Load Meteo data from Meteo initialisation file.

3.24.3.2 Asynchronous Meteo data requests  receive request to generate Meteo information for a point or set of points.  store request on local event manager as an immediate event.  when event is signalled generate new Meteo data for specified point or points.  signal a trajectory event for given flight and tag name, and distribute to subscribers

3.24.3.3 Synchronous Meteo data request  receive synchronous request to generate Meteo data for a given point or set of points.  generate new Meteo data for the specified point or points.  return the generated Meteo data to the client.

3.24.3.4 Subscription for Significant Meteo events.  receive subscription request to generate Meteo data for significant Meteo events that may occur.  Store EventListener in subscription list.  when event is signalled generate new Meteo data and distribute to all subscribers.

3.24.4 Published Events Published Event Description SigMetMessage Produced by the MET, this event defines an element of significant meteo.

3.24.5 Subscribed Events Subscribed Event Description TimeTickMessage Produced by the Time Service, this event is automatically subscribed to by the client side Time Service implementation object, to update the local clock

3.24.6 Meteo Service Interface The MeteoServiceInterface presents a serialized interface to the client component, to support the inter- component messages generated by the Java RMI architecture. The implementation class for this interface defines the TP component controller object and generates the serialised inter-component messages. These are in turn converted into the pure entity data model objects in the client side Meteo service object to provide clean access to the Meteo objects.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.25 SCRIPTED EVENT

3.25.1 Description The Scripted Event (SE) component enables the sending of orders into other ComponentController interfaces based on commands written in scripts. Each script line contains the name of a logical target to which the command should be sent (e.g. GROUND), and this target name represents a ServerAgent object that is responsible for translating the script into system commands. Every command sent to a target (e.g. GROUND) has an alias name (e.g. CFL) and the ServerAgent translates the alias name into a method call which sends the order to appropriate ComponentController(s). Each ServerAgent contains the ComponentController references that it needs, and these references are initialised when the ServerAgent is created. In this way, changes to any of the ComponentController interfaces will result in a compiler error, not a runtime error. The ScriptedEventController has commands for executing a File of such scripted orders. Each order is wrapped in a ScriptedEvent object and scheduled for execution at the appropriate time.

Script Files T S TimeTickMessage E

S SubscribeTimeTickMessage

SE SaveOrders() PlayOrderNow() Order Messages W R W

GetOrders() GetScriptTargets() Component CWP Controller

Scripted Event 3.25.3 Use Cases 3.25.3.1 Read/Save/Delete scripted order files 3.25.3.2 Translate scripted orders into system calls on existing ComponentControllers that are scheduled at the appropriate times. 3.25.3.3 Export the scripted orders for display/editing in a HMI

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.25.3.4 Play a scripted order immediately. 3.25.3.5 Export the available list of targets for the scripted orders together with a list of commands that are possible on the targets.

3.25.4 Subscriptions to other Services Subscribed Event Description TimeTickMessage Produced by the Time Service, this event is automatically subscribed to by the client side Time Service implementation object. It’s needed by the scheduler to schedule the scripted orders.

3.25.5 Published Events No events are sent out by the SE component.

3.25.6 Entities A list of ScriptTarget entities may be obtained from the SE component. Each entity has the name of a logical target to which an order may be sent, and it contains a list of command names that be used for that target. The script of orders present in a given File may be retrieved in the form of a list of ScriptedEvent objects. Each ScriptedEvent entity corresponds to one command to be executed on a target at a particular time.

3.25.7 SE Interface The SE Server Interface is defined in ..\products\javadoc\atc\scriptedevent\server\ScriptedEventController.html It contains methods for:  Getting the list of ScriptTarget entities  Getting a list of ScriptedEvent objects loaded from a given File  Saving a list of ScriptedEvent objects to a given File  Deleting a File containing a list of ScriptedEvent objects  Playing (scheduling) a list of ScriptedEvent objects  Playing one ScriptedEvent

3.26 ADS-B MESSAGE PROXY SERVER

3.26.1 Description The ADS-B Message Proxy Server (ADSB) provides a conduit for ADSB messages for the platform. The messages may enter the server through a standard GSDK / RMI interface to the PM or eCockpit, or through a UDP ASTERIX based interface to external processes such as SMART.

3.26.2 Context Diagram The following context diagram shows how the ADS-B proxy server interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the ADS-B proxy server application, and the rectangular boxes indicate other servers in the eDEP platform that the ADS-B proxy server communicates with. Communication is made either through the use of an event

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 or through a direct call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file. ADSBReport ADSBReportUpdates E S ARTAS / E ADSB E PM SMART GeneratedADSBReport ADSBReportMessage E sendGeneratedADSBReport E ADSBMessage Cockpit

Figure 3-36 ADS-B Proxy Server Context Diagram

3.26.3 Use Cases Initialisation  Subscribe to ADS-B report events from the PM  Connect to required UDP channels Message Handling  Receive DAP (Cat21) reports via UDP or from eDEP and notify subscribers.  Receive DAP reports from connected cockpits and transmit via UDP (Cat244) or to eDEP.

3.26.4 Published Events Published Event Description ADSBMessage Produced by ADSB, this event identifies the receipt of DAP data in the form of a cat 21 message via UDP or through an ADSBReport from PM. GeneratedADSBMessage Produced by ADSB, this event identifies the receipt of DAP data from a connected cockpit for transmission in the form of a cat 244 message via UDP or to subscribers.

3.26.5 Subscribed Events Subscribed Event Description ADSBReportMessage Produced by the PM, this event identifies DAP updates generated for datalink equipped aircraft.

3.26.6 ADSB Interface The ADS-B proxy server interface is defined in ..\products\javadoc\atc\adsb\server\ADSBController.html and provides methods to subscribe to receive ADSBReports and GeneratedADSBReports. It also provides methods supporting direct calls to transmit GeneratedADSBReports generated by cockpits or other components.

3.27 TIS-B MESSAGE PROXY SERVER

3.27.1 Description The TIS-B Message Proxy Server (TISB) provides a conduit for TIS-B messages for the platform. The messages may enter the server through a UDP ASTERIX based interface to external processes

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 such as ARTAS/SMART. Received TIS-B messages can be optionally filtered by service volume before distribution to subscribers (cockpits).

3.27.2 Context Diagram The following context diagram shows how the TIS-B proxy server interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the TIS-B proxy server application, and the rectangular boxes indicate other servers in the eDEP platform that the TIS-B proxy server communicates with. Communication is made either through the use of an event or through a direct call to a remote method. Items indicated by a cylindrical shape indicate an initialisation file.

subscribeAPWMessa TCAS A ATCCO ge A APWMess AT age E S RE T CG GATCXP C RA E SATD E PHI C e CS C ATCLIVE_ GSDK AO T C Figure 3-37 TIS-B Proxy Service ContextC DiagramK P I 3.27.3 Use Cases T Initialisation  Subscribe to Tracks and DAP events from the IAS  Connect to required UDP channels Message Handling  Receive Track reports via UDP (Cat62) or from eDEP (Tracks / DAP) and notify subscribers.

3.27.4 Published Events Published Event Description TISBMessage Produced by TISB, this event identifies the receipt of TrackReport data in the form of a cat 62 message via UDP or the periodic generation of TrackReports by combining Tracks and DAP information from IAS.

3.27.5 Subscribed Events Subscribed Event Description TrackReportMessage The track report message defines a set of track reports generated by the TISB component. The track report provides a detailed description of a track rather than a simple track position update.

3.27.6 TISB Interface The TIS-B proxy server interface is defined in ..\products\javadoc\atc\tisb\server\TISBController.html and provides methods to subscribe for notification on receipt of TrackReports via UDP or from IAS.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.28 ARTAS MESSAGE PROXY SERVER

3.28.1 Description The ARTAS Proxy Server (ARTAS) provides a conduit for ARTAS messages for the platform. The messages may enter the server through a set of UDP ASTERIX based connections to external processes such as ARTAS, or through a standard GSDK / RMI interface to IAS.

3.28.2 Context Diagram The following context diagram shows how the ARTAS proxy server interfaces with other servers in the eDEP platform. The circle in the centre of the diagram indicates the limits of the ARTAS proxy server application, and the rectangular boxes indicate other servers in the eDEP platform that the ARTAS proxy server communicates with. Communication is made to IAS through the use of a direct call to a remote method addStateVectors.

Cat62 / 21 Asterix addStateVectors ARTAS / Cat32 Asterix ARTAS SMART IAS

Figure 3-38 ARTAS Proxy Service Context Diagram

3.28.3 Use Cases Initialisation  Connect to required UDP channels Message Handling  Receive Track reports via UDP (Cat62), provide IAS with State Vectors, correlate the track reports with Flightplans and generate and transmit a Category 32 Enrichment report to ARTAS.  Receive Track reports via UDP (Cat21), provide IAS with State Vectors and correlate the track reports with Flightplans.

3.28.4 Published Events No Events are produced by the ARTAS Proxy Server.

3.29 ACSG TCAS SERVER

3.29.1 Description The TCAS Server (ACSG) provides TCAS Advisory messages to the PM component via the Piloted Flight Advisory Service. It operates in two modes, according to the setting of the STANDALONE resource.  If standalone is set to true, the advisory messages are read from a scripted resource file.  In connected mode, the ACSG server acts as a gateway to the ACAS server. It is responsible for providing the Acas Server with eDEP data (position and altitude of aircrafts) and for

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 receiving RA data from the Acas Server. The communication between the ACSG gateway and the ACAS server is done via UDP.

The PM is responsible for scheduling the TCAS events and adding the advisories to the Flight entities. The PM Advisory Service also offers subscriptions for TCAS events.

PM StateVectorEvent E (Connected Mode) S ACAS registerStateVectorEvent UDP W ACSG

reportTCASAdvisory (Disconnected Mode) Script File

3.29.3 Use Cases 3.29.3.1 Read scripted TCAS advisory files (disconnected). 3.29.3.2 Convert PM generated State Vector events into binary MTRK messages for ACAS. (Connected). 3.29.3.3 Convert ACAS MACA binary messages into TCAS advisories. (Connected). 3.29.3.4 Inform PM, via the PMAdvisoryService of TCAS advisories.

3.29.4 Subscriptions to other Services Subscribed Event Description StateVectorMessage Produced by the PM. Only required in connected mode to provide the ACAS server with state vector information.

3.29.5 Published Events No events are sent out by the ACSG component.

3.29.6 Entities TCASEntity entities encapsulate TCAS advisories. They are read using an Entity Parser in disconnected mode and stored in the ACSG database. The Scripted Event Reader then reads these entities and informs the PM of the advisories.

3.29.7 ACSG Interface There is no ACSG Service interface.

3.30 INTRUMENT LANDING SUBSYSTEM

3.30.1 Description The Instrument Landing Subsystem (ILS) detects when an aircraft is captured by a runway’s ILS equipment.

3.30.2 Context Diagram The following context diagram shows how the ILS component interfaces with other servers in the eDEP platform.

Runways ASP ILS

WaypointPassed StateVector LocaliserIntercepted

Figure 3-39 ILS Subsystem Context Diagram

3.30.3 Use Cases The following use cases have been identified. These relate to communication with the PM.

3.30.3.1 Initialisation Upon initialisation, the ILS shall:  subscribe to state vector events; and  subscribe to waypoint passed events (if in automatic STAR mode).

3.30.4 Published Events The PWP does not define any external events for eDEP; the PWP is a pure client component. Published Event Description LocaliserInterceptedEvent Informs clients when a flight

The ILS does not inform clients when a flight has broken an ILS. This event is published by the PM.

3.30.5 Subscribed Events Subscribed Event Description StateVector Uses state vectors to determine whether flight is in the ILS capture zone. WaypointPassed Uses waypoint passed events in automatic STAR to determine whether flight should attempt lock on.

3.31 ATC NETWORK COMPONENT (INCLUDING DATALINK)

3.31.1 Overview The ATC Network component (atccore.componentnetwork.server.AtcNetworkController) is a server that loads gsdk.componentnetwork.plugin.NetworkPlugin objects at start-up, as defined in the resources. Each NetworkPlugin represents a protocol and, when loaded, clients may communicate with each other via the NetworkController according to that protocol. The only current NetworkPlugin is the atc.datalink.server.plugin.DatalinkPlugin. The DatalinkPlugin receives subscriptions from Air and Ground clients for a particular radio frequency. Ground clients may send messages to Air clients on the same frequency, and mirror them back to Ground clients on the same frequency. Similarly the Air clients may send messages to the Ground clients on their frequency. The DatalinkPlugin also maintains the notion of channels, so that only one message may be sent on a particular channel for a particular aircraft at a time.

TimeTickMessage

ATC NetworkController registerFor ComponentMessage unregister

Figure 3-40 ATC Network Component Context Diagram

3.31.3 Use Cases 3.31.3.1 The ATC Network component shall load NetworkPlugin objects at start-up and make the Plugin available for any client that registers for messages using that protocol. 3.31.3.2 The network messages shall maintain a trace of the originating and replying nodes. 3.31.3.3 Each network message shall have a header which shall serve as a category of messages that may be subscribed to. 3.31.3.4 Each network message shall have a unique dialogue ID that shall be set (as appropriate) by the NetworkPlugin.

of 87 Development and Evaluation Platform Reference GL/eDEP/ADD/1/2.0 13 Aug 2007 3.31.3.5 Each network message shall have a channel ID to permit the separation of messages into parallel channels using the associated protocol.

3.31.4 Subscribed Events Subscribed Event Description TimeTickEvent The current simulation time.

3.31.5 Published Events Published Event Description ComponentMessage A message being sent across the ATC Network.

3.31.6 Datalink-specific implementations of the ComponentMessage. 3.31.6.1 DatalinkStatusMessage Published after each action taken by the DatalinkPlugin in order to transmit the current datalink channel status to all clients.

3.31.6.2 DatalinkClearanceMessage Published to destination clients on the same frequency and mirrored back to originating clients on the same frequency as a result of a client issuing an ATC clearance message to the DatalinkPlugin.

3.31.6.3 DatalinkTransferMessage Published to destination clients on the same frequency and mirrored back to originating clients on the same frequency as a result of a client issuing an ATC Sector transfer message to the DatalinkPlugin.