[AIXM-590] Revision of Final Profile tables model

ID:	AIXM-590
target version:	AIXM 5.2
version:	1.0
last updated:	10 JAN 2023
status:	APPROVED

Description

The ApproachTimingTable is renamed FinalApproachProfile and gets additional properties for rate of descent, speed reference and distance between the reference points. The ApproachDistanceTable and ApproachAltitudeTable classes are deleted and replaced with a new FinalApproachControlAltitude class, which has attributes for elevation and an association to SignificantPoint.

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-160, https://aixmccb.atlassian.net/browse/AIXM-263

The current model includes three classes named “Approach[…]Table”, which are associated with the InstrumentApproachProcedure through the FinalProfile and which are meant to support the coding information related to the vertical profile of the procedure, mainly for the final segment. These classes are shown in the diagram below.

The first one is the ApproachTimingTable, which is meant to support the coding of the “rate of descent and timing” table provided in the vertical profile of instrument approach procedure (ICAO) charts. It depicts the rates of descent (usually expressed in ft/min) for a particular descent gradient (vertical angle) and for a range of speeds (e.g. ground speed - GS). For a given horizontal distance, expressed between two significant geographical locations, e.g. FAF to MAPT, outer to middle marker, etc. and considering the same speeds, an approach timing is also provided. For example:

The existing class ApproachTimingTable is missing several attributes, such as rate of descent and the distance between the reference points (typically FAF to MAPT). Additionally, the speed modelled in the ApproachTimingTable cannot be qualified (e.g.. IAS, GS, etc.). Therefore it is proposed to add the missing properties in this class. It is also proposed to rename this class to better reflect its scope and purpose - FinalApproachProfile (as each occurrence corresponds to one rate of descent, not to the full table)

The ApproachDistanceTable is meant to support the coding of control altitudes/heights on the final approach. Such tables typically contain procedure altitude/height values at regular intervals along the final approach, with reference to the landing threshold and/or to a DME navaid, if applicable. For example:

The current model is missing the possibility to code all the information contained in this table, such as altitudes. In addition, the valueHAT has an unclear meaning and the model cannot explicitly indicate the start/end significant points (such as “THR RWY 31”).

Some procedures charts also contain control altitudes at specific points in the final approach for positions that are not the start or the end of a segment leg, such as in the following example:

Such control altitudes could be coded using the ApproachAltitudeTable, but this class is missing the possibility to indicate the actual navaid/waypoint where the altitude is controlled. It is also not a table.

Therefore, it is proposed to modify the ApproachDistanceTable and the ApproachAltitudeTable classes by merging them in a single FinalApproachControlAltitude class, with a revised set of attributes. The new FinalApproachControlAltitude, could be used to code the approach control altitudes as a particular case: the distance from the reference significant point is zero (above the point) and there is a single instance, not a set of values (not a table).

The CodeProcedureDistanceBaseType identifies positions (such as OM, MM, MAPT, etc.) used in the timing and altitude control tables discussed above. Some of these values (such as HAT, THLD) include a “height” term, which is inappropriate. They need to be replaced with the position that they represent (THR, TDN).

Finally, the FinalProfile <<object>> does not serve any real purpose in the model. Therefore, the associations to the new/renamed classes can come directly from the InstrumentApproachProcedure and the FinalApproach intermediate element can be removed.

Impact assessment

[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.

Change Proposal details

In the UML model:

Rename CodeProcedureDistanceBaseType into CodeFinalSegmentPointBaseType and
- change definition into “A code indication a conventional position in the final approach segment of an instrument approach procedure”;
- add the following values to the codelist:
  - THR = Threshold
  - TDN = Touch-down
  - RWY_END = Runway end
  - MAPT = Missed-Approach Point
- delete the values:
  - THLD
  - HAT
  - RECH
  - MAP
- Rename CodeProcedureDistanceType into CodeFinalSegmentPointType
- Rename the class ApproachTimingTable into FinalApproachProfile and:
  - change definition into “Control time and rate of descent values for the final approach depending on the aircraft speed. Note: usually presented as a table in the vertical profile section of instrument approach charts”
  - rename the attribute startingMeasurementPoint into startPoint and change its definition into “An indication of a specific point role (such as ‘FAF’) in the approach procedure from where the control timing is calculated”;
  - rename the attribute endingMeasurementPoint into endPoint and change its definition into “An indication of a specific point role (such as ‘MAP’) in the approach procedure down to which the control timing is calculated”;
  - add a new attribute distance, data type ValDistanceType, definition = “The horizontal distance flown between the start point and the end point.”
  - add a new attribute speedReference, data type CodeSpeedReferenceType, definition = “An indication of the speed reference (ground or air).”
  - add a new attribute rateOfDescent, data type ValSpeedType, definition = “The calculated value of the vertical descent speed between the start and the end point.”
- Delete the class ApproachDistanceTable
- Delete the class ApproachAltitudeTable
- Insert a new class FinalApproachControlPosition <<object>>, definition = “The position of a FinalApproachControlAltitude relatively from a SignificantPoint”, with the following attributes and associations:
  - distance, type ValDistanceType, definition = “The value of the distance from the reference position (SignificantPoint) to the point where the control altitude is provided”;
  - FinalApproachControlPosition hasReferencePoint SignificantPoint with
    - navigable towards SignificantPoint with role “relativeFrom”, multiplicity 0..1 and definition= “The navaid or the point used as reference for the position where the control altitude/height is specified”
    - FinalApproachControlPosition multiplicity 0..*
  - FinalApproachControlPosition hasAnnotations Note with
    - Note role “annotation” (definition = “A free text remark concerning the final approach control distance or one of its properties.”), multiplicity 0…*
  - Insert a new class FinalApproachControlAltitude with <<object>> stereotype:
    - definition = “A relative position and a corresponding altitude/height that is used on the final approach segment to control the correctness of the vertical location of the aircraft.”
    - attributes:
      - altitude, data type ValDistanceVerticalType, definition = “The value of the control altitude”
      - altitudeReference, data type CodeVerticalReferenceType, definition = “An indication of the reference for the altitude value”
      - height, data type ValDistanceVerticalType, definition = “The value of the control height, in relation with the heightReference”
      - heightReference, data type CodeHeightReferenceType, definition = “An indication of the surface used as height reference, such as the landing threshold.”
      - measurementPoint, data type CodeFinalSegmentPointBaseType , definition = “An indication of a specific point role (such as ‘OM’, ‘THR’, etc.) in the approach procedure where the control altitude/height is specified”
    - associations:
      - FinalApproachControlAltitude isLocatedAt FinalApproachControlPosition with
        navigable towards FinalApproachControlPosition, with role name “location”, multiplicity 0..* and definition = “The position, relative to a navaid above or point, where the control altitude/height is specified”
      - In the InstrumentApproachProcedure class
        delete the association declares FinalProfile
        add a new composition relationship hasProfile FinalApproachProfile with
        FinalApproachProfile role name “descentProfile” (definition=”Rate of descent and timing on the final approach segment.”), multiplicity 0…*;
        add a new composition relationship hasControlAltitude FinalApproachControlAltitude with
        FinalApproachControlAltitude role name “controlAltitude” (definition=”An altitude/height used for verifying the correct vertical positioning of the aircraft at a specified point on the final approach segment.”), multiplicity 0…*;
        Delete the FinalProfile class, including all its associations

The following UML class diagram presents the updated FinalApproachProfile class.

The following UML class diagram presents the new FinalApproachControlAltitude class and the classes that it replaces.

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

The following algorithm shall be applied:

For each AIXM 5.1(.1) InstrumentApproachProcedure that has a child element FinalProfile:
- [MAPC-01] For each ApproachTimingTable element:
  - rename timing into descentProfile and move it (including its descendants) directly below the InstrumentApproachProcedure
  - rename ApproachTimingTable into FinalApproachProfile and modify its child elements as follows:
    - startingMeasurementPoint into startPoint
      - if applicable, map the value of this element as follows:
        RECH into OTHER:RECH
        THLD into OTHER:THLD
        HAT into OTHER:HAT
        MAP into OTHER:MAP
        OTHER:MAPT into MAPT
        OTHER:THR into THR
        OTHER:TDN into TDN
        OTHER:RWY_END into RWY_END
      - endingMeasurementPoint into endPoint
        if applicable, map the value of this element as follows:
        RECH into OTHER:RECH
        THLD into OTHER:THLD
        HAT into OTHER:HAT
        MAP into OTHER:MAP
        OTHER:MAPT into MAPT
        OTHER:THR into THR
        OTHER:TDN into TDN
        OTHER:RWY_END into RWY_END
        [MAPC-01] For each ApproachDistanceTable element
        rename distance into controlAltitude and move it (including its descendants) directly below the InstrumentApproachProcedure
        rename ApproachDistanceTable into FinalApproachControlAltitude and modify its child elements as follows:
        startingMeasurementPoint into measurementPoint
        if applicable, map the value of this element as follows:
        RECH into OTHER:RECH
        THLD into OTHER:THLD
        HAT into OTHER:HAT
        MAP into OTHER:MAP
        OTHER:MAPT into MAPT
        OTHER:THR into THR
        OTHER:TDN into TDN
        OTHER:RWY_END into RWY_END
        valueHAT into height
        insert a new sibling heightReference = HAT
        distance into distance
        If endingMeasurementPoint has a value, which is unlikely, from the three backward mapping options, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:
        Remove the endingMeasurementPoint element
        Add an Note associated with the ApproachTimingTable with:
        purpose=“OTHER:BACKWARD_MAPPING”;
        LinguisticNote.note=”endingMeasurementPoint: <endingMeasurementPoint>”
        [MAPC-01] For each ApproachAltitudeTable element
        rename altitude into controlAltitude and move it (including its descendants) directly below the InstrumentApproachProcedure
        rename ApproachAltitudeTable into FinalApproachControlAltitude and modify its child elements as follows:
        for measurementPoint, if applicable, map the value of this element as follows:
        RECH into OTHER:RECH
        THLD into OTHER:THLD
        HAT into OTHER:HAT
        MAP into OTHER:MAP
        OTHER:MAPT into MAPT
        OTHER:THR into THR
        OTHER:TDN into TDN
        OTHER:RWY_END into RWY_END
        remove the FinalProfile element

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

The following algorithm shall be applied:

[MAPC-01] For each InstrumentApproachProcedure that has child FinalApproachProfile and/or controlAltitude.FinalApproachControlAltitude elements:
- add a child FinalProfile element
For each FinalApproachProfile element
- [MAPC-01] rename descentProfile into timing and move it (including its descendants) under the FinalProfile element
- rename FinalApproachProfile into ApproachTimingTable and modify its child elements as follows:
  - [MAPC-01] rename startPoint into startingMeasurementPoint
    - if applicable, map the value of this element as follows:
      - MAPT into OTHER:MAPT
      - THR into OTHER:THR
      - TDN into OTHER:TDN
      - RWY_END into OTHER:RWY_END
    - [MAPC-01] rename endPoint into endingMeasurementPoint into
      - if applicable, map the value of this element as follows:
        MAPT into OTHER:MAPT
        THR into OTHER:THR
        TDN into OTHER:TDN
        RWY_END into OTHER:RWY_END
      - [MAPC-02] For the distance, speedReference and rateOfDescent elements, from the three backward mapping options, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:
    - Remove the distance, speedReference and/or rateOfDescent elements, as applicable
    - Add an Note associated with the ApproachTimingTable with:
    - purpose=“OTHER:BACKWARD_MAPPING”;
    - LinguisticNote.note=”distance: <distance> <uom>, speedReference: <speedReference>, rateOfDescent: <rateOfDescent> <uom>”
    - For each FinalApproachControlAltitude element that has a descendant FinalApproachControlDistance.distance value
      - [MAPC-01] rename controlAltitude into distance and move it (including its descendants) under the FinalProfile element
      - rename FinalApproachControlAltitude into ApproachDistanceTable and modify its child elements as follows:
        [MAPC-01] rename measurementPoint into startingMeasurementPoint
        if applicable, map the value of this element as follows:
        MAPT into OTHER:MAPT
        THR into OTHER:THR
        TDN into OTHER:TDN
        RWY_END into OTHER:RWY_END
        [MAPC-02] If referencePosition_runwayPoint, referencePosition_DesignatedPoint or referencePosition_navaidSystem is present, then from the three backward mapping options, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:
        remove the referencePosition_runwayPoint, referencePosition_DesignatedPoint or referencePosition_navaidSystem element as applicable
        Add an Note associated with the ApproachTimingTable with:
        purpose=“OTHER:BACKWARD_MAPPING”;
        LinguisticNote.note=”referencePosition_runwayPoint/DesignatedPoint/navaidSystem: <@xlink:href>”
        [MAPC-01] If heightReference=’HAT’, then rename height into valueHAT and remove the heightReference element
        [MAPC-02] If heightReference is different from ’HAT’, then from the three backward mapping options, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:
        remove the height and heightReference elements
        Add an Note associated with the ApproachTimingTable with:
        purpose=“OTHER:BACKWARD_MAPPING”;
        LinguisticNote.note=”height: <height> <uom>, heightReference: <heightReference>”
        [MAPC-02] If altitude has a value, then from the three backward mapping options, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:
        remove the altitude and altitudeReference elements
        Add an Note associated with the ApproachTimingTable with:
        purpose=“OTHER:BACKWARD_MAPPING”;
        LinguisticNote.note=”altitude: <altitude> <uom>, altitudeReference: <altitudeReference>”
        For each FinalApproachControlAltitude element that does not have a descendant FinalApproachControlDistance.distance value
        [MAPC-01] rename controlAltitude into altitude and move it (including its descendants) under the FinalProfile element
        rename FinalApproachControlAltitude into ApproachAltitudeTable and modify its child elements as follows:
        [MAPC-01] if applicable, map the value of the measurementPoint element as follows:
        MAPT into OTHER:MAPT
        THR into OTHER:THR
        TDN into OTHER:TDN
        RWY_END into OTHER:RWY_END
        [MAPC-02] If height has a value, then from the three backward mapping options, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:
        remove the height and heightReference elements
        Add an Note associated with the ApproachTimingTable with:
        purpose=“OTHER:BACKWARD_MAPPING”;
        LinguisticNote.note=”height: <height> <uom>, heightReference: <heightReference>”
        [MAPC-02] If referencePosition_runwayPoint, referencePosition_DesignatedPoint or referencePosition_navaidSystem is present, then from the three backward mapping options, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:
        remove the referencePosition_runwayPoint, referencePosition_DesignatedPoint or referencePosition_navaidSystem element as applicable
        Add an Note associated with the ApproachTimingTable with:
        purpose=“OTHER:BACKWARD_MAPPING”;
        LinguisticNote.note=”referencePosition_runwayPoint/DesignatedPoint/navaidSystem: <@xlink:href>”

Mapping example

(Note: for mapping test data see: https://github.com/aixm/mapping_52_511/tree/master/AIXM-590)

Input

Output