Rhapsody TechBlog

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

Two people working with an IBM 704 computer at NACA Langley in 1957, one at the open cabinet, one at the card reader
NASA / NACA Langley, 21 March 1957. Public domain, via Wikimedia Commons.

From Prompt to Model: What I Told a Room Full of Engineers at WoTS

September 28, 2026 / / 0 Comments

Last Tuesday I had thirty minutes on the Embedded Software & AI stage at WoTS in Utrecht. Full room, everyone wearing those silent-disco headphones. The question I came to answer was not “will AI replace engineers” — it was something much more practical, and much more uncomfortable.

Here it is. You ask an assistant for a CAN bus monitor. You get 2 400 lines of C. It compiles. The tests are green. Nobody has read it.

Now explain it to the assessor.

“We generated it with AI and then we reviewed it” is not an argument. It has no volume, no depth, and no denominator. And if you work in automotive, aerospace, rail or medical, you already know that this conversation is coming.

We have been here before — and we were wrong before

I opened with 1865. British law required a man to walk sixty yards ahead of any self-propelled vehicle, carrying a red flag. Two miles per hour in town. The law stood until 1896.

But our own profession did exactly the same thing. In 1954, John Backus wrote that it was difficult to convey the strength of the scepticism about “automatic programming”. The objection was not that FORTRAN would take anyone’s job. The objection was that it could not possibly be as good as a human.

That is the same objection I hear today, and it deserves the same treatment: take it seriously, then check whether it is still true.

Two things that genuinely are different

I am not selling anything here, so let me be precise about what has changed.

It is probabilistic. Ask the same question twice, get two different answers. A compiler is deterministic. A generator is not.

It has no oracle. A compiler knows the rules of C. A language model has nothing to check itself against. It cannot distinguish a correct answer from a confident one.

Both of those matter enormously when the output is going into something safety-related. Neither of them is a reason to stay away. They are reasons to put something between the intent and the generated code.

The claim

This was the centre of the talk:

A model is a human-readable, machine-checkable statement of intent.

Code is what the machine does. The model is what we agreed it should do. As long as you wrote the code yourself, that distinction was fairly academic. The moment a generator writes it, the distinction becomes the whole ball game.

Take the same CAN monitor. As a state machine in Rhapsody: 23 states, 41 transitions. Readable in a review? Minutes. Traceable to a requirement? Directly. Those 2 400 lines of C: hours, if anyone really does it — and traceability by hand, if at all.

Two verification surfaces, same system. You get to choose which one you hand to the assessor.

Walter van der Heiden pointing at the slide Level 2 - the target is the model, not the text
Level 2: the same request, but the answer lands in the model rather than in a paragraph.

The reversal that surprised me

Most of the talk runs in the familiar direction: requirements → model → code. The direction I did not expect runs the other way.

You have code you did not write. Legacy, or generated four minutes ago. Point the assistant at it and have it build the model: states, blocks, interfaces, relations. Then you read 23 states instead of 2 400 lines.

Modeling stops being the preparatory work. It becomes how the AI shows its work.

How the assistant actually reaches the model

This is where it gets concrete for Rhapsody users. The assistant does not need to be a plugin, and it does not need to swallow your whole project. It needs a described, callable interface to the model — which is exactly what the Model Context Protocol gives you. Any assistant you already use on one side, your model on the other.

SodiusWillert have built exactly this for Rhapsody. Their AI Modeling Assistant for IBM Rhapsody — SAM — is an MCP broker sitting between the model and whatever assistant you prefer. It reads and writes Rhapsody elements directly: statecharts, activity and sequence diagrams, requirements, AUTOSAR profiles, code generation settings. You point Claude or GPT at it and it works on the actual model, not on a copy of your export.

It was built with Andy Lapping, Technical Fellow at SodiusWillert — the same man behind Power Pack and Profile Builder, who knows Rhapsody about as thoroughly as anyone alive. He has put together a video series that is worth more than any slide of mine:

And two write-ups from their side that cover ground I only had thirty minutes for: Practical AI in MBE, and How to create a system model from a PDF — which is exactly the “first model from a requirements document” I mentioned as something that genuinely works today.

And here is a side effect I did not anticipate: the model makes the assistant better, too. It works as external memory — the assistant does not need your forty-state machine in its context window, it needs the three states that matter. Long contexts degrade in the middle; a model lets you avoid needing one. And it works as a constraint, which is precisely what a probabilistic generator is short of.

An honest report

I put up a slide with what does not work, because otherwise you should not believe the rest either.

Works today. Building a first model from a requirements document — not the final model, but a structured starting point, in minutes rather than days. And requirements coverage analysis: which requirements does this model not satisfy? That one alone has found gaps I had missed myself.

Does not work yet. Context — it cannot see the whole model, large models have to be sliced, and slicing well is a real skill that nobody is teaching. And determinism: same prompt, different answer. Fine for a proposal you are going to review. Not acceptable as a build step.

Where that leaves us

The man with the red flag was not wrong that cars were dangerous in 1865. He was wrong about how long you keep walking in front of them.

My guess is that we are somewhere inside those thirty-one years. Not out in front with a flag, but not climbing in blindfolded either. Making sure there is something between the intent and the generated code that a human being can actually read.

The slides are here (PDF). There is a shorter, more personal write-up in Dutch on vanderheiden.blog.

Image at the top: an IBM 704 at NACA Langley, 21 March 1957 — the machine John Backus and his team were writing FORTRAN for, and the scepticism he described was about. Photograph NASA, public domain, via Wikimedia Commons.

DCUG Day 2026: The Dutch IBM Champions Are Gathering — and They Want You On Stage

August 4, 2026 / / 0 Comments

If you follow this blog, you know I spend most of my time deep inside IBM Rhapsody and Model-Based Systems Engineering. But there is a whole world of IBM technology and community around that — and this autumn a big part of it is coming together in Amsterdam.

On Friday, 2 October 2026, the very first DCUG Day takes place at the IBM Innovation Center in Amsterdam. DCUG stands for the Dutch Champions User Group — the Netherlands-based community of IBM Champions who share knowledge and enthusiasm across the whole IBM portfolio.

What to expect

A full day of content-driven, non-commercial sessions by and for the community, spread across four tracks:

  • Data & AI
  • Automation
  • Hardware & Storage
  • Cloud

Covering IBM priority areas from watsonx and hybrid cloud to IBM Z, IBM i, Storage and Power. It is the kind of day where you learn something new in every slot and bump into exactly the people you needed to talk to.

📣 Call for Papers — extended to 14 August 2026

Here is where you come in. The Call for Papers has been extended to Friday, 14 August 2026. If you are an IBM Champion with something to share — a real-world story, a technical deep-dive, a lesson learned — consider this your invitation to the stage.

Sessions are short and punchy: 25 minutes plus 5 minutes of Q&A, preferably in English. Send your title, a short abstract, your preferred track, session language and speaker information to the organisers (all the details are on the DCUG site below).

And yes — if your world is systems engineering and modeling, there is absolutely a place for that conversation here. The IBM ecosystem is broad, and cross-pollination is exactly what these days are for.

Join us in Amsterdam

Whether you want to speak or simply come along and connect, mark 2 October in your calendar. All the details, the full Call for Papers and submission instructions are on the DCUG website:

👉 DCUG Day 2026 & Call for Papers on dcug.nl

See you there!

🎸 Retired but Not Gone — and Rhapsody Plays On

April 13, 2026 / / 2 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.

The room in Paris where it happened

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

Jannie in Paris

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.

Paris in spring

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

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

October 16, 2025 / / 0 Comments

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

Mercury Rising

September 10, 2025 / / 0 Comments

AI Meets Rhapsody (and I Meet Welsh Hedgerows)

Mercury Rising: AI Meets Rhapsody (and I Meet Welsh Hedgerows)

Flying into Bristol, picking up a rental car, and immediately remembering why left-hand driving on narrow Welsh roads is… an experience. Destination: Usk, Wales. Purpose: work stuff that I can’t talk about in detail, but let’s just say it involved some interesting conversations about the future of systems engineering.

The drive from Bristol to Usk was like being dropped into an episode of “Escape to the Country” (which, yes, Jannie and I watch religiously). Rolling green hills, stone cottages, roads that seem designed for horses and carts rather than rental cars driven by confused Dutch guys trying to remember which side of the road they’re supposed to be on.

Welsh countryside aerial view

Every turn felt like I was about to meet a tractor head-on, or worse, scrape the rental car against one of those ancient stone walls. But somehow I made it to Usk in one piece, which is more than I can say for my nerves.

Mercury: When AI Meets Model-Based Engineering

Which brings me to why I’m really writing this post. While I was navigating those Welsh country lanes, my colleagues back home were putting the finishing touches on something we’ve been working on for a while: Mercury, our latest extension to Rhapsody.

Now, before you roll your eyes and think “Oh great, another AI thing,” hear me out. Mercury isn’t just AI for the sake of having AI. It’s AI that actually does something useful for us systems engineers.

Mercury AI in IBM Rhapsody

What Does Mercury Actually Do?

Simple version? You can write your requirements in natural language, and Mercury will generate a model for you. Not a perfect model—let’s not get carried away—but a decent starting point that you can refine.

Think about it: instead of spending hours creating class diagrams from scratch, you describe what you want in plain English (or Dutch, or German, or whatever), and Mercury gives you something to work with.

“I need a system that manages user authentication with role-based permissions and audit logging.”

Boom. Mercury creates the basic structure. Classes, relationships, interfaces. You still need to refine it, add the details, make it actually work—but the tedious initial setup? Done.

Rental car in Wales

Reverse Engineering That Actually Works

But here’s where it gets interesting (and where I stopped thinking about Welsh hedgerows for a moment). Mercury can also work backwards. Give it existing code, and it’ll create models and documentation.

You know that legacy system everyone’s afraid to touch? The one where the original developer left three years ago and took all the knowledge with them? Mercury can help make sense of it. It’ll read through the code, identify patterns, create UML diagrams, even suggest what the requirements might have been.

Is it perfect? No. Is it better than trying to reverse-engineer a 50,000-line codebase by hand? Absolutely.

Rhapsody reverse engineering

Requirements and Traceability

And then there’s the requirements side. Mercury can read your existing requirements documents (yes, even those Word documents everyone pretends don’t exist) and create proper traceability matrices. It can spot inconsistencies, identify gaps, even suggest test cases based on the requirements.

Remember those three-hour meetings where you try to figure out which requirements are actually implemented and which ones are just wishful thinking? Mercury can do a lot of that legwork for you.

The Welsh Connection

Sitting in a pub in Usk that evening (after successfully navigating more narrow roads without major incident), I was thinking about how both AI and Welsh country roads require a certain amount of trust. You have to trust that the AI understands what you’re asking for. You have to trust that the road actually goes somewhere and isn’t just going to end in someone’s back garden.

Pub in Usk, Wales

With Mercury, we’re not trying to replace systems engineers. We’re trying to give them better tools. The same way GPS doesn’t replace the need for a driver, but it sure makes navigation easier (even on Welsh country roads).

First Impressions

I’ve been playing with Mercury for some time now, and honestly? It’s promising. Not revolutionary—let’s not oversell this—but definitely useful. It’s like having a junior engineer who never gets tired, never complains about documentation, and doesn’t mind doing the boring setup work.

The model generation is surprisingly good for simple systems. Complex stuff still needs human intervention, but for getting started? It beats staring at a blank Rhapsody workspace.

The reverse engineering is where it really shines. I fed it some automotive code we’ve been working with, and it produced documentation that was actually readable. Not perfect, but readable.

StopwatchModel in Rhapsody

The Reality Check

Will Mercury solve all our systems engineering problems? No. (I feel like I say this a lot, but it’s always true.) Will it make some tasks less tedious? Yes, and that’s enough for now.

The AI hype cycle is exhausting, I know. Everyone’s promising that AI will revolutionize everything, cure diseases, solve world hunger, and probably make better coffee. Mercury has more modest goals: help systems engineers do their jobs with less tedious busy work.

And sometimes, that’s exactly what you need.

Pics or it didn’t happen

Well i have a movie? Does that count?

Create a model from almost nothing.

Back home

My flight left on saturday morning. Who needs weekend when he does amazing things… It was early but really cool. Great visit to Wales. “I’ll be back”!

Welsh countryside from the road
View from airplane window

Final Thoughts

Driving back to Bristol the next day (slightly more confident about the left-hand driving thing), I realized that both Mercury and Welsh country roads teach you the same lesson: trust the process, but stay alert.

Mercury will generate models and documentation that are mostly right. Your job is to spot where “mostly right” isn’t good enough and fix it. Just like driving those narrow roads—the GPS will get you close, but you still need to pay attention to avoid the stone walls.

If you’re curious about Mercury, drop me a line. We’re still in beta, still figuring out what works and what doesn’t. But so far, it’s looking promising.

P.S. – “Escape to the Country” makes Welsh property hunting look much more relaxing than Welsh driving. Trust me on this one.

Usktoberfest poster
Indian food
Airplane window
Train station
Restaurant dinner
Breakfast
Allo Allo dinner invitation
Fawlty Towers poster
Clifton Suspension Bridge in rain
Rental car interior

Have you tried any AI-powered engineering tools? What worked, what didn’t? Let me know in the comments below.

From the Depths to the Heights: Rhapsody SE and the Grand Canyon

August 30, 2025 / / 0 Comments

Every year in January I go to Phoenix (Scottsdale actually), for the yearly 321-Gang kick-off. Like last year, I took Jannie with me (i have a truckload of KLM miles to spend), and although I had to work, we had some free time to see some things. So we decided to go to the Grand Canyon. Yes, that’s quite a drive, but I like driving, certainly in the USA. Very relaxed there.

I’ve been at the Grand Canyon before—many years ago on a road trip from Minneapolis to Las Vegas. But that’s a story for another time.

The drive from Phoenix was nice enough—20°C and sunny (and no, I don’t use FreeDumb Units). But once we got up to the South Rim? Different story entirely. Way, way colder. Like, “why didn’t I pack better clothes for this” cold.

[Photo: Grand Canyon winter view - those layered rock formations]

Jannie was smart enough to bring proper winter gear. Me? Not so much. But hey, the views were worth the frozen fingers.

A Canyon of Perspective
(and Frozen Fingers)

Standing there at the rim, trying to take decent photos while my fingers slowly turned into ice cubes, watching the layers of geological history unfold in the winter light, I couldn’t help but think about layers of a different kind—the architectural layers we’ve been building in the new IBM Rhapsody Systems Engineering (Rhapsody SE).

The Grand Canyon has this way of putting things into perspective, doesn’t it? There I was, looking down at rock formations that took millions of years to create, thinking about how we systems engineers are always trying to manage complexity and time in our own projects. The Vishnu Schist at the bottom? That’s like our foundational architecture. The Kaibab Limestone at the top? Well, that’s probably the user interface everyone actually sees and judges us by.

But here’s where it gets interesting (and where my mind inevitably wandered back to work, because apparently I can’t help myself even at one of the world’s natural wonders)—the Grand Canyon makes all those layers visible. You can see the relationships, the dependencies, the way each layer built upon the previous one. And that’s exactly what we’ve been trying to achieve with systems engineering for… well, forever.

Enter Rhapsody SE
(From the Outside Looking In)

Which brings me to the real reason I’m writing this post. Now, full disclosure—I’m still an “old fashioned” Rhapsody Classic guy. Haven’t made the jump to Rhapsody SE yet. But I’ve been reading about it, talking to people who have tried it, and honestly? It sounds like someone finally listened to what we systems engineers actually needed.

[Screenshot placeholder: Rhapsody SE web interface - if someone can send me one!]

What’s Different This Time?

First off, it’s web-based. No more “Can you install this on my machine?” or “The license server is down again” conversations. You just… open a browser. Revolutionary, right? Well, for our industry, it kind of is.

But here’s the thing that really caught my attention: SysML V2 support. Finally! I mean, we’ve all been waiting for this for what feels like forever. It’s supposed to be like moving from a horse-drawn carriage to a Tesla. Sure, both get you there, but one makes the journey significantly more pleasant and efficient.

[Photo: Me looking cold but happy at the Grand Canyon - because why not?]

Of course, I’m still stuck in Classic Rhapsody land for now. But a guy can dream, right?

The Collaboration Game-Changer

Standing at Hopi Point (thankfully they had a heated visitor center), watching tourists from around the world gather to see the same incredible view despite the cold, it struck me how good collaboration really needs that shared perspective—that common view of what you’re all working on. That’s what Rhapsody SE is supposed to be all about.

In Classic Rhapsody, collaboration often feels like playing telephone. You work on your part of the model, export it, someone else imports it, merge conflicts happen, and suddenly you’re in a three-hour meeting trying to figure out why the state machine doesn’t match the interface definition anymore.

Sound familiar? Yeah, thought so.

From what I’m hearing, Rhapsody SE is supposed to change this. Everyone’s looking at the same “canyon”—the same live model, the same data, the same current state of the architecture. No more version conflicts, no more “Well, in my version…” discussions.

At least, that’s the promise. I’ll believe it when I see it, but I’m cautiously optimistic.

[Screenshot placeholder: Rhapsody SE collaborative interface showing real-time updates - anyone?]

Real-Time Everything

The Grand Canyon was carved by the Colorado River over millions of years, but today’s business environment doesn’t give us millions of years to get our systems right. We need real-time everything: real-time collaboration, real-time updates, real-time validation.

SysML V2 and other data and workflow APIs enable model-based integrations with downstream domains as cross-domain digital threads, boosting productivity and accelerating system engineering processes. This is the kind of integration we’ve been promising stakeholders for years. Finally, we can actually deliver on it.

The View from Here

As I walked the Rim Trail that day, moving from viewpoint to viewpoint, each offering a slightly different perspective on the same magnificent canyon, I realized that’s what good systems engineering is about—providing multiple perspectives on the same system, helping stakeholders understand the relationships and dependencies that aren’t immediately obvious.

Rhapsody SE feels like it’s finally giving us the tools to create those multiple perspectives without having to maintain separate models or worry about consistency. The solution supports systems of all sizes, from small projects to large enterprises, by providing layers of abstraction to manage different levels of detail and keep models clear and manageable.

The Verdict (From Someone Who Hasn’t Used It Yet)

Will Rhapsody SE solve all our systems engineering problems? Probably not. (Nothing ever does, really.) Will it make some of our daily frustrations disappear? Maybe. And after using Classic Rhapsody for over a decade, I’m willing to be hopeful.

The Grand Canyon took millions of years to become what it is today, and it’s still changing. Our systems engineering practices are evolving too, just a bit faster. Rhapsody SE sounds like it might be a significant step in the right direction—a tool that finally acknowledges that systems engineering is inherently collaborative and that maybe, just maybe, we should make that collaboration as seamless as possible.

Plus, it’s web-based. Did I mention it’s web-based? Because after years of Classic Rhapsody license server issues, that alone makes me want to try it.

Now I just need to convince management to let me play with it…

[Photo: Final Grand Canyon shot - the vastness that puts everything in perspective]

P.S. – If you’re ever at the Grand Canyon in winter, pack warm clothes. Trust me on this one. And yes, Hermit’s Rest still has the best coffee and least crowded viewpoint, even in January.

What are your thoughts on the evolution of systems engineering tools? Have you tried Rhapsody SE yet? Let me know in the comments below.

10 Jahre MESCONF

April 24, 2025 / / 0 Comments

MESCONF – Modeling Embedded Systems

Worum geht es bei der MESCONF?

Embedded Systeme sind allgegenwärtig; ein Alltag ohne diese intelligenten kleinen Helfer kaum noch vorstellbar. Wie man Embedded Systeme so baut, dass sie zuverlässig das tun, was erwartet wird, das steht bei der MESCONF im Mittelpunkt. Dabei betrachten wir insbesondere, wie Modelle helfen können, Architekturen, Systeme und Software zu entwickeln und zu verfeinern.

Warum solltest Du teilnehmen?

Der oft beschworene “Blick über den Tellerrand” kann
überraschende und wertvolle Anregungen bringen, wie
die eigene Projektarbeit verbessert werden kann.
Deshalb steht der Austausch von praktischen
Erfahrungen in konkreten Anwendungsbeispielen bei der
MESCONF im Vordergrund. Anwender berichten aus
ihren Projekten, und es gibt viel Raum, sich über das
Gehörte, eigene Ideen, Erfahrungen und Erwartungen im
persönlichen Gespräch auszutauschen.

Format der MESCONF

  • Fachvorträge
  • Diskussionsrunden
  • Workshops der Toolhersteller
  • Fishbowl

Warum gibt es die MESCONF?

Ganz einfach: weil Embedded Systeme heute derart komplexe Aufgaben
lösen, oft auch im Verbund, dass die Entwicklung extrem aufwendig
werden kann. Fehler werden spät entdeckt; deren Beseitigung ist
kompliziert und kann zu unerwünschten Seiteneffekten führen, und am
Ende laufen Kosten aus dem Ruder, und Liefertermine werden verpasst.

Visuelle Hilfsmittel wie Bilder sind hilfreich; noch besser sind Modelle!
Weil die Symbole eindeutig sind und nicht falsch interpretiert werden
können. Modelle können in Entwicklungstools bearbeitet werden, was
viele Entwicklungsaufgaben erleichtert.

Inhalte können überprüft werden, Source-Code, Dokumente und andere
Artefakte generiert werden, mit Hilfe von Simulationen können
Unstimmigkeiten frühzeitig aufgedeckt oder ausgeschlossen werden.
Missverständnisse werden minimiert, viele mögliche Fehlerquellen sind a
priori ausgeschaltet.

Was kann Modellierung konkret leisten und was ist dabei zu
berücksichtigen? Das „Modeling Manifest“ (http://mdse-manifest.org)
einer Gruppe von Experten ist ein guter Einstieg. Jedoch: was sich darin
einfach liest und logisch anhört, ist in der Praxis nicht in jedem Projekt
exakt so umsetzbar, und es stellen sich immer wieder neue Fragen.

Und genau deshalb gibt es die MESCONF, fokussiert auf diese Thematik.
Am 22. und 23. Mai 2025 treffen sich Experten und Anwender, um „Best
Practices“ auszutauschen, Ideen und Fragen zu besprechen und neue
Erkenntnisse zu gewinnen.


Rückblick auf die MESCONF 2024


Fachvorträge MESCONF 2024 (Auswahl)

  • Funktionsorientierte Entwicklung mit MBSE und Potentiale für den Einsatz von AI
    Jochen Epple, Mercedes-Benz, Anuschka Gummel, BHC
  • Game Changer SysML v2 und AI
    Tim Weilkiens, oose
  • Guided System Modeling und Übergang in die SW und E/E Domäne
    Johannes Trageser, SodiusWillert
  • SysML v2 in der praktischen Erprobung
    Samir Sarkic, Bosch


Workshops MESCONF 2024

  • Infineon: Model-Based Design (MBD) and Automated Code Generation
  • Mathworks: System Architecture Modeling of an Electric Vehicle with MathWorks Toolchain
  • Incquery: Model Governance für das Digital Engineering der Zukunft: IncQuery Validator Product Launch
  • IBM: Einstieg in die Modellbasierte Entwicklung – Welchen Einfluß hat die neue SysML v2 auf etablierte MBSE Methoden?


Auszug aus den Diskussionsrunden MESCONF 2024

  • AI-Assisted MBSE
  • Model-based requirements engineering
  • Text vs. Grafik aus Anwendersicht
  • Reviewing models — review management, results management, results documentation
  • Requirements in the loop — Verifikation von Anforderungen durch Formalisierung
  • Product-line engineering — ab wann sinnvoll, wo anfangen?
  • Impact analysis in models — how to make it work
  • Das Problem mit den UML-Komponenten in IBM Rhapsody


Hier gehts zur Agenda 2024

Ich hoffe viele von euch zu sehen auf der MESCONF!

Walter van der Heiden (walter@sodiuswillert.com)

10 Years of MESCONF 

April 16, 2025 / / 0 Comments

10 Years of MESCONF – Let’s Talk Models, Not B.S.

April 16, 2025 / rhapsody207 / 1 Comment / Edit

🎉 We’re celebrating 10 years of modeling, collaboration, and fresh ideas!

📅 May 22–23, 2025 | 📍 Infineon Campeon, Munich

Let’s cut to the chase: 2025 marks 10 years of MESCONF.

What started as a small prototype has grown into the go-to event for model-based systems engineering (MBSE) pros, tool nerds, process thinkers—and let’s be honest, all of us who just really like making complex stuff actually work.

Whether you’re a Systems Engineer, Architect, Tool Wizard, or just MBSE-curious, MESCONF is where the real conversations happen—with folks who know what they’re talking about, no PowerPoint fluff required.

💬 What’s on the agenda?

Classic expert talks? Yep.

Open discussion formats? You bet.

PowerPoint prison? Nope.

Pre-scripted speakers? Forget it.

The real star? Open Space.

Here’s how it works:

👉 Got a topic? Bring it.

👉 Others care? Talk about it.

👉 No hierarchy, no moderator—just smart people exchanging real-world ideas.

From SysMLv2 to traceability, simulation, tool integration, and yes—AI in modeling—Open Space is where the sparks fly.

🤖 My 2 cents this year:

I’m pitching an Open Space session on AI in modeling.

(And yes, I do say “AI” not “KI”. “KI” sounds like a technique for getting cows pregnant—no offense to the cows. 🐄💉)

On a serious note:

  • Where does AI actually help in MBSE?
  • Where is it just shiny nonsense?
  • How can we integrate smart assistance into our workflows without handing over the model to some black box?

Curious? Opinionated? Just want to argue a bit over coffee? Come join the conversation—I’d love your input.

🛠️ Why bother showing up?

Because modeling is how we wrangle complexity.

Because MBSE doesn’t have to live in an ivory tower.

And because MESCONF is one of the very few places where you’ll find open, honest, practical exchange without corporate smoke and mirrors.

🎟️ Spots are limited – sign up now:

👉 https://mesconf.de

🚀 10 years of MESCONF – let’s write the next chapter together.

See you in Munich!

Keep modeling – with Rhapsody or whatever gets the job done.

Walter van der Heiden

walter@sodiuswillert.com

Happy Modeling ( preferably with Rhapsody)!!

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

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

April 10, 2025 / / 0 Comments

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

Detroit Rhapsody Rock Units

September 2, 2024 / / 0 Comments

Introduction

For our US Automotive Day I flew to Detroit again! I really like Detroit, it’s way better than its reputation!
We organized a day after the German Automotive Day example. Our Marketing Guru, Tom Hollowell, discovered a racing track. It offered a great conference place and a race track where we were driven around.
No we were not allowed to take the wheel, unfortunately, but we were chauffeured by 2 professional racing drivers.
It was pretty awesome. We had just enough rides for everybody. Luckily, not everybody had enough nerves to go in a fast car around the track.
So I went twice… Loved it…

Rhapsody Units

There are still people asking what “Units” are in Rhapsody. And it is easy: it is the smallest “Unit” you can store in CM separately. Default units are:

  • Model
  • Package
  • Component

Units are easily ( if you have good eyes, that is… ) recognizable by the small icon decorator in the lower left corner. The decorator is either Grey (saved) or Red ( not saved). This indicates that Rhapsody will store that “unit” in a separate file. It allows it to be stored separately in a CM (That is mostly file-based). By right-clicking on a “non-Unit” element in Rhapsody, you can select “Create Unit.” This will give you the opportunity to store a Unit in its own file. The property General::Model::DiagramIsSavedUnit causes all diagrams to be saved in a separate file. In the same Subject::Metaclass, you can also find properties like BlockIsSavedUnit, ClassIsSavedUnit, and ComponentFileIsSavedUnit. There are also properties like ComponentIsSavedUnit (Default on), FileIsSavedUnit, and FolderIsSavedUnit. You will find ObjectIsSavedUnit and PackageIsSavedUnit (Default on) too. With these, you can control what is a Unit and what not.

The file extensions are: (add an “x” for the post 8.3 file format)

ElementOld < 8.3New > 8.3
Model.rpy.rpyx
Package/Profile.sbs.sbsx
Component.cmp.cmpx
Object Model Diagram.omd.omdx
Sequence Diagram.msc.mscx
Use-Case Diagram.ucd.ucdx
Structure Diagram.std.stdx
Deployment Diagram.dpd.dpdx
Collaboration Diagram.clb.clbx
Panel Diagram.pld.pldx
Timing Diagram.tmd.tmdx
Class/Object.cls.clsx
Did I miss one????????x


Ann Arbor

After the event I was invited by Tom and Carol to a dinner in Ann Arbor. A beautiful place, we drove around after dinner. (Thanks again! It was great!) Tom always posts sunsets on FaceBook… unbeatable.

Have fun modeling with Rhapsody

Walter van der Heiden ( walter@sodiuswillert.com )

« Older posts

© 2026 Rhapsody TechBlog

Theme by Anders Noren — Up ↑