Author: rhapsody207 (Page 2 of 15)

Introduction

M2M is a product from SodiusWillert that helps you to save large amounts of time. It converts Rhapsody models made with certain profiles to other profiles. For example, taking a SysML model and convert that to an AUTOSAR model.

How does it work?

It is not really magic… actually you do your own magic. M2M uses a ruleset to define what elements are moved to which other elements, for instance: take a SysML Block and transform it to an AUTOSAR Block.
Now that would be an easy one. You can also make it more complicated. E.g.: You can define that a SysML Block with stereotype “SWC” will be converted into an AUTOSAR SWC.

That is already more interesting. But it doesn’t stop there. The rules allow you to define multiple elements to convert to one element or one element to convert to multiple elements (1:1, 1:m, n:1, m:n)
But then the fun really starts because you can also add functions (written in JavaScript) to do pre-conversion checks (“Do I want this specific element to convert?”) or post-processor actions (:e.g. “Rename this element” or “Create other elements on other places”)

You only sync once?!?

This opens a lot of posibilities to transfer model element between models from different profiles. Using M2M in combination with DiffMerge opens even more possibilities.
This helps you in keeping different models up-to-date, no matter where you make changes.
So you can have multiple different views on your System under Development, a Systems Engineering view, an AUTOSAR view, a Software View and maybe even a source-code view of the used BSW (Basic SoftWare) all of them subject to changes but all of them in sync thanks to M2M.

Put the power where you need it.

Some models have certain possibilities that others don’t have and vice-versa.
This means that you should model in the profile that offers you what you need.
SysML is perfect to model requirements and use-cases and link them, the AUTOSAR model gives you feel insights in all parts of your software and the UML model has a bit of both (and state machines…)
M2M allows you to add your own information exactly where it fits best.

I want to have this!!

That is cool. Contact me to get an evaluation version and an evaluation license.

Introduction

When developing systems or software for an Automotive environment you cannot avoid using AUTOSAR. This is the standard for exchanging information between involved parties inside Automotive projects, can be an OEM requesting a TIERx to do the development of a certain ECU or small companies doing parts of software applications that will run on that ECU.
AUTOSAR also defines a standard software layer (BSW or in Adaptive ARA) that helps you developing on different microcontrollers without really knowing all details.
Then there is the Operating system, which on the Classic Platform is almost completely statically defined an generated out of the information in your AUTOSAR model. Also called RTE.
There are several companies where you can purchase tools to help you creating applications and generate the stuff that you need to make a complete production ready application.
They are from companies like Vector, Elektrobit, dSpace, Dassault but also from Siemens (former Mentor). We used to use ArcCore but they have been purchased by Vector and integrated in their tools now.
The problem with most of these tools is that they are looking at things from the “low-level” side. There is a lot of detailing necessary before you can work with these tools and that certainly is not helpful when you only want to create an overview of the blocks you are going to implement.
You can use Visio or a cheap UML tool for that, this will not give you the benefits you want since they are solutions that will not allow you to incorporate that information in a dynamic way in your AUTOSAR model.
There are also tools from previous named companies that try to overcome this disadvantage but these tools still work in a proprietary world, not with an open standard like UML or SysML

Why UML (or SysML)?

These are standards. And standards that were developed quite a while ago with many people that have knowledge of them. Standards that are taught on universities.
The UML was made out of lots of other smaller pieces of standards that were already available, hence the “Unified” in the name. It was made especially for handling the growing complexity of software projects. Source code (generation) played a role, of course, but the emphasise was on the handling of complexity. This was done with different diagram types for different aspects of the system to be developed. Every person that is involved in the project can enter information and extract information from the UML model and the exact right level without being disturbed by information that is not relevant for that person.

Rhapsody AUTOSAR profile

Rhapsody has, for quite a while now, an AUTOSAR profile. This allows Rhapsody to read in and write ARXML files. They are then stored in a Rhapsody Model so they can be edited on an AUTOSAR level. Rhapsody can even convert information between AUTOSAR versions!!
All AUTOSAR Elements are implemented and can be edited. This is not always the most comfortable way, some things are better done by using an AUTOSAR dedicated tool like Vector’s DaVinci for instance.
For use with the Code Generation from Rhapsody we also have an “AUTOSAR lite” profile

Rhapsody Rulezzz!

So, how do we do that with Rhapsody then?
Rhapsody is a UML tool that exists since 1996. It also does SysML (Because that is a UML profile, although that will change in the SysML 2.0 release).
But that is not all, the tool is part of the IBM Engineering Tools and can exchange information with DOORS, DNG and many other tools via OSLC on the Jazz platform.So your requirements from DOORS or DNG can be seen and linked inside Rhapsody. The same platform also allows you to use widespread external tools like Jira from Atlassian or even link to your production using WindChill from PTC.
And as already said above: Rhapsody can read ARXML files and exchange them with all other AUTOSAR enabled tools. You can even use MATLAB Simulink models linked to Rhapsody models.
This all enables you many different views on your application or system but still have these views synchronized (or even linked when they use OSLC)

Doing the Magic: M2M

Of course Linking informations is ALWAYS better than synching information, sometimes linking is just not possible. For that we have M2M (Model to Model) that can convert Rhapsody models with different profiles. It is rule-based, you create rules like:

When a certain element of MetaClass “SourceMetaClass” and a stereotype “SourceStereoType” is found
Then see if certain conditions “Conditions” apply
If that is the case, convert the element to an element of MetaClass “TargetMetaClass” with stereotype “TargetStereoType”. If there is a linked operation “Operation” then execute that.
All Rules have a sequence number, lower numbers will be executed first and exclude higher sequence rules.

After applying the rules, the resulting model must be merged back using (built-in) DiffMerge. This ensures that changes can be made to single model elements without redoing the whole model.

This allows a very sophisticated way of maintaining different views to the same information.

Happy Modeling with Rhapsody

Walter van der Heiden (wvdheiden@sodiuswillert.com)

Introduction

When developing systems or software for an Automotive environment you cannot avoid using AUTOSAR. This is the standard for exchanging information between involved parties inside Automotive projects, can be an OEM requesting a TIERx to do the development of a certain ECU or small companies doing parts of software applications that will run on that ECU.
AUTOSAR also defines a standard software layer (BSW or in Adaptive ARA) that helps you developing on different microcontrollers without really knowing all details.
Then there is the Operating system, which on the Classic Platform is almost completely statically defined an generated out of the information in your AUTOSAR model. Also called RTE.
There are several companies where you can purchase tools to help you creating applications and generate the stuff that you need to make a complete production ready application.
They are from companies like Vector, Elektrobit, dSpace, Dassault but also from Siemens (former Mentor). We used to use ArcCore but they have been purchased by Vector and integrated in their tools now.
The problem with most of these tools is that they are looking at things from the “low-level” side. There is a lot of detailing necessary before you can work with these tools and that certainly is not helpful when you only want to create an overview of the blocks you are going to implement.
You can use Visio or a cheap UML tool for that, this will not give you the benefits you want since they are solutions that will not allow you to incorporate that information in a dynamic way in your AUTOSAR model.
There are also tools from previous named companies that try to overcome this disadvantage but these tools still work in a proprietary world, not with an open standard like UML or SysML

Why UML (or SysML)?

These are standards. And standards that were developed quite a while ago with many people that have knowledge of them. Standards that are taught on universities.
The UML was made out of lots of other smaller pieces of standards that were already available, hence the “Unified” in the name. It was made especially for handling the growing complexity of software projects. Source code (generation) played a role, of course, but the emphasise was on the handling of complexity. This was done with different diagram types for different aspects of the system to be developed. Every person that is involved in the project can enter information and extract information from the UML model and the exact right level without being disturbed by information that is not relevant for that person.

Rhapsody AUTOSAR profile

Rhapsody has, for quite a while now, an AUTOSAR profile. This allows Rhapsody to read in and write ARXML files. They are then stored in a Rhapsody Model so they can be edited on an AUTOSAR level. Rhapsody can even convert information between AUTOSAR versions!!
All AUTOSAR Elements are implemented and can be edited. This is not always the most comfortable way, some things are better done by using an AUTOSAR dedicated tool like Vector’s DaVinci for instance.
For use with the Code Generation from Rhapsody we also have an “AUTOSAR lite” profile

Rhapsody Rulezzz!

So, how do we do that with Rhapsody then?
Rhapsody is a UML tool that exists since 1996. It also does SysML (Because that is a UML profile, although that will change in the SysML 2.0 release).
But that is not all, the tool is part of the IBM Engineering Tools and can exchange information with DOORS, DNG and many other tools via OSLC on the Jazz platform.So your requirements from DOORS or DNG can be seen and linked inside Rhapsody. The same platform also allows you to use widespread external tools like Jira from Atlassian or even link to your production using WindChill from PTC.
And as already said above: Rhapsody can read ARXML files and exchange them with all other AUTOSAR enabled tools. You can even use MATLAB Simulink models linked to Rhapsody models.
This all enables you many different views on your application or system but still have these views synchronized (or even linked when they use OSLC)

Doing the Magic: M2M

Of course Linking informations is ALWAYS better than synching information, sometimes linking is just not possible. For that we have M2M (Model to Model) that can convert Rhapsody models with different profiles. It is rule-based, you create rules like:

When a certain element of MetaClass “SourceMetaClass” and a stereotype “SourceStereoType” is found
Then see if certain conditions “Conditions” apply
If that is the case, convert the element to an element of MetaClass “TargetMetaClass” with stereotype “TargetStereoType”. If there is a linked operation “Operation” then execute that.
All Rules have a sequence number, lower numbers will be executed first and exclude higher sequence rules.

After applying the rules, the resulting model must be merged back using (built-in) DiffMerge. This ensures that changes can be made to single model elements without redoing the whole model.

This allows a very sophisticated way of maintaining different views to the same information.

Happy Modeling with Rhapsody

Walter van der Heiden (wvdheiden@sodiuswillert.com)

Introduction

AUTOSAR is the standard created to support software development in automotive environments.
Why is there a special standard for that? Is software for cars special?
No, the software itself is not, it’s just plain ‘C’ (lately also ‘C++’) But the circumstances are different.
Are there special Tools for that? Yes there are. Wouldn’t it be nice to just use the normal Development Tools? YES Of Course!
Willert has all these tools and the add-ons necessary to use them in an AUTOSAR environment!

Differences

• Timing is critical, in more than one way.
  There is the timing in the software itself, which is still critical although CPU performance increased severely last years. This is partly because most software in cars is “polled”. Due to the fact that there are algorithms in cars where developers use Simulink (and code generation in TargetLink and/or Embedded Code) that is “control loop software”, so does stuff every 10 milliseconds.
  That is OK, it works but your software is ALWAYS doing “something”. And while different paths through your code are taken (with different execution times) this is difficult to manage.
  Then there is the timing in the release of cars. That is different than most projects…. A cars introduction and production is planned years ahead and there is NO DELAY possible. Period. You can easier shift the timing of a solar eclipse that the intro of a car. So software development cycles must be predictable (they aren’t but they must be….)
• Cooperation not only between colleagues but worldwide between multiple companies.
  Yes. Cars are defined by OEM’s, parts are made by Tier 1,2,3 etc by companies that have developers everywhere over the world.
  The environment supports exchanging information on buts and bytes and, for all, the possibility to exchange pieces of software built by one company for other pieces. AUTOSAR (ARXML) makes this possible.

How can Rhapsody help?

That is not too difficult. Rhapsody has the AUTOSAR Profile. This allows you to read-in ARXML files and make them visible, graphically, in Rhapsody.

You can also edit the AUTOSAR model in Rhapsody. Or even create it there and export what you’ve mad to an ARXML file that can be read by an AUTOSAR Authoring Tool like e.g. DaVinci.

Here you can import any ARXML file. Rhapsody will import it (Remember: Use the 64Bit version to import, 32Bit is way too slow)

Another possibility to fill your AUTOSAR model is by using plain SysML or UML with the simplified AUTOSAR profile. This gives you stereotypes for the most used AUTOSAR elements. The M2M Tool will then synchronize your 2 views, the AUTOSAR view and the SysML/UML View.

In this way your models will always be up-to-date, wherever you make your changes.
The second step to use Rhapsody is then to generate code that can directly be used inside your AUTOSAR environment!

This picture shows the workflow. Mixing this with other tools like Simulink (even with co-simulation) is no problem!

Reverse Engineering

This allows you to use the code from your AUTOSAR Tool (Basic Software and other RTE functions) in your Rhapsody state-machines or functions.
In contrast to the previous Rhapsody Workflow (RIMBO and then link your Rhapsody App in the AUTOSAR code) this is the much easier way: Just use a few stereotypes and you can use the Rhapsody Code you already know (If you’ve used Rhapsody for non-Automotive environments) in an AUTOSAR environment.

Contact me if you need more information. I can arrange an evaluation version!

Happy driving with Rhapsody!

Walter van der Heiden (wvdheiden@sodiuswillert.com)