Controller con GPIO per automazione IoT

La costruzione di un sistema IoT, Internet of Things,  deve prevedere uno spazio cloud per i dati, anche big data, con un middleware verso un’ampia collezione di servizi. Allestiremo una versione per sviluppo e test in locale con Ubuntu server virtualizzato mediante Virtualbox.

Supponiamo di voler allestire dei sistemi periferici  per il monitoraggio e l’automazione.

Il più semplice sistema è costituito da un computer, che definiamo controller, collegato mediante apposito BUS all’elettronica che realizzi una GPIO, General Purpose Input Output.

Affinché il controller sia realizzato con una tecnologia moderna, bassissimo consumo, dimensioni minime, potente, costo ridotto, unica alimentazione, per esempio 5V DC 2A, con una distribuzione Linux ben collaudata, deve essere, per esempio, ARM.

Tra le schede ARM scegliamo un modello diffuso, robusto, economico, per esempio il Raspberry Pi, RPi, in particolare la non costosa quad core versione 2. Questa scheda permette di eseguire il sistema operativo Linux completo degli ambienti di sviluppo ed è dotata delle connettività di base.

Il RPi ha una sua GPIO, ma, per dire, non ha convertitori AD, il numero di pin IO è modesto, la CPU è collegata direttamente alla GPIO …, quindi  preferiamo dotarla di microcontroller dedicato ed esterno, per essere indipendenti dalla specifica tecnologia del controller, poter godere di due sistemi autonomi, anche nel mutuo controllo. Infatti, per dire, RPi manca di un sistema di spegnimento. Definiamo gpio0 quella a bordo del RPi e gpio1 la principale, che in questa situazione, è esterna.

La miglior scheda con GPIO per diffusione, documentazione, facilità di sviluppo e costo è del tipo Arduino,  con microcontroller AVR.

Abbiniamo nel modo più conveniente la RPi con una Arduino in un contenitore del tipo utilizzato negli impianti elettrici. Utilizziamo le righe di headers per alloggiare le due schede su una basetta costruita con PCB, Printed Circuit Board, su misura. Aggiungiamo sulla stessa PCB:

  • una ventola
  • un IC con 7 oppure 8 darlington
  • un LM35 per leggere la temperatura interna al contenitore
  • un relè per gestire l’accensione e lo spegnimento del RPi
  • un led per indicare lo stato
  • un led per indicare ed errori
  • un pulsante esterno per reset (opzionale e disattivabile mediante software)
  • un pulsante esterno per accensione/spegnimento RPi (opzionale e disattivabile mediante software)
  • un pulsante interno per reset to factory.

Consideriamo il sistema di alimentazione più adatto per dispostivi del più vario genere. La tensione sia unica per semplificare il trasporto. Teniamo conto di  standard correnti per esempio in ambito automotive, pannelli solari, batterie al piombo, alimentazione di prodotti generici. Quindi scegliamo 12 V DC con corrente almeno di 5 A, meglio verso 10A, in tecnologia switching-mode.

Inseriamo l’alimentatore in un contenitore simile a quello scelto per il controller, ma di dimensioni più contenute e con una ventola sempre attiva. Una morsettiera permetta di collegare lo stesso alla f.e.m. ed ai dispositivi da alimentare.

Pertanto dobbiamo aggiungere nel contenitore del controller con GPIO con convertitore 12 V DC a 5 V DC, che regga almeno 1,5A. Ne proveremo alcuni, e cominciamo con un modello della Recom R-78B5.0-1.5 pin compatibile serie LM78xx, ma switching con il 92% di efficienza.

Raspbian, il sistema operativo derivato da Debian per RPi, permette di utilizzare Python e Qt 4.8, che costruiscono l’ambiente per lo sviluppo.

Utilizziamo come cloud middleware un RDBMS, la miglior scelta è Postgresql 9.3 o 9.4 con PL/Pythonu per la collezione necessaria di trigger.

Attiviamo un firewall ed una VPN o tunnel, tipo SSH,  per proteggere la comunicazione. Naturalmente con sistemi di backup e ridondanza adeguati.

Il primo servizio residente nel controller, RPi nel nostro caso, è di controllo dei microcontroller collegati ed operativi, per poi  aggiornare la specifica tabella. Realizziamo il programma in Qt e lo attiviamo al minuto con Cron e privilegi di root per gestire il BUS in totale libertà.

Il servizio principale realizza nel suo ciclo principale un doppio poll verso il middleware e verso la gpio1.

Caratterizziamo mediante id, identificatore unico naturale, ogni servizio del sistema specifico, detto sid.

Ogni device ed host sarà caratterizzato da un device id, detto did.

La tabella commands nel middleware permetterà l’interazione tra le parti. All’inserimento di un record in commands scatta il trigger in PL/Python, che avvia l’interprete del comando e l’esecuzione dello stesso.

Il tracciato di commands prevede oltre a campi scontati quali id, timestamp, commands, parameters e status, anche il sid del mittente e del destinatario, il campo alive che viene aggiornato dal destinatario entro un tempo stabilito altrimenti il servizio giornaliero provvederà a eliminare la riga. Dei campi permettono la ripetizione per n volte ad un dato tempo del comando stesso.

I commnadi sono raggruppati secondo le varie tipologie.

Una opportuna collezione di tabelle permette di tenere lo stato dei dispositivi.

Gli eventi sono resi come comandi.

I comandi tra il middleware ed il controller sono più strutturati di quelli dal controller alla gpio.

Particolare riguardo è data alla costruzione del firmware del microcontroller. Sono previste due possibili funzionamenti: con o senza autoreset alla comunicazione della serial principale. La tensione per lo stato alto delle porte è per ora 5V, mentre gpio0 lavora a 3.3V. Il firmware prevede due modalità di funzionamento con o senza connessione attiva al controller. Nel caso di connessione attiva, il ciclo principale legge il buffer ed esegue il parsing dei comandi ricevuti, inviando infine la risposta. Nell’altro caso attiva le funzionalità di watch dog oppure di attesa per la riaccensione della scheda ARM. In questa seconda situazione la gpio1 è isolata, ma può memorizzare dei dati.