Cosa bisognerebbe sapere quando si specifica un MCU Wi-Fi-enabled

Di Alex Li, Microchip Technology

All’evolvere dell’Industrial IoT, la tendenza è quella dell’esecuzione di più funzioni in un singolo SoC, anziché in più dispositivi discreti perché in questo modo il risultato è una distinta base più contenuta, con meno rischi di progettazione, un ingombro ridotto, ed altri vantaggi. Un eccellente esempio è l’MCU Wi-Fi che integra la connettività Wi-Fi con un processore e il GPIO necessario per soddisfare le esigenze di una vasta gamma di applicazioni. Ci sono molteplici fattori da considerare quando si specifica uno di questi dispositivi e, nel fare una scelta oculata e prudente, è importante averne approfondita comprensione.

Oggi sul mercato esistono opzioni di connettività Wi-Fi a basso costo, ma spesso hanno limiti per quanto riguarda il numero massimo di periferiche e nel loro utilizzo in generale. Ciò significa che scegliere il miglior MCU Wi-Fi è impegnativo oltre che rischioso perché un MCU Wi-Fi non deve avere solo una connettività Wi-Fi robusta ma anche funzionalità MCU ad alte prestazioni. La mancanza di entrambi causerà il ritardo dell’intera progettazione e persino il suo fallimento. Quale nucleo del sistema, l’MCU è la parte più critica dell’MCU Wi-Fi, quindi è necessario esaminarne le prestazioni all’inizio del progetto perché il cambio di dispositivo in un secondo momento richiederebbe, generalmente, la riprogettazione di tutto il software e la configurazione del relativo circuito.

Non dimentichiamo l’ADC

La conversione da analogico a digitale è una delle funzioni più trascurate quando si specifica un MCU Wi-Fi, anche se è il primo componente di elaborazione nella catena del segnale dopo l’ingresso analogico. Ciò significa che le sue prestazioni riguardano l’intero sistema, quindi è importante comprendere le metriche chiave del analog-to-digital converter (ADC) e come il produttore dell’MCU Wi-Fi dovrebbe affrontarle.

[boris]

Una delle prime specifiche su cui si concentrano i progettisti è il numero di bit dell’ADC. Questo può essere fonte di confusione perché in pratica il numero effettivo di bit sarà inferiore alla specifica del datasheet, a volte anche in modo sostanziale. La cosa più importante è il numero effettivo di bit (ENOB) che l’ADC ha a disposizione per eseguire la conversione. Questo sarà invariabilmente inferiore alle specifiche del datasheet, ma la corrispondenza delle specifiche ENOB e della scheda dati più vicina possibile è molto importante perché è un dato che varia notevolmente tra gli ADC. Minori sono i bit disponibili per eseguire la conversione, meno precisamente il SoC rappresenterà il segnale di ingresso.

Inoltre, come tutti i dispositivi elettronici, gli ADC “contribuiscono” al segnale che influisce negativamente sulle loro capacità, inclusi errori quali quantizzazione e temporizzazione, nonché variazioni di offset, guadagno e linearità. Gli ADC sono anche noti per la loro sensibilità ad ampi sbalzi di temperatura che sono comuni in molti ambienti operativi IoT industriali (ved. Figura 1). Il produttore dell’MCU Wi-Fi può mitigare questo problema, quindi è importante contattare i produttori di ciascun MCU Wi-Fi candidato per determinare il loro ENOB, le prestazioni nell’arco elle temperature di esercizio, la linearità e l’accuratezza. Se queste informazioni non possono essere fornite, passa oltre.

Figura 1. Gli ADC di bassa qualità hanno scarsa precisione e linearità e sono sensibili alle condizioni ambientali e alle temperature.

Supporto per periferiche

Tutti gli MCU Wi-Fi supportano almeno alcuni standard di interfaccia, quindi è facile convincersi che saranno sufficienti. Gli ingegneri spesso si pentono di aver accreditato questa ipotesi quando tentano di utilizzare lo stesso MCU Wi-Fi in un altro progetto. Questo è sempre più comune quando si costruiscono o si modificano sistemi Industrial IoT perché la maggior parte degli impianti di produzione dispone di un’ampia gamma di macchine e controller costruiti in tempi diversi da una varietà di produttori.

E man mano che il sistema cresce, è probabile che si aggiungano ancora più interfacce, e potrebbe quindi arrivare un momento in cui sarà necessario il supporto per funzionalità come il rilevamento tattile ed LCD. Se il SoC ha GPIO inutilizzato, è possibile controllare più relè, interruttori e altri componenti con una condivisione minima o nulla dei pin. Per questo motivo, le interfacce supportate dal dispositivo dovrebbero includere Ethernet MAC, USB, CAN, CAN FD, SPI, I2C, SQI, UART e JTAG (e potenzialmente tattile e supporto per display) per garantire che praticamente qualsiasi scenario possa essere adattato, ora o in un prossimo futuro.

La Sicurezza inizia da dentro

La sicurezza è essenziale per ogni applicazione IoT, ma gli scenari industriali sono assolutamente mission-critical. Una volta che una minaccia si sia fatta strada in una rete Industrial IoT, può spostarsi in un’intera struttura e credibilmente in un’intera azienda. Il primo livello di sicurezza richiesto è all’interno del motore crittografico integrato dell’MCU, in cui la crittografia e l’autenticazione vengono eseguite in sequenza o in parallelo. I cifrari dovrebbero includere la crittografia AES con chiavi di dimensioni fino a 256 bit, DES e TDES e l’autenticazione dovrebbe includere SHA-1 e SHA-256 e MD-5.

Poiché ogni fornitore di servizi cloud ha la propria certificazione e le proprie chiavi, e il provisioning del dispositivo per loro è complesso, ciò richiede una notevole conoscenza della crittografia ed è uno dei compiti più impegnativi quando i progettisti forniscono il loro prodotto per un servizio cloud. Fortunatamente, alcuni produttori, tra cui Microchip Technology, rendono questo processo semplice, facendo risparmiare enormi quantità di tempo e denaro. La riduzione di tempo e confusione che derivano dall’approccio non possono essere sopravvalutate: è possibile eliminare settimane o più dal processo di progettazione, garantendo al contempo che tutti i requisiti di sicurezza e provisioning siano soddisfatti con un approccio comprovato e verificabile.

È importante notare come la maggior parte degli MCU Wi-Fi archivia le credenziali nella memoria flash in cui i dati sono accessibili e vulnerabili nei confronti di attacchi software e fisici. La massima sicurezza si ottiene memorizzando queste informazioni in un elemento di sicurezza codificato perché i dati al suo interno non possono essere letti da alcun software esterno. Ad esempio, gli MCU Wi-Fi di Microchip, come WFI32 (Figura 2), utilizzano questo approccio nella piattaforma Trust&GO dell’azienda per il provisioning sicuro dei suoi MCU per la connessione ad AWS IoT, Google Cloud, Microsoft Azure e reti TLS di terze parti.

Gli elementi di sicurezza preconfigurati, con provisioning preeseguito, o personalizzati, archiviano le credenziali generate all’interno degli Hardware Secure Modules (HSMs) del dispositivo al momento della produzione, isolandole dall’esposizione durante e dopo la produzione. La piattaforma Trust-and-Go richiede solo un kit di sviluppo Microchip, economico, in cui il progettista lavora all’interno della suite di progettazione inclusa utilizzando tutorial ed esempi di codice per creare il file manifest richiesto. Una volta che il codice C per l’elemento protetto funzioni nell’applicazione, il progetto potrà essere inviato alla produzione.

L’altra forma di sicurezza richiesta è la più recente sicurezza Wi Fi certificata da Wi-Fi Alliance. L’ultima versione è WPA3 che si basa sul suo predecessore WPA2, e aggiunge funzionalità per semplificare la sicurezza Wi-Fi, consentire un’autenticazione più robusta, fornire una maggiore forza crittografica e mantenere la resilienza della rete. Tutti i nuovi dispositivi devono essere certificati WPA3 per poter utilizzare il logo Wi-Fi Alliance, quindi ogni chip Wi-Fi e MCU Wi-Fi dovrebbero essere certificati per la massima sicurezza. Tuttavia, assicurati che l’MCU Wi-Fi candidato sia effettivamente certificato WPA3.

Assicurare l’interoperabilità

È sempre possibile che un MCU Wi-Fi non sia in grado di comunicare con alcuni punti di accesso presenti sul mercato a causa di una mancata corrispondenza di RF, software e altri fattori. La mancata connessione ad access point tra i più diffusi potrebbe danneggiare la reputazione di un’azienda. Sebbene sia impossibile garantire che un MCU Wi-Fi funzioni con qualsiasi access point (AP) del pianeta, il problema può essere ridotto al minimo assicurandosi che l’MCU Wi-Fi abbia superato i test di interoperabilità con gli AP più diffusi sul mercato. Queste informazioni possono essere trovate sui siti Web dei produttori, ma se non fossero prontamente disponibili, chiama il produttore e chiedi e, se non ti vengono date, scegli un altro fornitore.

Ti servirà aiuto

Ultimo, ma sicuramente non meno importante degli altri punti, è la necessità di supporto alla progettazione. Senza una piattaforma IDE (Integrated Development Environment) completa, il progettista deve mettere insieme le risorse del Web che possono o meno essere utili, semplici o affidabili. Ad esempio, alcuni produttori di MCU Wi-Fi forniscono informazioni di base sul prodotto e istruzioni per la prototipazione, ma si fermano qui anziché includere le informazioni necessarie per spostarlo da questa fase alla produzione.

Per essere veramente utile, il produttore dovrebbe fornire un IDE completo, come in Figura 3, che includa ogni funzione analogica e digitale eseguita dall’MCU Wi-Fi e tutti i componenti esterni necessari per l’implementazione in applicazioni specifiche. Dovrebbe fornire un mezzo per visualizzare come le modifiche al progetto si riflettono nelle prestazioni complessive e la capacità di valutare le prestazioni RF del progetto, nonché la conformità normativa. Alcuni degli strumenti di base sono gratuiti mentre altri sono disponibili ad un costo modesto, comprese le schede di valutazione progettate per servire la famiglia di MCU Wi-Fi del produttore.

Riassumendo

La tendenza nell’IoT è quella di spostare una maggiore potenza di elaborazione sull’Edge della rete anziché esclusivamente nei data center basati su Cloud. Per ottenere ciò, è necessario integrare quante più funzioni possibili nel minor spazio e componenti possibili. L’MCU Wi-Fi è uno dei tanti SoC che fanno molto per raggiungere questo obiettivo integrando più funzioni in un singolo dispositivo anziché in componenti discreti specifici per funzione.

L’integrazione di questi dispositivi in un sottosistema IoT  embedded  può essere relativamente semplice, supponendo che siano disponibili risorse adeguate dal produttore dell’MCU Wi-Fi. Ciò include un alto livello di sicurezza, un mezzo semplice per fornirlo per soddisfare le esigenze dei fornitori di servizi cloud e un IDE completo che guida il progettista dal prototipo alla produzione.

[/boris]