SWIM-SUIT: Laying the technological foundation for SWIM Massimiliano De Angelis May 2008 ICNS 2008

Project Details RTD project (STREP) Call 4b of the 6FP Budget: 11,8 M€ 6,3 M€ funded by EC

Consortium at a Glance 10 Countries 20 Partners 6 Industries 1 Airport Managing Company 2 Airlines 4 ANSPs 4 SMEs 2 Research Centres 1 University External support from: User Group

SWIM-SUIT Objectives SWIM Prototype Specification of the requirements for the SWIM implementation Validation of the technologies identified as enablers of the SWIM concept Assessment of the Organisational, Legal and Financial Implications SWIM FEASIBILITY

SWIM-SUIT Prototype AOC Flight Simulator MXP AIRPORT Lisbon AIRPORT ISPOC Prototype ATFCM (CFMU) ACC/APP ACC ACC/APP

SWIM-SUIT Prototype Manage Content Check Store Acquire Data AOC Flight Simulator MXP AIRPORT Lisbon AIRPORT ISPOC Prototype ATFCM (CFMU) ACC/APP ACC ACC/APP

SWIM-SUIT Prototype AOC Flight Simulator MXP AIRPORT Lisbon AIRPORT ISPOC Prototype ATFCM (CFMU) ACC/APP ACC ACC/APP Disseminate Data Manage Access Security Licensing Pricing

SWIM-SUIT Prototype ATM Virtual Information Pool AVI POOL AOC Flight Simulator MXP AIRPORT Lisbon AIRPORT ISPOC Prototype ATFCM (CFMU) ACC/APP ACC ACC/APP

WP 2.2: Identification of Technology and of Services Options (2/3)  SWIM-SUIT partners have identified the criteria as important for selecting the right technologies Technical knowledge available at partner Applicability for Wide Area Network (WAN) Scalability Robustness Flexibility Reliability Message overhead Portability Manageability Interoperability Suitability for Near Real Time COTS selection Use of standards Availability of IDE Support for Security The different criteria are grouped by topics having different weights: Network Performance e.g. Message overhead Efficiency e.g. Reliability, Robustness, Scalability Maintainability and Management e.g. Flexibility, Manageability.. Stability and Evolutivity e.g. Interoperability, Use of Standards.. Security Support for Security

WP 2.2: Identification of Technology and of Services Options (3/3) Scalability Robustness Use of standard Message Overhead …  For each property a value in the range from 0 to 4 has been assigned 0 - Technology does not lean on standard Technology leans on a new standard (durability not guaranteed) Technology leans on mature and widespread standards.  The Criteria are divided in two groups: the Swim Criteria are those that must be considered allocated to the SWIM project, while the SWIM-SUIT Criteria that are related to SWIM- Prototype aiming to more pragmatic issues in the short time.

Candidate Technologies  For request/reply pattern CORBA ESB request/reply Web services (J2EE)  For publish/subscribe pattern MOM (JMS) Web services notification ESB publish/subscribe CORBA Notification service DDS  The criteria Analysis shown that  in relation to the Request/Reply pattern, the Web Services technology has been evaluated as the more indicated  Relatively to the Publish/Subscribe pattern, JMS gets the higher score for the SWIM-SUIT Criteria while DDS stands out among the selected technologies for the SWIM Criteria.

 For request/reply pattern:  Web services (J2EE) and ESB Req/Rep have been considered substantially equivalent for the SWIM criteria  For the prototype implementation a better knowledge by the partners leads to Web Service selection.  For publish/subscribe pattern:  DDS has been considered more suitable with respect to efficiency, network performance group criteria (better QoS support, scalability …)  For the prototype implementation a better availability of IDE integration and maturity of technology leads to experiment both JMS then DDS. Criteria Analysis

WP 2.3: Information Models and Services Specification  Defines the data structure of the ATM Domain that will be included in the prototype (Information Model)  Identifies several interaction scenarios between ATM Systems on the SWIM network (Service specification ). These scenarios are the input for the design phases of the SWIM prototype.

The ATM Data Domain considered  The data Domain that will be considered for the prototype design and implementation are:  Flight Data. Thanks to the experience of ICOG, the Flight Object Server scenarios will be analyzed. At the moment the following SWIM services are envisaged:  Surveillance Data ( e.g. Asterix ) create_FO Create (locally) a Flight Object:  Verify eligibility  Assign unique ID  Assign ownership update_FOEnable changes of Flight Object or part of it handover_FOAllow to take the ownership of Flight Object

General SWIM-based interaction schema Request/reply communication pattern Publish/subscribe communication pattern

WP 2.4: SWIM Prototype Architecture Design (1/2)  Transfers technology and information models into an architectural design.  The early description of the business scenarios is leading to the definition of a component model for SWIM-SUIT.  The design phase is trying to define the layers that have been highlighted in WP1

WP 2.4: SWIM Prototype Architecture Design (2/2)  For each identified layer, the high level architecture foresee different services/modules  Technical services hiding distribution and communication technologies have been placed at the lowest level and a “technology independence” layer has been introduced

WP 2.4: SWIM-BOX To/From ATM Stakeholders To/From DataLink Layer The “SWIM-BOX” composition reflects the previous identified layered approach:  A Data Domain level  A Core Level which in turn is composed by a technology independence layer trying to hide the actual technology utilized for the Pub/Sub and Req/Reply patterns

Legacy Systems integration  SWIM-SUIT prototype will be tested integrating different systems provided by SWIM-SUIT partners emulating ATM Legacy Systems in operation (activity will be carried out during WP 2.5) How to connect these systems to SWIM-SUIT? Legacy ATM System service request Gateway /adapter SERVICEINTERFACESERVICEINTERFACE TOTHENETWORKTOTHENETWORK

Solutions  The adapters or the gateways between the ATM Legacy Systems and SWIM-BOX as access point to/from SWIM-BOX:  To access to data and services of SWIM-BOX;  By subscribing to specific data domains.  To receive data and service calls from SWIM-BOX;  By registering services and corresponding callbacks.