El hecho de depender actualmente de energías que tienen fecha de caducidad para suministrar la potencia necesaria en los llamados motores de explosión de los coches modernos, quedará relegado por la nueva era eléctrica. Este cambio tecnológico no solo radica en la necesidad de buscar una energía alternativa por la escasez de la actual comentada, es más, será un factor sine qua non si se quiere preservar la calidad y conservación del medio ambiente, dadas las bastas emisiones de CO2 actuales.
Modelo Nissan LEAF, vehículo eléctrico más vendido del mundo actualmente. (Fuente, El economista).
Una vez argumentada esta revolución y pasado el recelo inicial, como siempre ha sucedido en el dinámico y evolutivo mundo de la tecnología cuando aparece un diamante en bruto del avance tecnológico, como el caso que acontece, finaliza la catarsis y se planea la proyección comercial del nuevo producto.
Estos nuevos vehículos eléctricos dispondrán de nuevos sistemas de abastecimiento, los llamados puntos de carga. Para algunos puntos de carga (los que no pertenecen a particulares) sería interesante el control y monitorización de los mismos de forma remota mediante un sistema o software de gestión. Para 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 web manager 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. Pensando de esta manera nació el llamado protocolo de comunicación OCPP (Open Charge Point Protocol) o en castellano, Protocolo Abierto de Punto de Carga. 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 sólo 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 (Simple Object Acces Protocol), donde intervienen dos elementos principales, los puntos de carga y el gestor de los mismos (web manager o estación central). En una u otra dirección, pueden realizarse «requests» y «responses» basadas en acciones propias de cada uno de estos elementos. El hecho de emplear una arquitectura SOAP deriva en la utilización del lenguaje XML (lenguaje de marcas extensible) para entender OCPP. Este lenguaje permite una gran interoperabilidad a la hora de comunicar aplicaciones de distintas plataformas y da soporte a bases de datos, siendo útil cuando varias aplicaciones deben comunicarse entre sí o integrar información.
A continuación visualizaremos dos ejemplos prácticos de la aplicación de OCPP en un punto de carga.
La comunicación entre el punto y la central puede iniciarse desde ambos puntos; veremos un ejemplo para ilustrarlo; la acción HeartBeat (latido, en su traducción al español), que deberá iniciar el punto de carga.
Esta acción se programa en el cargador y se ejecuta cada X minutos para comunicar a la central que sigue en línea. La instrucción Heartbeat también puede ser empleada para actualizar la IP asociada al punto de carga en el sistema central, en caso de contar éste con una IP dinámica. El contenido de la «request» o petición tendría el aspecto siguiente (una estructura SOAP; envelope, header, body):
<?xml version=»1.0″ encoding=»UTF-8″?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=»http://www.w3.org/2003/05/soap-envelope»
xmlns:SOAP-ENC=»http://www.w3.org/2003/05/soap-encoding»
xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»
xmlns:xsd=»http://www.w3.org/2001/XMLSchema»
xmlns:wsa5=»http://www.w3.org/2005/08/addressing»
xmlns:cp=»urn://Ocpp/Cp/2010/08/»
xmlns:cs=»urn://Ocpp/Cs/2010/08/»>
<SOAP-ENV:Header>
<wsa5:MessageID>b3332-a322-4ttt-b3n2-c68wc9d88</wsa5:MessageID>
<wsa5:From><wsa5:Address>http://192.168.1.7</wsa5:Address></wsa5:From>
<wsa5:To SOAP-ENV:mustUnderstand=»true»>http://192.168.1.23:8005/CimsSimulator</wsa5:To>
<wsa5:Action SOAP-ENV:mustUnderstand=»true»>/Heartbeat</wsa5:Action>
<cs:chargeBoxIdentity>12345678</cs:chargeBoxIdentity>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<cs:heartbeatRequest></cs:heartbeatRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
En la cabecera recibiremos (entre otros valores) el identificador del mensaje y la IP actual del punto de recarga. En el cuerpo podríamos enviar otros valores que necesitásemos, aunque para este ejemplo el «stub» o código de testeo vale como está. 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 a la siguiente:
<?xml version=»1.0″ encoding=»UTF-8″?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=»http://www.w3.org/2003/05/soap-envelope»
xmlns:SOAP-ENC=»http://www.w3.org/2003/05/soap-encoding»
xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»
xmlns:xsd=»http://www.w3.org/2001/XMLSchema»
xmlns:wsa5=»http://www.w3.org/2005/08/addressing»
xmlns:cp=»urn://Ocpp/Cp/2010/08/»
xmlns:cs=»urn://Ocpp/Cs/2010/08/»>
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<cs:heartbeatResponse>
<cs:currentTime>2014-12-15T08:46:37Z</cs:currentTime>
</cs:heartbeatResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Un ejemplo avanzado: recarga de un vehículo
Como hemos comentado, punto y central cuentan con acciones básicas que combinadas entre sí crean comunicaciones más complejas. En el diagrama siguiente se podrá visualizar como 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.
– Al 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 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 la carga.
– El punto queda disponible de nuevo.
Sin duda, OCPP nos abre un amplio abanico de posibilidades para poder 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 (web manager), sin importar que el fabricante de dichos equipos sea del país que sea. 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.
Autor: Edgar Zahino Andrés
Fuentes bibliográficas:
José Vte. Calderón. (2014, Diciembre 16). “Front and Back blog” [En linea]. Disponible en: http://www.frontandback.org/
Sergio Piccione. (2009, Agosto 5). Diario “El Mundo” [En linea]. Disponible en http://www.elmundo.es/elmundomotor/2009/08/04/coches/1249383953.html
Web estandarización OCPP:www.openchargealliance.org