A Digital Twin: What it is and Why you might want one.

If you do a search on the Internet for “Digital Twin” and then click on the Image tab, I can guarantee you that one of the first pictures you will see is a picture of an airplane Turbo motor and then a digital rendition of it. The general feeling one then gets is that a Digital Twin is, therefore, a Digital rendition of reality, where I can perhaps gain insights such as an imminent maintenance need, a temperature gauge that is too high, or a part that looks like it’s being shaken loose.

For me, it conjures up some sort of Minority Report images in my mind. I can see myself with my Augmented Reality gloves and glasses on, spinning the image in my hands, expanding the motor until I can see the problem and triumphantly spot the wobbly screw, and have people look upon me with amazement. It’s worth noting that I have seen projects with Augmented Reality that a getting closer to that vision.

Putting my wild fantasy aside, Digital Twins are all the craze right now, and I wanted to try and make a bold attempt to define what a Digital Twin can be for you and ask the question, “do you want one at all?”.

I’ve had the pleasure of seeing a couple of Digital Twins put into action, IOT sensors installed, Cloud solutions set up, and AI and ML put into action in several different sectors, including manufacturing, Smart Buildings, Smart Energy, and Smart Health. I’ve seen how things work and how things often do not live up to expectations, so my goal here is to give you my very personal view of what a Digital Twin is.

So, let’s go!

Let’s start by narrowing our perspective to Digital Twins in the Manufacturing world to create a Digital Twin on the Production floor.

Let’s assume then you have a discrete manufacturing production floor spinning out products using a combination of people, robots, co-bots, test machines, and Visual AI for inspection to be able to run your production cycle. Your factory is already producing a ton of data without even starting to think about Digital Twins. You have data around your Supply chain, incoming inspections, spare parts, returns, unfinished products, BOM lists, order lists, Quality and Assurance checklists, Failure Mode and Effect Analysis reports, track, and trace, actual products produced, shipment lists, well the list is long, and I will not try and attempt to mention them all. Then someone from management pops up and says, “we need a Digital Twin to make sense of all of this!”. Well, where do you start?

Most Digital Twin projects attack the problem from two different angles, the machines used on the production floor and the data that is produced from them. (Spoiler alert: they also forget something that is way more important).

Machines used on the production floor: I’ve seen many cases cited where Digital Twin projects are kicked off by adding a sensor to a machine to be able to detect an up-and-coming maintenance need. This would be a Digital Twin of an asset on the shop floor. Not a bad place to start as the feeling, in general, is, “well, let’s get going with something.”

The use case is the following: a critical machine is running 24 hours a day, and it may have a specific window of maintenance downtime, where you stop the machine, replace a spare part, tighten a screw, etc., and then kick the machine up and running again. This means stopping production as well for the maintenance of a machine that may or may not be needed. Often such stoppages lead to frustration and stress and lead to the conclusion of “let’s not stop for maintenance at all attitudes.”

This leads us to our Digital Twin use case: let’s put a sensor on the machine that measures vibration, sound, temperature, etc., let’s collect data from the sensor, and we can input it into a program that, if, say a sound above 110DB is reached, or vibration above a certain level or a temperature of a certain part of the machine is continuously over a certain degree, then we need to flag for maintenance. We are therefore learning about our machine through data collection, only stopping the machine when we need to. This is classified as Preventative Maintenance. Over time with enough data, we can then start detecting patterns in our data, and we can use, say, Machine Learning programming to detect that a failure is just about to happen. This is called Predictive maintenance.

The result, in general, is you are stopping machines because you know you have to, and not just because of some sort of general presumption that “we’ve always done it this way.” Not a bad place to start to be honest.

Data that is produced from production floor machines: Most production floors have several machines that produce data every second of the day, maybe, for example, the Test Analyser machine for a circuit switchboard, a machine producing metal parts around the clock, or simple handheld devices like Bar code readers or RFID card readers can also produce interesting data for production needs. In the context of a Digital Twin project, all these sources of data are usually referred to as “vertical data silos” and the wish to retrieve information from them.

For example, the machine producing metal parts is probably producing data in a very specific Software environment that perhaps one or two people have access to and understand the data. Bar code reader data doesn’t sound very exciting to the normal person. However, for the Quality Assurance Engineer, it could be producing information about the First inspection or tracking and tracing of production throughout the factory floor.

Vertical data silos usually stay siloed because they are attended to by specialized people with specialized needs. The argument for a Digital Twin here is the wish to integrate all “vertical data” into a Digital Twin and create a view of the data that is relevant to all types of needs in the organization. So, in this case, the purpose of the Digital Twin is to make data accessible to all and understandable by all. Furthermore, a case is argued that if you aggregate all types of data into one place, then you may be able to learn about trends over time. Trends about the Supply Chain or demand or, say, comparison of one factory in one location compared to another factory in another. This type of Digital Twin is a more difficult goal to achieve. Its main goal is to find new insights in combined data. One of the best ways to get going with such a Digital Twin strategy is to create dashboards combining your vertical silos.

I alluded to a third use case for Digital Twins that most tend to forget: Human Beings: In any Digital Twin use case, most allude to connecting machines and data, and use technology such as Machine Learning and AI, but more often than not they do not stop to mention the people who may be using the solutions or real people that are part of the inherent process of production. Machines or Digital Twins don’t make mistakes, but the people who design and build them do.

Do we need to therefore ask ourselves what the most important factor of your production floor is? Hopefully, your answer is the people working there every day. Where do these people factor into a Digital Twin?

The production certainly involves machines and robots, but also people running them and ensuring the product is built, ensuring set standards, certain steps are taken at every stage to ensure Quality, Failure analysis to ensure that the product has been built according to certain rules, etc. Most of these processes are set down in Work Instructions that are created for the Production line. So, another Digital Twin use case is digitizing Work Instructions, production processes, Quality Assurance tools, and such like.

You can go even further; why not digitize Worker Safety, Worker Certification, and your whole Quality Assurance process that can then automatically update your work instructions? Creating a Digital Twin of how your product is produced from entering the factory to exiting again (working the Gemba with your Digital Twin in mind) is a compelling use case that is often alluded to in the industry 4.0 paradigm shift. I like this type of Digital Twin best. Many Digitalization projects, unfortunately, don’t tend to think too much about the people who will use the data or reap the benefits from it. It seems obvious but unfortunately, in my experience, not.

Richard Savage works with Innovation at MTEK. Richard has worked on numerous IoT projects and Semiconductor solutions at Qualcomm. He has a long background in driving 3G and 4G solutions for the Telecom Industry and has worked with driving Cloud and Digital Twins at IBM as a subject matter expert. Reach out to Richard on LinkedIn to continue the conversation.