Dall’Edge al Cloud l’Iot… Parla Italiano!

a cura della Redazione

 

Nel nuovo millennio abbiamo assistito a una serie di fenomeni epocali: lo sviluppo esponenziale del Web e del Cloud fino ad arrivare, in tempi più recenti, a quella che è stata spesso definita “rivoluzione digitale”, con la diffusione dei dispositivi intelligenti dell’IoT o “Internet of Things”. Molti ne parlano, pochi sono in grado di comprenderne tutti i tecnicismi e l’immenso potenziale di applicazione e sviluppo. Con l’aiuto dell’Ing. Maurizio Caporali di SECO S.p.A., in queste pagine cercheremo di fare un po’ di chiarezza, partendo dalla definizione di device fino a giungere alle problematiche di gestione di sistemi strutturati più complessi.

 

Buongiorno Ingegner Caporali, La ringraziamo per aver accettato il nostro invito e Le porgiamo le nostre congratulazioni per il nuovo incarico. Potrebbe descriverci di cosa si tratta?

In SECO la mia attività principale è quella di product manager, alla quale recentemente si è affiancata la responsabilità di una nuova Business Unit, SECO Mind, in qualità di co-CEO. Una società del Gruppo creata per apportare servizi innovativi e caratterizzati da un alto valore aggiunto per il cliente. Le attività spaziano dalla raccolta dei dati sul campo – dove sono collocati i device – alla loro elaborazione e analisi attraverso algoritmi di intelligenza artificiale (AI), sia sull’Edge che sul Cloud, fino ad arrivare al servizio vero e proprio che può consistere anche nel progetto di una soluzione completa. Il mio lavoro consiste prevalentemente nel coordinamento delle attività per la realizzazione di un prodotto che si pone alla base di tutto questo, uno strumento che permetta ai clienti di rendere “intelligenti” i propri prodotti e di portarli rapidamente sul Cloud, creando per loro nuove opportunità di business, che vanno ad aggiungersi a quelle tradizionalmente già consolidate.

Mi sta descrivendo un modello di business “a 360 gradi”, in grado di fornire una soluzione davvero completa, che va ben oltre la fornitura del solo HW ed è incentrata soprattutto sui servizi e sulla soluzione degli aspetti più critici: raccolta, interpretazione, trasporto e gestione dei dati. È così?
Nell’ecosistema dell’IoT, l’hardware rappresenta una parte fondamentale, ma ciò che realmente fa la differenza è l’ingegnerizzazione dell’intero sistema, con il progetto di soluzioni personalizzate che rispecchiano esattamente le esigenze dell’utenza.

Quello dell’IoT è un fenomeno che negli ultimi anni ha avuto uno sviluppo esponenziale, senza soste. Molti ne parlano, pochi ne comprendono effettivamente le caratteristiche, la tecnica e l’enorme potenziale che vi stanno dietro. Tornando alle origini dell’Iot, potrebbe farci un esempio di quello che, secondo la sua esperienza, ha rappresentato un po’ la “pietra miliare” dell’utilizzo di un “device” ?
Con molto piacere, anche perché quello dell’IoT è sempre stato per me un argomento di grandissimo interesse. Il mio background va dalla parte puramente tecnologico-ingegneristica dei servizi software, all’UX, o “User Experience”, acquisita attraverso molti anni di studi e collaborazioni in team di ricerca orientati al Design Thinking; gruppi di lavoro nei quali rappresentavo un “ponte”, un collegamento tra la parte di progettazione e quella di implementazione del servizio stesso, focalizzandomi soprattutto su progetti e sistemi complessi. In quest’ultimi, l’attenzione non era posta esclusivamente sul mero sviluppo del software – come avviene nel progetto di un programma per PC, ad esempio – ma era particolarmente focalizzata sull’analisi dell’intervento dei dispositivi, degli oggetti o device ai quali l’utente si doveva interfacciare, laddove la tecnologia va ad aumentare e si fa più complessa.
Il primo esempio che ricordo, che considero un po’ come il vero inizio dell’era IoT, riguarda un’implementazione che realizzammo per rendere “smart” un museo di Siena. In quell’occasione, per offrire al pubblico un’esperienza con un livello di coinvolgimento senza precedenti, utilizzammo per la prima volta i dispositivi TAG RFID, integrandoli in un “magic wand”, una sorta di bacchetta magica che veniva consegnata ai visitatori. Questi, avvicinandola alle zone di interesse disseminate lungo l’itinerario, ottenevano diverse reazioni da parte degli impianti espositivi del museo, animandoli come per magia. All’epoca (si parla di oltre vent’anni fa) questa implementazione dalle connotazioni “tra il mistero e la fantascienza” suscitò un notevolissimo scalpore e fu particolarmente apprezzata. L’introduzione di questi piccoli dispositivi RFID nelle bacchette segnò l’inizio di una nuovo corso. Da allora, bisogna dirlo, il concetto di IoT è mutato radicalmente. Il percorso ormai era tracciato.

Fu certamente un primo passo verso la vera e propria “pervasione dell’IoT” a cui stiamo assistendo, che vede online un enorme numero di device. Potrebbe spiegarci cosa si intende esattamente con questo termine e portarci qualche esempio dei suoi utilizzi comuni?
In SECO la mia attività quotidiana è proprio quella di lavorare con aziende che producono questi dispositivi. Ad esempio, quando ci alziamo, entriamo in cucina per fare colazione, prendiamo il latte dal frigorifero, lo scaldiamo nel forno a microonde e accendiamo la macchina del caffè. Abbiamo già utilizzato, magari inconsapevolmente, due o tre device. Si tratta di congegni elettromeccanici, dotati di un’elettronica elementare o comunque non troppo raffinata, che svolgono le funzioni alle quali sono destinati, limitandosi a quelle. In questo caso li possiamo definire “dispositivi non intelligenti”. Quello che facciamo in SECO è proprio “renderli più intelligenti”. Le nuove generazioni di questi dispositivi vengono dotate, di default, di una microelettronica che li rende “smart”. A seconda delle tipologie e delle necessità, si può trattare di un microprocessore con un sistema operativo, oppure di un microcontrollore. In ogni caso, parliamo di elettronica simile a quella di un computer o di uno smartphone. Oltre all’ambito domestico, ovviamente i device li troviamo anche nell’industria. In questo caso si tratterà di macchine destinate ai più vari tipi di lavorazioni che, rispetto al passato, stanno diventando a loro volta “intelligenti”. L’equipaggiamento elettronico di un device a uso industriale è destinato principalmente a gestire i sensori e gli attuatori che ne governano il funzionamento. Un’altra caratteristica fondamentale che distingue un device smart è quella della connettività, un aspetto al quale abbiamo già iniziato ad abituarci.

Prima di andare oltre parlando della connettività, vorrei tornare per un istante a sensori e attuatori. Mentre per quest’ultimi vi è sempre stata una certa interattività con il sistema – nel senso che dopo aver ricevuto un comando ne hanno sempre comunicato (a ritroso) l’avvenuta esecuzione – per i sensori di generazioni precedenti il funzionamento è sempre stato piuttosto semplice, dal momento che si limitavano a trasmettere le grandezze rilevate all’elettronica di controllo, senza ricevere comandi. Cos’è cambiato negli ultimi anni a tale proposito?

Vi sono stati cambiamenti molto importanti. Oggi i sensori disponibili sul mercato sono già dotati di una propria “intelligenza”.
Anche i più semplici hanno a bordo almeno un microcontrollore che li gestisce, un chip con un proprio firmware dedicato allo svolgimento di poche ma essenziali funzioni, che vengono svolte in modo estremamente efficace. Se, ad esempio, dobbiamo rilevare una corrente, una sola misura non basta; per costruire un valore medio ne servono molte. L’intelligenza del sensore “smart” serve anche a questo, a eseguire una “pre-elaborazione” dei dati prima del loro invio. La sensoristica moderna fa esattamente tutto ciò, restituendo al resto del sistema un insieme di dati già utilizzabili.
Generalmente l’interfacciamento avviene con canali di comunicazione su bus I2S, uno tra gli standard più sicuri ed affidabili utilizzati in campo industriale, ma anche da questo punto di vista c’è stata un’evoluzione: i sensori comunicano anche in modalità wireless.
Ritengo importante distinguere due macro categorie di device:

• quella che annovera i più elementari descritti in precedenza (ad es. elettrodomestici).
• quella degli apparati più evoluti e complessi destinati a un ambito industriale come – giusto per fare un esempio – nel caso di una macchina a controllo numerico CNC.

Quest’ultima macchina disponeva, già molti anni or sono, di un notevole livello di intelligenza. Era perfettamente in grado di operare in completa autonomia con computer e sensori a bordo, eseguendo lavorazioni anche molto complesse.
Ma non era connessa.
Dopo la vendita del macchinario, il produttore non riceveva alcuna informazione sulle condizioni d’uso e di funzionamento del medesimo, perdendo, così, tutta una serie di informazioni che, per forza di cose, restavano retaggio esclusivo dell’utente finale. Con l’evoluzione attuale dell’IoT e della connettività, possiamo dire di essere riusciti ad aumentare ulteriormente la versatilità di questi strumenti, già piuttosto raffinati, rendendo possibili funzioni impensabili fino a qualche anno fa:

• offrire supporto tecnico e assistenza anche da remoto (tele-diagnosi)
• far evolvere, nel tempo, il livello di operatività della macchina, migliorandone gli algoritmi funzionali con aggiornamenti implementati a distanza
• ricavare dai device nuovi servizi a valore aggiunto, che non erano disponibili sugli apparati di vecchia generazione

L’analisi di tutti questi dati raccolti permette una valutazione comparativa tra dispositivi dello stesso tipo, permettendo ai tecnici di assistenza di identificare problemi in essere o addirittura di praticare la cosiddetta “manutenzione predittiva”, così da segnalare la necessità di sostituzione di un componente (un cuscinetto a sfere rumoroso, ad esempio) addirittura prima che vada fuori uso. I tecnici di assistenza (interni o esterni, in caso di telediagnosi…) possono così arrivare sulla macchina completamente preparati, con il quadro chiaro della situazione e, soprattutto, con tutti i ricambi necessari in valigia!

Quindi i sensori intelligenti possono riconoscere il determinarsi di particolari situazioni critiche durante l’uso?
Certamente. Posso citare l’esempio di un operatore CNC, molto esperto, che dopo decenni di lavoro sulla macchina è in grado di riconoscere le anomalie di funzionamento semplicemente appoggiando la mano, percependo le vibrazioni. Un sensore intelligente – che in questo esempio della testa del CNC è dotato di un accelerometro triassiale – fa esattamente lo stesso: studiando i dati rilevati creiamo dei modelli in grado di riconoscere queste categorie e siamo in grado di comunicare all’operatore l’insorgere di un fenomeno anomalo, prima che questo porti a conseguenze molto più gravi. Di questi tempi, nelle aziende il “turn over” del personale è aumentato notevolmente. Gli operatori di nuova generazione cambiano mansione molto più frequentemente rispetto al passato, non riescono più a maturare la necessaria esperienza diagnostica sui singoli macchinari. Anche per questo motivo, poter disporre di un sistema di telediagnosi diventa un fattore di importanza fondamentale nella realtà industriale moderna e SECO si distingue in modo particolare confermandosi leader di mercato.

Questi nuovi dispositivi “ultra-intelligenti” dotati, a loro volta, di sensori altrettanto sofisticati e versatili, producono una mole di dati piuttosto “importante”; moltissimi dati, che dovremo necessariamente trasferire e gestire lungo la catena di comunicazione, decidendo dove, come e quando elaborarli per ottenere un risultato ottimale. Modello FOG o Edge?
Questo rappresenta proprio il punto focale del nostro lavoro, la base delle nostre attività quotidiane, sia dal punto di vista della gestione di questi dati, sia da quello della gestione dei vari software che li devono portare avanti. L’altro aspetto fondamentale riguarda l’elettronica che gestisce questi sensori e gira il software di sistema, occupandosi anche della connessione.
Un device si definisce “edge” proprio perché si trova ai limiti della rete, nella sua porzione più periferica. Un dispositivo del genere offre performance di un discreto livello. Può essere basato sia su microcontrollori che su microprocessori, generalmente chip molto prestazionali a clock elevato, in grado di tracciare e analizzare i segnali in arrivo da sensori altrettanto veloci come, ad esempio, gli accelerometri montati sulle teste da taglio della nostra macchina CNC. Se è necessario rilevare “pattern” anomali, che di solito sono dei veri e propri indicatori di funzionamento in condizioni critiche, risulta molto più utile farlo ai limiti di rete, ovvero sull ”edge” e arrestare la macchina prima che sia troppo tardi. Questi sensori ad alte prestazioni sono perfettamente in grado di girare in locale tutti gli algoritmi di AI che permettono loro di riconoscere la maggior parte delle situazioni di funzionamento anomalo.
Ovviamente questi device non si limitano a questo, acquisiscono anche una notevole quantità di altre informazioni che risultano invece utili sul Cloud (su vari server di gestione) dove avviene la cosiddetta “orchestrazione” dei dati, attraverso la quale si riesce a dirottarli in modo dinamico a seconda delle funzioni da eseguire e dei risultati che si desidera ottenere.
Quando, invece, il numero delle macchine da gestire localmente diventa davvero elevato – così come avviene, di pari passo, con la mole dei dati da gestire – si può ricorrere a un’architettura di tipologia FOG nella quale, anche se l’attività di Edge resta comunque invariata, la gestione e l’orchestrazione dei dati provenienti dai margini di rete avviene localmente, attraverso server industriali per ambienti critici (“rugged”) installati in una sorta di intranet aziendale, elaborandoli prima che vengano inviati verso il Cloud.
L’utilizzo dell’elaborazione sul Cloud diventa invece indispensabile quando si devono contemplare statistiche ad ampio raggio, su installazioni dislocate in aree a superficie estremamente elevata, a livello nazionale, continentale o addirittura globale. In questi casi, evidentemente, data l’estrema frammentazione geografica delle infrastrutture, non si potrà fare altro che ricorrere al Cloud, acquisendo i dati ed eseguendo le analisi di nostro interesse su vasta scala, ma con tempi e ritmi più dilatati.

 

Le cose si complicano, Ingegnere: dal singolo device siamo arrivati a una piccola rete locale, passando poi a realtà industriali di maggiori dimensioni per finire a reti strutturate complesse a diffusione globale!
Non è pensabile che un’Azienda, anche di alto livello, abbia tutta l’esperienza necessaria alla gestione di un network simile, in completa autonomia. Non trova?
Proprio per questo SECO, negli anni, ha maturato una propria, specifica esperienza di settore, offrendola alle aziende. Per i nostri progettisti è sufficiente che il cliente conosca le proprie macchine in modo approfondito e sia in grado di trasferirci la propria “expertise”, con tutte le informazioni relative al loro utilizzo, consentendoci così di sviluppare l’hardware e il software di gestione di rete, nonché gli algoritmi di AI necessari alla realizzazione dell’intero sistema. Inoltre, siamo in grado di assisterlo in un percorso davvero completo, stabilendo quali tipi di analisi e di attività siano da effettuare sull’edge, quali vadano svolte localmente a livello FOG e quali, invece, si possano realizzare sul Cloud, mediante i vari broker di servizi.

Broker di servizi? Li deve scegliere il cliente?
No, non necessariamente. La funzione svolta dal broker è assolutamente essenziale ma risulta piuttosto “trasparente”, poco visibile all’utente finale. Per SECO non è così, negli anni ha integrato nella sua offerta queste soluzioni, concertando tutte le implementazioni e le modifiche necessarie per garantire un servizio ottimale e la completa portabilità “on premises” dei servizi forniti sui server (intranet) del cliente.

Prima si è citato un esempio di connessione di tipo fisico, cablato, all’interno di un device. In Azienda non è sempre così facile realizzare network via cavo, soprattutto negli edifici “datati”, che risultano i meno adatti alla posa di questo tipo di infrastrutture. Come operate in SECO da questo punto di vista?
Uno dei punti di forza dell’evoluzione IoT sta proprio nella flessibilità delle soluzioni di connettività. Nel corso degli ultimi anni, lo stesso cambiamento radicale che ha riguardato i computer embedded, dedicati a questi sistemi industriali, ha coinvolto anche tutti gli aspetti del collegamento. Per gestirlo all’interno dei nostri device operiamo principalmente a due livelli:

• integrazione della connettività, saldata direttamente sulla scheda di questi sistemi
• mantenimento della modularità, per garantire qualsiasi aggiunta di connettività rispetto agli standard

Ad esempio lo standard M.2, utilizzato anche sui computer domestici, permette di aggiungere l’insieme dei componenti che danno questo tipo di connettività anche ai computer embedded, con Wi-Fi e Bluetooth come scelte di default. Come si è visto, però, la connettività tra device Cloud è stata spesso oggetto di diverse battaglie commerciali a discapito della loro fruibilità; per questo e per altri motivi in SECO abbiamo fatto una scelta, optando per la connettività mobile. Le nostre elettroniche hanno caratteristiche di potenza elevata, possono elaborare una notevole mole di dati che richiede, dove e quando serve trasferirle, la disponibilità di una banda passante altrettanto alta. Anche se le applicazioni con requisiti minori non richiedono tutta questa larghezza di banda, abbiamo comunque preferito basarci sulla rete mobile per garantire la più ampia flessibilità di utilizzo e, soprattutto, fruire della maggior sicurezza di copertura geografica (e di sicurezza del trasporto dati) che fosse possibile ottenere. Inoltre, nella tecnologia mobile, con l’avvento del 4.5G (LTE Advanced Pro) c’è stata un’evoluzione dedicata al M2M (machine to machine) e all’IoT, legata al passaggio dal 2G a nuove tecnologie di connettività mobile dedicate ai device, che sono LTE-M e NB-IoT.
Sono tecnologie assolutamente attuali, hanno raggiunto una copertura globale molto importante.
La tecnologia LTE è molto usata nella telefonia commerciale. Inoltre, a differenza dell’LTE Cat. 4 che opera su frequenze differenti a seconda dell’area di copertura, LTE-M e NB-IoT utilizzano una frequenza unica in tutto il mondo: un vantaggio enorme per quanto riguarda gli apparati che, una volta certificati nel Paese di produzione, possono essere utilizzati a livello globale senza formalità ulteriori. Si tratta di mercati paralleli anche se, dobbiamo dirlo, l’evoluzione tecnologica dell’LTE ha portato notevoli vantaggi anche al mondo dell’embedded industriale. In ogni caso, i produttori di silicio realizzano comunque famiglie separate di modem mobile, ognuna dedicata al proprio specifico segmento; quelle destinate al mondo IoT industriale devono garantire una disponibilità di mercato di almeno 10 anni, oltre a possedere caratteristiche di funzionamento continuo in ambienti ostili (temperatura e vibrazioni elevate), ben diverse da quelle destinate al comparto consumer.
Un altro dei nostri punti di forza consiste nella capacità di certificare l’intero sistema, non limitandoci all’infrastruttura aggiunta da SECO, ma includendo nel processo di certifica anche i device del cliente, compresi i sensori sull’edge.
Questi modem vengono integrati all’interno dei device, oppure aggiunti a livello modulare (con M.2); in alternativa, su rete locale, possiamo utilizzare la connettività ZigBee o LoRa, con i relativi gateway di rete. Il nostro software è già predisposto per accogliere anche questi standard.

Molto versatile! Con queste tecnologie è possibile strutturare un sistema che va dai più remoti sensori di edge, all’intelligenza del device locale, al suo collegamento nell’intranet aziendale, fino ad arrivare al data orchestration attraverso il Cloud. Un percorso piuttosto esteso, lungo il quale siete comunque in grado di intervenire con l’applicazione di aggiornamenti software e firmware anche frequenti (il cosiddetto “tuning” di sistema, per il miglioramento delle sue caratteristiche di AI e l’ottimizzazione generale).
Questa elevata frequenza di aggiornamento può, in qualche modo, rappresentare un rischio per l’integrità del sistema stesso?
In passato, la tendenza di progetto era quella di studiare un firmware, collaudarlo estensivamente nella fase di pre-produzione per poi passare alla mass-production e non modificarlo più per tutta la vita prevista del prodotto (10-15 anni), come si diceva nell’esempio precedente degli elettrodomestici semi-intelligenti. Oggi le cose sono cambiate in modo radicale: è proprio lo stesso concetto di AI che porta a questa nuova esigenza di evoluzione e miglioramento continui. Il mantenimento della sicurezza e dell’integrità di sistema è uno dei punti cardine del nostro business. In SECO usiamo il modello DevOps, con il CI-CD (Continuous Integration – Continuous Delivery), un metodo per l’implementazione e la distribuzione continua delle app. L’analisi dei dati acquisiti in tutti i punti della rete permette di applicare costantemente nuove implementazioni e miglioramenti al sistema, in un percorso virtuoso. In altre parole, i modelli di analisi in uso vengono migliorati attraverso lo studio dei dati che questi stessi hanno prodotto, generandone di nuovi, ancora più evoluti, che vengono a loro volta distribuiti e utilizzati, e così via.

 

Distinguerei però almeno due livelli di aggiornamento:

• a livello applicativo, o di device, che anche lo stesso cliente può anche gestire in autonomia, diluendolo nel tempo, per aree geografiche, o comunque secondo modalità di propria scelta che possono dipendere dalla tipologia di prodotto e dalle condizioni d’uso.
• a livello più elevato, quello del core di sistema, che prevede necessariamente un riavvio del computer embedded, con conseguente interruzione temporanea del servizio, la cui riattivazione deve comunque essere sempre garantita.

Nel secondo caso, il livello di rischio e di eventuali conseguenze negative è molto più elevato; per questo sono stati previsti sistemi di protezione di tipo fall-back che, nell’eventualità di un crash di sistema a seguito di update, fanno riavviare la macchina con la versione precedente, ripristinandone il funzionamento. Queste due modalità di aggiornamento remoto si basano a livello di applicazione su tecnologie Container, Docker e Kubernetes e al livello sistema operativo linux sul Device Tree, la struttura dati che descrive l’hardware della scheda.

Può darci qualche dettaglio in più sul loro utilizzo?
Sono strumenti che permettono di sviluppare applicazioni e farne il “deployment” secondo le esigenze del programmatore e dello sviluppatore. La tecnologia “a container” ha avuto un’evoluzione molto importante (e ormai conosciuta) dal lato server, mentre il suo utilizzo dal lato embedded, sull’edge di rete, è meno noto, ma non certo meno importante. Mi spiego meglio. Immaginiamo di avere uno sviluppatore che ha prodotto un’applicazione di machine learning che gira in Python – con tutte le librerie relative – e che non conosca nulla (né voglia saperne…) del sistema che gira sulla scheda embedded, ad esempio uno Yocto Linux. Evidentemente non potrà ritrovare su Linux le sue librerie Python e la strada della ricompilazione non è sempre la più semplice da seguire. Lavorando nella modalità “a Container”, sarà possibile definire esattamente quante e quali risorse del sistema utilizzare (ad esempio, solo un core su 4 del processore Quad e non oltre 256 MB di RAM), facendo girare la sua applicazione Python soltanto all’interno di esso, in una sorta di “sandbox” di protezione la quale, anche in caso di crash, impedirà il collasso dell’intero sistema, proteggendone il core e aumentandone considerevolmente il livello di sicurezza. Sarà sempre possibile eseguire gli aggiornamenti delle applicazioni che girano all’interno dei container senza influenzare il funzionamento e la stabilità delle funzioni di core, mantenendo la filosofia CI-CD. La stessa filosofia vale e viene utilizzata per le applicazioni che vengono eseguite sul Cloud.

Il vostro catalogo prodotti è piuttosto ricco e articolato, a tutto vantaggio della flessibilità e modularità del sistema. Esiste una soluzione “unica”, un pacchetto completo HW-SW-FW e networking, che possa rispondere alle più diverse esigenze dell’utenza?
Proprio in questi giorni SECO ha introdotto sul mercato Clea , un prodotto che rappresenta una soluzione “end-to-end” che spazia dall’hardware al servizio, nel quale andiamo a gestire praticamente tutto, inclusa la parte di connettività. Attraverso una serie di moduli (o “building block”) possiamo arrivare rapidamente a costruire una soluzione adeguata al cliente. Clea si basa anche su una serie di soluzioni open-source – un altro punto di forza di questo prodotto – in quanto permette alle aziende di gestire il prodotto anche in modo autonomo, averne un maggiore controllo e poterlo mantenere con continuità. Partendo da vari moduli della parte server, basata su Kubernetes e sui diversi micro-servizi che vi stanno dietro, fino ad arrivare agli SDK (Software Development Kit) che permettono ai clienti di sviluppare (anche) autonomamente all’interno dei propri device.
Del resto, anche nel campo dell’HW stiamo assistendo a un’evoluzione.
È questo il caso del Risc-V, che sta portando la visione “open” anche nel mondo dell’hardware con dei risvolti interessanti, anche per la crescita, nel tempo, del prodotto stesso.
Proprio per questo stiamo lavorando nel contesto più “open” dell’Azienda, quello della famiglia di prodotti che, tra l’altro, penso rivesta un particolare interesse per i vostri lettori: quello di UDOO.
A breve sarà disponibile una soluzione dedicata ai developer, che potranno accedere all’utilizzo di un’ampia piattaforma HW e SW, potendo così realizzare velocemente tutti i propri “proof of concept”. Una volta che i loro primi oggetti saranno stati messi “in campo” e il business inizierà a crescere, SECO potrà offrire tutto il supporto necessario per industrializzare il prodotto, sia per la componente hardware che per il resto della soluzione, concretizzandolo per loro mediante la soluzione Clea dedicata al mondo enterprise.

Questa flessibilità può essere fruita anche dai developer più anagraficamente “senior”, con un “focus” molto spesso limitato alle proprie macchine, o resta perlopiù retaggio degli sviluppatori di ultima generazione?
Certamente. SECO affianca il team di sviluppo del cliente, fornendo tutta l’esperienza necessaria alla strutturazione del progetto completo.
A qualsiasi livello, nel percorso Edge – Cloud – Edge, siamo in grado di occuparci di tutti gli aspetti da gestire, soprattutto quelli dove il livello di conoscenza dei progettisti locali di device – spesso concentrati quasi esclusivamente sul proprio prodotto – risulta in qualche modo inadeguato o insufficiente.
Questa filosofia di approccio non si applica solo in questi casi, vale anche per le aziende o i professionisti impegnati nell’attivita R&D di nuovi prodotti e per le Startup. Anche in questo caso siamo in grado di aiutare queste figure professionali, fornendo tutti gli strumenti necessari per creare il proprio device e portarlo in campo con i servizi.

Per concludere vorrei parlare delle prospettive future dell’Internet delle Cose. Il 2020 è stato un vero e proprio “Annus Horribilis”, molti scenari sono mutati in modo irreversibile. Pur non avendo la “sfera di cristallo” quali potrebbero essere, a suo parere, le conseguenze e le implicazioni per il mondo dell’IoT?

A mio avviso ci sarà un deciso rafforzamento di questo mondo. A noi tutti ora è chiaro quanto sia di importanza fondamentale il poter gestire da remoto innumerevoli dispositivi, da quelli essenziali ai più banali. In SECO stiamo portando avanti “Biorespira”, un nostro progetto in campo medicale. Nelle condizioni di emergenza che abbiamo vissuto, respiratori o apparati simili, gestibili a distanza da un medico che possa ricevere informazioni da più pazienti in tempo reale, diventano strumenti irrinunciabili.

Grazie, Ingegner Caporali, per il tempo che ci ha dedicato! Dopo aver stimolato la curiosità e lo spirito creativo dei nostri lettori, ci aspettiamo domande e richieste di approfondimento sulla realizzazione di progetti che possano popolare l’universo IoT attraverso la flessibilità delle piattaforme, dei prodotti e del supporto forniti dalla vostra azienda.

A chi rivolgersi?
https://www.seco.com/it/contattaci

“Maurizio Caporali è co-CEO SECO Mind e cofondatore e Product Manager di UDOO (www.udoo.org).
La sua formazione, quale PhD in ICT, spazia dalla consulenza in information technology, al design di servizi e applicazioni AI, Web, Mobile e IoT. I suoi interessi di ricerca includono il physical computing, l’intelligenza artificiale, l’Internet delle cose, l’interaction design e i servizi mobili.
Attualmente è coinvolto nella gestione del ciclo di vita dei prodotti Clea, UDOO e nello sviluppo di soluzioni AI & IoT industriale e in numerosi progetti riguardanti la progettazione di nuovi prodotti tecnologici per il mercato dei sistemi di automazione embedded, Smart Device, Wearable e Internet of Things.”