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.
The association of the Event with ContactInformation enables the provision of a phone number, e-mail address or web site which could be consulted for additional information about the situation notified, in particular when the Event extension is used for data origination.
The association with Unit is meant to enable a simplified coding of the minimal metadata required by ICAO for digital AIS data sets, without the need to use a complete metadata (ISO 19139) schema.
An Event may concern zero or more AirportHeliport and/or zero or more Airspace. The purpose of these associations is to enable quick sorting/filtering of the Events that may operationally affect the identified airport/heliport or airspace. 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 by the system that supports the digital data coding. 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.
Note: The Event is a regular AIXM feature, thus having its own TimeSlice(s). However, as the Event is typically used for coding information about changes and temporary situations, its lifetime is in general known from the beginning. Therefore, in most situations, a single BASELINE will be coded for the Event. No use case was yet identified for an Event TEMPDELTA TimeSlices.
The UML classes and data types created for the Event extension are provided in the attached AIXM_5.1.1_EventExtension_2.0_Draft_20230324.eap (Sparx Enterprise Architect) file.
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.
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 "j", 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-j.
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: