edep technical document trs requirements document · 2002. 7. 24. · company ref. template :...

TRS_eDEP_2002_ANNEX_v1.0.doc

Date : 14/11/01

Page : i

EUROCONTROL

STATUS TITLECompany Ref. Template : tec01.dot

EUROCONTROL EXPERIM ENTAL CENTREBrétigny-sur-Orge, FRANCE

eDEP

Technical Document

TRS Requirements Document

Document Ref: TEC/eDEP/TRS_2002Issue date:14 November 2001

The information contained in this document is the property of the EUROCONTROL Agency and no part should be reproduced in any form without theAgency’s permission.

The views expressed herein do not necessarily reflect the official views or policy of the Agency.


Date : 14/11/01

Page : ii

EUROCONTROL


Document Change LogRelease Author Date of the

releaseDescription of the

releaseModifications (sections affected

and relevant information)0.1 D.Smith 29/10/01 Draft0.2 D.Smith 10/11/01 Updated Content1.0 D.Smith 26/11/01 General Release

Acceptance andReviewing ProceduresName (s) Date of acceptance/ review Date of approval

Document distributionto/cc Name Role

to EEC Contract Framework Membersto Danielle Maisonnierto Patrick Peeters

Table of contents

1. INTRODUCTION .................................................................................................................................. 1

1.1 PURPOSE ........................................................................................................................................... 11.2 INTENDED AUDIENCE............................................................................................................................ 11.3 ASSOCIATED DOCUMENTATION ............................................................................................................. 11.4 GLOSSARY ......................................................................................................................................... 11.5 TERMINOLOGY .................................................................................................................................... 2

2. PROJECT OVERVIEW......................................................................................................................... 3

2.1 OBJECTIVES ....................................................................................................................................... 32.2 PLATFORM VERSIONS .......................................................................................................................... 32.3 EDEP ARCHITECTURE......................................................................................................................... 42.4 EXISTING SOFTWARE........................................................................................................................... 6

3. DEVELOPMENT PROCESS ................................................................................................................ 6

3.1 OVERALL PROCESS ............................................................................................................................. 63.2 DESIGN PROCESS ............................................................................................................................... 6


Date : 14/11/01

Page : iii

EUROCONTROL


3.3 DESIGN CHARACTERISTICS .................................................................................................................. 73.4 TOOLS SUPPORT................................................................................................................................. 83.5 CODING STANDARDS ........................................................................................................................... 8

4. TENDER ISSUES................................................................................................................................. 8

5. DELIVERABLES AND SCHEDULE ..................................................................................................... 8

5.1 SOFTWARE......................................................................................................................................... 85.2 DOCUMENTATION ................................................................................................................................ 95.3 SCHEDULE.......................................................................................................................................... 9

6. PROJECT MANAGEMENT ................................................................................................................ 11

6.1 GENERAL ......................................................................................................................................... 116.2 ROLES AND RESPONSIBILITIES............................................................................................................ 11

7. AIR SUBSYSTEM REQUIREMENTS ................................................................................................. 11

7.1 OVERALL ARCHITECTURE................................................................................................................... 117.2 DESIGN ISSUES................................................................................................................................. 137.3 PWP REQUIREMENTS ....................................................................................................................... 147.4 PILOT MANAGER REQUIREMENTS FROM THE HMI VIEWPOINT ................................................................ 14

7.4.1 Section 3 – Supervise Aircraft Flights ...................................................................................... 147.4.2 Section 4.1 – Describe Existing Pseudo Pilot Display Screen................................................... 147.4.3 Section 4.1.2 – Display A/C Strips ........................................................................................... 147.4.4 Section 4.1.3 – Display Flight Information ................................................................................ 157.4.5 Section 4.1.4 – Display Flight History....................................................................................... 157.4.6 Section 4.1.5 – Display Radar Map.......................................................................................... 157.4.7 Section 4.1.6 – Display Order Entering and Display Data Entering........................................... 157.4.8 Section 4.1.6.7 Enter Flight Orders .......................................................................................... 15

7.5 EXTRA REQUIREMENTS...................................................................................................................... 177.6 DEVELOPMENT SCHEDULE ................................................................................................................. 17

8. SIMPLE PREPARATION TOOL ......................................................................................................... 18

8.1 WORK ALLOCATION ........................................................................................................................... 188.2 OVERVIEW ....................................................................................................................................... 188.3 GENERAL REQUIREMENTS .................................................................................................................. 198.4 1ST ITERATION – BASIC FUNCTIONALITY ............................................................................................... 198.5 2ND ITERATION................................................................................................................................... 20

9. GRD FUNCTIONALITY IMPROVEMENTS ......................................................................................... 20

9.1 IFPL................................................................................................................................................ 209.2 TP................................................................................................................................................... 209.3 COORD .......................................................................................................................................... 21

9.3.1 Richer Data Content ................................................................................................................ 219.3.2 Co-ordination Dynamics .......................................................................................................... 219.3.3 Transfer Dynamics .................................................................................................................. 229.3.4 Automatic Mode ...................................................................................................................... 229.3.5 Design Issues.......................................................................................................................... 22

9.4 FM.................................................................................................................................................. 229.5 STCA.............................................................................................................................................. 229.6 FPM................................................................................................................................................ 22

10. IMPROVED CWP FUNCTIONALITY .................................................................................................. 23

10.1 ANTI-OVERLAP .............................................................................................................................. 23


Date : 14/11/01

Page : iv

EUROCONTROL


10.2 CWP MANAGEMENT ...................................................................................................................... 2310.3 ‘REUSE’ DESIGN ISSUES ................................................................................................................ 2310.4 EXAMPLE CWP APPLICATION ......................................................................................................... 2410.5 EATMP – 1ST ITERATION ............................................................................................................... 24

10.5.1 Overview................................................................................................................................. 2410.5.2 PVD : EATMP Compliant Labels.............................................................................................. 2510.5.3 PVD : Secondary Windows (Co-ordination related) .................................................................. 2610.5.4 PVD Popup Menus.................................................................................................................. 2610.5.5 PVD Toolbox ........................................................................................................................... 26

10.6 EATMP – 2ND ITERATION (OPTIONAL) .............................................................................................. 2610.7 EXTREME REUSABILITY (OPTIONAL) ................................................................................................. 26

11. EXPERIMENTATION FUNCTIONALITY ............................................................................................ 27

11.1 DISTRIBUTION FRAMEWORK............................................................................................................ 2711.1.1 1st Iteration .............................................................................................................................. 2711.1.2 2nd Iteration (optional) .............................................................................................................. 27

11.2 PERFORMANCE ............................................................................................................................. 2711.3 DATA RECORDING FRAMEWORK (EEC WORK PACKAGE).................................................................... 2811.4 REPLAY (EEC WORK PACKAGE) ...................................................................................................... 28

12. TOOLKIT FEATURES (OPTIONAL WORK PACKAGE) .................................................................... 28

12.1 GENERAL...................................................................................................................................... 2812.2 CONFIGURATION FRAMEWORK ........................................................................................................ 2812.3 LOGGING FRAMEWORK .................................................................................................................. 28

13. ANNEX A : MASS SCREEN SHOTS.................................................................................................. 29

13.1 BASICS......................................................................................................................................... 2913.1.1 Nav Start / Transferred-in Flight............................................................................................... 2913.1.2 Flight Selection........................................................................................................................ 29

13.2 HEADING ORDER ........................................................................................................................... 3013.2.1 Beginning a heading order....................................................................................................... 3013.2.2 Heading Data Entry Panel ....................................................................................................... 3113.2.3 Executing a Heading order ...................................................................................................... 3213.2.4 Turn Orders............................................................................................................................. 3413.2.5 Rejoining Plan ......................................................................................................................... 34

13.3 LEVEL ORDERS ............................................................................................................................. 3613.4 SPEED ORDERS ............................................................................................................................ 3713.5 TRANSFER ORDERS....................................................................................................................... 3913.6 COMBINED ORDERS....................................................................................................................... 39

13.6.1 General Comment ................................................................................................................... 3913.6.2 Level and Rate Of Climb.......................................................................................................... 40

13.7 DIRECT TO – LEAVING THE PLAN ..................................................................................................... 4013.8 ERROR MESSAGES ........................................................................................................................ 42

Index of figures

Index of tables


Date : 14/11/01

Page : 1

EUROCONTROL


1. INTRODUCTION

1.1 PurposeThis top-level document defines the expected eDEP platform, as it shall be developed in 2002. Hence, thisdocument defines,

• software requirementshigh level requirements within this document, completed by detailed requirements within the annexdocuments

• process requirementscoding standards, design standards

• architecture issuesdesign / implementation considerations

1.2 Intended audience

All companies responding to the TRS offer.

1.3 Associated documentation

Title Reference Date

[Ref 1] MASS v9.0 HMI Specification

[Ref 2] EATMP HMI Web Site https://www.eurocontrol.be/hmi

[Ref 3] EATMP Generic HMISpecification

Version 1.0 10 March 2000

[Ref 4] OLDI Standard v2.3http://www.eurocontrol.int/projects/eatchip/odt/documents/standards/oldi_e23.zip

Dec 2000

1.4 Glossary

ASP Airspace Server

CWP Controller Working Position

FPM Flight Plan Monitor

IFPL Initial Flight Plan

LoA Letters of Agreement

MTCD Medium Term Conflict Detection

PWP Pilot Working Position

STCA Short Term Conflict Alert

TP Trajectory Predictor


Date : 14/11/01

Page : 2

EUROCONTROL


VAW Vertical Assistance Window

XFL eXit Flight Level

1.5 Terminology

In order to ensure clarity and readability, the following conventions are applied in this document:

"shall": The word "shall" is used whenever a mandatory requirement is expressed.

"should": The word "should" is used in order to express a recommendation.

"bidder": The word "bidder" designates an organisation responding to this Call for Tender.

"supplier": The word "supplier" designates the organisation selected by EUROCONTROL tocarry out the work defined in this Specification.

"he": The word "he" stands for "he/she".


Date : 14/11/01

Page : 3

EUROCONTROL


2. PROJECT OVERVIEW

2.1 ObjectivesThe eDEP project shall produce an open reusable ATM java toolkit that facilitates the development ofspecific ATM demonstrators. Hence, the EEC shall place great emphasis on the software architecturequality.

The following sections describe in more detail the expected functionality.

2.2 Platform Versions

The e-DEP platform is proposed in a number of incremental versions,

• eDEP Standalone Edition (Q1 2002)

• light-weight demonstrator facility

• ideal for portable PC, PC or web-based demonstrations

• consists of single CWP and FDPS components

• already partly developed (80%) – brought as input to the eDEP project

• eDEP Experimentation Edition (2002)

• build upon the Standalone edition

• provide distribution support for multiple CWPs ( maximum 15)

• provide an simple preparation tool (EEC Development)

• provide an simple AIR subsystem with piloting HMIs

• eDEP Integrated Edition (2003) [beyond current TRS]

• IPAS support(the eDEP preparation tool shall read IPAS data)

• MASS SupportAbility to replace the eDEP Piloting tool with MASS

• ACE/EAT SupportAbility to plug the eDEP HMI into the GRD subsystem

The following diagram illustrates the principle,


Date : 14/11/01

Page : 4

EUROCONTROL


FDPS-lite

CWP

CWP

CWP

e-DEP Standalone Edit ion

e-DEP Experimentation Edition

IPASReader

SimplePrepTool

SimplePilotPosn

e-DEP Integrated EditionMASSGateway

ACE /EATGateway

CWP

MUDPIESTORIA

link

DataRecord

-ing

It is expected that with time, concept / long-term research projects move from the Standalone, to theExperimentation and finally to the Integrated platform versions.

2.3 eDEP ArchitectureThe eDEP platform is built, and shall continue to be built, following solid software engineering principles. Inorder to manage complexity and encourage software reuse the internal architecture is composed of anumber of layers

��

��

��

��

��

��

��

��

��

��

�� !�"�

��!�"�

!�#$��%��

&��'��#�

��!�"�

(��%$��

��%��

��

��%��


Date : 14/11/01

Page : 5

EUROCONTROL


• generic toolkit layer (GSDK) Graffica Ltd Product

• Geometry, Projection functions

• Map management functions

• Model View Controller framework

• Rich Graphics Toolkit (transparency management, various widgets)

• Event management, Service provision management

• ATC Object Model layerconceptual ATC objects such as Aircraft, Trajectory, Track, Sid, STAR, Airport, Runway

• ATC Service Layer

light-weight ATM functional components following an AVENUE/ESCAPE architecture.

• ASP (Airspace Component)

• TME (Time Component)

• ATG (Air Traffic Generator)

• IFPL (Initial Flight Plan Component)

• TP (Simple 3D Trajectory Predictor Component)1

• FM (Flight Manager Component)

• COORD (intra-centre co-ordination Component)

• MTCD (Medium Term Conflict Detection Component)

• STCA (Short Term Conflict Alert Component) [new component]

• FPM (Flight Path Monitoring)

• HIPS Conflict Zone Engine

• ATC HMI (CWP) Layer

• Low-level Graphical Objects

• Various Menu mechanisms• Various Trajectory Editors, Elastic vector tools

• Configurable Labels

• High-level Graphical Objects

• PVD (Plan View Display)

• Vertical Profile Window

• Conflict Risk Display

1 based upon a nominal B737 aircraft performance model


Date : 14/11/01

Page : 6

EUROCONTROL


2.4 Existing Software

The eDEP platform has been under development since April 2001 by Graffica Uk Ltd. The current platformconsists of approximately 500 java classes, and concentrates on the GRD / CWP functionality.

This existing software conforms to eDEP spirit of toolkit reuse, having the layered architecture demonstratedabove.

This existing software shall be improved and extended during this 2002 TRS.

3. DEVELOPMENT PROCESS

3.1 Overall process

In order to reduce risks, the eDEP platform shall be developed following an iterative step-wise process,whereby for a given subsystem/component, the iterations are expected to take the following form,

• 1st iteration – foundation design/developmentemphasis shall be placed on building a strong design foundation (i.e. the design shall anticipate thefunctionality required in future iterations).Some minimum level of ATM functionality is implemented

• 2nd 3rd etc iteration – increased ATM functionalityBuilding upon the strong design work, extra ATM functionality is added step-by-step

Hence, within this document, various requirements / functionality have an associated priority. This priority isrelated to the development iteration process (high priority tasks are implemented in early iterations).The priorities are named as follows,

• Very High (VH) – essential functionality, implemented in the 1st iteration

• High (H) – essential functionality, designed in from the 1st iteration, but implemented in later iteration(2nd 3rd etc)

• Medium (M) – interesting functionality, implemented only if time permits

• Low (L) – functionality of little importance – implementation not expected

• Very Low (VL) – functionality will never be implemented

3.2 Design Process

As outlined above, the eDEP project shall use an iterative step-wise development process. For eachidentified work package iteration the following will occur –

• initial supplier / EEC discussion on the exact nature of the task

• determine deviations from original software development plan

• refine planning estimates

• Supplier conducts the initial design work

• UML model of major interfaces / classes and system dynamics

• design documentation

• prototype key areas

• Joint Supplier / EEC design review


Date : 14/11/01

Page : 7

EUROCONTROL


• Supplier conducts the implementation phase

• Joint Supplier / EEC code review

3.3 Design Characteristics

Building reusable toolkits is a non-trivial task. A good toolkit should have the following characteristics -

• simple to understand – APIs should be intuitive and well structured

• developer centric interfaces – all interfaces shall be designed with the minimum informationrequired by the developer

• low coupling – in order to encourage reuse the various classes should have low coupling (i.e. inorder to understand a class, a developer should be forced to understand a minimum number ofother classes)

• well structured – the toolkit should be divided into well identified subsystems / components(e.g. entity subsystem, services subsystem, graphics).The dependencies between these subsystems should be monitored closely

• use of patterns (standard or not) – In order to assist developers in understand complex softwarepatterns should be employed and documented.

• designed for reuse – when designing eDEP we shall strive to identify key behaviour which atypical developer would wish to modify. This behaviour should be encapsulated in a replaceableunit (interface + class).

• well documented – this includes design, java-doc, user and tutorial documentation

As an example, consider the following characteristics which exist in the current eDEP software,

• use of patterns

• ATC services pattern, with server-side interface and client-side interface. Between the twowe pass messages, but within the client and within the server we manipulate OO entities(rebuild from the messages)

• developer centric interfaces –

• the introduction of the EntityContext interface, which defines a clear container contract tothe entity developer. This pattern should be reused elsewhere.

• low coupling -

• Entity objects should rely upon a minimum number of classes (e.g other entities). Inparticular, entities should not know about graphics and ATC services

• graphical objects (such as Radar Labels, or the PVD) should only depend on Entity objects.It is not expected that graphical objects directly access ATC services

• design for reuse

• ATC Entities – these entity classes are very loosely coupled and could be reused in othercontexts

• ATC Graphical objects (e.g. Labels) should be built on 3 levels –

• level 0 – generic behaviour (e.g. AwsLabel, AwsField, AwsRow …)

• level 1 – ATC graphical behaviour (e.g. EATMP colours and fields and popup menus)


Date : 14/11/01

Page : 8

EUROCONTROL


• level 2 – ATC functionality ‘plumbing’ (e.g. what happens when we select an XFL value)

During the design and development phase the above criteria (and others) shall be applied. The design revueprocess shall equally test the design with respect to these critiera.

Note : this implies that the current atcapp package shall contain more code. Currently, we mix applicationlevel and reusable code in the atc package layer

3.4 Tools Support

An appropriate UML tool shall support the software design process.

JBuilder5 shall be used for software development.

A software configuration tool (such as CVS) shall be used.

All software shall be developed on a PC Windows environment, using the Sun JDK (1.3 and then 1.4).

3.5 Coding StandardsThe supplier shall apply appropriate Java code and comment standards within the project (e.g. Sunrecommendations).

4. TENDER ISSUES

The bidder shall provide the following information within the response,

• proof of technical expertise in java / ATC (e.g CVs)

• software development schedule including

• major deliveries (as outlined below)

• minor ‘delivery’ dates (iteration completions, design proposal review points)

• software quality plan (coding standards, development process)

• necessary license agreement information concerning COTS products

The eDEP project shall at some point make demos available via the Internet. Hence, the issue of COTSproducts and runtime licence agreements is paramount.

Equally, the EEC is concerned with medium to long term maintenance issues. Hence the bidder shall statehis/her intentions with respect to maintenance and how the EEC can mitigate risk (e.g. avoiding bidder lock-in).

5. DELIVERABLES AND SCHEDULE

5.1 Software

The software shall be designed in accordance to section 3.


Date : 14/11/01

Page : 9

EUROCONTROL


The code shall contain extensive javadoc comments.

Full software source code shall be delivered to the EEC, respecting Graffica/EEC software licenceagreements.

5.2 Documentation

All documentation shall be delivered in MS-Word 97 format.

HTML documentation shall also be accepted (e.g. javadoc, on-line user guides)

The following documentation is expected,

• Architecture Document

• high-level document considering ATC components as black-boxes

• ATC component context diagrams (data flows)

• ATC Component interfaces

• Important UML sequence diagrams (FPL creation, Controller orders, significant events)

• Toolkit Design Document

• medium-level document outlining the major design centres(e.g. GSDK layer, ATC object layer, ATC Services layer, ATC HMI Layers)

• internal component design issues

• component design patterns (UML),

• threading issues / component dynamics

• distribution considerations

• this document should be at a higher level compared to the HTML javadoc documentation.

• Developer’s User Guide

• step-by-step tutorials on how to build ATC and HMI components.

• administration issues – installation, configuration, launching

• Comprehensive HMTL javadoc documentation

• Test Plan Procedure Documentation (with EEC participation)

5.3 Schedule

The following delivery schedule is expected


Date : 14/11/01

Page : 10

EUROCONTROL


Due Date (T0 +) Work Package Deliverable Description

1.5 months Standalone Edition(1st Delivery)

Architecture Document

Draft Design Document(focusing on FM, COORD, CWP design issues)

Draft Test Plan Document (developed in collaborationwith the EEC)

Initial prototype delivery

3 months Standalone Edition(2nd Delivery)

Updated Documentation (Architecture, Design, Test, andUser manual)

Tested Software (GRD and CWP functionality)2

• full ATC object model

• ATC core services upgrade (COORD, FM)

• EATMP CWP

4.5 months Experimentation Edition(1st Delivery)

Architecture, Design and Test Plan Document draftupdates for

• AIR focus (HMI + Pilot Manager)

• Distribution Support

• ATC Tool Services Upgrade (STCA, FPM)

7 months Experimentation Edition(2nd Delivery)

Document Updates

Software (GRD focus)

• Distribution Support

• ATC tool Services Upgrade (STCA, FPM)

Software (AIR focus)

• Pilot HMI (PWP)

• Initial Pilot Manager logic

• CWP upgrade (e.g. Feed / non-feed issues)

10 months Experimentation Edition(General Availability)

Document Updates

Full Software Delivery including

• Full Pilot Manager Logic (inc. basic 4D TP)

• Performance Issues

As previously mentioned the eDEP platform shall be developed within an iterative process – hence betweenmajor delivery dates, minor deliveries are expected (e.g. design reviews).

2 AIR behaviour is simulated through FM (i.e. aircraft immediately flies controller entered orders)


Date : 14/11/01

Page : 11

EUROCONTROL


6. PROJECT MANAGEMENT

6.1 GeneralCritical reviews, formal inspections and progress reports shall be conducted at all significant contract stagesaccording to a plan produced by the supplier in co-operation with the EUROCONTROL eDEP ProjectManager.

Reporting shall be:

• Weekly progress by email (very short and informal);

• Monthly formal progress reports

• For each major milestone completion;

• By exception for major problems and delays.

6.2 Roles and Responsibilities

The responsibilities shall be as follows:

• The Supplier:Shall be responsible for the organisation of all activities previously described which arenecessary for him to produce the deliverables.Shall manage all meetings and aspects of the contract, in co-ordination with the eDEP Manager(or his delegate). The Contractor shall provide, in co-operation with the eDEP Manager, agendasfor meetings and shall produce the minutes thereof.

• The eDEP Manager (or his delegate)shall be responsible for the overall control and organisation of the whole project (delegated tothe contractor) and shall assist in meetings.

• Decisions shall be prepared by the supplier, co-ordinated and agreed with the eDEP Manager,and made by the eDEP Manager (or his delegate).

• Reviews and Acceptance shall be as follows:Internal Supplier review followed by sign off by the eDEP Manager.

• In case of conflict, the eDEP Manager shall be the ultimate authority

7. AIR SUBSYSTEM REQUIREMENTS

7.1 Overall Architecture

The overall architecture is expected to be as follows,


Date : 14/11/01

Page : 12

EUROCONTROL


• Common Functionalitythe AIR and GRD subsystems may share common eDEP functionality3 where possible. Identifiedcomponents include

• Trajectory Predictor (TP)possibly configured with different aircraft parameters for error generation

• Flight Path Monitoring (FPM)for the generation of piloting report events?

• Time (TME)common simulation time source

• Initial Flight Plan (IFPL) and Airspace (ASP) serverscommon environment servers

• AIR subsystem

• Pilot Working Position (PWP)Graphical Piloting HMI containing limited (or even no) ATM logic

• Pilot Managerthe pilot manager shall contain all the AIR-side ATM logic. This includes

• navigating aircraft & state vector generation

• pilot order processing & aircraft trajectory management

• query processing (e.g. simple data access)

• asynchronous report processing (e.g. inform pilot posn 3 when a/c XXX reaches FL 200)

• maintaining the aircraft->pilot position mapping (with the necessary transfer logic)

• GRD Subsystem

• Flight Manager (FM)processes CWP generated orders/clearances. Maintains GRD trajectories

• Integrated Air Surveillance (IAS)generates the ‘radar’ a/c state vectors from the air-provided state vectorsIn more complex versions this may perform SSR-code/Flight Plan correlation (possibly with FMcollaboration)

• Controller Working Positions (CWP)measured CWP positions, connected to the Flight Manager

• Feed CWPhybrid non-measured CWP positions which act as both pilot and controller working positions

The following diagram summaries the expected architecture

3 Sharing component functionality does not necessarily imply sharing component instances at runtime.


Date : 14/11/01

Page : 13

EUROCONTROL


��

)��

)�� )

��

��*��

'��%��

)��

'��

)

�� '!

��+��*��"��*��"��

��

��

'*��"

'�

��,��

��-*�"��

�

��

��

��-*�"��

'��

7.2 Design Issues

The following issues have been identified by the EEC and should be addressed in the overall design –

• Richness of Pilot Order Object ModelThe MASS system supports a wide variety of pilot orders which can be combined in a number ofways (e.g. change [level] and heading) . Equally, Pilot Orders may be delayed or constrained (e.g.reach [level] at beacon [ref point]).Even though the eDEP AIR subsystem shall not implement all these pilot order combinations, theoverall design shall support the eventual implementation of combined, constrained/delayed orders.

• Relationship between Pilot Order Object Model and Trajectory ConstraintsThe issue of mapping pilot orders (possibly composite and delayed) to trajectory constraints requirescareful consideration.

• Open ended orders (Heading)The Pilot Manager will eventually need to support open-ended orders (e.g. heading orders). This willbecome especially true if weather conditions shall be simulated within the AIR subsystem4

Clear Design work is required to determine if the AIR subsystem should implement pilot orders ‘viatrajectories’ or ‘via instantaneous navigation’ (as is the case with MASS).

4 An aircraft on-plan will follow a fixed track to next waypoint (i.e. track not affected by wind). However, an a/cfollowing a heading order will be affected by wind (i.e. track will be affected by wind).


Date : 14/11/01

Page : 14

EUROCONTROL


• Improved TP functionalityIt is assumed that the current 3D TP will need to be upgraded to 4d constraints (time, rate of climb,rate of turn)

• Pilot HMIThe HMI should be designed (especially the order and data input windows) with extensibility in mind.That is, once the HMI framework is in place, it should be easy to add new order types.

• Feed CWPIn simple demonstrations (e.g. internet) the Piloting HMI positions would not be used. Hence, aflexible mechanism is required which allows the PilotManager to be driven via CWP clearances

7.3 PWP Requirements[1] The major requirements for the AIR subsystem are documented in the “MASS v9.0 AWP HMI

Specification” [Ref 1]. This document defines the current EEC ESCAPE piloting position HMI.

[2] The eDEP PWP HMI shall be a reduced subset of the ESCAPE PWP HMI (essentially a reduced subsetof pilot orders, and pilot order combinations).

[3] The Pilot Manager component shall provide sufficient functionality to support the PWP HMI data needs.

7.4 Pilot Manager Requirements from the HMI viewpoint

The follow section reviews the HMI requirements on the Pilot Manager, with particular reference to the“MASS v9.0 AWP HMI Specification”.

Extra screen shots are provided at the end of this document to complement the MASS specification.

7.4.1 Section 3 – Supervise Aircraft Flights

[4] The eDEP platform shall cater for Feed CWPs. Such feed CWPs would only invoke simple atomic pilotorders –

• Change Level (nominal rate)

• Change Speed

• Heading / Turn

• Direct To

• Transfer

7.4.2 Section 4.1 – Describe Existing Pseudo Pilot Display Screen

[5] The mapping of PWP to a/c is usually via frequency (SS-C-4.1.1.2). However, within eDEP this mappingshould be defined as a plug-in (within the Pilot Manager).

[6] SS-C-4.1.1.3 : The AudioLan connectivity shall be performed at the EEC

7.4.3 Section 4.1.2 – Display A/C Strips

[7] The eDEP Air subsystem shall not distinguish between pre-active and active flights as outlined in theMASS document. That is,

• the Pilot Manager shall not implement any pre-active pilot order functionality (e.g. cancel, early startetc)


Date : 14/11/01

Page : 15

EUROCONTROL


• the Pilot HMI shall only display active flight strips (i.e. the full 32 lines may be filled with active strips).

[8] The eDEP AIR Subsystem shall support the notion of datalink aircraft (e.g. colour coding of flight strips).However, no specific datalink order functionality shall be implemented.

7.4.4 Section 4.1.3 – Display Flight Information

[9] SS-C-4.1.3.2 the eDEP AIR subsystem need not cater for the various flight equipment (ATN, CPDLC,ASAS).

7.4.5 Section 4.1.4 – Display Flight History

[10] Flight history shall be maintained.

[11] Note : when an a/c changes frequency, the order history needs to be transmitted from the Pilot Managerto the new Pilot HMI.

7.4.6 Section 4.1.5 – Display Radar Map

[12] In the interests of timely software delivery and convenience, some deviation from the MASS specificationwill be allowed (i.e. allowing the reuse of existing eDEP PVD code)

7.4.7 Section 4.1.6 – Display Order Entering and Display Data Entering

[13] The MASS ‘Order Entry’ HMI has been designed to follow standard ATC phraseology – hence inputtingpilot orders is both intuitive and rapid. This shall be respected within the eDEP HMI.

[14] The pilot manager interface should model pilot orders in a similar fashion to the HMI – that is, HMIentered orders (including combined, delayed orders) should be easily translated into Pilot Manager calls.

[15] SS-C-4.1.6.1 : pre-active flight orders shall not be implemented

[16] SS-C.4.1.6.3 : ASAS order functionality shall not be implemented

[17] SS-C.4.1.6.4 : DATALINK order functionality shall not be implemented (although a future implementationshould not be excluded)

[18] SS-C.4.1.6.5 : TRAJECTORY NEGOTIATION order functionality shall not be implemented

7.4.8 Section 4.1.6.7 Enter Flight Orders

[19] The following table lists the MASS Pilot orders, and associates an implementation priority for eDEP. (seesection 3.1 for more information)

Category Flight Order Priority Comment

Navigation Start Orders

Start NavDelay NavModify Initial FLModify SID

Low

Report Passing Level Medium

Report OrdersReport / before beacon Low

Query Orders Query posn, time at beacon, time at level Low

Speed Control Orders Change SpeedMaintain Speed

VeryHigh


Date : 14/11/01

Page : 16

EUROCONTROL


Change LevelMaintain Level

VeryHigh

Reach Level LowLevel Control Orders

Change Climb / Descent Rate High 4D TP?

Resume Normal NavigationChange HeadingMaintain Heading5

Turn OrderDirect To

VeryHigh

Direction Control Orders

Intercept Localiser Low

Hold and Orbit Orders Hold, Orbit, Cancel Hold Medium

Time Constraint Orders Reach Waypoint Low

Flight Plan Modification OffsetRejoin RouteModify STARNew RouteGo -Around

Low

Avionics Orders Set SSR Transponder, Squawk Ident Medium

Flight Supervision Transfer Flight, Kill Flight VeryHigh

Data Link ACL Very Low

ASAS Orders Very Low

[20] General comment concerning composite orders: their implementation is not mandatory.However, time permitting, the supplier may implement a number from the following table.

Order Combined with

Change Speed (immediately) Change LevelChange Heading

Change Level (immediately) Set ROCDChange SpeedChange HeadingDirect ToTurnTransfer FlightReport when passing level

Change Heading / Turn Change LevelChange SpeedTransfer Flight

Direct To Change LevelChange Speed

5 maintain heading can be given when on plan – indicates that a/c leaves plan on current heading


Date : 14/11/01

Page : 17

EUROCONTROL


[21] No support for delayed orders shall be provided.

7.4.8.1 Report Flight Events

[22] All beacon-passing events should be automatically reported in the Flight strips ‘reporting’ column.

[23] Given sufficient time, a simple subset of SS-C-4.1.6.7.2 is expected. Namely

• report passing altitude

7.4.8.2 Speed Control Orders

[24] Orders will be expressed in either IAS (CAS) or MACH.

7.4.8.3 Level Control Orders

[25] the target level shall be restricted to Flight Levels (and not altitude)

7.4.8.4 Direction Control Orders

[26] Concerning Direction Control Orders: the notion of manual mode shall be supported.In the future wind may be introduced into the air subsystem (i.e. influencing the track followed by a/c onheading orders).

7.5 Extra Requirements

[27] Java Swing components shall be used where possible in the Order, Data Entry and Flight strip panels.

[28] [optional] The Pilot Manager in the future should be capable of introducing errors

• delay in processing Pilot HMI requests

• METEO effects

7.6 Development Schedule

The following iterations are expected,

• 1st iteration –

• major design work (demonstrating the feasibility of composite orders)

• Pilot Manager - basic order functionality(‘Very High’ priority work with the exception of 4d/speed related orders)

• Pilot HMI – initial HMI

• RMI support

• 2nd iteration

• TP improvements for speed related orders (see below)

• (optional) limited composite pilot order support

• other pilot orders (‘High’ priority work) such as Reporting

Further iterations (‘Medium’ priority work) will depend on remaining effort.


Date : 14/11/01

Page : 18

EUROCONTROL


8. SIMPLE PREPARATION TOOL

8.1 Work AllocationThis task shall be allocated to the EEC. The following section is provided for information only.

8.2 Overview

The eDEP platform requires a simple preparation tool that allows static and traffic data to be loaded,modified and saved. Such a tool shall be intuitive and efficient to use.

Given the richness of the ATM data and its strong interdependence (e.g. moving a beacon point implies thatall dependent routes and flights are equally moved?), such a preparation tool can become rapidly verycomplex.

This is especially true when flights are represented not as simple 3d trajectories, but rather as realistic InitialFlight Plans (IFPLs). That is, a sequence of 2d route segments with indirect application of Letters ofAgreement (for the dynamic calculation of the 3rd dimension – flight levels).

Hence, the software shall be developed in iterations

• 1st iteration (mandatory)

• core HMI development

• flights represented as a sequence of 3d points

• basic efficiency enhancing tools for traffic definition

• some copy/paste functionality (e.g. copying flights)

• Concept of flight templatesi.e. ability to define a template flight, which can be instantiated a number of times withsome random factor (e.g. start time).Updates to the template flight (e.g. profile change) are then carried into all flightinstances

• 2nd iteration (mandatory – although exact nature of work shall be re-evaluated)

• flights represented as 3d points or as realistic Initial Flight Plans – 2d route segments withLoA application

• dynamic part to tool (running the eDEP platform within the prep tool)

• route expansion / strategic constraints / trajectory calculation from IFPL

• conflict calculation (with ability to dynamically change flight start times in order togenerate conflicts)

• CWP visualisation

• 3rd iteration (work to be performed by the EEC)

• Refactoring of the Entity Load/Save functionality into a Data Source plug-in framework

• Development of an EEC IPAS Data Source plug-in


Date : 14/11/01

Page : 19

EUROCONTROL


8.3 General requirements

[29] The HMI shall be developed using Java Swing components

[30] The HMI shall be intuitive, following Javasoft Swing look and feel / interactivity recommendations.

[31] Where appropriate, graphical interaction shall be favoured over simple text entry interaction.

8.4 1st Iteration – Basic Functionality

[32] The EEC shall supply an initial java mock-up of the expected HMI (from an existing Eurocontrol tool).

[33] This iteration shall implement the core HMI functionality

• Geographical view – PVD-style view of airspace and traffic

• Vertical profile view – for viewing trajectory profiles

• tabular views – for viewing data in tabular format

[34] The Geographical view shall display the following data in independent layers

• Static data layer

• Map layer – filled or outline map data

• Sector layer

• Point layer (beacons, fixes, airport / runway points)

• Route Layer (SID, STAR, route)

• Traffic layer (aircraft trajectories)

[35] Within the geographical view the following shall be possible

• move layers up or down in the drawing order

• make a layer visible or invisible

• increase / decrease the amount of detail within a layer (e.g. with / without additional text labels)

• zoom / re-centre functionality

[36] All geographical view layers (apart from the map layer) should be mouse-sensitive (i.e. editable). Namelythe following interactivity should be supported,

• sector layer – selecting a sector, editing the points defining a sector, delete sector, create new sector

• beacon layer – selecting a beacon, move beacon6, delete beacon, create beacon

• route layer – selecting a route, editing the points defining a route, delete route, create new route

• traffic layer – selecting a flight, copy/paste flights, editing the flight’s constraint points, delete a flight,create new flight

[37] Tabular views shall present entity data in text format. This is complimentary to the geographical view,and in certain cases necessary for data that is not easily represented in graphical format (e.g. sector min/ max FL values).

[38] The tool shall provide load / save functionality

6 moving a beacon – implies that dependent routes and trajectories shall be modified


Date : 14/11/01

Page : 20

EUROCONTROL


[39] The tool shall provide a number of efficiency aids

• copy / paste of flights

• concept of template flights

8.5 2nd Iteration

[40] Flights shall be represented as either

• simple trajectories - sequence of 3d points (as in 1st iteration)

• Initial Flight Plans – 2d route segments + RFL. Implies an implicit application of LoA

[41] The definition of flights as IFPLs requires

• richer graphical editing tools (in order to define that flights follow route segments)

• richer ATM functionality(in order to display a flight’s vertical profile the Letters of Agreement must be dynamically evaluated)7

[42] The preparation tool shall incorporate eDEP FDPS/CWP functionality allowing traffic samples to bedynamically run seamlessly within the tool. This enables,

• Real TP profiles to be visualised (as opposed to simple constraint points)

• CWP positions to be run (for a chosen sector)

• conflicts to be identified

• conflicts to be created (manually or automatically) by altering start times

9. GRD FUNCTIONALITY IMPROVEMENTS

9.1 IFPL[43] The IFPL component shall dispatch Initial Flight Plans ‘x’ minutes before navigation start (where x is a

configurable value, defaulting to 10 minutes).

9.2 TP

The Trajectory Predictor shall be upgraded to incorporate a basic 4D capability. This allows the FM/Pilotlogic to support

• time constraints

• rate of climb / descent

• speed control

The aircraft model shall be improved to support several a/c types.

7 In other words, the prep tool contains eDEP Flight Manager logic


Date : 14/11/01

Page : 21

EUROCONTROL


9.3 COORD

The co-ordination server shall be upgraded to support the co-ordination logic required of EATMP GenericHMIs. Key improvements include,

• richer Co-ordination data content in order to support EATMP Labels and Sector Inbound Listfunctionality

• co-ordination dynamics that fit EATMP HMI needs (automatic and manual)

• transfer dynamics that fit EATMP HMI needs

• automatic mode for unmanned sectors (i.e. automatic transfer and negotiation acceptance)

9.3.1 Richer Data Content

[44] For each flight the following data shall be maintained

• global co-ordination state (if such a thing exists?)

• current controlling sector

[45] For each sector traversed by a flight, the following data shall be maintained

• COP (Co-ordination Point)8

• XFL

• 4d sector boundary crossing point

• co-ordination state with respect to (FROM,TO) sector pairs

9.3.2 Co-ordination Dynamics

[46] The co-ordination dynamics (i.e. state machine) shall be sufficiently rich to support the EATMP HMIneeds

• support for automatic ‘ACTivation’ 12 minutes (configurable) before sector entry

• support for FORCE ACT (from CWP)

• support for OLDI like XFL negotiation

• CDN (counter) proposal

• ACP accept

• RJC reject

[47] Advanced functionality to be added in a second iteration

• Support for automatic compliance filtering (i.e. flight XFLs that conform to LoA).

• Support for co-ordination updates (REVision) that still conform to LoA.

• [eventual] support for MAC (abrogation – a unit is no longer traversed due to some FPLchange)

8 The COP shall be deduced for flights no longer following standard routes (e.g. heading, direct to orders)


Date : 14/11/01

Page : 22

EUROCONTROL


9.3.3 Transfer Dynamics

[48] The transfer dynamics (i.e. state machine) shall be sufficiently rich to support the EATMP HMI needs

[49] However, the following need not be implemented

• A/C RECALL function (section 5.2.4.3 [Ref 3] )

• A/C HANDOVER (TRANSFER variant for cases where LoA are not respected)

9.3.4 Automatic Mode

[50] The COORD server should provide support for unmanned sectors

• That is, relevant aircraft are automatically assumed and/or transferred

• For relevant aircraft, upstream co-ordination modifications are automatically accepted

• For relevant aircraft, downstream co-ordination modifications are automatically refused (?)

9.3.5 Design Issues

The impact of COORD upon other components (namely FM and CWP) needs to be carefully studied.

Specifically, efforts shall be made to ensure that the CWP co-ordination related code is maintainable.

The COORD state machine is partially in offline data files, and partially hard-coded (e.g. the COORD codethat sets event timers for different state machine changes). This hard-coded logic should be well identified.

The relationship between the GRD System trajectory and COORD data (especially XFL) needs to becarefully specified. For example,

• Initial (IFPL-derived) Trajectory used to calculate XFL values?

• Afterwards, trajectory updates in vertical plane do not effect XFL values (rather, it indicates adivergence)?

9.4 FM

[51] The FM shall require upgrades in order to integrate the COORD server component.

[52] The FM shall be upgraded to

• provide route expansion & (simple) strategic constraint addition (LoA) for traditional IFPL processing

• still support a more simplistic IFPL processing model (i.e. IFPL consisting of a list of 3D points notrequiring any route expansion & strategic constraint addition)

• provide a modular internal architecture allowing FM-variants to be rebuilt easily

9.5 STCA

[53] A simple STCA component is required

9.6 FPM

[54] The FPM component should be extended to fully implement

• Significant point passing notification

• Deviation warnings (lateral, longitudinal, vertical)


Date : 14/11/01

Page : 23

EUROCONTROL


10. IMPROVED CWP FUNCTIONALITY

10.1 Anti-overlap

[55] The CWP will be upgraded to include some form of label anti-overlap. The EEC may supply an existingjava algorithm as input to this task (TBD).

10.2 CWP Management

[56] It should be able to qualify a CWP position with the following attributes

• sectors under its control (1+)

• controller role (e.g. planner, tactical, supervisor etc)

[57] It should be possible to locate CWP position remote interfaces based on these characteristics (this maybe attributed to the Discovery Mechanism to be added in the RMI implementation).

10.3 ‘Reuse’ Design Issues

It is expected that eDEP clients will very often re-engineer CWP code. Hence the eDEP CWP shall bedesigned for reusability.

Typically this implies that the graphical behaviour is separated from the functional (interactive) behaviour.

[58] There shall exist a reusable and extendable EATMP PVD class. This class shall encapsulate EATMPbehaviour beyond that of the generic AWS Canvas class (filtering, toolbox). The class shall equally offerplug-in points for application developers,

• factory issues : e.g what classes to use in order to represent graphical objects (e.g. labels,beacons etc)

• plumbing plug-ins – entry points for specifying ‘added external functional behaviour’ (see below)

[59] The EATMP ACC Label code shall be separated into different reusable blocks

• Graphical Behaviourlabel colours/field visibility etc based on current Aircraft Entity state

• Added Self Contained Functional Behaviourstandard behaviour when clicking on fields (e.g. XFL, CFL, PEL, TRANSFER menus)

• Added External Functional Behaviourthe final ‘plumbing code’ that typically determines what external action is required when the Self-contained functional behaviour terminates (e.g. click on XFL field -> XFL menu -> select valueFL290 -> ??). In a typical application the end action involves calling the FlightManager andpotentially the PilotManager (hybrid CWPs).

It is typically the 3rd element (External Functional Behaviour) that needs to be separated out in order toensure code reusability.

For example, one design implementation strategy could be the following

• eatmp.acc.Label – class that implements the graphical behaviour (i.e. fields, colours, visibility,and initial fuctional behaviour – i.e activation of popup menus). This class is only dependent onentity (Aircraft) and AWS objects (AwsLabel, Button, Menus)


Date : 14/11/01

Page : 24

EUROCONTROL


• eatmp.acc.LabelBehaviour – an interface defining the label behaviour entry points. Typically, theoperations on this interface are called when values are selected from label popup menus.Forexample,

interface LabelBehaviour { void xflChosen (int XflValue); void cflChosen (int CflValue); void forceActivation ();…}

• eatmp.acc.DefaultLabelBehaviour – implements LabelBehaviour and simply raisesasynchronous events to the EventScheduler. Hence this default behaviour finally ties thegraphical class to the Event Scheduler paradigm

• Some CWPController class – will intercept these EventScheduler events and perform thenecessary calls to ATC services layer

[60] Consider extending the Aircraft entity and providing supplementary ‘Manager/Controller’ classes torepresent current aircraft focus/selection. Issues include,

• ‘intra-selection’ issues :when an a/c is ‘selected’ all relevant graphical objects (views) should be informed9. For example,selecting an a/c in the PVD may cause entries in the SIL, Message windows to be selected.

• ‘inter-selection’ issues :when an a/c is selected it may have an affect on previous aircraft selections (e.g. single focus policy)

10.4 Example CWP Application

[61] The eDEP platform shall be delivered with a clear distinction between

• reusable CWP code (to be found in atc.graphics atc.cwp)EATMP graphics code shall be suitably placed here (potentially an atc.eatmp package)

• a specific CWP application used for testing / demo purposes (to be found in atcapp)(note : this is currently not the case)

[62] The specific CWP application shall have the following characteristics –

• uses the reusable EATMP look and feel

• ability to function as a feed sector (through some configuration parameter)

10.5 EATMP – 1st Iteration

10.5.1 Overview

The default CWP delivered with eDEP shall migrate towards an EATMP look and feel. The emphasis shallbe placed on supporting an EATMP ‘flavour’ by implementing key EATMP features. Complete 100% EATMPcompliance (especially the proprietary window manager behaviour) is not expected in this iteration.

This initial step shall concentrate on implementing essential EATMP functionality within the PVD such as

9 This probably implies an ‘entity’ attribute isSelected is changed, and all Views receive an attribute updateevent. This type of mechanism allows developers to easily add-on other ‘selected’ behaviour (e.g. cause thea/c to be selected in other CWP positions)


Date : 14/11/01

Page : 25

EUROCONTROL


• EATMP compliant data-block labels (content, colour)

• EATMP style menus (full compliance not expected10)

• EATMP style co-ordination (Sector Inbound Lists, Message In/Out Lists)

• (if time permits ) Initial PVD toolbox functionality11 (Zoom, Filter, ..)

• Elastic vector

Major input references include the EATMP Generic HMI Specification [Ref 3] and the EATMP Web site [Ref2].

10.5.2 PVD : EATMP Compliant Labels

The eDEP CWP shall be delivered with EATMP ACC Labels (as defined in section 3 [Ref 3]).

These labels should have standard interactivity (as defined in sections 4 and 5).

The following table defines the development priorities,

Task Priority Comment

ACC STANDARD Label Very High

ACC SELECTED Label Very High Standard field interactivity required (unlessspecified otherwise)

ACC EXTENDED Label (window) Medium optional 2nd iteration development (if time permits)

ACC NON CORRELATED Label Low

STCA HMI Support -- Development upgrade when STCA function is on-line

Manual Input Warning Low requires presence of EXTENDED Label window

XFL Non Conformance Medium

Manual aide memoire function Low

Tracker Function (section 4.4) Medium

Note: some deviation from the specification shall be accepted for menus (e.g. lack of scroll bar).

Careful attention shall be given to the A/C Co-ordination / transfer status and the corresponding label and NS(Next Sector) field colours. Certain functionality may be initially omitted,

• A/C RECALL function (section 5.2.4.3 [Ref 3] )

• A/C HANDOVER (TRANSFER variant for cases where LoA are not respected)

The following URL provides an interactive demonstration of EATMP compliant labelshttps://www.eurocontrol.be/hmi/show_room/acc/acc_label_frame.htm

10 For example – the 2nd iteration may implement difficult requirements (slider bars, retention areas)11 In this iteration the toolbox is not expected to support sophisticated drag & drop functionality


Date : 14/11/01

Page : 26

EUROCONTROL


10.5.3 PVD : Secondary Windows (Co-ordination related)

The Sector Inbound List (SIL) window is described in section 2.3.5.11 [Ref 3].

The Message In/Out windows are described in section 2.3.5.12 [Ref 3].

The full EATMP window manager functionality (temporary iconify) etc. need not be implemented in thisiteration.

10.5.4 PVD Popup Menus

The essence of EATMP menus shall be implemented with the eDEP CWP. That is, the EATMP-specifiedmenu content shall be implemented. However, the following details may be implemented in the 2nd iteration –

• slider bars

• retention areas (i.e. automatic menu closing if cursor leaves a certain area around the menu)

10.5.5 PVD Toolbox

If time permits, an EATMP-like toolbox shall be implemented. The following functionality is of use –

• level filters

• zoom

10.6 EATMP – 2nd Iteration (optional)

This optional phase (dependent on separate EEC funding) shall concentrate on detailed compliance issues.This includes,

• EATMP window manager functionality ([Ref 3] section 1.6)

• title bars, close buttons etc

• parent / child window concepts

• Full Tool box functionality (e.g. PVD toolbox with detachable areas)

• missing menu functionality (e.g. slider bars)

• MTCD, VAW, MONA, STCA HMI functionality

• detailed interaction issues

• concept of visual, acquisition & retention areas

• full input actions – point, single click, press & hold (for quick look) , press & drag, release

• menu closing once retention area is lost

10.7 Extreme Reusability (optional)

This work package is on the ‘wish-list’ assuming all other tasks have been completed.

• Look and Feel code orthogonal to core HMI functionality (as with Swing – metal, motif, windowsL&F).

• Full Java Beans implementation

• extreme Window re-use (not just widget re-use)


Date : 14/11/01

Page : 27

EUROCONTROL


11. EXPERIMENTATION FUNCTIONALITY

11.1 Distribution Framework

11.1.1 1st Iteration

The eDEP platform shall be deployed in one of two configurations –

• standalone configurationFDPS and CWPs (and possibly a PWP) within a single process (VM)

• experimentation configurationSimulation Engine (Pilot Mgr, FDPS) in one process, with a number of PWP and CWPs runningon different machines

This work package should address,

• implementing a simple RMI layer for the experimentation configuration(simple = no complex supervision framework)

• threading / dynamic issues introduced by RMI

• basic control HMI (Timer start/freeze/stop) functionality

11.1.2 2nd Iteration (optional)

Given time, the Distribution framework shall be extended to include a web presence – that is, the ability forclients to run eDEP platforms via the web.

Candidate technologies include Java Web Start (for experimentation platforms) and Applets (for simpledemonstrators).

11.2 Performance

Once a stable functional platform is in place, a number of performance factors require optimising for,

• platform size - number of CWP & PWP positions

• screen size – the eDEP platform shall run with 2k screens

• traffic size – number of a/c active in the system

This work package should address issues such as

• Profiling of eDEP – enabling a focused approach to tuning

• Distribution enhancements(e.g. use of MarshalledObjects – speeds up performance when the number of clients areimportant.)

• JDK1.4 Swing / AWT enhancements

• Volatile Image support

• Java 2D transparency versus Graffica transparency

• full screen support (suspension of Window Manager)


Date : 14/11/01

Page : 28

EUROCONTROL


• Understanding of general JDK performance issueshttp://java.sun.com/j2se/1.4/docs/guide/performance/index.html

• Applying common java patterns for performance improvements

• Object pools – in order to avoid costly object construction (e.g. in AwsContext for repaintrectangles)

11.3 Data Recording Framework (EEC work package)

The eDEP platform shall include a data-recording framework that provides access points to key areas of thesystem such as,

• Entity Model updates

• inter component communication

• HMI interactions

This framework should enable various data recording applications to be developed,

• recording / replay facility

• recording / analysis facility

11.4 Replay (EEC work package)

The eDEP platform shall be delivered with a basic replay facility. This facility should allow all external stimuli(such as CWP and PWP inputs) to be automatically re-injected into a re-run of a simulation exercise

12. TOOLKIT FEATURES (OPTIONAL WORK PACKAGE)

12.1 General

This optional work package is concerned with usability issues (e.g. ease of configuration) from a platformuser point of view (and not necessarily the developer point of view).

12.2 Configuration Framework

A general configuration framework shall be put in place, enabling window positioing, fonts, colours etc to beconfigured (loaded *& saved). The Preferences API for Java 1.4 may be of use.

12.3 Logging Framework

The JDK 1.4 Logging framework should be examined.


Date : 14/11/01

Page : 29

EUROCONTROL


13. ANNEX A : MASS SCREEN SHOTS

13.1 Basics

13.1.1 Nav Start / Transferred-in Flight

The following screen shot demonstrates a navigation start (which is similar to an aircraft transfer-in) forTCOUF.

Note that the Aircraft column for TCOUF is green – indicating to the pilot that this a/c is new. Clicking on theREPORTS column will remove this green background.

Note : the blue flight strips are non-active flights (not required in the eDEP pilot position).

13.1.2 Flight Selection

Selecting TCOUF in the Flight Strip Panel (clicking on the AIRCRAFT column) results in the following screenshot.

Note :

• yellow background colour for flight strip

• order groups. Within the context of eDEP only the following buttons should be sensitive -Transfer, Direct, Turn, Level, Heading, Speed, Backtrack, CancelNote : may be SSR

• The flight leg is displayed on the PVD with beacon time estimates

• The flight information panel contains TCOUF data


Date : 14/11/01

Page : 30

EUROCONTROL


• the flight strips panel is no longer sensitive – in order to select another a/c the BACKTRACK orCANCEL button must be selected.

• Note : clicking the MIDDLE Mouse Button anywhere within the piloting HMI is interpreted asBACKTRACK

13.2 Heading Order

13.2.1 Beginning a heading order

The following screen shot can be obtained in one of two ways

• Click in HEADING column of Aircraft Strip LTN561

• Click in AIRCRAFT column of Strip LTN561 (as above 13.1.2) and then click on ‘HEADING’button in Order Entry panel

Note the following

• The Flight Information Panel begins constructing the verbal order

• the heading button corresponding to the current heading is highlighted yellow


Date : 14/11/01

Page : 31

EUROCONTROL


The ‘CONTINUE HEADING’ order, for a flight on-plan, is equivalent to a HEADING order with the currentheading value (i.e. the flight will leave the flight plan).

13.2.2 Heading Data Entry Panel

The above screen shot illustrates the default values found in the heading data entry panel.

Clicking on the ‘other’ button shall shift the heading values by 5 degrees

[Optional : if time permits] Clicking once again on the ‘other’ button shall produce

This allows the entry of a 3 figure heading (1st,2nd,3rd digits)


Date : 14/11/01

Page : 32

EUROCONTROL


13.2.3 Executing a Heading order

Once a value is selected from the heading data entry panel we have the following

Note :

• the buttons STEEP TURN, TURNING LEFT, TURNING RIGHT, AT BEACON, AT LEVEL, ANDTHEN LEVEL, AND INTERCEPT are not to be implemented

• the buttons AND TRANSFER, AND SPEED, AND LEVEL shall be discussed later on

• the EXECUTE BUTTON is now present

Next the EXECUTE button is clicked in order to process the order. Note that clicking on the RIGHT HANDmouse button anywhere on the HMI shall be equivalent to clicking on the EXECUTE button

Having executed the order the HMI is as follows with the heading column for the LTN561 flight strip nowcontaining “349L270”


Date : 14/11/01

Page : 33

EUROCONTROL


Reselecting the LTN651 aircraft once it has reached the 270 heading will result in the following screen

The following should be noted

• the heading column is still green, indicating to the pilot that the flight is off-plan

• the PVD and Flight Info. Panel still show the previous plan times


Date : 14/11/01

Page : 34

EUROCONTROL


13.2.4 Turn Orders

Turn orders are obviously similar to heading orders and give rise to the following panels.

Firstly, clicking on the TURN button in the order entry panel gives the following,

Then selecting 10 degrees right,

Clicking on execute then returns to the usual post-execution panel with the heading column of the flight strip

containing

13.2.5 Rejoining Plan

This can be achieved in one of two ways

• Order Entry : HEADING -> ‘NORMAL NAVIGATION’ -> EXECUTE

• Order Entry : DIRECT -> DataEntry: -> EXECUTE

Once the order is given the following should be noted

• the aircraft heading (within the flight strip) is no longer green

• the beacon over flight times are updated


Date : 14/11/01

Page : 35

EUROCONTROL


13.2.5.1 Direct To

Clicking in the Order Entry panel on the DIRECT button will give the following

For eDEP purposes the LAT/LONG button is not active.

The other button allows a Direct to a beacon point not on the current plan – this acts like a heading order (i.e.the aircraft is still considered off plan). See section 13.7

Selecting a beacon point gives the following,

Finally, after EXECUTION, if we reselect the aircraft then we have the following screen


Date : 14/11/01

Page : 36

EUROCONTROL


13.2.5.2 Resume Normal Navigation

Clicking successively in the Order Entry panel on HEADING and NORMAL NAVIGATION will produce thefollowing

For eDEP purposes the ‘AT xxx’ order buttons and the LAT/LONG data buttons are not present/sensitive

Note the following

• immediately selecting EXECUTE will cause the flight to rejoin the plan via the 1st point

• Otherwise, a planned beacon is selected and EXECUTEd.

13.3 Level Orders

A Level order may be initiated either via the order entry panel (i.e. flight selection -> LEVEL) or directly viathe flight strip (clicking on the LEVEL column).


Date : 14/11/01

Page : 37

EUROCONTROL


Either way, results in the following

Note :

• for eDEP purposes the altitude values are not required

• the REACH buttons are not required

• within the data entry panel the current FL is coloured yellow, and unachievable FLs colouredgrey

• the OTHER button is not required

Selecting a FL results in

The majority of these ‘AND’ and ‘AT’ buttons are not relevant to eDEP.

13.4 Speed Orders

Selecting a flight (e.g. LTN651 , and then clicking on the Order Entry Button ‘SPEED’ results in the following


Date : 14/11/01

Page : 38

EUROCONTROL


The following should be noted

• Concerning the data entry panel

• it contains either IAS or MACH values (in this case MACH)

• the ‘normal’ mach speed is highlighted, and the text ‘MACH NORMAL’ is found in the flightinformation panel. Clicking on EXECUTE will cause the flight to fly at normal speed (i.e. anyprevious speed control is now cancelled)

• Otherwise, a MACH value is selected

• Note: the bottom half of the panel allows explicit values to be specified (eDEP does notrequire this)

• Concerning the order entry panel

• the ‘AT xxx’ buttons are not required/sensitive.

• the TAS button is not required

Selecting a value results in

The ‘AT” buttons are not relevant. See below for the ‘AND ‘ buttons.

Once executed the flight strip is updated as follows,


Date : 14/11/01

Page : 39

EUROCONTROL


Note :

• the text indicates Speed control is applied to this flight

• once the MACH speed .86 is reached the .81 -> .86 text is replaced by .86

13.5 Transfer Orders

Clicking on the transfer order button (or directly on the strip’s frequency column) results in

Note : ignore the Pilot button

13.6 Combined Orders

13.6.1 General Comment

This work package depends on the renaming effort available. If time permits, the supplier should implementa number of combined orders.

For the majority of combined orders, the HMI (order + data panels) follows the standard patterns.

When entering the 2nd order, the order panel has less ‘option’ buttons (i.e. can’t combine combined orders).So, as an example consider the level + speed combined order, which gives the following screen shot


Date : 14/11/01

Page : 40

EUROCONTROL


Compare the above screen shot to a normal speed order.

13.6.2 Level and Rate Of Climb

When selecting the ‘AND RATE’ combined order, the screen is as follows,

13.7 Direct To – Leaving the plan

As mentioned in section 13.2.5.1 a DirectTo order can take the aircraft off plan. In other words the a/c is sentto a beacon point not in the current plan.

Note: this point is not added to the plan – in fact, the plan is suspended (as is the case with a heading order).

In order to rejoin the plan a resume normal navigation or direct-to order must be given (as in section 13.2.5).

In fact, if the a/c reaches this beacon point without having received a new order, the a/c will perform somedefault action (orbit around point, or continue on same heading).


Date : 14/11/01

Page : 41

EUROCONTROL


Clicking on OTHER gives

Selecting ‘T’ lists all beacons beginning with T

Having selected TITUS, and EXECUTED the aircraft will now fly to this point.

As the following screen shot illustrates the plan is no longer updated

• note : the next beacon in the flight strip is in green (indicating off plan)


Date : 14/11/01

Page : 42

EUROCONTROL


13.8 Error Messages

If erroneous orders are input (.e.g resuming navigation for a flight already on plan) then a simple errormessage (with a green background) is placed in the flight strip ‘REPORTS’ column.

edep technical document trs requirements document · 2002. 7. 24. · company ref. template :...

Documents