Testing and Validation for EV Charging Software
For charger OEMs preparing firmware for release and engineering teams validating OCPP interoperability: CI/CD quality gates, MISRA C compliance, and TDD with Ceedling. Validated on real hardware before it ships.
What a Testing Engagement Delivers
Each engagement is scoped to a concrete outcome. Not a tool inventory. A defined deliverable with conditions, scope, and exit criteria.
Interoperability Readiness
OCPP message flows validated against multiple CSMS backends. Conformance gaps identified with reproducible test cases. Outcome: firmware ready for multi-vendor deployment.
CI/CD Quality Gate Setup
Automated test suites integrated into the CI pipeline with defined pass/fail criteria. Outcome: every merge request validated against quality thresholds before it reaches main.
Firmware Test Automation
TDD with Ceedling for embedded C. Unit tests run on host, validated on target hardware. Outcome: feedback cycle reduced from hours to seconds, regressions caught before flash.
Standards and Conformance Preparation
MISRA C enforcement, OCTT-based interoperability checks, and traceable reporting. Outcome: engineering evidence ready for audit, conformance review, or OEM acceptance.
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 (primary); Modbus TCP/RTU, CAN, SPI, I2C, UART, Ethernet tested where required by the engagement |
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. This significantly reduces repetitive manual test effort and shortens the feedback cycle from hours to seconds.
Not a Generic QA Provider
Real Hardware in the Loop
Tests run on actual charger MCUs, not simulators. Firmware behaviour is validated on the target before release. A generic QA house tests at API level; this team tests at register level.
Real CSMS Backends
OCPP interoperability is validated against multiple live backends, not mock servers. Protocol edge cases surface only under real transaction loads and vendor-specific interpretations.
Embedded Firmware Proximity
The same engineers who write firmware also write the tests. No handoff gap. Test design reflects actual memory constraints, interrupt timing, and peripheral dependencies.
OCPP Engineering Context
Testing is grounded in protocol specification knowledge. OCPP 2.0.1 message sequences, state machines, and error handling are tested against the specification, not just against "does it respond."
Traceability from Requirement to Result
Every test maps to a requirement. Every result traces back. Reporting is structured for OEM acceptance reviews, not just internal dashboards.
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.
Toolchain und Qualitätsstandards
| Kategorie | Werkzeuge |
|---|---|
| Unit-Testing | Ceedling (C), GoogleTest (C++), pytest (Python) |
| Statische Analyse | MISRA C, Pylint, SonarQube, CodeRabbit |
| Requirements-Traceability | Confluence, Polarion, Yogi |
| Testmanagement | Jira, Azure DevOps |
| Debugging | Segger, Saleae, STLink V2, PCAN USB, AZ Delivery Logic Analyzer |
| Getestete Protokolle | OCPP (primär); Modbus TCP/RTU, CAN, SPI, I2C, UART, Ethernet – getestet je nach Projektanforderung |
Warum Ceedling?
Ceedling macht testgetriebene Entwicklung für Embedded C praktikabel. Es führt Unit-Tests auf dem Host-Rechner gegen gemockte Hardware-Interfaces aus und liefert schnelle Feedback-Zyklen ohne Firmware-Flashing bei jedem Test. Das reduziert den repetitiven manuellen Testaufwand erheblich und verkürzt den Feedback-Zyklus von Stunden auf Sekunden.
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-2 and ISO 15118-20 are 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 in development. The architecture already separates protocol handling from application logic, so adopting 2.1 features will be a controlled extension. OCPP 2.0.1 is the current baseline.
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.