Introduction

The Digital NOTAM Specification provides coding scenarios for situations that are likely to occur frequently and that have a high potential for the data to be used digitally, for example for the creation of graphical PIB or for triggering an automated process. This includes events such as TWY closure, airspace activation, navaid unserviceable, runway condition reporting, etc.

There will continue to exist situations for which no pre-defined coding scenario is available. As a NOTAM needs to be issued in many such situations, an equivalent "Digital NOTAM" is also expected by the clients. This will ensure that the Digital NOTAM service is complete and that the clients do not have to look somewhere else (for example, on the AFS/AFTN) for the missing NOTAM messages. The purpose of this section is to explain how this can be achieved in relation with the AIXM Event Extension model.

Event - AIXM feature association possibilities (reminder)

Before going further, it is useful to recall how an Event may be associated with other AIXM features. As explained in the Event Extension usage guidelines, the temporary modification of the properties of an aeronautical information feature, such as the operational status of a navaid, is coded with an additional TEMPDELTA TimeSlice for the feature concerned (for example, the Navaid). On the following diagram, these are highlighted as "AIXM feature associations". The same principle applies when a temporary feature (such as a temporary obstacle) is created through an Event. A new BASELINE TimeSlice is created for that features, for example for a new VerticalStructure.

In addition, the Event Extension usage guidelines also indicate that an Event may be operationally related to airports/heliports of FIR. This information is coded at the level of the Event instance, as associations towards zero or more AirportHeliport and/or zero or more Airspace (with type 'FIR'). No additional TimeSlice is created for the concerned AirportHeliport or Airspace feature. On the following diagram, these are highlighted as "Event associations".

AIXM Event variants

When Event is coded in relation with a NOTAM, several levels of digitisation may be applied. The NOTAM can be 'fully digital', if coded following the rules of a pre-defined scenario, including timeslices for the affected AIXM features. For NOTAM that do not have an equivalent pre-defined scenario, an Event could still be coded, with or without an association with an AIXM feature TimeSlice. An association may be used in order to "link" the NOTAM with the feature concerned. This is the equivalent of the NOTAM Linkage applied in the European AIS Database (EAD) at present, for example in order to prevent that a feature is withdrawn while still referenced by a NOTAM. Thus, the following (AIXM) Event variants are identified:

"D variant" - Events that are coded applying the rules of a pre-defined Digital NOTAM Scenario (such as SAA.ACT, etc.) and that are associated with (from) AIXM feature (AirportHeliport, Runway, etc.) TimeSlices. The letter "D" that identifies this variant comes from "fully Digital":
- for such Events, one or more equivalent NOTAM might also be issued, but it is not mandatory. For example, there exists pre-defined scenarios for de-icing operations in progress, low visibility procedures in operation, etc. for which no NOTAM is usually issued. Also, the ICAO rules might evolve in the direction or removing the obligation to issue certain NOTAM if equivalent digital data is provided (as AIXM Event and related AIXM feature TimeSlices).

"N variant" - Events that are not coded according to a Digital NOTAM Scenario and which are not associated with any AIXM feature. However, such Events may still have the direct associations with the AirportHeliport and/or Airspace (FIR) that are concerned by the Event. The letter "N" that identifies this variant comes from "NOTAM only"
- they are used for example for " bird strike risk", "pandemic", "grass cutting", etc.
- the "OTHER" scenario is used for this purpose. However, more specific scenario could be defined, if considered useful for improving the sorting/filtering of Events for pre-flight briefing purpose, for example.

"L variant" - Events that are not coded according to a Digital NOTAM Scenario, but which are associated with a TEMPDELTA Timeslice of a relevant AIXM feature for " linkage" purpose. This provides, at AIXM feature level, an indication that there exist a temporary situation affecting the feature, but that this is not coded digitally.
- this is the equivalent of the current NOTAM Linkage in EAD, which is also indicated by the letter "L" that identifies this variant. The TEMPDELTA Timeslice would not have any specific data. just a link to the Event.
- specific scenario identifier could be defined and used, not only OTHER. This would allow sorting/filtering of Events for pre-flight briefing purpose, for example.
- "L variant" events may be used when a limited Digital NOTAM service is provided, for example, when not sufficient baseline data is available for enabling the fully digital coding of an Event or when the effort required for the digital coding is not considered justified for some locations in the area of responsibility of the service.
- The "L variant" is still useful for narrow-route PIB, as it allows a more precise localisation of the subject/condition than the simple association with airport or airspace. The L variant also contributes to the coherence of the aeronautical information, as it enables identifying attempts to withdraw a feature which is still referenced by a NOTAM in force.

Note: In addition, an "S variant" may be identified - Events used for static data maintenance. There might exist pre-defined scenarios for these, but none is defined at present. These can be complex Events that may have parent-child relations. They are not in the scope of the Digital NOTAM process. The letter "S" that identifies this variant comes from 'Static Data Event".

Important Note

The main purpose of identifying the Event variants (D, L, N, S) is to offer a common terminology for business processes, use cases and functional specifications for Digital NOTAM systems. A "D variant" Event is likely to be subject to different functional requirements from an "L variant" Event. There is no specific property in the Event feature that would allow recording the Event variant, However, as explained below, the Event attributes and associations are used differently in each variant. Thus, it is relatively easy to identify the Event variant.

The following diagrams indicate which data elements are used for each of these variants

D variant

the feature TimeSlice associated with the Event has properties with values that correspond to the Event scenario.
the summary of the Event provides text for PIB entry
a scenario identifier is mandatory and the data coding rules may be verified based on it
an AISMessage (NOTAM) may be also published, but it might not always be the case.

N variant

the are no feature TimeSlice associated with the Event
the summary of the Event provides text for PIB entry
a scenario identifier can still be used for filtering/sorting purpose
there exist AISMessage (NOTAM) published for the Event

L variant

the feature Timeslice associated with the Event does not have any data properties, only the link with the event,
the summary of the Event provides text for PIB entry
a scenario identifier can still be used for filtering/sorting purpose
an AISMessage (NOTAM) may be also published, but it might not always be the case.

Browser not supported