OCPP

Referenz zum Treiber OCPP: das eingebettete Zentralsystem, Zertifikate der Ladestationen, Tags je Ladepunkt und die Namensregel Meter/Status.

Der Treiber OCPP macht Ganter Lab zum Zentralsystem für Ladestationen für Elektrofahrzeuge, die das Open Charge Point Protocol sprechen. Wie bei LoRaWAN ist die Richtung umgekehrt: Die Station verbindet sich nicht mit der Ladestation, sondern die Ladestation verbindet sich mit Ganter Lab über einen WebSocket, meldet sich an und sendet ihre Messdaten von sich aus.

Das eingebettete Zentralsystem startet, sobald das erste aktivierte OCPP-Gerät in den laufenden Connector geladen wird, und hört auf, sobald das letzte entfernt oder deaktiviert wird: Ist keine Ladestation eingerichtet, lauscht überhaupt nichts auf dem Port. Eine hinzuzufügen holt es zurück, ohne die Anwendung neu zu starten. Jedes Gerät, das Sie einrichten, steht für eine Ladestation, erkannt an der Kennung, unter der sie sich verbindet.

Zentralsystem und Ports

Der Lauscher ist immer mit TLS; ein Lauscher mit einfachem HTTP wird überall abgelehnt außer auf Loopback, das es nur für Tests im selben Prozess gibt. Eine Ladestation meldet sich mit ihrer BootNotification an (beantwortet mit einem Herzschlagintervall von 60 Sekunden), und jede zur Autorisierung vorgelegte Karte wird angenommen: Ganter Lab beobachtet das Laden, es verwaltet weder Tarife noch Zutritt.

Zertifikate

Die Serverseite des TLS-Handschlags weist das eigene OPC UA-Zertifikat der Anwendung vor. Jede Ladestation muss ein Client-Zertifikat vorweisen:

1. Es muss auf diesem Windows-Rechner eine gültige Kette bilden, ohne Verstöße gegen die TLS-Richtlinie; eine fehlgeschlagene Prüfung weist die Verbindung ab, und das Journal hält fest, welche Prüfung fehlschlug.
2. Sein Common Name im Antragsteller oder ein alternativer DNS-Name muss die Kennung der Ladestation nennen, unter der sie sich verbindet. Ein Zertifikat, das eine andere Ladestation nennt als der Pfad der Verbindung, wird abgewiesen.

Ein Handschlag ohne Client-Zertifikat wird verworfen, bevor Daten fließen.

Verbindungsfelder

Es gibt keine Felder für Host, Port oder Anmeldedaten: Die Ladestation hält die Einzelheiten der Verbindung, und diese Station muss nur wissen, welche Ladestation das Gerät meint. Es gibt auch keine Felder für das Abfrageintervall. OCPP sendet von sich aus, die Ladestation schickt MeterValues und StatusNotification nach ihrem eigenen Takt, und die Tags frischen sich aus den zuletzt empfangenen Daten in einem festen Ein-Sekunden-Takt auf.

Eine Ladestation, die sich noch nicht verbunden hat, oder ein Ladepunkt, der noch nichts gemeldet hat, hat daher keinen Messwert, keinen fehlgeschlagenen. Ihre Tags bleiben leer, das Gerät meldet, dass nichts beobachtet wurde, statt offline zu gehen, und es wird kein Fehlschlag protokolliert: Das ist der normale Zustand einer Ladestation, die gerade eingerichtet wurde und noch nicht angekommen ist.

Tags

Ein OCPP-Tag liest einen Ladepunkt der Ladestation (den connector im Sinne von OCPP: eine Steckerposition, ab 1 nummeriert). Es gibt zwei Arten von Tags, die am Namensende des Tags unterschieden werden, das geprüft wird:

Ein Name ohne eines der beiden Enden wird von der Prüfung abgelehnt: Benennen Sie Tags wie Connector1Meter und Connector1Status.

OCPP-Tags sind nur lesend: Das Feld für den Zugriff bietet keine schreibbare Wahl an, und ein Schreibvorgang wird abgelehnt, statt vorgetäuscht. Eine Ladestation zu befehlen ist ein Befehl für sich, gleich beschrieben, und kein Wert, der auf einen Tag geschrieben wird.

Befehle

Eine Ladestation wird nicht nur gelesen, sondern auch befehligt. Jedes OCPP-Gerät trägt die Befehle unten als Methoden am Gerät im eigenen OPC UA-Adressraum dieser Station, alles, was eine Methode aufrufen kann, kann sie also erteilen: ein OPC UA-Client oder eine Aktion in Logic, die sie aufruft.

Jeder Befehl nimmt als erstes Argument die Kennung der Ladestation und gibt als Ergebnis die eigene Antwort der Ladestation zurück.

AttributeType ist eines von Actual, Target, MinSet, MaxSet.

Auf die Antwort warten. Ein Befehl ist nicht fertig, wenn die Station ihn gesendet hat. Die Station hält den Aufruf offen, bis die Ladestation genau den Auftrag beantwortet, den sie gesendet hat, zugeordnet über die Korrelationskennung, die mitreist, und meldet erst dann Erfolg und gibt die Antwort zurück. Drei Dinge beenden ihn anders, jedes als Fehlschlag mit seinem Grund gemeldet:

• Die Ladestation ist nicht verbunden, oder ihre Verbindung ist nicht offen. Es wird nichts gesendet.
• Die Ladestation antwortet mit einem OCPP-Fehler, zum Beispiel bei einem Befehl, den sie nicht umsetzt. Der Fehlercode ist der Grund.
• 30 Sekunden vergehen ganz ohne Antwort. Ein Befehl, den niemand beantwortet hat, ist ein Fehlschlag, nie ein Erfolg.

Ein Befehl für eine Ladestation, die ein Gerät nicht trägt oder die nicht verbunden ist, wird sofort abgelehnt, statt in eine Warteschlange gestellt zu werden.

Gerätesuche

Suchen führt beim Treiber OCPP die Ladestationen auf, die gerade mit dem Zentralsystem verbunden sind, und die Kanäle eines Kandidaten zu lesen schlägt je einen Tag Meter und Status für jeden Ladepunkt vor, den die Ladestation bisher gemeldet hat.

Die erste Ladestation wird immer von Hand eingerichtet. Nichts kann sich verbinden, bevor das Zentralsystem lauscht, und es lauscht erst, wenn es hier ein OCPP-Gerät gibt, ein Suchlauf in einer Anlage ohne eingerichtete Ladestation findet also nichts und sagt es. Legen Sie dieses erste Gerät mit der Kennung an, unter der sich die Ladestation verbinden wird; danach lässt sich eine Ladestation, die sich verbunden hat, finden. Der allgemeine Ablauf der Gerätesuche steht auf der Seite Connector.

Die Kennung wird ohne Rücksicht auf Groß- und Kleinschreibung verglichen, im Zertifikat, im Pfad der Verbindung und gegen das Gerät: Eine Ladestation, die sich als cp-a mit einem Zertifikat auf CP-A verbindet, ist dieselbe Ladestation wie ein Gerät, dessen Kennung CP-A lautet.