EV Charging Module Certification Evidence: What Should an RFP Request at Each System Layer?

An RFP may place module efficiency, complete-charger safety, connector requirements, OCPP and regional rules in one compliance section. An EV charging module certification evidence request answers only the named power-stage object unless the RFP also identifies the charger, protocol and market evidence. The same caution applies to a broad label such as B2B EV charging solutions: it does not replace an object, scope or owner. Use one primary artifact: an RFP Evidence-Scope Matrix.

Turn each requirement into an evidence object

Rewrite every clause into one of five rows:

1. Module: the named power-conversion object, model, page, operating conditions and test record. It does not automatically prove the complete charger’s HMI, payment, connector, network or certification.

2. Integrated charger: the named device or configuration, connector, enclosure, controls, market and certificate/test scope. A module certificate is not a substitute.

3. Protocol: the communication implementation, version, profiles and tested object. OCPP should be tied to the Charging Station, Charging Station Software Stack or CSMS that was tested.

4. Interoperability: a defined pairing or system scenario, including endpoints, versions, configuration and workflows.

5. Regional/regulatory: the jurisdiction, official requirement, product object, holder and validity.

These rows describe different evidence types, not a hierarchy in which one removes the others.

Use the RFP Evidence-Scope Matrix

Add a responsibility column—supplier, integrator, backend provider, client or third party—and an open-action owner. A module datasheet may close a power-stage row while the complete charger, protocol and regional rows remain open.

The matrix should also state whether a row is closed, conditional or held. “Conditional” is appropriate when the object is clear but a report, configuration or regional document is still due; “held” means the missing scope could change the bid decision.

Check identity, scope and validity

For every certificate or report, record:

• exact model or software object;

• hardware, firmware, OCPP, profile and connector version;

• certificate holder, applicant and legal entity;

• laboratory or issuing body;

• date, region, feature scope, exclusions and change conditions.

If a field is missing, mark the row open. Do not infer it from a similar model, a catalogue logo or a general compatibility statement. A product-family declaration has its own scope and still needs a representative configuration and applicable rules.

Keep OCPP evidence in the communication rows

The Open Charge Alliance’s official OCPP Certification Program, OCA FAQ and OCPP Compliance Test Tool distinguish conformance testing, formal certification and the test object. A conformance result shows how the defined implementation addressed specified test cases. Certification is the formal programme result for a stated version, profile and holder. OCTT is a test tool; it is not itself a certificate.

End-to-end interoperability asks whether named implementations work together in the project configuration. OCA’s Plugfest guidance describes testing between real Charging Station and CSMS implementations and does not make participation a certification or endorsement. A project may therefore need both protocol evidence and a separate pairing plan.

Neither external definition proves a UUGreenPower or UUinside certificate, a named backend or vehicle pairing, or which party owns the project integration. Those require the relevant product, official company or client evidence.

Separate external definitions from supplier proof

Use the current official standards body, regulator or recognized certification programme to define a requirement. Then request product-specific evidence from the supplier. The external source explains what the requirement means; it cannot prove that a named model is certified. A certificate or declaration shows its own scope; it cannot replace the current market rule.

This two-source rule also applies to safety, connector, cybersecurity and regional requirements. Record source, date and applicability in the matrix rather than attaching a standards PDF as if it were a supplier result.

Stage the review before bid submission

1. Freeze the baseline: name product layers, models, versions, OCPP profiles, connector, market and exclusions.

2. Review evidence scope: check holder, laboratory, validity, test cases and configuration.

3. Plan pairing: identify the Charging Station and CSMS, workflows, network/security settings, logs and pass/fail criteria.

4. Assign closure: record defect owner, retest trigger, handover responsibility and any client or company confirmation.

If firmware, backend, connector, region or cabinet changes, reopen the affected row. Do not let an old report silently cover a new configuration.