OCPP 2.0.1 as Production Baseline. Forward to 2.1.
OCPP 2.0.1 is the production baseline. Clemios designs systems to evolve safely toward 2.1. Clemios does not build new systems on OCPP 1.6. The protocol is integrated into real charger hardware, validated against real backends, and the firmware is architected so the transition to 2.1 does not require a rewrite.
Why OCPP Is Harder Than the Specification Suggests
OCPP defines how EV chargers communicate with central management systems. The specification is open, well-structured, and maintained by the Open Charge Alliance. On paper, implementing it looks straightforward. In practice, it is not.
Backend systems interpret the specification differently. Security profile behavior varies between CSMS vendors. Firmware update flows that work against one backend fail silently against another. Version drift between 1.6 deployments still in the field and 2.0.1 production targets creates upgrade paths that touch every layer of the charger firmware. These are engineering problems, not configuration problems. Left unmanaged, they produce regressions in the field, backward compatibility failures, and chargers that pass lab tests but fail in production networks.
Clemios is an OCA member since January 2026. There is no OCPP stack for sale. Clemios integrates OCPP into charger hardware using FlexCharge.OCPP, a reusable engineering asset, and validates it against the specific backends each client needs to interoperate with. The difference matters when a charger has to pass interoperability tests against systems it was never designed for.
OCPP Version Comparison
| Feature | OCPP 1.6 | OCPP 2.0.1 | OCPP 2.1 |
|---|---|---|---|
| Communication | WebSocket (JSON/SOAP) | WebSocket (JSON) | WebSocket (JSON) |
| Security profiles | Basic authentication | 3 profiles incl. TLS mutual auth | Extended security |
| Device model | Flat key-value | Structured component model | Enhanced component model |
| Functional blocks | Monolithic | Modular (Core, Smart Charging, Reservation, etc.) | Expanded blocks |
| ISO 15118 support | No | Plug and Charge ready | Native integration |
| Firmware management | Basic | Signed firmware updates | Enhanced |
| Clemios status | Legacy support | Actively implemented | In development |
Clemios production systems start with OCPP 2.0.1. From there, the architecture is designed for forward compatibility toward 2.1, without breaking rewrites or parallel protocol stacks.
Source: Open Charge Alliance specifications. Clemios status reflects current engineering capability, not OCA certification status.
FlexCharge.OCPP in Six Layers
FlexCharge.OCPP is designed around OCPP 2.0.1 semantics and lifecycle concepts, making evolution toward 2.1 a controlled engineering step rather than a system rewrite.
Every OCPP integration project Clemios delivers starts with FlexCharge.OCPP. Rather than writing OCPP code from scratch for each client, Clemios deploys a modular, production-tested architecture and adapts it to the specific hardware and backend requirements.
The architecture separates concerns so that changes in one layer do not propagate to others. When a client switches from an Infineon to an NXP MCU, the work stays in the Hardware Abstraction layer. The protocol core, communication logic, and security enforcement above it remain unchanged. This containment is what makes the architecture reusable across projects with different hardware.
For clients, this means three things. Fewer regressions when upgrading protocol versions, because changes stay in one layer. Predictable behavior across different CSMS backends, because communication and security are isolated from protocol logic. And testable upgrade paths from 2.0.1 to 2.1, because the transition affects the Protocol Core layer without requiring changes to the five layers below it.
-
1. Protocol CoreMessage routing, state machine, profile management, device model handling. This layer implements the OCPP specification directly.
-
2. CommunicationWebSocket transport, JSON encoding and decoding, retry logic, session management. Handles the wire protocol between charger and CSMS.
-
3. SecurityTLS session setup, certificate lifecycle (provisioning, renewal, revocation), security profile enforcement across all three OCPP 2.0.1 profiles.
-
4. Hardware AbstractionChip-specific drivers, I/O adapters, vendor isolation, capability APIs. Supports 8 MCU families.
-
5. DiagnosticsStructured logging, metrics collection, fault reporting. Designed for field debugging where physical access to the charger is limited.
-
6. LifecycleBoot sequencing, graceful shutdown, firmware update management, recovery procedures. Handles the operational states that OCPP does not specify but production chargers require.
FlexCharge.OCPP: 6-Layer Architecture
OCPP Integration Methodology
This methodology applies whether implementing OCPP for the first time or migrating from OCPP 1.6 to 2.0.1.
Protocol Status
The production baseline starts with OCPP 2.0.1. The statuses below reflect current Clemios engineering capability.
| Protocol | Status | Description |
|---|---|---|
| OCPP 2.0.1 | Actively implemented | Deployed on real hardware. Production-ready. |
| OCPP 2.1 | In development | Active engineering effort. Not yet available. |
| ISO 15118 | Future capability | On the development horizon. Not yet implemented. |
| IEC 61850-104 | Future capability | For grid integration use cases. Not yet implemented. |
| VDV 261/463 | Future capability | For public transport charging scenarios. Not yet implemented. |
| OCTT | Actively testing with OCTT | Testing methodology aligns with OCTT. Not certified. |
This table is updated when capabilities change. Clemios will never claim certification it has not achieved. Last reviewed: April 2026.
Frequently Asked Questions
Clemios builds and integrates OCPP systems starting from OCPP 2.0.1 as the production baseline, designs them for forward evolution toward 2.1, and does not build new systems on OCPP 1.6.
OCPP 2.0.1 is the Clemios production baseline. It is the first OCPP version that provides the security model, device management, and lifecycle controls required for production-grade charging systems. All Clemios OCPP integrations start from OCPP 2.0.1.
Clemios implements the OCPP 2.0.1 core and relevant optional profiles required for secure operation, firmware management, diagnostics, and backend integration. Profile selection is driven by the actual system architecture and operational requirements, not by a fixed checklist.
OCPP 2.1 is an evolution of OCPP 2.0.1, extending functionality while keeping the same architectural foundations. Clemios designs systems so that moving from 2.0.1 to 2.1 is a controlled upgrade, not a protocol reset or rewrite.
Clemios designs OCPP implementations with forward compatibility in mind. Version upgrades are handled through clear separation of protocol logic, backend integration, and device-specific behavior. This allows upgrades from OCPP 2.0.1 toward 2.1 without regressions or parallel protocol stacks.
Clemios does not build new systems on OCPP 1.6. The production baseline starts with OCPP 2.0.1. Migration from existing OCPP 1.6 systems can be supported where required, but all new implementations are based on modern OCPP versions.
OCTT is the Open Charge Alliance's conformance testing tool. Clemios uses OCTT as part of the interoperability and validation process to verify protocol behavior. Clemios is not OCTT-certified, and does not claim certification where it has not been achieved.
OCPP Engineering That Ships
From first implementation to version migration, from security profiles to interoperability testing. OCPP that works in production.