Internet of Things, revisione 0.02
Internet of Things, IoT, estende l’ambito informatico tradizionale prevedendo l’interazione tra computer e la realtà circostante.
La necessaria sperimentazione crea delle linee guida, sulle quali proviamo ad argomentare.
Ruolo fondamentale nel rendere possibile l’interazione con le cose attraverso internet, è da attribuirsi al sistema middleware, che tipicamente risiede in ambito cloud e raggiungibile stabilmente attraverso internet. Il middleware realizza il ponte tra chi vuole accedere alle cose attraverso internet e le cose stesse.
Denotiamo con processori, tipicamente ARM, le schede atte alla rielaborazione dei dati e con controller, tipicamente AVR, quelle che realmente interagiscono con la realtà circostante.
E’ possibile utilizzare le schede i386 o amd64 come processori, nei tradizionali allestimenti desktop o server. La maggior potenza e stabilità vede come contro altare consumi, costi e volumi decisamente superiori. Certamente la soluzione ARM offre quella leggerezza che ben si accompagna all’IoT, o meglio alla distribuzione dei sistemi nel territorio.
Le particolari schede ARM Raspberry Pi si candidano come processori di riferimento per l’universo informativo disponibile.
Analogamente Arduino, Genuino al di fuori degli USA, per i controller.
Le schede ARM utilizzano sistemi operativi con kernel Linux ARM 32 bit. La versione a 64 bit è praticamente ancora non utilizzabile. Le varie distribuzioni hanno raggiunto una buona maturità nell’ambito 32 bit, anche se ancora ben lontana dalle compilazioni per i386 o, vero riferimento, amd64.
La distribuzione Debian è ancora la meglio utilizzabile. Ubuntu è da poco utilizzabile concretamente ed è piuttosto faraginosa negli archivi dei compilati in linea. La distribuzione Debian per RPi, detta Raspbian, offre quanto serve in termini di servizi e strumenti di sviluppo.
L’adozione di schede ARM permette di semplificare drasticamente i sistemi costruiti. L’alimentazione degli stessi è un primo aspetto che si semplifica all’estremo. E non da poco è la potenza assorbita che si riduce dalle varie centinaia di watt a una o due decine. Comunque, in termini di alimentazione di dispositivi, se si necessita di flussi di corrente di ampere, per esempio per alimentare le schede ARM stesse, si adottano convertitori step down DC DC, minimizzando la dissipazione e disaccopiando la scheda dai ruoli delicati.
Fissare l’alimentazione a 12 V è una buona scelta.
Infatti facilita l’integrazione con le batterie e l’alimentazione da rinnovabili. In particolare facilita le applicazioni mobili.
Unifica in una sola tensione, uno standard di fatto, sia per i processori che per i controller.
Per le schede controller standard AVR, dato l’assorbimento tra 10 mA e 100mA, conviene sfruttare il loro riduttore di alimentazione dissipativo ponendo un intermedio 7808, sempre dissipativo, e condensatore, per esempio da 330 micro Farad, ai fini di disaccopiare il controller dalla fonte di alimentazione, ma anche l’alimentazione dai sensori ed attuatori connessi al controller.
Per le tensioni di riferimento, 5V e 3.3V, necessarie ai sensori ed attuatori si utilizza elettronica dissipativa.
Gli attuatori possono usare direttamente i 12V beneficiando della grande diffusione di schede con questa alimentazione.
Il trasporto dell’alimentazione ed anche dei segnali è realizzato con il diffuso cavo per antifurti.
Il processore si connette al middleware via internet, anche wifi o radio su IP.
In locale, il router per internet provvede ai servizi WiFi e DHCP, presupponendo quest’ultimo sempre operativo.
Il controller si connette al processore mediante USB con il cavo dei +5V interrotto.
Lato processore esiste il delicato servizio di controllare quali controller siano connessi e a quale porta, aggiornando periodicamente o in caso di variazione dell’assetto, il middleware.
Per ogni controller connesso al processore via USB, è attivo un servizio che riporta i dati dal controller al middleware e viceversa.
Dai controller possono diramarsi connessioni seriali.
Nella comunicazione tra processore e controller il ruolo di server o di client dipende dal particolare utilizzo.
Per dire, se il controller è atto alla misura di potenza f.e.m., allora è client nella comunicazione. Se deve attivare delle commutazioni o fornire a richiesta misure, allora è server.
Il linguaggio di programmazione tipicamente utilizzato è il C.
I convertitori AD hanno un ruolo essenziale.
Nel caso di usare direttamente le porte del RPi, non ci sono AD. Una soluzione è adottare il 3008, purtroppo a 3.3V, quindi diminuendo drasticamente la velocità di campionamento.
Si riesce ad misurare qualche campione al ms per AD ed utilizzando in contemporanea tute le otto porte. Purtroppo il buffer non può stare nella mSD, ma in RAM. Quindi bisogna realizzare due processi concorrenti allo stream di dati. Altro aspetto realmente delicato riguarda le due porte SPI, con questioni di precisione e di instabilità. Comunque conviene erogare al 3008 un 3.3V isolato e preciso.
In molte situazioni concrete, quali misure di potenza f.e.m., servono molti canali AD, quindi si può considerare un Mega con 16 AD. Ma ci si scontra con la lentezza di computazione rischiando facilmente, soprattutto se si usano quasi tutti gli AD in contemporanea, di non arrivare nemmeno ad un campione per ms.
La scelta cade sul Due che con 12 AD fino a 12 bit ed il clock a 84 MHz, permette di mantenere uno stream, usando le 12 porte ed elaborando i dati, nettamente migliore di un campione al ms per ogni porta. Lo stream è realizzato dal client, attraverso USB, verso il controller.
La scelta dei trasformatori per misure di alta tensione e corrente alternata apre un capitolo a parte. Anticipiamo che la parte più interessante è la determinazione del tempo di sfasamento del segnale attraverso questi dispositivi. Pertando si devono considerare coppie di misure con la relativa coppia di sfasamenti rispetto al segnale originale.
La taratura dei sensori apre altre interessanti questioni.