Testing und Validierung für EV-Ladesoftware
Interoperabilitätstests, CI/CD-Qualitäts-Gates, MISRA-C-Konformität und TDD mit Ceedling. Validierte EV-Ladesoftware, bestätigt funktionsfähig vor Auslieferung.
Testumfang
Ausgerichtet auf die Fehlermodi, die Ladesysteme in der Produktion zum Ausfall bringen.
OCPP-Interoperabilitätstests
Validierung von OCPP-Nachrichtenflüssen zwischen Ladegerät und CSMS. Test gegen mehrere Backends. Identifikation von Protokoll-Konformitätslücken vor dem Feldeinsatz.
CI/CD-Qualitäts-Gates
Automatisierte Testsuiten, integriert in die CI-Pipeline. Jeder Commit wird gegen definierte Qualitätskriterien validiert, bevor er gemergt wird.
MISRA-C-Konformität
Statische Analyse und Durchsetzung von Codierstandards für sicherheitskritische Firmware. Angewandt auf alle Embedded-C-Projekte.
Ceedling TDD für Firmware
Testgetriebene Entwicklung für Embedded C mit Ceedling. Unit-Tests laufen auf dem Host, validiert auf dem Target. So werden Firmware-Fehler erkannt, bevor sie die Hardware erreichen.
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, Modbus TCP/RTU, CAN, SPI, I2C, UART, Ethernet |
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. Über mehrere Kundenprojekte hinweg hat dieser Ansatz den manuellen Testaufwand um bis zu 85 % reduziert.
Übersicht Standardausrichtung
| Standard | Umfang | Status | Beschreibung | Zuletzt geprüft |
|---|---|---|---|---|
| MISRA C | Firmware | Angewandt | Codierstandard für sicherheitskritisches C. Durchgesetzt in gesamter Produktions-Firmware. | März 2026 |
| OCTT | Prozess / Validierung | Aktiv mit OCTT getestet | OCA-Konformitätstest-Tooling für Interoperabilitätstests eingesetzt. Kein Zertifizierungsanspruch. | März 2026 |
| IEC 61851 | System / Hardware-Abstraktion | Referenziert | EV-Ladesicherheitsstandard, referenziert auf System- und Hardware-Abstraktionsebene. | März 2026 |
| ISO 15118 | System | Zukünftige Fähigkeit | Plug-and-Charge-Standard auf dem Entwicklungshorizont. Noch nicht implementiert. | März 2026 |
Testmethodik
Anforderungen definieren
Testbare Anforderungen mit strukturierten Werkzeugen erfassen (Confluence, Polarion). Rückverfolgbarkeit von Anforderung zu Testfall herstellen.
Tests zuerst schreiben
TDD anwenden, wo sinnvoll. Unit-Tests (Ceedling oder GoogleTest) werden vor der Implementierung für kritische Firmware-Komponenten geschrieben.
In CI automatisieren
Testsuiten in CI/CD-Pipelines integrieren (GitHub Actions, GitLab CI, Azure DevOps). Jeder Commit löst automatisierte Validierung aus.
Interoperabilität testen
OCPP-Protokolltests gegen mehrere CSMS-Backends ausführen. Nachrichtensequenzen, Fehlerbehandlung und Grenzfälle validieren.
Auf Target validieren
Testergebnisse auf realer Hardware bestätigen. Firmware auf den Ziel-MCU flashen und verifizieren, dass das Verhalten den Host-basierten Testvorhersagen entspricht.
Berichten und nachverfolgen
Testberichte generieren, verknüpft mit Anforderungen. Vollständige Rückverfolgbarkeit von Spezifikation zu Testergebnis.
Standardausrichtung
| Standard | Geltungsbereich | Status | Beschreibung | Letzter Review |
|---|---|---|---|---|
| MISRA C | Firmware | Angewandt | Codierstandard für sicherheitskritisches C. Durchgesetzt in gesamter Produktions-Firmware. | März 2026 |
| OCTT | Prozess / Validierung | Aktiv mit OCTT getestet | OCA-Konformitätstest-Tooling für Interoperabilitätstests eingesetzt. Keine Zertifizierungsaussage. | März 2026 |
| IEC 61851 | System / Hardware-Abstraktion | Referenziert | EV-Ladesicherheitsstandard, referenziert auf System- und Hardware-Abstraktions-Designebene. | März 2026 |
| ISO 15118 | System | Zukünftige Fähigkeit | Plug-and-Charge-Standard auf dem Entwicklungshorizont. Noch nicht implementiert. | März 2026 |
Clemios beansprucht keine Zertifizierungen, die noch nicht erreicht wurden. „Zukünftige Fähigkeit“ bedeutet, dass die Engineering-Arbeit noch nicht begonnen hat. „Ausgerichtet“ bedeutet, dass die Methodik den Prinzipien des Standards folgt, ohne formale Zertifizierung. Diese Transparenz ist beabsichtigt. Engineering-Entscheider erkennen den Unterschied.
Dies stellt sicher, dass die Validierung mit der Art und Weise übereinstimmt, wie Ladesysteme spezifiziert, eingesetzt und auditiert werden.
Häufig gestellte Fragen
Clemios testet gegen mehrere CSMS-Backends und validiert vollständige Nachrichtenflüsse. Dazu gehören Verbindungsaufbau, Authentifizierung, Transaktionssequenzen, Fehlerbehandlung und Grenzfälle wie Netzwerkunterbrechungen und Offline-Verhalten. Das Ziel ist es, Konformitätslücken vor dem Feldeinsatz zu erkennen.
Ceedling für Embedded C, GoogleTest für C++ und pytest für Python. Statische Analyse wird mit MISRA C, SonarQube und CodeRabbit durchgeführt. Anforderungsrückverfolgbarkeit läuft über Confluence, Polarion und Yogi. Hardware-Debugging erfolgt mit Segger, Saleae, STLink V2 und PCAN USB.
MISRA C wird in der gesamten Firmware angewandt. Clemios testet aktiv mit OCTT. IEC 61851 wird im Hardware-Abstraktions-Design referenziert, und ISO 15118 befindet sich auf dem Entwicklungshorizont. Clemios beansprucht keine Zertifizierungen, die noch nicht erreicht wurden. Dies stellt sicher, dass Testergebnisse widerspiegeln, wie Ladesysteme spezifiziert, auditiert und im Feld eingesetzt werden.
OCPP 2.1 ist eine Weiterentwicklung von 2.0.1, kein Ersatz. Die Architektur trennt bereits Protokollverarbeitung von Anwendungslogik, sodass die Übernahme von 2.1-Features eine kontrollierte Erweiterung ist, kein Rewrite. Wer heute mit 2.0.1 beginnt, kann problemlos auf 2.1 umsteigen.
Clemios kann bestehende 1.6-Implementierungen testen und warten, baut jedoch keine neuen Systeme auf OCPP 1.6. Die Baseline ist OCPP 2.0.1, OCPP 2.1 ist in Entwicklung. Für neue Projekte ist 2.0.1 der Ausgangspunkt.
Ladesoftware vor dem Einsatz validieren
Unit-Tests, Protokollkonformität, Interoperabilitätsprüfungen — EV-Ladesoftware wird vor dem Einsatz auf Produktionsreife verifiziert.