Skip to content

Device twins

What Device Twins Are

Device twins (often called digital device twins) are software representations of physical devices — like EV chargers — that mirror each device’s identity, configuration, status, telemetry, and history in a backend system. A device twin is the “single source of truth” for what the charger is, what it’s configured to do, and what it’s currently doing.

Why Device Twins Matter

Device twins make large fleets of connected chargers easier to operate, secure, and improve over time:
– Centralize device configuration and reduce manual setup errors
– Enable faster troubleshooting with full status + event history
– Support predictive maintenance using telemetry trends
– Make firmware rollouts safer with clear device state tracking
– Improve reliability by detecting anomalies early
– Provide auditable records for compliance and incident response

What a Device Twin Typically Contains

A good device twin includes both static and dynamic information:

Identity: serial number, charger ID, model, hardware revision
Ownership and site mapping: operator, location, site group, installer
Configuration state: OCPP settings, power limits, access rules, tariff profile
Connectivity: online/offline, signal quality, IP/network, last heartbeat
Operational status: availability, fault codes, connector states, session activity
Metering and energy data: delivered kWh, counters, diagnostics readings
Firmware and software: current version, update channel, update history
Security state: certificates, provisioning status, last auth event
Logs and events: alarms, resets, exceptions, technician actions

How Device Twins Work in Practice

Device twins are usually maintained by a CPMS or IoT platform via:
– Device telemetry uploads (heartbeats, measurements, error events)
– OCPP messages and transaction records
– Configuration sync (desired state vs reported state)
– Backend rules that update twin fields when events occur
A common pattern is:
Desired state: what the backend wants the charger to be configured as
Reported state: what the charger reports it currently is
Drift detection: alerts when reported state differs from desired state

Use Cases in EV Charging

Device twins support many practical charging-operator workflows:
– Remote commissioning and configuration at scale
– Site-wide depot power management and load group control
– Detecting repeated faults on a specific hardware revision
– Benchmarking uptime and utilisation across locations
– Coordinating safe OTA firmware updates with rollbacks
– Warranty and service management (proof of errors, timelines, usage patterns)

Best Practices

– Define a clear schema: what fields exist, update frequency, ownership
– Track desired vs reported state and alert on drift
– Store event history with timestamps (not only “current status”)
– Keep identity and security fields immutable or tightly controlled
– Integrate service workflows (tickets, RMA, technician notes)
– Ensure data privacy compliance for user-identifiable session data

Common Pitfalls

– Treating the twin as “just telemetry” and ignoring configuration state
– No versioning → hard to know what changed and when
– Inconsistent identifiers across CPMS, ERP, and service systems
– Too much raw data without actionable alerts and KPIs
– Not handling offline scenarios (delayed reporting, missing events)

Digital twins
Device provisioning
Charge Point Management System (CPMS)
Charger diagnostics
Remote monitoring
OTA firmware updates
Intrusion detection
Secure update pipeline