Model Based Systems Engineering delivers … a lot of promises. But at first glance it also promises a steep learning curve! Isn’t there a way to … “just get started with it?”

For those of you who have no idea what MBSE is … better stop reading and start learning about it … if you’re involved in system / product development somehow.

“MBSE => abstraction of systems => digitalization of systems”

Now I am no expert in this field, but it seems we (me and a team of clever engineers) have applied MBSE … by accident!

Reverse MBSE, as we call it, is a practical approach.  It starts with what you already know: the assembled and fully operational (part of a) system you just delivered.

Look at it: you should be proud on what you/your team/your company have achieved. A complex piece of technology making itself useful to humanity! No kidding. Engineers tend to forget what wonders they work.

And you’ve put it all together such that it meets the requirements?! Impressive! Now disassemble it all! And document how all the parts (let’s call them objects) relate to each other. And see if you can trace them back to a requirement.

How is that? Too much?! Too complex?!

Complexity’ is nothing more

than a lack of overview.

‘Complexity’ wasn’t an excuse to not built the system, was it? And to actually built a system, you need a level of detail that might scare you off … if you had known at the start.

Describing the system’s complexity requires a language to do so. SysML (System Modeling Language) is meant for that purpose. An overwhelming rich, accurate, graphical language. It needs to be rich, because there are many aspects involved. It needs to be accurate, because a minor detail can lead to a major system failure. It needs to be graphical, because human language is ambiguous and text is just too cumbersome. But you don’t need to use all of it.

Here’s 5 steps to an easy reverse MBSE start [note: you’d better start with something really ‘simple’]:

1. represent every physical component of your (sub)system as a SysML object with its name and properties.
2. if components are connected, draw a line between the corresponding objects; these are ‘dependencies‘
3. group the objects in packages, just like you group components to make assemblies
4. introduce a change (e.g. a product option resulting in a product variant) and repeat step 1-2-3.
5. See how it affects the model

You’ve probably had to make a few choices: what component belongs to what assembly. And you’ve probably found a few ‘dependencies’ that “just didn’t feel right.”

The (sub)system appears not so complex any more! Or maybe it does even more, because you came to realize the tremendous amount of detail and the dependencies between objects! You also know that if one of these details is ‘wrong’, your system will not operate as desired.

Already the (reverse) MBSE approach has delivered one of its promises: you’ve gathered a better understanding of WHAT your system is just by modelling it’s structure. The ‘HOW it works’ can be captured in a behavioural model. The ‘WHY it exists’ in a requirement model.

If you came this far and want to learn more, dig in to it! Ask a colleague (from a different discipline!) to join in; systems engineering is a team effort! And SysML is the team language!

If you want to get to the next level of engineering, you’d better learn more about MBSE. Just get started!

Note: the picture on top shows a logical model of a single AC-drive control system…. !!!