In fabbrica la rete cade spesso. Una volta è rimasta giù per diversi giorni: un cantiere aveva danneggiato la fibra in strada. Lo stabilimento era tagliato fuori dal gestionale in cloud, da cui arrivano gli ordini.
La produzione non si è fermata. Il buffer ha retto senza problemi. E per le interruzioni lunghe era già prevista una modalità manuale: gli ordini e le altre informazioni che non potevano arrivare dal gestionale si inserivano a mano, in locale. Quando la fibra è tornata, i dati sono ripartiti verso il cloud.
Non è stata fortuna. Era stato deciso prima.
Quando progetto un middleware industriale parto da un presupposto: la rete cadrà, e prima o poi un servizio esterno non risponderà. Non è un'eccezione da gestire, è uno stato normale del sistema. Va progettato come gli altri, decidendo tre cose: cosa continua, cosa si ferma e come si rimettono in ordine i dati quando la rete torna.
01Cosa continua, cosa si ferma
Continua
In locale, senza rete
- L'acquisizione dai PLC.
- Le logiche che non hanno bisogno di informazioni esterne.
- La registrazione degli eventi, nel buffer.
- Il lavoro manuale previsto per le interruzioni lunghe.
Si ferma, dichiarandolo
Quello che dipende da altri
- Un nuovo ordine dal gestionale.
- Una rischedulazione.
- Le conferme che solo un sistema esterno può dare.
Se aspetto un nuovo ordine o una rischedulazione dal sistema centrale, non posso inventarmeli. In quel caso il sistema deve dire che l'operazione non è disponibile, oppure passare la decisione a una persona, come nei giorni senza fibra. La cosa peggiore è un sistema che sembra funzionare quando non può.
02Il buffer non dura per sempre
Il buffer lo dimensiono su tre cose: quanto a lungo il sistema deve poter lavorare senza connessione, quanti dati genera in quel tempo e quanto spazio c'è davvero sull'edge.
Poi decido cosa succede quando si riempie, perché non posso scrivere fino a esaurire il disco. A seconda del dato posso ridurre la frequenza di acquisizione, scartare i campioni meno importanti, o smettere di accettare operazioni che richiedono una registrazione affidabile.
Un buffer che promette di durare all'infinito è una promessa falsa.
03Non tutti i dati valgono uguale
Telemetria
Per una temperatura letta ogni secondo può bastare l'ultimo valore, o una frequenza ridotta durante un'interruzione lunga.
Pezzi, scarti, eventi
Coda persistente, integrale: sono i dati che servono alla tracciabilità e al conteggio.
Eventi critici
Una politica di conservazione esplicita, e un segnale quando non posso più garantirla.
Non è una scelta tecnica. È una decisione sui requisiti del processo: prima si stabilisce cosa si può perdere, aggregare o recuperare e cosa va conservato. Poi si scrive il codice.
04Quando la rete torna
Reinviare i messaggi accumulati non basta. Ogni evento deve avere un identificativo univoco e il momento in cui è nato.
Duplicati. Con MQTT a QoS 1 la consegna è garantita «almeno una volta» (OASIS, MQTT 5.0): lo stesso messaggio può arrivare due volte. Chi riceve deve riconoscere gli eventi già elaborati, con l'identificativo e un registro persistente di ciò che ha già processato. Altrimenti un pezzo prodotto viene contato due volte.
Tempi. Distinguo tre momenti, e con tutti e tre si ricostruisce cosa è successo durante l'interruzione.
Tre timestamp per ogni evento
- quando la macchina l'ha prodotto
- quando il middleware l'ha messo nel buffer
- quando il sistema centrale l'ha elaborato
Ordine. L'ordine di arrivo non è sempre quello reale. Per un evento di produzione devo poter ricostruire la sequenza. Per una misura aggiornata spesso conta di più sapere qual è il valore più recente e attendibile.
05Chi vince, il locale o il cloud?
Non c'è una regola unica. Dipende dal dato e da chi ne è responsabile. Lo stato di una macchina si decide in locale; un ordine di produzione può appartenere al sistema centrale.
Per questo separo i dati che si possono aggiornare in locale da quelli che richiedono un'autorizzazione o una conferma esterna. Al ritorno della rete il sistema riconcilia secondo queste regole. Un'informazione non vince solo perché è arrivata per ultima.
06Cosa vede l'operatore
L'operatore non deve trovarsi davanti a uno schermo che mostra dati vecchi come se fossero attuali. L'interfaccia deve mostrare lo stato della connessione e distinguere i dati aggiornati da quelli che non arrivano più. Se un'operazione non è disponibile, deve dirlo.
Se si possa lavorare a mano dipende dal processo e dalle procedure dello stabilimento. A volte si continua a produrre e si registra in locale, per recuperare dopo. Altre volte certe operazioni vanno sospese, perché mancano informazioni o autorizzazioni.
07L'errore più comune
Un sistema che sembra offline-first ma dipende ancora da servizi esterni per le operazioni fondamentali. L'acquisizione dai PLC continua, ma alla prima chiamata a un servizio irraggiungibile il worker si blocca. Oppure un errore ferma anche i messaggi che di quel servizio non avevano bisogno.
Prima del rilascio
Le quattro prove che faccio in collaudo
- Il backend o il broker che non rispondono.
- La rete che cade e torna.
- Un'interruzione lunga, fino a riempire il buffer.
- Un riavvio dell'edge con dati ancora da inviare.
Il test non è «si riconnette». È «dopo il ripristino i dati e lo stato applicativo sono ancora coerenti, senza duplicati». Prevedere la riconnessione è la parte facile; il lavoro vero è progettare come si comporta tutto il sistema mentre la rete non c'è.
