Výhody a nevýhody dodávek VZT zařízení s vlastní regulací
Článek popisuje možnosti integrace vzduchotechnických a klimatizačních jednotek s vlastní regulací do systémů řízení budov. Pokud se zúčastněným stranám podaří předem přesně domluvit, jakým způsobem a s jakými funkcemi budou komunikovat, vyhnou se problémům při realizaci a zpoždění dodávek. Zařízení s vlastním řídicím systémem se v dodávkách objevují stále častěji a to do jisté míry mění pohled na úlohu profese měření a regulace.
Úvodem
Profese měření a regulace (MaR) se v posledních letech čím dál častěji setkává s tím, že dodávky vzduchotechniky jsou již vybaveny vlastním řídicím systémem. Důvodů je několik - vzduchotechnické firmy chtějí poskytovat komplexní řešení a koordinace s profesí elektro nebo MaR by u menších zakázek byla poměrně nákladná, především ale dodavatel vzduchotechniky (VZT) má jistotu, že řídicí systém pracuje přesně podle jeho požadavků. U samostatně instalovaných zařízení to je v pořádku; problém nastává v okamžiku, kdy v budově je instalován (původní nebo nový) systém MaR pro další technologické celky a přirozeným požadavkem investora je, aby se nové VZT jednotky staly součástí tohoto systému a veškerá technická zařízení v budově měla jednotné ovládání včetně přenosu alarmů, záznamu historických dat atd.
Profese MaR dodává regulaci obvykle tehdy, když řídicí systém pro VZT má malý podíl na celkové dodávce MaR a integrace by se nevyplatila. Hrají zde roli ale i obchodní zájmy firem, takže v praxi občas vídáme velmi kuriózní technická řešení. MaR se dodávky vzdává např. u multisplitů a dalších systémů, projektovaných tak, aby mohly existovat autonomně a regulace je nedílnou součástí technologie - právě tam se VZT do řídicího systému budovy (Building Management System, BMS) integruje přes datové rozhraní.
Řídicí systém dodávkou VZT
Pro dodavatele VZT dodávka vlastní regulace znamená:
- vyšší obrat (a to i ve službách - oživení, pozáruční servis)
- menší problémy s instalací periferií, ty se montují a přezkušují již při výrobě a nehrozí, že by například na stavbě nebylo kudy namontovat protimrazovou ochranu,
ale na druhé straně
- obtížnější přizpůsobení řídicího systému případným změnám na stavbě, se kterými by si profese MaR obvykle snadno poradila
- nutnost řešit ovládání jednotek, školení uživatelů, náklady na záruční servis atd.
- a především koordinaci s profesí MaR při integraci do BMS.
Pak dochází k jednáním mezi investorem a stavební firmou či generálním dodavatelem - a podle smluvních vztahů na stavbě obvykle stavba nasmlouvá a koordinuje profese MaR a VZT, nebo měření a regulace je subdodávkou vzduchotechniky (což je z našeho pohledu jednodušší případ). Dodavatel VZT musí poskytnout technické podklady k použitému řídicímu systému a dodavatel MaR vyspecifikuje, jak a s jakými náklady je schopen řídicí systém jednotek zaintegrovat do systému řízení budovy.
Nekomunikativní systémy
Řada starších analogových regulátorů i novějších mikroprocesorových, ale bez komunikačních rozhraní (staefa classic, Polygyr a další). Pokud s integrací výrobce nepočítá již předem, integrace je obtížná, vyžaduje zásahy do zapojení rozvaděče a omezuje se na povolení chodu jednotky, snímání provozních stavů (chod, alarm), případně měření několika teplot nezávislými čidly. Protože se VZT jednotky dnes umisťují i na méně přístupná místa, jako jsou střechy, mezistropy atd., alespoň základní dálková kontrola jejich chodu je nutná. Pokud toto projektant ani uživatel neřeší, může se stát, že jednotky celé dny stojí na alarm, časové programy neodpovídají provozní době, vnitřní hodiny se odchylují od správného času atd., což vede k nižšímu komfortu či vyšší spotřebě energie.
Systémy s komunikací
U systémů, které výrobce označuje jako komunikativní, se zajímáme o tyto vlastnosti:
Rozhraní je součástí dodávky, nebo bude představovat vícenáklady?
Poměrně zásadní otázka. Obchodní politikou některých výrobců může být dodávka dostupné regulace za dobrou cenu s volitelnou komunikací. Cena komunikační karty nebo převodníku na otevřený protokol, zvláště pokud se jedná o rozhraní Ethernet, může i přesáhnout cenu samotného regulátoru v základním provedení (např. Siemens Saphir ACX32 a komunikační karta Ethernet pro web, OPC a BACnet ACX52.22.). Karty pro rozhraní RS485 (např. u Lennox Climatic 50) bývají již cenově dostupné, karta pro LON je poněkud dražší a vyšší náklady na integraci se mohou projevit i na "druhém konci linky", viz dále. Jindy je regulátor sériovou komunikační linkou RS485 (např. Jesy) nebo dokonce rozhraním Ethernet (namátkou Swegon) vybaven již v základním provedení.
Pro více regulátorů stačí jedno rozhraní, nebo je nutná karta do každé jednotky?
Některé systémy používají pro propojení jednotek vlastní vnitřní sběrnici, která vede do jediného komunikačního převodníku. Ten pak poskytuje data v podobě standardního rozhraní a známého protokolu. S tímto řešením se často setkáváme u splitových jednotek, multisplitů, VAV/CAV systémů (a v topenařině u kotlů, např. Buderus a jeho "RS232-Gateway").
Jak se komunikace konfiguruje?
Dodavatel by měl specifikovat, jestli je pro nastavení komunikace potřebný nějaký servisní převodník, software atd., tedy s jakými náklady ze strany dodavatele VZT musíme počítat. Pro většinu standardních karet výrobce dodá manuál pro fyzické nastavení rozhraní (rychlost, parita...) a tabulku proměnných. U složitějších rozhraní (např. BACnet server Haier) musíme počítat s několika hodinami technika. Je pravda, že náklady na nastavení systému jsou ve srovnání s cenou celé dodávky zanedbatelné, nicméně je dobré mít smluvně ošetřeno, která strana je pokryje.
Jakým způsobem regulátor komunikuje?
Protože datové komunikace jsou z pohledu dodavatelů strojní části stále tak trochu obestřeny tajemstvím, integrující strana musí jasně a nejlépe písemně sdělit, jaké informace potřebuje. Jedná se o tyto body:
- Fyzické rozhraní (RS232, RS485, LON, Ethernet, EIB/KNX...), podle něj se volí převodník nebo dokonce celé řešení na straně BMS.
- Popis svorek se signály, což je důležité hlavně u nestandardních nebo šroubových konektorů, např. v případě Ethernetu "není co řešit". Pro přepólované komunikační svorky byly ztraceny již stovky hodin pokusů a omylů.
- Použitý komunikační protokol, případně jeho dialekt, verzi atd. Do jisté míry souvisí s fyzickým rozhraním, např. pro Modbus TCP bude regulátor mít nejspíše rozhraní Ethernet.
- Tabulku s proměnnými, jejich adresy, interpretace a význam. Formát nebo vzhled tabulky závisí na použitém protokolu. Proměnné (čili datové body) by měly být i příslušně okomentovány a u protokolů, kde nejsou určeny významy hodnot, musí být uvedeno, co která hodnota znamená.
Například u LON rozhraní pro klimatizační jednotky Toshiba vypadá část tabulky takto:
Jelikož Toshiba používá standardní typy proměnných LON (Standard Network Variable Types, SNVT), u proměnné Operation Mode Setting (čteme nastavení provozního módu) stačí výpis použitých stavů. Podobně u čtení nastavené požadované teploty (Temperature Setting) stačí informace o tom, že proměnná je typu SNVT_temp_p. Tím je určena délka proměnné, rozlišení, interpretace v telegramu atd. Zásadní výhoda je ale ta, že na protější straně komunikace stačí nadefinovat proměnnou stejného typu a víme, že hodnota bude přenesena správně.
Pro "jednodušší" protokoly, například Modbus RTU, může tabulka vypadat podobně:
Vidíme, že v políčku Type je číslo modbusové funkce a informace o tom, zda proměnná je určena pro čtení (R) nebo pro zápis. Podstatný je údaj Modbus address, což je adresa proměnné v modbusové tabulce rozhraní. Popis (Description) ukazuje, jaký význam proměnná vůbec v systému má.
Součástí popisu komunikace Modbus jsou ještě další zásadní informace: fyzické parametry linky (přenosová rychlost, parita, počet stop bitů) a formát analogových hodnot - Modbus typicky přenáší 16bitové hodnoty, interpretované jako celá čísla, takže pro přenos analogových hodnot se používá tzv. HVAC integer: hodnota se před přenosem vynásobí x10 nebo x100 a po přijetí se tímto koeficientem vydělí, takže např. 18.5 °C se přenáší jako 185.
Při zjišťování technických parametrů si u většiny protokolů musíme dát pozor na terminologii, například "komunikujeme po Modbusu" může znamenat
- komunikujeme protokolem Modbus TCP na rozhraní Ethernet
- komunikujeme protokolem Modbus RTU na rozhraní RS485
- komunikujeme protokolem Modbus RTU na rozhraní RS232
- komunikujeme protokolem Modbus ASCII na rozhraní RS232
- komunikujeme některou z výše uvedených možností, ale jako klient (master), nikoli server (slave)!
... a znalce jistě napadne řada dalších nuancí. Překvapení někdy umíme řešit přepnutím DIP vypínače nebo nastavením komunikačního parametru, jindy dokoupením převodníku (stovky až tisíce Kč) nebo dopsáním komunikačního driveru (tisíce Kč až "nemožné").
U protokolu BACnet existují podle standardu dvě varianty, BACnet/Ethernet a BACnet/IP. Podrobný popis rozdílů mezi nimi je nad rámec tohoto textu, zrada spočívá v tom, že v topologických schématech vypadají oba protokoly stejně - přenášejí z uživatelského hlediska stejné informace a fungují na stejném médiu (Ethernet). Ačkoli BACnet/IP se vyskytuje podstatně častěji, můžeme se setkat i s druhým z nich.
Náklady
Vždy záleží na tom, do jakého systému BMS jsou VZT jednotky integrovány - tedy zda systém použité standardy podporuje, nebo musí být doplněn o další hardwarové nebo softwarové komponenty. U nestandardních firemních protokolů je třeba získat kompletní popis, na jehož základě je vyvíjen driver - softwarové komunikační rozhraní. Cena vývoje se pohybuje od tisíců do statisíců korun.
Příklad: rooftopy Trane, rozhraní LON
Byla zvolena integrace přes převodník LON/Ethernet firmy Loytec do databáze LNS a přes LNS/OPC server IPLONGATE do vizualizace RcWare Vision. S licencí pro max. 600 proměnných dodávka včetně služeb (zaškolení) nepřesáhla 70 000 Kč (z toho hardware cca. 15 000 Kč, licence cca. 45 000 Kč).
U jednodušších aplikací by se dalo použít levnější řešení bez LNS, například s převodníkem LON/Modbus BabelBuster (hardware asi 12 000 Kč). Pak je ovšem omezen počet proměnných na 50, protože převodník nemá kromě čipu LON další procesor, a proměnné nestandardních typů je třeba přepočítat ve vizualizačním softwaru.
Příklad: VZT s regulací Swegon, rozhraní Modbus TCP
Žádný další hardware nebyl nutný, jednotky byly zaintegrovány do procesní podstanice Domat, která řídí vytápění a další větrací okruhy, pouze pomocí modbusové tabulky poskytnuté dodavatelem zařízení. Driver pro Modbus je součástí dodávky podstanice. Náklady nepřesáhly 5 000 Kč.
U komunikace Modbus RTU / RS485 by bylo třeba doplnit převodník RS485 / RS232 v ceně necelé 4 000 Kč.
Je zřejmé, že při uvádění do provozu je ideální, když si můžeme komunikaci vyzkoušet předem "na stole" v teple kanceláře, bez stresu a rušivých vlivů, které s sebou staveniště přináší. Dodavatelé obvykle regulátor na tyto pokusy ochotně zapůjčí nebo alespoň umožní testy ve vlastním showroomu. Počítejme s časovou rezervou několik dní až týdnů (při vývoji vlastního rozhraní).
Přenášené hodnoty
Především nás zajímají aktuální hodnoty, tedy teploty, tlaky, vlhkosti a stavy. Dále budeme chtít měnit požadované hodnoty, zapínat a vypínat jednotku a nastavovat další binární nebo vícestavové proměnné. Zde asi problém nevznikne nebo se dá řešit snadno (například BACnet server fy. Haier poskytuje vícestavové proměnné v podobě analogových hodnot, nikoli jako typ integer, což by bylo vhodnější).
Horší je to u složitějších datových struktur, jejichž typickým představitelem jsou časové programy. Některé protokoly - jako třeba BACnet - z definice nastavení časových programů umožňují, což ovšem automaticky neznamená, že tento typ objektu je v regulátoru naprogramován. Například regulátory BMR firmy Kieback & Peter podporují v protokolu BACnet pouze objekty Analog Input a Analog Output, tedy časové programy zatím není možné přes tento protokol uvnitř regulátoru měnit. U Modbusu se můžeme setkat s více či méně povedenou tabulkou spínacích časů (např. Regin Corrigo), která je ale do většiny vizualizací integrovatelná jen obtížně, u LONu vzhledem k množství proměnných, která by taková tabulka s sebou nesla, se časové programy obvykle neřeší, resp. v těchto případech se časový plán nastaví v systému MaR a do regulátoru se přenáší jen povel pro vypnutí a zapnutí.
Do jaké úrovně integrovat?
Pro ovládání z vizualizace nebo na dálku (web, vzdálený přístup) vyhovuje integrace přímo do vizualizačního programu. Tato cesta bývá díky větším možnostem PC oproti automatizační stanici jednodušší. Spokojíme se s čtením a nastavováním hodnot, záznamem trendů a přenosem alarmových stavů.
Pokud chceme hodnoty z VZT jednotek využít pro přímé vazby na další procesy, tedy pro sběr požadavků na energie, odpínání od čtvrthodinového maxima, centrálních poklesů, řízení podle přítomnosti, s vazbou na kartové systémy apod., měli bychom integrovat v úrovni automatizační (do podstanic).
Je jasné, že požadované funkce musejí být známy již při specifikaci zařízení, abychom mohli určit, do které úrovně - a tedy do jakého prostředí - se bude integrovat a jestli je tato integrace vůbec možná nebo ekonomická. Při integraci do podstanic jsou pochopitelně všechny integrované hodnoty přístupné i v počítači na řídicí úrovni (stejně jako vlastní proměnné podstanic).
Při vytváření menu nebo grafiky je nutné zpracovat uživatelské rozhraní tak, aby obsluha věděla, v kterém ze zařízení došlo k poruše, a podle toho volala příslušný servis. Často se stává, že prvním cílem telefonátů je dodavatel grafiky, který "má v systému alarm".
Co nás čeká
Trend dodávat technologie i s regulací je čím dál silnější. Souvisí to jistě i s čím dál vyšší inteligencí regulátorů a jejich komunikačními schopnostmi - daleko lépe se za stejnou cenu prodává jednotka s otevřeným systémem, než zařízení s vlastní regulací, do níž není vidět. Profese MaR se pak stává "pouhým" koordinátorem a integrátorem a již tolik neřeší vlastní základní regulační algoritmy a bezpečnostní funkce. Tím pádem se soustředí na obslužné rozhraní směrem k uživateli a na koordinace procesů, ale - protože regulaci již nedodává - může se stát jakýmsi oponentem dodané regulace, což by mohlo vést k jejímu zkvalitnění.
Například ve Slovinsku, jako zemi, kde volně programovatelné systémy hrály již historicky menší roli než třeba v ČR, se dodavatelé MaR stali integrátory standardních zařízení - typicky Carel (VZT, chlazení), Siemens (VZT, topení), Buderus (kotle) - a poskytovateli sjednocujících řešení s webovým a dálkovým přístupem k těmto zařízením přes jednotnou platformu. MaR dále řeší světla ve společných prostorách, odtahy atd. a koordinace všech technologií. Stinnou stránkou jsou pro MaR pochopitelně nižší objemy dodávek včetně periferií, potenciál je zde ale v komunikacích, uživatelském rozhraní a dálkovém přístupu.
Na straně dodavatelů jsou jednoznačně ve výhodě výrobci zařízení se standardní komunikací, která je pokud možno již v základní dodávce. To se týká jak výrobců větších VZT jednotek (Lennox, Systemair, CIC...), tak dodavatelů konvektorů, fan-coilů atd. (např. Jaga). V příštích letech tedy bude nutné, aby i obchodníci získali základní přehled o komunikačních technologiích a byli schopni dotazy protistrany kvalifikovaně zodpovídat nebo přesměrovávat na vlastní tuzemskou i zahraniční technickou podporu.
Today, many air handling units are supplied with integrated control system. Integration of those controls into a building management system may bring along lots of questions in the design and specification phase. If the parties involved are able to exchange relevant information in time, they avoid delays and problems in supplies and commissioning. AHUs and other components with integrated controls are changing the role of the control system suppliers who have to become system integrators. However, the mechanical part suppliers will have to increase their know-how on communicative controls.
