eurocontrol guidelines for asm support systems …

EUROCONTROL Guidelines for ASM Support Systems Interfaces Implementation

Edition number: 1.0 Edition date: 12/04/2021 Document reference: EUROCONTROL-GUID-185

Guidelines ASM Support Systems Interfaces

EUROCONTROL Guidelines for ASM Support Systems Interfaces

Implementation

DOCUMENT IDENTIFIER : EUROCONTROL-GUID-185

Edition Number : 1.0 Edition Date : 12/04/2021 Status : Released Issue Intended for : General Public Category : EUROCONTROL Guidelines


Page 2 Released Issue Edition: 1.0

DOCUMENT CHARACTERISTICS TITLE


Publications Reference: GUID-185 ISBN Number: 978-2-87497-113-6

Document Identifier Edition Number: 1.0 EUROCONTROL-GUID-185 Edition Date: 12/04/2021

Abstract These Guidelines complement the EUROCONTROL Specification for Airspace Management (ASM) Support System Requirements supporting the ASM processes at local and FAB level Part II – ASM to ASM Systems Interface Requirements and provide guidance to support stakeholders in the implementation of interfaces between ASM Support Systems.

Keywords ASMtoASM Service Operational Interfaces ASM Actors WSDL

Filtering Technologies Information Definition

Information Exchange Mechanism

Publish/Subscribe Error handling Service Quality Documentation

Contact Person(s) E-mail Pavlin BELICHOVSKY

[email protected] Sasho NESHEVSKI

STATUS, AUDIENCE AND ACCESSIBILITY Status Intended for Accessible via

Working Draft General Public Intranet Draft EUROCONTROL Extranet Proposed Issue Restricted Internet (www.eurocontrol.int) Released Issue



DOCUMENT CHANGE RECORD The following table records the complete history of the successive editions of the present document.

EDITION NUMBER

EDITION DATE REASON FOR CHANGE PAGES AFFECTED

0.1 25/11/2019 Creation of the document All

0.2 14/04/2020 Update following internal review All





1.0 12/04/2021 Proposed Issue, following external stakeholder consultation All


Edition: 1.0 Released Issue Page 5

CONTENTS DOCUMENT CHARACTERISTICS ............................................................................ 2

DOCUMENT APPROVAL .......................................................................................... 3

DOCUMENT CHANGE RECORD .............................................................................. 4

CONTENTS ................................................................................................................ 5

LIST OF FIGURES ..................................................................................................... 7

EXECUTIVE SUMMARY ............................................................................................ 8

1. Introduction ...................................................................................................... 9 1.1 Purpose of the document ..................................................................................... 9 1.2 EUROCONTROL Guidelines ................................................................................. 9 1.3 Use of the document ............................................................................................. 9 1.4 Maintenance of the Guidelines ............................................................................. 9 1.5 Conventions .......................................................................................................... 9 1.6 Abbreviations and acronyms ............................................................................. 10 1.7 Definitions ............................................................................................................ 11 1.8 Reference material .............................................................................................. 14 1.9 Document structure ............................................................................................ 14

2. Implementation guidance .............................................................................. 15 2.1 Definition of the ASMtoASM service .................................................................. 15

2.1.1 Operational information exchange requirements definition ..................... 15 2.1.2 Definition of the ASM actors ....................................................................... 15 2.1.3 Definition of the information exchange mechanism ................................. 16

2.2 Implementation of ASMtoASM service .............................................................. 16 2.2.1 Interface implementation ............................................................................ 16

2.3 Technologies ....................................................................................................... 18 2.3.1 Web Services Description Language ......................................................... 18 2.3.2 Updating the WSDL ..................................................................................... 18

2.4 Information Definition ......................................................................................... 19 2.5 Deployment of the operational interfaces ......................................................... 19

3. Guidance on functional requirements .......................................................... 21 3.1 Publish/Subscribe Behaviour ............................................................................. 21

3.1.1 Connection Timeouts .................................................................................. 21 3.1.2 Message Timeouts ....................................................................................... 21 3.1.3 Client Acknowledgement ............................................................................ 21 3.1.4 Filtering ........................................................................................................ 22 3.1.5 Publication ................................................................................................... 22

3.2 Filter Behaviour ................................................................................................... 22 3.2.1 AirspaceIDFilter ........................................................................................... 22 3.2.2 ActivityIDFilter ............................................................................................. 22



3.2.3 MissionIDFilter ............................................................................................. 23 3.2.4 ChangePeriodFilter ...................................................................................... 23 3.2.5 InterestedIntervalFilter ................................................................................ 23 3.2.6 GeometryFilter ............................................................................................. 24

4. Guidance on non-functional requirements .................................................. 25 4.1 Error Handling ..................................................................................................... 25 4.2 Service Quality .................................................................................................... 25 4.3 Documentation .................................................................................................... 25

4.3.1 ASMtoASM Conformity ............................................................................... 25

ANNEX A - Guidelines Update Procedures .......................................................... 26



LIST OF FIGURES Figure 1 Identification of potential ASMtoASM clients ............................................................. 15 Figure 2 Identification of required information exchange mechanisms ................................. 16 Figure 3 Identification of appropriate interfaces and gap analysis ......................................... 17 Figure 4 Interface integration tests ............................................................................................ 19 Figure 5 Client integration tests ................................................................................................ 20



EXECUTIVE SUMMARY These EUROCONTROL Guidelines provide implementation guidance to support stakeholders in their effort to implement the necessary interfaces between ASM Support Systems. As such, this document complements the EUROCONTROL Specification for Airspace Management (ASM) Support System Requirements supporting the ASM processes at local and FAB level - Part II – ASM to ASM Systems Interface Requirements [RD 2]. The implementation guidance covers the definition and the implementation of the ASMtoAMS service, the associated technologies, the information definition and the deployment of the operational interfaces. Guidelines are also provided regarding the functional requirements – publish-subscribe behaviour and filter behaviour, as well as regarding the non-functional requirements – error handling, service quality and documentation.



1. Introduction1.1 Purpose of the document These Guidelines complement the EUROCONTROL Specification for Airspace Management (ASM) Support System Requirements supporting the ASM processes at local and FAB level: Part II – ASM to ASM Systems Interface Requirements [RD 2], and provide guidance to support stakeholders in the implementation of interfaces between ASM Support Systems.

1.2 EUROCONTROL Guidelines EUROCONTROL guidelines, as defined in EUROCONTROL Regulatory and Advisory Framework (ERAF), are advisory materials and contain: “Any information or provisions for physical characteristic, configuration, material, performance, personnel or procedure, the use of which is recognised as contributing to the establishment and operation of safe and efficient systems and services related to ATM in the EUROCONTROL Member States.”

Therefore, the application of EUROCONTROL guidelines document is not mandatory. In addition, EUROCONTROL Regulatory and Advisory Framework specifies that: “EUROCONTROL Guidelines may be used, inter alia, to support implementation and operation of ATM systems and services, and to:

• complement EUROCONTROL Rules and Specifications;• complement ICAO Recommended Practices and Procedures;• complement EC legislation;• indicate harmonisation targets for ATM Procedures;• encourage the application of best practice;• provide detailed procedural information.”

1.3 Use of the document This document is intended to be read and used by all civil and military ATS Providers in the EUROCONTROL Member States (41) and Comprehensive Agreement States (2). EUROCONTROL makes no warranty for the information contained in this document, nor does it assume any liability for its completeness or usefulness. Any decision taken on the basis of the information is at the sole responsibility of the user.

1.4 Maintenance of the Guidelines This EUROCONTROL Guidelines document has been developed under the EUROCONTROL Regulatory and Advisory Framework (ERAF) and is maintained by EUROCONTROL in accordance with this framework and in line with the EUROCONTROL Standards Development Procedures. The procedures are described in detail in Annex A.

1.5 Conventions The following conventions are used in this EUROCONTROL Guidelines:



1) Guidelines using the operative verb shall indicate that they must be implemented to achievethe minimum objectives of this guidance material.

2) Guidelines using the operative verb should indicate that they are recommended to achievethe best possible implementation of this guidance material.

3) Guidelines using the operative verb may indicate options.Numbers within square brackets are used to identify reference documents listed in Section 1.8, e.g.[1] identifies the first reference documents of Section 1.8.

Keywords are highlighted in the requirement text using bold as shown above.

Every requirement in this EUROCONTROL Guidelines is followed by a structured identifier, which can be used to uniquely reference the requirement/recommendation from associated documents and traceability tools. Such identifiers have the form:

ASM-[yy]-[Fn]-[nnn], where: ASM stands for ASM Support System requirement.

[yy]: Is a sequence of 2 to 4 characters to identify the environment to which the requirement is referring to;

Note: In this Guidelines this sequence of characters will be INTF

[Fn]: Is a sequence of 2 to 4 characters to identify the functionality of ASM Support System to which the requirement applies.

Note: In this Guidelines this sequence of characters will be IMPL

[nnn]: Is a numeric identifier, for a sequence of requirements with the same [Fn] identifier1.

1.6 Abbreviations and acronyms Abbreviation Term

AIRM ATM Information Reference Model

AIXM Aeronautical Information Exchange Model

AMQP Advanced Message Queuing Protocol

ASM Airspace Management

ATM Air Traffic Management

ATS Air Traffic Services

CR Change Request

EC European Commission

1 Requirement numbers are initially allocated incrementally in tens. This aids the subsequent management of this guidelines document allowing new requirements to be inserted between existing requirements whilst maintaining a logical number sequence.



Abbreviation Term

ERAF EUROCONTROL Advisory Framework

FAB Functional Airspace Block

GML Geographical Markup Language

ICAO International Civil Aviation Organisation

ID Identifier

INTF Interface

IMPL Implementation

LoA Letter of Agreement

SWIM System Wide Information Management

TTL Time-To-Live

XML Extensible Markup Language

XSD XML Schema Definition

WSDL Web Services Description Language

1.7 Definitions Term Definition Source

airspace management A planning function with the primary objective of maximising the utilisation of available airspace by dynamic time-sharing and, at times, the segregation of airspace among various categories of airspace users on the basis of short-term needs.

European Route Network Improvement Plan – Part 3 – ASM Handbook

action A specific permission to interact with a booking via the interfaces offered by this service. Actions may change with time and the state of the booking. Different actions may be performed via the same service operation in which case the modifiable data fields may be restricted by the currently available actions.

-



Term Definition Source

activity data Represents additional system specific data associated with an airspace structure.

-

ASM actors Human or system that participate in the ASM process

EUROCONTROL Specification for Airspace Management (ASM) System Requirements supporting the ASM processes at local and FAB level Part I - Baseline Requirements [RD 1]

conflict An overlap, both spatial and temporal, between any of the airspace structures in one airspace reservation (ARES) with any of the airspace structures of another ARES.

EUROCONTROL Specification for Airspace Management (ASM) System Requirements supporting the ASM processes at local and FAB level Part I - Baseline Requirements [RD 1]

client An application making use of any given service.

-

consumer A Consumer is the application that receives the messages from the message queue.

RabbitMQ and AMQP Concepts Glossary [RD 4]

external user Any local/FAB external system and its users that is a client of the ASM to ATC service including other ASM Support Systems

-

Interface binding Specification of the protocol and data format to be used in transmitting messages defined by the associated interface.

W3C Web Services Glossary [RD 3]




interoperability A set of functional, technical and operational properties required of the systems and constituents of the European ATM network and of the procedures for its operation, in order to enable its safe, seamless and efficient operation. Interoperability is achieved by making the systems and constituents compliant with the essential requirements.

European Route Network Improvement Plan – Part 3 – ASM Handbook [RD 5]

procedures As used in the context of the interoperability Regulation, means a standard method for either the technical or the operational use of systems, in the context of agreed and validated concepts of operation requiring uniform implementation throughout the European ATM network.

European Route Network Improvement Plan – Part 3 – ASM Handbook [RD 5]

producer A Producer is the application that is sending the messages to the message queue.

RabbitMQ and AMQP Concepts Glossary [RD 4]

proposal Update to a subset of the reservation data, namely FLs, times, or area. Proposals could be accepted or rejected.

-

synchronous An interaction is said to be synchronous when the participating agents must be available to receive and process the associated messages from the time the interaction is initiated until all messages are actually received or some failure condition is determined. The exact meaning of "available to receive the message" depends on the characteristics of the participating agents (including the transfer protocol it uses); it may, but does not necessarily, imply tight time synchronization, blocking a thread, etc.

W3C Web Services Glossary [RD 3]




system The aggregation of airborne and ground based constituents, as well as space-based equipment, that provides support for air navigation services for all phases of flight.

European Route Network Improvement Plan – Part 3 – The ASM Handbook [RD5]

topic or subscription topic

A subject to which clients can subscribe to receive related notifications.

-

1.8 Reference material [RD 1] EUROCONTROL Specification for Airspace Management (ASM) System Requirements

supporting the ASM processes at local and FAB level Part I - Baseline Requirements, EUROCONTROL-SPEC-166, dated 26/09/2017. https://www.eurocontrol.int/publication/eurocontrol-specification-airspace-management-asm-support-system-requirements

[RD 2] EUROCONTROL Specification for Airspace Management (ASM) Support System Requirements supporting the ASM processes at local and FAB level: Part II – ASM to ASM Systems Interface Requirements, EUROCONTROL-SPEC-179, dated 13/01/2020 (also referred to as ASMtoASM service specification), https://www.eurocontrol.int/publication/eurocontrol-specification-airspace-management-asm-support-system-requirements

[RD 3] World Wide Web Consortium (W3C) Web Services Glossary (2004), http://www.w3.org/TR/ws-gloss/

[RD 4] RabbitMQ and AMQP glossary and concepts https://www.cloudamqp.com/blog/2017-07-25-RabbitMQ-and-AMQP-concepts-glossary.html

[RD 5] European Route Network Improvement Plan (ERNIP), Part 3, Procedures for Airspace Management - The ASM Handbook – Airspace Management Handbook for the Application of the Concept of the Flexible Use of Airspace, ed. 5.7, dated 18/11/2020, https://www.eurocontrol.int/sites/default/files/2020-11/ernip-part-3-asm-handbook-edition-5-ver-5-7.pdf

1.9 Document structure The document is structured as follows:

• Section 1 describes the purpose, scope and structure of the document and lists referencedocuments, explains terms and contains a list of abbreviations.

• Section 2 contains the guidance for the implementation of the ASMtoASM service.

• Section 3 provides implementation guidance on functional requirements.

• Section 4 provides implementation guidance on non-functional requirements.

• Annex A describes the Guidelines update procedure.

https://www.eurocontrol.int/publication/eurocontrol-specification-airspace-management-asm-support-system-requirements




http://www.w3.org/TR/ws-gloss/

https://www.cloudamqp.com/blog/2017-07-25-RabbitMQ-and-AMQP-concepts-glossary.html

https://www.cloudamqp.com/blog/2017-07-25-RabbitMQ-and-AMQP-concepts-glossary.html

https://www.eurocontrol.int/sites/default/files/2020-11/ernip-part-3-asm-handbook-edition-5-ver-5-7.pdf

https://www.eurocontrol.int/sites/default/files/2020-11/ernip-part-3-asm-handbook-edition-5-ver-5-7.pdf



2. Implementation guidance2.1 Definition of the ASMtoASM service 2.1.1 Operational information exchange requirements definition The implementation of the ASMtoASM service2 starts with the definition of the applicable operational requirements. Any existing documented requirements need to be reviewed and confirmed as applicable in the context of the information exchange enabled by the ASMtoASM service. The ASMtoASM service specification [RD 2] (Section 2.2 and Annex B) provides detailed description of the aspects that need to be considered when defining the operational requirements. ASM-INTF-IMPL-010: The implementation of the ASMtoASM service shall start with the definition of the operational requirements. A ‘Conformity Checklist’ (Annex D) is defined as part of the ASMtoASM service specification [RD 2]. This should be used to ensure the expected level of conformity is achieved by any implementation.

2.1.2 Definition of the ASM actors The ASMtoASM Service is designed to be used either between two ASM Support Systems or between an ASM Support System and an External ASM User. An External ASM User could be, for example, a mission planning system, or any other system that needs ASM data and information.3 The target ASM actors should be identified along with their requirements for this service. Figure 1 shows an ASM system with 3 pre-existing client applications connected to the system via other, non-SWIM interfaces. Of these clients, two consume data that forms part of the ASMtoASM service, thus these two clients are the potential service consumers.

Figure 1 Identification of potential ASMtoASM clients

2 The full definition of the ASMtoASM Service is provided in Section 2 of the ASMtoASM service specification) [RD 2] 3 The Guidelines do not include requirements on NM systems. The scope of this Guideline document remains within the scope of the

ASMtoASM service specification) [RD 2], as defined in Section 1.3 Scope of the document: “This Specification does not address interfaces requirements of other systems such as NM, NOTAM and FDPS. The NM B2B Airspace Structure Services are already specified in the document NM NOP/B2B Reference Manuals – Airspace Services, Document Reference B2B/Airspace, latest release, and are outside of the scope of this Specification. Requirements for local ASM Support Systems to interface with NM systems are also not addressed in this specification.”



2.1.3 Definition of the information exchange mechanism The ASMtoASM Service supports both a Synchronous Request/Reply mechanism and a Publish/Subscribe Push mechanism. Depending on the ASM actors involved in the implementation the appropriate mechanisms need to be selected. It should be noted that the ASMtoASM service manages subscriptions through a Request/Reply mechanism and so ASM actors requiring only a Publish/Subscribe mechanism will still need to make use of a Request/Reply interface. Although the service can operate only with the Synchronous Request/Reply mechanism, it is recommended that both mechanisms are implemented in order to ensure timely reception of frequently changing data, thus ensuring information exchange efficiency. Figure 2 Identification of required information exchange mechanisms shows the two potential ASMtoASM service clients for an ASM system. Client 1 requires real-time activation data which can be fulfilled using a Publish/Subscribe mechanism. Client 2 is only interested in the booking data of the ASM system at certain times of day and so it can make use of a Request/Reply mechanism to retrieve the data it requires when it requires it.

Figure 2 Identification of required information exchange mechanisms

2.2 Implementation of ASMtoASM service The ASMtoASM service is a single overall service, broken down into several different interfaces. Each of these interfaces constitutes a contract that must be respected in order to achieve interoperability. This section outlines the steps required to implement any given interface as defined by the service.

2.2.1 Interface implementation Each of the interfaces defined in the ASMtoASM service provides the means of exchanging a variety of data and information for different aspects of the ASM process. While there are some data dependencies between these interfaces they can be implemented and, to an extent, consumed independently. This interdependence does not mean the interfaces cannot be implemented or used independently but more that the data may not be understandable without information from another interface. For instance, choosing to share booking conflict information without sharing any booking information would leave the conflict information unusable whereas the opposite may be appropriate for an application to share.



ASM-INTF-IMPL-020: Each interface should be assessed to determine its usefulness and applicability to the end goal for both the provision and consumption of data. ASM-INTF-IMPL-030: When carrying out the assessment of the interfaces to be implemented, the following activities shall be performed:

• Identify the data subject to exchange and the associated interfaces, based on existing LoAs,contracts, etc., as well as the description of the interfaces (ASMtoASM service specification,[RD 2] Section 2.11 Service Behaviour)

• Build an understanding of the purpose and scope of those interfaces• Analyse the workflows defined in the interfaces and how they correspond to the existing

system to identify gaps• Analyse the inputs and outputs and how they correspond to the existing data in the system

to identify gaps• Analyse how any potential gaps can be filled, where workflows and data in the interfaces and

current system may need to be supplemented

To supplement the basic requirement and to further aid interoperability, Section 2.11 Service Behaviour of the ASMtoASM service specification [RD 2] also defines service behaviour examples for each interface outlining simple use cases for each interface. The content of this section will facilitate both the interface selection and implementation. ASM-INTF-IMPL-040: When implementing any of the ASMtoASM service interfaces the use cases defined in the ASMtoASM service specification, [RD 2], Section 2.11 Service Behaviour should be followed as guidance. ASM-INTF-IMPL-050: Each selected interface shall be implemented to conform to the corresponding requirements from the EUROCONTROL ASMtoASM service specification [RD 2]. ASM-INTF-IMPL-060: Interfaces should be selected for both provision and consumption of data.

Figure 3 Identification of appropriate interfaces and gap analysis Figure 3 Identification of appropriate interfaces and gap analysis shows the ASM system with two clients, one interested in activation data and the other interested in booking data. The ASMtoASM Activation and Booking interfaces have been selected for implementation to serve these clients. In order to implement these interfaces, they must integrate with the existing parts of the ASM System responsible for the activation and booking processes. Any difference in the internal processes and



data models need to be bridged to provide the interface.

2.3 Technologies The goal of the ASMtoASM service is to enable an ASM Support System to exchange information with other ASM Support Systems and/or External Clients. To be able to do this seamlessly, all the implementations, both servers and clients, must be interoperable. To enable a smooth and efficient implementation it is necessary to build a solid understand of the technology requirements of the interfaces, including identifying any possible conflicts with existing technologies in use. From an overall system point of view, it needs to be determined how the selected interfaces will be incorporated into the existing operational system. The required technologies, to enable interoperability, are defined by the selected SWIM interface bindings in the ASMtoASM service specification [RD 2], Section 2.5 Technologies, and specified by the ASM-INTF-TIP-010, ASM-INTF-TIP-020 and ASM-INTF-TIP-030.

2.3.1 Web Services Description Language The Web Services Description Language (WSDL) is used to describe the operations provided by a web service. The ASMtoASM service definition is supplied with a companion WSDL for each of the interfaces. These WSDLs describe the operations as well as the inputs and outputs of the interfaces in exact detail. This allows the generation of interface stubs and data model from the WSDL. Compliance with the WSDL is essential for interoperability. With the growing use of web services and the WSDL specification, the most widely used high-level programming languages provide support to generate the interface code. This allows either a client or server implementation to be guaranteed to be syntactically compatible with any other implementation. Implementations using such a technology will be able to work entirely with their chosen technology to produce and consume interface messages and exchange them with other clients. Where code generation technologies are not available, the WSDL will need to be examined and understood in greater detail. The rules defined in the WSDL will need to be respected manually by the developers to ensure interoperability. ASM-INTF-IMPL-070: Interface implementations shall be compliant with the WSDL. Each of the WSDLs is accompanied by one or more XML Schema Definition (XSD) files which are standard XML schemas. These schemas define the detail of the structure of the inputs and outputs. ASM-INTF-IMPL-080: Messages exchanged shall be compliant with the XML schemas.

2.3.2 Updating the WSDL A WSDL and its schemas may change over time, whether to introduce new operations or new data types into the existing interfaces. When using technologies supporting code generation this can be a reasonably straightforward process. Regenerated code can be used to replace the existing code and most incompatible changes will be highlighted automatically. In cases where code generation is not available this process will require the XSDs to be completely re-evaluated manually to assess whether there are significant changes affecting the syntactic correctness of the system.



2.4 Information Definition To supplement the WSDL the ASMtoASM service specification provides an ‘Information Definition’ section (ASMtoASM service specification, [RD 2], Section 2.7 Information definition). This describes the same messages and data structures defined by the WSDL and the XSD schemas but in plain language. This description gives more context to every element in the model to provide a greater understanding of the data being exchanged. In addition, the Information Definition section highlights elements that are mandatory and those that are optional. It also highlights elements that vary depending on the operation being called, for instance server defined identifiers should never be set when requesting to create a new booking or mission for example. Supplementing this further, the Information Definition is mapped to the AIRM through a semantic correspondence. This links all elements of the Information Definition to pre-existing elements of the AIRM.

2.5 Deployment of the operational interfaces The final step of the implementation is the integration of the interfaces with the current system workflows. This requires development of test cases to allow validation of the interface implementation. ASM-INTF-IMPL-090: Test cases shall be developed to test the functioning of the new interfaces and their integration within the rest of the system.

Figure 4 Interface integration tests Once the test and validation activities have been completed successfully, the operational interfaces can be deployed.

Service consumers, the ASM actors originally identified, should be provided with a test platform to allow integration testing to be performed by the consumer, separate from the operational system. This also allows for some validation of the consumer application by the service provider to protect against an application overloading the services.

ASM-INTF-IMPL-100: A test system should be deployed to allow service consumers to validate their connections and interoperability.



Figure 5 Client integration tests Once these activities have been completed, service consumers can be allowed access to the operational services.



3. Guidance on functional requirements3.1 Publish/Subscribe Behaviour Subscriptions are managed through the Request/Reply based SubscriptionManagement interface. This interface is used to establish AMQP message queues which are used to fulfil the Publication interface. Subscriptions are expected to follow the lifecycle of the client application. On start up a client application is expected to establish the subscriptions it requires, no more than one subscription per topic. The service provider should expect to maintain this subscription until the client deletes it or the client application terminates. Subscriptions, however, are not expected to be persistent. In the case where the service needs to be taken offline, for maintenance for example, client applications should be expected to re-establish their own subscriptions when they reconnect. A subscription will always relate to one AMQP message queue. One message queue may be related to more than one subscription belonging to the same client.

3.1.1 Connection Timeouts The AMQP message broker should be configured to required keep alive messages to be sent by the client. A keep alive timeout of 60 seconds for the message broker should be reasonable in most situations. AMQP client applications can define their own timeout and could request a shorter timeout interval. This should be discouraged; a very short timeout will demand additional resources from the broker which could be detrimental.

3.1.2 Message Timeouts AMQP messages have a Time-To-Live (TTL) attribute defining the time in the future that the message will expire. This should be set for all message with a reasonable, relatively small value. Clients not wanting to process messages as soon as they become available should instead make use of the request/reply interfaces to access data when it is required. Any messages reaching their TTL and expiring should cause all subscriptions linked to the same message queue to be deleted. In such a situation where the client is still available it will detect the deleted message queue and it can re-establish its subscriptions as appropriate and in the same way that it would, should the service go offline for maintenance. The mechanism to detect message expiry may be dependent upon the AMQP implementation chosen. Some implementations allow for expired messages to be automatically moved to a ‘dead letter’ queue which the producer can monitor. Alternatively, other implementations provide extensive management APIs allowing for expiry to be notified as a message on a management message queue.

3.1.3 Client Acknowledgement The ASMtoASM service interfaces allow access to potentially critical real-time data, particularly the Airspace Status interface. To be sure of reliable delivery of messages, service providers should encourage the use of the acknowledgement mechanism in the AMQP protocol. AMQP implementations generally allow for an automatic or a manual acknowledgement process, allowing for the client to potentially perform some, if not all, processing of a message before it is removed from the queue following the manual acknowledgement. This approach should be encouraged so that clients failing to process messages can be disconnected following expiry before they become a problem.



3.1.4 Filtering Filters may be provided to the ASMtoASM service interfaces when creating a subscription. Filters should be applied when possible to reduce the load on both the service provider and the consumers side. The AMQP 1.0 protocol provides its own mechanisms for filtering. This mechanism must not be used as it will lead to the expiry of messages through their TTL which should lead to the deletion of subscriptions as described in Paragraph 3.1.2 above.

3.1.5 Publication Publication of changed data should occur as soon as possible in order to notify clients in a timely manner. Any subscription topics which experience regular significant delays in publication should be documented.

3.2 Filter Behaviour The ASMtoASM service specification [RD 2] defines a general filtering mechanism and specific filters. The interfaces are specified such that they allow for any filter or combination of them to be applied to any request and any subscription. This section describes the expected behaviour of each filter regarding each service interface. This section groups booking data, booking action data and booking conflict data under ‘booking data’, both actions and conflicts refer to one or more bookings and it is those bookings that should be used when applying filter criteria. In case filters are not implemented, the complete set of data will be received as provided by the service provider.

3.2.1 AirspaceIDFilter This filter allows for several airspace identifiers to be defined. ASM-INTF-IMPL-110: If any one of the following airspace identifiers is found by the filter, the subject shall be retained by the AirspaceIDFilter.

• Static Data – Static data messages contain airspace definitions, the identifiers of theseshould be compared with the filter IDs.

• Activity Data – Each activity data instance references a specific airspace by the airspaceidentifier, this should be compared with the filter IDs.

• Activation Data – Each activation data instance references the airspace identifier it is for; thisidentifier should be compared with the filter IDs.

• Booking Data – Each booking instance references one or more airspace; these should becompared with the filter IDs.

• Proposal – The identifiers of the airspace referenced by the proposal should be comparedwith the filter IDs.

• Mission Data – While missions do not reference bookings in the service model, bookings doreference missions. The airspace identifiers from the bookings referencing the mission datashould be compared with the filter IDs.

• Event – There are no links from an event to any airspace. An INVALID_INPUT messageshould be returned in response to such a filter.

3.2.2 ActivityIDFilter This filter allows for a number of activity identifiers to be defined.



ASM-INTF-IMPL-120: If any one of the following activity identifiers is found by the filter, the subject shall be retained by the ActivityIDFilter.

• Static Data – No activity information is referenced from static data. An INVALID_INPUTmessage should be returned in response to such a filter.

• Activity Data – No activity information is referenced from activity data. An INVALID_INPUTmessage should be returned in response to such a filter.

• Activation Data – Each activation instance references several bookings which are causingthe activation, these booking IDs should be compared with the filter IDs.

• Booking Data – The booking ID should be compared with the filter IDs.

• Proposal – The proposal ID should be compared with the filter IDs.

• Mission Data – While missions do not reference bookings in the service model, bookings doreference missions. The identifiers from the bookings referencing the mission data shouldbe compared with the filter IDs.

• Event – The event ID should be compared with the filter IDs.

3.2.3 MissionIDFilter This filter allows for a number of mission identifiers to be defined. ASM-INTF-IMPL-130: If any one of the following mission identifiers is found by the filter, the subject shall be retained by the MissionIDFilter.

• Static Data – No mission information is referenced from static data. An INVALID_INPUTmessage should be returned in response to such a filter.

• Activity Data – No mission information is referenced from activity data. An INVALID_INPUTmessage should be returned in response to such a filter.

• Activation Data – Each activation instance references several bookings which are causingthe activation, these bookings in turn reference associated missions, these mission IDsshould be compared with the filter IDs.

• Booking Data – Each booking may reference several associated missions; these mission IDsshould be compared with the filter IDs.

• Proposal – Each proposal instance references a booking which the proposal is for: the IDsof the missions associated to the original booking should be compared with the filter IDs.

• Mission Data – The mission ID should be compared with the filter IDs.

• Event – There are no links from an event to any mission. An INVALID_INPUT messageshould be returned in response to such a filter.

3.2.4 ChangePeriodFilter This filter allows for a time period to be defined where both the start and end of the interval are defined. ASM-INTF-IMPL-140: Any subject that has changed within the defined time interval shall be retained by the ChangePeriodFilter. For all data elements, they should be returned if their definition was last modified within the given change interval.

3.2.5 InterestedIntervalFilter This filter allows for a time period to be defined where both the start and end of the interval are defined.



ASM-INTF-IMPL-150: Any subject that exists within the defined time interval shall be retained by the InterestedIntervalFilter.

• Static Data – The AIXM lifetime should be compared with the filter interval.

• Activity Data – The lifetime of the associated airspace should be compared with the filter interval.

• Activation Data – The intervals defined by activation bands should be compared with the filter interval.

• Booking Data – The booked intervals defined by the booking should be compared with the filter interval, if one interval overlaps the filter interval the booking should be retained.

• Proposal – The booked intervals defined by the proposal should be compared with the filter interval, if one interval overlaps the filter interval the booking should be retained.

• Mission Data – Missions contain no time references. An INVALID_INPUT message should be returned in response to such a filter.

• Event – The event interval defined by its start and end times should be compared with the filter interval.

3.2.6 GeometryFilter This filter allows for a GML geometry to be defined. ASM-INTF-IMPL-160: Any subject that overlaps/intersects the defined geometry shall be retained by the GeometryFilter. ASM-INTF-IMPL-170: The GeometryFilter shall apply as per the AirspaceID filter, however instead of comparing the referenced airspace IDs it should compare the geometry of the airspace of each applicable data type with that defined in the filter.



4. Guidance on non-functional requirements4.1 Error Handling The ASMtoASM service specification provides support for signalling that errors were encountered via the Reply message. This allows for a reply status to be defined with each response. These status codes and their meaning are defined in the specification. Except for the ‘OK’ status, the status codes can all be accompanied by optional error messages to describe the problem in more detail. When possible the problematic identifier or field names should be provided in the description to support the client application in resolving the problem.

4.2 Service Quality The ASMtoASM service specification document outlines several considerations that should be made in terms of service quality. These can be found in section 2.10 of the ASMtoASM service specification [RD 2].

4.3 Documentation 4.3.1 ASMtoASM Conformity ASM-INTF-IMPL-180: Supporting documentation shall be provided covering the following elements:

• Identification of which service interfaces and requirements the system conforms to.

• Identification of any interface operations that have been implemented but do not conform tothe ASMtoASM service specification [RD 2].

• Full details of all deviations from the ASMtoASM service specification [RD 2] including detailsof any elements of the data models that are not supported or additional restrictions that needto be placed on use of the model due to constraints of the ASM support system.

• Any permissions restrictions not managed by the service interfaces, for instance whetherclients with read access to the Mission interface can expect to also have write access.

ASM-INTF-IMPL-190: The supporting documentation shall be made available to support the integration with any other ASM support system using the ASMtoASM services. Before starting integration of two ASMtoASM enabled systems this documentation needs to be shared to ensure there are no significant conformity issues that may prevent the integration.



ANNEX A - Guidelines Update Procedures It is necessary to periodically check this EUROCONTROL Guidelines for consistency with referenced material. The Guidelines is also expected to evolve following real project and field experience, as well as advances in technology.

The main objectives of a regular review are:

a) to improve the quality of the requirements (e.g. clarity, testability, etc.);b) to verify that the level of detail published is adequate;c) to ensure that design-oriented requirements, imposing unnecessary constraints totechnical solutions, have been avoided;d) to ensure that advances in technology are properly reflected;e) to make all stakeholders, including industry, aware of the latest developments.

The update process for this EUROCONTROL Guidelines may be summarised as follows:

Stakeholders may provide change proposals either through existing working arrangements (e.g., established working groups) or by sending a formal Change Request (CR) to the generic email address: [email protected]

The CR needs to provide following minimum elements:

• Originator information (name, Organisation, contact details)• Guidelines title, number and edition date• Page, chapter, section (subsection) where the issue appears• Description of the issue and reason for change• Specific change proposal text (incl. potential alternatives, if any).

Main steps towards a revised version:

• Agency (Standardisation unit) will assess each CR in coordination with content owners,classify the urgency and establish the CR impact category (major, minor or editorial).• Agency will then prepare resolution proposal(s) and, if needed, discuss those with theoriginator and/or relevant working arrangements. Note: CR will be grouped into “changepackages” to consider reasonable update cycles.• Agreed changes will be integrated into a revised version “Proposed Issue” including asummarised list of changes.• Consultation will be performed in accordance with the CR impact category identified:

o Major changes need consultation at working layers (e.g., working group or Team)o Editorial changes may be implemented directly at any stage though grouped withchange packages.

Note: Identified errors which may cause potential problems when implementing, may be corrected directly via separate “Corrigendum”.

The Agency will apply this process in an objective and impartial way and will consult stakeholders as needed and in line with the formal Standards Development Process.

mailto:[email protected]

Edition number: 1.0 Edition date: 12/04/2021 Document reference: EUROCONTROL-GUID-185

EUROCONTROL Specifications

Subtitle Roboto Light 24pt Second line Date, period or phase Roboto Regular 14pt

eurocontrol guidelines for asm support systems …

Documents