|
Život je dávkový proces...
a pak plánujte inteligentní automatizované řešení
Ideální automatizační projekt nebere ohled na čas ani na rozpočtová omezení.
Chemický závod, který ho realizuje, si např. může dovolit luxus automatizace všech ventilů a míchacích zařízení bez ohledu na to, zda jsou malé nebo velké, používané každou hodinu nebo jednou za čtvrt roku. Každý dostane svůj odpovídající pohon a spínače pro zpětné hlášení o stavu.
V takovém ideálním světě také neexistují polovičatá řešení. Při automatizaci reaktoru se současně automatizují podpůrné trasy pro dopravu ingrediencí a předmíchávací nádrže. Automatizuje-li se trať A, automatizují se i trati B a C.
Realita je složitější
V praxi se takový ideální automatizační projekt vyskytuje zřídka, jestli vůbec. Namísto kompletní automatizace přístrojů v provozu je mnohem reálnější se setkat se závodem nebo provozem automatizovaným jen zčásti a daleko nejpravděpodobnější je následující scénář.
Malý, ručně ovládaný chemický provoz s jedním reaktorem se od vedení společnosti po léta snaží získat prostředky na automatizaci. Když jsou konečně uvolněny, je jich málo. Stačí tak na převedení reaktoru na řízení podle receptur a již nikoliv na pomocné nádrže a menší míchací nádoby. Naplánuje se tedy automatizace ovládání hlavních ventilů reaktoru a před ním se nacházejícího mísiče. Peníze na další ventily, popř. na celkovou modernizaci přívodních tras do reaktoru se snad seženou příště. Nadšení z alespoň dílčího pokroku přehluší případné obavy a projekt základní automatizace reaktoru se uskuteční.
Najednou však vyjde z reaktoru produkt s vlastnostmi mimo přípustné tolerance. Technici začnou pobíhat kolem se svými zápisníky a snaží se zjistit příčinu. Protože ale neexistují záznamy o ručně ovládaných ventilech na přívodech ingrediencí, vyvstávají jen otázky.
Ingredience byly vkládány do reaktoru uprostřed noci. Jak dlouho to trvalo? Je jisté, že ventil HV1007 byl otevřen dříve, než začala dodávka katalyzátoru, nebo to bylo později? Neví se a zjistit skutečnou příčinu výroby zmetku nelze.
Předpokládejme nyní, že realizátoři automatizovaného systému nicméně přes omezený rozpočet, takovéto problémy předvídali a předešli jim tak, že do postupu zpracování receptury zahrnuli i všechny ručně ovládané ventily. V čase, kdy je třeba je přestavět, dá naprogramovaný systém pokyn k ručnímu zásahu operátorovi a trpělivě čeká, dokud ten nepotvrdí jeho provedení. Vše je zaznamenáváno.
Po částech k cíli?
Závod se tedy vyhnul výdajům na automatizaci většiny akčních členů a přesto vše pěkně funguje – zatím.
Zádrhel se ukáže následující léto, kdy přijde několik dolarů umožňujících automatizovat občas používaný křížový ventil mezi dvěma přívody ingrediencí. Co se stane nyní? Nejprve musí technik závodu, spíše nepříliš obeznámený s původním projektem, najít a odstranit příslušné hlášení pro operátora.
To není až tak obtížné – stačí je vyhledat a komentářem zrušit. Složitější je již upravit logiku stávajících činností kolem vsádky týkajících se daného ventilu. K tomu je třeba zasáhnout do kódu řídicího programu, což již může být i složitější a časově náročné. Pracovník provádějící úpravu nemusí znát všechna uvažovaná kriteria, použité standardy anebo jemné nuance původního návrhu. Nějak se to však podaří a po odstranění několika drobných problémů pracuje nový automatizovaný ventil podle představ.
Za čtvrt roku pak přijde trochu peněz na automatizaci 12 ventilů v přívodu vody a celá procedura se, ve větším, opakuje. Potom je v příštím roce schválena další část rozpočtu určená k automatizaci druhé trati, dosud řízené ručně.
Takovéto postupné evoluční změny však dosti narušily původní elegantní strukturu řídicího programu. Systém vyžaduje záplaty, komentáře a práci kolem toho. Nakonec ztrácí podstatnou část své původní pružnosti a modifikovat ho je čím dál tím obtížnější. Aby se čím dál tím více netrápili, přestanou provozní pracovníci usilovat o další peníze na automatizaci a systém zůstává v nějakém suboptimálním mezistavu. Postoj provozních pracovníků lze vyjádřit slovy: „Proboha jen žádné peníze na automatizaci třetí trati!“.
Co by se však stalo, kdyby projektantský tým přistoupil ke všem akčním členům stejně, bez ohledu na to, zda jsou ovládané automaticky či ručně, mají či nemají elektrický pohon anebo dokonce zatím neexistují a jsou teprve plánovány do budoucna? Mohl by vzniknout dobře promyšlený projekt vyhovující současným i budoucím potřebám. Co kdyby systém mohl, po úvodním spuštění, automaticky rozlišit neautomatizované akční členy a vybavit pro manipulaci s nimi operátorský dialog?
A co kdyby se našel způsob, jak v systému zacházet s ručně ovládanými akčními členy jako stejně jako s automatizovanými prvky, které budou do systému přidány teprve v budoucnu. A co kdyby se to vše stalo naráz, aby se už později nikdo nemusel vůbec zaobírat programovým kódem? Podívejme se, jak na to.
Nejprve si to představte
Vezměme základní vsádkový proces s recepturou pracující s jednou míchací nádrží (MIXTANK) a dvěma reaktory (REACTOR1, REACTOR2 – viz faximile zobrazení technologického zařízení na obr. 1). Představme si, že operátor spustí provádění receptury po cestě MIXTANK a REACTOR1. Tato receptura naplní obě nádoby příslušnými ingrediencemi, spustí míchadla, přemístí materiál z míchací nádrže do reaktoru, určitou dobu počká a poté z reaktoru vypustí hotový produkt.
Nyní si představme, že operátor spustí recepturu po alternativní cestě. Na ní jsou všechny ovládací prvky automatické s výjimkou přepouštěcího ventilu 03XV003 do reaktoru REACTOR2.
Spuštěná receptura nejprve inicializuje MIXTANK a REACTOR2 uzavřením všech jejich ventilů. Řídicí systém ale nemůže uzavřít ručně ovládaný ventil 03XV003. Systém tedy vydá zprávu žádající operátora o pomoc. Zpráva, která se objeví na obrazovce ovládací stanice, obsahuje tyto informace:
- datum a čas,
- jméno jednotky vydávající povel: zde REACTOR2,
- textový pokyn k uzavření určitého ventilu: zde 03XV003.
Procedura zpracování receptury se zastaví a nebude pokračovat, dokud operátor nepotvrdí provedení úkolu.
Dále si představme, že operátor došel k manuálnímu ventilu 03XV003, zjistil, že ve skutečnosti je zavřený, vrátil se k operátorské stanici a tuto skutečnost potvrdil (obr. 2). Receptura se posune do dalšího kroku. Předtím ale změní zobrazení tak, aby bylo zřejmé, že ventil 03XV003 je zavřený – barva jeho symbolu se změní ze zelené na červenou.
Později, když je třeba přepustit materiál z mísidla MIXTANK do reaktoru REACTOR2, je operátor obdobně vyzván, aby ventil 03XV003 otevřel. Příklad se dotýká jednoho ventilu, ale principálně lze takovým způsobem obsluhovat libovolný počet ručně ovládaných zařízení, ať už ventilů, míchadel aj.
Řídicí systém se tedy vyrovnal s některými ze shora zmíněných problémů. Počítačem řízená procedura zpracování receptury pracuje nejen s automatizovanými akčními členy, ale i s ručně ovládanými ventily a systém permanentně zaznamenává veškeré zásahy na ručně ovládaných zařízeních.
Nyní se posuňme dále dopředu v čase a představme si, že závod dostal peníze na to, aby automatizoval ventil 03XV003 a přes subsystém I/O ho připojil k řídicímu systému. A jak složitá bude úprava řídicího programu?
V prvním kroku je třeba otevřít modul Engineering Builder pro jednotku REACTOR2 obsahující seznam jmen proměnných se vztahem k tomuto reaktoru. Před jménem napájecího ventilu 03XV003 je zvláštní znak M, označující ruční ovládání. Stačí odstranit M, znovu zkompilovat kód a vložit ho do řídicí jednotky. Nic jiného. Celá operace může trvat asi minutu.
Nyní operátor opět spustí tutéž recepturu cestou přes REACTOR2. Během jejího zpracování již systém ví, že napájecí ventil pracuje automaticky a ovládá ho tudíž přímo přes subsystém I/O, aniž by vyžadoval pomoc operátora. Jediná rychlá, on-line provedená změna stačila k tomu, aby se do řídicího programu promítla skutečné situace v provozu.
V čem je kouzlo?
Jak toto všechno funguje? Řídicí systém použitý pro tuto ukázku znázorňuje činnosti jednotky (tj. unit, v terminologii podle normy ANSI/ISA S88 Batch Control – pozn. red.) jako sekvenční přechodové diagramy s vlastním řídicím programem fáze (phase) sestaveným v jazyce pro programování vsádek. Zde použitou vlastností tohoto jazyka je křížové odkazování mezi kódem a seznamem symbolických jmen proměnných vázaných k jednotce. Jazyk také podporuje programové funkce vytvořené uživatelem.
Fáze, jako nejmenší prvek procedurálního řízení (viz zmíněná norma S88 – pozn. red.) tak může zavřít napájecí ventil reaktoru vyvoláním uživatelské funkce a provedením jednotlivých z následující posloupnosti:
- Vyvolat jméno proměnné (M03XV003) odpovídající obecnému jménu (GFEED).
- Oddělit ze jména proměnné krajní levý znak.
- Zjistit, zda jde o písmeno M.
- Je-li znakem M:
– spustit dialog vyžadující po operátorovi manipulaci s ručně ovládaným ventilem,
– vložit do dialogu skutečné jméno (03XV003) a požadovaný stav (CLOSED),
– počkat, dokud operátor nepotvrdí, že manipulaci s ventilem provedl,
– aktualizovat softwarový stav zařízení (a tím změnit barvu symbolu v zobrazení ze zelené na červenou),
– vrátit se do hlavního řídicího programu fáze.
- Jestliže znak není M:
– přestavět ventil automaticky přes I/O subsystém,
– zkontrolovat zpětné hlášení; jestliže ventil neodpoví, spustit výstrahu,
– příchod zpětného hlášení od ventilu sám způsobí změnu barvy symbolu,
– vrátit se do hlavního řídicího programu fáze.
To je celkem 29 řádek kódu. Protože skutečné jméno proměnné je argumentem uživatelské funkce, stačí vytvořit pro všechny přístroje v provozu jeden jediný úsek programového kódu. Jinými slovy: tentýž kód je použitelný pro všechny ručně ovládané akční členy v projektu.
Není nač čekat
Popsaný postup má v praxi mnoho výhod. Především umožňuje projektantskému týmu vytvořit pro celý proces „čistý“ projekt, který se všemi přístroji v provozu zachází jako s automatickými, byť budou zpočátku ovládané ručně.
Nemůže se stát, že by záměry původních autorů projektu týkající se zpracování výjimečných situací a společného sdílení zdrojů, na první pohled skryté, byly později nepochopeny nebo špatně interpretovány. Daný postup naopak podporuje tvorbu receptur v elektronické podobě pro každý jednotlivý produkt.
Zmizí kombinace počítačových a „papírových“ procedur. Práce operátorů je klidnější a auditor receptur je spokojenější.
Vytvořený systém pohotově podporuje obsluhu při všech manuálních činnostech, ať jde o otevírání a zavírání ventilů, spouštění míchadel, vyplachování nádrží apod. Dokumentace pak poskytuje neocenitelné služby technikům stojícím před otázkami typu: „Proč je tato dávka mimo tolerance?“, „Proč trvají výrobní cykly během víkendu mnohem déle?“.
Velmi významné také je, že přístroje v provozu lze při tomto způsobu projektování automatizovat kdykoliv a v jakémkoliv pořadí, po jednom při pauzách v provozu i hromadně při rozsáhlejších automatizačních akcích. Inovace řídicího systému není nutné soustřeďovat do větších celků a handrkovat se o velké částky z rozpočtu. Každé jednotlivé zařízení lze změnit v automatizované, jakmile je k dispozici byť i relativně malá finanční částka.
Nejvýznamnějším přínosem uvedené metody je však skutečnost, že při přechodech z ručního na automatické řízení nevyžaduje změny v řídicím programu. Investice a inženýrské úsilí vložené do původního projektu zůstávají zachovány. A navíc vše, co bylo vytvořeno, je opakovaně použitelné. Jakmile myšlenka funguje na jedné platformě, lze ji beze změny přenášet z projektu do projektu.
Odpor operátorů k systému
Nepochybně zde však existují i stinné stránky. Především, třebaže vést úplné záznamy o činnosti všech ručně manuálně ovládaných zařízení je z pohledu technických složek i managementu závodu žádoucí, pro operátory řídící výrobu může být obtížné se s takovouto situací vyrovnat.
Z jejich pohledu je jednodušší prostě jít do provozu a otevřít ventil než přijmout dialogové okno, jít přestavět ventil, vrátit se k operátorské stanici a potvrzovat každou jednotlivou akci.
Jak dlouhá doba uplyne do potvrzení ručního zásahu operátorem závisí do značné míry na rozmístění operátorských stanic. Obecně si tento způsob vyžaduje více času, a to až do té míry, že může být ovlivněna celková doba zpracování vsádky.
A dále, i když v tom management závodu vidí výhodu, operátoři mohou mít k systému dirigujícímu každý jejich pohyb averzi. To platí zejména tehdy, instaluje-li se řídící systém v již existujícím provozu. Management by měl brát tato protichůdná stanoviska v potaz tehdy, je-li podíl manuálně ovládaných v celkovém počtu řídicích modulů asi třetinový.
K preventivním opatřením patří také projektování v předstihu. Jde o metodu umožňující velmi snadno a s minimálními náklady v budoucnu doplňovat automaticky řízené moduly. Její účinnost je nicméně značně závislá na kvalitě výchozího projektu.
Není-li původní projektantský tým při své práci dostatečně disciplinovaný, mohou být špatná modularizace zařízení nebo poruchy sdílených zdrojů příčinami vzniku chaotických situací. Tým se proto musí vždy pečlivě vyvarovat škodlivé tendence soustřeďovat pozornost na to, co je automatizované a ponechávat stranou stranou to, co je – byť jen dočasně – ponecháno na ručním ovládání obsluhou.
David Christie,
consultation engineer,
Yokogawa Corporation of America,
Newman, Georgia, USA
Článek vychází z příspěvku předneseného autorem na World Batch Forum´s North American Conference, Florida, 2001, odkud je také převzata grafika. Překlad a úprava Karel Suchý. Otištěno se svolením zastoupení společnosti Yokogawa v ČR.
YOKOGAWA - Reprezentační kancelář
1. máje 120
730 00 Ostrava
tel.: 595 953 967
fax: 595 955 673
e-mail: yokogawa@daas.cz
http://www.yokogawa.cz
|