Chiedere "fate backup?" in un impianto con PLC Siemens di solito produce una risposta affermativa. Ma la domanda giusta è un'altra: se domani mattina il server SCADA, la engineering station e due CPU S7-1500 fossero inutilizzabili, sareste in grado di ricostruire tutto e ripartire? E in quanto tempo?
Nella pratica, la distanza tra "avere un backup" e "poter ripristinare un impianto" è enorme. In mezzo ci sono progetti TIA Portal incompleti, configurazioni di rete perse, parametrizzazioni drive mai esportate, licenze non documentate, firmware non archiviati e procedure di ripristino mai testate. Questo articolo affronta il tema in modo concreto, concentrandosi sugli ambienti Siemens perché sono tra i più diffusi nell'industria europea, ma molti principi valgono anche per altri vendor.
Perché il backup OT non è come il backup IT
In ambito IT, il backup è un problema relativamente ben definito: database, file system, configurazioni server, immagini VM. Esistono tool consolidati, policy standard e procedure collaudate. In OT la situazione è diversa per almeno tre motivi.
Primo: gli asset da salvare sono eterogenei. Un impianto Siemens tipico include CPU S7-1500 o S7-1200, pannelli HMI Comfort o Unified, switch SCALANCE, server WinCC, eventualmente un historian, drive SINAMICS, safety program, configurazioni ProfiNET, configurazioni di rete e routing. Ogni componente ha il suo formato, il suo metodo di esportazione e le sue dipendenze.
Secondo: il backup del progetto TIA Portal non è il backup dell'impianto. Un file .ap17 o .ap19 contiene il progetto di engineering, ma non necessariamente riflette lo stato reale della CPU in produzione. Se qualcuno ha fatto un download diretto senza aggiornare il progetto offline, il file archiviato è già disallineato.
Terzo: il ripristino non è trasparente. Ripristinare un PLC Siemens non è come fare il restore di una VM. Servono la versione corretta di TIA Portal, le licenze attive, la stessa versione firmware della CPU (o una compatibile), eventuali GSD file per device ProfiNET di terze parti, e spesso la presenza fisica o remota di qualcuno che sappia riconfigurare gli indirizzi e i parametri di rete.
Cosa salvare: la lista che manca quasi sempre
La maggior parte degli impianti salva solo il progetto TIA Portal e, nei casi migliori, un'immagine del server SCADA. Serve molto di più.
Progetti PLC completi e allineati
Il progetto TIA Portal deve essere completo di tutte le stazioni configurate, aggiornato rispetto a quanto gira in produzione e salvato in un formato che consenta il ripristino. La funzione "Go online" di TIA Portal permette di confrontare il progetto offline con il contenuto della CPU: è uno strumento utile per verificare l'allineamento, anche se ha dei limiti su blocchi protetti e su alcune configurazioni hardware.
Per ogni CPU vanno archiviate:
- il progetto TIA Portal nella versione corretta (incluso l'Update che era installato)
- l'archivio completo della stazione hardware (configurazione rack, indirizzi, parametri di comunicazione)
- i blocchi sorgente, le librerie usate e le eventuali librerie custom
- la documentazione dei blocchi protetti con know-how protection, se presenti
Se nell'impianto ci sono blocchi con know-how protection inseriti da un OEM o da un integratore, il backup del progetto potrebbe non essere sufficiente per una ricostruzione completa. Serve chiarire contrattualmente chi detiene le sorgenti e come vengono rese disponibili in caso di emergenza. Senza questo accordo, un blocco protetto perso è un blocco perso.
Programmi safety
Negli impianti con CPU F (S7-1516F, S7-1518F, ET 200SP F-CPU, ecc.) il programma safety ha requisiti specifici. Le modifiche ai blocchi F-call richiedono la riaccettazione del programma safety con password, e il ripristino deve essere coerente con la configurazione hardware F-I/O. Un backup safety incompleto o disallineato può significare dover rifare la validazione, il che in molti contesti comporta fermi significativi e coinvolgimento di personale qualificato.
Pannelli HMI
Ogni pannello HMI (Comfort Panel, Unified Comfort Panel, Basic Panel) ha il suo runtime caricato. I pannelli Comfort Panel salvano il progetto runtime nella memoria interna, ma se il pannello viene sostituito fisicamente, serve il progetto WinCC (Unified o Classic) per rigenerare il runtime e scaricarlo. Anche qui, il progetto deve essere allineato con ciò che è effettivamente in uso.
Per i Comfort Panel è possibile eseguire un backup del runtime dal pannello stesso (tramite il menu di servizio o dal Control Panel di WinCC Runtime), che include la configurazione, le ricette e gli user definiti localmente. Questa copia è utile per un ripristino rapido sullo stesso modello di pannello, ma non sostituisce il progetto sorgente.
Configurazione di rete
In un impianto Siemens la rete ProfiNET è parte integrante del progetto TIA Portal, ma ci sono elementi che vivono fuori dal progetto:
- configurazione degli switch SCALANCE (VLAN, port security, ridondanza MRP/HRP, SNMP, syslog)
- configurazione di eventuali router o firewall industriali SCALANCE S o SINEMA
- tabelle di routing, regole NAT e assegnazione indirizzi IP se gestiti manualmente
- configurazione di SINEMA Remote Connect o altri server per accesso remoto
Gli switch SCALANCE gestiti possono essere configurati via web interface, CLI o tramite SINEC NMS. In ogni caso, la configurazione va esportata e archiviata. Un reset di fabbrica di uno switch managed senza backup della configurazione può interrompere la comunicazione ProfiNET di un'intera cella.
Drive e parametrizzazioni
I drive SINAMICS (S120, G120, S210) hanno parametri che influenzano direttamente il comportamento meccanico dell'impianto: rampe, limiti di coppia, anelli di regolazione, dati encoder, configurazione dei telegrammi PROFIdrive. Questi parametri vengono impostati durante il commissioning e spesso modificati durante l'ottimizzazione in produzione.
Il backup dei parametri drive si può fare tramite TIA Portal (se il drive è integrato nel progetto come stazione), tramite STARTER/SCOUT per le versioni precedenti, oppure tramite la card di memoria del drive stesso. Il metodo dipende dalla configurazione. Il punto critico è che molti impianti non archiviano mai i parametri drive dopo il commissioning, e quando un drive si guasta il sostituto parte con parametri di fabbrica.
Server SCADA e Historian
Un server WinCC (Professional, Unified o WinCC OA) è un sistema complesso: progetto runtime, configurazione database, tag, trend, script, utenti, certificati. Il backup deve includere:
- il progetto WinCC sorgente (nel formato TIA Portal o standalone, a seconda della versione)
- il backup del database runtime (archivi storici, allarmi, trend)
- la configurazione del sistema operativo, patch, servizi e permessi
- eventuali connettori OPC, script VBS/C, configurazioni di reporting
Per WinCC Unified, il runtime gira su un'architettura diversa da WinCC Professional classico, con un application server basato su Node.js e un database PostgreSQL. Il metodo di backup cambia di conseguenza.
Engineering station
La postazione di engineering è spesso l'asset più sottovalutato. Contiene TIA Portal con la versione specifica e tutti gli Update installati, le licenze (gestite tramite Automation License Manager), i GSD file per device di terze parti, le librerie custom, i template, eventuali Add-in e la configurazione di rete per raggiungere i dispositivi. Perdere la engineering station senza un piano di ricostruzione significa non poter intervenire sull'impianto nemmeno per una modifica banale.
1. Progetto TIA Portal completo e allineato alla produzione
2. Programmi safety con documentazione di validazione
3. Backup runtime HMI e progetto sorgente pannelli
4. Configurazione switch SCALANCE e apparati di rete
5. Parametri drive (SINAMICS, MICROMASTER, ecc.)
6. Progetto e database server SCADA/Historian
7. Immagine o procedura di ricostruzione engineering station
8. Licenze, versioni firmware, GSD file, librerie
9. Documentazione di rete (IP, VLAN, routing, regole firewall)
10. Credenziali e certificati (in modo sicuro e controllato)
Dove e come conservare i backup
Archiviare tutto su un NAS nella stessa rete OT non è un piano di disaster recovery: è un singolo punto di guasto in più. I backup OT devono seguire almeno alcuni criteri di base.
Separazione fisica o logica
Almeno una copia deve essere fuori dalla rete OT. Può essere un server in rete IT con accesso controllato, un supporto offline (disco USB cifrato, conservato in luogo sicuro), o un repository in un segmento dedicato. La copia offline è particolarmente importante in scenari di ransomware o compromissione estesa della rete.
Versionamento
Il backup deve essere versionato, non solo sovrascrivibile. Se l'ultimo backup è stato fatto dopo una modifica errata, servire solo l'ultima copia non aiuta. Meglio mantenere almeno le ultime N versioni con data, autore della modifica e note di rilascio. Alcuni impianti usano Git per i sorgenti TIA Portal esportati in formato XML (con la funzione di export del progetto), ma la soluzione può variare in base al contesto e alla complessità del progetto.
Periodicità e trigger
Il backup non deve essere solo periodico. Deve scattare anche a ogni modifica significativa: dopo un commissioning, dopo un intervento di manutenzione, dopo un aggiornamento firmware, dopo una modifica al programma PLC o alla configurazione di rete. In molti impianti il problema non è la frequenza del backup automatico, ma il fatto che le modifiche manuali non vengono mai archiviate.
Integrità e verifica
Un backup che non si apre, che si riferisce a una versione di TIA Portal non più installata, o che contiene un progetto incompleto non è un backup: è un falso senso di sicurezza. La verifica periodica dei backup è una misura semplice che quasi nessuno fa. Basta aprire il progetto sulla engineering station, verificare che si compili, e confrontare la versione con quella in produzione.
Disaster recovery OT: non basta il backup
Il backup è una condizione necessaria ma non sufficiente. Il disaster recovery è la capacità di ripristinare l'operatività dell'impianto entro tempi accettabili, e richiede molto più di un file salvato.
Procedure documentate
Ogni scenario critico deve avere una procedura di ripristino scritta, che includa:
- quali asset sono coinvolti e in che ordine vanno ripristinati
- quali tool, versioni software e licenze servono
- chi è autorizzato e competente per eseguire il ripristino
- quali dipendenze ci sono (ad esempio: prima la rete, poi il PLC, poi l'HMI, poi lo SCADA)
- quali verifiche fare dopo il ripristino prima di rimettere in produzione
Senza questa documentazione, anche con un backup perfetto il ripristino dipende interamente dalla disponibilità e dalla memoria di chi conosce l'impianto. In un fermo non pianificato, con pressione e urgenza, non è una strategia affidabile.
Tempi di ripristino realistici
Il tempo di ripristino di un PLC S7-1500 con un progetto TIA Portal pronto è relativamente breve: download del programma, verifica, rimessa in RUN. Ma se il PLC è parte di una cella con safety, ProfiNET con device di terze parti, e comunicazione con un server SCADA, il ripristino della singola CPU non basta. Serve rimettere in piedi l'intera catena funzionale, e questo richiede tempo, competenze e accesso ai tool corretti.
Per uno SCADA server WinCC, il ripristino può richiedere ore o giorni, a seconda che si parta da un'immagine disco, da un progetto sorgente o da zero. Se il server originale era un sistema con anni di personalizzazioni, script, connettori e configurazioni accumulate, ricostruirlo senza documentazione è un progetto a sé.
Ricambi e spare
Il disaster recovery non è solo software. Se una CPU S7-1500 si guasta e non c'è un ricambio a magazzino, il backup è inutile fino all'arrivo del componente. Lo stesso vale per pannelli HMI, switch SCALANCE, alimentatori e schede I/O. Una politica di spare parts coerente con i tempi di ripristino accettabili è parte integrante del piano.
Per le CPU S7-1500, la SIMATIC Memory Card contiene il programma e la configurazione: se la CPU si guasta ma la card è integra, il ripristino su una CPU identica sostitutiva è veloce. Ma se anche la card è persa o corrotta, serve il progetto TIA Portal completo. Per le CPU S7-300 e S7-400 ancora in servizio, la MMC o la Micro Memory Card hanno la stessa funzione, ma con vincoli diversi sulla compatibilità firmware.
Test di ripristino
Un piano di disaster recovery non testato è un documento, non un piano. Testare il ripristino significa provare almeno uno scenario critico in condizioni realistiche: ricostruire una stazione PLC da backup, ricaricare un pannello HMI, riportare online un server SCADA, verificare che le comunicazioni ProfiNET riprendano. Non serve testare tutto ogni mese, ma non aver mai testato nulla è un rischio che molti impianti corrono senza rendersene conto.
La engineering station principale si guasta. TIA Portal era installato con una versione specifica più tre Update. Le licenze erano su quella macchina. I GSD file erano stati importati manualmente da vari fornitori. Le librerie custom non erano archiviate separatamente. Risultato: anche con il progetto PLC salvato, ci vogliono giorni per ricostruire un ambiente funzionante. Nel frattempo, nessuno può intervenire sull'impianto.
Gli errori più comuni
Dopo anni di lavoro su impianti esistenti, alcuni pattern si ripetono con regolarità.
Backup del progetto ma non dello stato reale
Il progetto TIA Portal viene salvato, ma nessuno verifica se corrisponde a ciò che gira nella CPU. Le modifiche online, le forzature, i valori di inizializzazione cambiati a caldo e le configurazioni hardware modificate durante la messa in servizio creano uno scostamento che può rendere il backup inutilizzabile per un ripristino pulito.
Nessun backup della rete
La configurazione degli switch managed, le VLAN, le regole di port security, il MRP ring, le tabelle di routing: tutto questo vive fuori dal progetto PLC e quasi mai viene archiviato. In caso di sostituzione di uno switch SCALANCE, senza backup della configurazione si deve rifare tutto a mano, spesso senza documentazione aggiornata.
Licenze non documentate
Le licenze TIA Portal, WinCC, STEP 7 Safety e gli Add-in hanno chiavi legate alla macchina (tramite Automation License Manager) o al portale Siemens (License Keys). Se la engineering station è persa e le licenze non sono documentate, il ripristino del software di engineering si blocca su un problema amministrativo prima ancora che tecnico.
Backup su supporto unico nella stessa rete
Un backup su NAS nella rete OT protegge dal guasto di un singolo componente, ma non da un ransomware che cifra tutto il segmento, da un errore di configurazione che rende il NAS irraggiungibile, o da un evento fisico che coinvolge l'intero quadro o sala server.
Nessun test di ripristino
L'errore più diffuso e il più pericoloso. Molti impianti scoprono che il backup non funziona, è incompleto o si riferisce a una versione diversa solo quando ne hanno bisogno. A quel punto è tardi.
Un approccio graduale e sostenibile
Non tutti gli impianti possono implementare una strategia di backup e disaster recovery completa in una volta. Un percorso realistico parte dal censimento di ciò che si ha, passa per la definizione delle priorità e arriva a un processo mantenibile nel tempo.
Questo percorso non richiede investimenti straordinari. Richiede disciplina, tempo dedicato e la consapevolezza che il backup OT è un processo continuo, non un'attività una tantum.
Il legame con la NIS2 e la continuità operativa
La direttiva NIS2 include esplicitamente la continuità operativa, il backup management e il disaster recovery tra le misure richieste. Per le aziende industriali rientranti nel perimetro, questo significa che la capacità di ripristino dell'impianto non è più solo una questione tecnica: è un requisito di governance.
Non serve però affrontare il tema come un esercizio di compliance. Un impianto che ha backup completi, procedure documentate e un piano di ripristino testato è un impianto più resiliente indipendentemente dalla normativa. La NIS2 in questo caso non aggiunge obblighi artificiali: formalizza ciò che dovrebbe già essere buona pratica operativa.
Considerazioni finali
Il backup OT in un impianto Siemens non si riduce a un file archiviato. È un insieme di elementi — progetti, configurazioni, parametri, licenze, firmware, procedure, competenze — che devono essere coerenti tra loro e con lo stato reale dell'impianto. Il disaster recovery è la capacità di rimettere insieme questi elementi in tempi accettabili, e questa capacità si costruisce prima dell'emergenza, non durante.
La domanda da porsi non è "abbiamo un backup?", ma "se domani l'impianto fosse da ricostruire, sapremmo da dove partire, con cosa, in quanto tempo e chi lo farebbe?"
Serve una valutazione dello stato dei backup e del piano di disaster recovery del tuo impianto?
Contattaci per un assessment tecnico — verifichiamo cosa c'è, cosa manca e come strutturare un percorso di miglioramento sostenibile.
Risorse ufficiali e guide utili
- Siemens — SIMATIC S7-1500: Backup and Restore (FAQ)
- Siemens — TIA Portal: progetto e gestione delle versioni
- Siemens — SCALANCE: backup e ripristino della configurazione
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security
- ISA/IEC 62443 — Industrial Automation and Control Systems Security