What Are Digital Twins and Digital Threads?

In feature-based PLE, engineering assets are shared across a product line. A configurator, here the Gears PLE tool from BigLever Software, produces product-specific instances based on features chosen from a superset of features. Each of these instances is the start of a digital twin.

Previous Next

Conventional simulation and digital mockups (DMU) are still valuable, but they’ve become limiting when managing today’s very Internet of Things-like (IoT) products, such as connected and autonomous vehicles. These are products with embedded software and electronics, real-time and ubiquitous connectivity and data communications to cloud-based data repositories through the internet, oodles of smart embedded sensors, real-time data analysis based on artificial intelligence and other complex and sophisticated technologies.

What’s an automotive OEM and tier supplier to do? They should grab a hold of digital twins and digital threads. Don’t get thrown by these terms; they’re basically the latest iteration of familiar data-management concepts.

What is a digital twin?

A digital twin is basically a virtual version of a physical entity, whether product, factory, or some other type of asset or system. The digital twin unites business, contextual and sensor data to represent the physical object. More to the point, says Marc Lind, senior vice president of strategy for Aras Corp., a PLM systems vendor, “While virtual models tend to be generic representations of a part or a family of parts, the digital twin is literally instance-based. Think VIN level, the digital twin is an exact digital representation of the physical vehicle right now.”

Note two key attributes. First, with DMUs, the goal was to fully test a proof-of-concept before actually creating the physical thing, such as the 2018 model of a car. The digital twin, says Charles Krueger, CEO of BigLever Software (biglever.com), producer of product line engineering (PLE) tools, “Looks at the real instances of things out in the real world, how they exist, and how they evolve over time. Rather than terminating our relationship with this thing we manufactured when we sell it, let’s maintain our relationship so that we actually understand and know for each one of those individual things its current state, how it’s performing and detect a malfunction that’s happening or just about to happen.”

Second, given today’s ubiquitous connectivity, the physical product out in the field can report its status, operating conditions, ambient environmental factors and so on back to the digital twin. In this way, the digital twin is not only an exact representation, it’s an updated, current exact representation. Better, continues Lind, “A digital twin adds context to interpret the time-series data streaming back from the field.”

What does this have to do with PLE?

“This engineering model of a thing, of what comes out of a product line factory, that’s the birth of a digital twin. That’s the first incarnation of a digital representation of a thing,” explains Krueger. “We haven’t put a serial number on it yet. We haven’t connected it to maintenance records or anything like that. But that’s where that whole digital twin process comes into being for the first time.”

PLE talks “features,” the lingua franca that everybody understands, according to Krueger. PLE equates “here’s a feature I want” with “is that feature compatible with these parts or these other features?” Take blind spot alert systems, points out Krueger. “Mechanical people hear that and they go, `Oh, it’s this part and that part and this radar and that light that needs to go off to show there’s a car in my blind spot.’ The electrical people are thinking algorithms.

Production is thinking wiring harnesses. Marketing is thinking glossy brochures. Manufacturing is thinking about how do they get that subsystem in the car at the right time. And people worried about digital twins need to understand whether that feature is on the car or not.”

By extension, Krueger continues, “Changes in features and variations of features really have to be understood, the impact on the software, the electrical and the mechanical—altogether in a connected way. That brings up this notion of the digital thread, where all these things have to be correlated in a formal engineering approach.”

So, what is a digital thread?

Digital threads refer to the digitization and traceability of product “from cradle to grave.” The digital thread, says Krueger, “connects all the various capabilities in the digital twin back to the part designs, requirements and software that goes into the product represented by the digital twin.”

To Krueger, “digital thread” and “full traceability across a full lifecycle” are synonymous. Lind agrees. “Digital thread traceability is something people have been talking about for a long time.” Lind gives this example: Say a vehicle has a catastrophic accident that’s not the driver’s fault, such as unintended acceleration. “That is what the digital thread is intended to achieve: Have digital traceability across the lifecycle—end-to-end—all the way back to the model-based systems engineering capabilities, where the concepts for the vehicle were originally explored.”

Essentially, digital threads are a type of uber PLM system.

What does that have to do with PLM?

Painfully, automakers began realizing several years ago that PLM isn’t quite up to the task of managing data for the world of mechatronics, especially IoT.

PLM implementations have tended to be in engineering and manufacturing—not truly across the lifecycle of a product, according to Lind. PLM mainly supported mechanical design; it was never intended for mechatronic systems. As a result, the mechanical guys have product data management (PDM). Software developers have application lifecycle management (ALM).

Electronics and wire harness guys have electronic CAD or electronic design automation (EDA) software. These are islands of information themselves.

The cross-discipline complexity of mechanical, electronics, software and other engineering domains becomes super critical when working on the connected or autonomous vehicle, especially when representing a vehicle at the VIN-instance level. Jokes Lind, a digital twin is #NotCADonly.

Another problem is that while the major PLM systems, really PDM systems, developed in the 1990s, have since been optimized, it’s been done with bolt-ons. “They’re still fundamentally 1990s-style client-server technology that no one has taken the time, cost, or effort to fundamentally rewrite and reengineer from the ground up,” says Lind. These and heavily customized PLM systems are difficult to upgrade and, thus, evolve to an enterprise’s evolving strategy and process needs. 

All these issues are pushing the industry to upgrade PLM. As an alternative to the conventional “rip & replace” approach, Aras connects the various tools used for developing mechanical, electrical and software components to create a single cross-discipline data environment to support mechatronics. This connection is accomplished either directly or as an overlay to existing PDM/PLM/ALM/EDA/etc. systems. The result, says Lind, “is a digital thread that allows organizations to trace every decision made throughout the complete product lifecycle and connect these data back to the information the digital twin provides.”