ID: | AIXM-473 |
target version: | AIXM 5.2 |
version: | 1.0 |
last updated: | 04 AUG 2021 |
status: | PROPOSED |
The ApproachCondition class is enhanced with additional properties (landingPrecisionCategory, satelliteApproachType, specialAuthorisation, minBaroVNAVTemperature, maxBaroVNAVTemperature, stepDownFix association to TerminalSegmentPoint) in order to allow coding of sets of minima for the same FinalLeg. As a consequence, the landingSystemCategory, guidanceSystem and minimumBaroVnavTemperature are removed from the FinalLeg. The multiplicity of the association with the Minima class is increased and the association to Aircraft Characteristics is moved at the Minima class level. The properties of the Minima class that support the coding of various types of minima are refactored, separate attributes being introduced for the coding of OCA/OCH, MDA/MDH and DA/DH. Separate attributes are introduced in order to code military specific minima, runway visual range and the militaryMinima is replaced with a militaryCeiling attribute.
See https://aixmccb.atlassian.net/browse/AIXM-308, https://aixmccb.atlassian.net/browse/AIXM-119, https://aixmccb.atlassian.net/browse/AIXM-306
Several ‘minima lines’ may appear on an Instrument Approach Procedure chart. According to ICAO PANS-OPS, these can have two meanings:
In the current model (see the first UML class diagram further down in this document), the Minima are associated with the FinalLeg, through the intermediate of the ApproachCondition. Therefore, the possibility to specify several sets of minima for the same Instrument Approach Procedure is practically limited by the properties (associations and attributes) offered by the ApproachCondition class:
The first three bullet points typically correspond to “minima table lines”, while the aircraft landing category (coded with AircraftCharacteristics) corresponds to “minima table columns”. The association with AircraftCharacteristics means that the ApproachCondition needs to be coded separately for each aircraft landing category that has a different set of minima.
The Minima class has attributes that can be used for the coding of various types of Minima (OCA/OCH, MDA/MDH, DA/DH) and their specificities, such as military, RVR required, etc.
The following diagram shows the classes, properties and lists of values from the current AIXM 5.1.1 model, which are relevant when discussing the rationale for this change proposal:
The following issues affect the usability of the current ApproachCondition model for coding the real world data:
A related issue concerns the guidanceSystem attribute of the FinalLeg, which is an unnecessary duplication of the approachType attribute of the InstrumentApproachProcedure, as the type of procedure is the same as the final approach type. The two lists of values are almost identical, which is also an indication of the duplication.
In order to correct these model issues and limitations, the ApproachCondition needs to be extended with additional properties that allow it to identify a set of minima (presented as a “minima line” in the minima tables of Instrument Approach Charts). As a consequence, the current FinalLeg properties that identify “minima lines” (guidanceSystem and landingSystemCategory) need to be removed from the model. The Minima class needs to be completely reviewed in order to allow coding multiple types of minima values and their associated conditions without multiplying the ApproachCondition.
[FWD_MAP_1:1] Data mapping is possible and no data loss occurs when data is exchanged from a system (A) that uses AIXM 5.1.1 for output towards a system (B) that uses AIXM 5.2 for input.
[BWD_MAP_LOSS] Data mapping is possible, but some data would be lost (or converted into Notes) when data is exchanged from a system (B) that uses AIXM 5.2 for output towards a system (A) that uses AIXM 5.1.1 for input.
In the UML model:
The following UML class diagram shows the main elements of the new model for minima. The new/changed elements are indicated with in blue, the deleted elements are indicated in red:
Note: for completeness sake, the diagram also includes relevant changes coming from other Change Proposals, such as the modified list of values for the CodeApproachType, changed attributes related to PBN, etc.
The following algorithm shall be applied:
AIXM 5.1(.1) | AIXM 5.2 | |
finalApproachPath | finalApproachPath | satelliteApproachType |
STRAIGHT_IN | STRAIGHT_IN | - |
CIRCLING | CIRCLING | - |
SIDESTEP | SIDESTEP | - |
OTHER | OTHER | - |
OTHER:STRAIGHT_IN_LPV | STRAIGHT_IN | LPV |
OTHER:STRAIGHT_IN_LVAV | STRAIGHT_IN | LNAV |
OTHER:STRAIGHT_IN_LVAV_VNAV | STRAIGHT_IN | LNAV_VNAV |
OTHER:STRAIGHT_IN_LP | STRAIGHT_IN | LP |
OTHER:STRAIGHT_IN_GLS | STRAIGHT_IN | GLS |
OTHER:STRAIGHT_IN_RNP | STRAIGHT_IN | RNP |
OTHER:CIRCLING_LPV | CIRCLING | LPV |
OTHER:CIRCLING_LVAV | CIRCLING | LNAV |
OTHER:CIRCLING_LVAV_VNAV | CIRCLING | LNAV_VNAV |
OTHER:CIRCLING_LP | CIRCLING | LP |
OTHER:CIRCLING_GLS | CIRCLING | GLS |
OTHER:CIRCLING_RNP | CIRCLING | RNP |
OTHER:SIDESTEP_LPV | SIDESTEP | LPV |
OTHER:SIDESTEP_LVAV | SIDESTEP | LNAV |
OTHER:SIDESTEP_LVAV_VNAV | SIDESTEP | LNAV_VNAV |
OTHER:SIDESTEP_LP | SIDESTEP | LP |
OTHER:SIDESTEP_GLS | SIDESTEP | GLS |
OTHER:SIDESTEP_RNP | SIDESTEP | RNP |
AIXM 5.1(.1) | AIXM 5.2 | ||||
altitude | altitudeCode | obstacleClearanceAltitude | decisionAltitude | minimumDescentAltitude | annotation.Note |
value | OCA | value | - | - | - |
value | DA | - | value | - | - |
value | MDA | - | - | value | - |
value | OTHER | - | - | - | purpose=“OTHER:FORWARD_MAPPING”; translatedNote.LinguisticNote.note=”altitude” <value of the altitudeCode>, <value of the altitude>, <value of the altitude.uom>; |
AIXM 5.1(.1) | AIXM 5.2 | ||||
height or militaryHeight | heightCode | obstacleClearanceHeight | decisionHeight | minimumDescentHeight | annotation.Note |
value | OCH | value | - | - | - |
value | DH | - | value | - | - |
value | MDH | - | - | value | - |
value | OTHER | - | - | - | purpose=“OTHER:FORWARD_MAPPING”; translatedNote.LinguisticNote.note=”height” <value of the heightCode>, <value of the height/militaryHeight>, <value of the height/militaryHeight.uom>; |
AIXM 5.1(.1) | AIXM 5.2 | |||
visibility | mandatoryRVR | visibility | runwayVisualRange | annotation.Note |
value | No or NIL | value | - | - |
value | Yes | - | value | - |
value | OTHER | value | - | purpose=“OTHER:FORWARD_MAPPING”; translatedNote.LinguisticNote.note=”mandatoryRVR” <value of the mandatoryRVR>; |
The following algorithm shall be applied, in the order specified below:
AIXM 5.2 | AIXM 5.1(.1) | ||||
obstacleClearanceAltitude | decisionAltitude | minimumDescentAltitude | Minima instance | altitude | altitudeCode |
value | - | - | [1] | value | OCA |
- | value | - | [2] | value | DA |
- | - | value | [3] | value | MDA |
AIXM 5.2 | AIXM 5.1(.1) | ||||
obstacleClearanceHeight | decisionHeight | minimumDescentHeight | Minima instance | height | heightCode |
value | - | - | [1] | value | OCH |
- | value | - | [2] | value | DH |
- | - | value | [3] | value | MDH |
AIXM 5.2 | AIXM 5.1(.1) | |||
visibility | runwayVisualRange | visibility | mandatoryRVR | annotation |
- | value | value | Yes | - |
value | same value | value | Yes | - |
value | different value | value | Yes | purpose=“OTHER:BACKWARD_MAPPING”; translatedNote.LinguisticNote.note=”runwayVisualRange” <value of the runwayVisualRange> <value of the runwayVisualRange.uom> |
Mapping example
(Note: for mapping test data see: https://github.com/aixm/mapping_52_511/tree/master/AIXM-xxx)
AIXM 5.2 | AIXM 5.1(.1) | ||
---|---|---|---|
|
|