Digital Twins Explained: How I Built a Smart Vehicle Twin

A digital twin is a software model that mirrors a physical object in real time. Every reading from a sensor, every state change — reflected in the model as it happens.

Why Vehicles?

Vehicles are interesting because they generate enormous amounts of telemetry that almost nobody uses. Speed, RPM, fuel consumption, temperature, tyre pressure — all of it sits unread on an OBD-II port or disappears into a black box.

A digital twin changes that. The data becomes queryable, analysable, and actionable.

The Architecture

The system has three layers:

Ingestion. An MQTT broker receives telemetry from the vehicle (simulated in my prototype). Messages are time-stamped and written to InfluxDB — a time-series database designed exactly for this kind of continuous stream.

Storage and query. InfluxDB lets me ask questions like "show me fuel consumption over the last 500km" or "flag any RPM readings above threshold." Time-series queries that would be slow in Postgres are instant here.

Visualisation. Grafana sits on top, pulling from InfluxDB to render dashboards. Real-time panels. Alert rules. The kind of thing a fleet manager actually wants to look at.

The Interesting Problem: Anomaly Detection

Static thresholds are brittle. A "high" temperature reading means different things at different ambient temperatures, different loads, different ages of vehicle.

I moved to a rolling baseline approach — compare current readings against the trailing average for this vehicle, not against a fixed number. This catches genuine anomalies while ignoring expected variation.

What a Production Version Would Need

The prototype simulates data. A real version needs a reliable hardware interface, encrypted telemetry transport, and careful handling of connectivity drops — vehicles go through tunnels.

The software problem is interesting. The deployment problem is harder.