You are currently browsing the tag archive for the ‘MBSE’ tag.

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

 

 

Advertisements

changeRecently, I have written about classical PLM (document-driven and sequential) and modern PLM (data-driven and iterative) as part of the upcoming digital transformation that companies will have to go through to be fit for the future. Some strategic consultancy companies, like Accenture, talk about Digital PLM when referring to a PLM environment supporting the digital enterprise.

 

From classical PLM to Digital PLM?

The challenge for all companies is to transform their businesses to become customer-centric and find a transformation path from the old legacy PLM environment towards the new digital environment. Companies want to do this in an evolutionary mode. However my current observations are that the pace of an evolutionary approach is too slow related to what happens in their market. This time the change is happening faster than before.

A Big Bang approach towards the new environment seems to be a big risk. History has taught us that this is very painful and costly. To be avoided too. So what remains is a kind of bimodal approach, which I introduced in my recent blog posts (Best Practices or Next Practices). Although one of my respected readers and commenters Ed Lopategui mentioned in his comment (here) bimodal is another word for coexistence. He is not optimistic about this approach either

So, what remains is disruption?

And disruption is a popular word and my blog buddy Oleg Shilovitsky recently dived into that topic again with his post: How to displace CAD and PLM industry incumbents. An interesting post about disruption and disruption patterns. My attention was caught by the words: digital infrastructure.
I quote:

How it might happen? Here is one potential answer – digital infrastructure. Existing software is limited to CAD files stored on a desktop and collaboration technologies developed 15-20 years using relational database and client-server architecture.

Digital Infrastructure

imageAs I mentioned the words, Digital Infrastructure triggered me to write this post. At this moment,  I see companies marketing their Digital Transformation story in a slick way, supported by all the modern buzz words like; customer-centric, virtual twin and data-driven. You would imagine as a PLM geek that they have already made the jump from the old document-driven PLM towards modern digital PLM. So what does a modern digital PLM environment look like ?

The reality, however, behind this slick marketing curtain, is that there are still the old legacy processes, where engineers are producing drawings as output for manufacturing. Because drawings are still legal and controlled information carriers. There is no digital infrastructure behind the scenes. So, what would you expect behind the scenes?

Model-Based Definition as part of the digital infrastructure

Crucial to be ready for a digital infrastructure is to transform your company´s product development process from a file-based process where drawings are leading towards a model-based enterprise. The model needs to be the leading authority (single source of truth) for PMI (Product Manufacturing Information) and potentially for all upfront engineering activities. In this case, we call it Model-Based Systems Engineering sometimes called RFLP (Requirements-Functional-Logical-Product), where even the product can be analyzed and simulated directly based on the model.

A file-based process is not part of a digital infrastructure or model-based enterprise architecture. File-based processes force the company to have multiple instances and representations of the same data in different formats, creating an overhead of work to keep up quality and correctness of data, that is not 100 % secure. A digital infrastructure works with connected data in context.

econimistTherefore, if your company is still relying on drawings and you want to be ready for the future, a first step towards a digital infrastructure would be fixing your current processes to become model-based. Some good introductions can be found here at ENGINEERING.com – search for MBD and you will find:

Moving to Mode-Based is already a challenging transformation inside your company before touching the challenge of moving towards a full digital enterprise, through evolution, disruption or bimodal approach – let the leading companies show the way.

Conclusion

Companies should consider and investigate how to use a Model-Based Engineering approach as a first step to becoming lean and fit for a digital future. The challenge will be different depending on the type of industry and product.
I am curious to learn from my readers where they are on the path to a digital enterprise.

%d bloggers like this: