difodam - Eurocontrol

Transcription

EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION
EUROCONTROL
EUROCONTROL EXPERIMENTAL CENTRE
DIFODAM
( Distributed and Fault Tolerant Flight Data Management )
EEC Report No. 326
EEC Task R16
EATCHIP Task ODP-5-E1
Issued: February 1998
The information contained in this document is the property of the EUROCONTROL Agency and no part should be
reproduced in any form without the Agency’s permission.
The views expressed herein do not necessarily reflect the official views or policy of the Agency.
REPORT DOCUMENTATION PAGE
Reference
EEC Report No. 326
Originator
EEC - F.D.R.
(Flight Data Research)
Security Classification
unclassified
Originator (Corporate author) Name/Location :
EUROCONTROL Experimental Centre
BP 15
91222 Brétigny-sur-Orge CEDEX
FRANCE.
Telephone: +33 (0) 1 69 88 75 00
Sponsor
Sponsor (Contract Authority) Name/Location
EUROCONTROL Agency
96, rue de la Fusée
B-1130 Brussels
BELGIUM
Telephone: +32 2 729 90 11
EATCHIP Development Directorate
DED.2
Title :
DIFODAM
(Distributed and Fault Tolerant Flight Data Management)
Authors
Date
Pages
Figs
Annexes
References
J.P. Florent
F. Barabas
A. Poddany
02/98
V + 22
3
-
4
EATCHIP Task specification
EEC Task No.
Sponsor Task No.
Period
ODP-5-E1
R16
R16
1996 - 1997
Distribution Statement :
(a) Controlled by :
Head FDR
(b) Special Limitations (if any) : None
(c) Copy to NTIS :
YES/NO
Descriptors (keywords) :
Client/Server Architecture, Groupware Communication, Shared Data, Data Distribution, Dynamic
Objects, Java Objects, Trajectory, Gate to Gate, Fault Tolerant
Abstract :
DIFODAM introduces the concept of Shared Flight Plans.
Traditional implementations of shared data rely on a central database management system which
guarantees data consistency.
We propose an alternative solution based on Group Communication which provides a simple, common
service for sharing Flight Plan Data in a synchronous multi-server context. We describe the design of
the architecture with emphasis on flexibility.
This document has been collated by mechanical means. Should there be missing pages, please report
to:
Publications Office
B.P. 15
91222 Brétigny-sur-Orge CEDEX
France
DIFODAM
DIFODAM
SUMMARY
DIFODAM introduces the concept of a Shared Flight Plan to support inter-operability and
seamless integration 1 . It is based on Group Communication which provides a simple, common
service in a multi-users context. A notification server maintains a consistent state for several
communication channels, each channel being a Shared Flight Plan (or other shared data).
Controllers (and pilots) can tune into and be in conference on flight plans. They will be able cooperate efficiently since they have access to the same set of data.
DIFODAM uses dynamic object technology 2 . Each Shared Flight Plan is a dynamic object which
can evolve (using inheritance) without disturbing the service. Clients which have not upgraded
their system can still use the old services, clients with an upgraded system can use also the new
services. Clients which want to upgrade are able to download the new software from the
notification server. This will facilitate a progressive introduction of new systems and services
across boundaries.
This architecture is able to manage different types of data simultaneously. It may be used for
applications like CDM (Collaborative Decision Making), ESCAPE (the new real time ATC simulator
of the EEC). The architecture is also applicable to ASD (Air Situation Display) and Interoperable
FDPS.
1
“New ATM concepts will require greater interoperability between systems of aircraft operators and ATM service
providers... The objective is to create system specifications which allow the design and implementation of an ATM
system to evolve over a long period of time involving diverse manufactures and without requiring systems to be
replaced before the end of their normal economic lifetimes. The specifications must enable inter-operability between
ground-ground element and allow seamless integration, development and upgrading with new technology”. (Yellow
Book on ATM R&D Strategy, Feb. 1997)..
2
Upgrading existing software systems usually requires switching off the system in order to make the necessary
adjustments. But for a growing number of today’s complex, mission-critical systems, ”switching off” is simply not an
option. Software updates or changes must occur while the system is fully operational; the software must be flexible
enough to accept new alterations without compromising current functions.
Enter dynamic object technology .. an enabling technology for user-evolved software. With dynamic object
technology, new software functions, new capabilities, and new classes can be added on the fly. Moreover, the work
being done is typically invisible to the user. In a world where software creations are changing at such a rapid pace,
dynamic objects have surely come of age.” (Diane Crawford, Executive Editor of Communications of the ACM ,
(Association for Computing Machinery, Inc.) Vol.40, No.5, May,1997.)
EEC Task N° R16 - EEC Report N° 326
III
DIFODAM
TABLE OF CONTENTS
1. INTRODUCTION ................................................................................................................... 1
1.1. Presentation ......................................................................................................................................................................1
1.2. Objectives..........................................................................................................................................................................1
1.3. Background : Air Traffic Management Context ..........................................................................................................1
2. DESIGN CONSTRAINTS ...................................................................................................... 2
3. GROUP COMMUNICATION.................................................................................................. 3
3.1. Synchronous group communication...............................................................................................................................3
3.2. Group communication applied to Flight Plan Data .....................................................................................................5
4. SHARED DATA ..................................................................................................................... 5
5. EVENT NOTIFICATION AND FILTERING ............................................................................ 6
5.1. Creation events .................................................................................................................................................................6
5.2. Update events....................................................................................................................................................................6
6. PERSISTENCE ..................................................................................................................... 8
6.1. Persistence on the server .................................................................................................................................................8
6.2. Persistence on the client...................................................................................................................................................8
7. TRANSACTIONS .................................................................................................................. 8
8. VERSIONS AND ACCESS RIGHTS...................................................................................... 9
9. FAULT TOLERANCE ............................................................................................................ 9
9.1. Fault tolerant Server........................................................................................................................................................9
9.2. Client failure detection ....................................................................................................................................................9
10. QUERIES ............................................................................................................................ 9
11. TRAJECTORY PREDICTOR............................................................................................... 9
IV
DIFODAM
12. CONCLUSIONS .................................................................................................................. 9
13. BENEFITS......................................................................................................................... 10
14. LIST OF REFERENCE DOCUMENTS .............................................................................. 11
VERSION FRANCAISE ....................................................................................................12
V
DIFODAM
1.
INTRODUCTION
1.1.
Presentation
The project is executed in the frame of the EATCHIP domain “Data Processing Systems” (DPS) to
investigate the effect of flight data distribution and fault tolerance on flight data management. The
scenario is based on the FDPS Interoperability Study, on System Supported Co-ordination
(SYSCO) and the associated standard for On-Line data Interchange (OLDI).
DIFODAM is an EEC project designated to meet the requirements of DPS.ET1.ST05.2000.
This document details the architecture design of the prototype’s implementation.
The purpose is to provide an interactive and collaborative service for the manipulation and
distribution of Shared Flight Plans.
The architecture relies on Java Shared Data API (JSDA ref. 2), a synchronous group
communication API implemented in the Java language.
The client applications of DIFODAM are Java Applets (accessible trough an Internet WEB
browser, e.g. Netscape) or standalone Java Applications.
1.2.
Objectives
DIFODAM implements a service of persistent shared data with update notification to clients:
•
Shared data : Flight plans and related data are shared in a multi-user context.
•
Persistence and transactions : Flight plans are stored in stable repository and updated
within transactions.
•
Event notification and filtering : clients are able to subscribe to a specific class of events
in order to be notified automatically of changes occurred on a flight plan.
•
Dynamic access rights : the right to modify a flight plan is exclusive and can be passed to
another client. The creator is the first owner of a flight plan.
•
Flight plan versions : a client can create versions of a flight plan and will be the owner of
this version.
Fault tolerance : DIFODAM uses replicated shared data in order to increase reliability.
1.3.
Background : Air Traffic Management Context
All over the globe new ATM systems are conceived or implemented. Those in the
implementation stage will stay in service at least until 2010, those in the design state even
longer. Common to all these systems is that they are designed for one site or ATC centre. This
applies also to project AVENUE in the frame of the R&D programme of the European Union. But
during their lifetime these systems will become co-operative and information sharing will be
normal.
They will also collaborate with non ATC systems. This is a necessary result of the collaborative
planning and decision making paradigm that is a key element of the future EATMS R&D
programme ("Yellow Book").
Collaboration and information sharing raise new questions. In addition to data consistency and
persistence and system compatibility new types of problems have to be resolved, e.g.
• who is responsible for shared data?
1
DIFODAM
• what are the contingency procedures to follow in case of failure?
• how to upgrade systems which share data?
• how to assure continuous operation?
Current design pattern assume local (or national) responsibilities and it is not conceivable that a
neighbouring system in a foreign country will be used as back up.
Current ATC systems are based on local data bases which are updated by message exchange (
e.g. SYSCO, OLDI ). For co-ordination amongst ATC centres so called ‘areas of common
interest’ are defined where shared data may exist. Simple exercises show that the overlapping of
these areas together with the co-ordination and update messages will lead to unmanageable
data and messages (amount and responsibilities).
If systems collaborate and share data the upgrade of systems and of data structures becomes a
critical issue. For example, if an attribute should be added to a shared flight plan, systems of the
current design have to be switched off and to be restarted with the new data structure. This is
already a delicate procedure for one system with a local data base but it becomes a nightmare if
the data shared by two or more systems have to be upgraded. A synchronised shut down and
restart is not conceivable.
Continuous operation becomes a necessity if information is shared. Systems and data structures
of different generations must be able to coexist. There will always be at least one system which
has not the latest software or data level, in addition new systems will be added to the information
sharing, therefore the whole system will be in an eternal transition phase. It follows that
upgrading of systems and data structures must be a normal procedure which does not hamper
normal operations.Collaboration and Information Sharing have been recognised as a
requirementI but are not yet treated in ATM system architectures.
Fortunately data sharing is not limited to the ATM domain. Several commercial systems exist
(data bases, groupware) which allow collaboration. Usually these COTS products are not for
safety critical systems and also other requirements (response time, amount of data) are not the
same.
Since the ATM domain does not inspire the software community to propose adequate solutions
we have to define ATM architectures which support collaboration and information sharing and to
evaluate and test which of the COTS products are suitable for ATM and what additional features
are necessary.
It follows that further research is necessary.
DIFODAM has been launched to explore an architecture which could help to overcome the
problems raised by this new challenge.
2.
Design Constraints
In addition to the above requirements, the following constraints have been considered:
•
flexibility
DIFODAM should be flexible enough to cope with 60 clients in the ECAC area. Previous
experience has shown that ATC systems have a long life cycle and need to evolve in a
step-wise fashion. DIFODAM should integrate smoothly with the existing FDPS.
•
I
scalability
National Airspace System Architecture, chapter 8 NAS Information Services for Collaboration and Information Sharing,
FAA ASD-1, December 1997
2
DIFODAM
The growing of air traffic will increase the amount of data. In a near future, new clients like
aircraft operators would be involved in the system.
•
performance
Predictability of response time is a critical constraint if additional flight plan related data (
e.g. co-ordination data ) are requested.
•
interoperability
Future ATC applications might have to communicate with applications on other systems,
e.g. AOC systems, airport systems, airborne systems.
•
cost
Maximum use of COTS products in order to reduce implementation cost, if requirements
specific to the ATC domain can be separated from general requirements.
The choice of a software architecture for DIFODAM is a trade-off between these
conflicting goals. After a preliminary design phase we chose a solution based on Group
Communication.
3.
Group Communication
3.1.
Synchronous group communication
In synchronous groupware, two or more people collaborate at what they perceive to be “the same
time”. Each person’s actions within the collaboration are mediated by some software system.
We refer to the parts of the software system “in front of each person” as the clients. (We refer to
the persons themselves as users). The clients typically need to co-ordinate some parts of their
data with each other. They achieve this co-ordination via a notification service, which is
implemented by one or more notification servers.
The primary functionality provided is the ability for each client of a group to send data to the
others. A client can send a message to a group (also called a communication channel), and be
certain that all members of the group receive it (unless they crash or a network partition occurs).
The notification server maintains a consistent state for several communication channels. A client
can be connected to several notification servers. Every client can join a channel to receive data
send to it, and by joining an appropriate combination of channels, and by consuming them, a client
can choose to receive messages sent to these channels and ignore messages sent to others
channels.
Clients subscribe to and leave the desired channels at any time. Channels can be created at run
time. Channels are not shared between servers.
A communication server can be dedicated to share the state of one object (or an aggregate of
related objects). In this case, all messages represent the entire state of the object.
3
DIFODAM
DIFODAM
EUROCONTROL
Client
Client
Client
FDR:DIFODAM
Client
//
Communication
Channel FPL
Communication
Channel FPL
Communication
Channel FPL
Communication
Channel FPL
Communication
Channel FPL
Multi - Notification Servers
Client
##
The notification server can provide additional services such as authentication, access rights
control, notification to a single client or notification to all clients of the server.
Due to the simplicity and the power of synchronous groupware concepts, there is a wide range of
applications including conferencing, group decision support systems, collaborative editors.
4
DIFODAM
3.2.
Group communication applied to Flight Plan Data
There is a natural way to map Group Communication concepts to DIFODAM’s shared flight plan.
The clients, concerned by a particular flight plan, shall be connected to the same channel. By
analogy, a controller and the pilots in the same sector use the same radio frequency.
Thus, there is a one to one mapping between a shared flight plan and a communication channel.
Additional related data concerning one flight plan (e.g. SSR code) can be present on the same
communication channel if it is needed by all clients.
The following table summarises the traceability between DIFODAM’s general requirements and
the design choices.
requirements
implementation
shared data
communication channel - notification server
event notification
filtering
allocator process - notification server
persistence
in prototype on the server side - but depending
on requirements it may be also on the client
side
transaction
atomicity guaranteed by the notification server
versions
rights
4.
and
and
access
access rights are managed by notification
server
fault tolerance
backup server
queries
notification server
trajectory predictor
separate service
Shared Data
The concept of communication channel offers a good solution to share flight plan in a synchronous
way.
The type representation of a channel state is a variable length byte array un-interpreted by the
server. The semantics and processing (encoding/decoding) of this raw data is left entirely to the
clients. Therefore, DIFODAM must provide a harmonised interface on the client side.
On the client side, an object oriented framework hides implementation details and facilitates the
use of shared objects. The client will deal with Shared Flight Plan objects. All clients have the
same object oriented framework with the same flight plan classes. A client application can extend
this model with private data that will not be shared. Flight plans are proxy objects synchronised
with the corresponding channel state.
When the IFPU creates a Flight Plan, an allocator process assigns a server and a communication
channel to this Flight Plan. The location of the Flight Plan remains unchanged during all its life
cycle.
5
DIFODAM
The IFPU assigns a unique identifier to each Flight Plan (IFPLID field in ADEXP format). From the
client perspective, this identifier is sufficient to access the associated server and channel. The
association (IFPLID, channel identifier) is maintained by the allocator process.
A simple naming rule is used to map flight plans to channels. Each notification server has a
unique name ( or network address). Each channel has a unique number relative to its server. A
channel is uniquely identified with a pair ( server address, channel number). The allocation table is
a one to one mapping between flight plan identifiers and channel identifiers).
FPLID <-> ( server address , channel number )
5.
Event notification and filtering
5.1.
Creation events
Creation events are messages sent by the allocator process located at the IFPU. These
messages contain the flight plan identifier. The allocator calls the geographical filter process which
computes the list of clients whose Area of Interest intersects the flight plan’s route.
After reception of a creation message, a client can choose to join the channel in order to access to
the flight plan content and to be notified of update events.
5.2.
Update events
When a change initiated by a client occurs on the server, all the clients including the initiator are
notified and their proxies are updated. The notification acts as a “software interrupt” that is handled
using an event handler mechanism. In the framework, the shared object classes enable the client
to redefine event handling methods.
Events can be filtered on the client side by the event handling methods at notification time.
A special case of flight plan update is re-routing: the client must call the geographical filter process
in order to re-compute the new list of clients. Therefore, re-routing a flight triggers an update event
to the clients already aware of this flight, and triggers a re-routing event to the newly concerned
clients. The filter process is called with the flight plan identifier and the re-routed trajectory.
The centralised allocation process simplifies the generation of an unique flight plan identifier and
an unique address. In addition, it enables to perform load balancing at flight plan creation time
between notification servers.
The following diagram shows the events and data flows paths between clients, server and the
initial flight plan processing unit.
6
DIFODAM
System Overview
Allocation Table
Allocator
IFPU
DIFODAM API
DIFODAM
Servers
Channels
Client
Creation Events
Subscription
Local client
DIFODAM API
FPL
FPL
Applications
DIFODAM API
Flight Plan
Update Events
FPL
Filters
(e.g.
Area of interest)
The system is divided into three main components:
•
The Allocator Process is in charge of retrieving the initial Flight Plan and to create it on the
different servers.
•
The DIFODAM servers support the communication mechanism to share consistent Flight Plans in
a multi-user context. A shared Flight Plan is mapped on one communication channel.
The servers are also in charge of filtering the creation of new Flight Plans in order to notify the
interested clients via subscription channels.
•
The Client Applications rely on the DIFODAM API which provides the connection to the service
and an object-oriented model for manipulation of shared Flight Plans.
7
DIFODAM
System Context
This figure shows the layers of the two main components of the system.
DIFODAM Server
Client Applications
DIFODAM API
JSDA
Java Virtual Machine
Operating System
The JSDA library is hidden from clients’ applications, it has been entirely encapsulated in order to
reduce the impact of a change in JSDA on the client code.
6.
Persistence
Current notification servers do not support any form of persistence of the channel’s state, because
many groupware applications don’t need persistence. The notification server does not add
overhead to implement persistence. The design principle is that clients and servers should only
pay for the facilities that they actually use.
6.1.
Persistence on the server
The notification server can be customised to store on a reliable repository the state of a channel
before notifying the clients. During a server crash, the flight plans are not available but after a
restart, they recover the previous consistent state from the persistent storage. The persistent
storage is easy to implement because channels are just byte arrays. There is no need for a
complex and costly database management system on the server.
6.2.
Persistence on the client
If the server is not persistent, clients can choose to store objects in a local persistent storage in
order to continue processing in case of a temporary network or server failure.
7.
Transactions
Sometimes, modifications on two or more objects depend on each other. In such cases a
transaction manager would be desirable. In our case, most transactions affect one flight plan. In
our implementation, the flight plan belongs to one communication channel. Therefore, atomicity is
guaranteed by the notification server.
8
DIFODAM
8.
Versions and access rights
The required version scheme is implemented by adding a version number attribute to the object.
In the same way, dynamic access rights require an attribute referencing the owner of the flight
plan. The value of this attribute is checked on the client side before an update attempt.
9.
Fault tolerance
9.1.
Fault tolerant Server
Our proposed solution involves two types of notification servers. The primary server is connected
to the clients. A backup server mirrors all the channels of the primary server. The mirroring
program acts as a client program for the primary server. Thanks to the synchronous property of
communication channels, the backup server will always have the same content as the primary
server. The mirroring program is easy to implement because it does not have to interpret the
channels content, it just has to replicate it.
With respect to the channel naming rule, it is easy to find the flight plan on a backup server:
IFPLID <-> ( server address, channel number )
same
9.2.
IFPLID <-> ( backup server address, same channel number )
Client failure detection
A client connected to a communication channel is notified of other clients entering or leaving the
channel. This is a basic requirement of notification server. A client failure is detected by the
notification server.
10.
Queries
Main client applications are FDPS which rarely perform queries on DIFODAM because they are
already notified of flight plans crossing their area of interest. Nevertheless, other clients like
aircraft operators are not interested in a particular geographical area. They need to query
DIFODAM in order to retrieve flight plans matching arbitrary criteria.
A query is carried out in two steps. The first step is to retrieve the flight plan identifiers. It implies to
query all the persistent repositories of the notification servers. The second step is to join the
corresponding channels and check the search criteria. This task is performed on the client side.
11.
Trajectory predictor
The trajectory predictor is a separate object which calculates a 4D trajectory according to aircraft
performance, Meteo, ATC constraints. The resulting trajectory is copied to a shared flight plan by
the client application.
12.
Conclusions
The prototype architecture puts the emphasis on having a synchronous view of flight plans at the
expense of having traditional database querying functionality.
DIFODAM has a scaleable architecture, it is easy to add notification servers, or to use the
communication channel concept for other purposes. New applications can take advantage of the
scalability of shared flight plans.
9
DIFODAM
For most of the DIFODAM requirements, the group communication concepts offers many ways to
implement them. The above design choices are kept hidden from client application and can be
revised for performance, cost or evolutivity reasons.
13.
Benefits
Benefits can be summarised as follows:
• Every client has access to the same data
• Simple system architecture which is applicable to a wide range of systems (ATCFDPS, AOC, airport)
• No management of complicated data structures, therefore a wide range of data can be
covered (FPL, Meteo, CDM)
• It is possible to introduce and upgrade systems progressively in the ECAC area,
heterogeneous systems and data (based on inheritance) are supported
• Continuous operation assured, no switching off for system and data upgrade
10
DIFODAM
14.
List of Reference Documents
DIFODAM
Software Requirement Document
R16.DIF.SRD.01.00
Prototype Specification Document
R16.DIF.PROTO.01.0
Prototype Architecture Document
R16.DIF.PROTO.ADD.01.00
Prototype User Guide
11
DIFODAM
CENTRE EXPERIMENTAL EUROCONTROL
VERSION FRANÇAISE
DIFODAM
Résumé
DIFODAM introduit le concept d’un Plan de Vol partagé offrant des facilités d’interopérabilité entre
différents systèmes et une grande flexibilité de mise à jour, de développement et d’intégration
pour de nouveaux utilisateurs 1.
Il se base sur une communication de groupe qui fournit un service élémentaire et commun dans
un contexte multi-utilisateurs. Le serveur de notification maintient la consistance entre plusieurs
canaux de communication, chaque canal étant un objet partagé (dans notre cas: un plan de vol).
Les utilisateurs ( contrôleurs, pilotes..) sont en conférence pour finaliser un plan de vol. Ayant
accès à un même jeu de données, ils peuvent ainsi coopérer efficacement.
DIFODAM utilise la technique des objets dynamiques 2. Chaque plan de vol partagé est un objet
dynamique qui peut évoluer sans interrompre le service rendu. Les clients qui ne veulent pas
changer l’état de leur système, utilisent l’ancienne version, les autres peuvent utiliser la nouvelle
mouture en chargeant les programmes à partir du serveur de notification. Ceci facilite l’ajout de
nouveaux systèmes ou de nouveaux services.
Cette architecture est capable de gérer différents types de données simultanément et peut être
utilisée dans le cadre du CDM (Collaborative Decision Making), d’ESCAPE (le nouveau
simulateur ATC du CEE). L’architecture est aussi possible dans des applications telles que l’ASD
(Air Situation Display) ou partie prenante dans l’interopérabilité entre les FDPS (Flight Data
Processing System).
1
“Les nouveaux concepts ATM exigent plus d’interopérabilité entre les systèmes des compagnies et les services
ATM...L’objectif est de trouver des spécifications qui permettent une conception et une implémentation d’un système
ATM, évoluant sur une longue période, incluant diverses industrialisations et assurant sa pérennité. Ces
spécifications doivent permettre une interopérabilité entre des éléments de communication sol-sol, une intégration
facile de nouveaux systèmes, des développements et des évolutions utilisant les nouvelles technologies”. (Yellow
Book on ATM R&D Strategy,Fev. 1997).
2
“L’amélioration des systèmes informatiques existants nécessite de stopper le service en vue d’exécuter les
modifications nécessaires. Mais aujourd’hui, pour un nombre croissant de systèmes complexes et de missions
critiques, ”arrêter” ces systèmes n’est plus une option acceptable. Les ajustements et changements des programmes
informatiques doivent s’exécuter avec des systèmes en état opérationnel. Les programmes doivent être assez flexibles
pour accepter toute modification sans compromettre le service rendu.
L’utilisation de la technique des objets dynamiques est le moyen qui permettra l’évolution des programmes des
utilisateurs. Avec les objets dynamiques, de nouvelles fonctions, de nouvelles capacités et de nouvelles classes d’objet
peuvent être ajoutées en temps réel. De plus, ces opérations sont transparentes pour les utilisateurs. Au vu des
évolutions rapides des techniques informatiques d’aujourd’hui, les objets dynamiques y trouveront naturellement leur
place.” (D.Crawford, executive Editor of Communications of the ACM (Association for Computing Machinery,Inc.)
Vol.40,No.5,May,1997.)
Tâche CEE N° R16 - CEE Rapport N° 326
12
DIFODAM
1.
Introduction
1.1.
Présentation
Le projet est développé dans le cadre du programme EATCHIP et plus particulièrement dans le
domaine du DPS (Data Processing Systems). Il étudie l’apport d’un système sécurisé de
distribution de données de vol. Le scénario est basé sur l’étude d’interopérabilité entre les
systèmes de distribution de plans de vol, supportant la coordination (SYSCO) et associés aux
lignes d’échange de données (OLDI).
DIFODAM est un projet du CEE, répondant aux exigences du DPS.ET1.ST05.2000.
Ce rapport détaille la conception d’une architecture et l’implémentation d’un prototype.
Le but est de procurer un service interactif et collaboratif qui permet de manipuler et de distribuer
un plan de vol partagé.
L’architecture se base sur une interface Java : “Java Shared Data API : JSDA ref.2”, une
communication de groupe synchrone implémenté en langage JAVA.
Les applications clientes de DIFODAM sont des applets java (accessibles par l’Internet WEB
browser de Netscape) ou des applications java dédiées.
1.2.
Objectifs
DIFODAM implémente un service persistant de données partagées avec notification de mise à
jour vers les clients.
•
Données partagées : les plans de vol et les données en liaison sont partagées dans
un contexte multi-utilisateurs.
•
Persistance et transactions : les plans de vol sont mémorisés dans un répertoire
stable et sont mis à jour pendant les transactions.
•
Evénement de notification et de filtrage : les clients souscrivent à une classe
spécifique d’événements pour être automatiquement notifiés quand un changement
apparaît dans un plan de vol.
•
Droit d’accès dynamique : le droit de modifier un plan de vol est exclusif et peut être
passé à un autre client. Le créateur du plan de vol est le premier propriétaire du droit
de modification.
•
Versions d’un plan de vol : un client peut créer une nouvelle version d’un plan de vol
et est le propriétaire de cette version.
•
Tolérance aux pannes : DIFODAM utilise des données partagées répliquées en vue
d’augmenter la fiabilité.
Tâche CEE N° R16 - Rapport CEE N° 326
13
DIFODAM
1.3.
Contexte Gestion du trafic
Partout dans le monde, de nouveaux systèmes ATC sont conçus et mis en fonction. Ceux-ci
resteront en service, au moins, jusqu’à l’an 2010, les systèmes aujourd’hui en conception, bien
plus longtemps. Tous ont la particularité d’être destinés à un site ou un centre ATC. Ceci englobe
aussi le projet AVENUE dans le cadre du programme R&D de l’Union Européenne. Mais, durant
leur cycle de vie, ces systèmes devront, tout naturellement, coopérer et partager leurs
informations. Ils devront aussi collaborer avec des systèmes non-ATC. Ceci est la conséquence
nécessaire pour une collaboration dans la gestion et la prise de décision qui est un élément clé
du programme R&D du futur EATMS. (“Yellow Book”).
Collaboration et informations partagées lancent un nouveau défi. En plus de la consistance et de
la persistance des données, de la compatibilité des systèmes, de nouveaux problèmes devront
être résolus :
•
Qui est responsable des données qui sont partagées ?
•
Quelles sont les procédures à suivre en cas de panne ?
•
Comment améliorer les systèmes qui se partagent leurs données ?
•
Comment assurer la continuité du service ?
Les conceptions courantes assument une responsabilité locale ( ou nationale ) et n’envisagent
aucunement qu’un système avoisinant d’un autre pays puisse servir de back-up.
Les systèmes ATC courants se basent sur des banques de données locales qui sont mises à jour
par échange de messages ( SYSCO, OLDI ). Pour une coordination entre centres ATC, des
zones, aussi appelées “zones d’intérêt commun”, sont définies la où des données à partager
existent. La pratique montre que les recouvrements de ces zones laissent des données et des
messages ingérables ( en quantité et en responsabilité ) entre la coordination et les messages de
mises à jour.
Si les systèmes collaborent et partagent leurs données, l’amélioration de ces systèmes et de la
structure des données devient un point critique. Par exemple, si un attribut doit être ajouté à un
plan de vol partagé, les systèmes de conception courante doivent être coupés et redémarrés
avec la nouvelle structure des données. C’est déjà une procédure délicate pour un seul système
à base de données locales mais cela deviendrait un cauchemar si les données, partagées entre
deux ou plusieurs systèmes, devaient être modifiées. Une coupure et un redémarrage
synchronisés sont inconcevables.
La continuité du service devient une nécessité dans le contexte d’une information partagée.
Systèmes et structures de données de générations différentes doivent coexister. Il y aura toujours
au moins un système qui n’utilisera pas la dernière version des programmes ou des données.
De plus, de nouveaux systèmes s’ajouteront dans le circuit de l’information partagée.C’est
pourquoi le système global sera considéré comme en éternelle phase de transition.
En conclusion, l’amélioration des systèmes et des structures de données sera perçue comme
une procédure normale qui n’influe pas sur les opérations en cours. La Collaboration et
l’Information Partagée sont reconnues comme une exigence1 , mais ne sont pas encore prises en
compte dans les architecture des systèmes ATM. Heureusement, les données partagées ne se
limitent pas qu’au domaine ATM.
1
National Airspace System Architecture, chapter 8 NAS Information Services for Collaboration and Information
Sharing, FAA ASD-1, December 1997
14
DIFODAM
Plusieurs systèmes du commerce existent (base de donnée, conférence) qui permettent la
collaboration. Normalement ces produits du commerce ne s’adressent pas à des systèmes où la
sécurité est critique ou à d’autres exigences comme les temps de réponse ou la quantité des
données à traiter.
Comme le monde ATM ne pousse pas la communauté informatique à proposer des solutions
adéquates, nous avons à définir des architectures ATM qui supportent la collaboration et
l’information partagée, les évaluer, les tester avec des produits sur étagère qui correspondent à
l’ATM et trouver des fonctionnalités supplémentaires si nécessaire.
S’en suit que des recherches complémentaires seront nécessaires.
DIFODAM a vu le jour pour trouver une architecture qui réponde aux problèmes posés par ce
challenge.
2.
Contraintes de Conception
En plus des exigences précédentes, d’autres contraintes sont à considérer:
•
Flexibilité
DIFODAM doit être assez flexible pour supporter les 60 clients dans la zone ECAC. Les
expériences précédentes ont démontré que les systèmes ATC ont un cycle de vie assez
long et qu’ils évoluent régulièrement. DIFODAM devrait s’intégrer harmonieusement avec
les systèmes FDPS existants.
•
Evolutivité
L’augmentation du trafic aérien multiplie la quantité de données. Dans un proche future,
de nouveaux clients, comme les opérateurs des compagnies, voudront être impliqués
dans les systèmes.
•
Performances
La rapidité de réponse des systèmes est une contrainte critique si des données
supplémentaires s’ajoutent au plan de vol.
•
Interopérabilité
Les applications ATC à venir devront communiquer avec des applications d’autres
systèmes tels que les AOC, le contrôle des aéroports, les avions.
•
Coûts
L’utilisation au maximum de produits du commerce réduiront le coût d’implémentation, si
les exigences spécifiques du domaine ATC peuvent être séparées des exigences
générales.
Le choix de l’architecture de DIFODAM est un trait d’union entre ces objectifs contradictoires.
Après une première phase de conception, nous avons opté pour une solution basée sur une
communication de groupe.
3.
Communication de Groupe
3.1.
Communication de groupe synchrone
Dans un système de conférence, deux ou plusieurs personnes collaborent simultanément. Les
interventions de ces utilisateurs sont gérées par un système informatique.
15
DIFODAM
Nous ferons référence au “client” comme étant la partie informatique s’interfaçant avec chaque
personne (les personnes étant les utilisateurs). Les clients ont besoin de coordonner une partie de
leurs données avec les autres. Ils assurent cette coordination via un service de notification, qui est
implémenté au moyen d’un ou plusieurs serveurs de notification.
La première fonctionnalité fournie est la capacité, pour chaque client du groupe, d’envoyer des
données vers les autres. Un client peut envoyer un message au groupe (aussi appelé canal de
communication ) et être certain que tous les abonnés du groupe le recevront (sauf une panne ou
sur une partition du réseau).
Le serveur de notification maintient un état consistant pour les canaux de communication. Un
client peut être connecté à plusieurs serveurs de notifications. Chaque client peut joindre un canal
pour recevoir ses données. En joignant une combinaison appropriée de canaux, un client peut
sélectionner les messages envoyés vers ces canaux et ignorer les autres.
DIFODAM
EUROCONTROL
Client
Client
Client
FDR:DIFODAM
Client
//
FPL : Canal de
Communication
FPL : Canal de
Communication
FPL : Canal de
Communication
FPL : Canal de
Communication
FPL : Canal de
Communication
Multi - Serveurs de Notification
Client
##
Les clients souscrivent et quittent les canaux à tout moment. Les canaux sont créés en temps
réel. Un canal n’appartient qu’à un seul serveur.
Un canal de communication peut servir à partager l’état d’un seul objet (ou un agrégat d’objets).
Dans ce cas, tout message représente l’intégralité de l’état de l’objet.
Le serveur de communication peut rendre d’autres services comme l’authentification, le contrôle
des droits d’accès, une notification par client ou pour tous les clients abonnés au canal.
Au vu de la simplicité et des possibilités des concepts des groupes de communication, il y a une
large panoplie d’applications possibles dont le système de conférence, les systèmes d’aide à la
décision, les éditions partagées.
16
DIFODAM
3.2.
Application du groupe de communication aux plans de vol
C’est tout naturellement que le concept de groupe s’interfère avec les plans de vol partagés de
DIFODAM. Les clients, intéressés par un plan de vol déterminé, se connectent sur le même canal.
Par analogie, un contrôleur et les pilotes d’un même secteur utilisent une même fréquence radio.
Il y a donc une liaison directe entre le plan de vol partagé et le canal de communication. Des
données en relation avec le plan de vol ( SSR code, trajectoire..) peuvent être ajoutées au même
canal de communication si elles répondent à un besoin des utilisateurs.
La table suivante résume la tracabilité entre les exigences générales de DIFODAM et les choix de
conception:
Exigences
4.
Implémentation
Données partagées
canal de communication - serveur de notification
Evénements de notification et
filtrage
processus d’allocation
Persistance
pour le prototype fait du coté serveur - mais
dépend des exigences et peut se faire coté client
Transaction
l’atomicité est
notification
Versions et droit d’accès
droits d’accès gérés par le serveur de notification
Tolérance aux pannes
serveur dédié
Requêtes
serveur de notification
Calculateur de trajectoire
service extérieur
- serveur de notification
garantie
par
le
serveur
de
Données partagées
Le concept du canal de communication donne une bonne solution pour partager un plan de vol
d’une façon synchrone.
Le type de donnée représentant l’état d’un canal est un tableau d’octets de longueur variable et
non-interprété par le serveur. La sémantique et le processus de codage/ décodage de cette
somme de données sont exécutés au niveau client. C’est pourquoi, DIFODAM fournit un interface
approprié du coté client.
Du coté client, une bibliothèque orientée objet contient les détails d’implémentation et les facilités
de manipulation des objets partagés. Le client traitera donc directement avec des objets plan de
vol. Tous les clients disposent de la même bibliothèque avec les mêmes classes de plans de vol.
Une application client peut étendre son modèle avec des données privées qui ne seront pas
partagées. Les plans de vol sont des objets proxy synchronisés avec l’état du canal
correspondant.
17
DIFODAM
Lorsque l’IFPU crée un plan de vol, un processus d’allocation assigne une adresse serveur et une
adresse canal de communication au plan de vol. La localisation du plan reste inchangée durant
tout son cycle de vie. L’IFPU donne un identificateur unique à chaque plan de vol (champ: IFPLID
en format ADEXP). Pour le client, cet identifiant est suffisant pour accéder au serveur et au canal
associé. L’association (IFPLID, adresse serveur/canal) est maintenue par le processus
d’allocation.
La liaison plan de vol / canal est simple. Chaque serveur de notification a un nom unique (ou
adresse réseau). Chaque canal a un numéro relatif à son serveur. Un canal est donc identifié
avec une paire d’adresses (adresse serveur et numéro de canal). La table d’allocation est la
liaison entre l’identifiant du plan de vol et l’identifiant du canal.
FPLID <-> ( adresse serveur, numéro de canal )
5.
Evénement de notification et filtrage
5.1.
Evénements de création
Les événements de création sont des messages envoyés par le processus d’allocation localisé à
l’IFPU. Ces messages contiennent l’identifiant des plans de vol. L’allocateur appelle le processus
de filtrage (géographique..) qui recherche la liste des clients intéressés ou traversés par la route
du plan de vol.
Après réception du message de création, un client peut choisir de rejoindre le canal en vue
d’accéder au contenu du plan de vol et d’être notifié sur toute modification future.
5.2.
Evénement de mise à jour
Si un changement, initié par un client, intervient sur le serveur, tous les clients, y compris
l’initiateur, sont notifiés et leurs proxies sont mis à jour. La notification agit comme “une
interruption logicielle” qui est prise en charge par un gestionnaire d’événements. Dans la
bibliothèque, les classes d’objets partagés permettent au client de redéfinir la méthode du
gestionnaire d’événements.
Les événements peuvent être filtrés du coté client par le gestionnaire d’événements au moment
de la notification.
Un cas spécial de modification du plan de vol est le déroutement. Le serveur doit appeler le
processus de filtrage géographique en vue de rechercher la nouvelle liste des clients intéressés.
C’est pourquoi, le déroutement d’un plan de vol déclenche un événement de modification chez les
clients actuels du vol et aussi vers les nouveaux clients concernés. Le processus de filtrage
nécessite l’identifiant du plan et la trajectoire associée.
Le processus d’allocation centralisé simplifie la génération d’un identifiant et d’une adresse unique
pour un plan de vol. De plus, à la création d’un plan de vol, il permet de répartir la charge du
système entre les serveurs de communication.
Le diagramme suivant montre la répartition des événements et du flux des données entre : clients,
serveurs, et l’unité de production des plans de vol.
18
DIFODAM
Architecture Générale du Système
Table d’Allocation
Allocateur
IFPU
DIFODAM API
Serveurs DIFODAM
Evénement de
Canaux
Applications
Création
DIFODAM API
Client local
Client
Souscription
DIFODAM API
FPL
FPL
FPL
DIFODAM API
Plan de vol
Evénement de
modification
Filtres
zone d’intérêt
Le système est divisé en trois composants:
•
Le processus d’allocation qui prend en charge le plan de vol initial et le crée sur les différents
serveurs.
•
Les serveurs de DIFODAM supportent le mécanisme de communication et assure la consistance
des plans de vol partagés dans un contexte multi-utilisateurs. Un plan de vol est lié à un seul
canal de communication.
Les serveurs ont aussi la charge de filtrer les créations de plans de vol en vue de notifier les
clients intéressés via la liste de souscription des canaux.
•
Les applications client s’appuient sur l’API DIFODAM qui fournit la connexion au service et le
modèle orienté objet pour la manipulation des plans de vol partagés.
19
DIFODAM
Architecture Logicielle
Ce diagramme montre les couches des deux principaux composants du système :
Serveur DIFODAM
Applications Client
DIFODAM API
JSDA
Java Machine virtuelle
Système opérationnel
La librairie JSDA est transparente de l’application client, elle est entièrement encapsulée pour
réduire l’impact d’une modification dans le code java client.
6.
Persistance
Les serveurs de notification ne supportent pas la persistance de l’état des canaux, car la plupart
des applications de groupe ne l’exige pas. Le principe de conception est que les clients et les
serveurs ne paient que pour les facilités qu’ils utilisent aujourd’hui.
6.1.
Persistance coté serveur
Le serveur de notification peut être étendu pour sauvegarder, dans un support fiable, l’état du
canal avant la notification aux clients. Sur une panne du serveur, les plans de vols ne sont plus
disponibles, mais au redémarrage du système, ils recouvrent leur précédant état, consistant,
depuis le répertoire. Le stockage persistant est facile à implémenter puisque le contenu des
canaux ne sont que des ensembles d’octets. Il n’y a donc pas besoin d’avoir un système de base
de données complexe et coûteux du coté du serveur.
6.2.
Persistance coté clients
Si le serveur n’est pas persistant, les clients peuvent choisir de stocker leurs objets localement
pour continuer de fonctionner en cas de panne temporaire du réseau ou du serveur.
20
DIFODAM
7.
Transactions
Des modifications simultanées de deux ou plus d’objets peuvent s’interférer. Dans un tel cas, un
gestionnaire de transactions est recommandé. Dans notre cas, les transactions n’affectent qu’un
seul objet : le plan de vol. De plus, dans l’application DIFODAM, le plan de vol appartient à un
seul canal de communication. C’est pourquoi, l’atomicité des transactions est assurée par le seul
serveur de notification.
8.
Versions et droits d’accès
Pour répondre à l’exigence de pouvoir versionner un plan de vol, un attribut supplémentaire est
ajouté à l’objet: le numéro de la version.
De la même façon, des droits d’accès dynamiques nécessitent un attribut référençant le
propriétaire du plan de vol. La valeur de cet attribut est contrôlée, du coté client, avant toute
modification.
9.
Tolérance aux pannes
9.1.
Tolérance aux pannes coté serveur
La solution proposée implique deux types de serveurs de notification: le serveur primaire auquel
les clients sont connectés et un serveur de secours qui est le miroir de tous les canaux du premier
serveur. Le serveur miroir agit comme un client du serveur primaire. Grâce aux propriétés
synchrones des canaux de communication, le serveur de secours aura toujours le même contenu
que le serveur principal. Le programme miroir est facile à implémenter puisqu’il ne doit pas
interpréter le contenu des canaux, mais juste les répliquer.
En respectant les règles d’identification des canaux, il est aisé de retrouver un plan de vol sur le
serveur de secours:
IPPLID <-> (adresse serveur, numéro du canal)
identique à
9.2.
IFPLID <-> (adresse du serveur de secours, même numéro du canal)
Détection d’une panne client
Un client, connecté à un canal de communication, est notifié si d’autres clients entrent ou quittent
le canal. C’est une fonction de base du serveur de notification. Une panne client est détectée par
le serveur de notification.
10.
Requêtes
La plupart des applications client sont des FDPS qui feront rarement des requêtes sur DIFODAM
puisqu’ils sont déjà avertis des plans de vol traversant leur zone d’intérêt. Néanmoins, d’autres
utilisateurs comme les compagnies ne sont pas forcément centrés que sur une zone
géographique particulière. Ils doivent retrouver des plans de vol selon des critères qui leur sont
propres.
Une requête se passe en deux temps. Le premier pas est de retrouver l’identifiant du plan. Ceci
implique une recherche sur tous les répertoires persistants des serveurs de notification. Le
second pas est de rejoindre les canaux correspondant et de contrôler les critères de recherche.
Cette tâche est exécutée du coté client.
21
DIFODAM
11.
Calculateur de trajectoire
Le calculateur de trajectoire est un objet distinct qui calcule en 4D la trajectoire en tenant compte
des performances de l’avion, de la Meteo, des contraintes ATC. La trajectoire résultante est
copiée dans le plan de vol partagé de l’application client.
12.
Conclusions
L’architecture du prototype met en valeur le fait de disposer d’une vue synchrone d’un plan de vol
plutôt que de requérir aux fonctionnalités d’une base de donnée traditionnelle.
DIFODAM dispose d’une architecture évolutive, en ce sens qu’il est aisé de rajouter des serveurs
de notification ou d’utiliser le concept des canaux de communication pour d’autres objets. De
nouvelles applications bénéficieront de l’évolutivité du concept des plans de vol partagés.
Pour la plupart des exigences de DIFODAM, le concept de communication de groupe offre
différentes manières de les implémenter. Les choix de conception, ci dessus, sont transparents
pour une application client et peuvent être remodelés en fonction des performances, des coûts ou
toute raison d’évolutivité.
13.
Bénéfices
Les bénéfices peuvent être résumés :
•
Tous les clients ont accès aux mêmes données.
•
Système d’architecture simple qui est applicable dans une large panoplie de
systèmes (ATC- FDPS, AOC, Airport)
•
La gestion des données est très simple bien que de larges domaines de types de
données peuvent être couverts (FPL, Meteo, CDM).
•
Il est possible d’introduire ou de modifier, progressivement, les systèmes de la zone
ECAC, systèmes hétérogènes et données ( basées sur l’héritage) sont supportés.
•
La continuité du service est assurée: pas de coupure des systèmes pour leur remise
à niveau.
22

difodam - Eurocontrol

Transcription

Documents pareils

Flight Centre - Aurora Realty Consultants

Page 28 - Star-Pack

FLIGHT CASE PRO 19" 2U

Eagle Flight (et plus) à la Nocturne de la Biennale de Montréal

ROAD READY RR12MIX Marque :ROAD READY Prix

Module 3 - Stage de photo numérique

Informations Arrivée / Départ Arrival and departure informations

MATERIAL à VENDRE La Maison de la Culture de Tournai revend