Premessa

Questo è il secondo post di una serie dedicata all’Internet delle Cose nell’ambito più ampio dell’Industria 4.0. Il primo ha coperto, oltre ad una breve introduzione all’argomento, i criteri di scelta del sistema operativo e del software associato, mentre l’intervento di oggi toccherà gli aspetti hardware tentando di chiarire i criteri con cui scegliere la piattaforma IoT giusta per il proprio prodotto. Vale per questo come per il post precedente l’approccio metodologico di non trattare Arduino e piattaforme su cui giri Linux per i motivi già menzionati in quest’ultimo.

 

L’hardware

A questo punto serve qualche chiarimento: ciascuna delle sezioni hardware seguenti descrive un chip, il quale proviene da un singolo costruttore e va acquistato all’ingrosso da terze parti o da distributori autorizzati. Di solito non viene fornito con strumenti in grado di immagazzinare codice o interagire col mondo esterno.  Un modulo invece è un prodotto basato sui succitati chip, aggiungendo caratteristiche come la capacità di immagazzinare dati in maniera persistente, antenne WiFi/Bluetooth integrate, e così via.  I moduli sono rilasciati da produttori diversi ma usano lo stesso chip. Di prassi i suddetti moduli sono versioni prodotte su larga scala del design di riferimento del costruttore del chip, quindi per componenti hardware comuni c’è solitamente ben poca differenza fra i vari moduli, fatta eccezione per il prezzo. Una scheda può contenere un chip o un modulo ma fornisce in più cose come diversi modi di alimentare l’hardware, connettori e pin per collegarvi hardware esterno, e via dicendo. A differenza dei moduli le schede possono variare molto da un costruttore hardware all’altro, e tendono ad essere adattate ad usi o esigenze specifiche. Una occhiata alle immagini qui sotto renderà tale concetto molto più chiaro:

[Chip] Atmel ATXMega 128A1 Photo By Springob – Own work, CC BY 3.0,

[Modulo] ESP8266 Photo By Sparkfun Electronics – CC BY 2.0

[Scheda] Wireless Internet of Things (WIOT) Board by ubld.it CC BY-SA 3.0

Dal punto di vista hardware scegliere la piattaforma giusta è un compito ancora più importante. Non va dato nulla per scontato in quanto soluzioni differenti possono sembrare inferiori comparate ad altre ma potrebbero essere del tutto adeguate al compito cui sono destinate. Concepire soluzioni IoT all’uopo è tutt’altra questione rispetto a idearne per uso generico, si prenda ad esempio la connettività WiFi:

I sistemi per uso generico oggigiorno sono tutti forniti di una qualche interfaccia WiFi che ci si aspetta semplicemente che “funzioni”. Ma la WiFi su dispositivi IoT è un altro paio di maniche. Si tengano a mente un paio di cose quando si sceglie quale chip utilizzare, sebbene nessuno ci penserebbe mai riguardo ad un dispositivo ad uso generico di questi tempi:

* Questo dispositivo è destinato ad un ambiente domestico o industriale? Nel secondo caso chip WiFi differenti possono avere antenne separate per la ricezione e la trasmissione, anche più di una. Si tenga conto che se il dispositivo deve agire come sensore o per acquisizione dati, per fare in modo di ridurre perdite di dati in uscita bisognerà procurarsi un chip che abbia due antenne per la trasmissione e una per la ricezione, ad esempio. Un disturbo da parte di un altro apparecchio può rendere irrealizzabili i design oltre un certo livello di complessità in quanto non sono resilienti verso le interferenze quanto gli elementi più semplici.

* Bisogna inoltre chiedersi quanti dati riceverà e trasmetterà il dispositivo. A differenza dei dispositivi per uso generico, la memoria è spesso scarsa e in tal caso due scenari negativi si prospettano su hardware di fascia bassa: o il firmware è troppo lento nel gestire i dati in ingresso, o è troppo veloce nel generare quelli in uscita. Nel primo caso si deve riuscire a gestire la perdita di dati, e pertanto si potrebbe aver bisogno di implementare un meccanismo di ritrasmissione dei dati se si ha bisogno di una bassa latenza, oppure passare a protocolli che lo facciano di per sé – a spese di un incremento di memoria o maggiore latenza. Nel secondo caso a seconda del sistema si potrebbe riscontrare un crash di sistema o l’impossibilità di trasmettere i dati senza che sia generato un messaggio di errore, dato che per quanto concerne al sistema operativo, l’unica cosa di cui preoccuparsi è il mandare i dati alla scheda di rete per la trasmissione (la cui coda d’invio è piena e i pacchetti finiscono nel nulla senza generare avvisi).

Tutto ciò va ad aggiungersi alle scelte tradizionali di design della parte elettronica, come il consumo di corrente, la dispersione di calore, i requisiti di voltaggio, e così via. Il design dell’hardware non è mai stato facile di suo ma se per un certo periodo ce la si poteva cavare con soluzioni generiche come computer a scheda madre singola con CPU x86 compatibile, di questi tempi clienti potenziali e non vogliono componenti più piccole e meno dispendiose – la qual cosa comporta lavoro extra nel selezionare le componenti che finiranno nel design finale.

Quelli fra di voi che erano attivi tra la seconda metà degli anni Ottanta e la prima dei Novanta possono paragonare senza problemi un simile scenario con quello degli home computer dell’epoca, quando c’era una pletora di sistemi diversi incompatibili fra di loro che si davano battaglia per una fetta di mercato – tutto ciò avveniva prima della standardizzazione verso il PC con cuore Intel. Per l’IoT siamo ancora alla fase “competitiva”, in cui soluzioni diverse incompatibili fanno del loro meglio per dominare il mercato. A titolo di esempio ecco una rapida lista di alcune CPU presenti sulle schede IoT:ARM, ARC, AVR, FT32, MIPS, NDS32 ), PIC, Super-H , x86 e Xtensa.  Alcune di esse sono ben note, come ARM e x86, ma si va anche verso soluzioni esotiche con esempi come NDS32 (la CPU dietro il modulo MediaTek MT7681 per dirne una), o FT32 – la quale è una architettura CPU nuova di zecca creata da FTDI per cui sono appena stati disegnati dei moduli.

 

Il post successivo di questa serie approfondirà le caratteristiche tecniche del chip ESP8266.

Guest post di Alessandro Gatti: consulente freelance IoT a Taiwan, in passato dopo aver esordito nello sviluppo di app J2ME nel 2003 ha lavorato fra gli altri come dipendente di Rakuten in Giappone (principale concorrente di Amazon in quel paese) e Opera a Taiwan e in Norvegia. Cura l’intero sviluppo in ambito embedded e su piattaforme iPhone/Android/Windows Phone, fino ad aspetti low-level come la programmazione in assembly o C del firmware e offre servizi di reverse engineering, coaching dei team di sviluppo, design di soluzioni Industry 4.0 dai tempi di SCADA e non solo. Editato da Fabrizio Bartoloni. Alessandro Gatti è stato uno dei relatori, in diretta Skype da Taiwan, all’evento UBG dedicato all’IoT il 22 febbraio presso Hub Corciano.