Report
Teaser, summary, work performed and final results
Periodic Reporting for period 2 - PJ17 SWIM-TI (SWIM Technical Infrastructure)
Teaser
Many Air Traffic Management (ATM) systems (Air Navigation Services Providers, Airports, Airlines Operation Centres, Meteo Service Providers, Aeronautical Services Providers, Airspace Users, Military, etc.) still communicate using various custom-designed one-to-one protocols...
Summary
Many Air Traffic Management (ATM) systems (Air Navigation Services Providers, Airports, Airlines Operation Centres, Meteo Service Providers, Aeronautical Services Providers, Airspace Users, Military, etc.) still communicate using various custom-designed one-to-one protocols, maintained locally, without being standardized. In addition, the ATM information structure, provision and consumption are specific per system and inconsistently updated. This leads to a lot of bilateral communications, low reuse, inefficiency, and cost increase.
In order to tackle this situation, the System Wide Information Management (SWIM) relies on a network of SWIM nodes (also called ‘ATM intranet’) which dramatically reduces the number of interfaces, decouples the information providers from the information consumers, and capitalizes on open standards.
It also completely changes the management of information along its lifecycle and across the European ATM system, thus considerably facilitating the exchange of information between a wide range of ATM stakeholders.
As explained in the ICAO SWIM Concept of Operations, SWIM will bring operational benefits by providing commonly understood, accurate and secured information delivered to the right stakeholders at the right time, in order to support them in collaborating and taking the right decisions. This seamless information access and interchange will allow the ATM community to conduct its business and operations in a safer and more efficient manner.
At the SWIM nodes, SWIM-enabled applications use interoperable services to exchange information conveyed through a SWIM Technical Infrastructure (SWIM-TI) middleware based on an IP-based network.
The three PJ.17 solutions build on the SESAR 1 results to extend the SWIM-TI (which will be a key communication enabler for other SESAR 2020 solutions):
• PJ.17-01 (SWIM-TI Purple Profile for Air/Ground Advisory Information Sharing) to integrate the aircraft into the SWIM network, thus giving it access to air/ground existing or new services (e.g. in meteorological and aeronautical domains);
• PJ.17-03 (SWIM-TI Green Profile for G/G Civil Military Information Sharing) to provide ground/ground secured access by the military to the civil SWIM network, leading to quicken civil/military collaboration.
• PJ.17-08 (SWIM-TI Common Runtime Registry) to develop a Runtime Registry extending the capability of the SESAR 1 SWIM-TI design-time (static) registry by acting as a real-time directory, used to dynamically discover and connect to deployed SWIM services.
Work performed
The project is structured in 5 Work Packages (WPs).
WP1: Project Management
WP1 has managed the project to achieve its objectives within schedule, resources and quality, while ensuring its integration into the SESAR 2020 Development Framework. It has also carried out the reporting and coordination to SJU, the technical and scientific coordination, and the communication.
Major achievements:
• Project management deliverables and H2020 reports submitted and approved;
• Close monitoring of the 3 solutions activities, which have delivered as expected;
• Integration within the SESAR programme, in particular with the dependent projects.
WP2: Solution PJ.17-01 SWIM-TI Purple Profile for Air/Ground Advisory Information Sharing
Building on the SESAR 1 results, WP2 aims at delivering a mature (TRL6) SWIM-TI Purple Profile solution for air-to-ground and ground-to-air sharing of advisory (non-safety critical) information. WP2 takes into account design constraints and requirements identified by other SESAR2020 solutions.
WP2 validates the Technical Specification in two phases:
1. TRL2 – TRL4: evolving SESAR 1 TRL2 solutions to TRL4.
2. TRL4 – TRL6: evolving TRL4 technical specification to TRL6.
Major achievements:
• Upgrades of the terminology, security risk assessment, architecture, requirements, integration of ISO/IEC AMQP 1.0;
• Technical architecture, messaging capabilities, security controls and interface requirements technically validated;
• TRL4 maturity gate passed;
• TRL6 activities launched.
WP3: Solution PJ.17-03 SWIM-TI Green Profile for G/G Civil Military Information Sharing
Its objective is to specify, prototype and verify a SWIM-TI Green Profile supporting G/G Civil-Military information exchanges with appropriate (cyber) security measures, resilience level and performance level.
WP3 addressed the Functional and Non-functional Requirements, and the Initial Verification Plan for the V2/TRL4 Iteration.
Major achievements:
• TRL2 Gate gate passed;
• Yellow Profile standard requirements relevant for the Green Profile TRL4 prototypes;
• Initial TRL4 TS/IRS.
• Draft TRL4 TVALP.
WP4: Solution PJ.17-08 SWIM-TI Common Runtime Registry
Based on the initial requirements and use cases identified as well as the experience from the design time registry identified during SESAR 1, WP4 originally aimed at delivering a mature (TRL6) solution for a SWIM runtime registry of services. During the reporting period the solution was descoped for budgetary reasons, with its maturity target reduced to TRL2 and some work of TRL4 remaining.
PJ.17-08 has developed a high-level technical specification including technical requirements of a runtime registry. Starting from the TRL2 maturity achieved in the preceding reporting period, the solution elaborated an OSED capturing the operational needs for a runtime registry. This OSED determines the functionalities of the runtime registry that are required from an operational point of view. These needs were the constraints for the high-level technical specifications.
Major achievements:
• OSED document (reflected as appendix to the technical specification);
• TRL4 High-level Technical Specification;
• Important findings related to the architecture leading to revisit the initial assumptions (e.g. distinction between a static design-time and a dynamic runtime registry with fixed functionalities is difficult to maintain).
WP5: Ethics requirements
WP5 has finalised the D5.2 - POPD - Requirement No. 2 and D5.4 - DU - Requirement No. 4 deliverables taking into account SJU\'s comments.
Final results
Progress beyond the state of the art:
* PJ.17-01 will support standardized air/ground exchange of advisory information via SWIM, whereas they are nowadays transmitted through specific means (voice over VHF, ACARS, etc.);
* PJ.17-03 will support civil/military communication via SWIM thus enabling to encompass Air Defence in the coordination;
* PJ.17-08 will add the real-time dimension to the existing static design-time registry.
Expected results until the end of the project:
The 3 solutions target the following maturity levels:
* PJ17-01: TRL6;
* PJ.17-03: TRL4;
* PJ.17-08: TRL2, and TRL4 elements to be complemented during a next R&D phase.
The main impacts are derived from the above-mentioned objectives. By greatly facilitating accurate and secure information sharing, collaboration between ATM stakeholders and with Military will be improved and the decisions made on more solid grounds. The operations are thus expected to be more efficient and less costly. In addition, the SWIM runtime registry will improve the resilience of the ATM system since data consumers using it will have the ability to recover in real time from a provider downtime by selecting immediately an alternative.
Website & more info
More info: http://www.sesarju.eu/projects/swim-ti.