DOC 99-70-04

Common Modular SimulatorFinal Report

PHARE/CENA/CMS-2.4.3/FR; 1.0

Prepared by: JR. Velten, CENA

JG. Bakalemian, CENA

Date: May 99

EUROCONTROL 96 rue de la Fusée

B-1130 BRUXELLES

Copyright Statement CMS Final Report

-2- Version 1.0 / May 1999 DOC 99-70-04

The information contained in this report is the property of the PHARE Participants*.

The report or parts thereof may be published and or reproduced on the condition thatdue acknowledgement of authorship is made by quoting the copyright statementbelow. The copyright and the foregoing condition on publication and reproductionshall extend to all media in which the information may be embodied.

The information contained in this document is provided on an "as-is" basis and thePHARE Participants shall provide no express or implied warranty of any kind andshall accept no liability whatsoever for or in connection with the use of theinformation contained in the document.

* The PHARE Participants are:

- the EUROCONTROL Agency;

- the CENA (Centre d'études de la navigation aérienne);

- the STNA (Service technique de la navigation aérienne);

- the NLR (Nationaal Lucht- en Ruimtevaartlaboratorium);

- the RLD (Rijksluchtvaartdienst);

- the LVNL (Luchtverkeersleiding Nederland);

- the DLR (Deutsches Zentrum für Luft- und Raumfahrt);

- the DFS (Deutsche Flugsicherung GmbH);

- the UK CAA (Civil Aviation Authority);

- the NATS (National Air Traffic Services);

- the DERA (Defence Evaluation and Research Agency)

Copyright statement:

The copyright in this report vests in the European Organisation for the Safety of AirNavigation (EUROCONTROL); the CENA (Centre d'études de la navigationaérienne); the STNA (Service technique de la navigation aérienne); the NLR(Nationaal Lucht- en Ruimtevaartlaboratorium); the RLD (Rijksluchtvaartdienst); theLVNL (Luchtverkeersleiding Nederland); the DLR (Deutsches Zentrum für Luft- undRaumfahrt); the DFS (Deutsche Flugsicherung GmbH); the UK CAA (Civil AviationAuthority); the NATS (National Air Traffic Services) and the DERA (DefenceEvaluation and Research Agency).

All rights reserved.

CMS Final Report Revision History

DOC 99-70-04 Version 1.0 / May 1999 -3-

REVISION HISTORY Date

Revision Number Reason for revision

12/09/98 0.1

26/04/99 0.2 Conclusion and suggestions added

17/05/99 0.3 Completion of Executive summary and Chapter 4

18/08/99 1.0 Publication Version

Document Approval CMS Final Report

-4- Version 1.0 / May 1999 DOC 99-70-04

DOCUMENT APPROVAL

NAME SIGNATURE DATE

AUTHOR 1 JG. Bakalemian

Sep 99

AUTHOR 2 JR Velten

Sep 99

Project Leader JR. Velten

Sep 99

PHARE ProgrammeManager

H. Schröter

Sep 99

CMS Final Report Executive Summary

DOC 99-70-04 Version 1.0 / May 1999 -5-

EXECUTIVE SUMMARY

The main objectives of the Common Modular Simulator project were to:

• Provide a simulation and experimentation environment for new ATMconcepts, in such a way that software components could be identified,produced by individual participants as required and exchanged betweenthem.

• Improve the flexibility and adaptability of real-time simulators used forexperimentation.

• Permit closer collaboration between member establishments and crossfertilisation of research ideas through the exchange of softwarecomponents.

To that extent, the main goal of this project was to provide the PHARE programmewith a Common Modular Environment. Most of the effort within the CMS project hasbeen dedicated to the incremental definition of the Standard APIs in accordance withthe PATs tools requirements and to some extent in accordance, at the end, with theEFMS and PATN projects requirements. This is, in fact, in line with the mainobjectives of the project. This has led to the delivery of a set of really mature set ofATM APIs as illustrated by the important role that these PHARE APIs has played inother European projects such as PATIO, CINCAT, DA VINCI and AVENUE. To thatextent, these APIs have progressively acquire the status of a « de facto » EuropeanStandard and this shall be seen as a very valuable contribution of PHARE to thewhole ATM R&D effort.

The other major result of the CMS project is the PARADISE prototype. The mainobjective of this prototype was to serve as a validation test bed for these standardPHARE APIs. But it has very soon been seen as an integration test bed for the PATstools. When considering the integration of ATM tools on such a platform it isimportant to highlight the three main phases that such an integration process need toencompass, namely the technical integration, the functional integration and finally theoperational integration. To that extent, the PARADISE prototype has been used tosupport the technical integration issues of the PATs in the scope of PD/1 and thefunctional integration ones in the scope of PD/2. It has nevertheless not beenpossible to assess the operational integration issues on PARADISE: PHARE has notdeveloped a common HMI software through the GHMI project (thus relaying thisoperational integration to the PHARE demonstrations sites), and the PD/3 project hasnot used CMS, except for the CENA platform.

The standardisation approach initiated by CMS in the frame of PHARE definitivelyneeds to be continued since it has proven to be beneficial. But as such definitionprocess need to be incremental in order to always stick to the evolving requirements,such standards have to be always consolidated, refined and augmented. It istherefore recommended to give them more exposure, as this has been undertaken inthe frame of projects sponsored by the European Commission.

CMS Final Report

-6- Version 1.0 / May 1999 DOC 99-70-04

This page left intentionally blank.

CMS Final Report List of Contents

DOC 99-70-04 Version 1.0 / May 1999 -7-

LIST of CONTENTS

1. INTRODUCTION................................................................................................. 9

2. OBJECTIVES AND DEVELOPMENT............................................................... 11

2.1 GENERAL OBJECTIVES ....................................................................................... 11

2.2 DESIGN AND QUALITY OBJECTIVES ..................................................................... 11

2.3 CMS DEVELOPMENT PHASES ........................................................................... 11

3. DESIGN AND ARCHITECTURE PRINCIPLES ................................................. 13

3.1 ACTIVE CLIENT-SERVER MODEL .......................................................................... 13

3.2 PHYSICAL DISTRIBUTION ..................................................................................... 13

3.3 OBJECT ORIENTED DESIGN AND CLIENT/SERVER MODEL....................................... 14

3.4 EXTERNAL, PRIVATE AND KERNEL APIS ................................................................ 14

4. CMS APPLICATION PROGRAMMING INTERFACE DEFINITION ................... 17

4.1 THE COMMON LIBRARY ....................................................................................... 17

4.2 THE APPLICATION PROGRAMMING INTERFACES .................................................. 18 4.2.1 Flight Application Programming Interfaces .......................................... 18 4.2.2 Surveillance Application Programming Interface ................................. 19 4.2.3 Environment Application Programming Interfaces............................... 19 4.2.4 Negotiation and P-ATN Application Programming Interfaces .............. 20 4.2.5 Deviation Application Programming Interfaces.................................... 20 4.2.6 Conflict Application Programming Interface......................................... 20 4.2.7 Simulation Application Programming Interfaces .................................. 20

5. THE PARADISE PLATFORM ........................................................................... 21

5.1 PHARE PD/2 ARCHITECTURE: PARADISE V1.7.4 ............................................. 21

5.2 PHARE PD/3 ARCHITECTECTURE: PARADISE V2.2 .......................................... 22 5.2.1 Simulation servers and TEST BENCH client ....................................... 22 5.2.2 P-ATN facilities.................................................................................... 23 5.2.3 Negotiation facilities ............................................................................ 25 5.2.4 Environment facilities .......................................................................... 26 5.2.5 Surveillance facilities ........................................................................... 26 5.2.6 Flight facilities...................................................................................... 27

6. PROJECT RESULTS AND CONCLUSIONS ...................................................... 29

7. SUGGESTIONS AND RECOMMENDATIONS .................................................... 31

8. GLOSSARY, LIST OF ACRONYMS ................................................................... 33

CMS Final Report

-8- Version 1.0 / May 1999 DOC 99-70-04

This page left intentionally blank

CMS Final Report Introduction

DOC 99-70-04 Version 1.0 / May 1999 -9-

1. INTRODUCTION

The objective of the Programme for Harmonised Air Traffic Management Research inEUROCONTROL (PHARE) is to organise, co-ordinate and conduct studies andexperiments aimed at proving and demonstrating the feasibility and merits of a futureair-ground integrated air traffic management system in all phases of flight. Such asystem should increase air traffic management capacity as well as safety andeconomy of flight in comparison with current non-integrated systems. The results ofthe programme should help to refine the description of the future Air Traffic Systemconcepts (ACG, FANS and FEATS) and of the best transition from the currentsystem to the new one as defined by the European ATC Harmonisation andIntegration Programme (EATCHIP) Phase IV/EATMS.

In the context of the PHARE programme a number of European researchestablishments, assisted by their administrations have decided to combine theirexperience and resources to enable a comprehensive and co-ordinated researcheffort, building upon the existing in-house research programmes.

The PHARE Programme had, from the very beginning, identified the need for acommon integration environment which allowed to create an homogeneousinfrastructure with the aim of facilitating and harmonising the development as well asthe evolution of ATM simulators in the different research establishments. As aconsequence, the Common Modular Simulator (CMS) project had been launched.

The present document is the final report of the CMS Project.

This report presents in chapter 2 the objectives and the development of the projectand in chapter 3 the main design and architecture principles that were adopted forthe definitions of APIs and the implementation of PARADISE.

The chapter 4 lists and describes briefly the APIs. The chapter 5 describes thePARADISE integration platform. This report will then deal with the results and willpropose some suggestions on the way forward after the conclusions.

CMS Final Report

-10- Version 1.0 / May 1999 DOC 99-70-04

This page left intentionally blank

CMS Final Report Objectives and Development

DOC 99-70-04 Version 1.0 / May 1999 -11-

2. OBJECTIVES AND DEVELOPMENT

2.1 GENERAL OBJECTIVES

The main objectives of the Common Modular Simulator were to:

• Provide a simulation and experimentation environment for new ATM concepts,in such a way that software components could be identified, produced byindividual participants as required and exchanged between them.

• Improve the flexibility and adaptability of real-time simulators used forexperimentation.

• Permit closer collaboration between member establishments and crossfertilisation of research ideas through the exchange of software components.

2.2 DESIGN AND QUALITY OBJECTIVES

The following principles were applied to CMS to achieve these objectives:

• Modularity: to master the complexity of ATC simulators, CMS proposeddecompose ATC simulators into a set of sub-systems of reasonable size.

• Flexibility: in an ATC simulation context, changes are likely to occur. As aconsequence, CMS put the emphasis on flexibility and expandability to easerapid evolution in functional specifications and the plug-in of new components.

• Standardisation. To ease the exchange of components, priority was given tothe standardisation of the APIs.

2.3 CMS DEVELOPMENT PHASES

This project has progressively built up the software environment to perform thesimulations necessary to evaluate and then validate the elements of the advancedATM systems. In particular, CMS has been the support for the development of thefunctions of the PHARE demonstrations.

The CMS partners had decided to concentrate on an architecture philosophy takinginto account both the various challenges of the project and the operationalrequirements of such ATM systems in the context of the PHARE Medium Termscenario, on one hand, and the relevant PHARE demonstrations, on the other hand.This has led to a very open and modular architecture concept based on a client-server model supported by a set of standard Application Programming Interfaces(APIs). One of the most significant advantages of this choice was the use of CMS asan integration framework, in particular for the PHARE Advanced Tools (PATs)project.

In accordance with the short, medium and long term use of the CMS, the threefollowing phases were initially defined:

• PHASE 1 : Requirements• PHASE 2 : Design and Implementation• PHASE 3 : Exploitation of CMS

CMS Final Report

-12- Version 1.0 / May 1999 DOC 99-70-04

PHASE 1 led to the inventory of CMS requirements, taking into account the variousCMS user requirements. This was the occasion to identify the products that the CMSproject had to develop. One of these products was PARADISE, a Prototype of anAdaptable and Re-configurable ATM Demonstration and Integration SimulatorEnvironment. The other products initially identified were the associated supportingtools namely PREPCOT for Data Preparation, LORAS for the management of theSoftware Components Library and ASCOT to assist users in Platform Configuration.

PHASE 2 was then dedicated to the design and implementation activities of CMS. Itsobjective was the implementation of the CMS sub-systems and associated tools. Butthis phase particularly concentrated on the development of the CMS APIs and theCMS components library in order to provide the means to build PARADISE, the CMSsoftware integration platform. A decision was effectively taken early in this phase notto develop the supporting tools, LORAS, PREPCOT and ASCOT. Moreover, it wasagreed that phase 2 would provide an integration test framework for the PATs tools.

PHASE 3 covered the exploitation of CMS and of its related deliverables andcomprised:

• PARADISE as the integration platform for the PHARE Advanced Tools andas the Core integration platform for PD/2;

• the continuing refinement of the APIs in order to support the 3 PHAREdemonstrations.

CMS Final Report Design and Architecture Principles

DOC 99-70-04 Version 1.0 / May 1999 -13-

3. DESIGN AND ARCHITECTURE PRINCIPLES

3.1 ACTIVE CLIENT-SERVER MODEL

The definitions of the CMS APIs are based on a standard client/server model:

A server:

• provides a set of services to its client, as the management of data anddatabase operations on these data (create, update, cancel) or the execution ofspecific algorithms.

• only answers the client's requests and never initiates the dialogue with theclient. In other words a server can run without any client.

• is able to serve several clients.• does not know « a priori » what will be its clients : the number and the location

of its clients may evolve without any impact for it.

A client:

• use the services provided by the servers.• only communicates with the servers through predefined business Application

Programming Interfaces (APIs), i.e. the server location, the supportinghardware used, the software design and the communication techniques arecompletely hidden to the client and any modification in the serverimplementation (algorithm modification for instance) has no impact for theclients.

Client and server are implemented in different processes or sets of processes.

In addition to the standard client server concept, CMS provides the subscriptionmechanism. This means that an API may include the definition of events and theassociated management routines. From a semantic point of view each event isassociated with a set of conditions. The client may subscribe to events defined in theAPI. It will then be notified by the server when the associated set of conditions willbecome true through the delivery of the event and the relevant associatedinformation.

Another feature of the CMS model is the possibility to associate several APIs to asingle server. This will enable to design modular APIs, reducing thus the couplingbetween the various components of the system. A client will only use the APIs itneeds and will not be impacted by the potential changes on other APIs of the sameserver.

3.2 PHYSICAL DISTRIBUTION

In order to provide a physical distribution of clients and servers on distinct processesor distinct computers, the CMS communication architecture is based on the RPC(Remote Procedure Call) model.

On the client side, a piece of code called the client stub provides the necessaryprocessing to adapt the underlying client/server communication layer to the service;typically coding and decoding services.

On the server side, a server stub performs a similar processing to receive requests,call the convenient procedure implementation and send back the reply.

Automatic code generators were used to help the production of these stubs.

CMS Final Report

-14- Version 1.0 / May 1999 DOC 99-70-04

3.3 OBJECT ORIENTED DESIGN AND CLIENT/SERVER MODEL

Similarities between the concepts developed in the client/server model and the objectoriented abstraction are straightforward.

Therefore, the following assumptions were made:

• Interface of one object, if necessary of several objects, is provided by oneApplication Programming Interface. When needed, the additional operations tohandle collections of this object are added.

• Public data related to the object are viewed as stored in the server supportingthe API, thus providing persistency to several users of the object.

• Implementation of the object methods and private data will be done through theimplementation of the server.

3.4 EXTERNAL, PRIVATE AND KERNEL APIS

The CMS architecture introduced 3 types of APIs:

• the external APIs used by the external client to access the servicesoffered by a server,

• the private APIs used by the internal clients to update data in the servers,• and the kernel APIs used by the internal clients to access kernel services.

Figure 1 is an illustration of how APIs are used into PARADISE.

figure 1 APIs Organization

EXTERNAL USERS

ConstraintData

TrajectoryData

SectorisationData

Flight PlanData

External APIs

Private APIs

... DATA

LAYER

ConsistencyManagementClients

SectorisationComputation

TrajectoryPredictor

Kernel APIs Use this API

an API

Event

CMS Final Report Design and Architecture Principles

DOC 99-70-04 Version 1.0 / May 1999 -15-

CMS APIs provide two access modes to an object or a group of objects:

• A synchronous access mode, using synchronous RPC call, allowing clients toperform usual operations.

• An event notification access mode, allowing clients to be warned of objectsmodifications. Clients must use a special operation, namely the subscriptionoperation, to specify the set of events they wish to receive. They may alsospecify, during subscription, a domain of interest. Clients should then onlyreceive events that belong to this domain. A typical example of use is tosubscribe to events related to the set of flights currently crossing a givencontrol sector.

A given API or service is defined by:

• a set of data types which defines the objects that the service handle;• a set of operations which defines the methods associated to these objects;• a set of exceptions that may be raised when an error occurs during the

execution of an operation , and• a set of events that clients may subscribe to.

CMS Final Report

-16- Version 1.0 / May 1999 DOC 99-70-04

This page left intentionally blank

CMS Final Report CMS Application Programming Interface Definition

DOC 99-70-04 Version 1.0 / May 1999 -17-

4. CMS APPLICATION PROGRAMMING INTERFACE DEFINITION

The CMS APIs definition is made of two parts:

• the basic Air Traffic Management objects definition. These objects weregrouped into the COMMON library, and

• the methods associated to these objects wrongly named the APIs.

4.1 THE COMMON LIBRARY

The COMMON library defines the basic ATM objects and is organised as follow:

• the BASIC directory contains the low level objects such as:

− Time− Units (meter, feet, mach and so on)− Hash table, sorted list, ...− Usual mathematical functions (sin, cos, ...)

• the ATC TOOL directory contains all the classical air traffic control proceduresand aircraft attributes. These definitions were the results of the MASS 4.0 datadictionary:

− Holds,− Airways,− Airports,− Approaches,− Sids and Stars,− Sectors,− Waypoints,− Latitude and longitude,− ATC centres,− Aircraft equipment, call sign, company name, ...− Aircraft kinematics and position data.

• the DAARWIN directory contains the definition of:− trajectory,− strategic and tactical constraints,− advisories,− tubes,− deviations,− progressions.

• the CITRAC directory contains the definition of the CITRAC format.

CMS Application Programming Interface Definition CMS Final Report

-18- Version 1.0 / May 1999 DOC 99-70-04

• the TRAJECTORY PREDICTOR directory contains the definition of:

− the trajectory predictor API. This API allows an internal client toaccess trajectory prediction functions using the CITRAC format,

− the CITRAC operations which allow an internal client to prepare aCITRAC input from a set of constraint and convert a CITRAC outputinto a trajectory.

All these object definitions were available in both ADA and C programminglanguages.

4.2 THE APPLICATION PROGRAMMING INTERFACES

The collection of APIs has been divided in 7 distinct groups:

• Flight APIs, to manipulate flights data;• Surveillance APIs, to receive radar data;• Environment APIs, to receive information about flight environment;• Negotiation and P-ATN APIs, to manage trajectory negotiation and frequency

change dialogues;• Deviation APIs, to access deviation detection;• Conflict API, to access conflict computations;• Simulation APIs, to manage the execution of a simulation.

4.2.1 Flight Application Programming Interfaces

Several APIs were provided; each ones giving a different view of flight data:

• GENERAL: This API manages the user access point to the Flights databasemanaged by the Flight Processing System. The user of the API selects theflights he is interested in - his field of interest, which will be refined hereafter-,through a set of procedures providing a semantic close to a SQL request.During the run-time, the main events of the flight life cycle (e.g.: creation,deletion, etc.) are sent to this user only for the flights that are part of his field ofinterest.

• FLIGHT PLAN: This API provides all the facilities to create and modify flightplans.

• CONSTRAINT: This API provides operations to change the trajectory of a flightthrough imposing new strategic (e.g. route change) or tactical (e.g. controlorders) constraints.

• TRAJECTORY: This API provides the foreseen trajectory according to differentviews needed by different users (geometric description, strip-like description,tube description). This view is updated according to the flight progression.

• CO-ORDINATION: This API provides the mechanism to handle the negotiationprocess from upstream to downstream control units.

• SECTORISATION: This API exports the foreseen lists of sectors and thecurrent sector/entity of the flight. Two lists are exported: a first one concerningsectors for control (it means that these sectors have to take flight underresponsibility) and another one for information (sectors that have to be awareof flight but will not control it).

CMS Final Report CMS Application Programming Interface Definition

DOC 99-70-04 Version 1.0 / May 1999 -19-

• CONTEXT: The purpose of this API is to implement the "what if" functions asneeded for instance by the PAT project for alternative SPL. The concept ofcontext comes from the Data Base Management Systems where they supportthe transaction mechanisms with temporary copies of data. Here, when asimulation function is to be done on a given flight, a context has to be created(identified by a context-id) which will identify what may be seen as a temporarycopy of the SPL. Then, modifications on this "simulated flight" named by itscontext-id may be performed re-using the APIs related to the flight object. This"alternative SPL" will re-use all the existing functional components of the SPL(TP for example) server. This will result in a very cheap and flexibleimplementation of the alternative SPL for the PATs. It would effectively notmake sense for all the tools, which need to work on an alternative SPL, toduplicate a huge part of the SPL server just in order to, build and manageinternally a temporary copy of a system plan.

• TRAJECTORY UTILITIES: This API provides external clients with a way toaccess kernel services of the trajectory predictor.

• MSP: This API exports the foreseen list of multi-sectors crossed by a flight.Multi-sectors are defined as a set of one or several sectors.

• AIR NEGOTIATION: This API is dedicated to the PAT negotiation manager andprovides a way to update a constraint list and the associated trajectory for agiven flight without triggering the trajectory predictor. This API is usually usedwhen the negotiation manager receives a trajectory by data link and expectsthis trajectory to become the reference one into the ground FDPS.

4.2.2 Surveillance Application Programming Interface

This API provides surveillance data (navigation, kinematics data) for a flight.Surveillance data may be provided independently from any flight plan: this is thecase for data that are not correlated for any reason to a specific flight plan.

4.2.3 Environment Application Programming Interfaces

The environment APIs provide information about environment objects. They are theMETEO API, the AIRCRAFT APIs and the AIRSPACE APIs.

• METEO: These API provide meteorological observations (called analyseddata) and meteorological prediction (forecast data) as set ofmeteorological profile (e.g.: temperature, pressure settings, altitudewinds) on required 4D-points.

• AIRCRAFT: These APIs provide performance description (e.g.: flightenvelope, speed law policies according to a given aircraft, an airline, andthe nature of the flight: short, mid or long range) for all the civil andmilitary aircraft types pertinent for the system. The AIRCRAFT APIs are:− BADA_COEF: This API provides the data of an identified set of aircraft

in the SIM model form.− BADA_SYN: This API provides for given flight, synonym, i.e. an

equivalent aircraft from those described in the SIM model.− PERFO: This API provides other aircraft performance data.

CMS Application Programming Interface Definition CMS Final Report

-20- Version 1.0 / May 1999 DOC 99-70-04

• AIRSPACE: These APIs provide descriptions of the different airspaceelements described in the airspace model and the operations necessary todynamically change their state. The AIRSPACE APIs are :

− AIRPORTS− AIRWAYS− FIR and UIR− HOLDS− NAVIGATION POINTS− RESTRICTED AREA− RUNWAYS− SECTORS− SID and STAR

4.2.4 Negotiation and P-ATN Application Programming Interfaces

This API provides the data related to the establishment of air ground communication,and the data transmitted during Trajectory Negotiation

4.2.5 Deviation Application Programming Interfaces

This API provides the data related to deviations observed when comparing the actualflight to its foreseen trajectory. These data include information about the way that thedeviation was handled by the flight processing system. The API user definesthresholds, above which he will be notified of the deviations.

4.2.6 Conflict Application Programming Interface

This API provides the data related to conflicts found and conflicts that have beencleaned. The API also allows client tools to define such things as time or geometricboundaries to a requested conflict probe.

4.2.7 Simulation Application Programming Interfaces

• TIME• NAME• SUPERVISION

CMS Final Report The Paradise Platform

DOC 99-70-04 Version 1.0 / May 1999 -21-

5. THE PARADISE PLATFORM

The PARADISE platform was used to integrate the PHARE Advanced Tools andvalidate the design of the APIs. Several versions of PARADISE were published,always compliant with the in-use CMS APIs. A preliminary version of the PARADISEprototype was used to test the technical integration of the PD/1 PATs tool set. Thefollowing sections describe two other major releases: the ones used for PHARE PD/2(functional PATs integration) and PHARE PD/3 (operational PATs integration).

A PARADISE distribution always contained the following components:

• an implementation of the client/server protocol as it has been defined inthe « Active Client-Server concept »section ;

• a set of servers which provide the SIMULATION services : the TIMEserver, a NAME server and a SUPERVISION server ;

• a graphical client that manages the simulation execution. This client alsocalled the Test Bench, allows to select the exercise to be played and thecomponents to be launched.

In addition, a PARADISE distribution relied on the COMMON library and a set of datathat defined one or several environments and one or several exercises. Finally, astatic air traffic generator was also delivered to make possible the execution of anexercise. This component was a usual PARADISE client that fed the simulation testbench with flight plans and radar data in compliance with what has been defined intoa given exercise. This client was called StaticMass2Daarwin.

5.1 PHARE PD/2 ARCHITECTURE: PARADISE V1.7.4

Here is the description of the logical architecture of PARADISE platform version1.7.4. This version was used as part of the PD/2 simulation facility for the integrationof the PD/2 Advanced Tools and was subsequently run for the PD/2 demonstrationat DLR.

FPL Constr Traj secto Coord Deviat

trigger

cstr

trigger

TP

trigger

sect

trigger

coord

trigger

FPM

trigger

AM

CP

trigger

CP

figure 2 : The PD/2 PARADISE logical Architecture

The Paradise Platform CMS Final Report

-22- Version 1.0 / May 1999 DOC 99-70-04

5.2 PHARE PD/3 ARCHITECTECTURE: PARADISE V2.2

Here is the description of the PARADISE platform version 2.2. This configuration hasbeen used for the integration of the PD/3 Advanced Tools and is fully compliant withthe CMS V2.2 APIs definitions.

FPL Constr Traj secto Coord Deviat

trigger

cstr

trigger

TP

trigger

sect

trigger

coord

trigger

FPM

ACI

trigger

aci

MSP

trigger

msp

trigger

NM

trigger

PATN

Negot. PATN approach

trigger

DM

trigger

AM

CT

trigger

CT

CP

trigger

CP

figure 3 : The PD/3 PARADISE logical Architecture

5.2.1 Simulation servers and TEST BENCH client

Three different servers were provided; one for each simulation services:

• a NAME server;• a SUPERVISION server and• a TIME server.

Associated to these servers, the TEST BENCH client was provided to start andmanage a simulation.

CMS Final Report The Paradise Platform

DOC 99-70-04 Version 1.0 / May 1999 -23-

5.2.2 P-ATN facilities

Figure 4: PATN Facilities- Ground Side

On the ground, PARADISE V2.2 provided a server called the P-ATN server and twoclients: the P-ATN Trigger and the P-ATN Criterion.

The AIR P-ATN services were provided by one client: the AIR Trigger. The EFMSmodules play the role of a PARADISE server but it is completely hidden by the AIRP-ATN APIs.

GROUND PATN

Communication

Stack

Air Systems Real Aircraft, MCS,

Traffic Generators

X.25,

F

L

I

G

H

T

A

P

I

TrajectoryNegotiation

PATNCriterion

FrequencyChange

The Paradise Platform CMS Final Report

-24- Version 1.0 / May 1999 DOC 99-70-04

5.2.2.1 P-ATN Server

It provides access to P-ATN data links applications, stores protocol states for all datalink applications and propagates messages received from aircraft to ground users.

5.2.2.2 P-ATN Criterion client

This client has been designed to create flights into the P-ATN server when they arecreated into the FLIGHT server. In addition to that, it is able to maintain a P-ATNcriterion consistent with the one stored in the FLIGHT server.

5.2.2.3 P-ATN Trigger client

This client is the gateway to the P-ATN world. When a ground user requests to senda message, the P-ATN Trigger converts the message to P-ATN data structures andsends the message to the P-ATN stack. When a message is received on the groundfrom an aircraft, the P-ATN Trigger converts the message and asks the P-ATN serverto update its data base and broadcast the message to interested ground users; forexample the Negotiation Manager or the GHMI.

Figure 5: PATN Facilities - Air Side

5.2.2.4 AIR Trigger

This client is similar to the P-ATN Trigger client but dedicated to the AIR side.

Experimental Flight

Management SystemAir Trajectory Negotiation

APIAir Frequency Change

API

AIR PATNCommunication

Stack

X.25, Satellite

CMS Final Report The Paradise Platform

DOC 99-70-04 Version 1.0 / May 1999 -25-

Conflict Probe

5.2.3 Negotiation facilities

In order to manage the negotiation process and allow the integration of thenegotiation manager, the following client and server were developed.

5.2.3.1 Negotiation Server This server has the responsibility to store all negotiations related data for flights

currently flying. It is able to handle negotiation requests for 3D and 4D aircraft andground-ground co-ordination.

5.2.3.2 Negotiation Criterion This client has been designed to create flights into the Negotiation server when they

are created into the FLIGHT server. In addition to that, it is able to maintain aNegotiation criterion consistent with the one stored in the FLIGHT server.

Figure 6: Negotiation Facilities

GHMI 1 GHMI 2 GHMI 3

Negotiation Server

Criterion APINegotiation Private API

Negotiation Public API

Trajectory Negotiation API

PATN Server

Conflict API

Configuration API

Operational Server

FLIGHT Server

Constraint, Trajectory, Coordination, Sectorization,Air Negotiation, General, Flight Plan, Context APIs

The Paradise Platform CMS Final Report

-26- Version 1.0 / May 1999 DOC 99-70-04

5.2.4 Environment facilities

Three servers are available: aircraft, airspace and meteo. Each of these servers provides the services defined by the corresponding APIs.

5.2.4.1 Airspace Server

This server provides all the information concerning airspace objects. Data base loading is done at initialisation time and is based on MASS V4.0 data

dictionary.

5.2.4.2 Aircraft Server

This server provides all information concerning aircraft objects. Data base loading is done at initialisation time and is based on BADA V2.6

definitions.

5.2.4.3 Meteo Server

This server provides information concerning meteo conditions. Data base loading is done at initialisation time.

5.2.4.4 Operational Server and Configuration Init.

Operational organisation is stored in a server called Operational. This server alsocontains the MSP area organisation.

The initial operational configuration is loaded at start up thanks to the ConfigurationInit. client. A configuration can be dynamically changed during a simulation using theConfiguration API.

5.2.5 Surveillance facilities

5.2.5.1 Radar Server & Correlation Trigger

Surveillance service is provided by the radar server. A client called CorrelationTrigger is in charge of correlating a radar track with a flight plan that currently existsinto the Flight Server data base.

5.2.5.2 Flight Path Monitor

The Flight Path Monitoring functionality is provided by the PHARE Advanced ToolsFPM. Deviation data are computed by these components and available to externalusers through the deviation API.

CMS Final Report The Paradise Platform

DOC 99-70-04 Version 1.0 / May 1999 -27-

Figure 7: Surveillance Facilities5.2.6 Flight facilities

Flight services are provided by one server that is called the flight server. A set ofclients provides the necessary computation to feed this server with required andconsistent information; i.e trajectory, sectorisation, co-ordination and so on.

5.2.6.1 Flight Server

This server is the implementation of each flight service described in section XX.

5.2.6.2 Constraint Trigger

This client has the responsibility to maintain the consistency of all the constraints fora given flight. The mechanism is as follow:

• a user inserts or modifies a constraint using the constraint API;

• the flight server informs the Constraint Trigger by event notification that auser has requested to modify the constraint set for a given flight. The flightserver; when receiving this request; does not make immediately themodification into the flight data base but sends a request for modification tothe Constraint Trigger using the event mechanism.

External User External User

Flight Path Monitor

Deviation API

Surveillance API

Radar Server

FLIGHT Server

Trajectory and General APIs

The Paradise Platform CMS Final Report

-28- Version 1.0 / May 1999 DOC 99-70-04

• the constraint trigger receives the event notifying a request for aconstraint modification. It then processes the overall consistency of thenew constraint with the current ones and then calls the private constraintAPI to request the update for real.

5.2.6.3 Trajectory Trigger

The trajectory trigger has the responsability to ask the trajectory predictor to computea new trajectory given a new constraint set and then to update the trajectory data intothe flight server. The behaviour is the following:

• the constraint set of a given flight has been updated by the flight server;• the trajectory trigger catches the event related to the constraint

modification;• it then asks the TP to compute the new trajectory with the updated

constraint set;• the TP returns the new trajectory to the trajectory trigger which requests

the trajectory update to the flight server.

5.2.6.4 Sectorisation Trigger

This client is responsible of the sectorisation computation. Each time a trajectory iscalculated for a given flight, the corresponding sectorisation is re-computed. Thesectorisation consists in a list of sectors crossed by the flight and the estimated entryand exit times for each of them.

5.2.6.5 State Trigger

This client manages the global state of a flight into the system.

CMS Final Report Project Results and Conclusions

DOC 99-70-04 Version 1.0 / May 1999 -29-

6. PROJECT RESULTS AND CONCLUSIONS

Most of the effort within the CMS project has been dedicated to the incrementaldefinition of the Standard APIs in accordance with the PATs tools requirements andto some extent in accordance, at the end, with the EFMS and PATN projectsrequirements. This is, in fact, in line with the main objectives of the project. This hasled to the delivery of a set of really mature set of ATM APIs as illustrated by theimportant role that these PHARE APIs has played in other European projects such asPATIO, CINCAT, DA VINCI and AVENUE. To that extent, these APIs haveprogressively acquire the status of a « de facto » European Standard and this has tobe seen as a very valuable contribution of PHARE to the whole ATM R&D work.

The other major result of the CMS project is the PARADISE prototype. The mainobjective of this prototype was to serve as a validation test bed for these standardPHARE APIs. But it has very soon been seen as an integration test bed for the PATstools. When considering the integration of ATM tools on such a platform it isimportant to highlight the three main phases that such an integration process need toencompass, namely the technical integration, the functional integration and finally theoperational integration. To that extent, the PARADISE prototype has been used tosupport the technical integration issues of the PATs in the scope of PD/1 and thefunctional integration ones in the scope of PD/2. It has nevertheless not beenpossible to assess the operational integration issues on PARADISE: PHARE has notdeveloped common HMI software through the GHMI project (thus relaying thisoperational integration to the PHARE demonstrations sites) and the PD/3 project hasnot used CMS, except for the CENA platform.

In the frame of PD/1, the PARADISE prototype has effectively been used to exerciseand evaluate the technical integration of the PD/1 PATs tools set. Then, the PD/2project has decided to use PARADISE as the core ATC simulator of its simulationfacility thus implying that the PD/2 PATs tool set had to be integrated on PARADISE.PD/3 as a multi-site project involving three partners, finally took the decision not tocommit to the CMS standards, taking into account the technical difficulties to adaptboth the EEC and NLR simulators to the CMS APIs, despite the fact that CMS wasmainly targeted toward PD/3. As a consequence, PD/3 has unfortunately not been ina position to take full benefit of the interoperability offered by the CMS standards. Itshould therefore be noted that the latter simulators have used a lot of the CMScommon data type, thus making a decisive step toward these standards. In the frameof its PD/3 developments, the EFMS project has decided to use some CMS software,referred to as the «CMS light», to interface with the PATN software. It is regrettablethat the PATs tools never went to a full integration exercise with the big benefit todeliver a set of integrated tools to the demonstration simulators.

The first conclusion that can be drawn is that the CMS project has suffered from theconfusion between the logical architecture and the implementation. The name of theproject was may be misleading. Effectively, CMS was, in fact, aimed to be a CommonModular Environment. The PARADISE prototype was just a validation and testprototype. It was never designed as an other simulator to be deployed in theparticipating centre, despite it has proven its ability to become a real time simulationenvironment for PD/2.

Project Results and Conclusions CMS Final Report

-30- Version 1.0 / May 1999 DOC 99-70-04

An other important conclusion is that when defining an API, it is not sufficient to justdefine the data types, the procedures and the events. It is effectively of paramountimportance to also carefully define the semantic of the data types as well as theapplicative protocol supported by the API. This was particularly emphasised inPHARE through the experience of the Trajectory Predictor (TP) PATs tool, which hasprove to be a critical tool from the integration point of view. This is mainly becausethe TP is using complex data types in term of semantic and a rather complicatedapplicative protocol.

From the CMS experience in PHARE, it can also be concluded that such standardshave to be considered by all related projects. The EFMS project is a good illustration.Effectively, EFMS did not took the CMS standards into account when starting itsPhase 2 design, considering they were oriented towards ground systems. This hasproved to be rather expensive with regard to the overall system integration. On theone hand, because the EFMS TP was used in the ground PATs TP and as such hadto be adapted to the ground environment and on the other hand, because a complexand inflexible piece of software as the EFMS are more difficult to adapt. So anenvironment as CMS has to be considered as a whole: What could appear asflexibility for a given tool or sub-system could be constraining for another. Thisneeds to be accepted by all interested parties.

It is clear that there is definitely a price to pay for modularity and flexibility. It is animportant investment taking into account the evolution rate and the maintenancecycle of experimental platforms. However the most important issue is at thestrategical level. Such standards are of no value if there is not a global commitmentof all the interested partners.

CMS Final Report Suggestions and Recommendations

DOC 99-70-04 Version 1.0 / May 1999 -31-

7. SUGGESTIONS AND RECOMMENDATIONS

The CMS project has experienced a lot of difficulties due to the use of a very simpleword as “architecture”. As a consequence it is suggested a careful use of the wordarchitecture which is subject to various interpretation by different partners. It istherefore recommended to always be precise when using such words.

The standardisation approach initiated by CMS in the frame of PHARE definitivelyneeds to be continued since it has proven to be beneficial. But as such definitionprocess need to be incremental in order to always stick to the evolving requirements,such standards have to be always consolidated, refined and augmented. It istherefore recommended to give them more exposure as this has been undertaken inthe frame projects sponsored by the European Commission.

It is nevertheless suggested that a special attention is given to the adequatedescription of the associated semantic to ensure a common understanding of thesestandards. It is, in addition, strongly recommended that such standardisation workalways keep as a major objective to ensure the global consistency of the resultingstandards and pay a special attention at any time not to be driven by any specificrequirement of a given component of the system.

Such standards cannot be worked only on the paper and it is suggested that they areconstantly validated through the use of software prototype as PARADISE forexample. Effectively the deployment of such standards in various platforms calls foran independent test and validation platform, mainly to evaluate integration problems.But it is recommended that such prototypes are only considered for technical andfunctional integration since the operational integration can only be performed on thetarget platform.

From the experience gained in the PHARE programme, it is strongly recommendedthat standardisation initiatives are only undertaken if a minimum commitment from allthe key players is guaranteed in order to ensure the right return on investment. Tothat extent, it shall be highlighted that standards do not need to be fully used.

Finally, it is recommended that the development of such standard is considering theneed for common data preparation. Effectively, testing such standards on local testharness with their own set of test data set has proved to fail.

CMS Final Report

-32- Version 1.0 / May 1999 DOC 99-70-04

This page left intentionally blank

CMS Final Report References

DOC 99-70-04 Version 1.0 / May 1999 -33-

8. GLOSSARY, LIST OF ACRONYMS

ACSE Association Control Service Element

AES Aircraft Earth Station (AMSS)

AMSS Aeronautical Mobile Satellite Services

AOR-E Atlantic Ocean Region – East (INMARSAT satellite)

AOR-W Atlantic Ocean Region – West (INMARSAT satellite)

API Application Programming Interface

ARINC Aeronautical Radio Incorporated

ASN 1 Abstract System Notation

ASE Application Service Element

ATC Air Traffic Control

ATCo Air Traffic Controller

ATN Aeronautical Telecommunication Network (ICAO)

ATNP ATN Panel

BIS Boundary Intermediate System (a class of router)

CITRAC Common Interface for Trajectory Calculation

CMS Common Modular Simulator

CPDLC Controller-Pilot Data-Link Communications

DAARWIN Distributed ATM Architecture based on RNAV, Workstations, Intelligenttools, and Networks

DAP Downlinking of Aircraft Parameter

DLCRD Data-Link Communication Requirement Document

DMA Direct Memory Access

DRAM Dynamic Random Access Memory

EFMS Experimental Flight Management System

EMI ElectroMagnetic Interference

ES End System

EurATN European ATN

FC Frequency Change

FMS Flight Management System

GES Ground Earth Station (AMSS)

HDLC High Level Data link Control

I/O Input / Output

ICAO International Civil Aviation Organisation

IDRP Inter-Domain Routing Protocol

CMS Final Report

-34- Version 1.0 / May 1999 DOC 99-70-04

IEC International Electrotechnical Commission

IOR Indian Ocean Region (INMARSAT satellite)

IS Intermediate System (router)

ISO International Standardisation Organisation

LAN Local Area Network

MASS Multiple-Aircraft Simplified Simulator

MCS Multiple Cockpit Simulator

NARSIM NLR ATC Research SIMulator

OSI Open System Interconnection

PATN PHARE Aeronautical Telecommunication Network

PD/3 Third PHARE Demonstration

PDU Protocol Data Unit

PER Packed Encoding Rules

PHARE Programme for Harmonised of ATM Research in Eurocontrol

PR Position Reporting

ProATN Prototype ATN

SARPs Standards and Recommended Practices (ICAO)

SDU Satellite Data Unit (AMSS)

SITA Société Internationale de Télécommunication Aéronautique

TES Trial End System

TN Trajectory Negotiation

Transpac name of the public packet-switched data network operated by FranceTelecom

VDL VHF Digital Link

WAN Wide Area Network