OCPP Conformance vs. Certification vs. Interoperability Testing: What’s the Difference?

For a buyer comparing OCPP conformance vs interoperability testing, the first step is to name the implementation, version and risk being tested. An EV charging module may appear in the same package, but its evidence does not cover network or management functions. EV charging management solutions therefore need a separate system evidence row. Use one primary artifact: a Project Protocol Evidence Register.

Keep three evidence types separate

1. Conformance evidence records results from defined OCPP test cases for a specified implementation, version and profile.

2. Certification evidence records the formal programme result for a defined scope, process and certificate holder.

3. Interoperability evidence records a particular implementation pair or system configuration working through realistic project workflows.

These are complementary, not a ladder in which one automatically includes the others. A project may also need vehicle, connector, network and regional evidence.

What conformance can show

The Open Charge Alliance’s OCPP Certification Program, OCA FAQ and OCPP Compliance Test Tool describe tests for a defined Charging Station, Charging Station Software Stack or CSMS, depending on the programme and scope. A conformance result can show that the tested implementation addressed the specified cases under the stated configuration.

Record the OCPP version and profile, tested object, hardware/software version, test cases and exclusions, tool or laboratory method, report date and unresolved deviations. Conformance does not prove that another firmware version, profile, backend, vehicle, connector or site network will behave identically. It also does not prove complete-charger certification.

A conformance row is closed only for the object and configuration named in the report. If the RFP needs a different profile, firmware release or complete-device function, create a separate row and identify the new test or clarification. This keeps a useful protocol result from being reused as evidence for an untested scope.

What certification adds

Certification is a formal result with a defined version, profile, object, holder, issue date and validity. Check the programme identifier, issuing organization, limitations and change conditions. A protocol logo, OCTT reference or generic “OCPP compliant” statement is not the same as a certificate covering the configuration being purchased. OCTT is a conformance test tool; it does not itself issue the certificate.

An external OCA definition explains the evidence category. It does not prove a UUGreenPower or UUinside certificate, a named backend or vehicle pairing, or a contractual responsibility assignment.

What interoperability adds

End-to-end interoperability connects named implementations, such as a Charging Station or software stack with a named CSMS, and exercises the workflows the project needs. Capture endpoint identities, software and firmware versions, OCPP profiles, network/security settings, authorization, start/stop, metering, faults, reconnect and recovery where relevant, plus logs, defects, owners and retest results.

OCA’s Plugfest guidance describes round-robin testing of real Charging Station and CSMS implementations and distinguishes participation from certification or endorsement. A project should still define its own acceptance scope. A conformance result can coexist with an incomplete or failed pairing test because the tests ask different questions.

For example, a station may pass its defined cases while a project pairing still needs work on authentication, message timing, recovery or a backend-specific profile. The register should show the defect, owner and retest result instead of treating the protocol result as a universal compatibility statement.

Keep product layers visible

Do not assign a row to a supplier because an architecture diagram shows a controller, PMU, DCU or backend block. Use the ICD, contract, configuration record or project test evidence to assign responsibility.

Use the limitation column when the result enters an RFP. A closed row has an identified object, version and scope; a conditional row names the missing evidence and owner; a held row means the missing fact could change acceptance. This keeps a useful result without expanding its meaning.

The same register can carry an EV charging module record beside the charger and communication rows, but the acceptance owner should not close the system rows until the named implementation pair has been exercised. A component interface, protocol result and project handover are related records, not one combined certificate.

Use the register before acceptance

Freeze the version, profiles, endpoint identities, firmware/software, network assumptions and exclusions; review holder, scope, validity and test cases; test the named pairing with agreed workflows, faults, logs and pass/fail criteria; then assign defect, retest, configuration-release and handover owners. Reopen affected rows when the OCPP version/profile, charger controller, CSMS/backend, authentication, network, connector, vehicle or site workflow changes. A similar product name is not enough to inherit an old pairing result.