Use of the AIXM Event extension

Event extension

The purpose of the Event Extension is to enable the digital encoding of the aeronautical data that concerns identifiable operational situations, which result in the temporary or permanent alteration of one or more aeronautical information features or of their properties. A runway closure, the unavailability of a navaid or a temporary new obstacle are examples of such situations. Thus, the coding of Digital NOTAM uses the AIXM Event extension, which enables:

to specify the operational situation for which the Digital NOTAM is encoded, in order to enable specific verification and processing rules to be applied to the associated feature TimeSlices;
to enable the automatic generation of the NOTAM fields and the association of the event with the corresponding Text NOTAM message. This should facilitate the migration from Text NOTAM to Digital NOTAM and the issuing in parallel of the two, during the transition period;
to enable a basic digital encoding of the data contained in the NOTAM messages that are not digital; such NOTAM can be encoded as free text notes associated with the feature affected. This should enable the digital data users to work with a single source of data and will avoid the need to consult text NOTAM for those information items that are not yet available digitally;
to enable the further updates of a previously issued event and of the corresponding NOTAM messages.

The elements of the Event Extension that are relevant for Digital NOTAM encoding are presented in the following UML class diagram.

The information about the actual change brought by the operational situation for which the Digital NOTAM is issued is encoded as TimeSlice(s) of the relevant AIXM features. This is the genuine “digital NOTAM” side of the schema. In order to relate the AIXM feature TimeSlices with the Event, the belongsTo association is used, as visible on the top-right side of the diagram. Most events will need a single AIXM feature TimeSlice to be provided. For example, the activation of a temporary restricted area will require a single Airspace TimeSlice of type 'TEMPDELTA'. There might exist events that require several AIXM feature TimeSlice to be encoded in different AIXM features. For example, the establishment of a new obstacle (temporary or permanent) might require two AIXM features TimeSlice to be encoded: (1) a new VerticalStructure 'BASELINE' and (second) an additional ObstacleArea TimeSlice including the association to the new VerticalStructure, if relevant.

A NOTAM, SNOWTAM or ASHTAM message may be generated and associated with the Event. These classes have all the attributes and associations necessary for coding the elements of the current messages as defined by ICAO - such as series, number, FIR, purpose, traffic, etc. The airports and/or FIR airspace affected by the Event may be identified through the direct "concerns" associations between the Event class and the AirportHeliport or Airspace class respectively. The issuing NOTAM office is modelled with the issuedBy association to the Unit class. Although this association is not used in the Digital NOTAM examples provided with this Specification, it is available in the Event XML schema and it can be used in implementations, if necessary.

There are current NOTAM practices that can lead to situations where several NOTAM are associated with one Event. For example, if a navaid is used for approach/departure/arrival procedures at several closely located airports, then the current practice in many States is to publish a "navaid unserviceable" NOTAM for each airport that is affected, with the corresponding airport designator in item A. This ensures that the corresponding NOTAM will appear in the airport section of the Pre-Flight Information Bulletins (PIB), for the concerned airport. Therefore, the same event and its single AIXM 5 encoding may have several associated NOTAM.

The Event also has a "self-association" that allows encoding event trees, in which one event is the cause of other events. For example, the temporary displacement of a runway threshold could trigger changes in approach and departure procedures, which could be encoded as separate events and issued as separate NOTAM messages.

Coding rules

The general Event coding rules are applied to Digital NOTAM. However, there are specific rules for NOTAM messages, stated in the ICAO PANS-AIM or in regional documents such as the Eurocontrol OPADD, which need to be taken into consideration. For example, when the validity of an Event is extended or shortened it will result in an additional 'BASELINE' TimeSlice for the Event feature, including the text of the NOTAM with type equal-to 'R' or 'C'. The initial Event TimeSlice remains associated with the initial NOTAM (type 'N'), while the new Event TimeSlice is associated with the NOTAM 'R' or 'C'.

In order to clearly state the event coding rules for Digital NOTAM, some specific NOTAM situations are discussed in this section.