Digital AIM Training - AIXM Notes: EUROCONTROL Copyright 2011

Digital AIM Training - AIXM Temporality Model Definition A model that incorporates the concept of time at feature level! Key assertions All features are temporal with start of life and end of life Example, A new air traffic control sector All features can change over time Example, A VOR changes frequency AIXM Temporality Model Relates feature properties to the time extent in which they are valid Provides various means to describe the time extent A temporal model is one that incorporate the concept of time. In AIXM we recognize that all aeronautical data is temporal. Aeronautical features have a start of life and end of life. In addition aeronautical features can change over time. The AIXM temporality model is used to describe when features are valid and when feature properties change over time. All this is described in the AIXM temporality concept document, which is available on the www.aixm.aero site. The next few slides will provide a short summary of this concept. Note that temporality is one of the most complex aspects of AIXM. Its correct understanding and application is critical, in particular for Digital NOTAM applications. Notes: EUROCONTROL Copyright 2011

Features have time varying properties Digital AIM Training - AIXM Features have time varying properties The first step in the construction of the AIXM temporality model is represented by this diagram, which shows the values of a feature’s properties (P1, P2, … P5) along a timeline. Notes: EUROCONTROL Copyright 2011

The basic Time Slice model Digital AIM Training - AIXM The basic Time Slice model We can mark the times where the properties change with vertical lines. We can see that at one time P1 changed from value 1 to value 2. We can call this line an event – it is an event that led to the change of property P1. Events occur at instants of time when one or more properties change. Here we quite literally slice up the time based on when the values of a property change. In order to describe the feature properties during states and events, the time varying properties of every feature are encapsulated in a container called “Time Slice”. The history of the feature is described with “state” Time Slices, each containing the values of the time varying properties between two consecutive changes (events). Each Time Slice has maximum one value for each property and one specified validity period. Notes: EUROCONTROL Copyright 2011

The basic Time Slice model Digital AIM Training - AIXM The basic Time Slice model You can now see the different states of this feature. The transition between states happens because of an event. In this example the states can become BASELINE timeslices. Instead of grouping property values in Time Slices, another approach could be a temporal model where every property gets it own validity period. The first argument against this approach is that, in general, the properties of a feature do not change independently from each other. There exist operational constraints that link the values of some properties with the values of other properties. Therefore, several properties would have anyhow to be grouped together, with a common validity period. The second reason is that changes in the aeronautical world are regulated by the AIRAC cycle. This imposes that significant operational changes occur at predefined dates, in order to ensure the predictability of the aeronautical environment and to allow time for the users to accommodate with the changes. In general, aeronautical features have stable property values between AIRAC cycle dates. Therefore, grouping together the properties in Time Slice with a unique validity period is a simplified temporal model, which supports well the operational requirements. Notes: EUROCONTROL Copyright 2011

Digital AIM Training - AIXM PERMDELTA TimeSlices In order to encode the change that makes the difference between two consecutive baselines, the model also introduces the concept of “PERMDELTA” Timeslice. This is a “delta” (a difference) and “perm” (permanent), meaning that it introduces a static change. PERMDELTA are events, with a time instance validity time. Note that the creation of a feature is also encoded as a Timeslice – the difference between something and nothing. Notes: EUROCONTROL Copyright 2011

Digital AIM Training - AIXM Temporary events (digital NOTAM) To this “static” model we need to add the idea of NOTAMs. These apply temporary changes. They are modelled as an overlay. When the temporary timeslice ends the property revents to the permanent timeslice value. Therefore, we now have three kinds of Time Slices BASELINE = describes the feature state (the set of all feature’s properties) as result of a permanent change; PERMDELTA = A kind of Time Slice that describes the difference in a feature state as result of a permanent change; TEMPDELTA = describes the transitory overlay of a feature state during a temporary event. Notes: EUROCONTROL Copyright 2011

Current status of a feature Digital AIM Training - AIXM Current status of a feature We can expand the temporality model and include some additional timeslices that can be useful. We can identify a “snapshot” as the state of the feature at a time instant. It is the result of combining the baseline timeslice with any temporary timeslices in effect at the “snapshot” time. SNAPSHOT = describes the state of a feature at a time instant, as result of combining the actual BASELINE Time Slice valid at that time instant with all TEMPDELTA Time Slices applicable at that time instant. Notes: EUROCONTROL Copyright 2011

Temporality – something different Digital AIM Training - AIXM Temporality – something different Another less formal way of explaining the temporality concept is presented in this slide. Let’s consider the case of a TV shop: new TV arrives and is put on sale for 999 Euro; this is a PERMDELTA (new TV) which instantiates a first BASELINE for that TV (with a price of 999 euro); this remains valid for some time Then, it’s sales time and the price of the TV is temporarily lower by 25% for one month; this is a TEMPDELTA; the BASELINE price is still 999 Euro; but if you want to know the actual price you have to merge the BASELINE information (999 Euro) with the TEMPDELTA (-25%); this is a SNAPSHOT – the actual price When the sales period is over, the TEMPDELTA is no longer valid and the price of the TV is back to 999 Euro Towards the end of the commercial life of the TV, a permanent price reduction is put in place to get rid of the stocks, before the arrival of a new model; this is a PERMDELTA that instantiates a new BASELINE (899 Euro is the new price); this will remain valid until the TV is no longer on sale Notes: EUROCONTROL Copyright 2011

AIXM Temporality document Digital AIM Training - AIXM AIXM Temporality document The AIXM Temporality Concept document available on www.aixm.aero also contains a detailed analysis of other aspects that need to be considered when modelling the evolution of the properties of a feature in time, from creation until its complete withdrawn. Some of these topics are listed below, but will not be further detailed in this course: Undetermined end of validity Multiple occurring properties (such as “cityServed” for an AirportHeliport) Changes of complex properties (such as “surface characteristics” for a Runway) Identifying the feature affected Cancelling a time slice (for example, correction of pending data) The complete Temporality Concept document is available for download from the www.aixm.aero Web site. Notes: See www.aixm.aero EUROCONTROL Copyright 2011

Example – abstract Start of life

Example - abstract Permanent Changes Attention: “DELTA” for complex properties (objects) – see section 3.4 “DELTA” for multi-occurring properties – see section 3.5

Example - abstract Temporary change (NOTAM)

Example - abstract End of life

Properties with schedule Digital AIM Training - AIXM Properties with schedule The Temporality Model described up to this point works well for features that have properties with constant values during their time of validity. In some cases, one or more properties of a feature may have their own cyclic variation in time according to an established schedule. For example, a navaid can be operational during day time and unserviceable during night time; a restricted airspace could be active every day from 09:00 till 17:00; etc. To model such situations, the concept of “properties with schedule” has been introduced in AIXM 5.1. The idea is to associate the properties that have cyclic varying values with a “Timesheet” that describes the times when each value is applicable for those attributes. The concept of Timetable/Timesheet already existed in AIXM 3.x and 4.x. It was inherited as such in AIXM 5.0. At the feature level, all the properties that change according to an established schedule must be isolated in a separate class, as illustrated below with class NavaidOperationalStatus. This class inherits from an abstract class called “PropertiesWithSchedule”. Notes: EUROCONTROL Copyright 2011

An Example: Navaid frequency change Digital AIM Training - AIXM An Example: Navaid frequency change AML Navaid undergoes an upgrade that changes its frequency from 112.0 MHz to 113.2 MHz… This slide illustrates the temporal model for a hypothetical NAVAID called AML. Imagine that the NAVAID is undergoing scheduled maintenance that will result in a new Frequency. Before the frequency change the AIP publishes a baseline of the AML NAVAID indicating all of its properties. Before maintenance begins the AML NAVAID is taken offline for upgrades. This operational status change results in TemporalDelta1. Once the frequency change is made there is a permanent delta indicating a frequency change. A new Baseline starts at the new AIRAC cycle. Finally after the frequency change the NAVAID is placed in operational status = test. A second temporary delta is created for this operational status change. In all this scenario generates 4 versions of the NAVAID. A version is created at the start and end of each delta. Notes: EUROCONTROL Copyright 2011

Digital AIM Training - AIXM Questions? Notes: EUROCONTROL Copyright 2011