MBSE implementation: an overview

July 08, 2024

“No greater waste in doing efficiently something that shouldn’t be done at all”                                                                                          

(Peter Drucker 1970’s Business Guru)

From prior reading in the blog series, you know what systems engineering is and how it needs to be supported by MBSE models of all kinds to handle our product complexity.  However, implementing MBSE in your organization is yet another level of systems engineering, i.e. we are implementing MBSE inside yet another complex organization system that is in itself living inside a complex product market.  As such, we shouldn’t expect to step into our existing paper-based practices and get the productivity improvements we are looking for without making some organization and process changes. Yet that is what happens in many organizations leading to MBSE failures in organizations that just attempt to automate existing practices without considering whether those practices should be automated.

I grew up in a large family.  At one family get together sitting around the dinner table talking and my sister asks my mother, “Why did we have liver and onions every Thursday night for dinner?” My mother responded, “Your father loves liver and onions.”  My father replied, “I don’t like liver and onions, the only reason I ate it was because you loved liver and onions.” Mom already nodding her head, didn’t like it either and thus it went around the table discovering that no one in the family liked liver and onions, yet we had it for dinner every Thursday night.

Systems engineers are always asking the “why” question.  Systems engineering is about considering the many different aspects that impact the product and considering/trading off those aspects to achieve a product balance (a product that does what it’s supposed to do, in a cost effective way, that is safe, reliable, that works in its intended environment, and the list goes on).  Product development organizations are complex systems too.  If you attempt to implement MBSE without considering that, you shouldn’t be surprised you have built islands of automation that can’t communicate with each other, perpetuating the communication problem you hired the tools to solve.  This means that implementing MBSE isn’t a tool, but a journey.

As with any journey, first you need to know where you are before you make your travel plans.  Which is why we developed a practice of mapping organization MBSE maturity by understanding what technologies you are currently using to do the job of systems engineering (i.e. simple way to find out where are we).  Once we know where we are, we can plan a journey that can change your organization with a successful MBSE implementation.

So where are we…

We find out where you are by asking what technologies you are currently using to do the systems engineering job:

The first column of this matrix summarizes the things that systems engineers are supposed to do based on the standards (like ISO15288, IEEE 1220,…)  For example, systems engineers define the requirements, develop the product architecture, define the constraints i.e. parameters to be used, understand the impact of change, etc.   You could be doing those systems engineering jobs using a variety of tools, technologies and practices based on paper and models.

For example, looking at the requirements management row from left to right, you could be managing requirements using uncontrolled spreadsheets and documents, you could be managing them with controlled documents in a shared document repository, you could be managing requirements in stand-alone requirements tools (there a many out there).  As you move to the right across this row you’re moving from disconnected practices on the left to integrated practices on the right (remember we are after continuous integration) so as we move to the right, requirements begin to show up in places like inside CAD models or inside math models.  The most integrated practice on the right is requirements are part of the product baseline, so they are controlled like the rest of the product structures, tied to other things inside the product like parts, tasks, test procedures, change management, etc. enabling complete traceability to where a requirement goes when it changes.

To pick another example row, we manage interfaces because they represent the agreements between the silo’s (I’m going to deliver this content, that looks like this, at this time,…) that allows everyone to develop an integrate-able product. If we fail to deliver what we agreed, when we agreed to deliver it, we end up with an integration problem.  This is why all the bad things in a products life happen at their interfaces and why they are so critical (…and why my college professors said systems engineering is all about managing interfaces).  Today almost everyone uses interface control documents (ICD’s) to manage interfaces on the left while the advanced practice on the right involves defining interfaces by allocating functions (i.e. allocating functions to things that accomplish that function defines an interface, for example allocating the “stop vehicle” function to things that perform that action defines an interface between everything involved in stopping the vehicle).  If interfaces are included in the product baseline (level 5 thinking in the above matrix) they would carry interface knowledge throughout the product allowing you to see where a function is performed and where a function change goes (for example imagine walking up to a wire or hydraulic line and asking it what functions cross here).

If you’re down at level 1 managing interface in a document with no functional allocation (or even no functions defined at all), then jumping to level 5 capabilities is impossible, but we could start from where you are by taking a step to the right.  For example, you could import your ICD into Teamcenter and start managing individual interfaces as part of change, workflow, history, etc.  That step by itself is of incredible value and sets us up for the next improvement of reusable interface libraries to enable reuse, etc. and so our journey begins.

This incremental MBSE journey with little victories like interface capture, requirements impact understanding, trustworthy parameters used across an enterprise, focused testing vs testing everything when anything changes will provide little bright spots that everyone in your organization can see that will help motivate the organization thru the change needed to achieve the full value and capabilities of MBSE.


So how/where do you start your MBSE journey in your organization?  

We’ve done enough of these assessments in a wide variety of organizations and industries, that we have 95.6% confidence that you are an average organization (see above matrix).  Starting at the bottom of the matrix we can predict that you are using your PLM system to manage CAD models, that your test cases are managed outside of PLM, the various behavior models (math, behavior, Excel, etc.) are kept either on individual’s desktop or in GIT, requirements are managed in standalone management tools outside PLM, you are still using document based change practices, with many parameter repositories around your organization, with some functional architectures kept in documents, you use ICD’s to manage interfaces, technical risk in risk documents and spreadsheets, product-line variation descriptions in documents, and product architectures kept in Visio with some SysML modeling on some projects.

Tell me I’m wrong.

So we suck– what do we do about it?  Given where you are and based on our experience, we recommend starting with areas that you’ve already invested in over the years and focus on getting value out of that existing investment.  Requirements, parameters, test, and change management.  Start with your existing requirement repositories, do the meta-data mapping and co-exist them into your Teamcenter repository.  Once there you can link them up to things like parts, tasks in program schedules, manufacturing processes, etc.  This will give you requirement change impact you need to understand where things go now versus later.  With the requirements in place, let’s get the test cases imported and linked up with the requirements, after all tests are there to validate requirements.  This gives you the ability to do focused testing (testing only what is impacted by the change vs. testing everything, every time, since you don’t know where a change goes). You’ll want to get your parameters under control next since they are used in conjunction with the requirements. Imagine the value of a trustworthy enterprise parameter library (vs. hundreds of parameter repositories spread around your organization) that can be referenced into requirements, simulation models, etc. to minimize wasted time and money on the wrong versions of parameters being used across the organization.

These little victories will produce measurable improvements and provide evidence that integrated MBSE is worth the journey.  Those bright spots will help change your company culture needed to make MBSE stick by providing continuous feedback on where “straight ahead is” (see earlier blog on walking in circles).

Nature is ahead of us…

Turns out this is how nature gets everything to align…

You’ve been hearing about the current Cicada-geddon happening in various regions in the U.S. I grew up in Las Vegas with Cicadas almost every summer with their deafening buzzing. I didn’t think of it at the time, but all their buzzing noises were synchronized. Just like crickets chirping is synchronized, fireflies flash synchronized, and other things like your brain waves, heart rhythms, and more (just like we’re trying to get our organization’s development practices synchronized continuously).  Turns out someone noticed this behavior in fireflies and wanted to know how they chose a leader to start syncing with (suggest you read up on the science of synchronization or TED talk on the topic).  Turns out that fireflies don’t choose a leader, their flashing clock gets nudged in small increments every time another nearby firefly flashes eventually leading to all fireflies (and crickets and cicadas, brainwaves,….) triggering at the same time. Suggest you try out this firefly simulator to see how fireflies synchronize with each other even with disruption.  That’s interesting but imagine controlling it.  Check out controlling firefly firing with programmable LED’s.

Remember our goal is to synchronize whole organizations so we can be continuously integrated (start integrated, stay integrated), imagine applying this technique small victories to MBSE implementation.  Organization change comes with small incremental changes, little steps on your integrated MBSE journey, they will create bright spots that will nudge others around you to synchronize with you and over time synchronize the entire organization.  Teamcenter solutions support this and we can help you along this journey, just let us know.

In Summary…

So how do we move from disconnected silos where we are to this integrated SysLM…

Here’s how the practice works…

  1. Find out where you are in your MBSE maturity
  2. Pick out some short-term value projects to implement
  3. Attract attention with your small victory
  4. Repeat

…we will pick up back up on taking the next steps with a discussion on justification and some case studies over the next months. Please join us for the conversation.

Mark Sampson

Systems Engineering Evangelist.

It’s time to unleash your potential

Reach out to the team at Applied CAx to learn how our aerospace solutions can make your company’s goals achievable.