...
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 adaptéru Easylon USB Interface+
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
...
- Kategória komunikačnej linky: TCP/IP-UDP, LonWorks, Serial, SerialOverUDP Device Redundant.
- Parametre linky TCP/IP-UDP:
- Host: IP adresa sieťového rozhrania, ktoré KOM proces používa na komunikáciu. Je možné zadať aj sybolické meno, ktoré sa dá previesť na IP adresu.
Pozn: Je možné zadať aj adresu ALL alebo * - v tom prípade sa používajú všetky dostupné rozhrania. - Port: číslo UDP portu, ktorý KOM proces používa na komunikáciu (podľa normy 0xBAC0, t.j. 47808).
Pozn: parametre záložného servera (Host a Port) nie sú v protokole použité
...
- 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
...
- použitý konfiguračný program: Echelon Node Utility Release 1.82
- nastavené veľkosti a počty buffrov:
DEVICE:0> (B)uffer configuration
Node buffer configuration
Type Count Size Bytes
Receive transaction 11 13 143
Transmit transaction 2 28 56
App buffer in 2 82 164
App buffer out 2 82 164
Net buffer in 5 82 410
Net buffer out 2 82 164
App buff out priority 1 82 82
Net buff out priority 1 82 82
==> Total bytes = 1265
Poznámka k adaptéru Easylon USB Interface+...
Bolo otestované použitie Easylon USB Interface+ adaptéra na 64-bitových Windows 10 (s 32-bitovou D2000). V konfigurácii linky bolo nutné zadať názov zariadenia EasyLVU11-3-Mip0 (nefungoval názov EasyLVU11-3-Vni0). Na počítači bol nainštalovaný ovládač OpenLDV 5.1.
Poznámka k implementácii BACnet MS/TP
...