Kdo se bojí řídit přímo v provozu?

Peter G. Berrie, Eugenio F. da Silva Neto

Důležitou vlastností komunikační sběrnice Foundation Fieldbus je možnost umístit softwarové funkční bloky provádějící řídicí algoritmus přímo do provozních přístrojů, tedy použít tzv. řízení v provozu. Co to však znamená v praxi? Článek pojednává o výhodách a omezeních vlastních tomuto způsobu řízení technologických procesů a uvádí příklady z aktuálních instalací.

1. Úvod

Kdo se bojí řízení v provozu? Známkou toho, jak daleko pokročila v posledních deseti letech řídicí technika, je, že většina řídicích techniků se buď přímo vysloví proti, nebo alespoň bude mít k tomuto způsobu řízení výhrady. Že jde o rozšířený názor, potvrzuje mnoho prodejců: „Když prodáváme Foundation Fieldbus, není řízení v provozu tím, o čem by se zejména vedla řeč – ve skutečnosti se o něm pokud možno vůbec nezmiňujeme.„

Jednou z příčin tohoto skepticismu může být, že mnozí z první vlny uživatelů průmyslových číslicových komunikačních sběrnic přecházejí na tuto techniku z prostředí distribuovaných řídicích systémů (DCS) nebo programovatelných automatů (PLC), založeného na analogových přístrojích s řídicí jednotkou tradičně umístěnou mimo vlastní prostředí provozu. Mnozí již zpravidla sledují a obsluhují řízený proces z ústředního velínu. A kteří ne, ti se pravděpodobně rozhodli pro komunikaci prostřednictvím sběrnice právě proto, aby takový scénář realizovali. Jedním z přínosů komunikačních sběrnic je mohutnější a plynulejší tok dat: takže kde jinde je potom lépe data shromažďovat, porovnávat, hodnotit, jednat podle nich a ukládat je než v centrálním místě. Tedy tam, kde se spolu setkávají inteligence člověka a stroje.

Protože sledování, obsluha a řízení spojitého technologického procesu (dále jen proces – pozn. red.) jsou v současné době vnímány jako navzájem neoddělitelné části jedné souhrnné aktivity a často se jim věnují titíž lidé, zdá se být návrh na přenesení řízení přímo do provozu v rozporu s filozofií komunikačních sběrnic. To je ale omyl. Řízení v provozu nabízí větší pružnost a efektivnější využití nákladů v etapě projektování automatizačního systému i – je-li správně použito – jeho bezpečnější a optimu bližší provoz.

2. Vzpomínka na budoucnost

V počátcích automatizace řízení procesů byla veškerá řídicí technika distribuovaná a nacházela se přímo ve výrobních provozech (obr. 1). Každá řídicí smyčka měla svůj vlastní pneumatický (později analogový elektrický) regulátor a byla fyzicky patrná: snímač, pneumatické potrubí do regulátoru a poté z regulátoru k regulačnímu ventilu apod. Technik – přístrojář, operátor i „inženýr„ zodpovědný za řízení procesu (control engineer, řídicí technik) – to vše tehdy obvykle byla jedna a táž osoba.

Obr. 1. Vývoj distribuovaných řídicích systémů (DCS)

Když po roce 1960 začaly administrativní útvary používat sálové počítače, začali vbrzku spřádat své představy o využití této techniky při řízení svých provozů i řídicí technici. Očekávání byla velká, a aby se úroveň řízení procesů pozdvihla co nejvíce, bylo třeba do počítače vkládat všechny možné řídicí algoritmy. Přes enormní investice ze strany dodavatelů i zákazníků však byla řešení se sálovými „centrálními„ řídicími počítači předem odsouzena k neúspěchu. Na první pohled byla příčinou nedostatečná spolehlivost: střední doba do poruchy (MTBF) tehdejších sálových počítačů zdaleka neodpovídala požadavkům kladeným na řízení procesů. Ne tak zřejmá, ale vcelku možná významnější potíž tkvěla v tom, že v počítači musely být „naprogramovány„ veškeré rozumové schopnosti (inteligence) nutné k řízení. Vše, od nejjednoduššího PID řídicího algoritmu po ty nejsložitější řídicí strategie, bylo třeba předtím, než to bude možné vykonat, zapsat v programovém kódu. Pro svou přílišnou složitost byly tehdejší programy pro řízení procesů v praxi nepoužitelné.

V 70. letech minulého století se objevily distribuované řídicí systémy (DCS). Levné mikroprocesory umožnily rozdělit řídicí systém do většího počtu samostatných modulů, z nichž každý řídí jen omezenou část závodu. Tím byl jednoznačně vyřešen problém spolehlivosti. Vedle toho DCS vyřešily ještě další problém: řídicí systémy začaly být konfigurovatelné! K vykonávání jednoduchých i složitějších řídicích úloh začaly být k dispozici předem naprogramované moduly.

Skutečnost, že DCS jsou konfigurovatelné, má pro diskusi o „řízení v provozu„ velký význam. Od doby svého vzniku se totiž DCS uplatnily v mnoha odvětvích průmyslu při řízení nejrůznějších spojitých i vsádkových technologických procesů. V důsledku působení těchto mnoha různých prostředí DCS dosáhly značné dokonalosti: byly vyvinuty a v systémových knihovnách jsou uloženy stovky různých konfigurovatelných programových modulů (tzv. funkčních bloků) pro řešení téměř jakéhokoliv myslitelného problému řízení. (Podobný vývoj lze pozorovat v oblasti programovatelných automatů, kde se poptávka soustředila na sekvenční a centralizované řízení diskrétních procesů). Současně se jednotlivé nabízené DCS také liší. Některé se častěji používají k řízení chemických procesů, jiné našly typické použití na trhu s elektřinou, zatímco jiné došly obliby při řízení komplexních vsádkových výrobních procesů s velkým podílem diskrétního řízení. Pro jiné oblasti jejich použití jsou zase typické velké požadavky na archivaci technologických dat a na systémy pro správu výstražných hlášení apod.

Hardware se postupem let stával stále spolehlivějším. Co se týče řídicích modulů i pro komunikaci, byly vyvinuty redundantní systémy. Řídicí jednotky brzy dokázaly řídit desítky, stovky i tisíce řídicích smyček, a to bez poklesu spolehlivosti celého systému. To vše se dělo pod označením „distribuované řízení“, ačkoliv ve skutečnosti stupeň „distribuovanosti„ stále klesal. Označení DCS se stalo v podstatě synonymem pro „snadno konfigurovatelné“ (předem naprogramované), avšak proprietární řídicí počítače dokonale odpovídající potřebám automatizace spojitých technologických procesů zejména nabídkou téměř nevyčerpatelných knihoven funkčních bloků s mnoha parametry.

Nakonec se, v 90. letech, započalo s „digitalizací“ spojení mezi řídicími jednotkami a provozními přístroji. Své příznivce si postupně začala získávat myšlenka průmyslové komunikační sběrnice, až vykrystalizovala dvě základní řešení: sběrnice umožňující přenést provádění řídicích algoritmů až na provozní úroveň (Foundation Fieldbus – FF) a sběrnice bez této možnosti (Profibus). Idea byla, že se provozní přístroje stanou inteligentními (budou vybaveny mikroprocesory) a řízení bude moci být opět, jako dříve, distribuováno na úrovni výrobních provozů.

Skutečností je, že metoda řízení v provozu – po deseti letech od svého zrodu a při reálně existující sběrnici FF – stále ještě usilovně zápasí o uznání. Jeden důvod je zřejmý, a tím je nedostatek autority: dodavatelé DCS nechtějí z pochopitelných důvodů nabízet své velmi dobře propracované a ověřené funkční bloky v prostředí otevřeného standardu. Existovat však musí ještě další důvody. Například se stále prodává velmi mnoho jednosmyčkových regulátorů. To znamená, že na trhu je o tato jednoduchá řešení stále zájem. Mnoho zákazníků potřebuje jednoduchou automatizaci na poměrně nízké úrovni, kterou lze zajistit několika jednosmyčkovými regulátory s jednoduchými PID algoritmy. Příčinou pocitu „úzkosti„ tedy nejspíše není koncept řízení v provozu jako takový, ale obava ze změny, z opuštění paradigmatu, který v oblasti řízení procesů dominoval posledních dvacet let. Do jisté míry se s takovouto obavou pohlíží i na průmyslové sběrnice všeobecně.

3. Pohled na hierarchii řízení

Bez ohledu na patrný růst zájmu o komunikační sběrnice je jisté, že většina současných řídicích systémů, ať už typu DCS nebo na bázi PLC, používá ke spojitému řízení proudovou smyčku 4 až 20 mA a že proudové signály nenesou v tomto případě žádnou jinou informaci než o hodnotě vstupní nebo výstupní veličiny. To znamená, že ohledně vykonávaných funkcí jsou řídicí a provozní úroveň od sebe přirozeným způsobem odděleny (obr. 2). Snímače a převodníky poskytují hodnoty technologických veličin, z nichž řídicí jednotky odvozují požadavky na akční zásahy realizované akčními členy, to vše ve zpětnovazební smyčce. Díky definovanému standardnímu rozhraní mezi řídicí jednotkou a provozním přístrojem si uživatel může vybrat, které ze zařízení nabízených na trhu použije, a dosáhnout výhodného snížení nákladů.

Obr. 2. Hierarchie řízení: tradiční a s řízením v provozu

Mikroprocesory, které se objevily koncem 70. let, přinesly převratná řešení do oblasti DCS a možnost dovést do nynější podoby programovatelné automaty. Současně podnítily vznik nové generace inteligentních provozních přístrojů, nabízejících mnohem více informací o řízeném procesu, než může přenést samotná proudová smyčka. První zařízení pro komunikační sběrnice byla představena v roce 1989 a brzy poté byl ustaven výbor ISA SP50, jehož úkolem bylo sestavit specifikaci nové, univerzální průmyslové komunikační sběrnice. Nový standard musel nabídnout stejnou možnost volby zařízení jako analogová technika, takže bylo třeba specifikovat standardní rozhraní nejen komunikační, ale také uživatelské. To bylo realizováno v podobě funkčních bloků v nejvyšší, osmé vrstvě komunikačního modelu ISO/OSI [1].

I když se pominou tzv. války o sběrnice, je zajímavé připomenout, že Profibus, konkurenční standard komunikační sběrnice vzešlý přímo z výboru SP50, používá v podstatě stejnou metodu funkčních bloků jako FF. Hlavní rozdíl spočívá v tom, že tyto bloky lze vložit do všech zařízení navržených podle specifikace FF, což standard Profibus neumožňuje. Protože však způsob interakce mezi řídicí jednotkou a provozním přístrojem použitý u systému Profibus dobře ladí s tradiční hierarchií řízení, není zde metoda funkčních bloků nijak na překážku obchodům. Jde sice také o přechod k novému paradigmatu, ale jen postupný, nikoliv tak radikální jako u FF. Zákazníky vcelku zajímá totéž, co u sběrnice FF: certifikace, integrace, interoperabilita a samotná sběrnice.

Provozní přístroje určené k použití v systému FF lze přizpůsobit potřebám tradiční hierarchie řízení a použít je prostě jako periferie DCS. U mnoha již dodaných systémů tomu tak je. To je však jen uhýbání před problémem. Je-li v provozním přístroji jednou vestavěna inteligence (a mikroprocesor ovládající procesy měření a komunikaci mají již téměř všechna provozní zařízení), proč ji plně nevyužít? Protože řízení v provozu má nesporné výhody, je třeba se zákazníkem probrat všechny jeho obavy a ukázat, že jsou neopodstatněné. Uživatel, i když má před sebou holá fakta, se přesto může rozhodnout pro tradiční řešení. Ale alespoň jde o rozhodnutí informovaného.

4. Hokus pokus

Pro uživatele je vždy obtížné podstupovat rizika a překonávat překážky nevyhnutelně provázející zavádění každé nové techniky. A ještě obtížnější je to v situaci, kdy pozice „starých dogmat„ je stále ještě velmi pevná. Naproti tomu je ale třeba přiznat, že některá řešení nabízená v současné době nejsou natolik dokonalá, aby ve zcela novém „sběrnicovém„ scénáři skutečně obstála. Není tedy překvapivé, že mnoho potenciálních uživatelů váhá. Typické reakce jsou např.:

• „Nevím, jak v mém závodě použít komunikační sběrnici.„
• „Necítím se být dost připraven k tomu, abych ji zavedl právě teď.„
• „Průmyslové sběrnici nedůvěřuji, a proto dávám ve svém závodě přednost tradičnímu řešení.„

Tyto reakce se vyskytují i v situacích, kdy je průmyslová sběrnice tím nejschůdnějším řešením. Příčinou existujících znepokojení a obav je především nedostatek znalostí a zkušeností. Rozhodnout o použití nové techniky nelze bez důkladného obeznámení se s ní a s jejími přednostmi a nedostatky. Aby zkušenost uživatele byla pokud možno pozitivní, je nutné mu poskytnout veškeré možné školení a další podporu. Pro uživatele je také velmi důležité najít partnera ovládajícího všechny nezbytné prvky projektu založeného na komunikační sběrnici, od koncepce a projektu přes zavedení až po provoz.

Důvody uváděné ve prospěch použití průmyslové sběrnice sahají od úspor nákladů na kabeláž přes rozšiřitelnost řídicího systému až po jeho snadné uvádění do provozu. Největším přínosem pro uživatele však je kvalita informací poskytovaných za běžného provozu. Dosavadní zkušenosti ukazují, že má-li být maximalizována celková výkonnost závodu, je nutné použít inovační řešení: je-li cílem bezpečná a hospodárná výroba, lze jen těžko obhájit další používání již zastaralé techniky. Sběrnice FF poskytuje nejen podrobné údaje o připojených provozních zařízeních, ale současně i mnoho údajů o řídicí smyčce jako celku.

Je-li ovšem zařízení určené pro průmyslovou sběrnici použito „tradičně“, uvedené přínosy nevzniknou. Uživatelé např. po léta kupují zařízení s protokolem HART. Protože to ale pro ně neznamená žádnou finanční ztrátu, z valné většiny nikdy tento způsob komunikace nevyužili. Jinak je tomu se zařízeními pro ostatní komunikační sběrnice, jejichž současná vyšší cena musí být vyvážena provozními přínosy. Strategie typu „počkáme a uvidíme„ jsou nákladné. V dané situaci se návratnost hodnoty výrobních prostředků (ROA) stává stejně důležitou jako návratnost investic (ROI). Maximalizovat ROA znamená pro FF orientaci na řízení v provozu. Výsledkem je, že technologická data jsou dostupná ve všech částech řídicího systému a výrobní činnost se stává jednodušší a mnohem výnosnější i bezpečnější.

I když ekonomické argumenty ve prospěch řízení v provozu jsou dostatečně přesvědčivé, metoda sama zůstává stále ještě zahalena jakýmsi tajemstvím. Je třeba ukázat, jak funguje, a to nejen teoreticky, ale i v konkrétních průmyslových podmínkách.

5. Řízení v provozu

5.1 Základy

Řízení v provozu není nic jiného než provádění řídicích algoritmů (v podobě softwarových funkčních bloků) v provozních přístrojích. Řídicí smyčka se sestavuje propojováním výstupů a vstupů příslušných funkčních bloků naprosto stejně, jako kdyby řízení probíhalo v řídicí jednotce. Jediný rozdíl je v tom, že funkční bloky jako takové se „přidají“ do provozních přístrojů. Spíše než o propojování zařízení může jít o jednoduché „přetažení“ funkčního bloku do provozního přístroje; záleží na konfiguračním programu (obr. 3).

Obr. 3. Příklad konfigurování kaskádní řídicí smyčky v konfiguračním programu sběrnice Foundation Fieldbus

Zatímco se v popředí definuje řídicí strategie, v pozadí je sestavován seznam všech vzájemných vazeb. K vazbám mezi funkčními bloky jsou navíc přidány ještě další vazby, které umožňují hostitelskému systému sledovat parametry v každém z použitých funkčních bloků. Při zavádění sestaveného projektu do reálné sítě je každá tato vazba zaznamenána jako virtuální komunikační vztah (Virtual Communication Relationship – VCR), který si lze představit jako telefonní linku umožňující dvěma nebo více zařízením „hovořit„ navzájem mezi sebou. V reálném provozu používá FF tři typy VCR. Jsou to:

• poskytovatel/příjemce (publisher/subscriber, producent/consumer),
• klient/server
• šíření zprávy.

Vztahy typu poskytovatel/příjemce, používané k realizaci vazeb mezi funkčními bloky, jsou navazovány cyklicky podle pevného časového rozvrhu. Vztahy typu klient/server se používají pro nepravidelné přenosy dat navzájem mezi dvěma zařízeními v síti. Naproti tomu šíření zpráv se používá např. k rozesílání časových průběhů, výstražných hlášení apod. (z jednoho zařízení současně několika jiným – pozn. red.).

Dění v segmentu sběrnice FF řídí řadič zvaný Link Active Scheduler (LAS). Ten obvykle sídlí v řídicí jednotce nebo vazebním členu, ale může být umístěn i v provozním přístroji. Řadič LAS řídí pravidelný (plánovaný) provoz na sběrnici podle časového rozvrhu obsahujícího seznam všech zařízení poskytujících data s přesným vymezením doby, ve které mají právo vysílat na sběrnici. Řadič LAS synchronizuje činnost segmentu sběrnice tak, že postupně prochází seznam a po řadě vyzývá jednotlivé bloky k poskytnutí technologických dat. Aktuální hodnota vyslaného údaje se tak současně dostane ke všem zařízením, která ji potřebují (příjemcům). V obdobích bez pravidelného provozu na sběrnici zpracovává LAS nepravidelné (tzv. neplánované) požadavky systému: na zobrazení dat, záznam povelů, šíření administrativních údajů apod. (Podrobněji je o řadiči LAS pojednáno ve vloženém textu na této a protější straně – pozn. red.)

Obr. 4. Příklady řídicích strategií a vliv umístění funkčních bloků (AI – Analog Input, AO – Analog Output)

Doba potřebná k obnovení technologických dat v celém systému je dána periodou tzv. makrocyklu, zahrnující dobu potřebnou na vyvolání a přenos technologických dat a fixní časový interval určený pro neplánované přenosy dat. Je třeba upozornit, že obnova údajů na operátorském rozhraní (HMI) může trvat i déle než jeden makrocyklus. Záleží na délce periody makrocyklu a množství neplánovaného provozu na sběrnici.

5.2 Optimalizace makrocyklu

Jedním ze způsobů, jak optimalizovat řízení procesu, je zkrátit periodu makrocyklu. K tomu je třeba omezit plánovaný provoz na sběrnici, tj. zmenšit počet vazeb (přenosů dat) potřebných k provedení řídicího algoritmu. Na obr. 4 je příklad smyčky s PID regulačním algoritmem, ve které je průtokoměrem řízen regulační ventil. Takovou smyčku lze realizovat třemi způsoby:

1. Umístit PID regulátor do řídicí jednotky; to znamená uskutečnit v každém řídicím kroku tři vnější přenosy:
   – údaje z bloku AI průtokoměru do bloku PID regulace v řídicí jednotce,
   – výsledku výpočtu PID algoritmu do bloku AO akčního členu,
   – výsledku výpočtu z bloku AO akčního členu zpět do bloku PID regulátoru.
2. Je-li PID regulátor umístěn v průtokoměru, jsou nutné dva vnější přenosy:
   – výsledku výpočtu algoritmu PID do bloku AO akčního členu,
   – výsledku výpočtu z bloku AO akčního členu zpět do bloku PID regulátoru.
3. Při umístění bloku PID regulátoru v akčním členu postačí uskutečnit pouze jeden vnější přenos:
   – zaslat údaj z bloku AI průtokoměru do bloku PID regulátoru.

U jednotlivé smyčky jde, v porovnání s dobou potřebnou na výpočet bloků, o úsporu poměrně malou. Zejména uváží-li se, že řídicí jednotka provede výpočet smyčky rychleji. Běží-li však několik smyček současně, ztrácí doba výpočtu značně na významu a rozhodujícím faktorem se při optimalizaci makrocyklu stává počet externích vazeb. Menší počet externích vazeb zároveň vede k větší integritě smyčky. Z tohoto pohledu nabízí nejvyšší stupeň integrity smyčky metoda uvedená v bodě 3. Na uvedeném příkladu lze vidět, že použít řízení v provozu je zjevně výhodné. Nicméně je třeba vzít v úvahu také případná omezení.

5.3 Funkční bloky

Jedno na první pohled patrné omezení představují počet a typy funkčních bloků, které systém nabízí k použití v provozních přístrojích. Čím více jich je, tím lepších výsledků lze dosáhnout při optimalizaci výkonnosti systému. Potíž je ale v tom, že většina dostupných funkčních bloků je určena k řízení spojitých procesů. Zde se nabízí možnost zcela bez problémů spolu integrovat spojité a logické řízení v tzv. hybridní řízení, a to při použití metody tzv. pružných funkčních bloků. Z hlediska použití funkčních bloků při sekvenčním řízení jsou ovšem jednoznačně slabými stránkami na jedné straně kritické požadavky na rychlost taktu sběrnice a na druhé straně skutečnost, že metoda funkčních bloků dosud nedostatečně podporuje sekvenční logiku.

Nemá ovšem smysl přeplňovat zařízení funkčními bloky, které se pravděpodobně nikdy nepoužijí, neboť to zbytečně zatěžuje jeho paměť. Řešení nabízené sběrnicí FF spočívá v použití tzv. konkretizace (přidělení paměti a hodnoty objektu, který byl deklarován), která umožňuje vytvářet funkční bloky ad hoc nebo je do zařízení zavádět z knihovny obsažené v systému. Znamená to, že uživatel může funkční bloky volně umisťovat kdekoliv v provozu a může pružně rozhodovat o tom, odkud bude proces řízen.

Metodu konkretizace ovšem nepodporují všichni výrobci ani hostitelských systémů, ani provozních přístrojů. Ještě zcela nedávno dokonce stačilo, aby byla pouze deklarována v konfiguračním souboru zařízení (.cfx), a ihned vznikly problémy s interoperabilitou (tento nedostatek již organizace Fieldbus Foundation zjistila a odstranila).

K zajištění maximální možné míry pružnosti a rozšiřitelnosti systému je také důležité, aby funkční bloky použité v řídicí jednotce a bloky v provozních přístrojích byly shodné. Při použití fixně vložených funkčních bloků musí být zaručeno, že jsou tyto v celém systému identické. Jen tak je zajištěn jednotný způsob konfigurování a další standardní parametry. Ačkoliv se situace postupně zlepšuje, je do programu zkoušek interoperability v současné době zahrnuta jen necelá polovina bloků obsažených ve specifikaci FF. Postupně budou zahrnuty další. Momentálně je ale třeba všechny ostatní, tj. do programu zkoušek nezahrnuté i veškeré další zvláštní bloky nabízené výrobci či vytvořené na zakázku, před použitím pečlivě prověřit z hlediska zvolené strategie výměny provozních přístrojů. Při pochybnostech ohledně interoperabilty je zapotřebí ptát se výrobců, zda jejich funkční bloky spolupracují s vybraným hostitelským prostředím. Většina těchto producentů disponuje prvotřídními laboratořemi schopnými prověřit, jak se bude sběrnice chovat při kombinaci zařízení od různých výrobců.

5.4 Virtual Communication Relationship (VCR)

Jak již bylo uvedeno, je VCR obdobou telefonní linky a zařízení musí mít jednu takovou linku pro každou vnější vazbu. Zařízení mohou nabízet pevné počty VCR daného typu, nebo mohou být v tomto ohledu zcela flexibilní. Některá zařízení podporují jen několik málo VCR, což při požadavku na větší počet vazeb znamená omezení. Projevit se to může např. při velmi složitých řídicích strategiích při podpoře redundance zařízení, systémů správy výstražných hlášení nebo kaskádního řízení s prostředky umožňujícími obnovu či zrušení a náhradu funkčního bloku. Třebaže nejde o kritérium, které by mohlo být příčinou odmítnutí řízení v provozu, je co možná největší počet VCR u zařízení zcela jistě významným příspěvkem k větší integritě řídicí smyčky a pružnosti struktury systému.

5.5 Multi-Variable Optimisation

Parametry funkčního bloku provozního přístroje jsou hostitelskému systému dostupné ve čtyřech standardizovaných tzv. pohledech (view). Přenáší se vždy celý pohled, a to i když je požadován byť jen jeden parametr. Databáze hostitelského systému se aktualizuje prostřednictvím neplánovaných přenosů v režimu klient/server. Přenos jednoho pohledu trvá asi 50 ms. Při umístění funkčních bloků v provozních přístrojích četnost přenosů těchto pohledů roste. Jsou-li parametry vybrané ke sledování každý v jiném pohledu, může se situace na sběrnici i vyhrotit. Jak již bylo zmíněno, vyžaduje-li řídicí úloha bezpodmínečně krátkou periodu makrocyklu, může být doba potřebná na obnovu údajů např. na operátorském rozhraní delší než perioda makrocyklu.

Podporuje-li hostitelský systém vlastnost sběrnice FF zvanou Multi-Variable Optimisation (MVO), lze neplánovaný provoz na sběrnici výrazně zredukovat a tím zkrátit dobu její odezvy. Zařízení s touto vlastností sloučí dohromady sledované parametry z několika funkčních bloků do jednoho objektu, který lze přenést jedinou transakcí a tak výrazně zmenšit zatížení sběrnice. Výsledkem je výrazné zkrácení doby potřebné na aktualizaci sledovaných údajů.

6. Hororové scénáře

6.1 Analýza rizika

Při znalosti hlavních výhod a omezení vlastních řízení v provozu je nyní na místě pojednat o obavách, které vyvolává.

Obr. 5. Sběrnicový systém s redundancí na několika úrovních

Přestože každý řídicí technik má své vlastní osobité tzv. hororové scénáře, přece jen existují určité základní varianty vyskytující se častěji než ostatní. Určit co, a jestli vůbec něco je třeba dělat v případě nenadálých situací je součástí analýzy rizika. Výsledkem následné syntézy může být systém podobný tomu na obr. 5. V dalším textu jsou vybrány čtyři obvykle se vyskytující obavy řídicích techniků, probrány důsledky každé z nich a uvedena možná řešení.

6.2 Zombie

Zařízení mi „odchází“ uprostřed noci. Regulační smyčka přestává fungovat.

Taková porucha může nastat u jakéhokoliv systému. Skutečné následky závisejí na úloze dotyčného zařízení v řídicí smyčce. Někdy je možné funkci smyčky určitým postupem obnovit, jindy musí být postižené zařízení vyměněno. Platí, že:

1. Přestane-li zařízení fungovat, funkční bloky čekající na jeho výstupní údaje ohlásí chybový stav a odpovídající řídicí smyčky přejdou do naprogramovaného bezpečného stavu.

2. Jde-li o zařízení poskytující vstupní informace do smyčky, lze s použitím bloku pro výběr vstupu (INEL) automaticky obnovit její činnost přechodem na duplicitní (redundantní) komponentu.

3. Zařízení, ve kterých pracují řídicí bloky, musí být vyměněna. Momentálně totiž většina hostitelských systémů nepodporuje redundanci funkčních bloků. Smyčka ohlásí chybový stav a všechny výstupy přejdou do naprogramovaného bezpečného stavu. Je-li řídicí blok umístěn v akčním členu, přestaví ventil do zvolené bezpečné polohy jeho mechanická tzv. havarijní funkce.

4. Zařízení montované náhradou za porouchané musí obsahovat všechny funkční bloky použité v nahrazovaném zařízení. Při použití nestandardních funkčních bloků musí náhradní zařízení odpovídat do všech detailů nahrazovanému. Při použití vhodného konfiguračního nástroje je již jednoduché nové zařízení nastavit a vložit do něj odpovídající část řídicího algoritmu. Smyčka pak začne znovu fungovat.

6.3 Godzilla

Něco jde kolem a přerušuje kabel sběrnice vedoucí do řídicí jednotky: ztrácím vládu nad všemi přístroji připojenými k postiženému segmentu sběrnice.

K přerušení kabelu může dojít u libovolného systému. Výsledkem je vždy ztráta přinejmenším jedné řídicí smyčky. Co je rychlejší: znovu spojit dva vodiče sběrnice, nebo vyhledat a opravit vadnou analogovou přípojku? Dále platí, že:

1. Jelikož se obvykle přeruší také přívod elektrické energie, přestaví se ventil mechanicky, působením havarijní funkce, do zvolené bezpečné polohy.

2. Ztráta spojení znamená, že veškeré smyčky v ostatních segmentech sběrnice očekávající data z postiženého zařízení ohlásí chybový stav na vstupu a automaticky přejdou do naprogramovaného bezpečného stavu.

3. Je-li smyčka navržena tak, že je redundantní pouze napájení, převezme řízení záložní LAS a všechny smyčky v postiženém segmentu budou dál fungovat normálně. Vnější smyčky budou reagovat podle bodu 2.

4. Je-li zajištěna redundance na úrovni napájení, řídicí jednotky (hardwaru) i řídicího algoritmu (aplikačního programu), převezme řízení záložní řídicí jednotka. Všechny smyčky budou pracovat zcela normálně.

6.4 Psycho

Porouchala se řídicí jednotka a ztrácím jakoukoliv možnost řídit.

S jinými systémy ano, ale u FF záleží na tom, jaká byla zvolena strategie řízení. Nejprve předpokládejme, že řídicí jednotka neobsahuje žádný funkční blok. Tehdy platí:

1. Při běžném uspořádání, tj. bez redundantně řešené řídicí jednotky, se ve všech připojených segmentech aktivují záložní LAS a všechny smyčky uzavřené uvnitř těchto segmentů budou pracovat normálně (za předpokladu, že jsou napájeny). Všechny smyčky uzavřené napříč různými segmenty přestanou pracovat a přejdou do naprogramovaného bezpečného stavu.

2. Je-li řídicí jednotka řešena jako redundantní, převezme řízení záložní řídicí jednotka a všechny smyčky budou normálně pracovat.
   Jsou-li v řídicí jednotce prováděny některé funkční bloky, stane se toto:

3. Při běžném uspořádání se opět ve všech připojených segmentech aktivují záložní LAS a všechny smyčky uzavřené uvnitř těchto segmentů budou pracovat normálně (jsou-li dále napájeny), s výjimkou těch, jejichž funkční bloky jsou umístěny a prováděny v řídicí jednotce. Ty, a spolu s nimi všechny smyčky uzavřené napříč různými segmenty, přestanou pracovat a přejdou do naprogramovaného bezpečného stavu.

4. Je-li zajištěna redundance řídicí jednotky i řídicího algoritmu, převezme řízení záložní řídicí jednotka a všechny smyčky budou pracovat normálně.

6.5 Bezhlavý jezdec

Operátorské rozhraní (HMI) je „pryč“. Jsem slepý a netuším, co se děje.

Nepříjemná situace, které však lze do budoucna předejít pořízením záložního systému. Protože součástí specifikace FF je tzv. vysokorychlostní Ethernet (High Speed Ethernet – HSE), nemusí to být, s ohledem na konkrétní řídicí systém, nijak zvlášť nákladné, protože redundantní datovou síť lze vybudovat s použitím běžných komerčně dostupných komponent (COTS). Dále platí, že:

1. Ztráta operátorského rozhraní nemá přímý vliv na řídicí jednotku ani na přístroje v provozu, takže všechny řídicí smyčky pokračují v činnosti.

2. Je-li redundantní i OPC server a je k dispozici záložní operátorské rozhraní, přejde řízení na ně.

3. Velmi vhodné je pořídit centrální nebo místní nouzové panely a tlačítka. Funkční bloky podle specifikace FF obsahují diskrétní vstupy umožňující manuálně překlenout kritické řídicí smyčky a přepnout je do bezpečného pracovního režimu.

7. Kdy je vhodné použít řízení v provozu?

7.1 Rozhoduje přínos uživateli

Třebaže to někdy může být i otázka preferencí, použít řízení v provozu je obvykle vhodné tehdy, jestliže z toho uživateli plyne nějaký technický nebo ekonomický užitek. Při porovnávání nákladů na FF s náklady na jiné systémy platí, že každý řídicí blok použitý v provozním přístroji nahrazuje analogový kanál v DCS. V samotném systému FF však z umístění řídicích bloků v provozních přístrojích neplyne žádný na první pohled patrný ekonomický přínos, pokud ovšem není omezen počet bloků nebo vazeb, které dokáže zvládat řídicí jednotka, není-li požadován vysoký stupeň integrity smyčky či pokud se lze obejít zcela bez řídicí jednotky.

Obr. 6. Příklad systému řízení destilační kolony s řízením umístěným v provozních přístrojích: distribuované bloky I/O ovládají pohony, jednoduchý podsystém řízení průtoku (průtokoměr a regulační ventil) je umístěn v regulátoru polohy ventilu stejně jako podsystém regulace teploty v koloně (snímač teploty, snímač tlaku a regulátor polohy ventilu)

Jak je naznačeno v kap. 5, lze se pečlivým návrhem všeobecné strategie řízení, řídicího algoritmu a segmentu sběrnice efektivně vypořádat s většinou úloh vyskytujících se v praxi. Omezení představují počet a typy dostupných funkčních bloků a podporovaných vazeb. Ty zase závisejí na provozním přístroji a hostitelském systému. Následující příklady ukazují, jak vypadá řízení v provozu v praxi. Vychází se přitom z obr. 6, kde použitý hostitelský systém i provozní přístroje podporují metodu MVO.

7.2 Jednouché zpětnovazební řízení průtoku

V kap. 5.2 je ukázáno, že blok PID regulátoru ventilu je nejlepší umístit do samotného regulátoru polohy činného prvku ventilu (obr. 4). Tím se nejen minimalizuje počet vnějších vazeb při vzrůstu integrity řídicí smyčky. Současně se také zajistí, že při chybě na vstupu blok přejde do bezpečného pracovního režimu, a to bez jakéhokoliv zásahu ze strany operátora nebo některého z ostatních zařízení v síti.

7.3 Regulace teploty v destilační koloně

Jako kontinuální proces představuje regulace teploty v destilačních kolonách (anebo parních kotlích) z pohledu použití řízení v provozu přímo ideální úlohu. V automatizovaném systému na obr. 6 jsou rozpouštědla destilována po dávkách (vsádkách). V počáteční fázi zahřívání kotle musí být tudíž nějak řízena změna teploty v čase, a to s průběhem tvaru rampy. To se udělá s použitím tzv. charakterizačního a aritmetického bloku, spolu se sledovacím funkčním blokem prováděným v regulátoru polohy ventilu. Celkem je třeba zřídit pět komunikačních vazeb typu poskytovatel/příjemce. Kdyby byly řídicí bloky zavedeny v řídicí jednotce, byla by potřeba vazeb dvojnásobná; to by výrazně ovlivnilo periodu makrocyklu a snížilo stupeň integrity smyčky. Při větších počtech řídicích smyček je zde, v porovnání s tradičním řešením, zřetelně patrný významný pokles nákladů. Není totiž nutné replikovat místní řídicí jednotky k řízení teplot prostřednictvím jednotlivých nezávislých řídicích smyček.

Obr. 7. Logické řízení lze do systému Foundation Fieldbus začlenit třemi způsoby

7.4 Řízení pohonu prostřednictvím distribuovaného modulu I/O

Logické řízení není, jak již bylo uvedeno, příliš silnou stránkou současné sběrnice FF. Běžně se správa analogových a digitálních I/O signálů zajišťuje tak, že se k řídicí jednotce přidají I/O karty. Nicméně existuje několik možností, jak do systému FF integrovat programovatelné automaty, nebo je možné použít distribuované moduly I/O s rozhraním FF (obr. 7). U systému na obr. 6 byl zvolen druhý způsob, a to distribuovaný modul I/O nainstalovaný lokálně v segmentu sběrnice FF (typu H1). Při použití pružného funkčního bloku lze tak na provozní úrovni v určitém omezeném rozsahu uskutečnit také logické řízení. Pro řízení elektrických pohonů v popisovaném destilačním provozu je to ideální řešení.

8. Krása je v jednoduchosti

Má řízení v provozu budoucnost? S razantním nárůstem rozsahu i funkčních schopností řídicích systémů upadly v zapomenutí možnosti, které z hlediska dalšího zvládání prostorové rozlehlosti a rostoucí složitosti automatizovaných systémů nabízejí menší, rychlejší a levnější automatizační komponenty použité v rámci velkých systémů. Možná, že právě toto je jeden z hlavních důvodů, proč se řídicí technici „bojí“. Vzbuzuje tyto obavy představa závislosti na spolehlivé vzájemné spolupráci tisíců komponent – komponent, které již nadále nebudou dodávat informaci do jednoho místa, ale budou ji, s cílem řídit proces, distribuovat, zjevně bez dozoru, napříč výrobním prostředím?

Centrální velín již totiž není – z čistě technického hlediska – nadále nutný. „(Současné) řídicí systémy jsou natolik dokonalé, že ke koordinaci řídicích činností již nepotřebují zvláštní velíny.„ [2]. Možná, že cesta vpřed vede, pro někoho překvapivě, „zpět„ na provozní úroveň a k realizaci malých, snadno zvládnutelných jednotek schopných samostatné činnosti, ale přitom pravidelně informujících nadřazený dohlížecí systém. Sběrnice FF je pro takové systémy ideálním řešením, neboť její segment může být provozován i bez „řídicí jednotky„ a vlastně i bez nadřazeného řídicího systému, je-li to třeba.

Současně je požadována také „jednoduchost„. Ovšem jednoduchost nikoliv v tom smyslu, že by se uživatelé již nemuseli věnovat kvalifikovaným činnostem, jako je např. zapojování zařízení. Spíše jde o to, že uživatelé by při integrování přístrojů do systému, jejich konfigurování a návrhu strategie řízení rádi, a to mnohem častěji než dosud, využívali postupy typu plug and play.

Systém Foundation Fieldbus bezpochyby patří mezi významné „enabling„ – tedy možnosti otevírající – prostředky a metody. Nelze však zapomínat na ty, kdo s ním musejí pracovat. Výrobci řídicí techniky jistě mohou použití FF v praxi ještě v mnohém usnadnit a zefektivnit. Výsledkem vynaloženého úsilí bude ztráta „živné půdy„, z níž dopředu vyrůstají obavy a očekávání problémů s novou technikou. Když je možné vyměnit pronásledování zombimi za prostou možnost zbavit se jich stiskem tlačítka, a tudíž vedoucí provozu může v noci klidně spát, jde o cíl, o jehož dosažení stojí za to se vynasnažit.

Literatura:
[1] ISO/IEC 7498-1 Information technology – Open Systems Interconnection – Basic Reference Model: The Basic Model. ISO/IEC, 1994.
[2] TOTHEROW, G. K.: Instrument Engineers‘ Handbook, 3rd Edition: Process Software and Digital Networks, Chapter 3.1: Operator Interface Evolution.

Peter G. Berrie,
Eugenio F. da Silva Neto,
Endress+Hauser Process Solutions AG

Peter G. Berrie pracuje ve společnosti Endress+Hauser Process Solutions AG, Reinach, Švýcarsko, jako manažer marketingové komunikace. Po absolvování londýnské Imperial College pracoval pět let ve výzkumu v organizaci Euratom v Karlsruhe v Německu a na Loughborough University v Anglii. V roce 1978 se začal věnovat komunikaci v technice. V roce 1990 nastoupil do společnosti Endress+Hauser GmbH+Co v německém Maulburgu jako autor technických publikací o produktech pro digitální komunikaci a měření polohy hladiny a průtoku. Nynější pozici, na které se věnuje technice sběrnic a řešením v oboru automatizace spojitých technologických procesů zahrnujícím snímače, dohled, správu výrobních prostředků a řídicí systémy, zastává od roku 2000.

Eugenio F. da Silva Neto pracuje ve společnosti Endress+Hauser Process Solutions AG, Reinach, Švýcarsko, jako manažer v oblasti produktů pro automatické řízení. Po absolvování University of Sao Paulo v Brazílii v oboru elektrotechniky pracoval dvanáct let v oblasti průmyslových komunikačních sběrnic při koncipování a vývoji provozních přístrojů na bázi protokolů HART, Profibus-PA a Foundation Fieldbus. Během této doby také reprezentoval svého zaměstnavatele v různých orgánech zabývajících se standardizací uvedených protokolů. K současnému zaměstnavateli nastoupil v roce 2001 jako vedoucí projektu vývoje řídicí platformy určené k použití na úrovni provozu. V nynější pozici, zastávané od roku 2003, odpovídá za tvorbu řešení, která při použití techniky komunikačních sběrnic lépe využívají inteligenci vloženou do provozních přístrojů pro dohled, správu výrobních prostředků a řízení procesů ve výrobním podniku.

Poděkování

Originál příspěvku byl pod názvem Who’s afraid of Control in the Field přednesen na konferenci koncových uživatelů sběrnice Foundation Fieldbus (FF End User Conference) v Singapuru v roce 2003. Přeložen a uveřejněn je s laskavým svolením autorů, organizace Fieldbus Foundation a společnosti Endress Hauser Group.

Přeložil a některé mezititulky doplnil Karel Suchý.

Endress+Hauser s. r. o.
Olbrachtova 2006/9
140 00 Praha 4
tel.: 241 080 450
fax: 241 080 460
e-mail: info@cz.endress.com
http://www.endress.com