OCPP 1,6 vs. OCPP 2.0.1: Guía de actualización del protocolo de carga EV
OCPP (Protocolo de Punto de Carga Abierto) es el estándar de comunicación universal en el Carga de vehículos eléctricos Campo. En pocas palabras, actúa como un "traductor" entre las estaciones de carga y los sistemas de gestión de back-end, lo que permite que dispositivos de diferentes marcas se comuniquen utilizando el mismo idioma. Este protocolo es administrado por la Open Charge Alliance, una organización internacional compuesta por empresas globales de infraestructura de vehículos eléctricos. El valor central de OCPP es que es un estándar libre y hardware-independent abierto. Esto significa que los operadores no tienen que estar encerrados en el ecosistema de un proveedor y pueden elegir de manera flexible Estaciones de carga EV De diferentes marcas mientras las maneja usando el mismo sistema de software. Actualmente, la versión más utilizada en el mercado es OCPP 1,6, mientras que 2.0.1, como estándar de próxima generación, se está promocionando gradualmente. Este artículo brindará una comparación detallada de estas dos versiones para ayudarlo a determinar si es necesaria una actualización.
Desde su lanzamiento en 2015, OCPP 1,6 se ha convertido en el estándar de hecho para las redes de carga globales. La gran mayoría de las estaciones de carga todavía usan esta versión hoy en día, incluida su variante mejorada 1,6 (j). Su adopción generalizada es fácil de explicar: es estructuralmente simple, funciona de manera estable y es básicamente suficiente. Para las redes de carga temprana, la versión 1,6 de hecho satisfizo las necesidades básicas: transmitir el estado de carga, procesar registros de transacciones y admitir control remoto. Sin embargo, a medida que la industria de carga se desarrolla rápidamente, este protocolo de casi una década de antigüedad ha comenzado a mostrar limitaciones. Los principales problemas con OCPP 1,6 incluyen:
El mecanismo de comunicación de la versión 1,6 fue diseñado en una era de amenazas de seguridad de red relativamente simples. En el complejo entorno de red actual, su método de autenticación es relativamente básico y se convierte fácilmente en un objetivo para ataques. Para cargar redes que manejan información de pago y datos de usuario, este es un riesgo que no se puede ignorar.
A medida que la báscula de la estación de carga se expande, la versión 1,6 comienza a tener problemas. No admite compresión de datos ni transmisión de mensajes por lotes. Las primeras versiones incluso utilizaban el protocolo SOAP, que es voluminoso y prolijo, y consume una gran cantidad de ancho de banda. Para estaciones grandes con cientos de puntos de carga, la eficiencia de la transmisión de datos se convierte en un cuello de botella.
Los escenarios de carga modernos requieren métodos de inicio diversificados: aplicaciones móviles, tarjetas RFID, códigos QR, pagos NFC, tarjetas de crédito e idealmente "conectar y cargar". Sin embargo, la versión 1,6 solo admite de forma nativa tarjetas RFID y tokens de aplicaciones; otros métodos requieren sistemas externos, lo que aumenta la complejidad y los posibles puntos de falla.
La versión 1,6 simplifica la estructura de la estación de carga a dos capas: estación y conector. Este modelo plano no puede reflejar la compleja arquitectura de las estaciones de carga modernas. En realidad, una estación puede contener múltiples unidades de potencia, cada una controlando múltiples enchufes. El modelo simplificado 1,6 dificulta que los operadores determinen con precisión el estado de los recursos, a menudo confiando en datos adicionales provistos por el proveedor, que varían en formato y confiabilidad.
El mecanismo de manejo de transacciones fuera de línea en la versión 1,6 no es perfecto. Los ID de transacción son generados por el sistema central, y una vez que la red está caída, los ID locales son propensos a errores. Los eventos de inicio remoto carecen de identificadores únicos, lo que dificulta el seguimiento posterior. Estos problemas son particularmente evidentes en áreas con señales inestables, como estacionamientos subterráneos.
Cuando una estación de carga funciona mal, la información de diagnóstico proporcionada por la versión 1,6 a menudo no es lo suficientemente detallada. A los operadores les resulta difícil localizar rápidamente la causa raíz, lo que resulta en una baja eficiencia de mantenimiento. Además, si es necesario reemplazar un sistema de administración de back-end, migrar las estaciones de carga 1,6 a una nueva plataforma es complejo y puede provocar la pérdida de datos históricos.
Aunque la versión 1,6 (j) admite carga inteligente, lo que permite límites de potencia y ventanas de tiempo, sus capacidades son relativamente básicas. Para escenarios que requieren equilibrio de carga complejo o interacción Vehículo a Red (V2G), la versión 1,6 es insuficiente.
OCPP 2.0.1 es una versión revisada de 2,0 (la versión 2,0 fue descontinuada debido a múltiples problemas). Es una arquitectura completamente nueva, incompatible con 1,6, con cambios significativos en la filosofía de diseño y operación.
La documentación para la versión 2.0.1 ha sido reescrita, con una estructura más clara, funciones modularizadas y diagramas detallados y ejemplos de uso. Para los desarrolladores, esto significa un tiempo de implementación más corto y menos malentendidos.
Este es el cambio arquitectónico más significativo en 2.0.1. El nuevo modelo consta de tres capas:
Estación: toda la instalación de carga
EVSE (Equipo de Suministro de Vehículos Eléctricos): controlador físico que administra la distribución de energía
Conector: el enchufe de carga real
Esta estructura en capas permite al sistema identificar con precisión el estado de cada unidad de potencia. Por ejemplo, si un EVSE falla, los operadores pueden localizar con precisión el controlador específico sin afectar a otros enchufes en funcionamiento en la estación. Este nivel de gestión detallada es particularmente importante para estaciones de carga grandes.
Además, el 2.0.1 modelo de dispositivo se extiende a atributos físicos como sensores de temperatura, sistemas de refrigeración, iluminación y capacidades de visualización, proporcionando un soporte de datos más completo para operaciones y mantenimiento.
La versión 2.0.1 admite transmisión de mensajes por lotes y compresión de datos, lo que reduce en gran medida el uso de ancho de banda. En áreas con de infraestructura de comunicación limitada, esta mejora puede reducir directamente los costos operativos.
La nueva versión presenta perfiles de seguridad, que soportan autenticación básica y autenticación basada en certificados (mTLS). La información de autenticación se puede actualizar de forma remota y los eventos de seguridad notifican activamente al backend. Estas funciones son esenciales para cumplir con con las regulaciones de protección de datos y defenderse contra ciberataques.
El sistema central puede reiniciar EVSE individuales sin afectar a toda la estación. Para las transacciones en curso, el sistema ha mejorado la gestión del estado. Estas funciones mejoran significativamente la flexibilidad operativa y reducen la dependencia de la intervención manual en el sitio.
La versión 1,6 solo admite métricas basadas en transacciones, mientras que 2.0.1 admite non-transaction-level la recopilación de métricas e introduce un nuevo modelo de métricas. Los operadores pueden monitorear de manera más flexible el estado del equipo, los patrones de uso de energía y otros datos críticos.
2.0.1 de forma nativa admite funciones de carga inteligentes avanzadas, incluido el equilibrio de carga y la respuesta a la demanda. Es importante destacar que proporciona soporte completo para la interacción de vehículo a red (V2G) y el estándar ISO 15118.
Además de los RFID tradicionales y los tokens de aplicaciones, 2.0.1 admite de forma nativa códigos PIN, tarjetas de crédito y otros métodos, lo que proporciona una base técnica para estaciones no tripuladas y escenarios de carga y conexión.
La nueva versión mejora el funcionamiento fuera de línea: admite tipos de tokens complejos, gestión flexible de listas de autorización local, carga y carga fuera de línea y procedimientos estandarizados para el almacenamiento en caché de datos y cargas de reconexión. Estas mejoras garantizan un funcionamiento confiable incluso en condiciones de red inestables.
Esta es una de 2.0.1 las características más vanguardistas. ISO 15118 es el estándar de comunicación entre vehículos y estaciones de carga, compatible con plug-and-charge- los usuarios simplemente conectan, y el sistema los identifica automáticamente y comienza a cargar, sin interacción de tarjeta o aplicación.
La implementación de esta función requiere coordinación entre los fabricantes de vehículos, los vendedores de estaciones de carga y los operadores de red. 2.0.1 proporciona un marco técnico completo, que incluye gestión de certificados, sistemas de identidad estructurados y flujos de trabajo alineados con con ISO 15118.
2.0.1 permite que el sistema central envíe información de precios a las estaciones de carga, incluidas las tarifas actuales, los costos estimados y las facturas finales. Los usuarios pueden ver los detalles de los costos directamente en la pantalla de la estación, lo que mejora la transparencia.
Entender las especificaciones técnicas es una cosa; ver su funcionamiento práctico es otra. Los tres escenarios siguientes ilustran las diferencias entre las versiones.
Tomando el escenario común de "enchufar primero, luego autorizar":
La versión 1,6 no tiene un mensaje claro de "CablePluggedIn". Los sistemas suelen inferir esto a través de cambios de estado en StatusNotification (por ejemplo, Preparando, SuspendedEV). El problema es que estos estados varían según los vendedores: algunos indican esperar el deslizamiento de la tarjeta, otros indican que el vehículo no está listo y otros indican una autoprueba interna.
Esta ambigüedad causa tres problemas: comportamiento inconsistente entre marcas que afectan la experiencia del usuario, posibles inicios de transacciones no autorizadas y dificultad para que los sistemas de back-end evalúen con precisión el estado real, afectando las decisiones operativas.
Versión 2.0.1 presenta mensajes de Transaction Event y campos TriggerReason, lo que indica claramente eventos como "CablePluggedIn". Combinado con un ciclo de vida de la transacción bien definido, el proceso se vuelve predecible y rastreable, con comportamiento consistente entre los proveedores, mejorando significativamente la interoperabilidad.
OCPP 1,6: La disponibilidad del conector se limita a estados simples como en línea / fuera de línea o inactivo / ocupado. Para una estación con ocho enchufes, si dos están fuera de línea debido a fallas, es posible que 1,6 no refleje con precisión este detalle.
OCPP 2.0.1: La capa EVSE permite la identificación precisa del problema, ya sea una falla de comunicación de un controlador o un problema de hardware de un enchufe específico. Los operadores pueden diagnosticar de forma remota e incluso reiniciar una sola unidad de alimentación sin enviar técnicos.
OCPP 1,6: Admite lista blanca de RFID local, pero no tiene estándares para listas caducadas, integridad de datos fuera de línea y sincronización posterior a la reconexión. La implementación varía ampliamente, lo que puede causar pérdidas o duplicaciones de transacciones.
OCPP 2.0.1: Define flujos de trabajo completos fuera de línea, incluidas decisiones de autorización local, almacenamiento en caché de datos, cargas por lotes después de la reconexión y resolución de conflictos. Esto proporciona soporte técnico confiable, particularmente en áreas con de infraestructura de red limitada.
A pesar de las claras ventajas de 2.0.1, la adopción de la industria es lenta. Las razones principales incluyen:
Costo y complejidad: la actualización a 2.0.1 requiere una inversión significativa en desarrollo de hardware y software. Los ciclos de implementación de firmware son largos y los costos de soporte posteriores son altos. Para los operadores, actualizar o reemplazar el firmware existente puede implicar trabajo en el sitio a gran escala.
Consideraciones de estabilidad: se ha demostrado que 1,6 es estable durante muchos años. Si bien 2.0.1 tiene mejoras significativas, su complejidad es mayor. Para los operadores que priorizan operaciones estables, "funciona de manera confiable" a menudo supera "tiene más características".
Alternativas Funcionales: Muchas 2.0.1 características, como el pago con código QR, la visualización de tarifas y la programación inteligente, se pueden implementar en sistemas 1,6 a través de aplicaciones externas o desarrollo personalizado. Aunque menos elegantes, satisfacen las necesidades básicas.
Inercia del Ecosistema: Millones de 1,6 dispositivos ya están desplegados globalmente, formando un gran ecosistema. Los accesorios, herramientas y habilidades del personal giran en torno a 1,6. La migración requiere reconstruir estas capacidades.
Nuevas redes de carga: para la planificación de nueva infraestructura, se recomienda adoptar 2.0.1 para evitar futuros costos de migración y aprovechar al máximo el rendimiento y la extensibilidad del nuevo estándar.
Aplicaciones de gama alta: para proyectos de enchufe y carga, V2G y respuesta a la demanda complejos, 2.0.1 es necesario, ya que 1,6 no puede admitir de manera confiable estas funciones.
Operaciones a gran escala: los operadores con cientos de cargadores pueden beneficiarse de las optimizaciones de 2.0.1 rendimiento y los modelos detallados de dispositivos, mejorando la eficiencia operativa.
Seguridad y Cumplimiento: las estrictas regulaciones de pago y datos de con las regiones pueden confiar en 2.0.1 los mecanismos de seguridad para cumplir con el cumplimiento más fácilmente.
Para la mayoría de los operadores existentes, el cambio completo a 2.0.1 todavía no es oportuno. Un enfoque pragmático es:
Mantener los dispositivos 1,6 existentes: Continúe ejecutando el sistema 1,6 estable y complemente las funciones que faltan con los sistemas externos.
Seleccione 2.0.1 para nuevos dispositivos: Elija 2.0.1 equipo compatible para estaciones recién construidas.
Requiere soporte de versión doble: al comprar nuevos equipos, requiera que los proveedores soporten tanto 1,6 como 2.0.1, conservando la flexibilidad para futuras actualizaciones.
Supervise las tendencias de la industria: siga el progreso de la implementación de 2.0.1 los principales proveedores para evaluar el tiempo de migración.
La relación entre OCPP 1,6 y 2.0.1 es similar a la transición de los teléfonos con funciones a los teléfonos inteligentes. 1,6 es simple, confiable y suficiente, lo que respalda la primera ola de desarrollo de la red de carga global. 2.0.1 es más poderoso, seguro y flexible, sentando las bases para experiencias de carga de próxima generación.
Qué versión elegir depende de su situación: si su sistema 1,6 existente funciona bien con no necesita características urgentes, puede esperar; para nuevos proyectos o requisitos de características avanzados, abrazar 2.0.1; para escenarios intermedios, adopte un enfoque gradual, preparando nuevos dispositivos para el futuro.
Independientemente de la versión, comprender estas diferencias técnicas le ayuda a tomar decisiones más inteligentes y construir una red de carga de vehículos eléctricos más confiable y eficiente.
