Protokol BACnet

Podporované typy a verzie zariadení
Konfigurácia komunikačnej linky
Konfigurácia komunikačnej stanice
Konfigurácia meraných bodov
Scheduler v zariadeniach Siemens Desigo
Scheduler v zariadeniach Delta Controls
Informácie o eventoch
Informácie o alarmoch
Poznámka k cachovaniu adries
Poznámka k zariadeniam Delta Controls
Poznámka k zariadeniam E-DDC3.1
Poznámka k zariadeniam Klimasoft MBG-MSTP
Poznámka k zariadeniam Siemens Desigo
Poznámka k iLON 10 Ethernet adaptéru
Poznámka k implementácii BACnet MS/TP
Poznámka k podpore BBMD (BACnet Broadcast Management Devices)
Tell príkazy
Literatúra
Zmeny a úpravy
Revízie dokumentu

Podporované typy a verzie zariadení


Protokol BACnet (Building Automation and Control Networks) je implementácia štandardu ANSI/ASHRAE 135-2001.
Implementácia bola testovaná na nasledovných zariadeniach:


Vlastnosti aktuálnej verzie sú:

Protokol BACnet sa pozerá na všetkých účastníkov komunikácie ako na sieťové zariadenia (network devices). Každé sieťové zariadenie obsahuje aspoň jeden (väčšinou práve jeden) objekt typu Device (jeho Object Identifier musí byť unikátny v celej sieti). Tento objekt obsahuje ďalšie objekty zadefinovaných typov (Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value, Calendar, Command, Event, Group, File atď.) Zisťovanie objektov - viď popis Request type Who-Is a Who-Has.
Jednotlivé objekty majú vlastnosti (properties), pričom norma definuje pre jednotlivé typy objektov povinné a voliteľné vlastnosti a navyše každý výrobca BACnet zariadení môže implementovať ďalšie rozširujúce vlastnosti podľa potreby.
Správy protokolu BACnet sa týkajú manipulácie s objektmi a ich vlastnosťami. Správy sú definované pomocou ASN.1 (Abstract Syntax Notation version 1) a zakódované pomocou zjednodušenej verzie BER (Basic Encoding Rules - základné kódovanie ASN.1 správ).
Definícia správ obsahuje okrem pevne definovaných položiek aj položky typu 'Abstract Syntax & Notation', čo znamená, že na danom mieste správy môže byť ľubovoľná sekvencia (resp. 'strom'), ktorej význam určuje implementátor. Použitie BER umožňuje parsovanie aj takejto správy s vopred neznámymi položkami. BER definuje dva základné typy položiek (tagov): aplikačné a kontextové. Aplikačné tagy sú preddefinované:

Kontextové tagy sú závislé na kontexte (na mieste v správe). Bez znalosti kontextu (popisu správy, ktorá sa parsuje) je možné zistiť, že na konkrétnom mieste sa nachádza kontextový tag č. 5 s dĺžkou 4 bajty, ale je potrebná dodatočná informácia, či je to Unsigned, Signed, Real, Bitstring alebo iný typ hodnoty.
Okrem jednoduchých aplikačných a kontextových tagov môžu byť vlastnosti aj komplexné:

Príklad - výpis z trace súboru KOM procesu so zapnutým debugom:

  === ASN Body beg ===
  objectIdentifier (tag 0) OBJID 0 analog-input,10
  listOfResults (tag 1) SEQUENCE {
    propertyIdentifier (tag 2) ENUM 85 present-value
    propertyValue (tag 4) SEQUENCE {
     ENUM 1
    }
  }
  === ASN Body end ===
 


Interpretácia:
ide o sekvenciu (Sequence) dvoch tagov: tag objectIdentifier je kontextový s číslom 0, typu Object Identifier. Jeho hodnota je Object type=0 (analógový vstup), Instance=10. Tag listOfResults má kontextový tag 1 a je to sekvencia (Sequence of) dvoch tagov. Prvý tag je propertyIdentifier, je to kontextový tag č. 2 typu Enum s hodnotou 85, ktorá zodpovedá vlastnosti 'present-value'. Druhý tag je kontextový s číslom 4 a je to sekvencia obsahujúca jeden tag typu Enumerated Value s hodnotu 1 (je to aplikačný a nie kontextový tag).
Na parsovanie tejto správy musí poznať KOM proces ASN.1 definíciu správy, pretože bez nej by zistil, že sa v správe nachádza kontextový tag 2 (s hodnotou o dĺžke 1 bajt), ale nevedel by, že ide o Enumerated Value a teda nedokázal by bajt interpretovať (mohlo by ísť o Enumerated Value, Unsigned alebo Signed číslo), nevedel by, že tento kontextový tag má názov propertyIdentifier a hodnota 85 zodpovedá vlastnosti 'present-value'.
Vlastnosti (properties) objektov sú v konfigurácii D2000 mapované na merané body. Kvôli existencii kontextových tagov je na meranom bode možné špecifikovať Application tag, ktorý hovorí, ako treba interpretovať daný kontextový tag. Aby bolo možné získať hodnoty z implementátorom definovanej sekvencie, obsahuje meraný bod položku Complex address, ktorá udáva 'cestu' v parsovanom 'strome'.

Konfigurácia komunikačnej linky



Parametre protokolu linky

Kľúčové slovoPlný názovPopisJednotkaNáhradná hodnota
DBGI
Debug InputRozšírené debug informácie o vstupných dátach. Význam jednotlivých bitov:
  • 1. bit - debugovanie parsovania ASN správy
  • 2. bit - debugovanie názvov meraných bodov, ktorým prišla nová hodnota
  • ostatné bity - zatiaľ nepoužité
-0
DTQ
Debug Timeout QueueRozšírené debug informácie o správach v časovej fronte.-False
DI
Device InstanceNenulová hodnota spôsobí, že KOM proces odpovedá na požiadavku Who-Is správou I-Am, v ktorej uvádza zadané Device Instance. Nulová hodnota spôsobí, že Who-Is požiadavky budú ignorované.-0
RB
Receive Buffer(iba pre TCP/IP-UDP linku) Veľkosť prijímacieho buffra nastavovaná na UDP sockete. Hodnota 0 znamená, že sa veľkosť buffra nemení. Štandardná veľkosť na Windows XP je 8192 bajtov, pri väčšom počte staníc, resp. intenzívnejšej komunikácii je vhodné buffer zväčšiť.bytes0
RO
Receive OnlyAk je hodnota True, žiadnej stanici na linke sa neposielajú žiadne správy. Parameter je použiteľný napr. pri odposluchu komunikácie LonTalk: Na linke sa nakonfiguruje adresa zhodná s adresou existujúceho LonTalk zariadenia a nakonfiguruje sa stanica s adresou zariadenia, ktorého komunikáciu potrebujeme odpočúvať. V logovacom súbore linky sa bude nachádzať zaznamenaná komunikácia medzi zariadeniami. RO=True zabezpečí, že KOM proces neovplyvní komunikáciu vlastnými príkazmi a odpoveďami.-False
SC
Send Count(iba pre LonWorks linku) počet opakovania jedného paketu - prednastavená hodnota je 1, ale v určitých situáciách pri použití iLON(tm)10 Ethernet Adapter-a prvá správa akoby neprešla a komunikácia začala korektne fungovať, keď sa nastavil SC=2.
Poznámka: neskôr bolo zistené, že na vine bolo neukončenie Free topology zbernice terminátorom, ale parameter bol už implementovaný..
-1
SD
Send Delay(iba pre LonWorks linku) doplnok parametra SC, ktorý udáva oneskorenie (v ms) po každom poslaní paketu.ms0
VI
Vendor IDParameter Vendor ID správy I-Am (viď parameter Device Instance).-1


Parametre protokolu linky špecifické pre BACnet MS/TP

Kľúčové slovoPlný názovPopisJednotkaNáhradná hodnota
BR
MS/TP baud rateRýchlosť linky. Tento parameter slúži na prepočet niektorých timeoutov, ktoré sú v parametroch protokolu linky zadávané kompatibilne s normou v bitových časoch, tj. v násobkoch doby, ktorú si pri konkrétnej nastavenej prenosovej rýchlosti vyžiada prenos 1 bitu.bits/sec9600
MIF
MS/TP Nmax_info_framesMaximálne množstvo informačných rámcov, ktoré môže KOM proces vyslať pred tým, ako musí odovzdať token. Norma nešpecifikuje konkrétnu hodnotu, iba hovorí, že pokiaľ táto hodnota v zariadení nie je konfigurovateľná, musí byť 1. Čím väčšia hodnota je nastavená, tým menšie množstvo času ostane pre ostatných Mastrov, ale na druhej strane sa zmenšuje množstvo rámcov bez informačného obsahu.-5
MO
MS/TP Nmin_octetsMinimálne množstvo dát (bajtov) prijatých na linke, ktoré musí prijať KOM pred vyhlásením linky za "aktívnu".-4
MY
MS/TP my addressAdresa KOM procesu na linke RS-485. Platná hodnota je z intervalu 0 - 127. Adresa sa musí líšiť od adries ostatných zariadení na linke (ich adresy budú uvedené v konfiguráciách staníc).-1
TFA
Tframe_abortMinimálny čas (zadávaný v dĺžke vysielania bitov, t.j. závislý od parametra MS/TP baud rate), po ktorého vypršaní, bez prijatia ďalšieho znaku počas prijímania rámca, sa celý rámec zahodí. Podľa normy môžu implementácie používať aj väčšie hodnoty, ktoré neprekročia v absolútnom čase hodnotu 100 ms.bits60
TNT
Tno_tokenČas (zadávaný v ms) po ktorého vypršaní bez prijatia dát bude vyhlásená strata tokenu.ms500
TR
Treply_timeoutMinimálny čas (zadávaný v ms), ktorý musí KOM čakať, kým stanica začne odpovedať na požiadavku.ms255
TS
TslotČas (zadávaný v ms), počas ktorého môže stanica vygenerovať token.ms10
TU
Tusage_timeoutMinimálny čas (zadávaný ms), ktorý musí KOM čakať, kým partner začne používať token alebo odpovie na Poll for master rámec. Štandardná hodnota je 20 ms, podľa normy môžu implementácie používať aj väčšie hodnoty, ktoré neprekročia 100 ms.ms20

Konfigurácia komunikačnej stanice


Komunikačná stanica zodpovedá zariadeniu na BACnet sieti, s ktorým KOM proces komunikuje.









Príklad konfigurácie stanice na linke TCP/IP-UDP:

Príklad konfigurácie stanice na linke LonWorks:


Parametre protokolu stanice

Kľúčové slovoPlný názovPopisJednotkaNáhradná hodnota
RAS
Read After SubscribeParameter ovplyvňuje merané body s Request type = SubscribeCOV alebo SubscribeCOVProperty. Nastavenie hodnoty na True spôsobí, že po výzve SubscribeCOV resp. SubscribeCOVProperty pošle KOM proces následne aj požiadavku na čítanie (ReadProperty-Request).
Pozn: Štandardne parameter netreba nastavovať, pretože ako odpoveď na SubscribeCOV resp. SubscribeCOVProperty väčšina zariadení pošle okrem potvrdenia aj aktuálnu hodnotu. Parameter bol implementovaný kvôli komunikácii so Saphire Communication Controller rev.077-0210, ktorý poslal iba potvrdenie, ale nie aktuálnu hodnotu.
-False
RSD
Receive-send DelayOneskorenie medzi prijatím odpovede stanice a poslaním ďalšieho paketu.ms0
SR
Segment-ResponseBajt obsahujúci Max Segs a Max Resp parametre (viď špecifikáciu protokolu BACnet). Povolené sú iba niektoré hodnoty z intervalu 0-127, ktoré špecifikuje norma BACnet. Hodnotu 128 interpretuje KOM proces ako default:
  • LonWorks linka: hodnota sa nastaví na 0x70 (akceptovaných je viac ako 64 segmentov, max. dĺžka správy 50 bajtov)
  • TCP/IP-UDP linka: hodnota sa nastaví na 0x75 (akceptovaných je viac ako 64 segmentov, max. dĺžka správy 1476 bajtov)
  • Serial a SerialOverUDP Device Redundant linka: hodnota sa nastaví na 0x73 (akceptovaných je viac ako 64 segmentov, max. dĺžka správy 480 bajtov)
-128
TSU
Time-Synchronization UTCParameter má význam, iba ak je povolená synchronizácia v konfigurácii stanice na záložke "Časové parametre".
Ak je hodnota parametra True (default), časová synchronizácia je vykonávaná pomocou správy UTCTimeSynchronization-Request (synchronizácia v UTC čase). Ak je hodnota parametra False, časová synchronizácia je vykonávaná pomocou správy TimeSynchronization-Request (synchronizácia v lokálnom čase).
Poznámky:
  • Odporúčame synchronizáciu v UTC čase, pokiaľ ju zariadenie podporuje - je tak možné vyhnúť sa problémom s prechodom časov.
  • Požiadavky na časovú synchronizáciu sú nepotvrdzované správy - t.j. od zariadenia nepríde odpoveď ani v prípade, ak podporuje časovú synchronizáciu, ani keď ju nepodporuje.
  • Časová synchronizácia bola otestovaná na zariadení Siemens PXC36-E.D (HW=V3.02). Toto zariadenie podporuje synchronizáciu cez UTC aj lokálny čas. Je možné vyčítať aktuálny čas a dátum ako property local-date(56) a local-time(57) objektu typu Device(8).
    Z tohto objektu je možné vyčítať aj property utc-offset(119) udávajúci offset lokálneho času od UTC (v minútach, t.j. -60 je stredoeurópsky pásmový čas) ako aj property daylight-savings-status(24) udávajúci, či pracuje zariadenie na letnom čase (v septembri 2012 bola na testovanom zariadení hodnota True).
    Po časovej synchronizácii sa hodnoty local-date(56) a local-time(57) príslušne zmenili.
-True

Konfigurácia meraných bodov


Možné typy hodnôt bodov: Ai,Ci,Di,TiA,TiR,TxtI,Ao,Co,Dout,ToA,ToR,TxtO.

Meraný bod zodpovedá vlastnosti objektu (object property).



Prehľadávanie adresného priestoru

Po stlačení tlačidla "Browse" v záložke Adresa meraného bodu sa zobrazí dialóg Bacnet Item Browser. Dialógové okno umožňuje prehliadanie adresného priestoru zariadenia a vkladanie jeho prvkov do adresného dialógu meraného bodu.

Prehľadávací dialóg umožňuje filtrovanie prvkov podľa 4 základných kritérií:

Poznámka: Typ, meno a popis objektu nie je potrebné zadať celé. Postačuje nasledujúci zápis "*FILTROVANÝ VÝRAZ*", kde hviezdičky reprezentujú ľubovoľný text pred začiatkom a koncom výrazu.

Poznámka: Pomocou Ctrl+C je možné skopírovať obsah dialógu Bacnet Item Browser do clipboardu. Pokiaľ je vyznačený konkrétny riadok, skopíruje sa iba ten.

Poznámka: Vo verziách z 20.12.2018 a novších bolo implementované recyklovanie prehliadacieho dialógu. Pokiaľ je dialóg zavretý tlačidlom Cancel alebo po výbere objektu, v skutočnosti je iba skrytý a je k dispozícii pre browsovanie iného meraného bodu v rámci tej istej stanice, takže sa zachováí stromová štruktúra prehliadaných objektov. Kliknutie na krížik vpravo hore spôsobí skutočné zavretie dialógu.

Prehliadanie adresného priestoru

Zápis ľubovoľnej ASN sekvencie
Pomocou nakonfigurovaného meraného bodu typu textový výstup (TxtO) s nenastaveným aplikačným tagom je možné zapísať ľubovoľnú ASN sekvenciu. Pravidlá zápisu sú nasledovné:

Poznámka 1: Ak je pri čítaní meraného bodu z komunikácie výsledkom ASN sekvencia a meraný bod je typu Txt, táto ASN sekvencia je zapísaná (podľa hore uvedených pravidiel) do meraného bodu, pričom platí:

Poznámka 2: Zápis prázdnej sekvencie je možný reťazcom " ", reťazec s dĺžkou 0 (t.j. "") je pri zápise ignorovaný.

Príklady konfigurácií meraných bodov (zariadenie Siemens Desigo PXC64-U):
Analógový vstup:

Binárny vstup:

Binárna hodnota:

Poznámka: Ak sa nenastaví správny Application tag (pre binárnu hodnotu je to Enum), stanica Desigo bude pri pokuse o zápis vracať chybu 'invalid-data-type':

  error-class ENUM 2 property
  error-code ENUM 9 invalid-data-type	

Pre zariadenie Siemens Desigo PXC64-U sú pri zápise potrebné nasledovné nastavenia Application tag:

Poznámka k vstupno-výstupným meraným bodom: je možné nakonfigurovať meraný bod, ktorý bude zároveň vstupný aj výstupný:
Meraný bod typu Ao - Analóg výstup:

Pri zápise hodnoty sa použije správa WriteProperty-Request. Keďže je zaškrtnuté Subscribe/read, po zápise sa spätne číta zapísaná hodnota. Keby bol meraný bod nakonfigurovaný s Request type: WriteProperty, jeho správanie by sa líšilo iba absenciou periodických čítaní hodnôt (pri štarte KOM procesu a počas jeho behu, pričom perióda je nastaviteľná na stanici na záložke Časové parametre.

Poznámka k zariadeniam Siemens Desigo: merané body sú v riadiacom systéme Desigo reprezentované textovým názvom. Inštancia meraného bodu sa dá zistiť zo súboru DOTS00.DAT konfigurácie aplikácie - nachádza sa 24 bajtov pred začiatkom názvu.

Scheduler v zariadeniach Siemens Desigo


D2000 podporuje čítanie a zápis schedulerov (časových plánov). Scheduler má implementované BACnet atribúty weekly-schedule(123) a exception-schedule(38).
Weekly-schedule je pole 7 položiek (jedna položka pre každý deň týždňa). Každá položka je postupnosť dvojíc čas-hodnota, ktoré určujú zmeny hodnoty schedulera v danom čase. Pri čítaní aj zápise je možné nakonfigurovať aj Array index, a pristupovať tak k položkám poľa weekly-schedule(123). Index poľa je 1-7 pre jednotlivé dni (1=pondelok), index 0 obsahuje rozmer poľa (hodnota 7 pre atribút weekly-schedule(123)), hodnota 0 až N pre exception-schedule(38).
Exception-schedule sa používa, keď je pre špeciálne dni (sviatky, prázdniny) potrebné nakonfigurovať iný režim ako pre bežný týždeň. Exception-schedule je postupnosť 0 až N položiek, pričom jedna položka vždy obsahuje dátum (alebo rozsah dátumov), niekoľko dvojíc čas - hodnota u weekly-schedule a prioritu (najvyššia 1, najnižšia 16). Priorita udáva, ktorá z položiek sa uplatní, ak sa v nejakom čase prekrývajú.


Čítanie schedulera (atribút weekly-schedule)

Do textovej hodnoty sa načítajú časy a hodnoty oddelené bodkočiarkou (viď Poznámka).
Pri zápise hodnoty schedulera je potrebné si uvedomiť, že hodnota môže byť poslaná s rôznymi aplikačnými tagmi (Unsigned, Signed), pričom zariadenie očakáva konkrétny tag (najjednoduchšie sa dá zistiť načítaním hodnoty pri zapnutom debugu na linke). Aplikačný tag hodnoty je konfiguračne určený položkou Application tag v konfigurácii. Platné hodnoty Application tag sú Boolean, Unsigned, Signed, Real a Double. V prípade, že je nastavený iný typ, sa automaticky posiela Unsigned hodnota. Typ hodnoty je možné dynamicky zmeniť - ak je prvý znak zapisovanej textovej hodnoty B,U,S,R alebo D, je chápaný ako (B)oolean, (U)nsigned, (S)igned, (R)eal alebo (D)ouble.


Zápis schedulera (atribút weekly-schedule)

Poznámka: Okrem špecializovaného requestu ReadWriteScheduler je možné zapísať weekly-schedule aj cez zápis ASN sekvencie, napr. hodnote "0:0:0; 1; 2:30:40.5; 2; 5:00:00;1" z predchádzajúceho príkladu zodpovedá sekvencia "{ T0:0:0 u1; T2:30:40.5 u2; T5:0:0 u1 }" pričom konfigurácia meraného bodu sa líši iba v Request type=ReadProperty. Navyše je možné zapísať časový plán na celý týždeň, ak sa nenastaví Array index a hodnota obsahuje 7 sekvencií na jednotlivé dni, napr. "{ T0:10:0 u3 T1:3:0 u1; } {T2:0:0.0 u2 T5:30:10.0; u3; } { T6:0:0.0 u2 T7:0:0.0 u3} { T20:0:0.33; u1} { T21:0:0.0; u1} { T22:0:0.0; u2} { T0:0:0.0; u3; T1:2:0.0; u1; T2:0:0.0; u2; T5:30:10.0; u3}".


Zápis schedulera (atribút exception-schedule)

Zápis exception-schedule je podporený cez zápis ASN sekvencie. Majme meraný bod s nasledovnou konfiguráciou:

Ak pri zápise použijem reťazec "0{ 0D2.10.2005 } 2{ T1:0:0; u1; T12:0:0; u3 } 3u10", tak pomocou neho zapíšem časový plán na 2.10.2005, pričom od 1:0:0 bude mať scheduler hodnotu 1, od 12:00:00 hodnotu 3. Priorita exception-schedule je 10. Pri spätnom načítaní hodnoty (je nakonfigurované Subscribe/Read) so zapnutým debugom na linke je vidieť nasledovný výpis:

 === ASN Body beg ===
 objectIdentifier (tag 0) OBJID 17 schedule,6
 propertyIdentifier (tag 1) ENUM 38 exception-schedule
 propertyValue (tag 3) SEQUENCE 3 {
  readResult (tag 0) SEQUENCE 0 {
   date (tag 0) DATE 2.10.2005 NoDay
  }
  listOfTimeValues (tag 2) SEQUENCE 2 {
   time TIME 1:0:0.0
   value UNSIGNED 1
   time TIME 12:0:0.0
   value UNSIGNED 3
  }
  eventPriority (tag 3) UNSIGNED 10
 }
 === ASN Body end ===

Ak chceme nastaviť exception-schedule pre rozsah dátumov, zapíšeme hodnotu "0{ 1{ D5.10.2005; D8.10.2005}} 2{ T1:0:0; u1; T7:0:0; u3; } 3u15" Táto hodnota pre rozmedzie dátumov 5.10.2005-8.10.2005 nastavuje scheduler od času 1:00:00 na hodnotu 1 a od času 7:00:00 na hodnotu 3. Priorita exception-schedule je 15. Pri spätnom načítaní hodnoty (je nakonfigurované Subscribe/Read) so zapnutým debugom na linke je vidieť nasledovný výpis:

 
 === ASN Body beg ===
 objectIdentifier (tag 0) OBJID 17 schedule,6
 propertyIdentifier (tag 1) ENUM 38 exception-schedule
 propertyValue (tag 3) SEQUENCE 3 {
  readResult (tag 0) SEQUENCE 0 {
   dateRange (tag 1) SEQUENCE 1 {
    startDate DATE 5.10.2005 NoDay
    endDate DATE 8.10.2005 NoDay
   }
  }
  listOfTimeValues (tag 2) SEQUENCE 2 {
   time TIME 1:0:0.0
   value UNSIGNED 1
   time TIME 7:0:0.0
   value UNSIGNED 3
  }
  eventPriority (tag 3) UNSIGNED 15
 }
 === ASN Body end ===

Je možné zapísať do exception-schedule niekoľko položiek hore uvedených typov zapísaním reťazca, ktorý obsahuje pospájané sekvencie, napr. "0{ 0D2.10.2005 } 2{ T1:0:0; u1; T12:0:0; u3 } 3u10 0{ 0D3.10.2005 } 2{ T0:0:0; u2; T5:0:0; u3; T14:0:0; u1 } 3u11 0{ 1{ D5.10.2005; D8.10.2005}} 2{ T1:0:0; u1; T7:0:0; u3; } 3u15 "

Scheduler v zariadeniach Delta Controls


Podobne ako pre scheduler v zariadeniach Siemens Desigo bolo otestované čítanie a zápis do schedulera (časového plánu) v zariadení Delta Controls DAC-1146. Otestovaný bol iba BACnet atribút weekly-schedule(123).
Weekly-schedule je pole 7 položiek (jedna položka pre každý deň týždňa). Každá položka je postupnosť dvojíc čas-hodnota, ktoré určujú zmeny hodnoty schedulera v danom čase. Na rozdiel od zariadení Siemens Desigo sú časové plány implementované s Boolean hodnotami True/False, ktoré sú prezentované navonok ako Enum hodnoty 0/1. Príklad časového plánu Delta Controls:
"{ T0:10:0 E0 T1:3:0 E1; } {T2:0:0.0 E1 T5:30:10.0; E0; } { T6:0:0.0 E0 T7:0:0.0 E1} { T20:0:0.33; E0} { T21:0:0.0; E1} { T22:0:0.0; E0} 0{ T0:0:0.0; E0; T1:2:0.0; E1; }"
Prejde aj zápis a následné čítanie hodnoty E2, akurát nevieme, ako to DAC-1146 následne interpretuje :-)

Informácie o eventoch


Pomocou requestu GetEventInformation-Request je možné vyžiadať si od zariadenia zoznam objektov, ktoré sú v stave Offnormal alebo Fault alebo ktorých prechod do Offnormal, Fault alebo Normal stavu nebol kvitovaný.
Príklad konfigurácie meraného bodu:

Odpoveďou na GetEventInformation-Request je správa GetEventInformation-Ack, ktorá obsahuje zoznam objektov a pre každý objekt zoznam vlastností:

Na konci zoznamu sa nachádza atribút moreEvents, ktorý je nenulový, ak zoznam eventov nie je kompletný (prekročenie dĺžky maximálnej správy a podobne). Vtedy je nutné prekonfigurovať meraný bod a nastaviť Object type a Instance na posledný objekt v zozname, čo spôsobí vygenerovanie novej správy GetEventInformation-Ack, ktorá bude ďalšiu časť zoznamu eventov.

Príklad odpovede GetEventInformation-Ack:

 === ASN Body beg ===
 listOfEventSummaries (tag 0) SEQUENCE 0 {
  objectIdentifier (tag 0) OBJID 0 analog-input,1
  event-state (tag 1) ENUM 3 high-limit
  acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
  eventTimeStamps (tag 3) SEQUENCE 3 {
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:28:49.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:25:59.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:25:56.0
   }
  }
  notifyType (tag 4) ENUM 0 alarm
  eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
  eventPriorities (tag 6) SEQUENCE 6 {
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 7
  }
  objectIdentifier (tag 0) OBJID 214,1
  event-state (tag 1) ENUM 2 offnormal
  acknowledgedTransitions (tag 2) BITSTRING 0,1,0 to-offnormal(0),to-fault(1),to-normal(2)
  eventTimeStamps (tag 3) SEQUENCE 3 {
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 18.11.2005 Fri
    time TIME 12:52:11.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 18.11.2005 Fri
    time TIME 11:16:23.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 12:23:58.0
   }
  }
  notifyType (tag 4) ENUM 0 alarm
  eventEnable (tag 5) BITSTRING 0,0,0 to-offnormal(0),to-fault(1),to-normal(2)
  eventPriorities (tag 6) SEQUENCE 6 {
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 7
  }
 }
 moreEvents (tag 1) BOOLEAN FALSE
 === ASN Body end ===    

Informácie o alarmoch


Možné je kvitovať eventy a alarmy, ktorých zoznam bol načítaný pomocou requestu GetEventInformation. Kvitovací request má podľa BACnet protokolu nasledovný formát (zápis v ASN.1 syntaxi):

  *********************** Confirmed Alarm and Event Services ******************
  AcknowledgeAlarm-Request ::= SEQUENCE {
    acknowledgingProcessIdentifier [0] Unsigned32,
    eventObjectIdentifier [1] BACnetObjectIdentifier,
    eventStateAcknowledged [2] BACnetEventState,
    timeStamp [3] BACnetTimeStamp,
    acknowledgmentSource [4] CharacterString,
    timeOfAcknowledgment [5] BACnetTimeStamp
  }

Podrobnejší popis jednotlivých parametrov viď literatúra.
Kvitovanie prebieha zápisom hore uvedenej sekvencie do textového výstupného meraného bodu podľa štandardu zápisu ľubovoľnej ASN sekvencie.

Príklad: Pomocou requestu GetEventInformation načítam nasledovný zoznam alarmov a eventov:

   === ASN Body beg ===
   listOfEventSummaries (tag 0) SEQUENCE 0 {
    objectIdentifier (tag 0) OBJID 0 analog-input,1
    event-state (tag 1) ENUM 4 low-limit
    acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:4:37.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
    objectIdentifier (tag 0) OBJID 0 analog-input,2
    event-state (tag 1) ENUM 3 high-limit
    acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:41:59.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:20.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:21.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
    objectIdentifier (tag 0) OBJID 214,1
    event-state (tag 1) ENUM 2 offnormal
    acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:20.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:21.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 0,0,0 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
   }
   moreEvents (tag 1) BOOLEAN FALSE
   === ASN Body end === 

Prvý v zozname je objekt
objectIdentifier (tag 0) OBJID 0 analog-input,1
ktorý je v stave low-limit
event-state (tag 1) ENUM 4 low-limit
a má nekvitovaný prechod do stavu offnormal (t.j. v terminológii D2000 ide o aktívny alarm low-limit vyžadujúci kvitovanie):
acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
Tento prechod nastal v čase
dateTime (tag 2) SEQUENCE 2 {
date DATE 25.11.2005 Fri
time TIME 11:54:23.0
}

Alarm budeme kvitovať zápisom textovej hodnoty
0u1; 1o0:1 ; 2E2; 3{ 2{ D25.11.2005 T11:54:23} } 4C'D2000' 5{ 2{ D25.11.2005 T11:55:23 }}
pričom jednotlivé položky sú (viď definíciu AcknowledgeAlarm-Request vyššie):

Po kvitovaní alarmu a následnom načítaní zoznamu alarmov a eventov pomocou requestu GetEventInformation bude vidieť, že alarm bol kvitovaný, pretože sa zmení:
acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)

na

acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)

Pokiaľ by bol objekt v stave normal, tak sa v zozname alarmov neobjaví vôbec, ale v tomto príklade bol v stave low-limit, takže ide o aktívny kvitovaný alarm.

Na načítanie zoznamu alarmov, ich výpis do browsera a kvitovanie alarmu je potrebné napísať obslužné skripty na parsovanie textovej hodnoty requestu GetEventInformation a skladanie textovej hodnoty pre AcknowledgeAlarm.

Pozn: v konkrétnom prípade pri potvrdzovaní alarmu vyžadovalo zariadenie DESIGO PXC 100E.D, aby v rámci dátumu bol zadaný aj deň v týždni (napr. D8.6.2020.1  pre pondelok). Hodnota 255 (unspecified) dňa v týždni, ktorá sa posiela, keď deň nie je zadaný, zariadeniu pri potvrdzovaní alarmu nevyhovovala.

Poznámka k cachovaniu adries


Ak má stanica aspoň jeden meraný bod s Address Type = Name, pri inicializácii takýchto meraných bodov sa zisťuje číselná adresa z ObjectName pomocou správy Who-Has-Request. Po získaní adresy sa uloží štvorica (ObjectName; Object Type; Instance; DeviceInstance) do cache súboru a je k dispozícii pri ďalšom spustení KOM procesu.
Cache súbor existuje pre každú stanicu jeden. Nachádza sa v adresári aplikácie v podadresári Cache a jeho názov je Cache_nazov_stanice.txt, napr. Cache_B.StationX1.txt.
Pri uložení stanice BACnet dôjde k opätovnému načítaniu údajov zo súboru. Pokiaľ súbor nebol nájdený, dôjde k vygenerovaniu Who-Has správ na všetky merané body tejto stanice, ktoré majú Address Type = Name.
Toto chovanie je možné využiť po zmene konfigurácie zariadenia, s ktorým KOM proces komunikuje (ak pri zmene konfigurácie došlo k zmene adries objektov). Stačí vymazať cache súbor tejto stanice a uložiť stanicu - po niekoľkých sekundách cache súbor znovu vznikne a naplní sa získanými údajmi.

Poznámka: Interakcia cache a meraných bodov s Request type = WhoHas.

Poznámka k zariadeniam Delta Controls


Testovacia konfigurácia obsahovala zariadenie DSC-1212E pripojené k lokálnej sieti Ethernet a zariadenie DAC-633 pripojené k DSC-1212E cez MS/TP rozhranie (RS-485). D2000 KOM komunikoval priamo s DSC-1212E a cez DSC-1212E aj s DAC-633 (DSC-1212E plnilo funkciu BACnet routra).
Pri testovaní komunikácie bol použitý softvér ORCAview 3.30 Build 1481, z ktorého boli vyčítané nasledovné konfiguračné informácie:



Obidve zariadenia podporujú pollingový aj zmenový spôsob čítania dát (ReadProperty aj SubscribeCOV).
Parametre Object type a Instance v konfigurácii meraného bodu sú zistené z ORCAview z atribútov Object a Description (napr. objekt 3200.AI12 je Analog Input, Instance 12; objekt 3202.PG3 je Program, Instance 3). Parameter Address type je Object type+Instance a ak nie je uvedené inak, Request type je SubscribeCOV.

Nakomunikované typy bodov:


Poznámka k zariadeniam E-DDC3.1


Komunikáciu s testovacou zostavou sa podarilo oživiť v nasledujúcej konfigurácii:


Bolo vyskúšané ReadProperty, SubscribeCOV, WriteProperty (na objekty typu Binary Output, Binary Value, Analog Value).
Nakomunikované typy bodov (testovacia konfigurácia iné typy neobsahovala):


S pôvodným firmvérom zariadenie (2.01.05) nereagovalo na Who-Is, po upgrade firmvéru na verziu 2.01.16 sa toto chovanie opravilo a korektne funguje aj WriteProperty.

Poznámka k zariadeniam Siemens Desigo


Podľa dokumentu "DESIGO INSIGHT: Installation, setup and communication - Engineering guide" odporúčané adresné nastavenia pre komunikácu cez LonWorks sú:

Poznámka k zariadeniam Klimasoft MBG-MSTP


Testovacia konfigurácia obsahovala Moxa NPort 5150 (prevodník z UDP na RS485) pripojený k prevodníku MBG-MSTP, ktorý komunikoval s meračom tepla Siemens UH50-A21R-SK06-G. Vyčítavané boli analógové vstupy, prevodník MBG-MSTP podporoval iba ReadProperty.
Komunikáciu s testovacou zostavou sa podarilo oživiť v nasledujúcej konfigurácii:

Poznámka k iLON 10 Ethernet adaptéru


Pri použití iLON 10 Ethernet adaptéra na komunikáciu si treba uvedomiť, že komunikačný procesor tohto zariadenia (Neuron 3120) má prednastavené pomerne krátke buffre (network buffer je 66 bajtov), preto nebude prijímať dlhšie pakety. Prejaví sa to vo webovom rozhraní iLON 10, kde bude v záložke Status narastať číslo Missed Messages pri pokuse čítať hodnotu (napr. vždy po uložení meraného bodu, pokiaľ má zaškrtnuté Subscribe/read). Pri testovaní sa tento problém prejavil, keď časový plán schedulera obsahoval viac ako 4 dvojice čas, hodnota. Pri štyroch hodnotách bola celková dĺžka prijatej LON správy 63 bajtov, po pridaní ďalšej dvojice cez terminál PXM20 sa už časový plán načítať nepodarilo.

Pozor! Pomocou utility Nodeutil je možné zväčšiť veľkosť prijímaného paketu zväčšením network buffra a aplikačného buffra, ale rovnako dobre je možné nastavením nevhodných hodnôt zariadenie iLON 10 zničiť (Neuron 3120 prestal komunikovať s užívateľským procesorom).
Ak sa rozhodnete prestaviť veľkosť buffrov, postačí zmeniť sieťové a aplikačné buffre z 66 bajtov na 88 bajtov (a zredukovať počty buffrov), pretože KOM proces v svojich paketoch oznamuje, že je schopný prijať 50-bajtovú ASDU (+ 3 bajty hlavička BACnet + 16 bajtov hlavička LON)
Adaptér PCLTA-10 ISA (postavený na komunikačnom čipe Neuron 3150) mal dostatočne dlhé buffre (255 bajtov).
Po zakúpení nového zariadenia iLON 10 bola úspešná konfigurácia vykonaná s nasledovnými parametrami:


Poznámka k implementácii BACnet MS/TP


Implementácia BACnet MS/TP v žiadnom prípade nie je úplná. Bola otestovaná iba na jednoduchej konfigurácii (KOM oproti BACnet MS/TP MicroGateway firmy York). Komunikácia fungovala pri použití linky Serial (použitý RS485/RS232 prevodník) ako aj linky SerialOverUDP Device Redundant (použitá Moxa NPort rady 5xxx).
MicroGateway firmy York implementuje komunikáciu typu MS/TP Master (t.j. zisťuje prítomnosť ďalších staníc typu Master vysielaním rámca Poll for master). KOM sa v súčasnosti spolieha na partnerskú stanicu a nemá implementované vysielanie tohto rámca. Rovnako zatiaľ dostatočne nerieši ani výpadok stanice, ktorej odovzdáva token. Súčasná implementácia je vhodná iba na komunikáciu s jedinou stanicou typu Master, môže byť vhodná na komunikáciu s jednou alebo viacerými stanicami typu Slave (netestované). Takisto časové pomery môžu byť v zaťažených systémoch problém - KOM nemusí stihnúť odpovedať vo vyžadovanom čase na rámce Poll for master alebo Token, čím môžu vzniknúť napr. kolízie na linke. Časové pomery sa navyše zhoršia zapnutím logovacích výpisov na linke.
Pokiaľ bude záujem rozšíriť implementáciu BACnet MS/TP, bude potrebná explicitná požiadavka a zabezpečenie testovacej konfigurácie.

Poznámka k podpore BBMD (BACnet Broadcast Management Devices)


Do protokolu BACnet bola dorobená (a je k dispozícii vo verziách zverejnených po 17.01.2012) nasledovná vlastnosť týkajúca sa prevodu textových mien na číselné adresy meraných bodov (Siemens zariadenia Desigo) na linke TCP/IP-UDP: ak KOM proces vyšle požiadavku Who-Has a odpoveď I-Have príde z inej IP adresy, hľadá sa (v rámci linky) stanica, ktorá vyslala Who-Has request s textovým názvom, ktorý je uvedený v odpovedi. Ak sa takáto stanica nájde, odpoveď sa spáruje s jej výzvou.
Táto vlastnosť je užitočná, pokiaľ sa komunikuje s viacerými Siemens routrami (za ktorými sú napr. BACnet/LON zariadenia), z ktorých jeden je nakonfigurovaný ako BBMD (Bacnet Broadcast Management Device) a ostatné nie.
Modelová situácia:
KOM proces komunikuje s dvoma BACnet routrami Desigo PXG80-N (Rtr1 a Rtr2). Za každým routrom je LON sieť, pre zjednodušenie s jedinou stanicou Desigo PXM20 (Des1 resp. Des2). Router Rtr2 je nakonfigurovaný tak, aby BACnet broadcasty z LON siete preposielal na Rtr1.

Majme jednu komunikačnú linku typu TCP/IP-UDP na nej dve stanice typu BACnet/IP reprezentujúce Des1 a Des2

KOM proces pošle kvôli prevodu textového názvu nakonfigurovaného v adrese M.Des2_test Who-Has požiadavku na zariadenie Des2. Pri posielaní sa použije IP adresa Rtr2 10.0.0.2.
Rtr2 prepošle požiadavku do LON siete na Des2 (podľa parametrov Destination network=12 a Destination address=2.2 uvedených v konfigurácii stanice B.Des2). Z BACnet/LON zariadenia Des2 príde broadcast odpoveď I-Have. Keďže BACnet router Rtr2 je bez podpory BBMD, prepošle odpoveď (za predpokladu, že je tak nakonfigurovaný) BACnet routru Rtr1, ktorý má podporu BBMD.
Rtr1 prepošle I-Have správu ako UDP paket KOM procesu, pretože je nakonfigurovaný parameter stanice B.Des1 Register-Foreign-Device a teda KOM proces sa registroval ako príjemca broadcast správ u Rtr1). Takto sa I-Have správa dostane do KOM procesu s inou IP adresou ako bola pôvodná výzva. Vyššie popisovaná funkcionalita spáruje takúto odpoveď s výzvou od stanice B.Des2 na základe zhody textového názvu objektu v poslanej výzve.

Z popísaného postupu zároveň vyplýva jedno konfiguračné obmedzenie - všetky popísané činnosti sa dejú v kontexte jednej linky, takže je nutné, aby na jednej linke sa nachádzali všetky stanice, ktoré sú v pôsobnosti jedného BBMD zariadenia.

Tell príkazy


PríkazSyntaxPopis
STWATCHSTWATCH MenoStaniceTell príkaz pošle na stanicu príkazy ReadProperty, ReadPropertyMultiple a Subscribe podľa konfigurácie jednotlivých meraných bodov.

Literatúra


ANSI/ASHRAE Standard 135-2001: BACnet - A Data Communication Protocol for Building Automation and Control Networks

ASN.1 Complete by Prof. John Larmouth


O protokole BACnet si môžete prečítať aj blogy:


Zmeny a úpravy


-

Revízie dokumentu


Komunikačné protokoly