Para o fazer, clique em "cFos Power Brain Wallbox Configuration" e introduza o seguinte:
EVSE como Cliente OCPP: activar
ID | O conjunto de identificação da ChargeBox no backend. Se quiser operar o cFos Power Brain Wallbox como cliente OCPP no cFos Charging Manager, este deve corresponder à ID que introduziu como "Endereço" no cFos Charging Manager para o EVSE correspondente. |
Servidor | O URL do backend do OCPP. Se quiser operar o EVSE cFos como cliente OCPP no Gestor de Carregamento cFos, introduza aqui o endereço IP do Gestor de Carregamento cFos e a porta que configurou como porta do servidor OCPP nas definições do Gestor de Carregamento cFos. |
Para o fazer, clique em "Definições" do EVSE correspondente e introduza o seguinte:
Tipo de dispositivo | EVSE com OCPP 1.6 |
Endereço | Aqui deve introduzir a identificação da ChargeBox que foi configurada no EVSE. |
Id | Deve introduzir aqui o ID do conector. Para EVSEs com um ponto de carregamento este é sempre 1, para dois pontos de carregamento é correspondentemente 1 ou 2, etc. |
Alguns EVSEs com OCPP, tais como o Innogy eBox profissional S ou Mennekes Amtron, podem transmitir dados de contadores para o backend do OCPP em conformidade com os regulamentos de calibração. O portal OCPP do Gestor de Carregamento cFos pode transmitir de forma transparente esses dados do contador para o backend.
A porta de entrada não é necessária para operar um cFos Power Brain Wallbox, porque o cFos Power Brain Wallbox permite o funcionamento simultâneo do OCPP ao backend para autorização e facturação e do Modbus para gestão de carga. Para tal, configure o cliente OCPP em "cFos Power Brain Controller Configuration" e, adicionalmente, active o Modbus. Em seguida, introduzir um EVSE cFos em "Iniciar" e introduzir o endereço ou os dados da porta COM e a ID do Modbus.
Se quiser configurar a porta de entrada, deve configurar os seguintes parâmetros. Para o fazer, clicar em "Definições" do EVSE correspondente e introduzir o seguinte:
URL do Portal OCPP | O URL do backend contabilístico do OCPP, por exemplo ws://ocpp.backend.com/ para ligações não encriptadas ou wss://ocpp.secure-backend.com/ para ligações encriptadas em TLS. Para alguns backends, é também necessário especificar um caminho, por exemplo ws://ocpp.backend.com/path/to/resource/. |
Senha do CPP Gateway | Se o operador backend especificar uma senha para a ligação OCPP, esta deve ser introduzida aqui. Se o operador backend não especificar uma palavra-passe, este campo pode permanecer vazio. |
OCPP Gateway ID do cliente | A identificação com a qual a porta de entrada reporta ao backend. Esta identificação deve normalmente ser especificada pelo operador do backend. Alguns backends identificam os seus clientes através de chaves individuais que fazem parte do URL, por exemplo ws://xyz123.backend.com/ ou ws://ocpp.backend.com/xyz123/. Neste caso, o cliente pode ser livre de escolher o ID do cliente. |
Os certificados são utilizados quando se utilizam ligações TLS encriptadas entre cliente e servidor. Para estabelecer com sucesso tal ligação, o servidor necessita sempre de um certificado e de uma chave privada associada. O Gestor de Carregamento cFos já tem um certificado autoassinado a bordo. Por conseguinte, nenhum certificado próprio tem de ser importado. No entanto, esta opção existe tanto do lado do servidor como do lado do cliente.
No lado do servidor, um certificado próprio e a chave privada correspondente podem ser importados. Este certificado pode ser autoassinado ou assinado por uma autoridade de certificação oficial. Se nenhum certificado CA (CA = Autoridade Certificadora) for armazenado no cliente, é estabelecida uma ligação TLS em qualquer caso. Se um ou mais certificados da CA forem armazenados no cliente, os respectivos certificados do servidor devem coincidir (Perfil de Segurança OCPP 2). O certificado do servidor em si pode ser armazenado como o certificado da CA. Se o cliente tiver uma ligação à Internet, os certificados de raiz das autoridades de certificação que assinaram o certificado do servidor também podem ser armazenados aí. No entanto, também pode armazenar o seu próprio certificado de raiz que tenha assinado o certificado do servidor.
Como nível de segurança adicional, um certificado também pode ser utilizado na direcção oposta (Protocolo de Segurança OCPP 3). Para este efeito, um certificado e a chave privada correspondente são armazenados no cliente. O servidor também recebe este certificado entre os certificados CA ou um certificado de raiz que tenha assinado o certificado do cliente. Isto significa que a ligação TLS só é estabelecida se o servidor também puder verificar o certificado do cliente.
Pode criar certificados você mesmo, por exemplo, com o programa OpenSSL, que está disponível gratuitamente para Windows e Linux. Seguem-se alguns exemplos que utilizam OpenSSL. Os exemplos utilizam um ficheiro de configuração guardado em formato UTF8 em conjunto com o parâmetro -config. Isto tem a vantagem de umlauts e outros caracteres Unicode também poderem ser utilizados no certificado. O ficheiro de configuração tem sempre o seguinte 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
Criação de uma chave privada raizCA.key para um certificado de raiz:openssl genrsa -des3 -out rootCA.key 4096
Criar um certificado rootCA.crt autoassinado usando a chave privada rootCA.key criada acima e o ficheiro de configuração rootCA.cnf (o parâmetro -days especifica para quantos dias o certificado é válido):openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 365 -out rootCA.crt -config rootCA.cnf -utf8
Criação de uma chave privada client.key para um certificado de cliente:openssl genrsa -out client.key 2048
Criar um pedido de assinatura de certificado (CSR) client.csr para um certificado de cliente usando a chave privada client.key criada acima e o ficheiro de configuração client.cnf:openssl req -new -key client.key -out client.csr -config client.cnf -utf8
Criação de um certificado cliente cliente1.crt, que é assinado com o certificado raiz raizCA.crt acima e a chave privada raizCA.key associada (o parâmetro -dias volta a especificar por quanto tempo o certificado é válido):openssl x509 -req -in client.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out client.crt -days 365 -sha256
Pode operar uma cFos Power Brain Wallbox em paralelo com Modbus e OCPP, por exemplo, para integrá-la na gestão de carga local via Modbus e ligá-la a um backend de facturação via OCPP. Para este efeito, "Activar Modbus" deve ser activado nas definições da cFos Power Brain wallbox e uma porta TCP ou parâmetro COM deve ser configurada de modo a que a wallbox possa ser endereçada através do Modbus. Além disso, um URL OCPP para o backend, o ID do cliente OCPP e, se aplicável, o ID do conector OCPP deve ser definido nas definições OCPP. OCPP começa então os processos de carregamento, ou seja, as transacções. Determina se a transacção é permitida com base na RFID transmitida e começa a carregar, se necessário. Se não houver um leitor RFID disponível, pode configurar um RFID fixo que seja conhecido pelo backend do OCPP. Usando Modbus, a corrente de carga pode agora ser regulada para fins de gestão de carga, ou seja, a corrente de carga especificada pelo perfil de carga do OCPP pode ser reduzida. O perfil de carga especifica a corrente de carga máxima. A corrente de carga é portanto sempre o mínimo das correntes de carga especificadas via Modbus e OCPP. O carregamento também pode ser temporariamente desactivado e reactivado via Modbus ou OCPP. O carregamento só tem lugar se tanto o Modbus como o backend OCPP permitirem o carregamento.