OCPP-Interoperabilitätsprüfungen

Prüfumfang

• Start, Registrierung und Austausch der Konfiguration
• Heartbeat sowie Verhalten bei Verbindungsverlust und Wiederverbindung
• Vollständiger Transaktionsablauf einschließlich paralleler und unterbrochener Ladevorgänge
• Messwerte: Einheiten, Kontexte, Intervalle und Eignung für die Abrechnung
• Remote Start, Stop, Reset und Unlock – an der Ladestation und nicht nur auf Protokollebene verifiziert
• Firmwareverwaltung einschließlich Statusmeldungen bis zum vollständigen Abschluss
• Verfügbarkeit, Reservierung und Smart-Charging-Profile, sofern im Umfang enthalten
• Fehlerbehebung nach Neustart der Ladestation, Neustart der Plattform und Zeitabweichungen

Negative und unterbrochene Abläufe

Entscheidend sind die Tests, bei denen mitten im Ablauf etwas schiefgeht. Trennen Sie während einer aktiven Transaktion das Netz. Starten Sie die Ladestation bei einer offenen Sitzung neu. Senden Sie einen Befehl, den die Ladestation ablehnt. Das anschließende Verhalten beider Seiten entscheidet darüber, ob sich eine installierte Flotte zuverlässig abrechnen lässt.

Prüfnachweise

Für jeden Prüffall wird der Nachrichtenaustausch aufgezeichnet und zusammen mit den getesteten Firmware- und Plattformversionen aufbewahrt. Damit lässt sich ein späterer Streit anhand der Daten statt durch Diskussion klären. Nach einem Release auf einer der beiden Seiten entsteht außerdem ein belastbarer Regressionstest.

Für die Beschaffung

Die Aussage eines Anbieters, OCPP zu unterstützen, ist nur ein Ausgangspunkt. Erst ein Test gegen Ihre vorgesehene Plattform macht diese Aussage belastbar. Der richtige Zeitpunkt ist vor der Vergabe und nicht nach der Installation – es handelt sich um dieselbe Arbeit, nur früher im Beschaffungsprozess.

Was die Prüfung nicht leistet

Eine Interoperabilitätsprüfung ist keine Zertifizierung und bestätigt keine Konformität im Namen einer Prüfstelle. Sie dokumentiert das beobachtete Verhalten zweier konkreter Implementierungen in konkreten Versionen. Diese Aussage ist enger gefasst, für den Betrieb aber wesentlich nützlicher.

Worum es bei Interoperabilität tatsächlich geht

Eine Konformitätsprüfung fragt, ob eine Implementierung der Spezifikation folgt. Eine Interoperabilitätsprüfung fragt, ob zwei konkrete Systeme zusammenarbeiten. Ein bestandener Konformitätstest sagt nur wenig über die zweite Frage aus, auch wenn Käufer häufig genau das annehmen.

Wir haben erlebt, dass eine als OCPP-konform verkaufte Ladestation nicht mit der Plattform funktionierte, für die sich der Betreiber bereits entschieden hatte. Das Problem war nicht mangelnde Konformität. Konformität und Interoperabilität sind unterschiedliche Fragen – gestellt worden war nur eine davon.

• Welche Plattform in welchem Release – nicht nur welche OCPP-Version
• Der Nachrichtensatz, von dem Ihr Betrieb tatsächlich abhängt, einschließlich der Nachrichten, die erst bei einem Fehler wichtig werden
• Verhalten nach Wiederverbindung, bei nicht erreichbarem Backend und bei teilweise abgeschlossenen Transaktionen, weil Implementierungen hier auseinanderlaufen
• Firmware-Update over the air als durchgängiger End-to-End-Test, denn genau diesen Mechanismus benötigen Sie, wenn sich später ein anderer Fehler zeigt

So arbeiten wir dabei mit Ihnen

Prüfergebnisse sind nur dann nützlich, wenn die verantwortlichen Personen verstehen, was geprüft wurde und was nicht. Deshalb stimmen wir den Prüfplan vor dem ersten Lauf mit Ihrem Team ab und dokumentieren zusammen mit den Ergebnissen auch die nicht abgedeckten Bereiche.

Wir sagen außerdem offen, wenn ein Testprogramm nicht die richtige Investition ist. Ist die Antwort bereits aus der Architektur ersichtlich, bestätigt ein Testprogramm sie lediglich auf teure Weise.

Die zwei typischen Einsatzfälle

Fast jeder Auftrag in diesem Bereich gehört zu einem von zwei Fällen. In beiden geht es um eine konkrete Systemkombination und nicht um Konformität im abstrakten Sinn.

1. 1

   Ladestation eines anderen Anbieters gegen Ihre Plattform prüfen

   Sie erwägen Hardware eines bisher nicht eingesetzten Anbieters oder haben sie bereits gekauft. Zu klären ist, ob sie mit Ihrem Managementsystem in genau dem von Ihnen betriebenen Release funktioniert – einschließlich der Abläufe, von denen Ihr Betrieb abhängt.

2. 2

   Plattform wechseln und vorhandene Hardware erneut prüfen

   Sie wechseln zu einem anderen CSMS. Jede Ladestation der Flotte kommuniziert nun mit einem Backend, das sie noch nie verwendet hat. Welche Geräte Probleme zeigen werden, lässt sich aus Datenblättern nicht ablesen. Ein Test vor der Migration ist deutlich günstiger als die Entdeckung während der Umstellung.

Beide Fälle werden gleich beantwortet: gegen die benannte Plattform und das konkrete Release, mit dem für Sie relevanten Nachrichtensatz und einschließlich der Fehlerpfade.

Der gemeinsame Prüfablauf

Vor dem ersten Test erstellen wir die Checkliste gemeinsam. Sie ist das zentrale Arbeitsdokument des gesamten Auftrags.

1. 1

   Wir entwerfen sie für Ihren Betrieb

   Ausgangspunkt sind das Verhalten Ihrer Flotte, die Funktionen Ihrer Plattform und die Fehler, die Ihrem Betrieb tatsächlich schaden würden. Eine generische Konformitätsliste prüft oft Funktionen, die niemand benötigt, und übersieht die entscheidenden Abläufe.

2. 2

   Sie ergänzen die Checkliste

   Ihre Fachleute kennen die Fälle, die bereits Probleme verursacht haben. Diese werden aufgenommen und sind häufig die wertvollsten Punkte der gesamten Liste.

3. 3

   Wir führen sie jedes Mal vollständig aus

   Für jedes Gerät und jede Plattform im vereinbarten Umfang gilt dieselbe Checkliste. So sind Ergebnisse vergleichbar und nicht nur anekdotisch.

4. 4

   Die Checkliste bleibt bei Ihnen

   Nach Abschluss gehört die Checkliste Ihnen. Sie wird zum Abnahmetest für den nächsten Anbieter und die nächste Migration und ist damit wertvoller als ein einzelner Prüfbericht.