cFos Power Brain Wallbox als OCPP Client betreiben

Hierzu klicken Sie auf "cFos Power Brain Wallbox Konfiguration" und tragen folgendes ein:

Wallbox als OCPP Client: aktivieren

Eine OCPP Wallbox mit dem cFos Charging Manager betreiben

Hierzu klicken Sie auf "Einstellungen" der entsprechenden Wallbox und tragen folgendes ein:

OCPP Gateway im cFos Charging Manager

Das OCPP Gateway im cFos Charging Manager erlaubt, jede Wallbox, die im Lastmanagement eingerichtet ist, gegenüber einen OCPP Backend wie eine OCPP Wallbox aussehen zu lassen.
Es stellt dem Backend gegenüber ein einheitliches Interface zur Verfügung, unabhängig davon, was die konkrete Wallbox kann. Die Wallbox muss nur vom cFos Charging Manager fernsteuerbar sein, sie muss insbesondere kein OCPP unterstützen.
Falls die Wallbox OCPP unterstützt, kann der cFos Charging Manager gegenüber dem Backend einige Schwächen ausgleichen. Funktionen des OCPP Gateway:

• Eine Wallbox, die kein OCPP kann, gegenüber dem backend wie eine mit OCPP erscheinen lassen
• Eine OCPP-fähige Wallbox, die in ein externes backend (z.B. zu Abrechnungszwecken) eingebucht ist, mittels OCPP im lokalen Lastmanagement steuern

Einige Wallboxen mit OCPP, wie z.B. die Innogy eBox professional S oder Mennekes Amtron, können eichrechtskonforme Zählerdaten ans OCPP Backend übermitteln. Das OCPP Gateway des cFos Charging Managers kann solche Zählerdaten transparent ans Backend weiterleiten.

Zum Betrieb einer cFos Power Brain Wallbox ist das Gateway nicht erforderlich, denn die cFos Power Brain Wallbox erlaubt den gleichzeitigen Betrieb von OCPP zum Backend zur Autorisierung und Abrechnung und Modbus zum Lastmanagement. Hierzu konfigurieren Sie unter "cFos Power Brain Konfiguration" den OCPP Client und aktivieren zusätzlich Modbus. Dann tragen Sie unter "Start" eine cFos Power Brain Wallbox ein und geben die Adresse bzw. COM Port-Daten und Modbus ID an.

Pro Ladepunkt benötigen Sie eine zusätzliche OCPP Gateway Lizenz.

Wenn Sie das Gateway einrichten möchten, müssen Sie folgende Parameter konfigurieren. Hierzu klicken Sie auf "Einstellungen" der entsprechenden Wallbox und tragen Folgendes ein:

Zertifikate für OCPP Clients und Server

Zertifikate kommen bei der Verwendung verschlüsselter TLS-Verbindungen zwischen Client und Server zum Einsatz. Zum erfolgreichen Aufbau einer solchen Verbindung benötigt der Server stets ein Zertifikat und einen zugehörigen privaten Schlüssel. Der cFos Charging Manager hat dazu bereits ein selbst-signiertes Zertifikat an Bord. Es müssen also keine eigenen Zertifikate eingespielt werden. Diese Option besteht allerdings sowohl auf der Server- als auch auf Clientseite.

Serverseitig können ein eigenes Zertifikat und der zugehörige private Schlüssel eingespielt werden. Dabei kann dieses Zertifikat selbst-signiert oder auch von einer offiziellen Zertifizierungsstelle signiert sein. Wird im Client kein CA-Zertifikat (CA = Certificate Authority) hinterlegt, kommt so in jedem Fall eine TLS-Verbindung zu Stande. Werden im Client ein oder mehrere CA-Zertifikate hinterlegt, müssen die jeweiligen Server-Zertifikate dazu passen (OCPP Security Profile 2). Als CA-Zertifikat kann das Server-Zertifikat selbst hinterlegt werden. Hat der Client eine Verbindung ins Internet, können dort auch Root-Zertifikate von Zertifizierungsstellen hinterlegt werden, die das Server-Zertifikat signiert haben. Es kann aber auch ein eigenes Root-Zertifikat hinterlegt werden, das das Server-Zertifikat signiert hat.

Als zusätzliche Sicherheitsstufe kann zusätzlich ein Zertifikat auch in umgekehrter Richtung verwenden werden (OCPP Security Protocol 3). Dazu werden im Client ein Zertifikat und der zugehörige private Schlüssel hinterlegt. Der Server erhält unter den CA-Zertifikaten ebenfalls dieses Zertifikat oder ein Root-Zertifikat, das das Client-Zertifikat signiert hat. Damit kommt die TLS-Verbindung nur zu Stande, wenn auch der Server das Client-Zertifikat verifizieren kann.

Sie Können Zertifikate selbst erstellen, z.B. mit dem Programm OpenSSL, das kostenlos für Windows, wie auch für Linux erhältlich ist. Es folgen ein paar Beispiele unter Verwendung von OpenSSL. Die Beispiele verwenden in Verbindung mit dem Parameter -config eine Konfigurationsdatei, die im UTF8-Format gespeichert ist. Dies hat den Vorteil, dass im Zertifikat auch Umlaute und sonstige Unicode-Zeichen verwendet werden können. Die Konfigurationsdatei hat stets folgendes Format:

[req]
prompt = no
distinguished_name = dn
req_extensions = ext

[dn]
CN = Unsere Tiefgarage
emailAddress = info@tiefgarage-koeln.de
O = Tiefgarage Köln GmbH
OU = Abteilung 13
L = Köln
C = DE

[ext]
subjectAltName = DNS:tiefgarage-koeln.de,DNS:*.tiefgarage-koeln.de
         

Erstellung eines privaten Schlüssels rootCA.key für ein Root-Zertifikat:
openssl genrsa -des3 -out rootCA.key 4096

Erstellung eines selbst-signierten Root-Zertifikats rootCA.crt unter Verwendung des oben erstellten privaten Schlüssels rootCA.key und der Konfigurationsdatei rootCA.cnf (der Parameter -days gibt an, wieviele Tage lang das Zertifikat gültig ist):
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 365 -out rootCA.crt -config rootCA.cnf -utf8

Erstellung eines privaten Schlüssels client.key für ein Client-Zertifikat:
openssl genrsa -out client.key 2048

Erstellung eines Certificate Signing Requests (CSR) client.csr für ein Client-Zertifikat unter Verwendung des oben erstellen privaten Schlüssels client.key und der Konfigurationsdatei client.cnf:
openssl req -new -key client.key -out client.csr -config client.cnf -utf8

Erstellung eines Client-Zertifikats client1.crt, das mit dem obigen Root-Zertifikat rootCA.crt und dem zugehörigen privaten Schlüssel rootCA.key signiert wird (der Parameter -days gibt wieder an, wie lange das Zertifikat gültig ist):
openssl x509 -req -in client.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out client.crt -days 365 -sha256