Testing and Validation for EV Charging Software
Interoperability testing, CI/CD quality gates, MISRA C compliance, and TDD with Ceedling. We validate that EV charging software works before it ships.
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.
What We Test
We test the same failure modes that break charging systems in production.
OCPP Interoperability Testing
Validate OCPP message flows between charger and CSMS. Test multiple backends. Identify protocol conformance gaps before field deployment.
CI/CD Quality Gates
Automated test suites integrated into your CI pipeline. Every commit is validated against defined quality criteria before merge.
MISRA C Compliance
Static analysis and coding standard enforcement for safety-critical firmware. Applied across all embedded C projects.
Ceedling TDD for Firmware
Test-driven development for embedded C using Ceedling. Unit tests run on host, validated on target. This is how we catch firmware bugs before they reach hardware.
How Our Toolchain Supports Quality
| Category | Tools |
|---|---|
| Unit Testing | Ceedling (C), GoogleTest (C++), pytest (Python) |
| Static Analysis | MISRA C, Pylint, SonarQube, CodeRabbit |
| Requirements Traceability | Confluence, Polarion, Yogi |
| Test Management | Jira, Azure DevOps |
| Debugging | Segger, Saleae, STLink V2, PCAN USB, AZ Delivery Logic Analyzer |
| Protocols Tested | OCPP, Modbus TCP/RTU, CAN, SPI, I2C, UART, Ethernet |
Why Ceedling?
Ceedling makes test-driven development practical for embedded C. It runs unit tests on the host machine against mocked hardware interfaces, giving you fast feedback loops without flashing firmware for every test. Across multiple client projects, this approach has reduced manual test effort by up to 85 %.
Standards Alignment Overview
| Standard | Scope | Status | Description | Last Reviewed |
|---|---|---|---|---|
| MISRA C | Firmware | Applied | Coding standard for safety‑critical C. Enforced across all production firmware. | Mar 2026 |
| OCTT | Process / Validation | Aligned (not certified) | OCA conformance test tooling used for interoperability testing. No certification claim. | Mar 2026 |
| IEC 61851 | System / Hardware Abstraction | Referenced | EV charging safety standard referenced at system and hardware‑abstraction design level. | Mar 2026 |
| ISO 15118 | System | Future capability | Plug‑and‑Charge standard on our development horizon. Not yet implemented. | Mar 2026 |
How We Test
Define Requirements
Capture testable requirements using structured tools (Confluence, Polarion). Establish traceability from requirement to test case.
Write Tests First
Apply TDD where applicable. Unit tests (Ceedling or GoogleTest) are written before implementation for critical firmware components.
Automate in CI
Integrate test suites into CI/CD pipelines (GitHub Actions, GitLab CI, Azure DevOps). Every commit triggers automated validation.
Test Interoperability
Run OCPP protocol tests against multiple CSMS backends. Validate message sequences, error handling, and edge cases.
Validate on Target
Confirm test results on real hardware. Flash firmware to the target MCU and verify that behaviour matches host-based test predictions.
Report and Trace
Generate test reports linked to requirements. Full traceability from specification to test result.
Standards We Align With
| Standard | Status | Description |
|---|---|---|
| MISRA C | Applied | Coding standard for safety-critical C. Enforced across all firmware. |
| OCTT | Aligned | OCA conformance test tool. We are actively testing with OCTT. Not yet certified. |
| IEC 61851 | Referenced | EV charging safety standard. Referenced in our hardware abstraction design. |
| ISO 15118 | Future capability | Plug and Charge standard. On our development horizon. |
Clemios does not claim certifications it has not achieved. When we say "future capability", we mean the engineering work has not started. When we say "aligned", we mean our methodology follows the standard's principles without formal certification. This transparency is intentional. It is how we build trust with engineering buyers who can tell the difference.
This ensures our validation aligns with how charging systems are specified, deployed, and audited.
Frequently Asked Questions
We test against multiple CSMS backends, validating complete message flows. This includes connection setup, authentication, transaction sequences, error handling, and edge cases such as network interruptions and offline behaviour. The goal is to catch conformance gaps before field deployment.
Ceedling for embedded C, GoogleTest for C++, and pytest for Python. Static analysis is handled by MISRA C, SonarQube, and CodeRabbit. Requirements traceability runs through Confluence, Polarion, and Yogi. Hardware debugging uses Segger, Saleae, STLink V2, and PCAN USB.
MISRA C is applied across all firmware. OCTT conformance testing is actively in progress. IEC 61851 is referenced in our hardware abstraction design, and ISO 15118 is on our development horizon. We do not claim certifications we have not achieved. This ensures our test results reflect how charging systems are specified, audited, and deployed in the field.
OCPP 2.1 is an evolution of 2.0.1, not a replacement. Our architecture already separates protocol handling from application logic, so adopting 2.1 features is a controlled extension, not a rewrite. If you start on 2.0.1 today, moving to 2.1 is straightforward.
We can test and maintain existing 1.6 implementations, but we do not build new systems on OCPP 1.6. Our baseline is OCPP 2.0.1, with active development toward 2.1. For new projects, 2.0.1 is the starting point.
Let Us Validate Your Charging Software
Unit tests, protocol conformance, interoperability checks. We verify that your EV charging software is production-ready before it ships.