 |
|
 |
Equal coverage for static and dynamic data
|
|
|
Modularity and extensibility
|
|
|
Flexibility of messages and exchange scenarios |
|
|
|
AIXM is able to communicate both permanent changes, such as those that occur at AIRAC cycles and temporary situations, typically promulgated through NOTAM. This required the introduction of an exhaustive temporality model into AIXM, at feature level.
|
|
|
There are two levels at which aeronautical feature instances are affected by time:
|
|
Every feature has a start of life and end of life
|
|
|
The properties of a feature or the target of any feature relationship can change within the lifetime of the feature. |
|
|
|
AIXM 5 uses the following terminology in its temporal model:
|
|
Baseline – The state of a feature and all of the feature properties as a result of a permanent change. The Baseline state of a feature also exists when the feature is initially created. The baseline state lasts until the next permanent change. |
|
|
Version – The state of a feature and all the feature properties during the time period between two changes. |
|
|
Permanent Delta – A set of properties that have changed or will change permanently. The permanent delta will result in a new baseline.
|
|
|
Temporary Delta – A set of values for one or more feature properties that are effective for a limited time. The result is a temporary change to an underlying feature baseline. |
|
|
|
| The temporal model can be explained best in a diagram. The diagram below shows changes to a navigation aid between one AIRAC cycle and the next. In this example, navaid AML has a frequency change from 112.0 MHz to 113.2 MHz. The workflow for this change might involve the following steps: |
|
|
Schedule permanent change to coincide with update cycle |
|
|
Shutdown AML before the upgrade
|
|
|
Change the frequency temporarily and start AML in test mode to flight check
|
|
|
Make the frequency change permanent |
|
|
|
This involves two NOTAMs.
|
|
|
|
|
|
Modularisation and Extensibility |
A data modeller might be interested only by a limited number of features to model a domain. For example, when designing a tool to chart aerodromes, the en-route features would not be needed.
Modularisation allows for the easy re-use of parts of AIXM without having to deal with the complexity of the whole standard.
Third parties can expand the model, adding new features, additional properties or domain values for a local application.
This, in turn, allows concepts of local interest to be handled in a standard way without affecting the global interoperability. Place names in a local language are a typical example of a local extension.
|
|
|
Earlier versions of the AIXM standard had two message formats in which to exchange data: Snapshot and Update. While generally sufficient for applications like a regional database, these have been proven insufficient for advanced applications such as:
|
|
WFS (Web Feature Service)
|
|
|
Digital NOTAM |
|
|
Procedure Design packets |
|
|
Automated charting data packets |
|
|
|
Under AIXM 5, user communities and applications have the possibility to design their own message formats. The messages can use the AIXM pool of features.
Users can also agree on the scenarios in which these messages are used.
|
|
