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

According to LinkedIn, there are over a 7500 PLM consultants in my network.  It is quite an elite group of people as I have over 100.000 CEOs in my network according to LinkedIn. Being a CEO is a commodity.

PLM consultants share a common definition, the words Product Lifecycle Management. However, what we all mean by PLM is one of the topics that has evolved over the past 19 years in a significant way.

PLM or cPDM (collaborative PDM)?

In the early days, PLM was considered as an engineering tool for collaboration, either between global subsidiaries or suppliers. The main focus of PLM was to bring engineering information to manufacturing in a controlled way. PLM and cPDM, often seen as solving the same business needs as the implementation of a PLM system most of the time got stuck at the cPDM level.

Main players at that time were Dassault Systemes, UGS (later Siemens PLM) and PTC – their solutions were MCAD-driven with limited scope – bringing engineering information towards manufacturing in a coordinated way.

PLM was not really an approach that created visibility at the management level of a company. How do you value and measure collaboration? Because connectivity was expensive in the early days of PLM, combined with the idea that PLM systems needed to be customized, PLM was framed as costly and hard to deliver value.

Systems Engineering and New Product Introduction

Then, 2005 and beyond, thanks to better connectivity and newcomers in the PLM market, the solution landscape from PLM became broader.  CAD integrations were not a necessary part of the PLM scope according to these newcomers as they focused on governance (New Product Introduction), Bill of Materials or at the front-end of the product design cycle, connecting systems engineering by adding requirements management to their PLM suite.

New players in this domain where SAP, Aras, followed by Autodesk – their focus was more metadata-driven, connection and creating an end-to-end data flow for the product. Autodesk started the PLM and cloud path.

These new capabilities brought a broader scope for PLM indeed. However, they also strengthened the idea that PLM is there for engineers. For the management too complicated, unless they understood the value of coordinated collaboration. Large enterprises saw the benefits of having common processes for PLM as an essential reason to invest in PLM. The graph below showed the potential of PLM, where the shaded area indicates the potential revenue benefits.

Still, this graph does not create “hard numbers,” and it requires visionaries to get a PLM implementation explained and justified across the board.  PLM is framed as expensive even if the budgets spent on PLM are twenty percent or less compared to ERP implementations. As PLM is not about transactional data, the effects of PLM are hard to benchmark. Success has many fathers, and in case of difficulties, the newcomer is to blame.

PLM = IoT?

With the future possibilities, connectivity to the machine-level (IoT or IIoT), a new paradigm related to PLM was created by PTC.  PLM equals IoT – read more here.

Through IoT, it became possible to connect to products/assets in the field, and the simplified message from PTC was that now thanks to IoT (read ThingWorx) PLM was now really possible, releasing traditional PLM out of its engineering boundaries. The connected sensors created the possibility to build and implement more advanced and flexible manufacturing processes, often called Smart Manufacturing or Industrie 4.0.

None of the traditional PLM vendors is talking about PLM solely anymore. Digital transformation is a topic discussed at the board level, where GE played a visionary role with their strong message for change, driven by their CEO Jeff Immelt at that time – have a look at one of his energizing talks here.

However is PLM part of this discussion?

Digital Transformation opened a new world for everyone. Existing product lifecycle concepts could be changed, products are becoming systems, interacting with the environment realized through software features. Systems can be updated/upgraded relatively fast, in particular when you are able to watch and analyze the performance of your assets in almost real-time.

All consultants (me included) like to talk about digital transformation as it creates a positive mood towards the future, imagining everything that is possible. And with the elite of PLM consultants we are discovering the new roles of PLM – see picture below:

Is PLM equal to IoT or Digital Transformation?

I firmly believe the whole Digital Transformation and IoT hypes are unfortunately obfuscating the maximum needs for a digital enterprise. The IoT focus only exposes the last part of the lifecycle, disconnected from the concept and engineering cycles – yes on PowerPoint slides there might be a link. Re-framing PLM as Digital Transformation makes is even vaguer as we discussed during the CIMdata / PDT Europe conference last October. My main argument: Companies fail to have a link with their digital operations and dreams because current engineering processes and data, hardware (mechanical and electronics) combined with software are still operating in an analog, document-driven mode.

PLM = MBSE?

However what we also discussed during this conference was the fact that actually there is a need for an end-to-end model-based systems engineering infrastructure to support the full product lifecycle. Don Farr’s (Boeing) new way to depict the classical systems engineering “V” also hinted into that direction. See the image below – a connected environment between the virtual modeled word and the physical world at any time of the product lifecycle

So could MBSE be the new naming for PLM?

The problem is as Peter Bilello also mentioned during the CIMdata/PDT conference is that the word “ENGINEERING” is in Model-Based Systems Engineering. Therefore keeping the work what the PLM “elite” is doing again in the engineering box.

So perhaps Model-Based Enterprise as the new name?

Unfortunate MBE has already two current definitions – look here and here. Already too much confusion, and there a lot of people who like confusion. See Model-Based – The confusion. So any abbreviation with Model-Based terminology in it will not get attention at the board level. Even if it is crucial the words, Model-Based create less excitement as compared to Digital Twin, although the Digital Twin depends on a model-based approach.

Conclusion

Creating and maintaining unique products and experiences for their customers is the primary target of almost every company. However, no easy acronym that frames these aspects to value at the board level. Perhaps PID – the Product Innovation Diamond approach will be noticed? Your say ….

 

Advertisements

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

 

 

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: