AIRM Derivation: Generating ATM Exchange Models

4,137 views

Published on

This is the outcome of the AIRM Derivation task within the OGC OWS-9 Aviation Thread,

The aim of this task was to demonstrate how to generate an ATM exchange model (UML) conforming to ISO 19109 Rules for Application Schema which can then be used to automatically generate implementation schema (GML/JSON).

To download the MDA Transformation templates and get further information go to Snowflake labs: http://wiki.snowflakesoftware.com/display/LAB/OWS-9+Aviation%3A+
AIRM+Derivation.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,137
On SlideShare
0
From Embeds
0
Number of Embeds
147
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Hello, I‘m Debbie Wilson from Snowflake Software and I shall take you through the work undertaken by Snowflake Software and interactive instruments within the OWS-9 Aviation Thread – AIRM Derviation Task
  • The AIRM is a consolidated logical domain model being developed by Eurocontrol within the SESAR programme. It shall be used as the common reference model for key subject fields relating to the wide range of Air Traffic Management applications such as meteorology, flight information and airspace management. [Click]The aim of this task is to demonstrate how to derive an ATM exchange model and their physical implementation schema from the AIRM using the Weather Exchange Model (WXXM) as an example.[Click]To achieve this goal we needed to:Develop the tools needed to generate ATM exchange models and their implementation schemaDevelop and document the mapping rules, andDemonstrate the process by transforming the AIRM Meteorology package into WXXM Application Schema and generate a GML and JSON schema
  • Stage 1 involves executing MDA Transformations within Enterprise Architect to transform the relevant AIRM packages into an ATM exchange model that contains one or more application schema conforming to the ISO 19136 UML Profile.[Click]Once the UML version of the exchange model has been generated it is now ready to generate the physical implementation schema and associated resources (such as codelist dictionaries and feature catalogues) using ShapeChange
  • To successfully transform the AIRM, two set of mapping rules were defined:[Click]The first set of rules are for the MDA Transformation – which adds the relevant stereotypes and tagged values to UML constructs and sets the AIRM default multiplicities on attributes and associations, where needed.[Click]The second set of rules define the mapping between UML types and their relevant types in GML and JSON. ShapeChange already supports mapping rules for converting ISO/OGC types to GML and JSONso all we needed to do was define some additional mapping rules for :Simplifying the encoding of AIRM data types such as measures and stringsMap any AIRM data types that have already been implemented in an existing ATM exchange model such as AIXM, and Map ISO types used in the model that could not be directly instantiated to a relevant GML/JSON type
  • To generate an ATM exchange model from the AIRM involves several steps:[Click]You first need to set up the AIRM model for generating ATM exchange models. By firstly, importing the MDA transformation templates and then create a destination package for the Exchange models[Click]Now you are ready to select the relevant packages and classes from the subject field and data types packages and transform them into the exchange model. The final step in the process is to set the tagged values to ensure that ShapeChange can process the model correctly to generate the implementation schema.
  • Each ATM Exchange Model will be different and vary in complexity (as already exemplified by AIXM, WXXM and FIXM). Therefore the MDA Transformation must be capable of handling diversity and allow the modeller flexibility to develop the exchange model based on the outcome of key design decisions such as:Will it is contain only 1 Subject Field or multiple?Is it going to be a large model, if so should it be made up of multiple Application Schema or a single Application Schema?Does the Application Schema contain sub-packages? If so should these be handled as leaf packages?Shall it import types from other ATM exchange models (e.g. AIXM)?How should the classes contained within the Data Types package be handled?Should common types used in multiple exchange models be encoded in a common AIRM exchange model or encoded in the first **XM developed?Should codelists be encoded external to the schema?
  • Now the Exchange Model has been generated it is a simple process to generate the implementation schemas using ShapeChange. But before you can execute ShapeChange you must first configure the ShapeChange configuration file. This requires you to set the:Input parameters: in this section, you specify the location and format of the source model, which application schema packages are to be converted and UML Profile that has been applied[Click]Logging parameters: where you specify the destination location for the log file and the logging level[Click]Target parameters: here you will specify the destination locations , formats, and encoding rules for each of the outputs
  • In the demo, ShapeChange output two sets of GML & JSON Schema:AIRM – containing the common data types and WXXM – containing the WX and AVWX Application Schemas
  • In the demo, ShapeChange output two sets of GML & JSON Schema:AIRM – containing the common data types and WXXM – containing the WX and AVWX Application Schemas
  • Codelists can either be encoded directly within the XML schemas (which is the current approach for ATM exchamge models). Alternatively they can be maintained in codelist registries within this demonstration, WXXM was configured to encode the codelists as a codelist dictionary which can then be stored in a codelist register within the SESAR registry.
  • Codelists can either be encoded directly within the XML schemas (which is the current approach for ATM exchamge models). Alternatively they can be maintained in codelist registries within this demonstration, WXXM was configured to encode the codelists as a codelist dictionary which can then be stored in a codelist register within the SESAR registry.
  • ShapeChange supports two encoding options for codelists – GML Dictionary or SKOS
  • Finally if required, ShapeChange can generate a Feature Catalogue which provides a user-friendly description of the exchange model.
  • This can be output either in HTML or XML
  • This can be output either in HTML or XML
  • Thanks for taking the time to watch this video.If you want to find out more about AIRM Derivation work undertaken in OWS-9 please take a look at the Engineering Report and if you have any questions please don’t hesitate to contact the Aviation Domain Working Group via the mailing list.
  • AIRM Derivation: Generating ATM Exchange Models

    1. 1. ® Hosted and Sponsored by AIRM Derivation 83rd OGC Technical Committee Redlands, CA USA Debbie Wilson Clemens PorteleSnowflake Software interactive Instruments January 17, 2013 © 2013 Open Geospatial Consortium
    2. 2. AIRM to WXXM Derivation ATM Information Reference Model (AIRM) is used as a common reference for civil, military and civil-military information constructs relevant to ATM developed as part of SESAR. Aim: Demonstrate how to derive ATM exchange models (**XM) and their implementation schema from the AIRM – Meteorology to WXXM Objectives 1. Develop tools for generating ATM Exchange Models (**XM) from AIRM 2. Develop and document mapping rules: • AIRM to ISO 19109 UML Application Schema • Additional mapping rules needed for programmatic derivation 3. Demonstrate transforming AIRM Meteorology package into WXXM and two implementation schemas: GML/ JSON ®OGC © 2013 Open Geospatial Consortium, Inc.
    3. 3. AIRM Derivation Architecture Two Stage Approach: ShapeChange Available from: http://shapechange.net ®OGC © 2013 Open Geospatial Consortium
    4. 4. AIRM Derivation Architecture Two Stage Approach: ShapeChange GMLAIRM WXXM MDA Shape Transform Change JSON Stage 1: Transform relevant AIRM packages into an ATM Exchange Model (**XM ) Application Schema Stage 2: Transform the ATM Exchange Model into physical implementation schemas (GML, JSON) and other representations ®OGC © 2013 Open Geospatial Consortium, Inc.
    5. 5. Mapping Rules• Two sets of mapping rules were defined: MDA Transformation Rules UML to GML/JSON Encoding Rules• Add Stereotypes and Tagged Values to • ShapeChange already supports mapping rules packages, classes and attributes for ISO/OGC UML types to GML and JSON*• Set AIRM default multiplicities on • Defined additional mapping rules for: attributes and association roles 1. Simplify encoding of AIRM data types (measures and strings) to use existing types (e.g. gml:Measure, integer) 2. Mapping AIRM data types to existing **XM types (e.g. AIXM geometry types) 3. Map ISO types not instantiated in GML & JSON to relevant GML/JSON type (e.g. DirectPosition  GM_Point) * UML to JSON Rules were developed in the SSI thread ®OGC © 2013 Open Geospatial Consortium
    6. 6. MDA Transformation• Transforming AIRM packages into an ATM Exchange Model involves several steps: Set-up 1. Import the MDA Transformation Templates into Enterprise Architect 2. Create a destination package for the Exchange Models Transformation: 3. Select then transform relevant AIRM Subject Fields, Data Types and Abstract Types 4. Set the relevant tagged values to ensure correct generation of the implementation schema using ShapeChange ®OGC © 2013 Open Geospatial Consortium
    7. 7. Demo: Generating an Exchange Model from AIRM http://youtu.be/kCOSr7PtZhs
    8. 8. Generating the implementation schemas ShapeChange ConfigurationShapeChange Configuration Specify the location and format (xmi/eap) of the source model, which application schema packages are to Input be converted and UML profile applied Logging Specify the name and destination location of the log file and the logging level Target • XML Specify the destination locations, • JSON formats, encoding rules and any • Codelist Dictionary additional mapping rules for each of the required outputs • Feature Catalogue ®OGC © 2013 Open Geospatial Consortium
    9. 9. Running ShapeChange …• Either from the command line referencing the configuration file: java -jar ShapeChange-2.0.0-SNAPSHOT.jar -Dfile.encoding=UTF-8 -c ows9_wxxm_config.xml• Or from Enterprise Architect: After processing, the log file, implementation schema and other targets are generated on the file system ®OGC © 2013 Open Geospatial Consortium
    10. 10. Outputs from ShapeChange GML & JSON Schemas: • AIRM • WXXM – WX & AVWX ®OGC © 2013 Open Geospatial Consortium
    11. 11. Outputs from ShapeChange GML & JSON Schemas: • AIRM • WXXM – WX & AVWX ®OGC © 2013 Open Geospatial Consortium
    12. 12. Outputs from ShapeChange GML & JSON Schemas: • AIRM • WXXM – WX & AVWX Codelist dictionaries ®OGC © 2013 Open Geospatial Consortium
    13. 13. Outputs from ShapeChange GML & JSON Schemas: • AIRM • WXXM – WX & AVWX Codelist dictionaries ®OGC © 2013 Open Geospatial Consortium
    14. 14. Outputs from ShapeChange GML & JSON Schemas: • AIRM • WXXM – WX & AVWX Codelist dictionaries Feature Catalogue ®OGC © 2013 Open Geospatial Consortium
    15. 15. Outputs from ShapeChange GML & JSON Schemas: • AIRM • WXXM – WX & AVWX Codelist dictionaries Feature Catalogue ®OGC © 2013 Open Geospatial Consortium
    16. 16. Outputs from ShapeChange GML & JSON Schemas: • AIRM • WXXM – WX & AVWX Codelist dictionaries Feature Catalogue ®OGC © 2013 Open Geospatial Consortium
    17. 17. Outputs from ShapeChange GML & JSON Schemas: • AIRM • WXXM – WX & AVWX Codelist dictionaries Feature Catalogue ®OGC © 2013 Open Geospatial Consortium
    18. 18. Summary Issues: • AIRM is still in development so inconsistencies exist between model and AIRM Foundation Rules • Difficult to automatically transform structured data types • Recommendation: apply <<Entity>> to features and assign no stereotype to identifiable structured data types and do not apply the suffix “Type” • Some association roles are assigned multiplicity but no name so inconsistent with ISO 19136 Rules for GML Application Schema • May incorrectly transform some multiplicities as EA sets multiplicity to 1 by default – not visible on model. But in the AIRM, if multiplicity is not visible the property carries the AIRM default multiplicity: 0..1 • The model uses an old version of the ISOTC211 foundation schema and has deleted several key packages (e.g. ISO 19103 and ISO 19156 (draft). • Recommendation: import full ISOTC211 model (preferably connect to SVN repository) ®OGC © 2013 Open Geospatial Consortium
    19. 19. Summary Improvements MDA Transformation Rules UML to GML/JSON Encoding Rules• Develop an AIRM UML Profile to ensure • No encoding rule improvements were identified classes are implemented consistently based on WXXM according to AIRM Foundation Rules • Additional encoding rules may need to be• Evaluate use of additional tagged values developed to support AIXM (Temporality/ to improve encoding: extension) • inlineOrByReference • Evaluate ability to generate schematron rules • vocabulary, extensibility (INSPIRE) automatically from the UML • Voidable (INSPIRE)• Future Work • Identified modeling issues should be resolved to enable a consistent conversion from AIRM to implementation schemas • Evaluate ability to generate other exchange models (FIXM, AIXM) • Test implementation schemas, particulary JSON ®OGC © 2013 Open Geospatial Consortium
    20. 20. Summary• Key Accomplishments Successfully demonstrated the ability to transform AIRM and automatically generate implementation schemas Developed simple, flexible transformation & mapping rules for generating ATM **XM Application Schema By using a schema conversion tool such as ShapeChange ensure schemas are generated consistently http://wiki.snowflakesoftware.com/MDA Transformation display/LAB/OWS-9+Aviation%3A+Templates AIRM+DerivationShapeChange http://shapechange.net/tmp/ows9/wxxm/Config & Schemas ®OGC © 2013 Open Geospatial Consortium
    21. 21. ® OGC Public Engineering Report 12-094: OWS-9 Aviation: AIRM Derivation http://www.opengeospatial.org/standards/per Aviation Domain Working Group Email: aviation.dwg@lists.opengeospatial.orghttp://external.opengis.org/twiki_public/AviationDWG/WebHome © 2013 Open Geospatial Consortium

    ×