Back in the days we used to test with simulators. The test systems unavailable or too scarce for our needs would be replaced with replicas that were not quite the real thing, but also allowed breaking the real thing intentionally in ways that real things would break accidentally. Then something changed, or is it just word play: people now talk about digital twins. Are they essentially the same thing? It it just fancier words to talk about a solution we’ve had around for ever?
Are there folks here who would happen to have experiences with digital twins for physical world embedded systems?
We have created a digital twin (power simulator) using docker that replicated the device behaviour for us.
Additional context:
We built a digital twin of an embedded device using Docker and not just a simulator that mocks APIs, but a full replica running the same software stack, exposed at an IP just like the real device would. It let us test the actual behavior of the device before the hardware was ready, which was a huge win for parallel dev and test.
Simulators usually fake specific parts, but this setup felt closer to the real device and more accurate, flexible, and safer to break.
Once the actual device was available, we switched over, but the digital twin gave us a good head start. So yeah, it’s not just wordplay, it’s a meaningful upgrade in how we test embedded systems.
A digital twin is a highly consistent, software-based replica of a physical system that runs the same software, behaves like the real device, and can be interacted with as if it was the real thing.
Unlike traditional simulators that mock specific parts or APIs, a digital twin mirrors the actual device’s environment, allowing for realistic and early testing even before the hardware exists.
It’s like having a stand-by for your device that you can test, break, and explore without needing the physical hardware on hand.
We did a simulator with these features for embedded yocto + our software in our project, but I would not have qualified it as digital twin. Real hardware comes with complexities that none of the digital counterparts come with, even if we put in more of the stack inside.
However, from your story I take that 1) my concept of simulators is more versatile 2) my model of twinning complexity is high.
When the hardware is needed in scales that prevent having ones own, these were really useful. We had virtual weather stations. However, when testing larger physical systems, things became complex. We could not find a virtual way of shooting balloons up in the air to move over the atmosphere, or scan the closest 200 km radius with all kinds of safety features.
I went and revisited time I used a digital twin, basically a high fidelity simulator, and reflected on the things we missed while simulating:
we learned our real devices did not support subzero temperatures only with a real device in the backyard - the discipline to take control of the data was too much for us even though the theory is that you can be intentional while simulating
we learned there was no digital twinning for solar panels which the real device had; put it on a rock somewhere in Finnish summer conditions and it dies out with a few cloudy days. We overestimated the sun until we went from twins to real deal.
similarly, we did not take the twins around like we did the real, and roaming in connectivity globally as a service has dimensions I can now speak of, but had no clue before - turns out configurations of packet sizes matter and it gets very complex when you bring in the world your digital twin does not include
birds produce a lot of excrement that has features, that impacts the system; their aim is also brilliant in all its randomness.
try updating a thing on a rock in middle of ocean over wire to learn you missed a system feature that means the thing is now unavailable for 24 hours. Oops. Not visible with the twin.
So I concluded my digital twin research by creating my pirate twin, just for the fun of it. Useful yet incomplete.
My favorite pieces of testing embedded are still the price and size of toys, artificial sky and taking test environments to shower. Good times.
So in terms of OS computing for an analogy, a digital twin is a virtualized hardware/system?
and digital twins only apply to hardware that has a software interface or API, or otherwise input/output connections that use digital transmission and protocols? I don’t see how you have digital twin if the interface on the device is all analog or hardware otherwise.
In other words, the digital twin has the same DNA as the real twin. So when you test the digital twin, you are actually testing the DNA of the real twin.
Talked about digital twins at an event today, and learned that for example city of Helsinki has a digital twin. It is more than the software that would run without hardware, it is a separately built replica with control over data that they are interested in testing - air pollution levels, traffic and congestion data. Some use cases they have used these on are on physical accessibility and measuring / designing accessible routes and guidances, and introducing new services to the physical infrastructure seeking interaction problems.
“Quite simply, a digital twin is a virtual model of a process, product or service." - Bernard Marr
in a different body.