1. AIXM 5 Concepts
This presentation is based on the first part of the “AICM and AIXM 5 - Exchange Model goals, requirements and design” document. The purpose of this briefing is to introduce the main components of AIXM. We’ll begin by discussing the design requirements and approach. This will be followed by a summary of the major AIXM data model components.

2. Presentation Topics Requirements AIXM Design Components
Design Concepts
UML
ISO standards
Geography Markup Language (GML)
Temporality
Conceptual Model Packages
In this briefing we will cover three topics:
AIXM design principles
Design concepts
A review of the AIXM conceptual areas

3. Presentation Topics Requirements AIXM Design Components
Design Concepts
UML
ISO standards
Geography Markup Language (GML)
Temporality
Conceptual Model Packages
In this briefing we will cover three topics:
AIXM design principles
Design concepts
A review of the AIXM conceptual areas

4. Requirements Based on global aeronautical data requirements
ICAO standards and practices
RTCA/EUROCAE Airport Mapping Databases
PANS-Ops and TERPS Terminal Procedures
Airport Layout Plans (AirMAT)
NATO and Military requirements
Support for current and future AIM Information System Requirements
Aeronautical Information Publication (AIP)
Integrated Digital NOTAMs
Aerodrome Mapping Databases and Applications
Charts
Procedure Design
Situational displays
Industry requirements
The goal for AIXM 5 is to provide an extensible, modular aeronautical information exchange standard that can be used to satisfy information exchange requirements for current and future aeronautical information applications. These applications include:
Automated production of Aeronautical Information Publications (AIPs)
Automated aeronautical chart creation and publication systems
Integrated NOTAMs (e.g., xNOTAM)
Aerodrome Mapping Databases (AMDBs) and related applications
Electronic Flight Bag data requirements
Cockpit situational displays and Flight Management System (FMS) data requirements

5. Presentation Topics Requirements AIXM Design Components
Design Concepts
UML
ISO standards
Geography Markup Language (GML)
Temporality
Conceptual Model Packages
In this briefing we will cover three topics:
AIXM design principles
Design concepts
A review of the AIXM conceptual areas

6. AIXM Design Objectives
Technical Design Decisions
ISO19100 series
UML
GML 3.2
First, a number of technical design decisions: adoption of a number of international standards that would maximize the chances for interoperability (not only within the aeronautical domain but also with other transportation industries) while also reducing the implementation costs, by enabling the use of Commercial Off The Shelf (COTS) software:
Use GML (Geography Markup Language) for encoding geographical information – positions, areas, routes, etc.
As opposed to the custom geometry encodings used in the current AIXM 4.5
Use the ISO19100 series of geospatial information standards as data modelling framework
This would maximize the chances of cross-domain interoperability
Use UML (Unified Modeling Language) for developing AIXM 5 Conceptual Model
Closely linked to the ISO modelling framework, the requirement for exhaustive metadata incorporation into the model has been identified. Metadata is in fact closely linked to a stringent requirement, as highlighted in the previous presentations: the need to endure data integrity from end to end of the data chain.
Let’s see now how the scope of the model will evolve.
Metadata
Integrity
Data Quality Mandates

7. AIXM Design Objectives
New Data Requirements
Technical Design Decisions
ISO19100 series
Aerodrome
Mapping
UML
Terminal
Procedures
GML 3.2
Obstacles
The world of aeronautical information is in continuous evolution and in the last few years this is happening with increasing speed. Not only that the scope of the domain has expanded, but also well established concepts face new requirements. This is particularly the case with:
Obstacle information – where States are required by ICAO to make available (by 2008) obstacle databases, following a number of strict criteria for data quality; (terrain is another such requirements, but for the moment it is considered outside the scope of the model; terrain information is not subject to the same update cycles and distribution channels as the rest of the aeronautical information)
Data publication requirements for SID/STAR/IAP procedures have been radically modified by the introduction of area navigation (RNAV) and especially by the GNSS based navigation; just as an example, the concept of Terminal Arrival Altitudes (TAA) has been introduced.
Aerodrome mapping – data publication requirements are the result of a joint activity of RTCA and EUROCAE. The aim of AIXM 5 is to support temporary change notifications for the objects that have an impact on international air navigation; airport maps – cockpit situational displays – need to be supported; therefore, the features identified in the Industry Requirements for Airport Mapping Data will be supported in AIXM 5.
Information in NOTAM
Military
Metadata
Integrity
Data Quality Mandates

8. AIXM Design Objectives
Future Capabilities
New Data Requirements
Modularity
Technical Design Decisions
Extensibility
ISO19100 series
Aerodrome
Mapping
Flexible Exchange
UML
Terminal
Procedures
Flexible Messages
GML 3.2
Obstacles
Finally, a number of a new capabilities for the data exchange specification itself:
First and most important – equal coverage for permanent and temporary data; be able to communicate both ‘permanent’ changes, such as those that occur at AIRAC cycles and temporary situations, typically promulgated through NOTAM; this requires the introduction of an exhaustive temporality concept in the model; it will be the subject of detailed presentations during this Meeting
Second, modularity and extensibility: offer the possibility to easily re-use a part of the exchange specification for a particular domain, which might be interested only by a limited number of features without dealing with the complexity of the whole AIXM; offer the possibility for third parties to expand the model – additional features, additional properties or domain values – for local application; the experience with the AIXM change requests in the last two version (4.0 and 4.5) have shown how necessary this is; almost every application has some concepts of local interest that need a standard way to entry in the model without affecting the global interoperability. Place names in local language are a typical example.
Third – flexibility of messages and exchange scenarios: the current model is limited to two standard messages: Snapshot and Update – which have been proven insufficient for a range of applications. User communities and applications should have the possibility to decide on the types of messages that they want to compose using the AIXM pool of features and also on the scenarios in which these messages are used. The ‘navaid’ application example, which will be presented this afternoon, will demonstrate this aspect.
Permanent & Temporary
Information in NOTAM
Military
Metadata
Integrity
Data Quality Mandates

9. AIXM Design Objectives
Future Capabilities
New Data Requirements
Modularity
Technical Design Decisions
Extensibility
ISO19100 series
Aerodrome
Mapping
Flexible Exchange
UML
Terminal
Procedures
Flexible Messages
GML 3.2
Obstacles
Coming back to the high level design objectives, the next few slides will give a few more details about the ISO modelling framework, use of UML and GML. Also, a few words about the temporal concepts for AIXM 5.
Permanent & Temporary
Information in NOTAM
Military
Metadata
Integrity
Data Quality Mandates

10. Presentation Topics Requirements AIXM Design Components
Design Concepts
UML
ISO standards
Geography Markup Language (GML)
Temporality
Conceptual Model Packages
In this briefing we will cover three topics:
AIXM design principles
Design concepts
A review of the AIXM conceptual areas

11. Unified Modeling Language (UML)

12. Unified Modeling Language (UML)
Stereotype
Feature class (Abstraction of real world phenomenon that can exist on its own)
Relationship
(Navaid hasNavigableLocation 0 or 1 ElevatedPoint)
Object class (Does not exist on its own)
Association Class
(Object containing properties of the relationship)

13. Unified Modeling Language (UML)
Choice class
(Indicates exclusivity property can be one of many values)
(Navaid isInstalledAt either RunwayDirection or TouchDownLiftOff)

14. Unified Modeling Language (UML)
Abstract class (Cannot be instantiated in an instance document)
Inheritance
(Localizer inherits properties of the NavaidEquipment)

15. ISO19100 series framework
Internationally developed standards for expressing geographical data
Features - Airports, Runways, Airspace
Metadata - Data originator, Status, Published Date
Temporality - Start and end dates
Geometry - Point, Line, Polygon
Helps us organize information for the aeronautical domain
Feature data dictionaries, feature catalogs, registries and application schemas
Well-established
Geography Markup Language (GML)
Widely adopted and implemented by vendors and governments
Why are ISO standards so important? Because ISO standards provide a well-thought out foundation for building geographical data exchange specification, that can be applied to AIXM. The ISO standards includes internationally accepted models for temporality, geometry and meta-data that should be included in AIXM. Basically the ISO series has three layers:
General feature model framework for building a conceptual schema that represents in a formal way the universe of discourse
Application schema specification – A conceptual schema that defines how a universe of discourse shall be described as data is called an application schema; this level gives the possibility to re-use the already defined ISO concepts for temporality, geometry, metadata, etc.
Data encoding specification – which is our final objective. This will provide the AIXM 5 XML Schema modules that containing XML representations of the features, properties and messages and can be used to build custom system to system interchange messages
The ISO standards help us organize the AIXM model in an internationally understood framework. By using ISO we can leverage well-established standards like GML. Use of standards improves interoperability and reduces barriers to adoption by vendors and governments.

16. ISO 19100 standards used in AIXM
AIXM Conceptual Model (UML)
AIXM Exchange Model (XML)
Geometry ISO 19107
GML ISO 19136
Temporality ISO 19108
Metadata ISO 19115
Metadata ISO 19139
This diagram tries to illustrate the components of AIXM.
At the top left is the AIXM Conceptual model. The conceptual model is described in UML (Unified Modeling Language) a format used by engineers. The conceptual model describes aeronautical features including their properties, geometry, temporal aspects and metadata. In addition the concept model includes an extensibility component enabling adopters to create application models for their specific business needs.
Documentation
Feature Catalog ISO 19126

17. What is GML? ISO exchange format for geographical features encoding
Based on XML Schema
Open GIS Consortium
Good industry adoption by Geographic Information System (GIS) vendors
Commercial Off the Shelf Software
<gml:Point>
<gml:pos> </gml:pos>
</gml:Point>
GML simplifies GIS (Geographic Information Systems) because industry tools understand it. This contrasts with current AIXM (developed in the years preceding the apparition of GML) where geometries are encoded using a custom XML schema. Custom computer code is required to understand and draw geometries encoded in AIXM 4. By using GML, we can leverage commercial software that can already understand GML.
Including GML reduces barriers to adoption and makes it easier to include AIXM into GIS systems.

18. GML structures the AIXM Exchange Model
Object-Property Model
Objects have properties
Properties are simple values or other objects
Geometry
Points, Lines, Polygons
Temporality
Timeslices describing feature state over a time period
Metadata
Based on ISO 19139

19. Temporality Model Definition Key assertions AIXM Temporality Model
A model that incorporates the concept of time
Key assertions
All features are temporal with start of life and end of life
Example, A new air traffic control sector
All features change over time
Example, A VOR is out of service for a day
AIXM Temporality Model
Relates features to the time extent in which they are valid
Provides various means to describe the time extent
Temporality is the last major concept of AIXM 5. A temporal model is one that incorporate the concept of time. In AIXM we recognize that all aeronautical data is temporal. Aeronautical features have a start of life and end of life. In addition aeronautical features can change over time. The AIXM temporality model is used to describe when features are valid and when feature properties change over time.

20. AIXM TimeSlice Model
TimeSlice created every time one or more feature properties change

21. TimeSlice – Version and Delta
Version – The state of a feature and value of its properties over a time period between two changes.
Delta – Difference between two consecutive versions.
The fundamental concepts of the AIXM temporality model are versions and deltas.
A Version is the state of the feature and its properties over a time period between two changes. A delta is the different between two consecutive version.

22. An Example: Navaid frequency change
Imagine that AML Navaid undergoes an upgrade that changes its frequency from 125 MHz to MHz…
Schedule permanent change to coincide with update cycle
Shutdown AML before the upgrade
Perform the upgrade
Start AML in test mode to evaluate change
This slide illustrates the temporal model for a hypothetical NAVAID called AML. Imagine that the NAVAID is undergoing scheduled maintenance that will result in a new Frequency.
Before the frequency change the AIP publishes a baseline of the AML NAVAID indicating all of its properties. Before maintenance begins the AML NAVAID is taken offline for upgrades. This operational status change results in TemporalDelta1. Once the frequency change is made there is a permanent delta indicating a frequency change. A new Baseline starts at the new AIRAC cycle. Finally after the frequency change the NAVAID is placed in operational status = test. A second temporary delta is created for this operational status change.
In all this scenario generates 4 versions of the NAVAID. A version is created at the start and end of each delta.

23. An Example: Navaid frequency change
Imagine that AML Navaid undergoes an upgrade that changes its frequency from 125 MHz to MHz…
This slide illustrates the temporal model for a hypothetical NAVAID called AML. Imagine that the NAVAID is undergoing scheduled maintenance that will result in a new Frequency.
Before the frequency change the AIP publishes a baseline of the AML NAVAID indicating all of its properties. Before maintenance begins the AML NAVAID is taken offline for upgrades. This operational status change results in TemporalDelta1. Once the frequency change is made there is a permanent delta indicating a frequency change. A new Baseline starts at the new AIRAC cycle. Finally after the frequency change the NAVAID is placed in operational status = test. A second temporary delta is created for this operational status change.
In all this scenario generates 4 versions of the NAVAID. A version is created at the start and end of each delta.

24. Basic Structure of AIXM

25. AIXM Structure and Application
AIXM provides the standard foundation for describing aeronautical information
Features: Runway, En route Route, Airspace
Properties: Valid time, Location
Data Types: code list of airspace types
Metadata: Data originator
AIXM can be used to build compliant application schemas
Enable real-world implementation
Digital NOTAMs
Procedure Design
Automated Charting
Enables maximum flexibility while remaining ISO compliant
Examples this afternoon and tomorrow
So AIXM provides a standard model for aeronautical data covering features (runway), properties (valid time), geometry (location) and metadata (data origination).
AIXM compliant application schemas leverage the AIXM extensibility model to enable real-work implementations such as digital NOTAMs, terminal procedure design and automated charting.
AIXM 5 enables maximum flexibility while remaining ISO compliant.

26. Presentation Topics Requirements AIXM Design Components
Design Concepts
UML
ISO standards
Geography Markup Language (GML)
Temporality
Conceptual Model Packages
In this briefing we will cover three topics:
AIXM design principles
Design concepts
A review of the AIXM conceptual areas

27. AIXM Coverage Aerodrome/Heliport Aerodrome/Heliport Facilities
Airspace
Holding
Navaids and Points
Obstacles
Organizations
Procedures
Routes
Services
Shared Components
Geometry
Notes
Time Management
Aircraft
AIXM 5 is divided into 10 conceptual areas and 4 shared components. These areas and components are listed on this slide. In the rest of this briefing I will highlight aspects of the conceptual areas.

28. Aerodrome and Heliports
Aerodromes
Heliports
Movement Areas
Distances, Services, Lights
The aerodrome and heliport concept area covers aerodromes and heliports. It includes movement areas such as runways, taxiways, aprons and gate stands. The model describes declared distances, ground services, ground facilities and lighting.

29. Aerodrome and Heliports
Data necessary to support aerodrome mapping applications (RTCA DO-272A, EUROCAE ED-99A)
Movement area geometries
Intersections
Markings
With version 5 we expanded AIXM into include the data content requirements for aerodrome mapping databases as described by RTCA/EUROCAE recommendations. As a result we modeled all parts of an aerodrome including movement area geometrics, intersections and markings. With version 5, AIXM includes all the data necessary to generate aerodrome mapping databases used for applications like moving map displays.

30. Aerodrome and Heliport Facilities
Fuel
Oil
Oxygen
Passenger Facility
Ground Services
Repair
Fire fighting
Other…
Aerodrome facilities are used to encode fuel, oil, oxygen and other services available at the airport. Each can be described and assigned hours of operation.

31. Airspace Represents Airspaces used in/by ICAO Regions Areas Zones
Sectors
Airspaces used in/by
Air traffic services
Special regulated airspace
Client defined airspace
Various ‘limited’ airspace
The airspace concept area is a generic model for describing airspaces representing ICAO regions, area, zones, sectors and other airspace partitions.

32. Airspace Altitudes
The airspaces are defined with horizontal boundaries and altitudes for upper limits, lower limits and minimum altitudes.

33. Derived Airspace Airspaces with same horizontal border
The airspace model includes two geometrical constructs:
Airspaces can be related by sharing the same horizontal borders.
Airspaces can be created by combining component airspaces through union ( addition), intersection and subtraction.
Airspaces with same horizontal border
Airspace derived from aggregation of parts

34. Holding En route and terminal holding Planned and Unplanned
Segments by length or time
Integrated with procedure conceptual area
The holding pattern concept area is used to define en route and terminal holding patterns. The patterns may be part of a procedure or missed approach. The segments of the holding pattern can be described in terms of distances or time.

35. Navaids and Points Significant Points Used for Navigation
Navaids Navigation Service based on Equipment
Designated Points Points not associated with equipment
Fixes and waypoints
Navaid and Points is another area where we made major enhancements. The basic model is the same as in AIXM We have significant points used for navigation that are divided into two types: Navaids and Designated Points.
New to AIXM 5, Navaids are defined as a service for navigation provided to pilots. The Navaid service is provided by one or more Navaid Equipment. The Navaid Equipment includes physical systems like VOR, DME, TACAN.
Designated Points are navigable points that are not directly associated with conventional naviaid equipment. Designated points include fixes and waypoints.
DME, VOR, TACAN, Azimuth, and so on

36. Obstacles ICAO Annex 4, 14, 15 & DOC 8126 RTCA /EUROCAE DO-276A/ED-98A
IATA
Lighting
Schedule
Area 1, 2, 3
Point, Line, Polygon
Obstacle (ICAO) = All fixed (whether temporary or permanent) and mobile objects, or parts thereof, that are located on an area intended for the surface movement of aircraft or that extend above a defined surface intended to protect aircraft in flight
In AIXM 5 we redesigned the obstacle model to accommodate the latest ICAO requirements as well as data requirements of RTCA, AICM 4.5 and IATA. The resulting obstacle model allows us to describe point, line and polygon obstacles. Obstacles may be lighted and may be associated with marker beacons. The obstacle and its lighting may be scheduled. For example a mobile crane may be an obstacle during working days only.
Finally the ICAO Annex 15 Amendment 33 concepts of Area 1, 2, 3 obstacles has been added to AIXM 5.

37. Organizations and Units
Organization Authority
“Model organizations and authorities”
ATS organizations (IATA), Aircraft Operators (United), States (Argentina), Groups of States (NATO Members)
Unit
“’Unit’ that provides services”
Approach Control, Military, Tower, ARTCC
Organizations and Units model the authorities and units providing air traffic system services.

38. Terminal Procedures Coverage Describes PANS-OPS, TERPS Arinc 424
Conventional and GPS
Describes
Procedures
Segment Legs
Minima
Circling
Protection Areas
Design Surfaces
The terminal procedure model has been significantly expanded and changed for AIXM 5. Coverage has been expanded to accommodate PANS-OPS and TERPS requirements. The model now covers conventional and GPS procedures.
Components of the terminal procedure model covers procedures, segment legs, minima, circling, protection areas and design assessment surfaces.

39. Routes Describe En route structure Conventional and GPS
EnRouteRoute
RoutePortion
RouteSegment
Standard flight levels Minimum Altitudes Change over points DME usage (RNAV)
Flight Levels Track Length Track Width Track Direction Flight Rules and Use
Routes are used to describe RNAV and conventional routes. Each route is made of many route segments with start and ending points. The route segment describes the applicable flight levels, track width, track direction and flight rules for usage. The route model also includes a RoutePortion concept for describing usage and restrictions for subsections of the route.
Describe En route structure
Conventional and GPS
Minimum clearance altitudes
Usage restrictions

40. Services Unit Service Airspace Route Aerodrome/Heliport Holding
Procedure …
Unit
Service
Unit provides service
Communication
Flight Information
Air Traffic Control
Meteorological
Radar …
Provided On
Services are provided by Units. Services are provided on features like airspace, routes, aerodrome/heliports, routes, holding patterns and procedures. AIXM 5 includes a long list of services that can be encoded some include communication, flight information, air traffic control, meteorological and radar.
Service is