Una cel·la robotitzada aturada perquè ningú va fer una còpia de seguretat abans de canviar el controlador. Un programa de soldadura sobreescrit per error que va trigar dues jornades a reconstruir-se. Són situacions reals que es produeixen amb més freqüència de la que hauria a plantes industrials de tota la regió. Tanmateix, implementar un procés de backup sòlid és una de les tasques de gestió més senzilles i econòmiques que existeixen.
Què conté realment un backup complet
L'error més habitual és confondre «tinc el programa desat» amb «tinc un backup complet». Un fitxer de programa per si sol no és suficient per restaurar un robot al 100 % després d'una fallada greu. Un backup complet ha d'incloure, com a mínim:
- Programes de moviment i rutines de procés, incloent-hi tots els mòduls i subrutines auxiliars.
- Dades del sistema: configuració d'eines (tool data), dades de peça (work object / frame data), variables persistents i dades de càrrega útil.
- Paràmetres del controlador: configuració d'eixos, límits de software, paràmetres de comunicació i opcions de software activades.
- Dades de seguretat: configuració de zones segures, enclavaments i paràmetres del mòdul de seguretat quan la cel·la en disposa.
- Dades de calibratge i mastering: els valors que defineixen la posició zero de cada eix. Sense ells, restaurar el programa no serveix de res si el robot no torna a moure's per les posicions correctes.
Cada fabricant agrupa aquests elements de manera diferent i utilitza la seva pròpia terminologia, però el concepte és el mateix en ABB, KUKA i FANUC: un backup parcial és millor que res, però pot ser insuficient en una situació d'emergència real.
Quan fer el backup: freqüència i esdeveniments disparadors
Definir una freqüència fixa (per exemple, setmanal o mensual) és un bon punt de partida, però no n'hi ha prou per si sol. Hi ha esdeveniments que obliguen a fer una còpia de seguretat immediata independentment del calendari:
- Abans i després de qualsevol modificació del programa, encara que sigui puntual.
- Abans d'una actualització de firmware o de software del controlador.
- Abans de substituir qualsevol component del controlador (mòdul d'accionament, placa principal, disc de sistema).
- Abans d'una aturada de vacances o de producció prolongada.
- Després de completar una posada a punt o un ajust de calibratge.
- Després de la validació d'un nou programa en producció.
Un backup realitzat just abans d'una intervenció és també la millor evidència d'auditoria si alguna cosa va malament durant el treball.
On emmagatzemar les còpies i durant quant de temps
El suport d'emmagatzematge importa. Un USB oblidat al calaix de l'armari de control no és una política de backup. Les bones pràctiques recomanen una estratègia en tres nivells:
- Còpia local al propi controlador o en un suport a l'armari (quan el controlador ho permet), accessible de manera immediata en cas de restauració urgent.
- Còpia en servidor de xarxa de planta (NAS o servidor de fitxers), amb accés controlat i organitzada per robot, data i versió.
- Còpia fora de planta o al núvol, que protegeix davant d'incendis, inundacions o altres esdeveniments que afectin les instal·lacions físiques.
Quant a la retenció, mantenir almenys les últimes tres o quatre versions de cada programa permet retrocedir a una versió anterior si es detecta un problema que no era visible en el moment de la modificació. Per a processos crítics, convé guardar també la versió validada en producció de manera indefinida.
Com validar que el backup és restaurable
Una còpia de seguretat que mai s'ha provat no és una còpia de seguretat: és una esperança. El procés de validació no ha de ser complex, però sí periòdic:
- Verificar que els fitxers s'han generat correctament i que no estan corromputs.
- Documentar a la GMAO la data, l'operari que va fer la còpia i la versió del programa.
- Almenys una vegada a l'any, realitzar una restauració completa en un entorn controlat o en una finestra de manteniment planificada, i verificar que el robot recupera les seves posicions de referència sense desviació.
Aquest darrer punt és especialment important si el pla de contingència inclou la substitució del controlador. Podeu llegir-ne més al nostre article sobre substitució del controlador d'un robot obsolet.
Errors habituals que converteixen el backup en una trampa
- Desar només el programa principal i ignorar els mòduls de sistema, les dades d'eina o els fitxers de configuració de seguretat.
- No versionar: sobreescriure sempre el mateix fitxer impedeix retrocedir a una versió anterior.
- Backups sense etiquetar: carpetes sense data ni descripció són inútils sota pressió.
- No incloure les dades de mastering: restaurar el programa sense les dades de calibratge obliga a repetir el procés de mastering complet.
- Accés no controlat: si qualsevol operari pot sobreescriure la còpia «oficial», la política de backup no té cap valor.
Integració amb la GMAO i el canvi de torn
La gestió de backups guanya consistència quan s'integra en els processos habituals de manteniment. Registrar cada còpia a la GMAO —amb robot, data, operari i motiu— permet rastrejar l'historial i detectar si algun equip fa setmanes que no s'actualitza. El nostre servei de manteniment preventiu inclou la verificació i actualització sistemàtica de les còpies de seguretat com a part de cada intervenció planificada.
Conclusió
El backup de programes de robot és una de les poques mesures preventives que no requereix inversió en maquinari, no atura la producció i pot evitar aturades de dies en el pitjor escenari possible. Dedicar temps a estructurar aquest procés avui és, amb diferència, l'acció de manteniment amb millor retorn possible.