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.
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.
Charger-to-Backend Integration
We own 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.
We work on real OEM hardware, not simulators. The firmware runs on the target MCU, connects to the actual 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.
We test every smart charging feature against multiple CSMS implementations to verify correct handling across vendors.
Every Project Benefits from FlexCharge.OCPP
FlexCharge.OCPP is our reusable engineering asset. It is a modular OCPP implementation that we deploy as the starting point for every eMobility project. Instead of writing OCPP code from scratch, we adapt production-tested components 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.
Our Protocol Status
We publish our protocol status openly. No vague capability claims. No "supported" without context. Here is exactly where we stand:
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 our development horizon, not yet implemented. | Mar 2026 |
| IEC 61850-104 | Future capability | Not available (future capability) | On our 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 | Aligned | Methodology alignment only | Testing methodology aligns with OCTT practices, not certified. | Mar 2026 |
| This table is updated when our 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 · Aligned = methodology alignment only | ||||
How We Work
We operate as an extension of your engineering team. Integrated into your workflows, accountable for delivery.
Our engineers join your sprints, commit to your repository, and demo progress bi-weekly. The team works in English and German. When something breaks in the field, our engineers debug it alongside yours.
Our engineers use AI-assisted tooling (RAG, prompt engineering, MCP) to accelerate code analysis and protocol research. These are workflow accelerators, not replacements for engineering judgment.
This is not a vendor relationship where you write requirements and wait. You get engineers who understand your codebase, your CSMS, and your 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 your backend and business requirements are ready.
No. We do not build new systems on OCPP 1.6. Our engineering baseline is OCPP 2.0.1, and our tooling, testing, and architecture are built around the modern protocol.
Let Us Engineer Your Next eMobility System
OCPP 2.0.1 and 2.1 on real hardware, validated against real backends, ready for production.