I sensori sono utili se riusciamo a monitorarne live lo stato e le relative informazioni. Pertanto per ottenere il massimo dai sensori ed anche da dispositivi IoT occorre effettuare il recupero dei dati in maniera continua. Quando questi sensori sono in migliaia e più potresti rischiare di autoprocurarti rallentamenti se non addirittura un Denial of Service(DoS).
La gestione dei sensori: dati semplici e management complesso
I sensori inviano dati spesso semplici come la temperatura di un impianto o come la chiusura o apertura di un determinato circuito. Cosa accade se costruisci una Dasboard per la visualizzazione attraverso overlay, mappe o Human Machine Interface(HMI) di tutti i tuoi sensori e qualcuno di essi fallisce, non viene instanziato correttamente o ci sono molte informazioni?
Potresti trovarti nella condizione di avere delle inconsistenze, dei dati errati ed in casi estremi di interrompere la corretta visualizzazione della dashboard generando tu stesso un attacco DOS involontario verso i tuoi servizi. Le soluzioni ci sono e nel prossimo paragrafo ti indicheremo una strategia che abbiamo adottato per un nostro cliente.
Polling, GET/PUSH ed Exponential Backoff
Molto spesso è necessario affidarsi al Polling per poter ricevere dati aggiornati. Quando si effettua il Polling è necessario prevedere una logica di retry in caso di fallimento di una certa chiamata alla API.
In un contesto di Front-End(la Dashboard) e di Back-End( le API ed i Web Services) in cui la Dasboard invia richieste GET per ottenere i dati dal backend, se questa richiesta dovesse fallire, è opportuno che la componente della Dashboard ripeta autonomamente la richiesta applicando la tecnica dell’Exponential Backoff, vale a dire che riprovi dopo un tempo T una seconda volta, poi dopo un tempo T + 20% la terza, poi dopo T + 40% la quarta e così via fino a quando non si considera definitivamente fallito il tentativo o la richiesta va a buon fine.
Inoltre quando la prima richiesta GET ha successo, per evitare traffico inutile ed il susseguirsi di continue chiamate alla API, la componente di Front End si sottoscrive(come in un algoritmo di Pub/Sub) ad un topic che in modalità PUSH riceve informazioni direttamente dal Web Service tramite un opportuno socket. Tale modalità consente così alla Dasboard di rimanere sempre aggiornata sullo stato del sensore ma senza sovraccaricare di richieste inutili il Web Service.
In questa maniera:
- si evitano possibili “bombardamenti” di richieste di informazioni che fanno lievitare i costi e potrebbero rendere inefficiente il Web Service;
- il Web Service può gestire in maniera efficace le connessioni singolarmente con migliaia di sensori senza alcun impatto particolare per il workflow qualora qualcuno di essi fallisse;
- si aumentano le performance della Dasboard permettendo un flusso asincrono, push e consistente.
In pratica applicando l’Exponential Backoff e gestendo correttamente il flusso GET/PUSH tramite algoritmi Pub/Sub è possibile rendere scalabile e performante una Web Application di telemonitoraggio che, in questo caso essendo Cloud based, si traduce anche nel renderla efficiente con un risparmio dei costi.
Glue Labs ed i Sistemi di Telemonitoraggio
Abbiamo lavorato per tantissimi contesti industriali e numerosi Clienti e ti forniamo supporto ed assistenza nella realizzazione, progettazione, design, implementazione, deploy di qualsiasi soluzione di telemonitoraggio e di HMI con garanzia 12 mesi da qualsiasi bug. Contattaci subito e senza impegno per un preventivo gratuito.
