A remote monitoring requirement is not met by a charger alone. It is met by a pairing: chargers whose listings state a protocol version, connected to a platform that surfaces status, faults and session records. So a project specification has to name three things — the functions required, the protocol evidence the hardware must show, and the proof produced at commissioning. Write only the first and the requirement is a wish; write all three and it is testable.
Key Takeaways
- A monitoring requirement is a pairing: stated protocol on the hardware plus a platform that surfaces the records.
- Write every requirement as function, wording and commissioning evidence — all three.
- “OCPP-ready” does not meet a requirement written as OCPP 1.6J; close the phrase in writing first.
- EVDANCE operates no platform; its listings state the protocol claims the platform contract must match.
The Requirement Table: Function, Wording, Evidence
| Monitoring function | How the specification words it | Evidence produced at commissioning |
|---|---|---|
| Live status and availability | Each charger reports its state — available, charging, faulted, offline — to the platform continuously | A platform report per unit from the commissioning tests, filed against its serial number |
| Fault codes and alerts | Faults are reported as codes with timestamps and routed as alerts to named recipients | A raised test fault on each unit, shown arriving with its code and alert |
| Session and energy records | Every session is recorded with start, stop and energy delivered, per charger and per credential | A completed test session on each unit, exported in an open format |
| Remote actions | The platform can start, stop and reset a charger remotely, and push configuration changes | Each action demonstrated once per unit type and logged; unsupported actions are struck from the requirement, in writing |
| Access records | RFID or app authorisations are logged against the credential that used them | A test charge on each access method, matched to its record |
| Uptime reporting | Availability is computed from the platform’s records over a stated period, in a stated format | The first report run at handover, showing the computation the contract will rely on |
The pattern matters more than any row: function, wording, evidence. A function named without evidence wording will be argued about at handover; evidence demanded without a named function cannot be failed fairly.
The Protocol Line Decides Whether the Table Is Real
Every function above travels on the charger’s connection to the platform — the pairing our OCPP explainer for charge point operators sets out. That makes the hardware-side line of the specification decisive, and it is a line about stated words. A requirement written as “the charger shall implement OCPP 1.6J” is met by a listing that states OCPP 1.6J, and not by one that says “OCPP-ready”: “ready” names no version, cites no certification and names no tested pairing. Either close the question in writing before the order — version, certification evidence, named tested platform — or write the requirement around hardware that states its version outright.
The sequence runs in one direction: the functions are specified here, configured when the site is built, and proven at commissioning, where the evidence column is produced unit by unit before sign-off. Specifying with that end in view — which report, which export, which test fault — separates a monitoring requirement from a monitoring hope.
The Hardware Side: What EVDANCE Listings State
EVDANCE manufactures chargers; it does not operate a monitoring platform, so the platform half of the pairing is the project’s own contract. The hardware half is stated per model. The EV-AC03201T dual-connector AC station (two Type 2 connectors, up to 43 kW shared, RFID, IP54) states OCPP 1.6J, as does the EV-RHDC30K-L compact DC charger (22 kW DC, IP54) — named versions a specification can be written against. The EV-ACS3210E states app control with energy monitoring and is described as OCPP-ready: its app figures are a local record, and the platform pairing is the written confirmation to close. Project teams can put a planned pairing to our commercial charging team or contact us before the specification freezes.
Frequently Asked Questions
Does EVDANCE supply the monitoring software?
No. EVDANCE is the hardware manufacturer and operates no platform. Monitoring duties sit with the platform the project chooses; EVDANCE’s side is the stated protocol on each model and the written pairing confirmation for a planned platform.
Can a charger with no stated protocol still be monitored?
Not on paper. Monitoring needs a networked unit paired with a platform over a stated protocol. A model whose listing names no protocol has no monitoring story to specify against, and a “ready” phrase must be closed in writing first.
What belongs in the commissioning evidence for monitoring?
One artefact per function, per unit: a status report, a raised test fault with its alert, an exported test session, and a demonstration of each remote action the specification kept. Filed against serial numbers, that pack is what the operating contract argues from.
Related Reading
- OCPP Explained: What Charge Point Operators Need From EV Charger Hardware
- Commercial EV Charger Maintenance Checklist
- How Do Commercial EV Charging Stations Work?
- RFID and User Management for Shared EV Chargers
