I consumatori sono sempre più attratti dai dispositivi smart domestici, anche grazie alle nuove e sofisticate tecnologie di controllo vocale come il telecomando Siri Remote di Apple e Alexa Voice Service di Amazon Echo e ai sistemi per il controllo remoto di dispositivi domestici come i prodotti Google’s Nest. Per questo, molti produttori di dispositivi di comando, come i termostati, si trovano davanti alla sfida di trasformare un sistema tradizionale in una soluzione dotata di connettività. Per fare fronte a queste esigenze, può essere utile fare affidamento su tecnologie Rf standard come il Wi-Fi o la comunicazione tramite Bluetooth Low Energy. I progettisti di sistemi integrati hanno a disposizione una vasta gamma di ricetrasmettitori e moduli Wi-Fi e Bluetooth. I produttori di circuiti integrati Rf offrono una serie di protocolli di comunicazione gratuiti e pronti all’uso per Wi-Fi, Bluetooth e connettività Internet. Inoltre, nell’ottica di trasformare un termostato in un dispositivo più smart, i produttori di microcontrollori mettono a disposizione una procedura di migrazione per aumentare la potenza di elaborazione e la memoria indirizzabile, oltre ad aggiornare le caratteristiche periferiche del termostato Mcu esistente. Da un punto di vista prettamente hardware, quindi, per modificare un design esistente e trasformarlo in un prodotto smart sono disponibili diverse soluzioni pronte all’uso. Ciononostante, la vera sfida per gli sviluppatori di soluzioni embedded è di riuscire a integrare hardware, firmware e software applicativi per venire incontro alle aspettative degli utenti in termini di funzionalità, assicurando l’interoperabilità tra diverse piattaforme come HomeKit di Apple o le tecnologie Works with Nest di Google. In realtà, la parte più difficile nella progettazione di un termostato smart di successo non è tanto il design della connettività wireless, bensì lo sviluppo del software. In questo senso, avere a disposizione una piattaforma di sviluppo completamente integrata aiuta a lavorare in tempi più brevi senza la necessità di implementare nuovi design per dispositivi smart domestici.
Protocolli compatibili
Per supportare le funzioni di comando vocale e remoto disponibili attraverso varie piattaforme, un termostato richiede una connessione Internet attiva, che di solito viene resa disponibile attraverso un gateway come un router Wi-Fi. Il dispositivo dovrà supportare anche protocolli di applicazione come Http, Smtp, Ntp ed Mqtt per assicurare una comunicazione efficace con server web e applicativi su Internet. A livello applicativo, il termostato potrebbe eseguire anche vari elementi software specifici come l’Homekit Accessory Protocol di Apple. La sicurezza è un requisito essenziale per i dispositivi connessi in rete, per tutelare in ogni momento la privacy dell’utente ed evitare intrusioni nella rete domestica. Le transazioni sicure e lo scambio di messaggi tra il dispositivo e il Cloud possono avvenire attraverso il sistema Ssl (Secure sockets layer) con Tls (Transport layer security) 1.2 o ricorrendo ad altri protocolli di sicurezza. Vista la complessità delle operazioni necessarie a livello applicativo, di sicurezza e di comunicazione, l’architettura del sistema richiederà un sistema operativo per definire le priorità e l’allocazione della memoria. Per un dispositivo dotato di risorse limitate come un termostato, la soluzione sarà un sistema operativo in tempo reale che occupi una quantità di memoria ridotta. Ed è esattamente questa la sfida per lo sviluppatore del termostato: dovrà essere in grado di offrire una connessione Wi-Fi affidabile a un router e, in alcuni casi, una connessione Ble per dispositivi quali i sensori wireless, ma dovrà anche implementare vari protocolli e il software applicativo in un ambiente che richiede un’interoperabilità continua con servizi e dispositivi di terze parti connessi a Internet. Si tratta di un’attività di sviluppo articolata, che può presentare anche problemi tecnici e imprevisti difficili da risolvere. È proprio per questo che nasce la tecnologia Wiced (Wireless internet connectivity for embedded devices) di Cypress.
Una piattaforma unificata
L’obiettivo di Wiced è mettere a disposizione una piattaforma unificata per lo sviluppo di dispositivi connessi a Internet che utilizzano Wi-Fi, Bluetooth o ZigBee. Ma cosa si intende con unificata, in questo contesto? La piattaforma Wiced presenta elementi software e hardware caratterizzati da una totale interoperabilità, e si compone di:
- moduli Ic Rf di Cypress, alcuni dotati di Mcu, che offrono connettività tramite Wi-Fi, Wi-Fi+Bluetooth, Bluetooth+Bluetooth Low Energy o Bluetooth+ZigBee;
- architettura software completa in grado di offrire connettività, sicurezza e tutte le applicazioni necessarie (Fig. 2);
- supporto nativo per sistemi operativi in tempo reale quali ThreadX, NuttX e FreeRtos; possibilità per gli sviluppatori di assicurare la portabilità di altri sistemi operativi in tempo reale per la piattaforma Wiced; distribuzione di ThreadX come binari condivisibili all’interno di Wiced senza royalty;
- supporto nativo per gli stack di rete NetX, NetXDuo e LwIP; portabilità agevole di altri stack Tcp/IP su Wiced; distribuzione di NetX e NetXDuo come binari condivisibili all’interno di Wiced senza royalty;
- un kit di sviluppo software completo realizzato per l’ambiente open-source Eclipse Integrated Development Environment in grado di mettere a disposizione degli sviluppatori tutte le funzionalità disponibili in Eclipse per le applicazioni di sviluppo e debug per i prodotti Rf di Cypress;
- schede base di sviluppo compatibili con Arduino, con la possibilità per gli utenti di collegare sensor shield e altri dispositivi periferici;
- design di riferimento offerti da altri partner di sviluppo Wiced;
- codice di esempio applicativo per l’implementazione di tutte le comunicazioni, le reti e i protocolli più usati;
- esempi applicativi per la comunicazione con i fornitori di servizi Cloud come Amazon Web Services, Azure di Microsoft o Bluemix di Ibm;
- una procedura a prova di errore per gli aggiornamenti Over The Air;
- documentazione completa per le Api e gli esempi applicativi.
Tutti gli elementi sono testati e verificati per dare agli utenti la certezza che il codice Wiced Hap venga eseguito senza problemi in un ambiente software ThreadX su CYW43907, un dispositivo Wi-Fi IC dotato di core Arm Cortex-R4. La piattaforma Wiced supporta diverse architetture hardware, offrendo agli utenti la possibilità di scegliere se implementare Wiced in un modulo dedicato dotato di Mcu, in un Mcu Rf completamente integrato o in un processore host esterno.
Il processo di sviluppo di Wiced
Prima di tutto, sarebbe opportuno collegare un sensore di temperatura, un relè e un modulo Wiced. La Fig. 3 mostra una configurazione con un sensore di temperatura dotato di interfaccia I2C collegata al CYW43907AEVAL1F, una scheda di valutazione dotata di modulo LBWA1UZ1GC-958 di Murata basato sul system-on-chip Wi-Fi CYW43907, nonché un display che indica lo stato e la temperatura del sistema. Il driver del sensore di temperatura può essere aggiunto alle librerie dell’Sdk Wiced per dare anche ad altre applicazioni la possibilità di utilizzarlo. Questa stessa cartella contiene anche il driver del display supportato nell’Sdk. Nella cartella con i frammenti di codice dell’applicazione si trova anche un esempio applicativo che mostra come utilizzare il protocollo I2C per leggere i valori del sensore di temperatura. La lettura della temperatura ambiente può essere effettuata tramite semplici chiamate Api. Gli I/O possono essere configurati nei file della piattaforma. Il file platform.c contiene tutte le mappature pin-out e le rispettive configurazioni. Durante la fase di configurazione dei pin I2C, è necessario verificare: la porta I2C a cui è collegato il sensore di temperatura; i pin Sda ed Scl; il driver da usare. Un altro frammento di codice dell’applicazione integra un display da 128 x 128px nel design. Combinando entrambe le applicazioni, è possibile leggere la temperatura ambiente sopra l’interfaccia I2C e visualizzarne il valore sul display. Per scrivere l’applicazione, effettuare le seguenti operazioni:
- inizializzare Wiced
- inizializzare il dispositivo I2C
- inizializzare il display
- leggere il valore I2C del sensore di temperatura
- mostrare il valore sul mini display tramite Spi o I2C.
Finora, nel sistema sono state implementate solo le funzionalità di base del termostato. Il passo successivo è integrare una serie di funzioni smart, come la possibilità di confrontare la temperatura desiderata con quella attuale e, se la temperatura ambiente risulta inferiore a quella desiderata, passare automaticamente alla modalità di riscaldamento tramite relè. A questo punto, lo sviluppatore si aspetterà che il termometro sia in grado di connettersi a una rete Wi-Fi. A questo punto, l’utente può scegliere tra varie modalità operative:
- interfaccia Sta, basata su stazione, dove il termostato funge da client;
- punto di accesso SoftAP, dove il termostato ospita un server web;
- punto di accesso SoftAP e Sta, nota come “modalità Apsta”, dove il termostato funge da server e da client.
Apsta è disponibile all’interno dell’Sdk Wiced tra i frammenti di codice degli esempi applicativi. In questo caso, il termostato può ospitare un server web e dare accesso anche ad altri client; allo stesso tempo, come client, può collegarsi al punto di accesso domestico per la connessione a Internet. L’Sdk Wiced permette di ospitare un server http sul termostato per effettuare e ricevere chiamate Api Rest e ottenere o comunicare la temperatura desiderata. In questo modo, il termostato sarà accessibile anche ad altri dispositivi nella stessa rete. Per esempio, è possibile programmare una piccola applicazione peer su un dispositivo mobile per impostare la temperatura con una richiesta Post come questa: http://mysmarthome.com/thermostat1/setTemp?value=65. L’app può inoltre chiedere al termostato di comunicare al dispositivo mobile la temperatura attuale attraverso una richiesta Get come questa: http://mysmarthome.com/thermostat1/getTemp?value=65. La pagina html sviluppata per ospitare un server web si trova nella cartella delle risorse, insieme ai file di immagine, javascript e css necessari. Questa deve essere inclusa nell’applicazione Make Target come oggetto risorsa per dare al server la possibilità di effettuare il rendering e visualizzarla non appena un client si collega al dispositivo. Esistono due sistemi per connettere il termostato a un punto di accesso: inserire l’Ssid e la password del punto di accesso nel file di configurazione; chiedere a un client, ad esempio un dispositivo mobile connesso al punto di accesso softAP del termostato, di autorizzare l’utente a inserire la password per il punto di accesso selezionato. A questo punto, il termostato viene riavviato e memorizza le credenziali del punto di accesso in una tabella di configurazione del dispositivo. L’Sdk Wiced offre inoltre un’opzione di sicurezza Wps per registrare un nuovo dispositivo a un punto di accesso. Una volta connesso a Internet, il termostato può cominciare a trasferire i valori della temperatura in Cloud. La connessione a Internet permette al termostato di ricevere anche dati in ingresso, ad esempio previsioni meteo, aggiornamenti firmware e data e ora tramite il protocollo Ntp. Wiced supporta anche il protocollo Smtp, che consente all’utente di configurare un account e-mail per inviare notifiche all’indirizzo di posta elettronica dell’utente.
