Efektivní práce s daty na dispečinku
Problémem monitoringu dnes není získat data, ale rychle je vyhodnotit a provést příslušný zásah v technologii. Kde se nachází rozhraní mezi tím, co je lepší nechat na systému a tím, co by měla dělat obsluha?
© Fotolia.com
Úrovně řídicího systému
Řídicí systém s nadstavbami můžeme rozdělit do několika úrovní:
K běžné obsluze systému dochází na třech nejvyšších úrovních. Na úrovni PLC (automatizačních stanic a periferií) se provádějí základní operace pomocí místního ovládání přes displej, dotykovou obrazovku nebo panel na rozvaděči. Jde o potvrzování alarmů, protože při něm je dobré být u technologie a kontrolovat ji i fyzicky, dále o nouzové nebo servisní manuální zásahy apod. Obsluha reaguje na okamžité provozní stavy.
Obr. Čtyři úrovně řídicího systému
Vizualizace (SCADA) již poskytuje komplexnější pohled, důležité jsou zejména historické průběhy hodnot v čase, záznamy o událostech v systému a historie alarmů. To jsou data, která buď nejsou v automatizačních stanicích dostupná vůbec, nebo je práce s nimi nepohodlná. V historických datech může technik například odhalit kmitající regulační smyčku, dohledat příčiny výpadků technologií, či najít potenciál ke změně parametrů regulace a tím k úsporám energie. Systém SCADA nicméně stále slouží především pro operativu – udržení technologií v provozu.
Nad vizualizací stojí systém pro energetický management. Ten už primárně nepracuje s aktuálními daty. Slouží k dlouhodobému vyhodnocování, porovnávání budov mezi sebou a případně i k dalším úlohám, neboť může například obsahovat servisní moduly včetně tiketovacího systému či být napojen na další systémy pro řízení podniku. Obvykle ho používá energetik, tedy pracovník, který nemá na starosti operativu (běžný provoz), ale déledobou koncepci provozu, nákup energií a jejich hospodárné využívání.
Podívejme se nyní na několik příkladů, které ukazují, jak se s těmito třemi úrovněmi obsluhy vyrovnali někteří typičtí zákazníci.
Velké datové centrum, Praha
Datové centrum, které spravuje stovky serverů, zajišťuje jejich napájení, klimatizaci a bezpečnost. Celý řídicí systém vznikal postupně, zpočátku byly instalovány jen komunikativní měřiče a vstupní karty pro hlídání přítomnosti napětí na napájecích okruzích. Obsluha měla k dispozici webové rozhraní s aktuálními hodnotami, což pro operativní dohled stačilo. S řízením klimatizace přibyla nutnost vizualizace s historickými hodnotami, tedy úloha typická pro systém SCADA. Zákazník ale vyžadoval webový přístup přímo do podstanic. Paralelně s tím vznikl systém pro energetický management, spojený se správou zákazníků (CRM). Ten má několik základních funkcí:
- poskytuje výpis zákazníků, kterých by se mohla dotknout porucha či plánovaná odstávka některého ze zařízení nebo napájecích okruhů
- shromažďuje historická data pro rozúčtování nákladů na energie
- umožňuje ruční či automatické zakládání alarmových ticketů, přeposílání na servisní organizace (subdodavatele) a kontrolu jejich stavu
- automaticky generované tickety slouží také pro plánování revizí a pravidelných prohlídek.
Systém dále poskytuje data pro helpdesk, aby technici ve službě kdykoli viděli aktuální situaci a stavy technologií. To by ovšem již byla úloha pro vizualizaci (SCADA); aktuální hodnoty byly do systému ale přivedeny jako vložené webové stránky z web serverů v jednotlivých PLC. Na přechod na plnohodnotný webový SCADA systém došlo až v průběhu několika let.
Zákazník zde zpočátku trval na tom, že systém SCADA nepotřebuje: pro aktuální hodnoty (hlídání poruch) mu stačí webová rozhraní a systém CRM s tím souvisí jen málo. Tento přístup měl svou logiku: vedení mělo zkušenost z předchozích období, kdy se zadání pro všeobjímající systém pilovalo tak dlouho, až z realizace sešlo. Klient proto chtěl okamžitou funkčnost, aby mohl datacentrum provozovat. Díky modularitě řídicího systému bylo možné vizualizaci posléze doplnit, aniž by většina práce z předchozích etap přišla nazmar. Data z CRM jsou použita i pro dlouhodobé vyhodnocování energetických parametrů, systém EMS sám o sobě není instalován.
Velké datové centrum, Morava
Programovatelné podstanice opět sbírají data z elektroměrů, čidel, pomocných kontaktů jističů a dalších periferií. V tuto chvíli jsou pro obsluhu hodnoty dostupné jen z webových stránek v PLC, byla nabídnuta instalace systému SCADA. Zákazník zvažuje implementaci vlastního systému, do něhož by integroval online data z monitorovacích podstanic. Vlastní CRM systém by rovněž řešil ukládání historie a další funkce SCADA a nejspíše i EMS.
Toto řešení by znamenalo, že systém může být maximálně přizpůsoben požadavkům: zákazník si ho vyvíjí sám. Může stanovit priority při vývoji, rozšiřovat systém jen pokud má volnou vývojovou kapacitu, rozhodovat o implementovaných funkcích. Na druhou stranu, pokud má vzniknout profesionální řešení, musí řešit práci se zdrojovými kódy, verzování, zálohování, dokumentaci atd. Je vždy nutné zvážit, jestli se vývoj vlastního systému vyplatí a jestli nebude vhodnější se držet svého core businessu. Vlastní vývoj je zcela určitě k diskuzi v případě, že jeden subjekt spravuje více instalací, jako je tomu například u provozovatelů FVE nebo velkých poskytovatelů datových služeb. Vždy ale půjde o softwarovou nadstavbu; není reálné, že by se vyplatil vývoj i hardwarových komponent (PLC, I/O moduly, senzory, měřiče atd.).
Řetězec supermarketů, ČR
Významný řetězec supermarketů, provozující pod svou značkou přes 250 prodejen. Firma během svého působení na českém trhu získala jeden z konkurenčních řetězců, čímž skokově zvýšila počet poboček. V průběhu posledních asi 10 let postupně své prodejny rekonstruuje. Při tom sjednocuje řídicí systémy tak, aby bylo možné porovnávat energetické parametry poboček mezi sebou (benchmarking) a vyhodnocovat prodejny, v nichž by se vyplatila rekonstrukce technologií nebo jiné opatření pro úsporu energie.
Díky vlastnímu intranetu, v jehož rámci je oddělená technologická síť pro systém řízení budov, komerční chlazení a zabezpečovací systém, bylo možné vybudovat centrální stanici SCADA. Pro práci na ní je na plný úvazek určena jedna pracovnice, která průběžně kontroluje alarmy, funkce čidel, diferenční tlaky na vzduchotechnických jednotkách, tlaky topné vody atd. Z historických grafů lze díky provozní zkušenosti poměrně přesně určit příčiny poruch nebo dokonce preventivně zasahovat dříve, než se porucha projeví (např. dlouhodobý pokles tlaku vody s periodickým doplňováním může znamenat únik topné vody ze systému). Pracovnice dále řeší požadavky z helpdesku, jako je nastavení provozních hodin technologií, časy spínání osvětlení podle provozní doby atd. Vedoucí prodejen si sami přes helpdesk řeší ostatní provozní celky, jako je sanita, odpadové hospodářství apod.
Toto personální zajištění dává větší smysl než zaškolování vedoucích prodejen na jednotlivých pobočkách. Ti mají řadu jiných starostí, nedisponují zkušenostmi z více poboček a v případě volání externí servisní firmy nejsou schopni diagnostikovat závadu tak přesně, jako obsluha centrály.
Energetický management včetně sběru dat z měřičů je v tuto chvíli zajišťován samostatným systémem zahraničního dodavatele, který má na řetězec historické vazby.
Řetězec diskontních prodejen, ČR
Podobná situace jako v předchozím případě, řetězec spravuje asi 180 prodejen po celé ČR. U stanice SCADA ovšem nesedí trvale obsluha, zákazník žádá přenos alarmových dat do systému pro energetický management. Úrovně PLC a SCADA jsou tak využívány v podstatě pro sběr dat a správu alarmů. Vlastní vizualizace SCADA je používána jen pro nastavování požadovaných hodnot a časových programů, pobočky nejsou pravidelně a systematicky sledovány.
Data o spotřebách energie jsou vyhodnocována – včetně benchmarkingu – zatím ručně pomocí tabulek v Excelu, firma je nicméně certifikována podle ISO 50001, Systémy managementu hospodaření s energií. (To jen ilustruje, že energetický management lze realizovat i s jednoduchými nástroji, pokud jsou procesy důkladně popsány a dodržovány.) V plánu je zavedení tiketovacího systému. Zatím je používán ticketing vlastní, bez propojení se subdodavateli. Několik poboček bylo implementováno do demoverze systému EMS a po vyhodnocení zkušebního provozu se zákazník rozhodne, zda bude chtít připojit i ostatní prodejny.
Provozovatel sítě rychlého občerstvení
Významná zahraniční firma, provozující čtyři řetězce rychlého občerstvení s celkem více než 160 restauracemi v ČR. Pro místní ovládání na automatizační úrovni v provozovně je použit pultík s LCD displejem nebo dotyková obrazovka, systém SCADA je nasazen na centrále v podobě dashboardu s přehledem hodnot jednotlivých restaurací a aktivními alarmy. V tuto chvíli není na řešení operativních závad vyhrazen žádný pracovník, nicméně počítá se s jedním technikem, který by měl – podobně jako u supermarketů v jednom z předchozích příkladů – centrálně řešit provozní závady.
Obr. Mapa s aktivními alarmy ve vizualizaci
Pro měření spotřeb jsou instalovány patní měřiče vody, plynu a elektrické energie, elektřina je dále měřena podružnými měřiči pro jednotlivé technologie – osvětlení, klimatizace, chlazení potravin, kuchyňské spotřebiče atd. Tyto náměry se ukládají v databázi systému pro energetický management. Vedení firmy má silnou snahu snižovat náklady na energie a k tomu je sběr hodnot a podrobný benchmarking prvním krokem. S EMS portálem pracuje energetik, který byl dříve odkázán na ruční sběr dat a vyhodnocování v tabulkovém procesoru.
Obr. Přehled (dashboard) s daty z poboček
Manuálně nebo automaticky?
Některé činnosti, které provádí obsluha i energetik, jsou rutinní. Je ale dobré je nechat na systému, i když by se daly algoritmizovat?
Typickou úlohou je zahájení a ukončení topné sezóny. Dodavatel tepla dodržuje algoritmus podle vyhlášky MPO č. 194/2007 Sb., ale v jednotlivých objektech mohou být vlivem místních zátěží, orientace budov či provozní situace podmínky programově upraveny v místní ekvitermní regulaci. V přechodném období se tak dá oproti standardnímu algoritmu ušetřit i několik hodin denně, během nichž jsou topné větve zcela odstaveny.
Při monitoringu se nejčastěji setkáváme s požadavky na jednoduchá pravidla pro hlídání, zda teploty či další veličiny nevybočují z přípustných mezí. V tom případě je nutné správně určit časové a toleranční okno, v němž bude chyba ignorována, aby nedocházelo k falešným alarmům. Hloubavý uživatel snadno přijde na další podmínky a vazby, jejichž kombinace by rád hlídal. Do jisté míry to může usnadnit přehled.
Čím více je ale celkové „zdraví“ technologií vyhodnocováno automaticky, tím více se obsluha na algoritmy spoléhá a přestává uvažovat analyticky. V budoucích letech očekáváme s nastupujícím rozvojem tzv. umělé inteligence posilování tohoto trendu. Bohužel, každý program je jen tak dobrý, jak dobře byl naprogramován, a zejména jaké zadání měl programátor. Kritický pohled technika, který je s budovou důvěrně obeznámen, proto bude ještě dlouho nutnou podmínkou efektivní správy objektu.
Výběr systému
Ze zkušeností zákazníků vyplývá, že je velmi vhodné rozdělovat obsluhu na
- operativní složku (má za úkol udržet zařízení v chodu při dodržení požadovaných parametrů, jako jsou teploty, vlhkosti, úrovně osvětlení apod.) a
- dlouhodobý (nákladový) management, který zajišťuje energeticky efektivní provoz, ale i optimalizaci nákupu energií či dalších služeb, jako je servis, revize atd.
Zároveň se ale ukazuje, že vizualizační nebo energetický systém by měl být budován s ohledem na personální obsazení firmy tak, aby sloužil lidem a ne lidé jemu. Proto by dodavatel měl vždy nejprve zjistit aktuální i plánované procesy a jejich personální zajištění a na základě těchto informací teprve plánovat nasazení webové vizualizace, místního systému SCADA, EMS, či případně rozhraní do existujících nebo budoucích systémů zákazníka. Je jasné, že každý dodavatel nabízí nějaké více či méně konfigurovatelné řešení a pokud možno by ho chtěl upravovat co nejméně. Zdánlivě banální úpravy mohou pak stát statisíce korun nebo mohou být v rámci systému nerealizovatelné. Jde zejména o sběry a směrování alarmů, podmíněné hlášení nestandardních stavů, exporty dat pro cizí systémy atd. Ideální postup je tento:
- vyslechnout zákazníka, který popíše aktuální stav a své požadavky do budoucna
- zkontaktovat ho se zákazníky, u nichž byl již systém realizován, a nechat ho si vyměnit zkušenosti s obsluhou, která se systémem (nebo i jeho starší verzí) již nějakou dobu pracuje
- nabídnout co nejvýhodnější řešení postavené na standardních prvcích sortimentu, případně s adaptacemi, u nichž lze dobře odhadnout časovou a finanční náročnost
- v dalších kolech jednání využít zkušeností z podobných projektů a seznámit zákazníka s kritickými body a riziky
- po vzájemné dohodě podrobně sepsat zadání (specifikaci) a nechat si ho odsouhlasit zákazníkem.
Často se stává, že zákazník vypisuje výběrové řízení a rozhodne se sestavit zadání sám. Tím riskuje, že žádný z dodavatelů nebude schopen vše stoprocentně splnit a výběrové řízení bude zrušeno, nebo že dodavatelé formálně odsouhlasí požadovanou funkčnost, ale ve skutečnosti bude systém poněkud odlišný od původních představ zadavatele. Jako řešení se ukázalo vybrat jednoho z potenciálních dodavatelů, který se pak výběrového řízení nezúčastní, a zapojit ho jako placeného konzultanta. Konzultant tak může naplno zúročit své zkušenosti při tvorbě „realizovatelného“ zadání a navíc jako oponent na straně zákazníka bude silným protihráčem svým obvyklým konkurentům.
Počítejme s tím, že stvořit konečnou verzi zadání zabere minimálně šest měsíců, možná i déle, jsou-li do rozhodovacího procesu zapojeny vyšší manažerské úrovně (schvalování „na představenstvu“ apod.). Nezřídka se stává, že vztah s dodavatelem je delší než doba funkčního působení odpovědných osob zákazníka. Pak může dojít ke změně požadavků při tvorbě zadání nebo dokonce ke změně zadání během realizace projektu, což je už obhajitelný důvod k vícepracem – pokud jsou ovšem vůbec technicky možné.
Žalostná situace nastává v případech, kdy developer nebo realizační oddělení firmy staví budovu a po dokončení ji předává (jiné) správcovské firmě nebo provoznímu oddělení. V známé matici „moje peníze, cizí peníze; stavím pro sebe, stavím pro jiného“ jde o kombinaci, kde se zadavatel snaží srazit investiční náklady i navzdory hrubému dopadu na technické řešení. Začátkem r. 2019 jsme například byli postaveni před projekt, v němž bylo navrženo kolem stovky komunikativních regulátorů fancoilů, které ovšem již nebyly propojeny komunikační sběrnicí – v půlmiliardovém rozpočtu nezbylo 200 000 Kč na kabeláž. Toto srážení nákladů dramaticky snižuje užitnou hodnotu budovy a nesmírně komplikuje provoz a údržbu, například týdenní programy by bylo nutné nastavovat ručně z každé kanceláře, jakákoli závada by musela být kontrolována na místě bez možnosti dálkové diagnostiky, nebyly by k dispozici historická data, nebylo by možné nastavovat centrální časové výjimky (svátky) atd. Pak je sice možné měřit spotřeby energií a vyhodnocovat základní klíčové indikátory (KPI), ale těžko již budeme hledat konkrétní příčiny neblahých stavů, jako například chybně nastavené časové programy, ventily otevřené na ruku (= zbytečné přetápění) atd. Naštěstí se ještě včas podařilo instalaci sběrnice prosadit a její výhody se projevily již při uvádění budovy do provozu – postupně obsazované kanceláře, do nichž byl v pozdější fázi velmi komplikovaný přístup, bylo možné zaregulovávat na dálku.
Závěrem
Návrh a výběr dispečinku by měl tedy vždy vycházet z toho, jak a kým bude celý řídicí systém obsluhován. Dodatečné přizpůsobování požadavkům uživatele bývá drahé a pomalé. Ideální tedy je, pokud se podaří do procesu specifikace a výběru zapojit i konečného uživatele, otázkou zůstává, je-li tento uživatel v době vzniku systému již znám.
Domat Control System s.r.o. patří k evropské špičce dodavatelů řídicích systémů a regulací pro inteligentní budovy, průmysl a energetiku. Cílem této ryze české společnosti je vyvíjet, vyrábět a dodávat řídící systémy v mezinárodním měřítku.
