avenue omg

36
AVENUE ATM Validation ENvironment for Use towards EATMS TRANSPORT RESEARCH PROGRAMME DG7 - TRANSPORT/AIR TASK N° 4.1.3/24A OMG transportation 16 November 1999

Upload: emmanuel-fuchs

Post on 12-Jan-2015

612 views

Category:

Technology


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Avenue Omg

AVENUE

ATM Validation ENvironment for Use towards EATMS

TRANSPORT RESEARCH PROGRAMMEDG7 - TRANSPORT/AIR

TASK N° 4.1.3/24A

OMG transportation16 November 1999

Page 2: Avenue Omg

Contents� Avenue Overview� Technical Overview

� CCM� OASIS (Open Architecture for SImulation System) and

PLUG (Presentation layer Universal Generator)

� System Development Approach� Logical Model� Component Interface Definition (CIDs) and

APIs � Component interconnection (first instance of

the system).

Page 3: Avenue Omg

Contents�Avenue Overview� Technical Overview

� CCM� OASIS and PLUG

� System Development Approach� Logical Model� Component Interface Definition (CIDs) and

APIs� Component interconnection (first instance of

the system).

Page 4: Avenue Omg

AVENUE

� European Union Project (4th Framework)

� Construct a European ATM Validation Platform� European agreement on IDL interfaces� 1st Platform built using OASIS

� Industry Driven � Validate operational concepts� Harmonize system interfaces� Provide practical system solutions

Page 5: Avenue Omg

AVENUE Partners

� AENA Aeropuertos Espanoles y Navegacion Aerea (E)� Aérospatiale Société Nationale Industrielle (F)� Airsys ATM SA (F), ATM UK Ltd (GB)� Alcatel ISR Informatique de Systèmes et réseaux (F)� ALENIA Alenia Difesa, un'Azienda Finmeccanica SpA (I) � DERA Defense Evaluation and Research Agency (GB)� DFS Deutsche Flugsicherung GmbH (D)� EEC EUROCONTROL Experimental Centre� INDRA DTD, S.A (E)� ISDEFE Ingeniera de Sistemas para la Defensa de Espana (E) � NLR Nationaal Lucht- en Ruimtevaartlaboratorium (NL)� SOFREAVIA Société Française d'Etudes et de Réalisations d'Equipements

Aéronautiques (F)

Page 6: Avenue Omg

Main design areas

� Infrastructure (middleware, recording,

configuration etc.)� CORBA Component Model

� Developed by EEC in line with standards : OASIS

� Support by AIRSYS tools : PLUG

� Application architecture

� IDL specification

� Independent of physical architecture

Page 7: Avenue Omg

CORBA services

CORBA

ORB

AVENUE component model

OASIS services NS EDS IRP XSP

Component context

•events

•transactional

•tech sup

•properties

Increasing

complexity

Tighter rules

Container Events Connect SupRecording

ComponentApplication

Page 8: Avenue Omg

Contents� Avenue Overview�Technical Overview

�CCM� OASIS and PLUG

� System Development Approach� Logical Model� Component Interface Definition (CIDs) � Component interconnection (first instance of

the system).

Page 9: Avenue Omg

CORBA Components� Industry driven

� based on experience of building complex distributed systems

� follows other emerging models (EJB, JavaBeans)

� Major content� Component extensions to IDL� Container / Component Model

Page 10: Avenue Omg

Component IDL (IDL3)

� Extension to IDL � «packaging» language

� Offered functionalityinterfaces providedevents emitted

� Configuration attributes

� Define a component in terms of...

� Dependenciesdistant interfaces requiredevents consumed

Page 11: Avenue Omg

Component IDL

IDL3 provides•architecture clarity

•natural connectivity

•dependency visibility

Page 12: Avenue Omg

Components need containers � container handles,

� component interconnection� event issues� transactions� config / packaging issues� other functions

� Component is isolated from the underlying architecture.

� this is a standard & formal way of creating wrappers.

Page 13: Avenue Omg

Component/Container interaction

Component interacts with containerContainer interacts with other containerContainer interacts with Component Components exchange information

Page 14: Avenue Omg

Component/Containers� Containers are like ‘wrappers’

� that isolate/protect the core function from the ‘architecture’ of the platform

� provide a neutral and simple interface to the core function.

� Tighten the rules for developers

� but also...� can provide additional added value functions,

such as data recording, data management� can be automatically generated.

� E.g for a different architecture we need only use a different code generator.

Page 15: Avenue Omg

Component IDL

� an IDL interface� defines the ‘what’ and not

the ‘how’� implemented by

component developers� middleware independent

IDL3

Parser

IDLContainer

� container code� provides the vendor

specific ‘how’

� IDL3 is parsed, producing :

Page 16: Avenue Omg

Contents� Avenue Overview� Technical Overview

� CCM�OASIS and PLUG

� System Development Approach� Logical Model� Component Interface Definition (CIDs) � Component interconnection (first instance of

the system).

Page 17: Avenue Omg

OASIS (Open Architecture for SImulation System)

� CORBA middleware� large scale simulation and pre-operational

validation� Built on ORBIX +..

� lifecycle� publish subscribe� data management� supervision� supports ADA83, C++ and JAVA

Page 18: Avenue Omg

CORBA services

CORBA

ORB

Technical framework

OASIS services NS EDS IRP XSP

Component context

•events

•transactional

•tech sup

•properties

Tighter rules

Container Events Connect SupRecording

ComponentApplication

Page 19: Avenue Omg

OASIS in Avenue

� Standard within EUROCONTROL� used by external partners� selected for AVENUE but upgraded

� modified to CORBA component/container model.

� Container uses OASIS services� Code generation (PLUG)

Page 20: Avenue Omg

PLUG Code Generation Toolkit : TDL parser

TDL : Template Description Language

IDL2Container

IDL

Parser

IDL3

TDL

Parser

Plug :Presentation layer Universal Generator

OASISTemplate

IDL 3 to IDL 2Template

Page 21: Avenue Omg

Contents� Avenue Overview� Technical Overview

� CCM� OASIS and PLUG

�System Development Approach� Logical Model� Component Interface Definition (CIDs) � Component interconnection (first instance of

the system).

Page 22: Avenue Omg

Logical architecture

� Logical modules derived from � CMS (common modular simulator)

� Daarwin (Distributed ATM Architecture Integrating RNAV, Workstations, Tools and Networks)

� ESCAPE (EUROCONTROL Simulation Capabilities And Platform for Experimentation)

� PATIO (Platform for ATM Tools Integration up to Pre-operation)

� Defined in SSDD (system/segment design document)

� Interface definitions in terms of API (Provided interfaces in IDL).

Page 23: Avenue Omg

Decomposition is based on 3 views

FDP View

AGDC ViewABS/AS View

Page 24: Avenue Omg

FDP ViewSFPL Flight info

Fir Exit PointFPL Termination

ADS Session Control (trajectory request)

FDPD

ACR

FPG

GGDC

TACT

AS

FPM

MTCD

SNETCWP

AMAN

DMAN

WEA

ASP

AGDC

IFPL requestsIFPL data

IFPL data

Aircraft data

Airspace data

Weather data

SFPL data

DMAN constraints

AMAN constraints

SFPL data

CWP commands

Messages tobe sent

Receivedmessages

FlightActivation

Slots data

ADS-Radar Tracks

Trajectories

Flight positionFlight progressionTrajectory deviations

Trajectories

Flight Conflicts

Trajectories

SFPL dataFLIPCY warning

Flight ValidityADS-C gnd report(Aircraft Trajectory)

Page 25: Avenue Omg

Airborne/Surveillance View

A/C Logon RequestA/C Contact ResponseADS-C reportAFPL

Raw plots

Radaremulator

ADS-Bserver

AGDC

ADS-B

TIS

ABS

A/C Logon ResponseA/C Contact Request

CPDLC Link managementAir CPDLC dialogue mngmntCPDLC UM & DM

ACR

Aircraft Data

Page 26: Avenue Omg

Air-ground data link view

ADS-C gnd Report

SFPL Flight infoFir Exit PointFPL TerminationADS Session Control (trajectory request)Flight Validity

CWP

FDPD

AGDC

Link statusDownlink CPDLC messagesDLIC warning

Uplink CPDLCmessages

ABS

A/c Logon ResponseA/c Contact Request

A/c Logon RequestA/C Contact Response

ADS-C reportAFPL

AS

CPDLC link managementAir CPDLC dialogue mngmntCPDLC UM & DM

Ground CPDLC dialogue mngmnt

WEA

ADS-C gnd report (Aircraft Trajectory

FLIPCY warning

ADS-C Session control

ADS-C gnd Report

ADS-C Session control

Page 27: Avenue Omg

Modules are decomposed further into sub modules

� IFPM, supporting the Initial Flight Plan Information Management and the IFPLdataset,

� RTEM, supporting the Route Management and the Route dataset,

� CTRM, supporting the ATC Constraints Management and the Constraintsdataset,

� TP, supporting the Trajectory Predictor and the Trajectory dataset,

� CDNM, supporting the Co-ordination Management and the Traversed Sector List and the Co-ordination Sector List datasets.

� SSRM, supporting the SSR Code Management and the SSR Code dataset,

� NTFM, supporting the Notification Management and the Notified Sector Listdataset,

� CMCM, supporting the Civil/Military Crossings Management and the Civil/Military Crossings dataset,

� OCLM, supporting the Oceanic Clearance Management and the Oceanic Clearance dataset,

� CORL, supporting the Track/Callsign Correlation function and the Correlationdataset, and

� FLIPCY, supporting the Flight Plan Consistency function. No additional datasetsare owned by this module.

Page 28: Avenue Omg

TP

CTRM

CDNM

Aircraft Data

Weather Data

FPM

SFPL

IFPL,Route,

Constraints

Compute Trajectory

SFPL

WEA

Trajectory

Flight position,Flight progression,

Trajectory deviations

ACR

Compute Trajectory

Example: Trajectory Predictor Context

Page 29: Avenue Omg

APIs

� An API is defined for each module.� No mapping to physical components� No implementation details� Just a large number of services in CORBA

IDL covering the ATM functions� First level (main) of interface

harmonization

Page 30: Avenue Omg

Example: Weather API

#include <AvWeaServices.idl>#include <AvWeaEvents.idl>

component AvWea {

//provided interfaces provides AvWeaServices::Services process; // processing services

// Emitted events. publishes AvWeaEvents::Event sigmet_event;

};

#endif // AV_WEA_MD_INCLUDED

Page 31: Avenue Omg

Contents� Avenue Overview� Technical Overview

� CCM� OASIS and PLUG

� System Development Approach� Logical Model�Component Interface Definition (CIDs) � Component interconnection (first instance of

the system).

Page 32: Avenue Omg

Components

� Modules are mapped to physical ‘peer’ components

� Interfaces defined in CIDs (provided andrequired interfaces in IDL)

Provided servicesRequired services

Page 33: Avenue Omg

Relationship between API and CID

Module Provides X

Provides Y

Module is allocated to physical component/s

Requires B

Requires A

API maps directly to provided interface of CID

Provides Y

Provides X

Required interface is added to CID

Page 34: Avenue Omg

Contents� Avenue Overview� Technical Overview

� CCM� OASIS and PLUG

� System Development Approach� Logical Model� Component Interface Definition (CIDs) �Component interconnection (first instance of

the system).

Page 35: Avenue Omg

The first instance

� In parallel with module to component mapping is the physical architecture

� connecting components together� static & dynamic modeling of the whole

Page 36: Avenue Omg

The Avenue 1st Instance

CPDLCDATALINKGATEWAY

JAN

E

ABSGATEWAY

RADAREMULATOR

SURVEILLANCEGATEWAY

ADSP ARTAS DATAFUSION

DLIC FLIPCY ADS-C

EOLIA

GroundATN Router

AVENUE Middleware, Arcades Recording and TMCS supervision

ASAS

MASS ECS

ASAS

EONSFPMCPTPData

Servers

IPAS ARISTOTE EVA

XXX

XX

X

Data preparationFiles

Off-line

RecordingFiles

.....

.

AVENUE API

AVENUE 1stInstance Component

DIS/HLAX Simulators

interconexion(SIMINGA)

XX Private protocol(Asterix)

XXX Private protocol(X.25, OLDI/SYSCO)

SACTA/FDP