By Ruben Flohr (SJU)

1. Page 1
LESSONS LEARNED

2. 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 -

3. Lessons learned: Operational concept
• Full compliancy with FF-ICE1 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 -

4. 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 -

5. 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 -

6. 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 -

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

8. 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