SYSTEM WIDE INFORMATION MANAGEMENT: THE SWIM-SUIT PROTOTYPE

Dario Di Crescenzo, Antonio Strano, SESM s.c.a.r.l., Giugliano in Campania, Italy Georg Trausmuth, Frequentis AG, Vienna, Austria

Abstract

This paper describes the results of the FP6 project SWIM-SUIT (System Wide Information Management – Supported by Innovative Technologies) that currently integrates a number of existing ATM (Air Traffic Management) systems on top of a newly build prototype. As SWIM-SUIT has been identified to provide relevant inputs to SESAR, the authors give an overview on the prototype architecture and major software components. The relevant data domains for the prototype are Flight Data, Surveillance Data and Aeronautical Information. The paper provides insights and lessons learned derived from the design decisions of the prototype implementation as guidance for future work to take place within SESAR. The last part of the paper presents a view on the ongoing validation activities that connect ATM systems throughout Europe to the SWIM-SUIT prototype.

Introduction Modern systems used in critical infrastructure

are increasingly growing in complexity and size while having to satisfy software engineering properties, both in terms of design characteristics, flexibility, maintainability and in terms of reliability, availability and security.

Such characteristics become even more relevant when the systems embrace geographical areas interconnecting multiple systems and subsystems with a heterogeneity of stakeholders and requirements. These features fall in the so called category of ULS (Ultra Large Scale) systems where flexibility, decoupling, scalability and security requirements become more and more stringent and hard to satisfy.

Moreover, it must be considered that, in real life, ULS systems are rarely built and deployed in a single point in time; more likely, they will be designed taking into consideration the whole picture and a long term view, while the actual instantiation and

deployment is in turn designed and carefully planned. Furthermore, a number of industrial actors take part in building, testing and turning into operation each single instance of a ULS system; to increase complexity, often the operational execution and management of each “piece” of the system falls under the responsibility of yet other parties (the final stakeholders) which will be primarily moved by business efficiency and economic revenue rather than strictly technical considerations.

Considering this picture, it is clear that the complexity of building ULS systems not only resides in technical but also “organizational” considerations which in turn may add requirements to system capabilities and design characteristics. In particular, in this scenario decoupling, flexibility and interoperability characteristics are of fundamental importance; different technologies are able to help the designers to reach the goal of building this kind of systems both for distributing data, as well as requesting services to remote system instances. In the latter case, principles derived from Service Oriented Architectures (SOA) help in reaching the decoupling and flexibility levels that are usually required even if performance issues may arise when real-time requirements become part of the problem.

When considering the task of distributing data, technologies like Java Messaging Service (JMS), Advanced Message Queue Protocol (AMQP), Data Distribution Service (DDS) may provide both decoupling as well as flexibility and Quality of Service guarantees with different degrees of “resolution”. In the ATM (Air Traffic Management) domain, an example of a future ULS system that will have to face the scenario that has been previously depicted will be the implementation of a System Wide Information Management environment. SWIM constitutes the future software infrastructure which will interconnect the multiplicity of stakeholder and systems which take part in the ATM domain; its task will be to represent the software bus allowing the realization of seamless integration among geographically distributed and heterogeneous

978-1-4244-7459-2/10/$26.00 ©2010 IEEE C2-1

systems providing a common interface to access domain services and a uniform information model for the data exchange and intercommunication among each of such systems as well as, of course, including strict security characteristics together with scalability, performance, reliability, maintainability and evolution.

SWIM – The ATM Information Bus

System Wide Information Management The need for SWIM has been widely

recognized both by European and USA main ATM players (FAA [1] and SESAR [2]). The main objective of SWIM is to enable a seamless information sharing between the air transportation stakeholders as, for example, airports, airlines, military air defense and air traffic control centers, Air Navigation Service Providers (ANSP) etc.

SWIM-SUIT [3], an FP6 research project lead by SELEX Sistemi Integrati, has realized a first attempt to build such a system by focusing on a subset of ATM stakeholders (and therefore requirements) which will have to be considered by the future SWIM.

The fundamental problem of enabling interoperability between a heterogeneous set of systems and stakeholders has been faced by structuring the analysis on a per “data domain” basis as also suggested by the SESAR approach [4]. The establishment of a common dictionary in terms of data and services is, of course, one of the enablers for systems interoperability. Flight and Surveillance data domains have had the greatest attention during the design and modeling phases; in the first case, the work has adopted as baseline the results of the ICOG2 project [5] which defined a “Flight Object” model further extending the FOIPS [6] model, while in the latter an “ad hoc” dictionary has been developed supporting the current ASTERIX CAT 62 [7] standard for surveillance information.

The determination of the data and service model has involved different stakeholders (e.g. Airport Operation Centers, Airline Operators, Network Information Management, Air Traffic Control Centers etc.) leading to the extension of the Flight Object structure so as to cover stand to stand information. Of course, also the service model has

been correspondingly extended enabling the interaction with stakeholders not considered in the ICOG scope.

The SWIM-SUIT approach in performing its tasks has been structured in a number of steps that have been executed even before starting the design of the actual system. One important step has been the selection of the most suitable technology both for the aspects related to the data distribution (following the publish/subscribe pattern) and to the invocation of synchronous services using a request/reply approach. The selection has been based on a wide set of formalized weighted selection criteria (one major point in the selection of these technologies has been the existence and adherence to international standards) which have led the project team to select JMS/DDS as technologies to be experimented for the data distribution while Web Services for the request/reply interactions.

SWIM Prototype Design Outline In order to instantiate and validate the

applicability of the SWIM concept, during the course of the SWIM-SUIT project a SWIM prototype, consisting of a fully decentralized architecture, has been developed. The high level architecture has been structured in basically two layers: a core layer offering a set of common services and components to the upper layer (e.g. security, data distribution, and registry) which was then in charge of offering specific domain services (e.g. subscriptions to flight data, notifications of incoming flight information, subscription to surveillance information etc..).

In our architecture the SWIM system is composed by a number of SWIM instances represented by a physical node residing at each stakeholder premise being therefore able to communicate on one hand with the local system (willing to exchange data and services via SWIM) and on the other end to the other SWIM Instances (named as “SWIM-BOXes”). The set of these system instances physically represent the SWIM Network where such system instances form the “logical bus” among which information flows and services are provided and consumed. Only SWIM-BOX instances are allowed to directly exchange data and invoke services over this network; therefore they act as mediators with respect to the external clients (e.g. Flight Data Processor systems). As of today, each

C2-2

existing ATM System participating in the SWIM-SUIT project is not aware of the services and functionalities of the SWIM prototype and each might use its own technology to exchange and represent information. For this reason, on each site the task of interfacing the “legacy system” to the SWIM-BOX instance is assigned to an “Adapter” component. Depending on specific requirements and constraints present at each site the SWIM-BOX and the Adapter architectural components might reside on a same machine even though the reference deployment foresees each component on a different machine. Both for security reasons and for ease of configuration, the different SWIM-BOX are connected together via VPN (Virtual Private Network) connections. The resulting high level structure can be therefore illustrated as in Figure 1.

Figure 1. SWIM-SUIT Prototype Complete

Instance Connections

The end to end interaction among (current) ATM systems in a SWIM Network may therefore be depicted as in Figure 2.

Figure 2. SWIM-SUIT Prototype End to End Connection

Each ATM system exchange data and provide/consume services via the mediation of the SWIM-BOX component which defines and assures a common dictionary for each of the data domains supported (e.g. meteo, flight data, surveillance etc.) enforcing the respect of security policies (e.g. restricted access both to data than to services). The Adapter architectural component shown in Figure 2. will likely be removed (or incorporated) in the future ATM systems since they will be natively able to interact with the SWIM Infrastructure. For this reason, current ATM systems connected with the SWIM-SUIT prototype are also referred as “legacy” systems in the following sections.

The SWIM-SUIT Prototype Architecture In order to guarantee interoperability also at

“wire” level for each system instance two kind of external interfaces have been designed:

• An external interface among data domain components and external applicative clients

• An external interface among the two System Instances (i.e. SWIM-BOXes).

The external interfaces exposed to the (local) Adapter(s) (refer to Figure 2) are in turn provided by specific domain components (one per domain) as illustrated in Figure 3. In consideration of the long timeframe in which this kind of application is supposed to be in operation, a specific abstraction layer isolating the actual distribution middleware technology utilized in the prototype has been foreseen. For this reason the system is currently able to fulfill the data distribution task by transparently (to the Adapters/Legacy Systems but also to the domain level internal components) delegating it to JMS or DDS middleware; this has been realized by defining a specific sub-component abstracting the middleware COTS (Common Off the Shelf) services implementing the data distribution function.

C2-3

 

Flight Data Domain

Ownership Mng

Surveillance Data Domain

Data Transf. Mng

Data Transf. Mng

Aeronautical Data Domain

Data Transf. Mng

SWIM

Cor

eM

iddl

ewar

e Pub/

Sub

Tech

n. 2

Pub/

Sub

Tech

n. 1

Req

/Rep

lTec

hnPu

b/S

ub T

ech.

Ind

ep. L

ayer

Tech

. Ind

epLa

yer

Authentication Mng.

Authorization Mng.

Figure 3. SWIM-BOX Logical Architecture

Figure 3 therefore basically shows the logical internal decomposition of the SWIM-BOX into two basic layers:

• a domain specific layer composed by specialized domain components (one per data domain) which provide domain specific services and are aware of domain specific data representation

• a core common layer where components reside providing common services like data distribution, encryption, authorization etc..

This logical decomposition may then result in different deployment schemas (each logical component may be deployed as a library, as an Enterprise Java Bean etc..). Still referring to Figure 3, the leftmost external interfaces are dedicated to the communication with the “local” Adapter, while the rightmost ones are dedicated to the interactions with the other SWIM-BOX instances, therefore only SWIM-BOX instances are authorized to directly consume services on these interfaces.

The prototype has been designed with a modular architecture in such a way to ease the introduction of different specialized data domain components. Given this modular architecture each component may (and it actually does) implement its own standard or technology to exposes its interfaces. Of course, a uniform principle has been followed in defining the technology through which the interfaces are exposed, but, also in order to empirically test different solutions, various standards have been adopted (e.g. Web Feature Service, Web Service Notification, etc..). The main components are hereafter described.

FDD (Flight Data Domain) Component The FDD component provides basic services to

create, distribute and in general interact with Flight Data related information. It fully supports the “Flight Object” concept [6]; anyway, since in our prototype the SWIM layer has been somehow placed under the applicative layer as defined in the ICOG specification, its interfaces are loosely coupled with the actual Flight Object structure. By confronting this solution with the ICOG architecture, the FDD external interfaces best fit at the ICOG middleware layer. Therefore, in ICOG terminology, they can be associated to the API Interfaces. Anyway, some differences exist; apart from minor differences (e.g. differences in signatures) in the two interfaces, in our prototype some responsibilities that in the ICOG architecture were allocated to the application layer are in charge to the FDD component; this is particular true in the case of the management of the “distribution list” which represents the list of system instances that will have to receive the Flight Data information. In our prototype the task of determining such list is allocated to the middleware which, analyzing the trajectory and other flight information (e.g. aircraft identifier, departure airport, arrival airport, etc) being present in the Flight Objects and knowing information like the AoR/AoI (Area of Responsibility/Area of Interest) of the Air Traffic Control centers determines which of the subscribed systems will have to receive such information or will be authorized to request for data modification (e.g. being elected as “Contributors”). Clients (i.e. the “Adapters” in our architecture) interact with the component by declaring their interest on the domain (i.e. subscribing to it) and optionally providing an “Endpoint” on which they will be contacted upon data reception (filters may be applied in order to limit notifications). Also a “pull” style approach is provided for those clients that cannot provide an endpoint in order to be asynchronously notified; in this case, the client may adopt a polling strategy in order to retrieve new flight data being present in the component cache. The client interactions with the component is exclusively based on plain Web Services standards in both directions (i.e. invocation of a service on the FDD, notification of data on the Adapter Endpoint), thus implicitly providing independence from the platform and the implementation language. The component has been implemented as a set of collaborating EJBs

C2-4

(Enterprise Java Beans [8]) which are then packaged into a single jar archive which in turn is part of a EAR archive; it depends upon a set of common libraries which are also shipped within the EAR (Enterprise ARchive) archive.

SDD (Surveillance Data Domain) Component Surveillance Data is currently propagated within

ANSPs using specific network infrastructure (e.g. RADNET). Usually this position information of aircraft is not exposed to external parties apart from military organizations or neighboring countries. The SDD component of SWIM-SUIT provides an impression on how data distribution can be administered to selectively push information out to legitimate subscribers that previously have expressed their interest in aircraft positions, e.g. an AoC might subscribe for positions of aircraft within an AoC of a specific ANSP.

Technically the SDD component realizes a publish/subscribe service that is presented to an outside system via a Web Service (WS) interface, specifically a subset of the services standardized by WS-Notification [9]. In order to utilize the underlying functions of the Publish/Subscribe Service (PSS), the external WS operations are translated to executions of functions provided by the PSS.

Once the subscription has been registered at a SWIM-BOX, relevant messages are delivered to the subscriber. The prototype supports both push and pull delivery mode: push mode means that each message is spontaneously delivered to a subscriber whenever a new message becomes available; in pull mode the SWIM-BOX stores each received message until the external system is ready to actively fetch them from the so-called pull point.

For demonstration purposes only a subset of ASTERIX [7] Cat62 data elements have been translated into an XML Schema [10] as the current SWIM-SUIT design requires data to be sent in XML format between SWIM-BOXes.

AID (Aeronautical Information Data Domain) Component

The AID Component demonstrates how functions available via a specific messaging interface called EAD (European Aeronautical Database)

System Interface (ESI) can also be accessed via Web Services. The prototype implementation covers some basic functions to query static information in the database as well as to execute some reporting functions.

Additionally to the AID functions mentioned above, an implementation of OGC (Open Geospatial Consortium) conforming Web Feature Services (WFS) [11] for geospatial information has been prototyped within the SWIM-SUIT project. This new kind of interface allows to (1) query available geographic information types and (2) to subsequently retrieve geographic information based on selection criteria that might also include geographic filtering. WFS enables a clean separation of server-side data storage from client-side presentation. This has been demonstrated in validation sessions by integrating the WFS output of the SWIM-SUIT prototype with the pre-existing GIS (Geographic Information System) tool SkyView [12] that is maintained by Eurocontrol.

The Web Service and Web Feature Service implementations rely on a core component called Request/Reply that implements a dynamic proxy. This proxy covers aspects of location transparency as the external systems are only connected to the SWIM-BOX and are not aware of the connection between the SWIM-BOXes. Moreover, the proxies need to handle and enforce security between SWIM-BOXes.

Core Components In our architecture, domain level components

use services and functionalities provided by core components. Such components basically provides services as much as possible independent from the domains; therefore, for the maximum possible extent, we tried to ensure that such components be unaware of the data being distributed or shared. Some of them are physically implemented as EJB, some as simple libraries; they provide local interfaces hiding the actual technology that is used in the implementation (e.g. JMS [13] and DDS [14] in case of the data distribution service, the three-cache for the synchronization of shared information etc.).

PSS (Publish/Subscribe Service) Component The primary objective of the PSS component is

to take in charge the distribution of the data being provided by the domain level components by means

C2-5

of the publish/subscribe pattern. In consideration of the necessity of testing different technologies (DDS and JMS) for this purpose, but also taking into account the fundamental need of hiding to the maximum extent the actual (COTS) technology adopted to fulfill the data distribution task, this component provides an abstraction layer capable to easily substitute the underlying technology without impacting the domain level components using it. As already stated, this has been possible by defining a thin facade interface (in order to limit the impact on the performances), providing the basic operations needed to subscribe and publish data over the SWIM Network. Subscriptions may be requested both in a push than in a pull style allowing the subscriber to be asynchronously notified on each new data arrival (push-style) or providing it a cache (pull-point) from which synchronously retrieve data. Moreover, it also provides the possibility to specify a content based filtering criteria both at subscription than at “execution” time. It is a responsibility of the component to guarantee data (i.e. topic in the publish/subscribe idiom) specific QoS (Quality of Service); this guarantee may imply a thinner or thicker layer depending on the capabilities of the underlying technology and COTS product.

SDS (Shared DataStore) Component The Shared Datastore subsystem aims to provide

a facility for the domain level subsystems to store and share data; in particular, by storing data in this “repository”, the client subsystem is declaring its need to share such data among distributed SWIM Boxes. This means that, considering that in the network different instances of the prototype are present, a client subsystem does not have to take care of how its different instances have a consistent view on the data that it stores and how the data are distributed to the other prototype instances. Therefore, it provides a transparently distributed and transactional store in such a way that other client instances may access and use shared data. The component interface is based on concepts like “SharedData” and “StoreKey” which represent the data (objects) to be shared and the key that uniquely identifies the data into the data store. This service is primarily intended to be used to store infrequently updated information that are needed to be known by (and automatically synchronized among) distributed SWIM-BOX subsystems instances. Current realization of this subsystem is based on the JBoss

Cache [15] implementation which provides a distributed transactional tree cache which can be configured to persistently store data among a cluster of nodes.

SEC (Security Manager) Component The Security Manager subsystem provides

support for securing message exchange on the SWIM-SUIT network by means of the implementation of authentication, authorization and message confidentiality mechanisms according to W3C XML Security specifications [16]. The Security Manager subsystem provides central self-signed certificate management through a preconfigured key-store containing private keys and certificates associated to all SWIM-BOXes and an access control repository, storing user accounts, roles and rules, to enforce authorization policies on client interactions. The Security Manager authorization model takes care of two main security aspects:

• manage access constraints at service level • to allow access to signed and encrypted

messages, or portions of them, only to authorized users

Since the WS-Security [17] and WS-Policy [18] requirements are not sufficiently powerful to enforce rules that are dependent on runtime parameters, the design choice has targeted a hybrid model composed of a static part, which implements an access control repository for providing policy enforcement at service level, and a dynamic part that allows authorization decisions, in terms of selective message signing/encryption and validation/decryption, based upon runtime parameters. Each SWIM-BOX access control repository is then configured through the definition of stakeholders, roles, allowed operations and their relationships. The main characteristic of the SWIM-SUIT security architecture is that it is not requested to the external (to the SWIM-BOX) clients to enforce any specific security check or task (e.g. data encryption) since these are completely in charge to the SWIM-BOX and to the SEC component in particular. Therefore, security tasks become for the maximum extent transparent to the clients, which are only requested to be eventually in charge of the right certificates for HTTPS communication with their “local” SWIM-BOX instance.

C2-6

Some Lessons Learnt One of the major issues that has to be

undertaken in this highly distributed system of systems environment is the complexity of the collaborative model that the nature of the system itself force to face. The SWIM concept is in fact mainly aimed at allowing interoperability and information/service sharing among heterogeneous systems and stakeholders each with its own requirements and needs (not only technical but also operational). This nature not only forces “SWIM providers” to look for standardization as a primary enabler for interoperability, but also to interact with a number of stakeholders with their own background, “dictionary” and different levels of knowledge on the various aspects of the problems to which the SWIM concept is applied. Since the SWIM system somehow represents the communication infrastructure on which these heterogeneous systems interact, while each stakeholder may have a partial knowledge of the processes and problems of the ATM business (where it is directly involved in) the SWIM provider should be able to gain a wider view on the system as a whole, thus being forced to interact with each of such stakeholders (e.g. in order to gather requirements).

A Technical Perspective The SWIM-SUIT project has given the

possibility to the project partners to have hands on experience in realizing a first SWIM prototype. Whatever opinion a third party may have on the actual prototype implementation, this has given a unique opportunity to the project team to test and experiment solutions. This encompasses, as an example, the utilization in a real challenging environment of new (at least for the ATM domain) technologies. JMS and DDS (the ones that maybe had the more expectations) are only few examples.

Web Service Notification, EJB3, EJB3 based Web Services and Application Server technology, JPA (Java Persistence API), JAXB (Java API for XML Binding), JBoss Cache etc.. are examples of technologies that have been experimented during the project.

A specific task is present in the SWIM-SUIT project which will report in detail such experience, therefore we intend here just to give an initial feedback.

DDS/JMS DDS and JMS are both powerful technologies

which have been successfully tested during the course of the project. Each has its pros and cons and its specific features. Both technologies have been found relatively easy to use even if programmers were not starting from a deep knowledge. JMS has been probably found easier to use (many books and examples might be found on the internet) but it offers lower support in terms of capabilities if compared to DDS. Anyway, depending on the features that need to be put in place (e.g. JBoss Messaging (JBoss JMS implementation) was used in a clustered configuration) its configuration might be complex to set up (since it also varies with the product). DDS is somehow more difficult to start with (less material and examples are available) but the technology acquisition is rather quick; difficulties arise when different Quality of Service (DDS has a very rich set of available QoS) must be put in place and, above all, when fine tuning is necessary. We did experienced a very different behavior when testing it in a LAN or in a WAN environment. Determining the right configuration that balance different needs (e.g. good both for small data samples then for large ones) could be very challenging. Also its integration in Application Server (JBoss AS in our case) introduces “tricks”.

EJB/Application Server EJB 3 technology has introduced a great

simplification thanks to the POJO (Plain Old Java Object) utilization. Anyway, a right Application Server configuration and, in general, its utilization and the debugging of application built on it are definitely not trivial tasks. An Application Server is composed by a large number of technology and product stacks working together, each one potentially having its own configuration; the task of making it correctly work as expected can be really challenging. Moreover, it is not a trivial task for an inexperienced programmer to acquire the “awareness” of what is the lifecycle of the different kinds of EJBs and how the Container manages them. Also in this case, many not immediately evident implications derive from the introduction of the Container layer and the particular EJB lifecycle; anyway, it is a very powerful instrument which definitely provides a feature rich environment providing support for virtually any need (e.g. security, transactions, management etc..). The EJB 3 stack also supports the JPA technology, which

C2-7

greatly simplifies the entity persistence model and allow to manage the relational data among entities and how are stored on a relational database. The user is therefore (relatively) free to worry about the management of storage and retrieving of data into the underlying relational database focusing its attention on the business code. Of course, also in this case, these benefits come with some additional complexity due to the need of correctly learn, use and configure the framework.

JBoss Cache JBoss Cache product is an open source product

which avoided us to produce, from scratch, a service being able to provide a transactional distributed cache for storing data with a low update frequency. It is a very flexible technology which can be customized and configured in different ways ranging from a centralized (with a single physical data store and several in memory caches) till to a completely distributed architecture (each instance having its own physical database and its replicated in memory cache). Therefore, from this point of view, it allowed us to test different configurations while not influencing SDS (our architectural component hiding the JBoss Cache product) clients and providing very valuable features (transactions, replication etc..).

On the other hand, its usage also gave us many “headaches” since it introduced an unexpected coupling among SWIM-BOX instances which, in a target scenario where each instance (meaning software version) might evolve asynchronously, is very unwelcomed. In general, in fact, since the JBoss Cache assures transactional behavior, an object insertion in the cache may fail if one of the system being involved in the transaction does not complete the task. A part from scalability considerations (which we were not able to test) – consider that every SWIM-BOX instance participates in the transaction – we found that if on a SWIM-BOX instance some domain component (refer to the architectural description) is newer or older and for this reason it does not know (meaning it does not has available a library) the object type being introduced in the cache produce an error on that system instance which prevents the transaction to successfully complete. This of course means that an indirect coupling among data domain components has been introduced by the SDS which prevents the whole system “network” (on that specific domain) to successfully accomplish its business tasks. Anyway, this problem might be

handled implementing a more complete transaction manager, provided the fact that JBoss Cache gives the possibility to specify the preferred transactions manager implementation to use). Other issues arose when having a system lately joining the network; in this case, if the SDS in the network contains a large amount of data, a “storm” effect take place on the late joining system. This effect may be probably prevented by properly setting the JBoss Cache configuration but it is another example of side effects introduced by the replication capability of the product which might be not immediately evident.

JAXB JAXB technology is largely utilized into

Application Servers and is even becoming part of the JDK (Java Development Kit). It greatly speeds up the task of obtaining a Java Object representation from an XML document and vice-versa. A number of customizations (plug-ins) are available in order to extend features that are not natively present in the reference distribution [19]. This technology has been extensively utilized in the context of the FDD component, where, following the ICOG2 architectural pattern, most of the actual informative content is represented via XML. Therefore, ICOG2 XML schemas defining the data and services to be supported by the interoperable systems, Java source code has been generated. Some minor changes to the XSDs (XML Schema Definition) have been necessary in order to accomplish this task, but this technology has been of fundamental importance in order to speed up the production of a Java Object / XML representation which is then been utilized both in the SWIM-BOX than in the Adapter side. Anyway, some limitations exist, at least considering the full set of capabilities that would have been needed in this context. In fact, ICOG model also specifies OCL (Object Constraint Language) constraints that should be enforced in order to ensure internal (in a same datum) and external (among different data) coherence. JAXB technology is not currently able to automatically generate code enforcing these specific checks, therefore ad hoc code has to be produced to accomplish this task. Of course, considering that JAXB produced source code is automatically generated, a careful design is needed to introduce, on top of the generated code, the necessary checks (thus avoiding write custom code in automatically generated sources).

C2-8

Web Service Notification During our work on Web Services that support

publish/subscribe operations it turned out that there are currently at least two different competing stacks of standards. Moreover, we could not find a stable version of the implementation that would have been compatible with the JBoss Web Service stack that had been selected for implementation earlier on. For that reason a new implementation had to be done for our prototype; for this reason not all features of WS-Notification are supported. It also turned out that not all features of WS-Topics [20] could easily be translated to the limited set of features provided by the core publish/subscribe system. The PSS had to abstract away some of the technology specific functions that would have been required to seamlessly transform high-level WS-Topics and WS-Notification features into low-level transport technology features. Finally, after some development cycles an interface could be defined that provided a feature set rich enough to satisfy the requirements of the upper software layers. Future implementations will have to seek for a method to both harmonize technologies to some extent but to also allow for differences where these lead to major improvements of some non-functional requirements.

WFS (Web Feature Services) When implementing the Aeronautical

Information Data Domain Component it turned out that the AIXM (Aeronautical Information XML Model) model defined by Eurocontrol could not be easily combined with the WFS standard. Some work on this topic has already been made within the Digital AIM [21] project and for that reason a specifically tailored version of the AIXM model had to be used [22]. This issue is currently dealt with by both Eurocontrol on the AIXM side and the Open Geospatial Consortium on the WFS side. Upcoming versions of both standards will then enable seamless integration. Some integration issues have already been solved by a newer version of WFS, but currently this version lacks support of the freely available browsers.

A Validation Perspective It is clear that such a complex system will be

designed, developed, tested and validated by different producers which, on the one hand allows obtaining a wider consensus and hopefully higher quality

solutions, but on the other hand increases the complexity of each of the steps needed for the production of such system. A carefully managed software development process is therefore very important together with, from our experience, a clear separation of system components concerns (i.e. in our architecture, a clear separation among domain level components) avoiding dependencies and interaction among them.

Validation exercises are also a critical step of such a process from different point of views:

• Organizational: Since the validation of the solution implies the participation of different systems (and consequently stakeholders), validation sessions must be carefully organized in order to assure that in a given timeframe the systems are ready for the validation exercise, each stakeholder technical expert(s) is(are) available and prepared together with operational experts. A validation exercise therefore needs the participation of a wide range of figures encompassing different skills (network experts, technical specialists, operational experts for the different systems being involved in the validation).

• Technical: Validation exercises had to be executed among geographically distributed locations with heterogeneous end user systems. Also in this case, from the technical point of view the only chance to successfully test the whole infrastructure is to separate the concerns and proceed by steps. Our experience has been to set up three levels of integration and validation:

• (A) A local integration/validation whose aim has been to test the integration among each (local) system and the SWIM-BOX (representing the local “endpoint” of the SWIM Infrastructure) and validate the technical interactions among them (e.g. data reception, data publication, service invocations etc..).

• (B) A global technical integration whose aim has been to test the correct functioning of the system on a geographical deployment limiting the validation to the technical interactions among

C2-9

heterogeneous systems (e.g. systems are able to receive data published from a third party or to invoke services on an endpoint remote system)

• (C) A pseudo-operational validation whose aim has been to validate the interactions among the endpoint systems on the basis of pseudo-operational scenarios (e.g. testing operationally meaningful scenarios etc..)

The first integration step has been obviously undertaken in parallel by the different systems that had to connect to the prototype, while the second and third steps are being conducted in an incremental fashion as soon as systems becomes available.

From the authors point of view, an important validation result however is already clear. In fact, it has been empirically proven that the ICOG2 architectural pattern (applied on the FDD component) which allows to execute application services (i.e. services exposed by the Adapters in our architecture) translating them in a underlying generic operation, allows to greatly limit the impact of changes in the data and service model on the FDD (i.e. middleware) level. Of course, this is obtained thanks to the extensive usage of XML in order to exchange and manage information and to a limited “intervention” at the FDD level on the data/service itself. In the course of the project, in fact, both data structures than application level services have been progressively added to the original ICOG FO model. The impact of such extensions is mainly located on the Adapter level (and mitigated by the usage of JAXB technology and an ad hoc developed utility library) since, as an example, whenever a system will want to consume or provide such a new service its adapter will have to be extended accordingly. On the contrary, on the FDD level, this extension/modification is nearly transparent as soon as it does not affect the very basic information that are internally (i.e. in the FDD) managed by the middleware. Moreover, such extensions may also occur asynchronously among SWIM-BOX/Adapter instances without impacting the whole system (e.g. if an adapter instance does not provide a newly introduced service, an incoming request on that service will simply result in an exception being raised on the requesting adapter).

Moving Towards Global Interoperability As already highlighted, SWIM concept is being

experimented both in Europe than in USA by different initiatives. EUROCONTROL and FAA organizations have already set up actions aimed to understand each other specificities and differences and, above all, to guarantee interoperability among the solutions that are being currently built. SWIM-SUIT project, being the first European effort in building a SWIM prototype, have been also involved in such coordination and, more concretely, is currently moving to physically experiment an EU-US data exchange by taking profit of the Boeing BR&TE participation to the project. Boeing labs, in fact, are also involved in US SWIM implementation programme thus enabling interoperability trials among the SWIM-SUIT test network and the USA SWIM network. As schematically depicted in Figure 4, the physical connection among the two SWIM networks has been realized via a dedicated VPN connection among Being labs in Chantilly (VA) and Madrid (Spain), the latter representing the physical bridge among the two networks.

09/12/2010 SWIM-SUIT User Forum, Rome

US SWIM Prototype

SWIM Prototype

Figure 4. Connection Among EU-US SWIM Networks

The actual trials are being currently defined in detail, but it has been already agreed to focus the experiments on the exchange of Surveillance and Flight data. In both cases, mediation and transformation services among the two sides of the “communication channel” will be necessary since differences exist among the respective data representations.

C2-10

In fact, in the SWIM-SUIT network, surveillance information is exchanged using Asterix Cat.62 EUROCONTROL standard ([7]) both in a binary format than in an ad hoc XML format while, on the US side, in order to speed up the end-to-end integration process, an XML ASDI (Aircraft Situation Display to Industry - [23]) representation have been chosen. Since ASDI web based HMI already exist allowing to visualize surveillance information, this choice guarantees an easy and quick validation which will allow to early discover possible issues in the whole connection chain.

C2-11

Anyway, the most important and valuable results of such experiments will come from the exchange of Flight Data. In this case, the task is much more difficult due to fact that, even if they are both based on XML, the EU flight data representation (i.e. the ICOG Flight Object) and the US one (i.e. the “ERAM” Flight Object [24]) are quite complex. Mapping the information present in both schemas is already a non trivial task in itself ([25]) given the differences in definition and design among the two Flight Object representations.

Therefore, a specific architecture has been designed in order to cope with the differences between data flows and services that are in place in

the two SWIM networks ends. The high level connection schema is shown in Figure 5 below.

As depicted in Figure 5. , message flows among the two ends with mediation services transforming ICOG Flight Objects to ERAM and vice-versa. Starting from the European side, the following flow occurs:

• The SWIM-BOX receives Flight Objects (representing flight crossing the Atlantic) from the SWIM-SUIT network

• Through a dedicated Adapter (not shown in the picture), the ICOG Flight Object is transferred to the Mediation Bridge, which encapsulates it in a JMS topic which is in turn published via the WAN to the next broker.

• The broker receiving the data over the WAN in Chantilly, publishes the data over a different JMS topic.

• The US mediator subscribes to the topic and transforms the ICOG flight object to an ERAM Flight Object. It then publishes the Flight to the US SWIM network via JMS.

QoSManagement

VPN (Internet)

SWIM-SUIT NodeUS SWIM Node

ASDI Provider

FO Provider (ERAM)

FO Consumer(ERAM)

ASDI Consumer

MediationService

(US side)

MediationService

(EU side)

SurveillanceProvider

(Asterix Cat. 62)FO Provider

(ICOG)

FO Consumer(ICOG)

SurveillanceConsumer

(Asterix Cat. 62)

SWIM-SUITNetwork

US SWIMNetwork

(Boeing Labs)

SWIM-BOX

ICOG FOCat.62 XML

ICOG FOCat.62 XML

Figure 5. EU-US SWIM Interconnection

The SWIM-SUIT team is currently fine tuning this architecture and data flows, also defining suitable pseudo-operational validation scenarios

which should focus on the provision of oceanic clearance during the course of flights crossing the Atlantic. Given the current time schedule, the actual

trials will be carried out in June 2010. The results of these experiments will be an important step for gaining insights and experience for moving towards a SWIM global interoperability and will form integral part of the project lessons learnt.

Conclusions The course of the SWIM-SUIT project gave to

the project team a very valuable opportunity to experiment different solutions both architectural and technological. It has been, and is currently being, a very challenging task from every point of view. Probably, rather than strictly technical issues, that as described before are also present and could be more deeply investigated, probably the bigger issue to face is the “human factor”. The interactions among a wide variety of actors, each one with its own background and skills, the set up of geographically distributed validation session (each with specific actors involved), the synchronization for assuring the availability of the partner legacy systems, network connectivity, personnel for performing tests, validation and actual building of several “adapter” prototypes is really a complex task.

Moreover, the design of meaningful interactions among the various “legacy” systems also brought its own complexity and issues (consider that, as per definition, a legacy system is a system with its own constraints and not designed and intended to perform tasks a part from those for which it is built for). It is quite obvious, but not worth to say, that in order to let future systems work in the new SWIM collaborative environment these will have to be modified (extended, enhanced etc.); a legacy system is a legacy system, you cannot expect that SWIM magically allows it to manage data or provide functionalities it does not already manage or provide. Rather, SWIM will definitely be a fundamental enabler to realize a seamless interoperability among the next generation of ATM systems.

References [1] FAA SWIM web site, www.faa.gov/about/office_org/headquarters_officies_ato_service_units_techops/swim, 2008

esarju.eu/[2] SESAR Programme homepage, www.s

[3] EU FP6 SWIM-SUIT Consortium project homepage, www.swim-suit.aero , 2008

[4] SESAR Consortium, The ATM Target Concept D3, pp. 36-38

[5] ICOG IOP Interface Specification – Final Report 07/05/2008

[6] FOIPS project homepage, www.eurocontrol.int/eatm/public/standard_page/foips.html

[7] Eurocontrol,ASTERIXCat 62 Ed.1.9, http://www.eurocontrol.int/asterix/gallery/content/public/documents/cat062p9ed19.pdf

oducts/ejb/

[8] Java Platform, Enterprise Edition (Java EE) , Enterprise JavaBeans Technology, http://java.sun.com/pr

[9] Organization for the Advancement of Structured Information Standards (Oasis), WS-BaseNotification v1.3, http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf

[10] W3C XML Schema homepage, http://www.w3.org/XML/Schema

dard

[11] Open Geospatial Consortium, Web Feature Service homepage, http://www.opengeospatial.org/stans/wfs

[12] Eurocontrol, SkyView2 homepage, http://www.eurocontrol.int/aim/public/standard_page/skyview_intro.html

[13] Sun Microsystems, Java Messagging Service JSR 914, http://java.sun.com/products/jms/overview.html

[14] Object Management Group (OMG), Data Distribution Service (DDS) for Real Time Systems Specifications, version 1.3 (formal/2007-01-01)

[15] JBoss Cache project homepage, http://jboss.org/jbosscache/

[16] W3C XML Security Working Group homepage, http://www.w3.org/2008/xmlsec/

C2-12

C2-13

of is), WS-

[17] Organization for the Advancement Structured Information Standards (OasSecurity Standard, version 1.1 http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

[18] Organization for the Advancement of Structured Information Standards (Oasis), WS-SecurityPolicy v1.2, http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf

[19] JAXB Reference Implementation Project home page, https://jaxb.dev.java.net/

[20] Organization for the Advancement of Structured Information Standards (Oasis), WS-Topics v1.3, http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-os.pdf

[21] Eurocontrol, Digital AIM homepage, http://www.eurocontrol.int/aim/public/standard_page/interoperability.html

[22] Pulsar, Wiki pages related to AIXM WFS and AIXM WFS Schema, http://wiki.pulsar.be/xnotam-wiki/index.php/AIXM_WFS_Schema

[23] ASDI Functional Description and InterfaceControl

Document

(ICD), http://www.fly.faa.gov/ASDI/asdidocs/ASDI_XML_ICD-v1.7-final.doc

[24] En Route Automation Modernization To System-Wide Information Management Service

BJECT MEDIATION SERVICE , 28th Digital Avionics

er 25-29, 2009

as been sponsored by the European Commission by contract No. TREN/07/FP6AE/S07.69084/036990.

2010 Integrated Communications Navigation and Surveillance (ICNS) Conference

May 11-13, 2010

Consumers Interface Requirements Document. Document Number: FAA-ERAM-2008-0831

[25] Samet Ayhan, Paul Comitz - SWIM INTEROPERABILITY WITH FLIGHT O

Systems Conference, Octob

Acknowledgements Work on the SWIM-SUIT project h