/
Event update or cancellation

Event update or cancellation

Owned by POROSNICU Eduard
Last updated: 2024 Jan 29

Introduction

The EUROCONTROL Guidelines Operating Procedures for AIS Dynamic Data (OPADD), Ed.4.1, section 2.4 provides rules for the creation of NOTAMR and NOTAMC. The update or cancellation of a Digital NOTAM Event will also trigger the issuing of equivalent NOTAM messages. Therefore, the rules for Event update and cancelation need to be aligned with the NOTAMR and NOTAMC provision rules.

The OPADD rules cater for two key aspects:

  • whether the temporary feature condition described in the Event/NOTAM remains the same (but with a different validity period) or it changes;
  • whether the Event is already active or the activity period starts in the future.

This leads to the situations described on this page. 

Note: although in general this Specification does not include the NOTAM generation rules, in this particular case it was considered useful to mention the NOTAM that are issued, in order to facilitate and justify the alignment with the current NOTAM practices.

Active Event (NOTAM in force)

The diagram to the right side indicates the initial situation. The Event has a valid time starting at "T-start" and ending at some time "T-end" in the future. This could also be an estimated termination. The Event is coded with an initial BASELINE TimeSlice 1.0, which corresponds to the TEMPDELTA TimeSlice 1.0 coded for the feature affected by the Event. A NOTAMN is associated with the Event BASELINE 1.0.  

The current time is somewhere in between the start and the end of lifetime of the Event.

In this case, the following general OPADD rule applies:

2.4.1.5 "The date-time group in Item B) of a NOTAMR or NOTAMC shall be the actual date and time that this NOTAMR or NOTAMC is created.
i.e. NOTAMR and NOTAMC shall take effect immediately and no future start of coming into force is permitted. The replaced or cancelled NOTAM cease to be valid from the very moment their replacing NOTAMR or NOTAMC are issued. This is done to assure the correct processing in all systems regardless of their design."

This practically means that, even if the Event update or termination information is received in advance from the data originator, the Event cancellation and the equivalent NOTAM are released/issued just when the current time reaches that moment.

Immediate Event termination

This is a relatively common situation, where an Event is terminated with immediate effect. In this situation:

  • for the feature, a correction TimeSlice TEMPDELTA 1.1 needs to be coded, the only change being its modified end of validity, which is the current time.
  • for the Event, an anticipated end of life needs to be coded, which means a correction TimeSlice BASELINE 1.1 that has validTime.TimePeriod.endPosition and its featureLifetime.timePeriod.endPosition set to the current time. However, a NOTAMC needs also to be issued, effective immediately. By exception to the AIXM Temporality rule TS_017, this NOTAMC is also associated with the correction TimeSlice for the Event (BASELINE 1.1).

Example

See DN_AD.CLS_immediate_cancelation.xml (based on the following Digital NOTAM scenario AD.CLS and the following coding example:  DN_AD.CLS_with_daily_schedule_on_baseline_with_schedule.xml)

Modified Event termination (in future)

In this situation, the condition notified in the Event remains unchanged, but it will last shorter or longer as compared to the initial status. The new termination is shown as time "T2" on the diagram to the right.

This should be coded as follows:

  • for the Event, a correction TimeSlice BASELINE 1.1 and a new BASELINE 2.0 need to be coded. The Event BASELINE 2.0 has its validTime.TimePeriod.endPosition and its featureLifetime.timePeriod.endPosition equal with the new " T2" time. The new BASELINE 2.0 also contains the NOTAMR that needs be issued and becomes immediately applicable.
  • for the feature, the coding depends on the presence (and content!) of a schedule in the feature TEMPDELTA 1.0. That's because the OPADD rules for NOTAM schedules require that the start/end of validity (item B and C) are aligned with the first and the last period specified in the schedule. Thus:
    1. if no Timesheet is present in the TEMPDELTA 1.0, then just a correction TimeSlice TEMPDELTA 1.1 needs to be coded, with a modified end of validity. This according to the AIXM Temporality rule TS_017, which allows a correction TimeSlice to have a start of validity in the past, on condition that the only correction made concerns its end of validity;
    2. if one or more Timesheet are present in the TEMPDELTA 1.0 and if any of these need to be modified for alignment with the Event BASELINE 2.0 start and/or end of validity, then a correction TimeSlice BASELINE 1.1 and a new BASELINE 2.0 need to be coded for the feature as well.

Important Note: Due to the potential complexity of the Timesheet data and the difficulty to interpret such information automatically, the decision to choose between (a) and (b) will most likely be made by the human operator who does the data coding. In addition, in a Digital NOTAM editing tool, it would be very difficult (or even impossible) to prevent that the operator does only an editorial modification of the Timesheet data and not a real schedule change (which is not allowed in this case, as that would be considered a "condition change"). Thus, the correct encoding of a Timesheet modification remains the responsibility of the data operator and it is unlikely to be fully automated.

Example

See DN_AD.CLS_modified_future_termination.xml (based on the following Digital NOTAM scenario AD.CLS and the following coding example:  DN_AD.CLS_with_daily_schedule_on_baseline_with_schedule.xml)

(a) No Timesheet modification for the feature TEMPDELTA: 

(a) When an editorial Timesheet modification for the feature TEMPDELTA is necessary, so that the NOTAMR complies with the OPADD rules, in particular 2.3.18.2, 2.3.18.3 and 2.3.18.4:


Immediate modified feature condition

Sometimes, the condition coded in the Event is changed with immediate effect. For example, a runway threshold displacement value or the maximum altitude of an airspace reservation might be changed. This modified condition could affect any property of the feature TEMPDELTA and it could even require that additional properties are coded.

In order to ensure the proper coding and compliance with a coding scenario, a separate Event will be coded for the modified feature condition, as indicated in the diagram to the right. In parallel, the first Event needs to be cancelled with immediate effect, as discussed in the "Immediate Event termination" above.

Note: In order to facilitate the coding of the new Event, tools that support the Digital NOTAM coding might offer the possibility to copy the previous Event as starting point for the new Event. However, if there are too many differences between the previous and the new condition, it might be safer to re-start the coding from the beginning.

This should be coded as follows (see also the diagram to the right):

  • for the initial Event(1), a correction TimeSlice BASELINE 1.1 that changes its end of validity and end of life.
  • a new Event(2) which covers the lifetime of the new situation. This is coded as any other new Event with a given scenario. 
  • for the feature, a correction TimeSlice TEMPDELTA 1.1 and one new TEMPDELTA 2.0 need to be coded. The TEMPDELTA 1.1 remains associated with the initial Event(1).  The TEMPDELTA 2.0 is associated with the new Event(2).

Modified feature condition in future

In this situation, the condition coded in the Event will change, but not immediately. It will stay the same for a while and then it will change at a future datetime, within the period of validity of the initial Event.

Similarly to the scenario above ("Immediate modified feature condition"), the coding of the future change condition is done through a separate (new) Event. This approach is taken in order to simplify the Event timeline and to ensure a proper verification of the scenario (as the future condition could even fall under a different coding scenario).

Similarly to the scenario "Modified Event termination (in future)", this might require the coding of an additional feature TEMPDELTA, necessary for aligning an eventual schedule with the new validity period of the NOTAMR.

This should be coded as follows (see also the diagram to the right):

  • for the initial Event(1), a correction TimeSlice BASELINE 1.1 that changes its end of validity and end of life.
  • a new Event(2) which covers the lifetime of the new situation. This is coded as any other new Event with a given scenario. 
  • for the feature, the coding depends on the presence (and content!) of a schedule in the feature TEMPDELTA 1.0. That's because the OPADD rules for NOTAM schedules require that the start/end of validity (item B and C) are aligned with the first and the last period specified in the schedule. Thus:
    1. if no Timesheet is present in the TEMPDELTA 1.0, then a correction TimeSlice TEMPDELTA 1.1 needs to be coded, with a modified end of validity;
    2. if one or more Timesheet are present in the TEMPDELTA 1.0 and if any of these need to be modified for alignment with the Event BASELINE 2.0 start and/or end of validity, then a correction TimeSlice TEMPDELTA 1.1 and a new TEMPDELTA 2.0 need to be coded, covering the new validity of the initial Event. The same Important Note applies here, as in the "Modified Event termination (in future)" above.
    3. then, the new condition is coded in a separate TEMPDELTA (2.0 or 3.0, depending on what was necessary above), covering the validity of the new condition.

(a) No Timesheet modification for the feature TEMPDELTA 1.1:

(a) When an editorial Timesheet modification for the feature TEMPDELTA 1.1 is necessary, so that the NOTAMR complies with the OPADD rules, in particular 2.3.18.2, 2.3.18.3 and 2.3.18.4:


Inactive Event (NOTAM not in force) updated and cancellation

In this situation, it is assumed that the current time is before the start of life of the Event, as indicated in the diagram to the right. As the condition notified in the Event will no longer occur in reality, then both the Event TimeSlice and the feature TEMPDELTA TimeSlice need to be moved out of the timeline, as explained in the AIXM Temporality Document, version 1.1, section 4.4.8 for "abandoned changes":

  • for the Event, a correction TimeSlice BASELINE 1.1 with an empty gml:validTime with nilReason='inapplicable' and an empty aixm:featureLifetime with nilReason='inapplicable';
  • for the feature, a correction TimeSlice  shall be coded having the same sequenceNumber as the initial TEMPDELTA, an increment correctionNumber ('1'), an empty gml:validTime with nilReason='inapplicable';

If necessary, a new Event will be coded, corresponding to the new situation that needs to be notified.