OCPP 2.0.1 as Production Baseline. Controlled Path to 2.1.
Clemios integrates OCPP 2.0.1 on real charger hardware, validates it against real CSMS environments, and designs a controlled upgrade path toward OCPP 2.1. Clemios does not build new systems on OCPP 1.6.
Built for Teams That Need OCPP Delivery to Work
On real hardware, against real CSMS environments, with a controlled path toward 2.1.
For Charger OEMs
Build new charging systems on an OCPP 2.0.1 production baseline designed for real hardware and backend interoperability.
For Upgrade and Migration Teams
Move from OCPP 1.6 or plan toward 2.1 through a controlled architecture path that reduces rewrite risk.
For Interoperability-Critical Programmes
Validate OCPP behaviour against real CSMS environments, security profiles, and field edge cases before deployment.
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.
CSMS implementations interpret the specification differently. Security profile behaviour varies between CSMS vendors. Firmware update flows that work against one CSMS 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 CSMS environments each client needs to interoperate with. The difference matters when a charger has to interoperate with CSMS environments, security profiles, and field behaviours that were not part of the original implementation assumptions.
Functional profiles, security profile selection, CSMS targets, and migration constraints defined before implementation starts.
OCPP 2.0.1 implemented in charger firmware, not treated as configuration or middleware.
Testing against real CSMS environments and vendor-specific behaviour before field deployment.
Structured test workflows aligned with OCTT methodology, before formal certification activities.
Firmware updates, diagnostics, regression testing, and a controlled path from OCPP 2.0.1 toward 2.1.
Why Clemios for OCPP
The offer is engineering execution, not a boxed protocol stack for sale.
Real Hardware Integration
Clemios integrates OCPP into charger firmware and hardware constraints, not only abstract protocol logic.
Real CSMS Validation
Clemios validates behaviour against the CSMS environments each client actually needs to interoperate with.
Controlled Upgrade Path
OCPP 2.0.1 is the production baseline. The path toward 2.1 is planned early to reduce avoidable rewrite risk.
Service-Led Delivery
FlexCharge.OCPP accelerates delivery, but the offer remains engineering execution rather than boxed stack sales.
Current OCPP Engineering Status
Clemios publishes OCPP status openly. No vague capability claims. No "supported" without context.
Supported only where legacy migration or interoperability constraints require it. No new builds.
Production baseline. Validated on real charger hardware with structured functional-profile coverage.
Active engineering effort. Not yet available for client deployments.
Conformance-preparation methodology. Actively testing against OCTT practices. No OCA certification claim.
Governed by engineering sign-off, not marketing.
OCPP Integration Methodology
This methodology applies whether implementing OCPP for the first time or migrating from OCPP 1.6 to 2.0.1.
FlexCharge.OCPP in Six Layers
FlexCharge.OCPP is a reusable engineering asset used to accelerate OCPP delivery. It is not a boxed protocol stack. OCPP-focused integration projects can start from this architecture where it reduces delivery risk, adapting it to the specific charger hardware and CSMS requirements.
The six layers separate concerns and are designed to limit how changes propagate across the architecture. A change from an Infineon to an NXP MCU is handled primarily in Hardware Abstraction. Protocol core, communication, and security enforcement are intended to remain stable where possible. This containment makes the architecture reusable across projects and supports a controlled engineering path toward OCPP 2.1 while reducing avoidable rewrite risk.
For clients: reduced regression risk when upgrading protocol versions, more predictable validation across target CSMS environments, and testable upgrade paths from 2.0.1 toward 2.1.
-
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 for the required OCPP 2.0.1 profiles.
-
4. Hardware AbstractionChip-specific drivers, I/O adapters, vendor isolation, capability APIs. Designed for adaptation across multiple 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
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. New Clemios OCPP delivery is scoped around OCPP 2.0.1 unless migration constraints require OCPP 1.6 handling.
Clemios implements the OCPP 2.0.1 core and relevant optional profiles required for secure operation, firmware management, diagnostics, and CSMS 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 path rather than an unmanaged protocol reset.
Clemios designs OCPP implementations with forward compatibility in mind. Version upgrades are handled through clear separation of protocol logic, CSMS integration, and device-specific behavior. This reduces regression risk and avoids unnecessary parallel protocol stacks on the path from OCPP 2.0.1 toward 2.1.
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 new Clemios OCPP delivery is scoped around OCPP 2.0.1.
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. OCTT status is methodology alignment only. No OCA certification claim is made.
OCPP Engineering Ready for Delivery
Scope OCPP 2.0.1 delivery, interoperability validation, or the path toward 2.1 before implementation risk compounds.