1 / 31

AIXM and Instrument Flight Procedures Automation

AIXM and Instrument Flight Procedures Automation. 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).

gusj
Télécharger la présentation

AIXM and Instrument Flight Procedures Automation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AIXM and Instrument Flight Procedures Automation

  2. 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]. Instrument Flight Procedures Automation (IFPA)

  3. Data Exchange Integration for IFPA

  4. Military Integration for IFPA

  5. IFPA Products • 8260 Forms (Rule making documents) • Flight Inspection Documents • Aeronautical Charts • Data coding for FMS and MMR

  6. IFPA Messages

  7. IFPA Messages • Request Messages • WFS (getFeature, getObject, etc.) • Filters • Response Message • WFS:FeatureCollection • Custom Application Schema • Fault errors • WFS (transaction: insert, update, delete)

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

  9. IFPA Messages • Response Message • Custom messages extending AIXM

  10. AIXM Data Products • Feature/Object Extensions • Data Types Extensions • Codelist Extensions • Application Schemas

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

  12. 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)

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

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

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

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

  17. Codelist Extensions Extend a codelist by creating a class with the same name as the codelist and giving it a stereotype <enumeration>>.

  18. Fix Holding Data

  19. Fix Holding Data Record

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

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

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

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

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

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

  26. 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:TimePeriod> </gml:validTime> <interpretation>TEMPDELTA</interpretation> <sequenceNumber>1</sequenceNumber> </AirspaceUsageTimeSlice> </Value> </Property> - <ogc:Filter> <ogc:FeatureId fid="A00002" /> </ogc:Filter> </Update>

  27. Questions?

  28. Designated Point (Fix) Extensions

  29. Designated Point (Fix) Data Type Extensions

More Related