In practice, it is already clear that the model-based approach promotes the modularisation of systems. Components and functions can be clearly structured and mapped in the model in a reusable way… more precisely than was previously possible with purely document-centric methods. Although modular construction kits were also used in the past, MBSE brings a new level of rigour and consistency. The big advantage is the common ‘language’ created by a central system model. Everyone involved – from mechanics and electronics to software and requirements management – works on the same model and therefore understands each other better. Different views of the same model also make it possible to understand complex products at different levels of abstraction: Stakeholders who are not familiar with the subject matter can use a simplified view to understand the overall system, while experts can delve deep into the details of individual components. This common foundation greatly facilitates cross-functional collaboration and prevents misunderstandings between teams.

‘The big advantage of MBSE is that everyone involved, whether electrical engineers, software developers or requirements managers, works with the same model and speaks a common “language”.

’This quote from one of our interviews sums it up: MBSE creates a common understanding and thus improves coordination across the entire development team.

Development processes in transition: from the V-model to agility

Classic development models such as the V-model remain relevant, but MBSE is noticeably changing how they are used. With all disciplines working more closely together in the model, design and integration are increasingly merging. In the past, development phases were often strictly sequential. First, extensive development took place, then separate verification and validation. Today, we are seeing much more parallel processes: validation steps are carried out iteratively during the design phase. The ‘V’ is becoming narrower, so to speak – development and testing are intertwined at an earlier stage. The early integration of simulation plays a particularly important role here. We can now model several concept variants and test them virtually in a matter of days, instead of just comparing them theoretically. This early verification in the model provides valuable insights into the strengths and weaknesses of concepts, which ultimately increases the chances of success for the chosen approach. Overall, the process model adapts dynamically to today’s requirements. MBSE helps to integrate more agile cycles into traditionally phase-driven processes without completely abandoning the reliable structure of the V-model.

Introducing MBSE in a company is more like a marathon than a sprint. We recommend proceeding patiently and step by step. MBSE represents a change in the entire development philosophy. This cannot be forced overnight. It has proven effective to first implement smaller model-based pilot projects or introduce MBSE in parallel with ongoing processes. This allows teams to gain experience without immediately turning the entire company upside down. Another good approach is to retrofit existing products or variants into models. This makes the advantages tangible: earlier projects serve as examples to convince internal stakeholders of the benefits of MBSE. It is important not to view MBSE as just another IT tool, but as a method for developing complex systems more efficiently. It takes patience. Depending on the size of the company, it can take years for MBSE to become firmly established in all areas. But the effort is worth it: in the long term, the improvements are enormous, for example through fewer errors, faster iterations and clearer communication.An interesting counterexample are start-ups, which often approach the topic with a completely open mind. We have met young companies that have been working exclusively with models from day one. Without historically grown processes and legacy issues, they rely directly on systems engineering with MBSE methods to develop complex products. These agile pioneers – often spin-offs from established companies – demonstrate how flexibly and rapidly MBSE can deliver results when you don’t have any baggage to carry. For large, established organisations, the transition is understandably more challenging! Here, established structures and processes have to be adapted, which requires internal persuasion and perseverance.

Regardless of industry or company size, one fundamental success factor for MBSE is clear: a powerful data management system. Without a central product lifecycle management (PLM) system or a comparable data platform, it is virtually impossible to use model-based approaches effectively. All model-based artefacts – from requirements to test specifications – must be consistently managed and linked. Without such a central ‘backbone’, MBSE initiatives quickly become bogged down in isolated island solutions. Unfortunately, many medium-sized companies are lagging behind in this area. Often, there is no established PLM system because they have previously worked with Office documents and file storage. We often find that it is only through MBSE that companies become painfully aware of how important a central data repository is. Companies that already have a good PLM infrastructure find it much easier because they can integrate MBSE models into it and immediately benefit from consistent data and complete traceability from requirements to product documentation.

Contrary to some fears, MBSE does not require completely new job profiles. Most companies already have the necessary experts in their ranks: system engineers, system architects, requirements engineers and similar roles. These specialists usually already have a foundation in model-based work – a mechanical engineer, for example, has been working with 3D CAD for decades, which is ultimately also a model-oriented tool. The challenge lies less in staffing levels than in mindset and collaboration: MBSE requires a shift towards cross-functional processes. Existing departments – whether mechanical, electronic, software or testing – need to be more closely networked. Disciplines that have previously operated in silos often have only limited insight into each other’s needs and contributions. For example, software developers or electronics engineers do not always see the big picture of the system they are working on. A common working framework must be created so that all relevant departments are involved and pulling in the same direction.

In many companies, we observe that informal knowledge transfer and familiar processes are a tough obstacle to the introduction of MBSE. The biggest ‘blocker’ is often the people themselves: a great deal of expert knowledge is stored in the minds of experienced employees and has never been formally recorded in models or documentation. With older products in particular, countless decisions have been made and changes made during development without everything being properly documented. Transferring this knowledge into MBSE models retrospectively is difficult. Some things are simply lost when the people involved are no longer available. In addition, existing processes or legacy systems often do not fit seamlessly with MBSE. We often have to start from scratch and build models from the ground up to create a consistent basis for future developments. This takes time and persuasion, but it is necessary to reap the long-term benefits of MBSE.

Despite all the initial difficulties, there are also quick wins with MBSE that can be realised relatively quickly. One clear benefit is improved data consistency. Thanks to the model-based linking of requirements, functional models, test cases and product structures, all information is coordinated. Changes made in one place are consistently reflected throughout the entire model. This minimises conflicting documents and saves a lot of coordination effort.

Even more significant is the new transparency in the development process. MBSE provides everyone involved with an up-to-date overview of the project status at all times. Instead of laboriously compiling information from various documents, the system model allows you to answer the following questions at the touch of a button: Where are we right now, what has been completed, where are the bottlenecks? Managers appreciate this clear visibility because it allows them to identify and address problems early on before they escalate. We have often seen that in traditional projects, someone manually consolidates reports to present the big picture. If information is lost or delayed in the process, the project can easily run into trouble. MBSE, on the other hand, provides a continuous, real-time picture of the situation. This transparency is a huge advantage, especially in large organisations. Technically, MBSE offers many benefits, but for management, the real-time overview is perhaps the most important.

‘The big advantage of MBSE is transparency – it shows the project status at all times and helps to identify and solve problems early on.’

MBSE is not tied to a single tool …

… on the contrary, different specialised tools have proven themselves in industry, depending on the task at hand. In medical technology, for example, there is a widely used tool that offers excellent traceability between requirements, tests and changes. Such systems are de facto standards in certain industries because they optimally support regulatory requirements. The downside is that these tools cannot be easily replaced or viewed in isolation. Open interfaces between the various systems are therefore extremely important. A model-based process must allow the integration of existing tools so that companies can continue to use the solutions that work best for them without sacrificing key functions. Closed, isolated solutions make little sense in today’s networked development world. We hope and expect that tool manufacturers will place even greater emphasis on compatibility in the future. Ultimately, MBSE should not be a monolithic software implementation, but a methodological framework that connects existing tools and data. In our projects, for example, we often work directly on our customers’ platforms to ensure smooth data exchange. This keeps all parties up to date, prevents information from being lost, and makes it much easier to involve additional experts or partners because everyone has access to the same networked information base.