10.9.2024

Komunikácia - BACnet protokol, časť 2

V prvom článku o protokole BACnet sme prešli obecné vlastnosti, modelovanie zariadenia pomocou objektov a spôsoby vyčítavania dát zo zariadenia. V dnešnej časti sa budeme venovať správam a typom hodnôt, ktoré BACnet protokol podporuje.

 

Správy, tagy a hodnoty objektov

 Aké typy hodnôt podporuje BACnet? Predtým, ako dokážeme zrozumiteľne odpovedať na túto otázku, vysvetlime si, ako vyzerajú BACnet správy.

Všetky dátové elementy správ sú v BACnet protokole nazývané tagy. Existujú dve triedy tagov:

  • aplikačné tagy - ich typ je pevne daný - sú to primitívne (základné) dátové typy
  • kontextové tagy - ich typ záleží od definície správy, v ktorej sa vyskytujú
Bacnet-6.png
Obr 6: aplikačné tagy – primitívne dátové typy. Typ BACnetObjectIdentifier je 32-bitový reťazec kódujúci typ objektu (10 bitov) a inštanciu (22 bitov).

 

BACnet štandard popisuje správy v ASN.1 syntaxi, ktorá umožňuje pomerne zrozumiteľný a ľahko čitateľný symbolický zápis dátových štruktúr. V tejto syntaxi je aplikačný tag zapisovaný typom a kontextový tag číslom v hranatých zátvorkách a typom. Tagy sú organizované do sekvencií (kľúčové slovo SEQUENCE).

Bacnet-7.png
Obr 7: príklad správy (požiadavka SubscribeCOV) s kontextovými tagmi. Tagy [2] a [3] sú voliteľné
(v správe nemusia byť - kľúčové slovo OPTIONAL). Správa obsahuje presne jednu sekvenciu. 

Bacnet-8.png
Obr 8: príklad správy s aplikačnými tagmi.  Posledný tag je voliteľný.
Správa môže obsahovať viac sekvencií (SEQUENCE OF SEQUENCE).

 

Bacnet-9.png
Obr 9: príklad správy s kontextovými aj aplikačnými tagmi. Kontextovo sú tagované sekvencie, pričom správa obsahuje buď sekvenciu [0] alebo sekvenciu [1] (kľúčové slovo CHOICE).

Správa umožňuje dva spôsoby špecifikácie čítania dát zo súboru - streamovo orientovaný prístup so špecifikáciou pozície a počtu bajtov a záznamovo orientovaný prístup so špecifikáciou počiatočného záznamu a počtu záznamov.

Silnou stránkou BACnet protokolu je aj variabilita správ - rôzne spôsoby špecifikácie viditeľné na obrázku 9, voliteľné parametre, opakovanie sekvencií. Podporované sú aj polia.

Teraz, keď vieme, ako vyzerá špecifikácia správ, môžeme sa pozrieť, ako vyzerajú správy použité na  čítanie hodnoty atribútu.

 

Bacnet-10.png
Obr 10: požiadavka ReadProperty-Request a odpoveď ReadProperty-ACK

Vidíme, že požiadavka je jednoduchá – špecifikuje pomocou kontextových tagov identifikátor objektu, identifikátor atribútu a voliteľne index v poli (pokiaľ je atribút pole). Odpoveď obsahuje tie isté tagy a navyše hodnotu. Tá je ale typu ABSTRACT-SYNTAX.&Type. Čo to znamená?

V ľudskej reči to znamená „tu môže byť hocičo“. No dobre, ale ako to budeme parsovať? Ako môže klient spracovať správu, v ktorej je „hocičo“ ?

Kľúčom k odpovedi je znovu ASN.1, resp. kódovanie ASN.1 tagov v binárnom formáte, ktorý je používaný v BACnet protokole. Kódovanie každého dátového elementu správy obsahuje trojicu TLV – Tag (číslo a príznak, či sa jedná o kontextový alebo aplikačný), Length (dĺžka dát) a Value (samotné dáta). Štart a koniec sekvencie (a jej tag) sú takisto v binárnom formáte zachytené. Takto môže BACnet klient spracovať odpoveď obsahujúcu ľubovolnú štruktúru. Jediný problém je, že ak je dátový element kontextový tag (napr. [2] s dĺžkou 4 bajty), tak je nutná doplňujúca informácia, ako jeho hodnotu interpretovať (môže to byť Unsigned, Signed, Real, Character String, BACnetObjectIdentifier a iné).

 Pokiaľ neobsahuje správa jednoduché dáta (či už aplikačne alebo kontextovo tagované), ale štruktúrované „hocičo“, umožňuje konfiguračný dialóg meraného bodu zadať tzv. komplexnú adresu a špecifikovať, ktorá položka štruktúrovaných dát bude do meraného bodu priradená.

 

Bacnet-11.png
Obr 11: komplexná adresa meraného bodu

Na obrázku 11 je meraný bod s komplexnou adresou [1].3.2.[1]. Znamená to, že v prijatých dátach sa najskôr hľadá kontextový tag č. 1 (očakáva sa nájdená sekvencia), následne v rámci tejto sekvencie tretí tag v poradí (opäť musí byť nájdená sekvencia) a v nej druhý tag v poradí (znovu sekvencia) a konečne v tejto poslednej sekvencii kontextový tag 1. Keďže sa jedná o kontextový tag, je nutné ešte špecifikovať pomocou parametra Application tag (na obrázku hneď nad komplexnou adresou), že ho treba interpretovať ako reálne číslo (Real).

 Konkrétnym prípadom implementácie komplexnej správy obsahujúcej štruktúrované dáta je objekt typu schedule(17) implementovaný v zariadení Siemens Desigo PXC64-U slúžiaci na vytváranie časových plánov. Pri čítaní atribútu weekly-schedule (123) s indexom poľa 1 (konfiguračný parameter Array) parsoval D2000 KOM prijatú odpoveď takto:

 

Bacnet-12.png
Obr 12: odpoveď na čítanie hodnoty atribútu weekly-schedule

Hodnota (propertyValue)  obsahuje sekvenciu v ktorej je striedavo čas a kladná hodnota. Komplexná adresa pre prístup k prvému času by bola 1.1 , k prvej hodnote by bola 1.2, k ďalšiemu času a hodnote 1.3 a 1.4. Kontextové tagy by neboli použité, keďže v rámci sekvencie propertyValue je už vnorená sekvencia a všetky hodnoty aplikačne tagované.

Načítaná hodnota predstavuje hodnotu časového plánu pre prvý deň v týždni (preto ten index poľa Array spomenutý vyššie). Dvojica čas/hodnota udáva, o ktorej hodine sa má časový plán zmeniť na požadovanú hodnotu (ktorá môže napr. reprezentovať úroveň vykurovania). Pokiaľ by sme čítali bez indexu poľa, dostali by sme propertyValue obsahujúcu sedem sekvencií, pre každý deň v týždni jednu.

Táto implementácia atribútu weekly-schedule je v súlade s BACnet normou, ktorá špecifikuje atribút weekly-schedule ako pole siedmich položiek typu BACnetDailySchedule:

 

Bacnet-13.png
Obr 13: špecifikácia atribútov objektu typu schedule

 Pričom typ BACnetDailySchedule je sekvencia BACnetTimeValue, čo je sekvencia času a hodnoty:

 

Bacnet-14.png
Obr 14: špecifikácia typov BACnetDailySchedule a BACnetTimeValue

Treba si uvedomiť, že podľa poznámky v definícii normy pole value môže byť ľubovolný primitívny typ – takže iný výrobca (alebo aj Siemens v inom zariadení) môže implementovať atribút weekly-schedule s použitím iného typu ako Unsigned. A naozaj, napr. Delta Controls DAC-1146 implementuje časový plán na základe hodnôt 0/1 (t.j. nešpecifikuje sa napr. úroveň kúrenia ale iba informácia typu kúri-nekúri), ktoré sú ale implementované nie ako dátové typy Boolean(1) ale ako Enumerated(9). Dôvodom môže byť práve rozšíriteľnosť a spätná kompatibilita v budúcnosti (podpora viacúrovňových časových plánov).

Protokol BACnet umožňuje implementátorom zadefinovať si vlastné typy objektov, v nich vlastné atribúty a hodnoty týchto atribútov nemusia byť jednoduché, ale ľubovolne komplikované a vnorené štruktúry. Klientská implementácia ich dokáže parsovať  - s tým, že v prípade použitia kontextových tagov je nutné zadať , aký je primitivny dátovy typ konkrétneho tagu. Podobnú úroveň flexibility neponúka žiaden ďalší protokol, s ktorým sme sa stretli.

D2000 KOM proces umožňuje načítanie celej štruktúrovanej hodnoty do jediného meraného bodu. Pokiaľ je bod nakonfigurovaný ako textový vstup (TxtI) bez zadania parametra Application tag, komplexná hodnota z obr. 12 (sekvencia troch dvojíc čas/hodnota) sa zapíše ako textová hodnota "{ T0:0:0; u2; T4:0:0; u3; T22:0:0; u1 }".

Znak T indikuje, že nasleduje hodnota typu Time, znak u že nasleduje hodnota typu Unsigned (ďalšie dátové typy sú popísané v helpe D2000), množinové zátvorky ohraničujú sekvenciu. Pre konkrétny prípad (časový plán) je tento spôsob vhodnejší, pretože každý zo siedmich dní týždňa môže obsahovať ľubovolný počet dvojíc čas/hodnota. Preto nie je obecne vhodné ich indexovať pomocou komplexnej adresy, ale lepšie je celý časový plán (alebo jeho jednotlivé dni) vyčítať do textového meraného bodu a následne v ESL skripte vyparsovať a zobraziť užívateľovi v tabuľke na editáciu.

V zakončení článku o týždeň sa budeme venovať zapisovaniu hodnôt, synchronizácii času a procesným alarmom implementovaným v protokole BACnet. Spomenieme aj špecifiká Siemens Desigo zariadení a ukážeme browsovanie BACnet objektov.

 

25.9.2017, Ing. Peter Humaj, www.ipesoft.com

 

Iné blogy