Testing and Validation for Production-Ready EV Charging Software
EV charging firmware validated before production release. OCPP interoperability risks identified before field deployment. For charger OEMs and engineering teams: CI/CD quality gates, real hardware validation, and OCTT-based conformance preparation.
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 conformance preparation and interoperability validation, and traceable reporting. Outcome: engineering evidence ready for audit, conformance review, or OEM acceptance.
Engineering Discipline Behind the Validation
| 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. Validation managed from Germany, delivered by dedicated engineers.
Conformance-Preparation as Process
OCTT-based conformance preparation is a structured workflow, not a final-stage checkbox. Protocol validation runs continuously throughout development, so interoperability issues surface early, not at formal conformance testing.
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 traceable test reports linked to requirements. Evidence prepared for OEM acceptance review, conformance verification, or audit. Validation managed from Germany, delivered by dedicated engineers.
Standards Alignment
| Standard | Scope | Status | Description |
|---|---|---|---|
| MISRA C | Firmware | Applied | Coding standard for safety-critical C. Enforced across all production firmware. |
| OCTT | Process / Validation | Actively testing with OCTT | OCA conformance test tooling used for interoperability testing. No certification claim. |
| IEC 61851 | System / Hardware Abstraction | Referenced | EV charging safety standard referenced at system and hardware-abstraction design level. |
| ISO 15118-2 | System | Future capability | AC/DC charging communication. On the development horizon. Not yet implemented. |
| ISO 15118-20 | System | Future capability | Plug-and-Charge and bidirectional power transfer. On the development horizon. Not yet implemented. |
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-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
EV charging software ready for production release. OCPP interoperability verified, firmware validated on target hardware, conformance evidence prepared for OEM review or audit.