Page tree
Skip to end of metadata
Go to start of metadata

ID:

AIXM-337

target version:

AIXM 5.2

version:

1.0

last updated:

24 sep 2018

status:

APPROVED


Description

Create a new object to provide the design criteria (standard name, version, etc.) used in the design of feature instances such as Route, SafeAltitudeArea and HoldingPattern.  Replace the designStandard property of Procedure with an association to the new class. Add similar associations from the SafeAltitudeArea, TerminalArrivalArea, Route and HoldingPattern classes.

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-205

Design criteria for instrument flight procedures are modeled at a high level for Procedure features (approach, arrival and departure). This does not exist in the model for other features (route, holding and safe altitude), although ICAO PANS-OPS provides design criteria for them.

An additional attribute is necessary to indicate the design standard version. This may be important to know in particular when changes in the design concepts applied are made.

Impact assessment

On short term, there is no impact on existing implementations as the current AIXM 5.1(.1) data remains fully valid against AIXM 5.2. The deprecated property remains available in the AIXM 5.2 schema.

On longer term, existing implementations will have to gradually adjust the existing data in order to use the new object. The forward mapping rules defined further in this document shall be applied.

When receiving data from AIXM 5.2 implementations, current AIXM 5.1(.1) systems will have to be able to map back the coding standard for Procedures, as described in the mapping rules further in this document. The coding standard for other features can only be mapped as notes, because the corresponding concept does not exist in the current model.

Change Proposal details

In the UML model, create a new class <<object>> DesignStandard.

Description: “A formal standard containing rules and criteria applied in the design of the flight procedures or routes”.

Attributes:

  • name with type CodeDesignStandardType

Description: “The name by which the standard that provides the design rules is known”  

Note: Currently, the enumeration for CodeDesignStandardType includes nilReaon, PANS_OPS, TERPS, CANADA_TERPS, NATO, OTHER.

  • version with type TextNameType

Description: “A textual identifier of the exact document/version used as the design standard.

Associations:

    • Procedure ‘designedAccordingTo’ DesignStandard
      • 0…1 from Procedure with “designCriteria” role name, definition = “Standard applied in the design of the procedure.”
    • HoldingPattern ‘designedAccordingTo’ DesignStandard
      • 0…1 from HoldingPattern with “designCriteria” role name, definition = “Standard applied in the design of the holding pattern.” 
    • SafeAltitudeArea ‘designedAccordingTo’ DesignStandard
      • 0…1 from SafeAltitudeArea with “designCriteria” role name, definition = “Standard applied in the design of the safe altitude area.”
    • TerminalArrivalArea ‘designedAccordingTo’ DesignStandard
      • 0…1 from TerminalArrivalArea with “designCriteria” role name, definition = “Standard applied in the design of the terminal arrival altitudes.”
    • Route ‘designedAccordingTo’ DesignStandard
      • 0…1 from Route with “designCriteria” role name, definition = “Standard applied in the design of the route.”

In the UML model, delete the Procedure.designCriteria attribute.

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

[MAPC-04] The following algorithm shall be applied:

  • For each InstrumentApproachProcedure, StandardInstrumentDeparture or StandardInstrumentArrival that has an assigned designCriteria value:
    • Copy the value into a new child element designCriteria.DesignStandard.name
    • Remove the designCriteria element

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

[MAPC-04] From the three backward mapping options applicable in this case, 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 the designCriteria, where it exists, complemented with 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:

  • For each InstrumentApproachProcedure, StandardInstrumentDeparture or StandardInstrumentArrival that has designCriteria.DesignStandard child element:
    • Copy the value of designCriteria.DesignStandard.name into the designCriteria attribute;
    • If designCriteria.DesignStandard.version has an assigned value, then create an annotation.Note with 
  • property=”designCriteria”
  • purpose=“OTHER:BACKWARD_MAPPING”
  • translatedNote.LinguisticNote.note=”designCriteria.DesignStandard.version: <version>
    • Remove the designCriteria element


  • For each HoldingPattern, SafeAltitudeArea, SafeAltitudeArea, TerminalArrivalArea, Route that has a designCriteria.DesignStandard child element:
  • create an annotation.Note child element with:
    • purpose=“OTHER:BACKWARD_MAPPING”
    • translatedNote.LinguisticNote.note=”designCriteria.DesignStandard.name: <DesignStandard.name>; designCriteria.DesignStandard.version: <DesignStandard.version>”.
  • Remove the designCriteria element.

Mapping example

Mapping example to be added....


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

AIXM 5.2AIXM 5.1(.1)
  ...





...



  • No labels