Scegliere il protocollo giusto

Il collegamento di un impianto comincia quasi sempre dalla domanda sbagliata. Non è «quale protocollo supportate», ma «quale dato deve uscire da questo dispositivo, ogni quanto, e chi altro lo sta già leggendo». Dalle risposte a queste tre il protocollo scende quasi da solo, e la scelta smette di essere una preferenza.

Il protocollo non lo scegli tu, lo sceglie il campo

Un analizzatore di rete montato in un quadro nel 2014 espone quello che espone. Un inverter fotovoltaico ha la sua interfaccia e non ne avrà altre. Un contatore di calore fiscale ha un’uscita normata e un contratto dietro. Nella grande maggioranza dei casi la scelta non è fra tutti i protocolli esistenti: è fra i due o tre che quel dispositivo ha già a bordo.

Questo cambia l’ordine delle operazioni. Prima si fa l’inventario di che cosa c’è e di che cosa espone, poi si decide come leggerlo. L’ordine inverso — scegliere l’architettura e poi cercare i dispositivi che ci stiano dentro — porta a sostituzioni di hardware che nessuno aveva messo a budget.

Parti dal dato, non dalla porta

Prima di guardare le morsettiere, scrivi che cosa deve arrivare dall’altra parte. Per ogni dispositivo servono tre righe:

• La grandezza e la sua unità: energia attiva in kWh, potenza in kW, temperatura in °C. Non «i dati del contatore».
• Il passo con cui ha senso leggerla: al quarto d’ora per un’utenza di stabilimento, al secondo per un transitorio che stai indagando.
• Chi altro la sta già leggendo, e se quel qualcuno accetta di condividerla o pretende il collegamento in esclusiva.

La terza riga è quella che salta più spesso ed è quella che costa di più. Molti dispositivi seriali tollerano un master solo: se il sistema di supervisione li sta già interrogando, il tuo secondo master non si aggiunge, entra in conflitto.

Modbus, e perché nel dubbio è la risposta

Modbus è vecchio, minimale e privo di semantica: legge registri numerati, non grandezze con un nome. Proprio per questo lo implementano tutti, ed è la ragione per cui resta il minimo comune denominatore fra analizzatori di rete, contatori, PLC e inverter.

Il prezzo è che la mappa dei registri non sta nel protocollo, sta nel manuale del dispositivo. Ogni collegamento porta con sé una tabella: indirizzo, tipo di dato, ordine dei byte, fattore di scala. È un lavoro noioso ma finito, che si fa una volta per modello e non per esemplare — ed è per questo che conviene tenerlo scritto da qualche parte che non sia il progetto di un singolo impianto.

Le due varianti si scelgono da sole: RTU su seriale, quando il dispositivo ha solo una linea a due fili e vive su un bus condiviso; TCP quando ha una porta Ethernet e un indirizzo. Non sono due protocolli diversi, sono lo stesso protocollo su due trasporti, e la differenza pratica sta tutta in quanti dispositivi devono aspettare il proprio turno.

Quando Modbus non basta

Ci sono tre casi in cui insistere con Modbus è un errore: quando il dato non è elettrico, quando la semantica conta più del numero, e quando il dispositivo appartiene a un mondo che ha già la sua norma.

La riga che pesa di più in una diagnosi energetica è la prima. Una diagnosi si fa per vettore, e calore, gas e acqua non parlano Modbus: senza M-Bus si misura l’energia elettrica e si stima il resto, che è esattamente ciò che una diagnosi basata su dati misurati non può fare.

Il passo di lettura è una scelta, non un default

Il passo si decide sul fenomeno, non sulle capacità del collegamento. Un consumo di stabilimento si legge al quarto d’ora perché è il passo su cui è costruita la tariffa e su cui si confronterà la baseline. Un transitorio di avviamento al quarto d’ora semplicemente non esiste: o lo leggi al secondo, o non lo stai misurando.

Leggere tutto al secondo «per sicurezza» sembra prudente e non lo è. Moltiplica il carico sul bus, riempie lo storico di punti che nessuno guarderà e soprattutto non aggiunge informazione: un contatore che integra internamente su quindici minuti restituisce quindici volte lo stesso valore, non quindici valori.

La regola pratica è il passo più lungo che descrive ancora il fenomeno che devi vedere. Se una decisione si prende su base oraria, misurare al minuto è già abbondante.

Tre errori che si pagano dopo sei mesi

L’ordine dei byte dato per scontato. Un valore a 32 bit letto con le parole invertite non dà errore: dà un numero. Sbagliato di ordini di grandezza, ma plausibile abbastanza da finire in un report. Si verifica una volta sola, confrontando la lettura con il display del dispositivo, e non si verifica mai più.

Il totalizzatore che riparte da zero. Un contatore ha un fondo scala, e quando lo raggiunge riparte. Se i consumi si calcolano come differenza fra letture consecutive, quel giro produce un consumo negativo enorme oppure — peggio — viene scartato in silenzio e lascia un buco. Va gestito quando si progetta la lettura, non quando succede.

L’indirizzo lasciato al caso. Un dispositivo che prende l’indirizzo di rete automaticamente prima o poi lo cambia, e il collegamento smette di funzionare senza che nessuno abbia toccato niente. Vale anche per gli indirizzi di nodo su un bus seriale: se non sono documentati, il primo intervento di manutenzione li riassegna.

Prima di collegare

Una lista breve, da percorrere una volta per impianto:

• Inventario dei dispositivi con marca, modello e interfacce effettivamente presenti — non quelle a catalogo.
• Per ciascuno: le grandezze da leggere, con unità e passo.
• Chi altro interroga quel dispositivo oggi, e con quale ruolo.
• La mappa dei registri o dei punti, verificata su un esemplare reale contro il display.
• Come si comporta il sistema quando un dispositivo non risponde: un buco dichiarato è un dato, uno zero silenzioso è un errore che entrerà nei totali.

L’ultima riga è quella che distingue un collegamento fatto bene da uno che sembra funzionare. Un impianto misurato produce anche l’informazione di quando non ha misurato, e quella informazione va conservata insieme al resto.