La referencia del protocolo OCPP 2.0.1 y 2.1.
Los 91 mensajes de OCPP 2.0.1 y 2.1 con sus campos y un ejemplo, cuáles añadió la 2.1, el modelo de dispositivo que sustituyó a las claves de configuración de la 1.6 y los tres perfiles de seguridad.
MensajesModelo de dispositivoPerfiles de seguridadSi viene de la 1.6Preguntas
¿Qué son OCPP 2.0.1 y 2.1?
Son las versiones más recientes del Open Charge Point Protocol, el estándar abierto de la Open Charge Alliance que define cómo se comunica un cargador con el software que lo gestiona: el CSMS en la especificación, el backoffice en el mercado. Como en 1.6J, el cargador abre un WebSocket hacia el backoffice y ambos lados se envían mensajes JSON por él.
OCPP 2.0.1 no es retrocompatible con la 1.6. Describe un cargador como un modelo de dispositivo de componentes y variables, incorpora tres perfiles de seguridad, notifica una transacción en un solo mensaje, TransactionEvent, y admite ISO 15118 para Plug & Charge y para la carga inteligente con datos del coche.
OCPP 2.1 se basa en la 2.0.1. Sus esquemas son los de la 2.0.1 con campos opcionales añadidos, y añade 27 mensajes para la carga bidireccional, el control de DER, las tarifas en un cargador que calcula el coste por sí mismo, el pago en el cargador, los flujos periódicos de eventos y el intercambio de baterías. Un cargador y su backoffice acuerdan una versión al abrir el WebSocket.
- Un estándar abiertoLibre de implementar, mantenido por la Open Charge Alliance. OCPP 2.1 también se publica como IEC 63584-210.
- WebSocket y JSONUna conexión que el cargador mantiene abierta. La 2.1 añade SEND, un mensaje que no recibe respuesta.
- 91 mensajes64 en la 2.0.1 y 27 más en la 2.1, en 19 bloques funcionales.
- En ambos sentidosEl cargador y el backoffice inician cada uno sus propios mensajes.
Los 91 mensajes de OCPP 2.0.1 y 2.1
Cada mensaje es una solicitud de un lado y una respuesta del otro, emparejadas por un ID de mensaje. NotifyPeriodicEventStream es la única excepción: un mensaje SEND de la 2.1 que no recibe respuesta.
Seguridad
Certificados para el cargador y el backoffice, y los eventos de seguridad que notifica un cargador.
Aprovisionamiento
Arranque, registro en el backoffice, lectura y ajuste del modelo de dispositivo, y reinicios.
Autorización
Comprobación de un token de identificación antes de cargar, la caché de autorización y, en la 2.1, el pago ad hoc.
Lista de autorización local
La lista de tokens de identificación que el backoffice guarda en el cargador, para que pueda autorizar por sí mismo.
Transacciones
Un solo mensaje, TransactionEvent, para el inicio, las actualizaciones y el final de cada transacción.
Control remoto
Iniciar y detener una transacción desde el backoffice, desbloquear un conector y activar un mensaje.
Disponibilidad
El estado de cada conector, el heartbeat y la puesta fuera de servicio de un cargador o un EVSE.
Reserva
Reservar un EVSE para un token de identificación y cancelar esa reserva.
Tarifa y coste
Precios y coste en curso para el conductor; en la 2.1 también tarifas en un cargador que calcula el coste por sí mismo.
Valores de medida
Lecturas del contador fuera de una transacción; durante una transacción viajan en TransactionEvent.
Carga inteligente
Perfiles de carga con límites de potencia o corriente, límites externos y las necesidades del vehículo.
Gestión del firmware
Actualizar el firmware de un cargador y publicarlo a través de un controlador local.
Gestión de certificados
Instalar y comprobar certificados, incluidos los certificados de contrato de Plug & Charge.
Diagnóstico
Registros, monitores en el modelo de dispositivo, eventos, datos de clientes y, en la 2.1, flujos periódicos de eventos.
Mensajes en pantalla
Mensajes que el backoffice define para que un cargador los muestre a los conductores.
Transferencia de datos
Datos del fabricante, para funciones que el estándar no cubre.
Transferencia bidireccional de energía
Nuevo en la 2.1: control de la carga y la descarga (V2X) mediante perfiles de carga.
Control de DER
Nuevo en la 2.1: ajustes de apoyo a la red para un cargador y un coche que actúan como recurso energético distribuido.
Intercambio de baterías
Nuevo en la 2.1: estaciones de intercambio de baterías.
Ningún mensaje coincide con esa búsqueda.
El modelo de dispositivo de OCPP 2.0.1
En OCPP 1.6, un cargador tiene una lista plana de claves de configuración. En la 2.0.1 y la 2.1 se describe a sí mismo como componentes, como la estación de carga, un EVSE, un conector o un controlador como OCPPCommCtrlr, y cada componente tiene variables. Una variable puede tener cuatro valores: Actual, Target, MinSet y MaxSet. Lo que antes era una clave de configuración ahora es una variable de un componente controlador.
Cómo se trabaja con él
- GetVariables y SetVariablesLeen o fijan varias variables en un solo mensaje. El cargador responde por cada variable por separado.
- GetBaseReport y GetReportPiden todo el modelo de dispositivo o una parte. El cargador lo devuelve en mensajes NotifyReport.
- MonitoresSetVariableMonitoring vigila una variable por un umbral, un cambio o un intervalo fijo, y el cargador informa mediante NotifyEvent.
- Enabled, por funciónEl controlador de una función opcional, como AuthCacheCtrlr o ReservationCtrlr, tiene una variable Enabled que activa o desactiva esa función.
Las respuestas a SetVariables
- Accepted
- El valor está fijado.
- Rejected
- La variable existe, pero se rechazó el valor.
- Unknown
Component - El cargador no tiene ese componente.
- Unknown
Variable - El componente no tiene esa variable.
- NotSupported
AttributeType - La variable no tiene ningún valor de ese tipo, por ejemplo ningún Target.
- RebootRequired
- El valor se guarda y se aplica tras un reinicio.
Variables que sustituyeron a las claves más conocidas de la 1.6
La especificación normaliza muchas más, enumeradas en sus anexos. Un cargador notifica las que tiene en respuesta a GetBaseReport.
| Componente y variable | Tipo | Qué fija | En OCPP 1.6 |
|---|---|---|---|
| OCPPCommCtrlr | entero en segundos | Segundos sin otros mensajes tras los cuales el cargador envía un Heartbeat. | Heartbeat |
| OCPPCommCtrlr | integer | Cuántas veces intenta el cargador entregar un TransactionEvent que el backoffice no pudo procesar. | Transaction |
| OCPPCommCtrlr | integer | Segundos que espera el cargador antes de volver a intentarlo. | Transaction |
| OCPPCommCtrlr | entero en segundos | Segundos entre pings de WebSocket; 0 desactiva los pings propios del cargador. | Web |
| OCPPCommCtrlr | integer | Cuántas veces reintenta el cargador un reinicio que falló. | Reset |
| OCPPCommCtrlr | boolean | Desbloquear el cable en el cargador cuando se desconecta en el lado del coche. | Unlock |
| SampledDataCtrlr | lista | Lo que mide el cargador durante una transacción, enviado en TransactionEvent con eventType Updated. | Meter |
| SampledDataCtrlr | entero en segundos | Segundos entre esas lecturas; 0 no envía ninguna durante la transacción. | Meter |
| SampledDataCtrlr | lista | Lo que va en el TransactionEvent que cierra la transacción. | Stop |
| AlignedDataCtrlr | entero en segundos | Segundos entre lecturas alineadas con el reloj. | Clock |
| AlignedDataCtrlr | lista | Lo que contienen las lecturas alineadas con el reloj. | Meter |
| AlignedDataCtrlr | lista | Lecturas alineadas con el reloj que van en el TransactionEvent que cierra la transacción. | Stop |
| TxCtrlr | entero en segundos | Segundos que tiene un conductor para conectar el coche tras el inicio de la transacción, antes de que se cancele. | Connection |
| TxCtrlr | boolean | Terminar la transacción cuando se desconecta el cable en el lado del coche. | Stop |
| TxCtrlr | boolean | Detener una transacción en curso cuando su token de identificación resulta no aceptado. | Stop |
| TxCtrlr | integer | Energía en Wh que el cargador aún puede entregar después de que el backoffice rechazara el token de identificación. | Max |
| TxCtrlr | lista | Cuándo empieza una transacción: al autorizar, al conectar, cuando fluye la energía, etcétera. | Nuevo en la 2.0.1 |
| TxCtrlr | lista | Cuándo termina una transacción, elegido de la misma lista. | Nuevo en la 2.0.1 |
| AuthCtrlr | boolean | Si el cargador comprueba primero con un Authorize el token de identificación de un inicio remoto. | Authorize |
| AuthCtrlr | boolean | Iniciar transacciones sin conexión para tokens de identificación que ya conoce. | Local |
| AuthCtrlr | boolean | Iniciar para tokens de identificación que ya conoce sin esperar al backoffice. | Local |
| AuthCtrlr | boolean | Iniciar transacciones sin conexión para tokens de identificación desconocidos. | Allow |
| AuthCacheCtrlr | boolean | Usar la caché de autorización. | Authorization |
| LocalAuthListCtrlr | boolean | Usar la lista de autorización local. | Local |
| LocalAuthListCtrlr | integer | Número máximo de tokens de identificación en un SendLocalList. | Send |
| SmartChargingCtrlr | integer | Nivel de pila más alto que puede tener un perfil de carga. | Charge |
| SmartChargingCtrlr | lista | Si las programaciones pueden ir en amperios, en vatios o en ambos. | Charging |
| SmartChargingCtrlr | integer | Número máximo de periodos en una programación de carga. | Charging |
| SmartChargingCtrlr | boolean | Si el cargador puede pasar de tres fases a una durante una transacción. | Connector |
| ReservationCtrlr | boolean | Si una reserva puede ser para el cargador en su conjunto en lugar de para un EVSE. | Reserve |
Ninguna variable coincide con esa búsqueda.
Perfiles de seguridad de OCPP 2.0.1 y 2.1
Ambas versiones definen tres perfiles de seguridad. Un cargador y su backoffice usan uno cada vez, y se fija antes del primer mensaje OCPP. El backoffice lo fija por ranura de conexión con SetNetworkProfile, y el cargador notifica el que usa en SecurityCtrlr.SecurityProfile.
| Perfil | Cómo demuestra el cargador quién es | Cómo demuestra el backoffice quién es | La conexión |
|---|---|---|---|
| 1. Transporte sin cifrar con autenticación básica | Autenticación HTTP Basic, con una contraseña | No lo hace | Sin cifrar. Solo para redes de confianza, como una VPN entre el cargador y el backoffice. |
| 2. TLS con autenticación básica | Autenticación HTTP Basic, con una contraseña | Su certificado de servidor TLS | TLS 1.2 o superior |
| 3. TLS con certificados de cliente | Su propio certificado de cliente TLS | Su certificado de servidor TLS | TLS 1.2 o superior |
- Bajar de perfilUn cargador solo puede pasar del perfil 3 al perfil 2, y solo cuando AllowSecurityProfileDowngrade está en true. Nunca baja al perfil 1 a través de OCPP.
- Contraseñas y certificadosLa contraseña es SecurityCtrlr.BasicAuthPassword. El cargador pide un certificado nuevo con SignCertificate, y el backoffice lo entrega con CertificateSigned.
- Eventos de seguridadEl cargador notifica lo que ocurrió, como un reinicio, una actualización de firmware o credenciales que el backoffice rechazó, con SecurityEventNotification.
De OCPP 1.6 a 2.0.1, mensaje a mensaje
OCPP 2.0.1 conservó muchos nombres de mensajes de la 1.6, y renombró o fusionó otros. Un enlace abre el mensaje en esta referencia o en la referencia de 1.6J.
| OCPP 1.6 | OCPP 2.0.1 y 2.1 | Qué cambió |
|---|---|---|
| StartTransaction, StopTransaction | TransactionEvent | Un solo mensaje con eventType Started, Updated o Ended. El cargador fija el ID de la transacción, una cadena. |
| MeterValues | TransactionEvent, MeterValues | Las lecturas durante una transacción van en TransactionEvent; MeterValues lleva las lecturas fuera de una transacción. |
| StatusNotification | StatusNotification, NotifyEvent | StatusNotification solo notifica el estado del conector, con evseId y connectorId. Los códigos de error van en NotifyEvent, y la 2.1 también prefiere NotifyEvent para la disponibilidad. |
| RemoteStartTransaction | RequestStartTransaction | Lleva un objeto idToken y un remoteStartId, que vuelve en el TransactionEvent que inicia la transacción. |
| RemoteStopTransaction | RequestStopTransaction | Detiene una transacción por su ID, que ahora es una cadena. |
| ChangeConfiguration | SetVariables | Fija varias variables del modelo de dispositivo en un solo mensaje. |
| GetConfiguration | GetVariables, GetBaseReport, GetReport | Lee variables elegidas, o pide un informe que llega en mensajes NotifyReport. |
| GetDiagnostics | GetLog | Pide un registro de diagnóstico o un registro de seguridad. |
| DiagnosticsStatusNotification | LogStatusNotification | Notifica el progreso de esa subida. |
| Reset | Reset | Immediate u OnIdle en lugar de Hard o Soft, y puede reiniciar un solo EVSE. |
| ChangeAvailability | ChangeAvailability | Se dirige al cargador, a un EVSE o a un conector mediante su campo evse. |
| Authorize | Authorize | Un objeto idToken con un tipo, en lugar de la cadena idTag. |
| BootNotification | BootNotification | Añade el motivo del arranque; los datos del cargador están en un objeto chargingStation. |
| Heartbeat, UnlockConnector, ClearCache, DataTransfer, ReserveNow, CancelReservation, SendLocalList, GetLocalListVersion, SetChargingProfile, ClearChargingProfile, GetCompositeSchedule, TriggerMessage, UpdateFirmware, FirmwareStatusNotification | Los mismos nombres | Los mismos mensajes, con campos para los EVSE y los tipos de datos más recientes. |
Preguntas sobre OCPP 2.0.1 y 2.1
La versión 2.0.1 del Open Charge Point Protocol, publicada por la Open Charge Alliance en 2020. Sustituyó a OCPP 2.0 y, frente a la 1.6, añade el modelo de dispositivo, los perfiles de seguridad, la compatibilidad con ISO 15118 y TransactionEvent. No es retrocompatible con la 1.6.
OCPP 2.1 se publicó en enero de 2025 y también es la norma IEC 63584-210. Añade 27 mensajes y no elimina ninguno: carga bidireccional (V2X) y control de DER, ISO 15118-20, tarifas en un cargador que calcula el coste por sí mismo, pago en el cargador con un terminal de tarjetas o un código QR, carga prioritaria, perfiles de carga dinámicos, flujos periódicos de eventos e intercambio de baterías. Elija Nuevo en la 2.1 encima de los mensajes para verlos.
Los esquemas de la 2.1 son los de la 2.0.1 con campos opcionales añadidos y, según la Open Charge Alliance, la lógica escrita para la 2.0.1 sigue funcionando con dos pequeños cambios: SignCertificate puede llevar un requestId que CertificateSigned repite después, y NotifyMonitoringReport tiene un nuevo campo obligatorio. La versión se sigue acordando por conexión: en el handshake de WebSocket el cargador ofrece, por ejemplo, ocpp2.1, ocpp2.0.1 y ocpp1.6, y el backoffice elige una.
La 2.0.1 tiene su propio conjunto de mensajes: un modelo de dispositivo en lugar de claves de configuración, perfiles de seguridad, TransactionEvent en lugar de StartTransaction y StopTransaction, el EVSE como nivel entre el cargador y sus conectores, y mensajes para ISO 15118. Un cargador y su backoffice acuerdan una versión al abrir la conexión. La tabla de arriba empareja los mensajes, y la referencia de OCPP 1.6J tiene todos los mensajes de la 1.6.
Tras la publicación de OCPP 2.0 aparecieron problemas que solo podían resolverse cambiando los esquemas de los mensajes, algo que una implementación de la 2.0 no podía seguir. La Open Charge Alliance dio a la versión corregida su propio número, 2.0.1, y aconseja implementar solo la 2.0.1. En la especificación, OCPP 2.0 significa 2.0.1 salvo que se indique lo contrario.
La Open Charge Alliance publica ambas gratis en su sitio web, con un esquema JSON para cada mensaje y una hoja de erratas. Esta referencia sigue los esquemas JSON y la parte 2 de la especificación. Donde difieran, la especificación y sus erratas tienen razón.
Búsquelo en la base de datos de cargadores: 102 cargadores indican allí OCPP 2.0.1 y 4 indican la 2.1. La ficha técnica también suele indicarlo. Un cargador que admite varias versiones las ofrece todas al conectarse, y el backoffice elige una.
OCPP 1.6J en Plugchoice
Plugchoice conecta hoy cargadores OCPP 1.6J, según el modelo, el firmware y la configuración.