Configuration OCPP

cFos Power Brain wallbox tant que client OCPP

Pour cela, cliquez sur « cFos Power Brain wallbox Configuration » et saisissez les informations suivantes :

Wallbox comme client OCPP : activer

identifiantL'ID ChargeBox défini dans le backend. Si vous cFos Power Brain wallbox tant que client OCPP dans le cFos Charging Manager, celui-ci doit correspondre à l'ID que vous avez entré comme « Adresse » dans le cFos Charging Manager pour le cFos Charging Manager.
serveurL'URL du backend OCPP. Si vous cFos Power Brain wallbox tant que client OCPP dans le gestionnaire de charge cFos, saisissez l'adresse IP du gestionnaire de charge cFos et le port que vous avez configuré comme port de serveur OCPP dans les paramètres du gestionnaire de charge.

Exploiter une wallbox OCPP avec le gestionnaire de charge cFos

Pour ce faire, cliquez sur « Paramètres » pour la wallbox correspondante et saisissez les informations suivantes :

Type d'appareilEVSE avec OCPP 1.6
adresseIci, vous devez entrer l'ID ChargeBox qui a été configuré dans l'EVSE.
IdentifiantIci, vous devez entrer l'ID du connecteur. Pour les wallbox avec un point de charge, c'est toujours 1, pour deux points de charge, c'est 1 ou 2, etc.

Passerelle OCPP dans le gestionnaire de charge cFos

La passerelle OCPP dans le gestionnaire de charge cFos permet à chaque EVSE configuré dans la gestion de charge de ressembler à un OCPP EVSE par rapport à un backend OCPP.
Il fournit au backend une interface uniforme, indépendamment de ce que l'EVSE spécifique peut faire. L'EVSE doit seulement être contrôlable à distance par le gestionnaire de charge cFos ; en particulier, il n'a pas à supporter l'OCPP.
Si l'EVSE prend en charge OCPP, le gestionnaire de charge cFos peut compenser certaines faiblesses par rapport au backend. Fonctionnalités de la passerelle OCPP :
  • Faire en sorte qu'une wallbox qui ne peut pas faire d'OCPP apparaisse au backend comme une seule avec OCPP
  • Contrôlez une wallbox compatible OCPP qui est connectée à un backend externe (par exemple à des fins de facturation) à l'aide d'OCPP dans la gestion de la charge locale
Figure Passerelle OCPP dans le gestionnaire de charge cFos

Certains EVSE avec OCPP, tels que l'Innogy eBox professional S ou Mennekes Amtron, peuvent transmettre des données de compteur conformes à la loi d'étalonnage au backend OCPP. La passerelle OCPP du gestionnaire de charge cFos peut transmettre de manière transparente ces données de compteur au backend.

La passerelle n'est pas requise pour faire fonctionner un cFos Power Brain wallbox, car le cFos Power Brain wallbox permet le fonctionnement simultané d'OCPP vers le backend pour l'autorisation et la facturation et Modbus pour la gestion de la charge. Pour ce faire, configurez le client OCPP sous "cFos Power Brain Configuration" et activez également Modbus. cFos Power Brain wallbox sous "Démarrer" et entrez l'adresse ou les données du port COM et l'ID Modbus.

Vous avez besoin d'une licence de passerelle OCPP supplémentaire pour chaque point de charge.

Si vous souhaitez configurer la passerelle, vous devez configurer les paramètres suivants. Pour ce faire, cliquez sur « Paramètres » pour l'EVSE correspondant et entrez les éléments suivants :

URL de la passerelle OCPPL'URL du backend de facturation OCPP
Mot de passe de la passerelle CPPUn mot de passe que l'opérateur du backend vous donne pour ce EVSE
ID client de la passerelle OCPPL'ID avec lequel la passerelle rapporte au backend. L'opérateur du backend vous donne cet identifiant

Certificats pour les clients et serveurs OCPP

Les certificats sont utilisés lors de l'utilisation de connexions TLS chiffrées entre le client et le serveur. Pour réussir à établir une telle connexion, le serveur a toujours besoin d'un certificat et d'une clé privée associée. Le gestionnaire de charge cFos dispose déjà d'un certificat auto-signé à bord. Il n'est donc pas nécessaire d'importer vos propres certificats. Cependant, cette option existe à la fois côté serveur et côté client.

Côté serveur, vous pouvez importer votre propre certificat et la clé privée associée. Ce certificat peut être auto-signé ou signé par une autorité de certification officielle. Si aucun certificat CA (CA = Certificate Authority) n'est stocké dans le client, une connexion TLS est établie dans tous les cas. Si un ou plusieurs certificats CA sont stockés dans le client, les certificats de serveur respectifs doivent correspondre (profil de sécurité OCPP 2). Le certificat de serveur lui-même peut être stocké en tant que certificat CA. Si le client dispose d'une connexion à Internet, les certificats racine des autorités de certification qui ont signé le certificat du serveur peuvent également y être stockés. Cependant, vous pouvez également stocker votre propre certificat racine qui a signé le certificat du serveur.

Comme niveau de sécurité supplémentaire, un certificat peut également être utilisé dans le sens inverse (OCPP Security Protocol 3). A cet effet, un certificat et la clé privée associée sont stockés dans le client. Parmi les certificats CA, le serveur reçoit également ce certificat ou un certificat racine qui a signé le certificat client. La connexion TLS n'est établie que si le serveur peut également vérifier le certificat client.

Vous pouvez créer vous-même des certificats, par exemple avec le programme OpenSSL, qui est disponible gratuitement pour Windows et Linux. Voici quelques exemples utilisant OpenSSL. Les exemples utilisent un fichier de configuration enregistré au format UTF8 conjointement avec le paramètre -config. Cela présente l'avantage que les trémas et autres caractères Unicode peuvent également être utilisés dans le certificat. Le fichier de configuration a toujours le format suivant :

[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
         

Création d'une clé privée rootCA.key pour un certificat racine :
openssl genrsa -des3 -out rootCA.key 4096

Créez un certificat racine auto-signé rootCA.crt à l'aide de la clé privée rootCA.key créée ci-dessus et du fichier de configuration rootCA.cnf (le paramètre -days spécifie le nombre de jours de validité du certificat) :
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 365 -out rootCA.crt -config rootCA.cnf -utf8

Création d'une clé privée client.key pour un certificat client :
openssl genrsa -out client.key 2048

Création d'une demande de signature de certificat (CSR) client.csr pour un certificat client à l'aide de la clé privée client.key créée ci-dessus et du fichier de configuration client.cnf :
openssl req -new -key client.key -out client.csr -config client.cnf -utf8

Création d'un certificat client client1.crt, qui est signé avec le certificat racine ci-dessus rootCA.crt et la clé privée associée rootCA.key (là encore, le paramètre -days spécifie la durée de validité du certificat) :
openssl x509 -req -in client.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out client.crt -days 365 -sha256