Event Extension

Purpose and scope

The purpose of the Event Extension is to enable the digital encoding of the aeronautical data that concerns identifiable operational situations, which result in the temporary or permanent alteration of one or more aeronautical information features or of their properties. Such operational situations can range from a simple runway closure or navaid unavailability to a complex change of the route structure or a military exercise. 

The Event concept is not new in the aeronautical information domain. An “embryo” of the concept is used in the European AIS Database (EAD) in the form of a Private/Public Slot entity. The EAD slots allow grouping together the changes that have a common operational reason and the same effective date. The Eurocontrol Network Manager (NM) CACD system is using a relatively similar “project” concept in order to plan in advance the information about complex situations, such as large military exercises, Olympic Games, etc. when they have a significant impact on the Network operations.

The Event extension provides the following capabilities:

• provision of information about the event itself, such as name, activity, summary, contact details;
• identification of an eventual pre-defined coding scenario, in order to define business rules that concern that scenario and enable the verification of the coding quality. This supports the use of the Event concept in particular for the Digital NOTAM encoding, where very detailed scenarios are identified for situations such as navaid unserviceable, airspace activation, new obstacle, etc.
• identification (by association) of all the data elements that are encoded in relation with the event;
• the possibility to indicate the location of the event in relation with one or more airspace and airports/heliports;
• the possibility to specify common metadata for a group of Timeslices, from different features; for example, they could have the same reason for coming into existence and therefore common metadata;
• indicate which AIS document (NOTAM, AIP, SUP, etc.) includes the same information in a printed/message format. This allows to include digital representation of the AIP AMDT, AIP SUP, AIC or the full content of the NOTAM message;
• allows to establish a hierarchy of Events, by establishing a whole/part association;
• allows to indicate logical dependencies between events, such as an event that is the consequence of another event;
• allows very early information to be encoded about Events that will take place later in the future (the long term planning aspect)

The Event concept was initially developed as part of the Digital NOTAM Event Specification (version 1.0) and validated through SESAR trials and initial Digital NOTAM deployments, such as in particular in the United States Federal NOTAM System (FNS). An extension of the initial Event concept was developed in support for the long-term planning needs of the Civil-Military Airspace Management (eASM) process. The experience gathered with these earlier implementations and developments were taken into consideration into this specification.

The Event Extension is focused on the aeronautical information domain and it is built on the foundation of the Aeronautical Information Exchange Model (AIXM). It shall be kept in mind that one of the design objectives for AIXM (after version 5.0) is to model the full lifetime of aeronautical information features, including creation, permanent and temporary changes, decommissioning, etc. without recourse to any specific message. This enables the use of AIXM encoded data in combination with generic data exchange standards, such as Web Feature Services (WFS). An Event is also an AIXM feature, therefore it can also have a full lifecycle as any other aeronautical feature: it can be created, changed, cancelled, etc.
The Event Concept is targeted primarily for application in systems that support the encoding and processing of Digital NOTAM and automatic generation of AIP/charts content. 

UML Model

The Event class

The UML model that defines the Event class and its main properties is shown in the following diagram.

The main element is the "Event" feature, defined as “an operational situation that results in the temporary or permanent change of the properties of one or more aeronautical information features” with the following attributes:
name - “a title by which the event is known to people involved in aeronautical operations”;
designator - “a code by which the event is identified in applications and systems used in aeronautical operations”
digital - “an indication that the information is provided as digital data, to the full extent permitted by the coding rules and by the current data model, as opposed to free text annotations”;
scenario - “the identifier of a pre-defined scenario that provides the data encoding rules for a specific operational situation”. Together with the version attribute (see below), this allows identifying the set of data verification rules that may be applied in order to check the correctness of the coding.
version - “the version of the pre-defined coding scenario (usually the version of the document that contains the scenario)”;
estimatedValidity - “for Events that have an indeterminate end of life, it indicates a date and time by which the event is expected to end.” If the estimated end of life is reached without any other update of the Event data, the Event is considered to be still valid.
activity - “a short indication of the type of activity or operational situation that makes the event”
summary - “a descriptive summary of the event, with the possibility to include maps, diagrams and formatted text”.
An Event may be associated with one or more AirportHeliport and/or one or more Airspace. The purpose of these associations is to identify the locations that are operationally concerned by the event. This is derived from the current pre-flight information bulletin practice, in which information is organised by airport/FIR. In many cases the airspace or airport concerned may be identified automatically. However, there are situations, such as remote training areas used by military flights, where identifying the airport concerned might require human expertise.
In some particular situations, it might be interesting to also associate the Event with a smaller area, such as an area used for military training. This allows the identification of events that need to be included in the pre-flight information briefing for a military flight inside the area concerned.
The Event also has a "self-association" that allows encoding event dependencies, in which one event is the cause of other events. For example, the temporary displacement of a runway threshold could trigger changes in approach and departure procedures, which could be encoded as separate events.
A second self-association allows encoding groups of events, which are part of the same operational project, but which are not mandatory the consequence of each other. For example, the data about a large military exercise, seen as the root event, can be organised in sub-events such as airspace reservation, route closures, airport usages, etc. Usage rules for these self-associations are provided further in this specification.
The information about the actual change brought by the Event to the properties of the affected AIXM features is encoded as TimeSlices of the relevant AIXM features. This is the real digital Event encoding part of the schema. In order to relate the AIXM feature TimeSlices with the Event to which they belong, an extension for each AIXM feature is declared in the "event" namespace. This consists in an association from the feature TimeSlice towards the Event class, as shown in the Event UML class diagram.
Most events will need a single feature TimeSlice to be provided. For example, the activation of a temporary restricted area will require a single Airspace TimeSlice of type TEMPDELTA. However, there might exist events that require several TimeSlices to be encoded in several different features. For example, the establishment of a new obstacle (temporary or permanent) requires two AIXM features to be encoded or modified:
first, a new VerticalStructure needs to be encoded;
second, associations between the affected ObstacleArea(s) and the new VerticalStructure might need to be established.
An Event may also be associated with the Unit that is the provider of the Event information. This information is required by the ICAO PANS-AIM as part of the minimal metadata to be provided with the digital AIS data sets. A direct association between Event and Unit allows to avoid using the much more complex ISO 19139 metadata schema for such small digital data sets as is the case for Digital NOTAM.

XML Schema

Usage and applications