Sběr dat z výroby z pohledu systémového integrátora

Sběr dat z výroby z pohledu systémového integrátora

Příspěvek je věnován problematice řízení automatizačního projektu zaměřeného na sběr dat z výroby. Důraz je v něm kladen zejména na přípravné a ukončovací fáze projektu, jejichž průběh je zatím často neuspokojivý, a stávají se tak zdrojem problémů pro objednatele i dodavatele řešení. Autor těží z literatury i ze zkušeností, které získal jako programátor, projektant i vedoucí projektů monitorovacích a řídicích systémů pro stroje a zařízení.

Systémy pro sběr výrobních dat

Hlavním účelem sběru dat je zajistit dohled nad sledovaným technologickým (výrobním) procesem. Analogií je např. měření mezičasů a odstupů závodníků – běžců během závodu. To jsou po závodě údaje pro trenéra mnohem důležitější než samotné umístění jeho svěřence. Pro diváka a sponzory je naopak nejdůležitější konečný výsledek – to odpovídá pohledu z pozice objednatele (uživatele).

Zařazení
Systémy pro sběr výrobních dat (dále jen SSD) se liší od klasických informačních systémů (IS) určených pro podporu podnikové administrativy. Obvykle jsou přímo napojeny na strojní zařízení, z nichž sbírají data pro archivaci, a poskytují informace úzké skupině lidí spjatých s výrobou. Výpadek SSD v převážné většině případů znamená ztrátu dat. Naproti tomu však jím sbíraná data mají, v porovnání s daty uloženými v plánovacích systémech typu MRP (Manufacturing Resource Planning) či ERP (Enterprise Resource Planning), poměrně malou hodnotu (pominou-li se provozy, kde je třeba dokládat dodržení technologického postupu u každého jednotlivého kusu, jako např. v leteckém průmyslu nebo řízení toků materiálu a podobné operace nezbytné pro samotnou výrobu). Při použití terminologie řídicích úrovní (L0 – úroveň technologického zařízení, L1 – úroveň signálů, L2 – úroveň řízení technologického procesu, L3 – úroveň řízení výroby, L4 – ekonomická úroveň podniku) jsou SSD součástí úrovní L2 a L3. Data jsou obvykle přímo čtena z úrovně L1 (výjimečně z L0) a získané výsledky jsou v případě potřeby přenášeny do L4.

Význam
Úkolem SSD je data sbírat, zpracovávat (transformovat) a archivovat. V SSD je většinou obsažen nástroj k alespoň částečnému vyhodnocení informace obsažené v datech. Zatím však neexistuje spolehlivý způsob, jak automatizovat interpretaci dat (zjistit, co se skutečně stalo). Automatizovaný sběr výrobních dat má význam především pro:

• mistry a vedoucí provozů, jimž může nabídnout okamžité informace o výrobě a výrobním zařízení, možnost kontroly na dálku, podklady k objektivnímu hodnocení pracovníků atd.,

• technology, kterým umožňuje do detailu sledovat realizaci technologického postupu včetně nastavených hodnot (možnost vymáhat nápravu na základě zjištěné technologické nekázně dává technologům mocný nástroj pro boj s typickou lidskou snahou zjednodušovat si práci; významná je z pohledu technologie i báze historických dat, dovolující potvrzovat či vyvracet hypotézy a alespoň částečně eliminovat tendence směřující ke „znovuobjevování kola„),

• kontrolu jakosti, kde automatizace nabízí žádoucí vyloučení rutinních činností při vlastním sběru dat a umožňuje pracovníkům soustředit se především na zpracování a vyhodnocení dat (zjednodušeně řečeno, mnohdy by se vyplatilo pořídit SSD jen pro kontrolu jakosti, pak ovšem může být přínos ostatním profesím vnímán jen jako postranní efekt s důsledkem pomalejšího – nebo i žádného – pronikání SSD do práce ostatních).

Ostatní profese v podniku již nepoužívají data ze SSD jako hlavní podklad ke své práci, ale spíše jako informativní údaje usnadňující rozhodování. Jedná se především o obchodní oddělení (stav zakázky, funkceschopnost a výkonnost strojů), údržbu (přehled o poruchách, činnosti, nastavení apod.) a logistiku (dodávky materiálu, stav zakázek, odběr materiálu). Přestože je význam SSD pro tyto profese někdy i značně omezený, nemusí být při správném zavedení zanedbatelný. Vždy jde o produktivitu práce a jakýkoliv způsob, který ji při přiměřených nákladech zvětší, je přínosem.

Vlastnosti
Systémy sběru dat z výroby bývají řešeny nezávisle na ekonomických IS. Je tomu tak z důvodu správy (data je nutné spravovat tak, aby nedošlo k jejich ztrátě). Další jejich významnou vlastností jsou obrovské objemy archivovaných dat. Například při deseti strojích s výkonem po 2 000 výrobků denně a záznamu čtyř údajů o každém z nich se za rok nashromáždí asi 20 milionů záznamů. Pro správnou činnost SSD je třeba vytvořit datové mosty k ostatním IS, aby data vstupovala do systému pouze na jednom místě a byly vyloučeny nejen chyby, ale i zbytečná lidská práce. Rozsáhlejší požadavky na sběr dat se řeší samostatně (různé výroby, různé stroje apod.), jelikož nevýhody centralizovaného systému zde převáží nad náklady na distribuovaný systém. Hlavními důvody pro distribuované řešení SSD jsou údržba a spolehlivost. Také je jednodušší odstavit menší provoz než celý závod. Dalším faktorem je, že hlavními uživateli SSD jsou právě pracovníci v provozu, kteří mají snahu si systém upravovat podle vlastních potřeb (úpravy na zakázku, využití pomocných datových polí apod.). Tyto úpravy by jen zbytečně zatěžovaly pracovníky jiného provozu.

Nanejvýš žádoucí je také koncipovat SSD jako bezúdržbové, jelikož pracovníci udržující IS v provozech nebývají tak zdatní jako správci hlavních firemních serverů. Ti většinou nemají (a ani nechtějí mít) čas starat se o méně důležité systémy, navíc řešené pro ně odlišným způsobem.

Realita
Znalosti lidí, již se o sběr a vyhodnocování dat starají na úrovni rozhodování o investicích, obvykle nereflektují skutečné potřeby pracovníků z výroby. Stává se, že ve firmě chybí koordinace mezi jejími jednotlivými útvary.

Význam dat

Kvalitní informace sice nejsou jedinou podmínkou správných rozhodnutí, ale jsou podmínkou nutnou. Bez kvalitních a rychle dostupných informací se pracovníci podniku neobejdou. K rozhodování na základě výstupů ze SSD je třeba znát historii dat. Bez ní lze využít pouze ta výrobní data, která jsou exaktně definována. Mezi údaje, které je možné posuzovat jen při znalosti jejich historie, patří např. takt nebo využití stroje. Těžiště problémů zpravidla spočívá v metodice vyhodnocování údajů, která musí vycházet z jejich z stanovení.

Stanovení údajů
Na základě poskytovaných údajů se lze zodpovědně rozhodovat jen tehdy, jsou-li tyto řádně stanoveny. Až příliš často se lze setkat s vágně určenými údaji, o nichž se neví, jak vlastně vznikly. Takto (ne)vymezené údaje nepomáhají, ale matou.

Charakteristika každého údaje dat by měla obsahovat:

• typ snímače včetně principu měření, dále např. polohy referenčních bodů, umístění snímače atd.,

• přesnost převodní charakteristiky včetně její linearity,

• frekvenci vzorkování (zde je třeba, aby byl splněn Shannonův-Kotelnikovův teorém, tj. frekvence vzorkování musí být nejméně dvojnásobkem největší významné frekvence obsažené v měřeném signálu),

• použitý způsob výpočtu, nejde-li o přímé měření (někdy se např. volí algoritmy založené na statistických metodách, z nichž každá má své silné i slabé stránky, o nichž je dobré vědět),

• časovou vazbu, neboť údaje se často vkládají do systému až po vyhodnocení z dat, které může trvat i několik minut až hodin, a proto je dobré, aby bylo určeno, kde na časové ose údaj vlastně leží,

• měřicí jednotku; je-li to jen trochu možné, je vhodné ukládat data v základních jednotkách soustavy SI, což podstatným způsobem zjednodušuje případné výpočty (nevyskytují se obvyklé chyby v přepočítávacích konstantách); dále by se měly používat stejné jednotky na všech zařízeních v daném provozu (odstrašující je příklad americké kosmické sondy, která se v důsledku záměny jednotek podle soustavy SI s anglo-americkými odmlčela po prvním pokusu o komunikaci se Zemí).

Logická správnost

Sbíraná data je třeba volit tak, aby vytvářela ucelený obraz reality. Je vhodné předem stanovit, jak podrobně z dat rekonstruovat minulé děje. V této části přípravy se bude třeba vždy rozhodnout mezi jednoduchostí (a tím i menšími náklady a rychlejším zavedením) a podrobným popisem minulosti (většími náklady, delší dobou zavádění a méně přehledným uživatelským rozhraním).

V praxi se lze často setkat s požadavky na archivaci „všeho„. Když potom zákazník obdrží seznam několika desítek, popř. i stovek nastavovaných a měřených údajů, většinou nastane rozčarování nad množstvím údajů, které by měly být zaznamenávány. Takový systém po realizaci nepřináší uživateli požadovaný efekt. Je tomu tak proto, že vyškolení obsluhy je časově náročné a mnohá ukládaná data nemají skutečnou informační hodnotu, ale jsou v systému jen tzv. do počtu.

Mezi další chyby patří sběr údajů, které je možné vypočítat z jiných výchozích údajů. Ty v principu neposkytují žádnou jinou informaci než tu, která je obsažena ve výchozích údajích.

Opakem je sběr údaje, který má význam jen po sloučení s jiným: typickým příkladem jsou dvouhodnotové (bitové) signály, které je vhodnější sloučit do jednoho kombinovaného signálu.

Vhodným výběrem sbíraných údajů je možné dosáhnout značného zjednodušení práce se SSD bez ztráty informační hodnoty. Nevhodným výběrem nebo nevhodnou kombinací se lze dostat do stavu, kdy bude systém zcela nepoužitelný. Ať již z důvodu chybějících údajů, nutných pro správné rozhodování, nebo naopak pro přebytek údajů bez skutečné informační hodnoty. Při výběru je nutná velmi dobrá spolupráce všech složek, které budou data ze SSD využívat.

Volba názvosloví
Názvosloví by mělo být voleno tak, aby jasně, s použitím mnemotechnických zkratek, vystihovalo měřený údaj. Opět by mělo být jednotné alespoň pro daný provoz. Je velmi vhodné, jestliže se volí názvosloví v souladu s ČSN nebo jinou (státní) normou. Jeho výhodou je, že mu rozumí většina odborné veřejnosti přicházející do styku s daným oborem. Avšak místním pracovníkům, kteří nejsou v oboru šířeji vzděláni a jsou „odchováni„ v „odborném„ jazyce místní skupiny, může způsobovat i značné problémy. Velkým problémem jsou „počeštěné“ anglické výrazy, které navíc nejsou zcela výstižné ani v originále. Za mnohé zde lze uvést např. slovo kvitace, kdy zřejmě má jít o alternativu anglického quit (v základním významu nechat, opustit).

Nejlépe si lze volbu vhodného výrazu ověřit tak, že osoba dostatečně znalá oboru se pokusí „rozluštit„ navrhované zkratky nebo složeniny. Pokud s tím bude mít problémy, je rozumné hledat výstižnější pojmenování.

Výstižné názvosloví pomůže vyhnout se mnohým dlouhým vysvětlováním a mnoha nedorozuměním. Než začne kdokoliv vymýšlet svoje vlastní slova, bylo by patrně vhodné otevřít si nějaký slovník a pokusit se vystačit s některou již zavedenou alternativou.

Realita
V praxi se po definici údaje začíná pátrat až tehdy, když nastanou problémy. Tím se ale ztrácí hlavní smysl sběru dat. Často se totiž stává, že data v databázi jsou zatížena systematickou chybou, která vylučuje jejich použití pro řešení problému. Rovněž je možné, že se někdy rozhoduje na základě údajů, o kterých se neví, jak se k nim dospělo.

Stanovování cílů

Dostaví-li se pocit, že již nastala vhodná doba k investování do SSD, je třeba realisticky stanovit cíl. V tomto směru je asi nejvhodnější obrátit se na určitou firmu, jež se vývojem nebo implementací SSD zabývá.

Jestliže se reálný cíl podaří stanovit, je třeba začít na něj připravovat svoji firmu (provoz, dílnu). Tato kapitola pojednává o tom, jak správně postupovat při stanovování cílů, které problémy lze očekávat a jak se jim vyhnout.

Lidé
O tom, zda bude projekt úspěšný a zda jeho výsledky budou odpovídat představám, rozhodují především lidé, kteří budou za objednatele pracovat na analýze současného stavu a na vytyčení cílů. Nemalou měrou k úspěchu (nebo také neúspěchu) rovněž přispějí ti pracovníci, kteří budou systém používat těsně po jeho zavedení.

V počáteční fázi hraje velmi důležitou roli nadšení z něčeho nového. Pro mnoho pracovníků je možnost podílet se na přípravě nového projektu velkou motivací (jedná se zvláště o pracovníky v útvarech kontroly kvality, údržby, o mistry apod.). Mnohdy je však reakce spíše záporná, zvláště je-li s novým systémem zaváděna i výpočetní technika, na kterou pracovníci nejsou zvyklí.

Základem úspěchu je aktivní spolupráce mezi dodavatelem a odběratelem. Jedná se např. o etapu ověřování činnosti SSD, kdy se pracovníci odběratele učí pracovat se systémem a zároveň si ověřují, že systém plní to, co má. Naučí se, jak si údaje ověřit a jak jsou data zpracovávána a celkově získají k systému důvěru. Aktivní spolupráce v etapě jeho ověřování má velmi pozitivní vliv také na kvalitu zavedeného SSD. Jelikož je při ní dodavatel nucen v praxi prokazovat správnou činnost všech částí systému, je podstatně omezeno riziko vzniku pozdějších chyb.

Lze se setkat se situacemi, kdy objednatel, byť budoucí uživatel systému, není ochoten při ověřování systému ani asistovat, a kdy se spoléhá na poskytované údaje, aniž ho zajímá, jak se k nim dospělo. Většinou je tomu tak tehdy, je-li na objednatele vyvíjen tlak auditory nebo jeho zákazníky, aby zavedl SSD, a není veden vlastní potřebou být informován o dění v provozu.

Normy a metodiky
Většina organizací má své vlastní předpisy (interní normy), které upravují a doplňují obecně platné právní a technické normy a předpisy (ČSN, ISO, EN, VDA apod.), a v některých případech také uvádí výjimky z těchto norem.

Při stanovování cílů je vhodné postupovat podle zmíněných norem. Mohou rychle navést na cestu, ke které by se jinak asi stejně – většinou metodou pokus – omyl – dospělo. Při zavádění SSD je výhodné nejprve zvolit některou z obecných metodik (převážně na základě matematické statistiky), ověřit její vhodnost bez SSD a teprve po jejím akceptování rozhodnout o zavedení SSD pro uvedenou metodiku. V žádném případě není dobré začít sbírat data a až poté hledat způsoby, jak je využít. To by odpovídalo stavu, kdy si např. rodina koupí auto a teprve pak hledá, kam jím bude jezdit.

Cíle
Stanovování cílů není zcela běžná práce. Je tomu tak proto, že každá výchozí situace je jiná: jednotlivé podniky mají na úrovni výroby jiné reálné problémy, jiné personální obsazení a jiný způsob administrativního řízení. Pravděpodobně nejlepší je navštívit dodavatele, popř. i jiné podniky, a inspirovat se tím, jak zde řeší své problémy. Získané informace je třeba použít jako náměty, nikoliv jako dogmata. Mnoho námětů lze získat i shromažďováním připomínek vlastních pracovníků, popř. konzultacemi se specializovanými agenturami či vysokoškolskými pracovišti.

Fáze následující po uskutečněném průzkumu je již přípravou na analýzu. Jednotlivé náměty je třeba kategorizovat a na základě dobré znalosti vlastní situace a s jejím využitím stanovit reálné cíle. Často vytváří zásadní bariéry v používání SSD (obecně čehokoliv) právě neznalost situace ve vlastním podniku.

Výsledkem etapy stanovování cílů by měl být investiční záměr (nebo naopak důkaz o tom, že investovat do této oblasti není rentabilní). Ten je výchozím bodem analýzy, která znovu otevře všechny jeho body.

Zde se lze setkat se dvěma extrémy. První vyžaduje maximum funkcí i maximální rozsah systému, druhý jen základní řešení s minimem funkcí a bez možnosti jejich rozšíření. Tento jev je kombinován s počtem záložních prvků v systému. Výsledek bývá hodně podobný nedávnému případu, kdy došlo k výpadku hlavního databázového serveru v systému navrženém tak, že byl schopen pracovat i bez něj. Obsluha pokračovala v práci a pracovník odpovědný za chod počítačové sítě byl o nově vzniklé situaci vyrozuměn až dvě hodiny po výpadku. Následkem toho byl stav, že v hlavní databázi nebyly uloženy údaje o zakázkách, které se v té době dostaly do výroby. Přímo na výrobu zmíněný výpadek neměl podstatný vliv, zato na administrativu značný. Bylo totiž nutné všechny údaje zkontrolovat a ručně upravit.

Jedním z klasických problémů při odhadování toho, co si lze dovolit pořídit, je, že cena systému není přímo úměrná jeho funkčním schopnostem. Většinou se postupuje tak, že se nejdříve vloží značné finanční prostředky do pořízení základní množiny funkcí. Následně drobná investice z pohledu koncového uživatele přidá stejný počet funkcí jako počáteční investice (obr. 1). Problémem levných systémů bývá, že ve výsledku většinou jsou nejdražší.

Dobře zpracovaný seznam cílů včetně priorit je základem pro vykonání analýzy. Obecně platí, že vhodnější je pracovat se širším seznamem cílů, ale zároveň je třeba účelně zacházet s prioritami.

Realita
V praxi bývají cíle specifikovány velmi povrchně, popř. se jejich stanovení ponechává zcela na dodavateli. Občas se stává, že se vytyčení cílů zaměňuje s analýzou (studií) požadavků. Neexistence seznamu cílů a priorit často vede k ne zcela funkčnímu řešení s nežádoucími postraními efekty. V takovém případě také není v praxi možné přínos projektu (a to nejen zavedení SSD) objektivně ocenit.

Analýza

Jestliže se podařilo stanovit vhodné cíle, měla by nastoupit analýza. Termín analýza je v běžné praxi většinou synonymem pro analýzu i syntézu dohromady (analýza – zkoumání reality, syntéza – projektování řešení). Výsledky analýzy by měly poskytnout návod k dosažení stanovených cílů, popř. formulovat, proč jich dosáhnout nelze. Podstatou analýzy je:

• vymezení hranic, kterými jsou styčné body systému s okolím: tato na první pohled jasná věc nemusí být zcela zřejmá při samotné realizaci, zvláště je-li třeba koordinovat několik na sebe navazujících dodavatelů,

• vymezení funkcí, tj. určení funkcí, které bude systém plnit navenek: cíle představují pouze přání uživatele systému, která nemusejí být realizovatelná, nebo mohou obsahovat chyby v zadání (redundantní požadavky, chybějící funkce, krizové scénáře),

• analýza vnějších vazeb, popisující toky dat přes hranice systému: hlavním výstupem této části analýzy je posouzení možných způsobů předávání dat a integrování systému,

• analýza vnitřních vazeb, spočívající v úplném popisu řešeného problému, rozdělení řešení do samostatných bloků a návrhu vazeb mezi bloky,

• syntéza řešení, představující návrh řešení po technické i organizační stránce: teprve v tomto bodě je známa skutečná cena systému,

• analýza shody s cíli, ověřující, že výsledný systém bude plnit stanovené cíle,

• stanovení kontrolních bodů (milníků) spolu se seznamem etap, ve kterých se bude systém zavádět, včetně předpokládané úrovně funkceschopnosti, jíž bude v každé etapě dosaženo: systém etap umožňuje flexibilně reagovat na změny vstupních podmínek.

Výsledkem analýzy je zpráva, která popisuje současný stav, a návrh způsobu, jakým dosáhnout stanovených cílů, včetně kontroly. Během analýzy musí nastat shoda představ dodavatele a objednatele (obr. 2). Zpráva vycházející z analýzy je základním dokumentem, na základě kterého se uzavírá smlouva o dodávce SSD (či jiného systému). Někdy se lze setkat s analýzou označenou úvodní studie.

Analyzovat stav by měl dodavatel, jelikož součástí analýzy je i syntéza řešení. To musí být navrženo tak, aby odpovídalo technickým i finačním možnostem obou stran.

Realita
Analýza je obvykle založena na nejasných cílech, popř. zcela chybí. Tím se velmi zdržuje zavádění systému a jeho zapojování do okolí. Se zdržením jsou spojeny také podstatně větší náklady než v případě přímého vývoje. Pracovníci, kteří mají za úkol vykonat analýzu, mívají ještě další povinnosti, popř. nejsou dostatečně odborně připraveni na řešení problémů spojených se zaváděním nových principů a postupů.

V praxi se např. stalo, že na straně dodavatele byl analýzou pověřen pracovník, který nebyl schopen připravit základní diagramy pro tvorbu datových schémat. Ve spojení s chybami, kterých se dopustil při plánování návazných operací, postupovaly práce na projektu místo podle plánu metodou pokus – omyl.

Zavádění

Zavádění (implementace, uvádění do chodu) projektovaného systému do praxe je z pohledu objednatele nejméně vzrušující částí příběhu (z jeho pohledu se v podstatě nic neděje). Opak je ale pravdou. Při včasném přizvání objednatele k prvním výstupům je možné případné chyby odhalit daleko dříve, než budou zavlečeny do dalších částí systému. Dodavatel má pak na opravu chyb více času.

Doba potřebná k zavedení systému je velmi závislá na rozsahu projektu, dále na počtu nových metod, programů a zařízení a také na kvalitě pracovníků. Její závislost na rozsahu projektu není lineární. Důvodem jsou synergické jevy, které nastávají ve větších projektech.

Samotnou implementaci se doporučuje rozdělit do návazných etap. Důvodem je přirozený vznik kontrolních bodů a možnost reakce na změny. Rozdělení do etap je lepší variantou než jen plynulé rozšiřování systému také proto, že při stejném počtu výsledných funkcí je levnější. Důvodem je analýza, která musí být předem připravena pro všechny etapy. Tím jsou známy další následné kroky a systém je na ně připraven.

Pokus o implementaci příliš složitého systému (nemusí být složitý technicky, stačí organizačně) se snadno může změnit v těžko řešitelný problém. Hlavní příčinou obvykle bývají příliš velké ambice zúčastněných kombinované s omezenými znalostmi v daném oboru, popř. zanedbání některé z přípravných fází (obr. 3). Vždy je vhodnější postupovat podle hesla dvakrát měř a jednou řež.

Využití prototypů
S využitím techniky prototypů lze navržená řešení ověřovat, aniž je nutná jejich úplná implementace. Místo skutečného detailního aplikačního softwaru se vyvine jen částečně funkční „torzo„. Jde především o schválení uživatelského rozhraní, ověření, že jsou zobrazeny všechny vstupy a výstupy, ověření úplnosti tiskových sestav apod.

Použít prototypy přímo ve funkci definitivního aplikačního softwaru lze jen u malých projektů, které se dotýkají pouze velmi malé skupiny pracovníků (ideálně jednoho).

Realita
Průběžná kontrola postupu řešení projektů je již celkem běžnou praxí. Tvorba prototypů není příliš rozšířena pro svoji finanční náročnost (prototyp nelze použít pro nic jiného).

Integrace do reality

Po úspěšném naprogramování je třeba vytvořené dílo začlenit do současné reality. Tomuto postupu se říká integrace, popř. systémová integrace. Její podstatou je navázání a ověření vazeb mezi systémem a jeho okolím a dále ověření všech vnitřních vazeb.

Základním pravidlem zde je „rozděl a panuj„. Je-li to možné, je třeba složitější úlohy rozdělit na menší celky, postupně vkládané do systému při průběžném odstraňování chyb a nedostatků.

Objednatel musí být během fáze integrace velmi ostražitý, jelikož nejvíce chyb spočívá v nepochopení se (v případě dvou konkurenčních firem nemusí vždy jít o náhodu) v zajišťování služeb atd.

Rozsah fáze integrace se zvětšuje rychleji než rozsah systému. V případě větších projektů je nutné s ní počítat jako s významnou fází. Integraci ve většině případů zajišťuje generální dodavatel, popř. si ji zajišťuje sám objednatel. Jen výjimečně řeší integraci firma, která se jinak na projektu nepodílí.

Realita
V praxi se autor tohoto příspěvku setkal s vážnějšími problémy během integrace jen dvakrát. Poprvé při jednání s firmou, která tvrdošíjně odmítala poskytnout jakékoliv údaje o rozhraní svých strojů, přičemž odkazovala na to, že cokoliv, co bude zákazník požadovat, zrealizují její pracovníci.

Podruhé šlo o inženýrskou firmu, která měla dodat algoritmy pro výpočty při procesu tváření oceli. Ukázalo se však, že výpočty nefungují, jak by měly. Ve výsledku tato část projektu musela být označena za slepou větev (se všemi negativními důsledky). Tento jev by zčásti eliminovalo rozdělení projektu na etapy (a odpovědnější schvalování investic na straně objednavatele).

Ověřování

Ověření řešení je základním předpokladem pro jeho uvedení do používání. Rozhodně není vhodné, aby řešení ověřovali koncoví uživatelé. Jsou tím zbytečně stresováni, navíc namísto spolupráce je možné čekat lhostejnost nebo netečnost, v extrémních případech i pokusy o sabotáž. Důvodem je prudký nárůst požadavků kladených na tyto pracovníky, musí-li vedle ověřování nového systému souběžně vykonávat svou běžnou práci. Dalším faktorem jsou chyby v systému, které se uživatelé naučí obcházet. To vede k vytvoření nevhodných pracovních návyků (např. nefunkční export dat bude pracovník obcházet tak, že text zkopíruje do schránky a následně jej vloží do jiného programu, ze kterého jej teprve uloží).

Že bude vše bezchybně fungovat napoprvé, je v praxi pouze těžko dosažitelný ideál (jde spíše o náhodu). Proto je třeba všem testům věnovat pozornost, jinak se na chyby přijde až v době, kdy je již očekáván rutinní chod systému.

Vnitřní testy
Každý produkt by měl obsahovat sadu vnitřních testů, které lze spustit v laboratorních podmínkách. Tak by mělo být možné automatizovaně ověřit, zda základní funkce softwaru jsou v pořádku (např. výpočty daní, kontrolní součty, základní operace). Uvedené testy jsou určeny k tomu, aby při odstraňování určitých chyb nebyly do systému vneseny chyby jiné.

Předávací testy
Tyto testy se obvykle dělají jen jednou (nebo v malém počtu). Jejich úkolem je objednateli prokázat správnou funkci systému. Testy jsou zaměřeny přímo na oblast použití systému u objednatele. Je výhodné zapojit do nich všechny pracovníky. Ti si tak osvojí práci se systémem bez nebezpečí ztráty provozních dat.

Výsledkem testu by měl být dokument prokazující požadované funkční schopnosti systému.

Realita
V skutečnosti se testování velmi odbývá. Testy bývají zaměřeny pouze na základní funkce nutné pro okamžitou práci. Skutečně všechny funkce, zvláště při sběru dat, se obvykle netestují. Není výjimkou, že na závažné chyby se přijde až po několika letech.

Jako příklad lze uvést případ měření teploty provalku, kdy byl použit nevhodný algoritmus pro stanovení teploty. To bylo zjištěno a opraveno až po třech letech provozu.

Údržba systému

Každý reálný systém, který je používán, je nutné udržovat po technické i administrativní stránce. Je třeba reagovat na nové požadavky, byť malého rozsahu, potřebu školení při změně personálního obsazení a na další jevy.

Výsledkem je situace, kdy jsou objednatel a dodavatel na sobě závislí. Tuto závislost sice lze částečně omezit, ale nelze ji zcela odstranit. Jediné, co s ní lze udělat, je uvědomovat si její oboustrannost.

Údržba
Systémy pro sběr výrobních dat vyžadují preventivní údržbu především v podobě kontroly záznamů o chodu systému, velikosti dostupného pracovního prostoru, kontroly zatížení a odezvy na požadavky, kontroly stavu záložních zdrojů energie a mechanik pevných disků. V případě potřeby je rovněž třeba opravit bezpečnostní a systémové chyby softwaru.

Úpravy
Nedílnou součástí života SSD, jako ostatně každého IS, jsou změny a rozšiřování – ať už se jedná o administrativní změny ve způsobech vykazování nebo o rozšíření na další zařízení, popř. o integraci s dalšími IS. V jakém rozsahu a za jakých podmínek, včetně finančních, bude dodavatel tyto služby zajišťovat, je třeba stanovit nejpozději ve smlouvě o dodávce systému. Objednatel se musí vyhnout stavu, kdy by byl dodavatelem „zamknut„ v uzavřeném řešení, jehož každou pozdější změnu by musel neúměrně draze platit. Vhodnou metodou je také trvání na otevřených rozhraních mezi systémy nebo mezi částmi systému.

Realita
Preventivní údržba se opět často zanedbává. Je znám případ, že déle než půl roku nikdo nekontroloval automatizované zálohování obsahu databáze na pásku. Další podobnou epizodou byla situace, kdy místní správce výpočetních prostředků doplnil do databáze tabulku, ale nepřiřadil práva pro její zálohování, které tudíž téměř rok nefungovalo.

Závěr

Přestože se situace při řízení projektů pomalu lepší, v mnoha případech zatím zdaleka nelze hovořit o efektivním nakládání s investicemi. V příspěvku jsou lehce konfrontačním způsobem připomenuty některé časté problémy vyskytující se především při stanovování cílů sledovaných zaváděním systémů sběru dat z výroby a při jejich analýze.

Ing. Slavomír Skopalík,
Elekt Labs s. r. o.
(skopalik@elektlabs.cz)

Článek je redigovanou verzí příspěvku Sběr dat – zkušenosti systémového integrátora předneseného autorem na čtvrtém ročníku mezinárodního semináře Řízení strojírenských podniků – 2004, VŠB-TU Ostrava, 2003.