Introduction

A basic knowledge of the AIXM key concepts, in particular of the Temporality model, is necessary in order to understand the Digital NOTAM coding examples discussed here. The XML sources are attached, together with the Visio file that contains the source of the diagrams used on the page.

A Digital NOTAM is a small data set, which provides in coded format (AIXM 5.1 or later versions) information about operationally significant aeronautical information changes. Most of the time, these changes are of short duration and affect only a few of the properties of a feature (the operational status of a runway, the activation status of an airspace, the position of a runway threshold, etc.). It may also happen that the change is of longer duration or even permanent and it is also possible that the event in fact consists in the creation of a complete new feature (such as a temporary new obstacle).

Two examples are presented here: an airspace that becomes active (temporary situation for an existing feature) and a temporary obstacle (new feature, which did not exist before the event).

Relation with the baseline data

Existing airspace becomes active - add TEMPDELTA TimeSliceNew obstacle (temporary or permanent) - create new feature and its first BASELINE TimeSlice


In most situations, the Digital NOTAM is in the form of a "temporary delta" which contains only the properties actually changed during the event. For example, if an existing Airspace is activated, the Digital NOTAM is encoded as a TEMPDELTA TimeSlice for the Airspace that contains an (activation.AirspaceActivation.)status='ACTIVE'.

The TEMPDELTA and the BASELINE records are closely related, they are facets of the same feature.


When there is no baseline feature, the Digital NOTAM itself is in the form of a new baseline.
It contains all the properties that are necessary to be known for that feature during its duration of validity.

The role of the Event feature

In addition to the aeronautical information features defined by the AIXM model (such as Airspace, VerticalStructure, Runway, etc.), the coding of a Digital NOTAM relies on an additional "Event" class. This is added through an Event extension of the AIXM 5.1(.1) XML schema.

The primary purpose of the Event class is:

  • to identify the kind of event that is being encoded, which then enables verifying the conformance with the coding rules and also facilitates its processing;
  • where applicable, to explicitly associate all the TimeSlices of the different features that contribute to the digital encoding of one event;
  • to provide further information about the event, such as a textual description suitable for pre-flight briefing, advanced planning data, etc.
Airspace activation - TEMPDELTA association with the Event

New obstacle with runway declared distance changes - associated with same Event


In this example a single Airspace TEMPDELTA is sufficient, therefore only its TEMPDELTA TimeSlice needs to be associated with the Event.


In this example the temporary obstacle also impacts the values of the declared distances of a closely situated runway. Therefore, both the VerticalStructure BASELINE and the RunwayDirection TEMPDELTA are associated with the Event. The scenario coding rules are practically an aggregation of the coding rules of the two sub-scenarios (new obstacle and runway declared distance changes).

XML code - basic elements

The airspace activation will be used further in order to detail the AIXM XML coding of the Digital NOTAM.

The Airspace TEMPELTA and the new Event BASELINE

Legend


  The overall container of the Digital NOTAM can be an AIXMBasicMessage, which is simply a collection of AIXM features.

  This is the Airspace TEMPDELTA TimeSlice that contains the data about the activation. Note the following elements:

<gml:validTime> indicates the period when the TimeSlice is valid, which corresponds to the period when the Digital NOTAM is active

<aixm:interpretation> indicates the type of TimeSlice (TEMPDELTA in this case)

<aixm:activation> contains the actual data about the activation. In this view, this element is collapsed, note that there are in fact 22 hidden lines. This will be discussed in more detail further down.

Note that the TEMPDELTA contains strictly the Airspace feature properties that have a different value during the event, as compared to the baseline situation. For example, the name, designator, etc. properties are not modified and thus not included in the TEMPDELTA.


   This <event:theEvent> element associates the Airspace TEMPDELTA TimeSlice with the Event. The association is encoded as an "abstract reference" in this example (see the AIXM Feature Identification and Reference, chapter 3.4 for further details about this topic).

   The Event element is also present in the Digital NOTAM encoding. Note that in this view this element also is collapsed, there are 49 hidden lines. The details are will be discussed further down.




The airspace activation data

Legend

  The data about the airspace activation is provided with an <aixm:AirspaceActivation> element. The complete list of properties of this element is described in the AIXM UML model.

   The type of activity (coded value "UAV" according to the AIXM predefined list of values for this property) and the "ACTIVE" status are explicitly provided in the Digital NOTAM coding.

   The <aixm:levels> complex element is mandatory and indicates the vertical extent of the activation. The special coded values "FLOOR" and "CEILING" indicate that the airspace is active between its predefined lower and upper limits, as contained in the baseline data. The explicit values are not copied here.

    A Digital NOTAM may still contain free text annotations, for information that is intended for human operators and for which there is no predefined AIXM property. In this case, the annotation provides details about the activity and who to contact for further information. Note that it is possible to further qualify a free text annotation, using purpose ('REMARK' in this case) and indicating that it concerns a specific property of the feature, In this example, the first sentence ("In between firing periods...") would better be encoded as a separate annotation, associated with the <aixm:activity> property.


The Event details

Legend

    The Event itself is also encoded as an AIXM feature, using the Event extension schema. it has all the characteristics of an AIXM feature such as a TimeSlice, a unique identifier, etc.

   The value of the Event.gml:identifier was used in the Airspace shown above in order to associate the TEMPDELTA TimeSlice with the Event. See Legend item 3 above.

   The duration of validity of the Event is equal to the duration of validity of the TEMPDELTA TimeSlice of the Airspace, because the Event exists only for as long as the temporary situation exists.

   These properties allow identifying the type of event (SAA.ACT in this case) and the version of the Digital NOTAM specification that provides the coding rules applied (2.0 in this case). In addition, it allows giving a name to the event, which is interesting especially for events that are planned in advance and that are known to the operational people under that name.

   This element contains an equivalent "NOTAM message" for the temporary Airspace activation event. This is expected to be generated automatically, applying the SAA.ACT "decoding" rules, as defined in the Digital NOTAM Specification. It can serve two main purpose:

  • offer an event description ready to use in advanced pre-flight briefing applications. Note that the text is written using both upper and lower case, as necessary in order to improve the readability of the text;
  • backwards compatibility with the current NOTAM system. The event:NOTAM element contains all the fields of an ICAO NOTAM and therefore it can be used in order to generate a NOTAM message for distribution over AFTN. In this situation, the event:text will have to be converted to upper case for compatibility with the AFS/AFTN limitations.

Complementary Digital NOTAM data

The example discussed above is a minimal Digital NOTAM encoding in the sense that it provides strictly the data that belongs to the event - the Airspace TEMPDELTA and the Event BASELINE. The Airspace affected is identified by its gml:identifier (UUID value). An application that represents graphically the Airspace activation would have to be also provided with baseline data for the Airspace, including its geometry, name and other relevant characteristics. If necessary, the Digital NOTAM message may be enriched with some baseline information so that the graphical representation (for example) can be done using only the Digital NOTAM message, without the need for accessing a reference static data source.