Nejnavštěvovanější odborný web
pro stavebnictví a technická zařízení budov
estav.tvnový videoportál

TZB-info / Elektrotechnika / Inteligentní budovy / Standard sítě pro automatizaci v budovách BACnet – část 2: služby a interoperabilita

Standard sítě pro automatizaci v budovách BACnet – část 2: služby a interoperabilita

25.9.2025
doc. Ing. Antonín Platil, Ph.D., ČVUT v Praze, Fakulta elektrotechnická (FEL)
Recenzovaný

V dvoudílném seriálu se zaměřujeme na pokročilý standard komunikace automatizačních prostředků v budovách. V minulé části byly popsány podporované sítě a objektový model. V této druhé závěrečné části je popsán systém služeb a nástroje zajištění interoperability zařízení různých výrobců.


Příklad budovy řízené BACnetem: Manchester airport, terminal 2, autor: Ardfern (licence Creative Commons Attribution)

Poznámka k pojmu služeb namísto úvodu

V nejobecnější rovině se v prostředí IT pojem tzv. síťových služeb vztahuje na celý komplex „neviditelných“, ale důležitých automatizovaných činností, které umožňují efektivní provoz firemní sítě a sdílení dat. Lze sem zahrnout protokoly jako DNS (Domain Name System – rozklíčování lidsky čitelných doménových jmen na IP adresy), DHCP (Dynamic Host Configuration Protocol – automatické přidělování IP adres), VPN (Virtual Private Network – k zajištění lepší bezpečnosti a důvěrnosti přenášených dat), protokoly zajišťující funkce e-mailu, FTP (File Transfer Protocol – pro přenášení velkých souborů) atd. [21].

V kontextu BACnetu mnohem úžeji pod pojmem služeb myslíme sadu nástrojů pro manipulaci s vlastnostmi objektů (podle druhu objektu). Konkrétní aktivace služby je realizována zasláním zprávy s příslušnými parametry od žadatele k vykonavateli (serveru, vlastnícímu objekt). Pro srovnání: v prostředí objektového programování bychom snad mohli služby připodobnit k metodám objektu (vyvolaným s příslušnými parametry) a vlastnosti objektu k datovým položkám objektu. Celkově služby BACnetu poskytují komfortní a ucelený způsob manipulace s objekty, podporující komplexní činnosti (např. algoritmické vyhodnocení alarmových stavů), který jde nad rámec prostého zápisu do registrů (např. v průmyslové síti Modbus). Díky konceptu standardizovaných služeb BACnet dokáže zajistit operační kompatibilitu mezi výrobci, napříč různými druhy sítí (BACnet/IP – Ethernet – MS/TP), s otevřenou škálovatelností umožňující budoucí rozšíření funkcí podle potřeb budovy, s podporou vzdáleného dohledu a údržby, s podporou pokročilých funkcí řízení podle kalendářů a časových rozvrhů atd.

Přečtěte si také Standard sítě pro automatizaci v budovách BACnet – část 1: základy, sítě a objekty Přečíst 1. část článku

Služby BACnetu – BACnet Services

BACnet definuje pět hlavních kategorií služeb [1, 7]:

  • přístup k objektu (Object access), tj. čtení a zápis vlastností, v některých případech i dynamické tvoření objektů, vyhledání určitého objektu nebo vlastnosti
  • správa zařízení (Device management), identifikace, discovery, inicializace, …
  • alarmy a události (Alarms and Events), umožňuje ohlašovat abnormální stavy
  • přenos souboru (File transfer), hromadný přenos většího množství dat, jako uložené záznamy trendů
  • virtuální terminál (Virtual terminal), jednoduché znakové rozhraní pro dálkové ovládání

(Konkrétních služeb je mnoho, přičemž většina zařízení podporuje jen malou část z nich.)

Všechny druhy služeb přístupu k objektům jsou potvrzované (confirmed), tedy očekávají nějakou formu odpovědi nebo potvrzení.

Nejrozšířenější službou podporovanou napříč všemi druhy zařízení a objektů je přečtení vlastnosti objektu (ReadProperty Service). Příslušná zpráva zaslaná konkrétnímu zařízení specifikuje objekt a vlastnost k přečtení. Odpověď zaslaná tazateli obsahuje specifikaci objektu, vlastnosti a přečtenou hodnotu. (Případná negativní odpověď obsahuje chybové hlášení.)

Variantou služby, která se vyskytuje často (ale ne vždy) [2] je přečtení více vlastností naráz (ReadPropertyMultiple Service). Ještě vzácněji podporovanou službou je čtení vlastností podmíněné splněním zadaných kriterií (ReadPropertyConditional Service). Pokud to zařízení podporuje, lze se např. dotázat na všechny objekty které splňují že vlastnost Units = degrees-celsius a zároveň vlastnost Present_Value > 23.5.

Služba zápisu (WriteProperty Service) má pochopitelně smysl pouze u zapisovatelných vlastností objektů. Tudíž nejspíš bude podporována např. pro objekt typu Analog Output a vlastnost Present_Value u nějakého aktuátoru, ale ne u objektu typu Analog Input a vlastnost Present_Value v případě senzoru. Oba objekty, tj. jak analogový výstup do aktuátoru, tak analogový vstup ze sensoru však mohou mít např. nepovinnou vlastnost Description (datového typu CharacterString) implementovanou jako zapisovatelnou. Obdobná služba WritePropertyMultiple se vyskytuje ještě méně často, než ReadPropertyMultiple [2].

Commandable property

Při vícenásobném zápisu do vlastnosti Present_Value objektu realizujícího výstup (např. různými zásahy z více zdrojů jako kontrolér a operátorský panel) mohou vznikat konflikty v logice řízení a rozhodoval by (víceméně náhodně) ten, kdo provede poslední zápis. Proto BACnet [1] u některých typů objektů vyžaduje tzv. commandability (česky zhruba „priorita velení“). Každý takový objekt musí pro zápisy do vlastnosti Present_Value udržovat také vlastnost Priority_Array, tj. pole 16 hodnot s odstupňovanou prioritou od 1 (nejdůležitější) po 16 (nejméně důležitou). Navíc takový objekt musí obsahovat vlastnost Relinquish_Default, což je přednastavená „rozumná“ hodnota, která se uplatní jako výchozí při absenci jiných hodnot zapsaných v poli priorit. Návrhář systému automatizace budovy by měl různým řídícím mechanismům přiřadit pro zápis odpovídající priority. Například týdenní plán (Schedule) může nastavit úroveň větrání na minimum pro úsporu energie, ale v případě požáru (Life Safety Zone) evakuační procedury nastaví odtah kouře na maximum, což je důležitější a má to vyšší prioritu [14].

Zpočátku jsou všechny položky pole priorit prázdné (obsahují speciální hodnotu NULL) a uplatňuje se výchozí hodnota nastavená v Relinquish_Default. Každý zápis nové hodnoty Present_Value přichází se zadanou úrovní priority (jinak se považuje za nejnižší prioritu 16). Při zápisu nové hodnoty do pole se vyhodnotí, která neprázdná položka má nejvyšší prioritu a ta se uplatní. Když ten, kdo provedl zápis přestane požadovat „svoje“ nastavení, měl by odpovídající položku v poli se svojí prioritou uvolnit zápisem NULL.

BACnet nepředepisuje, ale pouze doporučuje [14] k implementaci přiřazení úrovní priority tak, že nejdůležitější úroveň 1 odpovídá ručnímu nastavení v ohrožení života (Manual LifeSafety – typicky na pokyn velitele požárního zásahu), úroveň 2 odpovídá automatickému nastavení v ohrožení života (Automatic LifeSafety – typicky od požárního detektoru). Úroveň 5 odpovídá bezpečnostnímu odpojení (Critical Equipment Control – např. ochranným spínačem při sejmutí krytu přístroje). Úroveň 6 je určena pro ochranu citlivých přístrojů před rychlým zapínáním a vypínáním – tzv. Minimum ON/OFF (při zápisu změny stavu vnitřní logika přístroje dočasně zapíše nový stav také do úrovně 6 a tím zablokuje další změny z nižších priorit až do vypršení časovače, pak je úroveň 6 uvolněna). Úroveň 8 odpovídá ručnímu řízení (Manual Operator – tj. běžné převzetí řízení člověkem). Ostatní úrovně jsou volné k použití automatizačními prostředky.

Objekty Analog Output, Binary Output a Multi-State Output musí být implementovány jako commandable [2, 14], objekty Analog Value, Binary Value a Multi-State Value mohou být výrobcem implementovány jako commandable. Další povinně commandable objekty jsou Access Door, Binary Lighting Output a Lighting Output. Objekt Channel prioritní zápisy deleguje na všechny objekty, které jsou členem kanálu a ty pak řeší prioritu samostatně [14].

Change of Value

Základní metodou sledování údajů je přečtení službou ReadProperty případně ReadPropertyMultiple při periodickém dotazování. To však přispívá k zahlcení síťového provozu přenosy při rychlém opakování nebo naopak k příliš pomalé reakci při pomalém opakování dotazů. Alternativní metodou je oznámení o změně hodnoty (Change of Value – COV Notification), které funguje na základě přihlášení k odběru a oznámení o změně (Subscription and Notification) [1]. Tímto způsobem dochází ke komunikaci pouze při zaznamenání změny hodnoty nebo stavových příznaků [2] (Status_Flags). Pomocí služby přihlášení k odběru COV objektu, nebo některé jeho vlastnosti (SubscribeCOV, případně SubscribeCOVProperty) zájemce, tedy klient, požádá zdroj dat, tedy server, o přidání na seznam odběratelů a zaslání případného oznámení o změně sledované hodnoty. Zápis je obvykle na omezenou dobu (typicky minuty) a je třeba ho včas obnovit, jinak vyprší. Pokud zdroj dat službu podporuje a má kapacitu přidat dalšího odběratele, provede první oznámení o hodnotě okamžitě a další oznámení pouze při změně hodnoty podle nastavených kritérií (např. o více než je hodnota vlastnosti COV_Increment). Oznámení o změně odeslané serverem může být potvrzované nebo nepotvrzované (ConfirmedCOVNotification, případně UnconfirmedCOVNotification), podle zadání klienta. Úskalími této metody je omezená podpora (ne každý zdroj dat podporuje COV), možnost ztráty nastavení při resetu nebo přerušení napájení, ztráta dat, pokud klient není dosažitelný v okamžiku oznámení, zahlcení sítě mnoha oznámeními z mnoha souvisejících objektů při vzniku závažné poruchy vybavení budovy atd. U důležitých dat se pro jistotu doporučuje občasné přečtení hodnoty pomocí základní služby ReadProperty [2].

Dynamické tvoření objektů

Služby CreateObject a DeleteObject jsou podporovány jen některými zařízeními, a to jen u některých typů objektů. Např. kontrolér může podporovat dynamické tvoření objektů typu Calendar, Event Enrollment, File, Notification Class, Schedule a Trend Log [13].

Vzdálená správa zařízení

Do této kategorie služeb spadají nástroje pro dočasnou blokaci a povolení komunikace zařízení (DeviceCommunicationControl Service), restart a inicializaci (ReinitializeDevice Service), synchronizaci (TimeSynchronization Service a UTCTimeSynchronization Service) a zaslání jednoduché krátké zprávy (TextMessage Service).

Nejdůležitějšími službami této kategorie jsou ale dvojice služeb kdo-je, já-jsem (Who-Is, I-Am), používaná pro dynamickou konfiguraci sítě (dynamic device binding). Statická konfigurace, static device binding může být poporována, ale vyžaduje manuální přiřazení čísel zařízení (Device Instance) a fyzických adres v síti, což je pracné. Pomocí služby Who-Is je možno odeslat z klientské stanice broadcastovou zprávu všem zařízením na síti s požadavkem, aby se ohlásili krátkou odpovědí I-Am. Z ní pak lze vyčíst jak číslo zařízení (Device Instance), tak síťovou adresu (tj. číslo podsítě a MAC adresu). Aby takový dotaz nespustil záplavu odpovědí zahlcujících síť, lze v dotazu Who-Is omezit dotazovaná zařízení na úzký rozsah čísel zařízení.

Obdobnou funkci plní dvojice služeb kdo-má, já-mám (Who-Has, I-Have), která umožňuje vyhledat pomocí broadcastu na síti zařízení vlastnící objekt podle vlastnosti Object_Identifier (kdo má objekt „Analog Input 10“) nebo podle jména (kdo má Object_Name „vstupni teplota vzduchu“). To poskytuje tzv. dynamic object binding.

Alarmy a události

Zařízení v BACnetu mohou využívat služeb pro hlášení nenormálních stavů. Například pokud je analogový vstup mimo meze určené vlastnostmi High_Limit a Low_Limit, lze to vyhodnotit a nahlásit vnitřními mechanismy objektu, nebo takový stav vyhodnocovat externě složitějším algoritmem pomocí objektu Event Enrollment Object. V obou případech pak navázaný objekt Notification Class Object udržuje časově podmíněný seznam adresátů oznámení o vzniku alarmu nebo události. Služby ConfirmedEventNotification případně UnconfirmedEventNotification Service mohou vyžadovat potvrzení od lidské obsluhy službou AcknowledgeAlarm Service. Objekt EventLog napomáhá shromažďování záznamů o událostech, takže při dočasné ztrátě komunikace nedojde ke ztrátě informace o výskytu události. Přehled o proběhlých alarmech nebo událostech lze vyčíst také službami GetAlarmSummary Service resp. GetEventInformation Service [1].

Přenos souboru je podporován službami AtomicReadFile a AtomicWriteFile, kde označení atomic se vztahuje k nedělitelné povaze operace, tj. vylučuje se konfliktní přístup – např. nelze provést zápis nové hodnoty, dokud není dokončena operace čtení. Přístup k souborům (objektům typu File) může být organizovaný po záznamech nebo po bajtech.

Služby virtuálního terminálu (Virtual Terminal Services, VT-Open, VT-Data a VT-Close) umožňují komunikovat se vzdáleným zařízením pomocí jednoduchého znakového rozhraní a provádět základní konfiguraci a údržbu.

(Zde uvedený výčet služeb není úplný a vyčerpávající popis by byl neúměrně obsáhlý.)

Spolupráce mezi zařízeními (interoperabilita)

BACnet definuje pět oblastí interoperability [1, 7] (Data Sharing, Alarm and Event Management, Scheduling, Trending, Device and Network Management) a do nich příslušející tzv. stavební bloky spolupráce v BACnetu (BACnet Interoperability Building Blocks, zkráceně BIBBs). Jednotlivé BIBBs jsou úzce spjaté s výše popsanými službami (services) a často si vzájemně jednoznačně odpovídají, není to však všeobecně platným pravidlem. Navíc každý BIBB definuje dvě části: část A – klientskou (která požaduje provedení akce), a část B – serverovou (která vykonává požadavek a případně poskytuje odpověď). Mluví se pak o zařízení A a zařízení B.)

Například [1] v oblasti sdílení dat (Data Sharing, DS) existuje BIBB čtení dat, který má dvě části: klientskou ReadProperty-A (kód DS-RP-A) a serverovou ReadProperty-B (DS-RP-B). Pokud má nějaké regulační zařízení přes BACnet číst údaje z inteligentního senzoru na síti (např. teploměru), pak musí implementovat klientskou část BIBB, tj. DS-RP-A a vzdálený senzor musí implementovat serverovou část, tj. DS-RP-B. Tato varianta BIBB je naštěstí nejuniverzálněji podporovaná. (Některá zařízení mohou podporovat obě části, např. chovat se jako klient a vyčítat data ze vzdáleného serveru a zároveň jako server poskytovat data dalším uzlům. Implementují tedy DS-RP-A i DS-RP-B.)

Komplexnější BIBBs jsou pak ReadPropertyMultiple-A a -B (DS-RPM-A, DS-RPM-B) a ReadPropertyConditional-A a -B (DS-RPC-A, DS-RPC-B) – zdaleka ne všechna zařízení podporují tyto složitější verze sdílení dat. Je pak zbytečné pořizovat pokročilý kontrolér podporující tyto komplexní BIBBs pokud je nepodporují také připojené zdroje dat (senzory).

Dalšími BIBBs v oblasti Data Sharing jsou WriteProperty-A a -B (DS-WP-A, DS-WP-B), WritePropertyMultiple-A a -B (DS-WPM-A, DS-WPM-B), Change of Value COV-A a -B (DS-COV-A, DS-COV-B), COV Property COVP-A a -B (DS-COVP-A, DS-COVP-B) a Change of Value-Unsolicited-A a -B (DS-COVU-A, DS-COVU-B). (U novější verze standardu existují ještě další BIBBs z oblasti Data Sharing, které zde pomineme. Úplný seznam je např. v [15].)

Obdobně v oblasti Alarm and Event Management (AE) jsou definovány BIBBs jako klientská Notification-A (AE-N-A) a odpovídající serverové Notification-internal-B a Notification-External-B (AE-N-I-B a AE-N-E-B), Acknowledge-A a -B (AE-ACK-A, AE-ACK-B), AlarmSummary-A a -B (AE-ASUM-A, AE-ASUM-B), EnrollmentSummary-A a -B (AE-ESUM-A, AE-ESUM-B) a další.

Oblast Scheduling (SCHED) definuje BIBBs jako klientská Scheduling-A (SCHED-A), a odpovídající serverové Scheduling-Internal-B a Scheduling-External-B (SCHED-I-B, SCHED-E-B) a další.

Oblast Trending (T) definuje BIBBs klientská Viewing and Modifying Trends-A (T-VMT-A) a odpovídající serverové Viewing and Modifying Trends-Internal-B a Viewing and Modifying Trends-External-B (T-VMT-I-B, T-VMT-E-B), Automated Trend Retrieval-A a -B (T-ATR-A, T-ATR-B) a další.

Oblast Device Management (DM) definuje BIBBs jako Dynamic Device Binding-A a -B (DM-DDB-A, DM-DDB-B), Dynamic Object Binding-A a -B (DM-DOB-A, DM-DOB-C), ReinitializeDevice-A a -B (DM-RD-A, DM-RD-B), a mnoho dalších.

(Poslední verze standardu [16] definuje další oblasti interoperability jako Network Management, Gateway a Audit Reporting.)

Profily zařízení (Device Profiles)

Při výběru zařízení do automatizačního systému je tedy nutné kontrolovat, které BIBBs konkrétní výrobek skutečně podporuje. To je částečně zjednodušeno tím, že BACnet definuje několik standardních profilů zařízení (Device Profiles), které určují minimální množinu BIBBs, které zařízení daného profilu musí podporovat [1]. Nejjednodušší profil se nazývá BACnet Smart Sensor (B-SS) a vyžaduje pouze serverový BIBB ReadProperty-B (DS-RP-B). Další v řadě je profil BACnet Smart Actuator (B-SA), který navíc vyžaduje serverový BIBB WritePropery-B (DS-WP-B).

(Konkrétní model zařízení může podporovat i více BIBBs než vyžaduje základní množina jednoho profilu, ale muselo by podporovat všechny BIBBs vyžadované dalším vyšším profilem, aby spadalo do této vyšší kategorie.)

Komplexnější profily pak postupně přidávají požadavky na další a další BIBBs navíc. BACnet Application Specific Controller (B-ASC) vyžaduje také BIBBs pro dynamic device binding (DM-DDB-B) a dynamic object binding (DM-DOB-B) – tj. podporu služeb Who-Is, I-Am a Who-Has, I-Have a DeviceCommunicationControl-B (DM-DCC-B). Profil BACnet Advanced Application Controler (B-AAC) přidává požadavky na podporu alarmů a plánů (Schedule) a časovou synchronizaci. BACnet Building Controller (B-BC) přidává požadavky na podporu trendů, a další. Také je to první z profilů, který v omezené míře obsahuje požadavky na podporu i klientského chování, tj. např. čtení hodnoty ReadProperty je vyžadováno v obou formách A i B (DS-RP-A, DS-RP-B). (V novější verzi standardu se všechny dosud uvedené profily řadí do skupiny tzv. General Purpose Controller Profiles.)

Další v řadě je profil BACnet Operator Workstation (B-OWS), který vyžaduje podporu BIBBs obdobných jako Building Controller (B-BC), ale v klientské „-A“ verzi, zadávající požadavky serverům (tj. tzv. „B-side“ zařízením) k provedení.

Pozn.: v novější verzi standardu bylo toto jednoduché hierarchické schéma poněkud zkomplikováno, např. operátorská pracovní stanice B-OWS byla doplněna o jednodušší varianty s omezenou funkčností BACnet Operator Display (B-OD) a naopak pokročilou komplexní verzi Advanced Workstation (B-AWS) [12]. Také bylo doplněno hned několik profilů pro specifické aplikační oblasti jako např. Access Control Workstation (B-ACWS), Advanced Lighting Workstation B-ALWS), Lighting operator display (B-LOD), Life safety annunciator panel (B-LSAP), Life safety controller (B-LSC), Elevator workstation (B-EWS), atd. [17].

Deklarace schopností zařízení výrobcem (PICS)

Aby bylo možno vyhodnotit schopnosti konkrétního modelu zařízení, výrobce publikuje standardní dokument podobný datovému listu, popisující implementované funkce – tzv. BACnet Protocol Implementation Conformance Statement (PICS). Ten má několik standardních částí, odkazujících se na relevantní části standardu (resp. jeho přílohy – Annexes).

V úvodní části je specifikován výrobce, model a název zařízení, číslo revize firmware a revize BACnet protokolu. Dále uvede standardní profil zařízení BACnet Standardized Device Profile podle Annex L standardu, např. BACnet Building Controller (B-BC) [13].

Dále uvede seznam všech podporovaných BIBBs podle Annex K standardu, např.: Data Sharing Read-Property-A (DS-RP-A), Data Sharing Read-Property-B (DS-RP-B), Data Sharing Write-Property-A (DS-WP-A), Data Sharing Write-Property-B (DS-WP-B), Alarm and Event Notification-Internal (AE-N-I-B), Scheduling-Internal-B (SCHED-I-B), Trending Viewing and Modifying Trends Internal-B (T-VMT-I-B), Device Management Dynamic Device Binding-A (DM-DDB-A), Device Management Dynamic Device Binding-B (DM-DDB-B), Device Management Dynamic Object Binding-B (DM-DOB-B), atd…

Dále uvede schopnost zpracovávat segmentované zprávy (tj. dlouhé zprávy, které se nevejdou do jednoho přenášeného paketu).

Následuje seznam všech implementovaných typů objektů s vyznačením, které objekty je možné vytvořit nebo smazat dynamicky, např.: Analog Input, Binary Output, Calender (Dynamically Creatable: Yes, Dynamically Deletable: Yes), atd.

Dále je uveden seznam podporovaných Data Link Layer Options, např.: BACnet/IP, MS/TP apod. a další detaily o eventuální podpoře některých síťových technologií.

Závěr

Každý projekt má pochopitelně vlastní specifické nároky na požadované parametry prostředků automatizace. Přesto lze obecně doporučit, aby investor kromě samotné ceny na pořízení vyhodnotil celkové náklady vlastnictví (TCO – total cost of ownership), včetně nákladů na údržbu, dostupnost náhradních dílů, školení personálu, spolehlivost a náklady plynoucí ze selhání a výpadku síťových technologií atd. Přes počáteční cenovou výhodnost může zdánlivě levné řešení způsobit velké dodatečné náklady a ztráty. Dalšími aspekty jsou riziko svázání se s jedním dodavatelem proprietární technologie (vendor lock-in), (ne)možnost budoucího rozšíření o nové prvky, zda jde o rekonstrukci staršího systému nebo zcela nový systém tvořený od nuly, atd. Mnoho z těchto aspektů vede k upřednostnění některého z otevřených standardů, kde obvykle uživatel může těžit z větší konkurence mezi výrobci, lepší dostupnosti produktů, nesvázanosti s jediným dodavatelem a lepší propojitelnosti různých prvků.

BACnet představuje vyspělý standard s dlouhou historií a dnes již silným zastoupením na trhu. Podle organizace BSRIA měl BACnet globální zastoupení v 64 % projektů automatizace budov v roce 2018 [18] a 77 % v roce 2024 [19]. Standardizace základních konceptů a rigorózní testování shody dovoluje spolupráci jednotek různých výrobců. Zároveň začleněná flexibilita umožňuje výrobcům vyvíjet nové produkty a případně zavádět nové součásti standardu při zachování zpětné kompatibility se staršími produkty.

Organizace BACnet international na svém webu [20] představuje příklady úspěšných projektů nasazení BACnetu. Např. v Německu (Frankfurt n. M.) byl velký kancelářský komplex Theodor-Heuss-Allee 100 vybaven řídícím systémem sledujícím 20 tisíc vstupů a výstupů z klimatizace, osvětlení, požární ochrany, odkouření a elektrických rozvodů. Za páteř systému byl vybrán BACnet na Ethernetu přímo sledující 4000 vstupů a výstupů, s integrací dalších podsystémů na Profibusu (požární klapky) a EIB (osvětlení a stínění). Dále např. v Berlíně tzv. O2 World Arena (nyní Uber Arena) byla vybavena systémem 36 frekvenčních měničů ABB pro řízení ventilátorů klimatizace se zabudovanou podporou standardu BACnet MS/TP v kombinaci s BACnet/IP Router moduly pro efektivní správu sítě umožňující snadné sdílení údajů a dohled. Ve Velké Británii terminál 2 letiště Manchester nasadil kombinovaný systém BACnet a DALI (26 BACnet kontrolérů funguje jako DALI mastery pro LED osvětlení), který přizpůsobuje osvětlení provozním podmínkám (využití jednotlivých příletových/odletových bran) a denní době a přispívá ke značným úsporám energie.

Reference

  1. Building Automation System Integration with Open Protocols, American Technical Publishers, 2012, ISBN: 978-0826920126
  2. Chipkin P.: BACnet for Field Technicians, Revision 2.0 – Feb. 2024 (www.chipkin.com), online https://cdn.chipkin.com/assets/uploads/2024/Mar/BACnet%20For%20Field%20Technicians%20-%20Revision%202.0_20-20-35-15.pdf
  3. BACnet Committee (ASHRAE SSPC 135), online https://bacnet.org/
  4. BACnet Testing Laboratories, online https://btl.org/
  5. Hayes E.: BTL Certification Overview, Journal of Building Automation, 23, May 2023, p. 8-10, ISSN 2191-7825, online https://bacnetinternational.org/wp-content/uploads/sites/2/2023/05/Journal-of-BA_23.pdf
  6. Softwarová knihovna CAS BACnet Stack, online https://www.bacnetstack.com/
  7. Introduction to BACnet For Building Owners and Engineers, Ver.1.0, 2014, BACnet International, online
    https://www.ccontrols.com/pdf/BACnetIntroduction.pdf
  8. ANSI/ASHRAE Addendum q to ANSI/ASHRAE Standard 135-2008, online
    https://bacnet.org/wp-content/uploads/sites/4/2022/08/Add-135-2008q.pdf
  9. Butler J.: Introduction to BACnet/SC - A Secure Alternative to BACnet/IP, April 2019, AutomatedBuildings.com, online https://www.automatedbuildings.com/news/apr19/articles/cimetrics/190321112606cimetrics.html
  10. Fisher D.: BACnet/SC: The Big Picture, BACnet International Journal, 18, November 2020, p. 5-7, ISSN 2191-7825, online https://bacnetinternational.org/wp-content/uploads/sites/2/2022/07/journal_Issue_18.pdf
  11. Fisher D., Isler B., Osborne M.: BACnet Secure Connect - A Secure Infrastructure for Building Automation, online https://bacnetinternational.org/wp-content/uploads/sites/2/2022/07/B-SC-Whitepaper-v15_Final_20190521.pdf
  12. Wichenko G.: BACnet Explained, ASHRAE Journal, November 2013, online
    https://bacnet.org/wp-content/uploads/sites/4/2022/06/Wichenko-2013.pdf
  13. 750-832(/xxx-xxx) BACnet Protocol Implementation Conformance Statement (PICS), WAGO Kontakttechnik GmbH & Co. KG, https://www.wago.com/cz/procesorov%C3%BD-modul/procesorov%C3%BD-modul-pro-bacnet-ip/p/750-832
  14. Fisher D.: Commandability in BACnet, Aug. 2016, online https://polarsoft.com/bex/papers/Commandability.pdf
  15. BACnet BIBB’s TABLE – Bacnet Interoperability Building Blocks, online
    https://store.chipkin.com/articles/bacnet-bibbs-table-bacnet-interoperability-building-blocks
  16. ISO 16484-5:2022(en) Building automation and control systems (BACS) — Part 5: Data communication protocol
  17. Device Profile Quick Reference Guide, online https://cdn2.mycrowdwisdom.com/bacnet/s3courses/BACnet-Device-Profiles---SCORM12---9-24-1592243488077/story_content/external_files/Device_Profile_Quick_Reference_Guide.pdf
  18. BACnet Market Adoption Report Available, BACnet International Journal, 15, April 2018, p. 26, ISSN 2191-7825, online https://bacnetinternational.org/wp-content/uploads/sites/2/2022/07/journal_issue_15.pdf
  19. Heard M.C.: BACnet: The Standard’s Journey from a ’Fool’s Errand’ to Global Ascendency, Journal of Building Automation, 26, October 2024, p. 8-9, ISSN 2191-7825, online
    https://bacnetinternational.org/wp-content/uploads/sites/2/2024/11/241112_BJ_OfBuildingAutomation_26_digital.pdf
  20. BACnet International - Case Studies, online https://bacnetinternational.org/case-studies/
  21. Network services 101: Everything you need to know, online https://www.meter.com/resources/network-services
English Synopsis
Network Standard for Building Automation BACnet – Part 2: Services and Interoperability

In this two-part series, we focus on the advanced standard for communication between automation devices in buildings. The previous part described the supported networks and object model. This second and final part describes the service system and tools for ensuring the interoperability of devices from different manufacturers.

 
 
Reklama