OCPP 2.0.1 as Production Baseline. Forward to 2.1.
OCPP 2.0.1 is our production baseline. We design systems to evolve safely toward 2.1. We do not build new systems on OCPP 1.6. Clemios integrates the protocol into real charger hardware, validates against real backends, and architects the firmware so the transition to 2.1 does not require a rewrite.
Clemios is an eMobility software engineering partner delivering EV charging, OCPP, embedded, and test-ready systems through dedicated engineering teams for German and EU companies.
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. We do not sell an OCPP stack. We integrate OCPP into charger hardware using FlexCharge.OCPP, our reusable engineering asset, and validate 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 | Under development |
Our production systems start with OCPP 2.0.1. From there, we design for forward compatibility toward 2.1, without disruptive rewrites or parallel protocol stacks.
Source: Open Charge Alliance specifications. Clemios status reflects our 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 we deliver starts with FlexCharge.OCPP. Rather than writing OCPP code from scratch for each client, we deploy a modular, production-tested architecture and adapt 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
How We Integrate OCPP
This methodology applies whether implementing OCPP for the first time or migrating from OCPP 1.6 to 2.0.1.
Our Protocol Status
Our production baseline starts with OCPP 2.0.1. The statuses below reflect our current 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 our 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 | Aligned | Testing methodology aligns with OCTT. Not certified. |
We update this table when our 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 our 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.
We implement 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. We design systems so that moving from 2.0.1 to 2.1 is a controlled upgrade, not a protocol reset or rewrite.
We design 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.
We do not build new systems on OCPP 1.6. Our 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. We use OCTT as part of our interoperability and validation process to verify protocol behavior. Clemios is not OCTT-certified, and we do not claim certification where it has not been achieved.
Need OCPP Done Right?
From first implementation to version migration, from security profiles to interoperability testing. We deliver OCPP that works in production.