CONSUMER_SIDE

LongTermPlanning

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.

 

Operations
createEvent

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of these messages can be found in Section 2.7.3 Interface Messages.
Processing Consideration
N/A
updateEvent

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of these messages can be found in section 2.7.3 Interface Messages.
Processing Consideration
N/A
queryEventList

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of these messages can be found in section 2.7.3 Interface Messages.
Processing Consideration
N/A
Behaviour
N/A
Interface Binding Description

N/A

Interface Provision Side
CONSUMER_SIDE
TI Primitive Message Exchange Pattern
SYNCHRONOUS_REQUEST_RESPONSE
Service Interface Binding
SWIM_TI_YP_1_0_AMQP_MESSAGING
Network Interface Binding
IPV4_SECURE_UNICAST
Publication

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.

Operations
notifyStaticData

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of this message can be found in Section 2.7.3 Interface Messages.
Processing Consideration
N/A
N/A
notifyActivityData

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of this message can be found in Section 2.7.3 Interface Messages
Processing Consideration
N/A
N/A
notifyBooking

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of this message can be found in Section 2.7.3 Interface Messages.
Processing Consideration
N/A
N/A
notifyBookingAction

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of this message can be found in section 2.7.3 Interface Messages.
Processing Consideration
N/A
notifyBookingConflict

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of this message can be found in section 2.7.3 Interface Messages.
Processing Consideration
N/A
notifyMission

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of this message can be found in section 2.7.3 Interface Messages.
Processing Consideration
N/A
notifyProposal

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of this message can be found in Section 2.7.3 Interface Messages.
Processing Consideration
N/A
notifyEvent

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of this message can be found in Section 2.7.3 Interface Messages.
Processing Consideration
N/A
notifyActivation

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.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
TI Protocol Methods
Refer to Section 2.5 Technologies
Operation Message
The definition of this message can be found in Section 2.7.3 Interface Messages.
Processing Consideration
N/A
Behaviour
N/A
Interface Binding Description

N/A

Interface Provision Side
CONSUMER_SIDE
TI Primitive Message Exchange Pattern
SYNCHRONOUS_REQUEST_RESPONSE
Service Interface Binding
SWIM_TI_YP_1_0_AMQP_MESSAGING
Network Interface Binding
IPV4_SECURE_UNICAST
ArrivalSequenceInformationSubscriber

DSNA Arrival Sequence Service - Data distribution interface

Operations
publishArrivalSequence

Operation to transmit the ArrivalSequence message to the service consumer

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Precondition
To have a valid certificate and a valid subscription reference
TI Protocol Methods
AMQPS: AMQP 1.0 / TLS 1.2 / TCP / IPv4
Operation Message
ArrivalSequence
Processing Consideration
n.a
communicateException

Operation to inform the service consumer about problems occurring, at service run-time, on provider side.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Precondition
To have a valid certificate and a valid subscription reference
TI Protocol Methods
AMQPS: AMQP 1.0 / TLS 1.2 / TCP / IPv4
Operation Message
ProviderException
Processing Consideration
n.a
Operational

operational network address

Url

amqps://eaman.swim.dsna.fr:5671

Pre-Operational

pre-operational network address

Url

amqps://eaman.preops.swim.dsna.fr:5671

Behaviour
Nominal and unexpected behaviour
Interface Binding Description

AMQPS: AMQP 1.0 / TLS 1.2 / TCP / IPv4

Interface Provision Side
CONSUMER_SIDE
Service Interface Binding
SWIM_TI_YP_1_0_AMQP_MESSAGING
Network Interface Binding
IPV4_SECURE_UNICAST
DataDistribution

TBD

Operations
distributeFlightPlanData

The flight plan data distribution ensures that each client is provided with the latest up-to-date flight plan information detailing the fol-lowing information:
• General flight plan information
• Clearances
• 4D-Trajectory
• Airspace crossing & sector sequence information
• Entry & Exit coordination data for the current leg
• Current (under-control or first) and next sector conditions
• Basic correlation information
Note that the current implementation of the service only includes the coordination information related to the current leg . Downstream leg information may be provided at the same time by another service or by extending the definition of the current data type (see section Error! Reference source not found.), but this is considered out-of-scope of the ADaaS project. For the 4D-Trajectory, airspace crossing and sector sequence information, the complete flight within the considered system’s AoI will be covered.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
FlightPlanDataMessage
distributeSectorSpecificData

The SectorSpecific data distribution ensures that each client is provided with the latest up-to-date OPS sector-specific information for a flight detailing the following information:
• Sector status (normal, skipped, bypassed, etc.)
• Entry, Internal & Exit coordination data for the OPS sector for which information is distributed.
• Intra-sector dialogue information
• Event trigger information (for display purposes) for the OPS sector t
Important: the service will emit all sector-specific data for all flights over the service. It is the clients responsibility to filter out the relevant messages for him. The rationale of using such an approach is that it allows the usage of topics (multicast) at a later stage in the project without changing the client side functionality.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
SectorSpecificDataMessage
distributeFlightPlanMonitoring

This service provides all subscribed clients with all detected deviations (Lateral, Vertical and Longitudinal) between the trajectories cleared data and the track. Additionally, it provides an automatic re-routing proposal when available.
The service is implemented by means of the FpmMessage. Conformance monitoring information is only provided for SFPLs, which are under-control and not in MANUAL sub-state. Re-routing information may already be received for SFPLs, which have been coordi-nated at entry (e.g. ACT received at the server, or manual coordination performed) and are not yet-under-control of the local centre.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
FlightPlanMonitoringMessage
distributeCorrelation

This service provides all subscribed clients with all detected deviations (Lateral, Vertical and Longitudinal) between the trajectories cleared data and the track. Additionally, it provides an automatic re-routing proposal when available.
The service is implemented by means of the FpmMessage. Conformance monitoring information is only provided for SFPLs, which are under-control and not in MANUAL sub-state. Re-routing information may already be received for SFPLs, which have been coordi-nated at entry (e.g. ACT received at the server, or manual coordination performed) and are not yet-under-control of the local centre.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
CorrelationMessage
distributeFlightBright

The flight bright distribution service provides the means to highlight a flight within for the own OPS sector based on SSR Code(s) “SSR Bright” and/or ModeS callsign(s) “ModeS bright”, and within own or to other OPS sectors (internal/external) based on callsign(s) “flightplan bright”.
The service is implemented by means of the FlightBrightMessage. The message is distributed to the own OPS sector (case of bright for SSR code, ModeS code, or flightplan bright for the own OPS sector) or to another OPS sector (case of flightplan bright to another OPS sector); in other words message distribution is “OPS sector oriented”.
At initialisation, actual bright information for the OPS sector is distributed. Per OPS sector there can be a maximum of 20 requests for flight bright.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
FlightBrightMessage
distributeSectorisation

The sectorisation distribution service ensures that each client is provided with the latest up-to-date sectorisation information residing at the server. Basically, the following information is distributed:
• Sectorisation pattern: contains the sectorisation pattern (i.e. unique identifier for each sectorisation) selected for each sector group.
• Sector composition: composition contains the list of airspace volumes and basic sectors composing each flight sector (see section Error! Reference source not found. for more information on the concept).
• Sector consolidation: contains the list of flight sectors consolidated into each OPS sector (see section Error! Reference source not found. for more information on the concept).
• Sector allocation: contains the list of flight sectors allocated to each internal/external centre.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
SectorisationMessage
distributeSsrCode

The service provides the OPS sector with the information related to reservation of a free manual-assignable SSR code sequence described in section Error! Reference source not found..
The service is implemented by means of the SsrCodeMessage. The message is distributed to the own OPS sector only.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
SsrCodeMessage
distributeWindForecast

The meteorological information distribution service aims to provide all operational sectors with the latest:
• Wind & temperature forecast information extracted from the external world for a range of different levels,
• Airport related meteorological information received from the external world from the following sources:
o METAR and METAR COR
o SPECI and SPECI COR
• QNH, transition level and transition altitude information for airports

This service is implemented by means of two messages:
• WindForecastMessage, containing the wind & temperature forecast information.
• AirportMeteoMessage, containing the airport related infor-mation.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
WindForecastMessage
distributeMap

The map distribution service aims to provide requesting clients with the latest information of map data. A distinction is made between static, semi-dynamic and dynamic maps:
• Static: It is defined offline, and their contours cannot be modified on-line. Textual elements and/or other display elements may be modified.
• Semi-dynamic: It is defined offline, and their contours can be modified on-line. Textual elements and/or other display elements may be modified.
• Dynamic: They are created on-line. All of their contents may be modified.

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
MapMessage
distributeSystemMode

The system mode distribution service provides to all connected & subscribed clients the following FDPS system information:
• System: Primary or Fallback
• System mode: Operational or Test mode
• System sub-mode: Authorised or unauthorised
• Link status: ON or OFF (link between Primary and Fallback)
• MTCD Status: ON or OFF
• MTCD Time Horizon
• FDPS degradation level
• FDPS SW and adaptation data version
FDPS coordinate projection parameters

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
SystemModeMessage
distributeSpecialArea

The special area distribution service provides all subscribed clients with the latest status of all special areas (e.g. TSA, TRA, etc.) residing at the server side. For each area the following information is provided:
• Airspace status:
o pre-warning (pending to be active within 15 minutes)
o active
o inactive
• Operation Mode:
o Manual (i.e. the special area activation/de-activation is triggered by manual supervisor action)
o Scheduled (i.e. the special area activation/de-activation is triggered automatically by following an activation/de-activation schedule)
• The applicable lower and upper level related to the special area activation
• The start and end time related to the special area activation.
• In case of booking via LARA, additional LARA booking information, being:
o Unique LARA reservation identifier
o LARA activation status
o List of callsigns involved in the mission
o Mission type
o Permeable or non-permeable indicator

Idempotent
NON_IDEMPOTENT
Synchronous
ASYNCHRONOUS
Operation Message
SpecialAreaMessage
Behaviour
service behaviour
Interface Binding Description

AMQP 1.0 content-type header used to specify media type values

Interface Provision Side
CONSUMER_SIDE
TI Primitive Message Exchange Pattern
FIRE_AND_FORGET
Service Interface Binding
SWIM_TI_YP_1_0_AMQP_MESSAGING
Network Interface Binding
IPV4_UNICAST
Subscribe to CONSUMER_SIDE