Front & Back

Blog sobre el Desarrollo de aplicaciones web

Back end Un vistazo a OCPP (Open Charge Point Protocol)

OCPP es el acrónimo de "Open Charge Point Protocol"; un protocolo abierto pensado como un estándar de comunicación entre puntos de recarga de vehículos eléctricos y sistemas de gestión de los mismos. 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.

OCPP es básicamente un sistema bidireccional basado en la arquitectura SOAP, en el que intervienen dos actores; los puntos de recarga y la estación central. En una u otra dirección, pueden realizarse "requests" y "responses" basadas en acciones propias de cada uno de estos actores. Lo mejor, creo yo, es verlo con un ejemplo:

Una comunicación básica: HeartBeat

Como hemos comentado, la comunicación entre el punto y la central puede iniciarse desde uno u otro lado; vamos a utilizar para ilustrarlo un ejemplo; la acción HeartBeat (latido, en su traducción al español), que debe ser iniciada por el punto de carga.


OCPP - Ejemplo de HeartBeat

Esta acción se programa en el cargador y se ejecuta cada X minutos para comunicar a la central que sigue vivo. El uso de Heartbeat podría servir además para actualizar en el sistema central la IP asociada al punto de recarga, en caso de que éste no cuente con una fija. El contenido de la "request" 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" 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. Vamos a detenernos un momento en el diagrama siguiente; en él podemos ver cómo se lleva a cabo el proceso de recarga de un vehículo eléctrico:


OCPP - Ejemplo de recarga


A grandes rasgos, el 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.

Estos ejemplos que detallo, son orientativos; así por ejemplo acciones como la validación de la tarjeta RFID, la persistencia de los datos en la BD del servidor, etc, evidentemente no forman parte del protocolo, aunque he creído conveniente describirlos para que pueda verse mejor la utilidad real.

Todo esto es una aproximación muy, muy somera al protocolo OCPP. Si os resulta interesante os recomiendo leer la descripción del protocolo que es bastante sencilla, y echar un vistazo a la web oficial Openchargealliance.org.