Uno dei requisiti per poter accedere all’iperammortamento del piano impresa 4.0 (2017 o 2018) è che sussista tra la macchina e la fabbrica una forma di interconnessione che utilizzi un collegamento basato su specifiche documentate, pubblicamente disponibili e internazionalmente riconosciute.
Ovvero?
Si sentono alcune interpretazioni abbastanza conservative in merito a questa definizione, dimenticando che lo scopo della norma è interconnettere le macchine ai sistemi informatici della fabbrica, non fornire una specifica tecnica su come farlo.
Il requisito va quindi letto nell’ottica di evitare di portare in fabbrica sistemi completamente proprietari che diventano difficili da interconnettere con altri sistemi di produttori differenti. Difficili o totalmente impossibili da interconnettere perché richiedono, ad esempio, una rete fisica non standard.
Le macchine non hanno obblighi da rispettare per quanto riguarda il cablaggio interno, ma devono fornire verso l’esterno delle modalità di accesso e scambio dati che siano aderenti alle richieste della norma. La macchina può quindi essere dotata di un semplice gateway che permetta questo scambio dati senza che l’utilizzatore debba interfacciarsi con componenti proprietari.
Possiamo pensare ad una macchina industriale come ad un normle computer: la maggior parte di noi non sa come sia fatto all’interno, ma è consapevole che se ha una porta ethernet lo può collegare alla rete, se ha una interfaccia WiFi lo può collegare alla rete wireless, se ha una porta HDMI lo può collegare ad un proiettore o ad un televisore.
In questo caso gli standard sono veramente molto forti ed in alcuni casi (HDMI) entrano pure nel dettaglio delle informazioni che transitano (audio e video), mentre in altri (ethernet) si occupano di come far transitare le informazioni lasciando poi ad altri la definizione di come sono fatte (email, web, …). Allo stesso modo, quando installo un software nel computer, ad esempio per leggere la posta elettronica, mi aspetto che questo sia in grado di utilizzare uno standard riconosciuto (tra quelli disponibili: POP3, IMAP, SMTP) con il quale comunicare con il fornitore del servizio di email.
In campo industriale dove le macchine non sono normali computer e spesso sono personalizzate, l’interfaccia verso l’esterno deve essere facile da integrare con altri sistemi. Ecco perché la norma chiede che siano utilizzati protocolli internazionalmente riconosciuti (anche de-facto).
Esistono molti protocolli industriali a più livelli, dalla interconnessioni fisiche, al trasporto dei dati alla sematica stessa dei dati. Per citarne uno dei più completi, l’OPC-UA copre tantissimi aspetti che partono dal singolo sensore, alla sicurezza delle comunicazioni ad arrivare a comprendere gli strumenti office che possono esserci in una azienda.
E’ però molto complesso e la sua adozione in una piccola realtà non è immediata anche se vale assolutamente lo sforzo toccarne i concetti per capire quanto sia ampia la portata della digitalizzazione di una azienda. Può essere l’occasione per un corso di formazione.
La richiesta di protocolli “riconosciuti” da parte della normativa ha aperto una discussione su quali siano leciti e quali non lo siano. Spesso questa discussione si è basata su un elenco di standard dedicati all’industria dimenticando che l’integrazione delle macchine nel sistema informativo della fabbrica le avvicina incredibilmente al mondo IT, dove i protocolli non sono quelli della comunicazione machine-to-machine ma quelli dello scambio di informazioni a livello più alto.
Cosa succede quando una macchina viene progettata per non essere più un elemento “semplice” che scambia informazioni “semplici”, ma essa stessa dotata di un computer con tutti gli strumenti classici del mondo IT (per fare esempi: server FTP, database, file system di rete, …).
Queste tipologie di macchine sono sempre più diffuse: non più un PLC con qualche registro da impostare, ma un vero e proprio server che sovrintende la macchina e può parlare direttamente con altri server e software del mondo IT. Non si agisce più, quindi, sulle componenti elettroniche e logiche proprie della macchina, ma con dei veri servizi IT che vengono esposti e che vanno a fare parte degli altri servizi della rete dell’azienda (posta, file condivisi, servizi intranet, …).
Tutto questo avviene perché è sempre di maggior uso sulla macchine di veri computer con veri sistemi operativi (Windows Embedded, Linux, …). Basta pensare a quanto la miniaturizzazione dei personal computer li abbia resi adatti ad applicazioni su macchine industriali (RaspBerry PI, LattePanda, …).
Con questo tipo di macchine non si comunica più con l’hardware ma con dei servizi: domandiamoci allora quali siano i protocolli ammessi dalla normativa.
Cominciamo con identificare che cosa siano questi servizi. Sicuramente non si parla di Profinet o Modbus, ma di webservice (WS, HTTP REST, …) o di database (SQLServer Embedded, MySQL, MariaDB, SQLite, …) o di file system condivisi (SAMBA, NFS). Tipicamente sono tutti erogati su TCP/IP, quindi almeno alla base hanno un protocollo citato nella normativa.
Questi strumenti, classici del mondo IT, si basano tutti su protocolli internazionalmente accettati, per il semplice fatto che nessuna azienda, da molti anni, si può permettere di affidare i propri dati e le proprie comunicazioni a sistemi che non siano interfacciabili. Proprio per la necessità di interoperabilità, nel mondo IT la maggior parte di questi strumenti è pubblicamente documentata, se si vuole implementare una interfaccia “da zero”, ma il vero vantaggio è che esistono librerie di libero utilizzo per tutti gli ambienti, spesso fornite proprio dalle case produttrici anche con i sorgenti.
Questa pratica è così consolidata, che spesso i produttori forniscono strumenti liberi di interfaccia verso i proprio servizi anche per piattaforme sviluppate dalla concorreza, perché nessuna azienda si doterebbe di una soluzione chiusa senza la possibilità di acquistare soluzioni software o hardware da differenti realtà.
Il caso pratico (reale)
Per condensare tutti questi ragionamenti, vediamo un caso pratico. Abbiamo in azienda una fresa per manufatti in legno di grandi dimensioni. Questa fresa riceve i CAM per le lavorazioni da effettuare dall’ufficio progettazione, che poi vengono “attivati” nella macchina da operati specializzati.
La macchina è dotata di un PC che espone una interfaccia per l’operatore (con tutte le informazioni sulla lavorazione e sullo stato della macchina) ma che, avendo un “regolare” sistema operativo, espone anche delle cartelle condivise (con le quali si scambiano i file CAM) ed un database che contiene tutti i parametri di funzionamento, il log storico, l’avanzamento e moltissime altre informazioni.
Il database è un SQLServer della Microsoft.
In azienda c’è la necessità di recuperare dalla macchina gli stati di avanzamento delle commesse che vanno integrati nel gestionale (sia per un monitoraggio puntuale da parte dell’amministrazione sia per un’analisi statistica sul lungo termine).
Ovviamente l’integrazione più semplice è quella di andare a leggere dal database della macchina le informazioni che sono di interesse per il gestionale. Potrebbe un tecnico affermare che la scelta è sbagliata e l’interconnessione debba avvenire in altro modo?
Ancora, questa modalità di interfacciamento è a norma (per l’iperammortamento)? Se andiamo a vedere gli standard in questione per lo scambio dati con un database SQLServer possiamo trovare questo:
- la connessione a livello di trasporto è TCP/IP
- a livello più alto si utilizza il protocollo di SQLServer, prodotto proprietario della Microsoft, ma estremamente diffuso in ambito aziendale e cloud, le cui specifiche (https://msdn.microsoft.com/en-us/library/ee210043(v=sql.105).aspx) sono pubblicamente disponibili
- implementazione di queste specifiche esitono per moltissimi linguaggi di programmazione, disponibili gratuitamente, ed è un servizio di database supportato dai software aziendali (in forza della disponibilità di librerie e driver)
- il database supporta come linguaggio di comunicazione l’SQL92 (stardandizzato ISO)
Si può ritenere che questo stack di protocolli non sia accettabile per integrare una macchina nella fabbrica digitale? E’ possibile pensare di imporre un ulteriore strado di adattamento per poter comunicare con la macchina per essere a norma con l’iperammortamento?
Sicurezza e accesso ai dati
Possiamo aggiungere a favore dell’utilizzo di questi servizi IT a livello macchina il fatto che prevedono ampia flessibilità nel controllo dell’accesso e anche della sicurezza dei dati. Mentre una macchina con il suo PLC ovviamente non ha il concetto di utente o si accesso limitato ai dati, un database implementa by design queste caratteristiche.
Architettura uniforme
E’ chiaro a tutti che se si deve scegliere una architettura per tutta l’azienda, sarebbe meglio adottare protocolli come l’OPC-UA (pretendendo che ogni elemento parli questo protocollo) ma una adozione così massiva e la sua integrazione con la parte IT non è sufficientemente diffusa e talvolta praticabile in impianti che non siano complessi ed a produzione continua.
Pensare che sia l’unica via ammessa dal piano impresa 4.0 (che incentiva ogni attività che si muova verso la digitalizzazione, persino i distributori automatici) è troppo restrittivo.
La vera forza di questo incentivo è l’obbligo di pensare la macchina non come oggetto, per quanto eccezionale, a sè stante nel reparto produttivo, ma come elemento del processo produttivo e che con questo processo scambia dati diventandone un attore attivo. E questo approccio sia da parte dell’utilizzatore che da parte del produttore, dal quale spesso ci dimentichiamo perché non parte che beneficia dell’incentivo.
Pubblicamente disponibili non significa gratuiti
Moltissimi standard sono adottati dalle aziende e la maggior parte di questi sono pubblicamente disponibili anche se per averne una copia è necessario pagarla. Non bisogna confondere il concetto di disponibilità con il concetto di gratuito.
Nel mondo di internet moltissimi protocolli sono disponibili e le specifiche scaricabili liberamente senza costi, ma questo per un approccio aperto instauratosi fin dall’inizio. Moltissimi altri standard per i quali vengono certificate le macchine o le stesse aziende e spesso richiesti dalla legge (sia per commerciare un macchinario che per partecipare a determinati appalti) sono disponibili al pubblico ma a pagamento.
Non è quindi pensabile che la norma sull’industria 4.0 possa imporre l’adozione di standard che siano disponibili in via esclusiva a titolo gratuito.
E’ un articolo di 3 anni fa che leggo solo ora, tuttavia è molto attuale.
Concordo pienamente con quanto scritto, il panorama delle comunicazioni iudustriali è senz’altro meglio descritto by service che by protocol.
E’ strano che la quarta rivoluzione industriale, in prima stesura, è stata interpretata facendo ricorso ai soli PLC/CN e relativi protocolli, fortunatamente in seguito ci sono state molte precisazioni e sono stati inclusi anche i PC come unità di governo.
Complimenti per l’articolo.
Grazie Davide per il tuo commento. Tocchi ovviamente un nervo scoperto per chi è del settore informatico, quindi anche il sottoscritto. Gli incentivi ed i relativi requisiti, che in Italia sono stati confusi con l’emergere dell’industria 4.0 – un classico -, si erano concentrati nella ricerca di un rinnovo delle macchine industriali con versioni più moderne e predisposte all’interconnessione. Non penso sia stato speso abbastanza nel diffondere la cultura 4.0, che abbraccia tantissime materie, e quindi nel “forzare” maggiormente le relative implementazioni.
Contando poi che industria 4.0 non si fa senza informatica e digitalizzazione, la disparità tra incentivi per le macchine e quelle per il software non hanno aiutato a far passare il corretto messaggio. Ovviamente resta una mia impressione personale!