Fields marked with a * are required

SIGN UP FOR OUR NEWSLETTER

The Siemens PLM Vision: Creating A Complete Digital Twin of the Product

References Cited

Electrical Computer Aided Design (ECAD), Mechanical Computer Aided Design (MCAD), Mechanical Computer Aided Engineering (MCAE), Model Based Development, Model Based System Engineering (MBSE), Product Data Management (PDM), Product Lifecycle Management (PLM), Routed Systems Design (RSD), Siemens PLM

Last week, Siemens PLM held their annual analyst event in Boston to give us some insight into their top-level vision. After two and a half days of presentations from various executives, there is a lot of information to process. There were several high-level themes in this vision, but none is more important that this: creating a Digital Twin of the Product. Of course, the phrase Digital Twin has been bandied about by several software providers. However, I truly believe this one is different.

In this post, we’ll dive into Siemens PLM’s vision for creating the Digital Twin of a Product, step by step. But first, let’s get on the same page by defining the phrase Digital Twin.

What is a Digital Twin?

The concept behind the term Digital Twin is twofold. The first is to create an accurate and up-to-date digital representation of a physical product. The second is to take data from the physical product, most often from sensors, and use that as an input to the digital representation, perhaps even utilizing digital simulations. The result here is that the digital representation accurately mimics the behavior of the physical product, even remotely.

Digital Twins can be used for a variety of purposes. It can be used to monitor products remotely. It can be used to predict product failures. It can be used to gain insight for future product development efforts. The applications here are almost endless.

How do you create a Digital Twin? We touched on it only a moment ago. Create a digital representation of the product. Collect data from the physical product and plug it into the digital representation.

Now, let’s talk about how Siemens PLM does (and does not) do this.

A Complete Digital Definition of the Product

There are many different aspects of a product that needs representation in a product’s Digital Twin. So let’s go, step-by-step, and examine how Siemens PLM’s offerings support these aspects.

Mechanical Hardware

When it comes to designing mechanical hardware, and thereby creating one aspect of the product’s Digital Twin, Siemens PLM has a wide range of solutions. NX is the core here as the CAD and CAE application. It provides Parametric, Direct and Facet Modeling thanks to Convergent Modeling capabilities. There is a plethora of simulation tools here in the Simcenter suite, including NX NASTRAN capabilities, Virtual.Lab from the LMS acquisition and the STAR and HEEDS products from the CD-Adapco. Analysis capabilities can be correlated to test results with the Test.Lab offering from the LMS acquisition. Teamcenter can manage practically all of these artifacts, but also provides material management capabilities. In all, Siemens PLM has a very robust set of capabilities to create the mechanical hardware aspect of the Digital Twin.

Electrical Hardware

Before March 2017, Siemens PLM’s ability to create the electrical hardware aspect of the Digital Twin was severely lacking. But that all changed when they acquired Mentor Graphics. Mentor, now run as a Siemens business, has an incredibly broad set of tools to design electronic hardware. Xpedition is a single and multi Printed Circuit Board (PCB) design, simulation and data management suite. An expansive set of tools are available for Integrated Circuit (IC) design and manufacture. Capital is their electronics system and wire harness design suite. Note that there are not only powerful design capabilities in each of these applications, but also deep verification capabilities as well. Mentor’s depth in the realm of electronics design matches Siemens PLM’s depth in the mechanical field.

On-Product Software

When it comes to developing on-product software, one of the biggest challenges is ensuring that your application will run on its target electronic hardware. Here, the LMS acquisition provides a solution in the form of Imagine.Lab, which allows organizations to run a Model Based Development methodology that supports software-in-the-loop, hardware-in-the-loop and more.

In terms of actually developing code, a variety of software applications from the Mentor acquisition support the development of software for various Real Time Operating Systems (RTOS) and chipsets that are typically associated with embedded software and control systems. You see various Integrated Development Environments (IDEs) here as there are many different combinations of RTOS and chipsets, each requiring their own compilers and tests. There are also development tools available to create User Interfaces, going beyond control systems.

Creating a bunch of code, however, isn’t all there is to developing on-product software. Software Configuration Management (SCM) capabilities are provided by Polarion. This allows organizations to manage the complex configurations of on-product software within engineering teams. Polarion also provides Application Lifecycle Management (ALM) capabilities to run change processes, manage requirements, control unit tests and much more.

The capabilities across this aspect of the Digital Twin is deep, however, they come from a variety of acquisitions. There is some integration here, but not deep ones. More on that in a moment.

IoT Connectivity and Off-Product Software

Today’s products are mechatronic in nature, meaning they are a combination of mechanics, electronics and software. However, with the advent of the Internet of Things (IoT), they are becoming so much more. Products are now streaming data from their sensors to databases in the cloud, where that information is analyzed and used to predict a number of things.

In this domain, Siemens PLM capabilities to connect a product to the internet lies in Mindsphere, their open Platform-as-a-Service (PaaS). This offering allows manufacturers to quickly and easily connect the sensors on their products to the platform, allowing them to stream readings to the cloud. This same platform allows users to create MindApps, small software applications that do specific things or provide specific insights. MindConnect products are items that can be purchased that already have the ability to connect to the Mindsphere platform, streaming data almost out-of-the-box.

Systems

The complexity of today’s products are only growing. The good news is that system engineering can help tame it.

Keeping track of which thing should do what is an important part of developing products on schedule. In this regard, Siemens PLM’s Teamcenter offers capabilities to manage the Requirements, Functions, Logical, Physical (RFLP) aspects of a product. This essentially means that requirements are broken down and associated with generic functions, which are broken down and related to logical items when are then allocated to physical components, which can be hardware or software. Teamcenter’s capabilities provide engineering teams traceability from one end of this network all the way to the other. As a result, the entire organization gains visibility into the implications of changes, from one end or the other.

Of course, system design is fundamentally an engineering process. That means there is lots of iteration and exploration to determine the best architecture, meaning the right mix of hardware and software, to fulfill requirements. Siemens PLM’s Imagine.Lab, which came as part of the LMS acquisition, allows engineers to build up system models and simulation their performance. Using this approach, system engineers can try out different architectures for the product and understand the impact.

Takeaways on Digital Definitions

Stepping back, it is clear that Siemens PLM has the most complete, if not absolutely complete, offering to create the Digital Definition of a Product. There may be some holes here and there, but they are small, with most of the needs to create a complete Digital Twin covered.

So where is the drawback? Integration. There is widespread coverage, but not all of these products work well together. Do all of the Mentor software development IDEs seamlessly integration with Imagine.Lab? No. Does Teamcenter’s system engineering RFLP definitions completely work with Imagine.Lab’s system modeling and simulation? No. There are various spots where tight handoffs between these offerings could add tremendous value. But here’s the deal: they’re working on it. For example, Siemens PLM recently announced seamless associativity in passing PCB definitions back and forth between Xpedition and the 3D model in NX. Look for these gaps to close over time.

Connecting the Digital Definition to the Physical Definition

So far, we’ve talked about creating a complete digital representation of the product. However, there is one other aspect that it takes to create a Digital Twin: connecting that digital representation to the physical product. Pulling data from sensors on the product is relatively easy with Mindsphere. That information can be streamed to the cloud. You can have MindApps that provide some insight into the data. There is great value there.

However, that doesn’t equate to a Digital Twin.

To complete a Digital Twin, streaming data from the product needs to be connected back to its digital representation in real time. When that real time input is combined with simulations, such as system model simulations, that can emulate product behaviors where you don’t have sensors, then your Digital Twin is accurately mimicking the physical product.

Siemens PLM has many of the components to make this work. Imagine.Lab system simulations can fill the gaps as well as reduced order Simcenter analyses. However, these would need to run in the cloud so they can accept sensor readings as inputs in real time. The potential is there, but I can’t say that the Digital Twin, at least as I have defined it, has been fulfilled.

By the way, Siemens PLM is in many ways closer to fulfilling this vision more so than any other company.

Summary and Takeaways

  • Siemens PLM offers the best means of capturing a complete digital representation of a modern product across mechanical hardware, electrical hardware, on-product software, IoT connectivity, off-product software and systems. Note that there is tremendous value in this fact alone.
  • Creating a Digital Twin means marrying that digital representation to the sensor data coming off the physical product as well as a simulation than can fill in the gaps. Siemens PLM is very close, but lacks some capabilities in this regard. Note that no company offers a comprehensive means of accomplishing this today.

Alright folks. Those are my thoughts. Let me know your feedback in the comments. Looking forward to the discussion.

 

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

Fields marked with a * are required

SIGN UP FOR OUR NEWSLETTER

  • Dennis Nagy

    Excellent article, Chad. You have done a great job of decomposing the term “digital twin” into its component parts/requirements and indicating how Siemens PLM has most of the necessary technology and products to allow end-user enterprises to creat and beneficially use digital twins.

  • Ryan

    I agree with Dennis. Great breakdown of term “digital twin”. The future will tell when/if SPLM can get patch the holes and get the integration completed.

  • Well written article as usual.

    I have a question about your digital twin description.
    “accurate and up-to-date digital representation of a physical product”
    I agree and have no additional comment here.
    “take data from the physical product, most often from sensors, and use that as an input to the digital representation”
    This is where I have a question.

    I do not disagree that the information collected by sensors on the physical object has huge opportunities for companies; however, I struggle to see it as part of the digital twin. There is no doubt that they are related but I see them as two different “items.”

    Digital Thread – The connection of digital artifacts which can pier in the past (as-was) and answer the why questions (why does this part have these specs, why was this design this way, etc.)
    Digital Twin – the “exact” replica of the physical object including their logical relationships as well as the digital deliverables for manufacturing/fabrication/etc.
    Digital Vitals (just making something up) – the collection of sensor data throughout the lifecycle of the object.

    I am not one to make more acronyms or want more marketing buzz words, but I have usually been saying and writing that the IoT will leverage the Digital Twin not the Digital Twin contains IoT. Might be semantics but thought I would put out the comment to see your thoughts.

    • Hey Dennis. Sorry for the late response.

      In the end, this is all semantics. Understand the purpose and context is the important point here. I think you understand what I’m saying here.

      As far as this specific terminology goes, PTC and Siemens both offer this same definition: using sensor data plugged back into a complete definition of the product produces a digital twin of the product. That digital twin emulates the real-world behavior of the physical product in operation. So…

      Great question. I don’t have really strong feelings what terminology is used, as long as it is consistent and clear.

      • Thanks very much for your thoughts. Sometimes it is good to hear I am not missing something obvious.