Un cargador se sitúa entre dos conversaciones que no se encuentran. Por un lado, habla con el vehículo sobre cuánto corriente tomar y quién paga. Por otro lado, habla con un backend sobre sesiones, medidores y comandos remotos. Ambos utilizan protocolos diferentes, distintos modelos de datos y distintos regímenes de certificación.
Los compradores los confunden constantemente, y la confusión produce algunos de los malentendidos más costosos en la adquisición: una especificación que requiere un protocolo backend moderno bajo la creencia de que proporciona plug and charge, o una mejora del vehículo que se espera solucione un problema de facturación. Separar las capas hace que cada requisito sea verificable por sí solo.
Dos pilas, dos trabajos
La pila inferior pasa por el cable de carga. Se encarga de la conexión física, las comprobaciones de seguridad antes de la aplicación de la energía, la negociación de los parámetros de carga y — en sus versiones posteriores — la identidad del vehículo y el intercambio de certificados que permite la autorización automática.
La pila superior se ejecuta a través de una conexión de red, normalmente datos móviles o una LAN del sitio. Transporta lo que el operador necesita: comandos de inicio y parada, registros de transacciones, valores de contadores, diagnósticos, gestión de firmware y configuración. No tiene vista directa del vehículo. Todo lo que sabe sobre una sesión, lo aprendió del cargador.
Esa asimetría es la clave de todo el tema. El cargador es un traductor con sus propias opiniones, no una tubería transparente. Lo que el backend registra es lo que el cargador eligió informar, en el formato que define el protocolo superior.
Entre vehículo y Charger
La disposición antigua es sencilla y sigue siendo universal como alternativa. Una señal modulada en ancho de pulso en el piloto de control transmite una corriente máxima, el vehículo responde cambiando un nivel de voltaje y el cargador cierra su contactor cuando la secuencia lo permite. No existe un canal de datos en el sentido moderno ni un intercambio de identidad. La autorización se realiza fuera del protocolo, a través de un lector de tarjetas, una aplicación o una liberación manual.
Los protocolos de alto nivel añaden un canal de datos. La ISO 15118 y su predecesora DIN 70121 mantienen una conversación estructurada a través de la comunicación por línea eléctrica: el vehículo se identifica a sí mismo, ambas partes intercambian capacidades, el vehículo declara lo que quiere y el cargador informa de lo que puede suministrar. El intercambio continúa durante toda la sesión, por lo que el cargador puede ver la solicitud del vehículo y no solo la corriente resultante.
Las ediciones posteriores de ISO 15118 extienden esto a la identidad basada en certificados, que es lo que hace posible la autorización automática, y a la transferencia bidireccional de energía. Ambas extensiones requieren hardware y software que un cargador fabricado solo para la edición anterior no tiene.
Esta capa es donde las características del vehículo entran en el sistema. También es donde la documentación del propio cargador suele indicar dos cosas distintas: qué protocolo de alto nivel comunica al vehículo y qué protocolo de backend menciona.
Entre el cargador y el backend
El protocolo dominante aquí es OCPP, un estándar abierto mantenido por una asociación industrial e implementado por fabricantes de cargadores y plataformas backend de forma independiente. Define mensajes para autorización, inicio y fin de transacciones, valores de contadores, notificaciones de estado, comandos remotos, actualizaciones de firmware y configuración.
Las versiones posteriores de OCPP añaden gestión de dispositivos, perfiles de carga inteligentes mejorados y un enfoque más estructurado para los horarios compuestos. La diferencia práctica para un operador es cuánto control tiene el backend sobre cuándo y qué tan rápido carga cada conector, y cuánto de eso se puede cambiar sin necesidad de una visita al lugar.
Lo que OCPP no hace es comunicarse con el vehículo. Un backend que soporta la versión más reciente sigue aprendiendo sobre el vehículo de segunda mano. Si el cargador no muestra un valor, el backend no puede mostrarlo, y por mucho que la sofisticación de la plataforma lo recupere.
La conformidad añade una capa adicional de confusión. La conformidad con OCPP está certificada para un cargador según una versión definida, y la certificación pertenece a ese producto y a esa versión. No dice nada sobre el protocolo del lado del vehículo, ni sobre cómo un backend concreto implementa la misma versión. Dos productos conformes pueden seguir fallando en interoperar en las partes opcionales de la especificación, por lo que las pruebas de integración existen como una actividad separada.
Por qué Plug and Charge necesita ambos lados
La autorización automática, normalmente descrita como plug and charge, es una cadena más que una característica. El vehículo presenta un certificado contractual sobre el protocolo de alto nivel. El cargador lo valida contra una cadena de certificados en la que confía y autoriza localmente o reenvía la identidad hacia arriba para una decisión. El backend confirma que el contrato es válido y puede ser facturado.
Todos los enlaces deben estar presentes. Un vehículo sin certificado de contrato no puede presentar uno. Un cargador sin el protocolo de alto nivel y el trust store no puede leerlo. Un backend sin la gestión correspondiente de certificados no puede resolverlo. Cuando falta algún enlace, la sesión recurre a una tarjeta, una app o un código QR — que es exactamente lo que experimentan los conductores en redes que anuncian carga automática y la entregan solo para algunas combinaciones de vehículo y operador.
Por eso la función está disponible de forma desigual en la práctica. Depende de la intersección de tres sistemas actualizados de forma independiente, y la intersección es más pequeña que cualquiera de ellos.
Actualizar uno no mejora al otro
Cuatro supuestos comunes fallan por la misma razón.
Que un protocolo backend más reciente proporciona autorización automática. No lo hace, porque la autorización viaja por la pila inferior. Un cargador puede transmitir la versión más reciente del backend y aún así requerir tarjeta.
Que un vehículo que soporta carga automática funciona en cualquier red. Funciona cuando el cargador y el backend están configurados para ello y el operador tiene una relación de roaming o contrato con el proveedor del vehículo.
Que una actualización de firmware del cargador añada capacidad para el lado del vehículo. La parte del cargador puede actualizarse. El vehículo no puede, por el cargador.
Y esa certificación cubre ambas. Las certificaciones se emiten por producto, protocolo y versión, y un certificado que nombra una capa no dice nada sobre la otra.
Un cargador bien especificado indica las dos capas por separado, y los productos de esta gama suelen incluir una versión del protocolo backend junto a los protocolos del lado del vehículo que soportan. La especificación de estación 120 y 180 kW hace esto, y la separación es lo que hace que ambos requisitos sean evaluables individualmente.
Cómo escribir esto en un requisito
Un requisito que no pueda ser probado no es un requisito. Cuatro líneas lo hacen comprobable.
Indica el protocolo lateral del vehículo y la edición que debe soportar el cargador, y si se requiere autorización automática en esa interfaz. Indica el protocolo y la versión del backend, y si la conformidad debe certificarse o simplemente declararse. Indica el comportamiento de respaldo cuando cualquiera de las negociaciones falla, porque un sitio que pasa silenciosamente a un modo no autenticado es un problema de ingresos. Y indicar qué pruebas se aceptan: un número de certificado, un informe de prueba o una prueba conjunta con la plataforma que el operador pretende utilizar.
El último de estos es el que captura la mayoría de los proyectos. Las pruebas de conformidad demuestran que un producto cumple con una especificación. Las pruebas de integración demuestran que dos productos funcionan juntos. Los documentos de adquisición suelen pedir la primera y necesitan la segunda, y la brecha solo se hace visible después de entregar el hardware.
La relación entre estos protocolos y la gestión de carga es lo suficientemente estrecha como para causar confusión: un perfil de carga inteligente entregado a través del protocolo backend es una instrucción al cargador, que luego debe respetarlo dentro de lo que el vehículo acepte. Esa interacción se trata en la nota sobre load management, que describe dónde termina la instrucción y comienzan los propios límites del vehículo.
Una pila mira hacia el vehículo, otra hacia la plataforma, y ninguna puede sustituir a la otra. Cuando falta una funcionalidad, la primera pregunta es en qué pila se suponía que debía llegar.
Para la mayoría de los operadores, la consecuencia práctica es una lista de verificación en lugar de un rediseño. Escribe los dos requisitos del protocolo en líneas separadas, nombra la versión de cada uno, pregunta qué ocurre cuando la negociación falla y prueba la combinación antes de que abra el sitio en lugar de después de la primera queja.
¿Comprueba qué soporta realmente un cargador?
Pide el protocolo del lado del vehículo y el protocolo backend como dos líneas separadas, cada una con su versión. Un certificado no cubre ambos.
Haz una pregunta de especificación