- UX for AI
- Digital Twin: The Essential UX for AI Analysis Tool
Digital Twin: The Essential UX for AI Analysis Tool
Digital Twin modeling is at the exact intersection where UX for AI Design can effectively demonstrate its incredible potential.
Digital Twin is simply a digital model of the real world that focuses on modeling the metrics and outcomes that matter most to a physical system. It happens to be an excellent model for UX Design of AI-driven products.
Joint Homunculus vs. He-Man
Consider He-Man, arguably the greatest example of American Marketing prowess. Move over Oedipus and Hamlet — here comes the Power of Grayskull!
Image Source: He-Man, Art by Alex Ross. He-Man. (2024, January 29). In Wikipedia. https://en.wikipedia.org/wiki/He-Man
Now if all we cared about modeling is arthritis, you would reduce He-Man, a complex and powerful character, to… a pile of aching joints, a Joint Humanculous:
For a doctor of arthritic medicine, He-Man is just a pile of joints. Joint Homunculus is a particular type of Digital Twin of He-Man.
We hope you see where we are going with this.
Let us demonstrate with a few examples.
Digital Twin of a Wind Turbine Motor
One of our favorite examples of Digital Twin is the Digital Twin on GE Haliade 150, a gigantic off-shore wind turbine, which Greg had a chance to work with closely while at GE. Unfortunately, it’s a bit too complicated to get into in this article in sufficient detail. We can, however, look at a much simpler model, that of a yaw motor. (For those who are not familiar with the three-dimensional navigational axis, yaw is the direction (such as “East” or “South”) in which the wind turbine is pointing. You can read about it here: https://www.machinedesign.com/learning-resources/engineering-essentials/article/21834526/whats-the-difference-between-pitch-roll-and-yaw )
So what we are dealing with here is the GE digital twin of one of the seven motors that control the direction in which the wind turbine is pointing:
Image Source: https://youtu.be/P36yJkE1zlM?si=vqXiH5uHfrputhsE
Whew. (Yes, some of this IoT AI stuff gets hairy. But our model will be simple, we promise!)
So what we have here is a relatively simple Digital Twin of a simple electric motor: it’s collecting only two measurements:
Input current (“electricity” sent to the motor)
Temperature of the motor
Using these two inputs, this digital twin is predicting just one thing: the remaining motor life.
Image Source: https://youtu.be/P36yJkE1zlM?si=vqXiH5uHfrputhsE
The basic idea behind this AI model is that the more motor temperature jumps when the motor is running, the less remaining life it has. Intuitively, this model makes sense – a bit like we would expect an old car to be prone to overheat when driving uphill. You can see the image of the motor coils in the model is red because it is overheating, and probably will need to be replaced soon.
While this model is obviously quite simplistic, it works pretty well for the intended purposes: to avoid having a crew of mechanics take a boat 50 miles off-shore in rough seas and climb up 150m (500 feet) up the sheer turbine mast in punishing 50 mile-per-hour winds in order to inspect the yaw motors… All while the turbine blades are spinning at 150 miles per hour!
Now given the pain and expense of sending the mechanics crew over for the yaw motor inspection, you might think that our Digital Twin is too simplistic: you could, after all, track other things like the speed of the motor (RPM), torque, and temperatures at various spots on the motor (like that of front and rear sets of ball bearings, electrical coils, mount, etc.) vibration of the motor shaft, power curve (how increase in current corresponds to motor power output), etc.
GE does monitor all of these things for other machines… Just not for this motor. Why not? Because likely yaw motor is a relatively cheap and reliable component, installed with more than triple redundancy (e.g., two motors are likely sufficient to rotate the turbine under normal circumstances, and GE installed SEVEN.)
So the TLDR is that our simple digital twin is both necessary and sufficient to monitor this motor. That is because other measurements are not essential to the operational aspects of the machine and to our use case. To paraphrase Einstein, Digital Twin needs to be as simple as possible but no simpler:
The power of creating a Digital Twin is the exercise in figuring out what is essential and not essential to include in the model and nailing down the use cases the model will deliver.
Digital Twin is an essential modeling exercise for designing AI-driven products
Digital Twin is an essential exercise in understanding and modeling. In that way, it’s a bit like the exercise of creating a persona: what does my persona care about or does not care about? Usability? Esthetics? Efficiency? Or Ease of Learning? Think of the Digital Twin creation in the same way but for AI systems. Digital Twin should include all of the aspects which drive operational control of the system and contribute to knowing which “knobs” to rotate and “buttons” to push.
Recall the old story of the four blind men and an elephant (from the Buddhist text Tittha Sutta https://en.wikipedia.org/wiki/Blind_men_and_an_elephant ): the person touching the tail thinks an elephant is like a rope; the one touching the ear thinks an elephant is like a fan, trunk reminds the third of a snake, etc.
How to Build a Digital Twin: an Example
So how do we go about building a Digital Twin model? The core of the process is pretty straightforward:
Understand what information is collected by the AI model sensors from the real world.
Draw a picture visually representing relevant aspects of the physical world
Label the picture with the incoming data
Figure out the use case and most valuable measurements that the model can predict
Note any missing incoming data and discuss with the team how the system can obtain the missing data
Consider which siloes you can break to get the additional data
Watch out for creepy data conclusions, like things that might affect insurance rates, loan eligibility, etc. Ethics Matter!
Remain humble. Remain curious. Iterate, iterate, iterate!
The last point is the most important one – you are about as likely to guess at the right model at the outset as one of the blind men to accurately describe an elephant by touching its leg! Let’s take, for example, the case of an Apple watch exercise tracker. The most important measurement that the watch is collecting is the person’s pulse and the duration of the exercise, so the first iteration of the digital twin might look like this:
IMAGE: human with heart pulse rate labeled and duration of the exercise.
Then you might recall that the Apple watch is connected to the iPhone, which collects data such as location GPS coordinates and elevation of each point of the exercise walk so that the next iteration of the Digital Twin might include a picture of the terrain with this additional data:
IMAGE: human with heart pulse rate labeled and duration of the exercise + terrain with GPS coordinates, distance, and elevation.
So, now that we know the inputs, what kind of things would this information let us compute? One thing we might quickly realize is that knowing the GPS location and elevation of each point in the walk would let us compute the work required to traverse this route, in other words, calories burned! Calories burned is very useful because it is a piece of information that in today’s weight-conscious world can help people achieve and maintain a heathy weight.
However, as many of our readers might point out, to do the calorie computation accurately, we also need to know the weight of the person (it is much less work to move a 50-pound child around the park than a 300-pound man… Six times less work, to be precise. http://labman.phys.utk.edu/phys135core/modules/m6/work.html#:~:text=As%20you%20are%20lifting%20the,the%20direction%20of%20the%20force )
However, we might not want to stop there. If, for instance, in addition to weight, we also know the age of the person, we can correlate the speed and exertion of the exercise and come up with a measure of the comparative fitness of the specific individual vs other owners of the Apple Watches around the world – in other words, we could tell people how their fitness measures up against others of the similar age (and affluence, one presumes, as Apple Watches are not cheap). People say they hate being compared but actually really dig these types of comparisons.
If we are also able to measure the number of steps and know the height of the person and the expected length of stride, we can additionally estimate how limber they are and detect any walking abnormalities, such as one leg being shorter than the other, knee and ankle injuries, the like. Using this additional input data, one could more accurately predict the lifespan of the individual. And if this is not already getting into an uber-creepy life and health insurance costs territory…
Wait, there is more!
Exercise is but one silo created by the Apple App Store. As we’ve already pointed out in our previous edition, Apps are Dead, which can be found here: https://www.uxforai.com/p/apps-are-dead. Apps create unnecessary slioes that do not share data with each other. If we truly want to unleash the next level of AI, we want to traverse multiple apps to gather data and build our digital twin model. For instance, we might recall that many people also wear their Apple watch while they sleep. And while this may be data that is collected in a different app, it is data that is collecgted about the same exact individual. If we approach the problem holistically, a very interesting new set of inputs becomes available to us: the quality and quantity of rest:
IMAGE: human with heart pulse rate labeled and duration of the exercise + terrain with GPS coordinates, distance, and elevation with a bed added, plus comparative fitness, length of stride, joint mobility, etc.
But why stop there? Combine it with other kinds of tracking that a typical iPhone can do, such as:
Spending money at the supermarket vs. going out to eat
Number of hours per day of driving commute
Neighborhood location (plus crime, air pollution, noise, etc.)
What kind of music you listen to (and how many times a day)
Screen time (how much time you spend doom scrolling)
Data from DNA trackers like 23 and me
Data from your calendar to track your social connectedness
You can see where we are going with this: using this data, you can have a pretty complete picture of the person’s predicted life span, athletic performance, health problems, the likelihood of ending up in assisted living, the likelihood of early death, and… Oh, so much more.
Should you collect and model this data? As in the case of the wind turbine yaw motor we discussed earlier, it depends! It depends on what we are trying to predict and what types of data the humans who own these devices will allow to be shared in order to gain the specific insight your Digital Twin provides.
These discussions lie at the heart of technological, human, and ethical considerations of our age.
Happy Digital Twin modeling!
Greg Nudelman & Daria Kempka (Contributing Editor)