So beenden Sie einen Ladevorgang mit StopTransaction

Einführung

Um eine zu stoppen OCPP Während des Ladevorgangs müssen das Ladegerät und das Lademanagementsystem für Elektrofahrzeuge (EV) einem strengen Prozess folgen. Bei falscher Ausführung kann es zu Fehlern kommen und Ladegeräte für Elektrofahrzeuge für den nächsten Fahrer blockieren.

‍

Es gibt viele Möglichkeiten, den Ladevorgang für Elektrofahrzeuge zu beenden (und wir werden uns alle ansehen). Die häufigsten Auslöser sind jedoch, dass der Benutzer eine Stopptaste auf der Benutzeroberfläche des EV-Ladegeräts drückt, das Elektrofahrzeug vollständig aufgeladen ist oder das EV-Ladegerät beschließt, den Ladevorgang zu beenden (z. B. das Zeitlimit erreicht oder ein Hardwarefehler).

‍

Unabhängig von der Methode, mit der die Sitzung beendet wurde, sendet das EV-Ladegerät (OCPP-Client) eine neue Statusbenachrichtigung und eine StopTransaction-Anfrage an das Ladeverwaltungssystem (OCPP-Backend).

‍

Diese OCPP-Meldungen beenden den Ladevorgang und gehören zu den häufigsten Meldungen in der Welt des Ladens von Elektrofahrzeugen. Falls Sie dies noch nicht getan haben, empfehlen wir Ihnen, sich mit dem Starten eines Ladevorgangs für Elektrofahrzeuge vertraut zu machen, bevor Sie lernen, wie Sie einen Ladevorgang beenden. Lesen Sie dazu bitte die OCPP StartTransaction-Anleitung zuerst.

‍

Um die vom OCPP-Client initiierte OCPP-Ladesitzung, auch Transaktion genannt, zu beenden, benötigen wir die folgenden OCPP-Meldungen:

• Statusbenachrichtigungsanfrage
• StopTransaction-Anfrage

‍

So verwenden Sie ein Status-Benachrichtigungs-Update, um eine OCPP-Ladesitzung zu beenden

Bevor ein Ladevorgang beendet wird, befindet sich das EV-Ladegerät im Lademodus. Dies bedeutet, dass zuvor ein Ladevorgang eingeleitet wurde und die letzte vom EV-Ladegerät gesendete StatusNotification „wird geladen“.

‍

Um den Ladevorgang zu beenden, sendet das EV-Ladegerät eine neue StatusNotification-Anfrage (StatusNotification.req) an das OCPP-Backend. Die Statusbenachrichtigung ändert den aktiven Status von „Wird geladen“ in einen der folgenden Ladepunktstatus:

• „Verfügbar“
• „Dev suspendiert“
• „Fertigstellung“
• „Nicht verfügbar“
• „Fehlerhaft“

‍

Die Vielfalt der Statustypen spiegelt die Vielzahl der Gründe wider, die für das Ende eines Ladevorgangs sprechen. Im Folgenden erläutern wir die Bedingungen, die den jeweiligen Ladepunktstatus auslösen:

„Ladet"→ „Verfügbar“
‍Der Ladevorgang wird beendet, ohne dass eine Benutzeraktion erforderlich ist (z. B. wurde das feste Kabel auf der EV-Seite entfernt).

„Wird geladen“ → „SuspendeDev“
‍Der Ladevorgang wird auf Anfrage eines Elektrofahrzeugs gestoppt (das Elektrofahrzeug benötigt keine zusätzliche Energie).

„Wird aufgeladen“ → „SuspendedEVSE“
Der Ladevorgang wird auf Anfrage von EVSE (Electric Vehicle Supply Equipment) gestoppt (z. B. aufgrund einer intelligenten Ladebeschränkung, die Transaktion wurde in einer StartTransaction.conf nicht korrekt autorisiert).

„Laden"→ „Fertigstellen“
‍Der Benutzer stoppt die Transaktion über die Benutzeroberfläche des Ladegeräts oder eine RemoteStopTransaction-Nachricht + weitere Benutzeraktionen sind erforderlich (z. B. das Kabel entfernen und den Parkplatz verlassen).

„Wird geladen“ → „Nicht verfügbar“
‍Der Ladevorgang wurde beendet + es ist keine Benutzeraktion erforderlich + Der Connector wird voraussichtlich nicht verfügbar sein.

„Aufladen“ → „Fehlerhaft“
‍Es wurde ein Fehler erkannt, der weitere Ladevorgänge verhindert (Ladefehler).

Das mag komplex oder unnötig klingen, aber es gibt viele wichtige Einblicke in den Ladefehler während des Ladevorgangs und hilft dabei, Ladestationen effizient zu betreiben.

‍

Zusammenfassend lässt sich sagen, dass das Ladegerät, wenn das EV-Ladegerät den Ladevorgang beenden möchte, eine neue StatusNotification.req-Nachricht an den OCPP-Server sendet, die von „Laden“ zu einer der oben genannten Statustransaktionen wechselt. Ohne diese Statusaktualisierung hört das Ladegerät nicht auf zu laden.

Wenn das OCPP-Backend bereit ist, antwortet es mit einer StatusNotification.conf-Nachricht, um zu bestätigen, dass die Nachricht empfangen und verstanden wurde. Die Bestätigung enthält keine Informationen.

Unten sehen Sie den Ablauf der Statusbenachrichtigungsanforderung in OCPP:

‍

‍

Wie oben erwähnt, ist der Statusbenachrichtigung.req Die Nachricht wird in vielen Szenarien nach dem Beenden der Sitzung häufig verwendet. Sie enthält die folgenden Informationen:

• Connector-ID: Ist die Kennung des Ladeanschlusses, die typischerweise 1 oder 2 ist. Wenn die Ladestation mehr Stecker hat, ist diese Zahl höher.‍
• Fehlercode: Zeigt mögliche Fehler an, die vom Ladegerät gemeldet werden. Um die Sitzung zu starten, sollte sie idealerweise „NoError“ enthalten. Mögliche Fehler können jedoch „EvCommunicationError“, „UnderVoltage“ usw. sein. In vielen Fällen wird im Status „OtherError“ angezeigt und zusätzlich ein Herstellerfehlercode info oder VendorErrorCode Feld. Bei großen Operationen werden diese Fehlercodes sehr wichtig und bieten Einblicke in mögliche Hardwarefehler.‍
• Status: Wie oben erwähnt, sollte dies von „Laden“ auf „Verfügbar“, „Fertig stellen“ usw. geändert werden.

‍

‍

Hinweis: Wenn das Ladegerät mehr als eine Steckdose hat, wird die ConnectorID mit 1,2,3 usw. nummeriert. Dies ist wichtig, da einige Ladegeräte das gleichzeitige Laden ermöglichen. Anschluss 1 befindet sich dann möglicherweise im Status „Verfügbar“, während Anschluss 2 immer noch den Status „Wird geladen“ hat. Wenn jeweils nur ein Stecker aufgeladen werden kann, sollten die anderen Anschlüsse eine StatusNotification-Anfrage senden, die den Status „Nicht verfügbar“ enthält.

‍

Hier sehen Sie ein Beispiel für Statusbenachrichtigung.req

{
„ConnectorID“: 2,
„errorCode“: „Kein Fehler“,
„status“: „SuspendeDev“,
„Zeitstempel“: „12.09.2022 10:01:00.515 Z“
}

‍

‍

So stoppen Sie die Transaktionsanfrage und den Energiebericht in OCPP

Nach dem Statuswechsel von „Charging“ in einen der sechs möglichen Status sendet das EV-Ladegerät die StopTransaction-Anfrage (StartTransaction.req).

‍

Die Zeit zwischen der Statusänderung und der Stopp-Transaktionsanforderung kann je nach EVSE-Hersteller variieren. Bei Ampcontrol haben wir Zeiten zwischen 1 Sekunde und 10 Sekunden beobachtet. Dies ist die wichtige Information, dass der Ladevorgang beendet wurde. Sie wird vom OCPP-Client an den OCPP-Server gesendet.

‍

Nach Erhalt einer StopTransaction.Req antwortet der OCPP-Server mit einer StopTransaction.conf. Daher überprüft der Server die in der Stopp-Transaktionsanforderung enthaltenen Informationen, wie TransactionId, Timestamp oder IDTag.

‍

‍

Neben einem Stop-Zeitstempel, der TransactionID und dem IdTag, enthält die StopTransaction-Nachricht von OCPP auch zwei nützliche Felder: reason und meterStop.

‍

Das Feld „Grund“ identifiziert den Auslöser für die Beendigung des Ladevorgangs. Dies hilft dem Betreiber der Ladestation bei der Fehlerbehebung beim Ladevorgang und kann den Fahrer darüber informieren, warum der Ladevorgang unterbrochen wurde. Mögliche Gründe sind:

• Lokal: Lokal per Benutzeranfrage an der Ladestation gestoppt. Dies ist eine reguläre Beendigung einer Transaktion. Beispiele: Vorzeigen eines RFID-Tags oder Drücken einer Taste zum Stoppen.
• Leistungsverlust: Vollständiger Stromausfall.
• Neustarten: Ein lokal initiierter Reset/Neustart ist aufgetreten.
• Fernbedienung: Per Benutzeranfrage aus der Ferne gestoppt. Dies ist eine reguläre Kündigung einer Transaktion — Beispiele: Kündigung über eine Smartphone-App oder Überschreitung eines (nicht lokalen) Prepaid-Guthabens.
• SoftReset: Ein Soft-Reset-Befehl wurde empfangen.
• Elektrogerät getrennt: Der Not-Aus-Taster wurde betätigt oder das Fahrzeug wurde abgeklemmt.
• Deautorisiert: Die Transaktion wurde aufgrund des Autorisierungsstatus in einer StartTransaction.conf gestoppt
• Andere: Irgendein anderer Grund
• Befehl zum Entsperren: Das OCPP-Backend hat einen Befehl zum Entsperren des Connectors gesendet (ermöglicht das physische Entsperren eines Ladepunktsteckers).

Das Feld „MeterStop“ meldet den Energieverbrauch am Ende des Ladevorgangs. Dies hilft dabei, die insgesamt geladenen Kilowatt und die Gesamtenergiekosten für diesen Ladevorgang korrekt zu melden.

‍

Hinweis: Das OCPP-Backend (CMS) führt in der Regel eine Plausibilitätsprüfung durch, um die Daten in StopTransaction.req zu überprüfen. Das OCPP-Backend sollte jedoch immer mit einer StopTransaction.conf antworten. Wenn Sie nicht mit einer StopTransaction.conf antworten, versucht die Ladestation nur, dieselbe Meldung erneut zu versuchen, wie unter Fehlerantworten auf transaktionsbezogene Nachrichten angegeben.

‍

Zusammenfassend lässt sich sagen, dass sowohl die Anfrage als auch die Bestätigungsnachricht wichtige Informationen enthalten, die wir besprechen möchten:

• ID-Tag: Zeigt die Kennung an, die die Beendigung des Ladevorgangs angefordert hat. Dies ist optional, da eine Ladestation den Ladevorgang beenden kann, ohne dass ein IDTag vorhanden ist, z. B. im Falle eines Resets.
• Stopp des Zählers: Enthält den Zählerwert in Wh für den Connector am Ende der Transaktion. 
• Zeitstempel: Enthält das Datum und die Uhrzeit, an denen die Transaktion gestoppt wurde.
• Transaktions-ID: Enthält die TransactionID, wie sie vom empfangen wurde Starten Sie Transaction.conf.
• Grund: Zeigt den Grund an, warum die Transaktion gestoppt wurde.
• Transaktionsdaten: Dies enthält Informationen zur Transaktionsnutzung, die für Abrechnungszwecke relevant sind. Darüber hinaus wird das TransactionData-Element als Container für eine beliebige Anzahl von MeterValues verwendet, wobei dieselbe Datenstruktur wie die MeterValue-Elemente von verwendet wird OCPP MeterValues.REQ
• ID-Tag-Informationen: Enthält Informationen zum Autorisierungsstatus, zum Ablauf und zur Eltern-ID.

‍

Hier siehst du ein Beispiel für eine StopTransaction.req und die StopTransaction.conf:

Stoppen Sie Transaction.req

{
„reason“: „Lokal“,
„Transaktions-ID“: 568161113,
„MeterStop“: 4329600,
„Zeitstempel“: „08.09.2022 10:31:26,127 Z“
}

‍

Stoppen Sie Transaction.conf

{
„IDTagInfo“:
{
„status“: „Akzeptiert“
}
}

‍

‍

Zusammenfassung

Die StopTransaction- und StatusNotification-Nachrichten sind wichtige OCPP-Nachrichten, die häufig in Ladenetzwerken für Elektrofahrzeuge oder privaten Ladestationen verwendet werden.

Der typische Vorgang zum Beenden eines Ladevorgangs ist:

1. Ändern Sie den Ladestatus von „Wird geladen“ auf „Verfügbar“, „SuspendeDev“ usw.
2. Stoppen Sie den Ladevorgang per Benutzerinteraktion, Fahrzeug, Ladegerät oder Fernsteuerung.
3. Das EV-Ladegerät sendet die StopTransaction.req-Nachricht, die Zählerwerte für eine korrekte Meldung enthält.