OpenATM v 1.0

Subscription Management

allows service consumers to subscribe or unsubscribe to the distribution of a series of information areas.The following information areas can be subscribed to: • flightplan-data, • sector-specific-data, • safety-net, • flightplan-monitoring, • datalink, • correlation, • heartbeat, • flight-bright, • mtcd-service, • system-information, • strategic-constraint, • sectorisation-data, • ssr-code, • meteo-data, • runway-info, • special-area, • map-data

Not applicable

Heartbeat Distribution

supports the service provider and the service consumer to monitor each other’s status.

Not applicable

Management of Flight Plan Data

allows service consumers to provide the correct & latest up-to-date controller information, create, modifiy, udate ASPL or SFPL, Submit requests about instructions/clearances given to the flight crew (e.g. DCT, CFL, NFL, speed, heading, …), Change status information regarding the flight’s airframe (e.g. no FSSA, RVSM status, …), Etc.

Any instruction communicated to the pilot (either via voice or datalink) are expected to be executed by the aircrew. Furthermore, such information is communicated towards downstream partners and the network manager.

Management of Sector Specific Data

allows service consumers to provide the correct & latest up-to-date controller information regarding sector-specific information and coordination & transfer information, such as taking control of a flight (or proposing hand-over, request-on-frequency, etc.), Change the coordinated entry and exit levels, Deliver departure clearance for an flight departing from an internal aerodrome, 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 preferred one, Change the entry/exit frequency of sectors, Etc.

Upon communication of the SSR code to the aircrew, the aircraft transponder will emit that code. Furthermore, the present/next SSR codes allocated to the flight plan are communicated to downstream partners interested in the flight.

Management of Correlation

allows service consumers to provide inputs related to the linkage of flight plans with tracks, such as link a flight plan with and unlink a flight plan from a specific track, set the present, next or downstream SSR code a flight.

Correlation establishment, and the resulting identification of the current aircraft position related to the flight plan are communicated towards the network manager.

Management of Flight Bright

allows service consumers to provide inputs related to highlight of a track or flight plan, such as adding or removing SSR codes or Mode S callsigns to / from the Bright function for his OPS sector; adding or removing a Flight to / from the Bright function for his OPS sector;or another internal OPS Sector; point a flight to an external flight sector / centre

The management of flight bright does not have a real-world effect.

Management of Sectorisation

allows service consumers to perform a re-sectorisation change, such as verifying a new sectorisation change (would it be valid if performed), performing a sectorisation change.

Re-sectorisation changes in the configuration of the air traffic control unit result in the real-world effect that air traffic is handled in a more efficient way (in accordance with the flow of traffic).

Management of SSR code

allows service consumers to reserve an SSR code for manual assignment later on (i.e. manual assignment by using the Operation setSsr, see section 3.7.4), and to clear such code from display in the whole OPS sector.An SSR code reserved for manual assignment is not available for automatic assignment. The SSR code will be re-served during a design parameter time and then released if not manually assigned to any flight plan or released according to the standard release rules if manually assigned to a flight plan during this design parameter time.

The management of SSR code does not have a direct real-world effect. Its effect is reflected via the aforementioned management of correlation when the SSR code is communicated to the aircrew.

COLLABORATIVE_VALIDATION

Initialisation & distribution of messages

As a general principle, the MSB-CB is the system instance that governs the initialisation towards the remote clients. The MUAC FDPS initialisation capabilities are thus de-coupled from the remote connecting clients. Initialisation is performed by requesting a full transmission of all data on a dedicated channel for the requestor only so as not to be disturbed by initialisations of other clients at the same time . The MSB-CB is arranging the initialisation, and the client is not expected to include any logic (e.g. sequence number checking). Whenever a client subscribes to an interface, the internal flight plan data store is copied and all required data messages (supported by the requested interface(s)) for the initialisation are then emitted towards the client. Any update which is arriving in the meantime is distributed instantaneously to the up-and-running clients (i.e. the ones not initialising), while the updates for initialising clients are buffered until all initialisation data has been sent. After the initialisation is completed, the buffered updates are sent. For the updates, there are two types of data distribution: cyclic updates and updates on create/update/cancel for the non-cyclic distribution. It’s important to note that as a general principle, the majority of the data is sent only when changed (i.e. only the “delta” with respect to the previous message of the same type is distributed).