Un client BACnet ottiene un valore in due modi. Il polling lo legge secondo il programma del client, con ReadProperty o ReadPropertyMultiple. Il change of value (COV) chiede al dispositivo di inviare una notifica quando il valore cambia almeno di una quantità stabilita. La scelta determina il traffico di rete, la rapidità con cui arriva una variazione e il significato del silenzio.
Questa guida fa parte della serie BACnet e protocolli per gli edifici.
Come funziona il COV
Un client invia SubscribeCOV per un oggetto del dispositivo. La richiesta identifica il processo del sottoscrittore, sceglie notifiche confermate o non confermate e indica una durata in secondi. Il dispositivo invia poi una notifica contenente Present_Value e Status_Flags:
- una volta all'accettazione della sottoscrizione, così il client riceve il primo valore;
- per un oggetto analogico, quando Present_Value cambia di almeno il suo COV_Increment rispetto all'ultima notifica;
- per un oggetto binario o multistato, a ogni cambiamento di stato;
- quando cambiano gli Status_Flags, per esempio se il punto entra in allarme o va fuori servizio.
Supponiamo un incremento di 0,5 °C e un ultimo valore notificato di 20,0 °C. Letture di 20,2 °C e 20,4 °C non inviano nulla. Una lettura di 20,6 °C genera una notifica anche se ogni passo è stato soltanto di 0,2 °C: il dispositivo confronta il valore con l'ultima notifica, non con la lettura precedente. Una deriva lenta viene quindi comunicata quando raggiunge l'incremento. Una variazione inferiore all'incremento non viene mai notificata: il client può conservare per tutto il tempo in cui la stanza resta in quella condizione un valore distante quasi 0,5 °C da quello reale.
SubscribeCOVProperty sottoscrive una singola proprietà e permette al client di impostare il proprio incremento. Si usa per osservare una proprietà diversa da Present_Value, per esempio High_Limit, o per prevalere sul COV_Increment dell'oggetto senza scrivere nel controllore.
L'incremento determina anche il carico. Se un controllore legge un ingresso analogico rumoroso una volta al secondo e l'incremento è 0,01, può inviare una notifica al secondo a ogni sottoscrittore: 3.600 all'ora per un solo punto. Nel racconto della rete del campus Cornell, Newman cita un incremento troppo piccolo tra i problemi dei controllori che l'università limita facendo vedere a ogni rete dell'edificio soltanto il proprio traffico e al sistema centrale.
Notifiche confermate e non confermate
Una notifica confermata richiede una conferma di ricezione dal client. Se questa non arriva entro il timeout APDU del dispositivo, il dispositivo ritrasmette fino al numero configurato di tentativi. Una notifica non confermata viene inviata una volta sola, senza ritrasmissione. Se un router la perde o il client è occupato, la variazione si perde senza che le parti lo sappiano.
Usa notifiche confermate per allarmi e stati d'impianto. Le conferme aggiungono un breve messaggio per variazione. Le notifiche non confermate si prestano a punti analogici ad alta frequenza, dove la variazione successiva sostituisce quella persa, ma soltanto con una lettura di controllo (vedi Che cosa significa il silenzio).
Durata e rinnovo
La durata è il tempo per cui il dispositivo mantiene la sottoscrizione senza rinnovo. Il client la rinnova inviando di nuovo lo stesso SubscribeCOV prima della scadenza. In un client, la durata è normalmente un'impostazione. In Beckhoff TF8020 si chiama Subscriptions Lifetime nella finestra Settings.
Tenta il rinnovo a metà della durata e riprova prima della scadenza se il tentativo fallisce. Per una sottoscrizione di 600 s, il tentativo a 300 s lascia tempo per riprovare; aspettare 600 s dopo un tentativo perso raggiunge già il limite di scadenza. Le linee guida dei BACnet Testing Laboratories (BTL) richiedono che ogni server COV accetti qualsiasi durata da 1 a 28.800 s (8 ore), quindi valori in quell'intervallo non vengono respinti (clausole 7.24 e 7.25).
Una durata pari a 0 significa sottoscrizione indefinita. Evitala. La clausola BTL 7.6 ne spiega i motivi: il dispositivo non deve necessariamente conservare l'elenco delle sottoscrizioni dopo un reset o un'interruzione dell'alimentazione, un controllore sostituito parte con l'elenco vuoto e la sottoscrizione di un client rimosso occupa uno slot per sempre. SubscribeCOVProperty non consente una durata pari a 0.
Gli slot di sottoscrizione sono limitati. La norma richiede a un server COV il supporto di sole cinque sottoscrizioni contemporanee (BTL clausola 7.7, che cita le clausole K.1.12 e K.1.13 di ASHRAE 135). BACnet Stack, il progetto open source, ne riserva 128 per impostazione predefinita. Quando la tabella è piena, la richiesta di sottoscrizione fallisce con un errore: in BACnet Stack la classe è RESOURCES e il codice NO_SPACE_TO_ADD_LIST_ELEMENT. La proprietà Active_COV_Subscriptions dell'oggetto Device elenca le sottoscrizioni mantenute dal dispositivo. Leggila durante la messa in servizio per verificare quanti slot usano già il supervisore e gli altri client.
Una sottoscrizione fallita non deve passare inosservata. La clausola BTL 7.7 indica di ripiegare sul polling di quel punto, avvisare l'operatore o fare entrambe le cose.
Polling e COV a confronto
| Polling | COV | |
|---|---|---|
| Chi avvia ogni messaggio | Il client, secondo il proprio programma | Il dispositivo, quando cambia il valore |
| Traffico per un valore stabile | Una richiesta e una risposta a ogni intervallo | Soltanto i rinnovi, per esempio uno scambio ogni 300 s |
| Tempo di arrivo di una variazione | Fino a un intervallo di polling, più la lettura | Ciclo di scansione COV del dispositivo più transito; su MS/TP, anche l'attesa del token |
| Piccole variazioni | Visibili a ogni polling | Nascoste finché non raggiungono insieme l'incremento |
| Supporto richiesto | ReadProperty, che ogni dispositivo BACnet deve eseguire | SubscribeCOV nel dispositivo e nel client |
| Risorse sul dispositivo | Nessuna risorsa mantenuta | Uno slot per punto e per client; il minimo richiesto è cinque |
| Dopo il riavvio del dispositivo | Funziona il polling successivo | Le sottoscrizioni possono andare perse; tornano al rinnovo successivo |
| Prova che il dato è fresco | Timestamp di ogni lettura riuscita | Ultimo rinnovo, ultima notifica e lettura di controllo |
Bilancio del polling su MS/TP
Su BACnet/IP, leggere alcune centinaia di punti una volta al minuto genera un carico modesto. Su MS/TP occorre fare i conti. MS/TP trasmette 10 bit per ottetto. Una richiesta ReadProperty per Present_Value di un Analog Input occupa circa 23 ottetti nel frame MS/TP; la risposta con un REAL circa 29 ottetti. A 38.400 bit/s sono circa 14 ms per punto, prima delle pause di inversione, del ritardo di risposta del controllore e del passaggio del token fra gli altri master.
Calcola le letture al secondo prima di scegliere un intervallo. Trecento punti ogni 60 s sono 5 letture al secondo, circa 70 ms di ogni secondo sul mezzo. Trecento punti ogni 5 s sono 60 letture al secondo, circa 0,8 s di ogni secondo: non resta spazio per il traffico dei controllori. ReadPropertyMultiple trasporta più punti nello stesso scambio dove il dispositivo lo supporta e riduce il costo per punto. La guida BACnet/IP e MS/TP spiega il ciclo del token e le velocità.
Che cosa significa il silenzio
Con il polling, una lettura fallita è visibile: la richiesta va in timeout. Con il COV, il silenzio ha due possibili significati. Il valore potrebbe non essere cambiato oppure la sottoscrizione potrebbe essere sparita perché il dispositivo è stato riavviato, la durata è scaduta o una notifica è andata persa. Un valore stabile e una sottoscrizione morta appaiono uguali.
Registra tre timestamp per ogni punto COV:
- Ultima variazione: quando il valore è cambiato l'ultima volta.
- Ultimo messaggio: quando è arrivata l'ultima notifica o lettura riuscita.
- Ultimo rinnovo: quando è stato confermato l'ultimo SubscribeCOV per il punto.
Leggi ogni punto COV ogni 15 minuti come controllo. Se la lettura differisce dall'ultimo valore notificato almeno quanto l'incremento, una notifica è andata persa: rinnova la sottoscrizione e segnala il guasto. Marca il punto come obsoleto quando l'ultimo rinnovo è più vecchio della durata oppure l'ultimo messaggio è più vecchio dell'intervallo di controllo più un minuto. Per una durata di 600 s e un controllo ogni 15 minuti, le soglie sono 600 s e 960 s. La guida ai dati obsoleti spiega come mostrare e gestire valori che non sono più freschi.
Il polling richiede la stessa attenzione sotto un'altra forma. Un pianificatore che si avvia ogni minuto non dimostra che arrivi un valore valido ogni minuto. Misura il tempo fra letture riuscite.
Scegliere per punto
| Punto | Scelta abituale |
|---|---|
| Energia e potenza per analisi, ogni 1–15 minuti | Polling all'intervallo di analisi, allineato all'orologio |
| Temperature ambiente per la valutazione del comfort | Polling ogni 5 minuti oppure COV con incremento di 0,2–0,5 °C |
| Stati d'impianto e allarmi che devono arrivare entro pochi secondi | COV con notifiche confermate, durata 600 s rinnovata ogni 300 s e lettura di controllo ogni 15 minuti |
| Molti punti su un bus MS/TP | Leggi soltanto i punti necessari, con ReadPropertyMultiple dove supportato, oppure leggili dal supervisore BMS via BACnet/IP |
Prova la scelta sul sito, affiancando il registro del client e lo storico del controllore:
- Lascia stabile il punto per 30 minuti. Esito positivo: rinnovi confermati ogni 300 s, nessuna notifica e letture di controllo uguali all'ultimo valore.
- Produci una variazione inferiore all'incremento. Esito positivo: nessuna notifica e nuovo valore visibile nella successiva lettura di controllo.
- Produci una variazione superiore all'incremento. Esito positivo: una notifica. Registra il ritardo fra variazione e arrivo: è la latenza osservata sul sito.
- Riavvia il controllore. Esito positivo: le notifiche riprendono entro un intervallo di rinnovo e, se non riprendono, il punto risulta obsoleto.
- Riavvia il client. Esito positivo: si sottoscrive di nuovo prima di marcare qualsiasi punto come fresco.
- Leggi Active_COV_Subscriptions. Esito positivo: il dispositivo mantiene le sottoscrizioni previste e dispone di slot liberi.
Polling con Edge
Edge sul Gateway ZGW-20 legge BACnet/IP tramite polling di Present_Value. Non si sottoscrive al COV. Ogni punto segue un programma allineato all'orologio, per esempio ogni 60 o 300 secondi, oppure la modalità live, che legge comunque una volta al minuto. Ogni lettura riuscita ha il proprio timestamp. Una lettura fallita non registra un nuovo valore, quindi un controllore fermo appare come un vuoto nei dati. Edge non si collega direttamente a MS/TP: i controllori MS/TP si raggiungono tramite un router BACnet/IP o il supervisore BMS. Leggi così i punti energetici e ambientali lenti, e lascia al BMS gli allarmi che devono arrivare entro pochi secondi.
Domande frequenti
Che cos’è il COV in BACnet?
Change of value, cioè variazione di valore. Un client sottoscrive un oggetto e il dispositivo invia una notifica quando Present_Value cambia almeno dell’incremento COV rispetto all’ultima notifica oppure cambiano gli Status_Flags. Sostituisce il polling ripetuto per punti che cambiano raramente.
Che cos’è un incremento COV?
È la variazione minima di Present_Value di un oggetto analogico che genera una notifica COV. Con incremento di 0,5 °C e ultimo valore notificato di 20,0 °C, letture di 20,2 e 20,4 °C non inviano nulla; una lettura di 20,5 °C o più genera una notifica. Gli oggetti binari e multistato notificano ogni cambiamento di stato.
Quanto deve durare una sottoscrizione COV?
Usa una durata finita e rinnova a circa metà, per esempio 600 s con rinnovo ogni 300 s. BTL richiede ai server COV di accettare durate da 1 a 28.800 s. Una durata di 0 significa indefinita e le linee guida BTL chiedono ai client di evitarla.
Il COV è migliore del polling?
Riduce il traffico per punti che cambiano raramente e segnala rapidamente le variazioni di stato. Richiede il supporto sia nel dispositivo sia nel client, occupa uno slot di sottoscrizione e richiede rinnovi e una lettura di controllo. Il polling è più semplice e fornisce un timestamp a ogni intervallo.