Do all ATM systems SWIM?

1. Do all ATM systems SWIM? Panel Discussion SWIM-SUIT User Forum, Rome

2. Do all ATM systems SWIM? SWIMming Across the Globe Institutional Issues Transition Issues How the SWIM-SUIT architecture could fit SESAR SWIM-SUIT User Forum, Rome

3. SWIMming Across the Globe Miguel Vilaplana / Boeing RT Europe Paul Comitz / Boeing RT US Georg Trausmuth / Frequentis SWIM-SUIT User Forum, Rome

4. US-Europe SWIM Interoperability BOEING RESEARCH & TECHNOLOGY (B&RT) Miguel Vilaplana - BR&T Europe Paul Comitz - BR&T US (Advanced ATM) SWIM-SUIT User Forum, Rome

5. US-Europe SWIM Interoperability • Objectives • Conduct initial interoperability study between US and European SWIM infrastructures in coordination with the FAA and Eurocontrol/SJU • Envisioned as two complementary efforts: SWIM-SUIT and FAA • Explore challenges associated with interoperability and contribute to establish a reference framework to evaluate benefits to stakeholders • Approach • Conduct interoperability experiments between European and US SWIM prototypes focusing on surveillance and flight data exchange • SWIM-SUIT as European SWIM prototype and Boeing US Aviation Information Systems laboratory as US SWIM prototype • Define architectural framework and candidate set of experiments (using SWIM-SUIT Validation Framework), considering users/stakeholders input for pseudo-operational scenarios SWIM-SUIT User Forum, Rome

6. US-Europe SWIM Interoperability US SWIM Lab SWIM Prototype SWIM-SUIT User Forum, Rome

7. ERAM FO Cat 62 XML US-Europe SWIM Interoperability • Initial proposed architecture FO Source (ICOG) Surveillance Source ASDI Source FO Source (ERAM) ERAM FO US SWIM Network (Boeing Lab) Cat 62 XML Mediation Service (US side) Mediation Service (Europe side) SWIM-SUIT Network SWIM Box QoS Management ICOG FO ICOG FO Cat 62 XML VPN (Internet) Cat 62 XML FO Consumer (ERAM) Surveillance Consumer Surveillance Consumer FO Consumer (ICOG) SWIM-SUIT legacy System US SWIM Node SWIM-SUIT User Forum, Rome

8. SESAR SWIM Next Gen SWIM Interoperability Bridge New York New York Santa Maria Santa Maria AOC AOC A POSSIBLE FUTURE… TODAY… US-Europe SWIM Interoperability • Great potential to provide valuable insight and early lessons learnt: • Interoperability requirements • Network bridging • Data ontology (e.g. mapping flight object models) • Opportunities for users: “global operations from your local SWIM” SWIM-SUIT User Forum, Rome

9. On Second thought… • Synchronized SWIMming? SWIM-SUIT User Forum, Rome

10. Synchronized SWIMming • Ongoing work on SWIM in US and Europe, other regions may follow – with their own approach • How do we ensure interoperability? • Different data models • Different service models • Different technical implementations • SWIM borders – how to integrate countries outside? (local issue?) • Would the SWIM concept be extended to other domains (e.g. non ATM: Naval Traffic, Civil protection..) 10 SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

11. SWIMming across the Globe SWIM-SUIT User Forum, Rome

12. Institutional Issues Anna Masutti / AS&T Law Firm Georg Trausmuth / Frequentis Dario Di Crescenzo / SELEX SI SWIM-SUIT User Forum, Rome

13. Institutional Issues:Points for Discussion Anna Masutti / AS&T Law Firm SWIM-SUIT User Forum, Rome

14. It should be clarified whether the nature of Swim Services corresponds to a ‘commercial transaction’ or not. Regarding the nature of the relationship of the parties involved, it is necessary to consider which of the two main models proposed (A or B) is the most suitable: contractual, or non-contractual, in the absence of a contract. Institutional Issues: Points for Discussion 14 SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

15. Institutional Issues: Points for Discussion • With the channelling of liability, only one party will be identified as liable for the damage caused. • Is the channelling of liability suitable for SWIM, considering that there are many parties involved in the dissemination and use of information? 15 SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

16. Institutional Issues: Points for Discussion Are you in favour of the proposed system of protection of the liable party based on the limitation of its liability to a certain amount (first tier)? • If so, do you agree with the use of a flexible system for liability based on the following: • “(i) Up to the above [X] amount, the liable party shall not be able to deny or exclude its liability; • (ii) beyond the above [X] amount, the liable party can exclude its liability ifit proves one of the exemptions provided by law]” . 16 SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

17. Are you in favour of a two-tier liability system that comprises a firsttier funded by compulsory contributions and a second tier that could be made available when necessary? If so, which system of contribution to the Supplementary Compensation Fund is the most suitable of the following two options? “A percentage of the mandatory amounts collected in respect of each of the services offered to the users, or Member States could contribute to the second tier in proportion to their contributions to the SESAR Programme”. Institutional Issues: Points for Discussion SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

18. On Second thought… • Institutional Issues: Security • Institutional Issues: Information Sharing SWIM-SUIT User Forum, Rome

19. Institutional issues – Security • SWIM will depend on the trust that service providers and users will have in the system • An approach is required that links individual security components into an overall system (“federated architectures”) • Network-layer security, e.g. LAN • Service-level security • End-to-end security • Protection of service meta-data • Communication patterns may be in contradiction to security requirements 19 SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

20. Institutional issues: Information sharing • SWIM is asking for information sharing • Prior agreement on mandatory and optional data to be shared • Wrong information create responsibility i.e. liability • Would be worth to have in place benefit/penalties” models ? Sanctions for wrong information disseminated SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

21. Institutional Issues SWIM-SUIT User Forum, Rome

22. Transition Issues Gaetano Vito / SICTA Antonello Cedrone / SELEX SI Dario di Crescenzo / SELEX SI SWIM-SUIT User Forum, Rome

23. Transition Issues: The need for Data Filler: what lessons do we learn Gaetano Vito / SICTA SWIM-SUIT User Forum, Rome

24. Data Filler initial requirements • Data Filler has been designed as a helper library for the adapters. • It was meant to be used in pseudo operative scenarios to validate the data provided by legacy systems. • Three levels of checking: • Semantic, according to the ICOG Flight Object meta-model; • Cross consistency between different clusters; • Mandatory fields, originally filled with default static data. • It also allows the creation of new FO from scratch and provides further functionalities to facilitate Adapter development. SWIM-SUIT User Forum, Rome

25. The need for Data Filler • Static, default data was not sufficient to carry out the desired operative tasks • Data Filler was chosen as the technical enabler to fill this gap within the transition phase • New functionalities have thus been developed to extract and expand significant data from available sources Data Filler has evolved from a static helper library to a light Publisher • At run time further requirements have arisen: • Crucial FO clusters (e.g. Trajectory, Flight Script etc.) • could not be provided by all legacy systems SWIM-SUIT User Forum, Rome

26. Data Filler: Lessons learnt • Data Filler bridges whatwe currently have (legacy systems) and what we want to achieve (operational improvements) • Its features could thus represent a first subset of basic requirements which future SWIM compliant systems will have to implement • This preliminary gap analysis shall be refined in the SESAR context (WP8 and WP14) SWIM-SUIT User Forum, Rome

27. On Second thought… • Legacy System Integration • Extension, versioning and ownership of the model SWIM-SUIT User Forum, Rome

28. Legacy System Integration The Adapter is mandatory until a new Legacy System “SWIM compliant” is not available. The SWIM-BOX and the Adapter Design help the portability: The Web services in the different domains are coarse grained The adaptation of the SWIM-BOX Web-Services is done in one-shot The payload of the Web Services contains a stringfied representation of the service An incremental approach in the adaptation can be used by each SWIM Partner: At each step one or more Legacy services can be adapted while the other operational services don’t need to be changed SWIM-SUIT User Forum, Rome

29. Extension, versioning and ownership of the model • Information/Service model will evolve over time even after SESAR • Being SESAR “on line”, WP8 would drive the model evolution.. But what then? • A standardization body? • From our experience, real model extension will be effective only during actual usage • Most of the details will pop up by a “bottom up” approach SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

30. Transition Issues SWIM-SUIT User Forum, Rome

31. How the SWIM-SUIT architecture could fit SESAR Dario Di Crescenzo / SELEX SI Georg Trausmuth / Frequentis Gaetano Vito / SICTA SWIM-SUIT User Forum, Rome

32. SWIM-SUIT architecture:Pros and Cons Dario Di Crescenzo / SELEX SI SWIM-SUIT User Forum, Rome

33. SESAR WPS <-> SWIM-SUIT WP8 OpsWPs WPB TransversalWPs Requirements APP-ICD Prototype Application Provide applications fulfilling business objectives System WPs (e.g. 10, 12) MDW-ICD Physically Interact via MDW-ICD SWIM Infrastructure WP14 Provide technical infrastructure SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

34. SESAR WPS <-> SWIM-SUIT Legacy System ICOG2 WP4 (Pseudo-operative Validation) Execute validation scenarios using WP2 and WP3 outputs APP-ICD Adapter Builds Adapters and integrates them onto the platform WP3 (Integration) SB-ICD Physically Interact via SB-ICD (which represents the MDW-ICD) SWIM-BOX WP2 Provides technical infrastructure SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

35. An Example: FOS implementation using the SWIM-BOX Component Component Comp. Component Component Adapt. lib. Adapt. lib. Application Application FO-ICD I.L.. I.L.. A.L. A.L. SB-ICD SB-ICD Wire-ICD SWIM-BOX B Middleware Middleware FDD FDD DDS/JMS Web Services DDS/JMS Web Services System A System B FOS Legacy system (e.g. ENAV) Legacy system Adapter Applicative layer Interfacing layer SB-ICD Local Middleware Local Middleware SWIM-BOX A Network (VPN) SWIM-SUIT User Forum, Rome

36. Pros and Cons of the current architecture (1/2) SWIM-BOX foresees specialized “Data Domain” components Pro Decoupling among data domain components Each data domain may have its own “interface” and provide access to the clients using its own “technology” Cons Data Domains do not interact with each other (no information exchange) SWIM-BOX hides, to the external clients, details about the actual technology used to distribute data Pro Technology change has impact only at SWIM-BOX level Even internally to the SWIM-BOX, technology change can be (at a certain extent) transparent Cons Different technologies provide different features (can be easier or harder to guarantee a same level of “QoS”) SWIM-SUIT User Forum, Rome

37. Pros and Cons of the current architecture (2/2) • The actual information is basically seen as a payload which is analysed only at a limited extent • Pro • Dependency of the domain component from the information model is limited • Extension of the models and versioning issues have a very limited impact at SWIM-BOX level • Cons • In order to maintain the coupling to the model limited, the domain components are only able to provide basic features • Payload is usually XML -> Increase in the message size and computation effort when payload has to be analysed • SWIM-BOX enforces security characteristics • Pro • Complexity and Performance penalties added by security is totally taken in charge by the SWIM-BOX • Clients do not have to care about security issues • Cons • Clients have to “trust” the SWIM-BOX • End to End security? SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

38. On Second thought… • Data Modelling Issues • SWIM-SUIT Validation & SESAR SWIM-SUIT User Forum, Rome

39. Data Modelling Issues • SWIM-SUIT data models are relatively simple and easy to handle because of the size of the project • FDD is following ICOG model – with extensions • SDD is limited – a case study based on ASTERIX Cat.62 • AID is based on AIXM and “flattened” model • Issues for SWIM beyond prototypes • Versioning of service and data model • Responsible organisation for management 39 SWIM-SUIT User Forum, Rome SWIM-SUIT User Forum, Rome

40. SWIM-SUIT Validation & SESAR • A review of SWIM-SUIT results will be necessary to achieve convergence and compatibility with SESAR SWIM thread (WP8 + WP14 activities) • How much does SWIM-SUIT fit the expectations for the future SWIM system? • What are the main areas that will have to be adjusted? Why? • SWIM-SUIT Validation Strategy might represent a first step towards the creation of SESAR V&VI (WP3) • How much of the validation process can be re-used in SESAR? • What needs to be changed? SWIM-SUIT User Forum, Rome

41. How the SWIM-SUIT architecture could fit SESAR SWIM-SUIT User Forum, Rome