Tag: Paris

🎸 Retired but Not Gone — and Rhapsody Plays On

April 13, 2026 / rhapsody207 / 0 Comments

So. It finally happened. And for a career spent living out of airports, I marked the occasion by doing the most gloriously retired thing I could think of: I took the train to Paris. No security lines, no gate changes — just the countryside sliding by, a coffee that didn’t cost eight euros, and absolutely nowhere I needed to be in a hurry. Retirement, lesson one: take it easy.

As of Wednesday, April 8th, I am officially retired — after 25 years with Willert and later SodiusWillert (to April 11th, if we’re being precise about it, and after this many years I’ve earned the right to be precise). A quarter of a century. That is… a lot of models.

There’s a lovely bit of symmetry to the timing, too. April 8th also happens to be Jannie’s birthday — my wife, who came along for the trip (that’s her in the photos below). So this year I gave her a slightly unconventional present: a full-time husband. She is being remarkably gracious about it.

And fittingly, I didn’t sign the papers at some grey desk back home. I signed them in Paris — a city that does endings and beginnings better than anywhere, with good coffee, better views, and not a single license-server error in sight. If you’re going to draw a line under a career, do it somewhere with a proper terrace. Highly recommended.

And before anyone starts writing the eulogies: I’m retired, not gone. There’s a difference, and it’s an important one.

Here’s what retired means for me: no more 6 AM alarms to catch a flight to a customer site. No more license-server tickets at 23:00 on a Friday (Classic Rhapsody veterans know exactly what I’m talking about). No more juggling five time zones in a single week. I’ve done enough of that — honestly, I’ve done plenty. It’s time for the quieter life: more time with Jannie, more time for the things I kept saying I’d get to “after this next project.”

Here’s what not gone means: I’m still here. Still writing this blog — probably more of it, now that I actually have the time. Still an IBM Champion, still knee-deep in Model-Based Systems Engineering, because you don’t spend 25 years loving this stuff and then just switch it off like a license server (which, again — IYKYK). You’ll still find me at DCUG Day, at TechXChange, at MESCONF, at ESE, at the conferences, in the community. Just… without the alarm clock.

Think of it as going from full-time to full-enthusiasm.

Meanwhile, the world keeps turning — Rhapsody 10.0.3

And of course, the field doesn’t pause just because I clocked out. Right on cue, IBM Engineering Rhapsody 10.0.3 landed — and it’s a genuinely good release, aimed squarely at large models and distributed teams. A few things caught my eye:

One-Click Environment Setup. Cygwin and the Rhapsody transforms installed in a single click, turning what used to be an afternoon of yak-shaving into a couple of minutes. Every new engineer who never has to fight that setup owes 10.0.3 a quiet thank-you.
A load progress indicator that actually moves. Small thing, huge relief. No more staring at a frozen-looking Rhapsody wondering if it died or is just thinking. It’s thinking. Now it tells you.
Zoom (100–500%) and type-to-filter in tables and matrices. If you live in the big traceability matrices like I do, this is the quality-of-life upgrade you didn’t know you were allowed to ask for.
Auto-generated flowcharts from legacy code. Point it at the old code, get operational flowcharts out. Anyone who’s ever inherited a mystery codebase will appreciate this one.

And then there’s the one that made me laugh out loud: 10.0.3 ships an MCP server — read access to your Rhapsody models via the Model Context Protocol, near-instant analytics, “Bring Your Own AI.” Now… where have I heard that idea before? 😏 Those of you who’ve followed my little rhapsodymcp.com adventures know this has been my personal playground for a while now. So let me just say: it’s wonderful to see MCP go official in the product. Great minds, and all that. I’ll be poking at IBM’s version very soon — retired hobby project, meet enterprise feature.

One more chapter

The best part of retirement, I’m discovering, is that curiosity doesn’t retire. I get to play with Rhapsody 10.0.3 purely because I want to, not because a project needs it by Thursday. That’s a good place to be.

So: thank you — to everyone at Willert and SodiusWillert, and to everyone I’ve worked with, learned from, argued about UML with, and shared a stage (or a beer) with over these 25 years. This isn’t goodbye. It’s just the start of a slightly slower, considerably more enjoyable, verse.

See you in the comments. And at the next conference.

P.S. — Yes, I’ll still answer your Rhapsody questions. No, not before coffee. Some things retirement will never change. And Jannie — happy birthday. Sorry the gift was me.

What’s your favourite 10.0.3 feature so far — and if you’ve stepped back from the daily grind but not the passion, how’s that working out for you? Let me know in the comments below.

Happy Modeling ( preferably with Rhapsody)!!

Walter van der Heiden
walter@vdh-informatica.com

Paris Code Generation.

September 29, 2019 / rhapsody207 / 0 Comments

Introduction

Lately I do a lot of my travel to France or via France. Of course we are now, as SodiusWillert, located in Bückeburg but also in Nantes (and in Detroit)
But that is not all France… I prefer flying by KLM and that comes automatically with Air France and the occasional stop-over in Paris CdG.
Not my favorite airport as my regular readers know.
But sometimes the flight is just more convenient or just cheaper via CdG.

Not this time, I actually had to be in Paris. Closer to Orly than to CdG so I decided to fly there. The KLM-Air France “El Cheapo” airline “Transavia” flies to Orly and it was really quite cheap. The reason for that became clear when I was sitting in the train to Schiphol: I received a text message that my flight was cancelled. 15 Minutes later an email arrived with my options:

fly on another day
fly to a different place
ask my money back.

neither of these options was what I wanted, so I called the Transavia Hotline. After 15 minutes of waiting (“It will come in time” – Billy Preston and Syreeta on repeat…) the call was answered and the train entered a tunnel… so after 15 more minutes I was again in contact.
“We are currently busy checking all passengers out”, “please call back in half an hour” she said. After some pressure she promised to call me back as soon as she knew more. Apparently she is not much smarter because she still hasn’t called me.

I already expected that and started calling after 15 minutes. The next call center person was not able to do anything for me, she said. I had to do that in Schiphol at the rebook desk in terminal 2.
In the meantime I arrived and went to the desk. I already figured out there were 2 flights with KLM-Air France to Paris. One in 45 minutes (do-able since I had only carry-on luggage) and one on 21:30 in the evening.

To cut a long story short, I had to visit 2 more desks to finally buy a new ticket (€ 600) to Paris because nobody could rebook my flight. Of course I had the late flight, missed the early one due to the slow response and the lack of information. And I was at CdG so the Uber took an hour instead of 10 minutes. Thanks Transavia!

Code Generation

But I arrived in Paris and had to speak the next day about Code Generation. I got the usual questions like:

“Why Code generation”
because it’s the only way. Everywhere you look companies are already very low on staff, programming takes longer and longer, offshore programmers do not really help since we have to increase the effort for specification. Having code generated from a good spec dramatically decreases the time needed to deliver good quality software.
If that is so then why doesn’t everybody uses CG?
We started selling Rhapsody with CG about 20 years ago. At that time there was no other tools that had CG. So sales people from all competitors would claim that CG was something nobody needed. A really annoying statement that is still haunting us (
We can just start by drawing pictures and then when we have learned UML we can try CG..
Sounds like a cool idea. But it isn’t. think 25-30 years back. The time where ‘C’ came up. People were all using assembler and considered ‘C’ as being difficult, ‘C’-compilers were “eating memory” and everybody thought that this ‘C’ thing would go over because it wasn’t useful. Maybe only for documentation (Sounds familiar?)
Now if you are using ‘C’ to document your code and you’d be programming assembler, what is the chance that you have learned ‘C’ after a few months? I can tell you: zero.
You learn ‘C’ by developing in it and observe the compiler telling you what you did wrong. And after that the debugging of your programming. Then you learn ‘C’.
Same thing with UML. You will learn that when you’ve seen and debugged the code. Not by just drawing pictures.
But UML is better for documentation isn’t it?
Depends. As said before, just using UML without checking if you have done it right only increases the work you spend. Don’t forget that UML is a language with a lot of redundancy in it. You have to do a lot of work to create seamless documentation. Then why not generate code from it?

So what does a good UML Code generator needs?

We have tried to create an external code generator before (For EA, maybe you remember) This was not very successful, partly because there was no real integration.
Also many people thought they could take their existing models and then generate code from them, which is, of course, never going to work since you can do a lot in a UML Tool that does not make sense for Code Generation.
You can generate code from the following Diagrams:

Class Diagrams
– Classes -> .cpp/.h (or .c/.h)
– pointers or embedded classes for relations,
– code for ports
State Diagrams
– State machine that is connected to a class. All instantiated objects have this state-machine
Activity Diagrams
– code for a Class, you can use a limited version to describe code for functions
Sequence Diagrams/Interaction Overview Diagrams
– Lifelines are classes (Instances but they have to be classes first)
– messages are events or operations. In theory it would be possible to generate behavior from Interaction Overview Diagrams.
Object Diagrams
– Objects are Objects/instances
– Links are assignments of object pointers to attributes
Package/Profile Diagrams
– packages can have code, they need to bring the “glue” code for instantiating and connecting objects. Profiles influence the generated code.
Composite Structure Diagram
– instantiates objects and connects them
Component Diagram
– knows the relation of Components and could generate “make” files that links the correct components

No code is generated from:

Usecase Diagrams
– Oh how we would love that, don’t we 😉 No, is not really possible. I would rather write something that generates code directly from requirements….
Deployment Diagrams
– Not really feasible
Communication Diagram
– Possible but who would want that?
Timing Diagrams
– That is also possible but we haven’t worked that one out yet.

So we established that one of the important things for Code Generation is the integration with the UML Tool.
This needs to guide you with the model so that code can be generated from it.
Also we need to directly show the generated code in a window in the tool. Feedback is the most important thing.
Roundtrip and reverse engineering are very important. We need to able to change the code outside of the tool in “our favorite editor”. Also we must be able to use legacy code in an easy way.

Generated Code must be understandable by developers
it must be efficient in code size and in run-time behavior
- at least as optimised as hand-written code
- must satisfy timing requirements.
it must fulfil safety aspects if used in safety-critical systems.
- code must be compliant with standards like MISRA
The generated code must be abstracted from RTOS/CPU and Compiler (The framework will do that)
it should not be unnecessarily dependent on other stuff

Up till today, there is still only one tool that does this way better than all others and that is Rhapsody. More than 20 years old and still going strong.

So. That’s it, have fun generating code with Rhapsody!

Walter van der Heiden wvdheiden@willert.de

Paris, Pense!

October 8, 2018 / rhapsody207 / 0 Comments

Salut!

Just back from Munich I was one day at home to switch my suitcase and get prepared for the next trip. This time a bit longer and further away but the start was in Paris.

I had to go to France anyway so I combined the visit with a visit to the Louvre. No not the museum, IBM organized the IBM Think! Conference there.

This was a cool conference, the only problem is that everybody spoke French and all the presentations (but one) were in French.

My French is not as sophisticatedly my German and English, unfortunately… but I managed. There were 2 presentations with fast and unclear speaking people where I really struggled to understand what they were telling, but most was understandable.

The one presentation that was in English was also the coolest (by far…) :

INFRASTRUCTURES ET PERFORMANCES
Aston Martin Red Bull Racing – Brian Jones, Head of Software Development

I think that at least 2/3 of the audience left the room, because it was in English…. Their bad because Brian had a cool story to tell about using big data in formula 1 to achieve an advantage on the competition. Very very interesting, thanks Brian!

At night there was time left to visit the Mondial, the Paris Auto Salon. A nice view on the new cars of today and new technology, very cool!

AUTOSAR

This was a nice “bridge” to the subject of today. The use of Rhapsody in an Automotive environment. We at Sodius and Willert are working very hard at creating solutions that will support automotive engineers to do their complex jobs as good and right as possible.

That is not easy, many OEMs and TIERx companies have very well defined processes and always a high degree of time pressure that makes it difficult for them to change anything in their daily work.

As Henry Ford already said: If I had asked my customers what they wanted they would have said: “A faster horse”. So you can ask your customer (and you should surely do that!) but you have to define your own way at least partly and then convince customers that your way is the better way.

Since using Rhapsody with Code Generation will already change a lot in the daily routine of everybody but certainly in that of the automotive engineer who already has defined run-time systems (that mostly use periodic tasks) The Rhapsody generated code assumes a preemptive OS that allows you to send and receive events and react to them if they appear, and sleep when there is nothing to do. This is a fundamentally different approach than the MatLab approach that even uses “polled” state machines.

This kind of programming is also much closer to the human way of thinking. Many people consider a polling, or synchronous, system to be more deterministic than an asynchronous system. It is not, asynchronous systems are much more scalable and run without collision much longer than synchronous systems. They also fit better in Object Oriented Designs.

Many Automotive systems are only doable when using synchronous systems. All Control Loops work way better and simpler when you do them in Simulink. But there are lots of systems that are asynchronous. Think about everything that is under direct user control, indicator, power windows, HVAC control panel etc. There is lots of asynchronous stuff in a car.

The more complex systems in cars use both synchronous and asynchronous components. The easiest and nearest way to solve them is by using MatLab. Now that tool really helps you to do the synchronous stuff and it also can do asynchronous stuff with no real penalty. So that prevents people from using UML for creating code in an automotive environment.

Now MatLab and its friends will not really help you to gain understanding and reducing of the complexity in new systems. UML/SysML will, they allow you to setup an understandable architecture. But the real benefit will come from using it to program the asynchronous parts of the application and use the code generation.

The funny thing is that most people do not want the code that is generated from a UML tool like Rhapsody but have no objection against code from a MatLab Simulink model.
It took me a while to figure out why but I think I understand that now. Simulink, used by a Systems Engineer generates just a bit of code that is the exact representation of the algorithm. Writing the code for that would be difficult, the formulas are mathematical things that everybody hates to remember and understand. To generate the code actually relieves you from a lot of extra knowledge.
Generating code from UML is not that easy, you need a lot of extra knowledge to apply that. So people do generally not like to use it.

Another big difference with MatLab is that Simulink Code is mostly used in continuous algorithms, the code is incomprehensible but the diagram is easy to understand. UML (and certainly Rhapsody) excel in discrete algorithms. There the diagrams are also relatively light to understand, as is the code, but the code needs some extra stuff around it to work. That is where people stop using it, it is just not straight forward.

So this is the big dilemma of the Sodius Willert developers, but I think we have some pretty good solutions to use mixed UML/Simulink/AUTOSAR environments. We have a very minimal framework that is easily to use inside an SWC, per ECU we only need one Framework, it can handle multiple instances. You can also import and export ARXML to be converted in stereotyped UML/SysML elements. We will present some solutions on several congresses in the next months.

We have experience in using UML in AUTOSAR environments, we have ASPICE experts on board, certainly in environments where certification is an issue (ASIL C or D) we have expertise and matching tools. And we can train you in using them!

SECollab

A nice opportunity to introduce the Sodius/Willert Tool SECollab (Systems Engineering Collaboration). This helps System Engineers to control all data that they use in their development process, they can make links to achieve traceability, use it for reviews (You don’t even need a license for the original tool to do that!) and derive documents for certification purposes.

SECollab is a server based solution, clients use Web Access, so no tiresome installation issues, just login on the website and access all information available (to you, of course!)

Take a look at it, if you like it, contact me for a demo!

Happy modeling with Rhapsody (and SECollab!)

Walter van der Heiden (wvdheiden@willert.de)