Una célula robotizada parada porque nadie hizo una copia de seguridad antes de cambiar el controlador. Un programa de soldadura sobreescrito por error que tardó dos jornadas en reconstruirse. Son situaciones reales que ocurren con más frecuencia de la que debería en plantas industriales de toda la región. Sin embargo, implementar un proceso de backup sólido es una de las tareas de gestión más sencillas y baratas que existen.
Qué contiene realmente un backup completo
El error más habitual es confundir «tengo el programa guardado» con «tengo un backup completo». Un fichero de programa por sí solo no es suficiente para restaurar un robot al 100 % tras un fallo grave. Un backup completo debe incluir, como mínimo:
- Programas de movimiento y rutinas de proceso, incluyendo todos los módulos y subrutinas auxiliares.
- Datos del sistema: configuración de herramientas (tool data), datos de pieza (work object / frame data), variables persistentes y datos de carga útil.
- Parámetros del controlador: configuración de ejes, límites software, parámetros de comunicación y opciones de software activadas.
- Datos de seguridad: configuración de zonas seguras, enclavamientos y parámetros del módulo de seguridad cuando la célula dispone de uno.
- Datos de calibración y mastering: los valores que definen la posición cero de cada eje. Sin ellos, restaurar el programa no sirve de nada si el robot no vuelve a moverse por las posiciones correctas.
Cada fabricante agrupa estos elementos de forma distinta y utiliza su propia terminología, pero el concepto es el mismo en ABB, KUKA y FANUC: un backup parcial es mejor que nada, pero puede ser insuficiente en una situación de emergencia real.
Cuándo hacer el backup: frecuencia y eventos disparadores
Definir una frecuencia fija (por ejemplo, semanal o mensual) es un buen punto de partida, pero no es suficiente por sí solo. Hay eventos que obligan a realizar una copia de seguridad inmediata con independencia del calendario:
- Antes y después de cualquier modificación de programa, aunque sea puntual.
- Antes de una actualización de firmware o de software del controlador.
- Antes de sustituir cualquier componente del controlador (módulo de accionamiento, placa principal, disco de sistema).
- Antes de una parada de vacaciones o de producción prolongada.
- Después de completar una puesta a punto o un ajuste de calibración.
- Tras la validación de un nuevo programa en producción.
Un backup realizado justo antes de una intervención es también la mejor evidencia de auditoría si algo sale mal durante el trabajo.
Dónde almacenar las copias y durante cuánto tiempo
El soporte de almacenamiento importa. Un USB olvidado en el cajón del armario de control no es una política de backup. Las buenas prácticas recomiendan una estrategia en tres niveles:
- Copia local en el propio controlador o en un soporte en armario (cuando el controlador lo permite), accesible de forma inmediata en caso de restauración urgente.
- Copia en servidor de red de planta (NAS o servidor de ficheros), con acceso controlado y organizada por robot, fecha y versión.
- Copia fuera de planta o en la nube, que protege frente a incendios, inundaciones u otros eventos que afecten a las instalaciones físicas.
En cuanto a la retención, mantener al menos las últimas tres o cuatro versiones de cada programa permite retroceder a una versión anterior si se detecta un problema que no era visible en el momento de la modificación. Para procesos críticos, conviene guardar además la versión validada en producción de forma indefinida.
Cómo validar que el backup es restaurable
Una copia de seguridad que nunca se ha probado no es una copia de seguridad: es una esperanza. El proceso de validación no tiene por qué ser complejo, pero sí debe ser periódico:
- Verificar que los ficheros se han generado correctamente y que no están corruptos (comprobación de tamaño y, si es posible, de integridad).
- Documentar en la GMAO la fecha, el operador que realizó la copia y la versión del programa.
- Al menos una vez al año —o en cada cambio mayor de hardware— realizar una restauración completa en un entorno controlado o en una ventana de mantenimiento planificada, y verificar que el robot recupera sus posiciones de referencia sin desviación.
Este último punto es especialmente importante si el plan de contingencia incluye la sustitución del controlador. Si nunca has restaurado en un controlador diferente, descubrirás en el peor momento si hay licencias de software, opciones activadas o parámetros de hardware que bloquean el proceso. Puedes leer más sobre este aspecto en nuestro artículo sobre sustitución del controlador de un robot obsoleto.
Errores habituales que convierten el backup en una trampa
Incluso cuando existe una política de backup, estos errores comprometen su utilidad:
- Guardar solo el programa principal e ignorar los módulos de sistema, los datos de herramienta o los ficheros de configuración de seguridad.
- No versionar: sobrescribir siempre el mismo fichero impide retroceder a una versión anterior.
- Backups sin etiquetar: carpetas llamadas «robot1_final_v2_DEF» sin fecha ni descripción son inútiles bajo presión.
- No incluir los datos de mastering: restaurar el programa sin los datos de calibración obliga a repetir el proceso de mastering completo, lo que puede suponer horas de trabajo adicional.
- Acceso no controlado: si cualquier operario puede sobrescribir la copia «oficial», la política de backup carece de valor.
Integración con la GMAO y el cambio de turno
La gestión de backups gana consistencia cuando se integra en los procesos habituales de mantenimiento. Registrar cada copia en la herramienta de gestión de mantenimiento —con robot, fecha, operador y motivo— permite rastrear el historial y detectar si algún equipo lleva semanas sin actualizarse. Del mismo modo, incluir la verificación del último backup en la hoja de cambio de turno garantiza que esta información no se pierde entre relevos.
Para los equipos que gestionan flotas de robots ABB, KUKA o FANUC, nuestro servicio de mantenimiento preventivo incluye la verificación y actualización sistemática de las copias de seguridad como parte de cada intervención planificada.
Conclusión
El backup de programas de robot es una de las pocas medidas preventivas que no requiere inversión en hardware, no para producción y puede evitar paradas de días en el peor escenario posible. El coste de no tenerlo bien gestionado se mide en horas de reconfiguración, en producción perdida y, en ocasiones, en tener que reconstruir desde cero un programa que costó semanas de ajuste. Dedicar tiempo a estructurar este proceso hoy es, con diferencia, la acción de mantenimiento con mejor retorno posible.