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.

Mission Based on global aeronautical data requirements ICAO standards and practices Industry requirements Modular and extensible Support current and future AIM information system requirements Digital AIPs Automated charting and publications Integrated digital NOTAMs Aerodrome Mapping Databases and applications Situational displays 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

Presentation Topics AIXM Design Principles Design Concepts ISO 19100 standards Geography Markup Language (GML) Temporality Conceptual Areas In this briefing we will cover three topics: AIXM design principles Design concepts A review of the AIXM conceptual areas

Presentation Topics AIXM Design Principles Design Concepts ISO 19100 standards Geography Markup Language (GML) Temporality Conceptual Areas

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 19100 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

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. Metadata Integrity Data Quality Mandates

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 Metadata Integrity Data Quality Mandates

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 19100 modelling framework, use of UML and GML. Also, a few words about the temporal concepts for AIXM 5. Permanent & Temporary Metadata Integrity Data Quality Mandates

Presentation Topics AIXM Design Principles Design Concepts ISO 19100 standards Geography Markup Language (GML) Temporality Conceptual Areas

Technical Design Decisions In the ISO19100 series framework Internationally developed standard 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 Well-established Geography Markup Language (GML) Widely adopted and implemented by vendors and governments Standards reduce barriers to adoption 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 19100 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.

AIXM Structure and Application Based on ISO 19100 AIXM Conceptual Model (UML) ISO 19126 Feature Catalog ISO 19109 Application Schema ISO 19107 Spatial ISO 19108 Temporal ISO 19115 Metadata Aeronautical Features Properties Geometry Extensibility Application Models Temporality Metadata Data Types 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. Conceptual Model Feature Catalog Feature Data Dictionary Application Schema

AIXM Structure and Application Based on ISO 19100 AIXM Conceptual Model (UML) AIXM XML Schema (XML) Aeronautical Features GML 3.1 Profile Properties Geometry Extensibility Application Schemas Application Models Features Temporality Metadata Data Types Data Types On the right is the AIXM XML Schema. The schema derives from the conceptual model and implements XML standards such as the Geography Markup Language (GML). Like the conceptual model, the AIXM XML Schema includes extensibility components allowing adopters to create specific application schemas. Data encoding layer ISO 19136 GML XML Schema

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.

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>46.90278 0.08111</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.

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.

Versions 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.

Temporality Model (continued) Operational changes are modeled as deltas Deltas can be permanent or temporary: Permanent delta: A set of properties that have changed or will change permanently. The permanent delta will result in a new baseline. Baseline: The state of a feature and all of the feature properties as a result of a permanent delta. The Baseline state of a feature also exists when the feature is initially created. The Baseline state lasts until the next permanent delta. Temporary delta: A set of values for one or more feature properties that are effective for a limited time. The result is a temporary change to an underlying feature version. Version: The state of a feature and all the feature properties during the time period between two changes. The AIXM temporality model identifies 4 combinations of versions and deltas as described in this slide. These concepts of temporality apply to Features and properties. Charting database only works with baselines and uses permanent deltas to highlight information on the chart. A NOTAM database uses a baseline database and issues temporary deltas. Changes are also referred to as “deltas”. Temporary changes are normally associated with NOTAMs. Permanent changes are normally associated with Aeronautical Information Publication (AIP), AIP amendment, or a Permanent NOTAM. A Baseline is created when the feature is initially created. Properties correspond to attributes or navigable associations in UML (Unified Modeling Language) This is a conceptual temporal model that can be implemented in many ways

Temporality Conceptual Model Imagine that AML Navaid undergoes an upgrade that changes its frequency from 125 MHz to 132.5 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.

Temporality Conceptual Model Imagine that AML Navaid undergoes an upgrade that changes its frequency from 125 MHz to 132.5 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.

Presentation Topics AIXM Design Principles Design Concepts ISO 19100 standards Geography Markup Language (GML) Temporality Conceptual Areas

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.

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.

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.

Aerodrome and Heliports Usage and Restrictions Who can use the aerodrome When they can use it The model includes an expanded and comprehensive usage and restriction model. The model can be used to describe the rules of who can use the facilities and movement areas on an airport.

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.

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.

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

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

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.

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 4.5. 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

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.

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.

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.

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

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

Status and Schedule With FAA implementation plans Sep 06 - Dec 07 Digital NOTAM trials 2008 2010 AIXM Implementations Dec 07 Dec 06 Jun 07 Dec 09 AIXM 5 AIXM 5 RC 1 AIXM 5 RC 2 Possible AIXM 5 . x 2006 2007 2008 2009 2005 2010 In addition to the AIXM activities, the design team is focused on developing proofs of concept and strategies or delivering digital NOTAMS. This digital NOTAM work has started already and will be ongoing through 2007. We expect AIXM implementations including digital NOTAMs to begin surfacing beginning 2008. 2006 Jun 06 2007 2008 2009 AIXM Design Review AIM Global Congress AIXM User Conference AIXM User Conference AIXM User Conference