View
227
Download
0
Category
Preview:
Citation preview
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.
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
2/17
6
AIS-AIMSG/2-SN No. 12
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/7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
3/17
7
AIS-AIMSG/2-SN No. 12
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.
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
4/17
8
AIS-AIMSG/2-SN No. 12
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
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
5/17
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
6/17
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
7/17
11
AIS-AIMSG/2-SN No. 12
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.)
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
8/17
12
AIS-AIMSG/2-SN No. 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.
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
9/17
13
AIS-AIMSG/2-SN No. 12
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.
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
10/17
14
AIS-AIMSG/2-SN No. 12
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.
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
11/17
15
AIS-AIMSG/2-SN No. 12
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.17/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
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
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
13/17
17AIS-AIMSG/2-SN No. 12
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
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
14/17
18AIS-AIMSG/2-SN No. 12
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
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
15/17
19AIS-AIMSG/2-SN No. 12
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.
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
16/17
20AIS-AIMSG/2-SN No. 12
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
7/28/2019 SN.12 - Attachment - Guidance Material for the Aeronautical Information Conceptual Model
17/17
Recommended