sn.12 - attachment - guidance material for the aeronautical information conceptual model

7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model

1/17

5

AIS-AIMSG/2-SN No. 12

ANNEX

It is proposed that the following guidance material is included in the ICAO AIS Manual in order to

support States with an aeronautical conceptual and data exchange model.

- DRAFT -

1. INTRODUCTION

1.1 The Aeronautical Information Exchange Model (AIXM) provides a formal definition of

the aeronautical information published by the States, in the form of a conceptual model. It applies the

Unified Modelling Language (UML) conventions, which is the most common modelling language in use.

Language. This is meant to support the States in the automation of their AIS processes. The content of

Aeronautical Information Publication, including Amendments and Supplements, Circulars and NOTAM

can be extracted from a database structured according to this conceptual model.

1.2 AIXM also includes a data exchange format, which is based on the Extensible Markup

Language and, more precisely, on the Geography Markup Language (GML). GML is an ISO Standard

(ISO 19136) for the encoding of geographical information. This data exchange format enables the States

to exchange their aeronautical information in digital format.

1.2.1 AIXM 5.1 has been designed to meet the latest requirements for aeronautical information

exchange:

a) alignment with the ISO 19100 series of standards for geospatial information,

including the use of the Geography Mark-up Language (GML);

b) use of the Unified Modelling Language (UML), the widest used modelling standard,

for the definition of the conceptual model;

c) inclusion of a temporality model at feature level, which enables the model to describe

the history, the current status and the future changes, for each feature;

d) support for the latest ICAO and industry requirements for aeronautical data,

including obstacle databases, terminal procedures and airport mapping;

e) modularity and extensibility.

1.2.2 One of the most important aspects of AIXM 5.1 is that the temporality mechanism at feature level

can provide "digital NOTAM" capabilites. Basically, a digital NOTAM eliminates the free form text

contained within a NOTAM and replaces the text with a series of structured facts about the affected the

aeronautical feature concerned. The xNOTAM concept and its benefits are further explained in a separate

information paper.


2/17

6


2. SCOPE

2.1 The AIXM scope is based on the ICAO Annex 15 requirements for provision by the

Member States of the data necessary for the safety, regularity and efficiency of international air

navigation. However, the model goes beyond the strict ICAO Annex 15 requirements, by also taking

into consideration existing industry standards and emerging data needs. The complete model is providedas guidance material in order to facilitate the implementation of local solutions that might need to exceed

the ICAO SARPS.

2.1.1 The AIXM 5.1 specification includes the following:

a) a core Conceptual Model (UML), which describes the aeronautical information

features and their properties, associations, values and validation rules;

b) a Temporality Concept, which enables capturing the evolution of the properties of

an aeronautical information feature over time, from the start of its life until its

permanent withdrawal. In particular, this model enables the provision of digital

NOTAM;

c) a data Encoding Specification (XML/GML Schema), which implements all the

classes defined in the conceptual UML model;

d) an extension mechanism, by which groups of users can extend the properties of

existing features and add new features, which are for local interest in that group and

that are not relevant for global standardization;

e) additional documentation that explains the model and its intended usage.

2.1.2 A high-level introduction of these elements is provided in this section. The core AIXM

components (UML Model, Data Dictionary, XML Schema, Sample data, etc.) are provided on a CD-

ROM attached to the Manual. Their provision in printed format is not necessary, as most of the material is

intended for software developers who are better served by the electronic version.

2.1.3 Additional AIXM documentation is freely and openly available on the www.aixm.aero Web site

and through the on-line AIXM discussion Forum, which is accessible from the same Web site. In

particular, this includes an AIXM Wiki, which further explains and guides the users of the model.

3. CONCEPTUAL MODEL

3.1 The AIXM Conceptual Model provides a formal description of the aeronautical

information items, using UML class diagrams, a standard data modelling language. It uses classes,

attributes and associations in order to describe aeronautical features such as airports, runways, navaids,

obstacles, routes, terminal procedures, airspace structures, services and related aeronautical data. It also

details the business rules that help define aeronautical information. As such, it can be used as the basis for

the design of an AIS database.

3.2 The content of AIXM Conceptual Model is available in the form of a Data Dictionary,

built according to the ISO 19110 Standard. It also includes the most representative UML class diagrams

for each area of the model. An extract from the Data Dictionary is included in section 9.

3.3 An exhaustive explanation of the UML language is available from the creators of the

UML Specification, the Object Management Group (OMG): http://www.uml.org/. UML tutorials and
http://www.aixm.aero/http://www.uml.org/http://www.uml.org/http://www.aixm.aero/http://www.uml.org/


3/17

7


related resources are widely available in both printed and on-line format. In order to facilitate the

understanding of the AIXM Conceptual Model, a minimal description of the UML notation is provided in

this document.

3.4 Diagram types

3.4.1 Two types of diagrams are used in the model:

a) Class diagrams Used to represent the features, properties, relationships and

inheritance between features;

b) Package diagrams Used to split the model into modules and identify dependencies

among sets of classes.

4. Stereotypes

4.1.1 The classes are distinguished by their stereotypes. Stereotypes are used to further define and

extend standard UML concepts. The main stereotype are , , ,

, and .

4.1.2 Features

4.1.3 Features describe real world entities and are fundamental in AIXM. AIXM features can be

concrete and tangible, or abstract and conceptual and can change in time. Features are represented as

classes with a stereotype . Examples include Runway and AirportHeliport.

4.1.4 AIXM features are dynamic features. Timeslice objects are used to describe the changes that

affect the AIXM feature over time. Timeslice objects and temporality are discussed extensively in a

separate AIXM Temporality document.


4/17

8


5. Objects

5.1.1 Objects are abstractions of real world entities or, more frequently, of properties of these entities,

which do not exist outside of a feature. An object is created for two reasons in AIXM:

When a property or set of logically grouped properties has a multiplicity greater than one (such as the

city served by an AirportHeliport), or

The object has its own attributes that are reused throughout the model, such as ElevatedPoint.

5.1.2 In both cases, the property is represented as an object with the proper UML compositionrelationship as shown below.

5.1.3 Properties

5.1.4 Properties are the attributes and relationships that characterise a feature or object. In the UML:

Attributes are used to describe simple properties of a feature or object;

Relationships are used to describe associations to features or objects. Whenever a

property has a multiplicity greater than one, it is described using a UML relationship withcardinality.

6. Attributes

6.1.1 Simple properties of cardinality one are shown as attributes in the UML diagram.

6.1.2 An attribute has the following format:6.1.3 Visibility / stereotype name : type multiplicity

6.1.4 For AIXM 5 the following values are used:

Visibility Public

/ - not used

Stereotype not used


5/17


6/17


7/17

11


7. TEMPORALITY CONCEPT

7.1 Time is an essential aspect on the aeronautical information world, where change

notifications are usually made well in advance of their effective dates. Aeronautical information systems

are requested to store and to provide both the current situation and the future changes. The expired

information needs to be archived for legal investigation purposes.

7.2 For operational reasons, a distinction is usually made between:

permanent changes (the effect of which will last until the next permanent change or

until the end of the lifetime of the feature) and

temporary status (changes of a limited duration that are considered to be overlaid

on the permanent state of the feature).

7.3 A temporary change includes the concepts of overlay and reversion. The temporarychange is overlaid on the permanent feature state. When the temporary change ends, the temporary

changes no longer apply and we revert back to the permanent feature state.

7.4

7.5 Note that, from an operational point of view, temporary status also includes the concept

of temporary features. However, from the AIXM point of view, temporary features are in no way

different from normal features. The feature is created and withdrawn, just that the life span is shorter thanusual.

7.6 In order to satisfy the temporal requirements of aeronautical information systems, AIXM

must include an exhaustive temporality model, which enables a precise representation of the states and

events of aeronautical features. In particular, this shall enable the development and the implementation of

digital NOTAM. By digital NOTAM we mean replacing the free text contained in a NOTAM message

with structured facts, which enable the automated processing of the information.

7.7 In order to describe the feature properties during states and events, the t ime varying

properties of every feature are encapsulated in a container called Time Slice. The history of the feature

is described with state Time Slices, each containing the values of the time varying properties between

two consecutive changes (events). Each Time Slice has maximum one value for each property and one

specified validity period.

7.8 The following Time Slice types are used in the AIXM:

BASELINE = a kind of Time Slice that describes the feature state (the set of all features

properties) as result of a permanent change. For example, the information contained in AIP

Amendments is typically represented as baseline information;

PERMDELTA = A kind of Time Slice that describes the difference in a feature state as

result of a permanent change. A PERMDELTA contains only those properties that have

changed value.

TEMPDELTA = a kind of Time Slice that describes the overlay of a feature state during a

temporary event. The typical example of information encoded as TEMPDELTA is a

NOTAM (navaid unserviceable, closed route, etc.)


8/17

12


SNAPSHOT = A kind of Time Slice that describes the state of a feature at a time instant, as

result of combining the actual BASELINE Time Slice (valid at that time instant) with all

eventual TEMPDELTA Time Slices that are effective at that time instant. For examples,

applications that display the actual status of an airport will show the data in a snapshot.

7.9 The UML model contains a set of abstract AIXM classes that are used as templates forthe features and objects defined in AIXM. When applying the Time Slice concept, as described in the

previous paragraphs, this triggers the split of every UML class that represents a feature into a main classand a FeatureTimeSlice class, as shown in the following diagram.

7.10 The UML diagram shows how each and every inherits from the abstract

AIXMFeature class. The concrete features are described by TimeSlices which are composed of

properties. The TimeSlice inherits from the abstract AIXMFeatureTimeSlice class.

7.11 The diagram also shows that each AIXM Feature is described by FeatureMetadata and

each TimeSlice is described by FeatureTimeSliceMetadata. Finally, each TimeSlice may contain anExtension. The Extension mechanism allows each user of AIXM 5 to define and use his own specific

attributes and classes, in addition to the core AIXM ones.


9/17

13


7.12 The diagram above is quite complex. If applied to the whole set of AIXM classes, it

might undermine the readability of the UML diagrams. Therefore, a simplified UML model is provided,

without visible inheritance of all features from the abstract AIXMFeature and without visible

SomeFeatureTimeSlice classes. However, the split and into SomeFeatureTimeSlice classes is assumed to

exist, when converting from the UML model to the XML Schema of AIXM.

7.13 Example

7.13.1 The figure below illustrates the temporal model by showing a transmission frequency change for

a navigation aid (VOR AML, from 112.0 MHz to 113.2 MHz). Normally, this change should occur at an

AIRAC cycle date. Usually, the change requires the navaid to be out of service for a certain time, then to

be on test on the new frequency. The temporary status is communicated at present through NOTAM

messages.

7.14 Based on this diagram we can identify the following temporal components:

The diagram shows two BASELINE Time Slices. The first baseline has a NAVAID

frequency of 112.0 MHz and is valid since some time in the past; the second baseline has the

new frequency of 113.2 MHz and is valid starting from the AIRAC cycle date.

A PERMDELTA can be used to describe the permanent state change, which is the AML

VOR frequency change. For completeness sake, the previous PERMDELTA that has

preceded the first BASELINE (1) is also shown.

Each transitory event can be expressed as a TEMPDELTA that changes the Operational

Status of the navaid and eventually the frequency.

Based on the PERMDELTA and the TEMPDELTA delta Time Slices shown in the diagram,

four different versions for the current status of the feature may exist. Each current status

version begins and ends at the boundary of a Permanent or Temporary Delta and may be

presented as a Time Slice of type SNAPSHOT.


10/17

14


8. XML SCHEMA

8.1 The AIXM exchange model is an XML exchange standard based on a subset of the

Geography Markup Language (GML). Essentially:

AIXM Features are GML features;

AIXM Objects are GML objects;

AIXM follows the GML object-property concept.

8.2 The GML object-property model explains some of the complexity of the AIXM UML to

XSD mapping. It means that no GML object may appear as the immediate child of a GML object.

Consequently, no element may be both a GML object and a GML property.

8.3 The object-property model prohibits the encoding of an object directly inside a feature.Instead, in a compliant GML application schema, an association between two features (or a feature and an

object) is implemented over a property of the feature, e.g.

8.4 The direction of the association arrow from the UML diagrams (the navigability) dictates

which of the two association partners has the property that associates the other. In the AIXM XML

Schema, the object-property model is encoded by declaring a type and then assigning properties

(attributes and relationships) to that type. The type defines the object.


11/17

15


8.5 The full AIXM Schema is provided on the CD-ROM that accompanies the

documentation and it is also available for on-line validation on the www.aixm.aero/schema/5.1 Web site.

An example of an AIXM-encoded feature is provided below, showing the encoding of some data for an

Airport: designator, name, magnetic variations, validity tine, global unique identifier.

dd062d88-3e64-4a5d-bebd-89476db9ebea

2009-01-01T00:00:00.000

BASELINE

10

2009-01-01T00:00:00.000

EADH

DONLON/DOWNTOWN HELIPORT-3

19900.03

OPERATE

-32.03552.288888888888884

18.0
http://www.aixm.aero/schema/5.1http://www.aixm.aero/schema/5.1


12/17

16AIS-AIMSG/2-SN No. 12

9. DATA DICTIONARY SAMPLE

9.1 This section contains an extract from the AIXM Data Dictionary, which is available in on the CD-ROM attached to the AIS Manual.

AirportHeliport

Name/RoleName Definition MaximumOccurance

DataType Related Class

1 AirportHeliport A defined area on land or water (including any buildings,installations and equipment) intended to be used either

wholly or in part for the arrival, departure and surface

movement of aircraft/helicopters.

N Class

2 designator A coded designator for an Aerodrome/Heliport. The rules

according to which this identifier should be formed are as

follows: 1. If the AD/HP has an ICAO four letter location

indicator, then this one will become the CODE_ID for the

Aerodrome/Heliport; 2. If the AD/HP does not have anICAO four letter location indicator, but it has an IATA three

letter code, then this one will become the CODE_ID for theAerodrome/Heliport; 3. If the AD/HP has neither an ICAO

four letter location indicator nor an IATA three letter code,then an artificial generated code will be used. This will

contain a group of letters and a number. The group of letters

could be the 2 letter code of the State being responsible for

the Aerodrome/Heliport and the number could be an integer

between 0001 and 9999.

1 CodeAirportHeliportDesignatorT

ype

3 name The full free text name of the aerodrome/heliport. 1 TextNameType

4 locationIndicatorICAO The four letter ICAO location indicator of theaerodrome/heliport, as listed in ICAO DOC 7910.

1 CodeICAOType

5 designatorIATA The three letter IATA designator of the aerodrome/heliport. 1 CodeIATAType

6 type A code specifying the type of aerodrome. For example,aerodrome only, combined aerodrome/heliport or simple

landing site.

1 CodeAirportHeliportType

7 certifiedICAO Indicating that the airport is certified according to t he ICAO

rules.

1 CodeYesNoType

8 privateUse An aerodrome or heliport not open for the public. Only for

the use of the owners.

1 CodeYesNoType

9 controlType The primary organization type in terms of civil or military,

which controls the airport.

1 CodeMilitaryOperationsType

10 fieldElevation The value of the aerodrome elevation. The vertical distance

between the highest point of the landing area of an

aerodrome and mean sea level. Note: this might be different

from the elevation of the Aerodrome Reference Point.

1 ValDistanceVerticalType


13/17


11 fieldElevationAccuracy The vertical distance from the stated elevation within which

there is a defined confidence of the true position falling.

1 ValDistanceVerticalType

12 verticalDatum Attribute to take the \"Vertical Datum\" (viz. the tide gauge

to determine MSL - for example, \"AMSTERDAMGAUGE\", \"NEWLYN\" etc.).

1 CodeVerticalDatumType

13 magneticVariation The measured angle between Magnetic North and True

North at a given point and at the time reported in

dateMagneticVariation. By convention, the measure is

expressed as a positive number if Magnetic North is to the

east of True North and negative if Magnetic North is to the

west of True North. Therefore, magnetic bearing + magnetic

variation = true bearing. The following rule of thumbapplies: ""variation east-magnetic least, variation west-

magnetic best"".

1 ValMagneticVariationType

14 magneticVariationAccuracy The accuracy of the Magnetic Variation in angle degrees. 1 ValAngleType

15 dateMagneticVariation The date on which the magnetic variation had this value. 1 DateYearType

16 magneticVariationChange The annual rate of change of the magnetic variation. 1 ValMagneticVariationChangeTyp

e

17 referenceTemperature The value of the reference temperature at an

aerodrome/heliport.

1 ValTemperatureType

18 alt imeterCheckLocation A textual description of the altimeter check locations. 1 CodeYesNoType

19 secondaryPowerSupply A textual description of the secondary power supply

available at the aerodrome/heliport.

1 CodeYesNoType

20 windDirectionIndicator A textual description of the wind direction indicator (WDI)

and its position at the aerodrome/heliport.

1 CodeYesNoType

21 landingDirectionIndicator A textual description of the landing direction indicator (LDI)

and its position at the aerodrome/heliport.

1 CodeYesNoType

22 transitionAltitude The value of the transition altitude. 1 ValDistanceVerticalType

23 transitionLevel The value of the transition flight level. 1 ValFLType

24 lowestTemperature The mean lowest temperature of the coldest month of the

year References: PANSOPS 8168, PART III Section 3

Chapter 4 BARO-VNAV

1 ValTemperatureType

25 abandoned Indicating that the airport is no longer in operational use, but

it's infrastructure is still present and visible from the air.

1 CodeYesNoType

26 certificationDate The date when the airport certification has been issued by thesupervising authority.

1 DateType

27 certificationExpirationDate The date when the airport cert if ication will become invalid . 1 DateType

28 contaminant N Association AirportHeliportConta

mination

29 servedCity The location that is served by the airport. N Association City

30 responsibleOrganisation The Organisat ion that is responsible for managing the

airport. Usually, this indicates that the related

Organisation/Authority is responsible for the management of

1 Association OrganisationAuthorit

y


14/17


the aerodrome/heliport. The concept of 'airport management'

is not applicable to all aerodrome/heliports world-wide. In

that case, the Aerodrome/Heliport will be associated with the

State responsible fot its operations.

31 ARP Airport reference point. 1 Association ElevatedPoint

32 aviationBoundary Boundary of the airport/heliport used for aviation operations. 1 Association ElevatedSurface

33 altimeterSource The altimeter source used by the Airport. N Association AltimeterSource

34 contact The description of the contact address. N Association ContactInformation

35 availability N Association AirportHeliportAvail

ability36 annotation N Association Note

37 AirportHeliportAvailability Information about the operational status of the

airport/heliport.

N Realizes Class

(PropertiesWithSchedule)

38 operationalStatus Indicates the availability of the facility for specific flight

operations.

1 CodeStatusAirportType

39 warning A reason for caution when operating at the facility. 1 CodeAirportWarningType

40 usage N Association AirportHeliportUsage

41 AirportHeliportCollocation Two aerodromes/heliports may be co-located sharing some

or all of their ground facilities. E.g. a civil and a militaryaerodrome using the same runway.

N Class

42 type A code indicating the extent of the collocation situation of

the two aerodrome/heliports.

1 CodeAirportHeliportCollocationT

ype

43 hostAirport The host Airport. 1 Association AirportHeliport

44 dependentAirport The airport that is colocated at the host Airport. 1 Association AirportHeliport

45 annotation N Association Note

46 AirportHeliportProtectionArea An area situated in the vicinity of a runway, FATO or TLOF,

provided to protect aircraft during manoeuvring, take-off

and/or landing operations.

N Class

47 width The value of the physical width of the protection area. 1 ValDistanceType

48 length The value of the physical length of the protection area. 1 ValDistanceType

49 lighting A textual description of the lighting system on the protection

area.

1 CodeYesNoType

50 obstacleFree Indicates if the protection area is obstacle free. 1 CodeYesNoType

51 surfaceProperties The surface characteristics of the

AirportHeliportProtectionArea.

1 Association SurfaceCharacteristic

s

52 extent Extent of the protection area. 1 Association ElevatedSurface

53 annotation N Association Note


15/17


54 AirportHeliportResponsibilityOrg

anisation

N Realizes Class

(PropertiesWithSchedule),

Association Class

(AirportHeliport,OrganisationAuthority)

9.2 Below it is an example of an class diagram from the AIXM Conceptual Model. Such class diagrams are available for all areas of the model(airport, airspace, routes, navaids, etc.) and display in graphical format the main components of the model (features/objects), their attributes and theirassociations.

9.3 In this example, it is visible that an AirportHeliport feature has properties such as name, designator, referenceTemperature, etc. andassociations with classes such as OrganisationAuthority, SurveyControPoint, etc. This information is also present in the Data Dictionary, but the UMLdiagrams such as the one below present it in a more compact form. It is a standard practice in the information technology domain to provide such diagramsas part of a conceptual model documentation.


16/17


Point

horizontalAccuracy : ValDistanceType

(from Geometry)

GM_Point(from ISO 19107 Ge ometry)

AirportHeliportResponsibilityOrganisation

role : CodeAuthorityRoleType

AltimeterSourceStatus

operationalStatus : CodeStatusOperationsType

PropertiesWithSchedule(fromSchedules)

ElevatedPoint

elevation : ValDistanceVerticalType

geoidUndulation : ValDistanceSignedType

verticalDatum : CodeVerticalDatumType

verticalAccuracy : ValDistanceType

(from Geometry)

SurveyControlPoint

designator : TextNameType

1 +location1

hasPosition

City

name : TextNameType

NonMovementArea

ElevatedSurface

elevation : ValDistanceVerticalType

geoidUndulation : ValDistanceSignedType...

verticalDatum : CodeVerticalDatumType...

verticalAccuracy : ValDistanceType

(from Geometry)

0..1

+extent

0..1

hasExtent

AltimeterSource

isRemote : CodeYesNoType

isPrimary : CodeYesNoType

0..*

+availability

0..*

isAvailableOn

AirportHotSpot

designator : TextDesignatorType

instruction : TextInstructionType

0..1

+area

0..1

hasShape

ContactInformation

name : TextNameType

title : TextNameType

(from Add ress)

AirportHeliport

designator : CodeAirportHeliportDesignatorType

name : TextNameType

locationIndicatorICAO : CodeICAOType

designatorIATA : CodeIATAType

type : CodeAirportHeliportType

certifiedICAO : CodeYesNoType

privateUse : CodeYesNoType

controlType : CodeMilitaryOperationsType

fieldElevation : ValDistanceVerticalType

fieldElevationAccuracy : ValDistanceVerticalType

verticalDatum : CodeVerticalDatumType

magneticVariation : ValMagneticVariationTypemagneticVariationAccuracy : ValAngleType

dateMagneticVariation : DateYearType

magneticVariationChange : ValMagneticVariationChangeType

referenceTemperature : ValTemperatureType

altimeterCheckLocation : CodeYesNoType

secondaryPowerSupply : CodeYesNoType

windDirectionIndicator : CodeYesNoType

landingDirectionIndicator : CodeYesNoType

transitionAltitude : ValDistanceVerticalType

transitionLevel : ValFLType

lowestTemperature : ValTemperatureType

abandoned : CodeYesNoType

certificationDate : DateType

certificationExpirationDate : DateType

1

+ARP

1 hasReferencePoint

0..*

1

0..*

+associatedAirportHeliport

1

isSituatedAt

0..*+servedCity

0..*

serves

0..*1 0..*

+associatedAirportHeliport

1

isSituatedAt

0..1+aviationBoundary

0..1

hasBoundaryForAviationPurposes0..*

+altimeterSource

0..*

utilizes

1

0..*

+affectedAirport1

0..*

isLocatedAt

0..*+contact 0..*

isContactedAt

OrganisationAuthority

name : TextNameType

designator : CodeOrganisationDesignatorType

type : CodeOrganisationType

military : CodeMilitaryOperationsType

(from Organisation)

0..*

+contact

0..*

isContactedAt

0..*

1

0..*

+responsibleOrganisation1

isUnderResponsibilityOf


17/17

sn.12 - attachment - guidance material for the aeronautical information conceptual model

Documents