OCPP Integration Readiness Checklist for EV Charging Systems

1. Target OCPP version confirmed

OCPP 2.0.1 (stable) or OCPP 2.1 (in development) explicitly selected. Each charger-CSMS integration path targets one protocol version. Mixed-fleet migrations require a documented transition matrix.

2. Build-vs-integrate decision made

Write OCPP from scratch, use open-source, or integrate a reusable engineering asset. This decision changes test strategy, certification scope, ownership model, and timeline. For selected projects, Clemios can apply FlexCharge.OCPP as a reusable engineering accelerator, with implementation stack, integration scope, and IP ownership aligned to the client project.

3. Required OCPP functional blocks identified

Functional blocks listed: Core, Smart Charging, Reservation, Local Auth List, Firmware Management, ISO 15118 Certificate Management. Only needed functional blocks selected.

4. Protocol migration path documented (if upgrading from 1.6)

Every OCPP 1.6 message mapped to its 2.0.1 or 2.1 equivalent. Split, renamed, and restructured messages identified in a migration matrix.

5. Hardware platform meets minimum requirements

Clemios planning baseline: target MCU/SoC with 8 MB flash and 2 MB RAM for OCPP 2.0.1 Core + TLS + WebSocket. Higher functional blocks (ISO 15118-2, OCPP 2.1 in development) may require more. Targets below this baseline should trigger an architecture review.

6. Communication path defined

Charger-to-CSMS connectivity selected: Ethernet, Wi-Fi, cellular (4G/LTE), or combination. Reconnect strategy and fallback behavior on link loss defined. Latency, reliability, and certificate provisioning implications documented.

7. WebSocket + TLS 1.2+ confirmed on target hardware

OCPP 2.0.1 and 2.1 use WebSocket with JSON payloads. For production security profiles, wss:// with TLS 1.2+ is required. Firmware WebSocket library and TLS support verified on the target platform for the selected security profile.

8. Backend (CSMS) identified

Integrating with existing CSMS, building own, or using third-party. CSMS capabilities determine which OCPP profiles the charger must implement.

9. TLS certificate strategy defined

Self-signed for development, CA-signed for production. Full certificate lifecycle documented: issuance, renewal, revocation.

10. Security profile level chosen

One of three OCPP security profiles selected: unsecured, basic auth + TLS, or client-side certificates + TLS. Profile choice directly determines firmware complexity.

11. Private key storage approach determined

HSM, secure element, or software-based key storage selected. Hardware security affects cost and certification readiness.

12. Interoperability test plan written

Validation targets minimum 2-3 different CSMS implementations. Test matrix covers all selected OCPP profiles. OCA plugfest participation evaluated.

13. OCTT test cases mapped to implementation scope

OCA OCPP Compliance Testing Tool (OCTT) conformance cases reviewed. Applicable OCTT conformance profiles identified: Core, Advanced Security, Smart Charging, Reservation, Local Auth List, ISO 15118 Certificate Management.

14. Firmware unit testing framework selected

TDD framework chosen before coding starts: Ceedling (C), GoogleTest (C++), or equivalent. Protocol logic is operation-critical and requires regression-safe development.

15. Regression test environment with CI/CD operational

Automated protocol test suite re-runs after every firmware change. CI/CD pipeline configured and producing pass/fail results.

16. Device model variables mapped to OCPP Component/Variable structure

Every configurable parameter (connector count, power limits, metering intervals) listed and mapped to the OCPP device model (Component/Variable structure in 2.0.1 and 2.1).

17. Metering values and sampling intervals defined

Energy and power values that hardware reports identified. Sampling rate documented. MeterValues message configuration matches hardware capabilities.

18. Firmware images cryptographically signed

Firmware binaries are signed with a project-specific key. Signature verification is enforced on the device before installation. Unsigned or tampered images are rejected.

19. Firmware rollback mechanism exists

Device can recover from a failed or interrupted firmware update. Rollback to the previous known-good image is automatic or operator-triggered. Bootloader behavior on corruption is defined.

20. Remote firmware update via OCPP confirmed

OCPP FirmwareManagement (UpdateFirmware / FirmwareStatusNotification) is implemented on the target platform, or remote update is explicitly out of scope with justification documented.

21. OCPP-trained engineering team assigned

Engineers who have read the OCPP specification (Parts 1 and 2 for the target version) and can trace message flows are assigned to the project. Training or external support arranged if not.

22. Project timeline accounts for protocol complexity

First OCPP integration (Core + Smart Charging + Security Profile 2): 3-6 months for an experienced team. Add 30-50% if first OCPP project. OCPP 2.1 (in development) may add scope for new features (tariff, grid). Timeline reflects this.