EV Charger Vendor Technical Evaluation
The most useful thing to establish about a charger vendor is not what their product does. It is whether they built it. A supplier who assembled another vendor's control card and firmware can tell you what they supply and nothing about why it is behaving oddly two years later.
This is what we look at when we evaluate a charger vendor on a customer's behalf. It is weighted toward capability and longevity rather than toward specification, because specifications are easy to write and capability is what you need when something goes wrong.
Scope a vendor evaluationFor Procurement, consultant, CPO, investor
What gets examined
Swipe to compare
| Dimension | The question behind it |
|---|---|
| Architecture | Is the design coherent, or a collection of modules with no owner? |
| Protocol behaviour | Does it interoperate with your platform, verified rather than claimed? |
| Firmware practice | Can it be updated safely at scale, and rolled back when a release is bad? |
| Diagnosability | Can a fault be identified without a site visit? |
| Serviceability | What is repairable, by whom, with what parts? |
| Supply exposure | Single sourced components, and what happens when one goes obsolete? |
| Compliance evidence | Do the certificates cover the configuration actually being sold? |
| Engineering continuity | Does the team that designed it still exist? |
Specification sheets and what they omit
A specification states capability under conditions the vendor chose. It rarely states behaviour under the conditions that produce field failures: connection loss mid-session, supply voltage at the edge of tolerance, thermal load at the top of the ambient range, or a firmware release that has to be withdrawn.
Asking for those behaviours in writing is itself informative. A vendor who can answer has thought about them.
Certificates cover configurations, not products
A certificate applies to a specific configuration at a specific revision. Verifying that the certified configuration matches the unit being quoted, including its critical components and firmware, is a routine check that is routinely skipped.
Continuity risk
Charging hardware is a long-lived asset attached to a short-lived vendor landscape. The practical questions are whether firmware will still be maintained in five years, whether spares will exist, and whether anything protects you if the answer becomes no. Escrow and source access arrangements exist for this, and are worth raising before award rather than after.
Where we declare our position
RIOD builds chargers, which makes us a potential competitor to any vendor being assessed. Where that is a conflict for you, the evaluation can be scoped to exclude categories we supply, or run purely as a method and criteria set your own team applies. Say which you want at the outset.
Do they have an engineering team, or a supplier list?
The first question, and the one that predicts most of what follows.
- Is there a research and development team, or does the company assemble and brand?
- Did they design the control card, or buy it?
- Do they hold the firmware source, or depend on whoever wrote it?
- Do they understand OCPP themselves, or only that their supplier says it is supported?
- Do they understand the CMS side, load balancing, and what happens between the charger and a platform?
A company with one layer of knowledge can describe what it supplies. A company with cross-functional teams can look at a symptom and say which layer it is in. That distinction does not matter at the point of purchase and it matters every time afterwards.
Full stack, and why it decides support
When a fault appears in a deployed fleet, a single-layer vendor has one available answer: our part is fine. They are usually telling the truth, and it does not help you.
A vendor whose own team covers hardware, firmware, protocol and platform can take the symptom and pinpoint it, including when the answer is that the fault is theirs. That is the practical value of full-stack engineering in a supplier, and it is worth more than most of the specification differences that procurement processes actually compare.
How long have they existed?
Charging has attracted a lot of new entrants and some of them will not be here for the warranty period, let alone the asset life.
- How long has the company existed, and how long in this business specifically?
- Have they shipped at the volume you are planning, or is yours the largest order they would have taken?
- Do they have field history, and can they tell you what came back and why?
- What happens to your fleet if they stop trading, and does anything about the product depend on them continuing?
For context on how we answer that ourselves: RIOD has existed for around a decade and has been in this business for the last eight years.
What we actually verify
- 1
OCPP, by testing
Not by reading the datasheet. Against the platform and release you will run, with the message set your operation depends on.
- 2
Integration
An end-to-end test with your backend, because compliance and interoperability are different properties.
- 3
Certification
What they hold, issued by whom, covering which product and which revision. A certificate for a different variant is a common answer.
- 4
Customisation capability
Whether they can genuinely design an enclosure and a casing to your requirement, or whether customisation means a different sticker.
- 5
Their test setup
How they test chargers on their own line. Whether every unit is tested or a sample. Whether results are recorded per unit and retrievable later. This tells you more about quality than any certificate does.
Want this applied to your own site?
Scope a vendor evaluationTechnically reviewed by Anees P K, Director of Technology. Last reviewed 2026-08-29.
Frequently asked questions
Is this independent if RIOD also sells chargers?
That is a fair objection and we raise it first. The evaluation can exclude categories we supply, or be delivered as a method and criteria set your team applies. Choose the arrangement at the outset.
What does the evaluation produce?
A dimension-by-dimension assessment with the evidence behind each finding, the questions a vendor could not answer, and the risks that should be reflected in contract terms rather than in the score.
Can you evaluate a vendor we have already selected?
Yes, and pre-award is more useful than post-deployment, because the findings can still change the terms.
Do you test the hardware physically?
Depending on scope. Protocol behaviour and firmware practice can be assessed against a unit. Full electrical and environmental testing is a laboratory activity.
What is the single most overlooked check?
Verifying that the certificate covers the configuration actually being quoted, including critical components and firmware version, rather than a related variant.
Scope a vendor evaluation
Tell us the vendors, the deployment and whether our own hardware position is a conflict for you.
Scope a vendor evaluation