Nel precedente articolo si è effettuato un lavoro di progettazione dei modelli di riferimento per i dispositivi terminali della rete, sensori ed attuatori che siano, entrando nei particolari dei meccanismi tramite cui i dati vengono inoltrati nella rete o vengono ricevuti dalla rete, ma chi smista questi dati permettendo all’applicativo completo di lavorare in armonia? L’elemento in questione è quello di cui si andrà a parlare in queste righe, ossia il nodo a cui ci si è riferiti col nome di mediatore, che è una semplificazione per gli scopi di questo progetto di ciò a cui in letteratura ci si riferisce come Smart Gateway.
Facendo riferimento ai modelli introdotti in precedenza, il mediatore deve disporre di un’interfaccia che gli permetta di comunicare con diversi tipi di dispositivi, per potere effettuare sia delle operazioni di inoltro di dati che di interfaccia di controllo, in maniera intelligente. Generalmente, questo tipo di elemento può risultare di particolare complessità progettuale e di realizzazione: l’argomento verrà affrontato, quindi, cercando di utilizzare un approccio semplificato e con funzionalità tendenzialmente ridotte, lasciando aperta la porta ad aggiunte future, più complesse ma meno necessarie per degli scopi di base.
Una modalità di semplice comprensione per pensare alla schematizzazione di questo elemento è di immaginare di isolare ogni suo compito come un modulo a sé stante: ogni modulo deve potere eseguire le sue specifiche funzioni e, contemporaneamente, deve potere comunicare con gli altri moduli per fare sì che l’applicativo complessivo mediatore funzioni a dovere.
Quali sono i compiti dell’applicativo in questione?
- Ricezione dei dati ottenuti dai sensori della rete;
- Possibilità di registrare quanto ricevuto all’interno di una struttura dati, che rappresenterà lo stato dell’applicativo;
- Traduzione del tipo di dato ottenuto in un comando interpretabile dai nodi attuatori;
- Inoltro dei comandi agli attuatori;
- Interfaccia per la comunicazione con elementi terzi, quali App per monitorare la rete, o per ottenere dati complessi da quelli acquisiti localmente.
Ognuno di questi elementi gioca un ruolo fondamentale nel funzionamento dell’applicativo completo e può essere implementato in maniera differente a seconda di cosa si vuole realizzare: il modello, infatti, si presenta come particolarmente flessibile, dando la possibilità di implementarlo in maniera semplice e rigida, per scopi come progetti casalinghi, o in maniera complessa e funzionale, ad esempio permettendo di prevedere più traduzioni con regole dinamiche.
La flessibilità di cui si è parlato è data proprio dalla scelta di considerare ogni modulo come un servizio atomico ma non isolato. Ciò permette, avendo delle regole di comunicazione tra i moduli che rimangono invariate, di potere effettuare modifiche anche sostanziali ad i singoli moduli senza dovere riconsiderare l’intera architettura del mediatore.
L’argomento implementazione verrà trattato da un punto di vista semplificato, approfondendo poi su alcuni aspetti complessi in maniera isolata, onde evitare inutili aggiunte di difficoltà. Si è già discusso di come la tecnologia prescelta per la comunicazione Machine-to-machine (MNM) arà MQTT: questo tipo di architettura permette, però, di poterne utilizzare anche di differenti mantenendo la struttura interna del mediatore intatta.
Per realizzare quanto appena introdotto si andrà ad utilizzare principalmente Python3 (facendo uso della libreria paho-mqtt per la comunicazione con i vari nodi) su piattaforma Raspberry Pi. Il prossimo articolo offre un esempio di una semplice implementazione con le tecnologie appena nominate.