Challenges and Practical Solutions for MBSE

|

As an MBSE enthusiast and Arcadia/Capella advocate for Obeo, I had the chance and opportunity to give several talks over last years:

These talks result from a large experience in MBSE deployments, notably over the last few years when supporting numerous organizations in their MBSE transformation. It also includes several feedback and best practices from the community, in particular from Thales which has fully industrialized this type of deployment in recent years.

With this blog post, my intent is to provide insights to people wishing to implement a Model-Based Systems Engineering (MBSE) approach. Without being a silver bullet, I hope you will find here food for thought to structure your MBSE projects.

The recommendations below are not specific to the Capella MBSE workbench and could apply to other methods or tools. However, it is obvious that the practical examples given are based on what I know best, i.e. Capella and its operational usage.

Obeo supported various organizations moving from a traditional document-centric approach to model-driven engineering. And while this step is still challenging and has a huge impact on company practices and organization, we saw a multiplication of operational usages and deep democratization of the MBSE. And this, for a wide variety of business areas and all sorts of companies.

In particular, we have identified more than 400 organizations worldwide that are using Capella. There is also an Adopters page on Capella’s website where organizations can publicly declare their adoption of Capella. Note that if you are not yet on this page, you can simply send us a request to be added.

 Identified organizations using Capella

Identified organizations using Capella

Based on this rich experience, we identified 4 solutions to address MBSE main challenges:

  • Really do MBSE
  • Do your MBSE
  • Manage cultural change (take care of people)
  • Implement and deploy

1. Really do MBSE

This first section comes from a common misconception of MBSE or wrong expectations from its added values.

MBSE

“Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.”

INCOSE SE Vision 2020 (INCOSE-TP-2004-004-02, Sep 2007)


Actually, people often only focus on using a model, assuming that since they are using a model, they are doing MBSE. That’s unfortunately not perfectly accurate, especially when forgetting that modeling has to support the system engineering activities.

So, there’s no magic about models and it’s crucial to keep in mind that the core of MBSE is System Engineering, as a discipline. For this purpose, let’s go over the main principles and added value of System Engineering.

 

Focus on designing and managing complex systems

With or without models, System Engineering provides methods and means enabling complexity management. It defines engineering processes, coordinates various disciplines, proposes complexity management strategies like building blocks decomposition, and so forth.

All those aspects remain valid in an MBSE context. Not only MBSE won’t substitute for all those good practices but the MBSE will be strengthened by a rigorous and holistic approach. Regardless of the exact processes or standards that will be applied, it is especially important at this stage to be aware of the approach that will be taken and to ensure that it can be supported by the foreseen MBSE approach.

ECSS-E-ST-10C Rev.1 – System engineering general requirements

 

Architecture as prime engineering driver

Similarly, the usage of a model is not a goal in itself. Project global objectives remain unchanged. It is always a matter of satisfying a customer, optimizing productivity, securing a development…

Nothing really new here but it could be quite important to remind team members or stakeholders that the model itself is of little interest as opposed to the use that is made of it.

 

Over Disciplines & Engineering Phases

To continue in the same way, System Engineering also consists of interdisciplinarity, complexity management through product breakdown strategy, etc.

Once again, it’s very likely that the MBSE approach had to support that. It is therefore not enough to just ensure that the language/tool/approach chosen will allow the system to be 'represented' but to ensure that the information can be properly used to support the system engineering.

In the example above, it could be concertized by the ability to represent information in different ways or provide specific analysis capabilities for different types of users and their respective interests. Or, it could simply be a means to generate a subsystem model from a system model.

Viewpoints in Arcadia methodology

 

Document-Centric to Model-Centric

Obviously, what MBSE will bring is a move from a document-centric approach to a model-centric approach. The whole or part of textual documents will be replaced by a model(s).

A few words about that:

  • First, model elements ARE requirements. Trying to maintain both a model and an equivalent document is certainly one of the best ways to waste time and energy.
  • However, this doesn’t mean that all requirements have to be modeled. Some like architectural or functional requirements easily find their place in a functional architecture model. On the opposite, there’s a bunch of non-functional requirements which don't need to be included in the model (such as business or regulatory requirements for instance). So, classical textual requirements and model requirements are likely to coexist. And it’s probably a good idea to plan a strategy to support that.
  • Finally, people often tend to exclusively associate system models with the representation of the solution. It would probably be useful to remind us that, before designing the solution, it is often interesting to first have a look at the need (which can also be modeled) to check the specifications you received are well-formed, ensure a common need of understanding, etc. So you probably won't have a unique model but, depending on the methodology used, several models at different abstraction levels.

 

 

Model-based engineering method

 

Not all models are equivalent...

At this point, you probably get the idea. Unfortunately, what we observe too often is that people tend to choose an MBSE language/tool focusing exclusively on the ability to represent the system architecture under design (will I be able to represent my system using this language/tool/method?). This is required but won’t be enough to fully support the engineering. It would probably be much more appropriate to start asking ‘will the language/tool/method I’m choosing support my engineering as a whole, including system engineering advanced practices?’.

To present it in another way, making a diagram doesn't mean you're doing MBSE. I have seen and I still see too many places and talks where people are just filling in a diagram. In my opinion, if there is no clear objective, no design decision, no usage of the captured information, then it might be interesting but it doesn't support the engineering.

Finally, the term model is very broad and can cover many things, many of which have little to do with systems engineering or at least are marginally related to it.

So, in a slightly different way, people sometimes tend to confuse MBSE and simulations. It’s a bit simplistic in my opinion. To be clear, I'm not claiming that simulation models are not useful. They have their place in the engineering process and complete an MBSE approach. I'm just saying that simulation models aren’t covering the whole engineering process, as I have tried to illustrate. So deploying something based exclusively on simulation models, which are probably very different from system engineering models, is probably a mistake.

 

Do your MBSE

This second section is covering another common mistake: to believe that there is a unique and common way in adopting MBSE.

We generally observe a full list of benefits in MBSE presentations. MBSE will improve communication, improve your quality, increase productivity, reduce risk… In a way, it may seem obvious that ‘applying’ MBSE (whatever it means at this step) is enough to benefit from all of that. Unfortunately, it doesn’t work like that. What people often forget to mention is there is not a unique way of doing MBSE and you will have to adapt for a specific context and a specific purpose.

So the very first step is to be aware of what could be improved in your context: in your company, on your projects... You may have recurring problems defining interfaces, inconsistencies in your customers' needs, want to introduce Product Line Management, or want to adopt an agile way of working. Whatever it is, what is important at this stage is to understand that each company has different issues. It may be related to its activity domain, its history, its strategic objectives, etc.

Once your pain points are known, you can define your objectives accordingly. They must be formalized and factual. At kick-off, it ensures that everyone is sharing the same objectives, both the technical team and the management. But above all, it is extremely useful during the project to keep the team focused (or remind your management of your initial objectives).

Finally, don't forget to monitor your progress along with the project and readapt if required.

 

It may sound a bit abstract but I'll take a few examples.

Note for the keenest readers, you will find many more examples in the documents listed in the appendix.

 

REX1: Common understanding

From Thales Germany: Thales return on experience: usage of Capella in bid phase of railway signalling projects

This 1s example is related to a bid preparation in the railway domain. Here, the problem is ‘simply’ to ensure a better understanding of the requirements and to homogenize and improve the quality of produced documents.

It’s a very classic MBSE use case. The model used as a single source of truth allowed to fulfill those objectives. It also allowed inconsistencies detection in customer requirements. And, above all, to win the tender!

 

REX 2: Interface Definition

From Rolls Royce: Arcadia / Capella for a large complex mechanical system

In this second example, the challenge is to develop an extremely complex physical system implying numerous systems and subsystems levels. In this context, the key element is to be able to create and maintain a coherent set of interfaces between all those components.

In such a case, features enabling to keep interface consistency and the ability to generate subsystem models from a system model are the key to manage complexity.

 

REX 3: Reusability and Product Line Engineering

From Continental: Driving Intelligent Transportation Systems with Capella

In automotive the challenge is quite different: you have to design your systems in a very short time. Meaning a few weeks or even a few days after receiving the customer's requirements.

To reach this objective, Continental decided to base its design on an advanced product lines strategy. Generic systems are pre-designed at 80/90% in a way that, when a customer request arrives, only 10/20% of the design remains to be done.

In this context, the MBSE key enabler is to support this product line engineering by enabling the creation and the reuse of those generic components.

 

REX 4: Products Engineering

From Thales Alenia Space: Arcadia and Capella: a value-added combination for Space products engineering

For the most advanced practitioners, several goals can be achieved concurrently.

In this fourth and last example, we observe a specific engineering approach per product family while ensuring an overall homogeneity in the design process and the produced artifacts.

 

3. Manage Cultural change (take care of people)

Another parameter that is unfortunately often underestimated is the impact of cultural change. Still, it has a huge influence on the success of an MBSE deployment.

This is a rather wide topic that I won’t detail in this article. Instead, I will just point to this excellent paper :

In my opinion, this is probably the most substantial and complete paper I know on the subject. It describes all the actions Thales took to support the cultural change brought by MBSE.

In a nutshell, you have to train and support your users. However, it’s not enough. You also have to obtain a strong involvement from them. In practice, this implies:

  • to share with them clear and useful objectives (for them),
  • provide them with mature tools offering added-value in their daily work,
  • keep listening to them and make your approach useful.

Here again, the key is to keep in mind the MBSE has to support the engineering (and not the opposite).

As a complement, it’s also extremely interesting to set up a specific organization enabling methodological support and coaching. Particularly by identifying so-called ‘modeling champions’ who can support and coach operational teams.

You will find an illustration of such an approach in this Ariane Group feedback. They set up a specific organization with particular MBSE roles per project and a central unit coordinating and supporting all the projects.

 

4. Implement and deploy

Last challenge: implementation and deployment, meaning tooling aspects. Because, at the end of the day, this has to work.

You will note that it is intentionally the last point I’m addressing (which can sound weird for someone working for a software vendor). That’s because the choice of your tool(s) and implementation strategy should be done only after a careful analysis of the previous 3 topics.

At this point, It can be interesting to take a step back and consider the reasons why the choice, and deployment, of an MBSE tool can be perceived as so difficult for system engineers. The paper below provides a very interesting analysis:

Let’s recap the main issues the authors identified:

  • People (or their organization) will implicitly maintain a document-centric approach. (see section 1 - Really do MBSE)
  • They will develop or acquire tools without taking into account their teams’ needs (see sections 2 & 3)
  • I will complete this point with two aggravating factors:
    • the 'not invented here' factor consisting of rejecting or denigrating any external solution
    • and the 'too big to fail' factor: for some political or any other weird reason, a company will continue to fund (very expensively) something which is not providing the expected service. And, besides, it will nip in the bud any other alternative (even those that work better, and are even cheaper)
  • And, after all, it’s so easy to blame a tool. Let’s say easier compared to really changing practices or making a real in-depth project post mortem analysis.

This is actually a pretty interesting analysis since it means that most of the issues generally associated with MBSE tooling can be avoided.

However, you still end up having to select and configure a tool or tools supporting your engineering! It’s not obvious because system engineers are not so familiar with IT. That’s not really their job.

Anyway, here are a few tips.

First, make sure that the features you need are supported. Supporting a language is fine but you probably need much more.

The good news is you probably already can do a lot of things using an existing tool (at least this is the case for Capella).

 However, this doesn’t mean you cannot adapt a tool. In the same way, you adapt your process and practices, you can adapt your tool. But once again, it should be driven by your objectives.

  • It can be related to system engineering practices. For instance, you may need to add specific properties or information, or have to generate sub-system models, to generate customized documentation, etc.
  • It can be related to the integration of the tool in a broader environment: connection with requirement management tools, PLM, or product line engineering.
  • It could be specific features required by MBSE like enabling collaborative edition of your models, version management or setting up task management, etc.

I insist, it will be your responsibility to establish what you really need based on your objective.

And here again, the good news is: it’s very likely that technical solutions already exist (either through open source components or commercial products). And, in the same way, there are service providers able to train and support your teams moving to MBSE, there are also actors like Obeo that can support you in the definition and operational deployment of your workbench.

But perhaps the best news is that such workbenches (and their successful deployments and usages on operational projects) are becoming increasingly common.

See for illustration the examples below from Virgin Hyperloop, Continental, and Stille AB, a healthcare company.

 

 

Conclusion

So, as a conclusion, if the deployment of an MBSE approach isn’t obvious and raises many challenges, we are now at a stage where MBSE is widespread and really supporting operational teams. Nevertheless, the last remaining challenge for newcomers is less purely technical than in the appropriation and adaptation of this approach.

 

Try Capella for free

 

Resources

 

Discover Arcadia & Capella

 

Cultural Change

 

Community

 

Tooling

 

REX

 

Others

 

|
capella mbse
Sirius Web Behind the Scene #4
L'analyse d'impacts avec ArchiMate

Related Posts