Common interoperability guidelines

Why necessary

The interoperability of systems using AIXM is closely related to the definition of a use cases supported by these systems.

By design, AIXM 5.x has the ability to support a variety of use cases, such as data origination, charting, static data coding, Digital NOTAM, etc. Such a broad range of applications imposes a certain flexibility in the AIXM specification. For example, there are no mandatory feature properties (in order to allow the coding of "differences"), no predefined feature keys (both natural and artificial keys can be used, depending on the context), etc.

For a specific use case, such as provision by States of the ICAO Data Sets, the AIXM flexibility needs to be constrained with rules that limit the coding possibilities and ensure that the data is actually fit for the intended use. The objective of the interoperability rules identified here is to ensure that the end users, in particular data integrators, are able to seamlessly merge the digital data coming from different States. These rules also ensure that States can exchange between themselves the digital data sets specified by ICAO Annex 15.

Similar to the data coding rules, most of the interoperability rules can also be formulated as AIXM Business Rules, using SBVR. This enables to verify a particular data set for compliance with these rules, both on the data provider and on the data user side.

Use Cases

State publishes Data Set

Actors: State AIS, Neighboring State AIS

Use cases:

• (optional) State AIS collects latest published data sets from Neighboring State AIS
• (optional) State AIS coordinates data set changes with Neighboring State AIS
• State AIS provide initial data set (it is possible not all features are included in this initial release)
• (conditional) State AIS provide AIRAC updates of the data set
• (conditional) State AIS provide non-AIRAC updates of the data set
• (optional) State AIS extend data set with new features

Issues that require special attention:

• data with shared responsibility
  • Airspace borders that make reference to State or other natural or administrative borders
  • waypoints on the border
  • cross-border route segments
• neighboring State data
  • navaids used for procedures that extend in the the neighboring State airspace
  • other neighboring State data included “for convenience”

Data integrator collects Data Set

Actors: Data Integrator

Use cases:

• receive initial data set from a State
• receive AIRAC updates from a State
• receive non-AIRAC updates from a State
• receive extended data set from a State

Issues that require special attention:

• Minimal list of attributes that are expected to exist (nil Reasons?)
• Harmonised encoding of certain data
• Mixed versions of AIXM
• Data duplicates, conflicts (such as the same waypoint having different coordinates), gaps, etc.
• data with shared responsibility (if the data is not coordinated, the same feature could have two different UUID in the two or more data sets)
  
  • Airspace borders that make reference to State or other natural or administrative borders
  • waypoints on the border
  • cross-border route segments
• neighboring State data
  • navaids used for procedures that extend in the the neighboring State airspace
  • other neighboring State data included “for convenience”