Transitioning from AMHS to SWIM - EUROCONTROL

transcript

PublicSafety

PublicTransport

Air TrafficManagement

Maritime

Defence Transitioning from AMHS to

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

Airlines Airports

MET Office

Military

UTMServicesProviders

Voice Automation

MET ATFM

Air Navigation Service Provider (ANSP)

SWIM … System-Wide Information Management

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

Message broker

D-NOTAM

Flight/Flow

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

Transitioning from AMHS to SWIM - EUROCONTROL

Documents