Diagnostica e allarmi da remoto: individuare un impianto fermo prima del cliente

C'è una differenza operativa importante tra "un impianto ha smesso di produrre" e "un impianto ha smesso di comunicare". Nel primo caso c'è probabilmente un guasto reale — un inverter in blocco, una stringa disconnessa. Nel secondo, l'impianto potrebbe star producendo normalmente, ma il device che dovrebbe inviare le misure (un gateway, una connessione cloud, un router) si è fermato. Sono due problemi diversi, con due urgenze diverse, e confonderli — o peggio, non accorgersene affatto finché non chiama il cliente — è uno dei modi più comuni in cui un installatore perde fiducia.

Il problema della "staleness" silenziosa

Un dato che non arriva più non genera, di per sé, nessun errore visibile: la dashboard smette semplicemente di aggiornarsi, e se nessuno la guarda attivamente, nessuno se ne accorge. Questo è il problema della staleness: misure che diventano "vecchie" rispetto a quanto ci si aspetterebbe da un impianto sano, senza che nulla lo segnali esplicitamente.

La piattaforma affronta questo con un valutatore di freschezza dedicato — un'unica fonte di verità per le soglie di staleness, condivisa da tutta la diagnostica — che confronta l'ultimo timestamp di misura ricevuto con quanto tempo dovrebbe passare, in condizioni normali, tra due letture dello stesso device. Quando quel margine viene superato, scatta un allarme.

Un modello di allarme che sa anche chiudersi da solo

Un allarme che si limita ad "accendersi" e non si spegne mai da solo è quasi peggio di nessun allarme: genera fatica da notifica, e dopo un po' viene ignorato. Per questo il modello di allarmi è costruito attorno a un ciclo di vita idempotente di raise e clear: quando un device torna a inviare dati regolarmente, l'allarme relativo si chiude automaticamente, senza intervento manuale e senza duplicare allarmi già aperti per la stessa condizione.

Alla base c'è un modello di allarme canonico e un vocabolario di codici evento condiviso: ogni condizione anomala (device fermo, impianto degradato, lettura a zero sospetta) ha un codice riconoscibile, non un messaggio di testo libero diverso ogni volta. Questo rende gli allarmi filtrabili, aggregabili e — soprattutto — affidabili nel tempo: lo stesso codice evento oggi significa la stessa cosa tra sei mesi.

Un dettaglio che conta più di quanto sembri: la diagnostica distingue tra un intero impianto fermo e un singolo device fermo mentre il resto dell'impianto è regolare. Un impianto con tre inverter di cui uno ha smesso di comunicare non deve sparire dai radar né generare un allarme generico "impianto guasto" — deve segnalare con precisione quale device ha smesso di rispondere, mentre gli altri due continuano a essere monitorati normalmente.

Perché conta per chi gestisce, non solo per chi installa

Per un installatore o un EPC con un portafoglio impianti, il valore di questo non è tecnico ma di fiducia: essere il primo a sapere che qualcosa non va, prima che lo scopra il cliente controllando la app del proprio inverter o, peggio, notando la bolletta più alta del previsto. Un allarme che si apre e si chiude in autonomia, ogni volta collegato a un impianto specifico e (nel modello multi-tenant) visibile solo a chi ha in gestione quell'impianto, è la differenza tra reagire e anticipare.

Se gestisci impianti e vuoi essere avvisato quando un device smette di comunicare — prima che lo faccia il cliente — entra in lista d'attesa.