EUROCONTROL
EUROCONTROL is an intergovernmental organisation with 41 Member and 2 Comprehensive Agreement States.
ASMtoASM
1.0
Abstract
The ASMtoASM service enables the complete set of ASM functions necessary for the interactions between ASM Support Systems or ASM Support System and External Users at local/FAB level in the process of airspace management.
It supports data exchange between an ASM Support System and any External Users at local/FAB level both within and across FAB boundaries.
Service Type
DEFINITION
Lifecycle Stage
PROSPECTIVE
Business Activity Type
AERODROME_OPERATION
Intended Consumer
Information Exchange Category
AERONAUTICAL_INFORMATION_EXCHANGE
General
Operational Needs
Operational Need
ASM Support Systems facilitate the exchange of ASM data between ASM Support Systems used by different stakeholders.
This information exchange supports the optimisation of ASM operations from the beginning of the airspace planning cycle. Furthermore, users from one state could reserve airspace structures managed by another state using their national ASM Support System. The traceability of the requirements specified in this specification document to information exchange requirements, defined in Annex 12 of the ASM Handbook, can be found in Annex B of this document. These information exchange requirements have been used in the identification for the service interfaces defined in this specification document.
Operational Need
General description
The ASMtoASM Service is designed to support data exchange directly between any two ASM Support Systems both within and across FAB boundaries. Such an exchange is shown above between ASM Support System 1 and ASM Support System 2 and between ASM Support System 2 and ASM Support System 3. Additionally, the interface can be used by any client of an ASM Support System to exchange data. This is again shown above with the ASM Service Client making requests of ASM Support System 1 and ASM Support System 3. The ASM support systems both connect to each other acting as both a client and a server to the other, whereas the clients only connect directly to their own ASM support system. Data flow between the client and server is bidirectional.
ASM Support System - ASM Support System
In this configuration the ASM Support Systems can each act as a client to each other, though the relationship does not need to be bidirectional. This allows each ASM Support System privilege to distribute general information from the other system to its users. It also allows each ASM Support System to create and edit bookings in the other system and engage in coordination with the other system directly. It is the responsibility of the system providing the services to restrict the data shared with all or each client as appropriate. Equally, it is the responsibility of the client system to ensure booking, creation and editing is granted for the appropriate individual users.
External ASM User - ASM Support System
In this configuration an External User is authenticated itself as a specific user of the ASM Support System resulting in a series of privileges to view and create data in the same way as a standard user of the ASM Support System.
This configuration is applicable for external client tools of the ASM Support System that belong to the same state as opposed to the above ASM Support System – ASM Support System relationship which supports users from different states. Here the focus is on the option of the service to be used by any ASM Service Client that is not a client to the ASM Support System, e.g. a mission management system could be a client to the ASM Support System. In this context, the presumption is that both ASM and MMS are belonging to the same state.
It is anticipated that, for example, the creation of mission data within the ASM Support System may not generally be available to another ASM Support System but a privileged user may be allowed to access the functionality through this interface. This differentiation in privileges is the responsibility of the ASM Support System providing the service and not managed directly through the service interfaces.
Obtaining up to date data
The interfaces defined within this document are supported by both a Synchronous Request/Reply mechanism and a Publish/Subscribe Push mechanism.
-
Publish/Subscribe Push
The Publish/Subscribe Push mechanism allows a client to subscribe to a topic and receive messages published on that topic. The Publish/Subscribe mechanism is supported by two procedures:
- subscription management: the client creates a new subscription and, in general, a corresponding message queue is allocated to collect messages related to the requested subscription topic. (see SubscriptionManagement interface)
- message consumption: the client consumes the messages from the message queue for the subscription topic. (see Publication interface)
The Publish/Subscribe mechanism may be implemented using AMQP to support coordination between two ASM Support Systems to exchange the near real-time updates of their ASM data.
-
Request/Reply
The Synchronous Request/Reply mechanism allows a client to request and to receive ASM data. It is used to retrieve the current ASM data of the other system either on the initial connection between two established ASM Support Systems or to re-establish synchronisation potentially after one has experienced downtime or due to network failures.
This Request/Reply mechanism may also be implemented by clients that are interested in a small subset of the ASMtoASM service where the data is subject to change infrequently or when using latest data is not crucial.
As two ASM Support Systems may not be fully synchronised all of the time, Request/Reply mechanism is implemented to re-establish synchronisation by exchanging the latest snapshot of the available ASM data. The systems are synchronised again and they can continue to be updated by using the Publish/Subscribe mechanism.
-
Filtering
To avoid unnecessary processing of irrelevant messages on the client side some message filtering functionalities may be implemented by both Request/Reply and Publish/Subscribe mechanisms through a combination of the following filter criteria for each ASMtoASM Service Interface:
o Activity,
o Airspace,
o Change Period,
o Geometry,
o Interested Interval,
o Mission.
When using the Publish/Subscribe mechanism, the External User has to set the required message filtering criteria when creating the subscription so that the messages for each type of subscriptions can be filtered before they are published to the message queues allocated to that External User.
The Request/Reply mechanism requires the External Users to set the required message filtering criteria when generating the request.
To allow ASM data requests to be aligned with subscriptions a single abstract Filter definition is available for use by both mechanisms, in that the SubscriptionCreationRequest message is an extension to the basic FilteredRequest message as shown in the diagram below. Consequently, the same Filters can be used when requesting ASM data and subscribing for ASM data to ensure the same data is retrieved via both mechanisms.
Specific filter implementations that have been deemed necessary for the services to be usable are defined in this document. The available filters may be extended beyond those specified in any implementation of this service. This allows for custom filtering to be defined by a provider of this service while still conforming to the interfaces defined in this document. It has to be noted that only the filters defined in the document are to be relied upon in order to create an implementation independent client.
The FilteredRequest is used throughout the service interfaces and is extended to form the SubscriptionCreationRequest. The FilteredRequest defines a series of Filters which will be applied using the logical OR operator. Filters may be combined with a logical “AND” using the “AndFilter”.
In the specification document, each service interface defines in detail the Filters it accepts.
ASM-INTF-FIL-010: All ASMtoASM service interfaces specified in this document shall implement a filtering functionality both for Synchronous Request/Reply and Publish/Subscribe Push application message exchange patterns.
Functionality
Description
This functionality allows for creation, starting, stopping and deletion of subscriptions to consume data from the service.
Real World Effect
Creation, starting, stopping and deletion of subscriptions
Description
This functionality enables the management of updates based on subscriptions by External Users.
Real World Effect
Notifying an External User of a change in the data according to the subscription topics that have been subscribed to.
Description
This functionality allows for the creation, modification and retrieval of long term planning data held within the ASM Support System.
Real World Effect
Creation of an Event, Update of an Event and submission of a Request for a List of Events.
Description
This functionality allows for retrieval of airspace structures and activity data from within the ASM Support System by External Users.
Real World Effect
Obtaining access to static data and activity data by External Users from within the ASM Support System.
Description
This functionality enables the creation, modification and retrieval of bookings, including details of conflicts between different bookings within the ASM Support System by External Users.
Real World Effect
Creation of a Booking, Update of a booking, obtaining access to Booking information, obtaining access to the actions that can be performed by the actor and obtaining access to the history of all actions that have been performed on a Booking.
Description
This functionality allows access to the Booking conflict information from within the ASM Support System.
Real World Effect
Obtaining access to booking conflict data from within the ASM Support System.
Description
This functionality allows for the creation, modification and retrieval of missions held within the ASM Support System by External Users.
Real World Effect
Creation of a Mission, Update of a Mission and obtaining access to the Missions information from within the ASM Support System.
Description
This functionality enables the retrieval and handling of proposals held within the ASM Support System by External Users.
Real World Effect
Creation of a Proposal, obtaining access to the Proposal information and acceptance or rejection of the Proposal.
Description
This functionality enables the retrieval of activation data held within the ASM Support System by External Users.
Real World Effect
Obtaining access to the activation data held within the ASM Support System by External Users.
Access and Use
Quality of Service
There are a number of non-functional requirements which need to be taken into account when considering the exchange of ASM data, as they are relevant to any system development. These type of requirements typically are concerned with characteristics such as availability and performance, and can be used as measurements of a system’s efficiency, effectiveness and continued viability when comparing actual performance with expected performance.
In order for these non-functional requirements to be defined as concrete testable requirements, significant analysis of the entire environment would need to be carried out to ascertain the basic nature of the infrastructure and the predicted user activity.
The definition of these non-functional requirements is out of scope of this document.
A non-exhaustive list of some of the features which might directly influence the non-functional aspects is given below.
· Predicted load (typical and extreme)
· Number of concurrent users (typical and extreme)
· Available network bandwidth
· Hardware specifications
· Security policy restrictions
Some of the associated non-functional requirements which need to consequently be considered are described in the following section.
A definition of acceptable levels of downtime has to be agreed between all interested parties. Whilst the ideal goal is a consistent 24/7/365 service provision, this is not always a realistic target due to the potential need for disaster recovery, maintenance or upgrades. As well as agreeing on the acceptable levels of (non)availability, contingency plans need also to be agreed in order that operations can continue seamlessly and safely when any downtime is required.
Managing the availability is directly linked to two other non-functional aspects which are to be assessed to determine the effectiveness of the system:
· Recovery / recoverability (e.g. mean time to recovery - MTTR)
· Reliability (e.g. mean time between failures - MTBF)
Monitoring and measuring these provides a means to identify where improvements are required in terms of stability or quality.
A predictable pattern of resource consumption per load has to be achieved in order that scalability can be predicted for periods of unusually heavy act.
The system has to allow for extensibility whilst remaining interoperable between two major versions. Incompatibility between software versions is inevitable as systems mature and improve over their lifetime, but it is a priority to minimise disruption between upgrades. Maintaining a stable interface between two major versions would allow the wider user community the opportunity to upgrade their software at the most suitable time, rather than enforcing the need for updating as soon as a new release becomes available.
Response time has to be a key priority in assessing the effectiveness of a system. Performance can only really be gauged by identifying some level of typical usage, and agreeing acceptable response times for that degree of usage. Similarly, some level of maximum expected usage will be agreed and acceptable elapsed response times defined.
Information being managed within an ASM Support System is highly sensitive and is to be managed with utmost care in terms of security and privacy. Mechanisms and strategies for achieving this are numerous and various in nature. Whilst considering how best to achieve maximum levels of security, it is important also to consider that technology choices will not be so bespoke or idiosyncratic that they prevent potential future users from taking up the system.
Validation
Validation competed.
Concepts
Concepts
Abbreviations
|
Abbreviation |
Term |
|
A/B |
Air Base |
|
ACC |
Area Control Centre |
|
AIP |
Aeronautical Information Publication |
|
ADEP |
Aerodrome of Departure |
|
ADES |
Aerodrome of Destination |
|
AF |
ATM Functionality (in the PCP regulation) |
|
AFUA |
Advanced Flexible Use of Airspace |
|
AIRM |
ATM Information Reference Model |
|
AIXM |
Aeronautical Information Exchange Model |
|
AMQP |
Advanced Message Queuing Protocol |
|
AO ARES |
Aircraft Operator Airspace Reservation/Restriction |
|
ASM |
Airspace Management |
|
ATC |
Air Traffic Control |
|
ATFCM |
Air Traffic Flow and Capacity Management |
|
ATM |
Air Traffic Management |
|
ATS |
Air Traffic Services |
|
AUP/UUP |
Airspace Use Plan / Updated Airspace Use Plan |
|
B2B |
Business-to-Business |
|
CBA |
Cross Border Area |
|
CBO |
Cross Border Operations |
|
CDM |
Collaborative Decision Making |
|
CDR |
Conditional Route |
|
CR |
Change Request |
|
eAMI |
Electronic ASM Information message |
|
EC |
European Commission |
|
ERAF |
EUROCONTROL Advisory Framework |
|
EU |
European Union |
|
FAB |
Functional Airspace Block |
|
FBZ |
Flight Plan Buffer Zone |
|
ENV |
Environment |
|
FDPS |
Flight Data Processing System |
|
FF |
Fire and Forget |
|
FL |
Flight Level |
|
FMP |
Flow Management Position |
|
FUA |
Flexible Use of Airspace |
|
GML |
Geographical Markup Language |
|
HTTP |
Hypertext Transport Protocol |
|
ICAO |
International Civil Aviation Organisation |
|
ID |
Identifier |
|
IP |
Internet Protocol |
|
MTBF |
Mean Time Between Failures |
|
MTTR |
Mean Time To Recovery |
|
NOP |
Network Operations Plan |
|
NM |
Network Manager |
|
NOTAM |
Notice to Airmen |
|
PCP |
Pilot Common Project (EC Regulation) |
|
POC |
Point of Contact |
|
ERNIP |
European Route Network Improvement Plan |
|
SES |
Single European Sky |
|
SOAP |
Simple Object Access Protocol |
|
sR/R |
Synchronous Request Reply |
|
SWIM |
System Wide Information Management |
|
TI |
Technical Infrastructure |
|
TRA |
Temporary Reserved Area |
|
TSA |
Temporary Segregated Area |
|
UUID |
Universally Unique Identifier |
|
UOM |
Unit of Measurement |
|
WS |
Web Service |
|
XML |
Extensible Markup Language |
|
WSDL |
Web Services Description Language |
Information
Information Definition
The information definition is described in section 2.7 of 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 (EUROCONTROL-SPEC-170).
The semantic correspondence of the Information Definition with the semantics of the ATM Information Reference Model (AIRM) is established in ANNEX F – Semantic Correspondence Report of EUROCONTROL-SPEC-170.
AIRM Conformant
True
Data Structures
Exchange Schema
Schema Language
N/A
Technical
Interfaces
Interface role
The Subscription Management interface allows the management of subscriptions to the other services by External Users. External Users are able to receive the information of their interest generated by the ASM Support Systems and provided via the interfaces. Each interface applies filtering options in order to ensure data provision aligned with the requirements of the External User.
The interface allows for the creation and deletion of subscriptions to consume data from all other ASMtoASM service interfaces. A client may create a subscription to a single topic with each request but only one subscription per topic may be created at a time. In response the client will receive the name of an AMQP message queue. The name can then be supplied when creating subscriptions for additional topics to use the same queue. The client can consume the messages from the queue with the given name.
Figure 7 in Section 2.4.2.1 provides an overview of the Subscription Management interface
The elements in the data model are described in full detail in section 2.5.
Information Exchange Flow
The diagram in Section 2.4.2.2 presents the information exchange flow for the Subscription Management interface.
Interface Functions
The Service interface performs the following functions:
o Creating a Subscription introduces a new Subscription into the ASM Support System.
o Starting a Subscription starts an existing Subscription in the ASM Support System.
o Stopping a Subscription stops an existing Subscription in the ASM Support System.
o Deleting a Subscription allows for deletion of an existing Subscription.
ASM-INTF-SUBS-010: ASMtoASM Service shall be supported by the Subscription Management interface to manage the subscriptions
ASM-INTF-SUBS-020: The Subscription Management interface shall support the following operations:
o createSubscription,
o startSubscription,
o stopSubscription,
o deleteSubscription
PROVIDER_SIDE_INTERFACE
SWIM_TI_YP_1_0_WS_SOAP
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
This operation is intended to create a subscription in the ASM Support System in response to a request from an External User. As a result, a subscription is either created in the local ASM Support System and the External User is notified, or a subscription is not created and an appropriate error message is transmitted to the External User.
It is down to the implementation as to whether or not subscriptions need to be remade at any other subsequent connection.
Associated messages
ASM-INTF-SUBS-030: The createSubscription operation shall receive and process the SubscriptionCreationRequest message from an External User.
ASM-INTF-SUBS-040: If no queue name is provided in the SubscriptionCreationRequest message the service shall assign a queue name to the External User subscription.
ASM-INTF-SUBS-050: If an active queue name is provided in the SubscriptionCreationRequest message the service shall reuse this queue name for the External User subscription.
Note: The queue name allows for connection to an Advanced Message Queuing Protocol (AMQP) message queue.
ASM-INTF-SUBS-070: The service shall apply the filters defined in the SubscriptionCreationRequest to all data notified via the AMQP message queue.
ASM-INTF-SUBS-080: The createSubscription operation shall validate the SubscriptionCreationRequest message against the following criteria which must be met:
o All mandatory data for SubscriptionCreationRequest message are provided
o The requestor does not have an existing PAUSED or ACTIVE subscription for the same topic.
o If a queue name is set in the SubscriptionCreationRequest message it must match an existing queue name belonging to the requestor.
o The filters provided in the SubscriptionCreationRequest message must be applicable to the topic being subscribed for. Acceptable filters are defined by the query operation in this document that maps to the subscription topic.
ASM-INTF-SUBS-090: If the subscription request is valid, the createSubscription operation shall transmit the details of the newly created subscription, including the name of the AMQP queue to be used, in the SubscriptionCreationReply message to the requesting External User.
ASM-INTF-SUBS-100: The subscription shall always be created in the ‘PAUSED’ state.
ASM-INTF-SUBS-110: If the request or the resulting subscription is not valid, the createSubscription operation shall transmit an appropriate error in the SubscriptionCreationReply message to the requesting External User.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
This operation is intended to start a subscription process in the ASM Support System in response to a request from an External User. As a result, a subscription process is either started in the local ASM Support System and the External User starts receiving subscribed data, or a subscription is not started and an appropriate error message is transmitted to the External User.
Associated messages
ASM-INTF-SUBS-120: The startSubscription operation shall receive and process the SubscriptionCreationRequest message from an External User.
ASM-INTF-SUBS-130: The startSubscription operation shall validate the SubscriptionStartRequest message against the following criteria which must be met:
o All mandatory data for SubscriptionStartRequest message are provided
o The identified subscription to be started must belong to the requestor.
o The identified subscription to be started must be PAUSED.
ASM-INTF-SUBS-140: If the request is valid, the startSubscription operation shall return the SubscriptionStartReply message to the requesting External User.
ASM-INTF-SUBS-150: The SubscriptionStartReply message shall contain the details of the subscription, including the name of the queue to be used and the state which will be ‘ACTIVE’.
ASM-INTF-SUBS-160: If the request is not valid, the startSubscription operation shall transmit an appropriate error in the SubscriptionStartReply message to the requesting External User.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
This operation is intended to stop a subscription process in the ASM Support System in response to a request from an External User. As a result, a subscription process is either stopped in the local ASM Support System and the External User stops receiving subscribed data, or a subscription is not stopped and an appropriate error message is transmitted to the External User.
Associated messages
ASM-INTF-SUBS-170: The stopSubscription operation shall receive and process the SubscriptionStopRequest message from an External User.
ASM-INTF-SUBS-180: The stopSubscription operation shall validate the SubscriptionStopRequest message against the following criteria which must be met:
o All mandatory data for SubscriptionStopRequest message are provided
o The identified subscription to be stopped must belong to the requestor.
o The identified subscription to be stopped must be ACTIVE.
ASM-INTF-SUBS-190: If the request is valid, the stopSubscription operation shall return the SubscriptionStopReply message to the requesting External User.
ASM-INTF-SUBS-200: The SubscriptionStopReply message shall contain the details of the subscription, including the name of the queue to be used and the state which will be ‘PAUSED’.
ASM-INTF-SUBS-210: If the request is not valid, the stopSubscription operation shall transmit an appropriate error in the SubscriptionStopReply message to the requesting External User.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
This operation is intended to delete a subscription in the ASM Support System in response to a request from an External User. As a result, a subscription is either deleted in the local ASM Support System and the External User is notified, or a subscription is not deleted and an appropriate error message is transmitted to the External User. If a subscription is deleted and no other subscriptions reference its message queue then the queue will be deleted.
Associated messages
ASM-INTF-SUBS-220: The deleteSubscription operation shall receive and process the SubscriptionDeletionRequest message from an External User.
ASM-INTF-SUBS-230: The deleteSubscription operation shall validate the SubscriptionDeletionRequest message against the following criteria which must be met:
o All mandatory data for SubscriptionDeletionRequest message are provided
o The identified subscription to be deleted must belong to the requestor.
ASM-INTF-SUBS-240: If the request is valid, the deleteSubscription operation shall return confirmation that the subscription has been deleted in the SubscriptionDeletionReply message to the requesting External User.
ASM-INTF-SUBS-250: If the request is valid and the subscription’s queue is no longer in use by any other subscriptions, the queue shall be deleted.
ASM-INTF-SUBS-260: If the request is not valid, the deleteSubscription operation shall transmit an appropriate error in the SubscriptionDeletionReply message to the requesting External User.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
Endpoints
Interface Binding Description Overview
N/A
Behaviour
Interface role
The Publication interface enables the management of updates based on subscriptions by External Users. External Users are able to receive notifications of updates of the information of their interest generated by the ASM Support Systems. Each interface applies filtering options in order to ensure data provision aligned with the requirements of the External User.
This interface publishes the data that would otherwise be directly requested from other interfaces. As such the data coming via this interface is contained within the notification messages defined in section 2.7.3 Interface Messages and containing data items described by each of the other interfaces. As a result, this interface does not define its own data model.
Information Exchange Flow
The following diagram presents the information exchange flow for the Publication interface. The diagram shows a change occurring within the ASM Support System, the changed data being passed to the Publication interface which applies the filters related to each subscription and the relevant data being published to subscribed consumers.
Figure 10 in Section 2.4.3.2 depicts the Publication interface information exchange flow
Interface Functions
The interface performs the following function:
- Notifying a change in the data according to the subscription topics that have been subscribed to.
ASM-INTF-PUB-010: ASMtoASM Service shall be supported by the Publication interface to manage the updates.
ASM-INTF-PUB-020: The Publication interface shall support the following operations:
- notifyStaticData
- notifyActivityData
- notifyBooking
- notifyBookingAction
- notifyBookingConflict
- notifyMission
- notifyProposal
- notifyEvent
- notifyActivation
ASM-INTF-PUB-030: Any data item considered for publication shall be published if:
- the data item was of interest to the subscriber before the change according to the filter defined at the time of subscription, or
- the data item is of interest to the subscriber post the change according to the filter defined at the time of subscription.
ASM-INTF-PUB-040: All notifications shall contain the full definition of the changed data item.
CONSUMER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
This operation is intended to notify an External User of a change in the definition of static data.
Associated messages
ASM-INTF-PUB-050: Any change to the definition of static data within the ASM Support System shall be considered for publication via an AirspaceNotification message.
Note: The definition of this message can be found in section 2.7.3 Interface Messages.
This operation is intended to notify an External User of a change in the definition of activity data.
Associated messages
ASM-INTF-PUB-060: Any change to the definition of activity data within the ASM Support System shall be considered for publication via an ActivityDataNotification message.
Note: The definition of this message can be found in section 2.7.3 Interface Messages.
This operation is intended to notify an External User of a change in the definition of an existing booking.
Associated messages
ASM-INTF-PUB-070: Any change to the definition of a booking within the ASM Support System shall be considered for publication via a BookingNotification message.
Note: The definition of this message can be found in section 2.7.3 Interface Messages.
This operation is intended to notify an External User of an action that has been performed to an existing booking.
Associated messages
ASM-INTF-PUB-080: Any change to the definition of action data within the ASM Support System shall be considered for publication via a BookingActionNotification message.
Note: The definition of this message can be found in section 2.7.3 Interface Messages.
This operation is intended to notify an External User of conflict data related to an existing booking.
Associated messages
ASM-INTF-PUB-090: Any change to the definition of booking conflict data within the ASM Support System shall be considered for publication via a BookingConflictNotification message.
Note: The definition of this message can be found in section 2.7.3 Interface Messages.
This operation is intended to notify an External User of a change in the definition of mission data.
Associated messagews
ASM-INTF-PUB-100: Any change to the definition of mission data within the ASM Support System shall be considered for publication via a MissionNotification message.
Note: The definition of this message can be found in section 2.7.3 Interface Messages.
This operation is intended to notify an External User of a change in the definition of proposal data.
Associated messages
ASM-INTF-PUB-110: Any change to the definition of proposal data within the ASM Support System shall be considered for publication via a BookingProposalNotification message.
Note: The definition of this message can be found in section 2.7.3 Interface Messages.
This operation is intended to notify an External User of a change in the definition of event data.
Associated messages
ASM-INTF-PUB-120: Any change to the definition of event data within the ASM Support System shall be considered for publication via an EventNotification message.
Note: The definition of this message can be found in section 2.7.3 Interface Messages.
This operation is intended to notify an External User of a change in the definition of activation data.
Associated messages
ASM-INTF-PUB-130: Any change to the definition of activation data within the ASM Support System shall be considered for publication via an ActivationNotification message.
Note: The definition of this message can be found in section 2.7.3 Interface Messages.
Endpoints
Interface Binding Description Overview
N/A
Behaviour
Interface role
The Long Term Planning interface allows for the creation, modification and retrieval of long term planning data held within the ASM Support System. It is not foreseen that one ASM Support System may create long term planning in another ASM Support System and so the creation and update mechanisms may be limited to External Users acting as a user of the ASM Support System under the External ASM User - ASM Support System use of the service case.
Figure 12 in Section 2.4.4.1 provides an overview of the Long Term Planning interface
Information Exchange Flow
Figure 13 in Section 2.4.4.2 depicts the information exchange flow for the Long Term Planning interface.
Interface Functions
The interface performs the following functions:
- Creating an Event - introduces a new Event into the ASM Support System
- Updating an Event - updates an existing Event in the ASM Support System
- Requesting a List of Events - allows access to the Event information from within the ASM Support System
ASM-INTF-LTPL-010: ASMtoASM Service should be supported by the Long Term Planning interface to manage the events.
ASM-INTF-LTPL-020: The Long Term Planning interface shall support the following operations:
- createEvent,
- updateEvent,
- queryEventList.
CONSUMER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
This operation is intended to introduce a new Event into the ASM Support System.
Associated messages
ASM-INTF-LTPL-030: The createEvent operation shall receive and process the EventCreationRequest message from an External User.
ASM-INTF-LTPL-040: If the event request is valid, the createEvent operation shall transmit the newly created event in the EventReply message to the requesting External Users.
ASM-INTF-LTPL-050: If for any reason the request or the resulting event is not valid, the createEvent operation shall transmit an appropriate error in the EventReply message to the requesting External Users.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
This operation is intended to update an existing Event in the ASM Support System.
Associated messages
ASM-INTF-LTPL-060: The updateEvent operation shall receive and process the EventUpdateRequest message from an External Users.
ASM-INTF-LTPL-070: If the event update is valid, the updateEvent operation shall transmit the updated event in the EventReply message to the requesting External User.
ASM-INTF-LTPL-080: If for any reason the request or the resulting updated event is not valid, the updateEvent operation shall transmit an appropriate error in the EventReply message to the requesting External User.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
This operation is intended to allow access to the Event information from within the ASM Support System.
Associated messages
ASM-INTF-LTPL-090: The queryEventList operation shall receive and process the EventListRequest message from an External Users.
ASM-INTF-LTPL-100: If the event list request is valid, the queryEventList operation shall transmit the matching list of events in the EventListReply message to the requesting External User.
ASM-INTF-LTPL-110: If for any reason the request is not valid, the queryBookingList operation shall transmit an appropriate error in the EventListReply message to the requesting External Users.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
Endpoints
Interface Binding Description Overview
N/A
Behaviour
Interface role
The Local Airspace Structure interface allows for retrieval of airspace structures and activity data from within the ASM Support System by External Users.
Local ASM Support Systems maintain a local data base that contains national airspace structures. The interface allows External Users to obtain the definitions of the airspace structures, provided by the providing system in accordance with the provider requirements, as well as activity data, in order to follow their status and the reservations associated to them.
Figure 15 in Section 2.4.5.1 provides an overview of the Local Airspace Structure interface
The elements in the data model are described in full detail in section 2.7.3 Interface Messages.
Information Exchange Flow
Figure 16 in Section 2.4.5.2 depicts the information exchange flow for the Local Airspace Structure interface.
Interface Functions
The interface performs the following functions:
- Requesting Static Data - allows access to static data from within the ASM Support System
- Requesting Activity Data – allows access to activity data from within the ASM Support System
ASM-INTF-LAS-010: ASMtoASM Service shall be supported by the Local Airspace Structure interface to manage the access to local airspace static and activity data.
ASM-INTF-LAS-020: The LocalAirspaceStructure interface shall support the following operations:
- retrieveAirspace
- queryActivityDataList
CONSUMER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
This operation is intended to manage the access to static data from the ASM Support System.
Associated messages
ASM-INTF-LAS-030: The queryAirspaceList operation shall receive and process the FilteredRequest message from an External User.
ASM-INTF-LAS-040: If the request is valid, the queryAirspaceList operation shall transmit the matching static data in the AirspaceListReply message to the requesting External User.
ASM-INTF-LAS-050: If for any reason the request is not valid, the queryAirspaceList operation shall transmit an appropriate error in the AirspaceListReply message to the requesting External User.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
This operation is intended to manage the access to activity data from the ASM Support System.
ASM-INTF-LAS-060: The queryActivityDataList operation shall receive and process the ActivityDataListRequest message from an External User.
ASM-INTF-LAS-070: If the activity data list request is valid, the queryActivityDataList operation shall transmit the matching activity data list in the ActivityDataListReply message to the requesting External User.
ASM-INTF-LAS-080: If for any reason the request is not valid, the queryActivityDataList operation shall transmit an appropriate error in the ActivityDataListReply message to the requesting External User.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
Endpoints
Interface Binding Description Overview
N/A
Behaviour
Interface role
Booking is an interface that enables the creation, modification and retrieval of bookings, including details of conflicts between different bookings within the ASM Support System by External Users. The interface allows for continuous updates in real time of Booking information among authorised ASM Support Systems/External Users in order to enhance cross border coordination based on the most recent information.
The interface also enables booking of airspace structures across national borders; airspace users are able to book foreign airspace using their local ASM Support System. The process of a foreign booking follows the ASM process defined in dedicated LoAs between States.
The creation and modification of bookings is supported through the provision of ‘Actions’ by the interface. The Actions describe the allowed modifications that a user may take on a specific booking. Actions are subject to change based on the state of a booking and the current time.
Figure 18 in Section 2.4.6.1 provides an overview of the Booking interface
Information Exchange Flow
Figure 19 in Section 2.4.6.2 depicts the Booking interface information exchange flow
Interface Functions
The interface performs the following functions:
- Creating a Booking introduces a new Booking into the ASM Support System to be approved to be incorporated into the plan.
- Updating a Booking updates an existing Booking in the ASM Support System potentially as a result of a CDM process or simply to update the plan to reflect changes to planned activities.
- Requesting Booking List allows access to the Booking information from within the ASM Support System to allow for CDM processes.
- Requesting Actions allows access to the Actions that can performed by the actor. Identifying where they may contribute to the CDM process within the ASM Support System and which Airspace Reservation they can update to better inform the plan.
- Requesting History allows access to the history of all actions that have been performed on a Booking.
ASM-INTF-ARES-010: ASMtoASM Service shall be supported by the Booking interface to manage the reservations
ASM-INTF-ARES-020: The Booking interface shall implement synchronous Request-Reply application message exchange pattern.
ASM-INTF-ARES-030: The Booking interface shall support the following operations:
- createBooking,
- updateBooking,
- queryBookingList
- queryActionList
- queryBookingHistoryList
CONSUMER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
This operation is intended to introduce a new booking in the ASM Support System in response to a request from an External User. As a result, the new booking is either created in the local ASM Support System and the External User is notified, or the booking is not created and an appropriate error message is transmitted to the External User.
Associated messages
ASM-INTF-ARES-040: The createBooking operation shall receive and process the BookingCreationRequest message from an External User.
ASM-INTF-ARES-050: The createBooking operation shall validate the BookingCreationRequest message against the following criteria which must be met:
- All mandatory data for the BookingCreationRequest message are provided
- The booking ID must be null/not set
- The start date and time of all AirspaceReservations must be in the future
- The end date and time of an AirspaceReservation must be after its start date and time
- The External User must have permission to book the airspace structures as defined by the ActivityData.
- The entire booked period must be within the life time of all booked airspace structures
- The booked flight levels must be within or equal to the flight level bounds of the airspace structures
- The booked lower flight level of an airspace structure must be below the booked upper flight level of the airspace structure
- The selected responsible unit must be common to all booked airspace structures as defined by the ActivityData.
ASM-INTF-ARES-060: If the booking is valid, the createBooking operation shall transmit the newly created booking in the BookingReply message to the requesting External User.
ASM-INTF-ARES-070: If the request or the resulting booking is not valid, the createBooking operation shall transmit an appropriate error in the BookingReply message to the requesting External User.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
This operation is intended to introduce updates to an existing booking in the ASM Support System in response to a request from an External User. As a result, the booking is either updated in the local ASM Support System and the External User is notified, or the booking is not updated and an appropriate error message is transmitted to the External User.
Associated messages
ASM-INTF-ARES-080: The updateBooking operation shall receive and process the BookingUpdateRequest message from an External User.
ASM-INTF-ARES-090: The updateBooking operation shall validate the BookingUpdateRequest message against the following criteria which must be met:
- All mandatory data for the BookingCreationRequest message are provided
- The booking ID must be set
- The lastChangeTime in the booking must match that held by the service
- The start date and time of all AirspaceReservations must be in the future; if the booking is active the start dates and times must match the original start dates and times and the end time should be in the future
- The end date and time of an AirspaceReservation must be after its start date and time
- The External User must have permission to book the airspace structures as defined by the ActivityData
- The entire booked period must be within the life time of all booked airspace structures
- The booked flight levels must be within or equal to the flight level bounds of the airspace structures
- The booked lower flight level of an airspace structure must be below the booked upper flight level of the airspace structure
- The selected responsible unit must be common to all booked airspace structures as defined by the ActivityData
ASM-INTF-ARES-100: If the booking update is valid, the updateBooking operation shall transmit the updated booking in the BookingReply message to the requesting External User.
ASM-INTF-ARES-110: If the request or the resulting updated booking is not valid, the updateBooking operation shall transmit an appropriate error in the BookingReply message to the requesting External User.
ASM-INTF-ARES-120: An updateBookingRequest should be rejected by the service if the user performing the update does not have the appropriate actions matching their update.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
This operation is intended to introduce a query for the list of bookings in the ASM Support System in response to a request from an External User. As a result, the list of bookings is either transmitted to the External User or not, and an appropriate error message is transmitted to the External User.
Associated messages
ASM-INTF-ARES-130: The queryBookingList operation shall receive and process the FilteredRequest message from an External User.
ASM-INTF-ARES-140: The queryBookingList operation shall validate the FilteredRequest message against the following criteria which must be met:
- All mandatory data for FilteredRequest message are provided
ASM-INTF-ARES-150: If the request is valid, the queryBookingList operation shall transmit the filtered list of bookings in the BookingListReply message to the requesting External User.
ASM-INTF-ARES-160: If the request is not valid, the queryBookingList operation shall transmit an appropriate error in the BookingListReply message to the requesting External User.
ASM-INTF-ARES-170: The queryBookingList operation shall accept any combination of the following filters in the FilteredRequest message:
- ActivityIDFilter
- ChangePeriodFilter
- InterestedIntervalFilter
- AndFilter
ASM-INTF-ARES-180: The queryBookingList operation should accept any combination of the following filters in the FilteredRequest message:
- AirspaceIDFilter
- GeometryFilter
- MissionIDFilter
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
This operation is intended to introduce a query for the list of actions in the ASM Support System in response to a request from an External User. As a result, the list of actions is either transmitted to the External User or not, and an appropriate error message is transmitted to the External User.
Associated messages
ASM-INTF-ARES-190: The queryActionList operation shall receive and process the FilteredRequest message from an External User.
ASM-INTF-ARES-200: The queryActionList operation shall validate the FilteredRequest message against the following criteria which must be met:
- All mandatory data for the FilteredRequest message are provided
ASM-INTF-ARES-210: If the request is valid, the queryActionList operation shall transmit the list of actions in the BookingActionListReply message to the requesting External User.
ASM-INTF-ARES-220: If the request is not valid, the queryActionList operation shall transmit an appropriate error in the BookingActionListReply message to the requesting External User.
ASM-INTF-ARES-230: The queryActionList operation shall accept the following filter in the FilteredRequest:
- ActivityIDFilter
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
This operation is intended to introduce a query for the list of history of actions performed on a booking in the ASM Support System in response to a request from an External User. As a result, the list of history of actions performed on a booking is either transmitted to the External User or not, and an appropriate error message is transmitted to the External User.
Associated messages
ASM-INTF-ARES-240: The queryBookingHistoryList operation shall receive and process the FilteredRequest message from an External User.
ASM-INTF-ARES-250: The queryBookingHistoryList operation shall validate the FilteredRequest message against the following criteria which must be met:
- All mandatory data for the FilteredRequest message are provided
ASM-INTF-ARES-260: If the request is valid, the queryBookingHistoryList operation shall transmit the complete list of history of actions performed on a booking in the BookingHistoryListReply message to the requesting External User.
ASM-INTF-ARES-270: If the request is not valid, the queryBookingHistoryList operation shall transmit an appropriate error in the BookingHistoryListReply message to the requesting External User.
ASM-INTF-ARES-280: The queryBookingHistoryList operation shall accept the following filter in the FilteredRequest message:
- ActivityIDFilter
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
Endpoints
Interface Binding Description Overview
N/A
Behaviour
Interface role
Requesting Conflict List allows access to the Booking conflict information from within the ASM Support System to enhance CDM processes.
Figure 21 in Section 2.4.7.1 provides an overview of the Booking conflicts interface
The elements in the data model are described in full detail in section 2.7.3 Interface Messages.
Information Exchange Flow
Figure 22 in Section 2.4.7.2 depicts the information exchange flow for the Local Airspace Structure interface.
Interface Functions
The interface performs the following functions:
- Requesting booking conflict data – allows access to booking conflict data from within the ASM Support System
ASM-INTF-CON-010: ASMtoASM Service should be supported by the Booking Conflicts interface to manage booking conflicts.
ASM-INTF-CON-020: The Booking Conflicts interface shall support the following operation:
- queryConflictList
CONSUMER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
This operation is intended to introduce a query for the list of conflicts between bookings in the ASM Support System in response to a request from an External User. As a result, the list of conflicts between bookings is either transmitted to the External User or not, and an appropriate error message is transmitted to the External User.
ASM-INTF-CON-030: The queryConflictList operation shall receive and process the FilteredRequest message from an External User.
ASM-INTF-CON-040: The queryConflictList operation shall validate the FilteredRequest message against the following criteria which must be met:
- All mandatory data for the FilteredRequest message are provided
ASM-INTF-CON-050: If the request is valid, the queryConflictList operation shall transmit the list of conflicts in the BookingConflictListReply message to the requesting External User.
ASM-INTF-CON-060: If the request is not valid, the queryConflictList operation shall transmit an appropriate error in the BookingConflictListReply message to the requesting External User.
ASM-INTF-CON-070: The queryConflictList operation shall accept any combination of the following filters in the FilteredRequest:
- ActivityIDFilter
- AndFilter
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
Endpoints
Interface Binding Description Overview
N/A
Behaviour
Interface role
The Mission interface allows for the creation, modification and retrieval of missions held within the ASM Support System by External Users. This interface allows exchange of mission information between host and foreign ASM Support Systems.
Figure 24 in Section 2.4.8.1 provides an overview of the Mission interface.
Information Exchange Flow
Figure 25 in Section 2.4.8.2 depicts the Mission interface information exchange flow
Interface Functions
The interface performs the following functions:
- Creating a Mission - introduces a new Mission into the ASM Support System to be approved to be incorporated into the plan.
- Updating a Mission - updates an existing Mission in the ASM Support System potentially as a result of a CDM process or simply to update the plan to reflect real world changes to planned activities
- Requesting Missions - allows access to the Missions information from within the ASM Support System to allow for CDM processes.
ASM-INTF-MIS-010: ASMtoASM Service should be supported by the Mission interface to manage the exchange of mission information.
ASM-INTF-MIS-020: The Mission interface shall support the following operation:
- createMission,
- updateMission,
- queryMissionList
CONSUMER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
ASM-INTF-MIS-030: The createMission operation shall receive and process the MissionCreationRequest message from an External User.
ASM-INTF-MIS-040: If the mission is valid, the createMission operation shall transmit the newly created mission in the MissionReply message to the requesting External Users.
ASM-INTF-MIS-050: If for any reason the request or the resulting mission is not valid, the createMission operation shall transmit an appropriate error in the MissionReply message to the requesting External Users.
Note: The definition of these can be found in section 2.7.3 Interface Messages.
ASM-INTF-MIS-060: The updateMission operation shall receive and process the MissionUpdateRequest message from an External User.
ASM-INTF-MIS-070: If the mission update is valid, the updateMission operation shall transmit the updated mission in the MissionReply message to the requesting External Users.
ASM-INTF-MIS-080: If for any reason the request or the resulting updated mission is not valid, the updateMission operation shall transmit an appropriate error in the MissionReply message to the requesting External Users.
ASM-INTF-MIS-090: A MissionUpdateRequest should be rejected by the service if the user performing the update does not have the appropriate actions matching their update.
Note: The definition of these can be found in section 2.7.3 Interface Messages.
ASM-INTF-MIS-100: The queryMissionList operation shall receive and process the MissionListRequest message from an External User.
ASM-INTF-MIS-110: If the mission list request is valid, the queryMissionList operation shall transmit the list of missions in the MissionListReply message to the requesting External Users.
ASM-INTF-MIS-120: If for any reason the request is not valid, the queryMissionList operation shall transmit an appropriate error in the MissionListReply message to the requesting External Users.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
Endpoints
Interface Binding Description Overview
N/A
Behaviour
Interface role
The Airspace Negotiation interface enables the retrieval and handling of proposals held within the ASM Support System by External Users.
A proposal refers to a specific reservation and effectively re-defines a subset of the reservation data. The Negotiation interface enables a proposal to be accepted or rejected as per the actions accessible through the service.
The Negotiation interface allows users managing the airspace to make proposals to booking requests introduced by foreign airspace requesters. The proposals could address the FLs, times, or even different area. These proposals could be accepted or rejected.
Figure 27 in Section 2.4.9.1 provides an overview of the Airspace negotiation interface
Information Exchange Flow
Figure 28 in Section 2.4.9.2 depicts the Airspace negotiation interface information exchange flow.
Interface Functions
The interface performs the following functions:
- Creating a Proposal - introduces a new Proposal into the ASM Support System.
- Requesting Proposal List - allows access to the Proposal information from within the ASM Support System to allow for CDM processes.
- Handling Proposals – accepts or rejects the Proposal
ASM-INTF-NEG-010: ASMtoASM Service should be supported by the Airspace Negotiation interface to manage the reservations.
ASM-INTF-NEG-020: The AirspaceNegotiation interface shall support the following operations:
- createBookingProposal,
- queryBookingProposalList
- handleBookingProposal
CONSUMER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
ASM-INTF-NEG-030: The createBookingProposal operation shall receive and process the BookingProposalRequest message from an External User.
ASM-INTF-NEG-040: If the proposal is valid, the createBookingProposal operation shall transmit the newly created proposal in the BookingProposalReply message to the requesting External Users.
ASM-INTF-NEG-050: If for any reason the request or the resulting proposal is not valid, the createBookingPrposal operation shall transmit an appropriate error in the BookingProposalReply message to the requesting External Users.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
ASM-INTF-NEG-060: The queryBookingProposalList operation shall receive and process the BookingProposalListRequest message from an External Users.
ASM-INTF-NEG-070: If the proposal list request is valid, the queryBookingProposalList operation shall transmit the list of proposals in the BookingProposalListReply message to the requesting External Users.
ASM-INTF-NEG-080: If for any reason the request is not valid, the queryBookingProposalList operation shall transmit an appropriate error in the BookingProposalListReply message to the requesting External Users.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
ASM-INTF-NEG-090: The handleBookingProposal operation shall receive and process the HandleBookingProposalRequest message from an External User.
ASM-INTF-NEG-100: If the request is valid, the handleBookingProposal operation shall perform the requested action.
ASM-INTF-NEG-110: If for any reason the request is not valid, the updateBooking operation shall transmit an appropriate error in the HandleBookingProposalReply message to the requesting External User.
ASM-INTF-NEG-120: A HandleBookingProposalRequest should be rejected by the service if the user performing the update does not have the appropriate actions matching their update.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
Endpoints
Interface Binding Description Overview
N/A
Behaviour
Interface role
The Airspace Status interface enables the retrieval of activation data held within the ASM Support System by External Users.
An activation refers to the specific state of an airspace at the current time and until a specified end time. The end time of an activation is subject to change, it may be shortened or extended.
This interface allows users of host ASM Support System to see in real time the status of the airspace managed by another, foreign ASM Support System.
Figure 30 in Section 2.4.10.1 provides an overview of the Airspace status interface.
Information Exchange Flow
Figure 31 in Section 2.4.10.2 depicts the Airspace status interface information exchange flow.
Interface Functions
The interface performs the following function:
- Requesting Activations - Allows access to the activation data held within the ASM Support System by External Users.
ASM-INTF-STAT-010: ASMtoASM Service shall be supported by the Airspace Status interface to manage the retrieval of activation data held within the ASM Support System by external users.
ASM-INTF-STAT-020: The AirspaceStatus interface shall support the following operation:
- queryActivationList
CONSUMER_SIDE_INTERFACE
SWIM_TI_YP_1_0_AMQP_MESSAGING
IPV4_SECURE_UNICAST
SYNCHRONOUS_REQUEST_RESPONSE
Operations
ASM-INTF-STAT-030: The queryActivationList operation shall receive and process the FilteredRequest message from an External User.
ASM-INTF-STAT-040: If the activation list request is valid, the queryActivationList operation shall transmit the matching activation data in the ActivationListReply message to the requesting External Users.
ASM-INTF-STAT-050: If for any reason the request is not valid, the queryActivationList operation shall transmit an appropriate error in the ActivationListReply message to the requesting External Users.
Note: The definition of these messages can be found in section 2.7.3 Interface Messages.
Endpoints
Interface Binding Description Overview
N/A
Behaviour
References
Revision Save Date
Wed, 09/21/2022 - 13:38