EV charging operator dashboards: how to design them

A charge point operator dashboard has three jobs. Keep chargers working. Fix a driver's problem while they are standing at the charger. Prove uptime and revenue to the site hosts, funders and regulators who ask for it. The first job tends to get the design attention. The other two are where operators lose time and drivers lose patience.

We have written about energy dashboard patterns in general and what makes energy products different. Drill-down, freshness and alert suppression all apply here, so this piece does not repeat them. It covers what is specific to EV charging.

Who opens it

• Operations watch the network and want to know which connectors are down and why.
• Driver support take calls from someone in a car park and need one charger's story in seconds.
• Field technicians need to know what was already tried remotely, and how to find the unit.
• Site hosts and finance want sessions, energy delivered, revenue and uptime per site, by month.

One data model, four default views. The rest of this piece is about what goes in them.

1. Design the status model before the screens

Most chargers speak OCPP, and OCPP 1.6 defines nine connector statuses: Available, Preparing, Charging, SuspendedEVSE, SuspendedEV, Finishing, Reserved, Unavailable and Faulted. They are protocol states. Shown raw, they are hard to scan, and several of them mean very different things to an operator.

Group these into a handful of states a person can scan: free, in use, needs attention, out of service. Then add time in state, which is where most of the real signal is. A connector in Preparing for a few seconds is normal. The same connector in Preparing for ten minutes is a driver getting frustrated, and no fault code will tell you that.

Expect hardware to disagree with the spec. Manufacturers implement OCPP differently, and some report Preparing instead of Finishing when a session ends. Map statuses per charger model, and keep the raw status one click away for the technician who needs it.

2. Make the connector the unit

Sites have several chargers, and chargers often have more than one connector. A site that shows "4 of 6 available" hides whether the two missing connectors are in use or broken. Monitor, report and fix at connector level, then roll up.

Rank the list by impact, so a fault on the only fast charger at a busy site comes above a fault at a quiet one. A map is a good way in when the network is spread out. It works badly as the only view, for the reasons in our dashboard patterns piece.

3. Report uptime the way you are judged on it

Uptime is the number that site hosts, funders and some regulators will hold you to. Each of them can define it differently. In the US, the federal rule for chargers funded under the NEVI programme requires each port to average more than 97% uptime a year, calculated monthly over the previous 12 months. It excludes outages caused by utility interruptions, vehicle faults, scheduled maintenance, vandalism, natural disasters and hours outside posted operating hours, as long as the operator can show the port would otherwise have worked.

That last clause is a design requirement. If you want to exclude an outage, you need evidence that it was excluded for a real reason, captured when it happened. So:

• Put a cause on every outage at the time it is closed, from a short fixed list that matches your definition.
• Attach the evidence: a utility notice, a maintenance ticket, a vandalism report.
• Show raw uptime and adjusted uptime side by side, per connector, so nobody suspects you are hiding the bad months.
• Say which definition a number uses. A site host contract and a federal programme may not count the same outages.

4. Give support a session timeline

When a driver calls to say the charger will not start, support needs to find that connector fast. Let them search by the ID printed on the unit and by the driver's phone number or card. Show the last few sessions as a timeline: plug in, authorisation, start, power over time, stop, and the stop reason.

A "broken charger" call can turn out to be a failed authorisation, a payment problem or a car that has stopped accepting power. A timeline shows which one in a few seconds. A table of raw log lines takes minutes, and the driver has already left.

Remote actions belong on that screen, with care. Unlocking a cable, restarting a charger or stopping a session can end someone else's charge. The confirmation should name the connector, say whether a session is running, and say what will happen to it.

5. Turn faults into work orders

Separate faults that can be fixed remotely from faults that need a site visit, and record what was tried. A technician who drives to a site to do a reset that support already tried has lost half a day.

The work order should carry what a technician needs on arrival: the charger and connector, the fault history, what was tried remotely, and how to find the unit. In a multi-storey car park, "level 2, bay 14" matters more than a pin on a map. Close the loop by asking for the outage cause on the same screen, so uptime reporting is right without anyone filling in a spreadsheet later.

6. Make sure drivers see what you see

Drivers never see your dashboard. They see your status and price in your app and in third-party apps through roaming. The same US rule requires real-time status and price for each port to be available free to third-party developers through an API, in terms defined by OCPI 2.2.1, the roaming protocol.

So your internal status model and what drivers see have to agree. If your dashboard says a connector is out of service and a roaming app still shows it as available, someone drives to a broken charger. Give operators a "what drivers see" view per connector, showing the public status and price, so the gap is visible before a driver finds it.

Reporting for site hosts and finance

Sessions, energy delivered in kWh, revenue and uptime per site, by month, are the basics. Define utilisation on the page. Time with a car plugged in and time actually charging are different numbers, and the gap between them is the idle time a Finishing status measures. Hosts deciding whether to add chargers, and operators deciding on idle fees, need to see both.

What we took from NGX

On NGX, Trace monitors solar, wind and EV systems on a live map, as one of three products we designed in a single design language. When charging sits next to generation assets, each asset type needs its own measures, and they all need one vocabulary for health, so "needs attention" means the same thing on an inverter and on a charger. That is the same idea as the status model above, applied across a whole platform. It is what we bring to every energy product we work on.

Before you ship, check

• Raw OCPP statuses map to a few plain states, per charger model.
• Time in state is visible, and stuck sessions raise a flag.
• SuspendedEV never counts as a fault.
• Every outage has a cause and evidence, and raw and adjusted uptime sit side by side.
• Support can find a connector by its printed ID and see a session timeline.
• Remote actions name the connector and the session they will affect.
• Operators can see the status and price drivers see.

Sources

• OCPP 1.6 ChargePointStatus enumeration (the nine status values)
• Flipturn, Understanding OCPP statuses (plain-language definitions of each status, SuspendedEV vs SuspendedEVSE, manufacturers reporting Preparing instead of Finishing)
• 23 CFR 680.116 via Cornell LII (97% average annual uptime per port, monthly calculation over the previous 12 months, excluded outages and the "would otherwise be operational" condition, real-time status and price via API in OCPI 2.2.1 terms, free of charge to third-party developers)
• Anyday NGX case study (Trace monitors solar, wind and EV systems on a live map; three products; one design language)
• Anyday, Energy data dashboard design (map as a way in but not the only view; drill-down, freshness and alert patterns referenced, not repeated)
• Anyday, Designing for energy and renewables (irreversible actions, field conditions)