Nella Wallbox di cFos Power Brain, è necessario impostare la gestione del carico su "osserva" nelle impostazioni del Charging Manager. Fare quindi clic sulla ruota dentata nel riquadro della wallbox per accedere alle impostazioni. Scorrere fino alla sezione "Impostazioni gateway OCPP".
URL del gateway OCPP | L'URL del backend OCPP, ad esempio ws://ocpp.backend.com/ per connessioni non criptate o wss://ocpp.secure-backend.com/ per connessioni criptate TLS. Per alcuni backend è necessario specificare anche un percorso, ad esempio ws://ocpp.backend.com/path/to/resource/. |
Password del gateway OCPP | Se l'operatore del backend specifica una password per la connessione OCPP, questa deve essere inserita qui. Se l'operatore del backend non specifica una password, questo campo può rimanere vuoto. |
ID cliente gateway OCPP | L'ID con cui il gateway viene segnalato al backend. Questo ID dovrebbe di solito essere specificato dall'operatore del backend. Alcuni backend identificano i loro client tramite chiavi individuali che fanno parte dell'URL, ad esempio ws://xyz123.backend.com/ o ws://ocpp.backend.com/xyz123/. In questo caso, il client può essere libero di scegliere l'ID del client. |
A tal fine, fare clic su "Impostazioni" del relativo EVSE e inserire i seguenti dati:
Tipo di dispositivo | EVSE con OCPP 1.6 |
Indirizzo | Qui è necessario inserire l'ID del ChargeBox configurato nell'EVSE. |
Id | Qui è necessario inserire l'ID del connettore. Per gli EVSE con un punto di ricarica è sempre 1, per due punti di ricarica è 1 o 2, ecc. |
Nelle impostazioni del Charging Manager, alla voce "OCPP Server TLS" selezionare l'opzione "Off" se non devono essere accettate connessioni criptate, "Detect" se devono essere accettate sia connessioni criptate che non criptate e "On" se devono essere accettate solo connessioni criptate. In "Porta server OCPP" selezionare la porta TCP su cui accettare le connessioni OCPP (default 19520). La password del server OCPP è opzionale e, se specificata, deve essere inserita anche nella wallbox.
Nella wallbox, nelle impostazioni OCPP, configurare il protocollo OCPP-1.6J. Inserire l'indirizzo IP del Charging Manager e la porta OCPP selezionata come server. Di solito il prefisso è ws://. Ad esempio, ws://192.168.178.42:19520/
L'ID del ChargeBox selezionato nel Charging Manager deve essere inserito anche nella wallbox. In alcuni wallbox questo non può essere selezionato liberamente, ma è fisso e corrisponde, ad esempio, al numero di serie del box. Questo deve essere inserito di conseguenza nel Charging Manager.
In alcuni wallbox, la porta viene inserita in un campo separato. Per alcuni dispositivi, il ws:// può o deve essere omesso, per altri è obbligatorio. La maggior parte delle wallbox deve essere riavviata dopo la modifica delle impostazioni OCPP.
Alcune wallbox con OCPP, come Innogy eBox professional S o Mennekes Amtron, possono trasmettere i dati dei contatori al backend OCPP in conformità alle norme di calibrazione. Il gateway OCPP del Charging Manager cFos può inoltrare in modo trasparente tali dati del contatore al backend.
Alcune wallbox con OCPP possono inviare i dati Giro-E dal terminale della carta EC al backend. Il cFos Charging Manager inoltra questi dati in modo trasparente al backend.
Il gateway non è necessario per il funzionamento di un EVSE cFos, poiché quest'ultimo consente il funzionamento simultaneo di OCPP al backend per l'autorizzazione e la fatturazione e di Modbus per la gestione del carico. A tal fine, configurare il client OCPP in "Configurazione del regolatore di carica cFos" e attivare anche Modbus. Quindi inserire un EVSE cFos in "Start" e inserire l'indirizzo o i dati della porta COM e l'ID Modbus.
Se si desidera impostare il gateway, è necessario configurare i seguenti parametri. A tal fine, cliccare su "Impostazioni" del corrispondente EVSE e inserire i seguenti dati:
URL del gateway OCPP | L'URL del backend contabile OCPP, ad esempio ws://ocpp.backend.com/ per le connessioni non criptate o wss://ocpp.secure-backend.com/ per le connessioni criptate TLS. Per alcuni backend è necessario specificare anche un percorso, ad esempio ws://ocpp.backend.com/path/to/resource/. |
Password del gateway OCPP | Se l'operatore del backend specifica una password per la connessione OCPP, questa deve essere inserita qui. Se l'operatore del backend non specifica una password, questo campo può rimanere vuoto. |
ID cliente gateway OCPP | L'ID con cui il gateway viene segnalato al backend. Questo ID deve essere solitamente specificato dall'operatore del backend. Alcuni backend identificano i propri client tramite chiavi individuali che fanno parte dell'URL, ad esempio ws://xyz123.backend.com/ o ws://ocpp.backend.com/xyz123/. In questo caso, il cliente può essere libero di scegliere l'ID del cliente. |
I certificati sono utilizzati quando si utilizzano connessioni TLS crittografate tra client e server. Per stabilire con successo una connessione di questo tipo, il server ha sempre bisogno di un certificato e di una chiave privata associata. Il cFos Charging Manager dispone già di un certificato autofirmato. Pertanto, non è necessario importare certificati propri. Tuttavia, questa opzione esiste sia sul lato server che sul lato client.
Sul lato server, è possibile importare un proprio certificato e la corrispondente chiave privata. Questo certificato può essere autofirmato o firmato da un'autorità di certificazione ufficiale. Se nel client non è memorizzato alcun certificato CA (CA = Certificate Authority), la connessione TLS viene stabilita in ogni caso. Se nel client sono memorizzati uno o più certificati CA, i rispettivi certificati del server devono corrispondere (OCPP Security Profile 2). Il certificato del server stesso può essere memorizzato come certificato CA. Se il client dispone di una connessione a Internet, è possibile memorizzare anche i certificati radice delle autorità di certificazione che hanno firmato il certificato del server. Tuttavia, è possibile memorizzare anche il proprio certificato root che ha firmato il certificato del server.
Come ulteriore livello di sicurezza, un certificato può essere utilizzato anche nella direzione opposta (OCPP Security Protocol 3). A tal fine, nel client vengono memorizzati un certificato e la corrispondente chiave privata. Anche il server riceve questo certificato tra i certificati CA o un certificato root che ha firmato il certificato del client. Ciò significa che la connessione TLS viene stabilita solo se il server può verificare anche il certificato del client.
È possibile creare certificati autonomamente, ad esempio con il programma OpenSSL, disponibile gratuitamente per Windows e Linux. Seguono alcuni esempi di utilizzo di OpenSSL. Gli esempi utilizzano un file di configurazione salvato in formato UTF8 insieme al parametro -config. Questo ha il vantaggio di poter utilizzare nel certificato anche gli umlaut e altri caratteri Unicode. Il file di configurazione ha sempre il seguente formato:
[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
Creazione di una chiave privata rootCA.key per un certificato root:openssl genrsa -des3 -out rootCA.key 4096
Creare un certificato root autofirmato rootCA.crt utilizzando la chiave privata rootCA.key creata in precedenza e il file di configurazione rootCA.cnf (il parametro -days specifica per quanti giorni è valido il certificato):openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 365 -out rootCA.crt -config rootCA.cnf -utf8
Creazione di una chiave privata client.key per un certificato client:openssl genrsa -out client.key 2048
Creare una Certificate Signing Request (CSR) client.csr per un certificato client utilizzando la chiave privata client.key creata in precedenza e il file di configurazione client.cnf:openssl req -new -key client.key -out client.csr -config client.cnf -utf8
Creazione di un certificato client client1.crt, firmato con il certificato root rootCA.crt di cui sopra e con la relativa chiave privata rootCA.key (il parametro -days specifica ancora una volta la durata di validità del certificato):openssl x509 -req -in client.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out client.crt -days 365 -sha256
È possibile utilizzare una Wallbox cFos Power Brain in parallelo con Modbus e OCPP, ad esempio per integrarla nella gestione del carico locale tramite Modbus e per collegarla a un backend di fatturazione tramite OCPP. A tal fine, nelle impostazioni della wallbox cFos Power Brain deve essere attivata la funzione "Attiva Modbus" e deve essere configurata una porta TCP o un parametro COM in modo che la wallbox possa essere indirizzata tramite Modbus. Inoltre, è necessario impostare un URL OCPP per il backend, l'ID del client OCPP e, se applicabile, l'ID del connettore OCPP nelle impostazioni OCPP. OCPP inizia quindi a caricare i processi, cioè le transazioni. Determina quindi se la transazione è consentita sulla base dell'RFID trasmesso e, se necessario, avvia il caricamento. Se non è disponibile un lettore RFID, è possibile configurare un RFID fisso noto al backend OCPP. Utilizzando il Modbus, la corrente di carica può ora essere regolata ai fini della gestione del carico, vale a dire che la corrente di carica specificata dal profilo di carica OCPP può essere ridotta. Il profilo di carica specifica la corrente di carica massima. La corrente di carica è quindi sempre la minima delle correnti di carica specificate tramite Modbus e OCPP. La carica può anche essere temporaneamente disattivata e riattivata tramite Modbus o OCPP. La ricarica avviene solo se sia il Modbus che il backend OCPP consentono la ricarica.