Hierzu klicken Sie auf "cFos Power Brain Wallbox Konfiguration" und tragen folgendes ein:
Wallbox als OCPP Client: aktivieren
ID | Die im Backend eingestellte ChargeBox ID. Wenn Sie die cFos Power Brain Wallbox als OCPP Client im cFos Charging Manager betreiben möchten, muss diese mit der ID übereinstimmen, die Sie als "Adresse" im cFos Charging Manager bei der entsprechenden Wallbox eingetragen haben. |
Server | Die URL des OCPP Backends. Wenn Sie die cFos Power Brain Wallbox als OCPP Client im cFos Charging Manager betreiben möchten, tragen Sie hier die IP-Adresse des cFos Charging Managers und den Port ein, den Sie in den Einstellungen des Charging Manager als OCPP Server Port konfiguriert haben. |
Hierzu klicken Sie auf "Einstellungen" der entsprechenden Wallbox und tragen folgendes ein:
Geräte-Typ | EVSE with OCPP 1.6 |
Adresse | Hier müssen Sie die ChargeBox ID eintragen, die in der Wallbox konfiguriert wurde. |
Id | Hier müssen Sie die Connector ID eingeben. Für Wallboxen mit einem Ladepunkt ist dies stets 1, bei zwei Ladepunkten entsprechend 1 oder 2, usw. |
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.
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:
OCPP Gateway URL | Die URL des OCPP Abrechnungs-Backends |
CPP Gateway Passwort | Ein Passwort, das ihnen der Betreiber des Backend für diese Wallbox zuteilt |
OCPP Gateway Client ID | Die ID, mit der sich das Gateway beim Backend meldet. Diese ID gibt Ihnen der Betreiber des Backends |
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