Model Transformation

Introduction

What?!? No travel? Well… yes. too much travel. Hence the low posting frequency. Apart from moving with my family from our old house (that was sold and where we had to leave in 3 weeks) to a temporary vacation home that is not even large enough to house the family of 4 (well, 5 with the dog) let alone has enough place for all our stuff.
So most of it is stored at the moving company and will be brought to our new home when it’s finished (Planning date is December 13. But we all know what planning dates mean, do we….)

Luckily there was (and will be) much traveling in the last weeks and the coming months. I already visited Munich, for our MESCONF, Paris (just for flying to Schiphol), Bückeburg (For work, and we are also moving there), Köln (Cologne) and Zürich.

In the next weeks I’ll be traveling to Bückeburg (Office), Paris, Nantes, Berlin, Possibly Detroit, Ft Myers, Boston, Sindelfingen (ESE), Munich and more.

Transforming your Models

But that is not what I wanted to talk about. There is a more technical topic that needs attention.
Everybody knows (or should know) that we are no longer Willert but SodiusWillert and that we are awesome in connecting engineering data in the widest form possible.
Connecting Jira to IBM via OSLC, connecting the world of ALM to PLM by linking PTC Windchill to IBM with OSLC but also transforming your UML (or even SysML) model to code in C or C++.
One of the questions we receive is that to connect, sync or convert models into other models.

AUTOSAR

One of the models a lot of our customers use is AUTOSAR. That is a standard used in Automotive and contains a standard data format for exchanging information between tools. It is called ARXML (AUTOSAR XML) and is very complex. With ARXML you can exchange very detailed information about the software you make for car ECU’s. You have to use it if you want to create a run-time system for your ECU (RTE – Run-Time Environment) but also to use the Basic Software for your ECU.
But AUTOSAR also defines a model structure that can be used to define your ECU Architecture. Rhapsody can do that, you just load the AUTOSAR profile and you can model AUTOSAR. (Made by SodiusWillert)

Now this modeling structure has some similarities with SysML (Also uses Blocks and Ports etc) but that is, unfortunately, not really the same. AUTOSAR was, at the start, set up to improve cooperation between different automotive companies but somehow this path was left some time ago. IMHO opinion it is needlessly complex and tries to cover all possible ways to do something instead of limiting the users to the bare necessities and introduce an abstraction that would make life easier.
This is where the problems start when you want to use SysML to do architecture modeling, there is no defined path from SysML to AUTOSAR.

Different soup: M2M

That’s how this is called in German: everybody is boiling their own soup. That leads to the fact that there is no single correct solution but a tailor-made solution for every user.
That is where the SodiusWillert M2M comes in. Louis Talvande from SodiusWillert designed this tool to do a model transformation based on rules that the user can define himself.
These rules are part of your Rhapsody model so you can easily select your model elements.

Example of Transformation Rules

When started M2M will transform your current model to another model using the rules you have defined.

More than just transformation

Sometimes (or actually mostly….) just mapping one element to another just isn’t enough. That’s why M2M allows you to not only map single elements to multiple elements but also 1:n or n:1 or n:n.
You can also define conditions in your mapping rules that can decide if a transformation should be made.
And if that is not enough, you can also define scripts (Javascript) comfortably inside your Rhapsody model, to post-process your elements. The complete Rhapsody Java API is to your disposal there.

Merging

Of course, transforming a model is cool. But what if you make changes to the original model? Of course you can always throw away your target model and transform again but what if you also have made changes to the target model?
Rhapsody comes with DiffMerge built-in. Since you are using all standard Rhapsody elements Diffmerge works out-of-the-box.

Features of the M2M Tool

  • Transforms Rhapsody models into Rhapsody models
  • Flexible (user modifiable) transformation rules
  • Transformation can be launched via commandline
  • Portable mapping rules, so you can upgrade from e.g AUTOSAR 4.22 to AUTOSAR 4.31
  • Merging capability with DiffMerge
  • 1:1, 1:n, n:1 and n:n mappings
  • post-processing very easily possible
    • conditional mapping
    • creating new elements using the JAVA API

Just contact me or Louis if you want to learn more about M2M

Well… that’s it for today! Have fun transforming with Rhapsody

Walter van der Heiden ( wvdheiden@willert.de )
Louis Talvande ( ltalvande@sodius.com )

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.