Interrogazione industriale, backpressure e nuovi tentativi

Un master Modbus RTU invia una richiesta, attende la risposta o il timeout e solo dopo invia la successiva. Un bus RS-485 ha quindi un limite di capacità che nessuna impostazione può aumentare. Un gateway Modbus TCP davanti al bus non aggiunge capacità. Se il sistema di interrogazione chiede di più, la coda delle richieste in attesa cresce e il valore sulla dashboard rimane indietro rispetto all'orologio. Conta le transazioni prima di impostare gli intervalli di interrogazione.

Questa guida fa parte della serie sulla qualità e sulla trasmissione dei dati.

Contare le transazioni sulla connessione condivisa

Conta nel punto più stretto. Dieci client Modbus TCP che leggono attraverso un gateway seriale condividono la sua unica porta RS-485, indipendentemente dalla velocità del lato Ethernet. Il gateway mette in coda le richieste e le invia sul bus una alla volta.

Esempio calcolato su un bus RS-485 a 9600 bit/s, con 8 bit di dati, parità pari e 1 bit di stop:

Questo bus aggiorna ogni punto circa ogni 3,4 s, e non più spesso. Un intervallo di interrogazione di 1 s richiede una capacità 3,4 volte superiore a quella del bus. Il calcolatore dei tempi Modbus RTU qui sotto usa gli stessi dati. Restituisce 85 ms per scambio e 0,68 s per una richiesta a ciascuno degli otto contatori. Cinque blocchi per contatore portano il ciclo a 3,4 s.

Con 11 bit per carattere, un carattere richiede 1,15 ms a 9600 bit/s e l'intervallo fra frame di 3,5 caratteri richiede 4,0 ms. Oltre 19.200 bit/s, la guida per la linea seriale fissa l'intervallo fra frame a 1,75 ms e il timeout fra caratteri a 0,75 ms (sezione 2.5.1.1). Una velocità di trasmissione maggiore riduce il tempo sul filo, ma non il ritardo di risposta del dispositivo. A 38.400 bit/s lo stesso scambio richiede circa 37 ms, di cui 20 ms sono del contatore.

Leggi blocchi più grandi. Ogni transazione comporta una richiesta, un ritardo del dispositivo e un intervallo fra frame, indipendentemente dal numero di registri restituiti. A 9600 bit/s con un ritardo del dispositivo di 20 ms, 20 letture da 2 registri richiedono circa 870 ms. Una lettura degli stessi 40 registri consecutivi richiede circa 130 ms. I codici funzione 03 e 04 leggono fino a 125 registri in una richiesta (specifica del protocollo applicativo Modbus V1.1b3, sezioni 6.3 e 6.4). Un blocco che comprende un indirizzo non implementato dal dispositivo fallisce con l'eccezione 02, indirizzo dati non valido. Unisci i blocchi solo negli intervalli che la mappa dei registri indica come leggibili e verifica se la mappa prevede un limite inferiore per richiesta.

BACnet MS/TP presenta lo stesso limite in un'altra forma. Un controllore trasmette solo quando possiede il token e un router invia al massimo Max_Info_Frames richieste ogni volta che lo possiede. Edge interroga BACnet tramite BACnet/IP: raggiunge quindi i controllori MS/TP attraverso un router e ogni lettura attende il turno di quel router. La guida BACnet/IP e MS/TP illustra il tempo di rotazione del token.

Il costo di un dispositivo offline

Ogni richiesta a un dispositivo che non risponde attende l'intero timeout di risposta. Nell'esempio, con un timeout di 1 s e cinque richieste per contatore, un contatore offline aggiunge 5 s a ogni ciclo. Il ciclo passa da 3,4 s a 8,0 s e gli altri sette contatori, funzionanti, vengono letti meno della metà delle volte.

La guida per la linea seriale indica da 1 s a diversi secondi a 9600 bit/s come timeout di risposta tipico (sezione 2.4.1). È un valore prudente per un dispositivo lento, ma costoso su un bus occupato. Imposta invece il timeout in base alle misure. Registra la risposta più lenta di ciascun dispositivo durante una giornata di normale funzionamento e imposta il timeout a circa il doppio di quel valore. Un contatore la cui risposta più lenta è di 150 ms riceve un timeout di 300 ms. La penalità del contatore offline nell'esempio scende così da 5 s a 1,5 s.

Applica poi un backoff per ogni dispositivo. Per esempio, dopo tre timeout consecutivi, togli il dispositivo dalla normale pianificazione e contrassegna i suoi punti come obsoleti. Invia una richiesta di prova ogni 60 s. Quando una prova riesce, ripristina la pianificazione. I contatori funzionanti tornano al ciclo di 3,4 s e il contatore offline costa 0,3 s al minuto.

Il bus deve comunque avere margine per i timeout che si verificano prima che inizi il backoff. Con un intervallo di 5 s, il bus dell'esempio ha 1,6 s di margine. Un contatore offline con timeout di 300 ms costa 1,5 s e rientra nel margine. Lo stesso contatore con timeout di 1 s costa 5 s e non vi rientra. Quando i timeout di un dispositivo non rientrano nel tempo disponibile, dividi il bus.

Quando le richieste arrivano più in fretta di quanto vengano completate

Interroga il bus dell'esempio ogni 1 s: il sistema genera 40 richieste al secondo. Il bus ne completa circa 12. La coda cresce di circa 28 richieste al secondo. Se viene servita in ordine, la richiesta inviata dopo dieci minuti era stata messa in coda circa sette minuti prima. Ogni indicatore di stato può restare verde: il bus è occupato, i dispositivi rispondono e nessuna richiesta fallisce. Solo i timestamp mostrano che i dati hanno sette minuti di ritardo.

Decidi come gestire il lavoro in ritardo:

Monitora l'età della richiesta in attesa più vecchia oltre alla lunghezza della coda. Su un bus che tiene il passo, nessuna richiesta attende più di un intervallo di interrogazione. Genera un allarme quando la più vecchia supera due intervalli.

Separare i punti in tempo reale dai registri di energia

La maggior parte dei punti non richiede l'intervallo più breve. Un registro di energia (kWh) è un totale progressivo: una lettura ogni 15 minuti non perde energia, perché la lettura successiva include quanto accumulato nel frattempo. Potenza, setpoint o stato di un interruttore usati per il controllo richiedono invece intervalli di pochi secondi.

Assegna ai pochi punti in tempo reale un intervallo breve e ai registri di energia e configurazione uno lungo. Supponi che ciascun contatore nell'esempio abbia un blocco in tempo reale letto ogni 5 s e quattro blocchi di energia letti ogni 15 minuti. Le letture in tempo reale usano allora 8 × 85 ms = 0,68 s ogni 5 s. Le 32 letture di energia richiedono 2,7 s una volta ogni 15 minuti. Distribuiscile nell'intervallo, affinché non cadano tutte al quarto d'ora e non ritardino le letture in tempo reale di 2,7 s.

Ritentare solo ciò che può riuscire

Dietro un gateway Modbus TCP, due timeout sono in serie: quello del client e quello seriale del gateway. Imposta il timeout del client più lungo del timeout seriale del gateway, più il tempo di attesa della richiesta nella coda del gateway. Altrimenti il client rinuncia mentre il gateway sta ancora elaborando la richiesta, ritenta e mette una seconda copia della stessa lettura sul bus. La guida Modbus TCP e RTU tratta i timeout del gateway e i limiti di connessione.

Un timeout durante una scrittura (funzione 06 o 16) non dimostra che la scrittura sia fallita. Il dispositivo potrebbe averla applicata e la risposta potrebbe essersi persa. Rileggi il registro prima di ritentare. Scrivere due volte un setpoint assoluto non comporta conseguenze. Una scrittura che avvia un'azione, come l'azzeramento di un contatore o un comando di avvio, può agire due volte: non ritentarla mai senza una rilettura.

Backoff esponenziale e jitter contano quando molti client condividono un server. Diversi client Modbus TCP dietro un gateway, oppure una flotta di gateway di sito che si riconnettono allo stesso server dopo un'interruzione, ritentano tutti insieme a meno che ciascuno non aggiunga un ritardo casuale. AWS descrive questo schema, con un limite al numero di tentativi e all'attesa massima. In sua assenza, i nuovi tentativi dopo il ripristino possono mantenere sovraccarica una connessione lenta anche quando il guasto è risolto. Su un singolo bus RS-485 c'è un solo master, quindi il jitter non cambia nulla. A fare la differenza è il backoff per dispositivo.

Provare il ripristino sotto carico

1. Esegui l'elenco completo dei punti agli intervalli previsti per almeno un'ora. Registra il tempo di ciclo. Deve essere più breve dell'intervallo di interrogazione più rapido di almeno la durata dei timeout di un dispositivo.
2. Spegni un dispositivo. Dopo l'avvio del backoff, le letture degli altri dispositivi devono tornare ad avere meno di due intervalli di ritardo.
3. Riaccendilo. I suoi punti devono tornare aggiornati entro un periodo di prova, 60 s nell'esempio sopra.
4. Interrompi il collegamento verso il sistema a monte per 30 minuti. Le letture locali devono conservare i timestamp normali e la coda in uscita deve crescere alla velocità prevista: punti al minuto × 30.
5. Ripristina il collegamento. Ogni lettura in coda deve arrivare una volta. Conta le letture per punto e timestamp nel destinatario e verifica che il tempo di ciclo del bus torni al valore del punto 1 entro due cicli.

Interrogazione in Edge

Edge sul Gateway ZGW-20 ha cinque slot di connessione Modbus. Ogni slot gestisce un endpoint: una porta seriale oppure un host e una porta TCP. Ognuno ha code, limiti di frequenza, dati di latenza e backoff degli errori propri, nonché una pausa di 2.000 ms nelle letture in tempo reale dopo una scrittura. Tutti gli ID unità su uno slot li condividono, quindi un dispositivo guasto dietro un gateway può ritardare anche quelli funzionanti sullo stesso slot. Usa uno slot per ogni endpoint indipendente.

Il backoff degli errori conta le richieste fallite consecutive sullo slot, non su un singolo dispositivo. Dopo 3, Edge sospende le letture dello slot per 5 s o due intervalli di interrogazione, scegliendo il maggiore. Dopo 6 la pausa è di 15 s o tre intervalli, e dopo 10 è di 30 s o cinque intervalli. Una risposta riuscita azzera il conteggio. I dispositivi funzionanti sullo stesso slot di solito rispondono fra le richieste del dispositivo offline, quindi il conteggio raramente arriva a 3. I timeout del dispositivo offline continuano allora a ogni ciclo: per questo è importante il valore del timeout.

Per impostazione predefinita, uno slot invia fino a 20 richieste in tempo reale e 5 richieste pianificate, allineate all'orologio, al secondo. Entrambi i limiti possono essere impostati da 1 a 100. Il limite predefinito in tempo reale supera la capacità del bus dell'esempio, circa 12 al secondo a 9600 bit/s: impostalo sotto la capacità che hai misurato. La coda pianificata contiene 5.000 richieste e scarta prima le più vecchie. La coda in tempo reale ne contiene 250 e unisce le letture equivalenti. Quando la latenza di uno slot supera 5.000 ms, Edge riduce l'interrogazione in tempo reale su quello slot a una richiesta al secondo. Edge unisce letture contigue in blocchi fino a 125 registri. Ogni slot segnala la latenza più recente e media e il numero di errori; Edge registra un avviso quando scarta letture pianificate. Un dispositivo va offline dopo due interrogazioni previste mancate, e mai prima di cinque minuti.

Questi limiti proteggono un bus lento. Non aggiungono capacità. Un'interfaccia Modbus ZMB è il master RS-485 del proprio bus corto. La ZMB-31 legge fino a 30 registri dall'apparecchiatura accanto a essa e li invia al Gateway tramite la rete mesh Zigbee. Più ZMB sostituiscono un unico lungo bus condiviso con più bus corti, ognuno con il proprio budget di timeout.