Normy, standardy a výrobci

Během posledních deseti let došlo k výrazné normalizaci komunikačních standardů v budovách, viz (3). Je to především výsledek intenzivní snahy velkých výrobců. Ti si uvědomili, že pokud nabízejí tzv. proprietární systémy, neboli systémy uzavřené, bez veřejně dostupného popisu, zákazník může mít pocit, že se stává jakýmsi rukojmím dodavatele a je odkázán na jeho služby po celou dobu ­životnosti systému, což může být až několik desítek let. Tomu nahrávala i cenová politika při získávání velkých zakázek u ceny dodávky půjdeme na minimální (nebo i zápornou) marži a zisk realizujeme při vícepracích a servisu.

Tento model byl velmi funkční u developerských projektů, kde investor postavil budovu s minimálním nákladem – a vysoké náklady provozní přesunul na svého zákazníka a tedy na uživatele. I když cena systému řízení budovy představuje 3 až 5 % z celkových investičních nákladů, což není relativně mnoho, „ošizený“ řídicí systém může znamenat nesmírně neefektivní provoz budovy během celé její životnosti. Např. Polách (4) uvádí, že u VZT jednotky jsou investiční náklady kompletně včetně strojní části kolem 10 000 €, zatímco náklady na energii spotřebovanou za celý životní cyklus představují nejméně 300 000 €.

Standardizace komunikačních protokolů má pro dodavatele klady i zápory. Pozitivní stránky jsou tyto:

  • výrobce těží z vývojové základny společné pro více firem
  • může nabízet otevřená řešení a zaplňovat mezery na trhu (například dodávkou speciálního nebo designového pokojového regulátoru, kompatibilního s řídicími systémy jiných výrobců)
  • může nabízet své systémy do tendrů, kde je specifikován standard a nikoli konkrétní výrobce – konkurent

Naproti tomu ale:

  • při přechodu na standardní (tedy pro firmu nový) protokol je nutné dodržet zpětnou kompatibilitu a možnost integrace vlastních starších systémů
  • tento krok je někdy technicky obtížný, vývojáři musí respektovat „balast z minulosti“
  • hrozí vniknutí konkurence do servisního a retrofit byznysu, protože zákazník si může vybrat mezi více propojitelnými systémy.

Dá se říci, že pro zákazníka je to ve všech případech výhoda, s ­výjimkou situace, kdy díky přechodu na novou produktovou řadu nejsou starší systémy, které mohly ještě léta dobře sloužit, již podporovány. Klauzule o desetileté dostupnosti náhradních dílů ještě po ukončení výroby neříká, za jakou cenu a v jakých termínech jsou tyto díly dostupné. Často se některé komponenty pro servis shání po celé Evropě, demontují z likvidovaných staveb apod. Je ovšem třeba říci, že toto je běžná situace pro ukončení výroby z jakéhokoli důvodu, například nedostupnosti starších typů součástek nebo prostě produktové inovace; nedochází k ní tedy výhradně při ­přechodech na standardní sběrnice.

Následující poznámka platí nejen pro výběr sběrnice, ale především pro další standardy nebo služby, na nichž hodláme řídicí systém budovy stavět: Žijeme v rychlé době a inovační cyklus je až ďábelsky krátký!Zvláště v tzv. rezidenční domovní automatizaci a oboru audiovideo technologie vznikají i zanikají doslova sezónním tempem. Totéž platí i o životnosti výrobků spotřební elektroniky. Zvažme tedy, jestli například high-tech tablet, pomocí něhož chceme ovládat zabezpečovací systém, bude fungovat ještě za pět let.

 Otázku, jestli jeho následovník bude kompatibilní s ovládanou technologií, nezodpoví dnes nikdo. Příkladem budiž služba Google PowerMeter, která fungovala necelé dva roky – v červnu letošního roku ji Google přestal podporovat s tím, že uživatelům dal ještě deset týdnů na to, aby si zachránili naměřená data exportem. Jistě si dovedeme představit, co by čekalo uživatele, který by na této službě založil vážnější analýzy.

Tři úrovně komunikace v budovách

Již při přípravě výše zmíněné normy byly definovány tři úrovně ­komunikace v budově - úroveň periferií, kam někdy spadá i sběrnice pro zónové regulátory, tedy regulátory v jednotlivých místnostech – komunikativní pokojové termostaty, jinak se jedná o vstupně-výstupní moduly, komunikativní čidla atd. - úroveň automatizační, která propojuje procesní podstanice, ­případně rozhraní pro místní ovládání (obslužné panely), a - úroveň řídicí (managementu), na níž jsou servery pro ukládání dat, PC s vizualizací, weboví klienti a další prvky, které se přímo nepodílejí na řídicích procesech, ale sbírají z nich data nebo je mohou nějak ovlivňovat.

Je zřejmé, že na každou tuto úroveň budou kladeny jiné požadavky

U periferií vyžadujeme jednoduše adresovatelnou sběrnici s velkým počtem účastníků a relativně malými objemy dat. Sběrnice by měla mít nízké nároky na kabeláž a umožnit přenos dat řádově do 1 km. Použitý komunikační protokol by měl mít rychlou odezvu, aby u ­regulačních smyček nedocházelo k dopravnímu zpoždění. Protokol obvykle nepodporuje složitější datové struktury, jakými jsou například týdenní časové programy. Vzhledem k vyššímu počtu připojených uzlů by hardware neměl být příliš drahý.

Na úrovni periferií se obvykle používají sběrnice KNX, příp. EIB, častá je RS485 s nejrůznějšími protokoly (Modbus RTU, Advantech, S-Bus...), MP-Bus, LON s protokolem LonTalk, u klimatizací např. TCC-Net apod. Patří sem i M-Bus pro sběr dat z měřičů energií. Prostředky pro uvádění sběrnicových periferií do provozu jsou velmi pestré, což ale investora zajímat nemusí. Ten by se měl soustředit spíše na to, jestli použité prvky dovedou splnit jeho zadání, a pokud možno smluvně (aspoň na nějakou dobu) fixovat ceny servisních prací.

Automatizační úroveň již zpracovává větší objemy dat a měla by umožňovat další služby, jako například přehrávání softwaru v podstanicích. Tato funkce je velmi výhodná pro vzdálenou správu technik může provádět diagnostiku systému včetně úpravy programu na dálku a tedy šetří čas na cestách. (V praxi to spíše znamená, že požadované úpravy jsou realizovány obratem a mnohdy ani ­nefakturovány, protože u desetiminutového zásahu by náklady spojené s fakturací byly vyšší, než fakturovaná částka, a zásah je proveden v rámci dobrých vztahů.)

Dnes se používá většinou Ethernet, RS485 nebo LON s některým z neutrálních (např. BACnet, Modbus) nebo firemních (C-Bus, DB-net, Trend IQ apod.) protokolů. Výjimkou nejsou průmyslové sběrnice (Profibus, CAN). Pokud má podstanice rozhraní Ethernet, bývá v ní již také webový server pro jednoduché vzdálené ovládání. Tato funkce je u menších systémů velmi oblíbená a je potřeba ověřit, zda není pro webovou funkci podstanici ještě nutné dovybavit nějakou přídavnou kartou nebo licencí, což by mohlo systém poněkud prodražit.

Rychlost odezvy systému

Častým tématem je rychlost odezvy systému, tedy jak dlouho trvá, než se změna z technologie projeví na obrazovce. S použitou sběrnicí a komunikačním protokolem to velmi souvisí, i když ne tak, jak bychom na první pohled čekali. Pokud jedna sběrnice ­používá rychlost 9600 bitů za vteřinu a jiná řekněme osminásobek, tedy 78 kbps, nemusí to znamenat, že odezva druhého systému je osmkrát rychlejší. Efektivní odezva závisí jednak na tom, jaký je na sběrnici protokol, jednak na způsobu, jakým jsou data zpracovávána v podstanici. Některé protokoly přenášejí hodnoty periodicky s pevným intervalem – master se ptá „pořád dokola“, jiné mají priority pro vstupní signály nebo mechanizmy pro aktualizaci hodnoty, která se změnila o nějaký definovaný skok.

Jindy není přístup na sběrnici řízen masterem a jednotlivé uzly to náhodně „zkoušejí“ (CSMA nebo CSMACD, takto funguje třeba LON a Ethernet, kde díky vyšší ­fyzické přenosové rychlosti se tento „řízený chaos“ vyplatí). Podobně to pak platí pro alarmy, někde jsou dotazovány periodicky, jinde podle priorit, častý bývá tzv. asynchronní přenos, který aktivnímu alarmu umožní přednostně hlásit poruchu komunikací vyvolanou z podstanice na řídicí stanici. Obecně se dá říci, že záleží i na velikosti systému (tedy počtu datových bodů) a dimenzování prvků, čili zjednodušeně, kolik hardwaru s jakým výkonem je na ­řídicí systém použito.

Proto se v zadáních často objevuje maximální přípustná délka odezvy na změnu vstupní hodnoty nebo na alarm, čímž se starosti s návrhem topologie přesouvají na projektanta a dodavatele systému. Ten již musí nabídnout takovou konfiguraci, aby byl schopen zadání splnit. Některé protokoly jsou veřejně dostupné (BACnet, Modbus, M-Bus, Advantech...), jiné „zlidověly“ (Saia S-Bus), další nejsou veřejně zdokumentovány, nicméně existují pro ně rozhraní na standardní protokoly (například Toshiba TCC-link – rozhraní pro Modbus RTU, dodavatel RealTime Systems, Honeywell C-Bus – rozhraní pro OPC, dodavatel SoftYon) – právě tato rozhraní mohou pomoci při integraci cizích technologií do řídicího systému budovy.

První informaci by měl být schopen podat dodavatel, ten ale někdy preferuje ­nákladnější řešení výrobce technologie. Investor pak musí rozhodnout, zda zvolí zdánlivě bezpečnější, ale dražší originální řešení, nebo vsadí na levný převodník, dodávaný cizí firmou, která již má několik instalací za sebou. Rozdíly v ceně mohou činit až stovky procent. Při rozhodování mohou pomoci reference a zkušenosti ­ostatních zákazníků, spolehlivý dodavatel se jimi rád pochlubí. Vždy vyžadujme, aby technickou realizovatelnost potvrdily obě strany – dodavatel technologie i dodavatel systému, do něhož se má technologie integrovat.

Kompatibilita na automatizační a řídicí úrovni

I když prakticky všichni výrobci prezentují používání standardních sběrnic a protokolů jako všelék na problémy s kompatibilitou, ­servisními náklady, vzdáleným přístupem a podobně, ve skutečnosti záleží na tom, do jaké míry byly tyto standardy implementovány, tedy zda podporují všechny potřebné funkce. To musí potvrdit ­dodavatel na základě kvalitního zadání investora. Velmi propracovaný je v tomto ohledu BACnet, kde je definován tzv. PICS (Protocol Implementation Conformance Statement), tedy jakési „potvrzení o shodě“ – standardizovaná tabulka, kterou vyplňuje výrobce zařízení.

V ní je přehlednou formou (zaškrtáváním ­okének, výběrem z možností) přesně popsáno, které objekty a služby ­protokolu BACnet konkrétní výrobek podporuje. Tyto vlastnosti jsou dále seskupeny do BIBB (BACnet Interoperability Building Block), takže například pokud zařízení deklaruje, že „umí“ BIBB s názvem ­DM-TS-B, má všechny potřebné proměnné a funkce k tomu, aby mohlo pracovat jako server pro časovou synchronizaci s místním časem. Zvídavý zájemce najde podrobnosti v článku jednoho z ­duchovních otců BACnetu (5), pěkný popis je i v (6). Další stupeň standardizace představují tzv. funkční profily (BACnet Functional Profiles), tedy souhrny BIBB, které jsou podporovány určitým přístrojem – např. jaké BIBB má obsahovat volně programovatelný regulátor, zónový regulátor, operátorská stanice apod.

V tomto případě je tedy poměrně snadné sestavit zadání naprosto jednoznačně a přesně; ostatně proto BACnet a výše uvedené abstrakce vznikly. Řídicí úroveň, jak se výraz management level překládá, propojuje automatizační stanice s pracovními stanicemi (osobními počítači), na nichž běží vizualizační programy, databáze pro ukládání dat, alarmové servery a další služby. Dnes snad již bez výjimky jako médium slouží IP síť, opět s řadou protokolů. Nejčastěji se používají protokoly jako BACnet, proprietární protokoly, komunikace přes OPC servery atd. Zajímavá situace nastává právě při požadavku na zobrazení dat z různých systémů v jedné vizualizaci. Zde musí projektant rozhodnout, na jaké úrovni (a proto jsme je výše definovali) integraci provést:

Pokud připojí cizí systém přímo do podstanice, tedy na automatizační úroveň, má to tyto výhody:

  • s daty je možno pracovat již v řídicím softwaru v podstanici, cizí systém řídit časovými programy z podstanic atd.
  • není třeba řešit vazbu na řídicí úroveň, protože cizí proměnné jsou namapovány na proměnné z podstanic a přenášejí se stejným protokolem.

Možné nevýhody jsou naproti tomu tyto:

  • někdy je integrace do podstanic složitější, protože vizualizační program již může obsahovat potřebné drivery (a pokud neobsahuje, dají se obvykle doprogramovat snáze, než měnit firmware v podstanicích)
  • vyšší náklady, protože s proměnnými se pracuje dvakrát – jednou v podstanici, podruhé v grafice.

Příkladem možných komplikací je integrace časových programů přes OPC. OPC je oblíbené rozhraní mezi procesní úrovní a vizualizaci, vychází z potřeb průmyslu a je značně rozšířeno, ale pozor – v základu neřeší podporu složitějších struktur, jakými jsou například časové programy. Co to znamená? Týdenní tabulku časového programu můžeme přenést jako řetězec znaků (časů spínání a jim odpovídajících událostí), ale její interpretace již musí být řešena na straně klienta. Ten ovšem „sám od sebe“ neví formát, v jakém jsou data uložena (standard OPC ho nedefinuje), takže by bylo nutné klienta odpovídajícím způsobem doprogramovat. Tento problém se někdy řeší pevnou strukturou týdenního programu, například „4 změny stavu denně“, a v samostatných proměnných typu ­integer se přenášejí hodiny, minuty a stavy pro jednotlivé změny.

Toto ­řešení je ovšem kostrbaté a v případě desítek časových programů v budově prakticky nerealizovatelné. Zásadnější vliv na rozhodnutí pro výběr softwaru (a tedy způsobu komunikace) na řídicí úrovni ale má to, jaké jsou požadavky na ­další zpracování dat. Tedy – stačí mi ovládání technologie z PC, případně z webu, alarmová okna a historické grafy? Nebo budu chtít provozovat rozsáhlou manažerskou síť s automatickým exportem dat do podnikových řídicích systémů, zvyšovat spolehlivost systému redundantními topologiemi a přistupovat k technologii z několika operátorských pracovišť zároveň? Či snad chci systém rozšiřovat postupně, s tím, jak na něj budu připojovat další technologie?

Tyto otázky si investor musí ale klást i pro výběr sběrnic na úrovni automatizační. Než vznikne zadání, ptejme se tedy:

  • Jaké úmysly s budovou mám bezprostředně po dokončení? Budu ji spravovat sám, nebo chci jen základní řídicí funkce a zbytek ať si doplní uživatel?
  • Jak má stavba vypadat za pět let? Plánuje se rozšíření? Není možné dnešním rozhodnutím ušetřit významné náklady v budoucnosti? Jde především o pokládky kabelů a trasy pod komunikacemi, rezervní žíly a optická vlákna, dimenzováním systému na předpokládanou budoucí zátěž.
  • Bude stavba fungovat autonomně nebo bude napojená do ­nějaké komunikační struktury, jako je centrála ve vedlejší budově, dispečink pro správu více budov, nebo dokonce – u výměníkové stanice – centrála pro správu tepelného hospodářství města, či v případě obchodní jednotky připojení na centrálu, která sbírá data ze všech filiálek?
  • Nehrozí, že bude nutné do systému řízení budovy připojit cizí systém? Typicky v hotelu je to vazba na rezervační systém, ve výrobním provozu přenos dat (parametrů prostředí – teplota, vlhkost – nebo hodnot z měřičů energií) do ERP nebo v tepelném hospodářství export dat z kalorimetrů do fakturačního systému?

Ve spolupráci s konzultantem a projektantem by na základě odpovědí na tyto otázky mělo vzniknout zadání pro výběr dodavatele.

Pár příkladů závěrem

Opět platí stará pravda, že jakékoli dodělávání později je daleko nákladnější, než zahrnutí budoucího požadavku rovnou do základního zadání. Ne nadarmo mají například všechny chorvatské Spary v zadání přípravu na řízení čtvrthodinového maxima, ačkoli v chorvatské distribuční síti se v tomto měřítku E-Max dnes vůbec neřeší. Investor, skupina Spar, využil zkušeností z ostatních zemí střední a východní Evropy a vychází z toho, že investiční náklady budou takřka nulové – jedná se o tažení jednoho kabelu k elektroměru a přípravu v aplikačním softwaru. Při realizaci se vše připraví v rámci uvedení do provozu, později by náklady byly tisíce eur jen na cestovném.

Nejhorší situace nastane, pokud je vybrán ne úplně vhodný standard a investor na něm trvá. Příkladem může být větší komerční a logistická stavba v Praze, otevřená v r. 2010. Francouzský investor předepsal sběrnici LON, protože byla součástí (deset let starých) technických požadavků sestavených zahraniční centrálou firmy. Tendr vyhrála firma, která dodávala procesní podstanice ­komunikující po Ethernetu. Zadání podepsala a spoléhala na to, že odlišné řešení obhájí technicky se jednalo o výkonnější a v kontextu budovy „standardnější“ sběrnici, realizátoři měli hluboké zkušenosti a stál za nimi dodavatel systému včetně jeho zahraniční centrály.

Veškeré požadavky zadání byly při realizaci beze zbytku splněny, až na typ sběrnice. Generální dodavatel dal na vědomí, že systém na Ethernetu nebude ochoten převzít – jednak se jistil proti nesplnění zadávacích podmínek, kvůli čemuž by hrozilo nepřevzetí díla investorem, jednak tento argument byl dobrým důvodem, proč subdodavateli neplatit. Výsledkem bylo, že dodavatel instaloval na vlastní náklady převodníky Ethernet – LON a program v podstanicích upravil tak, že se tedy proměnné na ovládací panely a grafiku přenášejí po LONu. Na rozdíl od původního záměru podstanice nejdou dálkově spravovat (tento požadavek ovšem v zadání nebyl) a systém je pro svou komplikovanost servisovatelný jen s extrémním úsilím.

Uvedený příklad nemá nic proti LONu; pokud by byly použity nativní LON ovládací panely, všechno by bylo v pořádku. Proti postupu investora a GD rovněž nelze nic namítat trvali na předem známém zadání. Celkový výsledek je ale z technického hlediska prachbídný. Přátele jasných řešení musím nakonec zklamat obecně nelze říci, jaká sběrnice je „nejlepší“. Jak jsme si ukázali, záleží především na zadání, na typu technologie, jejím začlenění do existujících struktur, ale hlavně na projektantovi, případně konzultantovi, a výkonech ­realizační firmy. Pokud ve vás příspěvek vzbudil zájem o komunikace v systémech řízení budov a přiměje vás k začtení do odkazů uvedených níže, splnil svůj účel.

(1) httpvytapeni.tzb-info.czmereni-a-regulace6879-systemy-pouzivane-v-inteligentnich-budovach-prehled-komunikacnich-protokolu
(2) httpwww.grada.czautomatizovane-systemy-budov_5045knihakatalog
(3) ČSN EN 14908, Otevřená datová komunikace v automatizaci a řízení budov
(4) Polách, P. LCC jako metoda optimalizace..., httpwww.airtechnology.czczsouborylcc_metoda.pdf
(5) Bushby, S.T. New Tools for Specifying BACnet, httpwww.bacnet.orgBibliographyAJ-3-02.pdf
(6) httpwww.polarsoft.bizconform.html

Jan Vidim

Domat Control System s.r.o
jan.vidim@domat.cz
www.domat.cz