This is a partnership between Slovenia Control and EUROCONTROL
The OpenATM service decouples the ATM data service provider (ADSPs) from the air traffic service units (ATSUs) through an open and standardised service interfaces to foster ADSP/ATSU interoperability. Its aim is to provide ATSUs with an interface that allows its own CWP working positions (or other systems that require ATM data as a service) to connect with a remotely located FDPS. The OpenATM service includes correlation, flight data distribution, flight data management, etc.
Eurocontrol (MUAC) and potentially Slovenia Control in the future
allows service consumers to reserve an SSR code for manual assignment later on (i.e. manual assignment by using the Operation setSsr, see section 3.7.4), and to clear such code from display in the whole OPS sector.
An SSR code reserved for manual assignment is not available for automatic assignment. The SSR code will be re-served during a design parameter time and then released if not manually assigned to any flight plan or released according to the standard release rules if manually assigned to a flight plan during this design parameter time.
Access and Use
Quality of Service
OpenATM service does not support message persistency. Consumers are ensured that latest available and up-to-date data is received.
The Maastricht Upper Area Control Centre (MUAC) established in 2013 the Shared ATS System (SAS), where a virtual centre network solution has been put into operational use, with one air navigation service provider offering shared ATM data services for the benefit of another ATSU in the core area of Europe. With the Shared ATS System the safety, efficiency and cost-effectiveness of a data service solution has been proven.
The ADaaS Demonstrator, designed and developed in cooperation between MUAC and Slovenia Control, is composed of 3 phases: Phase 1: An ATM infrastructure is setup between MUAC and Slovenia Control where MUAC Controller Working Positions (CWP) installed in Slovenia Control are remotely connected to an FDPS instance in MUAC. The communication between the MUAC FDPS and CWPs is using the legacy interface. It is currently implemented and successful shadow operations have been conducted in June 2016. Phase2: The interface between FDPS and CWP is changed to an open interface and the Slovenia Control CWP is connected to the MUAC FDPS via this interface. The OpenCWP interface decouples the ATM data service provider (ADSPs) from the air traffic service units (ATSUs) through an open and standardised service interfaces to foster ADSP/ATSU cross-vendor interoperability. Services include correlation, flight data distribution, flight data management, etc. and has been successfully demonstrated in shadow operations in February 2017. Phase 3: The distributed architecture that allows remotely located data service providers to be completely synchronised is established. The identified solution(s) within the Target ADaaS Architecture have been experimentally established, in order to validate the assumptions and uncertainties of such architecture. Its feasibility has been demonstrated in shadow operations in November 2017
XML Encoding Rules
The information definition is described in section 4 Exchanged Information of the specification document (see SERVICE_SPECIFICATION in service documents). The AIRM semantic correspondence is established in a separate document (see AIRM_TRACE in service documents).
Authentication performed at application level
Service provider and consumer remain time-synchronized via NTP with their own time servers.
The SSR code management service allows a client to reserve an SSR code for manual assignment later on (i.e. manual assignment by using the Operation setSsr service call), and to clear such code from display in the whole OPS sector.An SSR code reserved for manual assignment is not available for automatic assignment. The SSR code will be reserved during a design parameter time and then released if not manually assigned to any flight plan or released according to the standard release rules if manually assigned to a flight plan during this design parameter time. When an input is made and successfully processed the response to the request is delivered in two parts: • Each input is first replied with the AcknowledgementMessage to indicate the acceptance or rejection of the request. The client is expected to start an internal timer in order to capture those cases where there would be no reply. In case of the latter, the client is expected to trigger a new input. • Secondly, provided the input was accepted, the updated information (as delivered by the SsrCode Distribution service) is sent. As such, subscription to the SsrCode distribution service is mandatory prior the user requesting modifications.
No operation defined
Interface Binding Description Overview
AMQP 1.0 content-type header used to specify media type values
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).