TCT Detailed Design Document

Transcription

1 Detailed Design Document TCT Detailed Design Document Issue: Draft 1.1 Author: Mike Vere Date: 3 January 2008 Company: Graffica Ltd Page 1 of 16

2 Table Of Contents 1 Introduction OVERVIEW SCOPE REFERENCES...3 Release Date Author Reason Changes Sep Nov 2007 Graffica (VERE) Graffica (OWEN) Initial Version TCT_WPE8.2.5_LEVEL_1_AND_LEVEL_2_FALLOUT: Update hybrid conflict issues. 2.4, 3.2, Page 2 of 16

3 1 INTRODUCTION This document provides a proposal to implement the Tactical Controller Tool (TCT) within the edep environment. It also proposes a strategy to prepare the TCT component for integration into the ACE environment and to create a new TCT service for use within the ACE platform. This proposal shall develop the framework architecture for the TCT tool, and shall produce a baseline implementation of the TCT subsystem ready for demonstration in September Given the exceptionally ambitious time scales for this task, Graffica can only commit to the development of specific elements of the TCT toolset, outlined in the task breakdown given in section Error! Reference source not found. below. Graffica shall ensure that the implementation is robust and flexible with options to configure the TCT tool features with run-time resource settings. Deleted: 6 The implementation shall where possible make use of existing edep functionality, and extend that functionality to support the new features of TCT. The implementation shall be divided into three separate phases to reflect the first two levels of operational use, outlined in the scope section 1.2 below, and the ACE wrapping task. 1.1 OVERVIEW The TCT tool has been proposed as a hybrid problem resolution tool that uses both surveillance information from radar tracks and planning information from system trajectories. It is provided as a tool for the tactical controller. 1.2 SCOPE The TCT is a tool targeted for use by the Tactical controller, with a time horizon of between 2 and eight minutes ahead of the current situation. The TCT implementation shall define three separate levels of operation dependent on the controller environment and an ACE wrapping task: 1) Level 1: Extended STCA warnings given on basis of state vectors (heading and climb) alone. 2) Level 2: In addition to level 1, tactical trajectories accounting for missed manoeuvres and detecting conflicts for the planned trajectory. 3) ACE Wrapping: Providing ACE wrappers through AEG to receive ACE system flight plan information and to provide TCT services for ACE based CWP. Note that level 3 is beyond the scope of this work plan, but shall be considered after delivery of level 1 and level 2 TCT, and ACE integration. 1.3 REFERENCES 1 EUROCONTROL DAS ATC Domain; TCT Operational Requirements, Part A Functional Requirements. Edition V0.1, dated 09/03/ EUROCONTROL DAS ATC Domain; TCT Concept Description, Near-term Conflict Resolution Project, Edition V0.7, dated 24/01/ edep TCT SRD 4 5 Page 3 of 16

4 2 USE CASES This section identifies the main use cases for the Tactical Controller Tool. These use cases cover the operation of the TCT component itself in response to the controlled traffic, and the display and input mechanisms offered to the controller through the HMI. 2.1 BASIC TCT USE CASE This use case illustrates the basic function of the TCT, which is to notify the controller of short/medium term conflict situations, notify alerts when a flight has failed to respond or manoeuvre as expected, and to propose optimised conflict resolutions. Figure 2-1 Basic TCT Use Case Deleted: STATE VECTOR USE CASE The state vector TCT use case illustrates how the TCT component generates a state vector trajectory from state vector information contained in a track, probes against other state vector based trajectories and reports any detected conflicts to the controller. Page 4 of 16

5 2.3 TACTICAL USE CASE The tactical TCT use case illustrates how the TCT component generates a tactical trajectory from flight plan information contained in a system flight plan object, SFPL, correcting for the aircraft s current location, and probes against other tactical trajectories and reports any detected conflicts to the controller. 2.4 HYBRID STATE VECTOR/TACTICAL CONFLICTS USE CASE The hybrid use case is very similar to the state vector and tactical use cases above except the state vector trajectory is conflict probed against the other flights tactical trajectories to produce conflicts between the projected state vector trajectory and a tactical trajectory. In the hybrid case, the state vector trajectory shall be probed on the tactical MTCD component, which holds a database of tactical trajectories. The hybrid conflicts are not returned to the TCT client (in the CWP) but are transformed into a MissedManoeuvreConflict. This is because: 1. The hybrid conflict may or may not mean that an aircraft has a missed manoeuvre situation in which it must perform some manoeuvre to avoid the associated StateVectorConflict 2. The two State Vector trajectories of the original StateVectorConflict may also result in a MissedManoeuvreConflict if both aircraft are heading toward each other and both have critical points at which they must act. Thus, it is the TCT server that analyses the StateVectorConflict and the hybrid Conflicts to deduce whether a critical manoeuvre miss applies, in which case a MissedManoeuvreConflict is sent back to the TCT client INSTEAD of the StateVectorConflict. Page 5 of 16

6 3 DETAILED DESIGN 3.1 OVERVIEW The TCT shall be implemented as a new component within the edep environment. It shall make use of existing services provided by the FM (system flight plans), FPM (conformance monitoring), TP (trajectory prediction) and IAS (tracks). The MTCD component shall provide conflict determination between the requisite tactical trajectory plans. The STCA component shall provide the state vector conflicts, subject to an extended time horizon commensurate with TCT operation. It is proposed to separate the TCT into a separate subsystem, using its own instances of TP, MTCD and STCA components, configured with separation thresholds appropriate to TCT operation. The conflicts produced by TCT shall be managed in the CWP entity model and associated clients in a similar way to those conflicts already produced by the existing MTCD and STCA. The TCT is likely to be computationally intensive and by factoring out the TCT into its own subsystem, it can be placed on its own dedicated machine. Figure 3-1 Proposed Separation of TCT into its own Subsystem Deleted: TCT CONTEXT Data Requirements The TCT shall be driven from existing data sources provided either by the edep ground system or through the ACE ground system APIs. The TCT has the following data requirements: State Vector information from tracks defining current position, altitude, heading and speed; System flight plan information defining the planned route and altitude constraints; Deviations between actual track position and expected plan position. Page 6 of 16

7 3.2.2 Data Produced The TCT produces two types of system flight plan derived from track and ground plan information. First it produces a state vector trajectory, projecting the current aircraft location forwards by 8 minutes along its current heading, secondly it produces a tactical trajectory from the current state vector location, but redirected back to the planned route. From these two trajectories, the TCT calculates state vector and tactical conflicts as described in the TCT output summary below: State vector trajectory derived from projecting current state vector; Tactical trajectory derived by projecting current state vector forwards by nominal time and merging with existing flight plan; State Vector Conflict conflict arising from proximity of points on state vector trajectories; Tactical conflict conflict arising from proximity of points on tactical trajectories. MissedManoeuvreConflict produced when there exists a StateVectorConflict that will normally be avoided if the aircraft follow their planned trajectories. The level 3 version of TCT shall provide suggested resolution advisories for the controller. These shall take the form of a resolution trajectory, from which a set of manoeuvre advisories shall be derived and presented to the controller. Each resolution shall have an associated cost included as part of the TP calculation. The following information shall be provided in the level 3 implementation. Resolution Trajectory suggested resolution option. 3.3 TCT COMPONENT FUNCTIONALITY The TCT functionality is divided into three levels of operation, each configured for the environment defined by the given controller position. This work plan shall only detail level 1 and level 2 functionality. The new functionality defined by each of the levels is detailed in the following paragraphs. The TCT shall generate conflicts from the tactical trajectory and the state vector trajectory to produce two new types of conflict, the extended state vector conflict, and the tactical conflict TCT Level 1 TCT Level 1 shall generate standard STCA alerts, but with modified thresholds to look ahead up to ten minutes, rather than the standard seconds. These alerts shall be determined by projecting the current aircraft track forwards by the look ahead time to form a state vector trajectory TCT Level 2 TCT Level 2 shall generate MTCD type conflict alerts, but using the tactical trajectory derived by merging the current track and the system plan trajectory, with modified thresholds to look ahead ten minutes, rather than the standard 20 minutes of MTCD. 3.4 TCT INTERFACE The TCT server shall provide a standard GSDK interface by implementing a component controller object. This shall provide access to the tactical and state vector flight details, held as system flight plan objects. The TCT component shall offer the following API to clients. public interface TCTController implements ComponentController { /** * Registers interest in a TacticalConflict message. */ public SubscriptionID subscribetacticalconflictmessage( EventListener action )) throws RemoteException; /** * Registers interest in a StateVectorConflict message. */ public SubscriptionID subscribestatevectorconflictmessage( EventListener action ) throws RemoteException; Page 7 of 16

8 /** * Registers interest in a HybridConflictMessage. */ public SubscriptionID subscribemissedmanoeuvreconflictmessage( EventListener action ) throws RemoteException; /** * Registers interest in a ResolutionTrajectory message. */ public SubscriptionID subscriberesolutiontrajectorymessage( EventListener action ) throws RemoteException; /** * Registers interest in a TentativeTrajectory message. */ public SubscriptionID subscribetentativetrajectorymessage( EventListener action ) throws RemoteException; } // End interface TCTController 3.5 TCT ENTITY MODEL Overview The TCT shall define its own entity model to manage the conflicts, critical alerts and the resolutions produced within the TCT server. The TCT Flight entity shall store the constraints and trajectory data for current state vector and tactical trajectories in the form of SFPL objects, with the trajectory tags TACTICAL and STATE_VECTOR. The TCT server stores the conflicts returned from the TACTICAL and STATE VECTOR conflict probes. This results in two main type of Conflict in the TCT server and the TCT client. TACTICAL on TACTICAL similar to MTCD STATE VECTOR on STATE VECTOR similar to STCA The TACTICAL Conflicts are returned back to the (CWP) client where they are also stored in the Entity database. Each STATE VECTOR Conflict is further analysed to see if there is a critical manoeuvre for one of the aircraft which will avoid the conflict. If there isn't one then the STATE VECTOR Conflict is sent back to the (CWP) client. If there is one then the STATE VECTOR Conflict is not sent back to the client, but instead a MISSED MANOEUVRE Conflict is sent back and stored in its own database. Thus the client has a third type of Conflict database (in addition to the others), which is calculated by the server: MISSED MANOEUVRE The following diagram illustrates the state vector trajectory, projected forward using the aircraft track and current speed, and showing a conflict with another aircraft s state vector trajectory. Page 8 of 16

9 State Vector Conflict System Plan Trajectory State Vector Trajectory Critical Manoeuvre Figure 3-2 Typical Scenario showing State Vector and Tactical Situation Deleted: 4 Tactical Trajectory System Plan Trajectory Aircraft Off Plan Tactical Conflict Figure 3-3 Typical Scenario showing Off Plan Flight and Tactical Conflict Deleted: Entity Objects The TCT shall introduce the following entity objects into the edep system. TCTFlight o Includes a tactical and a state vector trajectory o References the tactical, state vector and hybrid conflicts Tactical Conflict State Vector Conflict Missed Manoeuvre conflict Page 9 of 16

10 3.6 TCT WRAPPING FOR ACE Note that the TCT shall conform to the Java 1.4 run-time standard, and shall not employ any language or run time features added for the 1.5 or 1.6 releases. This is necessary to retain compatibility with the ACE build, which remains at JDK ACE Environment Classes The TCT shall be wrapped using standard ACE middleware elements to define the following Java interface classes: CDL Definition IDL Generation Build Scripts Component Building Main Component Development The main component shall include software from the existing AEG elements, FM, FPM, IAS and IFPL Flight Path Monitoring, MONA The AEG currently does not support an interface to the ACE flight path monitoring services, MONA. To support the TCT functionality, either the TCT subsystem shall include a local edep FPM component, providing MONA flight path monitoring services, or the AEG must be extended to include the ACE service. It is proposed that the AEG may be extended to include the additional service, which shall be provided through an FPM proxy component. Page 10 of 16

11 4 CHANGES TO CORE SOFTWARE 4.1 CHANGES TO GSDK MODULE A number of minor enhancements to the GSDK package are proposed to improve accessibility and handling of resources Launcher Improvements A new package has been developed within the TCT to provide an improved, standardised launcher facility. This defines standard command line arguments to provide resource files and run settings to the GSDK system, and a flexible approach to adding additional panels to the launcher window. It also includes options to run without the launcher window, and to start the clock automatically. This package has been developed at Graffica s expense and shall be moved in due course into the GSDK package for general use Change to GSDK Class The improved launcher requires a default constructor that initialises the GSDK system through resources only. Command line arguments are processed by the launcher, and no flags are set to load and start the system automatically. Eventually, all systems should be run using the default constructor, with the command line arguments processed in the launcher. Also the System Parameters class should be removed. However, this is beyond the scope of this work package Change to Resources The Resource class shall be changed to define a convenience method to create a new property from two String objects containing the text of the property name and the text of the property value. The launcher shall also make use of a new method to clear all resources from the static resource table, in order to load a fresh set of resources Change to Middleware Options The middleware setting option preferences shall be extended to include convenience methods to set the resources for discovery port, host and server run options Change to Position Class The Position class in the GSDK geometry package shall include a project method, to enable the calculation of a new Point2D object, projected backwards or forwards for a given time interval, given the current values of the position object s heading and speed. 4.2 CHANGES TO ATC MODULE A number of minor changes shall be made to the ATC module to improve the flexibility of access to specific servers. At present, most servers are hard-wired to their corresponding services. To allow multiple servers of the same type to run and be accessed specifically by a selected service, the connection configuration must be fully parameterised, allowing a service to access the specific server of choice IAS Server Changes The track class on the client side shall be improved to include an entity change event whenever the track updates with new positional information. The existing track object does not currently raise an entity change event when update occurs, but this is a convenient mechanism to be used by the TCT component FM Server Changes The FM controller API shall be rationalised to include a separate SFPL service, to allow servers like MTCD to access a simplified interface to provide flight plan and related information only. The existing FM controller Page 11 of 16

12 interface shall inherit from the SFPL subset, and the FM implementation shall remain unchanged. This split shall allow TCT to implement only a small subset of FM functionality to allow it to interact with its dedicated conflict servers. The System Plan service subset shall include: public SystemFlightPlan getsystemflightplan( Flight flight, String tag ); public void getsystemflightplan( Flight flight, String tag, EventListener callback ); public SubscriptionID registerforsystemflightplanevent( EventListener action, String tag ); public SubscriptionID registerforsfpldeletedevent( EventListener action ); public SubscriptionID registerforsfpldeletedevent( EventListener action, String tag ); public SubscriptionID registerforflightdeletedevent( EventListener action ); A new System Plan Service class shall be created to support the client side of the split of the FM API. The existing Flight Service interface shall extend the System Plan Service interface. When the service is created, the name of the target server shall be defined by a new resource, <context>.fm.server, which shall default to FM as before. This allows the System Plan service to connect to the TCT from the MTCD server. Additional null checks shall be added when creating an SFPL description as the sector crossing and clearance elements may be missing MTCD Server Changes The Conflict Service shall be modified to include an additional constructor to enable it to be connected to a selected server. The server shall be determined by resource, and supplied from the client application. This enables the client to select the server required to process a particular data set. The server configuration resources shall be of the form <context>.<type>.server <Server Name>, where <context> identifies the name of the host component <type> defines the type of service offered. For example, in the TCT component, the tactical trajectory conflict service would locate its tactical trajectory MTCD server with the following resource setting: TCT.TTCD.SERVER TCT_TTCD The MTCD server shall selectively determine the type of trajectory it accesses to determine conflicts. Only one trajectory type shall be stored with each server. Conflicts between one type and a specific instance of another type must be performed using the synchronous MTCD interface probeforconflicts. The MTCD defaults shall have a method to access a resource to specify the SFPL tag to use, and the MTCD controller shall use this tag to make subscriptions to the provider of SFPL data, using the new System Plan service defined by the FM component, but for this project, implemented by the TCT component. When using multiple MTCD servers, the client-side service must selectively process the common MTCD Update Event by setting the topic string to the name of the MTCD server in the event to determine which server source has produced the conflict Coordination Server Changes The coordination server shall be modified to provide support for an improved handover implementation. The present implementation uses the full unit crossing list to determine the handover sectors, but in practice, the server should only consider the current unit location of the flight, the current controlling unit, and the units in which the flight has been activated (generally only the next unit). Units that are orientated vertically shall take account of the possibility of clipping an uninterested unit whilst climbing between the current controlled unit and the next controlling unit. This is illustrated in Figure 4-1 below. Deleted: Figure 5-1 Page 12 of 16

13 Altitude Clipped Unit Next Unit Current Unit Distance Figure 4-1 Typical Clipping a Not Concerned Unit in Climb To Next Unit Deleted: 5 This issue is not correctly handled by the existing coordination server and shall be improved in the second phase of the work plan. Page 13 of 16

14 5 COMPONENT TESTS 5.1 OVERVIEW The TCT shall be tested using the scripted component test strategy adopted for the core edep platform. Each element of TCT functionality identified from the requirements shall be tested through a scripted test, that defines platform configuration and scenario details including the traffic sample, and airspace requirements. The following paragraphs describe individual test cases to exercise each of the requirements detailed in the TCT software requirements document, Ref TEST PLAN Test Case: Trajectory Generation Test Case ID Objective Test Items Input Specifications Output Specifications Test Criterion Environment Requirements Test Dependencies STP_TCT_GEN_010 Verify that the TCT shall generate both state vector and tactical trajectories and make them available for the CWP. edep platform, FASTI module and TCT subsystem A scenario shall be created with a conflict between two flights to illustrate the generation of the tactical and state vector conflicts. Flights shall be chosen to display the trajectories. State vector trajectory. Tactical trajectory. CWP PVD Flight Legs, VAW Check the displayed flight legs conform to the expected trajectory for state vector and tactical trajectory calculations. State vector trajectory shall show a forward projection for a nominal configurable time. Tactical trajectory: when on plan shall show the planning trajectory with nominal look ahead time: when off plan shall show a short forward projection followed by a smooth rejoin to planning trajecrtory. Airspace, Traffic, Configuration TCT_TCT_GEN_ Test Case: Conflict Detection Test Case ID Objective Test Items STP_TCT_GEN_011 Verify that the TCT shall generate both state vector and tactical conflicts and make them available for the CWP. edep platform, FASTI module and TCT subsystem Page 14 of 16

15 Input Specifications Output Specifications Test Criterion Environment Requirements Test Dependencies A scenario shall be created with a conflict between two flights to illustrate the generation of the tactical and state vector conflicts. Flights shall be chosen to display the conflicts on the flight legs and within the flight label and extended label. State vector conflict Tactical conflict CWP PVD Flight Legs, VAW Check the displayed flight legs show the expected conflicts for state vector and tactical conflict detection calculations. Airspace, Traffic, Configuration TCT_TCT_GEN_010 STP_TCT_GEN_ Test Case: Trajectory Change Filtering Test Case ID Objective Test Items Input Specifications Output Specifications Test Criterion Environment Requirements Test Dependencies STP_TCT_TAT_010 Verify that the TCT shall only generate trajectories for the CWP when there is a conflict detect from at least one of the trajectory types. edep platform, FASTI module and TCT subsystem A scenario shall be created with a pair of flights with no conflicts a state vector conflict between a pair of flights and a tactical conflict between a third pair to illustrate the generation of the tactical and state vector trajectories only when required. Flights shall be selected to display the trajectory flight legs. CWP PVD Flight Legs, VAW Check the displayed trajectory flight legs show the expected conflicts for state vector and tactical conflict detection calculations. Airspace, Traffic, Configuration TCT_TCT_TAT_050 STP_TCT_GEN_ Test Case: Critical Miss Test Case ID Objective Test Items STP_TCT_CRM_010 Verify that the TCT shall generate conflicts defining critical manoeuvres and make them available for the CWP. edep platform, FASTI module and TCT subsystem Page 15 of 16

16 Input Specifications Output Specifications Test Criterion Environment Requirements Test Dependencies A scenario shall be created with a conflict between two flights to illustrate the generation of the critical manoeuvre conflicts. Flights shall be chosen to display the conflicts showing critical manoeuvre on the flight legs and within the flight label and extended label. State vector conflict Tactical conflict CWP PVD Flight Legs, VAW Check the displayed flight legs show the expected conflicts for state vector and tactical conflict detection calculations. Airspace, Traffic, Configuration TCT_TCT_GEN_010 STP_TCT_GEN_010 Page 16 of 16