El protocolo de comunicación OCPP, impulsado por la Open Charge Alliance, busca la estandarización de la comunicación en el proceso de carga de vehículos eléctricos.

Los vehículos eléctricos disponen de sistemas de abastecimiento, los llamados “puntos de carga”. Sería interesante el control y monitorización de algunos puntos de carga (los que no pertenecen a particulares) de forma remota mediante un sistema o software de gestión. A fin de realizar esta tarea, se necesita un “catalizador” entre el hardware que suministra la energía eléctrica y el software de gestión.
Este intermediario es simplemente un protocolo de comunicación. Dicho protocolo deberá ser el traductor entre los datos del punto de carga (hardware) y la central que dispone el administrador web o sistema de gestión. Lo idóneo sería idear un protocolo en el cual de forma independiente al hardware empleado, la comunicación fluya sin problemas con el gestor de la carga (ver figura 1).

Pensando de esta manera, nació el llamado protocolo de comunicación “OCPP” (‘protocolo abierto de punto de carga’, por sus siglas en inglés). Este sistema impulsado por la Open Charge Alliance, un compendio de empresas dedicadas a hardware y software de cargadores del vehículo eléctrico, busca la estandarización de la comunicación que se acaba de comentar.
A modo de resumen, esta interfaz pretende, con su popularización, reducir el esfuerzo que podría suponer la adaptación de cualquier software a las características específicas de un punto de recarga. Si todas las estaciones “hablan” OCPP, el proveedor del software solo debe preocuparse de que su plataforma también lo haga.

Indagando en el protocolo OCPP

OCPP es un sistema bidireccional de comunicación basado en la arquitectura SOAP (‘protocolo de acceso de objeto simple’, por sus siglas en inglés), donde intervienen dos elementos principales, los puntos de carga y su gestor (administrador web o estación central). En una u otra dirección, se pueden realizar preguntas y respuestas basadas en acciones propias de cada uno de estos elementos (ver figura 2).

El hecho de emplear una arquitectura SOAP deriva en la utilización del lenguaje XML (‘lenguaje de marcas extensible’, por sus siglas en inglés) a fin de entender OCPP. Este lenguaje permite una gran interoperabilidad a la hora de comunicar aplicaciones de distintas plataformas y da soporte a bases de datos, todo lo cual es útil cuando varias aplicaciones deben comunicarse entre sí o integrar información.
En la figura 3, dos ejemplos prácticos de la aplicación de OCPP en un punto de carga. La comunicación entre el punto y la central se puede iniciar desde ambos puntos.

La acción HeartBeat (‘latido’) deberá iniciar el punto de carga. Esta acción se programa en el cargador y se ejecuta cada ‘x’ cantidad de minutos a fin de comunicar la central que sigue en línea. La instrucción también se puede emplear para actualizar la IP asociada al punto de carga en el sistema central, en caso de que este cuente con una IP dinámica.
En la cabecera, se recibirá (entre otros valores) el identificador del mensaje y la IP actual del punto de recarga. Al cuerpo se podrían enviar otros valores que se necesiten, aunque para este ejemplo el ‘stub’ o código de testeo es válido. El sistema central identificaría el cargador en su base de datos, restauraría la IP y devolvería la hora actual en una estructura similar (ver figura 4).

Un ejemplo avanzado: recarga de un vehículo

Como se dijo, punto y central cuentan con acciones básicas que, combinadas entre sí, crean comunicaciones más complejas. En la figura 5 se puede visualizar cómo se lleva a cabo el proceso de carga de un vehículo eléctrico.

A modo simplificado, el proceso secuencial del flujo es el siguiente:

• El punto de recarga solicita permiso para que un usuario opere, enviando en la variable, por ejemplo, el código RFID de su tarjeta para que el sistema central lo valide.
• El servidor, en este caso, acepta las credenciales y comunica al cargador que el usuario tiene permiso para realizar la carga, mediante un código de estado.
• Tras recibir la respuesta afirmativa, el punto solicita permiso para iniciar la recarga, y en este caso la central lo autoriza.
• El punto inicia la transacción. Durante este periodo de tiempo, podría utilizar ‘MeterValues’ para comunicar por intervalos el estado de la carga a la central, aunque se omite el proceso en este ejemplo.
• Una vez que la carga finaliza, el punto vuelve a solicitar autorización, y la central lo autoriza.
• El punto solicita permiso para detener la carga, la central registra la petición, y permite que se detenga.
• El punto queda disponible de nuevo.

Sin duda, OCPP abre un amplio abanico de posibilidades para realizar una comunicación cómoda, segura y eficiente del hardware del punto de carga y el gestor de cargas a través de un entorno de red local u online (administrador web), sin importar el país del fabricante de dichos equipos. Comienza el proceso de estandarización del mundo del vehículo eléctrico, un gran paso en el camino hacia una movilidad eléctrica y, sobre todo, sostenible.

Bibliografía
[1] Calderón, José. (2014, Diciembre 16). “Front and Back blog” . Disponible en: http://www.frontandback.org/
[2] Picciones, Sergio, (2009, Agosto 5). Diario “El Mundo” . Disponible en http://www.elmundo.es/elmundomotor/2009/08/04/coches/1249383953.html
[3] Web estandarización OCPP: www.openchargealliance.org
[4] Zahino Andrés, Edgar, https://etecnic.es

Por Ricardo Berizzo