Str učný př ehled r ozvoje automatizace v r afiner ii v Kr alupech. 1/ Vážené přátelé, Rádi bychom Vás seznámili s rozvojem automatizace v Kralupech. Rafinérská výroba je spjata s Kralupami od dvacátých let minulého století, ale nebojte se, tak daleko zpět nepůjdeme. Ostatně tato rafinerie byla zcela zničena náletem na jaře roku 1945. 2/ Přehled se týká nové rafinerie která byla postavena na protějším břehu Vltavy v rámci areálu Kaučuku v sedmdesátých letech. Rafinerie je v provozu od roku 1974, to je do dnešního dne 35 let. Za tuto dobu jsme měli tři různé řídící systémy a prošli jsme dvěma Upgrade. Prakticky to znamená, že v průměru každých sedm roků jsme výrazně zasahovali do systému řízení. Pro ty kteří již podobným zážitkem prošli může být moje prezentace zajímavá pro srovnání, pro ostatní snad alespoň jako malá příprava na to co je čeká. Nakonec to je hlavním smyslem této prezentace. Budeme tedy mluvit o předešlých systémech a cestě k FOXBORU, Jak se rozvoj odrazil v počtech pracovníků Pro objasnění našich přístupů se seznámíme s hlavními standardy ze kterých jsme vycházeli Jak jsme vybírali poslední systém, jak probíhaly jednotlivé instalace Zhodnotím průběh projektů včetně potíží na které jsme narazili Pokusím se upozornit na chyby a doporučit jak se jim vyvarovat Seznámím Vás s našimi záměry 3/ Velice stručně o technologii. Kralupská rafinerie byla postavena jako kompaktní výrobní jednotka bez skladování meziproduktů. Důvodem byly především úspory energií. Zvolený způsob provozování byl výzvou pro kvalitu řízení provozu, protože porucha v takto vázaných technologiích obvykle projde celým zařízením a může mít i závažné dopady. Kromě výrobního bloku byla jako součást rafinerie postavena řada pomocných provozů, expedičních zařízení a 60 skladovacích nádrží. Výchozí instrumentace byla tuzemská pneumatická od ZPA, v provozu bylo kolem 350 regulačních ventilů. Zabezpečení bylo realizováno reléovou logikou. Centrální počítač zabezpečoval řízení velice omezeného počtu smyček, zajišťoval sledování spotřeb energií, vyhodnocoval provozních a meziprovozních bilancí produktů a generoval expediční doklady.( V sedmdesátých letech neexistovala žádná výpočetní technika mimo velkých „sálových“ počítačů. ) Velice důležitým úkolem v rafinerii je sledování stavů zásob ve skladovacích nádržích. Rafinerie je skladem velikých objemů produktů s jejich neustálým pohybem. Znalost stavu zásob je důležitá z hlediska ekonomiky i z hlediska řízení provozu a technologie. 4/ Při uvedení do provozu v roce 1974 byla r afinerie řízena počítačem IBM 1800. Byl to počítač 2 ½ té generace, ( uměl maximálně klopný obvod), s děrnými štítky a operační pamětí 108 kB. Řídil supervizně pouze 36 smyček a to tak, že nastavoval přes převodníky externí žádanou veličinu pro pneumatické regulátory. Mimo to ale sledoval zásoby ve skladovacích nádržích a zajišťoval všechny funkce související s bilancemi, a expedicí. Operátor pomocí tlačítek vypsal tagname a na digitronech se mu zobrazila zvolená hodnota. Pro výstupní sestavy byl k dispozici el. Psací stroj. Expediční doklady na vlečku se posílaly potrubní poštou. ( Pro ilustraci stavu techniky: První jednočipový PC představila IBM v roce 1979. )
Součástí výbavy byl nadčasový bilanční systém jehož základy se používají doposud. 5/ V roce 1986 byl instalován již skutečný distribuovaný systém Honeywell TDC 2000, s konzolemi , klávesnicemi a barevnými monitory. Řídil klasickým způsobem 70 klíčových regulačních obvodů. Ve velínu zůstaly zachovány pneumatické regulátory pro případný záskok. Zavedením „Advance control loops“ došlo k výraznému zkvalitnění řízení. Pro bilanční systém byly zavedeny algoritmy pro korigování měřených veličin. Součástí systému byly také tiskárny pro tisky alarmů a bilančních sestav, později i přenosy dat do podnikové sítě. Reléová logika zabezpečení zůstala zachována. Skladba operátorského pracoviště je zřejmá z fotografie. Operátoři používali ke sledování provozu panel s informační nástavbou před kterou měli dvě stanice s monitory a klávesnicemi a tiskárnami. S rozvojem výpočetní techniky přibývaly na pracovišti další PC pro práci s Intranetem, laboratorním systémem, bilančním systémem teplárny a CCTV. Díky takovéto směsi se časem stalo pracoviště nepřehledným, nesourodým. 6/ Vznikem České rafinérské a změnou vlastnických vztahů byly vytvořeny podmínky pro další rozvoj a modernizaci. Od roku 1998 byl postupně zaváděn nový řídící systém FOX I/A pro pomocné provozy s operátorským pracovištěm ve starém velínu . V roce 2000 byla uvedena do provozu nová jednotka FCC s FOX I/A a řízením z nového velínu 2520. V rámci projektu Reinstrumentace v roce 2002 bylo do nového velínu a FOX I/A převedeno řízení výrobního bloku z TDC 3000 Honeywell formou HOT CHANGEOVER za plného provozu rafinerie. Se zrušením místních velínů (FARů) přešlo do nového velínu také řízení pomocných provozů. Ve všech projektech se vycházelo ze standardů SHELL. Řídící funkce byly důsledně odděleny od zabezpečovacích. DCS byl oproštěn od činností, které nesouvisí s řízením. Z hlediska informační nadstavby se stal jen zdrojem dat pro zpracování na úrovni IT. Po reinstrumentaci byly realizovány další projekty (Čistá paliva) a letos jsme vedle Sdružených projektů provedli upgrade s přechodem na MESHovou strukturu. 7/ V tabulce jsou uvedeny milníky a k nim přiřazeny počty pracovníků SW/HW, údržby instrumentace a počty operátorů. Neuvádím počty venkovní obsluhy, které také byly výrazně redukovány. Rozvojem automatizace došlo ke zvýšení dostupnosti zařízení, spolehlivosti, zvýšení bezpečnosti, zlepšení technologie, snížení give away a podobně. Nejlépe vyčíslitelná je oblast úspory pracovníků. Porovnáním počtu operátorů a rozsahu smyček jako měřítka rozsahu řízené technologie lze usoudit, že počty operátorů klesly na čtvrtinu oproti stavu před centralizací. V počtech pracovníků údržby instrumentace je pokles ještě výraznější. Ten souvisí s přechodem z pneumatické instrumentace na elektronickou a s její spolehlivostí. U vysílačů se (podle typu přístrojů) odhaduje střední doba mezi poruchou mezi 100 až 1000 roky. Spolehlivost celého obvodu dnes ovlivňují ostatní vlivy počínaje volbou vhodné instrumentace, její konstrukcí a instalací, vlivy technologie až po vyhodnocovací zařízení. Snižování počtů pracovníků probíhalo v relativně dlouhém časovém období v rámci generační výměny operátorů a pracovníků údržby, převáděním pracovníků na jiné odbornosti a podobně, takže nebyl zaznamenán žádný sociální dopad. 8/ Po vstupu fy. SHELL do České rafinerské začala technická divize spoluvytvářet a používat nové standardy, kter é se opíraly o standardy a doporučení SHELLů. V oblastech, kde se vyskytují české i SHELL standardy souběžně tam v CRC platí vždy ty přísnější. Standardizace byla podmínkou pro realizaci nových projektů.
Jednotka FCC byla vyprojektována a dodána holandskými firmami prakticky bez naší účasti. Standardizací jsme se vyhnuli potížím či dohadům. V úvodní fázi projektů instrumentace se vyhodnocovala nebezpečnost zařízení podle IPF klasifikace a klasifikované obvody byly zapojeny do IPS Triconex. Pro sjednocení konfigurace DCS/IPS byla vytvořena FDS která velice podrobně definuje chování systému, od SW po grafiku. Z předešlého DCS jsme převzali standardizaci textů, popisů, názvů proměnných a produktů, alarmových hlášení, Hart tagnaming a pod. Součástí standardizace jsou i knihovny Non standard typicals a faceplate. Značnou měrou pomohlo i povinné užívání INtools /později SPI/ pro všechny projekty. Oproti předešlému systému se výrazně změnila grafika. Zvýšila se hustota informací na displejích, panelovou nástavbu nahradily sady přehledových displejí. Změnila se barevnost displejů. Od původní grafiky která barevně odlišovala např. media typu zelená voda, červená pára jsme přešli na nový typ zobrazení: Všechno co funguje správně je barevně nevýrazné, šedé. Výrazné barevné odstíny upozorňují na odchylky , alarmy. Inženýrské jednotky jsou normalizovány, takže na displejích jsou uvedeny pouze číselné hodnoty, bez tagname a jednotek / s výjimkou nestandardních, ty jsou uvedeny/. Informace modu regulátoru nebo hodnotě SP jsou přístupné z faceplate. Data pro management nesouvisející s řízením provozu jsou z DCS vyčleněna. Operátor k nim má přístup přes síťové PC integrované do jeho pracoviště. Zvolená hustota displejů vychází ze SHELL názoru, že jeden operátor dokáže řídit jednotku až do počtu 500 regulačních smyček. . Nepochybně je možné řídit provoz uvedeného rozsahu jedním operátorem, ale je zde riziko, že při potížích operátor jednotku nedokáže uřídit a odstaví ji. V Kralupech připadá na jednoho operátora cca 200 smyček. Podobně je tomu i s alarmy, podle doporučení by jednomu operátoru za ustáleného stavu nemělo přijít více než 10 alarmů za hodinu. Do operátorských pracovišť kokpitůjsme sdružili všechno co potřebuje operátor: pracovní stanice, ovládací panely s odstavovacími spínači, CCTV, komunikační prostředky, intranet. Přidávání jakéhokoliv dalšího PC, pomocného zařízení, či zobrazovačů do kokpitů je striktně zakázáno. 9/ V roce 1997 se rozhodovalo o rozsahu nových investic a modernizaci v oblasti řízení technologických procesů. Výběr vycházel ze záměru managementu sjednotit řídící systémy v obou rafineriích. Vycházel z idealistické představy, že bude možný pohyb a zástupnost specialistů DCS/IPS mezi oběmi lokalitami. Byl zvolen standardní postup: Vybrané firmy byly požádány o cenovou nabídku řízení rafinérského provozu podle jednotného zadání. Byly poptány fy. Yokogawa, H&B, Honeywell a Foxboro. Nabídky byly vyhodnoceny podle klíče, kde největší váhu měla cena, technická úroveň, dostupnost podpory v ČR, znalost standardů CRC. Nabídka Yokogawy byla vyloučena, protože neměla zajištěnu podporu v ČR. Podobně neprošla ani nabídka Ř S. H&B. Systém měl nadčasovou úroveň v části nadstavby, např. logování operátorů vázané na typ operátorského prostředí – operátor v zácviku mohl mít p zalogování přístup VIEW ONLY, zkušený operátor přístup k ladění smyček apod. Procesní část nebyla na vhodné úrovni. Výběr se zúžil na HONEYWELL a FOX. Honeywell se zdál být na konci „evolučního vývoje“, FOX I/O byl modernější systém. V typové nabídce přišlo FOXBORO s nižší cenou. Holandští zástupci FOXbora mohli nabídnout zkušenosti se standardy SHELL a při projednávání nabídek byla znalost standardů a názvosloví SHELL výraznou výhodou. 10/ V roce 2000 byla uvedena do provozu jednotka FCC řízená z nového velínu novým DCS/IPS. Celý projekt byl realizován fy. Fluor Daniel v Holandsku . HW a SW byl
připraven týmem z Baarnu. Konfigurace byla výsledkem práce několika různých teamů z různých zemí, ale díky dobře definovaným standardům jsme získali konzistentní SW. Hladkému najetí jednotky výrazně pomohl i simulátor, který používal grafiku obdobnou té, která byla vytvořena pro DCS. Po najetí FCC jsme ovládali rafinerii ze dvou velínů na dvou různých systémech a objevovaly se potíže se vzájemnou komunikací. V roce 2002 jsme zahájili reinstrumentaci výrobního bloku. Zastaralou pneumatickou instrumentaci jsme nahrazovali elektronickou, připojenou do nového DCS/IPS v novém velíně. V letošní zarážce jsme realizovali Sdružené projekty , připravili upgrade s přechodem na MESH ovou strukturu a rozšíření velínu o pátý kokpit. Starší operátoři kteří byli zvyklí na klasický velín si stěžovali na nižší přehlednost řízení oproti klasické panelové nadstavbě. Zvažovali jsme řízení z kokpitů s přidanými velkoplošnými obrazovkami pro celkový přehled. Při přípravě projektu jsme otevřeli otázku filozofie řízení provozu. Nabízelo se řešení typu hlavního a pomocných operátorů, podobně jako v BEWAGu v Berlíně nebo na MERu. . Dospěli jsme k názoru, že vzájemné technologické vazby nejsou natolik rozsáhlé, aby bylo účelné zavedení velkoplošných monitorů . Po zvážení (i ekonomické části) jsme zachovali původní uspořádání řízení: Operátor má ke kokpitu přiřazeny provozní soubory včetně příslušných HW spínačů a je za přiřazenou oblast plně zodpovědný. Ostatní vrchní mistr, technologové a vedení provozu mají k dispozici xterminály mimo velín s View only přístupem. 11/ HOT CHANGE OVER proběhl v roce 2002. Snímek velínu je jen pro ilustraci postupu. Předávání obvodů po přepojení mezi pracovišti probíhalo písemně. Přepojené obvody se označovaly přelepením červenou izolepou. V nových kabinetech FOX měly všechny obvody po prozvonění rozpojené nožové svorky. Sepnuté svorky byly indikací, že obvod je již používán. Oproti projektu FCC se využití AMS pro loop checky ukázalo jako nevhodné. Důvodem byl chybějící HART u stávající použité instrumentace, chyby v Hart tagnamech nových přístrojů a nutnost denního scanování celé sítě vzhledem k „dynamice“ průběhu projektu. Při přepojování došlo k několika dílčím výpadkům provozu . Vždy kvůli změnám v HW a SW typicky nestandardnímu SW nebo nedokumentovaným změnám instrumentace. 12/ Při realizaci projektů jsme se setkali s řadou problémů. Školou pro nás byl projekt FCC, kde jsme nastoupili do rozjetého vlaku. Neměli jsme zkušenosti s tak velkým a mezinárodně vedeným projektem, neznali jsme dobře obecné standardy které byly používány, měli jsme potíže domluvit se. Angličtina byla jazykem projektu, ale vzhledem k mezinárodnosti teamu tam byla kromě „české“ angličtiny také německá, italská, francouzská, jugoslávská a mnoho typů americké. Specifická zkušenost bylo pro nás jednání s Holanďany. Jednání byla vždy korektní , ale obchodně mnohdy na ostří nože. Problém byl v personální oblasti. Investovali jsme přes milion korun do školení SW pracovníka. Aby byl dobře připraven, zúčastnil se také konfigurace SW v Baarnu. Nakonec ale SW pracovník před najetím odešel z CRC, takže jsme museli hledat náhradu. Vlastní najetí FCC bylo spojeno s řadou potíží s „neusazeným“ systémem. Kvůli výpadkům v komunikaci jsme občas zažívali Modrou smrt. Mladí operátoři, kteří přišli k DCS ze simulátoru se sžili se systémem velice brzy. Potíže měli ti starší, kteří byli zvyklí na panel a předešlý systém. Trenažér byl před lety zrušen a nyní se objevují potíže s tím, že operátoři zapomínají a chybují. Alarmování: Na základě stížností operátorů jsme provedli několik cyklů rozborů alarmů. Společně s operátory, technology a instrumentací jsme počty výrazně redukovali, nicméně do budoucna bude potřeba zvážit celou filozofii alarmování. Na jedné straně si provoz stěžuje na
množství alarmů, ale na druhé straně v seznamech opatření pro řešení provozních problémů je vždy požadavek na ustavení nových alarmů. To že používáme stejný systém jako Litvínov bude dále uvedeno jako výhoda, ale je nutné přihlédnout i ke ztrátě konkurenčního prostředí. Sloučením veškerého řízení do nového velínu 2520 jsme se stali zranitelnější a musíme věnovat zvýšenou pozornost spolehlivosti infrastruktury napájení, klimatizaci, zemnící soustavy a pod. 13/ Instalací FOX I/A jsme získali nový moderní systém řízení a zabezpečení provozu jehož součástí jsou SW aplikace MVC, WASP, OMM, TIS a pod. Operátorská pracoviště zahrnují řídící a zabezpečovací zařízeni, včetně F&G, CCTV a komunikačních prostředků – telefonů, vysílaček, Intranetu a ovládání hasicích zařízení. Sjednocení systémů s Litvínovem – HW a SW vedlo k minimalizaci ND v konsignačních skladech, jedné smlouvě o podpoře s Invensysem a možnosti předávání zkušeností mezi lokalitami. Centralizací a novými projekty jsme systém rozšířili téměř trojnásobně a nenarazili na kapacitní problémy. K limitům se blížíme pouze v oblasti komunikace s IPS. Po upgrade jsme otevřeli systém pro použití OPC serverů pro bilanční systém a do budoucna pro advance projekty včetně optimalizací od jiných stran. Máme otevřenou cestu pro Fieldbus apod. Z hlediska rizik napadení systému máme systém striktně oddělený od „světa IT“ firewally, můžeme integrovat PLC a dosáhli jsme vysoké standardizace dokumentace, SW, HW , typicals a HMI. Všechny projekty jsou vytvářeny uloženy a spravovány elektronicky v jednotné DB SPI. 14/ Instalace systémů i upgrade kterými jsme prošli se vždy prováděly na základě projektů. Všechny potíže měly společné příčiny: Nedokumentované změny v části DCS a IPS a v instrumentaci které se nepodařilo objevit při přípravě projektů, nedokumentované změny nastalé v průběhu přípravy projektů po zmrazení DB. Použití nestandardního a nezdokumentovaného SW a používání knihoven se shodnými názvy objektů s rozdílným chováním Ztráta dat z důvodu nedostatečné úplnosti záloh a chybám v obnově DB. Doporučení: Je nutné mít funkční a účinný Systém řízení změn , zvláště pro dokumentování změn v období commissioningu pro bezchybnou dokumentaci AS BUILT. Mít dostatečně podrobný systém standardů pro DCS/IPS – vycházející z obecných standardů (u nás DEPů) a standardů zaměřených na systém typu FDS, non standard typicals, faceplate, textů, názvů veličin, negr. Jednotek apod. Pro projekční činnost potom standardizaci (u nás SPI) a tyto systémy udržovat aktuální. Důsledně trvat na dodržování těchto standardů a nepřipustit žádnou odchylku. Mít vytvořený systém zálohování včetně manipulace a ukládání záloh je samozřejmostí, ale je nutné věnovat pozornost zavádění dat ze záložních medií, kde často dochází k nepříjemným pochybením. podobně je potřebné udržovat v pořádku dokumentaci HW včetně konfigurace polní instrumentace. vést ke každému systému Provozní deník se zápisy o HW problémech a jejich řešení a odděleně o SW změnách zvláště pokud vznikají mimo cykly pravidelného zálohování tak, aby bylo možné zrekonstruovat starší zálohu pro případ havárie aktuální zálohy zavést systém kooperace s údržbou polní instrumentace, zvláště vzhledem k Hart aplikacím typu Aset Manager Systém, Plant Ressource Manager, Valve manager které umožňují
vzdálený přístup z prostředí IT ke konfiguraci polních přístrojů. Při nekontrolovaném přístupu mohou přinést komplikace, které by mohly být přičítány DCS/IPS. 15/ road map V krátkodobém výhledu je pořádek po zarážce a upgrade. Je nutné zrevidovat veškerou dokumentaci k DCS/IPS , systémovou, výkresovou, včetně standardů a FDS. Dále je potřeba opravit SW a HW dokumentaci po všech projektech ze zarážky včetně výkresů a tabulek kabeláže a optik. Dalším úkolem je revize a zajištění zabezpečení systému. Centralizací celého řízení do jediného celku a příklonem k WINDOWS se důležitost zabezpečení stala mnohem důležitější. Podle odborných seminářů se zdá, že riziko napadení hackerem zvenčí není příliš pravděpodobné. Průnik zvenčí k DCS je možný pouze přes strukturu IT . Největším rizikem je zavirování nebo napadení zevnitř, ať již nechtěné nebo záměrné. Rizikem může být také chyba SW inženýrů, případně nezabezpečený přístup do prostor se zařízením. Cílem by měl být řízený přístup k veškerému zařízení a důsledné používání antivirových nástrojů na celém systému. Výzvou pro FOXBORO je způsob aplikace antivirových prostředků a možnost automatických update. Zásadně je nutné zamezit přístupu ostatních stran pomocí laptopů a přenosných zařízení. Mimo DCS a IPS může být zdrojem problémů i nedostatečně zabezpečený přístup z IT prostředí různými aplikacemi přímo k instrumentaci nebo PLC. Vzhledem k výše uvedeným rizikům je nutné připravit Recovery plan. Jedná se o vytvoření systému a postupů pro případ nutnosti obnovy celého systému. Plán musí obsahovat postupy pro obnovu operačního systému, aplikačního SW , komunikací a zavedení dat ze záloh včetně pořadí podle důležitosti. Musí také obsahovat informace o uložení potřebných záloh, jejich značení a přístupová hesla. Alarmová problematika je téma pro samostatný seminář. Alarmy vychází ze zadání projektů, jsou zavedeny do DCS a údržba DCS/IPS je za jejich stav zodpovědná. Podobně je tomu i s blokovacími limity. Změna je možná jen na základě písemného dokumentu „Změna zařízení“ kterou vydává žadatel. Teprve po schválení provozem a technologií je připravená k realizaci. Nepružnost tohoto systému má dostatečně odrazující účinky. V případě sporu by bylo obtížné vysledovat a dokladovat příčinu změny od projektového stavu. Cestou je zachycení současného stavu výpisem aktuálních hodnot všech alarmů a jejich kontrola ze strany provozu a případná redukce seznamu. Zásadní otázkou je ale, zda vůbec má být údržba správcem alarmových limitů. Technologové zadávají výrobě podmínky provozování v t. zv. Technologických kartách. Pokud technologie zadává teploty, velikosti nástřiků apod., bylo by zcela logickou součástí i přímé zadávání alarmových hodnot technology včetně převzetí zodpovědnosti za tuto oblast místo údržby. Současný stav vede k tomu, že řada operačních mezí je zbytečně široká jen proto, aby nebylo potřeba měnit alarmy při každé změně technologie. Teoretickým řešením by bylo i zavedení odchylkových alarmů, ale to je v rozporu se zásadou povinného předalarmu v DCS před dosažením blokovací úrovně v IPS. V zabezpečovacím systému je situace mnohem lepší: jakákoliv změna je spojena se změnou čísla verze. Dokumentujeme protokolárně výchozí číslo instance při předání do provozu a v provozní knize IPS vedeme číslo „Změny zařízení“ spolu se změnou čísla instance. V případě nutnosti bychom měli být schopni dokladovat veškeré změny až k původnímu předanému stavu. Potíže jsou s alarmy v období najíždění a odstavování .Čeká nás přehodnocení alarmovacího systému rozdělení alarmů na fatální a běžné včetně úpravy priorit a změn přiřazení indikací k Alm. Annc. a WASPu . Dále přepokládáme vytvoření souboru alarmů pro najíždění a sjíždění zařízení na vyhrazených stanicích kokpitů.
Z nových projektů připravujeme realizaci projektu nového bilančního systému protože současný původně z r. 1974 nevyhovuje přepracovatelskému způsobu provozování rafinerie. Otevřením systému a instalací OPC serverů budeme moci obousměrně přenášet data mezi DCS a serverem na IT straně pro bilanční zpracování. Otevřený je záměr integrace expedičních zařízení kde by rozšíření aplikace OMM přineslo výrazné zjednodušení a zvýšilo dostupnost zařízení. V minulosti proběhly prověrky SIF PRO týkající se zabezpečení všech provozů. Některé zjištěné nedostatky byly vyřešeny o zarážce 2009, k řadě se budeme vracet. Dalším úkolem je příprava dokumentace na audity. Typické jsou metrologické audity směrem ke stanoveným měřidlům certifikace nádrží a přenosů dat, audity akcionářů které zajímá např. způsob výpočtů objemů a hmoty v nádržích / korekce na tvar nádrží, korekce údaje hladinoměrů vzhledem k váze plovoucích střech, započítání parního prostoru /ullage area/, v TISu. audity pro životní prostředí a obchodování s emisními povolenkami audity finančního/celního úřadu pro sledování etylalkoholu bude –li nový „lihový zákon“ klasické audity IBP pro sledování zabezpečení vyhrazených zařízení /pecí/ audity elektrického zařízení nepochybně i audity týkající se legálnosti užívaného SW. Dalším důležitým úkolem je zavedení systému školení za účelem využívání všech možností systému jak operátory, tak technology a pracovníky údržby polní instrumentace. Za deset let užívání systému se všichni omezili na obvyklé rutinní funkce a řada možností systému není využívána. SW pracovníci jsou zbytečně zatěžováni požadavky na činnosti, které jsou běžně přístupné z operátorského prostředí. Pokud se CRC nevrátí zpět k trenažéru je nutné opakovaně školit operátory z logiky stávajícího zabezpečení aby se předešlo skoronehodám z neznalosti funkcí , z chybného a zbytečného forsování a chyb při provádění IPF testů. Dotazy. ?? Děkuji, J. Kraus 7. 12. 2009
