Dal polling REST a una piattaforma realtime per dispositivi industriali

Il punto di partenza

Obiettivo e vincoli

Questo progetto nasce da un'esigenza concreta: gestire dispositivi connessi su larga scala senza sacrificare compatibilità con il software esistente. La soluzione disegnata separa i canali di telemetria, configurazione e stato applicativo, mantiene il backend come sorgente affidabile del dato e introduce un layer realtime pronto a crescere senza imporre una riscrittura totale del sistema.

Obiettivo

Abilitare comunicazioni realtime affidabili senza spezzare i processi esistenti.

Vincolo

Convivenza tra legacy REST, rollout selettivi e backend già operativo.

Output

Una piattaforma capace di propagare comandi, ricevere conferme e osservare lo stato del sistema.

Dal comando al feedback

Flusso operativo del sistema

1. 1. Ingresso del comando

   L'applicazione o il portale salva il nuovo desired nel backend, aggiornando il modello dati in modo immediato e coerente con il frontend.

2. 2. Propagazione realtime

   Il backend pubblica il desired sui topic device e sul layer applicativo, in modo che attori diversi possano consumare lo stesso evento con scopi differenti.

3. 3. Feedback operativo

   Il dispositivo risponde con reported e telemetria. Questi eventi vengono consumati da servizi dedicati per aggiornare stato applicato, audit e monitoraggio.

4. 4. Osservabilità

   Broker, code e worker vengono monitorati tramite metriche, alert e DLQ per distinguere problemi di rete, regressioni applicative e backlog di processamento.

01 / Approfondimento

Il problema di partenza

Molti sistemi industriali crescono su integrazioni sincrone pensate per volumi più bassi e per una logica di richiesta-risposta. Quando i dispositivi iniziano a inviare dati continui e a ricevere configurazioni in tempo reale, il modello legacy mostra rapidamente i suoi limiti: code applicative poco osservabili, feedback lenti verso il frontend, tempi di riconciliazione lunghi e forte accoppiamento tra servizi REST, persistenza e logica di processo.

02 / Approfondimento

Una backbone progettata per convivere con il legacy

L'architettura sviluppata non impone una riscrittura totale. Il backend continua a governare la verità applicativa, mentre MQTT introduce un livello di propagazione realtime verso dispositivi e interfacce. Desired, reported e telemetria vengono separati per rendere esplicita la differenza tra comando emesso, stato recepito e dati operativi prodotti sul campo. Questo permette di mantenere consistenza lato applicazione anche quando il device non è ancora sincronizzato.

03 / Approfondimento

I processi separati che rendono il sistema leggibile

La piattaforma è stata organizzata in flussi distinti: persistenza applicativa, propagazione dei desired, ingestione della telemetria, gestione dei feedback reported, trattamento dei messaggi non validi e monitoraggio runtime. Ogni processo ha una responsabilità stretta, un punto di osservazione preciso e metriche che ne misurano il comportamento.

04 / Approfondimento

Desired e reported non sono lo stesso dato

Una delle semplificazioni più dannose nei sistemi IoT è trattare il comando desiderato come se fosse già stato applicato. In questa architettura i due concetti sono mantenuti separati. Il desired rappresenta l'intenzione lato backend e frontend; il reported rappresenta ciò che il dispositivo dichiara di aver recepito o applicato. La differenza tra i due consente di gestire pending state, retry, allarmi e sincronizzazioni parziali senza perdere controllo semantico.

05 / Approfondimento

Osservabilità e controllo operativo

Broker, code, worker e servizi di supporto sono stati progettati per essere leggibili. La piattaforma espone segnali chiari su backlog, consumer, dead letter queue, freshness dei dati, stato dei servizi e salute dei componenti. Questo consente di distinguere rapidamente tra un problema di rete, una regressione applicativa, un errore di validazione o un collo di bottiglia di processamento.

06 / Approfondimento

Perché questa architettura è utile anche lato frontend

Le applicazioni utente non devono dipendere direttamente dai topic dei dispositivi. Per questo il progetto prevede un layer applicativo derivato, pensato per aggiornare in modo coerente interfacce web e mobile anche quando il dispositivo non ha ancora recepito il cambio. Il backend mantiene così coerenza funzionale, auditabilità e possibilità di rollback selettivo. In pratica il frontend osserva uno stato elaborato, non il rumore grezzo del protocollo device.

07 / Approfondimento

Rollout selettivi e sicurezza dell'introduzione

L'introduzione di una backbone realtime in contesti esistenti non può avvenire con uno switch netto. Per questo il modello operativo prevede attivazioni selettive per gruppi di dispositivi, logging mirato, controlli sui mismatch di versione e possibilità di tornare temporaneamente al percorso legacy in caso di regressioni. La capacità di avanzare per subset è tanto importante quanto il design del protocollo stesso.

08 / Approfondimento

Ricerca e sviluppo come metodo

Questo tipo di progetto non è solo implementazione. Richiede prove sul campo, osservazione dei flussi reali, analisi delle failure mode, allineamento continuo tra software legacy, servizi realtime e strumenti di monitoraggio. È proprio in questa zona di confine tra prototipo, integrazione e produzione che il lavoro di ricerca e sviluppo genera il maggior valore: perché trasforma un'idea tecnica in una piattaforma misurabile, governabile e pronta a crescere.