In this example, a permanent change leads to updates of AIS products, such as AIP and charts. From the AIXM data point of view, such changes are coded as AIXM feature TimeSlices with interpretation BASELINE/PERMDELTA. Sometimes, such changes are initially announced by NOTAM or AIP SUP, when an operationally significant permanent change occurs on short notice. The following diagrams present the Event coding aspects that are relevant for this scenario.

Initial situation

Let's suppose that the initial situation consists in a BASELINE TimeSlice 1.0, with an indeterminate end of validity. This could be, for example, a VOR navaid equipment.


Permananent change directly in AIP/chart update

Let's assume that the VOR frequency is planned to be changed at a specified AIRAC cycle date. It will be published directly in the AIP (or in a data set).

This requires a new BASELINE 2.0 for the VOR, becoming effective at the date when the change occurs. A correction BASELINE 1.1 is also coded, in order to give an end of validity to the previously active BASELINE 1.0, as indicated on the diagram to the right,

The Event coded in the association with this change will have a limited lifetime:

  • its validity starts at the effective date of the frequency change, which is also the start of validity of the VOR equipment BASELINE 2.0
  • it remains valid for as long as it is considered necessary to have the Event data available for notification, for example in pre-flight information bulletins. This is typically 14 days, similar to Trigger NOTAM validity.

The Event is associated with one or more AISProduct that show the changed VOR frequency value - AIP AMDT and eventually some charts or even data sets. 

Permanent change first by PERM NOTAM, then incorporated in AIP/chart update

It may happen that the VOR frequency change needs to take place immediately, for example in order to eliminate radio interferences. In this case, the change is first notified with a NOTAM PERM and later incorporated in the AIP and charts.

From the data coding point of view, the same VOR feature TimeSlices need to be coded as in the example above.

The only difference is in the Event coding:

  • first, the Event is coded with a BASELINE TimeSlice 1,0, starting at the effective date of the VOR frequency change and with an undetermined end of validity;  
  • the Event is for the moment associated with an AISMessage, a NOTAM PERM

When the information about the change is included in the AIP/charts, the Event needs to be updated:

  • The Event BASELINE 1.0 is corrected with an end of validity (BASELINE 1.1), equal to the date/time when the PERM NOTAM is cancelled. This is also associated with the NOTAMC that cancels the NOTAM PERM at the date when the change is incorporated in the AIP, charts, etc.  By exception to the AIXM Temporality rule TS_017, this NOTAMC is also associated with the correction TimeSlice for the Event (BASELINE 1.1).

  • No labels