EMB_58

EMBEDDED

58 • novembre • 2015

hardware

HSA

rispetto al decennio precedente, passando a due mi-

liardi di dispositivi connessi (2) . Ora siamo nella terza

fase, che prevede che entro il 2020 vi saranno almeno

33 miliardi di unità connesse, 26 milioni delle quali

saranno dispositivi IoT (3) .

Mentre la domanda di reti “one-to-one” cresce in ma-

niera esponenziale, le risorse di elaborazione per tutti

questi dispositivi e nodi non segue il medesimo an-

damento. Ciò significa che la modalità con cui deve

essere architettata l’infrastruttura per soddisfare le

esigenze delle applicazioni IoT sarà diversa da quel-

la finora adottata. Il primo problema da affrontare è

re-immaginare l’architettura della rete stessa. Una

possibilità è riportata in figura 1.

Vivere “in periferia”

A questo punto è utile esaminare com’è “architetta-

to” l’IoT – se questo è il termine corretto poiché essa

attualmente si sviluppa seguendo una modalità “ad

hoc”, dai nodi alla periferia per arrivare al cloud. Non

è esatto affermare che tutto viene eseguito nel cloud e

che il modello “client-to-cloud” è quello più adatto per

le applicazioni IoT. Non bisogna dimenticare i 26 mi-

liardi di nodi appena sopra menzionati e considerare

l’eventualità che tutti i dati – provenienti da un ter-

mostato, un sensore del flusso veicolare, una fabbrica

automatica o una telecamera di sorveglianza – ven-

gano trasferiti al cloud.

Tutti questi dispositivi hanno esigenze molto diver-

se tra di loro. Alcuni potrebbero richiedere una bassa

latenza, altri un’elevata ampiezza di banda, altri an-

cora potrebbero aver bisogno di comunicare solo rara-

mente. Più in dettaglio, nell’ambito dell’automazione

della “casa intelligente”, per l’apertura o la chiusura

della saracinesca di un garage è sufficiente un segna-

le binario. In questo caso si potrebbe ricorrere a un

segnale di frequenza pari a 1 Hz o superiore. La si-

tuazione cambia radicalmente nel caso di un veicolo

autonomo, che ha requisiti completamente differen-

ti in termini di dati, latenza a affidabilità (si faccia

riferimento sempre alla Fig. 1). Esso infatti invierà,

sfruttando la tecnologia IoT, i dati telemetrici in mo-

dalità “fault tolerant” nell’arco di pochi millisecondi

(o in un tempo ancora inferiore). Se si aggiungono i

dati provenienti da numerosi altri veicoli unitamente

a quelli del traffico che arrivano via Internet attraver-

so Skype, Netflix, YouTube o altre fonti, è chiaro che

l’invio repentino di questa mole di dati è un problema

di non semplice soluzione, specialmente nel caso il

veicolo autonomo in questione si aspettano una rispo-

sta in tempi molto brevi. La topologia della rete e la

distribuzione di risorse di elaborazione dovranno es-

sere differenti con l’avvento della tecnologia IoT. Qua-

lunque sia l’applicazione – stabilimento, abitazione o

infrastrutture – iniziano ad apparire nuove tecnolo-

gie in prossimità della periferia della rete grazie alle

quali sarà possibile prendere decisioni locali evitando

così l’inoltro verso il cloud.

Largo al video

Si consideri adesso un data center. Nel caso si dispon-

ga di una soluzione IoT alla periferia della rete, dif-

Fig. 2 – In una topologia IoT evoluta non è prevista la connessione di ciascun nodo al cloud: le

connessioni sono invece effettuate o meno in funzione delle risorse e dei requisiti di comunicazione