Rhapsody TechBlog

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

Tag: MBSE (Page 1 of 2)

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

Photo by Pixabay on Pexels.com

M2M Magic

March 25, 2021 / / 0 Comments

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.

MesConf in COVID times

August 31, 2020 / / 0 Comments

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 

And to India again!

February 25, 2019 / / 2 Comments

Introduction

I love India. Friendliest people on earth, awesome food, great country! So I was happy to go there again. I was there to do some support/training in a large project with many people. All in Rhapsody and all in C++.

The Trip

The disadvantage was that I would be in India for a week, so that would cost me two weekends traveling. So on saturday morning I got up at 6 (am -> the wrong 6…) and before 7. I was sitting in the train to Zwolle that was surprisingly filled. Now, that part of the trip went very well, apart from the early hour of course.
Step-over in Zwolle to Schiphol and I arrived there on time.
I love Schiphol, great airport. It is really big but you hardly notice that, everything is being signed out very well. As long as you speak English or Dutch you will not have any problems finding stuff (Eat your heart out Munich and Paris…)
Checking in took longer than usual since I found out I was not checking in at the normal KLM booth (Hall 1 or 1A) but in 3 with Jet Airways.
I booked KLM, as usual, but it was a code sharing flight. I’ve been busy last weeks (Wauw: Tell us more new things….) so I did not really had studied the flight data.
It turned out I had quite a funny flight. All flights were Jet Airways, not a single segment was KLM, luckily also not Air France… On the outgoing trip I first flew to New Delhi, then to Mumbai and then to Hyderabad. Not really efficient… There are many direct flights from DEL to HYD. But OK. It is what it is. Rebooking was not possible, all flights were full.
So I checked in, left my good old Eagle Creek Roller at the desk and went to the KLM Lounge.

First Leg

It went faster than I thought, I could hardly eat a small breakfast and then the screen said that the flight was already boarding. So I hurried to the plane, a Boeing 777 and quickly found my chair. A nice chair (Business class this time!!!) The flight left on time at 11:20 and it was good, Jet Airways is fine, nice staff and great food (Indian of course!!)
We arrived in Delhi on time and in the dark. Last time in Delhi I found out that there actually 2 airports in Delhi with the name “Indira Gandi Airport” Read “Incredible India”. This time I was OK (I thought…) because the connecting flight was in the same terminal. Even if your luggage is checked “through” (The label on the suitcase already contains all destinations) you still have to pick up your suitcase from the belt and bring it through customs and then check it in again.
With some trouble I managed to do that. I did not check the monitors on the airport so after going through security again ( Which was “Pedantic”… I had to completely unpack all my backpacks…) I started looking for the right gate. Just to find a monitor where my flight was indicated as “cancelled”. !@#$%^&*(
I started looking for help and at another gate with personnel from Jet Airways two ladies told me to wait, someone would come and sort it out.
Pff… But now I had time to organize an internet connection. That is not easy in India, there is “Free WiFi” but that works with a text message to your mobile phone. You first fill in your phone number, then you opt-in for some things and they will send you a Text Message with a code. Then you have to hack on your phone until the login screen comes again and give that code (with the phone number again, all very tiresome.
But that did not worked… I tried several times: no Text… Then I remembered that I am the new proud owner of an iPhone XS and that I have 2 SIM cards. The normal Willert Phone and my Dutch number.
So I tried it with the dutch number and: Bingo! a Text message and yes… I had internet. OK… only for 30 minutes… So I could FaceTime with home and then post on Facebook. Then I routinely checked my mail just to find 2 mails from KLM with a new Ticket and new Travel information… from hours before… So the cancellation was apparently nothing new.

Second Leg

Back to the ladies from the Jet Airways desk. Just when I did that the Manager appeared and started to speak with people who appeared from nowhere. With some pressure he looked at my stuff and organized some guy to escort me out of the secure area. He brought me back to departures where I tried to check in again.
It appeared my flight was now rebooked to Air India (?) at 7am (?) and directly to Hyderabad (!) OK. I would arrive an hour later than planned… that was doable.
Getting a ticket was not.. I went from booth to booth until I found a guy that was willing to help. He organized that my suitcase came back and that I could check in at the Air India Booth. he even brought me to the lounge (through security!) so that I could try to sleep a little bit. It was now 4:00 am and I still had 3 more hours…
No sleeping though… the lounge was noisy (Parents with small kids… really??) so after some coffee I went to the plane. This was again a 777, the business class was completely  empty. Shortly before take-off an Indian guy came in with lots of people around him. He was something important I think. the staff was crawling around him to bring stuff and wait for orders. Luckily they did not forget me (I was hungry…) and I was served breakfast. The Business Class was the widest I have ever seen. I had a huge place, the chair before me was really far away. A large screen was built-in but I could hardly see it. Not that I wanted, after breakfast I turned my chair into a bed and slept for the rest of the flight.
That went quite well. The Taxi from the hotel was not there (They had received my mail that my flight was cancelled) so after 25 hours I was in the hotel. Time for a nap..

Work!

I had the rest of the sunday to rest a little bit. I did not sleep long. First a phone call from the check-in desk… then a knock on the door from somebody that wanted to fill the minibar. Grr.
So I already prepared for the busy week. I had to support a project where many people work on with very different levels of Rhapsody experience. It is what it is… UML and certainly Rhapsody are not easy to learn. reading a book and do a 2 day training is not nearly enough to become experienced. Not even beginner level can be reached. It requires a lot of effort and patience to become an expert there.
For all it is learning the process of MBSE. It is very different from just hacking source-code. These are the questions that you should ask yourself on different levels of the development process:

  • WHAT must be done
    • We take Use-Case diagrams for that. Add Sequence Diagrams and/or Activity Diagrams to explain the requirements. This is the base for the planning on what the system does.
  • WHO will do it
    • This is the domain of the architectural Diagrams such as Class, Object, Package, Structure, Component and Deployment Diagram. They define the architecture of the system.
  • HOW must we do it.
    • Here we use Statecharts and activity diagrams, also flow-charts. Here we define the behavior of the system.

Of course this is not Waterfall anymore, we are agile! So we will iteratively go through all these phases until we are done.
This means that just creating a class as placeholder for a statemachine and just adding a state to be able to respond to events is not the way to use MBSE.
Objects have states, the light is on or off. Objects also move between states and not only from inner to outer states.
The secret to finding out what states we have is to use many, many sequence diagrams. They will clear your mind and give you the information needed to define nice small statemachines that are understandable and re-usable!

So. That was it from India. I’ll be back!

Walter van der Heiden (wvdheiden@willert.de)

Da Boston Broker

August 24, 2018 / / 2 Comments

Introduction

This week I’m in Boston at a customer that is starting a new project. I’m helping setting it up, setting up the model and the rest of the development environment.

In the beginning of our Rhapsody days, we were always happy to tell people we were the experts in “Systems with limited resources”. Now. in fact, we still are, just because we have a lot of experience in that area. I don’t think many people know how to handle the specific requirements of modeling in small 8- or 16bit systems with kilobytes of memory and microseconds to respond.

But slowly we have been growing with our customers and we also do larger systems. This week I helped setting up a “larger” system. This a “normal” PC with Linux on it, accompanied by a couple of other boards that do small tasks (and have smaller controllers!)

The use of Linux as operating system immediately introduced one big question: how are we going to implement a framework?
Linux has processes and threads. ( See BLOG entry ) Are we using a distributed framework? Or the normal framework with Threads?
Both have advantages and disadvantages. Distributed Framework is more difficult to implement but just threads will influence the way you can use your system and will not give you all the advantages of memory protection.

We decided to use both ways with a “simple” framework and use IPC to communicate. So we would actually use multiple applications that communicate with the use of the OS.
The trouble with IPC is always that you need some base information to start the communication. You can use a “zeroconf” system like Apple’s bonjour where every client starts and assumes it is the “Master” until it finds another client that already is the master. Or you create a Master that is known by all clients.

We have chosen the last variant. A Master-broker is in the system, waiting and listening on a fixed IPC Channel. Clients report to that Channel with their name and the Master sets up the communication. The client then opens up for its local clients to publish/subscribe that it will communicate with the Master-broker that registers all clients in the complete network. C++ makes a lot of this easier.

It was real fun to set this up. Most work was spend on setting up the development environment and describing how to use it. We use GIT and Sharepoint to do that.
The compiler/IDE is Eclipse in Ubuntu Linux, we deploy code to a shared directory with Windows. IPC on Linux is done with named pipes.

We spend some time setting up the Rhapsody model so that the package structure was logical and ready for use by multiple people. The model will contain a lot of components that must be built separately. Luckily you can tell Rhapsody to “build all” (which will generate and deploy all in our case) Eclipse can also build a complete project with multiple executables. We also built some test tools to test the Broker setup.

This is what many people underestimate when starting to use MBSE. The UML Tool will not do that for you. It is a UML Tool, UML is a language, not a process nor a development environment. It is very important to spend time setting that up and documenting it. Use a central documentation tool like Confluence, Sharepoint or MediaWiki, your success depends on it!

So… just work in Boston? Nope… in my 3rd Boston visit I finally had the time to visit “Cheers”, the bar of one of my favorite TV series.
I’ll end this one with a quote from Norm:

“Can I pour you a beer, Mr. Peterson?”
“A little early isn’t it, Woody?”
“For a beer?” “No, for stupid questions.”

“Cheers!” and Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

Using Rhapsody in vacation time…

August 14, 2018 / / 0 Comments

Vacation!

Hi! And sorry for the low BLOG frequency. It’s vacation time. Not that I am on vacation, that would actually mean I have more time to write… No, I am busy at the moment, others are on vacation which leads to more work and I have a lot to do  privately: I’m building a new house.
That is… I have other people build me a house… As I always say: I have two right hands but unfortunately I am left-handed… (BTW: Today August 13 is international left-hander day!!)
So I do not build but that does not mean my work is done… there is a lot to do besides physically building.
So we did not planned a holiday because the house should have been finished around this time….
“Should have been”?? Yep. It’s not.

When software projects go rogue and take longer than planned, one of the things people (non-involved people…) say is: “These software projects… always late… they should learn how to plan just like the people who build houses.”
Well…. That is just sooo not true.. building projects also go rogue. Mine does but others do as well.
Builders plan but the same way software people plan. So plenty of space for mistakes and “unknown”
In my case the architect designed my house with a CAD tool. Not a very advanced one, I am still waiting on a 3D view…, but that is how he did it. The guy is an artist and he draws beautiful houses. We were very enthusiastic about it and we even got the permission to build it from our community (Yes that is needed in the Netherlands)

There were a lot of prerequisites that we had to comply with, it had to fit in a certain part of our (own!!!) ground and it had to have a straw roof (To make it look like the other farms in the neighbourhood)
I did not want that, I wanted Tesla Tiles that create power, but hey…
So the architect draw the straw roof. The drawings of the architect then have to be enhanced by a constructor that knows how you build a house. Then the builder starts organising sub contractors to deliver parts.
It turned out when he ordered the roof that the angle was not steep enough. So the roofer would do it but with our guarantee.
So back to the drawing board and half a year delay (New permit, new calculations…)
So don’t tell me building houses goes better than building software…

So I asked myself: Would modelling have helped here?
I think so. The fact that a straw roof needs an angle of more than 45º is basic knowledge that should have been a design rule in the CAD program.
Moreover, I have not seen anybody work with a tool like Doors or Polarion to fix the house requirements. It is more advanced than the last time I built a house (1986) but it is with Mail, WhatsApp and Word that the house is built.

Back to Rhapsody

Vacation time is a good time to work on improving your Rhapsody models!
Sometimes customers ask me to do a review on a Rhapsody model. What do I do in a review?
It depends of course but for totally new models I do a couple of steps which I want to share with you:

  1. Check how old the model is. You cannot see it all but you can ask (..) and check if the model has CGCompatibilityPreX.Y Settings. They tell you the conversion already performed on the model (And the fact that the creators did not know what to do with it)
  2. Do a Check Model ( “Tools”, “Check Model”, “<name>” ) This should give you a lot of information about the model. Most common warnings are: “Default Names” and “Empty Description” but there are many more.
    The more warnings, the less precise the model is built
  3. Use Metrics to determine the number of elements in the model. Check for requirements, sequence diagrams and classes. There should be a fair number of requirements and a lot of sequence diagrams. unfortunately IBM stopped using the Metrics in 8.2. There is a more complicated system to still do it.
  4. Use the built-in document creator ( “Tools” “Report on model”, then select only “Include Overridden Properties” ) to look at the overridden properties. This should be limited to profiles.
  5. Do a general check.
    1. How do the names look? Consistent?
    2. How many packages compared to classes?
    3. Are there requirements used?
    4. Are there any Sequence Diagrams?
    5. Little number of properties is OK but not much
    6. What is the number of elements on diagrams. Yes that can be more than the “normal” 7+-2 but they should be understandable
    7. Are comments used?
    8. How is the diagram navigation?
    9. How many level of state-chart are there? One level or at most one sub-state-chart is OK. Everything else must be documented and proved necessary.
    10. Are model elements described in comment?

This is something that you can check yourself…. Do it sometimes.

Happy Modeling with Rhapsody

Greetings from Motown!

Walter van der Heiden (wvdheiden@willert.de)

MESCONF 2018

June 8, 2018 / / 1 Comment

Introduction

As every year we have organized our MESCONF (Modeling of Embedded Systems CONFerence) We changed the format a little bit, this year we have extended it to 2 days, the first day is just like last year with the difference that we have an evening session, the second day is “Tool Vendor Day” to allow Tool vendors to do a more marketing focussed presentation of their tools

Again at the fantastic Infineon location in Munich we had 80 people there listening to various presentations of experts and later some Open Space sessions.

The evening session with Nicolas Dierks the Philosopher was really interesting and shines a new light on our lives as developers.

panorama2.png

As usual we used “Open Space” to organize a big part of the MESCONF. Proven concept, since years we receive very good critics about it.

We spoke about lots of things that occupy modelers these days. One thing that returned in many meetings was the topic of “How to handle people who are refusing to model.”
A very interesting topic. Why are people refusing to model?

  • Some people just don’t get familiarized with modeling. Modeling is not easy, you need a lot of initial knowledge to apply it in the correct way. The only thing that helps there is train, train, train, coach..
  • Modeling is different from programming. Sometimes people who are real programming guru’s refuse to switch to modeling while they lose their “guru” status. It is difficult to discuss with them since they do not refuse consciously most of the time. they will use other arguments to refuse modeling and keep on doing what they do.
  • “Known hurts are better than unknown happiness”. A common attitude of most people is to stick to what they know until the hurt is really, really big. As long as people manage somehow to deliver their products using old methods they will stick to them.
  • “We don’t have time to repair the fence, we are busy catching chickens”. Most people are under stress and continue doing what they do because the stress does not allow them to step back and take the time to evaluate the used methods.

There is no “silver bullet” solution to that. The common feeling is that the world is leaning more and more towards modeling, partly because younger developers have less objections against it (Mostly they had it in school) and because the complexity is increasing faster. We also notice an increase in Rhapsody business. And that’s good!

OK, that’s it. Happy modeling with Rhapsody

Walter van der Heiden (wvdheiden@willert.de)

Engineering@Scale Tech Day

October 4, 2017 / / 0 Comments

Join us for Engineering@Scale Tech Day. Learn how new solutions and technologies are helping to lead the innovation agenda while addressing the complexity challenge in the automotive industry.

This event will focus on engineering systems and software development.  We will feature sessions around industry best practices and the core processes of requirements management, architecture design, collaboration, change and configuration management, test and quality management, product line engineering and variant management. Improve your skills, network and collaborate with industry experts.

What to expect:

  •  Keynote session by the American Center for Mobility
  •  Technical sessions for novices to experts, with topics ranging from:
    •  Scaling Agile to the Automotive Enterprise
    •  Convergence of MBSE and the Product Innovation Platform in Automotive
    •  Connected Product initiatives with Digital Twin and Digital Thread
    •  Improving your processes with Automotive SPICE
    •  Feature-based Product Line Engineering and Operations for the Automotive Enterprise
    •  Certifiable framework for AUTOSAR
    •  And more
  •  Networking Lunch (no charge)
  •  Plus, tour the spectacular automotive collection at the GM Heritage Center.

 Register today and share with a colleague!

General Motors Heritage Center
6400 Center Drive
Sterling Heights, MI 48312

Thursday, October 12, 2017 from 8:00 AM to 4:00 PM (EDT)

« Older posts

© 2026 Rhapsody TechBlog

Theme by Anders Noren — Up ↑