Testing and Validation for EV Charging Software
Interoperability testing, CI/CD quality gates, MISRA C compliance, and TDD with Ceedling. Validated EV charging software, confirmed working before it ships.
Testing Scope
Targeting the 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 the 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 catches firmware bugs before they reach hardware.
Toolchain and Quality Standards
| 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, providing 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 | Actively testing with OCTT | 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 the development horizon. Not yet implemented. | Mar 2026 |
Testing Methodology
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 Alignment
| 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 | Actively testing with OCTT | 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 the development horizon. Not yet implemented. | Mar 2026 |
Clemios does not claim certifications not yet achieved. "Future capability" means the engineering work has not started. "Aligned" means the methodology follows the standard's principles without formal certification. This transparency is intentional. Engineering buyers can tell the difference.
This ensures validation aligns with how charging systems are specified, deployed, and audited.
Frequently Asked Questions
Clemios tests 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. Clemios is actively testing with OCTT. IEC 61851 is referenced in the hardware abstraction design, and ISO 15118 is on the development horizon. Clemios does not claim certifications not yet achieved. This ensures 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. The architecture already separates protocol handling from application logic, so adopting 2.1 features is a controlled extension, not a rewrite. Starting on 2.0.1 today, moving to 2.1 is straightforward.
Clemios can test and maintain existing 1.6 implementations, but does not build new systems on OCPP 1.6. The baseline is OCPP 2.0.1, with OCPP 2.1 in development. For new projects, 2.0.1 is the starting point.
Validate Charging Software Before Deployment
Unit tests, protocol conformance, interoperability checks — verifying EV charging software is production-ready before it ships.