eMobility Engineering for Production-Ready EV Charging Systems
For charger OEMs and CPOs: OCPP 2.0.1 integration, embedded firmware, backend connectivity, and conformance preparation. Validated on real hardware, managed from Germany.
What Has to Be True Before an EV Charging System Goes into Production
Protocol Integration and Embedded Firmware
The firmware that runs on a charger must implement OCPP correctly, communicate with the CSMS reliably, and handle real operating conditions.
OCPP 2.0.1 implementation, secure WebSocket communication, message routing, device model management, and backend API connectivity. The firmware targets real MCUs with a hardware-abstraction layer that isolates protocol logic from chip-specific code.
Smart charging capabilities (load management, energy scheduling, tariff-aware behaviour) are implemented as OCPP 2.0.1 functional blocks and tested for correct interaction with backend scheduling systems.
Validation and Production Readiness
Code that compiles is not production-ready. Production readiness requires structured validation against real hardware and real backends.
Firmware is validated on real OEM hardware, not only in simulators. Integration is validated against target CSMS environments to verify interoperability before handoff. OCTT-based conformance preparation covers OCPP 2.0.1 functional profiles systematically.
Diagnostics, regression testing across firmware updates, and release-readiness checks are part of the engineering workflow. The goal is that systems are release-ready when they leave engineering.
A Reusable Engineering Asset for OCPP 2.0.1 Delivery
FlexCharge.OCPP is a reusable engineering asset. It is a modular OCPP implementation used as the starting point for OCPP-focused eMobility projects. Instead of writing OCPP code from scratch, internally validated components are adapted to the client's hardware and backend requirements.
The six architectural layers (Protocol Core, Communication, Security, Hardware Abstraction, Diagnostics, Lifecycle) are designed to be adapted independently. If a client uses an NXP MCU instead of an STMicroelectronics part, the changes stay within the Hardware Abstraction layer. The protocol logic above it remains unchanged.
This approach reduces integration timelines. It also reduces the risk of protocol conformance issues, because the core message handling has already been validated through structured engineering cycles.
Germany-Managed Engineering Delivery
Clemios engineers operate as an extension of the client engineering team. Integrated into existing workflows, accountable for delivery, managed from Germany.
Clemios engineers join client sprints, commit to client repositories, and demo progress bi-weekly. The team works in English and German. Engineering governance, escalation paths, and release decisions follow documented engineering governance agreed with the client. All deliverables are client-owned IP.
Clemios engineers use AI-assisted tooling (RAG, prompt engineering, MCP) to augment code analysis and protocol research. These are workflow tools, not replacements for engineering judgment.
This is not a vendor relationship where requirements are submitted and queued. Clemios provides engineers who understand the codebase, the CSMS, and the release process, and who stay accountable through handoff, launch readiness, and production-support transition.
Request a Technical Scoping CallProtocol Status
Clemios publishes protocol status openly. No vague capability claims. No "supported" without context. This table reflects exact current status:
1 actively implemented. 1 in active development. 2 future capabilities. 2 integration-scope. 1 actively testing.
Swipe to see all columns →
| Protocol | Engineering Status | Delivery Availability | What This Means |
|---|---|---|---|
| Core OCPP | |||
| OCPP 2.0.1 | Actively implemented | Available for scoped OCPP 2.0.1 delivery | Validated on real charger hardware with structured functional-profile coverage. |
| OCPP 2.1 | In development | Not yet available for client projects | Active engineering effort, not yet offered in client deployments. |
| Future Standards | |||
| ISO 15118-2 | Future capability | Not available (future capability) | On the development horizon for Plug&Charge and TLS-based communication. |
| ISO 15118-20 | Future capability | Not available (future capability) | On the development horizon for bidirectional power transfer. |
| Integration Scope | |||
| IEC 60870-5-104 | Integration support scope | Not available as standalone service | Addressable within grid-integration projects. Not a charger-core protocol. |
| VDV 261/463 | Integration support scope | Not available as standalone service | Addressable within public-transport charging projects. Not a charger-core protocol. |
| Validation | |||
| OCTT | Actively testing with OCTT | Methodology alignment only | Actively testing against OCTT practices, not certified. |
| This table is updated when Clemios protocol status changes. It is governed by engineering sign-off, not marketing. | |||
| Actively implemented = validated on real hardware and actively maintained · In development = under active engineering, not client-usable · Future capability = on the development horizon · Integration support scope = addressable in projects, not a charger-core protocol · Actively testing = testing with OCTT methodology, not certified | |||
Frequently Asked Questions
Embedded firmware, OCPP 2.0.1 protocol integration, CSMS connectivity, diagnostics, validation workflows, and release readiness. The scope covers the full path from charger firmware to CSMS interoperability, validated against target CSMS environments before handoff.
Firmware is validated on real OEM hardware, not only in simulators. Integration is tested against target CSMS environments. OCTT-based conformance preparation covers OCPP 2.0.1 functional profiles systematically. Regression testing runs across firmware updates before any release is flagged ready.
FlexCharge.OCPP is a reusable engineering asset, not an off-the-shelf stack. It provides internally validated OCPP components that are adapted to each client's hardware and CSMS requirements. This reduces integration timelines and conformance risk while keeping the architecture adaptable to each project.
Engineers operate in CET overlap, communicate in German and English, and follow documented engineering governance agreed with the client. Escalation paths, release decisions, and delivery cadence are managed from Germany. All deliverables are client-owned IP.
ESP32, Infineon, Microchip, NXP, Renesas, STMicroelectronics, Texas Instruments, and Hilscher netX 90 on Linux, FreeRTOS, and bare-metal targets. The hardware-abstraction layer isolates protocol logic from chip-specific code, so new MCU families can be adopted while reducing avoidable rewrite risk.
Incrementally. Each functional block updates independently while the protocol core stays stable. Start on 2.0.1 today, move to 2.1 when the CSMS and business requirements are ready.
No. Clemios does not build new systems on OCPP 1.6. The engineering baseline is OCPP 2.0.1, and all tooling, testing, and architecture are built around OCPP 2.0.1.
Start an eMobility Engineering Project
Plan OCPP 2.0.1 integration, embedded firmware, backend fit, and real-hardware validation for a production-ready EV charging system. OCPP 2.1 remains in development.