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