La risposta breve: la produzione può fermarsi per un'utility che viene meno — aria compressa, refrigerazione, energia, acqua di processo — e non solo per un guasto informatico, eppure queste dipendenze fisiche raramente hanno un proprietario chiaro nella mappa dei rischi aziendali. Sorvegliarle significa mapparle, raccogliere i segnali che già esistono e stabilire chi risponde quando un allarme fisico diventa un problema che coinvolge anche i sistemi informatici.
La produzione dipende da più dei server
Quando si parla di continuità operativa, l'attenzione va quasi sempre ai sistemi informatici (IT): server, gestionale, rete. Ma uno stabilimento regge su servizi fisici che nessuno considera «informatici» finché funzionano. Alcuni esempi tipici:
- Aria compressa: alimenta attuatori, valvole pneumatiche, utensili e sistemi di verniciatura. Un compressore fermo può bloccare più linee insieme.
- Freddo: celle frigorifere, refrigerazione di processo, climatizzazione dei locali tecnici. Uno scostamento di temperatura può compromettere materie prime, prodotti finiti o le stesse apparecchiature elettroniche.
- Energia: non solo la presenza della fornitura, ma la sua qualità: buchi di tensione e squilibri possono far intervenire le protezioni delle macchine.
- Acqua e vapore: circuiti di raffreddamento, acqua di processo, trattamento delle acque reflue dove presente.
La guida NIST SP 800-82 revisione 3 colloca nel perimetro della tecnologia operativa (OT) anche l'automazione degli edifici e il monitoraggio dell'ambiente fisico, e pone affidabilità e sicurezza fisica tra i requisiti che distinguono l'OT dall'IT. Tradotto: questi sistemi di servizio non sono un dettaglio accessorio, ma parte del perimetro da conoscere e proteggere.
Mappare utility e sistemi di servizio
Il primo passo è un elenco onesto, costruito con chi lavora in stabilimento, non solo con chi gestisce l'IT. Per ogni utility conviene annotare:
- Cosa alimenta: quali linee, macchine o locali dipendono da quel servizio.
- Cosa succede se viene meno: fermo immediato, degradazione graduale, rischio per il prodotto o per le persone.
- Chi è il proprietario: manutenzione, facility, produzione o un fornitore esterno.
- Quali segnali esistono già: allarmi dei quadri elettrici, contatori, sonde di temperatura o pressione, supervisioni dei singoli impianti.
Questa mappa si incrocia con l'inventario dei dispositivi di rete e OT: i compressori e i gruppi frigo moderni sono spesso connessi, e un dispositivo dimenticato è sia un rischio di continuità sia un possibile punto di ingresso. Ne parliamo in come costruire un inventario OT senza scansioni intrusive. Attenzione a non confondere i due piani: la mancata lettura di un sensore può segnalare un problema fisico, un guasto del sensore o un'anomalia di rete, come distinguiamo in anomalie dei sensori IoT in produzione.
Sensori e segnali dalle dipendenze fisiche
La buona notizia è che spesso non serve installare nulla di nuovo: quadri elettrici, gruppi frigo e compressori recenti dispongono già di allarmi, contatori o uscite dati. Il lavoro utile è raccogliere questi segnali esistenti in un punto unico di osservazione, nel rispetto di due cautele.
La prima: la copertura dipende dalle integrazioni possibili sul singolo ambiente. Non esiste un monitoraggio universale che «vede tutto» da solo; ogni fonte va concordata, autorizzata e verificata. La seconda: un segnale raccolto non è ancora una risposta. Sapere che la pressione dell'aria è scesa serve solo se qualcuno sa cosa fare, entro quanto e con quali alternative. Per le anomalie che riguardano le macchine di linea, il tema è sviluppato in il monitoraggio passivo in officina.
Coordinare la risposta tra reparti
Le dipendenze fisiche vivono in un confine organizzativo scomodo: il compressore è della manutenzione, il supervisore che lo segnala è dell'IT o dell'automazione, il fermo lo subisce la produzione. Quando un allarme fisico richiede anche una risposta informatica — per esempio isolare un dispositivo, avvisare un fornitore, riconfigurare un servizio — serve una catena chiara: chi riceve il segnale, chi valuta l'impatto produttivo, chi autorizza gli interventi e chi registra cosa è stato deciso. È lo stesso schema che serve in emergenza, descritto in come preparare un runbook di emergenza per lo stabilimento.
Tre domande aiutano a verificare se la catena esiste davvero: un allarme del gruppo frigo arriva a qualcuno fuori dall'orario di turno? Chi può decidere di fermare una linea per salvare il prodotto in cella? E chi ricostruisce, il giorno dopo, la sequenza degli eventi e delle decisioni?
Esempio illustrativo: il sabato del compressore
Esempio illustrativo. Lo scenario seguente è inventato e non descrive un caso reale.
Uno stabilimento di verniciatura lavora anche il sabato, con personale ridotto. Un compressore principale va in allarme per temperatura e si arresta; il gruppo di emergenza mantiene la pressione solo per alcune utenze. Nel locale compressori un modulo di segnalazione segnala l'evento, ma lo storico avvisi arriva solo alla manutenzione, che il sabato non è presente. La linea di verniciatura rallenta, poi si ferma; nessuno sa dire se è un problema meccanico, elettrico o di rete.
Con una mappa delle dipendenze e i segnali raccolti in un punto unico, lo stesso evento avrebbe un percorso diverso: l'allarme raggiunge il responsabile reperibile con il contesto — quale compressore, quali linee alimenta, quanto autonomia resta nel gruppo di emergenza — e le opzioni possibili, dalla riduzione delle utenze al fermo coordinato. La decisione resta a una persona; ciò che cambia è che decide con le informazioni necessarie, invece di scoprire il fermo a linea già bloccata.
Il contributo di OverZeus
Nella configurazione OverZeus per fabbriche e laboratori, tre agenti sono pertinenti su questo tema, sempre entro le fonti e le integrazioni concordate per il singolo progetto:
- Hephaestus porta contesto a macchine, sensori e dispositivi connessi: stato, anomalie e automazioni entro confini operativi definiti. Aiuta a leggere un allarme fisico insieme al ruolo della macchina e alle sue dipendenze.
- Argus osserva eventi, servizi, rete e dispositivi collegati, evidenziando anomalie e scostamenti dalla situazione attesa, comprese le tendenze lente che anticipano un problema.
- Odysseus collega gli indizi, coinvolge i moduli giusti e riunisce analisi e proposte in un piano comprensibile: è il coordinamento che serve quando un segnale fisico tocca più reparti.
Le decisioni restano ai responsabili: gli agenti presentano proposte e conseguenze, e un intervento attivo richiede l'approvazione prevista; il silenzio non autorizza. Le funzioni di sicurezza e il controllo di processo restano affidati ai sistemi dell'impianto e ai responsabili tecnici.
Le tre domande, in sintesi
Quali utility fermano la produzione se vengono meno?
Dipende dallo stabilimento, ma le candidate abituali sono aria compressa, refrigerazione e freddo di processo, energia e sua qualità, acqua e vapore. La risposta giusta si costruisce mappando, per ciascuna, cosa alimenta e cosa succede se manca.
Chi sorveglia i sistemi di servizio dello stabilimento?
Spesso nessuno in modo coordinato: ogni impianto ha i suoi allarmi locali e il suo proprietario tecnico. La sorveglianza migliora raccogliendo i segnali esistenti in un punto di osservazione comune, con un proprietario chiaro per ogni dipendenza.
Come si collega un allarme fisico a una risposta informatica?
Definendo in anticipo la catena: chi riceve il segnale, chi valuta l'impatto sulla produzione, chi autorizza le eventuali azioni sui sistemi e chi registra decisioni ed esiti. Senza questa catena, l'allarme resta un rumore in un quadro elettrico.
Dalla mappa alla risposta
Le dipendenze fisiche non diventano meno fragili perché le osserviamo; diventano meno sorprendenti. Una mappa condivisa, i segnali che già esistono raccolti con cautela e una catena di risposta tra reparti sono interventi organizzativi prima che tecnologici — ed è per questo che spesso vengono rimandati. Vale la pena farli quando tutto funziona.
Descrivi impianti, sensori e vincoli produttivi per definire il perimetro di una demo.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.