Článek ve formátu PDF je možné stáhnout
zde.
Společnost I & C Energo a. s. došla na základě zkušeností, které nashromáždila v oblasti diagnostiky a optimalizace provozu technologických zařízení v energetice, ke konceptu jednotné vrstvové struktury optimalizačního systému. V článku je tento koncept stručně představen a jsou v něm uvedeny konkrétní realizované produkty, v nichž je úspěšně použit.
Při realizaci úloh hodnocení výkonnosti, diagnostiky a optimalizace technologického procesu je třeba vedle zavedení optimalizačních nástrojů také řešit napojení na existující technologické řídicí a informační systémy, přístupy do archivních stanic a rovněž problémy a požadavky související s prezentací výstupů a výsledků – vizualizací získaných údajů. Protože většina úkolů tohoto typu je v praxi realizována víceméně podobným způsobem, nabízí se otázka, jak navrhnout a optimalizovat softwarovou strukturu, aby výsledný optimalizační systém byl efektivní z hlediska času potřebného na jeho vývoj a uvedení do provozu a také spolehlivosti a flexibility při jeho rozšiřování a dalším vývoji. Jde o problematiku aktuální jak v energetice, tak obecně všude, kde je třeba optimalizovat složité spojité technologické procesy.
Požadavky na optimalizační softwarový systém
Lze říci, že naprostá většina úloh zmíněného typu je založena na zpracování dat v cyklu:
-
načtení dat z řídicích a informačních systémů sledovaného provozu,
-
předzpracování, kontrola a filtrace vstupních dat,
-
vlastní zpracování dat diagnostickým a optimalizačním nástrojem,
-
následné zpracování (tzv. postzpracování), filtrace výsledků,
-
předání dat řídicím a informačních systémům (optimalizované žádané hodnoty),
-
archivace výsledků,
-
prezentace výsledků, vizualizace.
Je zřejmé, že při realizaci uvedeného cyklu zpracování dat se vyskytují komunikační rozhraní (místa pro předávání/příjem dat), jejichž provedení závisí na použité technice (především na rozhraních řídicích a informačních systémů), a místa, kde tato závislost neexistuje, a formát dat tudíž může být neměnný a předem daný (typicky při výměně dat mezi vnitřními moduly systému). Dobu potřebnou k připojení diagnostického a optimalizačního nástroje k libovolnému řídicímu a informačnímu systému lze významně minimalizovat zavedením a využíváním standardních průmyslových komunikačních rozhraní. Čím více typů standardních rozhraní komunikační vrstva nástroje či systému podporuje, tím větší je pravděpodobnost, že daný řídicí a informační systém nabídne vhodné rozhraní a spolupráce s tímto systémem bude pouze otázkou konfigurace existujících prostředků, a nikoliv drahého vývoje prostředků nových.
Požadavky na vnitřní rozhraní mezi softwarovými moduly optimalizačního systému vyplývají z množství, typů a frekvence přenášených dat a lze je většinou stanovit před konkrétném použitím systému. Přitom zpravidla jde o rozhraní lokální, v rámci jednoho systému (fyzicky na jednom hardwaru a pod jedním operačním systému), a tedy parametry jako rychlost a objem dat nejsou zdaleka tak omezující jako u přenosů na dálku, popř. přenosy mezi různými systémy.
Zajistit potřebné vlastnosti vnitřních rozhraní odpovídající požadavkům lze tedy stanovením (a bezpodmínečným uplatňováním) základních obecných požadavků na vlastnosti struktury systému a samotných funkčních modulů. Z hlediska návrhu struktury samotné je třeba klást důraz na důsledné uplatnění vrstvového modelu. Ten již svou podstatou odstiňuje vyšší vrstvy struktury od způsobu realizace vrstev nižších. Přitom jedna konkrétní vrstva je zpravidla realizována v podobě jednoho nebo několika modulů propojených horizontálně s vertikální vazbou na vrstvu nižší a vrstvu vyšší.
Co se týče vlastností modulů ve vrstvách, platí pro ně všeobecné zásady těchto typů:
-
nezávislost a samostatnost v rámci realizované funkce,
-
možnost propojení uvnitř celého softwarového systému (nebo pouze jedné vrstvy) při použití jednotných rozhraní v rámci dané funkce (skupiny funkcí – např. výpočetní moduly, komunikační moduly, archivační moduly),
-
jednotné diagnostické rozhraní,
-
snadné konfigurování (nejlépe při použití jednotného společného konfiguračního nástroje),
-
komunikační a přenosové moduly musí přednostně využívat a dodržovat zavedené průmyslové standardy a protokoly.
Při realizaci konkrétní diagnostické a optimalizační úlohy spolu v určité fázi vývoje spolupracují programátor a specialista technolog. Jde především o konfigurování již sestaveného aplikačního softwaru určeného k použití nad daným technologickým procesem (zařízením). Obecně je při konfigurování třeba použít jak vizuální, tak nevizuální prostředky.
Jako příklad lze uvést tvorbu matematického modelu popisujícího technologický proces. Model vzniká zpravidla graficky, spojením předem definovaných komponent. Chování těchto komponent je však třeba konkretizovat. Přitom nemusí stačit pouze výběr konstant a podmínek, ale je třeba sáhnout ke složitějšímu popisu chování prostřednictvím algoritmu. Na specifikaci toho algoritmu se největší měrou podílí právě specialista technolog. Zde docházíme k požadavku na existenci technologického jazyka přizpůsobeného způsobu práce specialisty technologa. Je důležité, aby tato specifikace chování byla součástí konfigurace, nikoliv samotného výkonného kódu daného modulu.
Od struktury optimalizačního systému je dále požadováno, aby umožňovala konzistentní přechod z režimu vývoje a ladění do režimu provozu on-line. Tyto požadavky zohledňuje struktura znázorněná na obr. 1, která současně vyhovuje doporučení Open System Architecture for Condition Based Maintenance (OSA – CBM).
Popis vrstev ve struktuře
Vrstvy I až VI v softwarové struktuře optimalizačního systému podle obr. 1 plní tyto charakteristické funkce:
-
sběr údajů (data acquisition): čtení dat z řídicích a informačních systémů sledovaného provozu (vstupní data optimalizačního systému) a zápis výstupních dat do těchto systémů,
-
předzpracování (data manipulation): základní filtrace a třídění vstupních dat,
-
určení stavu (state detection): určení skutečného stavu zařízení1),
-
diagnostika (health assessment): vyhodnocení diagnostických údajů1),
-
predikce (prognostic assessment): odhad vývoje stavu zařízení na základě současného stavu a předpokládaného budoucího zatížení (způsobu provozování),
-
poradenství (advisory generation): poskytování rad pro údržbu a provoz s cílem optimalizovat technologický proces a životní cyklus zařízení.
Vizualizace
Zvláštní pozornost si zaslouží prezentace dat jejich vizualizací (viz podsystém Vizualizace na obr. 1 vpravo nahoře). Opět jde o vrstvovou strukturu, tvořenou softwarovými moduly typu silný klient, tenký (webový) klient a modul pro mobilní zobrazení. Použité uspořádání vyhovuje veškerým požadavkům v situacích, kdy jsou od provozní (technologické) sítě požadovány přenosy poměrně velkých objemů dat, velká rychlost odezvy a vysoká úroveň spolehlivosti.
Přes firewall postupují data z optimalizačního systému do sítě obecnějšího charakteru (vnitropodniková administrativní sít, popř. internet). Vybrané údaje, jejich časové průběhy a trendy, včetně grafických zobrazení, lze prezentovat i prostřednictvím mobilních zobrazovacích prostředků. V podsystému Vizualizace je rovněž řešeno zabezpečení, a to jak dat proti výpadkům spojení, tak systému proti neoprávněnému přístupu. Uživatele lze rozdělit do skupin podle požadovaného oprávnění a tato oprávnění v širokých mezích konfigurovat.
Příklady využití
Popsaná jednotná softwarová základna je společností I & C Energo v současnosti využita v těchto jejích optimalizačních či diagnostických produktech:
-
PowerOPTI pro hodnocení, diagnostiku, optimalizaci procesu (viz také článek Diagnostika a optimalizace tepelného cyklu parní turbíny v tomto časopise na
str. 24),
-
CombustionOPTI pro optimalizaci spalování v kotlích na pevná paliva,
-
Tramon pro diagnostiku výkonových olejových transformátorů.
Ing. Ladislav Havlát,
Ing. Vladimír Horký, Ph.D.,
Divize Optimalizace energetických výroben,
Obr. 1. Vrstvová struktura univerzální softwarové základny pro optimalizaci technologických procesů
1) Na základě pokročilých metod zpracování dat, např. metodou vyrovnání dat (
data reconciliation), simulace procesu (
process simulation) apod.