...
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
...
- Resubscribe interval: Čas v sekundách, po uplynutí ktorého sa znovu posiela stanici žiadosť o posielanie zmien meraných bodov. Tento parameter sa týka meraných bodov s Request type rovným SubscribeCOV alebo SubscribeCOVProperty.
- Max APDU: Maximálna veľkosť správy (APDU=application protocol data unit), ktorú KOM proces posiela. Prednastavené hodnota je:
Menenie prednastavenej hodnoty má zmysel kvôli testovaniu a na prispôsobenie sa staniciam, ktoré sú schopné spracovať iba menšie správy. V súčasnosti zmenšenie parametra Max APDU má vplyv iba na veľkosť a množstvo správ ReadPropertyMultiple-Request. Tieto správy slúžia na periodické čítanie hodnoty meraného bodu (viď konfigurácia meraného bodu).
Poznámka: Nastavenie Max APDU nemá vplyv na veľkosť parametra max-APDU-length-accepted v APDU BACnet-Confirmed-Request-PDU, ktorým KOM proces oznamuje partnerovi, akú najväčšiu správu je schopný spracovať. Tento parameter je konfigurovaný pomocou parametra protokolu stanice Segment-Response.
- Priorita: priorita správy v BACnet protokole. Existujú 4 priority, prednastavená je Normal, vyššie sú Urgent, CriticalEquipment a LifeSafety.
- Rpt_timer & reply: (iba pre LonWorks): parametre Repeat timer a Retry protokolu LonTalk. Prednastavené hodnoty sú 1 a 1.
- Tx_timer: (iba pre LonWorks): parameter Tx_timer protokolu LonTalk. Prednastavená hodnota je 3.
- Timeout a retry: timeout v milisekundách na potvrdenie správy. Prednastavená hodnota je podľa protokolu BACnet 3000 ms. Po vypršaní timeoutu sa správa posiela opäť a to až retry-krát. Ak nie je prijaté žiadne potvrdenie, zvýši sa počítadlo chýb na stanici.
Poznámka: Pri testovaní zariadenia Siemens PXC64-U (komunikácia cez LonTalk) bolo potrebné nastaviť Retry=8, Timeout=300 (viac opakovaní s kratším timeoutom), v dôsledku toho bolo treba zvýšiť aj hodnoty COM_ERR=10, HARD_ERR=20, aby pri opakovaní posielania správy neprechádzala stanica do chybového stavu.
...
- Request type: čítanie a zápis vlastností objektov je možný niekoľkými spôsobmi:
- ReadProperty - periodické čítanie vlastnosti objektu systémom výzva-odpoveď, periódu pollingu je nastaviteľná na stanici na záložke Časové parametre. Na výzvu sa použije správa ReadProperty-Request, zariadenie ako odpoveď posiela správu ReadProperty-Ack. Periodické čítanie zaťažuje sieť a je neefektívne, preto pokiaľ zariadenie podporuje posielanie zmenových dát, odporúčame použiť SubscribeCOV alebo SubscribeCOVProperty.
Správa ReadProperty-Request je posielaná iba vtedy, ak je zaškrtnutý checkbox Subscribe/read. - ReadPropertyMultiple - podobné ako predchádzajúce, na rozdiel od ReadProperty sa v jednej výzve aj odpovedi posiela niekoľko vlastností, takže komunikácia je efektívnejšia. Na výzvu sa použije správa ReadPropertyMultiple-Request, zariadenie ako odpoveď posiela správu ReadPropertyMultiple-Ack.
Správa ReadPropertyMultiple-Request je posielaná iba vtedy, ak je zaškrtnutý checkbox Subscribe/read. - WriteProperty - zapisovanie hodnôt správou WriteProperty-Request. Je nutné špecifikovať aj parameter Application tag. Ak je zaškrtnuté Subscribe/read, po zápise sa spätne číta zapísaná hodnota správou ReadProperty-Request.
- SubscribeCOV - čítanie hodnoty objektu zmenovým spôsobom. Ak je zaškrtnutý checkbox Subscribe/read, po štarte KOM pošle správu SubscribeCOV-Request, ktorou oznámi zariadeniu, že chce byť informovaný o zmenách hodnoty objektu. Je možné špecifikovať, či zariadenie má posielať potvrdzované (správa ConfirmedCOVNotification-Request) alebo nepotvrdzované (UnconfirmedCOVNotification-Request) notifikácie. Potvrdzovaná notifikácia je správa, ktorá vyžaduje explicitné potvrdenie KOM-u správou BACnet-SimpleACK-PDU, takže zaťažuje sieť potvrdeniami, ale pravdepodobnosť, že sa notifikácia stratí, je podstatne menšia ako u nepotvrdzovanej (ak zariadenie nedostane potvrdenie, správu opakuje).
Poznámka 1: Okrem dynamickej registrácie správou SubscribeCOV-Request môžu niektoré zariadenia podporovať statickú registráciu (uloženú v konfigurácii), takže nie je potrebné sa registrovať a checkbox Subscribe/read môže byť odškrtnutý.
Poznámka 2: Registrácia môže byť posielaná v pravidelných intervaloch (napr. kvôli možnému výpadku napájania zariadenia). Interval posielania registrácie sa nastavuje na stanici ako parameter Resubscribe interval.
Poznámka 3: Správy SubscribeCOV-Request (a SubscribeCOVProperty-Request, viď nasledujúci bod) sú posielané aj po obnovení spojenia so stanicou (po výpadku alebo po prechode zo stavu StOFF do StOn). | Kotva |
|---|
| subscribecovproperty |
|---|
| subscribecovproperty |
|---|
|
SubscribeCOVProperty - podobné ako SubscribeCOV, navyše je možné špecifikovať aj Property identifier (takže je možné sledovať aj zmeny iných vlastností objektov ako iba hodnoty) a prípadne Increment - veľkosť prírastku, ktorý spôsobí poslanie zmeny (t.j. pásmo necitlivosti).
Posielaná správa je SubscribeCOVProperty-Request.
Poznámka: Testované zariadenie Siemens PXC64-U nepodporovalo parameter Increment.- WhoIs-identifikačná správa Who-Is-Request na zistenie, aký Device Object zariadenie obsahuje. Odpoveďou je správa I-Am-Request (obsahuje polia iAmDeviceIdentifier, maxAPDULengthAccepted, segmentationSupported, vendorID). Ak je meraný bod typu TxtI, všetky tieto informácie sú v textovej podobe extrahované do hodnoty meraného bodu. Keď takto identifikujem Device Object, môžem si nakonfigurovať meraný bod na načítanie vlastnosti object-list identifikovaného Device Object-u a ak zariadenie túto vlastnosť implementuje, vráti zoznam identifikátorov všetkých objektov, ktoré obsahuje. Následne je možné zisťovať vlastnosti týchto objektov (object-name, location, description, present-value ..)
Poznámka: Pre zariadenie Siemens PXC64-U je nutné čítať vlastnosť object-list s nastaveným Array index, pričom Array index=0 udáva počet prvkov poľa, prístup k jednotlivým prvkom poľa je cez Array index=1 až N. - WhoHas-identifikačná správa Who-Has-Request na zistenie mena objektu z identifikátora objektu alebo naopak. Odpoveďou je správa I-Have-Request (obsahuje polia deviceIdentifier, objectIdentifier a objectName). Správa Who-Has-Request sa posiela iba raz pri inicializácii meraného bodu (resp. po TELL príkaze SETPTADDR) a slúži na prevod medzi menami a identifikátormi objektov.
Správa Who-Has-Request bude obsahovať buď meno alebo identifikátor objektu podľa toho, či je na meranom bode nakonfigurovaný Address type ako Name alebo Object type+Instance.
Podľa toho, či je zaškrtnuté Subscribe/read, môže sa použiť informácia z cache, čo je podstatne rýchlejšie ako zisťovanie z komunikácie. | Kotva |
|---|
| readwritescheduler |
|---|
| readwritescheduler |
|---|
|
ReadWriteScheduler: na výzvu sa použije správa ReadProperty-Request, na zápis WriteProperty-Request, pričom pri zápise sa zapisuje N dvojíc čas-hodnota. Konfigurácia sa používa na čítanie a zápis objektov typu schedule, podrobnejší popis viď Scheduler v zariadeniach Siemens Desigo.| Kotva |
|---|
| geteventinformation |
|---|
| geteventinformation |
|---|
|
GetEventInformation: zistenie zoznamu objektov, ktoré sú v alarmovom alebo chybovom stave alebo potrebujú kvitovanie, podrobnejší popis viď Informácie o eventoch.| Kotva |
|---|
| acknowledgealarm |
|---|
| acknowledgealarm |
|---|
|
AcknowledgeAlarm: kvitovanie alarmov, ktorých zoznam bol načítaný requestom GetEventInformation. Podrobnejší popis viď Informácie o alarmoch. Meraný bod musí byť textový výstup (TxtO).
- Address type: Každý objekt v protokole BACnet je adresovaný cez Identifikátor objektu. Pri návrhu aplikácie v systéme Desigo sú objekty reprezentované názvami, pričom adresa objektu nie je prístupná a môže sa meniť v dôsledku zmien aplikácie. Zariadenia Delta Controls majú naopak objekty, ktorých adresy zadáva tvorca aplikácie. Z tohto dôvodu sú možné dva spôsoby zadávania adresy meraného bodu zodpovedajúce dvom Address type:
- Name: zadá sa meno objektu. Typ objektu a číslo inštancie sa zistia dynamicky z komunikácie. Kvôli nezahlcovaniu komunikačných liniek pri štarte KOM procesu sa využíva ukladanie údajov do BACnet cache.
- Object type + Instance: zadá sa typ objektu a číslo inštancie. Vhodné pre BACnet objekty s konštantnými adresami.
- Object type: typ objektu, ktorého vlastnosti chcem čítať/zapisovať. Je možné použiť preddefinované typy alebo zapísať číslo nového typu objektu, ktoré si zadefinoval výrobca zariadenia. Typ objektu je 10-bitové číslo.
- Instance: poradové číslo objektu v rámci typu objektu. Každý objekt má v rámci zariadenia unikátny Object Identifier, čo je dvojica [Object type, Instance]
- Object Name: názov objektu, keď Address type= Name, t.j. keď adresa meraného bodu sa zisťuje dynamicky z komunikácie. Object Name musí byť zadaný presne, t.j. netolerujú sa zbytočné medzery na začiatku ani na konci a aj malé a veľké písmená sa musia zhodovať s názvom objektu, ktorý je uložený v zariadení, s ktorým sa komunikuje.
- Property type: typ vlastnosti - pre Simple sa zadáva iba PropertyIdentifier, pre Complex treba zadať aj Complex address. Komplexný typ vlastnosti je potrebný pri parsovaní implementátorom definovaných rozšírení štandardných správ (Abstract Syntax & Notation). Pri posielaní správ ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, SubscribeCOVProperty-Request je Complex address ignorovaná,
- Property identifier: identifikátor vlastnosti objektu. Je možné použiť preddefinované vlastnosti alebo zapísať číslo novej vlastnosti, ktoré si zadefinoval výrobca zariadenia. Identifikátor vlastnosti je typu Enumerated Value, vlastnosti 0-511 sú rezervované pre BACnet, čísla 512-4194303 sú použiteľné pre výrobcov zariadení.
- Array index: niektoré vlastnosti môžu byť definované ako polia hodnôt, v tom prípade je možné čítať alebo zapisovať konkrétnu položku poľa.
| Kotva |
|---|
| application_tag |
|---|
| application_tag |
|---|
|
Application tag: nutné špecifikovať pri zápise hodnoty (Request type=WriteProperty) a prípadne aj pre iné typy žiadostí, pokiaľ parsovaná odpoveď obsahuje kontextové tagy, ktorých aplikačný typ nie je známy, pretože ide o implementátorom definované rozšírenie správ. Výnimkou je výstupný textový bod, ktorý sa pri nešpecifikovanom aplikačnom tagu chápe ako 'AnyTree' a slúži na zápis ľubovoľnej užívateľom zadanej ASN sekvencie.
Poznámka: Pokiaľ je zapisovaná hodnota Invalid, nezapíše sa ako definovaný Application tag, ale ako Application tag "Null".| Kotva |
|---|
| complex_address |
|---|
| complex_address |
|---|
|
Complex address: adresa tagu v 'strome' v prípade implementátorom definovaných rozšírení správ.
Príklad adresy: [1].[3].2.1
Popis:
[1] - kontextový tag č.1 (predpokladá sa, že je to sekvencia),
[3] - v rámci tejto sekvencie kontextový tag č.2 (opäť musí byť sekvencia),
2 - v rámci tejto sekvencie druhý tag v poradí (opäť sekvencia),
1 - v rámci tejto sekvencie prvý tag v poradí.
Adresa v 'strome' sa začína od úrovne propertyValue (viď príklady správ nižšie).
Najjednoduchší spôsob zobrazenia parsovanej správy je zapnutie debugu na linke a sledovanie výpisov na konzole alebo v logu linky.
Príklad 1: Majme zariadenie, ktoré obsahuje objekt typu 2 (Analog Value) s číslom inštancie 1 a predpokladajme, že zariadenie posiela ako hodnotu objektu trojicu čísel, z ktorých prvá je aktuálna hodnota, druhá minútový priemer a tretia desaťminútový priemer. Výpis parsovanej správy môže byť nasledovný:
=== ASN Body beg ===
objectIdentifier (tag 0) OBJID 2 analog-value,1
listOfResults (tag 1) SEQUENCE {
propertyIdentifier (tag 2) ENUM 85 present-value
propertyValue (tag 4) SEQUENCE {
REAL 1.40000E+00
REAL 1.10000E+00
REAL 1.30000E+00
}
}
=== ASN Body end ===
Ak máme záujem o všetky tri hodnoty, nakonfigurujem 3 merané body, (Object type=analog_value, Instance=1, Property-identifier=present-value, Property-type=complex), ktoré sa budú líšiť komplexnou adresou (pre prvý bod 1, pre druhý 2, pre tretí 3). Iba jeden meraný bod by mal mať zaškrtnutý checkbox Subscribe/read, pretože odpoveďou na jednu žiadosť je správa s troma hodnotami. Pri posielaní správ ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, SubscribeCOVProperty-Request ani WriteProperty-Request sa komplexná adresa nepoužíva.
Poznámka: Ak by bol nakonfigurovaný meraný bod s Property-type=simple, jeho hodnota by sa po parsovaní správy nastavila na prvú nájdenú hodnotu (v príklade 1.40000E+00).
Príklad 2: Zariadenie Siemens Desigo PXC64-U má meraný bod (Object type=schedule, Instance=6, zaškrtnutý Subscribe-read, Property-identifier=weekly-schedule, Property-type=complex, Array index=1, Complex address=1). Na linke je zapnutý debug. Po uložení meraného bodu KOM proces pošle požiadavku a vypíše odpoveď:
=== ASN Body beg ===
objectIdentifier (tag 0) OBJID 17 schedule,6
propertyIdentifier (tag 1) ENUM 123 weekly-schedule
propertyArrayIndex (tag 2) UNSIGNED 1
propertyValue (tag 3) SEQUENCE {
SEQUENCE {
TIME 0:0:0.0
UNSIGNED 2
TIME 4:0:0.0
UNSIGNED 3
TIME 22:0:0.0
UNSIGNED 1
}
}
=== ASN Body end ===
V propertyValue sa nachádza sekvencia 6 hodnôt (striedavo čas a kladné číslo). Ak chceme pristupovať k prvému času, treba nastaviť Complex address=1.1, ak k prvému kladnému číslu, treba nastaviť Complex address=1.2, t.j. prvý element - sekvencia - a v rámci neho druhý element v poradí (UNSIGNED 2). Ak potrebujeme pristupovať k viacerým časom a/alebo hodnotám naraz, stačí nakonfigurovať niekoľko meraných bodov, z ktorých iba jeden bude mať zaškrtnuté Subscribe/read.
Poznámka 1: Hodnota meraného bodu po vytvorení a uložení s komplexnou adresou 1 zostane Unknown, pretože nakonfigurovaná komplexná adresa 1 zodpovedá 1. prvku v rámci propertyValue, čo je sekvencia a nie jednoduchý zobraziteľný typ.
Poznámka 2: Meraný bod typu Text je schopný obsiahnuť nielen jednoduchú hodnotu ale aj ľubovoľnú ASN sekvenciu. Jednotlivé hodnoty budú zapísané podľa pravidiel pre zápis ASN sekvencie. Ak v predchádzajúcom príklade nastavíme Complex address=1 a meraný bod zmeníme na textový vstup alebo výstup, jeho hodnota bude reťazec " T0:0:0.0; u2; T4:0:0.0; u3; T22:0:0.0; u1; ". Ak bude Property-type=complex, ale Complex address nebude zadaná, výsledok bude " 0{ T0:0:0.0; u2; T4:0:0.0; u3; T22:0:0.0; u1; }".- Increment: prírastok zmeny hodnoty vlastnosti objektu, ktorý spôsobí reportovanie zmeny (viď popis SubscribeCOVProperty).
- Confirmed: ak je checkbox zaškrtnutý, pre nakonfigurované Request typy SubscribeCOV a SubscribeCOVProperty špecifikuje, či zariadenie má posielať potvrdzované (správa ConfirmedCOVNotification-Request) alebo nepotvrdzované (UnconfirmedCOVNotification-Request) notifikácie.
| Kotva |
|---|
| subscriberead |
|---|
| subscriberead |
|---|
|
Subscribe/read: ak je checkbox zaškrtnutý, sú pre nakonfigurované Request typy posielané príslušné správy na čítanie/registráciu zmien hodnôt:
ReadProperty: správa ReadProperty-Request
ReadPropertyMultiple: správa ReadPropertyMultiple-Request
SubscribeCOV: správa SubscribeCOV-Request
SubscribeCOVProperty: správa SubscribeCOVProperty-Request
ReadWriteScheduler: správa ReadProperty-Request
...
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
...
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 Nodutil 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:
...