Come abbiamo portato i macchinari industriali sullo smartphone del responsabile

Per sapere se un macchinario stava lavorando, bisognava salire in macchina.

Non è un modo di dire. Prima di questo progetto, il responsabile della produzione aveva un solo modo affidabile di sapere come stava andando una macchina installata da un cliente a ottanta chilometri di distanza: andarci. Oppure telefonare a qualcuno che si trovava lì e fidarsi di quello che gli veniva raccontato al telefono, che è una forma di monitoraggio molto diffusa e molto poco precisa.

Il monitoraggio remoto dei macchinari industriali parte quasi sempre da qui: non da un progetto di Industria 4.0 scritto su una slide, ma da un’azienda manifatturiera che ha i suoi impianti sparsi sul campo e nessun modo di vederli senza mettersi in viaggio. Questo è il racconto di come abbiamo risolto la cosa, con i pezzi tecnici veri e senza abbellimenti.

Il contesto: ogni controllo era una trasferta

L’azienda produce e installa macchinari che poi vivono lontano dalla sede. Alcuni in capannoni di altri, alcuni in postazioni temporanee, alcuni in posti dove la connessione internet o non c’è o non è cosa loro.

La conseguenza è una routine che conoscono in tanti. Un tecnico parte, guida, arriva, guarda il display della macchina, annota due valori su un foglio, torna. Se nel frattempo il macchinario si era fermato, lo si scopriva ore dopo, a volte il giorno dopo, spesso perché aveva chiamato il cliente arrabbiato. E la manutenzione si programmava a calendario, non sui dati: si andava a controllare anche quando non serviva, e non si andava proprio quando sarebbe servito.

Il costo vero non erano le trasferte. Era decidere alla cieca: intervenire senza sapere, o non intervenire senza sapere.

La soluzione tecnica: GSM e MQTT, perché il capannone non collabora

La prima domanda di ogni progetto IoT è come fai arrivare i dati fuori dalla macchina. Nel nostro caso la rete del posto non era un’opzione: cambia da installazione a installazione, dipende da reti aziendali di terzi, e chiedere a un cliente di aprire una porta sul suo firewall è una conversazione che finisce male.

Così ogni macchinario porta a bordo un modulo GSM, con la sua SIM dati. La macchina si connette da sola alla rete mobile e non ha bisogno di nulla di quello che la circonda. Se c’è campo, parla.

Per far viaggiare i dati usiamo MQTT, che è il protocollo pensato esattamente per questo scenario: messaggi piccoli, banda scarsa, connessioni che si interrompono. Ogni dispositivo pubblica lo stato su un canale, il server è in ascolto e riceve in tempo reale. Nell’altro verso funziona uguale: dalla dashboard si manda un comando alla singola macchina, e la macchina lo riceve senza che nessuno debba essere fisicamente lì. Rispetto a una normale chiamata HTTP, il vantaggio è che la connessione resta aperta e leggera, e se cade si riprende da sola senza perdere il filo.

Dashboard, app e il pezzo che nessuno chiede mai: i report

Sopra il flusso di dati abbiamo costruito tre cose, che poi sono quelle che si vedono.

La dashboard web, sviluppata in Angular e TypeScript, mostra tutti i macchinari in un elenco con lo stato aggiornato: cosa sta facendo ogni macchina adesso, i parametri di funzionamento, gli allarmi. È il posto dove si guarda quando si è in ufficio.

L’app mobile, realizzata in Ionic e Angular, è la stessa cosa nella tasca del responsabile. Questa è la parte che ha cambiato le abitudini più di ogni altra: non perché sia tecnicamente sofisticata, ma perché il telefono ce l’hai anche alle sette di sera, e la dashboard sul PC dell’ufficio no.

Il backend è in Node.js, con NestJS e TypeORM: riceve i messaggi MQTT, li normalizza, li salva, li serve alle interfacce e gestisce utenti e permessi. Accanto gira un microservizio separato dedicato ai report, che dai dati grezzi costruisce i riepiloghi periodici e li spedisce via email con template dedicati.

Quel microservizio è la parte che nessun cliente chiede nel primo incontro e che poi diventa quella che usa di più. Perché vedere lo stato in tempo reale serve quando c’è un problema; il report che arriva ogni settimana senza che nessuno lo prepari serve tutti gli altri giorni, quando i problemi si vogliono prevedere.

La parte noiosa che tiene su tutto: PM2 e CI/CD

Un sistema di monitoraggio ha un problema di reputazione: nel momento in cui l’azienda smette di mandare il tecnico e si fida dello schermo, quello schermo deve essere sempre acceso. Se la dashboard è ferma, il macchinario per l’azienda non esiste.

Per questo i processi Node.js sono orchestrati con PM2, che li tiene attivi, li riavvia se qualcosa va storto e permette di aggiornarli senza spegnere il servizio. E il rilascio del codice passa da una pipeline CI/CD su GitLab: le modifiche vengono verificate e messe in produzione in modo ripetibile, non a mano da qualcuno che si collega al server la sera tardi sperando bene.

Non è la parte che si mette nelle presentazioni. È la parte per cui, tre anni dopo, il sistema è ancora acceso e nessuno ne parla — che nel nostro mestiere è il complimento più grosso che ci sia.

L’impatto: cosa è cambiato davvero

Non ti daremo percentuali inventate di risparmio, perché non le abbiamo misurate e i numeri tondi nei case study sono quasi sempre un’invenzione. Quello che possiamo raccontare è cosa succede diversamente da quando il sistema è in funzione.

• Il controllo non è più una trasferta. Lo stato di ogni macchinario si vede dal telefono, in qualsiasi momento, senza chiedere a nessuno.
• I fermi si scoprono quando succedono, non quando chiama il cliente. Cambia il tono della telefonata: la fai tu, e sai già di cosa parli.
• Chi parte, parte sapendo. La trasferta si fa lo stesso, ma per un motivo preciso e con il pezzo giusto già in furgone.
• I report si scrivono da soli. Nessuno passa il venerdì a rimettere insieme i dati per il riepilogo mensile.
• Il sistema è in esercizio da oltre tre anni e continua a ricevere aggiornamenti senza interruzioni di servizio.

C’è anche un effetto meno tecnico e più interessante: quando i dati esistono, le discussioni cambiano. Prima si discuteva di impressioni («quella macchina secondo me lavora male»), adesso si guarda lo storico e si discute di fatti. È lo stesso motivo per cui parliamo spesso di Industria 4.0 come questione di decisioni più che di macchine nuove.

Quando ha senso pensarci anche per la tua azienda

Non serve una flotta enorme e non serve rifare gli impianti. I casi in cui questo tipo di progetto si ripaga in fretta sono abbastanza riconoscibili.

Hai macchinari o impianti installati lontano dalla sede. Mandi qualcuno a controllare cose che potrebbero essere lette a distanza. Scopri i fermi in ritardo, e il ritardo costa più dell’intervento. Fai manutenzione a calendario invece che sui dati reali. Ogni riepilogo per la direzione è mezza giornata di lavoro manuale.

Se ti riconosci in due o tre di queste righe, la strada esiste ed è più corta di quello che sembra: si parte quasi sempre da un macchinario solo, si porta fuori il dato, e da lì si costruisce il resto. Se vuoi capire prima le basi, abbiamo scritto anche una spiegazione di cos’è davvero l’IoT senza parole da convegno; se invece ti interessa come lavoriamo su questi progetti, la pagina delle soluzioni IoT per il monitoraggio remoto dei macchinari racconta il metodo, e nel portfolio trovi gli altri progetti che abbiamo portato in produzione.

La cosa che ci piace di questo lavoro, alla fine, è sempre la stessa: prendere qualcosa di fisico e pesante, che sta in un capannone lontano, e renderlo visibile su uno schermo da sei pollici. Il macchinario non è cambiato. È cambiato quanto ne sai.