Nel tempo le evoluzioni delle capacità di trasmissione dati hanno preceduto le esigenze degli utenti; in altre circostanze, al contrario, le hanno inseguite. Per comprendere il fenomeno può essere di aiuto rifarsi al filosofo Giambattista Vico, che già nel XVII secolo (ne La Scienza Nuova – 1), aveva formulato, osservando le vicende storiche, la teoria dei corsi e ricorsi storici, dove gli avvenimenti si ripetono uguali, ma anche diversi, in una sorta di percorso ascensionale che ripiega e poi si dilata in qualcosa di diverso e nuovo. La analisi e la conoscenza di essi comunque ci può permettere di anticipare e intervenire su certi fenomeni migliorandoli.
Premetto che riportando questi “principi” nel campo delle tecnologie e delle relative rivoluzioni, sicuramente ci troviamo in un momento di dilatazione. Osservando il contesto più specifico dell’IoT e della sua evoluzione siamo nella situazione in cui Cloud e Things, nel senso di risorse di elaborazione e sensori/attuatori, non sono sufficienti con le loro capacità a sostenere diverse applicazioni: occorre cioè fare i conti con le capacità trasmissive, in senso lato come velocità, banda e tempi di latenza.
Cerchiamo a questo proposito di analizzarne la storia dell’evoluzione in questo campo. Nelle fasi iniziali della digitalizzazione e del “computing”, le applicazioni erano a caratteri e per lavorare con un terminale collegato in remoto erano più che sufficienti velocità trasmissive di 600/1200 bit/sec. Nel mondo Enterprise, con l’avvento del pc la prima esigenza per un utilizzo integrato nel sistema informativo di una azienda, è stata quella di un trasferimento asincrono di dati, i ben noti file transfer. Successivamente è nata l’esigenza della collaborazione e quindi della condivisione di file: per le dimensioni degli stessi non era possibile la condivisione in remoto ma solo in locale. Sono quindi state introdotte le reti locali, molto spesso accompagnate da un collegamento del server/gateway attraverso una connessione remota, con i Data Center.
Indice degli argomenti
Tre livelli per il Data Center
Le architetture delle applicazioni, quando accedevano a dati Enterprise posizionati nei Data Center, erano tipicamente a tre livelli proprio per superare la scarsa velocità di rete insufficiente per la quantità di dati richiesti più che di risorse di elaborazione.
Il primo livello era quello sul PC che conteneva l’applicazione locale con interfaccia grafica (GUI), molto più gradevole e accessibile rispetto a quella a caratteri, un terzo livello posizionato nel Data Center dove risiedevano i voluminosi Data Base e un livello intermedio che oltre alla funzione di gateway svolgeva una funzione di elaborazione locale soprattutto per superare i problemi di velocità della rete.
Ovviamente questa architettura introduceva problematiche di allineamento dati tra il server e i dati centralizzati. Esisteva anche una architettura a due livelli che però si è dimostrata per molte applicazioni impraticabile in quanto ad esempio le query al Data Base erano direttamente invocate dal client generando così la trasmissione di una gran quantità di dati e, malgrado tecniche di paginazione, rallentava le applicazioni. Inoltre esisteva anche un problema di distribuzione del software sul PC e sul Server che arichiedeva a sua volta una banda importante.
Con l’arrivo di Internet in un certo qual modo siamo ritornati ad un collegamento centralizzato in cui però l’interfaccia a caratteri è stata sostituita da una interfaccia user-firendly e grazie alle capacità elaborative locali, senza richiedere praticamente l’installazione di software in locale, si è aperto un nuovo mondo soprattutto di sviluppo e diffusione rapido delle applicazioni grazie alla semplicità del sistema. Contemporaneamente le capacità trasmissive di rete sono aumentate consentendo di poter trattare in tempo reale file multimediali, con qualità sempre migliore.
Quindi si è passati da una architettura a 2 livelli, terminale Mainframe, ad una a 3 livelli, e di nuovo ad una a 2 livelli migliore della prima. Più o meno questa situazione permane anche oggi con qualche novità infrastrutturale quale il Cloud e qualche problema non da poco indotto dalla sicurezza (Cybersecurity). Tutto ciò è rappresentato in maniera qualitativa nel grafico seguente.
Non vi sembra che questo sia un andamento che ricorda la teoria di Vico?
Internet of Things da due a tre livelli
Arriviamo ai giorni nostri: le applicazioni IoT sono partite adottando sia uno schema a 2 livelli che uno schema a 3 livelli con la tendenza a semplificare e alla connessione diretta a basso consumo. Se si guarda il campo industriale (di strettissima attualità grazie al fenomeno Industria 4.0) le applicazioni tipicamente si richiudevano nell’ambito locale in quanto era richiesta più che una capacità trasmissiva, una affidabilità che la rete non poteva garantire, quindi una architettura a due livelli e locale. È il mondo degli Scada e dei PLC progressivamente sostituito dalle architetture IoT dove con lo sviluppo anche di protocolli trasmissivi Low Power che coprono distanze geografiche interessanti e capillari si potrebbe privilegiare una architettura più semplice a due livelli remota.
Il ruolo del Fog Computing
Ma non è così sempre, esistono applicazioni che richiedono tempi di risposta rapidi e bassi tempi di latenza, ad esempio inferiori ai 5 millisecondi garantiti distribuiti geograficamente. In questo caso la distanza, dove il limite è costituito dalla velocità fisica di propagazione dei segnali e il tempo di latenza dei sistemi soprattutto mobili, possono costituire un limite importante. Ed ecco quindi che diventa necessario introdurre un livello intermedio, il Fog Computing (2, 3, 4). Un altro motivo è costituito dalla gran quantità di dati che viene prodotta da sensori e che ha bisogno di essere elaborata a livello locale per varie ragioni: o perché o deve essere elaborata rapidamente, in real time, cioè in un tempo utile per la gestione dell’applicazione oppure deve essere filtrata, eventualmente anche verificata, al fine di evitare di inserire nei Data Lake aziendali gran quantità di dati inutili.
Tra Edge e Cloud
In questi casi anche l’elaborazione dati è distribuita tra computer locale di prossimità ai bordi della rete, l’Edge, e quello centrale su Cloud. Con questa modalità si ha a che fare con una soluzione basata su una risorsa elaborativa che sostituisce per molti servizi il Cloud sostanzialmente per ottemperare ai limiti della capacità della rete di assicurare tempi di latenza bassi e affidabilità elevata di connessione.
L’adozione di un livello intermedio può sembrare una medicina da inghiottire e dei soldi da spendere in più per una deficienza, probabilmente temporanea, potendo prevedere nel futuro il superamento di questi problemi. In questo scenario il progettista deve studiare attentamente le applicazioni da sviluppare con l’ottica semplificativa di effettuare la scelta più idonea ed economica relativamente alla architettura.
Ma ritornando a Vico ecco che da una architettura a due livelli siamo passati, in questo campo, ad una a 3 livelli e ancora una volta migliorando in quanto i sensori sono a basso costo, le possibilità di comunicazione locale sono per lo più wireless e con coperture più ampie, gli ambienti operativi e di sviluppo su Edge sono sempre più simili o uguali a quelli presenti su Cloud, diventando esso stesso un piccolo Cloud, una proiezione di quello centrale sulle “nuvolette distribuite”, permettendo quella interazione tra cose, persone e macchine che sono una delle caratteristiche proprie dell’IoT.
Cosa ci attenderà il prossimo futuro?
Probabilmente si ritornerà a sistemi a due livelli quasi ovunque dove il serio limite è quello fisico della propagazione dei segnali una barriera insuperabile che ha frenato la stessa legge di Moore. Oppure si passerà a “things” sempre più dotate di intelligenza artificiale che saranno già in grado di effettuare delle elaborazioni, l’Internet delle Intellligent things, l’IoTT(5), consentendo così di immergersi veramente in una nebbia (Fog) dove persone e cose si confonderanno (Blurring). In questo caso i device collaboreranno tra di loro senza l’intermediazione di “cervelli” centralizzati ma comunque con un legame con Cloud remoti: vivranno in “bolle” di intercomunicazione insomma, ritornando a Vico, un ritorno evoluto delle Lan.
1. Scienza Nuova, Giambattista Vico, 1732. G.Pellegrino
2. Fog Computing and the Internet of Things: Extend the Cloud to Where the Things Are (PDF), cisco.com
3. The Fog Computing Paradigm: Scenarios and Security Issues – 2014 – Ivan Stojmenovic, Sheng Wen
4. Fog Computing: A Platform for Internet of Things and Analytics – 2014 – Flavio Bonomi, Rodolfo Milito, Preethi Natarajan
5. L’Internet of Thinking Things, l’IoTT – 2017 – Giovanni Pepicelli
Giovanni Pepicelli, Digital Transformation, Enel Global ICT
