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.
Was ein Testing-Engagement liefert
Jedes Engagement ist auf ein konkretes Ergebnis ausgerichtet. Kein Werkzeuginventar. Ein definiertes Lieferergebnis mit Bedingungen, Umfang und Abnahmekriterien.
Interoperabilitätsbereitschaft
OCPP-Nachrichtenflüsse validiert gegen mehrere CSMS-Backends. Konformitätslücken identifiziert mit reproduzierbaren Testfällen. Ergebnis: Firmware bereit für Multi-Vendor-Einsatz.
CI/CD-Quality-Gate-Einrichtung
Automatisierte Testsuiten in die CI-Pipeline integriert mit definierten Pass/Fail-Kriterien. Ergebnis: Jeder Merge Request wird gegen Qualitätsschwellen validiert, bevor er main erreicht.
Firmware-Testautomatisierung
TDD mit Ceedling für Embedded C. Unit-Tests laufen auf dem Host, validiert auf realer Target-Hardware. Ergebnis: Feedback-Zyklus von Stunden auf Sekunden reduziert, Regressionen vor dem Flash erkannt.
Standards- und Konformitätsvorbereitung
MISRA-C-Durchsetzung, OCTT-basierte Interoperabilitätsprüfungen und nachvollziehbare Berichterstattung. Ergebnis: Engineering-Evidenz bereit für Audit, Konformitätsprüfung oder OEM-Abnahme.
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.
Kein generischer QA-Anbieter
Reale Hardware in the Loop
Tests laufen auf echten Charger-MCUs, nicht auf Simulatoren. Firmware-Verhalten wird auf dem Target validiert, bevor es released wird. Ein generisches QA-Haus testet auf API-Ebene; dieses Team testet auf Register-Ebene.
Reale CSMS-Backends
OCPP-Interoperabilität wird gegen mehrere Live-Backends validiert, nicht gegen Mock-Server. Protokoll-Grenzfälle zeigen sich erst unter realen Transaktionslasten und herstellerspezifischen Interpretationen.
Nähe zur Embedded-Firmware
Die gleichen Ingenieure, die Firmware schreiben, schreiben auch die Tests. Keine Handoff-Lücke. Testdesign berücksichtigt reale Speicherbeschränkungen, Interrupt-Timing und Peripherie-Abhängigkeiten.
OCPP-Engineering-Kontext
Testing basiert auf Protokollspezifikationswissen. OCPP-2.0.1-Nachrichtensequenzen, Zustandsmaschinen und Fehlerbehandlung werden gegen die Spezifikation getestet, nicht nur gegen "antwortet es."
Traceability von Anforderung bis Ergebnis
Jeder Test ist einer Anforderung zugeordnet. Jedes Ergebnis ist rückverfolgbar. Reporting ist strukturiert für OEM-Abnahmeprüfungen, nicht nur für interne Dashboards.
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 |
|---|---|---|---|
| MISRA C | Firmware | Angewandt | Codierstandard für sicherheitskritisches C. Durchgesetzt in gesamter Produktions-Firmware. |
| OCTT | Prozess / Validierung | Aktiv mit OCTT getestet | OCA-Konformitätstest-Tooling für Interoperabilitätstests eingesetzt. Keine Zertifizierungsaussage. |
| IEC 61851 | System / Hardware-Abstraktion | Referenziert | EV-Ladesicherheitsstandard, referenziert auf System- und Hardware-Abstraktions-Designebene. |
| ISO 15118-2 | System | Zukünftige Fähigkeit | AC/DC-Ladekommunikation. Auf dem Entwicklungshorizont. Noch nicht implementiert. |
| ISO 15118-20 | System | Zukünftige Fähigkeit | Plug-and-Charge und bidirektionaler Energietransfer. Auf dem Entwicklungshorizont. Noch nicht implementiert. |
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-2 sowie ISO 15118-20 befinden 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, erhält einen kontrollierten Upgrade-Pfad zu 2.1, ohne bestehende Testgrenzen zu brechen.
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.