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 cross-vendor 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.
Access and Use
Quality of Service
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.\r\n\r\nThe ADaaS Demonstrator, designed and developed in cooperation between MUAC and Slovenia Control, is composed of 3 phases: \r\n• 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. \r\n• 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. \r\n• 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
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).
In order to define the messages, the ASN.1 definition language is used as a formal notation to define the OpenATM interface. For the OpenATM service, usage can be be made of the XER encoding (XML message format) and BER encoding. The usage of either message format is supported and can be either switched by using a configuration file, or alternatively by starting another CWP server process). The ASN.1 and XSD definition files are available in service documents. More information on XER and BER encoding is avaialble in the information definition.
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
Interface Binding Configurations
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).
"A nice little program that explains the service consumer step-by-step on how to connect.