What's new in AIXM 5.2
AIXM 5.2 is the upcoming version of AIXM, the language of aeronautical information.
Note: AIXM 5.2 is expected to be released in Q1 2022. The information on this page is based on the announcement made on 27th October 2021 by the AIXM Change Control Board (CCB), of which Nilacandi is a member. We will update this page when AIXM 5.2 is officially released.
This page aims to give an overview of the changes in AIXM 5.2 that have actual consequences for operators, be they aeronautical information editors in an ANSP, AIS Data Providers, or Data Users. AIS Data Managers and AIS software developers will rather read the AIXM.aero website, which gives detailed technical information about these changes. We don’t address minor changes that are not relevant to the production of AIP, aeronautical charts, or AIP datasets.
AIXM 5.2 is a “minor” new version of the aeronautical information exchange model. This means that changes are minor: they do not bring fundamental modifications to the AIXM 5.1 data model. Nevertheless, this version is an important one, as it accumulated over 10 years of important updates since version 5.1. The main areas of changes in AIXM 5.2 are as follows:
- Flight procedures encoding
- Lower case characters in names
- Route-level usage specifications
- Obstacle designator
Don’t wait for AIXM 5.2 to be released before kicking-off your migration to AIM. This next release is planned for Q1 2022, but it has been delayed quite a few times already. If you don’t know where to start, how about participating to an AIS to AIM workshop or attending our AIXM trainings?
Minor version or minor changes?
AIXM 5.2 is a “minor” new version, following standard terminology from the software industry.
- A “major” version would be numbered 6.0 and would bring large, disruptive changes.
- A “minor” version, such as this 5.2, may introduce disruptive changes, limited to a small area of the model, and may bring new feature types, or new attributes to existing features.
- A “patch” version would be numbered 5.1.2 and would offer purely non-disruptive changes, except for small corrections.
AIXM 5.2 does bring many changes, and some of them are incompatible with AIXM 5.1. The AIXM Change Control Board includes extensive documentation about each change, including instructions on how to migrate data to version 5.2 (what is coined forward mapping), and from 5.2 back to 5.1 (backward mapping, you guessed it right!).
If you currently enjoy an AIM system based on AIXM 5.1, be aware that you won’t be able to store AIXM 5.2 data in it. You will need a software upgrade, which may or not be included in your maintenance agreement. In the case of Facilis.aero software, we will support AIXM 5.2 shortly after its official release, and customers will have the option to migrate to the new version at their convenience, as this is included in the service subscription.
Long-awaited change: support for lowercase letters for place and feature names. Users of Synclude GroupVerve/Comsoft CADAS-EPS have a proprietary solution for this, which will allow for smooth migration to AIXM 5.2.
[pending] Improved support for PBN concepts, in line with ICAO Doc 9613, affecting RouteSegment and IFP.
AIXM 5.2 offers persistent identifiers for complex properties (“objects”, as called in the model): another long-awaited improvement that is useful to reference properties occurring multiple times inside datasets, in external applications.
Half-hour and quarter time zones are now supported: until AIXM 5.2, it was not possible to define a local time in Nepal (UTC+5:45), Myanmar (UTC+6:30), India, Sri Lanka, Afghanistan, Iran and some territories in France, Australia, New Zealand and Canada.
[pending] Talking about time sheets, if you found that the handling of day and dayTil was difficult, you might appreciate (or not) AIXM 5.2’s addition to the various codes of days. It is now possible to define a schedule such as “from Monday to Friday 09:00-17:00, irrespective of holidays” in a single timesheet, while 5 timesheets are necessary with AIXM 5.1. This simplifies the encoding of timesheet, although it makes their interpretation and the encoding of the day attribute more complicated.
[pending] Improved support of altitude interpretation, which was a confusing list of codes with sometimes incorrect definitions; this affects SegmentLeg, TerminalArrivalArea, Airspace (having more than 1 class layer) and possibly INS/VOR checkpoints.
Airports & Heliports
We can now link more than 1 OrganisationAuthority to an AirportHeliport (owner, supervisor or other), and set the airport’s local time zone.
At last! It’s possible to set AirportHeliport type to spaceports (and other new types). Those who have attended our AIXM 5.1 training might remember that one as an example of potential “OTHER” value. Now, we’ll have to find another funny example 😉 (but, to be frank, we don’t think the AIXM data model fully supports spacecraft operations).
Clearing: a new specific attribute is now available to store the “type of clearing equipment” as published in AIP section AD 2.7, row 1. Users of Synclude GroupVerve/Comsoft CADAS-EPS have a proprietary solution for this, which will allow for smooth migration to AIXM 5.2.
CheckpointINS can now be linked to AircraftStand, which is the case on many airports.
Runway status lights (RWSL) are now supported: LAHSO, THL, REL, RIL.
We can now define the ICAO aerodrome reference code, published in some AIPs. That is done on Runways, and the codes follow ICAO Annex 14 (1 to 4, A to F).
Approach categories on RunwayDirection get new codes (for non-instrument), existing codes are renamed to reflect the fact that precision approaches can be done with GNSS, not only with ILS/MLS, and CAT III D is removed.
AIPs sometimes publish the VASIS axis displacement angle (on VisualGlideSlopeIndicator). That has been added to the model, together with the distance from the threshold.
FATO/TLOF: previous version of the model incorrectly referred to a TLOF aiming point, where the TLOF centre point was meant. AIXM 5.2 renames aiming point to centre point.
AIXM 5.2 brings the possibility to define the type of taxi holding position, and the purpose of TWY marking.
AIXM 5.2 adds support for route usage specification at the route level, rather than just at route segment level. That is very useful as most routes have the same availability definition for all segments.
We can now have multiple MEA based on direction and aircraft equipment.
PBN support: see Global Changes above.
[pending] Improved support for GNSS.
AIXM 5 supports quite complex Airspace geometries made of several volumes. AIXM 5.2 introduces a name property on airspace volumes, to simplify their management. With previous version of the model, one had to use airspace parts for a similar effect.
AIXM 5.2 adds a designator property on feature type VerticalStructure, which was indeed lacking. It also allows for longer names, longer part designator, and adds the option to describe in text the location of obstacles and their parts.
- Support for multiple SafeAltitudeArea referred from procedures (SID, STAR, IAP).
- [pending] Improved support for approach minima definition, and allowing multiple minima for the same FinalLeg.
- [pending] Added support for multiple approaches per TerminalArrivalArea.
- [pending] Correction of TerminalArrivalArea with NoPT.
- [pending] Additional aircraft landing categories defined on AircraftCharacteristic, which is used throughout AIXM, but these categories are mostly useful to procedures.
- [pending] MEA and MOCA can now be defined for all types of procedure legs (previously there was only MOCA and only on DepartureLeg).
- [pending] Some new approach types added (SRA, GBAS…), others removed.
- [pending] SegmentLeg’s speed interpretation list of values is now corrected: it was incorrectly using a list of altitude interpretation codes.
- [pending] Added support for approach on close parallel runways.
- [pending] SegmentLegs and holding can now be defined with both TRUE and MAG course.
- PBN support: see Global Changes above.
There are several other changes, which we consider not essential for most users of AIXM, even though they will definitely be useful to some.
Is it worth waiting for AIXM 5.2 systems?
Short answer: no, but…
- Be sure to have a maintenance agreement, so that you can receive AIXM 5.2 support when your software provider is ready.
- It’s easier if you actually rent your AIM software, so that you don’t need to care about maintenance and upgrades: you receive them progressively.
- If you need an AIXM database to encode PBN or GNSS procedures, or other procedures subject to the limitations of AIXM 5.1 (see the section about procedures above), then you’d better wait for AIXM 5.2.
- If you need new AIXM 5.2 functionality but prefer not to wait, you can still use forward mapping definitions in your AIXM 5.1 data today, to ease a future migration to AIXM 5.2.
More importantly, don’t delay your AIS to AIM migration just because “something better is coming”. There will always be something better coming. AIXM, and in fact AIS in general, will continue to evolve. Remember that AIS to AIM is more about people and change management than about technology. Do what you can today, with your current resources, follow the roadmap from AIS to AIM in a “Kaizen” approach: multiple small steps producing continuous improvement towards a larger goal.
Do you want to learn how AIXM fits in AIS/AIM? We invite you to attend our international AIS to AIM workshop in Lilongwe, Malawi in March 2022. Cannot wait? Nilacandi can organise a tailored AIS to AIM workshop for your organisation. Please contact us for details.
We also offer AIXM hands-on training courses dedicated to AIP Editors and to Cartographers, as well as a 1-day introductory training to AIXM 5.x. These are not technical courses for data modellers and software engineers that you can find at Eurocontrol or other training houses: our courses are hands-on, practical, and cover the parts of AIXM 5.x that are actually useful to publish an AIP or to produce aeronautical charts.