Is There a Conflict Between Model-Based Systems Engineering and Modularization? 

Recently I received an interesting question from one of my colleagues within Modular Management. A customer within the automotive industry was exploring Model-Based Systems Engineering (MBSE) for their vehicle product line to gain a centralized repository of requirements and a single source of truth.

Within our organization, we often refer to PALMA as the preferred single source of truth for sharing requirements between the company’s various functions when implementing or managing modular systems. Since both systems are aiming to implement the same thing, might a conflict exist between MBSE practices and Modularization (and PALMA)? The short answer, spoiler alert, is that there isn’t a conflict between these two practices.

In my previous role as the Chief Engineer at ABB, I was involved in a large-scale attempt to model a complex system using MBSE practices. With my experience implementing modularization with PALMA, there isn’t a conflict between these two solutions. Let’s dig into why this is to eliminate any confusion on the topic.

In this forum I will try to explain:

• What problems does MBSE try to solve?
• What problems does Modularization try to solve?
• Personal experiences of implementing MBSE for an extensive modularized system.
• Essential factors to consider before going down the rabbit hole of MBSE.

With that said, let’s start by understanding MBSE.

What Problem Is Model-Based Systems Engineering Trying to Solve?

The primary assumption in MBSE is that projects fail due to a lack of correct requirements understanding and that solving the failure-related issues downstream costs up to 100 times more once the product has been launched to the market. To learn more about these costs, check out the blog Everyone cites that 'bugs are 100x more expensive to fix in production' research, but the study might not even exist.

While putting an exact figure on the costs associated with repairing an existing product on the market might be hard to quantify, it is unquestionably easier to build, for example, a warship with the correct length, height, and width for the number of guns required from the beginning, compared to discovering by the time of the maiden voyage that the number of guns was too many for the ship to handle. This was the case for the famous Vasa warship that sank on August 10, 1628, in Stockholm on its maiden voyage of just 1300 meters, still within sight of the shipyard where it was built. The sinking was a massive fiasco for the king of Sweden, cost many sailors’ lives unnecessarily and sent shockwaves through the Swedish empire (read more at vasamuseet.se).

The flaw of the Vasa was known from the validation phase, when Söfring Hansson, the captain supervising the construction of the Vasa, had thirty men run back and forth across the deck, making the ship roll alarmingly.

If computers and MBSE had been around in the 1600s, all construction data could have been put into a domain model to represent the system visually. This data could then have been shared in the system requirement, design, analysis, verification, and validation activities involved in building the ship.

Today MBSE is a technical approach to systems engineering that focuses on creating and exploiting domain models as the primary means of information exchange rather than document-based information exchange. This approach helps to overcome the challenges posed by complexity in systems engineering by making relationships between different parts of the system easier to see and manage.

Figure 1. MBSE promotes using a domain model for information exchange instead of a document driven approach.

If such a model as this had been available when building the Vasa, it would have been clear to everyone involved in the ship construction that conflicting requirements needed to be resolved. Solving these conflicts while still in the design phase would have cost much less, would have been much faster than trying to do the same thing in the validation phase, and ultimately could have saved the Vasa.

The takeaway of this story is that everyone should have access to the same data when making decisions, and MBSE is a method to provide the data. MBSE requires that a domain model satisfy all requirements in order to identify any potential issues early in the development process.

What Problem Is Modularization Trying to Solve?

Modularization decreases the overall costs for products over the course of its lifecycle. The economies reach the development stage throughout the supply chain and service phase. Another key benefit to modularity is that manufacturers employing this methodology can release new products to market faster as they satisfy market demands. These benefits are achieved by maximizing reuse, planning for where design variations occur, and anticipating rapid development change.

The use of strategic modularization enables the categorization of modules into one of three categories:

• Modules that maximize reuse would be classified as “Operational Excellence” category.
• Modules that require variation for the product to fulfill differing customer needs would be classified as the “Customer Intimacy” category.
• Modules that are core to the company, the product performance and need high speed of innovation would be classified as the “Product Leadership” category.

If these three categories were applied to the Vasa example from above, the cannons would have been considered Product Leadership modules, and accommodating various sizes of the Vasa ship would have been considered Customer Intimacy modules. At the same time, it would have been an Operational Excellence ballast calculation to keep her stable.

Since variance in sculptures was important at this time in history, a high variation of these modules would be necessary. As a result, the ship builders would have included Customer Intimacy modules driven by strong styling module drivers.

Figure 2. A model of the Vasa ship as she looked at the time of launch. Photo by Unknown Author is licensed under CC BY-NC

Full Product Visibility with PALMA

To manage the many stages of a modular product system, we recommend the using PALMA, a software solution for product and requirements management. The key focus of this feature-rich tool is tracking a module system. With a 360-degree view of the product, stakeholders can feel more confident in introducing new module variants based on the profitability of the entire module system. This method eliminates sub-optimizing customer requirements that may not be profitable enough to justify the introduction cost of a new module variant. In many ways, this approach is like MBSE, where a single source of truth is created by an information model instead of using a document driven approach.

Figure 3. PALMA promotes moving from a document driven information exchange to using an information model

The complexity cost of a module and its module variants are calculated from production, sourcing, and engineering costing data and split over the entire module system. The cost and profitability of different product configurations can be calculated for each configuration, and decisions on costs can be made based on the whole configuration and not on individual module variants.

For example, oversizing one module variant may be more profitable to make it suitable for the entire module system instead of introducing several cost-optimized module variants for each configuration. The reverse could of course also be true where manufacturers optimize one high-volume configuration and introduce variants to cope with other, less frequent configurations. In either situation, decisions are made based on the cost of complexity of the module system rather than on limited insights leading to sub-optimizations of the product.

Given the Vasa example, PALMA could have been used to calculate which hull would be best fit the number of guns required while providing an accurate product cost estimate quickly that could have been compared to the initial configuration. By using PALMA, the shipbuilders would have known the timeline for completing the planned module variants and the different product configurations early in the planning process. This valuable insight during the planning phase of the module system would have enabled reprioritization to accommodate the king’s configuration requests.

While both PALMA and MBSE are trying to be a single source of truth, modularization is solving a different problem than MBSE, and the approaches could complement each other.

Could a Module System be Documented in MBSE Tools?

Given the comprehensiveness of the available MBSE tools, one could consider documenting the module system directly in the MBSE tool instead of PALMA given that both systems rely on information models instead of documents.

This is an option, but since the primary purpose of MBSE tools is to keep track of requirements and ensure they do not contradict but not necessarily solve the profitability aspect of a module system, chances are that this benefit would be lost.

While PALMA keeps track of all module variants in a module system, it is not a complete requirements management system. MBSE tries to be both a central source of truth but also a complete requirements management system. It even tries to include simulation in the tools to visualize the system behavior early in the development process.

Some promoters of MBSE would attempt to document everything in the MBSE tool and abandon PALMA, arguing that all it takes is an improvement of the domain model to achieve the benefits of PALMA. While this may be true in theory, this is not where the issues lie with MBSE.

Experience of Implementing MBSE for a Large Modularized System

For a previous employer, I was involved in trying to implement MBSE for an extensive modularized system covering both mechatronics and software. My experience from this project was that while MBSE looks great in theory, it is usually a too comprehensive approach for most commercial products to succeed in the long run. Of course, there are exceptions, such as highly complex products within the defense industry or infrastructure products, nuclear power plants for example, where the costs for mistakes are tremendous, and requirements are generally stable. For most products with high volume and scale, too much data needs to be modeled into the MBSE tools to get any value out of it. The time spent describing all the requirements in detail required for MBSE is tremendous, even for relatively simple products. This level of manual processes will take much work to justify for project stakeholders since progress will be plodding at the project’s onset.

Secondly, since commercial product requirements evolve at an increasing rate, spending eons writing requirements wastes valuable time if the requirements change during the product development–and chances are high that they will. In fact, coping with an increased pace of change in requirements was the main reason the Agile development practices were invented in 2001 (learn more: Agile Development for Hardware and Modularization).

Furthermore, many of today’s products start from something other than a blank sheet of paper. If the product has existed for a while, chances are that much of the software comes from a previous generation, with many undocumented features hidden in the code. Another blog discusses this concept in detail: Improve your Software Architecture by Code Refactoring, Not Rewriting.

Implementing a module system in PALMA might seem like an equally tremendous task at first. Still, the requirements documentation in PALMA is related to describing the different module variants that are needed to reach the market requirements. Detailed technical aspects of the module variants can be covered in existing documentation, even linking back to MBSE tools if desired. The most important essential elements of module system profitability are based on production, sourcing, and development data, which is much easier to obtain and document in PALMA.

Figure 4. Difference in requirements covered by MBSE and PALMA.

This means that there is much less data required to be implemented in PALMA to realize the tool’s benefits as compared to the MBSE approach. As a result, the chances that organizations succeed with a PALMA implementation are much higher than with MBSE. I have seen many comprehensive MBSE projects emerge with great hopes of improvements to come that eventually are buried when the massive documentation load is realized. Project stakeholders place priority on a working product over a comprehensive documentation of the system. After all, a functional product generates value for the company, and incremental changes can be made to make the products even more successful in the future after receiving customer feedback. A perfect MBSE model doesn’t generate money for the company before the product has been designed, tested, constructed, and shipped to the customer.

Is There a Different Approach than MBSE That Could Be Considered?

As stated earlier, MBSE attempts to solve the problem of understanding system requirements early in the development process to avoid costly changes later.

The Agile approach requires incremental implementation and frequent product demos to receive fast feedback from product stakeholders. The process helps eliminate unnecessary, wasteful development and understand the customer’s priorities before it is too late in the development cycle.

Agile development practices are addressing the same problem as the MBSE method with a lightweight approach that is suitable for many commercial products of today. However, a more robust method is required for complex systems such as nuclear power plants and warships from 1628. To be successful in Agile development, a modularized system with PALMA can dramatically improve the results.

The final takeaway is that PALMA and modularization both provide much value for either the MBSE route or Agile practices. However, you can’t beat the benefits of investing in a modular architecture regardless of development methodology.

Want to Know More? 

If you’d like to learn more about implementing modularity for your organization or asking a follow-up question on this topic, feel free to message me using the contact information below. Additionally, if you’re interested in seeing more of PALMA, book a demo here.