OCPP 2.1 as Production Standard. Ready for Certification.
Clemios delivers certificate-ready OCPP 2.1 as the new production standard. By integrating a Hardware Abstraction Layer (HAL), we ensure future-proof charger-to-backend communication aligned with metrological standards and German Eichrecht. 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.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 OCPP 2.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.1 implemented in charger firmware, with ISO 15118 bridge support.
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 the production standard for OCPP 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.1 is the production baseline. Future protocol and firmware upgrades are 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.
Actively implemented. Ready for Certification. Optimized for Hardware Abstraction Layer (HAL) and metrological integration (Eichrecht).
Conformance-preparation methodology. Ready for formal OCA certification testing.
Supported only where legacy migration or interoperability constraints require it.
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.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 for OCPP 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.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 with OCPP 2.1 as the new production standard. With a Hardware Abstraction Layer (HAL) and metrological integration, implementations are designed for full certificate readiness and German Eichrecht alignment. Clemios does not build new systems on OCPP 1.6.
OCPP 2.1 is the latest Clemios production standard. It adds critical features for bidirectional charging, improved smart charging, and full certificate readiness. All new Clemios OCPP engineering is scoped around version 2.1 as the baseline.
Clemios implements the OCPP 2.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.
Clemios validates every OCPP 2.1 implementation against multiple target CSMS environments, not just a single reference server. This surfaces discrepancies in optional fields, session handling, and error behavior before they appear in the field.
Clemios uses a Hardware Abstraction Layer (HAL) to separate protocol logic from underlying hardware controllers. This enables migration between OCPP versions (identifying and resolving version drift from 1.6 to 2.1) without rewriting driver-level code, reduces regression risk, and ensures metrological integrity across hardware refreshes.
Clemios does not build new systems on OCPP 1.6. The production baseline starts with OCPP 2.1. Migration from existing OCPP 1.6 systems can be supported where required, but new Clemios OCPP delivery is scoped around modern standards.
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 implementations are actively tested with OCTT to ensure full compliance and readiness for formal OCA certification.
OCPP Engineering Ready for Delivery
Scope OCPP 2.1 delivery, interoperability validation, or the path toward certification before implementation risk compounds.