Zajištění spolehlivosti BMS
Moderní budovy umožňují sjednotit sledování a ovládání různých automatizačních a elektronických systémů do jednoho prostředí, nazývaného BMS (Building Management System). Zatímco v mnohých instalacích BMS hraje roli doplňku, který zejména zvyšuje pohodlí práce, od určité velikosti systému se BMS stává nepostradatelnou součástí provozu budovy, která jednak zajišťuje veškerou komunikaci mezi uživateli a zařízeními, a jednak umožňuje výrazně snížit náklady při dalším rozšiřování. V takovém případě se spolehlivost a dostupnost systému BMS stává kritickou pro zajištění bezproblémového fungování organizace. V tomto článku jsou představeny jak technické, tak metodické aprocesní aspekty zajištění spolehlivosti systému BMS, založené na zkušenostech z dlouhodobého provozování BMS na Masarykově univerzitě. Dodržování představených zásad umožňuje používat BMS jako primární prostředí pro ovládání technologií budov.
Obrázek 1: Využití vizualizačního serveru
Moderní stavby jsou obvykle vybaveny technologiemi automatizace budov, z nichž zřejmě nejvýznamnější součástí je systém měření a regulace nebo monitoring spotřeby energií. V budovách se nacházejí i další elektronické systémy jako například elektronická požární signalizace, elektronická kontrola vstupu nebo zabezpečovací systém. Všechny tyto systémy mohou být integrovány do takzvaného BMS (Building Management System), což je prostředí, které poskytuje jednak infrastrukturu pro komunikaci mezi systémy a zároveň také zajišťuje funkci různých dalších služeb, které usnadňují provoz budovy. Mezi tyto služby patří zejména vizualizační rozhraní, pomocí kterého lze technologie budov ovládat. Vizualizační rozhraní bývá často realizováno formou serveru, ke kterému se připojují tzv. tencí klienti, takže každý uživatel nemusí mít k dispozici plnohodnotnou aplikaci pro komunikaci se systémem a navíc nemusí mít k dispozici ani přímé připojení k zařízením, se kterými pracuje (viz Obrázek 1: Využití vizualizačního serveru). Další poskytovanou službou jsou zejména alarmové a notifikační zprávy, které jsou buď zobrazovány v prostředí vizualizační aplikace, nebo předávány dále např. pomocí SMS brány. Poslední obvyklou poskytovanou službou je archivní server, což je databáze, která umožňuje ukládat provozní data pro pozdější analýzu.
BMS jednak zvyšují uživatelské pohodlí a zvyšují efektivitu práce při zajišťování provozu budov, zároveň ale v rozsáhlých systémech mohou snižovat náklady na softwarové a hardwarové vybavení. Jako příklad uveďme situaci, kdy je stávající BMS rozšiřován o nová zařízení (např. byla postavena nová budova). V situaci, kdy by nová budova byla provozována autonomně, bylo by kromě jiného pořídit i programovou licenci pro stanoviště operátora, ze kterého bude probíhat obsluha systému, případně i pro archivační server. Pokud však připojujeme novou budovu k existujícímu BMS, kde je již k dispozici vizualizační a archivační (ať už ve formě webové aplikace, nebo serveru, ke kterému se lze připojit pomocí tenkých klientů), není tato investice nutná. Stačí nová zařízení připojit do stávající sítě a rozšířit uživatelské rozhraní o vizualizaci nově přidávaných zařízení a změnit konfiguraci archivačního serveru.
V rozsáhlých systémech s velkým počtem zařízení, velkým počtem uživatelů a zejména větší geografickou rozlohou však již BMS přestává být pouhou „nadstavbou“ zvyšující pohodlí, ale stává se nezbytným pro zajištění provozu. Velké množství prvků systému a také nemožnost rychlé fyzické kontroly (např. kvůli velké docházkové vzdálenosti) znamená, že uživatelé jsou odkázáni na automatické notifikace o alarmových stavech z BMS a také ovládání systému je prováděno prakticky výhradně přes vizualizační server. Ve chvíli, kdy se uživatelé začnou na tento systém spoléhat, je třeba zajistit jeho nepřetržitou funkčnost, protože výpadky mohou mít vážné ekonomické i technické dopady.
Tento článek se věnuje různým aspektům provozu BMS, které mají vztah k zajištění vysoké dostupnosti a spolehlivosti. Tyto oblasti vychází ze zkušeností s provozováním BMS Masarykovy univerzity (dále MU), jehož podrobnější popis lze nalézt v [http://www.tzb-info.cz/facility-management/11078-bms-na-masarykove-univerzite]. Jedná se zejména o:
- Redundantní infrastrukturu;
- Dohledové systémy;
- Procesní postupy při reakci na závadu a znalostní databáze;
- Správu konfigurací;
- Sklad náhradních dílů;
- Správu uživatelských oprávnění a auditing (sledování uživatelských operací);
- Procesní postupy při úpravách systému (testování nových zařízení, rozšiřování systému, úpravy konfigurace).
Správa BMS je v mnohém podobná správě „standardní“ počítačové sítě, kde jsou tyto oblasti dobře metodicky (např. ISO model FCAPS – Fail, Configuration, Auditing, Performance and Security Management) i technicky zvládnuté (protokol SNMP – Simple Network Management Protocol). Zároveň existující komerční nástroje, které komplexně pokrývají správu sítí. Pro oblast automatizace budov však takováto podpora vesměs chybí, zřejmě zejména díky velkému množství používaných protokolů (BACnet, LonWorks, MODBUS, M-BUS,…).
V dalších částech článku jsou postupně popsány jednotlivé oblastní zajišťování spolehlivosti BMS, jejich význam, problémy, se kterými se setkáváme, a možná řešení.
Redundantní infrastruktura
Redundantní infrastruktura zajišťuje běh klíčových součástí systému i v případě, že dojde k selhání jedné komponenty. Koncept redundance klíčových prvků je běžně používán ve standardním ICT, i když samozřejmě obnáší zvýšené náklady. Jeho nasazení pro oblast automatizace budov je relativně bezproblémové díky tomu, že komunikace v BMS na nejvyšší úrovni (např. mezi stanicemi operátorů, vizualizačním a archivním serverem a integračními regulátory) zapouzdřených do standardních síťových protokolů jako Ethernet nebo TCP/IP.
V zásadě máme k dispozici několik technik pro zajištění redundance:
- Násobení hardwarových komponent – Tento postup nalezne využití zejména u serverů a dalších komplexních zařízení. Jedná se zejména o využívání zrcadlení pevných disků v počítači a vybavení strojů redundantními napájecími zdroji (a jejich zapojení na nezávislé napájecí okruhy).
- Násobné síťové cesty – Aktivní prvky počítačové sítě jsou zapojeny a nakonfigurovány takovým způsobem, že jsou minimálně zdvojeny významné komunikační kanály – například spojení mezi budovami a centrálním uzlem BMS, zejména pomocí technologie Spanning Tree na úrovni přepínačů protokolu Ethernet a pomocí vhodně nastavených směrovacích tabulek na úrovni protokolu IP.
- Rozložení zátěže – Tuto techniku lze využít např. pro aplikační servery. Několik vzájemně plně zastupitelných uzlů lze nakonfigurovat tak, aby před uživatelem vystupovaly pod jednou adresou (tzv. loadbalancing cluster). Primárním účelem této technologie je rozložit zátěž, způsobenou velkým počtem připojených uživatelů, na více samostatných serverů. Z hlediska zajištění dostupnosti má však také svůj význam. V případě výpadku jednoho z uzlů dojde k jeho vyřazení z clusteru a také k přesměrování uživatelů na některý z funkčních serverů. V prostředí Microsoft Windows je tato technologie pojmenována Network Load Balancing (NLB) a je standardní součástí serverového operačního systému.
- Virtualizace – Virtualizace serveru umožňuje jeho snadný přesun na jiného fyzického hostitele v případě výpadku fyzického zařízení, na kterém virtualizovaný server běžel. Virtualizace umožňuje také snadné zálohování stavu serveru. Obzvláště výhodné je provozovat virtualizaci ve spojení s technologií „Failover clustering“ (viz dále).
- Failover clustering – Na rozdíl odrežimu rozložení zátěže tato technologie sice také využívá více uzlů, vystupujících pod jednou adresou, v daný okamžik je však aktivní pouze jeden z nich. Ostatní jsou připraveny jako tzv. „horká záloha“ v případě výpadku aktivního uzlu plně převzít jeho roli. V BMS Masarykovy univerzity je tato technologie využívána ve dvou případech. Prvním je Failover cluster nad fyzickými počítači, které slouží jako hostitelé pro virtualizované servery, které automaticky migrují mezi těmito dvěma hostiteli (Hyper-V Failover cluster). V druhém případě je vytvořen Failover cluster nad databázovými servery (SQL Failover Cluster). Failover clustering vyžaduje investici do samostatného diskového pole, protože pro správnou funkci této technologie je nutné mít k dispozici nezávislé sdílené úložiště.
Ze zkušeností z provozu BMS MU plyne, že technologie rozložení zátěže je vhodná pro vizualizační servery, protože nezpůsobuje zvýšenou komunikaci v BMS (objem komunikace se výrazně nemění v závislosti na tom, jestli uživatelé všichni využívají jeden server, nebo jsou rozprostřeni na více uzlech). Z výkonových důvodů nejsou server BMS virtualizovány. Virtualizace spolu s technologií Failover Clustering je naopak vhodná pro archivní server. Virtualizována je jeho aplikační část, tzn. program, který komunikuje se zařízeními v BMS, zpracovává data a odesílá je do databáze. Samotné databázové úložiště je oddělené a využívá MS SQL Failover Clustering. Rozložení zátěže pro archivní server není vhodné, protože v takovém případě by musely existovat dva archivní servery se stejnou konfigurací, takže by všechna data musela být ze zařízení stahována a poté ukládána dvakrát.
Naopak je nemožné v redundantním režimu provozovat zařízení, která komunikují primárně pomocí automatizačního protokolu (zejména tedy PLC, integrační regulátory, aplikační brány apod.). Taková zařízení jsou obvykle vybavena fyzickými vstupy a výstupy nebo jsou k nim připojena další zařízení např. pomocí linky RS485. Vzhledem k tomu, že tato zařízení nejsou klíčovými prvky systému, postačuje však časná detekce závady a její oprava.
Pokud se rozhodneme pro zavádění redundantních prvků v BMS, je třeba si uvědomit, že tato řešení vždy přinášejí zvýšené nároky na správu systému. Díky komplikovanosti využívaných technologií může i drobná nekonzistence nebo chyba v nastavení způsobit zhroucení celého systému. Kromě správné konfigurace je třeba zajistit i konzistenci dat a programového vybavení na redundantních prvcích. Jako příklad poslouží provozování vizualizačních serverů BMS v režimu rozložení zátěže. V případě, že se na všech serverech nenachází stejné verze dat (vizualizačních „obrazovek“) nebo jsou vybaveny rozdílnými verzemi softwaru, z vnějšího pohledu se systém chová naprosto nevypočitatelně a nahodile uživateli zobrazuje různá data podle toho, na který z uzlů je uživatel zrovna připojen. Tyto problémy je velice obtížné diagnostikovat a lze jim předcházet buď důsledným dodržováním pracovních postupů při úpravách systému, nebo pomocí technických řešení jako automatická synchronizace dat mezi uzly (např. DFS Replication – Distributed File System Replication v MS Windows Server).
V případě výpadku některého z redundantních prvků systému jsou možné dva základní scénáře. Buď použitá technologie sama detekuje závadu, nefunkční prvek vyřadí z provozu a adaptuje se automaticky na novou situaci, nebo chyba není detekovatelná vestavěnými mechanismy a je třeba změnu konfigurace vynutit zvenčí, ať už automatizovaně, nebo ručním zásahem. Obecně platí, že technologie pro zajištění redundance jsou schopné reagovat na závažné (a tudíž snadno rozpoznatelné) problémy, jako je například selhání hardwaru nebo výpadek napájení, méně kritické problémy (ztráta síťového spojení, pád aplikace, chybná konfigurace) však zůstávají nepovšimnuty. V následujících dvou částech se tedy věnujeme způsobům, jak takové závady detekovat a jak na ně reagovat.
Dohledové systémy
Automatizované dohledové systémy nad BMS slouží k včasné detekci závad. Dohledový systém se uplatní jak u kritických závad, kde je třeba zajistit co nejnižší dobu odezvy a opravy, tak u skrytých závad, které jinak mohou v systému zůstat neodhaleny po dlouhou dobu, zpětně však mohou způsobovat problémy. BMS sám o sobě sice obsahuje mechanismy pro detekci závad (alarmové zprávy a notifikace), tyto vestavěné metody však jsou vhodné spíše pro odhalování problémů podřízených zařízení (např. technologie HVAC). V případě chyby v samotném BMS nebo automatizačním systému může být vestavěný detekční mechanismus také nefunkční. Pro takové případy je možné použít dodatečné dohledové systémy, které sledují samotnou funkcionalitu BMS (např. právě správnou funkci vizualizačního serveru, archivního serveru nebo sledování dostupnosti jednotlivých zařízení v BMS).
Dohledové systémy lze v oblasti BMS rozdělit do tří kategorií podle toho, na kterou úroveň BMS se zaměřují:
- Standardní ICT systémy – Sledují systém na úrovni síťové infrastruktury. Tyto systémy sledují síťovou dostupnost a provozní parametry aktivních prvků počítačové sítě (přepínače, směrovače, servery, UPS jednotky s komunikačním rozhraním). Pro detekci závad využívají zejména standardizované a rozšířené protokoly ICMP a SNMP. Tyto nástroje nelze využít např. pro specializovaná automatizační zařízení (PLC), která tyto protokoly nepodporují, nebo pro detekci chyb v používaném softwarovém vybavení;
- Úroveň automatizačního protokolu – Tento dohledový systém komunikuje se specializovanými zařízeními, implementujícími specifický automatizační protokol jako například BACnet v případě Masarykovy univerzity. Umožňuje sledovat dostupnost klíčových zařízení BMS a jejich provozní parametry, například nastavení času, hodnoty významných proměnných nebo vstupů a podobně;
- Aplikační úroveň – Z důvodu spolehlivosti nebo efektivity může být nejvhodnějším řešením pro detekci chyb na úrovni softwaru využít na míru vytvořená řešení, která sice nevyužívají standardizovaných protokolů, jsou však schopná detekovat i jinak jen těžko odhalitelné závady. Tyto detekční mechanismy využívají technik jako automatická analýza databáze aplikace (archivního serveru) či aplikačního archivu událostí („logu“) nebo simulace akcí uživatele vizualizační aplikace BMS.
Obrázek 2: Dohledový systém pro BACnet
Na Masarykově univerzitě jsou používány dohledové systémy na všech uvedených úrovních. Dohled nad ICT infrastrukturou je zajišťován pomocí Open Source nástroje Nagios. Dohledový systém na úrovni protokolu BACnet je vyvíjen vlastními silami na MU. Nevíme o žádném běžně dostupném řešení, které by takovouto funkcionalitu zajišťovalo. Dohledový systém je vybaven uživatelským rozhraním v podobě jednoduché webové aplikace (viz Obrázek 2: Dohledový systém pro BACnet). Zároveň umožňuje i notifikaci uživatelů na zjištěné závady pomocí e-mailu a je možné propagovat zprávy do systému Nagios, který je sledován dohledovým centrem pro síťovou infrastrukturu na MU. Operátoři dohledového centra poté mohou zpracovávat hlášení chyb ze systému BMS stejně jako ostatní poruchy a směrovat je na zodpovědné pracovníky.
Dohledové systémy obecně v případě odhalené závady pouze upozorní na existenci problému, protože náprava situace obvykle nebývá natolik triviální, aby šla automatizovat. V některých situacích lze však využít výhod redundantní infrastruktury a problém provizorně vyřešit odstavením vyřazeného prvku. Tento postup je možné ilustrovat na příkladu více uzlů vizualizačního rozhraní BMS, provozovaných v režimu Network Load Balancing. V případě, že dohledový systém detekuje závadu na jednom z uzlů, může se nejdříve pokusit o restart uzlu. Pokud tento postup nevede k odstranění závady, může dohledový systém autonomně rozhodnout o dočasném vyřazení uzlu z clusteru a odeslání zprávy správci systému.
Reakce na závadu a znalostní databáze
Ve chvíli, kdy dojde k detekci závady, ať už tak, že ji nahlásí uživatel, nebo byla odhalena automatizovanými systémy, je třeba na ni zareagovat takovým způsobem a v takovém čase, aby ovlivnila provoz systému v co nejmenší možné míře. Klíčem k efektivnímu řešení problémů je definice jasných postupů, pokrývajících jak samotné hlášení závady, tak její odstranění.
Obecně je třeba minimalizovat závislost systému na dostupnosti jednoho konkrétního pracovníka, který přijímá zprávy o závadách, nebo který umí závadu odstranit. Zároveň je ale třeba jasně stanovit, kdo zodpovídá za odstranění objevené závady, aby nedocházelo k situacím, kdy závadu neřeší nikdo, nebo naopak zbytečně několik lidí nezávisle na sobě.
Proto je vhodné zřídit jedno kontaktní místo (tzv. Helpdesk) pro hlášení závad s vyškolenými pracovníky, kteří budou schopni závadu buď sami odstranit, nebo předat příslušnému specialistovi. Ideální situace pak nastává tehdy, když správci systému využívají vhodný systém pro evidenci požadavků, kde je možné úkoly přiřazovat konkrétním lidem a evidovat jejich dokončení. Na základě těchto dat je pak možné zpětně vyhodnocovat např. doby odezvy a další provozní data. Oblast hlášení závad a pravidelné i vyžádané údržby včetně přidružené analytiky bývá pokryta v systémech pro podporu facility managementu (CAFM – Computer Aided Facility Management).
Pro případy opakujících se provozních problémů je vhodné mít k dispozici znalostní databázi, která obsahuje přesně definované postupy pro odstranění závady nebo alespoň minimalizaci jejích následků do doby, než bude plně opravena (např. postupy pro vyřazení nefunkčních prvků systému, které mohou být nahrazeny v rámci redundantní infrastruktury). Na základě těchto postupů mohou některé úkony provádět i nespecializovaní pracovníci, což významně snižuje dobu reakce na závadu.
Správa konfigurací a sklad náhradních dílů
Velké množství závad bývá způsobeno nevhodnou změnou konfigurace některého prvku systému nebo jeho úplným zničením. V obou případech je nejsnazší a nejrychlejší cestou k obnovení funkčnosti systému jeho uvedení do původního stavu tím, že použijeme poslední známou funkční konfiguraci.
Pokud se jedná pouze o problém konfigurace, lze použít stávající zařízení. Pokud je chyba na úrovni hardwaru, je třeba mít k dispozici náhradní zařízení a funkční konfiguraci aplikovat na něj. V obou situacích je nutné mít k dispozici zálohu poslední funkční konfigurace, protože opravení chyby nebo kompletní definice nové konfigurace mohou být zdlouhavé.
Z toho důvodu by bylo vhodné mít k dispozici pravidelně (nejlépe automaticky) pořizované zálohy konfigurace všech prvků systému, které by bylo možné použít pro obnovu, to je však bohužel v mnoha případech nemožné. Toto je jedna z oblastí, která je dobře ošetřena v oblasti správy počítačových sítí, pro oblast automatizace budov však je (alespoň v prostředí Masarykovy univerzity) udržování aktuálních záloh obtížně realizovatelné. To je způsobeno zejména tím, že např. pro protokol BACnet neexistuje standardizovaný způsob zálohování, který by navíc výrobci byli nuceni implementovat. Ve výsledku tak každý z výrobců automatizačních zařízení nabízí vlastní řešení pro zálohování konfigurace, které jsou vzájemně nekompatibilní a často navíc ani neumožňují automatizaci.
V případě výpadku některé komponenty systému, která není provozována v redundantním režimu (typicky tedy regulátoru) je pro rychlé obnovení provozu navíc vhodné mít zřízený sklad náhradních dílů a zařízení. Je samozřejmě nereálné držet náhradní zařízení od všech použitých zařízení, proto je třeba pečlivě definovat ty části systému, pro které je to pravdu nutné, a počet kusů, které je pro tyto účely třeba držet. Jako vodítko mohou složit zejména cena zařízení, počet nasazených kusů a akceptovatelná doba výpadku.
Auditing a správa uživatelských oprávnění
Dalším krokem po odstranění závady je zjištění její příčiny, aby bylo možné v budoucnu možné závadě předejít. Z toho důvodu by bylo ideální mít k dispozici audit (deník) veškerých zásahů do systému. Tento seznam zásahů je bohužel nutné z velké části udržovat ručně, v tom případě však nikdy nelze získat záruku, že je deník úplný. Automatizované pořizování deníku je však v mnoha případech nemožné, například když dochází k výměně hardwaru. Stejně jako v oblasti odstraňování závad, i zde může dobře posloužit CAFM systém, poskytující podporu pro evidenci požadavků a prováděných pracovních úkonů.
Naopak není problém v BMS sledovat veškeré běžné uživatelské akce, jako například ovládání provozu budovy přes vizualizační rozhraní BMS, které mohou při zjišťování příčin závad taktéž užitečné. Využívání vizualizačního rozhraní BMS v režimu klient-server umožňuje také centralizovanou správu uživatelských skupin a oprávnění, což dále snižuje riziko nekvalifikovaných zásahů do systému. V případě, kdy je každý uživatel vybaven vlastním připojením do BMS a vlastní plnohodnotnou aplikací pro práci s BMS, je správa uživatelských oprávnění a evidence zásahů do systému výrazně složitější, než když uživatelé do BMS přistupují přes jeden „vstupní bod“ – vizualizační server.
Úpravy systému
Kritickým obdobím pro zajištění nepřetržité funkčnosti BMS jsou zejména chvíle, kdy dochází k rozšiřování systému (např. když je připojována nová budova). Zkušenosti ukazují, že automatizační zařízení i softwarové aplikace bývají náchylné na množství komunikace v síti a při zahlcení nefungují správně. Při připojení nového zařízení se může snadno stát, že konfigurace není přizpůsobena stávajícímu systému, nebo je dokonce zařízení neschopné v BMS bez problémů fungovat. V obou případech může dojít k tomu, že je síť zahlcena velkým množstvím nesmyslných zpráv a může docházet k výpadkům celého BMS.
Těmto situacím je naštěstí možné předcházet. Pro otestování nového typu zařízení je vhodné nejdříve ho připojit do oddělené testovací sítě, která však obsahuje základní komponenty BMS, jako například vizualizační a archivní server a v menším měřítku kopíruje strukturu BMS. Pro snížení nákladů lze například použít vývojářské verze aplikací nebo varianty s minimálním počtem licencí pro datové body. V tomto prostředí může dojít ke zprovoznění zařízení, prozkoumání možností konfigurace a zejména k ověření, jestli zařízení dostatečně podporuje všechny služby, které jsou vyžadovány v daném BMS (ukládání archivních dat, odesílání alarmů a notifikací, synchronizace času, korektní vizualizace dat ze zařízení v uživatelském rozhraní, atd.).
V zájmu důkladného prověření schopností zařízení je vhodné vypracovat metodiku testování – „testovací proceduru“, která se postupně zaměřuje na všechny aspekty provozu. Po ověření kompatibility zařízení lze s vysokou jistotou tvrdit, že jeho nasazení do BMS nepřinese problémy.
Pro ověření funkčnosti větších celků (nové budovy nebo areálu) je možné využít provoz v tzv. „ostrovním režimu“. V tomto případě je systém plně nakonfigurovaný a funkční včetně návazností na podřízené systémy, jsou vytvořeny nové podklady pro uživatelské rozhraní, lokální síť je dovybavena archivním a vizualizačním serverem a systém je provozován stejně, jako tomu bude později v ostrém provozu. Ostrovní režim tak umožňuje odstranit různé problémy v konfiguraci ještě během testovacího provozu a poskytuje čas pro úpravy konfigurací tak, aby byly kompatibilní se stávajícím prostředím. Je tak možné vyhnout se značným problémům, které by mohly nastat při připojování rovnou do stávajícího systému.
Závěr
Cílem tohoto článku bylo představit různé metody pro zajištění spolehlivosti a vysoké dostupnosti aplikací a komponent BMS. Spolehlivý chod tohoto systému se stává klíčovým v rozsáhlých instalacích, kde se jedná o jedinou efektivní cestu pro spravování automatizačních technologií budov. Podle zkušeností z dlouhodobého provozu BMS na Masarykově Univerzitě se ukazuje, že představené aspekty hrají klíčovou roli při zajišťování bezproblémového provozu.
I relativně velký BMS samozřejmě může uspokojivě fungovat bez těchto nástrojů, uvedené postupy však mohou výrazně zvýšit kvalitu služby zejména v kritických situacích, kterým se bohužel není možné zcela vyhnout (např. selhání hardwaru). Typický scénář pravděpodobně vypadá tak, že techniky pro zajištění vysoké dostupnosti a spolehlivosti systému jsou zaváděny postupně v průběhu provozu jako reakce na havárie. To je i případ Masarykovy univerzity. Technicky tento postup nepředstavuje problém, zejména zavádění nových metod práce a souvisejících kontrolních procesů však je náročné z organizačního hlediska, je totiž nutné změnit zaběhnuté postupy a nahradit je novými (a obvykle zdlouhavějšími), což se pochopitelně nesetkává s nadšením.
Nastíněná řešení bezpochyby přináší zvýšené finanční nároky (zejména kvůli nákupu hardwaru pro zajištění redundance infrastruktury a držení skladu náhradních dílů), od určité velikosti systému však nepředstavují příliš velký relativní nárůst ceny. Čím větší systém je, tím více pravděpodobně roste i jeho důležitost, dá se tedy říct, že v určitých situacích jsou tyto investice prakticky nevyhnutelné.
Modern buildings allow to unify monitoring and controlling of building automation and electronic systems under a common environment known as a Building Management System. Although in many environments the BMS represents an unnecessary feature that only improves the user experience, with growing size of the facility the BMS becomes essential for a building operation. BMS ensures a communication between users and devices and helps to significantly reduce costs of a system expansion. In that case, a reliability and an availability of the BMS becomes critical for a smooth operation. This article presents technical, methodical and process aspects of a high reliability in the BMS, based on experience with a long-term operation of the BMS at the Masaryk University. Fulfilling the presented principles enables the BMS to serve as a primary environment for controlling of the building operation.