Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 30 Next »

Editorial Note

This page and any eventual child pages will be moved to the AIXM Extension Space. This will explain  the purpose, scope of the Event extension and it will provide the UML model and the link to the XSD.

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 Overview

The Event class

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

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 operation;
  • scenario = The identifier of a predefined 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 predefined 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 description of the event, with the possibility to include maps, diagrams and formatted text.

An Event may concern zero or more AirportHeliport and/or zero or more Airspace. The purpose of these associations is to identify the locations that are operationally related to 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 involvement and cannot be done simply on geographical proximity rules.

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 two "self-association":

  • isCausedBy - 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;
  • isPartOf - 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.

AIXM Feature TimeSlice association with Event

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 genuine 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 (belongsTo) from the feature TimeSlice towards the Event class. The extension mechanism used here is explained in the rules for extensions, under the "All Features Extension" section.


Event associations with AIS Products

Another element of the Event schema is the possibility to identify the AIS Products (NOTAM, AIP Amendment, AIP Supplement, Data Set, etc.) that provide the event data, as shown in the UML class diagram to the right.

Each Event isNotifiedBy zero or more NOTAM, SNOWTAM or ASHTAM, as appropriate. This group of associations enable the inclusion all the NOTAM, SNOWTAM or ASHTAM message fields in the AIXM encoding. This was one of the design objectives of the Event Schema, in order to facilitate the transition from the Text NOTAM towards the Digital NOTAM. In addition, the text translation of the Event can directly be used for for applications, such as pre-flight briefing bulletins.

Another possibility is that the data contained in the Event coding isProvidedAs zero or more AISProduct, such as an AIP AMDT, a chart or a data set. The AISProduct is not a feature, but a complex property associated with the Event. It contains the information necessary to identify the AIP AMDT, AIP SUP, Data Set, etc. concerned (number, issuing authority, start of validity, etc.).

Several Events could include information that is embedded in same AIP AMDT, for example. The same Event could be published in two or more AIP, in case it affects features located on the State border, for example. Therefore, the association allows many AISProduct to be linked with the Event.

An Event may also be issuedBy an 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.



Event extension data types

The data types that are defined in support of the Event schema are presented below. Where possible, data types from the core AIXM schema are being used, such as ValPercentType, even if the format of the data is not identical to its presentation in an AIS product. However, the objective was to minimise the number of additional data types defined for the Event schema.

Note that a CodeRunwayConditionType is also added in order to support the strict use of the values 1, 2, 3... 6 for the Runway Condition Code of the new SNOWTAM. This list of values is expected to be part of the core AIXM model in the next version (AIXM 5.2).


UML Model

The UML classes and data types created for the Event extension are provided in the attached AIXM_5.1.1_EventExtension_2.0_Draft_20210210.eap (Sparx Enterprise Architect) file.

Warning

The Event extension definition file attached is still missing definitions for some classes and attributes. Apart from that, the .eap file is complete and was used for generating the Event Extension Schema (XSD) provided below.

XML Schema

The final version of the Event Extension 2.0 schema (XSD) will be provided here: www.aixm.aero/schema/5.1.1/event. For the moment, two draft versions are available:

  • version "f", which is used in particular for the DENOT Trial and for the example available on gitHub. This version is practically the initial Event 1.0 schema, but translated to the AIXM 5.1.1 context.
  • version "h", which is the latest draft, corresponding to the UML model detailed on this page and generated from the attached .eap file. This is located at www.aixm.aero/schema/5.1.1/event/version_5.1.1-h. 

Usage and applications

The Event extension is used in the coding of both temporary situations (such as a navaid that is unserviceable) and permanent updates of the aeronautical data (such as information about a new runway). The usage rules are provided at two levels:

  • No labels