This is already my fourth post related to Model-Based concepts, which started with Model-Based – An Introduction. There are at least two more posts to come depending on your feedback. The amount of posts also illustrates that the topic is not easy to explain through blog posts with a target length of 500-1000 words.
This combined with the observation that model-based in the context of PLM is quickly associated with replacing 2D Drawings by 3D annotated CAD models, or a marketing synonym for the classical interaction between a PDM-system and a CAD-system, see Model-Based – The Confusion, there is a lot to share. I will come back to Model-Based Definition in an upcoming post. But now Model-Based Systems Engineering.
Systems Engineering
When you need to define a complex product, that has to interact in various ways in a safe manner with the outside world, like an airplane or a car, systems engineering is the recommended approach to define the product. In 2004, when I spoke at a generic PLM conference about the possibilities to extend SmarTeam with a system engineering data model:
(a Requirements/Functional/Logical decomposition connecting to the Product- RFLP) most engineers considered this as extra work. Too complex was the feedback. A specification document was enough most of the time as the base for a product to develop. Perhaps at that time these engineers were right. At that time most of their products were purely mechanical and served a single purpose.
Now almost 15 years later products have become complex due to the combination of electronic and software. And by adding software and sensors, the product becomes a multi-purpose product, interacting with the outside world, a system.
If you want to dive deeper into an unambiguous explanation of systems engineering, follow this link to the INCOSE website.
INCOSE (International Council On Systems Engineering) is a not-for-profit membership organization founded to develop and disseminate the interdisciplinary principles and practices that enable the realization of successful systems.
There are a few points that I want you to remember from systems engineering approach.
First of all, it is an iterative approach, where you start with a high-level concept defining which functions are needed to full-fill the high-level requirement.
Then, by choosing for certain solutions concepts, you will have trade-off studies during this phase to select the solution concept is defined. Which functions will be supported, what are the logical components needed for the solutions and what are the lower-level requirements for these components.
Trade-off studies eliminate alternatives and create the base for the final design which will be more and more detailed and specific over time. You need a functional and logical decomposition before jumping into the design phase for mechanical electrical and software components. Therefore, jumping from requirements directly into building a solution is not real systems engineering. You use this approach only if you already know the products solutions concept and logical components. Something perhaps possible when there is no involvement of electronics and software.
Model-Based Systems Engineering
So what’s the difference between Systems Engineering and Model-Based Systems Engineering ?
As the addition of model-based already indicates, the process of systems engineering will be driven by using domain models to exchange information between engineers instead of documents. And more recently these models are also linked to simulations to define the best trade-off and decide on lower-level requirements.
In model-based systems engineering the most efficient way of working is to use parameters for requirements, logical and physical settings. Next decide on lower-level requirements and constraints the concept “Design of Experiments” is used, where the performance of a product is simulated by varying several design parameters. The results of a Design of Experiment assist the engineering teams to select the optimized solution, of course based on the model used.
Model-Based Systems Engineering and PLM
As I mentioned in the introduction systems engineering was often a disconnected discipline from engineering. Systems Engineering defines the boundaries for the engineering department. In a modern digital enterprise, the target is to offer data continuity where systems engineering is connected. Incremental innovation in particular thanks to software will require an environment where multidisciplinary teams can collaborate in the most efficient way together.

Slide from CIMdata: positioning of MBx approaches
The above image from CIMdata concludes my post on model-based related to systems engineering. As you can see MBSE is situated at the front-end of the product lifecycle, however we have to realize that the modern product lifecycle is no longer linear but iterative (you can read more here: From a linear world to fast and circular)
Conclusion
Model-Based Systems Engineering might have been considered as a discipline for the automotive and aerospace industry only. As products become more and more complex, thanks to IoT-based applications and software, companies should consider evaluating the value of model-based systems engineering for their products / systems
3 comments
Comments feed for this article
May 18, 2018 at 5:21 pm
Simon Kooij
I liked the previous blogs about Model-Based Definition etc.
And this blog gives a clear overview about Model Based System Engineering.
The importance of the V-shape starting with the Requirements for all the disciplines involved with the product makes it in today’s complexity an important methodology to develop, test and release Smart-products and maintain them by keeping the relations from requirement, function and physical product, and vice-versa.
Well done.
Thanks Simon for your feedback. I know Systems Engineering is close to your heart. Best Regards, Jos
LikeLiked by 1 person
May 24, 2018 at 12:55 pm
Henk Jan Pels
Hello Jos
Compact and clear description. Very good, but can you explain the difference between functional and logical decomposition?
Henk Jan Pels
Henk Jan, great to hear from you and I assume you know the answer and want to check the clarification. The functional decomposition describes which functions a system should perform, starting from the high-level (based on the mission) down to lower level functions based on the expected behavior/use cases. The logical decomposition describes how the system will be implemented from the system point of view. It means which logical components are needed deliver these functions. For example a function could be “Transport goods” where the logical implementation could be a conveyor system but also could be a slide which require different systems and components. Functional and logical composition are connected and through an iterative process as the end all defined functions should be implemented through logical components and later down the process through designed / physcial components. I hope this clarifies the difference .
Best regards, Jos
LikeLiked by 1 person
June 4, 2018 at 5:16 pm
Henk Jan Pels
Hallo Jos. Thanks for your explanation. It fits in my view on different product models. However, while trying to explain to mechanical engineers the importance of distinguishing different models in order to improve design reuse, I found that they recognize a functional, design and manufacturing phase in their projects. The next step is to explain that the design model is not a new version of the approved functional model nor is the manufacturing model a new version of the design model. For each of the three models an approved version should be kept for future reuse. My functional model is the model that can be used for all kind of analysis techniques to prove that it meets functional requirements. It can be highly parameterized, such that proofs are valid for ranges of parameter values. The design then adds the details that are required to make a unambiguous definition of a manufacturable product, while the manufacturing models contains all the documentation the people on the floor need to execute the process properly.
From your explanation I understand that in future I better use your term ‘logical’ in place of my ‘functional’.
Henk Jan
Henk Jan – thanks for your feedback I think we should go through perhaps a more detailed discussion together how the related views, i.e requirements, functional, logical and physical link together in specifying a complex product. Next based on your models you will define Bill of Materials to specify the manufacturing definition. I hope this help, otherwise talk to you soon.
Best regards, Jos
LikeLiked by 1 person