I fornitori di MCU rendono plug-and-play le connessioni IoT al cloud

La terminologia Internet è sempre stata vaga come la svolazzante linea chiusa che viene spesso usata per rappresentarla. Sappiamo, intuitivamente, che il cloud e l'Internet delle cose (IoT) sono espressioni diverse dello stesso concetto generale. Quando si progettano sistemi embedded, è essenziale operare una distinzione più chiara e capirne le conseguenze.

IoT è un sottoinsieme del cloud. Dal punto di vista dell'hardware, è popolato con sistemi embedded e altri dispositivi periferici come i telefoni cellulari, mentre l'elenco completo dell'hardware del cloud è costituito da server Web, server delle applicazioni, server di database, router, gateway, risorse informatiche e dispositivi periferici.

È facile per chi progetta sistemi embedded pensare al cloud semplicemente come un sistema che offre risorse di connettività per spostare i dati tra un dispositivo periferico e un server, un computer o un database. Inevitabilmente scopre che, mentre Internet potrebbe essere considerato "un semplice canale di trasporto" tra il sistema embedded e un server, lo stesso non può dirsi per il cloud. Se questa consapevolezza arriva verso le fasi finali del processo di progettazione può rivelarsi alquanto costosa ed è per questo motivo che, quando definiscono l'ambito dei propri progetti, i project engineer o i manager devono riuscire a coinvolgere parti ragionevoli per l'Information Technology o le operazioni IT.

Collegare i prodotti al cloud accresce l'impegno progettuale dei progettisti di dispositivi embedded, specie in termini di sicurezza e privacy. Oltre agli sforzi degli architetti del cloud di creare un sistema informativo universale e virtuale affidabile, occorre considerare il crescente numero di leggi che stabiliscono i requisiti di sicurezza e privacy. I motivi potrebbero essere più legati ai social media che non ai sistemi embedded, ma le stesse regole si applicano comunque a tutti i dati.

D'altra parte, sebbene i dati trasferiti su IoT potrebbero essere quantitativamente esigui rispetto ai petabyte che vengono scambiati ogni giorno tra i data center, i dati IoT sono particolarmente esposti a violazioni della sicurezza perché complessivamente alla fine controlleranno un numero estremamente elevato di dispositivi embedded nelle abitazioni private, nelle fabbriche e negli uffici.

Connessioni sicure

I tempi stanno cambiando per i progettisti di dispositivi embedded e, con essi, i paradigmi della progettazione. Si consideri ad esempio il fenomeno relativamente nuovo dei dispositivi embedded indossabili, come i dispositivi di monitoraggio wireless per il fitness e la salute quali i diffusi orologi per lo sport, i cardiofrequenzimetri o i contapassi che misurano i parametri di fitness.

L'attuale generazione di dispositivi indossabili comunica principalmente tramite Bluetooth con un telefono cellulare o un tablet, e quindi con un PC. Le connessioni col cloud sono per lo più gestite dal PC, che è dotato di sicurezze robuste. La sicurezza, come SSL/TLS, deve essere supportata e implementata a entrambe le estremità di una connessione.

La ratifica di Bluetooth Core Specification 4.1 cambierà tale stato di cose permettendo la connessione diretta del sensore con il cloud senza smartphone o PC in funzione di intermediario. Tra le altre cose, questo consentirà ai progettisti di dispositivi embedded di aggregare i dati di più sensori in modo da poter calcolare all'interno del cloud un rapporto completo sulla forma fisica e condividerli con altri sui siti dei social media a fini motivazionali.

I dispositivi presenti nelle abitazioni "intelligenti", nelle fabbriche, in siti di monitoraggio remoti e nelle auto connesse al cloud sono altri esempi di sistemi embedded che dovrebbero fornire quanto meno lo stesso livello di sicurezza dei computer. Internet richiede che i sistemi embedded prestino attenzione alle implicazioni della sicurezza e della privacy.

Dove le culture entrano in collisione

Mentre cambia la natura della connessione tra un sistema embedded e Internet, anche Internet si evolve. Un decennio fa la famosa chiocciola che rappresentava Internet si riferiva a un'infrastruttura hardware che era connessa ma non veramente integrata.

Nei diagrammi odierni, il cloud si riferisce a un'infrastruttura in cui le risorse vengono condivise al punto da poter essere considerate un'unica macchina virtuale. Questo accade malgrado la magia del software del cloud, che ci assoggetta a cloud pubblici, privati, ibridi e di comunità che sono tutti definiti e implementati dal software del cloud che li genera.

Le spiegazioni dettagliate del cloud esulano dallo scopo di questo articolo ma non il concetto che riguarda la scelta di un servizio cloud perché questo è il punto da cui parte un progetto collegato al cloud.

Data la complessità del software del cloud, la connessione a Internet tramite il cloud viene gestita da terze parti. Ad esempio, il 25% di quota di mercato detenuto da Amazon ne fa il fornitore più importante di servizi cloud IaaS/PaaS (Infrastructure as a Service/Platform as a Service).

La Figura 1 mostra la quota di mercato di società che forniscono infrastruttura cloud.


Un sistema embedded può ovviamente bypassare i fornitori del cloud e collegare Internet tramite un server Web esente da diritti d'autore che mette a disposizione siti Web dinamici in grado di servire più o meno contemporaneamente decine di migliaia di richieste. Una scelta tipica potrebbe essere LAMP, che sta per Linux (OS), Apache (server http), MySQL (gestione di database) e il linguaggio di scripting (PHP).

È tuttavia difficile pensare a un sistema embedded al riparo da una qualche attività illegale, illecita o semplicemente di disturbo. La vulnerabilità di un apriporta, che viene spesso usato come esempio di un sistema embedded basato su Web semplice ma utile, è ovvia. Meno ovvi sono, forse, i dispositivi presenti in una casa "intelligente". Ad esempio, le impostazioni del termostato potrebbero essere monitorate da malfattori pratici del Web per individuare le abitazioni delle famiglie in vacanza. Miliardi di dispositivi periferici IoT non monitorati potrebbero essere utili negli attacchi DoS (Denial of Service).

Da questo punto di vista, la mancanza di sicurezza robusta di un server LAMP ne fa una scelta inefficace per un server di produzione malgrado sia invece una buona scelta per uno sviluppo sul lato server.

Connessioni continue tramite i fornitori di MCU

Percorsi meno faticosi e molto più veloci per una connessione cloud sicura e robusta vengono offerti da fornitori di MCU che sfruttano le piattaforme informatiche messe a disposizione dai fornitori di cloud. È qui che i mondi dei progetti embedded e dell'IT si interfacciano.

L'unità base dei servizi basati su cloud di Amazon, ad esempio, è la Amazon Machine Image (AMI). AMI è un'applicazione virtuale usata per creare una macchina virtuale all'interno dell'Amazon Elastic Compute Cloud (EC2). I fornitori di MCU creano un ponte con AMI per i propri prodotti specifici con un layer di middleware. Sono disponibili schede dimostrative e kit di sviluppo per gestire tutte le complessità dell'interfaccia cloud-MCU.

Una volta accettata l'opportunità di connessione tramite un servizio cloud attento alla sicurezza, entrano in gioco complessità più familiari come stabilire connessioni a valle del cloud. La Figura 2 mostra i quattro percorsi dei dati usati più spesso tra i dispositivi embedded e il cloud. Potrebbe essere auspicabile per un progetto embedded utilizzare più di uno di essi.

Il Wi-Fi rappresenta la scelta più assennata, specie quando si impara come creare un'interfaccia AMI specifica per un fornitore di MCU, in quanto il progetto embedded diventa fondamentalmente un coordinatore centralizzato per la rete. È una sorta di Access Point (AP), ossia la topologia è sia basata su standard che familiare.

Ad esempio, nel kit di sviluppo 1 WCM (DM182020) di Microchip Technology, il firmware programmato nell'MCU PIC32MX695F512H a 32 bit su scheda può essere impostato per connettersi con una Amazon Machine Image (AMI) di Microchip utilizzando il modulo Wi-Fi MRF24WG0MA su scheda di Microchip.

Quando si esemplifica il progetto di un nuovo prodotto, tuttavia, il Wi-Fi non è l'unica scelta. Tutte le opzioni riportate nella Figura 2 hanno vantaggi e svantaggi. Di seguito ne vengono trattati alcuni.

• Il Wi-Fi è presente quasi ovunque, è facile da configurare ma assorbe non poca energia. Bluetooth ha una sicurezza intrinseca e consuma poca energia. Con la progressiva diffusione degli smartphone, Bluetooth sta sviluppando una disponibilità estesa. Ha però una portata limitata e richiede in genere il pagamento dei diritti d'autore.
• ZigBee (IEEE 802.15) e tecnologie proprietarie sub-GHz offrono vantaggi quali stack leggeri, portata e penetrazione eccellenti, costi contenuti e, a volte, bassissimo consumo. D'altra parte, solitamente richiedono che nel disegno venga incluso un altro progetto, un concentratore.
• Ethernet è una tecnologia economica che si avvantaggia di un disegno plug-and-play, flessibilità, alta larghezza di banda e immunità al traffico ad alta RF. Ma ha anche tutti gli svantaggi di un sistema cablato.

Implicazioni MCU

Non sorprende che la pianificazione di una connessione al cloud eserciti un'influenza significativa al momento della scelta di un MCU per un sistema embedded. Consumo energetico, frequenze di clock, memoria e costo unitario sono, come sempre, considerazioni fondamentali. La connessione al cloud aggiunge altri risvolti importanti, non pochi dei quali legati alla sicurezza.

In particolare, quando l'e-commerce è parte dell'applicazione l'accelerazione hardware per eseguire AES, DES e CRC può essere necessaria e queste funzioni potrebbero richiedere un set più lungo di parole di istruzioni. Analogamente, con MCU a 32 bit possono essere impiegate anche funzioni crittografiche di hash come Secure Hash Algorithm (SHA) e Message Digest Algorithm-5 (MD5).

Le funzioni di sicurezza possono essere eseguite su un MCU con periferiche integrate in linee di prodotti come la famiglia PIC32MZ EC di Microchip Technology. Microchip fornisce anche stack software per i progettisti di dispositivi embedded che supportano protocolli di sicurezza come SSL/TLS all'interno dello stack TCP/IP.

Texas Instruments offre il kit di sviluppo Connected LaunchPad della serie Tiva C (EK-TM4C1294XL), dotato di connettività Internet pronta all'uso per applicazioni abilitate per il cloud. Il progetto Connected LaunchPad di TI, una piattaforma di valutazione economica per microcontroller basati su ARM Cortex-M4, mette in luce il microcontroller TM4C1294NCPDT con MAC Ethernet 10/100 e PHY su chip, USB 2.0, modulo di ibernazione, modulazione dell'ampiezza degli impulsi, controllo del movimento e varie periferiche di comunicazione seriale.

In genere queste linee di prodotti, e quelle di altri fornitori di MCU, integrano periferiche di comunicazione quali USB 2.0 ad alta velocità, controller Ethernet a 10/100 Mbps, moduli di controllo CAN 2.0b, UART, interfacce seriali SPI/I²S, interfacce di comunicazione multiple I²C e Serial Quad Interface (SQI) a 4 bit. Nelle applicazioni industriali vengono impiegati in genere convertitori ADC integrati.

Kit di sviluppo

Come ricordato in precedenza, non è molto utile reinventare tutti i processi e il codice che sono già stati sviluppati dagli esperti del cloud.

I fornitori di MCU stanno incorporando nei kit di sviluppo quella conoscenza istituzionale, assieme alle capacità dei propri chip e al software. Un esempio è il kit di sviluppo 1 WCM di Microchip Technology ricordato in precedenza. Utilizzando questo kit di sviluppo e Amazon Machine Image (AMI) di Microchip, sia il dipartimento IT che quello di engineering possono apprendere le esigenze fondamentali richieste per lanciare una soluzione basata sul cloud.

Il kit consente all'utente di impostare un account Amazon AWS (Amazon Web Services) e usare il dispositivo incluso nel kit. Esistono quattro fasi preliminari base:

1. Trovare AMI di Microchip sul mercato AWS di Amazon.
2. Avviare un'istanza EC2 (Amazon Elastic Compute Cloud) da questa AMI.
3. Configurare la demo per accedere al proprio router locale o al punto di accesso.
4. Eseguire la demo.

Esistono numerose opzioni di personalizzazione ma la demo ne richiede solo due: una selezione per un gruppo di sicurezza che fornisce i nomi delle porte da aprire per procedere e la coppia di chiavi per la crittografia.

L'accettazione dei termini e delle condizioni d'uso di Amazon avvia l'istanza EC2 basata su AMI di Microchip. Quando l'istanza è pronta (il processo richiede alcuni minuti) è possibile accedere alla console AMI. Sebbene la nuova pagina sia ricca di informazioni, la demo richiede solo che venga trovato l'indirizzo IP pubblico.

Avviare una nuova pagina del browser e immettere l'indirizzo IP pubblico. Sullo schermo appare un'interfaccia Web per il server.

La connessione della scheda demo al Web implica l'impostazione della scheda nel modo AP così che possa essere configurata. Il kit demo chiede l'interazione dell'utente lungo l'intero processo di configurazione, compresa la scelta dell'opzione di sicurezza appropriata. L'immissione dell'indirizzo IP pubblico e del passcode è tutto ciò che serve per configurare la scheda demo per l'uso.

La Figura 3 mostra una finestra del browser della demo con la pagina Web sulla sinistra e la scheda sulla destra. I pulsanti sulla scheda possono essere premuti per illuminare i LED virtuali sulla pagina Web e la regolazione di un potenziometro sulla scheda viene segnalata sulla pagina Web da un numero che cambia in fondo alla schermata del browser.


Sebbene le funzionalità raggiunte dalla scheda demo e dal software siano molto semplici, il punto vero della demo è la possibilità di usare un dispositivo interamente connesso con una AMI Amazon predefinita specifica per un MCU Microchip impostabile in pochi minuti.

Conclusione

Disporre di un prodotto che si avvale di un'elaborazione o di uno storage remoti e in grado di connettersi al cloud è un concetto nuovo e allettante ma occorre prestare attenzione ai problemi della sicurezza e della privacy. Il software lato server è però complesso e non intuitivo per i progettisti di sistemi embedded per cui i fornitori di MCU stanno iniziando a stringere delle collaborazioni in grado di offrire connessioni quasi plug-and-play al cloud. L'uso di questi kit di sviluppo fa risparmiare tempo e fatica ai team di progettazione che sono più propensi a dotare i propri prodotti di funzionalità leader di mercato piuttosto che diventare esperti IT.

Questo articolo si basa su un corso tenuto da Stephen Porter, Applications Manager per Home Appliance Solutions Group di Microchip Technology, presentato originariamente in occasione della Conferenza internazionale MASTERs del 2014 di Microchip.