Did you ever wonder why we refer to certain objects with names that don’t really make sense? Things like calling a jet engine blade a “bucket” or having a “dash board” in a car? I’ll explain that later. What really matters is that we all understand what is meant by them in today’s context, even though we may not know where they originated. That combination of common understanding of the meaning of things, without necessarily knowing where they came from, is essential to implementing Systems Thinking.
I’m referring to Systems Thinking as applied to the management of ever-increasing complexity in today’s smart and hyper-connected products. Systems engineers use Systems Thinking principals when exploring and designing system behavior using MBSE tools and languages like SysML. Since everything that they do in a model is symbolic, they have wide latitude in creating their own meanings behind them (SysML does not enforce a methodology of any kind). And that’s where we run into a problem—when others need to interpret these models, or even worse, when one needs to interpret models from different sources that used different modeling methodologies.
At the same time these varying meanings from a variety of system models are expected to be represented in Digital Threads managed by a PLM Platform. Additionally, the same Digital Thread is expected to provide traceability to the details of other related design representations that span the entire lifecycle (simulation, mechanical, electronic, electrical, software, testing, etc.). But how to do that if the data itself comes from so many different tools utilizing so many different methodologies? Worse yet, how are the teams that represent different interests across the enterprise to understand what the individual authors meant when they were authoring the individual design representations? And what are the meanings of the relationships across these representations if we don’t understand the meaning of the linked data because that meaning changes depending on where the data came from?
There is another angle to it. Systems engineers should be able to participate in design decisions throughout every lifecycle state. They, too, depend on a uniform understanding of the Digital Thread content as it is reflecting more and more design details. After all, that is the goal of MBSE—providing systems engineers with more traceability and visibility into the whole design, manufacturing, and field operation representation so they can become more active contributors along the whole V-model and beyond.
Obviously, the answer is that users of the Digital Thread don’t care where the data came from, they only care about a uniform meaning of the data and a uniform meaning of the relationships between that data—regardless of where it came from and regardless what it is called. The Digital Thread must be capable of representing aspects of future design representations generated by future technologies (ex: IoT, AI, generative designs). Without that, users can’t collaborate, evaluate the effects of proposed changes, explore impacts of new functionality, or reuse already approved solutions as elements of new systems. And that in turn can have devastating effects on the ability to get the right product to market, at the right time, and at the right cost.
The only way to ensure that robustness and agility of the Digital Thread is by using a PLM platform capable of modeling data and relationships based on ontology-driven techniques. Data from the individual sources can’t be represented as it is in the original authoring tool. It must be abstracted to a tool-independent layer that normalizes differences between the authoring tools and authoring methodologies into a uniform meaning of things. In other words, you better pick the right PLM Platform architecture!
We all understand that Systems Thinking is extremely important to the market and to a successful implementation of Digital Thread, but it can’t succeed without a common interpretation of everything that it is supposed to be applied to. Feel free to add your point of view in the comments below and look for future blogs on the subject.
And going back to the “buckets” and “dashboards”? The “bucket” came from their usage on a water mill wheel to rotate it. Somewhat like a blade in a jet engine, I guess. And the dashboard came from the horse drawn carriages mud barrier in front. That was a convenient place to mount the fuel gauge for the early engines.
For more information on Systems Thinking, visit our website.