Presented to: AIXM Developer’s Seminar By: Navin Vembar Date: January 14, 2010 Federal Aviation Administration Changes in AIXM 5.1 from AIXM 5.0

2 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 The Change from 5.0 to 5.1 There were 46 accepted change proposals All available on AIXM Wiki Most were changes to existing features Some were major conceptual changes, however

3 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 New Features or Types AeronauticalGroundLight –Aerodrome Beacons, etc. HotSpot RulesProcedures CodeMarkingConditionType

4 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Removed Features, classes, types AirspaceAssociation removed TerrainPoint removed

5 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Updates to Features Nose-In Guidance at Aircraft Stands GateStand->AircraftStand Add synchronized lighting attribute to VerticalStructure Update to material attribute of VerticalStructure Addition of certification date info to AirportHeliport Runway Centerline Point designator attribute

6 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Updates to Features, cont’d Move attributes from VerticalStructure to VerticalStructurePart Addition of Navaid purpose Addition of attributes to FAS Data Block Addition of offset attributes to FinalLeg Updates to SurfaceContamination feature to better represent SNOWTAMs Add signalType to RadioFrequencyArea and NavaidOperationalStatus Add Morse Code to MarkerBeacon feature

7 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Updates to Relationships AirportHeliport isManagedBy relationship updated to association class ApproachLightingSystem now inherits from GroundLightSystem Multiplicity of relationship from PostalAddress, etc. to ContactInformation Self-association for OrganizationAuthority Add relationship from Navaid to AirportHeliport Reversed association between Procedure and SafeAltitudeArea

8 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Updates to Relationships, cont’d New association between SafeAltitudeArea and AirportHeliport New association between MissedApproachLeg and ApproachCondition

9 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Updates to Types Added new value in CodeProcedureDistanceType Added new value in CodeAltitudeAdjustmentType Remove Y, Z from CodeRouteDesignatorSuffixType Separating RunwayElement and TaxiwayElement types ILS Category changes to types Add RNAV types to CodeDesignatedPointType Use of ISO Language codes instead of custom CodeFuelType is changed to codelist Additional uom values NOTAM updates to CodePurposeType, CodeFlightStatusType and CodeOriginType Direction Finder added as a Navaid Type ALLOWED as FlightRestriction type

10 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Changes to XSD

11 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Changes in AIXM 5.1 XSD schemas The > types no longer exist => replaced by > with the OTHER value Mapping of >

12 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 AIXM 5.1 Mapping Rules - Datatypes Mapping >

13 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 AIXM 5.1 Mapping Rules - Datatypes Mapping > NO PATTERN --

14 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 AIXM 5.1 Mapping Rules - Datatypes Mapping > - default case

15 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 AIXM 5.1 Mapping Rules - NilReason Most of AIXM 5.1 Data Types define a nilReason, used to indicate the reason for a null value.

16 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 AIXM 5.1 Mapping Rules - NilReason Mapping nilReason ……………………..

17 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 AIXM 5.1 Mapping Rules - UOM Mapping Units of Measurement

18 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Conceptual Changes Replacement of all textual attributes with Notes –To facilitate a truly digital, non-textual definitions In enumerations, allow for OTHER: –Allows for arbitrary enumeration values to be added by the user Greater harmonization of AIXM and AMDB standards –Focus on SurfaceCharacteristics Aircraft Characteristics Updates –Updates across features and types to better represent the capabilities of an aircraft

19 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Conceptual Changes, cont’d Schedule –Simplification of representation of schedule across features (major change) Harmonzation of Usage Features –Tied to the above Timesheet –Significant updates to Timesheet

20 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Base AIXM Feature/Object Constructs AbstractAIXMObject: Base type for AIXM complex types that are NOT features. For example, City, ContactInformation, AirspaceVolume, etc. It derives from AbstractGMLType so that AIXM objects are recognised as GML objects, thus ensuring that GML-aware applications recognise them properly. Retains only the mandatory gml:id attribute.

21 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Base AIXM Feature/Object Constructs [Posted on the AIXM forum] The gml:id attribute is now mandatory for AIXM "objects" also, such as ContactInformation, VerticalStructurePart, etc. This is a side effect of deriving all AIXM Objects from AbstractGML, which was considered necessary in order to avoid the risk that GML-aware applications do not see certain geometrical information, if hidden inside a non-GML object such as VerticalStructurePart.

22 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Base AIXM Feature/Object Constructs AbstractAIXMPropertyType: It provides a basis for deriving AIXM feature/object properties. It defines the nilReason attribute and currently, it is only used for properties that are derived from association with an AIM object. The nilReason is now defined : –In Datatypes.xsd for simple properties –In AIXM_AbstractGML_ObjectTypes.xsd for complex properties

23 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010

24 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Usage & Properties with Schedule In AIXM 5.0, the concept of “usage” was not consistent –Should be how a feature can be used, not its status –Mixed status, flight restrictions and complex schedules without consistency across features Simplify with PropertiesWithSchedule –Replace Timesheet with PropertiesWithSchedule –Represents status at different times No longer a separate feature

25 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Example of PropertiesWithSchedule

26 Federal Aviation Administration AIXM 5.1 Changes – AIXM Developer’s Seminar January 2010 Future Plans The next major update to AIXM (either 5.2 or 6.0) will come in 2012 Minor updates in between, but they should not include any conceptual changes –Minimal impact to backward compatibility Developing a CM Plan –Including formalization through ICAO, Eurocontrol and the FAA