OCPP Integration Readiness Checklist

1. Target OCPP version confirmed

OCPP 2.0.1 (stable) or OCPP 2.1 (emerging) explicitly selected. Mixing versions in one deployment is not permitted.

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.

3. Required OCPP profiles identified

Functional blocks listed: Core, Smart Charging, Reservation, Local Auth List, Firmware Management, ISO 15118 Certificate Management. Only needed profiles 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

Target MCU/SoC has minimum 8 MB flash and 2 MB RAM for OCPP 2.0.1 Core + TLS + WebSocket. Higher profiles (ISO 15118, OCPP 2.1) may require more. Below this threshold, the item fails regardless of architecture quality.

6. Communication path defined

Charger-to-CSMS connectivity selected: Ethernet, WiFi, 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 mandate WebSocket (wss://) with JSON payloads. Firmware WebSocket library and TLS 1.2+ support verified on the target platform.

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 certification 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 safety-relevant 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 may add scope for new features (tariff, grid). Timeline reflects this.