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.
General
Operational Needs
Functionality
Access and Use
Usage and access conditions have to be agreed between the service provider and the service consumer. \r\nExample of restrictions in usage and access of the OpenATM service: Identified users are granted permission to access and use the OpenATM service according the Terms of Use, provided that:\r\n • they agree not to distribute any part of the delivered data received from the OpenATM service, without prior written authorization from the service provider.\r\n • they agree not to use the OpenATM service for any commercial use unrelated to ther service provider’s business interests without the prior written authorization of the service provider. o Prohibited commercial uses includes any of the following actions taken without the service provider’s express approval: o sale of access to the OpenATM service; o sale of the data delivered via the OpenATM service.\r\n • Prohibited commercial uses do not include any use that the service provider expressly authorizes in writing.
Quality of Service
Validation
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
Concepts
Abbreviations
Information
Information Definition
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).
Data Structures
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.
Technical
Security Mechanism
Technical Constraint
Monitoring Description
Interfaces
Operations
Endpoints
Interface Binding Description Overview
Interface Binding Configurations
Behaviour
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).
Operations
Endpoints
Interface Binding Description Overview
Interface Binding Configurations
Behaviour
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).
HeartbeatDistribution
Operations
No operation required
Endpoints
Interface Binding Description Overview
Interface Binding Configurations
Behaviour
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).
The Flight Plan Data Management service supports any connecting CWP client to send certain inputs in order to trigger the correct & latest up-to-date controller information, more specifically: • Create ASPL or SFPL, • Modify an ASPL/SFPL or upgrade an SFPL, • Downgrade an SFPL into an ASPL, • Delete an existing ASPL/SFPL, • Submit requests about instructions/clearances given to the flight crew (e.g. DCT, CFL, NFL, speed, heading, …) • Change status information regarding the flight’s airframe (e.g. no FSSA, RVSM status, …) • Etc. 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 Flight Plan Distribution service) on the flight is sent. As such, subscription to the Flight Plan Distribution service is mandatory prior the user requesting flight data modifications.
Operations
Endpoints
Interface Binding Description Overview
Interface Binding Configurations
Behaviour
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).
Operations
Endpoints
Interface Binding Description Overview
Interface Binding Configurations
Behaviour
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).
Operations
Endpoints
Interface Binding Description Overview
Interface Binding Configurations
Behaviour
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).
The Flight Bright Management service allows any connecting CWP client to perform inputs related to highlight of a track or flight plan, more specifically: • SSR Bright: o Add an SSR Code to the SSR Bright function for his OPS sector o Cancel all SSR Codes from the SSR Bright function for his OPS sector o Delete one SSR Code from the SSR Bright function for his OPS sector • ModeS Bright: o Add an ModeS callsign to the ModeS Bright function for his OPS sector o Cancel all ModeS callsign from the ModeS Bright function for his OPS sector o Delete one ModeS callsign from the ModeS Bright function for his OPS sector • FPL Bright: o Add a flight to the FPL Bright function for his OPS sector o Delete a flight from the FPL Bright function for his OPS sector o Add a flight to the FPL Bright function of another internal OPS Sector (by specifying an internal flight sector) o Point a flight to an external flight sector / centre 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 Flight Bright Distribution service) on the flight is sent. As such, subscription to the Flight Bright distribution service is mandatory prior the user requesting modifications. Please do note that the distribution of the FlightBright message is OPS sector oriented.
Operations
No Operation Defined
Endpoints
Interface Binding Description Overview
Interface Binding Configurations
Behaviour
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).
The sectorisation management service provides any connecting client with the means to perform a re-sectorisation change. Two kind of requests can be made, being: • A request to verify a new sectorisation change (i.e. would the request once executed be valid for the server?), • A request to perform a sectorisation change. 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 Sectorisation Distribution service) is sent. As such, subscription to the Sectorisation distribution service is mandatory prior the user requesting sectorisation modifications.
Operations
No operation defined
Endpoints
Interface Binding Description Overview
Interface Binding Configurations
Behaviour
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).
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.
Operations
No operation defined
Endpoints
Interface Binding Description Overview
Interface Binding Configurations
Behaviour
The service behaviour is described in text and diagrams in various sections of the specification document (see SERVICE_SPECIFICATION in service documents).
References
Service Documents
The official OpenATM service definition as published, including the information definition, service behaviour, numerous diagrams (interfaces, sequence and others), additional technical details, and conformance matrix to the SWIM Service Description specification
The AIRM Semantic Correspondence. The correspondence was performed on AIRM 4.1.0 (sesarju:airm:v410).
The XSD definition files are embedded in the following package
The ASN.1 files are embedded in the following package
"A nice little program that explains the service consumer step-by-step on how to connect.