Uno dei costi principali, anche se spesso nascosto, di un'applicazione IoT può essere quello dell'installazione, in particolar modo nel caso di nodi sensore che devono essere posizionati in locazioni difficilmente accessibili. Ciò impone alcuni vincoli al progetto del dispositivo embedded che, molto spesso, deve essere il più compatto possibile. Un altro fattore da tenere in considerazione è il consumo di energia. Molto probabilmente, non ci sarà la possibilità di fornire potenza attraverso la rete elettrica. Il sistema, invece, dovrà funzionare per l'intera vita operativa (solitamente di parecchi anni) sfruttando la carica immagazzinata in una batteria primaria. Dal punto di vista del progetto embedded questi due fattori tendono a favorire l'utilizzo di una soluzione basata su SoC, che si propone come l'approccio più valido. In questo modo quasi tutte le funzionalità del nodo sono integrate in un unico dispositivo. Un'implementazione basata su SoC minimizza la quantità di energia elettrica necessaria per la comunicazione tra i vari sottosistemi. Oltre a ciò, i moduli possono essere progettati per cooperare in modo da minimizzare il consumo di potenza a livello di sistema.
L'ampiezza di banda di comunicazione rappresenta un ulteriore vincolo. In locazioni remote potrebbero essere richiesti livelli di potenza RF elevati al fine di garantire che i dati possano raggiungere un gateway in modo affidabile. I progettisti quindi non solo devono selezionare protocolli caratterizzati da un elevato livello di efficienza ma tener conto anche della quantità di dati che deve essere trasmessa dal nodo. In molti casi i dati provenienti dal sensore e ricevuti dal nodo indicano un funzionamento normale. Quindi non esiste la necessità di continuare a inviare dati al cloud che riportino questo stato, consumando precocemente l'energia della batteria. Al contrario, è importante che siano rilevate e segnalate variazioni significative delle prestazioni. In molti casi, condizioni di questo tipo sono rappresentate non da un improvviso mutamento di una variabile, bensì da una combinazione di fattori.
L'elaborazione di tipo più avanzato entra in gioco in situazioni di questo tipo. In ogni caso è possibile delegare analisi di questo tipo a un nodo IoT facendo attenzione a bilanciare le risorse di elaborazione richieste e il loro impatto sul consumo di potenza complessivo. Un software efficiente che gira su un dispositivo che supporta funzionalità di elaborazione congiunta (coprocessing) permette di effettuare la maggior parte delle analisi senza richiedere il coinvolgimento di un server remoto. Un ulteriore vantaggio legato al trasferimento dell'elaborazione alla periferia è rappresentato dal fatto che un nodo IoT può far fronte al problema in maniera autonoma nel caso di guasto della connessione o nel momento in cui sorgono problemi di congestione sulla rete stessa.
Ogni volta che il nodo decide che le variazioni abbiano un'importanza tale da essere notificate a un gateway o a un server, esso può includere informazioni relative al comportamento sul lungo termine per favorire l'aggiornamento degli algoritmi di apprendimento automatico che potrebbero essere impiegati nel gateway locale o in un server remoto. Il costo aggiuntivo da sostenere per l'aggiunta di una modesta quantità di dati a un pacchetto che deve essere inviato è molto inferiore a quello richiesto per inviare i dati nei loro pacchetti non appena disponibili i dati.
Questa è solo una delle numerose decisioni a livello di sistema che avranno un effetto a catena sull'efficienza di un progetto di un dispositivo per la periferia della rete. Poiché sono parecchie le decisioni di questo tipo che è necessario prendere, è importante poter attingere all'esperienza di persone che hanno maturato un significativo know-how nella progettazione di un certo numero di dispositivi di questo tipo.
SoC: criteri di scelta
Sebbene un SoC rappresenti spesso la scelta più idonea per un nodo periferico, un aspetto da tenere presente è il tipo di SoC da utilizzare. Non è affatto necessario che sia un componente standard (off-the-shelf). In molti casi, l'utilizzo di un SoC di questo tipo non soddisfa i requisiti dell'applicazione finale, specialmente nel caso in cui è necessario tenere in considerazione fattori che vanno al di là della semplice funzionalità. Un problema chiave che i progettisti devono oggigiorno affrontare, specialmente nel momento in cui decidono di utilizzare SoC standard come nucleo centrale di un progetto, è la relativa semplicità con la quale è possibile effettuare il reverse-engineering della soluzione. Poiché i produttori devono fare in modo che i SoC soddisfino le esigenze del maggior numero possibile di sviluppatori, le loro mappe dei registri e i set di istruzioni si possono ottenere con facilità. Un altro aspetto sempre correlato all'uso di dispositivi prontamente disponibili è la necessità, da parte dei produttori, di concentrare la loro attenzione sui nodi di processo della generazione attuale al fine di trarre vantaggio dai costi NRE sostenuti durante lo sviluppo del core del processore del SoC, per cui non viene valutata la possibilità di beneficiare della riduzione dei costi associata all'uso di geometrie di processo meno recenti ma ancora in grado di garantire prestazioni di assoluto rilievo. Anche se il codice del programma fondamentale memorizzato a bordo del chip è cifrato e decifrato solo immediatamente prima dell'esecuzione, spesso è possibile utilizzare le porte di debug standard per tracciare il comportamento del programma ed estrarre il software memorizzato all'interno.
Un approccio alternativo prevede la realizzazione di un progetto basato su un SoC di tipo custom. Un approccio di questo tipo dà l’opportunità di utilizzare espansioni hardware che rendono più difficoltosa l’operazione di reverse-engineering. Oltre a ciò, un progetto di tipo custom può far ricorso a tecniche contro la manomissione che complicano notevolmente le operazioni finalizzate a estrarre il firmware interno oppure determinare la modalità di funzionamento del dispositivo e quelle pertinenti all’applicazione. Per gli utenti di SoC standard esiste un ulteriore problema. Anche quando un progetto è stato completato è il sistema è stato spedito, la pianificazione può essere letteralmente “sconvolta” dal fatto che un produttore di SoC decida di non fornire più il supporto per l’implementazione rendendo di fatto il componente obsoleto. Per affrontare un sistema di questo tipo è necessario immobilizzare del capitale per fare ingenti acquisiti di componenti per i quali è stata decretata la “EoL” (End of Life), correre il rischio di approvvigionarsi al cosiddetto mercato grigio (ovvero canali di distribuzione diversi da quelli autorizzati o da quelli pensati dal produttore o fabbricante) oppure effettuare un costoso porting su un SoC differente che potrebbe non avere il giusto mix di caratteristiche o risultare troppo costoso per la produzione in volumi a causa della presenza di un gran numero di core o interfacce non necessarie. Un SoC di tipo custom permette all’utilizzatore di avere il pieno controllo della fornitura. Le fonderie molto difficilmente dismettono le produzioni relative ai nodi di processo, specialmente dei nodi maturi e per i quali sono disponibili numerose risorse come quelli attualmente utilizzati per lo sviluppo dei progetti IoT. Le risorse comprendono un ampio supporto per circuiti analogici, digitali e RF finalizzato a favorire l’integrazione degli I/O, minimizzando il tal modo dimensioni e costo del prodotto finale. Con un SoC di tipo custom, i team di progetto possono scegliere interfacce hardware che supportano il software in modo efficace (software-friendly) invece di basarsi su decisioni progettuali fatte da ingegneri che potrebbero aver focalizzato l’attenzione su applicazioni differenti. Un’interfaccia hadware/software efficace permette non solo di ridurre il time to market ma anche di migliorare la manutenibilità del sistema complessivo. Questo obiettivo può essere raggiunto tramite lo sviluppo di un SoC per il quale la mappa dei registri e della memoria è stata pianificata con cura ed è stata esaminata preventivamente insieme con gli sviluppatori software.
Il problema dei consumi
Nei dispositivi per la periferia delle reti IoT, inoltre, il consumo di energia dipende spesso in larga misura dalle modalità secondo le quali il software interagisce con gli eventi che si verificano a livello hardware. Gli sviluppatori software possono fornire validi suggerimenti per la gestione delle periferiche che contribuiscono a limitare il consumo di potenza. Le macchine a stati per la gestione delle periferiche durante le modalità di “sleep” possono contribuire in maniera significativa a incrementare l’efficienza del software in quanto non costringono l’RTOS a effettuare frequentemente operazioni di interrogazione per verificare se hanno dati da trasmettere. Una periferica “intelligente” è in grado di intercettare gli I/O e memorizzarli temporaneamente utilizzando tecniche quali DMA (Direct Memory Access) mentre il core del processore è in modalità “sleep”, in modo da incrementare l’efficienza energetica del nodo IoT. Nel caso un ingresso superi una soglia prestabilita, la macchina a stati può rilevarlo e svegliare il processore perché questi possa analizzare la condizione.
Elaborazioni più avanzate che possono ridurre l’overhead imputabile al software includono l’implementazione di operazioni di crittografia in hardware. Ciò non solo contribuisce a diminuire il consumo di energia delle operazioni di cifratura e decifratura, sempre più importanti per le applicazioni IoT, ma anche a ridurre i rischi che il progetto possa venire in qualche modo compromesso. Utilizzando hardware specializzato, è più semplice mettere a punto contromisure efficaci contro attacchi di tipo “side-channel” o minacce simili. Altri co-processori per l’analisi dei dati possono essere progettato in sinergia con il team che si occupa dello sviluppo software in modo da assicurare che tutte le operazioni finalizzate a ridurre consumi, tempi e costi siano implementate nel miglior modo possibile nel progetto.
Un approccio basato su piattaforma
S3 Semiconductors, per esempio, ha fissato un nuovo traguardo nello sviluppo di SoC custom proponendo un approccio basato su piattaforma per la realizzazione di SoC destinati ad applicazioni alla periferia di IoT/IIoT. La piattaforma Smart Edge integra tutti i blocchi base necessari (Fig. 1) con l’obiettivo di fornire un SoC custom su chip singolo ottimizzato. Grazie ai blocchi IP AFE (Analog Front End) specifici che supportano differenti tipi di sensori, i progettisti di sistema possono ottimizzare le prestazioni di ciascun sensore (Fig. 2).
Il risultato è un SoC ottimizzato per soddisfare al meglio le esigenze dei costruttori di sistemi o nodi IoT in termini di funzionalità, sicurezza, costo ed efficienza energetica. Il supporto di personale specializzato nell’implementazione di SoC che può fornire validi suggerimenti su diversi aspetti – processo, architettura di sistema, progetto del circuito e infrastruttura software – assicura il buon esito del progetto.
