Live · CAN Bus Telemetry
OCPP reports the failure.
The CAN bus announces it.
How Stackbox reads the charger's CAN bus data through its own controller – sensor readings, charging power, and status from the same source – and surfaces component faults before the first driver pulls up to a dead charger. No extra box. No vendor portal.
Animated view of tapping the charger's controller: CAN messages are read passively, decoded into named signals, correlated with charging power from that same source and condensed into a finding – here a temperature drift of power module B2 at constant load. All values are illustrative.
01 · Challenge
The CPMS knows two states: running and broken.
Anyone operating a fast charging network knows the gap: the platform reliably shows that a station is down – but never that it is about to go down. Between available and faulted there is no state left in which you could still act.
OCPP has no in-between state
StatusNotification gives you Available, Charging, Faulted. No component, no history, no early stage. The message arrives the moment the damage is already done – and usually with a driver already standing there.
Silent power derating
A site reports itself as available but delivers only a fraction of its rated power. No fault shows up anywhere. It surfaces only as longer charging times, falling revenue, and complaints nobody can trace back to a component.
One portal per manufacturer
Every hardware vendor brings its own service portal, its own logins, its own vocabulary. In a mixed fleet that produces extra work rather than a shared picture – and nobody compares sites across manufacturers.
Truck rolls without findings
The technician drives out, finds nothing or replaces the wrong part, and drives out again next time. Every trip costs time and money, while the actual root cause stays hidden until it strikes again.
OCPP is an operations protocol, not a diagnostics protocol. It was designed to control and bill charging sessions – not to describe the condition of power modules, cooling circuits, and contactors. That data already exists: it sits on the station's internal bus. It just never leaves it.
02 · Solution
No extra box. The controller already knows.
Stackbox taps the charger's own controller and reads the CAN bus data there – sensor readings as well as charging power, duration, and status. That turns into a finding maintenance teams can actually act on: no additional hardware on site, no interference with charge control, no vendor software.
Tapping the charger's controller
The charger's controller already sits on the internal CAN bus and knows its messages. Stackbox reads them there, passively: power module temperatures, cooling circuit, DC contactor switching cycles, insulation monitoring, fan speeds. Listening rather than intervening – charge control stays untouched, and no extra hardware goes into the cabinet.
Normalising across manufacturers
Every vendor encodes its messages differently. A mapping layer translates vendor-specific signals into one shared model – the same metric means the same thing, whatever hardware stands on site.
Correlating inside one source
A temperature reading on its own says little. Only together with charging power, duration, and status does it become a statement: too warm for this load. Both come off the same controller – no second system to query, no timestamps to reconcile.
Trends instead of fixed thresholds
A fixed threshold fires when it is almost too late. So the system watches the trajectory: a module running steadily warmer at the same load over weeks raises a flag – long before it derates.
Findings in the workflow, not in a dashboard
Anomalies land as tickets in the existing service system, with site, affected component, and a recommended action. The visit gets planned and carried out with the right spare part – instead of reactively, and twice.
System Architecture
Capture · Normalise · Correlate
Integration
03 · Impact
What actually changes in operations.
A network that reports faults becomes a network that announces them. That shifts more than uptime – it changes how maintenance works, from reactive to planned.
Daily, hourly, by the minute – how often the data is monitored and evaluated is freely configurable
vendor portals the service team has to operate in parallel
continuous condition capture instead of spot checks at service intervals
shared signal model across every manufacturer in the fleet
power derating is caught before it comes back as a complaint
findings flow straight into the existing ticketing and operations stack
We used to find out a charger was down when a customer called. Now we see the anomaly while the charger is still running – and we schedule the visit instead of racing to it.
Stackbox · Condition Monitoring
Facing something similar in operations?
We look at what your hardware already reports today – and how much of it never leaves the station.
Let's talk →