AVENUE A TM V alidation EN vironment for U se towards E ATMS - - PowerPoint PPT Presentation

avenue
SMART_READER_LITE
LIVE PREVIEW

AVENUE A TM V alidation EN vironment for U se towards E ATMS - - PowerPoint PPT Presentation

AVENUE A TM V alidation EN vironment for U se towards E ATMS TRANSPORT RESEARCH PROGRAMME DG7 - TRANSPORT/AIR TASK N 4.1.3/24A OMG transportation 16 November 1999 Contents Avenue Overview Technical Overview CCM OASIS (Open


slide-1
SLIDE 1

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

slide-2
SLIDE 2

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).

slide-3
SLIDE 3

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).

slide-4
SLIDE 4

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

slide-5
SLIDE 5

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)

slide-6
SLIDE 6

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

slide-7
SLIDE 7

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 Sup Recording Component Application

slide-8
SLIDE 8

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).

slide-9
SLIDE 9

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

slide-10
SLIDE 10

Component IDL (IDL3)

Extension to IDL «packaging» language

Offered functionality

interfaces provided events emitted

Configuration attributes

Define a component in terms

  • f...

Dependencies

distant interfaces required events consumed

slide-11
SLIDE 11

Component IDL

IDL3 provides

  • architecture clarity
  • natural connectivity
  • dependency visibility
slide-12
SLIDE 12

Components need containers

container handles, component interconnection event issues transactions config / packaging issues

  • ther functions

Component is isolated from

the underlying architecture.

this is a standard & formal

way of creating wrappers.

slide-13
SLIDE 13

Component/Container interaction

Component interacts with container Container interacts with other container Container interacts with Component Components exchange information

slide-14
SLIDE 14

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.

slide-15
SLIDE 15

Component IDL

an IDL interface

defines the ‘what’ and not

the ‘how’

implemented by

component developers

middleware independent IDL3

Parser

IDL Container

container code

provides the vendor

specific ‘how’

IDL3 is parsed, producing :

slide-16
SLIDE 16

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).

slide-17
SLIDE 17

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

slide-18
SLIDE 18

CORBA services CORBA ORB

Technical framework

OASIS services NS EDS IRP XSP Component context

  • events
  • transactional
  • tech sup
  • properties

Tighter rules Container Events Connect Sup Recording Component Application

slide-19
SLIDE 19

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)

slide-20
SLIDE 20

PLUG Code Generation Toolkit : TDL parser

TDL : Template Description Language

IDL2 Container

IDL Parser

IDL3

TDL Parser

Plug :Presentation layer Universal Generator

OASIS Template IDL 3 to IDL 2 Template

slide-21
SLIDE 21

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).

slide-22
SLIDE 22

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).

slide-23
SLIDE 23

Decomposition is based on 3 views

FDP View AGDC View ABS/AS View

slide-24
SLIDE 24

FDP View

SFPL Flight info Fir Exit Point FPL Termination ADS Session Control (trajectory request)

FDPD ACR FPG GGDC TACT AS FPM MTCD SNET CWP AMAN DMAN WEA ASP AGDC

IFPL requests IFPL data IFPL data Aircraft data Airspace data Weather data SFPL data DMAN constraints AMAN constraints SFPL data CWP commands Messages to be sent Received messages Flight Activation Slots data ADS-Radar Tracks Trajectories Flight position Flight progression Trajectory deviations Trajectories Flight Conflicts Trajectories SFPL data FLIPCY warning Flight Validity ADS-C gnd report (Aircraft Trajectory)

slide-25
SLIDE 25

Airborne/Surveillance View

A/C Logon Request A/C Contact Response ADS-C report AFPL Raw plots

Radar emulator ADS-B server AGDC

ADS-B TIS

ABS

A/C Logon Response A/C Contact Request CPDLC Link management Air CPDLC dialogue mngmnt CPDLC UM & DM

ACR

Aircraft Data

slide-26
SLIDE 26

Air-ground data link view

ADS-C gnd Report SFPL Flight info Fir Exit Point FPL Termination ADS Session Control (trajectory request) Flight Validity CWP FDPD AGDC Link status Downlink CPDLC messages DLIC warning Uplink CPDLC messages ABS A/c Logon Response A/c Contact Request A/c Logon Request A/C Contact Response ADS-C report AFPL AS CPDLC link management Air CPDLC dialogue mngmnt CPDLC 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

slide-27
SLIDE 27

Modules are decomposed further into sub modules

IFPM, supporting the Initial Flight Plan Information Management and the IFPL

dataset,

RTEM, supporting the Route Management and the Route dataset, CTRM, supporting the ATC Constraints Management and the Constraints

dataset,

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 List

dataset,

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 Correlation

dataset, and

FLIPCY, supporting the Flight Plan Consistency function. No additional datasets

are owned by this module.

slide-28
SLIDE 28

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

slide-29
SLIDE 29

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

slide-30
SLIDE 30

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

slide-31
SLIDE 31

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).

slide-32
SLIDE 32

Components

Modules are mapped to physical ‘peer’

components

Interfaces defined in CIDs (provided and

required interfaces in IDL)

Provided services Required services

slide-33
SLIDE 33

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

slide-34
SLIDE 34

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).

slide-35
SLIDE 35

The first instance

In parallel with module to component

mapping is the physical architecture

connecting components together static & dynamic modeling of the whole

slide-36
SLIDE 36

The Avenue 1st Instance

CPDLC DATALINK GATEWAY

JANE

ABS GATEWAY RADAR EMULATOR SURVEILLANCE GATEWAY

ADSP ARTAS

DATA FUSION DLIC

FLIPCY

ADS-C

EOLIA

Ground ATN Router

AVENUE Middleware, Arcades Recording and TMCS supervision

ASAS

MASS ECS

ASAS EONS FPM CP TP

Data Servers

IPAS

ARISTOTE

EVA

XXX XX X

Data preparation Files Off-line Recordin g Files ..... . AVENUE API AVENUE 1st Instance Component DIS/HLA X Simulators interconexion (SIMINGA) XX Private protocol (Asterix) XXX Private protocol (X.25, OLDI/SYSCO) SACTA/FD P