AIXM and Instrument Flight Procedures Automation The purpose of this presentation is to discuss the Instrument Flight Procedures Automation effort and the AIXM implementation plans.

Instrument Flight Procedures Automation (IFPA) Capability to design all types of flight procedures including en route airways, area navigation (RNAV) airways, standard terminal arrival routes (STARs), precision instrument approaches, and standard instrument departures (SIDs). Capability to store coded instrument flight procedures. Capability to communicate flight procedure information to aircraft flight management system (FMS)/multi-mode radio (MMR) manufacturers. Capability to evaluate impacts on stored instrument procedures. Capability to determine the impact of existing or proposed obstacles on instrument flight procedures. Capability to provide metrics that track AVN work processes. Capability to provide a means for proponents to check status and procedure publication date of requested instrument flight procedures. Capability to access airport, runway, navigational aids (Navaids) and obstacle data needed for the development and inspection of flight procedures. Capability to provide future status and multiple pending statuses for each piece of data. Capability to integrate systems across all AVN organizations to eliminate manual effort and duplication of data. Capability to integrate with external agency and non-agency systems in a secure manner. Capability to coordinate instrument flight procedure requests and communicate implementation requests with appropriate FAA and other entities. Capability to support NOTAM development. Capability to support environmental impact assessments. Capability to meet future instrument flight procedure demands identified in the 1995 NAS Architecture [2]. Aviation System Standards (AVN) of United States Federal Aviation Administration (FAA) develops and provides quality control for all types of instrument flight procedures and charts (instrument flight rules [IFR] and visual flight rules [VFR]) for commercial air carriers, general aviation (GA), and military for domestic and international operations. Instrument flight procedures ensure safe operation of aircraft during approach, departure, and en route flight into instrument capable and non-instrument capable airports or other landing facilities such as heliports and helipads. The IFPA Program supports the Safer Skies Program (CIP M42.00-00) [3] and the Commercial Aviation Safety Team (CAST) Implementation Plan [5] as well as programs such as the Wide Area Augmentation System (WAAS) and Required Navigation Performance (RNP). The FAA has an executive goal to modernize the existing systems and build a next generation Instrument Procedure Development System (IPDS) as a common system that harmonizes the business rules that direct the construction of the procedures for the Federal Aviation Administration, United States Air Force, Army and Navy. The goal of Federal Aviation Administration is to modernize the systems using a Service Oriented Architecture with a phased delivery spanning 6 years.

Data Exchange Integration for IFPA

Military Integration for IFPA

IFPA Products 8260 Forms (Rule making documents) Flight Inspection Documents Aeronautical Charts Data coding for FMS and MMR These products are supported by several COI (Community of Interests); Procedure Development, Flight Inspection, Charting and On-board data providers. To support these communities and help our Application Developers, we created specific application schemas or messages using AIXM features. FMS – Flight Management System MMR – Multi-mode radio

IFPA Messages SOAP provides an XML framework for transporting a web service message between client and server. The SOAP message is embedded within an HTTP request or response. The SOAP Message consists of an Envelope element and optionally, one or more attachments that follow. The Envelope element has Header and Body elements. The SOAP Header serves to guide the routing of SOAP messages. The SOAP Body contains the application payload, i.e., the input (request), output (response) or fault message as declared in the WSDL for the operation.

IFPA Messages Request Messages Response Message WFS (getFeature, getObject, etc.) Filters Response Message WFS:FeatureCollection Custom Application Schema Fault errors WFS (transaction: insert, update, delete) The GetFeature web service request is based on the OpenGeospatial WFS specification [WFS] defines the schema for requesting and responding to GML features. This specification was selected as it provides standardized service interface to GML features, and as AIXM-5 implements a profile of GML. The implementation is based on SOAP. This operation is intended to support general querying/browsing of aeronautical objects in a Data Source. Design decisions: 1. Although the GetFeature service allows objects of more than one feature type to be requested. Clients should consider requesting only one feature type, to prevent queries against multiple databases that would slow down the response time. 2. Spatial filters can be expressed as a location code (country and state) in order to retain IAPA database inquiry capability, as well as expressed as a bounding box. 3. Wildcarding on object properties is included to match IAPA database inquiry capability. The GetFeature and GetObject operations enable data to be filtered on the server before it is sent back to the client. Each operation has its own specific filter parameters, e.g., spatial location, date, etc. Filters are implemented in the request messages using the OpenGIS Filter Encoding Implementation Specification [FILTER]. The core AIXM structure provides the foundation of aeronautical features Communities of Interest can exchange data using either: - use a pre-defined Web Service (such as WFS) which enables the direct provision of individual AIXM features or collections of AIXM features - or define custom AIXM Messages encompassing a selected list of AIXM Features and properties.

IFPA Request <wfs:GetFeature service = “WFS” version = “1.1.0” resultType = “results” outputFormat = “text/xml; subtype=gml/3.1.1” traverseXlinkDepth = “0”> <wfs:Query handle = “123” typeName = aixm:AerodromeHeliport> <ogc:Filter> <ogc:BBOX> <gml:Envelope srsName=“WGS84”> <gml:lowerCorner>13.0983 31.5899</gml:lowerCorner> <gml:upperCorner>35.5472 42.8143</gml:upperCorner> </gml:Envelope> </ogc:BBOX> </ogc:Filter> </wfs:Query> </wfs:GetFeature> The GetFeature and GetObject operations enable data to be filtered on the server before it is sent back to the client. Each operation has its own specific filter parameters, e.g., spatial location, date, etc. Filters are implemented in the request messages using the OpenGIS Filter Encoding Implementation Specification [FILTER].

IFPA Messages Response Message Custom messages extending AIXM

AIXM Data Products Feature/Object Extensions Data Types Extensions Codelist Extensions Application Schemas AIXM provides a standardization of Aeronautical Information. In order to use AIXM for a specific application or product, a community of interest will have to agree upon how instances of AIXM features are to be exchanged/communicated in the community. An Application Schema is designed to provide a custom developed AIXM message for a specific Community of Interest. In the definition of the AIXM Application Schema, the community might also want to extend the core AIXM with additional properties and features.

Basic Principles of Application Schemas Basic principles that regulate Application Schemas: An extension of an existing AIXM Feature should remain valid against the definition of the core AIXM XSD element with the same name An additional feature shall follow the core AIXM modeling conventions (stereotypes, naming, data types, associations, etc.) New stereotypes for collections and choices have been added for the message structure

Extending AIXM Create a new package under the Data Products package. Set XSD tool attributes Create Sub packages Feature/Object Extensions Data Types Extension Application Schema (Message package) Sub packages are used to control the generation of appropriate XML schemas (XSD). The first sub package is the extension package containing your extensions to the AIXM features and objects. If your extension requires new data types a second sub package, the data types extension package, is created containing any new data types needed. The final sub packages that are needed are your message packages. You may have multiple packages based on the number of different message XSDs you need. Most Data Packages will have at least one request package and one response package.

XSD Specifications The Community of Interest will define the Target Namespace and Prefix which are used when generating the XML Schema Element and Attribute Form Defaults are set to unqualified and qualified respectfully For ease of file naming, the Generate Filename property is overridden to provide a consistent file name. The extension package must have the appropriate XSD tool attributes set so the script can generate the namespaces correctly. The following was generated for the Fix Data Products package. <schema xmlns:fix="http://www.faa.gov/avnis/fixes" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:aixm="http://www.aixm.aero/schema/5.0" targetNamespace="http://www.faa.gov/avnis/fixes" elementFormDefault="unqualified" attributeFormDefault="qualified"> Most of the namespaces are standard for AIXM. There are four properties that are needed for each new Data Product package. These properties are shown below with the Source as Override. To modify these properties open the Package Specification and move to the XSD tab.

Feature/Object Extensions (UML) The extension class stereotype must be <<extension>> The class name for the extension must match the class you are extending The extension class must be a specialized class extending the matching base class The extension class attributes are added to the extension class the same as they would a regular AIXM class A feature or object may be extended by creating a class with the same name as the feature and giving it a stereotype <<extension>>. New Features and Objects can be created from the extension. The example below shows the modelling convention used to extend the DesignatedPoint feature. The example adds a new attribute to DesignatedPoint and a new relationship to a new object called DesignatedPointNASUse.

Feature/Object Extensions (XML) The <classname> ExtensionProperyGroup contains the properties (elements and relationships) of the Extension The <classname> ExtensionType element is generated as a XMLSchema <complexType.> and extends base type aixm:AbstractExtensionType The <classname> Extension element is generated as a XMLSchema <element> The Extension element cannot stand alone, it may only exist as an extension to an AIXM base element. The Extension element does not have a timeslice. The Extension element attribute substitutionGroup is the substitutionGroup of the base type extension. Extension elements are not extensible XSD Generation: Use AicmToXmlSchema.B.ebs script to generate the extension XSD. If new data types are introduced, the data type script must be executed first. The script triggers generation of an extension element by recognizing the <<extension>> stereotype. Generation of the extensions follows the AIXM generation rules. Classes with the stereotype of <<extension>> generates 3 related elements for that class. 1. <classname>ExtensionPropertyGroup 2. <classname>ExtensionType 3. <classname>Extension

Data Type Extensions To add new data types create a second sub-package, the data types extension package, containing any new data types needed It is not possible to extend <<enumerations>> or <<datatype>> classes. Only <<codelist>> may be extended

Codelist Extensions Extend a codelist by creating a class with the same name as the codelist and giving it a stereotype <enumeration>>. XSD Generation: Use AicmToXmlSchema.A.ebs script to generate the data type extension XSD. Data Types are generated as a XMLSchema <simpleType> with the appropriate facets, Patterns and/or enumerations defined.

Fix Holding Data The message package is used to generate an XSD for your request and response messages. The following is an example of the FixHoldingData Response Message. This message includes the extensions described above. A Message is modelled in UML using the class object with a stereotype <<message>>. In this example the message is a limited collection of AIXM features with extensions. This is modelled by relating the collection of features; <<collectionMemberChoice>> to the message through the relationship “hasMember”.

Fix Holding Data Record

File Imports & Includes Files within the same namespace should be ‘included’ Files external to the namespace should be ‘imported’ The path is configured to match the directory structure of the UML Model To control the include/import file section of the XSD, the message package must have the appropriate files defined so the script can include and/or import the appropriate XSDs correctly. The script has two methods for defining include and import files. The first method is done when running the script. If the following files are needed to validate your XSD, then select "INCLUDE AIXM NS" in the dialog window that is displayed while running the script. <import namespace=" http://www.opengis.net/gml/3.2" schemaLocation=" ./profile/gml4aixm.xsd "/> <import namespace=" http://www.aixm.aero/schema/5.0" schemaLocation="./AIXM_DataTypes.xsd "/> < import namespace=" http://www.aixm.aero/schema/5.0 " schemaLocation="./AIXM_Feature.xsd "/> <import namespace="http://www.w3.org/1999/xlink" schemaLocation="./xlink/xlinks.xsd"/> <import namespace=" http://www.aixm.aero/schema/5.0 " schemaLocation="./AIXM_AbstractGML_ObjectTypes.xsd"/ The second method for adding additional imports and includes such as the extension XSDs needed for the FixData Record is to define them in the message package specification. <include schemaLocation="Fix_Extension_Datatypes.xsd"/> <include schemaLocation="Fix_Extension.xsd"/>

Application Schema (XML) The <classname>CollectionPropertyGroup is generated as a XMLSchema <complexType>, which extends gml:AbstractFeatureMemberType, and includes a <choice> between all of the features it is pointing to XSD Generation: Use AIXM-ApplicationSchemaGenerator.ebs script to generate the message XSD. The script triggers generation of message element by recognizing the <<message>> stereotype. Classes with the stereotype of <<message>> following the AIXM feature collection response generates 4 related elements for that class. 1. <classname>CollectionPropertyGroup 2. <classname>MessagePropertyGroup 3. <classname>MessageType 4. <classname>Message The <classname>CollectionPropertyGroup is generated as a XMLSchema <complexType>, which extends gml:AbstractFeatureMemberType, and includes a <choice> between the all the features it is pointing to.

Application Schema (XML) The <classname>MessagePropertyGroup is generated as a XMLSchema <group>, which contains the properties (elements and relationships) of the Message.

Application Schema (XML) The <classname>MessageType element is generated as a XMLSchema <complexType.> and extends base type aixm:AbstractAIXMMessageType.

Application Schema (XML) The <classname>Message element is generated as a XMLSchema <element>. The associations are treated as objects. They are included in the schema.

WFS (transaction: insert, update, delete) WFS Insert uses FeatureCollection WFS update designed to send property to be updated and a filter to specify the feature being updated

IFPA Request <Update typeName="aixm:AirspaceUsage"> - <Property>   <Name>aixm:timeSlice</Name> - <Value> - <AirspaceUsageTimeSlice> - <gml:validTime> - <gml:TimePeriod>   <gml:beginPosition>2006-03-15T00:00:00</gml:beginPosition>   <gml:endPosition indeterminatePosition="unknown" />   </gml:TimePeriod>   </gml:validTime>   <interpretation>BASELINE</interpretation>   </AirspaceUsageTimeSlice> - <AirspaceUsageTimeSlice> - <gml:validTime> - <gml:TimePeriod>   <gml:beginPosition>2006-07-24T09:00:00</gml:beginPosition>   <gml:endPosition>2006-07-24T15:00:00</gml:endPosition>   </gml:validTime>   <interpretation>TEMPDELTA</interpretation>   <sequenceNumber>1</sequenceNumber>   </AirspaceUsageTimeSlice>   </Value>   </Property> - <ogc:Filter>   <ogc:FeatureId fid="A00002" />   </ogc:Filter>   </Update> This works fine for updates on single, uniquely identifiable features. However, it starts to get more complex when sending updates to features that do not have a unique control number. How would a transaction look for an update or a delete of a runway threshold elevation? One possibility is that the BASELINE timeslice has to include the association to the RunwayDirection feature, so the receiver can determine which runway it came from. Or we had the concept of transactable collections - that is to put a feature, then a set of features had to be sent (e.g. a RunwayDirection and its RunwayCenterlineElevation are always sent together). This could be then structured as a RunwayDirection BASELINE timeslice (the object being updated) and RunwayDirection and RunwayCenterlineElevation PERMDELTA timeslices (the updates).

Questions?

Designated Point (Fix) Extensions

Designated Point (Fix) Data Type Extensions