Chain of events

Event dependencies

There exist many operational dependencies between situations that can affect various aeronautical features. For example:

navaid outages can trigger the unavailability of certain routes or instrument approach procedures;
the creation or the activation of restricted areas can trigger the closure of certain route segments or the deactivation of other areas;
the closure of a runway portion can trigger changes in the runway declared distances, changes to landing minima, etc.

The general approach taken in the Digital NOTAM Specification is to define distinct scenarios for events that concern a subject and a condition. This allows identifying the data input requirements and also the data verification rules for each scenario. It also keeps the length of the scenario definitions and rules within reasonable dimensions. For example, the RWE.CLS scenario provides the coding rules for the closure of a runway element, while the RDD.CHG scenario provides the coding rules for changes to declared distances. A runway portion closure almost always causes a change in the declared distances for both runway directions. In one landing and take-off direction it might also cause a threshold displacement. The model allows for such event dependencies to be coded explicitly. This has the advantage that it is possible to define data coding rules that check if a consequence Event was also coded depending also on the existing baseline data.

Event schema support for associations between events

An Event (AIXM feature) may have two kinds of associations with other Event:

isCausedBy - which models event dependencies, such as the one described above - a declared distances change that is triggered by a runway portion closure. This is used when there is a strong connection between the two events. If the cause disappears, the consequence disappears as well. Therefore, they must have the same lifetime.
isPartOf - allows grouping events that might not be direct consequences of each other when they are part of the same operational project. For example, work at the end of a runway that might include a threshold displacement, a temporary work area and eventually some taxiway closures that evolve as the work progresses. The lifetime of the child event is at maximum equal to the lifetime of the parent event, but it could also be shorter. There are no predefined coding scenario rules for the inclusion of events. This depends on the actual operational situation.

These associations are not mutually exclusive. The essential difference between them is that the event dependencies are specified as event coding rules. For example, the RWE.CLS will contain a rule that verifies the existence of one or more dependent RDD.CHG events). There are no predefined rules for associating events into a parent event. Such associations are left to the discretion of the data providers.

Impact on scenario coding rules

Rules that indicate the need for a consequential event appear in the relevant Digital NOTAM coding scenario in the following generic format:

"If ... (baseline data condition) ... and if ... (operational consequence check) ... then a consequence ... (the identifier of the consequence scenario)... shall also be coded and shall include a reference to the current event with role 'causeEvent'.", where:

(baseline data condition) is typically a verification of the existence of baseline data for the feature that might be subject to a consequence event
(operational consequence check) represents a decision that needs to be taken by relevant operational people, who need to validate that there actually exists an impact on the dependent data
(the identifier of the consequence scenario) - represents the unique identifier of the dependent scenario.