BMS na Masarykově univerzitě
Moderní budovy obvykle obsahují automatizované řídicí systémy. Tyto systémy lze navzájem integrovat do jednotného prostředí nazývaného BMS (Building Management System). Tato integrace může klást specifické požadavky na použité systémy nebo na propojující infrastrukturu. V tomto článku jsou nastíněny různé způsoby integrace technologií do BMS a podrobněji představena architektura BMS založeného na protokolu BACnet, který je využíván na Masarykově univerzitě. Článek dále nastiňuje specifické problémy, se kterými je nutné se během budování a provozu BMS vypořádat, a představuje klíčové výhody, které z vysoké míry integrace v BMS plynou.
Součástí mnoha moderních („inteligentních“) budov je i takzvaný BMS – Building management system. Tématem tohoto článku je představení BMS Masarykovy univerzity (dále MU), úvod tedy věnujeme definici pojmu BMS tak, jako ho chápeme v kontextu MU. Tímto pojmem označujeme prostředí (ve smyslu souboru software, hardware a síťové infrastruktury), které zajišťuje integraci a spolupráci jednotlivých systémů zajišťujících provoz budovy. BMS sjednocuje jednotlivé autonomní technologie tak, že se z pohledu uživatelů jedná o jeden provázaný celek.
BMS tohoto cíle dosahuje poskytováním několika základních „služeb“. Jedná se zejména o:
- Sledování a ovládání stavu zařízení – Zajišťuje komunikaci se systémem v reálném čase, zobrazuje aktuální provozní data z budovy a zajišťuje předávání povelů od obsluhy dotčeným zařízením;
- Alarming – BMS aktivně upozorňuje obsluhu na výskyt netypických událostí – poruch, překročení prahových hodnot u sledovaných veličin v prostředí budovy (např. teploty v místnosti) apod.;
- Archivace – Ukládání dat z různých systémů do společné archivní databáze s jednotnou strukturou. Data z archivní databáze lze využívat ke zpětné analýze provozu.
V rámci BMS mohou být integrovány například následující systémy:
- Systém měření a regulace (MaR, BAS – Building automation system) – obvykle základní, nejrozsáhlejší systém v rámci BMS
- Ovládání osvětlení
- Monitoring výtahů
- Odečty energií
- Přístupový systém/Elektronická kontrola vstupu (EKV)
- Elektronický zabezpečovací systém (EZS)
- Elektronická požární signalizace
Obrázek 1: Metody integrace v BMS
Obecně lze BMS implementovat dvěma základními způsoby, a to sice integrací pomocí centrálního uzlu, nebo pomocí integrace na úrovni komunikačního protokolu (viz Obrázek 1: Metody integrace v BMS).
První způsob zajišťuje integraci na nejvyšší možné úrovni, kdy existuje centrální uzel (server), do kterého jsou přivedena data ze všech integrovaných systémů. S každým z těchto systémů centrální uzel komunikuje pomocí nativního protokolu daného systému. Data z různých systémů jsou poté společně prezentována v jednom uživatelském rozhraní. Veškerá komunikace mezi systémy využívající odlišné protokoly musí probíhat přes centrální uzel. Výhodou tohoto přístupu je to, že neklade žádné zvláštní požadavky na integrované systémy – integrace probíhá v rámci centrálního uzlu, který se musí naučit komunikovat pomocí všech potřebných protokolů. Na druhou stranu je třeba při připojení nového systému již z podstaty řešení vždy nutné zasahovat do již existujících prvků systému – je nutné doplnit podporu nového protokolu do centrálního uzlu. Při nutnosti rozsáhlé komunikace napříč systémy je také centrální uzel zatěžován překladem komunikace.
Druhou možností je integrace na úrovni komunikačního protokolu. V takovém případě v systému neexistuje jasně definovaný centrální prvek. Uživatelské aplikace (dispečink, archivní server) podporují komunikaci pouze pomocí jednoho – „integračního“ – protokolu a se všemi systémy v rámci BMS tedy komunikují stejným způsobem. Na trhu je k dispozici několik otevřených a/nebo standardizovaných protokolů, které mohou hrát roli tohoto společného komunikačního prostředku, namátkou jmenujme např. BACnet, LONworks nebo KNX/EIB. Při tomto přístupu je nutné, aby každý systém, který chceme integrovat, umožňoval nějakým způsobem komunikaci pomocí společného protokolu, ať už se jedná o nativní podporu nebo o využití překladače. Rozdílem oproti předchozímu řešení je v takovém případě to, že každý ze systémů má vlastní dedikovaný překladač umístěný v síti, překladače tedy nejsou koncentrovány na jednom uzlu. Požadavek na zajištění překladu na společný protokol klade zvýšené nároky na integrované systémy, na druhou stranu při připojení nového systému není nutné zasahovat do existujících aplikací, změny probíhají pouze na úrovni konfigurace. Integrační aplikace také mohou být jednodušší (obsahují podporu pouze pro jeden komunikační protokol). Komunikace mezi systémy může probíhat přímo bez nutnosti zapojení centrálního uzlu. Vzhledem k tomu, že systémy nejsou odděleny tak striktně jako v prvním případě, je zde větší nebezpečí toho, že se systémy budou navzájem negativně ovlivňovat (např. kvůli chybné konfiguraci nebo chybě v implementaci komunikačního protokolu).
BMS na Masarykově univerzitě
Masarykova univerzita využívá BMS integrovaný na úrovni komunikačního protokolu, kterým je v tomto případě BACnet. Strukturovaná kabeláž určená pro komunikaci v rámci BMS a související aktivní prvky jsou na MU označovány pojmem „technologická síť“ (TeNe). Jedná se o infrastrukturu oddělenou od standardní „akademické“ datové sítě, která je součástí internetu. Technologická síť využívá fyzické infrastruktury (rozvodny, kabelové trasy) budované v rámci akademické sítě MU, aktivní prvky (přepínače, směrovače) však používá vlastní. Zařízení, umístěná v technologické síti, jsou tedy v naprosté většině případů od internetového provozu oddělena – neexistuje síťová cesta umožňující zařízením komunikovat vně technologické sítě. Jedinými výjimkami jsou aplikační servery, umožňující ovládání a sledování BMS, které samozřejmě musí být dostupné ze stanic uživatelů, které nejsou součástí TeNe. Případná další omezení (např. pouze pro přístup z počítačů v síti MU, nikoliv odkudkoliv z internetu) jsou řešena pomocí firewallu v akademické síti. Vyčlenění BMS do samostatné sítě jednak zjednodušuje správu a konfiguraci zařízení zajišťujících provoz budovy, a jednak zvyšuje odolnost vůči bezpečnostním rizikům.
Univerzitní kampus Masarykovy univerzity v Brně získal titul Stavba roku 2011
Nominované a oceněné stavby
Základ dnešního BMS a technologické sítě byl vytvořen v rámci jedné z etap výstavby Univerzitního kampusu Bohunice (UKB), která byla dokončena v roce 2007. Z počátku technologická síť propojovala několik budov v rámci areálu UKB a obsahovala dva samostatné webové servery s vizualizační aplikací (dispečinkem BMS), dva archivní servery sloužící k ukládání historických dat provozu (jeden v aktivní a druhý jako záložní) a server pro zpřístupnění obrazu z kamer systému CCTV. Již tehdy byly v BMS integrovány systémy MaR, ovládání osvětlení, sledování výtahů a monitoring spotřeb energií a bezpečnostní systémy EZS a EPS. Tento rámec integrovaných technologií zůstal zachovaný do současnosti, v průběhu další výstavy UKB došlo i k integraci systému EKV do BMS (ruční otevírání zámků obsluhou, automatické otevírání zámků na základě rozvrhu výuky) a monitoring UPS. Souběžně se také BMS začal rozšiřovat na další budovy MU při příležitostech rekonstrukcí nebo inovace technologií. Technologická síť se tedy rozrostla na metropolitní úroveň, aby mohly být veškeré části BMS dostupné z jednoho místa (uživatelského prostředí). To snižuje nároky na obsluhu i zdroje při vzdáleném monitoringu například v nočních hodinách.
Kvůli zajištění vysoké dostupnosti, rozložení zátěže a zjednodušení přístupu k aplikacím BMS došlo k posílení IT infrastruktury technologické sítě. Webové servery s vizualizační aplikací jsou provozovány pod společnou adresou s rovnoměrným rozkládáním zátěže. Kvůli vysoké důležitosti některých archivovaných dat (např. data sloužící jako podklad pro akreditaci vědeckých laboratoří) je nyní archivace dat řešena pomocí virtuálních počítačů, které mohou v případě selhání hardwaru migrovat na náhradní hostitele. V rámci zvyšování spolehlivosti dochází k tzv. „zakruhování“ původní stromové struktury technologické sítě, aby existovaly záložní síťové cesty v případně výpadku.
V současné době BMS integruje zhruba 900 zařízení komunikujících protokolem BACnet od dvaceti různých výrobců umístěných v šesti geograficky oddělených lokalitách. Systémy jsou do BMS integrovány dvěma základními způsoby – velká většina zařízení (zejména systému MaR) využívají BACnet jako svůj primární nebo dokonce nativní komunikační protokol. Z pohledu MU je toto ideální řešení, protože takový systém (v prostředí MU zejména MaR) se pak z pohledu aplikace dispečinku BMS jeví jako transparentní až na velice nízkou úroveň a správci budov mají vysokou míru kontroly nad jeho chováním. V některých případech je však takové řešení technicky nemožné nebo příliš nákladné, v takové situaci lze použít jiný standardizovaný protokol (např. MODBUS) a integraci provést pomocí překladače protokolů, kterých je na trhu dostupné velké množství. U dalších systémů (jedná se zejména o bezpečnostní systémy, které využívají proprietární protokoly a plná integrace do BMS na úrovni protokolu ani není žádoucí) není možné použít běžně dostupná zařízení pro překlad. Je tedy nutné použít překladač (gateway) dodanou přímo výrobcem daného systému. Z důvodu spolehlivosti preferujeme jednoúčelová embedded zařízení před softwarovými aplikacemi, které vyžadují ke svému běhu běžný počítač a operační systém.
Nové výzvy v rozsáhlém BMS
Kromě výhod, ke kterým se dostaneme v další části, přináší takto rozsáhlý BMS i nové druhy problémů, které se v menším systému neprojevují nebo nejsou natolik závažné, ale které je třeba uspokojivě vyřešit, aby využívání BMS bylo stále efektivní a šetřilo náklady.
Prvním z problémů rozsáhlých BMS je včasná a přesná detekce poruch. U závažných poruch a výpadků může být kvůli komplikované architektuře systému obtížné detekovat přesnou příčinu problémů, ty méně závažné – buď méně akutní, nebo takové, které nelze na první pohled rozpoznat – naopak mohou v systému přetrvávat poměrně dlouhou dobu, protože pro obsluhu je nemožné neustále sledovat správnou funkčnost všech zařízení. V prostředí MU tento problém vedl k vývoji vlastního dohledového systému pro protokol BACnet, který umožňuje velkou část nejčastějších problémů detekovat automaticky a včas a upozornit obsluhu na jejich existenci.
Obrázek 2: Vizualizační aplikace BMS s polem pro zadávání provozních poznámek
S rozsáhlým BMS také pracuje větší množství operátorů, kteří v systému provádějí nejrůznější operace. V případě problémů způsobených nevhodnou obsluhou může však být obtížné dohledat zodpovědnou osobu, která havárii způsobila. Tomu lze předcházet důsledným „logováním“ (uchováváním záznamů) veškerých uživatelských akcí, což však může být problém u takzvaných „stanic operátorů“, což jsou osobní počítače s nainstalovanou ovládací aplikací pro BMS. V těchto aplikací buď log zcela chybí, nebo je obtížné shromažďovat tato data ze všech připojených stanic uživatelů. Je proto vhodné počet operátorských stanic redukovat na nutné minimum a co největší množství úkonů provádět pomocí webového rozhraní, kde je logování (alespoň v případě aplikace využívané na MU) na dobré úrovni. Rozšířili jsme také standardní rozhraní vizualizační aplikace o nástroj pro zapisování různých poznámek k jednotlivým zařízením. Operátor tedy může např. k jednotce VZT připsat poznámku typu „Nezapínat, čeká na opravu“, systém zaeviduje tuto zprávu a jméno autora spolu s časovým razítkem a ostatní uživatelé poté tuto zprávu vidí v aplikaci dispečinku zobrazenou vedle tlačítek pro ovládání daného zařízení (viz Obrázek 2: Vizualizační aplikace BMS s polem pro zadávání provozních poznámek, poznámka je zobrazena v pravém horním rohu).
Poměrně náročnou se v prostředí velkého BMS stává také správa konfigurací. Každý z výrobců volí jiný způsob zálohování stavu svých zařízení, u některých z nich není možné zálohu provést přes síť a v podstatě nikdy není možné zálohování nějakým způsobem automatizovat. Z pohledu správy sítě by ovšem bylo vhodné mít možnost automaticky v pravidelných časových intervalech uložit softwarovou konfiguraci veškerých zařízení v síti a v případě problémů mít možnost vrátit se do libovolného momentu v historii. Vzhledem k technickým překážkám však zůstávají mnohá zařízení bez pravidelných záloh a sledování změn konfigurace (které obvykle neprobíhá přes BMS) je organizačně velice náročné jak v rámci organizace, tak také kvůli externím subjektům, které provádějí servis.
To, že jsou všechna zařízení propojena v jedné síti, má i svou odvrácenou stranu. V případě, že je do takto propojené sítě připojeno zařízení, které buď implementuje komunikační protokol nesprávně, nebo je nevhodně nakonfigurováno dodavatelem, může dojít k ohrožení funkčnosti celého BMS. Špatně nastavená zařízení se často projevují zasíláním velkého množství nesmyslných zpráv do celé sítě. Tyto zprávy mohou systém zcela zahltit, a pokud dojde k přetížení např. vizualizačního serveru pro BMS nesmyslným provozem síti, stane se celý BMS nedostupný. V jiných se chybná implementace komunikačního protokolu projevuje nedostupností některých klíčových funkcí v ovládacím rozhraní BMS. Těmto situacím je možné (a nutné) předcházet důkladným testováním a nakonfigurováním všech nových zařízení v testovacím prostředí ještě předtím, než jsou připojena k technologické síti. Jako testovací prostředí může sloužit malá síť s klíčovými prvky (webové rozhraní, archivní server, několik dalších zařízení) vytvořená speciálně pro tyto účely. V případě větších investičních akcí je možné nově budovanou část technologické sítě dočasně provozovat v „ostrovním režimu“. To znamená, že zařízení jsou již nainstalována ve svých finálních umístěních, mají připojeny vstupy a výstupy, jsou nakonfigurována pro provozní režim a propojena sítí, nejsou však připojena ke stávajícímu BMS, ale provozována izolovaně. Do této samostatné sítě je nutné dále dočasně připojit webový server pro vizualizaci BMS a archivní server. Pokud provedeme důkladné testování jak v dedikovaném testovacím prostředí, tak později v ostrovním režimu, funkčnost nové části systému může být komplexně otestována s poměrně velkou zárukou, že po propojení nedojde k problémům.
Zřejmě největší výzvou pro další výzkum a vývoj je možnost provádění analýz nad velkými objemy dat, které jsou v BMS k dispozici. I když jsou data k dispozici, ruční výběr datových bodů pro každý report je kvůli velkému množství připojených senzorů velice zdlouhavé a náročné pro obsluhu. Automatizace těchto úkonů a inteligentní filtrování dat na základě např. údajů ze systému BIM přinese do BMS zcela nové schopnosti, díky kterým budou facility manažeři využívat data z BMS pro podporu svých rozhodnutí stejně snadno a rychle, jako dnes používají data z CAFM systémů.
Výhody BMS pro MU
I přes výše popsané úskalí má integrace co největšího počtu technologií budov do společného BMS pro MU své nesporné výhody usnadňující provoz organizace. Nejviditelnějším přínosem BMS je prostředí společného dispečinku pro ovládání a sledování veškerých zařízení v BMS. Dispečink v BMS přináší zejména následující výhody:
- Sjednocuje ovládání různých typů zařízení, usnadňuje tedy práci obsluze
- Umožňuje vzdálené ovládání technologií bez nutnosti fyzické přítomnosti u zařízení (při použití VPN odkudkoliv z internetu)
- Zajišťuje ukládání informací o akcích provedených jednotlivými uživateli
Díky tomu šetří BMS čas odborných pracovníků a umožňuje redukovat náklady na dohled nad systémy (např. lze provozovat jedno centrální dohledové pracoviště v režimu 24/7 pro celou univerzitu). Provoz centrálního webového dispečinku a archivního serveru také šetří náklady na hardware – pokud by v jednotlivých lokalitách byly BMS provozovány samostatně, znamenalo by to i nutnost provozovat vlastní server dispečinku i archivní server v každé z lokalit.
Díky využití standardizovaného protokolu BACnet není nutné při rozšiřování BMS o nové typy zařízení nijak zásadně zasahovat do stávajících částí systému – stačí pouze vytvořit nové vizualizační obrazovky. Velké množství produktů na trhu podporujících tento protokol redukuje riziko, že organizace ocitne v situaci nazývané “vendor lock-in” – silné závislosti na jednom výrobci či dodavateli, kdy je kvůli finanční náročnosti přechod ke konkurenci nemyslitelný. Pro protokol BACnet jsou k dispozici open source i komerční implementace a API (Application programming interface), které jednak umožňují MU provádět vlastní vývoj aplikací pro BMS a jednak umožňují výrobu BACnet kompatibilních zařízení i malým výrobcům.
Protokol BACnet je také použitelný jako integrační platforma, kterou lze využívat pro komunikaci mezi rozličnými systémy. Používání společného protokolu usnadňuje vývoj nových aplikací. Jako příklad uveďme požadavek ovládání určitého systému na základě rozvrhů výuky. Na MU tento požadavek poprvé vyvstal u několika učeben, u kterých bylo třeba měnit režim zámků systému EKV tak, aby v době, kdy v učebně začíná hodina, mohli studenti automaticky vstupovat dovnitř. Protože synchronizace mezi databází rozvrhů a přístupovým systémem byla implementována pomocí protokolu BACnet, je toto řešení snadno přenositelné i pro jiné využití. Takovým může být například požadavek, který se později objevil na jiné fakultě MU: ovládání režimu VZT na základě rozvrhů výuky. Vzhledem k tomu, že obě dvě lokality jsou integrovány v jednom BMS, pro splnění tohoto požadavku postačuje pouze změnit konfiguraci aplikace, která nyní zajišťuje otevírání zámků.
Kromě výše zmíněných přínosů BMS poskytuje podrobná, aktuální a přesná dat z BMS o provozu. Ačkoliv oblast analýzy dat z BMS ještě není uspokojivě vyřešena a podporována (alespoň pro BMS takového rozsahu, jako je na MU), skýtá do budoucna široké možnosti optimalizace provozu, zejména ve spolupráci se systémy pro podporu facility managementu (CAFM).
Z hlediska zásobování vodou je zde celá řada problematických míst, nejvážnější je asi situace v hygieně vody, kdy voda v potrubí v technické chodbě zůstává i déle než dva dny v teplém prostoru, ale nelze přehlédnout ani degradaci ocelového pozinkovaného potrubí ještě v záruční době, nedostatek tlaku na výtoku nejvýše položeného hydrantu.
Modern buildings are usually equipped with various automation systems. It is possible to integrate the systems under common environment which is referred to as Building Management System. Such integration usually puts specific requirements on the used systems and connecting infrastructure. This article introduces basic principles of system interconnection in the BMS and further describes BMS architecture based on BACnet communication protocol which is used at facilities of Masaryk University. Next, the article presents specific problems that occur during BMS establishment and operation, and lists main advantages that are brought into the organization’s operation by extensive integration of building automation and security systems.
