SWIM-SUIT: Laying the technological foundation for SWIM

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

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

3. User Group 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:

4. 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 Prototype SWIM-SUIT Objectives SWIM FEASIBILITY

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

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

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

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

9. 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 • 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

10. WP 2.2: Identification of Technology and of Services Options (3/3) • For each property a value in the range from 0 to 4 has been assigned • 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.

11. Candidate Technologies • For request/reply pattern • For publish/subscribe pattern • 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.

12. Criteria Analysis • 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. • 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.

13. Criteria Analysis

14. WP 2.3: Information Models and ServicesSpecification • 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.

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

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

17. WP 2.4: SWIM PrototypeArchitecture 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

18. WP 2.4: SWIM PrototypeArchitecture 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

19. WP 2.4: SWIM-BOX • 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 To/From ATM Stakeholders To/From DataLink Layer

20. Legacy ATM System 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? S E R V I C E I N T E R F A C E T O T H E N E T W O R K Gateway /adapter service request

21. Solutions • The adapters or the gatewaysbetween 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.