[Lot 6][AIXM-503] Equipment and authorization requirements for procedures

Description

The possibility to specify Radar support as an alternative to on-board navigation capabilities is extended to all Procedures and all Segment Legs. The additionalEquipment attribute is removed from the InstrumentApproachProcedure. The rnpDMEAuthorised attribute is removed from the FinalLeg. Additional values are included in the CodeNavigationEquipmentBaseType. The navigationEquipment attribute of the AircraftCharacteristics becomes an object, allowing for multiple occurrences. An attribute for dual radio frequency capability is added in the AircraftCharacteristics class. The possibility to specify a specialAuthorisation requirement is added in the Procedure class.

Note: For completeness and clarity, this Change Proposal includes the previously approved AIXM-341 Change Proposal, which is no longer provided as a separate Change Proposal. AIXM-341 has added DME/DME/IRU and ADF values in the CodeNavigationEquipmentBaseType.

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-453, https://aixmccb.atlassian.net/browse/AIXM-303.

The InstrumentApproachProcedure.additionalEquipment attribute was intended to allow the coding of additional equipment requirements when using that procedure. The current model has two issues:

• its list of values includes many codes that duplicate other elements of the model, such as "GPSRNP3", which can also be coded as navigation accuracy, ‘ADF’ that could be coded as an association InstrumentApproachProcedure  to  navigationEquipment = ‘ADF’, etc.
• its list of values includes some codes that belong to other concepts in the model, such as “SPECIAL” (aircraft and aircrew certification required);
• it can be used only for Instrument Approach Procedures. However, there are examples of SID/STAR that require radar assistance as an option to the non-availability of navigation equipment on board.

In addition, the FinalLeg class has a property called rnpDMEAuthorized, which may be used to indicate that  "DME/DME RNP 0.3 is allowed”. The attribute name is misleading because in fact it applies only to 0.3 RNP. The same restriction can be coded as an association with AircraftCharacteristics with navigation capability “DME_DME”.

The following UML class diagram indicates the location of this attribute and its list of values. This diagram also includes changes in the list of values of the AircraftCharacteristics.navigationEquipment, which were introduced with the AIXM-341 Change Proposal.

In order to clarify the coding of equipment requirements for Procedures, the following changes to the model are proposed:

• the additionalEquipment property is moved into the Procedure class, which will allow it to be used also for SID and STAR procedures.
• the list of values CodeApproachEquipmentAdditionalType is reduced to cover only values that cannot be coded through the association to AircraftCharacteristics.
• the lists of values CodeNavigationEquipmentBaseType and CodeCommunicationModeType are complemented with additional coded values, in order to cover all possibilities previously specified as additional navigation or communication capability;
• a specialAuthorisation attribute is added in the Procedure class in order to indicate that it can only be used with special authorisation for crew and aircraft. This also takes into consideration that the AIXM-473 Change Proposal introduces a specialAuthorisation for the ApproachCondition class, in order to identify the minima values that are subject to special authorisation.

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:

• In the CodeApproachEquipmentAdditionalBaseType data type:
  • Modify the class name into “CodeAdditionalEquipmentBaseType”;
  • Modify the definition into “A code indicating a ground service or equipment either required or that can be used as an alternative to an on-board navigation capability in order to fly the procedure”;
  • Modify the list of values as follows:
    • Delete the values ADF, DME, RADARDME, VORLOC, DUALVORDME, DUALADF, ADFMA, SPECIAL, DUALVHF, GPSRNP3, ADFILS, DUALADF_DME;
    • Add a new value “RADAR_DME”, definition = “Radar assistance may be used as an alternative to DME”;
    • Add a new value “RADAR_GNSS”, definition = “Radar assistance may be used as an alternative to GNSS”;
    • Modify the definition of the “RADAR_RNAV” value into “Radar assistance may be used as an alternative to RNAV navigation capabilities”;
  • In the CodeApproachEquipmentAdditionalType data type:
    • Modify the class name into “CodeAdditionalEquipmentType”

• In the CodeNavigationEquipmentBaseType data type add the following values:
  • VOR, definition = “VOR receiver”;
  • DUAL_VOR, definition = “Dual VOR receivers”;
  • ADF = “Automatic direction finder (ADF). An aircraft radio-navigation instrument that automatically and continuously displays the relative bearing from aircraft to a suitable radio station, including NDB.”
  • DUAL_ADF, definition = “Dual ADF receivers”;
  • DME_DME_IRU = “Navigation using Distance Measuring Equipment (DME) ranging from at least two DME facilities to determine position along with use of an integrated Inertial Reference Unit (IRU)”
  • FMS_RF, definition = “Flight Management System with Radius to Fix (RF) navigation capability”

• Add a new <<object>> AircraftNavigationEquipment, definition = “Radio navigation equipment capabilities available on board” with the following properties:
  • navigationEquipment, data type CodeNavigationEquipmentType, definition = “An indication of the aircraft capability for using a specified ground based, satellite based or on-board system for aerial navigation.”
  • hasAnnotations Note with
    • Note role “annotation” (definition = “A free text remark concerning the AircraftNavigationEquipment or one of its properties.”), multiplicity 0…*
  • In the AircraftCharacteristics class:
    • delete the navigationEquipment attribute
    • add a new association “has” AircraftNavigationEquipment with:
      • AircraftNavigationEquipment role name = “radioNavigationEquipment”, definition = “Radio navigation equipment available on the aircraft. Note: multiple occurrences in relation with the same AircraftCharacteristics are interpreted with an ‘and’ operator”, multiplicity 0…*
    • add a new dualFrequency attribute, data type CodeYesNoType, definition = “Simultaneous radio communication capability on two different frequencies, such as dual VHF.”

• In the InstrumentApproachProcedure class:
  • delete the additionalEquipment attribute
• In the Procedure class:
  • add a new attribute additionalEquipment, data type CodeAdditionalEquipmentType, definition = “A ground service or equipment either required or that can be used as an alternative to an on-board navigation capability in order to fly the procedure”
  • add a new specialAuthorisation attribute defined as “The procedure can be used only with special authorisation. Note: this is a different thing from the RNP AR APCH.”, data type CodeYesNoType.
• In the SegmentLeg class:
  • add a new attribute additionalEquipment, data type CodeAdditionalEquipmentType, definition = “A ground service or equipment either required or that can be used as an alternative to an on-board navigation capability in order to fly the procedure leg”
• In the FinalLeg class:
  • delete the rnpDMEAuthorized attribute

The following diagram shows the classes and properties concerned by this change:

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

The following algorithm shall be applied (in the order indicated below):

• [MAPC-01] For each AircraftCharacteristics that has a child navigationEquipment element:
  • copy the value of the navigationEquipment into a new navigationEquipment descendant element with the following mapping:
    • OTHER:VOR into VOR
    • OTHER:DUAL_VOR into DUAL_VOR
    • OTHER:ADF into ADF
    • OTHER:DUAL_ADF into DUAL_ADF
    • OTHER:DME_DME into DME_DME
    • OTHER:FMS_RF into FMS_RF
    • other values are copied identical;
  • remove the navigationEquipment
• [MAPC-01] For each InstrumentApproachProcedure that has an additionalEquipment child element apply the following mapping:
  • if it has AircraftCharacteristics child elements, then the values specified for radioNavigationEquipment.navigationEquipment and dualFrequency in the mapping table below shall be added in each existing aircraftCapability.AircraftCharacteristics descendant; otherwise, a these elements need to be added in a new aircraftCapability.AircraftCharacteristics.radioNavigationEquipment.navigationEquipment descendant element;
  • apply the following mapping: 

• [MAPC-01] For each FinalLeg that has an rnpDMEAuthorized child element apply the following mapping:
  • if FinalLeg has AircraftCharacteristics child elements, then in each of these add a new for radioNavigationEquipment.navigationEquipment with the value “DUAL_DME”;
  • if FinalLeg has no AircraftCharacteristics child elements, then add a new aircraftCapability.AircraftCharacteristics.radioNavigationEquipment.navigationEquipment with the value “DUAL_DME”;
  • delete the

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

The following algorithm shall be applied:

• [MAPC-01] For each AircraftCharacteristics that has as single child radioNavigationEquipment element:
  • copy the value of the navigationEquipment into a new navigationEquipment child element with the following mapping:
    • VOR into OTHER:VOR
    • DUAL_VOR into OTHER:DUAL_VOR
    • ADF into OTHER:ADF
    • DUAL_ADF into OTHER:DUAL_ADF
    • DME_DME into OTHER:DME_DME
    • FMS_RF into OTHER:FMS_RF
    • other values are copied identical;;
  • copy any eventual Note child element of the radioNavigationEquipment.AircraftNavigationEquipment into a annotation.Note of the AircraftCharacteristics.
  • remove the radioNavigationEquipment

Note: This mapping solution is not reusing the previous additionalEquipment of the InstrumentApproachClass because that would be too complicated and it would not work for SID/STAR. This mapping solution is also consistent with the coding guidelines.

• [MAPC-04] For each AircraftCharacteristics that has two or more child radioNavigationEquipment elements:
  • From the three backward mapping options discussed for MAPC-04, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3^rd option (backward mapping into the navigationEquipment property, 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:
• If not exceeding the maximum length for OTHER:... values, then concatenate all the values of the navigationEquipment separated by “_” and copy the resulting string into AircraftCharacteristics.navigationEquipment prefixed by “OTHER:”. For example, ILS and DME will become “OTHER:ILS_DME”
• Add an annotation.Note associated with the AircraftCharacteristics with:
• purpose=“OTHER:BACKWARD_MAPPING”;
• LinguisticNote.note=”radioNavigationEquipment[1].AircraftNavigationEquipment.navigationEquipment: <navigationEquipment> value [1]; radioNavigationEquipment[2].AircraftNavigationEquipment.navigationEquipment: <navigationEquipment> value [2]; etc.
• propertyName=’navigationEquipment’.
  • copy any eventual Note child element of the radioNavigationEquipment.AircraftNavigationEquipment into a annotation.Note of the AircraftCharacteristics.
  • remove the radioNavigationEquipment

Note: This mapping solution is not reusing the previous additionalEquipment of the InstrumentApproachClass because that would be too complicated and it would not work for SID/STAR. This mapping solution is also consistent with the coding guidelines.

• [MAPC-02] For each AircraftCharacteristics that has a dualFrequency child element:
  • From the three backward mapping options discussed for this mapping case, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3^rd 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:
• Add an Note associated with the AircraftCharacteristics class having
• purpose=“OTHER:BACKWARD_MAPPING”;
• LinguisticNote.note=”dualFrequency: <value of dualFrequency>
• Remove the dualFrequency element
• [MAPC-01] For each InstrumentApproachProcedure that has
  • either additionalEquipment child element or specialAuthorisation=’Yes’
  • additionalEquipment child element and specialAuthorisation either not present or equal-to ’No’;
  • apply the following mapping:
    • change the value of the additionalEquipment element as follows:
      • RADAR_DME into RADARDME
      • RADAR_GNSS into OTHER:RADAR_GNSS
      • other values remain unchanged
    • if specialAuthorisation=Yes then insert additionalEquipment=SPECIAL

• For each InstrumentApproachProcedure that has specialAuthorisation=’Yes’ and also an additionalEquipment child element:
  • [MAPC-01] Change the value of the additionalEquipment into “ SPECIAL” (as this is considered the most important data) and remove the specialAuthorisation element;
  • [MAPC-02] From the three backward mapping options discussed for this mapping case, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3^rd 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:
• Add an Note associated with the InsrtumentApproachProcedure class having
• purpose=“OTHER:BACKWARD_MAPPING”;
• LinguisticNote.note=”additionalEquipment: <value of additionalEquipment>;
• [MAPC-02] For each StandardInstrumentArrival, StandardInstrumentDeparture, DepartureLeg, ArrivalLeg, ArrivalFeederLeg, InitialLeg, IntermediateLeg, FinalLeg or MissedApproachLeg that has an additionalEquipment child element:
  • From the three backward mapping options discussed for this mapping case, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3^rd 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:
• Add an Note associated with the StandardInstrumentArrival, StandardInstrumentDeparture, DepartureLeg, ArrivalLeg, ArrivalFeederLeg, InitialLeg, IntermediateLeg, FinalLeg or MissedApproachLeg FinalLeg element as appropriate having:
  • purpose=“OTHER:BACKWARD_MAPPING”;
  • LinguisticNote.note=”additionalEquipment: <value of additionalEquipment>;
• [MAPC-02] For each StandardInstrumentArrival or StandardInstrumentDeparture that has a specialAuthorisation child element:
  • From the three backward mapping options discussed for this mapping case, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3^rd 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:
• Add an Note associated with the StandardInstrumentArrival or StandardInstrumentDeparture element as appropriate having:
  • purpose=“OTHER:BACKWARD_MAPPING”;
  • LinguisticNote.note=”specialAuthorization: <value of specialAuthorization>;

Mapping example

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

  ...

...