PLM solutions traditionally manage what a product is (aka design data) without much understanding of what the product does (aka design intent). Design data configuration management is critical for keeping track of product variants, releases, changes, and the transformation of the engineering Bill of Materials (eBOM) to the manufacturing Bill of Materials (mBOM). However, BOM management does not have a significant role in determining the product's purpose. That lack of design intent context, of course, becomes a significant issue when designing ever-complex products characterized by:
- A tsunami of requirements and regulations well beyond the product’s core functionality and stakeholder specifications, such as country-specific regulatory compliance or green initiatives
- The increasing necessity to design the product as part of a more extensive system – i.e., systems with increasingly complex system-to-system behaviors
- An accelerating drive towards software-defined products because of pervasive connectivity, SaaS models for delivering product functionality via online services, and over-the-air update capabilities
- Ubiquitousness and intelligence of physical and virtual sensors everywhere within and around the product
- And more…
Abstraction as a way of expressing design intent
The ability to abstract product complexity to a higher representation level is why Model Based Systems Engineering (MBSE) data is so important. MBSE also defines design intent critical to understanding the purpose of design data. That MBSE abstraction is precisely what "reduces" the complexity by focusing on the functional breakdown of a product (I’m simplifying here a bit). This allows the product’s functions to be defined and optimized before being allocated for implementation across mechanical, software, electronic, and electrical domains. I’m convinced this is how MBSE is also slowly transforming product design methodologies and tools within the individual domains, which eventually leads to a BOM managed by PLM. That is precisely what happened in software and semiconductor design when their design complexities became unmanageable.
Consider how software engineers today use high-level programming languages to design on a functional level with little need to understand how that gets compiled into an assembly language or a CPU-specific instruction set (an implementation domain!). It is the same with chip designers using hardware description languages (HDL) such as Verilog or VHDL to design on a functional/logical level without being concerned about how the code gets synthesized to a register-transfer logic (RTL) or how integrated circuit (IC) foundries generate photoimaging masks from it (also an implementation domain!). Software and semiconductor designers can achieve today’s design efficiency by elevating design complexity to a functional level.
Obviously, in the case of PLM this focus on functional representation does not diminish the importance of the implementation domains collaborating to optimize the overall result using PLM, nor does it diminish the value of managing a BOM in PLM. But I do see MBSE slowly changing the focus point for design engineers towards systems thinking with every design engineer using tools capable of creating a functional abstraction in every domain. It’s similar to the role of electronic schematics as a functional definition before laying out a printed circuit board (PCB). I predict that the same will happen to all product domains managed by PLM, allowing PLM to understand why a product is designed the way it is. In the immortal words of the Borg in Star Trek: “Resistance is futile.”
Digital Thread to support the future of product innovation
Making MBSE part of a PLM-managed Digital Thread, and therefore providing the design intent of a product within PLM, is already a reality and one of the results of Digital Transformation. This is either developed organically as part of an internal strategy or is enforced as part of industry-wide initiatives like The US Department of Defense INSTRUCTION 5000.97. Digital Thread, which spans both sides of the engineering V model, is the second requirement for the future of product innovation and PLM. To learn more, check out my previous blog, Let's Talk About the Model-Based Enterprise, Digital Threads, and Relationships.
One more note. A PLM-managed Digital Thread does not need to contain everything because the sheer amount of data would be overwhelming. It simply must know how to find it. The recent trend for implementing PLM services in the cloud addresses this since now many data sources can be accessed via cloud-based Data as a Service (DaaS).
Artificial Intelligence (AI) as a partner to engineering
Can PLM assist engineers in designing future complex products instead of “just” tracking what was designed? I’m convinced that it can, but only if engineering design methodologies and tools evolve in a way that makes PLM an interactive engineering “advisor”, or a “co-pilot”. The elevation of functional abstraction and Digital Thread with evolving relationships discussed above are vital to enabling AI to do just that.
Exposing design intent in PLM has many Digital Thread benefits throughout a product’s lifecycle, and many involve the ability to generate a Digital Twin in context instead of having to physically go to the asset in the field. For example, it can be used to analyze the impact of a proposed product update, or leverage IoT data in preventive maintenance, or wirelessly enable/disable services in specific product variants, and others. AI can certainly help by enabling more intelligent searches or generating task-specific reports from very complex data or translating requirements and regulations between languages without losing the context. However, none of that is genuinely transformational in terms of assisting engineers in creating the next design.
Imagine instead a Digital Thread that maintains traceability to ALL previous design solutions that worked or did not work, ALL previous product platforms and their variants, the history of ALL simulations, and ALL IoT data interpretations via Digital Twins of the physical assets. Imagine that the same Digital Thread maintains traceability to functional abstractions of all these solutions, products, and variants. Imagine also that these functional abstractions are modeled using the same system engineering methodology, ontology, and the structured model of data and relationships that can evolve over time. By being the “same” I mean that they can be compared without a loss of context.
Now imagine how the co-pilot would work:
- A systems engineer asks PLM for feedback on how a specific set of requirements and functions can be implemented based on the tracked history
- The PLM AI service returns a list of past solutions that succeeded or failed with an ability to drill down into the details of engineering or market success and failures
- Using AI reasoning, the engineer would compare a set of solutions that succeeded to see what the differences there were between them
- The engineer seeds the new design using the selected solution as a template
- Finally, the engineer uses the AI inference to see how likely the new design is to succeed or fail due to technology or market issues
- ... or something like that, use your imagination!
Thinking about PLM-managed Digital Thread strategies without considering the never-ending rise in future product complexities spells big trouble. This is because one risks a Digital Thread implementation that overfocusses on traceability for sole traceability's sake but does not improve the understanding of its meaning. This may not be a problem in mechanically dominated products where the view of a physical part is sufficient to understand its purpose but is likely a dead-end when products become software and silicon-driven (and where a physical view of the underlying 3D transistor technology is quite useless). I’m exaggerating, of course, to make a point.
That’s where the reimagining of future product innovation comes in. The same PLM platform used today to connect the dots between everything that represents a product can, in the future, assist engineers in generating new innovative designs with AI. After all, it’s your data. This is part of Engineering 5.0 (related to Industry 5.0) discussed by Rob McAveney, Aras CTO, during his recent ACE 2024 keynote address.