Detailed working notes on the Aeronautical Information Exchange Model (AIXM). This folder expands the summary in topics/aixm.md into per-aspect files so each can be read on its own.

Files in this folder#

• overview.md — what AIXM is, governance (FAA + EUROCONTROL), and how it sits in AIM/SWIM.
• components.md — feature catalogue (AirportHeliport, RunwayCentrelinePoint, Navaid, Airspace, RouteSegment), the temporality model, and the extension mechanism.
• blocks.md — version history of AIXM (3.x, 4.5, 5.0, 5.1, 5.1.1, 5.2) treated as the framework's "blocks".
• threads.md — feature families (Organisation/Authority, Airspace, Points and Paths, Obstacles, Procedure, Service).
• modules.md — anatomy of an AIXM feature: objective, schema, lifecycle, enablers.
• enablers.md — XML Schema tooling, GML, ISO 19100 series, validation, profile management.
• performance_objectives.md — data quality KPAs (integrity, accuracy, resolution, timeliness, completeness, traceability).
• timeline.md — AIXM 3 → 5.1.1 → 5.2 history and joint FAA / EUROCONTROL governance.
• references.md — ICAO Annex 15, PANS-AIM (Doc 10066), Doc 8126, AIXM and ISO references.

Reading order#

Start with overview.md, then components.md, then blocks.md (versions) and threads.md (feature families). Drill into modules.md, enablers.md, and performance_objectives.md for the engineering and data-quality detail. Use timeline.md for governance dates and references.md for citations.

Source basis#

Content is grounded in:

• ICAO Annex 15 (Aeronautical Information Services), 17th edition.
• ICAO Doc 10066 (PANS-AIM), Chapter 5, especially §5.3.1.5 and §5.3.1.6.
• ICAO Doc 8126 (Aeronautical Information Services Manual), Part II.
• AIXM 5.1 / 5.1.1 Specification (EUROCONTROL/FAA, 2018).
• AIXM 5.2 Specification (AIXM CCB, January 2025).
• OGC Geography Markup Language (GML) 3.2 / ISO 19136.
• ISO 19100 series (19103, 19107, 19108, 19109, 19115).
• AIXM website: https://aixm.aero/

What AIXM is#

AIXM stands for Aeronautical Information Exchange Model. It is a global, open data exchange specification for aeronautical information. AIXM comprises two artefacts that travel together:

1. A logical data model expressed as UML class diagrams describing aeronautical features, their attributes, associations, and code lists.
2. An XML Schema (XSD) encoding that uses a profile of the OGC Geography Markup Language (GML 3.2) for geospatial properties and a GML-aligned temporality framework for time-varying data.

The model is published at https://aixm.aero/ together with normative schemas, business-rule libraries, the temporality concept document, and the Digital NOTAM specification.

Governance — joint FAA and EUROCONTROL stewardship#

AIXM is co-stewarded by EUROCONTROL and the U.S. Federal Aviation Administration, with contributions from the U.S. National Geospatial-Intelligence Agency (NGA), through a joint AIXM Change Control Board (CCB). The CCB:

• Maintains the UML model and XSD encoding.
• Reviews and decides change proposals (CPs) submitted by users.
• Coordinates major and minor releases, errata, and the Digital NOTAM Event Specification.
• Publishes guidance, including the Temporality Concept document and business-rule encodings.

Working pages and change proposals are tracked on the EUROCONTROL SWIM Confluence (swim-eurocontrol.atlassian.net). This dual-agency stewardship is what gives AIXM its reach: every aeronautical authority that exchanges data with either the U.S. NAS or the European Network Manager touches the same model.

Where AIXM sits in ICAO AIM and SWIM#

In the ICAO framework AIXM is treated as the de facto best-practice implementation of the "standard aeronautical information exchange model" required for digital AIM and System-Wide Information Management (SWIM).

• Annex 15 (Aeronautical Information Services), Chapter 2, §2.3.10 requires that "globally interoperable aeronautical data and aeronautical information exchange models shall be used for the provision of data sets". The detailed specification is deferred to PANS-AIM (Doc 10066) and the implementation guidance to Doc 8126.
• PANS-AIM (Doc 10066), Chapter 5, §5.3.1.5 requires the model to be expressed in UML, to include data value constraints and verification rules, to provide metadata, and to "include a temporality model to enable capturing the evolution of the properties of an aeronautical information feature during its life cycle". §5.3.1.6 requires a commonly used encoding format (XML, GML or JSON) and an extension mechanism. AIXM meets every one of these clauses by design.
• Doc 8126 (AIS Manual), Part II, Chapter 2, §2.2.7.6 states that "the Aeronautical Information Exchange Model (AIXM) is considered as best practice for formatting and exchanging digital aeronautical data."
• Doc 8126, §7.2.6 groups AIXM with FIXM (flight) and IWXXM (meteorological) as the trio of exchange models that "facilitate seamless retrieval, exchange and distribution" across ATM/AIM/MET.

Why AIXM exists#

Before AIXM, States exchanged aeronautical information as PDFs of AIPs and free-text NOTAMs. Both are designed to be parsed by humans, not machines: airspace boundaries are prose, dates are abbreviated, and the relationships between objects (a runway belongs to an airport, which hosts a navaid, which serves a procedure) are implicit. This blocks automation in flight planning, briefing systems, performance computers, and any service that needs current, structured aeronautical context.

AIXM solves this by:

• Giving every feature a stable identifier (UUID, carried in gml:identifier).
• Modelling relationships explicitly through UML associations.
• Carrying geometry in GML 3.2 primitives so coordinates are machine-readable and CRS-tagged.
• Carrying time through the temporality model so the same schema can encode static AIP content and dynamic NOTAM-equivalent events.

AIXM and the SWIM trio#

AIXM is one of three GML-based ICAO exchange models that ride on SWIM:

• AIXM — aeronautical features (airports, navaids, airspace, routes, procedures, obstacles).
• FIXM — flight and flow information (the structured replacement for the legacy filed flight plan).
• IWXXM — operational meteorological information (METAR, TAF, SIGMET, AIRMET, VAA, TCA) per Annex 3.

AIXM supplies the shared aeronautical context that FIXM messages refer to and that IWXXM products are issued against. The three models share a common GML ancestry, which is why payloads from different domains can be mixed inside one SWIM service without semantic collision.

What AIXM is not#

• AIXM is not an AIP rendering format. AIP charts and PDFs are produced from AIXM data, not vice versa.
• AIXM is not a flight-plan format. That is FIXM.
• AIXM is not a meteorological format. That is IWXXM.
• AIXM is not mandatory in itself. ICAO mandates the use of a globally interoperable exchange model; AIXM is the universally recognised implementation of that requirement.

AIXM is structured as a catalogue of features plus a temporality model plus an extension mechanism. Together these answer: what is modelled, how it changes over time, and how local needs are added without breaking interoperability.

1. Features — the catalogue#

A feature in AIXM is a thing in the real aeronautical world that is identifiable, persistent, and worth tracking through change. Each feature type is defined in UML with its attributes, associations to other features, and applicable code lists. Representative feature classes:

Airports and runways#

• AirportHeliport — the aerodrome itself: ICAO/IATA designator, name, location, type, ARP, elevation, magnetic variation.
• Runway — physical runway with designator, surface, length, width, centreline geometry.
• RunwayDirection — the directional half of a runway (e.g. 25R) with threshold and end attributes.
• RunwayCentrelinePoint — discrete points along the runway centreline used by procedure design (THR, DER, displaced threshold).
• TouchDownLiftOff — TLOF area for heliports.
• Taxiway, ApronElement, AircraftStand — surface movement features (extended in detail by AMXM).

Navaids and points#

• Navaid — radio navaid grouping (a "VOR/DME at GLINA").
• NavaidEquipment subclasses — VOR, DME, NDB, ILS, MLS, Marker, TACAN, GBAS, SBAS — the individual installations that compose a Navaid.
• DesignatedPoint — named waypoint (5-letter ICAO name code).
• AngleIndication / DistanceIndication — point fixes defined by bearing/distance from a navaid.

Airspace and routes#

• Airspace — controlled, advisory, danger, restricted, prohibited, TSA/TRA, FIR/UIR, sector. Carries class, type, designator, vertical limits, geometry (which may be a Surface or a sequence of curve segments referencing other features).
• AirspaceVolume — the geometric component of an Airspace, allowing composite airspaces.
• Route — published ATS route (UN851, B201, etc.).
• RouteSegment — one leg of a Route between two points; carries level constraints, direction of flight, navigation specification.
• StandardInstrumentDeparture / StandardInstrumentArrival / InstrumentApproachProcedure — procedures and their leg sequences.

Procedures and obstacles#

• ProcedureLeg — the building block of SID/STAR/IAP, expressing the ARINC 424 path-and-terminator concept (TF, RF, CF, VA, etc.).
• Obstacle — natural or artificial obstacle with geometry, height, lighting, and AIP coverage area linkage.

Services and organisations#

• Unit — operational ATS unit (ACC, APP, TWR, FIC, AFIS).
• OrganisationAuthority — State authority, AIS provider, operator.
• AirTrafficControlService, InformationService, TrafficSeparationService, AirportClearanceService — service classes carried by an Airspace or Unit.
• RadioCommunicationChannel, RadioFrequencyArea — frequency assignments.

2. Temporality model#

Every AIXM feature carries a sequence of TimeSlice objects. A TimeSlice expresses the state of the feature over a defined validity window. Each TimeSlice has an interpretation attribute drawn from a fixed code list:

• BASELINE — the long-term reference state of the feature. The AIP picture.
• PERMDELTA — a permanent change being introduced. Once the change takes effect, BASELINE is reissued to reflect it.
• TEMPDELTA — a temporary overlay over the BASELINE. This is what carries Digital NOTAM events (runway closure, navaid out of service, airspace activation, RVR equipment unserviceability).
• SNAPSHOT — the resolved state at a given instant; produced by applying any active TEMPDELTAs to the BASELINE.

This four-mode pattern is what allows the same XSD to carry both static AIP-equivalent content and dynamic NOTAM-equivalent events. The Temporality Concept document (v1.1 with AIXM 5.1.1; v1.2 with AIXM 5.2) specifies the rules formally.

3. Identification#

Features carry stable UUIDs in gml:identifier. The UUID survives changes to attributes, geometry, name, and even airport assignment. This enables:

• Cross-data-set association (a Digital NOTAM TEMPDELTA references the exact navaid by UUID).
• Update tracking (a baseline reissue replaces the prior TimeSlice for the same UUID).
• External cross-reference (procedure data in one source can cite a navaid published by another).

4. Extension mechanism#

AIXM provides a controlled extension mechanism so regional or State needs can be expressed without forking the schema. Extensions are:

• Defined in their own XML namespace.
• Attached through an Extension element inside a host feature.
• Versioned independently of the core schema.
• Subject to change control by the originating organisation.

EUROCONTROL Network Manager and the FAA both publish extensions for their service-level requirements; both retain the core AIXM schema unchanged so that an instance document can be processed by any AIXM-aware reader, with the extension content optionally ignored. PANS-AIM §5.3.1.6 c) explicitly requires this extensibility property.

5. Code lists and value spaces#

Coded attributes (airspace type, navaid type, runway surface, procedure leg type, etc.) draw from controlled vocabularies maintained alongside the schema. Code lists are versioned with the spec and follow ISO 19139 patterns where applicable. State-specific values are accommodated through the OTHER value plus an annotation, or through an extension.

6. Geometry and CRS#

Geometry uses GML 3.2 primitives:

• Points carried as <gml:Point><gml:pos> with WGS-84 (EPSG:4326).
• Curve geometries (route segments, airspace boundaries) carried as gml:Curve with arc/line segments.
• Surfaces (airspace footprints) as gml:Surface / gml:Polygon.
• Heights and elevations carried with explicit units of measure and vertical reference (MSL, AGL, FL).

CRS tags are mandatory; AIXM does not allow geometry without an explicit coordinate reference system declaration.

AIXM does not have ICAO-style Block 0/1/2/3 availability windows. Its equivalent of a "block" is a major or minor version of the specification, each carrying a defined data model, XSD encoding, and companion artefacts (temporality concept, business rules, Digital NOTAM specification). The version sequence is:

Each version stays in service for a long time — operational systems move slowly. AIXM 5.1 was published in 2010 and remained the production baseline for over a decade. AIXM 5.1.1 added clarifications without breaking 5.1 instances. AIXM 5.2 (2025) is the first content-bearing update since 5.1 (2010).

AIXM 3.x — pre-GML era (2003–2006)#

Theme. Make European AIS data exchange possible at all.

• Designed for the EUROCONTROL European AIS Database (EAD).
• Flat XML schema; geometry expressed in AIXM-specific structures, not GML.
• No formal temporality concept — change was handled by reissuing records.
• Limited extension story.

AIXM 3.x is no longer used for new exchanges but archived data sets from this era still exist.

AIXM 4.5 — final pre-GML release (2006)#

Theme. Stabilise the 3.x lineage before the 5.x rewrite.

• Schema cleanups and additional features.
• Used in production for several years in parallel with the 5.x introduction.

AIXM 5.0 — the GML rewrite (2008)#

Theme. Re-found the model on ISO 19100 / GML for global interoperability.

• UML conceptual model formally aligned with the ISO 19100 series.
• XSD encoding using a GML 3.2 profile; geometry and time positions carried in GML primitives.
• Temporality concept introduced: BASELINE, PERMDELTA, TEMPDELTA, SNAPSHOT TimeSlices on every feature.
• Stable feature identifiers via gml:identifier.
• First version usable as a SWIM payload.

5.0 is rarely seen in the wild — most users skipped to 5.1.

AIXM 5.1 — production baseline (2010)#

Theme. Make 5.x operational.

• Refinement of the feature catalogue, code lists, and temporality rules.
• Companion Digital NOTAM Event Specification published — a catalogue of pre-defined event scenarios (runway closure, navaid unserviceability, airspace activation, special-use airspace, obstacle, GNSS RAIM outage, etc.) modelled as TEMPDELTA TimeSlices over baseline features.
• Adopted by EUROCONTROL Network Manager and the FAA NAS.
• The de facto standard for SWIM aeronautical services for over a decade.

AIXM 5.1.1 — errata release (2018)#

Theme. Clarify without breaking.

• Errata and clarifications to schema and documentation.
• Temporality Concept v1.1 — clarified rules for change identification and SNAPSHOT computation.
• Fully data-compatible with 5.1: a 5.1 instance is also a 5.1.1 instance with negligible adjustment.

5.1.1 is the version most production AIM systems run today.

AIXM 5.2 — content update (January 2025)#

Theme. First substantive content update since 5.1.

Released by the AIXM CCB in January 2025. Highlights:

• GNSS — expanded modelling of GNSS elements (constellations, augmentations, performance levels) supporting modern navigation specifications.
• Runway Condition Reporting (RCR) — alignment with the Global Reporting Format (Annex 14 amendment 13; GRF effective 2021) so runway condition codes and contaminant descriptors are exchanged in a structured form rather than free-text NOTAM/SNOWTAM.
• Instrument Flight Procedure (IFP) model — updates to procedure encoding aligned with PANS-OPS evolution and ARINC 424 path-and- terminator practice.
• Temporality Concept v1.2 — clarifications, finer change identification at complex-property level, no structural break with v1.1.
• Various code list extensions, association corrections, and metadata improvements.

5.2 is structurally compatible with 5.1.1 but introduces new optional elements; producers and consumers migrate at their own pace.

Version dependency principle#

Each AIXM version is a complete, self-contained spec; there are no cross-version dependencies in the ICAO ASBU sense. But operationally:

• A consumer that supports 5.1.1 can usually accept 5.1 instances with no change.
• A consumer that supports 5.2 must continue to accept 5.1.1 during the migration window.
• A producer that adopts 5.2 should publish a service description declaring schema version, namespace, and any extensions used.

Migration between major versions (3.x to 5.x) requires data re-modelling, not just schema swapping, because the underlying feature model changed fundamentally with the GML rewrite.

Where versions are published#

• AIXM 5.1 / 5.1.1 — https://aixm.aero/page/aixm-51-511
• AIXM 5.2 — https://aixm.aero/page/aixm-52 (release page) and https://aixm.aero/page/aixm-52-specification (specification).
• Temporality Concept v1.1 — https://aixm.aero/sites/default/files/imce/AIXM511/aixm_temporality_1.1.pdf
• Digital NOTAM Event Specification — https://aixm.aero/page/digital-notam

Where ASBU groups improvements into Threads, AIXM groups its features into feature families. A feature family is a coherent subset of the catalogue that addresses one slice of aeronautical reality. The UML model is organised so that each family can be discussed, evolved, and delivered in a service independently of the others.

The families below reflect the AIXM 5.1.1 / 5.2 model.

1. Organisation and Authority#

The "who" of the system. Encodes the legal and operational entities that produce, regulate, or consume aeronautical information.

• OrganisationAuthority — State civil aviation authority, ANSP, AIS provider, military authority, airport operator, airline.
• Unit — operational ATS unit (ACC, APP, TWR, AFIS, FIC, COM, MET).
• AeronauticalGroundLight operator references.
• Address, contact, jurisdiction, period of operation.

This family is the anchor for accountability: every other feature can trace its provider, designating authority, and area of responsibility through associations into Organisation/Authority.

2. Airspace#

The "where, in three dimensions" of the system.

• Airspace — the airspace itself, with class, type (CTR, TMA, FIR, UIR, ATZ, restricted, danger, prohibited, TSA/TRA, RMZ/TMZ), local designator, and activation pattern.
• AirspaceVolume — the geometric component, allowing composite airspaces and complex vertical limits.
• AirspaceLayer / AirspaceGeometryComponent — composition rules (UNION, INTERSECTION, SUBTRACTION) so an airspace can be defined as the difference of two volumes.
• AirspaceBorderCrossing — coordination point on a FIR boundary.
• DirectFlightSegment — direct routing element in a free route airspace.

The Airspace family is the most geometry-heavy area of AIXM. It is also the area most exercised by Digital NOTAM (activation/deactivation of restricted areas, opening of TSAs).

3. Points and Paths#

Navigation reference geometry: where aircraft are told to be.

• DesignatedPoint — named ICAO 5-letter waypoint.
• Navaid and NavaidEquipment subclasses (VOR, DME, NDB, ILS, MLS, TACAN, GBAS, SBAS).
• AngleIndication, DistanceIndication — bearing/distance fixes.
• Route and RouteSegment — published ATS routes.
• EnRouteSegmentPoint / TerminalSegmentPoint — segment endpoints with role discriminators.
• Approach, StandardInstrumentDeparture, StandardInstrumentArrival, InstrumentApproachProcedure.
• ProcedureLeg family — the path-and-terminator legs (TF, CF, RF, VA, FA, etc.) that compose every IFP.

This family is the densest from a procedure-design perspective: a single RNP AR approach is dozens of associated objects.

4. Aerodromes and Surface#

The "ground" of the system.

• AirportHeliport — aerodrome itself.
• Runway, RunwayDirection, RunwayElement.
• RunwayCentrelinePoint — discrete points (THR, DER, displaced THR) used by procedure design and approach charting.
• RunwayDeclaredDistance — TORA, TODA, ASDA, LDA.
• Taxiway, TaxiwayElement, ApronElement, AircraftStand.
• TouchDownLiftOff — for heliports.
• VisualAid — PAPI, lighting, signage references.
• AirportSuppliesService — fuel, de-icing, ground handling.

Detailed surface mapping (taxiway centrelines, hot spots, parking positions to within centimetres) is delegated to the companion AMXM — Aerodrome Mapping Exchange Model — for AMDB-grade content.

5. Obstacles#

• Obstacle — natural or artificial obstacle with geometry, height, lighting state, marking, and AIP-area assignment.
• Ties into Annex 15 Appendix 1 obstacle data set requirements (Areas 1–4).
• Carried by AIXM where it sits in the AIM exchange; bulk obstacle data sets often complement AIXM with formal eTOD GIS layers.

6. Procedure#

Closely related to Points and Paths but worth treating as a family because of its size and procedural-design concerns.

• InstrumentApproachProcedure — IAP including initial, intermediate, final, missed approach segments.
• StandardInstrumentDeparture / StandardInstrumentArrival.
• ProcedureLeg — leg-by-leg path-and-terminator (ARINC 424-aligned).
• Minima — approach minima (DA/DH, MDA/MDH, RVR/CMV).
• HoldingPattern.
• TerminalArrivalArea — RNP terminal arrival areas.

7. Service#

The "what is offered" of the system. AIXM models services as features so that SWIM consumers can discover and bind to them.

• AirTrafficControlService, InformationService, TrafficSeparationService, AirportClearanceService, SearchAndRescueService.
• RadioCommunicationChannel, RadioFrequencyArea — air-ground voice and data link frequency assignment.
• CallsignDetail.
• Service-area associations to Airspace, Unit, and AirportHeliport.

Cross-family dependencies#

• Procedure depends on Points and Paths (every leg references a fix or navaid) and on Aerodromes and Surface (runway centreline points, declared distances).
• Airspace depends on Points and Paths (boundary curves reference designated points and navaids).
• Service depends on Organisation/Authority (every service has a provider) and on Airspace or Unit (every service has a responsibility area).
• Obstacle depends on Aerodromes and Surface (Areas 1–4 are defined relative to runways).

These dependencies are why AIXM data exchange is rarely "one feature type at a time" — services usually publish a coherent slice of the graph.

Where ASBU has Modules at the intersection of Block and Thread, AIXM has features as its unit of modelling. Each feature is a coherent, named, identifiable thing in aeronautical reality, modelled in UML and encoded in XSD.

This file documents the structured shape of an AIXM feature so that producers and consumers know exactly what they are dealing with, and worked examples for three representative features.

Anatomy of an AIXM feature#

1. Title and identifier#

• A class name in the UML model (e.g. Navaid, Airspace, RunwayCentrelinePoint).
• A stable feature-instance identifier in gml:identifier (UUID).
• A human-readable designator attribute (e.g. ICAO 4-letter airport code, navaid identifier, airspace local designator).

2. Operational description#

A plain-language statement of what the feature represents in the real world. Carried as feature-level documentation in the spec; a producer populates the corresponding description/name attributes in instance data.

3. Logical schema (UML)#

• Attributes (typed, with cardinalities and code-list bindings).
• Associations (named relationships to other feature classes, with multiplicities — e.g. Runway belongs to AirportHeliport 1..1; AirportHeliport has Runway 0..*).
• Inheritance from abstract base classes (e.g. AbstractAIXMFeature → Navaid).

4. Encoding (XSD)#

• XML element name in the AIXM target namespace.
• Geometry elements typed against GML 3.2 primitives.
• Time positions typed against GML temporal types.
• Code-list-bound attributes typed against ISO 19139 / GML code-list patterns.

5. Lifecycle (TimeSlices)#

Every feature carries one or more TimeSlice objects. Each TimeSlice has:

• validTime — the period for which this state applies.
• interpretation — BASELINE / PERMDELTA / TEMPDELTA / SNAPSHOT.
• featureLifetime — when the feature first existed and (if applicable) ceased to exist.
• The actual property values for that time slice.

The TimeSlice is what makes AIXM more than a snapshot schema: a navaid with a baseline state and an active TEMPDELTA marking it unserviceable correctly represents both the AIP picture and the current operational state in one document.

6. Business rules#

Rules that go beyond what XSD can express. Carried as Schematron-style assertions in the spec's business-rule library. Examples:

• A runway's TORA cannot exceed the runway physical length.
• An ILS NavaidEquipment must reference the runway direction it serves.
• A SID must originate at a runway end designated point.
• A TEMPDELTA cannot extend an associated entity beyond the BASELINE feature lifetime.

7. Code lists#

Coded attributes (airspace type, navaid type, runway surface, ATS route type, procedure leg type) draw from controlled vocabularies maintained alongside the schema and versioned with it.

8. Standards basis#

Relevant SARPs and PANS that ground each feature:

• Annex 11 (ATS), Chapter 2 — airspace classification underlying Airspace.
• Annex 14 (Aerodromes), Volume I — runway, taxiway, declared distances underlying Aerodromes and Surface.
• Annex 10 (Aeronautical Telecommunications), Volume I — navaid performance underlying NavaidEquipment.
• Annex 15 (AIS), Chapter 5 and Appendices — data set requirements for AIP, terrain, obstacle, aerodrome mapping, IFP.
• PANS-AIM (Doc 10066), Chapter 5 and Appendices — Aeronautical Data Catalogue, data quality requirements (accuracy, integrity, resolution, publication resolution) feeding into AIXM attribute precision.
• PANS-OPS (Doc 8168) — procedure-design rules behind the Procedure family.

9. Enablers#

Tooling, infrastructure, and skills required to use the feature: XSD processors, GML libraries, validation engines, AIM data management systems, and trained AIM data officers. See enablers.md.

10. Consumers and downstream products#

What systems use the feature once published: flight-planning systems, briefing and NOTAM filtering systems, FMS database vendors (Jeppesen, Lido, NavBlue, Honeywell), AMAN/DMAN, performance computers, airline-OCC platforms.

Worked examples#

Example 1 — AirportHeliport#

• Operational description. The aerodrome itself: identifying code, name, location, type, ARP, elevation, magnetic variation, declared distances, certification status.
• Schema. Subclass of AbstractAIXMFeature. Associations to Runway (0..), Taxiway (0..), Service (0..*), and obstacles in proximity.
• Lifecycle. A new aerodrome is created with a BASELINE TimeSlice whose featureLifetime begins at its commissioning date. Closures and partial unavailability are TEMPDELTAs. Permanent renaming or reclassification is a PERMDELTA followed by a re-baseline.
• Standards. Annex 14 Vol I (design), Annex 15 Chapter 5 and Appendix 1 (data set). PANS-AIM 5.3.3 and Aeronautical Data Catalogue.

Example 2 — Navaid with NavaidEquipment (VOR/DME)#

• Operational description. A radio navaid grouping (e.g. VOR/DME GLINA) composed of one or more equipment units, each with its own identifier, frequency, operating hours, and performance class.
• Schema. Navaid aggregates one or more NavaidEquipment instances (VOR, DME). Each equipment unit has frequency, callsign, operating hours, magnetic variation, and a geometry.
• Lifecycle. A typical Digital NOTAM for navaid unserviceability is a TEMPDELTA TimeSlice on the affected NavaidEquipment with availability set to NOT_AVAILABLE for the validity window. The underlying BASELINE is unchanged; SNAPSHOT during the window resolves to the unserviceable state.
• Standards. Annex 10 Vol I, Vol II (procedures), Vol IV (surveillance not relevant here). PANS-OPS for use in IFPs.

Example 3 — Airspace (e.g. a TSA)#

• Operational description. A temporary segregated area whose activation is published in advance through schedules and triggered daily by Digital NOTAM.
• Schema. Airspace carries class, type (TSA), local designator, vertical limits, and a geometry association to one or more AirspaceVolume objects describing the 3-D footprint.
• Lifecycle. BASELINE TimeSlice describes the area's permanent attributes and default activation pattern. Each daily activation is a TEMPDELTA TimeSlice with activation set to ACTIVE for the declared validity, optionally with a different vertical limit. A consumer SNAPSHOT for any instant correctly reports whether the area is active.
• Standards. Annex 11 (ATS) Appendix 4 airspace classification table; PANS-ATM (Doc 4444) Chapter 16 ATFM and FUA principles where applicable.

How features become a service#

A SWIM service publishing AIXM data is built by:

1. Selecting the feature families relevant to the service scope (e.g. "European airspace structure", "U.S. NAS NOTAM", "FIR-level AIP subset").
2. Defining the temporality envelope — does the service publish only BASELINE, only TEMPDELTA, or both?
3. Defining how updates are delivered (full snapshot, incremental, or message-based publish/subscribe).
4. Declaring schema version and any extensions used.
5. Publishing the service through the SWIM service registry with policy-based access.

This is what the AIXM specification, the Digital NOTAM Event Specification, and the SWIM service governance frameworks together enable.

An enabler for AIXM is a supporting standard, tool, or capability without which AIXM cannot deliver its intended benefit. AIXM is a specification, not a system; it relies on an ecosystem of standards and tooling to become operational. The categories below cover that ecosystem.

1. XML Schema and core XML tooling#

• XML Schema 1.0 (XSD) — the encoding language for AIXM. AIXM schemas are valid against XSD 1.0 processors so that any standard toolchain (Java JAXB, .NET XmlSerializer, libxml2, Python lxml) can load them.
• Schema-aware XML editors — for instance authoring (Oxygen XML, Altova XMLSpy).
• Schematron / ISO 19757-3 — used to encode AIXM business rules that are beyond XSD's expressive power (cross-attribute constraints, cardinality conditional on type codes, geometry validity).
• XSLT 2.0/3.0 — for AIXM-to-AIXM transforms (version uplift, subset extraction) and for chart/AIP generation.
• XPath / XQuery — for navigating AIXM instances and computing SNAPSHOT views.

These are commodity tools; the value AIXM adds is the schema, business rules, and conventions on top of them.

2. GML and OGC geospatial stack#

• OGC Geography Markup Language (GML) 3.2 — equivalent to ISO 19136. AIXM uses a profile of GML for all geometry and time primitives.
• GML-aware geometry libraries — JTS Topology Suite, GeoTools, PostGIS, GDAL/OGR — for parsing AIXM geometry, reprojecting, intersecting, and converting to common GIS formats.
• OGC Web Feature Service (WFS) / OGC API Features — possible delivery mechanisms for AIXM data products.
• Schematron geometry validators — for closed-curve, non-self- intersection, vertical-limit consistency, and other geometric constraints.

GML is what lets AIXM data be loaded into general GIS without bespoke parsers. It is also what aligns AIXM with the IWXXM (MET) and OGC-based flight-information environments.

3. ISO 19100 series#

The AIXM conceptual model is grounded in the ISO 19100 family of geographic-information standards:

• ISO 19103 — Conceptual schema language (UML profiles for geographic information).
• ISO 19107 — Spatial schema (geometry and topology primitives).
• ISO 19108 — Temporal schema (the basis for the AIXM temporality concept).
• ISO 19109 — Rules for application schema (how to define a geospatial application schema in UML).
• ISO 19115 — Metadata.
• ISO 19136 — Geography Markup Language (GML), the encoding for ISO 19109 application schemas.
• ISO 19139 — Metadata XML schema implementation; informs AIXM's code-list patterns.
• ISO 19157 — Data quality, providing the framework that PANS-AIM data quality requirements draw on.

PANS-AIM §5.3.1.5 a) explicitly requires UML; ISO 19103 / 19109 is the shared rulebook for how that UML is expressed.

4. Validation pipeline#

Operational AIM systems run AIXM data through a multi-stage validator:

1. Well-formed XML check.
2. XSD schema validation — type and cardinality conformance.
3. Code-list validation — coded attributes against the published value set.
4. Schematron business rules — cross-attribute and cross-feature constraints.
5. Geometric validation — non-self-intersection, vertical limit ordering, CRS conformance.
6. Temporality validation — TimeSlice interpretations, validTime coherence, TEMPDELTA lifetime within BASELINE feature lifetime.
7. Reference integrity — UUIDs resolve, associations are bidirectional where required.
8. PANS-AIM data quality conformance — accuracy, integrity, and resolution attributes within the catalogue requirements.

Validation libraries are published by EUROCONTROL (AIXMValidator / related tools) and by community projects. The FAA AIXM tooling (aixm-tools, available on GitHub) covers schema and Schematron checking for U.S. NAS data.

5. Profile management and extensions#

• Service-level profiles — a SWIM service typically defines a profile that fixes which AIXM features, attributes, and code lists are in scope.
• Extension namespaces — for State or service-specific properties. Each extension has its own XSD and is invoked through the AIXM Extension host element.
• Profile catalogues — published by the consuming service so that producers know exactly what is required (and what is not).

EUROCONTROL Network Manager and the FAA both publish profile and extension catalogues for the data they ingest.

6. Identification and registry#

• UUIDs — required on every feature, ensuring stable cross-data-set reference. Generation typically follows RFC 4122.
• AIXM CCB registries — code-list values, extension namespaces, Digital NOTAM event scenarios, and business-rule catalogues, all published with each release on aixm.aero.
• SWIM service registries — used to publish AIXM-bearing services so consumers can discover them and bind to them.

7. Skills and roles#

• AIM data officers trained in PANS-AIM data quality requirements and AIXM modelling.
• Geospatial data engineers familiar with GML, ISO 19100, and CRS handling.
• XML/Schematron engineers for validation rule authoring.
• Procedure designers familiar with the AIXM Procedure family and ARINC 424 leg semantics.
• SWIM service architects familiar with the AIXM service profile and lifecycle.

8. How enablers come together in production#

A producing organisation typically runs:

• An AIM data store (commercial or in-house) that holds the authoritative aeronautical data set with full temporality.
• An AIXM exporter that emits XSD-valid AIXM instances on demand or on schedule.
• A validation gate that blocks publication of non-conforming data.
• A SWIM service endpoint publishing AIXM payloads with policy- based access.

A consumer typically runs:

• A SWIM client receiving AIXM payloads.
• An AIXM ingest that maps features to its internal model (preserving UUIDs).
• A temporality resolver that computes SNAPSHOT views for briefing, NOTAM display, or flight-planning context.
• Domain-specific downstream tooling (chart generation, FMS database build, briefing system, performance computer).

When any of these is missing, AIXM cannot deliver its benefit even if the data on the wire is valid. This is why AIXM enablement is a multi-year programme, not a procurement event.

AIXM does not have ASBU-style Performance Objectives tied to KPAs like "capacity" or "flight efficiency". Its performance lens is data quality: an AIXM data set is judged on whether it accurately, completely, and timely represents the real aeronautical world. The governing requirements come from Annex 15 and PANS-AIM Doc 10066, which together define the data quality regime for aeronautical information and which AIXM is built to express.

The data-quality framework draws on ISO 19157 (geographic information data quality) and the PANS-AIM Aeronautical Data Catalogue.

The data quality dimensions#

PANS-AIM defines required values for each data item along several dimensions. AIXM provides the attributes and metadata to record those values for every feature instance.

1. Accuracy#

How close a stored value is to the true value of the property. Specified per data item in the Aeronautical Data Catalogue.

• Horizontal coordinate accuracy at runway thresholds: 1 m.
• Horizontal accuracy at navaids serving en-route: 100 m or better depending on category.
• Vertical accuracy at runway thresholds: 0.25 m for precision approach serving runways.
• Obstacle accuracy: depends on Area (1, 2, 3, 4) and obstacle type.

AIXM expresses accuracy through metadata associated with measured values; the schema does not constrain the value itself but records the declared accuracy.

2. Resolution#

The granularity at which the value is stored and at which it is published. PANS-AIM distinguishes:

• Stored resolution — the precision held in the database.
• Publication resolution — the precision on charts and AIP.
• Chart resolution — the precision rendered on each chart product.

AIXM attribute types preserve full stored resolution; downstream products derive their own publication resolution as required.

3. Integrity#

The probability that an undetected error has corrupted the data along the chain from origination to use. PANS-AIM classifies aeronautical data into three integrity classes:

• Routine data — 1 × 10^-3.
• Essential data — 1 × 10^-5.
• Critical data — 1 × 10^-8.

Critical data includes runway thresholds, ILS reference points, the geometry of obstacle clearance surfaces. AIXM carries the integrity classification per data item and supports cyclic redundancy checks (CRC-32) on data sets where the catalogue requires them.

4. Timeliness#

How current the data is relative to the moment of operational use. PANS-AIM imposes the AIRAC cycle (effective dates aligned to a 28-day cycle) for permanent changes and NOTAM/Digital NOTAM for short-notice operational changes.

AIXM expresses timeliness through:

• TimeSlice validTime — when each state of the feature applies.
• TimeSlice featureLifetime — the existence span of the feature.
• AIRAC effective date alignment for PERMDELTA TimeSlices used in AIP data sets.
• TEMPDELTA TimeSlices for short-notice events (Digital NOTAM).

5. Completeness#

Whether all required data items are present and whether all real-world features are represented.

• Annex 15 / PANS-AIM specify required and conditional data items per feature type.
• AIXM cardinalities and Schematron rules detect missing required values during validation.
• Coverage completeness is a service-level concern (does the data set cover the entire State or just one airport?) and is recorded in the service description rather than the schema.

6. Traceability#

The ability to identify the origin of any data item and the chain of transformations to its current state. PANS-AIM requires originator identification and change history.

• AIXM gml:identifier (UUID) gives every feature a stable identity.
• TimeSlice history within a feature gives the change history.
• Metadata associations allow originator identification.

7. Format compliance#

The data set conforms to the published exchange model and profile. AIXM XSD validation, code-list validation, and Schematron business rules together evidence format compliance.

Mapping to KPAs#

While AIXM is data-quality-centred, its outputs feed the broader ATM KPAs of Doc 9854:

• Safety — high-integrity AIXM data underpins charted procedures, obstacle assessments, and PBN approach codings; errors propagate to safety-of-flight outcomes.
• Capacity — accurate and timely AIXM data feeds AMAN/DMAN, NOPS, and TBO services that depend on current navaid, route, and airspace state.
• Flight efficiency — current free-route airspace definitions, navaid availability, and procedure libraries enable optimum-routing computations.
• Predictability — Digital NOTAM via AIXM TEMPDELTA gives flight planning systems advance, structured knowledge of operational constraints.
• Cost-effectiveness — replacing duplicated, manual data flows with one authoritative AIXM data set per State reduces both the AIM authority's cost and the consumers' cost.
• Interoperability and global interoperability — the entire point of the model.

How quality is reported#

There is no single global AIXM data-quality monitoring report. Quality is reported through:

• State / ANSP quality management systems (PANS-AIM Chapter 3) with periodic audits.
• EUROCONTROL Network Manager ingestion-quality reports for the European AIS Database (EAD).
• FAA NFDC / AeroNav Products quality assurance for U.S. NAS data.
• Service-level conformance reports at SWIM consumer endpoints (validation pass rate, latency, completeness).

When a flight-planning vendor or briefing system reports a problem, the chain back to the originating AIXM data set, its TimeSlice, and its provider is enabled by the UUID + temporality + traceability metadata in the model.

Why this matters#

AIXM is the format in which the safety-critical, regulator-published picture of the airspace system reaches every consumer. The data quality lens is what keeps the model trustworthy: a perfectly schema- valid AIXM instance with an inaccurate runway threshold, an outdated navaid frequency, or a missing TEMPDELTA for a closed runway is worse than no data at all. PANS-AIM and Annex 15 define what "good" looks like; AIXM is the carrier that makes it conformable, exchangeable, and auditable.

Three timelines to keep distinct#

When discussing AIXM "dates", separate three things:

1. AIXM specification timeline — when the AIXM CCB published or amended the model itself.
2. ICAO regulatory timeline — when ICAO mandated the use of a globally interoperable exchange model.
3. National adoption timeline — when each State or organisation migrated AIS / AIM systems and data to AIXM.

National adoption lags both other timelines and is paced by the AIS-to- AIM transition (roughly tracking ASBU Block 0 / Block 1 windows).

AIXM specification timeline#

The cadence has been approximately one significant release per decade (5.0 in 2008, 5.1 in 2010, 5.2 in 2025), with errata and clarifications between. This slow cadence reflects the operational reality that AIM systems are long-lived and migrations are expensive.

ICAO regulatory timeline (mandates that drive AIXM uptake)#

Doc 8126 (AIS Manual) §2.2.7.6 declares AIXM "best practice" in the Part II current edition, anchoring AIXM as the recognised implementation of the PANS-AIM exchange-model requirements.

Joint FAA / EUROCONTROL governance#

The dual-agency stewardship model has been stable since 2005:

• 2005: Memorandum of Cooperation between FAA and EUROCONTROL formally establishes AIXM as a joint specification.
• AIXM Change Control Board (CCB) constituted with members from both organisations plus NGA observer/contributor status.
• Working pages, change proposal tracking, and discussion forums hosted on the EUROCONTROL SWIM Confluence (swim-eurocontrol.atlassian.net).
• Public-facing release pages, downloads, and tutorials at aixm.aero.
• Regular CCB meetings, change-proposal cycles, and major-release reviews.

The AIXM CCB also coordinates with:

• OGC for GML alignment.
• ICAO AIM Study Group / Information Management Panel — for alignment with PANS-AIM evolution.
• WMO / IWXXM developers — for shared GML practices in meteorological exchange.
• FIXM Change Control Board — for cross-domain references between flight and aeronautical context.

National adoption timeline (illustrative)#

National adoption depends on the State's AIS-to-AIM programme and is typically synchronised with regional plans (APAC Seamless ATM Plan, EUR ATM Master Plan, MID Air Navigation Strategy):

• 2008-2012 — Early adopters (EUROCONTROL EAD members, FAA, a few others) move to AIXM 5.0 / 5.1 for inter-State data exchange.
• 2013-2019 — ASBU Block 0 / DAIM-B0: States deliver electronic AIP and AIXM 5.1 data products, often via the EAD.
• 2019-2025 — ASBU Block 1 / DAIM-B1: full digital AIM, AIXM 5.1.1 data products feeding SWIM services. Digital NOTAM trials and rollouts (FAA, EUROCONTROL).
• 2025 onwards — AIXM 5.2 introduction; runway condition reporting (RCR) integration with the Global Reporting Format; broadened Digital NOTAM use.

Where Pakistan / APAC sit on this timeline#

Indicative regional context (verify current status against the latest ICAO APAC Implementation Plan, the APAC Seamless ATM Plan, and the APANPIRG AIM/SWIM task force outputs):

• Block 0 / DAIM-B0 — electronic AIP available across most States; AIXM 5.1 data exchange in development for some States via bilateral or regional arrangements.
• Block 1 / DAIM-B1 — active programme. Priority items: full AIXM 5.1.1 data sets, AIM data quality regime per PANS-AIM, SWIM-AIM service onboarding, Digital NOTAM trials.
• AIXM 5.2 — horizon planning; adoption follows once the regional Network Manager equivalents and key consumers (FMS database vendors) support the new content.

How to read a date in an AIXM context#

When a document gives an AIXM date, check which kind of date it is:

• "AIXM 5.1 (2010)" — specification publication date.
• "PANS-AIM applicable from 8 November 2018" — ICAO regulatory date.
• "AIXM 5.2 released January 2025" — specification publication date.
• "ANSP X migrated to AIXM 5.1.1 in 2022" — national operational milestone.
• "AIRAC effective date 28 March 2024" — instance-data validity, not spec or regulatory date.

Mixing these up causes false conclusions about whether a State, ANSP, or vendor is "behind" or "ahead". The only meaningful national measure is the State's AIS-to-AIM plan against its own declared milestones, sequenced through ASBU Block 0 / Block 1 windows.

Primary ICAO documents#

• Annex 15 (Aeronautical Information Services), 17th edition. The SARPs for AIS/AIM. Chapter 2, §2.3.10 — globally interoperable aeronautical data and aeronautical information exchange models for data sets. Chapter 3, §3.5.3 b) — automation requirements for globally interoperable exchange models. Chapter 5 and Appendices — data set content (AIP, terrain, obstacle, aerodrome mapping, instrument flight procedure).
• Doc 10066 (PANS-AIM), 1st edition (applicable from 8 November 2018). Foreword §1.1 b) — establishes SARPs for a standard aeronautical information conceptual model and standard aeronautical information exchange model. Chapter 5, §5.3.1.5 — UML, data value constraints, metadata, temporality model. §5.3.1.6 — encoding format (XML / GML / JSON) and extension mechanism. §5.3.3 — data set provisions. Aeronautical Data Catalogue (Appendix 1).
• Doc 8126 (AIS Manual), Part II. Chapter 2, §2.2.7.4 — illustrates AIXM coordinate (<gml:pos>) and date-time (<gml:beginPosition>) encoding. §2.2.7.6 — "the Aeronautical Information Exchange Model (AIXM) is considered as best practice for formatting and exchanging digital aeronautical data." Chapter 4, §4.2.4 — AIXM (with JSON) as data interchange format for AIP data sets. Chapter 7, §7.2.6 — AIXM/FIXM/IWXXM as the trio enabling seamless retrieval, exchange and distribution of information. Attachment E — AIXM data exchange format clause template.
• Doc 4444 (PANS-ATM). ATM procedures referenced by Service features and used in Digital NOTAM event scenarios.
• Doc 8168 (PANS-OPS). Procedure design rules underpinning the Procedure feature family.
• Doc 9750 (Global Air Navigation Plan). GANP / ASBU framework including the DAIM and SWIM threads under which AIXM is implemented.
• Doc 9854 (Global ATM Operational Concept) and Doc 9883 (Manual on Global Performance of the Air Navigation System). KPA and KPI framework used to justify AIM modernisation.
• Annex 3 (Meteorological Service for International Air Navigation). Where applicable, alongside IWXXM, illustrating the SWIM trio.
• Annex 10 (Aeronautical Telecommunications), Volumes I, II, IV. Source of navaid and surveillance performance underpinning relevant AIXM features.
• Annex 11 (Air Traffic Services). Airspace classification and ATS routes underpinning the Airspace and Points-and-Paths families.
• Annex 14 (Aerodromes), Volumes I and II. Aerodrome physical characteristics underpinning the Aerodromes-and-Surface family.

AIXM specification and CCB sources#

• AIXM home — https://aixm.aero/
• AIXM 5.1 / 5.1.1 specification — https://aixm.aero/page/aixm-51-511
• AIXM 5.2 release page — https://aixm.aero/page/aixm-52
• AIXM 5.2 specification — https://aixm.aero/page/aixm-52-specification
• Temporality Concept v1.1 (PDF) — https://aixm.aero/sites/default/files/imce/AIXM511/aixm_temporality_1.1.pdf
• Digital NOTAM Event Specification — https://aixm.aero/page/digital-notam
• AIXM Change Control Board working area / change proposals — https://swim-eurocontrol.atlassian.net (AIXM CCB and Digital NOTAM spaces).

EUROCONTROL and FAA implementation references#

• EUROCONTROL European AIS Database (EAD) — operational European AIM data set published in AIXM.
• EUROCONTROL Network Manager B2B services — SWIM services carrying AIXM payloads for the European Network.
• FAA System Wide Information Management (SWIM) — U.S. SWIM programme home; hosts AIXM-bearing services such as SAA (Special Activity Airspace), NFDC (National Flight Data Center) products, and Aeronav products.
• FAA NAS Common Reference (NCR) — FAA-side AIXM modelling and tooling reference.

ISO and OGC standards underpinning AIXM#

• ISO 19103 — Conceptual schema language (UML for geographic information).
• ISO 19107 — Spatial schema (geometry / topology primitives).
• ISO 19108 — Temporal schema (basis for AIXM Temporality Concept).
• ISO 19109 — Rules for application schema.
• ISO 19115 — Metadata.
• ISO 19136 — Geography Markup Language (= OGC GML 3.2).
• ISO 19139 — Metadata XML schema implementation.
• ISO 19157 — Data quality framework for geographic information.
• OGC Geography Markup Language (GML) 3.2 — geometry and time encoding used by AIXM.

Companion ICAO exchange models#

• FIXM (Flight Information Exchange Model) — https://fixm.aero/ — flight-domain twin used by FF-ICE.
• IWXXM (ICAO Meteorological Information Exchange Model) — Annex 3 / WMO; OPMET (METAR, TAF, SIGMET, AIRMET, VAA, TCA) in GML.
• AMXM (Aerodrome Mapping Exchange Model) — companion specification for surface and apron features; complements AIXM for AMDB-grade surface mapping.

Regional and training material#

• APAC Seamless ATM Plan (ICAO Asia/Pacific Regional Office) — APAC realisation of ASBU including DAIM/AIM/SWIM milestones.
• MID Air Navigation Strategy (ICAO MID Regional Office).
• European ATM Master Plan (SESAR JU) and EUROCONTROL LSSIP cycle reports — European programme references.
• ICAO APAC AAITF (AIM/SWIM Task Force) working papers and presentations — including the AAITF-19 (2024) overview of AIXM.
• ICAO AIM Study Group / Information Management Panel — global AIXM-relevant working groups.

External authoritative entry points#

• AIXM home — https://aixm.aero/
• OGC — https://www.ogc.org/standards/gml
• ISO Geographic Information / Geomatics (TC 211) — https://www.iso.org/committee/54904.html
• ICAO GANP Portal — https://ganpportal.icao.int/
• EUROCONTROL SWIM — https://www.eurocontrol.int/swim
• FAA SWIM — https://www.faa.gov/air_traffic/technology/swim