Transitioning from AMHS to SWIM - EUROCONTROL

PublicSafety

PublicTransport

Air TrafficManagement

Maritime

Defence Transitioning from AMHS to

SWIM

| © Frequentis AG 2019Classification<Presentation title> by <Presenter>2 |

You’ve heard this before..

| © Frequentis AG 2019SWIM WorkshopTransitioning from AMHS to SWIM by Josef JAHN|3

Based on X.400 Technology

Point-to-point communication

Monolithic systems


Based on commonly agreed and understood data standards and information models

Easy to Share/Monetize

data (Interoperability)

Digital Data – Enhance Air

Situation Awareness

Reduce Costs (Leverage

Internet Technology)


But are we really doing this service-oriented?


MosaiX SWIM

ATM Grade Digital Platform


Key Enabler of Digital Transformation

Micro-Services Architecture

Can be deployed with ATM and UTM Service modules

Low vendor lock- in

Different options available for message broker based on performance requirements

Flexible deployment options (on-premise, cloud, hybrid)

Compliance to ED-153 –guidelines for software assurance


Aeronautical info

Flight info

Surveillance

Weather info

STAKEHOLDERS Aviation and non-aviation

AVIATION EXCHANGE MODELS and legacy protocols

ATC

Airlines Airports

MET Office

Military

UTMServicesProviders

Voice Automation

MET ATFM

Air Navigation Service Provider (ANSP)

SWIM … System-Wide Information Management

AIM

Surveillance

Communications Automation Surveillance Networks Information Management

MosaiX


smartSIS

Enhance ATC Air Situation

Awareness


Enhance Air Traffic Controllers Air Situational Awareness

Display NOTAM (Textual and D-NOTAM) and MET information

Possibility to replay data (time slider)

Display UTM Information -Operational Plan, Airspace, Reservation (UVR), Drones Positions

Ingest AIMX5.1 and ARINC 424 Static Data

Create/approve Operational Plans

Creation of Airspace Reservation

Notification Capabilities (call the drone operator)

Native SWIM Application (Consumes AIXM, FIXM, IWXXM)

Basemap

FIR Boundaries

Airport




AMHS / SWIM

Gateway


MosaiX SWIM

AIDA-NG or smartMessenger

AMHSswitch

AMHSSWIM GW

Filte

ring

Message broker

NOTAM

Text

MET

Text

FPL

Text

D-NOTAM

AIXM

MET

IWXXM

Flight/Flow

FIXM

AMHS

SWIM

Provision of conventional operational data in AMHS format to SWIM-based applications

AMHS address based


Large existing customer base for AMHS

Clear path towards SWIM is needed

Two major challenges:

o Content handling

o Adressing / Routing


Idea 1: Extend AMHS address space into the SWIM world

o Benefit: Easy to learn for AMHS-proficient users

o Drawback: Point to Point, Not Service-oriented, SWIM becomes just another network cable

Idea 2: Terminate AMHS address space at the AMHS/SWIM Gateway

o Everything beyond that is service oriented

o May still need some way of In-Band communication back to an information originator


X.400 send to a “SWIM consumer” AMHS address

SWIM consumer does conversion and provides data via SWIM services

Data is persisted on the SWIM service side

Data no longer needs to be BER encoded

o This can be done by the gateway, simplifying data consumption

Subscribers on the SWIM side can specify exactly what content they are interested in

New consumers can request the latest relevant messages based on the same filters

Sender no longer needs to know whom to send data to within SWIM

No more cyclical address translation/routing table updates on Thursday

Filter expressions can be much more powerful

o Geometry-based

o Content-based

o Etc.


FROM originator could be the AMHS/SWIM Gateway itself

But recipients need to be known

o Distribution list could be preconfigured in the AMHS/SWIM Gateway

o Distribution on the AMHS side could then be handled in the AMHS World

But the question remains, is this direction even needed?


In a pure SWIM world, how do we replicate/replace this functionality?

How can a service consumer contact the producer of aeronautical information?

o Email? (Out-of-band communication)

o Specialized SWIM messaging services?

Do we even still need to send plaintext messages to a particular station?

o Request to correct a message could also modeled as part of a SWIM service

o Perhaps have a kind of originator address present inside the SWIM data?


Conversion Services

…as a service


TAC Weather to IWXXM

NOTAM to AIXM 5.1 DNOTAM

ATS Flight Plans to FIXM


Allows products to be SWIM-native even during transition period

We already have conversion services as microservices

o Very easy to offer this service to the outside, using our SWIM Platform

Enables the establishment of standardized conversion processes

Eliminates different conversion process interpretations


ICAO recommends against it

It may delay production of native AIXM/IWXXM/FIXM data

No human can reasonably grasp AIXM/IWXXM/FIXM data

Conversion from IWXXM/AIXM/FIXM to legacy formats is lossy

Different conversion implementations may lead to different results


Very few official IWXXM report sources

IWXXM requires an AIXM database

o Can use a simplified static data repository (without temporality support)

o Static data validity and representation as part of IWXXM display requires a full AIXM DB

Geometry conversion from TAC to IWXXM

o Invalid geometries due to formulas like "NW of LINE 3045N... etc" in which we use the geometry ofthe FIR to compute a gml polygon in IWXXM.

Many TAC messages are invalid

o Not compliant with ICAO annex 3 and amendments

o As no operator can validate all the messages

o Multiple validation levels are expected to be needed (FULL, STRICT, SOFT, NONE)

We recommend mandatory use of “Collect“ schema wrapper

o Allows multiple reports to be packaged in the same message

o Currently not regulated


SWIM Yellow Profile TI:

o SOAP

o AMQP 1.0

o REST

o Protobuf

Customers also ask for:

o Kafka

o ZeroMQ

o MQTT


Customers ask for IWXXM / FIXM / AIXM services via REST

Customers ask for IWXXM / FIXM / AIXM data structure, but in JSON format

Customers ask for OpenID Connect for service authentication/authorization

AMQP 1.0 gaining in popularity

o Mostly due to performance, simplicity, ease of transport across networks

Limited practical interest in SOAP

o WS-Notification: Low interest

o WS-Security: Medium interest

o WS-Federation, SAML: Low interest


Core services need to be standardized

o Conformance is good

o Compliance is better

o Interoperability is best

REST is a Fact of Life

OpenID is a Fact of Life

Data Conversion simplifies the transition from AMHS to SWIM

Data Conversion can help break the Chicken/Egg problem:

o No data producers if there’s no consumers

o No client applications if there’s nobody producing the data

PublicSafety

PublicTransport

Air TrafficManagement

Maritime

Defence

Documents

Transitioning from AMHS to SWIM - EUROCONTROL