Page 1

LESSONS LEARNED

Lessons learned: Benefits

• Benefits of improved sharing of network and flight information - both pre-flight and during flight execution - are recognised by global partners ANSPs and Network Managers.

• Further integration of AU operations into network management, also during flight execution, would be much welcomed by the involved AU

• There is value in moving towards globally harmonized network management (FF-ICE/2).

• Automated filtering, alerting and visualisation is increasing situational awareness

- 2 -

Lessons learned: Operational concept

• Full compliancy with FF-ICE\1 for downstream distribution requires further work

• Further work is required to achieve full traceability of data originator, processing and quality (meta data)

• At this moment national regulator at times require all NOTAMS to be physically on-board, which is not aligned to automated filtering and subscription to updates.

• Next step: download from FMS or FOC that contains the latest version of the flight plan, also during flight execution.

• Extended flight plan (containing AU 4D trajectory script) is only European concept at this moment

- 3 -

Lessons learned: Collaboration

• Global uptake of SWIM is a fact. Huge interest in collaboration on SWIM.

• Registry:– Registry service as bridge between SWIM Masterclasses and

SWIM Global Demonstrations. Helpful in accessing SWIM standards and service discovery.

– Most global partners keen to build experience using the SESAR registry. Different registries for FAA operations and MG-II.

– Usage of the registry as a collaborative environment tool was fair, but not optimal. Much coordination still done through email instead of the registry.

– With growing global SWIM participation the need for using a (federated) registry is still expected to increase, at the very least for service discovery.

- 4 -

Lessons learned: Information Models

• Usage of FIXM, AIXM, WXXM is very effective in easily achieving global interoperability. Using the XMs “works”!

• Multiple partners provided a Gufi service. Several consistency issues have popped such as the same flight with multiple Gufis

• UUID for AIXM data requires further coordination• Confusion about NOTAM vs D-NOTAM. Not all partners familiar with D-

NOTAM• Some residual ambiguity on FIXM 3.0.1 elements (or missing) that will be

fixed in FIXM 4.0. • Need for globally agreeing definition and usage of meta data• Extensions to the core versions of XMs have come into scope at several

occasions

- 5 -

Lessons learned: Architecture

• Architecture: – Common references were used: GATMOC, ICAO SWIM manual– Easier to start with NAF operational and technical views

• The demonstration has respected and demonstrated the possibility to integrate different deployment models (Centralized, distributed or federated)

• Federated Public Key Infrastructure (PKI) not yet used.• The role and ownership of (technical) transformation services. Popped up

at many places in the preparation, and can have multiple deployment options.

- 6 -

Lessons learned: Technology

• Usage of open standards was welcomed by all• SOAP based WS and REST-full based WS were selected as technology to

support synchronous messaging (R/R), and successfully validated (overlap with EU SWIM TI yellow profile)

• AMQP 1.0 was selected as technology to support asynchronous messaging (P/S), and successfully validated. Recommendation to further explore usage for R/R as well.

• Lots of connectivity problems, caused by all kinds of variations of network configurations. Requires further coordination to reach global standards.

• Need to distinguish between network security, transport level security, message level security, access management and business rules.

• Open issues on end-to-end security and data access governance and enforcement.

Recommended approach

Needs for global interoperability•Address lessons learned derived from architectural and technical challenges identified during the preparation of the joint interoperability demonstrations•Separate out data access governance from deployment architecture and policy enforcement•Centralized, federated and distributed have to be interoperable•Need to accommodate different types of services: commercial services vs mandatory ATM services. Not all SWIM services are ANSP owned, need to allow for non-ANSP services•A service provider needs to keep control over access•End to end security (no intermediaries, msg level security)•Complete specification on standards, rules, meta data, etc •Proper global governance for such specification