Por qué fallan las sesiones de carga de VE: una guía de diagnóstico para operadores y conductores

El cargador indica Disponible. El conductor conecta el vehículo. No ocurre nada. O bien, la sesión funciona durante dos horas y se interrumpe al 4% por debajo del objetivo, mientras el panel de control muestra que el puerto sigue en línea todo el tiempo.

Todos los operadores se enfrentan a esto semanalmente. Casi nadie publica el árbol de decisiones.

Esta guía es ese árbol. Divide los fallos en las sesiones de carga de VE en tres ramas, basándose en lo único visible a las 6 de la mañana en un depósito —lo que hizo el cargador— y luego ofrece la señal de diagnóstico para cada caso: el estado OCPP y el código de error esperado, si la evidencia se encuentra en el registro del cargador o en el del backend, y cómo distinguir un fallo del vehículo, del cargador o de la red. La última sección cubre el nivel operativo: qué fallos se resuelven solos, cuáles requieren un reinicio remoto, cuáles necesitan una visita técnica y cómo gestionar cada uno sin saturar a tu equipo con alertas.

Empieza aquí: el triaje de tres ramas

El orden es importante. La primera rama significa que el cargador no iba a funcionar bajo ninguna circunstancia; nada de lo que haga el conductor cambiará eso. Las ramas dos y tres sí merecen el tiempo del conductor.

Rama 1: El cargador está averiado o no disponible

Cómo se manifiesta. La luz de estado está en rojo. La pantalla indica no disponible, averiado, fuera de servicio o equivalente. Esto es visible antes de que nadie conecte nada.

Qué debe hacer el conductor. Nada. Vale la pena decirlo claramente porque los conductores pierden tiempo aquí. Un cargador en este estado no iniciará el proceso de autenticación en absoluto; conectar el cable y pasar la tarjeta no generará una sesión, sin importar cuántas veces se intente. Si hay otro cargador disponible, úsalo. Si esta es la única opción, llama al administrador del sitio o a la línea de soporte y deja que ellos se encarguen.

Qué significa internamente. En OCPP 1.6, esto es una StatusNotification con estado Faulted o No disponible, y el errorCode correspondiente es la carga útil de diagnóstico. Los más comunes y lo que indican:

Tres causas distintas generan esta rama, y no son igual de probables:

1. Un fallo real de hardware o firmware. Este es el caso más frecuente.
2. El operador dejó el cargador inoperativo de forma deliberada — mantenimiento programado, un problema conocido o un sitio que requiere aprobación previa antes de su uso. Esto es ChangeAvailability a Inoperative en el backend, no un fallo. Nunca debería sorprender a su propio equipo, pero suele sorprender a los conductores.
3. Algo aguas arriba — un disyuntor desconectado, un sistema de gestión de carga que mantiene el sitio en cero o un problema de suministro.

Lo que normalmente no es: un problema de conectividad. Este es un diagnóstico erróneo común. Los cargadores están diseñados para seguir funcionando durante un tiempo sin conexión al backend, utilizando listas de autorización en caché. Un cargador que ha perdido su enlace de red normalmente seguirá cargando; por lo general, no pasará a estado Faulted. Si sus sitios experimentan periodos reales sin conexión, ese es un caso para conectividad con redundancia y respaldo y soporte de carga sin conexión — pero no busque una explicación de red cuando lo que está viendo es una luz roja.

Rama 2: El cargador está disponible, pero la sesión nunca comienza

Cómo se ve. El cargador está en verde. El conductor se conecta y se autentica, ya sea mediante la aplicación móvil, la tarjeta de combustible o la autenticación automática a través del vehículo. El cargador hace algo visiblemente: la pantalla cambia y parece estar preparándose. Luego vuelve al estado de disponible o entra en un estado de error. Al desconectar el cable, vuelve a ponerse en verde.

Esta es la rama más confusa para los conductores, porque todo parece indicar que debería funcionar.

Secuencia de reintento del conductor, en este orden:

1. Confirme que está utilizando la tarjeta de combustible o la cuenta correcta para este sitio.
2. Desconecte el cable del vehículo.
3. Apague el vehículo, enciéndalo y vuelva a apagarlo. Déjelo apagado.
4. Vuelva a conectar el cable.
5. Inicie una nueva sesión en un plazo de unos 20 segundos.
6. Si eso falla, pruebe con otro método de autenticación: la pantalla del cargador en lugar de la aplicación, o una tarjeta diferente.

Qué significa internamente. El cargador pasa de Disponible → Preparando el momento en que se presenta un cable o una tarjeta. Esa transición es normal y es el cargador haciendo su trabajo. Lo que sucede después es donde se produce el fallo, y existen dos familias de errores diferentes que parecen idénticas desde fuera del vehículo.

Familia A: autorización y backend. El cargador envía una solicitud de Authorize (o el idTag dentro de StartTransaction) al backend. El backend responde con un estado idTagInfo :

• Invalid : tarjeta o cuenta desconocida para este sistema
• Blocked : conocida, pero desactivada
• Expired : periodo de validez vencido
• ConcurrentTx : este token ya tiene una sesión abierta en otro lugar
• Accepted — autorizado para cargar

CualquierAceptado respuesta finaliza el intento y el cargador vuelve a Disponible. Esto es determinista: fallará de la misma manera en cada reintento, esa es la clave. La evidencia se encuentra en el registro del backend, no en el cargador. El cargador solo sabe que fue rechazado; el backend sabe por qué.

Existe una tercera posibilidad en esta familia: el backend nunca respondió porque se agotó el tiempo de espera o estaba sobrecargado. Es menos común, pero produce el mismo comportamiento visible y, a diferencia de una tarjeta rechazada, un reintento realmente puede tener éxito. Este es el único caso en el que "inténtalo de nuevo" es un consejo real y no una táctica dilatoria.

Familia B: el cargador no puede comunicarse con el vehículo. El cargador y el vehículo intercambian datos a través del piloto de control en el cable: disponibilidad, corriente disponible y estados de error. Si el vehículo ha estado estacionado durante un tiempo, es posible que su controlador de comunicación haya entrado en modo de suspensión y no se despierte para responder.

En OCPP 1.6 esto aparece como errorCode: EVCommunicationError, o como una sesión que llega a SuspendedEV y se queda ahí: el cargador está listo y ofreciendo energía, pero el vehículo no la acepta. Esa distinción es la señal más útil de toda esta guía: SuspendedEVSE significa que el cargador o la instalación están reteniendo la energía; SuspendedEV significa que el vehículo está así. Uno es problema suyo para arreglarlo, el otro es de la flota.

El ciclo de apagado/encendido/apagado en la secuencia de reintento existe específicamente para activar el controlador del vehículo. Funciona con la frecuencia suficiente como para intentarlo antes de escalar el problema.

Cómo distinguir las familias rápidamente: si falla de forma idéntica cada vez con un retorno limpio a Disponible, sospeche de la autorización: verifique el backend. Si el comportamiento varía entre intentos o la sesión se queda bloqueada en un estado suspendido, sospeche de la comunicación con el vehículo. Alertas OCPP en tiempo real y estado del cargador y del conector le ofrecen esta distinción sin que nadie tenga que leer registros sin procesar en el depósito.

Rama 3: La sesión comienza, pero se detiene antes de tiempo

Cómo se ve. La sesión se inició correctamente. El vehículo recibió energía real (varios kWh, posiblemente durante horas). Luego se detuvo, sin que el vehículo estuviera completamente cargado.

Acciones del conductor: inicie una nueva sesión. Si no funciona, apague y encienda el vehículo e inténtelo de nuevo. Si sigue sin funcionar, pruebe con otra tarjeta o cuenta.

Qué significa internamente. Debido a que tuvo una sesión funcional, el fallo de hardware es la menos probable de las explicaciones. Priorice las políticas de uso.

Causa más común: un límite de SoC intencionado. Muchos depósitos y estaciones públicas limitan las sesiones a un estado de carga objetivo. Esto es deliberado por dos buenas razones. Primero, la mayoría de los vehículos reducen drásticamente la velocidad de carga por encima del 80% de SoC aproximadamente, por lo que el último quinto tarda mucho más de lo debido y bloquea el conector para el siguiente vehículo. Segundo, cargar habitualmente al 100% todos los días reduce notablemente la vida útil de la batería. Si su flota hace esto, asegúrese de que los conductores lo sepan; una parada intencionada que nadie documentó genera la misma llamada de soporte que una avería real.

Segunda causa: un límite de autorización. En las estaciones públicas, las tarjetas de combustible y de crédito tienen límites de preautorización. Cuando el coste de la sesión alcanza ese límite, muchos operadores detienen la sesión en lugar de asumir el riesgo. Una nueva sesión restablece el límite, por eso reiniciar funciona.

Tercera causa: algo realmente la detuvo. OCPP StopTransaction incluye un campo reason , y es la forma más rápida de resolver esto:

Una parada Remote en un depósito suele ser su propia gestión de carga haciendo exactamente lo que se configuró para hacer. Compruebe eso antes de enviar a alguien.

¿Registro del cargador o registro del backend?

Los dos registros responden a preguntas diferentes, y recurrir al equivocado hace perder los primeros veinte minutos de cualquier investigación.

• Registro del backend — ¿era válido el token?, ¿qué devolvió la autorización?, ¿qué mostraron los valores del medidor a lo largo del tiempo?, ¿qué motivo de parada se recibió?, ¿cuándo comenzó la interrupción del heartbeat? Úselo para fallos de autorización, paradas por políticas y cualquier problema de conectividad.
• Registro del cargador — eventos de contactores y relés, disparos térmicos y de protección, cambios de estado del control pilot, comportamiento del firmware, errores internos. Úselo para cualquier problema físico y para InternalError o OtroError.

La regla práctica: si el fallo fue determinista y limpio, es un problema del backend. Si fue caótico, intermitente o físico, es un problema del cargador.

Acceder al registro del cargador solía requerir una visita al sitio. No debería ser así. Diagnóstico de hardware y registro y auditoría del cargador son lo que permite que esto se resuelva desde el escritorio, lo cual es importante porque la diferencia entre diagnosticar de forma remota o en el sitio es todo un día de trabajo de un técnico.

La capa operativa: qué hacer con cada fallo

El diagnóstico es la mitad del trabajo. La otra mitad es la gestión: decidir qué fallos realmente requieren atención humana.

Autorreparación: regístralo, no generes una alerta. Reducción térmica que se resuelve sola. Eventos de SuspendedEV aislados en vehículos que luego cargan correctamente. Breves interrupciones de conexión que se recuperan dentro del margen de reintento. Alertar sobre esto entrena a tu equipo para ignorar las notificaciones, lo cual es peor que no recibirlas.

Reinicio remoto: inténtalo automáticamente y alerta solo si falla. FalloDeBloqueoDelConector, FalloDelLector, y muchos ErrorInterno casos se resuelven con un reinicio suave. Inténtelo y solo escale el problema a una persona si el reinicio no funciona o si el fallo persiste. Control remoto del cargador y actualizaciones automáticas de firmware solucionan la mayor parte de esta categoría; los fallos recurrentes relacionados con el firmware, en particular, deben resolverse mediante el despliegue de una versión, no con reinicios repetidos.

Desplazamiento de técnico: avise inmediatamente y proporcione contexto. FalloDeTomaDeTierra, FalloDelInterruptorDePotencia, FalloDelMedidorDePotencia, daños físicos en el conector y cualquier problema que persista tras dos reinicios. Un cargador que está realmente averiado requiere inspección o reparación de emergencia, lo cual puede llevar de horas a días. La alerta debe incluir el código de error, el extracto del registro y el historial de reinicios, para que el técnico sepa a qué se enfrenta al llegar. Notificaciones multicanal, el centro de alertasy la colaboración del equipo en las alertas son lo que evita que esto se convierta en una cadena de llamadas.

Si no te corresponde arreglarlo, redirígelo. Las fallas del vehículo son responsabilidad de la flota o del fabricante (OEM). Los problemas de pago y roaming corresponden al proveedor de servicios de movilidad (eMSP). Los problemas de suministro son competencia de la empresa eléctrica. El costo aquí no es la reparación, sino la hora perdida confirmando que, desde el principio, no era tu responsabilidad. Mesa de ayuda de nivel 1 y el soporte de nivel 2 existen para absorber ese triaje antes de que llegue a tus ingenieros.

El principio fundamental: cada alerta debe corresponder a una acción que una persona pueda realizar. Cualquier otra cosa es ruido, y el ruido es la razón por la que se pasan por alto las fallas reales. Combinar esto con el mantenimiento preventivo de cargadores elimina por completo una parte importante de estos fallos de la cola de tareas reactivas.

Preguntas frecuentes

¿Por qué mi cargador aparece como Disponible pero se niega a iniciar una sesión?El cargador está listo; algo después de ese paso es lo que está fallando. Por lo general, se trata de un rechazo de autorización del backend, un tiempo de espera agotado en el backend o un fallo de comunicación del vehículo a través del cable. Apagar y encender el vehículo e intentarlo de nuevo en menos de 20 segundos suele resolver los casos relacionados con el vehículo.

¿Por qué mi sesión de carga se detuvo antes de que la batería estuviera llena?Generalmente es algo intencionado. Muchos depósitos y sitios públicos limitan las sesiones a un estado de carga objetivo para liberar el conector y proteger la vida útil de la batería. La otra causa común es un límite de preautorización en una tarjeta de combustible o de crédito. Iniciar una nueva sesión normalmente permite continuar la carga.

¿Cómo puedo saber si el problema es el cargador o el vehículo?Compruebe qué lado suspendió la sesión. En OCPP, SuspendedEVSE significa que el cargador o el sitio está restringiendo la energía; SuspendedEV significa que el vehículo no la está aceptando. EVCommunicationError indica un problema en el enlace de datos del cable con el vehículo.

¿Deja de funcionar un cargador cuando pierde la conexión a internet?Por lo general, no. Los cargadores funcionan durante un tiempo sin conexión al sistema central utilizando la autorización en caché. Es mucho más probable que un cargador en rojo o con error se deba a una causa de hardware o configuración que a un problema de red.

¿Qué fallos de carga requieren una visita al sitio?Fallos de conexión a tierra, fallos en contactores y medidores, daños físicos y cualquier error que persista después de dos reinicios remotos. La mayoría de las otras categorías —fallos de bloqueo, fallos del lector, eventos térmicos y muchos errores internos— se resuelven de forma remota.

Reduzca los desplazamientos innecesarios. Ampcontrol ofrece a los operadores alertas OCPP en tiempo real, diagnósticos remotos y control remoto para cualquier marca de cargador; es la base para monitorear y mantener sus cargadores y para utilizar OCPP en las operaciones de carga a gran escala. Reserve una demostración para verlo aplicado a sus propios sitios.

‍