eMobility Engineering That Ships, from Charger to Cloud
Validated on real hardware, against real CSMS. Firmware, smart charging, and full backend integration that reaches production.
Charger-to-Backend Integration
Clemios owns the complete software path between a physical charger and its CSMS.
OCPP implementation, secure communication, message routing, device model management, and backend API connectivity, delivered as one integrated stack.
All firmware runs on real OEM hardware, not simulators. The code targets the actual MCU, connects to the production CSMS, and gets validated under real operating conditions.
Smart Charging Features
Smart charging is not one feature. It is a set of coordinated capabilities that must work together.
Load management, energy scheduling, tariff-aware charging, and grid-responsive behaviour. Each interacts with different OCPP 2.0.1 functional blocks.
Every smart charging feature is tested against multiple CSMS implementations to verify correct handling across vendors.
Every Project Benefits from FlexCharge.OCPP
FlexCharge.OCPP is a reusable engineering asset. It is a modular OCPP implementation deployed as the starting point for every eMobility project. Instead of writing OCPP code from scratch, production-tested 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 across previous deployments.
Protocol Status
Clemios publishes protocol status openly. No vague capability claims. No "supported" without context. This table reflects exact current status:
Swipe to see all columns →
| Protocol | Engineering Status | Client Project Use | What This Means | Last Reviewed |
|---|---|---|---|---|
| OCPP 2.0.1 | Actively implemented | Used in client projects | Deployed in real charger hardware with full profile support. | Mar 2026 |
| OCPP 2.1 | In development | Not yet available for client projects | Active engineering effort, not yet offered in client deployments. | Mar 2026 |
| ISO 15118 | Future capability | Not available (future capability) | On the development horizon, not yet implemented. | Mar 2026 |
| IEC 61850-104 | Future capability | Not available (future capability) | On the development horizon for grid-integration use cases. | Mar 2026 |
| VDV 261/463 | Future capability | Not available (future capability) | Relevant for public transport charging, not yet implemented. | Mar 2026 |
| OCTT | Actively testing with OCTT | Methodology alignment only | Actively testing against OCTT practices, not certified. | Mar 2026 |
| This table is updated when Clemios protocol status changes. It is governed by engineering sign-off, not marketing. | ||||
| Actively implemented = production-ready and deployed · In development = under active engineering, not client-usable · Future capability = not yet implemented · Actively testing = testing with OCTT methodology, not certified | ||||
Delivery Model
Clemios engineers operate as an extension of the client engineering team. Integrated into existing workflows, accountable for delivery.
Clemios engineers join client sprints, commit to client repositories, and demo progress bi-weekly. The team works in English and German. When something breaks in the field, Clemios engineers debug it alongside the client team.
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 until systems run in production.
Get a ProposalFrequently Asked Questions
The full charger-to-backend path: protocol stack, secure communication, message routing, device model, and smart charging (load management, energy scheduling, grid-responsive behaviour). Delivered as one integrated stack on OCPP 2.0.1, tested against multiple CSMS implementations before handoff.
ESP32, Infineon, Microchip, NXP, Renesas, STMicroelectronics, Texas Instruments, and Hilscher netX 90 on Linux, FreeRTOS, and bare-metal targets. New MCU families can be adopted without changing protocol logic.
Incrementally. Each functional block updates independently while the protocol core stays stable. Start on 2.0.1 today, move to 2.1 when the backend 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 the modern protocol.
Start an eMobility Engineering Project
OCPP 2.0.1 and 2.1 on real hardware, validated against real backends, ready for production.