Rhapsody vs. Preevision

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 develop on different microcontrollers without really knowing all details.

Then there is the Operating system, which on the Classic Platform is almost completely statically defined and generated out of the information in your AUTOSAR model. Also called RTE.

There are several companies where you can purchase tools to help you create 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 previously 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 in 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 emphasis 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 had 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 Transformation for Rhapsody

Of course, linking information is ALWAYS better than synching information and we explain why in this article, sometimes linking is just not possible. Because of that, we have M2M Transformation for Rhapsody (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 the 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 on the same information.