QA and Test Engineering
For engineering leaders shipping embedded and EV charging software. QA strategy, requirements traceability, interoperability coverage, and CI/CD quality gates before release.
Testing Capabilities
Testing Tooling Stack
| Category | Tools |
|---|---|
| Unit Testing (Embedded C) | Ceedling (core differentiator) |
| Unit Testing (C++) | GoogleTest |
| Functional Testing (Python) | pytest |
| Static Analysis | SonarQube, CodeRabbit, Linters, Pylint |
| Test Management | Jira, Polarion |
| Requirements Traceability | Polarion, Confluence |
| OCPP Conformance | actively testing with OCTT |
| Coding Standards Verification | MISRA C |
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 test reports linked to requirements. Full traceability from specification to test result.
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.
QA systems for embedded and EV charging releases
Broader QA coverage, release gates, and requirements traceability for embedded and EV charging software. Deployment-facing validation depth continues in Testing and Validation.