Macchine più flessibili, più aperte, capaci di evolvere con la tecnologia del futuro senza essere vincolati ad un’architettura di un vendor specifico. Questa è la promessa della nuova piattaforma di automazione Noa, presentata da Keb all’Sps di Parma in anteprima assoluta. La soluzione, infatti, verrà ufficialmente svelata all’Sps di Norimberga, che si terrà a novembre.
Ma di che cosa si tratta? In poche parole, è una rivoluzione nell’architettura di automazione dei macchinari industriali. Le soluzioni tradizionali sono impostate in modo da creare un flusso di dati rigorosamente gerarchico fra le varie componenti del macchinario. Noa, invece, una piattaforma modulare basata sul sistema operativo open source Linux e su un’architettura a container, consente a tutte le parti della macchina di parlare con tutte le altre parti.
Questo in maniera indipendente dall’hardware, senza artificiosi lock-in, e con ampia libertà di dotare la macchina di nuove funzionalità e servizi semplicemente aggiungendo nuove applicazioni attraverso i container.
A completare la piattaforma troviamo uno strato, il Noa Core, che si occupa di creare un bus di connessione dati fra i vari container, una serie di applicazioni di serie fra le quali il potente sistema di creazione delle interfacce uomo-macchina Helio, e al di sopra di tutto uno strato, il Noa Portal, che sta su cloud Azure e dove vengono forniti servizi quali gestione dei dispositivi, monitoraggio e tutta una serie di app e servizi anche creati da terze parti.
Oltre che una rivoluzione tecnologica, l’arrivo di Noa segna soprattutto un salto culturale: somiglia molto all’evoluzione improvvisa che, sul mercato consumer, si è avuta con il passaggio dai telefonini base agli smartphone con le app. Da questo punto di vista, la piattaforma risulta nettamente più adatta delle soluzioni convenzionali a realizzare macchinari il cui utilizzo, da parte degli operatori, sia semplice ed allineato ai paradigmi tecnologici dei quali le nuove generazioni hanno maggiore esperienza. Ma il salto non è riservato agli operatori della macchina completata: anche i progettisti del macchinario potranno infatti beneficiare dei concetti su cui si basa Noa, per esempio il fatto di essere costruita su basi software open source (sistema operativo Linux, tecnologia di container Docker), di essere hardware indipendent, e di consentire la creazione di interfacce utente ergonomicamente corrette tramite una componente (l’app Helio) che lavora in modalità low-code/No-code, e che guida il progettista evitandogli errori di usabilità basandosi sui canoni di user experience (UX) che convergono dal mondo consumer.
Abbiamo parlato di Noa, di Helio e degli sviluppi della piattaforma con Marino Crippa, amministratore delegato, Walter Naddeo, head of application management, e Stefano Berardi, application owner control & automation and software development di Keb Italia.
Cosa è Noa
Noa è una piattaforma per l’automazione industriale, orientata principalmente ma non esclusivamente alla realizzazione di macchinari. Essa è nata per rispondere alle crescenti esigenze di flessibilità e semplificazione espressa dai costruttori, ma anche dagli operatori che ogni giorno si trovano a gestire varie macchine ognuna completamente diversa dall’altra nelle modalità di interazione. Essendo nata come piattaforma aperta, Noa facilita la cooperazione fra macchinari di diversi costruttori, riducendo la complessità dello sviluppo delle macchine e di allestimento di linee di produzione multimarca.
L’infrastruttura centrale Noa Core sfrutta un’architettura basata su Linux e container e può essere utilizzata su hardware embedded, Ipc e pannelli di Keb oppure su dispositivi di terze parti.
Le app Noa (per esempio soluzioni per Hmi, machine learning, monitoraggio e controllo, nonché app specifiche del cliente) possono essere gestite tramite App Manager. Il Noa Portal, basato su cloud Azure, fornisce i servizi di livello superiore come la gestione dei dispositivi. Se necessario, questo può anche essere adattato come variante “white label” per i clienti finali.
Ma quali sono i punti di forza della piattaforma? «La caratteristica più innovativa di Noa è il fatto che permette la connessione di tutti i dispositivi che compongono l’architettura di macchina – spiega Naddeo – Tradizionalmente, nell’architettura di automazione standard, tutti i livelli sono ben distinti: il motore parla con il drive, il drive con il Plc, il Plc con l’Hmi, in un flusso verticale di dati e comandi. Con Noa, il flusso digitale diventa multidirezionale, e tutti i dispositivi possono dialogare fra di loro. Quindi il motore, per esempio, è in grado di condividere un dato direttamente con l’Hmi».
Questo approccio, applicato all’infrastruttura multiservice e docker all’interno di Noa, dà la possibilità di realizzare delle App che prendono i dati da qualsiasi dispositivo e ne fanno “uso”, realizzando delle funzioni di macchina. «Per certi versi, si tratta di un salto in avanti simile a quello che, nella tecnologia consumer, è stato realizzato passando dal telefonino che faceva chiamate e inviava Sms allo smartphone dove era possibile installare applicazioni per realizzare nuove funzionalità» chiosa Crippa.
Ora, le App Noa possono essere sviluppate da Keb, che le potrà mettere in un App Store dal quale il cliente può scaricarle, ma il grande vantaggio – con il quale Keb va incontro a un’esigenza spesso espressa dai clienti – è che queste app le possono sviluppare direttamente i clienti stessi, in qualsiasi linguaggio di programmazione preferiscano. Essendo il sistema basato su Linux, la scelta dei linguaggi è davvero ampia, si va dal Phyton al C++, al C# e via discorrendo.
Le applicazioni a corredo
L’architettura Noa comunque esce già con un corredo base di applicazioni. Per esempio, ci sono software appositi per realizzare le Hmi, quelli di manutenzione predittiva e raccolta dati, e uno strato di gestione macchina che raccoglierà i dati dalle varie applicazioni dei docker e potrà gestire i vari device hardware, il licensing, eccetera. «L’obiettivo finale comunque è di rendere il dato più fruibile su tutta la catena del valore: a noi, al costruttore di macchine che è il nostro cliente principale, e all’end user – specifica Crippa – Su tutta la catena, ognuno dei componenti potrà generare dei servizi per il proprio cliente, in modo da avere dei revenue stream alternativi alla classica transazione con il vendor del componente, il costruttore che vende la macchina, e l’end user che vende il prodotto. Riusciamo quindi a sfruttare il dato per una gestione del servizio che può essere progettato sulla piattaforma ad hoc per il tipo di macchina e di mercato».
Helio, l’Hmi si fa docker
Da anni, l’Hmi ha come ruolo primario quello di far funzionare la macchina, ma a dispetto del nome (significa infatti Human Machine Interface) ben poca attenzione è stata posta nel rendere questo modulo focalizzato sull’operatore. E questo nonostante i proclami teorici sulla centralità dell’operatore stampati a chiare lettere sugli opuscoli di Industria 4.0- così disattesi che sono stati rimessi, in bella copia, nelle specifiche di Industria 5.0, sperando che si la volta buona.
«Per progettare l’Hmi di Noa, Keb ha usato un approccio basato sulla user experience dell’operatore per definire un’interfaccia che facesse sì funzionare la macchina, ma che fosse di facile uso per il personale, che fosse portabile su qualsiasi dispositivo (mantenendo anche nell’Hmi il concetto di hardware independency dell’architettura complessiva), e che fosse low code o no-code elenca Crippa – Per soddisfare questi requisiti, l’Hmi mutua tutte le strategie di content management consolidate su Internet, diventando così una sorta di “WordPress dell’automazione”».
Il risultato del lavoro di sviluppo puo’ essere “containerizzata”, ovvero un’applicazione contenuta nella sua macchina virtuale, totalmente portabile e Ip-compatibile, che va sotto il nome di Helio.
«Helio è una app che viene installata sull’architettura Noa, e ha la caratteristica di poter comunicare con tutte le altre App – spiega Stefano Berardi, application owner C&A and software development di Keb Italia – Essendo hardware independent, non devo per forza installarla sul pannello, ma posso averla su qualsiasi dispositivo dove risieda il Noa (per esempio un edge server) in quanto per accedervi posso usare qualsiasi device, a patto che abbia a bordo un semplice browser Web. Di fatto, funzionando tramite un normale flusso di dati Ip, è possibile avere l’interfaccia di una macchina sia sui tradizionali pannelli, sia su qualsiasi dispositivo l’operatore voglia usare – per esempio, uno smartphone o un tablet».
In teoria, Helio dovrebbe andare in mano a degli sviluppatori di software. Ma allora, perché si è adottato un approccio di tipo low-code/no-code? «Perché Helio nasce per essere non solo facile da usare per l’operatore di macchina, ma anche per risultare facile da programmare per chi sviluppa il software dell’apparecchiatura – spiega Berardi – In questo modo, lo sviluppatore non perde più ore a definire dettagli banali come la posizione di un pulsante o di che colore visualizzarlo, perché Helio ha al suo interno una libreria di oggetti di interfaccia che sono già predisposti, e basta semplicemente trascinarli sullo schermo perché l’applicazione provveda a posizionarli nell’interfaccia e ad adattarli in modo corretto alla schermata».
Sì, anche a posizionarli, perché gli oggetti presenti nelle librerie integrano informazioni di corretta ergonomia (posizionamento, dimensionamento, colorazione…). «Per esempio, l’oggetto “Tasto di accensione” è configurato in modo da andare a piazzarsi in una specifica posizione ottimale. Se da una parte si potrebbe pensare che si tratti di una limitazione alla “libertà creativa” dello sviluppatore, nei fatti si tratta di un accorgimento fondamentale: in pratica, il sistema di creazione delle interfacce contiene una base di regole di corretta ergonomia, e impedirà a utenti troppo creativi di produrre interfacce utente che risulterebbero di difficile utilizzo, per esempio per la posizione inusuale di alcuni comandi, o per l’utilizzo di colori inadeguati e in contrasto con i codici internazionalmente adottati» spiega Berardi.
Un altro aspetto interessante, diretta conseguenza del precedente, è che per programmare un’interfaccia utente su Helio non serve più avere un ambiente di sviluppo completo: basta utilizzare un normale browser. Questo velocizza ulteriormente le operazioni di creazione dell’interfaccia, perché con l’approccio tradizionale bisognava prima scaricare l’ambiente di sviluppo dedicato sul proprio Pc, spesso corredato di una licenza legata al computer (e quindi se il Pc aveva un problema lo sviluppo si doveva fermare fino a riparazione avvenuta); invece, con Helio uno sviluppatore può collegarsi al sistema per esempio da un iPad e iniziare a dare forma a un’interfaccia.
E questo è solo uno dei tanti vantaggi prodotti dall’aver adottato per Noa un’architettura basata su “docker”. Il docker, in estrema sintesi, è una sorta di scatola, una piccola macchina virtuale al cui interno viene inserito il codice sorgente, le librerie, i compilatori/interpreti e in generale tutto ciò che serve per far girare il programma. In questo modo, è possibile spostare facilmente l’applicazione all’interno del sistema operativo Linux, in quanto non ci sono dipendenze esterne, e tutto ciò che serve al funzionamento è incluso nel container.
Il bus virtuale è al Core della piattaforma
Ma se ogni applicazione è un container monolitico, quindi un vero e proprio computer virtuale entrocontenuto, come è possibile far comunicare fra loro le varie app, e di conseguenza le varie parti della macchina? Ebbene, un altro elemento fondamentale nell’architettura Noa è il Message Bus, che costituisce il “core” della piattaforma, ed è a sua volta appoggiato direttamente sul sistema Linux.
Se i container possiamo immaginarli come tanti computer virtuali, il Message Bus è un po’ l’equivalente della rete locale dell’ufficio, una connessione che permette di scambiare dati e messaggi fra le varie macchine virtuali collegate, considerate ” a pari livello”, ovvero senza le limitazioni imposte dalle vecchie strutture gerarchiche. Tra l’altro, anche la gestione delle comunicazioni con componenti che richiedono il real time è gestita via appositi container, in questo caso specificatamente certificati per la trasmissione di messaggi in tempo reale e la gestione dei vari protocolli, e supportati da un apposito hardware prodotto da Keb.
Un vantaggio collaterale dell’architettura a docker connessi via message bus è che essa permette di evitare i lock-in che sono sempre più malvisti dai produttori di macchinari.
Helio, non solo in Noa
Il sistema di creazione delle interfacce Helio è un componente essenziale dell’architettura Noa, ma, coerentemente con la filosofia Keb, di massima flessibilità ed indipendenza, è disponibile anche come applicazione a sé stante.
In pratica, è possibile installare Helio come Hmi indipendente, senza dover passare dal docker di Noa. «Helio è disponibile stand alone per essere inserito nelle applicazioni di altri clienti – conferma Crippa – ed è anche una piattaforma di sviluppo per customizzare le interfacce macchina. Infatti, Helio nasce come prodotto “da scaffale”, quindi lo acquisto e ho già a disposizione una serie di funzioni. Tuttavia, se fossero necessarie funzioni aggiuntive, per esempio nel caso di macchine particolarmente complesse, possiamo contare all’interno del gruppo di 50 persone, di cui 25 programmatori e 25 esperti di User Experience, che possono interagire con il cliente per sviluppare l’interfaccia ad hoc di cui necessita».
Da notare la proporzione paritaria fra programmatori ed esperti di ergonomia, che la dice lunga sul concetto alla base di Helio, ovvero creare interfacce pensate in primis per facilitare il lavoro dell’operatore alla macchina. Tanto che quando il team comincia a progettare una nuova interfaccia, inizia parlando con i futuri operatori della macchina, prima ancora che con i progettisti.
Ma cosa vuol dire in concreto utilizzare Helio in modalità stand alone, ovvero staccato dal resto dell’architettura Noa? In linea teorica, sarebbe possibile per un produttore di macchine sostituire la sua Hmi convenzionale con Helio, ma la cosa non porterebbe a sfruttare le potenzialità del sistema, anche perché probabilmente il costruttore si limiterebbe a rifare con Helio ciò che aveva prima sull’altro Hmi. Il caso d’uso più auspicabile, invece, è quello di un cliente che, in una sua linea produttiva, debba sfruttare più macchinari di produttori diversi. Se tutti i macchinari vengono progettati usando Helio per l’interfaccia Hmi, il risultato finale è che gli operatori troveranno lo stesso ambiente Hmi su tutte le macchine, senza dover studiare sistemi e convenzioni diverse per ogni singolo apparato. Questo consente di passare in azienda da un controllo di macchine a un controllo di processo, e porta ovviamente a una semplificazione del lavoro per gli operatori, che si tradurrà a sua volta in un minor numero di errori e di criticità.
I vantaggi, comunque, non sono solo per l’acquirente della macchina: il produttore infatti potrà godere di tempi di time to market più brevi (grazie alla maggiore velocità di creazione delle interfacce) e potrà anche realizzare macchine che si diversificheranno di più dalla concorrenza. E se viene adottata in toto l’architettura Noa, si può contare anche la maggiore facilità nel creare stream di revenue legati a servizi realizzati o gestiti via docker.
Sopra tutto c’è l’IioT in Cloud
Perché le macchine basate su Noa possano sfruttare servizi cloud è necessario un ultimo strato, quello dell’IioT, che realizza appunto la connessione fra macchine e servizi basati su Internet. Il modulo, che si chiama Noa Portal, in pratica raccoglie e instrada i dati verso, in questo caso, il cloud Azure di Microsoft, dove potranno essere “presi in carico” dalle applicazioni e servizi cloud che li devono analizzare. Al momento del lancio, saranno disponibili i servizi di Device Management, App Management, Monitoring e Gestione Asset. Ma considerato che Keb ha sposato il concetto di apertura totale della piattaforma Noa, il portale è predisposto per ospitare, in futuro, applicazioni sviluppate da terze parti o anche dagli stessi clienti, e potrebbe diventare dunque una sorta di marketplace dove trovare servizi e app per ogni esigenza, pronte all’uso e magari certificate da Keb.
«Al momento, non è ancora stato deciso se avremo un App Store nostro o se ci appoggeremo a uno store preesistente. Stiamo ponendo ora le fondamenta di questo nuovo modello di business, in modo ottimale e coerente e al momento tutte e due le opzioni sono aperte e percorribili. Se l’esigenza di scrivere applicazioni è preponderante, probabilmente noi stessi cercheremo di creare un ecosistema di partner in grado di realizzarle. Per contro, se i costruttori volessero mantenere il know-how di realizzazione strettamente all’interno, il nostro ruolo diventerebbe di supporto per i costruttori stessi nelle fasi di sviluppo, con le app standard messe a disposizione su store indipendenti» conclude Crippa.
