AIXM 5 Design Concepts

1
AIXM 5 Design Concepts
2
AIXM 5 Design Methodology

• Build upon lessons learned from AIXM 4.x
• If possible incorporate industry and
  international standards
• ICAO
• ISO
• RTCA/EUROCAE
• ARINC

3
Topics

• Feature Identification and Relationships
• Geometry
• Temporality
• Data and Message Extensibility
• Metadata

4
Topics

• Feature Identification and Relationships
• Geometry
• Temporality
• Data and Message Extensibility
• Metadata

5
Definitions

• Feature identification
• How do we uniquely identify an important
  aeronautical entity
• KJFK Aerodrome
• Taxiway N
• Feature relationships
• How do we associate one feature with another
• Runway 25 is at Airport MXAB
• AML Navaid is the starting Point on a Procedure
  Segment Leg

6
Feature Identification and RelationshipsA safety
critical issue

• Safety critical applications
• NOTAMs indicating a change in operating
  environment
• Avionics updates FMS, Electronic Flight Bag,
  Situational Awareness
• Must ensure positive feature identification

7
Feature Identification and RelationshipsReview
of AIXM 4.x

• Natural keys
• Groups of feature properties and relationships
  used to identify features

From AIXM 4.x
8
Feature Identification and RelationshipsIssues
with Natural Keys

• Unnamed aeronautical features
• Runway markings, Procedure Legs, Gatestands
• Natural keys based on geography
• NAVAIDs identified by location
• Different projections, precision
• Overloaded purpose
• Natural keys are also feature properties
• Changes to natural key properties is awkward
• For example, Navaid AML is now called MAL

9
Feature Identification and RelationshipsAlternati
ves

• Artificial identifiers
• Keys provided by the data supplier
• Feature identification
• User may need to use business rules to reconcile
  data with their system
• Or store data supplier keys in their database.

Aerodrome x3234
My Aerodromes
My System
Data Supplier
10
Feature Identification and RelationshipsRecommend
ation Approach

• Flexible use of artificial or natural
  identification
• Support global registry if it becomes a reality
• Eliminate problem of property overloading
• Allow data supplier to provide natural key
  encoding rules

11
Feature Identification and RelationshipsDesign
Approach

• Combination approach
• Support natural and artificial identifiers
• Queries to indicate relationships

Global Identifier Property
Flexible query for relationships
12
Feature Identification and RelationshipsExample
Alternative 1
RunwayDirection uses Runway where identifier
3939 RunwayDirection uses Runway where
designator 20L/02R and on AerodromeHeliport
where codeID MABC RunwayDirection uses
Runway where identifier 3939 or uses Runway
where designator 20L/02R and on
AerodromeHeliport where codeID MABC
Alternative 2
Alternative 3
13
Topics

• Feature Identification and Relationships
• Geometry
• Temporality
• Data and Message Extensibility
• Metadata

14
GeometryIn AIXM 4.x

• Based on aeronautical domain
• Custom construction
• 2 ½ D
• Horizontal boundary
• Properties for upperand lower limits.

15
GeometryRecommendations

• Standardize geometries using ISO19107 Spatial
  Schema
• GM_POLYGON
• GM_LINE
• GM_POINT
• Consistent with GML (ISO19136)
• Augment with aeronautical properties where needed

16
Topics

• Feature Identification and Relationships
• Geometry
• Temporality
• Data and Message Extensibility
• Metadata

17
TemporalityRequirements

• Aeronautical Features have
• Start of Life and End of Life
• Feature properties can change with time
• Classify changes
• Temporary like NOTAMs
• Permanent like AIRAC Cycle

NDB
NDB
Version 1
Version 2
Version 3
Version 4
NDB Property A Property B
NDB Property A Property B
NDB Property A Property B
NDB Property A Property B
Commissioned
Decommissioned
18
Temporality Model

• Definition
• A model that incorporates the concept of time
• AIXM Temporality Model
• Relates features to the time extent in which they
  are valid
• Provides various means to describe the time
  extent

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

This is a conceptual temporal model that can be
implemented in many ways
20
TimeSlice Model

• Extended TimeSlice data content model from GML
• Valid time period
• Interpretation
• Baseline
• Version
• Temporary Delta
• Permanent Delta
• Sequence Number - tracks TimeSlices for a given
  feature from a particular feature provider
• Correction Number tracks corrections to a
  previously transmitted TimeSlice

21
TemporalityConceptual Model
22
Synchronization and the Temporality Model
B Baseline P Permanent Change T Temporary
Change V Version
T4
T1 P1 T2 T3
B1 B2 V1
V2 V3 V4
V5 V6 V7 V8
V9 V10
V1 B1 V2 B1 T1 V3 B1 B2
B1 P1 V4 B2 Bn Bn-1
?P? V5 B2 T2 V6 B2
V7 B2 T3 V8 B2 T3 T4 V9 B2
T4 V10 B2

Vm Vm-1 ?T?i ?P?j


23
Procedural considerations

• Systems determine what AIXM temporal capabilities
  to use
• Use baselines only
• Use temporary changes only
• Provide periodic versions
• Disregard difference between temporary and
  permanent changes
• Provide full AIXM temporality model capability

24
Procedural Aspects of Permanent Changes

• Permanent changes can result in a new version or
  a new baseline
• Whether a permanent change creates a new baseline
  or not is a procedural decision.
• A permanent change could be promulgated
  electronically
• Everyone would have important information as soon
  as possible
• This could be followed up by a published baseline
  

25
Topics

• Feature Identification and Relationships
• Geometry
• Temporality
• Data and Message Extensibility
• Metadata

26
Data Model ExtensibilityRequirements

• Feature properties
• Add a new power for a VOR navaid
• Feature relationships
• Add a new hasEmergencyAerodrome relationship to
  Airspace
• New features
• Create a new Aerial Refueling Track feature

27
Data Model ExtensibilityAdvantages

• Increased adoption of AIXM by allowing AIXM to
  support more applications
• Charting with style properties
• Design tools with design criteria properties
• Decreased pressure on AIXM configuration control
  board (CCB)
• Easy to add custom properties
• Use CCB to globalize useful extensions

28
Message ExtensibilityIssues

• AIXM 4.x
• ltAIXM-Snapshotgt and ltAIXM-Updategt insufficient
  for global exchange
• Based on EAD requirements for database updates
• Other messages
• WFS (Web Feature Service)
• xNOTAM
• US NOTAMs
• Procedure Design packets
• Automated charting data packets
• Airport Mapping

29
Topics

• Feature Identification and Relationships
• Geometry
• Temporality
• Data and Message Extensibility
• Metadata

30
Purpose

• Purpose of the AIXM metadata analysis was to
  recommend a metadata model and content for AIXM
  5.0
• AIXM 5.0 metadata profile identifies a minimum
  practical set of desirable elements required to
  describe information exchanged via AIXM

31
Linkage to ISO19115 2003 Geographic
Information-Metadata

• The structure of the AIXM metadata profile is
  based on ISO19115
• Not intended to be a substitution for ISO 19115
• Nor does it completely conform to ISO19115

32
Using AIXM Metadata Profile

• Within an AIXM message, data producers should
  include metadata about the message
• Within the feature section of the AIXM message,
  data producers should include metadata for each
  feature timeslice
• The decision to include metadata within the AIXM
  message is optional
• if the data producer elects to send metadata, it
  must conform to the AIXM metadata profile

33
The AIXM Metadata Profile

• The profile includes six models
• Metadata for the AIXM message
• Metadata for an AIXM feature
• Metadata for an AIXM feature timeslice
• Constraint information
• Citation and Responsible Party information
• Data Quality information

34
Study Approach

• Our approach to defining a metadata profile
  included
• Conducting an extensive review of the proposed
  features in AIXM 5.0 and of the available
  literature on metadata
• Holding meetings and interviews with metadata
  subject matter experts
• Developing UML (universal modelling language)
  class diagrams of proposed models of the metadata
  profile

35
Mandatory Metadata Elementsexample

• Example of the structure of an AIXM message
  including only the mandatory metadata elements
  proposed in this AIXM metadata profile
• (Beginning of AIXM message)
• ltMessageMetadatagt
• ltdateStampgt2006-05-15T170000Zlt/dateStampgt
• ltcontactgt
• ltindividualNamegtChristian
  Grothelt/individualNamegt
• ltpositionNamegtResearch Assistant at FSR/TUD,
  responsible for compiling sets of aeronautical
  data to AIXM messageslt/positionNamegt
• ltrolegtdistributorlt/rolegt
• lt/contactgt
• ltmessageIdentificationInfogt
• ltabstractgtThis AIXM message only contains an
  obstacle timeslice of type baseline, valid from
  01 Jan 1985lt/abstractgt
• ltlanguagegtenlt/languagegt
• lt/messageIdentificationInfogt
• lt/MessageMetadatagt

36
Mandatory Metadata Elementsexample continued

• AIXM message example selected is the encoding of
  an obstacle with point-type geometry
• lt?xml version"1.0" encoding"UTF-8"?gt
• ltFeatureMetadatagt
• (no mandatory elements in this portion of the
  profile)
• lt/FeatureMetadatagt
• ltObstacle xmlns"http//www.aixm.aero"
  xmlnsgml"http//www.opengis.net/gml"
• xmlnsxlink"http//www.w3.org/1999/xlink"
  xmlnsxsi"http//www.w3.org/2001/XMLSchema-instan
  ce"
• XsischemaLocation"http//www.aixm.aero
  AIXM-GML-ObjectTypes.xsd" gmlid"ID000000"gt
• ltidentifier codeSpace"http//www.aixm.aero/Amswel
  l"gtEA001lt/identifiergt
• ltgmlvalidTimegt
• ltgmlTimePeriodgt
• ltgmlbeginPositiongt1985-01-01T000000lt/gmlbeginP
  ositiongt
• ltgmlendPosition indeterminatePosition"unknown"/gt
  
• lt/gmlTimePeriodgt
• lt/gmlvalidTimegt

37
Mandatory Metadata Elementsexample continued

• lttimeSlicegt
• ltFeatureTimeSliceMetadatagt
• ltdateStampgt2006-05-12T120000Zlt/dateStampgt
• ltcontactgt
• ltorganizationNamegtInstitute of Flight Systems and
  Automatic Control
• (FSR)lt/organizationNamegt
• ltpositionNamegtInstitute at Technische Universität
  Darmstadt (TUD)surveying and supplying
  aeronautical datalt/positionNamegt
• ltrolegtoriginatorlt/rolegt
• lt/contactgt
• ltfeatureIdentificationInfogt
• ltabstractgt Baseline timeslice for obstacle with
  point-type geometry the Donlon
  antennalt/abstractgt
• ltcitationgt
• lttitlegtxNOTAM studylt/titlegt
• ltdategt2006-05-10T170000Zlt/dategt
• ltdateTypegtrevisionlt/dateTypegt
• lt/citationgt
• lt/featureIdentificationInfogt
• lt/FeatureTimeSliceMetadatagt

38
Mandatory Metadata Elementsexample continued

• ltObstacleTimeSlice gmlid"ID000002"gt
• ltgmlvalidTimegt
• ltgmlTimePeriodgt
• ltgmlbeginPositiongt1985-01-01T000000lt/gmlbeginP
  ositiongt
• ltgmlendPosition indeterminatePosition"unknown"/gt
  
• lt/gmlTimePeriodgt
• lt/gmlvalidTimegt
• ltinterpretationgtBASELINElt/interpretationgt
• .
• .
• .
• lt/ObstacleTimeSlicegt
• lt/timeSlicegt
• lt/Obstaclegt
• (end AIXM message)

39
Metadata wrap-up

• Metadata Profile white paper available at
  www.aixm.aero
• Validating the model using tools such as
  MetaModel Integration Bridge
• kim.w-ctr.barnette_at_faa.gov

40
Summary of AIXM 5 Design Recommendations

• Feature Identification and Relationships
• Include artificial identifier
• Use ltltquerygtgt stereotype
• Geometry
• 2 ½ D with aeronautical properties
• Temporality
• Versions and Deltas
• Implement with GMLs TimeSlice
• Data and Message Extensibility
• Metadata

41
Thank you
42

• Additional metadata slides

43
Metadata to include about the AIXM message
44
Two new metadata elements

• cyclicRedundancyCheckMessage is the value or
  string of alphanumeric characters usually
  generated by a cyclic redundancy check (CRC)
  algorithm.
• Best practice recommends that the algorithm
  consider all tags and data content within the
  AIXM message. When the data receiver applies a
  CRC algorithm to the message, a different CRC
  indicates that a tag or data content within the
  message has been changed since the sender
  generated the original CRC.
• noteCRCMessage is included to provide the ability
  to relay information to the data receiver if
  necessary about the CRC calculation.
• Using this data element, the sender can document
  the tags and data content considered in the
  cyclic redundancy check.

45
Constraint Information Metadata
46
Two new constraint roles

• messageConstraintInfo describes any restrictions
  on the access and use of the AIXM message
• If any of the features within the message have
  attributes with classification codes such as
  restricted, confidential, top secret, etc., the
  classification code for the feature captures the
  highest classification code among the attributes
• messageConstraintInfo captures the highest
  classification code among the features
• metadataConstraintInfo describes any restrictions
  on the access and use of the metadata for the
  AIXM message
• Classification code for this role is determined
  by the sender or data producer
• Both messageConstraintInfo and metadataConstraintI
  nfo are similar to the role metadataConstraints
  relating MD_Metadata to MD_Constraints in
  ISO19115

47
Metadata to include about an AIXM feature
48
Three new metadata elements

• dataIntegrity as a degree of assurance that an
  aeronautical data element and its value has not
  been lost or altered since the data origination
  or authorized amendment
• the dataIntegrity value for an error rate of 5
  errors in 10000 is equal to 1 (5/10000)
  0.9995
• cyclicRedundancyCheckFeature is the value or
  string of alphanumeric characters usually
  generated by a cyclic redundancy check (CRC)
  algorithm.
• Best practice recommends that the algorithm
  consider all tags and data elements within the
  feature data.
• When the data receiver applies the CRC algorithm
  to the feature data, a different CRC indicates
  that a tag or data element within the feature
  data has been changed since the sender generated
  the original CRC
• noteCRCFeature provides the ability to relay
  information to the data receiver if necessary
  about the CRC calculation.
• Using this data element, the sender can document
  the tags and data elements considered in the
  cyclic redundancy check

49
Metadata to include about an AIXM feature
timeslice
50
Three new metadata elements

• measureClass gives information about how any
  measurements within the feature timeslice data
  were captured
• contains the string from class-codelist
  MeasureClassCode
• measEquipClass is where the sender can describe
  the equipment used to capture any measurements
  within the feature timeslice
• dataStatus under IdentificationFeature gives the
  status of the source of the feature timeslice
  data
• This element is similar to ISO19115 status which
  maps to the codelist MD_ProgressCode referenced
  in Annex B.5.23 of ISO19115.
• We include this data element due to AirMAT-AICM
  metadata harmonization

51
Citation and Responsible Party Information
Metadata
52
Similar to ISO19115

• Class ResponsibleParty is essentially the same as
  the CI_ResponsibleParty class from ISO19115
  except we add a new data element systemName as a
  place to describe the responsible system, i.e.,
  database or repository that transmitted or
  compiled AIXM information.
• ISO19115 class maps data element contactInfo to
  the class CI_Contact, whereas the AIXM version of
  the responsible party class maps data element
  contactInfo to the class Contact.
• Contact class contains less information than the
  ISO19115 CI_Contact class
• Data element address is the same as in ISO19115
  which maps to the CI_Address class
• Data element phone maps to the class Telephone,
  whereas the ISO19115 phone points to CI_Telephone
  
• UML class diagram reflects the restricted
  associations between Contact and CI_Contact, and
  Telephone and CI_Telephone.

53
Data Quality Information Metadata