OCPP

Referencia del driver OCPP: el sistema central integrado, los certificados de los puntos de recarga, los tags de conector y la regla de nombres Meter/Status.

El driver OCPP convierte a Ganter Lab en el sistema central de los puntos de recarga de vehículos eléctricos que hablan el Open Charge Point Protocol. Igual que con LoRaWAN, el sentido está invertido: la estación no se conecta al cargador, sino que el punto de recarga se conecta a Ganter Lab por un WebSocket, se registra solo y le empuja su telemetría.

El sistema central integrado arranca cuando el primer dispositivo OCPP activado se carga en el connector en marcha, y se detiene cuando se quita o se desactiva el último: sin ningún punto de recarga configurado, no hay nada escuchando en el puerto. Agregar uno lo trae de vuelta, sin reiniciar la aplicación. Cada dispositivo que usted configure representa un punto de recarga, identificado por el id con el que se conecta.

El sistema central y los puertos

La escucha siempre es TLS; una escucha por HTTP sin cifrar se rechaza en cualquier lugar que no sea loopback, que existe solo para las pruebas dentro del proceso. Un punto de recarga se registra solo con su BootNotification (contestada con un intervalo de latido de 60 segundos), y cada credencial que se presente para autorización se acepta: Ganter Lab observa la recarga, no administra tarifas ni accesos.

Los certificados

El lado de servidor del saludo TLS presenta el certificado OPC UA propio de la aplicación. Cada punto de recarga tiene que presentar un certificado de cliente:

1. Tiene que formar una cadena válida en esta máquina Windows, sin errores de política TLS; una verificación fallida rechaza la conexión y el diario técnico registra qué verificación falló.
2. El nombre común de su sujeto o un nombre alternativo de sujeto de tipo DNS tiene que nombrar el id del punto de recarga con el que se conecta. Un certificado que nombre otro punto de recarga distinto del que va en la ruta de conexión se rechaza.

Un saludo sin certificado de cliente se tira antes de que fluya ningún dato.

Los campos de conexión

No hay campos de host, de puerto ni de credenciales: el cargador tiene los datos de la conexión, y esta estación solo necesita saber a qué punto de recarga se refiere el dispositivo. Tampoco hay campos de intervalo de sondeo. OCPP es de empuje (el punto de recarga manda mensajes MeterValues y StatusNotification según su propio calendario) y los tags se refrescan desde los últimos datos recibidos en un ciclo fijo de un segundo.

Por eso un punto de recarga que todavía no se ha conectado, o un conector que todavía no ha reportado, no tiene lectura, no tiene una lectura fallida. Sus tags se quedan vacíos, el dispositivo reporta que no se ha observado nada en lugar de irse sin conexión, y no se registra ninguna falla: este es el estado normal de un punto de recarga que se acaba de configurar y todavía no llega.

Los tags

Un tag de OCPP lee un conector del punto de recarga (conector en el sentido de OCPP: una posición de enchufe, numerada desde 1). Existen dos clases de tag, distinguidas por el sufijo del nombre del tag, que se valida:

Un nombre sin ninguno de los dos sufijos lo rechaza la validación: nombre los tags como Connector1Meter y Connector1Status.

Los tags de OCPP son de solo lectura: el campo de acceso no ofrece ninguna opción escribible, y una escritura se rechaza en lugar de fingirse. Mandar a un punto de recarga es un comando propio, descrito enseguida, no un valor escrito en un tag.

Los comandos

A un punto de recarga se le manda además de leerlo. Cada dispositivo OCPP lleva los comandos de abajo como métodos del dispositivo en el espacio de direcciones OPC UA propio de esta estación, así que cualquier cosa que pueda llamar a un método puede lanzar uno: un cliente OPC UA, o una acción de Logic que lo llame.

Cada comando toma el id del punto de recarga como su primer argumento, y devuelve como resultado la respuesta propia del punto de recarga.

AttributeType es uno de Actual, Target, MinSet, MaxSet.

Esperar la respuesta. Un comando no termina cuando la estación lo mandó. La estación mantiene la llamada abierta hasta que el punto de recarga conteste exactamente la orden que se le envió, emparejada por el identificador de correlación que viaja con ella, y solo entonces reporta éxito y devuelve la respuesta. Tres cosas lo terminan de otra manera, y cada una se reporta como una falla con su motivo:

• El punto de recarga no está conectado, o su conexión no está abierta. No se envía nada.
• El punto de recarga contesta con un error de OCPP, por ejemplo por un comando que no implementa. El código de error es el motivo.
• Pasan 30 segundos sin ninguna respuesta. Un comando que nadie contestó es una falla, nunca un éxito.

Un comando lanzado para un punto de recarga que ningún dispositivo lleva, o que no está conectado, se rechaza de inmediato en lugar de encolarse.

El descubrimiento

Descubrir en el driver OCPP lista los puntos de recarga conectados en ese momento al sistema central, y leer los canales de un candidato propone un tag Meter y un tag Status por cada conector que el punto de recarga haya reportado hasta ahí.

El primer punto de recarga siempre se configura a mano. Nada se puede conectar antes de que el sistema central escuche, y escucha solo una vez que existe aquí un dispositivo OCPP, así que un escaneo de una instalación sin ningún punto de recarga configurado no encuentra nada y lo dice. Agregue ese primer dispositivo con el id con el que se conectará el cargador; después de eso, un cargador que ya se conectó se puede descubrir. El flujo general del descubrimiento se describe en la página del Connector.

El id se compara sin distinguir mayúsculas, en el certificado, en la ruta de conexión y contra el dispositivo: un cargador que se conecta como cp-a con un certificado que nombra CP-A es el mismo punto de recarga que un dispositivo cuyo Identificador dice CP-A.