BACnet – stručný úvod do základů 5. díl

COV – Change Of Value

COV, neboli Change Of Value, změna hodnoty, je mechanismus, pomocí kterého se optimalizuje provoz na síti. Obecně vzato, klient by rád měl ze serveru co nejaktuálnější data. Znamenalo by to, že by se musel na proměnné dotazovat neustále dokola, přičemž by většinou nejspíš obdržel stejné hodnoty jako v minulých dotazech, protože hodnoty proměnných se obvykle zase až tak často nemění. Zároveň by ale zatěžoval síť i server zbytečnými dotazy.

BACnet proto umožňuje použít službu COV. Není to povinná funkce, každý výrobce se sám rozhoduje, jestli ji bude podporovat nebo ne. Pokud chce klient službu COV použít, pošle serveru žádost o subscription, neboli o registraci k odběru zpráv o tom, že se hodnota určité vlastnosti nějakého objektu změnila. Server ji přijme, zaregistruje si klienta a při změně příslušné hodnoty pak sám vyšle klientovi zprávu. Klient se tedy nemusí periodicky dotazovat, jen čeká na informaci o změně, tzv. notifikaci. Tím by se měla snížit frekvence dotazů a zároveň zvýšit rychlost přenosu změn ze serveru na klienta. Pokud už klient nemá o aktualizaci zájem, může registraci zrušit – třeba v případě, že uživatel přepnul na jinou stránku ve vizualizaci nebo opustil menu na obslužném pultíku.

Při registraci si klient také vyžádá, zda notifikace má být nepotvrzená nebo potvrzená. U nepotvrzené server vyšle data a nezjišťuje, jestli je klient přijal. Znamená to menší zátěž pro server i pro síť, ale informace nemusí ke klientovi dorazit. Při potvrzené notifikaci server očekává, že klient přijetí dat potvrdí. Pokud se tak do určité doby (timeout) nestane, notifikace je opakována. To znamená větší spolehlivost přenosu, ale zároveň větší zátěž pro síť i oba účastníky komunikace.

0501_cov_ok

Obr. Úspěšná žádost o registraci COV

Na obrázku výše je výpis komunikace, ve kterém v paketu 45 klient žádá server o registraci COV pro objekt Analog Input 0. V paketu 46 server tuto registraci potvrzuje (Simple-ACK) a v paketu 47 vzápětí posílá první notifikaci s hodnotami vlastností tohoto objektu. Vidíme, že jde o nepotvrzenou notifikaci – další pakety, 52 a dále[1], již řeší čtení jiného objektu, Analog Input 4.

Je-li registrována notifikace potvrzená, klient po jejím obdržení odpoví serveru potvrzovací zprávou: v paketu 14 server bezprostředně po registraci zasílá aktuální hodnoty, paketem 15 klient tuto notifikaci potvrzuje:

0502_cov_confirmed

Obr. Potvrzení notifikace

Následující obrázek naopak zachytil situaci, kdy server službu COV nepodporuje a žádost o registraci odmítl (Reject: Unrecognized Service). Klient pak už COV dále neřeší a periodicky čte aktuální hodnotu objektu Analog Input 4 službou Read Property.

0503_cov_unrecognized

Obr. Odmítnutá žádost o registraci COV

Jak server určí, kdy má notifikaci zaslat? U proměnných binárních nebo multistate (integer) je jasné, kdy ke změně došlo: místo True je False nebo naopak, integer je minimálně o 1 větší nebo menší. U proměnných typu real ale musí být určeno, jak velká změna se má považovat za tak významnou, aby notifikaci vyvolala (posílat notifikaci při sebemenší změně analogové hodnoty by pravděpodobně zatížilo linku ještě více, než pravidelné dotazování bez COV). K tomu slouží parametr COV Increment. Je to u objektů, které podporují COV, povinná vlastnost[2]. Notifikace je tedy vyslána až tehdy, pokud je od poslední notifikace změna hodnoty větší než COV Increment.

COV Increment má server nastaven jako nějakou rozumnou výchozí hodnotu, může si ji však také určit klient jako nepovinný parametr v žádosti o registraci. Pro hodnoty, jako je například teplota, je typický COV Increment 0,1 °C.

Žádost o registraci obsahuje mimo jiné identifikaci objektu, o jehož data má klient zájem, a čas, po který má registrace trvat. Po uplynutí tohoto času se předpokládá, že server registraci smaže, aby zbytečně nedržel v paměti registrace staré, již neaktuální. Klient by naopak měl registraci periodicky obnovovat, nejlépe s nějakým předstihem.

Příklady časů registrace a period obnovování u některých klientů:

Klient Požadovaný čas trvání registrace Perioda obnovování registrace
YABE

2 min.

1 min.

Siemens PXM20-E

3 min.

1,5 min.

Reliance 4

10 min.

10 min.

Tab. Příklady časování COV

Standard BACnet ale neurčuje, jaký může být nejdelší klientem požadovaný čas registrace (může to být i „nekonečno“). Pokud server podporuje COV, měl by akceptovat dobu registrace nejméně 8 hodin. Není ovšem předepsáno, že by server musel udržovat registrace i po výpadku napájení. Server sice může ukládat registrace do paměti, která se při restartu nemaže, ale potom zase hrozí riziko, že velké množství registrací na nekonečně dlouho jeho paměť časem zaplní – je tedy pak nutné definovat pravidla pro periodické čištění paměti… Proto může docházet k situacím, kdy například:

  • klient úspěšně zažádá o registraci například na 12 hodin, po několika minutách je server restartován, přičemž dojde ke smazání registrací. Klient žije v domnění, že by mu notifikace chodily, nicméně informace o nových hodnotách nedostává,
  • klient si zaregistruje bez potvrzení velký počet hodnot na dlouhou dobu, načež v serveru dojde k situaci, kdy najednou vznikne velké množství změn (krátkodobý výpadek napájení, uzavření stovek požárních klapek atd.). Klient nestačí příchozí změny zpracovávat a může dojít ke ztrátě dat,
  • klienti registrují velký počet hodnot, ale registrace neruší – server tudíž buď musí vyhradit dostatek paměti na to, aby uložil všechny požadavky, nebo časem začne nové požadavky zamítat,
  • atd.

S těmito vlastnostmi musíme počítat při projektování sítí a úvahách o spolehlivosti komunikace. Vždy záleží na tom, jak je implementace BACnetu v daném zařízení kvalitní.

 

Všechny díly najdete ZDE.


[1] V číslování paketů ve výpisech některá čísla chybí, protože na výpis je aplikován filtr – zobrazují se pouze pakety protokolu BACnet. Ostatní provoz na síti zde není viditelný.

[2] Přesněji řečeno, u objektů, které podporují COV a poskytují analogové hodnoty: jsou to objekty typů Analog…, Loop a Pulse.