/
[AIXM-585] FAS Data Block model update

[AIXM-585] FAS Data Block model update

Owned by KOKOLIA Sergo (EXT)
Last updated: 2024 Aug 28 by ADAM STYLES

ID:

AIXM-585

target version:

AIXM 5.2

version:

1.0

last updated:

29 MAR 2023

status:

APPROVED


Description

The existing FASDataBlock class is renamed FinalApproachSegmentData. New attributes are added and data types are adjusted in order to enable the exact coding of the data elements that enter into the calculation of the FASDataBlock.

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-199, https://aixmccb.atlassian.net/browse/AIXM-201, https://aixmccb.atlassian.net/browse/AIXM-187

In the current AIXM 5.1(.1) model, the alphanumeric data elements that enter in the calculation of the FAS Data Block are partially modelled as properties of the FASDataBlock class. The missing properties are in general available in other parts of the model. For example, the airport identifier is provided by the designatorICAO attribute of the AirportHeliport which may be associated with the InstrumentApproachProcedure either directly (through the “services” association) or indirectly (through the association to LandingTakeOffAreaCollection -> RunwayDirection -> Runway -> AirportHeliport.

The following issues have been identified in the current model:

  • the name of the FASDataBlock class is misleading because it does not actually contain the FAS Data Block. It contains some of the properties that are used as input in the calculation of the FAS Data Block;
  • it is not possible to provide the value of the actual FAS DB, as a hexadecimal string;
  • it is unclear how to code the position of the FTP/LTP, which enters in the calculation of the FAS DB;
  • there is no dedicated attribute for the coding of the TCH (Threshold Crossing Height) value.

it is not clear why some data elements used for the FAS DB calculation are modelled as explicit properties associated with the FinalLeg while other data is left to be recuperated from associations with other features and their properties;

Proposed model update

Note: some changes that are relevant for the coding of the FAS Data Block have already been introduced with other Change Proposals: AIXM-467 (Model improvements for GNSS).

Considering the particularities of the FAS DB data chain diagram presented in the Introduction, AIXM needs to support the coding of both the data elements that enter in the calculation of the FAS Data Block and the result of this calculation (hexadecimal expression of the FAS DB, including the CRC remainder). The alphanumeric data elements are, for example, used by DAT providers when coding procedures in the ARINC 424 standard. The hexadecimal string is recalculated and compared with the original one provided by the official sources. This ensures a certain redundancy of the data chain. AIXM will also allow the procedure designer (data originator) to provide the procedure information to AIS, including the eventual FAS DB, and further to the AIS clients. While the FAS DB for GBAS procedures is directly transmitted to the aircraft, it could still be useful to be able to provide it to providers of flight simulator data, for example.

Concerning the elements that enter into the calculation of the FAS DB, many of them exist as properties of classes associated with the FinalLeg. However, access to some of these data elements implies a complex path through the model classes and associations and sometimes the data element is part of a zero-to-many option. For example, the airport ICAO code that appears in the FAS DB could be retrieved from the association between InstrumentApproachProcedure and the served AirportHeliport, but the association has a multiplicity of more than one.

Therefore, it is proposed that all the attributes necessary for the FAS DB calculation are modelled explicitly in a dedicated FinalApproachSegmentData class, that replaces the previous FASDataBlock class. The data types are modelled in order to enable the direct input of these values in FAS data block calculation tools. This would allow coding of FAS DB input elements unambiguously and would offer direct support for the generation of products that need to show the FAS DB input data (such as AIS ‘back of the chart). The coherence between these properties and the other places in the data model where the same data can be retrieved would be ensured with business rules.

In addition, the FinalApproachSegmentData class could be also used for providing values (such as TCH) for instrument approach procedures that do not require the promulgation of a FAS data block.

The following approach is proposed for the FAS DB model changes:

  • the FASDataBlock class is renamed FinalApproachSegmentData;
  • the FAS Data Block in hexadecimal representation, including the CRC remainder, will appear as a property of the new class. The difference in length between SBAS and GBAS data blocks will be checked with business rules, not hardcoded in the data type;
  • all data elements that are necessary in the FAS data block calculation[1], including those that exist already as properties of another AIXM class, will be added as alphanumeric properties. The FAS DB is slightly different depending of the approach type:
    • for SBAS, there are 22 fields including the CRC remainder, as defined in Annex 10, Vol. I, Attachment D, Table D-1 (page dated 8/11/18) and further detailed in PANS-OPS, Vol II, Part III, Section 2, Appendix A to Chapter 6.
    • for GBAS, there are 20 fields including the CRC remainder, as defined in Annex 10, Vol. I, Appendix B, Table B-66 (page dated 8/11/18) and further detailed in PANS-OPS, Vol II, Part III, Section 2, Appendix B to Chapter 6.
  • the new FinalApproachSegmentData will also include properties that are not part of the FASDataBlock, but which are required to be provided for the final segment:
    • the orthometric height of the LTP (according to PANS-OPS, Vol II, III-2, Chapter 6, 6.3 for GBAS and Appendix A to Chapter 6, item 3 for SBAS)
    • ICAO code (Appendix A to Chapter 6, item 3 for SBAS)
  • Business Rules will be developed in order to check the coherence of the data, between the FinalApproachSegmentData class and the data elements that already exist as properties of other AIXM classes
  • In addition, AIXM business rules should ensure that all the elements that appear both in the hexadecimal string and as alphanumeric values in the model are identical. For example, the FTP latitude from the hexadecimal string should match exactly the "latitude" value of the gml:pos of the Point associated with the FTP SegmentPoint. The comparison is straight-forward because the AIXM format is degrees with decimals, which can be converted directly in seconds with decimals, as used in the hexadecimal representation.


[1] For certain FAS DB elements, PANS-OPS indicates that the procedure designer has to provide a value that is used as input in the FAS DB calculation. For example, the procedure designer provides the FPAP lat/long, not the “delta” values. Therefore, the AIXM class will also contain attributes that correspond to these input fields.

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:

  • Add a new <<DataType>> TextLongitudeDMSBaseType, specialisation of the Character3Type:
    • definition = “The textual representation of a geographical longitude value in DMS format, including eventual decimals and a hemisphere code”
    • <<XSDfacet>> pattern = (((0[0-9][0-9]|1[0-8][0-9])[0-5][0-9][0-5][0-9].[0-9]{4})|1800000.0000)(E|W)
  • Add new <<DataType>> TextLongitudeDMSType (specialisation of TextLongitudeDMSBaseType, definition: “ A complex data type that enables the provision of a NIL reason for any attribute using this type.”), attribute:
    • nilReason (type: NilReasonEnumeration)
  • Add a new <<DataType>> TextLatitudeDMSBaseType, specialisation of the Character3Type:
    • definition = “The textual representation of a geographical latitude value in DMS format, including eventual decimals and a hemisphere code”
    • <<XSDfacet>> pattern = ([0-8][0-9][0-5][0-9][0-5][0-9].[0-9]{4}|900000.0000)(N|S)
  • Add new <<DataType>> TextLatitudeDMSType (specialisation of TextLatitudeDMSBaseType,  definition: “ A complex data type that enables the provision of a NIL reason for any attribute using this type.”), attribute:
    • nilReason (type: NilReasonEnumeration)
  • Add a new <<DataType>> TextDecimalBaseType, specialisation of the Character3Type:
    • definition = “The textual representation of a decimal value, optionally including leading zeros and the positive or negative sign”
    • <<XSDfacet>> pattern = ”(\+|\-){0,1}\d*[.\d]*”
  • Add new <<DataType>> TextDecimalType (specialisation of TextDecimalBaseType,  definition: “ A complex data type that enables the provision of a NIL reason for any attribute using this type.”), attribute:
    • nilReason (type: NilReasonEnumeration)
  • Add a new <<DataType>> NoNumberBaseType, specialisation of the (xsd) unsignedLong type:
    • definition = “An integer value”
  • Add new <<DataType>> NoNumberType (specialisation of NoNumberBaseType,  definition: “ A complex data type that enables the provision of a NIL reason for any attribute using this type.”), attribute:
    • nilReason (type: NilReasonEnumeration)
  • In the <<DataType>> CodeRouteIndicatorBaseType, change the pattern to allow a single character:
    • <<XSDfacet>> pattern = “[A-Z]”
  • In the <<DataType>> ValHexBaseType remove the limitation to 8 characters:
    • <<XSDfacet> pattern = ([A-F]|[0-9])+
  • Change the name of theFASDataBlock class into FinalApproachSegmentData, modify its definition to read “Parameters that identify a single precision approach or APV and define its associated approach path” and modify its list of attributes as follows:
    • change the data type of operationType, serviceProviderSBAS, approachPerformanceDesignator into NoNumberType
    • change the data type of thresholdCourseWidth, lengthOffset, horizontalAlarmLimit and verticalAlarmLimit into TextDecimalType
    • add a new airportID attribute, data type CodeAirportHeliportDesignatorType, definition = “A three- or four-letter designator used to designate an airport”
    • add a new runwayNumber attribute, data type TextDesignatorType, definition = “The approach runway number”
    • add a new runwayLetter attribute, data type TextDesignatorType, definition = “The one-letter designator used, as necessary, to differentiate between parallel runways.”
    • add a new thresholdPointLatitude attribute, data type TextLatitudeDMSType, definition = “The latitude value of the landing or fictitious threshold point”
    • add a new thresholdPointLongitude attribute, data type TextLongitudeDMSType, definition = “The longitude value of the landing or fictitious threshold point”.
    • add a new thresholdPointHeight attribute, data type TextDecimalType, definition = “The height of the landing or fictitious threshold point above the WGS-84 ellipsoid.”
    • add a new finalPointLatitude attribute, data type TextLatitudeDMSType, definition = “The latitude value of the flight path alignment point (FPAP) ”
    • add a new finalPointLongitude attribute, data type TextLongitudeDMSType, definition = “The longitude value of the flight path alignment point (FPAP)”.
    • add a new deltaFinalPointLatitude attribute, data type TextDecimalType, definition = “The difference of latitude of the runway FPAP from the LTP/FTP in arc seconds”.
    • add a new deltaFinalPointLongitude attribute, data type TextDecimalType, definition = “The difference of longitude of the runway FPAP from the LTP/FTP in arc seconds”.
    • add a new thresholdCrossingHeight attribute, data type TextDecimalType, definition = “The height of the final approach segment path above the LTP/FTP defined in the unit of measurement indicated by the thresholdCrossingHeightUnits”.
    • add a new thresholdCrossingHeightUnits attribute, data type NoNumberType, definition = “An indication of the units of measurement used to express the thresholdCrossingHeight”.
    • add a new glidepathAngle attribute, data type TextDecimalType, definition = “The angle of the final approach segment path with respect to the horizontal plane tangent to the WGS-84 ellipsoid at the LTP/FTP”.
    • add a new thresholdOrthoHeight attribute, data type TextDecimalType, definition = “The height of the LTP/FTP as related to the geoid and presented as an MSL elevation to a tenth of a metre with the decimal point suppressed”.
    • add a new finalPointOrthoHeight attribute, data type TextDecimalType, definition = “The height of the flight path alignment point (FPAP) as related to the geoid and presented as an MSL elevation to a tenth of a metre with the decimal point suppressed“
    • add a new FASDataBlock attribute, data type ValHexType, definition = “The set of parameters to identify an approach and define its associated approach path in hexadecimal representation”

The following UML class diagram highlights the new/modified/deleted model elements:

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

The following algorithm shall be applied:

  • [MAPC-01] For each FASDataBlock element, rename the element FinalApproachSegmentData and copy its child elements in the following order (with the eventual adjustment indicated);
    • operationType
    • serviceProviderSBAS
    • approachPerformanceDesignator
    • routeIndicator
    • referencePathDataSelector
    • referencePathIdentifier
    • thresholdCourseWidth (remove the uom value)
    • lengthOffset (remove the uom value)
    • horizontalAlarmLimit
    • verticalAlarmLimit
    • codeICAO
    • CRCRemainder

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

The following algorithm shall be applied:

  • For each FinalApproachSegmentData element, rename the element FASDataBlock and
    • [MAPC-01] copy child elements in the following order (with the eventual adjustment indicated):
      • horizontalAlarmLimit
      • verticalAlarmLimit
      • thresholdCourseWidth (add @uom=’m’)
      • lengthOffset (add @uom=’m’))
      • CRCRemainder
      • operationType
      • serviceProviderSBAS
      • approachPerformanceDesignator
      • routeIndicator
      • referencePathDataSelector
      • referencePathIdentifier
      • codeICAO
    • [MAPC-02] For the remaining child elements, from the three backward mapping options available, 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:
      • Add an annotation.Note associated with the RunwayDirection class having:
    • purpose=“OTHER:BACKWARD_MAPPING”
    • LinguisticNote.note=”airportID: <value of airportID>”

“runwayNumber:<value of runwayNumber>”,

“runwayLetter:<value of runwayLetter>”,

“thresholdPointLatitude:<value of thresholdPointLatitude>”,

“thresholdPointLongitude:<value of thresholdPointLongitude>”,

“thresholdPointHeight:<value of thresholdPointHeight>”,

“finalPointLatitude:<value of finalPointLatitude>”,

“finalPointLongitude:<value of finalPointLongitude>”,

“deltaFinalPointLatitude:<value of deltaFinalPointLatitude>”,

“deltaFinalPointLongitude:<value of delta.FinalPointLongitude>”,

“thresholdCrossingHeight:<value of thresholdCrossingHeight>”,

“thresholdCrossingHeightUnits:<value of thresholdCrossingHeightUnits>”,

“glidePathAngle:<value of glidePathAngle>”,

“thresholdOrthoHeight:<value of thresholdOrthoHeight>”,

“finalPointOrthoHeight:<value of finalPointOrthoHeight>”,

“FASDataBlock:<value of FASDataBlock>”.

  • remove the airportID, runwayNumber, runwayLetter, thresholdPointLatitude, thresholdPointLongitude, thresholdPointHeight, finalPointLatitude, finalPointLongitude, deltaFinalPointLatitude, deltaFinalPointLongitude, thresholdCrossingHeight, thresholdCrossingHeightUnits, glidePathAngle, thresholdOrthoHeight, finalPointOrthoHeight, FASDataBlock elements, as applicable.

Mapping example

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

AIXM InputAIXM Output