Relationships and maturity – we all have something to say about that since we cannot function without them. It is how we live our private lives, raise our children, and succeed in our careers. It is important because, according to the thesaurus, the antonyms are incompetence and decline. But how do these concepts apply to Model-Based Enterprise and Digital Thread? It’s all about traceability.
The Digital Thread was recently the focus of CIMdata’s PLM Road Map & PDT North America 2023 event, the related Aerospace & Defense PLM Action Group report, and the AIAA position paper Digital Thread: Definition, Value and Reference Model. So, it is very much the center of attention for major industry players. This is unsurprising as it is a key element of the increasingly important Model-Based Enterprise strategy that extends beyond engineering. But there is an aspect of Digital Thread traceability that is rarely part of the discussion, yet that is critical to understanding if success is possible: the maturity of relationships.
This isn’t just another post about the Digital Thread; you will learn that something might be holding you back, and it is critically important to move your Digital Thread forward with the Model-Based Enterprise initiative.
Traceability drives the Model-Based Enterprise
Traceability in context (coupled with ease of navigation and visualization) is how the Digital Thread creates value, which is necessary for achieving the Model-Based Enterprise. This is because traceability in context is a much bigger concept than a library of URL-like links that connect elements between different models of a design. Traceability applies to the engineering and non-engineering parts of the Model-Based Enterprise and requires context. Its evolution looks like this:
- Model-Based Definition (MBD) – It typically starts with MBD of 3D designs where documents are replaced with 3D models that hold all the data that defines a mechanical product.
- Product Manufacturing Information (PMI) – 3D MBD models are then expanded with PMI, all the data needed to manufacture a mechanical product from the 3D model.
- Model-Based Engineering (MBE acronym use #1!) – Meanwhile, product engineering embraces MBE (“E” for engineering) by creating connected RFLP (Requirements, Functional, Logical, Physical) representations for all product representations. This includes Model-Based Systems Engineering (MBSE), simulations, mechanical and electronic CAD, software Application Lifecycle Management (ALM), Validation & Verification, documentation, and others.
- Industry 4.0 – At the same time, the entire manufacturing ecosystem starts transforming into Industry 4.0 by leveraging all engineering models from the previous steps and integrating such technologies as Digital Twins, Internet of Things (IoT), cloud computing and analytics, Artificial Intelligence (AI) with machine learning, and others.
- Model-Based Enterprise (MBE acronym use #2!) – Finally, all of this allows organizations to slowly transform themselves into MBE (enterprise) where not only engineering and manufacturing ever-evolving but all people, processes, tools, and data (including partners and suppliers) become model-driven and everything becoming traceable via the Digital Thread.
The Model-Based Enterprise cannot be achieved unless Digital Thread traceability can be expressed in the context of the task at hand. A context that reflects the task, who is performing it, for what purpose, and under what conditions that may or may not be engineering specific. In other words, nobody wants to see, is able to benefit from, or can understand the entire Digital Thread all at once, especially when, sometime in the not-so-distant future, its traceability will include – well – everything. And that task-specific “context” is a key enabling characteristic of a successful Model-Based Enterprise.
The genesis of Digital Thread traceability in product design
Figure 1 shows how individual relationships within Digital Thread keep maturing in context. It starts at conception (top left) and continues through all abstractions (left), all physical designs (bottom), V&V and integration (right), manufacturing (top right), and the field (extended right).
Figure 1 – Engineering V Model
For example, in “engineering speak,” a relationship between a requirement and a part begins as “allocated” (V-left), matures to “satisfied by” (V-bottom), matures to “verified” against a specific part rev (V-right), and keeps maturing with the physical asset to reflect maintenance and upgrades (V-extended right).
Figure 2 shows why individual views of the Digital Thread must be generated in the context of the relationship maturity of the task at hand. That means that most of the relationships depicted here are irrelevant to that contextual view even though they are critical to full Digital Thread traceability. For example:
- If I need to understand requirements (REQUIRED) then I need a view that shows their structure, decomposition, flow down, and perhaps change history and how it relates to the product (AS DESIGNED) – I do not need to see how they were allocated or satisfied at later lifecycle stages.
- If I need to interpret a specific IoT data stream from a physical asset, I need a view that shows how the related requirement (REQUIRED) was verified with a simulation study (AS DESIGNED) performed against a specific product variant (AS BUILT) and its operational performance (AS OPERATED) and maintenance/upgrade history (AS SERVICED).
Figure 2 – The Digital Thread and Product Lifecycle
The genesis of Digital Thread Relationship Maturity Indicators
Based on my own experience, the concepts of traceability I just presented have not found their way into discussions of Digital Thread and a Model-Based Enterprise although hints of it can be found in the AIAA’s paper referenced above. Assuming that you probably haven’t thought this out either, consider this since this is how your Digital Thread will succeed in enabling a Model-Based Enterprise.
Figure 3 – Digital Thread and Relationship Maturity
Figure 3 depicts the maturity evolution of a single relationship that sets up traceability between two specific digital artifacts A and B. It shows how the maturity of that relationship evolves to reflect different states of the product lifecycle. The table below explains what is meant by this “maturity” and how maturity indicators allow that relationship to evolve.
| Figure 3 Details | Comments |
 |
The web of traceability between all digital assets including bills of material, parts, software, electronics, CAD models, documents, requirements, simulation and analysis data, verification and validation data, supplier specifications, technical data pack (TDP) contents, manufacturing process plans, inspection & test plans, quality records, service manuals, maintenance records, and many others. |
 |
The initial maturity of a relationship is typically URL-like and sets up basic traceability between elements A and B. All we know at this point is that A is “somehow” related to B (not the other way around) and nothing else. Without other maturity indicators it has no context. |
 |
Types of relationship maturity indicators depend on the business needs, examples:
|
 |
Indicates the same relationship but now includes more maturity indicators. |
 |
Indicates maturity of the same relationship needed for specific use cases, such as release to manufacturing. |
 |
Indicates that specific relationship maturity applies to how individual views of the Digital Thread are dynamically generated without having to persist them. |
 |
Indicates that the maturity of the relationship keeps evolving together with the operation, maintenance, and upgrades of the physical asset and forms the basis for generating Digital Twins in context as a navigable view of Digital Thread. |
Bottom line: Relationship maturity is ever-evolving, possibly beyond the useful life of the asset itself because of reuse and sustainability. It also shows that the relationship evolves to be tool agnostic since the original design authoring tool may no longer be available.
And there we have it. While creating a massive library of URL-like links to set up some kind of traceability between digital elements of various models is useful (the “globe” in Figure 3), it is insufficient to drive toward a successful Model-Based Enterprise. For a Model-Based Enterprise to benefit from the traceability of everything-to-everything, all relationships within and between the various product, process, and organizational models must be capable of evolving relationship maturity indicators.
Conclusions
If you are intrigued by this blog and envision transforming your organization into a Model-Based Enterprise, then Aras Innovator® PLM platform should be on your list. The platform is the only PLM solution architected to model the Digital Thread relationship maturity indicators with a low-code modeling engine according to your current and emerging business needs. Aras customers start with the out-of-the-box (OOTB) functionality and use the modeling engine to evolve the platform in step with the internal transformation of people, processes, and tools towards the goal of a Model-Based Enterprise as outlined in the five steps above. There is no risk of getting stuck with incompatible implementations because Aras guarantees upwards compatibility via its no-cost upgrade services for all subscribers. This is true for on-premises and cloud (Aras Enterprise SaaS) deployments.
I encourage you to use the links cited above to learn more about the industry focus on the Digital Thread and judge how the concepts outlined above relate to it.
As to the maturity of relationships, I’ve been working on my specific relationship and its maturity for the last 45 years (!), and I’m told that there is so much left to do… Same challenge.