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.

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.

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.

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.

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.

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.

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?

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

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.

---

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

Happy modeling with Rhapsody! (You’ll get help soon!)

Walter van der Heiden ( walter@sodiuswillert.com )

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.

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.

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.

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.

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…

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.

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

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