Usługi
Vizualizace a SCADA
Zobrazit stav technologie, upozornit na odchylky a umožnit zásah tam, kde je přípustný.
Řídicí systém rozhoduje o chodu zařízení, ale sám o sobě neposkytuje obsluze žádný pohled na to, co se děje. Tuto úlohu plní vizualizace: zobrazuje stav technologie, upozorňuje na odchylky, uchovává historii a umožňuje zásah tam, kde je zásah přípustný.
Je to vrstva, která je v provozu nejvíc vidět, a její návrh má přímý provozní dopad. Rozhoduje o tom, jak rychle obsluha rozpozná blížící se problém a jak rychle najde jeho příčinu. Proto se způsob zobrazení jednotlivých prvků volí tak, aby byl přehledný a odpovídal standardu, který má zákazník zavedený jinde ve svém provozu. Údržbář, který přijde k zařízení poprvé, se pak orientuje podle toho, co už zná.
HMI a SCADA
Rozlišují se dvě úrovně.
HMI je operátorské rozhraní u konkrétního stroje nebo pracoviště. Bývá to panel umístěný přímo na zařízení, obsluhuje jednu technologickou jednotku a je určen pro toho, kdo u ní fyzicky stojí. Zobrazuje stav pracoviště, umožňuje ruční ovládání a seřizovací režimy.
SCADA je nadřazený systém pro celý provoz nebo jeho ucelenou část. Sbírá data z více řídicích systémů, poskytuje souhrnný pohled, spravuje alarmy a archivuje historii. Bývá provozována na serverech a přistupuje se k ní z operátorských pracovišť, dispečinku a někdy i z kanceláří.
Rozdíl není jen ve velikosti. HMI je součástí stroje a bez něj je stroj obtížně ovladatelný. SCADA je nadstavba: pokud vypadne, technologie zpravidla běží dál, jen na ni nikdo nevidí. Z toho vyplývají odlišné požadavky na jejich dostupnost a zálohování.
Architektura systému
Rozsáhlejší vizualizace se skládá z několika částí, které mohou být na jednom serveru i rozděleny na více strojů.
Komunikační vrstva načítá data z řídicích systémů. Volí se podle toho, co je v daném provozu zavedené, tedy nejčastěji OPC UA, případně nativní ovladač výrobce nebo prostředí dodané spolu s technologií. Princip zůstává ve všech případech stejný: na jedné straně stojí server poskytující data, na druhé klient, který je odebírá. Rozdíly jsou v konfiguraci a v možnostech diagnostiky, nikoli v přístupu k návrhu.
Datová vrstva spravuje proměnné, jejich aktuální hodnoty, jednotky, meze a vazbu na zdroj. U větších systémů jde o desítky tisíc proměnných a rozhoduje způsob jejich uspořádání. Standardizovaná struktura znamená, že stejný typ zařízení má proměnné pojmenované a členěné stejně napříč celým závodem. Kdo se zorientuje na jednom stroji, orientuje se pak i na ostatních, a to platí pro obsluhu, údržbu i pro kohokoli, kdo bude systém později upravovat.
Archivní vrstva ukládá historii hodnot a událostí. Bývá postavena nad relační databází nebo nad specializovaným úložištěm časových řad.
Klientská vrstva jsou operátorská pracoviště. Řešení se liší podle produktu: klasický klient instalovaný na počítač, tenký klient v prohlížeči nebo aplikace na mobilním zařízení.
Rozdělení do vrstev je podstatné pro dostupnost. Výpadek klienta znamená, že jedno pracoviště nevidí. Výpadek datového serveru znamená, že nevidí nikdo a přestává se archivovat.
Sběr dat z řízení
Způsob, jakým vizualizace získává data, ovlivňuje jak zatížení sítě, tak zpoždění zobrazení.
Cyklické dotazování znamená, že se systém v pravidelných intervalech ptá na hodnoty. Je jednoduché, ale generuje stálý provoz i tehdy, kdy se nic nemění, a interval určuje nejhorší možné zpoždění.
Odběr změn znamená, že se systém přihlásí k odběru a hodnota se hlásí až ve chvíli, kdy se změní o víc než stanovenou mez. Tento princip používá OPC UA a u většiny proměnných výrazně snižuje zátěž.
U spojitě se měnících veličin se stanovuje mrtvá zóna, tedy velikost změny, od které se hodnota považuje za novou. Bez ní systém zaznamenává i nepodstatné kolísání a zbytečně se zahlcuje.
Podstatné je také to, co se stane při ztrátě spojení. Dobře navržená vizualizace nezobrazuje poslední známou hodnotu jako aktuální, ale označí ji jako neplatnou. Zobrazená hodnota, o které obsluha neví, že je stará, je nebezpečnější než chybějící údaj.
Archivace a dohledatelnost
Archivace se často chápe jako doplňková funkce, dokud nenastane první situace, kdy je potřeba zpětně doložit, co se dělo.
Archivovat lze libovolnou veličinu, kterou systém sbírá: teploty, tlaky, průtoky, doby operací, stavy zařízení, alarmy i zásahy obsluhy. Skutečná hodnota archivu ale vzniká teprve tehdy, když jsou naměřené hodnoty navázané na konkrétní výrobek a na zakázku. Pak lze i po letech dohledat, za jakých podmínek daný kus vznikl, jaké byly v tu chvíli parametry procesu a zda odpovídaly předepsanému rozmezí.
V praxi je to nejčastěji otázka reklamací a záruk. Přichází-li reklamace na produkt vyrobený před delší dobou, rozhoduje schopnost doložit průběh výroby daného kusu. Bez této vazby lze prokázat pouze to, že linka v daném období fungovala, což pro posouzení konkrétní reklamace zpravidla nestačí.
Z toho také vyplývá, jak hluboko se archivace navrhuje. Rozhodující je délka záruky na výrobek a míra, v jaké je nutné jednotlivé kusy dohledávat. Podle toho se stanoví, které veličiny se ukládají, s jakou podrobností, jak dlouho se uchovávají a jak se párují na zakázky.
Nad archivem stojí trendy, tedy grafické zobrazení průběhu veličin v čase, a sestavy. Prakticky nejcennější je možnost zobrazit několik veličin nad společnou časovou osou spolu s alarmy, protože souvislost mezi příčinou a následkem je pak vidět přímo.
Archiv je zároveň vstupem pro vyhodnocování provozních ukazatelů. Pokud se sbírají doby chodu, prostoje s uvedením důvodu a počty kusů, dá se z nich sestavit ukazatel celkové efektivity zařízení bez potřeby dalšího systému.
Rozsah sbíraných dat
Návrhu sběru dat se vyplatí věnovat pozornost na začátku, protože obě krajní polohy jsou nákladné.
Nedostatečný sběr znamená, že se klíčová informace nikde neukládá. Zjistí se to zpravidla ve chvíli, kdy je potřeba, tedy při reklamaci nebo při hledání příčiny opakované poruchy, a zpětně už ji doplnit nelze.
Přehnaný sběr vede k databázím v řádu terabajtů. Ty je nutné zálohovat, spravovat a udržovat, což přesouvá náklady i práci na podnikové IT a časem zpomaluje i práci se samotnými daty. Přitom velká část takto uložených hodnot nebude nikdy použita.
Volba je tedy návrhové rozhodnutí, ne technická podrobnost. Vychází z toho, k čemu mají data sloužit: pro dohledatelnost výrobku, pro vyhodnocování ukazatelů, pro diagnostiku poruch nebo pro kombinaci těchto účelů.
Alarmy
Alarmová část je z celé vizualizace nejdůležitější a zároveň nejčastěji navržená špatně.
Alarm má jediný smysl: upozornit obsluhu na stav, který vyžaduje její zásah. Z toho plyne pravidlo, které se v praxi porušuje nejčastěji. Pokud na hlášení nemá nikdo jak reagovat, není to alarm, ale událost, a patří do záznamu, nikoli do alarmového seznamu.
Oblast má vlastní standardy. ANSI/ISA-18.2 a mezinárodní IEC 62682 popisují celý životní cyklus správy alarmů a jsou sladěné s evropskou publikací EEMUA 191, která mnohé z používaných měřítek zavedla. Referenčním hodnotám odpovídá průměrně nejvýše jeden alarm na operátora za deset minut při běžném provozu a nejvýše deset alarmů v prvních deseti minutách po závažné poruše. Jako alarmová záplava se označuje stav, kdy se v desetiminutovém intervalu objeví více než deset alarmů, protože při vyšší četnosti už obsluha nedokáže jednotlivá hlášení smysluplně zpracovat.
Většina systémů, které nikdy neprošly revizí alarmů, tyto hodnoty výrazně překračuje. Důsledek není jen nepohodlí: pokud obsluha vidí trvale desítky hlášení, přestane je číst a skutečně důležitý alarm zanikne mezi ostatními.
Prakticky se to řeší několika opatřeními. Prioritizací, tedy rozlišením hlášení podle závažnosti a podle toho, jak rychle je nutné jednat. Potlačením závislých hlášení, protože jedna příčina typicky vyvolá řetěz následků a obsluze stačí zobrazit tu příčinu. Zpožděním a hysterezí u veličin kolísajících kolem meze. A revizí alarmů, tedy procházením seznamu položku po položce s otázkou, jaká je očekávaná reakce obsluhy. Hlášení, u kterých odpověď neexistuje, se z alarmů vyřadí.
Ke každému alarmu patří i informace, se kterou se dá pracovat. Samotný text o poruše zařízení neříká nic. Užitečné hlášení obsahuje místo, povahu problému a odkaz na obrazovku, kde je vidět souvislost.
Návrh obrazovek
Vizualizace není ilustrace technologie. Jejím účelem je, aby obsluha co nejrychleji rozpoznala stav a našla příčinu odchylky.
Doporučení pro návrh operátorských rozhraní shrnuje standard ISA-101.
Barva nese význam, nikoli dekoraci. Pokud je obrazovka barevná celá, nemá čím upozornit. Osvědčený přístup pracuje s tlumeným, převážně šedým podkladem, na kterém výrazná barva označuje pouze odchylku od normálního stavu.
Hierarchie obrazovek. Přehledová úroveň ukazuje stav celého provozu a slouží k rozpoznání, že něco není v pořádku. Nižší úrovně postupně zpřesňují až k jednotlivému pracovišti. Obsluha se tak dostane k detailu cestou, která odpovídá tomu, jak problém hledá.
Konzistence napříč systémem. Stejný prvek má vypadat a chovat se stejně na všech obrazovkách. Nekonzistence stojí čas v okamžiku, kdy ho obsluha nemá.
Přístupová práva a záznam zásahů
Vizualizace umožňuje zasahovat do chodu technologie, a proto potřebuje rozlišovat, kdo co smí.
Obvyklé členění rozlišuje obsluhu, seřizovače, údržbu a správce systému. Rozsah oprávnění se přitom neodvíjí od funkce ve firmě, ale od toho, jaké důsledky může daný úkon mít.
Součástí je záznam zásahů, tedy kdo, kdy a jakou hodnotu změnil. U regulovaných provozů jde o požadavek, jinde o praktickou pomůcku: bez záznamu nelze po změně chování zařízení zjistit, zda šlo o poruchu, nebo o zásah.
Samostatnou otázkou je zabezpečení systému jako takového, tedy oddělení provozní sítě, správa účtů a ochrana serverů. Rámec pro tuto oblast dává řada norem IEC 62443.
Dostupnost a redundance
U vizualizace, na které závisí řízení provozu, se řeší, co se stane při výpadku serveru.
Redundance serverů znamená dvojici, kde záložní přebírá činnost při výpadku hlavního. Podstatné je chování archivu: kvalitní řešení po obnově doplní data, která během přepnutí chyběla.
Redundance komunikačních cest zajistí, že přerušení jedné trasy neznamená ztrátu spojení s řízením.
Nezávislost na klientech je samozřejmostí u serverových architektur, ale ne u řešení, kde vizualizace běží přímo na operátorské stanici.
Rozsah redundance je ekonomické rozhodnutí. Odvíjí se od toho, zda technologie při výpadku vizualizace může pokračovat, a od ceny doby, po kterou na ni nikdo nevidí.
Životní cyklus a migrace
Vizualizační systém má kratší životnost než technologie i než řídicí systém. Důvodem je vazba na operační systém a na databázi: skončí podpora verze, na které vizualizace běží, a tím vzniká nutnost přechodu bez ohledu na to, že samotná aplikace funguje.
Migrace vizualizace je proto pravidelně se opakující úloha. Zahrnuje převod obrazovek, proměnných, alarmů a přístupových práv a ověření komunikace s řídicími systémy, které zůstávají beze změny. Historická data se přenášejí v rozsahu, který je na produkčním systému běžně udržován, tedy zpravidla v horizontu jednotek let, protože starší archivy se uchovávají odděleně.
Migrace je zároveň přirozenou příležitostí k revizi alarmů a k úpravě návrhu obrazovek. Převzít stávající stav beze změny je rychlejší, ale znamená to přenést do nového systému i všechny jeho nedostatky na další období.
Aktualizace a migrace vizualizací jsou zpravidla součástí dlouhodobé péče o systém, nikoli samostatnou akcí. Blíže je popsána v kapitole o podpoře provozu.
Retrofit vizualizací
Ve starších provozech se dosud vyskytují ovládací panely, které pocházejí z doby uvedení technologie do provozu. Bývají to tlačítková pracoviště s kontrolkami, panely s jednořádkovým displejem nebo textové terminály komunikující s řízením po starších sériových sběrnicích.
Tato řešení zpravidla stále fungují, ale jejich životnost je překročena a projevuje se to mechanicky: opotřebená tlačítka, nečitelné popisky, praskající kryty, nedostupné náhradní díly. Zároveň neposkytují diagnostiku, takže obsluha vidí, že zařízení stojí, ale ne proč.
Výměna ovládání není jen náhrada panelu novým. Zahrnuje několik kroků, které je nutné udělat v pořadí.
Zjištění, jak stávající ovládání komunikuje. Použitá sběrnice, protokol a rozsah přenášených dat. U starších řešení k tomu často neexistuje dokumentace a je nutné to zjistit měřením a rozborem programu řídicího systému.
Rozbor stávající aplikace. Co panel skutečně dělá, které funkce jsou používané, které zůstaly nevyužité a jaké ovládací zásahy obsluha běžně provádí. Toto zjištění bývá překvapivé: část funkcí se nepoužívá roky a část zvyklostí obsluhy není nikde popsána.
Návrh náhrady a způsobu připojení. Buď se nový panel připojí ke stávající sběrnici, pokud ji podporuje, nebo se doplní převodník, nebo se úprava provede na straně řídicího systému. Volba ovlivňuje rozsah zásahu do programu a tím i dobu odstávky.
Zachování bezpečnostní části. Ovládací prvky s bezpečnostní funkcí, typicky tlačítka nouzového zastavení a potvrzovací prvky, se řeší samostatně a nelze je jednoduše přenést do dotykového rozhraní. Součástí retrofitu je proto vyhodnocení, zda se zásah dotýká bezpečnostních funkcí, a případné doplnění dokumentace a validace.
Převedení do nového rozhraní. Nové ovládání se navrhuje podle standardu, který zákazník používá na ostatních zařízeních, aby se obsluha nemusela učit další způsob práce.
Rozsah retrofitu se volí podle potřeby a podle možností odstávky. Provádí se buď jako úplná výměna ovládání celého zařízení, nebo postupně po jednotlivých pracovištích, kdy nové a původní panely dočasně fungují vedle sebe. Druhá cesta je pomalejší, ale nevyžaduje dlouhou souvislou odstávku, a u provozů, které nelze zastavit, bývá jediná průchodná.
Platformy
Pracujeme s vizualizačními a SCADA systémy běžně nasazovanými v evropském průmyslu, včetně prostředí dodávaných jako součást konkrétních technologických celků. Nejčastěji jde o Cimplicity, Ignition, řadu SIMATIC WinCC a DXQ.