Un hotel instala varios cargadores para huéspedes. Todo funciona bien hasta que una noche alguien lanza una actualización remota sin validar compatibilidad, sin aviso interno y sin plan de reversión. A la mañana siguiente, recepción acumula quejas, el parking tiene plazas bloqueadas y el equipo de mantenimiento no sabe si el problema está en el cargador, en el sistema de pago o en la comunicación con la plataforma de gestión. Eso ocurre más a menudo de lo que debería.
En infraestructura de recarga, una actualización software no es una tarea menor. Afecta a la disponibilidad del servicio, a la experiencia del usuario y a la continuidad del negocio. En hoteles, aparcamientos, hospitales o flotas, el problema no es solo instalar una versión nueva. El problema es hacerlo sin romper nada que ya estaba funcionando.
Por qué una actualización de software no es solo pulsar un botón
Cuando se opera una red de cargadores, actualizar firmware o software es parecido a intervenir una instalación viva. El cargador no está aislado. Está conectado a una plataforma de gestión, a sistemas de acceso, a medios de pago, a límites de potencia del edificio y, en muchos casos, a expectativas de servicio 24/7.
En un entorno pequeño, un fallo puede parecer asumible. En uno distribuido, no lo es. Si una actualización deja fuera de servicio varios puntos a la vez, el impacto salta de lo técnico a lo operativo. El hotel pierde valor para el huésped, el parking pierde rotación, la flota pierde planificación y el operador pierde tiempo resolviendo incidencias que eran evitables.
Una actualización bien ejecutada apenas se nota. Una mala actualización la nota todo el mundo.
La forma correcta de verlo es simple. Actualizar no es instalar cambios. Es gestionar riesgo. En activos críticos, esa diferencia importa mucho. Un caso conocido en la industria aeronáutica mostró que una actualización de software podía afectar a 5.100 aeronaves, lo que ilustra por qué hay que revisar con rigor ventanas de mantenimiento, compatibilidad y reversibilidad antes de tocar sistemas críticos (caso citado sobre impacto operativo en aeronaves).
Lo que suele salir mal
Hay patrones muy claros en despliegues problemáticos:
- Se actualiza por inercia. Nadie confirma si el cambio resuelve un problema real o introduce una función necesaria.
- Se mezcla hardware y software de distintos fabricantes sin comprobar si siguen hablando el mismo “idioma”.
- Se lanza a toda la red a la vez para “terminar antes”.
- Se elige mal la ventana de mantenimiento y el corte coincide con horas de uso.
- Nadie define qué hacer si falla y la reversión se improvisa.
Lo que sí funciona
Los despliegues tranquilos comparten tres rasgos: planificación previa, pruebas controladas y monitorización posterior. No hay magia. Hay método.
Fase 1 Planificar antes de actuar
A las 18:00, un hotel entra en su pico de llegadas. Si en ese momento una actualización deja varios cargadores en estado “disponible” pero sin aceptar sesiones, el problema no es técnico. Es operativo, comercial y reputacional. Por eso la planificación se decide antes del despliegue, no mientras aparecen incidencias.
Entender qué se va a tocar de verdad
En recarga EV, una actualización rara vez afecta a una sola pieza. Cambia firmware, comunicaciones, reglas de autenticación, pagos, telemetría o reparto de potencia. Si no se identifica ese alcance real, se aprueba un cambio “menor” que luego obliga a bloquear plazas, atender llamadas de soporte y enviar técnicos fuera de hora.
Hay dos siglas que conviene bajar a tierra:
- OCPP define cómo se comunican el cargador y la plataforma de gestión. Si la versión del equipo y la del sistema no encajan, aparecen fallos que en campo se ven muy claros: sesiones que no arrancan, estados erróneos, comandos remotos que no llegan o consumos que no se registran bien.
- OCPI regula el intercambio de información entre plataformas. Importa cuando los puntos deben mostrarse en redes de terceros, compartir disponibilidad o coordinar acceso entre distintos operadores.
Un caso típico es el de un aparcamiento público con cargadores de un fabricante y software de otro. El sistema funciona durante meses. Llega una nueva versión de firmware, se instala sin revisar compatibilidad y el punto sigue encendido, pero deja de reportar sesiones al CPMS o no refleja bien si está libre u ocupado. Desde fuera parece un detalle. En operación, provoca colas, reclamaciones y pérdida de confianza.
Decidir si el cambio compensa el riesgo
No todas las actualizaciones deben entrar en la siguiente ventana disponible. Algunas corrigen una vulnerabilidad o un fallo que ya está afectando al servicio. Otras añaden funciones que pueden esperar si el riesgo operativo es alto. La primera decisión no es técnica. Es de prioridad.
Antes de aprobar un cambio, conviene cerrar estas preguntas:
- Motivo del cambio. ¿Se corrige un fallo real, una exigencia de seguridad o una necesidad de negocio concreta?
- Inventario actual. ¿Qué versiones están instaladas en cargadores, pasarelas, routers, contadores y plataforma?
- Dependencias afectadas. ¿Puede alterar acceso, pago, balanceo dinámico, supervisión o medición?
- Perfil de uso del sitio. ¿Es un hotel con picos nocturnos, un parking de alta rotación o una base de flota con ventana cerrada de carga?
- Capacidad de reversión. ¿Se puede volver atrás en remoto o hará falta intervención física?
Una regla simple ayuda a filtrar decisiones pobres. Si el equipo no puede explicar en una frase por qué actualiza ahora, el cambio todavía no está listo para aprobarse.
Planificar también es coordinar a todos los implicados
Los fallos serios suelen aparecer entre equipos, no dentro de un equipo. Operaciones asume una ventana de mantenimiento. El fabricante da por hecho que la versión de backend ya está adaptada. El instalador no sabe que ese emplazamiento comparte cuadro con otros servicios. El resultado es el de siempre. Nadie veía un riesgo completo porque cada parte veía solo su tramo.
Por eso conviene documentar responsables, dependencias, validaciones previas, criterio de éxito y criterio de parada. En gestión de cambios, marcos como ITIL recomiendan evaluar impacto, riesgo, recursos, calendario y plan de reversión antes de autorizar la ejecución (guía de gestión de cambios de ITIL). En despliegues con varios proveedores, también ayuda ordenar tareas, aprobaciones y bloqueos con integraciones de gestión de proyectos, sobre todo cuando intervienen operaciones, soporte, fabricante e instalador.
Si además la infraestructura combina hardware, software y terceros, merece la pena revisar cómo plantear las integraciones entre socios tecnológicos antes de programar la actualización. Es mucho más barato detectar una incompatibilidad en la planificación que descubrirla con usuarios esperando para cargar.
Fase 2 Probar en un entorno seguro para evitar sorpresas
Son las 19:00 en un hotel. Llegan varios clientes, dos necesitan cargar antes de salir temprano al día siguiente y, tras una actualización mal probada, los cargadores aceptan la identificación pero no inician la sesión. El problema no siempre aparece como un fallo total. A veces se presenta como algo más peligroso para la operación: cobros que no se registran, estados erróneos en la plataforma o límites de potencia que cambian sin aviso.
Por eso la prueba previa no se hace para cumplir un trámite técnico. Se hace para proteger la continuidad del servicio.
Un entorno seguro no tiene que ser un laboratorio aislado y perfecto. Tiene que reproducir las condiciones que luego importan en producción. Mismo modelo de cargador, misma versión de backend, misma configuración de red y, si es posible, el mismo esquema de balanceo de potencia y control de acceso que usa el emplazamiento real. Si la instalación depende de reglas de usuarios, tarjetas RFID o permisos por franjas horarias, también conviene validarlo con un caso parecido al de explotación. En redes donde la autorización y las reglas operativas están muy ligadas al uso diario, merece la pena revisar cómo afecta la actualización al sistema de control de acceso para cargadores.
Qué conviene probar antes de dar luz verde
La muestra piloto debe parecerse al riesgo real, no al caso más cómodo. En una flota privada, suele bastar con un cargador poco crítico pero conectado al mismo entorno que el resto. En un hotel o un aparcamiento público, el piloto debe incluir al menos un punto que comparta cuadro eléctrico, comunicaciones y políticas de acceso con otros equipos. Ahí es donde aparecen incompatibilidades que en un banco de pruebas simple no salen.
Más que comprobar si el cargador vuelve a encender, hay que validar la cadena completa:
| Elemento a validar | Qué debe comprobar |
|---|---|
| Inicio de carga | Que la sesión empieza sin errores |
| Identificación de usuario | Que tarjetas, app o reglas de acceso siguen funcionando |
| Pago | Que el cobro o autorización no se interrumpe |
| Datos | Que el consumo y el estado se reportan al CPMS |
| Potencia | Que el reparto de energía no crea disparos ni limitaciones inesperadas |
El piloto debe tener criterio de parada
Aquí suele fallar la disciplina operativa. Se instala la nueva versión, se ve una carga correcta y se interpreta como prueba superada. No basta. Hace falta definir cuánto tiempo se observa el equipo, qué incidencias obligan a parar y quién autoriza seguir. Si durante la prueba aparece una sola anomalía en facturación, conectividad o reparto de potencia, la decisión correcta muchas veces es detener el despliegue y analizar, aunque el cargador siga pareciendo operativo de cara al usuario.
También hace falta un rollback real. No una nota genérica que diga “volver a la versión anterior”, sino un procedimiento probado, con tiempos estimados, responsables y condiciones claras para ejecutarlo. En operaciones 24/7, esa diferencia evita improvisaciones caras: reinicios en cadena, visitas urgentes sin diagnóstico y equipos fuera de servicio en la hora de mayor uso.
Si no se ha probado cómo volver atrás, la prueba aún no está cerrada.
La lógica del piloto es conocida en gestión de cambios: probar en un grupo reducido, documentar resultados y decidir la expansión con evidencias, no por calendario. Microsoft describe ese enfoque en sus despliegues por anillos y validación progresiva, una práctica útil cuando un fallo parcial ya supone impacto operativo.
Qué problemas detecta esta fase antes de que lleguen los usuarios
Los fallos más costosos no siempre bloquean todos los cargadores. A menudo dejan la red en una zona gris que desgasta al equipo de soporte durante días:
- Sesiones que arrancan pero no se cierran bien, con ajustes manuales de facturación.
- Estados incorrectos en plataforma, que hacen parecer disponible un cargador que no acepta cargas.
- Pérdida de telemetría, que impide ver alarmas, consumos o causas de fallo.
- Cambios en el balanceo de potencia, con disparos, limitaciones inesperadas o reparto desigual entre puntos.
- Errores de autorización, donde el usuario se identifica pero la regla no se aplica como antes.
Probar bien esta fase cuesta menos que sostener una operación inestable en un hotel, una comunidad o un aparcamiento abierto al público. Esa es la diferencia entre actualizar software y mantener el servicio.
Fase 3 Ejecutar la actualización de forma remota y controlada
La ejecución no debería parecer una carrera. Debería parecer una operación coordinada. En la mayoría de redes modernas, esto se hace con actualizaciones remotas u OTA. Eso permite lanzar firmware sin enviar un técnico a cada emplazamiento, pero solo funciona bien si la red está ordenada y la plataforma de gestión da control real sobre grupos, horarios y estados.
Elegir la ventana correcta cambia todo
La mejor hora para actualizar no depende del departamento de IT. Depende del uso del activo.
Un parking de oficinas suele tolerar mejor una madrugada de fin de semana. Un hotel, en cambio, puede tener menos impacto entre salida y entrada de clientes si su demanda de carga baja en ese tramo. En hospitales o infraestructuras con disponibilidad permanente, conviene dividir la red y mantener capacidad operativa durante todo el proceso.
Cómo ejecutar sin crear caos
En la práctica, el orden importa más que la velocidad:
- Agrupe por criticidad. No empiece por los cargadores más usados.
- Lance por oleadas. Primero un grupo pequeño, después un segundo grupo, y solo al final el resto.
- Congele cambios paralelos. No mezcle actualización con cambios de tarifas, acceso o configuración eléctrica.
- Avise antes. Recepción, mantenimiento, seguridad y atención al cliente deben saber qué pasará y cuándo.
- Verifique conectividad. Una OTA con red inestable es una invitación al fallo.
Uno de los errores más habituales al actualizar software es ignorar el coste total de mantenimiento. También conviene activar actualizaciones automáticas cuando sea seguro, hacer copias de seguridad previas y verificar compatibilidad para evitar pérdida de datos o regresiones funcionales (buenas prácticas y coste de mantenimiento en actualizaciones).
El papel del CPMS en un despliegue serio
Un CPMS es la plataforma desde la que se supervisan y gobiernan los puntos de recarga. En lenguaje simple, es el panel central que le dice qué cargador está disponible, cuál está cargando, cuál está fallando y qué cambios se pueden lanzar de forma remota.
Si además el sistema gestiona permisos, perfiles y reglas de uso, conviene coordinar la actualización con la lógica de acceso. Un cambio de firmware puede afectar a autorizaciones, horarios o validaciones si nadie revisa la configuración de software de control de acceso para recarga.
Más adelante, cuando la operación requiera una vista unificada de cargadores, usuarios y estados, una plataforma como Evenergia puede actuar como capa de gestión y monitorización sobre distintos equipos y fabricantes, siempre que se haya resuelto antes la compatibilidad y el modelo operativo.
Para entender cómo se organiza una ejecución remota con criterio, este vídeo resume bien el enfoque operativo:
Lo que nunca conviene hacer
Hay decisiones que salen caras:
Lanzar la misma actualización sobre toda la red porque “ya pasó en pruebas” es confundir validación con control de riesgo.
También conviene evitar dos cosas. Actualizar cuando hay incidencias abiertas que todavía no están diagnosticadas, y actualizar durante periodos comerciales sensibles, como fines de semana con alta ocupación o días de máxima rotación.
Fase 4 Garantizar la seguridad y el cumplimiento normativo
En 2026, seguir con versiones antiguas ya no puede tratarse como una simple decisión de mantenimiento. En muchos casos, es un problema de seguridad y de cumplimiento. Un cargador conectado no solo entrega energía. También intercambia datos, acepta órdenes remotas y depende de comunicaciones con otros sistemas.
Por qué la actualización ya forma parte del control de seguridad
En España, la actualización de software se ha vuelto crítica para la seguridad y el cumplimiento. La Ley 11/2022 y las guías del CCN-CERT exigen aplicar parches de seguridad con prioridad, mientras que el Esquema Nacional de Seguridad, revisado en 2022, consolida la gestión de actualizaciones como un control esencial para infraestructuras conectadas (marco citado sobre seguridad, parcheado y cumplimiento en España).
Esto tiene una consecuencia práctica. Si gestiona cargadores en un hotel, un hospital, un parking público o una red corporativa, mantener versiones desactualizadas no solo aumenta riesgo técnico. Debilita su posición operativa si hay una incidencia, una auditoría o una reclamación por indisponibilidad.
Qué revisar además del parche
La parte normativa no se limita a “instalar la última versión”. Hay varias preguntas de gestión que importan:
- Trazabilidad. ¿Quién aprobó el cambio, cuándo se ejecutó y sobre qué equipos?
- Registro. ¿Puede demostrar qué versión tenía cada punto antes y después?
- Privacidad. ¿El cambio afecta al tratamiento de datos de usuario o a métodos de autenticación?
- Interoperabilidad. ¿La actualización mantiene la comunicación con plataformas externas y sistemas administrativos?
- Continuidad. ¿Se ha diseñado para no dejar la instalación sin servicio innecesariamente?
En recarga pública o semipública, además, el software tiene impacto sobre cómo se informan sesiones, estados y disponibilidad. Si una actualización rompe esa capa, el problema no es solo interno. También afecta a terceros, a usuarios y a obligaciones de operación.
La parte legal y la parte operativa no van separadas
Muchos gestores ven la seguridad como un asunto del fabricante y el cumplimiento como un asunto del asesor. En la práctica, ambas cosas se cruzan en el mismo punto: cómo se gobiernan los cambios.
Un parche de seguridad aplicado tarde puede abrir una puerta técnica. Un parche aplicado mal puede cerrar el servicio.
Por eso conviene tratar la actualización como un proceso auditable. No basta con que “funcione”. Tiene que quedar constancia de qué cambió, por qué cambió y cómo se validó. En activos con uso continuo, esa disciplina reduce discusiones internas, acelera diagnósticos y protege mejor al operador.
Fase 5 Monitorizar el rendimiento y comunicar los resultados
Cuando la actualización termina, empieza la parte que muchos descuidan. El hecho de que una barra llegue al 100% no significa que la operación haya terminado bien. Significa solo que el sistema ha instalado algo. Ahora toca confirmar que el negocio sigue funcionando como debe.
Qué vigilar durante las primeras horas y días
La monitorización posterior tiene que centrarse en señales operativas, no solo técnicas. En un CPMS o plataforma equivalente conviene revisar:
- Disponibilidad real. Si los puntos aparecen online y aceptan sesiones de forma estable.
- Sesiones fallidas. Si aumenta el número de intentos que no llegan a completarse.
- Potencia entregada. Si la carga mantiene el comportamiento esperado.
- Estados anómalos. Si aparecen puntos en error, ocupado permanente o desconectado sin motivo claro.
- Incidencias de usuario. Si recepción, seguridad o soporte empiezan a recibir patrones repetidos.
Si surgen problemas, el diagnóstico debe ir por orden. Saber por qué fallan las actualizaciones ayuda mucho. Las causas comunes incluyen conectividad Wi-Fi deficiente, falta de espacio, controladores incompatibles o conflictos con software de seguridad (causas habituales de fallos en actualizaciones y diagnóstico).
Convertir incidencias en información útil
Un hotel puede detectar el problema porque un huésped no consigue iniciar carga. Una flota lo notará porque un vehículo sale con menos autonomía de la prevista. Un parking lo verá cuando varios usuarios llamen por el mismo mensaje de error. Esas señales no deben quedarse en “soporte”. Hay que clasificarlas y compararlas con el cambio realizado.
Una buena práctica es abrir un periodo corto de observación reforzada. Durante ese tiempo, operaciones revisa alertas, atención al cliente recopila incidencias y mantenimiento confirma si hay patrones por modelo, ubicación o versión.
La mejor revisión post-actualización no pregunta solo “¿falló algo?”. Pregunta “¿qué cambió en la experiencia del usuario?”.
Comunicar también forma parte de la operación
Si la actualización introduce una nueva forma de acceso, un ajuste en tarifas o una mejora en la reserva, hay que comunicarlo con claridad. Si no, el usuario interpreta el cambio como un problema, aunque técnicamente funcione.
En redes con varios emplazamientos, esa visibilidad mejora mucho cuando existe monitorización en tiempo real de los puntos de recarga. No solo ayuda a detectar incidencias. También permite explicar al cliente interno qué pasó, qué se corrigió y cuál es el estado actual de la red.
Convierta sus actualizaciones en una ventaja competitiva
Gestionar bien una actualización software protege la inversión, evita paradas innecesarias y mejora la experiencia del usuario. En recarga para empresas, hoteles, parkings o flotas, el valor no está en actualizar más rápido. Está en actualizar sin perder control.
Cuando el proceso se hace bien, pasan tres cosas. La infraestructura sigue disponible, el equipo interno trabaja con menos tensión y el negocio no convierte un cambio técnico en una incidencia visible para el cliente. Esa es la diferencia entre operar cargadores y simplemente tenerlos instalados.
Si necesita apoyo para planificar, probar, desplegar y supervisar cambios sin improvisación, puede revisar soluciones adaptadas a instalaciones para empresas, casos de uso en hoteles o servicios de operación y mantenimiento.
Si quiere que su infraestructura de recarga siga operativa mientras evoluciona, hable con un especialista de Evenergia. Podemos revisar su red, detectar riesgos de compatibilidad y proponer un plan de actualización ajustado a su operación. Solicite una evaluación gratuita y tome decisiones con criterio antes de que una actualización le obligue a reaccionar con prisas.