Nell’industria 4.0 le aziende trarranno i maggiori benefici dalla possibilità di sfruttare l’on-line (internet, cloud computing…) per migliorare la propria offerta, tuttavia credo che non debbano dimenticare l’elemento fisico che le contraddistingue, cioè le linee di produzione, e quindi darsi una corretta architettura enterprise capace di mantenere la massima operatività anche off-line.

Abbiamo infatti già assistito a diversi casi di interruzione della produzione molto significativi, per cui è bene comprendere quali scenari ci apprestiamo ad affrontare.

Interruzione della produzione a causa di un virus

Già nell’industria tradizionale corriamo il rischio di un fermo di produzione a causa di un virus, tuttavia con l’industria 4.0 viene a mancare definitivamente l’air gap, cioè quella sicurezza indotta dal solo accesso fisico alle macchine, per cui la probabilità di questa situazione è decisamente aumentata.

Per contenere l’infezione potrebbe essere necessario staccare una o più macchine dalla rete, ma questo potrebbe non essere indolore. Vanno quindi previste le giuste procedure per riportare la situazione alla normalità. Sicuramente è un tema da affrontare insieme ai fornitori, ma è bene conoscere gli anelli deboli della propria catena produttiva.

Il caso stuxnet

L’esempio più eclatante di questo rischio è stata la scoperta di stuxnet nel 2010, un programma appositamente creato per danneggiare gli impianti nucleari e che cerca di ingannare i sensori industriali per ritardarne la scoperta da parte dello staff di controllo.

Interruzione della produzione a causa di una centralizzazione eccessiva

Se l’azienda ha più siti produttivi che utilizzano lo stesso software via internet da un singolo fornitore, allora esiste un single point of failure a cui si deve porre rimedio.

Il rimedio classico a questo tipo di problema è ridondare la risorsa, che in questo caso consiste in 3 aspetti strutturali:

• La connettività (il fornitore del servizio telefonico)
• L’ambiente di esecuzione del software (il service/cloud provider)
• Il software (il servizio realmente utilizzato all’interno del sito produttivo)

Avere una seconda linea telefonica, gestita da un secondo fornitore, è una pratica oramai molto comune, per cui assumo che tutte le industrie si allineeranno a questa linea guida.

Avere due o più data center o cloud provider è invece una pratica molto rara. Implica uno sforzo maggiore sia dal punto di vista gestionale che dal punto di vista tecnico. In particolare si devono partizionare i propri servizi per essere erogati e consumati da diversi provider e soprattutto, se un provider risulta inattivo deve esserci una procedura chiara e rapida per spostare i servizi su un secondo provider.

Infine, se il rilascio di un nuovo software risulta problematico, è necessario poter ripristinare la vecchia versione in tempi estremamente brevi. Anche in questo caso ci troviamo di fronte ad uno sforzo maggiore sia in termini gestionali che tecnici: test automatici, procedure di rilascio automatiche e procedure di recovery automatiche.

Inutile dire che limitare al massimo l’uso di sistemi centralizzati sarebbe una buona pratica per mantenere al minimo il problema del single point of failure. Non sempre sarà possibile e non sempre è la soluzione ideale, però un buon architetto enterprise deve prendere in considerazione anche questo scenario.

Di seguito alcuni esempi che spero possano essere utili per comprendere cosa intendo nella pratica.

Il caso poste italiane

Nel 2011 destò parecchia preoccupazione il blocco di 14.000 uffici postali a causa di un problema sul sistema centrale. Mi ricordo che in quello stesso periodo stavo lavorando a un sistema per la gestione delle filiali di una banca e il progettista del sistema precedente mi raccontava con orgoglio che la sua architettura prevedeva anche la possibilità di lavorare off-line. Magari non si riesce a erogare il 100% dei servizi, ma il danno è più contenuto.

Il caso TNT

Poche settimane fa, era su tutti i giornali il caso del blocco globale delle operazioni di TNT Express a causa di un virus. In azienda da me sono arrivati per un paio di settimane dei corrieri che sembravano tornati al 1950, foglietti per le consegne scritti a mano sulla base di una telefonata dal benzinaio e l’impossibilità di rintracciare i pacchi dei clienti per giorni, dispersi in chissà quale magazzino.

In un sistema fortemente integrato, dobbiamo pensare il processo affinché sia sempre considerata la possibilità che una parte del sistema sia corrotta o inagibile, per cui la nostra architettura deve prevedere un sistema di feedback incrociati e la possibilità di lavorare con alcune parti completamente disconnesse.

Il caso asiatico

Da poco ho iniziato a collaborare con un cliente con diverse sedi sparse per il mondo.

Uno dei fattori del suo successo è appunto la capacità di lavorare off-line, perché in molte zone del mondo le città sono fortemente connesse, mentre le periferie e le campagne non lo sono per niente.

Quindi ha realizzato un sistema che rende gli operatori capaci di lavorare un po’ ovunque off-line (finché c’è elettricità o finché reggono le batterie), poi quando ritorna connesso vi è uno scambio di informazioni tra il sistema centrale e quello mobile. In questo caso, non solo l’architettura tecnica ma anche i processi di business devono essere pensati per supportare questo scenario.

Conclusioni

Nelle grandi aziende è abbastanza naturale parlare di business continuity, o continuità operativa, ma in un sistema fortemente connesso e distribuito è facile perdere la capacità di fare un’analisi dei rischi ed è qui che l’Enterprise Architecture può fornire un aiuto fondamentale.

Studiare il sistema perché sia strutturalmente resistente al fallimento di uno o più delle sue componenti, avere dei processi automatici di notifica, avere dei processi decisionali rapidi ecc. sono tutti estremamente importanti. L’aspetto nuovo per l’industria 4.0 è rispondere alla seguente domanda: per quanto tempo posso rimanere off-line prima di avere un danno significativo all’azienda?