OpenATM 1.0

Current JSON Original JSON

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

The operation allows to:
• Create ASPL or SFPL,
• Modify an ASPL/SFPL,
• Upgrade an ASPL into SFPL,
• Downgrade an SFPL into an ASPL.

The operation allows modifying:
• number of aircraft related to a flight plan
• aircraft type
• flight’s wake-turbulence category
• flight’s deviation status
• RVSM capability
• 8.33 kHz capability
• UHF equipment
• BRNAV/PRNAV equipment
• ModeS capability
• Number of people on board
• FSSA capability
• Avoiding weather indicator
• Fuel dumping indicator

The operation allows to:
• Modify the callsign of an existing ASPL or SFPL.

The operation allows to manually deleting an existing ASPL or SFPL from the system.

https://ost.eurocontrol.int/sites/B2BWS/B2B%20Reference%20Manuals%20HTM…

From an operational perspective, a DCT action can represent multiple cases. The interface definition has been considered to fulfil the op-erational scenarios listed below. For completeness reasons the required options to be passed in the RequestDCT input are given below:
• DCT to a (intermediate) Point
o to
Allows the sending of a single route point name (or coordinate) with optional intermediate point. In this case, the MSB-CB will automatically determine the most likely type of DCT instruction given (i.e. make the distinction between “to-original-route” and “to-trajectory” as given below). From an interface and client implementation perspective this option allows to perform DCT actions without the requirement for the client to reference to index in the trajectory. Also, this option allows also performing a DCT instruction for an ASPL for which no trajectory is available.
• DCT to Point on the Trajectory (Uplink = UM74)
o to-trajectory
 intermediate-point not sent
 end-point represents the index point and posi-tion in the trajectory
• DCT to Point on the Original Route (Uplink = UM74 + UM72)
o to-original-route
 intermediate-point not sent
 end-point represents the point name (located on the original route)
• DCT to (Intermediate) Point not located on the trajectory; in this case the end-point is on the trajectory (Uplink = UM79: "CLEARED TO [end-point] VIA [intermediate-point])
o to-trajectory
 intermediate-point represents the route point name or position of the intermediate point
 end-point represents the index point and posi-tion in the trajectory
• DCT to (Intermediate) Point not located on the trajectory; in this case the end-point is on the original route (Uplink = UM79: "CLEARED TO [end-point] VIA [intermediate-point] + UM72)
o to-original-route
 intermediate-point represents the route point name or position of the intermediate point
 end-point represents the point name (located on the original route)
• DCT to (Intermediate) Point not located on the trajectory, and no end-point specified. In this case, the DCT is considered to be a point completely off-route, which is not to be rejoined. A typical example is a DCT to a point outside the AoI, which is not located on the trajectory (Uplink = UM74).
o to-trajectory
 intermediate-point represents the route point name or position of the intermediate point
 end-point represents the null index point
Note 1: A current heading restriction will be removed upon receiving a DCT input.
Note 2: For ASPLs, a DCT to an Intermediate OR End Point is allowed (with whatever DctData option) provided any reference to a trajectory point is populated with the null-TrajectoryPointNumber. Inputs combining both Intermediate AND End Point will not be processed.

From an operational perspective, a change route action represents a re-routing of the flight across multiple waypoints (unlike a DCT where the flight is instructed to go to only one waypoint).
Note 1: A current heading restriction will be removed upon receiving Operation changeRoute.
Note 2: Only available for SFPLs.

The interface definition has been compiled taking into account the operational cases listed below. For completeness reasons the possible parameters, for such situations, to be passed in the RequestHeading input are indicated as well:
• Present Heading (uplink possible)
• Assigned Heading – relative or absolute true/magnetic heading (uplink possible)
• Non-specified Heading; use track direction as heading and update trajectory with this value (no uplink possible)
• Heading to avoid weather, for example CBs; use track direction as heading an generate an observed tactical trajectory with it (no uplink possible)
In the first three cases above, the type of heading closure is mandatory in the request. The following cases have been distinguished in case the application limit and trajectory resuming point are included in the request:
• No application limit and rejoining point specified in the input: a default application limit will be applied and the trajectory will be closed based on pre-defined closure rules.
• Application limit specified as distance and rejoining point present in the request: the specified distance and rejoining-point will be applied.
• Application limit specified as “Indefinite”: the system will auto-close the trajectory at AoR exit.
In all cases, the input heading is considered as magnetic heading.

The command allows resetting a previous heading instruction for ASPLs only. In case the command is requested for an SFPL, the result will be returned with an error.

To process the input of a cleared flight level, with application time/distance and/or ROCD restriction.

To process the input of an enroute cruising level. The ECL is applied until the exit of the AoI (i.e. propagated all the way), unless the ap-plication-limit is present in the request.

To process the input of a requested flightlevel as requested by the pilot or filed by the airline company.

To process the input of a planned flight level (PFL). The PFL is best described as an ECL, but only applied until the requesting sector’s exit.

To process the input of a control input command, to allow either:
• Take control of the flight,
• Transfer control of the flight,
• Delegate control of the flight to the sector where the flight is geographically located,
• Hand-over propose/accept.

To process the input of an entry flightlevel for the coordination between internal sectors or with the external upstream partner.

To process the input of a transfer flightlevel for the coordination between internal sectors or with the external downstream partner.

The operation allows to:
• Skip and cancel-skip of an internal sector,
• Bypass and cancel-bypass of the 1st downstream internal sector,
• Delegate the flight to another internal sector,
• Change the next downstream internal sector into the pre-ferred one.

The operation allows performing coordination changes related to the entry of the sector performing the request. The operation applies to both internal and external entry coordination.
Changes to the following items can be requested, or negotiated:
• NFL & NSFL (as also possible with requestNFL – see section 3.6.4)
• Departure level (indicates the initial cleared level for departure flights out of an internal aerodrome)
• ETO (Estimated Time Over)
• COP (Coordination Point)
• PSSR (Present SSR Code)
• DCT-to point (including intermediate point if required)
• Accepting Frequency
• Speed
• Heading

The operation allows performing coordination changes related to the exit of the sector performing the request. The operation applies to both internal and external exit coordination.
Changes to the following items can be requested, or negotiated:
• TFL & TSFL (as also possible with requestTFL – see section 3.6.5)
• ETO (Estimated Time Over)
• COP (Coordination Point)
• PSSR (Present SSR Code)
• DCT-to point (including intermediate point if required)
• Transferring Frequency
• Speed
• Heading

The operation allows performing a departure clearance (for a flight departing from an internal aerodrome). For example, a TWR sector can perform this action, or eventually a higher sector that has to deliver the departure clearance.
Items available in the departure clearance are kept limited for the first phase and include:
• Departure level (indicates the initial cleared level for departure flights out of an internal aerodrome)
• Take-off time
• PSSR (Present SSR Code)
• Accepting Frequency
• SID
• Departure runway

To process the input of a manual linkage/unlinkage request of a flight plan with a track.