BLOG about IBM Rhapsody. Contains technical information as well as more private travel stories.

Tag: AUTOSAR (Page 1 of 3)

Automotive Day 2025 in Munich – And Yes, I Have VIP Tickets to Give Away!

So here we are again. November 4-5, 2025. Munich. The IBM Watson Center. And yes, before you ask: it’s that impressive glass building on Mies-van-der-Rohe-Straße, not some random hotel conference room. Think less “generic conference center” and more “wow, they actually built this.” With a stunning view on the Alps included.

The Automotive Day is back, and this time with something I’m genuinely excited about: AI that might actually be useful instead of just being AI for the sake of having AI buzzwords on a slide deck.

Why Am I Writing About This?

Fair question. Look, I’ve been to enough conferences to know the difference between “we organized some presentations and called it a day” and events where people actually want to be there. The Automotive Day falls firmly in the second category.

This year’s lineup? Professor Sören Auer doing a keynote on “Generative AI with Knowledge Graphs.” Now, I know what you’re thinking: “Oh great, another AI keynote.” But hear me out—this is about making AI work with actual engineering knowledge, not just spitting out random code that looks plausible but breaks everything.

The Good Stuff: Real Projects, Real People

Here’s what I’m looking forward to: experience reports from people actually doing the work. Volkswagen, Thomas Magnete, Marquardt, and MotorAI are all presenting. These aren’t theoretical talks—these are “here’s what we tried, here’s what broke, here’s what actually worked” sessions.

And we managed to get Baan Slavens, VP Product Management at IBM, to talk about the ELM Tools roadmap. If you’re working with IBM Engineering Lifecycle Management tools (and if you’re reading this blog, chances are you do), this is your chance to hear what’s coming and—more importantly—ask questions directly.

OSLC: Finally, Someone Explains It Properly

There’s a whole session on OSLC (Open Services for Lifecycle Collaboration). I know, I know, it sounds like one of those standards that IT departments get excited about while the rest of us just want our tools to talk to each other without breaking.

But this session actually covers the practical stuff: integration, authentication, reporting, and how to manage OSLC at scale. They’re even building a simple “link loader” during the session to show how it actually works. Actual demonstrations > PowerPoint slides every single time.

The Breakout Sessions

Here’s what makes the Automotive Day different from just sitting in a room listening to presentations: the Breakout Sessions. These are where you actually get to talk, share your experiences, and—this is important—complain about things that don’t work.

Every year, participants tell me the real value isn’t just the scheduled presentations. It’s the conversations during coffee breaks, the “oh, you’re dealing with that too?” moments, and finding out you’re not the only one struggling with that one particular ISO 26262 requirement that makes no sense.

Two new topics this year that I’m particularly curious about (but won’t spoil here—you’ll have to come see for yourself).

The Practical Details

Dates: November 4-5, 2025
Location: IBM Watson Center Munich, Mies-van-der-Rohe-Straße 6, 80807 München
Hotel Recommendation: Motel One München-Parkstadt Schwabing (walking distance, basically)

Pricing:

  • Early Bird (until August 18): €199 + VAT
  • Regular Price (from August 19): €269 + VAT

German language conference, by the way. If your German is rusty, don’t worry—half the technical terms are in English anyway, and everyone switches to English when needed.

And Here’s the Part You Actually Scrolled Down For: VIP Tickets

I have some VIP tickets to give away. How do you get one? Simple: send me an email. First come, first serve. That’s it. No complicated application process, no essay about why you deserve it, just… send an email.

The tickets are limited (obviously), so if you’re interested, don’t wait until the last minute thinking “oh, I’ll do that tomorrow.” Tomorrow never comes. Trust me, I know this from personal experience with my own to-do lists.

Should You Come?

If you’re working in automotive systems or software engineering, dealing with ASPICE, AUTOSAR, ISO 26262, or any of those other acronyms that make our lives interesting, then yes.

If you want to hear from people who are actually implementing this stuff instead of consultants who only know it in theory, then yes.

If you want to network with people who understand why you care about the difference between a component and a module, and who won’t look at you funny when you start complaining about tool integration issues, then definitely yes.

What Participants Said Before

Just so you know I’m not making up how useful this event is, here’s what people said about previous Automotive Days:

“It was a very interesting event, can gladly be longer!”

“Very helpful and informative!!!”

“Top event, great atmosphere, excellent talks and presentations”

“It was fantastic. Great location, very good presentations and high-caliber conversations”

“Informative presentations, good networking opportunities. Looking beyond the horizon into the domains of mechanics and electronics”

Final Thoughts

Look, I get it. November. Another conference. More travel. But if you’re going to spend two days at an automotive engineering event, this is the one worth attending.

Want to see what it was like last year? Check out the 2024 program booklet or watch the video retrospective.

And seriously, if you want a VIP ticket: email me now. Don’t bookmark this page thinking you’ll remember later. You won’t. None of us do.

See you in Munich!

Register here: https://www.sodiuswillert.com/de/events/automotive-day


P.S. The IBM Watson Center has great views from the upper floors. Just saying. Worth showing up early to check it out.

P.P.S. If you’re flying in, Munich airport is well-connected. The city center is about 40 minutes by train. Much better than… well, Las Vegas. (See my other posts if you want to know how I feel about Vegas…)

🚀 Implementing DDS in IBM Rhapsody: Real-Time Systems Engineering for the Future

As embedded and distributed systems become increasingly complex, ensuring reliable, real-time communication is no longer optional—it’s essential. That’s where the integration of Data Distribution Service (DDS) into IBM Rhapsody changes the game.

At SodiusWillert, we’re enabling teams to build smarter, more connected systems by combining DDS with model-based systems engineering (MBSE). Here’s a breakdown of what DDS is, how it works with Rhapsody, and why it’s a major win for industries like aerospace, automotive, defense, and industrial IoT.


🧠 What is DDS?

Data Distribution Service (DDS) is a middleware standard defined by the Object Management Group (OMG), designed for scalable, real-time, and reliable data exchange in distributed systems. It uses a publish-subscribe communication model—perfect for:

  • Autonomous vehicles
  • Aerospace and defense systems
  • Industrial automation
  • Internet of Things (IoT) and cyber-physical systems

Key features of DDS:

  • ⚡ Low latency and deterministic communication
  • 🔁 Decentralized architecture (no single point of failure)
  • ✅ Built-in Quality of Service (QoS) management for reliability

💡 Why Combine DDS with IBM Rhapsody?

IBM Rhapsody is a powerful MBSE tool for designing and simulating embedded systems. Integrating DDS into Rhapsody brings multiple benefits:

1. Real-Time Simulation & Execution

Model systems in SysML or UML and simulate live DDS-based communication within Rhapsody. Perfect for systems where timing and data flow are critical.

2. Seamless Distributed Design

Define DDS publishers and subscribers directly in your Rhapsody models. Automatically generate DDS-compatible code for distributed execution.

3. Earlier Testing & Validation

Simulate DDS networks inside Rhapsody before deployment to reduce integration risk—vital for mission-critical domains.

4. Industry Standards Support

DDS is a core part of frameworks like AUTOSAR, ROS 2, and FACE. With DDS integration, Rhapsody projects stay compliant and future-proof.



🔧 How It Works

Using the SodiusWillert DDS integration for IBM Rhapsody, here’s how the workflow looks:

  1. Model your architecture in SysML or UML using IBM Rhapsody
  2. Use SodiusWillert M2M to transform SysML to UML
  3. Apply the DDS profile in Rhapsody
  4. Generate DDS-compliant source code
  5. Integrate with your target DDS libraries
  6. Build and execute your DDS applications
  7. Visualize results directly in Rhapsody

This approach enables a full MBSE cycle from modeling to real-time distributed execution.


🌍 Real-World Benefits

Whether you’re building autonomous vehicles, avionics systems, or industrial control software, DDS in Rhapsody provides:

  • 📉 Reduced development risk
  • 🧪 Testing before hardware is available
  • 🔁 Faster development cycles
  • 🛡️ Improved system robustness and reliability

🔎 Learn More

Want to dive deeper into DDS modeling with IBM Rhapsody? Need help setting up your DDS development environment?

👉 Contact us at SodiusWillert for a demo or expert advice.


Based on insights from a recent LinkedIn post by SodiusWillert Deutschland, this article highlights our commitment to advancing model-based engineering with real-time communication support.

Happy Distributing with Rhapsody!!

Walter van der Heiden email://walter@sodiuswillert.com

Using MatLab Simulink with Rhapsody

Back in Nantes

Since we are together with Sodius I have my regular visits to Nantes. Luckily! I really like Nantes and of course my colleagues in Nantes. Always big fun and great to see beautiful Nantes.

Simulink

People still use Simulink; I’m always surprised that nobody objects to the fact that it generates code; people use it without thinking. When it’s Rhapsody, millions of objections pop up against Code Generation. Probably, it is because Simulink is used by all kinds of engineers and Rhapsody by Software Engineers who feel attacked in their honor by Rhapsody (That does an excellent job generating code,..)

Now, with the Automotive Extension, there is another way to integrate the two tools: ARXML. That’s a “lightweight” integration; it doesn’t add much. The real benefit comes from co-simulation, and that’s what Andy does in his video. AFAIK that still works (I do not own a Simulink license, I cannot try it)

Resources

Now, I could be explaining here how it works but other people have done that already, way better than I can.

Andy’s (old) video. Explains it really good.

Justin Dyer IBM explaining. A tiny bit newer than Andy’s video.

Frank Braun’s video. Great explanation!

IBM TechXChange Lab (Also by Andy, you need an IBM ID for that)

TechXChange

Coincidently I answered a question on TechXChange, about this, it seems the Library for CygWin is broken:

OK. Not so easy but it works:

Add to your configuration in the “Settings” Tab under: “Link Switches”:
"<<UserShare>>/LangCpp/lib/cygwinsimulinkintegrationapplx64.a"

(Replace the <<UserShare>> with the path to your UserShare directory.)

Then you need to build the Simulink library, the following files need to be placed:

– In the directory <<Share>>\LangCpp\SimulinkIntegration the file cygwinsimulinkintegration.mak

– In the directory <<Share>>\LangCpp\ the file cygwinbuild.mak

Then call “Code” and “Build the Framework” from the menu. there is 1 warning, you can ignore that.

You can also edit sitec++.prp and add the Cygwin makefilecontent with the changed linker statement. But this works too.

So. That’s it for today! Happy simulinking with Rhapsody!

Walter van der Heiden walter@sodiuswillert.com

M2M Magic

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

Rhapsody vs Preevision

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

AUTOSAR

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

AUTOSAR Menu


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

AUTOSAR Importer

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

Rhapsody AUTOSAR model

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.

M2M Workflow

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!

The AUTOSAR Workflow

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)

MesConf in COVID times

Hi All!

Our yearly MesConf will, like any other conferences, be held online. It is what it is.
There are some advantages too, no travel, no maximum number of people and you can show up how you want, just keep your camera off… 😉
it will be held on September 17 and we have room left for interested people.

There are interesting presentations from Prof. dr, Alois Zoitl (Professor for cyber-physical systems for Engineering and production), Stephanie Borgert (Speaker, Author and Furtherthinker) and Martin Reiss (Chief Software Architect from Thales railway)

Of course I will be there as well (Speaking about using AUTOSAR together with UML and SysML) and many more of the Experts from OOSE, SodiusWillert, SiSy, IBM and many others!

Screenshot 2020-08-31 at 14.21.26.png

Here is the website (in German! Try to open with google translate if you want to read it in English)

The main message is here:

The subject is too important. Therefore, we will not skip the conference due to the corona risk, but will convert it into a one-day online conference.

MESCONF focuses on the benefits of modeling in the development of embedded systems. Another thematic pillar of MESCONF is model-based systems engineering (MBSE).

Our world is becoming more and more complex and dynamic. The constant change is one of the challenges for companies. Successful are those companies that can react flexibly and quickly to the changing requirements of the market with high-quality products.

We are convinced that modeling makes a crucial contribution to achieving this ability. We have formulated our values and convictions in a manifesto. At the conference we also want to talk and discuss the manifesto.

Tickets can be bought here at Xing.

I hope to 

Berlin #100

Intro

It is not only work… After a lot of work and travel it was time for a short break. For some time now I promised my sons to take them to Berlin and finally we managed to find the time.
First we drove to Bückeburg by car to stay at my apartment, the next day we would leave early to catch the train to Berlin. As I have found out a car is useless in most big cities, there is perfect public transport and parking is nearly impossible and costs a fortune.

100

This is BLOG # 100! Never thought 2 years ago that I would write 100 articles! This year also KLM (my favorite airline) celebrates 100 years, congrats!

Police

First we had to overcome some police activity. As soon as we crossed the border a fast BMW overtook us and a sign came up “Police, Follow”. I thought that would be a border control but it turned out I had forgotten my MOT for 1,5 years… In the Netherlands they send you an email when it is due but in Germany they don’t….
Also my tires were “Formula 1 ready” So I had some explaining to do. Luckily the police man were quite understanding, they soon figured out that I did not do that on purpose and they let me go with a small fine and the promise that I would take care of it.

Train

Trains are cool in germany. If you book on time and stick to a certain train you can travel quite far for a small amount of money. We even had first class seats. It was a nice drive and it went very fast. Impossible to match that with a car.

Hotel

The hotel was right next to the central station, perfect to use as a base to sightsee Berlin. The room had bunk 2 bunk beds but Robbert volunteered to sleep “upstairs”. Further it was not large but we were not there to enjoy the hotel room, but clean and the breakfast was good.

Berlin

Time to hit the city. We did the usual stuff, Parliaments building, Brandenburger gate, Jewish monument, Checkpoint Charlie etc.
On Wednesday a friend who was born in East-Berlin, showed us around in the eastern part, very very nice. We had lunch in the TV Tower (207 meters high) Also we saw the largest part of the Wall that is still there.
The next day we took the metro to see some other stuff like the Karl-Marx allee and much more. Berlin is very very nice. After every corner there is a reason to visit the city again. This month also is the celebration of 30 years since breaking the Berlin Wall.

AUTOSAR Workflow

Being without a car still cannot drag me away from AUTOSAR. We now have quite a nice AUTOSAR workflow.
You can start with SysML and then use M2M to create an AUTOSAR model, export that to an AUTOSAR authoring tool, add some more information and even use Rhapsody to implement AUTOSAR compliant SWC’s that contain statemachines.
You can also start with ARXML from a third party, read that in, use M2M to create a SysML model (Or UML) and the create your architecture there.

Back Home

Finally we had to return home, or at least to Bückeburg by train. Really tired (we walked more than 40 kilometer…) we hit our beds. On Friday I kept my promise to the policeman and went to the TÜV for a checkup. 2 days later the Dutch garage would switch my tires to wintertires. All is OK again.

Happy modeling with Rhapsody!

Walter van der Heiden

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 )

Back in Hyderabad, India

Introduction

Sorry, hardly time to write these days. We are having long days to use the week as effectively as possible. And then there is the time difference… If I am finally done working the US is just waking up and full of energy looking at projects.. My home city is preparing for dinner… But lets not complain. I will write more about India later, first I want to write something about the (near) future!

Embedded World

We are back at the Embedded World!! Yes finally. Not as big as before, we don’t see the point in having a huge booth anymore, a small one will do as well. We cooperate as before but now with OOSE (and with Sodius, of course)!
The Embedded World will be in the “Messe Nürnberg” from February 26-28. We are in Hall 4, Booth 4-150. We have Coffee….;-)

The motto will be:

EEE

(Engineering Efficiency Empowerment by seamless integration of Process, Methods and Tools)

The ability to collaborate across disciplines is the key success factor in product development. In today’s engineering processes we see a multitude of heterogeneous systems, which should fulfill the demand for integrated systems. We use requirements management tools, ALM / CLM / PLM solutions, modeling tools, department-specific tools, quality analyzers, just to name a few. All equipped with interfaces for integration or collaboration with other tools. Nevertheless, it is always a challenge to pass data loss-free from one discipline to the next. It is even more difficult when data is to be exchanged across company boundaries. Because often only a filtered subset of data is exchanged, or different standards or tool versions are maintained.

Willert, oose and Sodius cooperate with the objective to support you in the optimization of your processes and engineering methods and to ensure a valid data flow between the departments. Willert contributes its expertise in embedded and systems engineering. oose contributes its expertise in process and method consulting. And with SECollab, Sodius offers a tool for visualizing and processing engineering data from a wide variety of tools and disciplines.

Our Offer

On our booth on the Embedded World in Nürnberg we offer you a free, 30 minutes analysis and evaluation session of your current situation at our stand and give suggestions for improvement directly.

Use the expertise of Andreas Willert and Tim Weilkiens at our booth Hall 4 – 150 on 26. – 28.02. in Nuremberg. A maximum of 8 slots are available per day. If you want to be sure of getting a slot, make an appointment before the fair with Mrs. Willert: swillert@willert.de (Tell her I sent you…)

Of course I will be there to answer Rhapsody questions live!

We will gladly send you an admission voucher for the fair. (Sorry, the pictures are in german, they should be understandable. When I have the source I will translate them)

1st step: rough process definition

Grobe_Prozessdefinition

2nd step: Precise definition of the work steps

Praezise_Definition_der_Arbeitsschritte

Our lectures in the forum at Embedded World (Hall 2 – Booth 510)

Efficiency in engineering through seamlessly integrated processes and tools

Andreas Willert and Tim Weilkiens in German – 26.02. / 11.30 – 28.02. / 11.00 clock

A consistent environment reduces the obstacles on the way of developing artifacts from idea to product. Organizational, methodical and technical process breaks require more effort and at the same time lead to information losses and increased risk. We will show you how to develop benefit-oriented process steps and how to derive and implement the necessary seamless integration of tools.

 

Modeling the “Standards” Way

Walter van der Heiden in English – 27.02. / 10:00

In various standards we can observe common themes of abstraction, specialization, refinement and relationship (traceability). Aligning the value of these standards and easing the adoption is the most effective way to improve and realize success in an organization. We have applied a SysML for Systems Engineering, AUTOSAR for Vehicle Design and Software Architecture, and UML for Software Design and Implementation. Using high quality UML tools and simply targeted bridges, engineers can focus on their designs and models for developing their solutions. We want to demonstrate SysML models that transition to AUTOSAR designs, that are moved to implementation designs (in UML or Simulink), and finally code generation. All the while maintaining simple bidirectional traceability and design artifacts demanded by ASPICE.

 

That’s it, Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

 

« Older posts

© 2026 Rhapsody TechBlog

Theme by Anders NorenUp ↑