AMW Use Case - Comparison of large metamodels for Automotive Systems

AMW Logo

Frequently, the set of modeling concepts for a given domain experiments certain kind of evolution: new elements are added, previous elements are ruled out while others just remain but suffering from some modifications. This way, the models conforming to the previous version of the metamodel become obsolete, so they have to be updated in order to conform to the new metamodel specification. This task can be very tedious and even more in situations like the one tackled in this use case, where the size of the metamodels considered makes almost impossible to perform this task by hand.

In this Use Case we show how model weaving can be used in order to generate model transformations that support the migration of models conforming to different version of a same metamodel. This use case applies similar techniques of the Metamodel Comparison use case, but modified to work with very large metamodels (each one comprises around 25.000 elements). With such a size, the definition of a model transformation between those metamodels from scratch would be completely unaffordable.

The metamodels considered in this use case are two different versions of a metamodel used to describe the System, Software and Hardware of an automobile defined by AUTOSAR (AUTomotive Open System ARchitecture), a partnership of automotive manufacturers and suppliers working together to develop and establish a de-facto industry standard for automotive electrical/electronic (E/E) architectures.

Overview

The approach followed in this Use Case is basically the same followed in a previous one: two different versions of the same metamodel, AUTOSAR2.0 and AUTOSAR2.1, used to define the set of modeling concepts considered in the automotive domain, are compared with the aim of defining a model transformation that allows migrating from models conforming to the former version of the metamodel to the later one.
This model comparison is based on the execution of refined versions of the matching transformations already used in the mentioned Metamodel Comparison Use Case that generates as output different versions of the weaving model between the two versions of the metamodel considered.
The transformations were modified to support matching of large metamodels. The process is summarized in the figure below.



"Metamodel comparison" Use Case's Overview

A preliminary weaving model (Autosar.amw) containing just one root element referencing the woven models (AUTOSAR2.0 and AUTOSAR2.1) is created by hand using the AMW wizard.

This basic weaving model is refined in a continuous process that consist basically in executing different matching transformations that take as input the two considered metamodels and the last weaving model generated.
This way, with each new transformation executed we obtained a more valuable weaving model, since the different links defined between both metamodel elements are more likely to be real equivalences between the input metamodels. These equivalences will be translated to be supported by a model transformation.

So, the weaving models generated are:

  • Restricted Cartesian Product (Autosar_cp.amw): this weaving model is merely a Cartesian product of the elements having the same type found in both metamodels
  • Threshold (Autosar_cp_th.amw): the elements from the previous weaving model with the lower similarity values are rolled out of the resulting weaving model
  • Name equality (Autosar_cp_th_equal.amw): a similarity value is assigned to each one of the matched elements obtained in the previous model (Autosar_cp.amw); the elements with the same name receive a higher value.
  • Link rewriting (Autosar_cp_th_equal_lr.amw): the elements from the previous weaving model are reorganized according to their nature, that is, taking into account if they are Classes or Attributes/References contained in those Classes
  • Enum Datatypes processing (Autosar_cp_th_equal_lr_enum.amw): due to the special characteristics of the metamodels considered, a new transformation dedicated to map the enum datatypes has been developed and applied in this use case
  • Link rewriting - non equivalence ( Autosar_cp__th_equal_lr_enum_noneq.amw): a new set of links is added in the previous model, identifying the elements from the input metamodels (AUTOSAR2.0 and AUTOSAR2.1) for what no equivalence has been found

Finally, the obtained weaving model is used to automatically generate a model transformation that supports the migration of models conforming to AUTOSAR2.0 metamodel to models conforming to AUTOSAR2.1 metamodel. This transformation is obtained by executing a higher-order transformation (HOT) included in the AMW plug-in. This transformation takes as inputs two different metamodels and a weaving model between these metamodels and generates as output an .ecore model conforming to the ATL metamodel, that is, an ATL model (Autosar_cp_th_equal_lr_noneq_hot.ecore).
This model is directly extracted to an ATL file by using again one of the functionalities provided by the AMW/AM3 plug-ins.

Metamodels and Models extraction

As mentioned before, this use case is similar to the Metamodel comparison and model migration use case. The major difference is that the metamodels and models are much bigger, so new and refined transformations has been developed to generate the different weaving models.
Another significance difference is the way of defining the metamodels implied in the model migration process, as well as the models used to verify the ATL transformation generated as result of the process.
The idea of this process is depicted in the figure below:



Metamodels and Models extraction

In this case, developing the metamodels from scratch would had been a very tedious task and prone to errors. Nevertheless, we take advantage of the functionalities provided by EMF to automatically generate the AUTOSAR 2.0 and AUTOSAR 2.1 ecore metamodels from the original XML Schema where those metamodels were defined.

Moreover, once these .ecore metamodels are defined, we use EMF to generate the code capable of reading models models conforming to those metamodels, as well as a visual editor for those models.
Finally, by using the plug-ins automatically generated by EMF, any XML document conforming to the original XML Schema defining the AUTOSAR 2.0 metamodel (or AUTOSAR 2.1 metamodel) is automatically recognized as a model conforming to the AUTOSAR 2.0.ecore metamodel (respectively, AUTOSAR 2.1.ecore). Thus, this model is edited using the generated editor, and can be used as input to test the ATL transformation obtained directly. This process is an ad-hoc XML injection.

Download and examples

Autosar

This example contains the transformation that was generated.

Related use cases

Metamodel Comparison and Model Migration

The Use Case in which the one presented here is based. The step-by-step HowTo that explains how to execute the examples is recommended here in order to execute this Use Case.

Matching

Matching is the generic process that creates weaving models. This use case gives a general overview of the matching process, and how it is handled by AMW and ATL.

Acknowledgement

The present work is been supported by the GOLD project financed by the Spanish Ministry of Education and Science (TIN2005-00010) and the FoMDAs project (URJC-CM-2006-CET-0387) co-financed by the Rey Juan Carlos university and the Regional Government of Madrid.

General Information