You are currently browsing the tag archive for the ‘MBSE’ tag.
In this post, I want to explain why Model-Based Systems Engineering (MBSE) and Sustainability are closely connected. I would claim sustainability in our PLM domain will depend on MBSE.
Can we achieve Sustainability without MBSE? Yes, but it will be costly and slow. And as all businesses want to be efficient and agile, they should consider MBSE.
What is MBSE?
The abbreviation MBSE stands for Model-Based Systems Engineering, a specialized manner to perform Systems Engineering. Look at the Wikipedia definition in short:
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 on document-based information exchange.
Model-Based fits in the digital transformation scope of PLM – from a document-based approach to a data-driven, model-based one. In 2018, I focused on facets of the model-based enterprise and related to MBSE in this post: Model-Based: System Engineering (MBSE).
My conclusion in that post was:
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.
I drew this conclusion before I focused on sustainability and systems thinking. Implementing sustainability concepts, like the Circular Economy, require more complex engineering efforts, justifying a Model-Based Systems Engineering approach. Let’s have a look.
If you want to learn more about why we need MBSE, look at this excellent keynote speech lecture from Zhang Xin Guo at the Incose 2018 conference below:
The Mission / the stakeholders
A company might deliver products to the market with the best price/quality ratio and regulatory compliance, perceived and checked by the market. This approach is purely focusing on economic parameters.
There is no need for a system engineering approach as the complexity is manageable. The mission is more linear, a “job to do,” and a limited number of stakeholders are involved in this process.
… with sustainability
Once we start to include sustainability in our product’s mission, we need a systems engineering approach, as several factors will push for different considerations. The most obvious considerations are the choice of materials and the optimizing the production process (reducing carbon emissions).
However, the repairability/serviceability of the product should be considered with a more extended lifetime vision.
What about upgradeability and reusing components? Will the customer pay for these extra sustainable benefits?
Probably Yes, when your customer has a long-term vision, as the overall lifecycle costs of the product will be lower.
Probably No if none of your competitors delivers non-sustainable products much cheaper.
As long as regulations will not hurt traditional business models, there might be no significant change.
However, the change has already started. Higher energy prices will impact the production of specific resources and raise costs. In addition, energy-intensive manufacturing processes will lead to more expensive materials. Combined with raising carbon taxes, this will be a significant driver for companies to reconsider their product offering and manufacturing processes.
The more expensive it becomes to create new products, the more attractive repairable and upgradable products will become. And this brings us to the concept of the circular economy, which is one of the pillars of sustainability.
In short, looking at the diagram – the vertical flow from renewables and finite materials from part to product to product in service leads ultimately to wasted resources if there are no feedback loops. This is the traditional product delivery process that most companies are using.
You can click on the image to the left to zoom in on the details.
The renewable loop on the left side of the diagram is the usage of renewables during production and the use of the product. The more we use renewables instead of fossil fuels, the more sustainable this loop will be. This is the area where engineers should use simulations to find the optimal manufacturing processes and product behavior. Again click on the image to zoom in on the details.
The right side of the loop, related to the materials, is where we see the options for repairable, serviceable, upgradeable, and even further refurbishment and recycling to avoid leakage of precious materials. This is where mechanical engineers should dominate the activities. Focussing on each of the loops and how to enable them in the product. Click on the image to see the relevant loops.
Looking at the circular economy diagram, it is clear that we are no longer talking about a linear process – it has become the implementation of a system. Systems Engineering or MBSE?
The benefits of MBSE
Developing products with the circular economy in mind is no longer a “job to do,” a simple linear exercise. Instead, if we walk down the systems engineering V-shape, there are a lot of modeling exercises to perform before we reach the final solution.
To illustrate the benefits of MBSE, let’s walk through the following scenario.
A well-known company sells lighting projects for stadiums and public infrastructure. Their current business model is based on reliable lighting equipment with a competitive price and range of products.
Most of the time, their contracts have clauses about performance/cost and maintenance. The company sells the products when they win the deal and deliver spare parts when needed.
Their current product design is quite linear – without systems engineering.
Now this company has decided to change its business model towards Product As A Service, or in their terminology LaaS (Lightening as a Service). For a certain amount per month, they will provide lighting to their customers, a stadium, a city, and a road infrastructure.
To implement this business model, this is how they used a Model-Based Systems Engineering approach.
Modeling the Mission
Example of a business model
Before even delivering any products, the process starts with describing and analyzing the business model needed for Lightening as a Service.
Then, with modeling estimates about the material costs, there are exercises about the resources required to maintain the service, the potential market, and the possible price range.
It is the first step of using a model to define the mission of the service. After that, the model can be updated, adjusted, and used for a better go-to-market approach when the solution becomes more mature.
Part of the business modeling is also the intention to deliver serviceable and upgradeable products. As the company now owns the entire lifecycle, this is the cheapest way to guarantee a continuous or improved service over time.
Modeling the Functions
Example of a function diagram
Providing Lighting as a Service also means you must be in touch with your installations in real time. Power consumption needs to be measured and analyzed in real-time for (predictive) maintenance, and the light-providing service should be as cheap as possible during operation.
Therefore LED technology is the most reliable, and connectivity functions need to be implemented in the solution. The functional design ensures installation, maintenance and service can be done in a connected manner (cheapest in operation – beneficial for the business).
Modeling the Logical components
As an owner of the solution, the design of the logical components of the lighting solution is also crucial. How to address various lighting demands efficiently? Modularity is one of the first topics to address. With modular components, it is possible to build customer-specific solutions with a reduced engineering effort. However, the work needs to be done by generically designing the solutions and focusing on the interfaces.
Example of a logical diagram
Such a design starts with a logical process and flow diagrams combined with behavior modeling. Without already having a physical definition, we can analyze the components’ behavior within an electrical scheme. Decisions on whether specific scenarios will be covered by hardware or software can be analyzed here. The company can define the lower-level requirements for the physical component by using virtual trade-offs on the logical models.
At this stage, we have used business modeling, functional modeling and logical modeling to understand our solution’s behavior.
Modeling the Physical product
The final stage of the solution design is to implement the logical components into a physical solution. The placement of components and interfaces between the components becomes essential. For the physical design, there are still a lot of sustainability requirements to verify:
- Repairability and serviceability – are the components reachable and replaceable? Reducing the lifecycle costs of the solution
- Upgradeability – are there components that can behave differently due to software choices, or are there components that can be replaced with improved functionality. Reducing the cost of creating entirely new solutions.
- Reuse & recyclable – are the materials used in the solution recyclable or reusable, reducing the cost of new materials or reducing the cost of dumping waste.
- RoHS/ REACH compliance
The image below from Zhang Xin Guo’s presentation nicely demonstrates the iterative steps before reaching a physical product
Before committing to a hardware implementation, the virtual product can be analyzed, behavior can be simulated, and it carbon impact can be calculated for the various potential variants.
The manufacturing process and energy usage during operation are also a part of the carbon impact calculation. The best performing virtual solution, including its simulations models, can be chosen for the realization to ensure the most environmentally friendly solution.
The digital twin for follow-up
Once the solution has been realized, the company still has a virtual model of the solution. By connecting the physical product’s observed and measured behavior, the virtual side’s modeling can be improved or used to identify improvement candidates – maintenance or upgrades. At this stage, the virtual twin is the actual twin of the physical solution. Without going deeper into the digital twin at this stage, I hope you also realize MBSE is a starting point for implementing digital twins serving sustainability outcomes.
The image below, published by Boeing, illustrates the power of the connected virtual and physical world and the various types of modeling that help to assess the optimal solution.
Conclusion
For sustainability, it all starts with the design. The design decisions for the product contribute for 80 % to the carbon footprint of the solution. Afterward, optimization is possible within smaller margins. MBSE is the recommended approach to get a trustworthy understanding and follow-up of the product’s environmental impact.
What do you think can we create sustainable products without MBSE?
Last week I shared my first review of the PLM Roadmap / PDT Fall 2020 conference, organized by CIMdata and Eurostep. Having digested now most of the content in detail, I can state this was the best conference of 2020. In my first post, the topics I shared were mainly the consultant’s view of digital thread and digital twin concepts.
This time, I want to focus on the content presented by the various Aerospace & Defense working groups who shared their findings, lessons-learned (so far) on topics like the Multi-view BOM, Supply Chain Collaboration, MBSE Data interoperability.
These sessions were nicely wrapped with presentations from Alberto Ferrari (Raytheon), discussing the digital thread between PLM and Simulation Lifecycle Management and Jeff Plant (Boeing) sharing their Model-Based Engineering strategy.
I believe these insights are crucial, although there might be people in the field that will question if this research is essential. Is not there an easier way to achieve to have the same results?
Nicely formulated by Ilan Madjar as a comment to my first post:
Ilan makes a good point about simplifying the ideas to the masses to make it work. The majority of companies probably do not have the bandwidth to invest and understand the future benefits of a digital thread or digital twins.
This does not mean that these topics should not be studied. If your business is in a small, simple eco-system and wants to work in a connected mode, you can choose a vendor and a few custom interfaces.
However, suppose you work in a global industry with an extensive network of partners, suppliers, and customers.
In that case, you cannot rely on ad-hoc interfaces or a single vendor. You need to invest in standards; you need to study common best practices to drive methodology, standards, and vendors to align.
This process of standardization is so crucial if you want to have a sustainable, connected enterprise. In the end, the push from these companies will lead to standards, allowing the smaller companies to ad-here or connect to.
The future is about Connected through Standards, as discussed in part 1 and further in this post. Let’s go!
Global Collaboration – Defining a baseline for data exchange processes and standards
Katheryn Bell (Pratt & Whitney Canada) presented the progress of the A&D Global Collaboration workgroup. As you can see from the project timeline, they have reached the phase to look towards the future.
Katheryn mentioned the need to standardize terminology as the first point of attention. I am fully aligned with that point; without a standardized terminology framework, people will have a misunderstanding in communication.
This happens even more in the smaller businesses that just pick sometimes (buzz) terms without a full understanding.
Several years ago, I talked with a PLM-implementer telling me that their implementation focus was on systems engineering. After some more explanations, it appeared they were making an attempt for configuration management in reality. Here the confusion was massive. Still, a standard, common terminology is crucial in our domain, even if it seems academic.
The group has been analyzing interoperability standards, standards for long-time archival and retrieval (LOTAR), but also has been studying the ISO 44001 standard related to Collaborative business relationship management systems
In the Q&A session, Katheryn explained that the biggest problem to solve with collaboration was the risk of working with the wrong version of data between disciplines and suppliers.
Of course, such errors can lead to huge costs if they are discovered late (or too late). As some of the big OEMs work with thousands of suppliers, you can imagine it is not an issue easily discovered in a more ad-hoc environment.
The move to a standardized Technical Data Package based on a Model-Based Definition is one of these initiatives in this domain to reduce these types of errors.
You can find the proceedings from the Global Collaboration working group here.
Connect, Trace, and Manage Lifecycle of Models, Simulation and Linked Data: Is That Easy?
I loved Alberto Ferrari‘s (Raytheon) presentation how he described the value of a model-based digital thread, positioning it in a targeted enterprise.
Click on the image and discover how business objectives, processes and models go together supported by a federated infrastructure.
Alberto’s presentation was a kind of mind map from how I imagine the future, and it is a pity if you have not had the chance to see his session.
Alberto also focused on the importance of various simulation capabilities combined with simulation lifecycle management. For Alberto, they are essential to implement digital twins. Besides focusing on standards, Alberto pleas for a semantic integration, open service architecture with the importance of DevSecOps.
Enough food for thought; as Alberto mentioned, he presented the corporate vision, not the current state.
More A&D Action Groups
There were two more interesting specialized sessions where teams from the A&D action groups provided a status update.
Brandon Sapp (Boeing) and Ian Parent (Pratt & Whitney) shared the activities and progress on Minimum Model-Based Definition (MBD) for Type Design Certification.
As Brandon mentioned, MBD is already a widely used capability; however, MBD is still maturing and evolving. I believe that is also one of the reasons why MBD is not yet accepted in mainstream PLM. Smaller organizations will wait; however, can your company afford to wait?
More information about their progress can be found here.
Mark Williams (Boeing) reported from the A&D Model-Based Systems Engineering action group their first findings related to MBSE Data Interoperability, focusing on an Architecture Model Exchange Solution. A topic interesting to follow as the promise of MBSE is that it is about connected information shared in models. As Mark explained, data exchange standards for requirements and behavior models are mature, readily available in the tools, and easily adopted. Exchanging architecture models has proven to be very difficult. I will not dive into more details, respecting the audience of this blog.
For those interested in their progress, more information can be found here
Model-Based Engineering @ Boeing
In this conference, the participation of Boeing was significant through the various action groups. As the cherry on the cake, there was Jeff Plant‘s session, giving an overview of what is happening at Boeing. Jeff is Boeing’s director of engineering practices, processes, and tools.
In his introduction, Jeff mentioned that Boeing has more than 160.000 employees in over 65 countries. They are working with more than 12.000 suppliers globally. These suppliers can be manufacturing, service or technology partnerships. Therefore you can imagine, and as discussed by others during the conference, streamlined collaboration and traceability are crucial.
The now-famous MBE Diamond symbol illustrates the model-based information flows in the virtual world and the physical world based on the systems engineering approach. Like Katheryn Bell did in her session related to Global Collaboration, Jeff started explaining the importance of a common language and taxonomy needed if you want to standardize processes.
Zoom in on the Boeing MBE Taxonomy, you will discover the clarity it brings for the company.
I was not aware of the ISO 23247 standard concerning the Digital Twin framework for manufacturing, aiming to apply industry standards to the model-based definition of products and process planning. A standard certainly to follow as it brings standardization on top of existing standards.
As Jeff noted: A practical standard for implementation in a company of any size. In my opinion, mandatory for a sustainable, connected infrastructure.
Jeff presented the slide below, showing their standardization internally around federated platforms.
This slide resembles a lot the future platform vision I have been sharing since 2017 when discussing PLM’s future at PLM conferences, when explaining the differences between Coordinated and Connected – see also my presentation here on Slideshare.
You can zoom in on the picture to see the similarities. For me, the differences were interesting to observe. In Jeff’s diagram, the product lifecycle at the top indicates the platform of (central) interest during each lifecycle stage, suggesting a linear process again.
In reality, the flow of information through feedback loops will be there too.
The second exciting detail is that these federated architectures should be based on strong interoperability standards. Jeff is urging other companies, academics and vendors to invest and come to industry standards for Model-Based System Engineering practices. The time is now to act on this domain.
It reminded me again of Marc Halpern’s message mentioned in my previous post (part 1) that we should be worried about vendor alliances offering an integrated end-to-end data flow based on their solutions. This would lead to an immense vendor-lock in if these interfaces are not based on strong industry standards.
Therefore, don’t watch from the sideline; it is the voice (and effort) of the companies that can drive standards.
Finally, during the Q&A part, Jeff made an interesting point explaining Boeing is making a serious investment, as you can see from their participation in all the action groups. They have made the long-term business case.
The team is confident that the business case for such an investment is firm and stable, however in such long-term investment without direct results, these projects might come under pressure when the business is under pressure.
The virtual fireside chat
The conference ended with a virtual fireside chat from which I picked up an interesting point that Marc Halpern was bringing in. Marc mentioned a survey Gartner has done with companies in fast-moving industries related to the benefits of PLM. Companies reported improvements in accuracy and product development. They did not see so much a reduced time to market or cost reduction. After analysis, Gartner believes the real issue is related to collaboration processes and supply chain practices. Here lead times did not change, nor the number of changes.
Marc believes that this topic will be really showing benefits in the future with cloud and connected suppliers. This reminded me of an article published by McKinsey called The case for digital reinvention. In this article, the authors indicated that only 2 % of the companies interview were investing in a digital supply chain. At the same time, the expected benefits in this area would have the most significant ROI.
The good news, there is consistency, and we know where to focus for early results.
Conclusion
It was a great conference as here we could see digital transformation in action (groups). Where vendor solutions often provide a sneaky preview of the future, we saw people working on creating the right foundations based on standards. My appreciation goes to all the active members in the CIMdata A&D action groups as they provide the groundwork for all of us – sooner or later.
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 ….
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
Recently, 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
As 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 the quality and correctness of data, that is not 100 % secure. A digital infrastructure works with connected data in context.
Therefore, if your company is still relying on drawings and you want to be ready for the future, the 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.
Jos Voskuil's Weblog 
Jos, what a ride you have had! And looking at some of the spaghetti system architectures of even today's businesses,…
Congratulations, Jos! I'm very happy that you'll stay active in the PLM world and continue with your blogs - during…
Jos, welcome to the world of (part-time) retirement. Enjoy your AOW. Thanks Dick, you have the experience now - enjoy…
Thanks for all the valuable thoughts you have shared with us Jos, hope your 'new career' will bring you lots…
Great.. Congratulations on reaching yet another milestone... your blog is very thought proving and helps us to think in multiple…