Modernizace systému plánování a sledování výroby na řezací lince

Modernizace systému plánování a sledování výroby na řezací lince

V článku je na konkrétním případě modernizace informačního a řídicího systému linky pro výrobu izolačních panelů představen systematický postup tvorby informačního systému pro výrobu malého rozsahu, s jakou se lze běžně setkat v malých a středních firmách. Jsou popsány metodika tvorby, použité nástroje, postup řešení i výsledný modernizovaný řídicí systém linky, navázaný na ekonomický informační systém podniku. Důraz je kladen na postupy zajišťující aktivní účast konečného uživatele v procesu návrhu a tvorby řídicího systému a spokojenost jeho pracovníků s výsledným produktem.

1. Zadání úlohy

Úloha zněla minimalizovat, popř. zcela odstranit prostoje linky na výrobu izolačních panelů, způsobené ručním zadáváním nářezového plánu do řídicího systému letmé pily, za kterou následuje stohovač hotových panelů. Nářezový plán přicházel na pilu v papírové podobě. Jeho elektronická podoba je k dispozici v ekonomickém informačním systému podniku (EIS). Doba trvání prostojů byla odhadnuta na asi jednu hodinu týdně, což v daném případě znamená ztrátu ve výši asi 120 000 korun. Data jsou do EIS zadávána z obchodního oddělení (z podkladů od zákazníků), a proto bylo určeno, že přenos dat z EIS do řídicího systému linky bude primárně iniciován z obchodního oddělení.

Dalším úkolem bylo usnadnit obsluze stohovače tvorbu stohovacího plánu, který musel být ručně sestavován na základě upraveného nářezového plánu. Nářezový plán upravuje operátor pily na základě technologických možností a snahy minimalizovat odpad.

Úlohu lze tedy charakterizovat jako napojení výrobní technologie na informační systém podniku. Výsledkem řešení je informační systém pro výrobu, který se vyznačuje sice malým objemem přenášených dat, ale přitom relativně velkým počtem alternativních způsobů výměny dat mezi aplikacemi (např. v podobě souborů typu *.txt). Stávající řešení bylo třeba modernizovat za plného provozu výrobní linky. Výsledný informační a řídicí systém musí být nezávislý na chodu EIS a nesmí obsahovat zásadní závislosti mezi jednotlivými operátorskými pracovišti.

2. Analýza

2.1 Hranice systému
Prvořadým úkolem je co nejpřesněji určit hranice řešeného systému, tj. specifikovat, co je (a co není) předmětem díla. K tomu je vhodné vypracovat diagram datových toků nulté úrovně (DFD0). V rámci této činnosti se určí, i odkud se budou data číst a kam se budou zapisovat, jaké budou použity tiskové sestavy, jaký bude význam tištěných dat atp. Nepominutelnou součástí této fáze analýzy je hrubý návrh uživatelského rozhraní a co možná nejpřesnější seznam funkcí systému.

Specifikaci hranic řešeného systému a následně i jeho vnitřní strukturu je nutné detailně konzultovat se zákazníkem, který je také zdrojem většiny informací o hranici.

Uvedeným způsobem bylo pro daný případ stanoveno:

• Nářezový plán bude přenášen z EIS, založeného na databázi Informix v. 7.3. Informační systém pro výrobu bude mít vůči EIS právo pouze číst. Jestliže vynikne potřeba uchovávat nějaká data, je nutné vytvořit vlastní nezávislý (technologický) databázový server. Dále musí být zajištěn vstup z obchodního oddělení inicializující přenos dat a zároveň musí být nazpět poskytnuta informace o výsledku přenosu.

• K načtení do EIS pro potřeby oddělení odbytu budou z výroby k dispozici údaje o řezech vykonaných na pile, jejich přiřazení k zakázkám (bude-li to možné) a o struktuře každého balíku. Balicí listy tištěné laserovou tiskárnou na standardní kancelářský papír formátu A4 budou pro jednoznačnou identifikaci opatřeny čárovým kódem. Motiv balicích listů musí být uživatelsky editovatelný (různé jazykové verze, změna statutu firmy, loga atd.).

• Systém řízení letmé pily bude obsahovat vizualizaci v reálném čase. Pro komunikaci s pohonem Indramat CLM bude využita sériová linka RS-422 v nativním protokolu pohonu. Údaj o odjeté délce, popř. vzdálenosti do řezu, bude zobrazen na displeji LED. Alternativně musí být možné zadávat nářezový plán ze souboru *.txt i přímo obsluhou linky (opravy panelů, zkušební zakázky apod.).

• Stohovač bude řízen bez vizualizace v reálném čase. Bude ponechán stávající způsob vizualizace prostřednictvím nástroje ProTool Pro. Řešený program má za úkol předávat stohovači stohovací plán tak, aby byla zaručena návaznost na pilu, umožnit samotnou tvorbu stohovacího plánu (parametrizovatelný optimalizátor a editor) a zobrazit hlavní údaje o pile (pohled na hlavní zobrazení programu pily, ale bez možnosti editace).

Okolí řešeného systému a hrubý nástin toků dat ukazuje obr. 1.

2.2 Struktura systému
Po úspěšné identifikaci hranic systému je třeba rozkrýt jeho vnitřní strukturu. Na rozdíl od specifikace hranic systému, která vyplývá z požadavků okolí a kterou obvykle může ovlivnit jen málo, má řešitel při návrhu vnitřní struktury relativně volnou ruku. Dekompozici na této úrovni lze považovat za nejkritičtější část analýzy. Nejde sice o čistou analýzu, neboť zde již existují první náznaky syntézy řešení, ale chyby a opomenutí na této úrovni bývají nejnákladnější.

Z charakteru dané úlohy vyplývá, že pro technologii bude nutný samostatný databázový server. V něm budou uloženy údaje o zakázkách přenesené z EIS, některé číselníky (v případě složitějších technologií také výrobní postupy a jejich změny) a výsledky výrobních operací pro následné sledování výroby. Jde zejména o podklady pro statistiky a záznamy historie výroby konkrétního výrobku (záznam jednotlivých řezů, identifikace řádně vyrobeného panelu, opravy panelu, zmetkového výřezu nebo vzorku pro zkušebnu apod.). Ze záznamů lze diagnostikovat problémy výroby, zejména zmetkovitost v závislosti na sortimentu, personálním obsazení linky, dodavateli výchozího materiálu atd.

Dalším krokem je rozdělení jednotlivých požadovaných funkcí mezi dílčí programy a mezi nimi určení těch, které bude třeba naprogramovat. Některé programy lze přímo zakoupit, ale většinou jsou to pouze základní moduly, ze kterých je teprve třeba poskládat potřebný dílčí program s pouze těmi funkcemi, které jsou požadovány. Jestliže některá funkce chybí, je to chyba, přebývá-li, je to také chyba, jelikož doba adaptace obsluhy je přímo úměrná složitosti výsledného programu. Čím složitější program, tím kvalifikovanější musí být obsluha a tím zároveň roste pravděpodobnost chyby v programu.

Obecně byly zvažovány tři postupy:

• data si bude číst přímo technologický databázový server: problémy jsou s tím, že většina firem dodávajících databázové servery podporuje pouze přenos dat mezi svými produkty a že na serveru SQL zpravidla nejsou dostupné všechny transformační funkce, které mohou být při přenosu zapotřebí;

• data bude přenášet program umístěný v obchodním oddělení: problémy lze očekávat s údržbou tohoto programu a současně bude nutné, podle počtu instalací, nakoupit licence pro databázový server;

• o přenos dat se bude starat program umístěný na technologickém databázovém serveru a příkaz k přenosu dat bude vydávat jiný program, vůči kterému se program na technologickém serveru chová jako aplikační server.

K realizaci byla zvolena třetí z uvedených možností, zejména pro snadnou údržbu a malý počet licencí na technologický databázový server. Vznikly tedy programy dva, z nichž jeden běží na serveru a druhý na klientských počítačích. Nutné je počítat s tím, že druhý z programů může běžet v mnoha kopiích zároveň. Dále se nabízí možnost integrovat tento druhý program do komplexu EIS, např. formou DLL (Dynamic Linked Library) nebo objektu ActiveX.

Systémy pro vizualizaci v reálném čase (v anglicky psané literatuře Human Machine Interface – HMI) jsou logicky vázány na fyzické umístění strojů: co stroj, to jedna samostatná aplikace na samostatném PC.

Kompletní uspořádání řešeného systému je znázorněno na obr. 2.

3. Funkce komponent systému

3.1 Technologický server
Technologický databázový server je primárním zdrojem dat pro výrobu. Zároveň slouží pro výměnu dat mezi pilou a stohovačem. Server uchovává kopii původního nářezového plánu, neboť skutečný nářezový plán je z výrobních důvodů oproti původnímu modifikován. Tyto modifikace vznikají na pile i na stohovači.

3.2 Pila
Program letmé pily může načítat nářezový plán několika způsoby. Jednak standardní cestou z technologického serveru a dále dvěma nouzovými cestami: načtením ze souboru *.txt s předem dohodnutým formátem a ručním zadáním přímo obsluhou. O pořadí zakázek rozhoduje obsluha pily a program jí do rozhodování nijak nezasahuje. Nefunguje-li databázový server, zapisují se údaje o uskutečněných řezech do souboru *.txt, z něhož je potom možné rekonstruovat data. Pro nouzovou výměnu dat nabízí program letmé pily export nářezového plánu do souboru *.txt. Primárním úkolem programu je „parametrizovat“ pohon letmé pily Indramat CLM 1.3. Pohon je parametrizován přepisem vnitřního programu pohonu.

3.3 Stohovač
Program stohovače nezajišťuje vizualizaci v reálném čase, ale pouze připravuje data a balicí listy a umožňuje další práci s balíky. Data jsou připravována ve dvou fázích: nejprve se připraví stohovací plán, který se následně vloží do programovatelného automatu řídícího stohovač. Hlavním úkolem programu je příprava stohovacího plánu. Samotný stroj dovoluje stohovat jeden až čtyři balíky současně podle jejich délky. Úkolem bylo připravit plán tak, aby byla co nejmenší spotřeba palet, aby se co nejvíce využívalo paralelismu při stohování a zároveň byly co nejméně mezi sebou míchány panely různé délky. Tyto vlastnosti jsou v konečném produktu spojeny s možností parametrizovat samotný optimalizační program.

4. Volba nástrojů a technologií

4.1 Server
Technologický databázový server byl volen podle těchto kritérií: spolehlivost, nenáročnost na hardware, jednoduchá údržba a celková nízká cena. Jako operační systém přicházely v úvahu Windows NT, Windows 2000 nebo Linux. V době realizace byl OS Windows 2000 na trhu příliš krátce na to, aby bylo možné prohlásit ho za spolehlivý. Linux zase vyžadoval kvalifikovaného administrátora. Proto byl zvolen operační systém Windows NT 4.0, který lze již pokládat za celkem stabilní a spolehlivý.

Jako databáze byla zvolena Interbase 5.6 pro nenáročnou údržbu, malé požadavky na hardware a nízkou cenu. Interbase 5.6 je plnohodnotný server SQL s podporou transakcí, spouštěčů (trigger), uložených procedur a rolí. V současné době je zdarma k dispozici Interbase 6.01 jako projekt Open Source. Mezi kandidáty byly také servery Oracle a Informix. Hlavním problémem těchto serverů je z našeho pohledu složitá údržba.

4.2 Letmá pila a stohovač
Program pily byl nakonec napsán v produktu Delphi, ale cesta k tomuto rozhodnutí nebyla přímočará.

Standardní postup při řešení obdobných aplikací je přibližně tento:

• zvolí se některý z nástrojů pro tvorbu operátorského rozhraní (HMI), např. ProTool Pro, FactoryLink nebo InTouch;

• zvolený nástroj vyžaduje ovládač pro konkrétní hardware, tento ovládač však nemusí vždy existovat: potom se postupuje např. tak, že se v jazyce Microsoft Visual C++ napíše komunikační rozhraní, které se jako DLL nebo ActiveX (pokud ovšem zvolený nástroj tuto technologii podporuje) připojí k aplikaci;

• k přístupu do databáze se obvykle použije ovládač typu ODBC (Open Data Base Connectivity), ačkoliv zde jsou někdy problémy s transakcemi.

Při tvorbě programu pily bylo postupováno již uvedeným způsobem. Stále však rostl počet částí, které buď nešly v daném produktu naprogramovat vůbec, nebo jen se značnými obtížemi. Proto bylo na počátku implementace po dohodě se zákazníkem rozhodnuto vytvořit vše v Delphi, plnohodnotném kompilátoru jazyka Object Pascal s rozsáhlou vývojářskou základnou po celém světě, včetně naší republiky. Výsledným produktem je tedy jeden spustitelný soubor, což značným způsobem zjednodušuje instalaci a provoz programu i na jiném PC. Tohoto rysu díla bylo s výhodou využito především při školení obsluhy – viz kap. 5.5.

5. Realizace

5.1 Plán realizace
Realizace projektu byla rozdělena do tří etap. V nulté etapě byly zjišťovány rozsah a složitost prací, v první etapě byl nahrazen systém řízení letmé pily a v druhé etapě bylo dílo dokončeno. K popisu pracovní náplně jednotlivých etap jsou dále připojeny některé získané zkušenosti a poznatky usnadňující zavedení podobných automatizačních systémů jejich objednateli a uživateli.

5.2 Etapa nultá
Před započetím vlastních programátorských prací byla uskutečněna studie, jejímž výsledkem byly definované hranice systému, hlavní vnitřní bloky a návrh použitých technologií.

Úvodní studie je důležitá pro obě smluvní strany. Pro dodavatele je podkladem pro nabídku, jejímž nejdůležitějším bodem je cena, a pro zákazníka dokumentem, který mu říká, co úprava bude stát a co přinese, umožňuje odvodit další nepřímé náklady v důsledku odstávek apod. a shrnout, zda se modernizace vůbec vyplatí. Nabízet realizaci jakéhokoliv rozsáhlejšího systému, který má být integrován do vnějších struktur, bez úvodní studie nebo analýzy je spíše výstřel do tmy než seriózní počin (dodavatel se musí seznámit s podmínkami u zákazníka, aby mohl co nejkvalifikovaněji navrhnout a realizovat řešení).

Doba potřebná na úvodní studii je, podle rozsahu díla, od několika dnů do několika měsíců. V daném případě to bylo pět dní – tři dny strávené u zákazníka a dva dny na analýzu řešení a hledání subdodavatelů. Cena takovéto studie se pohybuje od 50 do 100 tisíc korun a v případě přijetí nabídky se odečítá.

5.3 Etapa první
Šlo o etapu velmi kritickou vzhledem k požadavku minimalizace odstávek výrobní linky. Zkoušky se konaly vždy o víkendech a bylo jich pět. Řešení na bázi nástroje FactoryLink se při prvních testech ukázalo jako nereálné. Na řídicím systému pily pracovali dva programátoři po dobu asi tří měsíců. Do plného třísměnného provozu byl systém uveden během jednoho víkendu, a to včetně zaškolení obsluhy. Během následujícího týdne byl nutný pouze jeden neplánovaný výjezd. Tato část řešení byla po zkušební době, dlouhé jeden a půl měsíce, bez výhrad předána do užívání.

Program pily je sestaven tak, že si vždy při startu zjišťuje poslední uložený stav. Ten porovnává s informací zjištěnou z pohonu Indramat, a je-li to možné, synchronizuje se. Výsledkem je, že nečekané přerušení chodu programu, operačního systému nebo počítače nenaruší výrobu. Pohon si udržuje frontu až 99 panelů, což při největší používané řezné rychlosti 7,5 m/min představuje, i při minimální délce panelu, rezervu asi 26 minut na nové spuštění PC. Při totálním selhání PC je ale nutné linku odstavit.

Součástí první etapy bylo i instalování databázového serveru, který je nutný pro plnohodnotnou práci s programem pily. V současné době vykazuje tento server běžnou délku doby mezi následujícími opětnými spuštěními kolem 4 000 hodin, což je přibližně pět měsíců nepřetržitého chodu.

5.4 Etapa druhá
Úkolem druhé etapy bylo navázat pilu na stohovač. Tento stroj je řízen programovatelným automatem Simatic S5 a je vybaven samostatnou vizualizací, jež je vytvořena nástrojem ProTool Pro. Díky tomu a protože řešený program stroj přímo neřídí, nebyla jeho implementace kritická na odstávky linky. Vždy bylo možné provozovat linku i bez programu stohovače. Jediným kritickým místem bylo vyzkoušení komunikačního protokolu a realizace komunikace na programové úrovni automatu Simatic S5. Tyto úkoly se řešily zčásti o víkendech a zčásti při plánovaných přerušeních výroby.

Součástí druhé etapy byla i úprava programu pily pro komunikaci s programem stohovače. Zde bylo nutné postupovat krajně opatrně, jelikož zásah do fungujícího programu vždy vede k opakování velké části zkoušek. Naštěstí se vyskytl pouze jeden větší problém, a ten byl po diagnostikování ihned vyřešen (šlo o výpadek PC během odesílání nářezového plánu).

Práce začaly vytvořením optimalizačního programu, jelikož se očekávalo jeho dlouhé ladění. Tato obava byla do značné míry motivována tím, že optimalizace byly založeny na empirických postupech. Z pohledu počtu stupňů volnosti řešení přesahovala složitost problému několikanásobně složitost šachové partie. Přitom nebyly do optimalizačních algoritmů zahrnuty nestandardní stavy, jejichž řešení bylo ponecháno obsluze. Úkolem řešitelů zadání bylo usnadnit obsluze co nejvíce rutinní práci s ponecháním možnosti ručních zásahů. Lze konstatovat, že tento úkol se podařilo splnit.

První výsledky druhé etapy prací byly předány ke zkouškám asi po jednom měsíci od jejího zahájení. Následovala část komunikační, kdy bylo třeba napsat ovládač pro protokol RK512 a vyzkoušet jej v dlouhodobých zkouškách. Pro tyto práce byl vytvořen zjednodušený model stroje v samostatném procesoru programovatelného automatu. Tak bylo možné vyvíjet ovládač v kanceláři a k zákazníkovi jezdit pouze zkoušet, zda nevznikla chyba v modelu.

5.5 Jak naplnit očekávání uživatele
O tom, zda realizovaný systém naplnil očekávání, nerozhoduje abstraktní průměrný „uživatel“, ale konkrétní pracovníci, operátoři, kteří ho používají jako pracovní nástroj. Ti musí především dostat možnost řádně si ho osvojit a popř. do něj včas promítnout své připomínky. Jaký postup se osvědčil v tomto směru?

V kap. 4.2 bylo uvedeno, že výsledným produktem je program v podobě jednoho spustitelného souboru, čímž se mj. usnadnilo vyškolení obsluhy. Ta si totiž mohla program pohodlně vyzkoušet ještě před tím, než byl dán do „ostrého“ provozu. Běžnou praxí bylo, že si obsluha anebo technický personál odnášeli program na disketě domů, aby se seznámili se všemi jeho funkcemi a vyzkoušeli si, jak se bude chovat v různých situacích. Pro tuto činnost byl program vybavena demonstračním módem, který simuloval zrychlený chod stroje. Demonstrační mód byl velmi užitečnou pomůckou i při ladění programu, kdy si každý programátor mohl vyzkoušet běh aplikace v kanceláři. Dobu zkoušky na zařízení se tak podařilo minimalizovat na pouhých asi 30 hodin (především o víkendech).

Dalším kladem z hlediska obsluhy je zvolený standardní vzhled aplikace se všemi funkcemi, na které jsou uživatelé všeobecně zvyklí z programů pracujících pod Windows. Jako příklady lze uvést „hints“ neboli tipy (zkrácený popis funkce nebo objektu, obvykle na žlutém podkladu), přetahování objektů, skupinové operace a standardní ovládací prvky, zkracující dobu nutnou k zaškolení obsluhy.

Program byl během vývoje předkládán budoucí obsluze, ale bez dalších návodů či školení. Jestliže obsluha dokázala vykonat všechny potřebné operace, bylo uživatelské rozhraní navrženo správně, když ne, bylo nutné je upravit, aby bylo dostatečně intuitivní. Toto se týká především operací, které se nepoužívají denně. Obsluha je tudíž nemusí mít rutinně vžité, a je-li před každou takovouto méně obvyklou operací nucena studovat dokumentaci, přínos řídicího systému podstatně klesá. Neočekávané chování systému vede k nedůvěře operátorů v systém samotný a tato nedůvěra se přenáší do celkového pohledu zákazníka na projekt. Je proto nutné, aby ovládání systému bylo do značné míry intuitivní, aby byl projekt vypracován v jednotné terminologii a jednotlivé operace neměly vedlejší efekty (sekundární projevy, které nejsou po vykonání operace patrné).

Velmi důležitým parametrem je doba odezvy automatizovaného systému. Je to opět spíše psychologie vnímání než nezbytná technologická nutnost, ovšem je třeba brát v potaz, že obsluhujícím personálem jsou lidé, a proto je nutné dát tomuto hledisku patřičnou váhu. Ideální je, jsou-li operace uskutečněny do 50 ms. To samé platí i u zobrazovaných veličin: jsou-li prodlevy mezi obnovením údajů dlouhé, působí plnění funkcí dojmem zpožděné reakce stroje.

6. Zhodnocení

Jak se očekávalo, přinesl projekt modernizace řídicího systému řezací linky zjednodušení a úspory, ale vedl i ke komplikacím a dalším nákladům. Je třeba si uvědomit, že obdobné projekty se ve výrobních firmách řeší s cílem ušetřit peníze. Jde především o snížení celkových nákladů, a je tedy nutné nahlížet na celou akci co možná komplexně. Jestliže nový systém umožní vyrábět problémové zakázky, které byly dříve ztrátové, nebo jestliže pomůže nabídnout trhu výrobek dříve nevyrobitelný, je třeba považovat za snížení nákladů např. marži, kterou firmě přinese nový sortiment. To je však nutné posuzovat také s ohledem na dobu uvedení nového (zdokonaleného) výrobního zařízení do chodu. Může se stát, a v některých oborech se to stává velmi často, že podnik bude mít výrobní sortiment, který přinese zisk pouze v prvním roce, ale napřesrok už může být zcela neprodejný, popř. konkurence může přijít s levnější technologií apod.

Jaké nevýhody nový systém přinesl:

• potřebný elektrický příkon vzrostl o asi 500 W; vzrostly požadavky na údržbu podnikové komunikační sítě, je třeba počítat se školeními a případné úpravy systému se dotknou větší části podniku;

• poklesla pružnost výroby: dříve pracovník obchodního oddělení běžně zašel přímo za obsluhou a předal jí podklady, které nyní musí předat mistrovi a ten je musí schválit (mistr vlastně někdy nevěděl, co se má vyrábět a co se vyrábí);

• vznikají neplánované prostoje způsobené výpadky informačního a řídicího systému: ačkoliv jich je málo, je třeba s nimi počítat ještě před tím, než se podnik rozhodne nový systém zavádět (představa, že systém nebude mít výpadky, je na úrovni představy, že osobní auto nikdy nemusí do servisu);

• větší požadavky na způsobilost obsluhy: skutečnost, která může, ale také nemusí znamenat větší mzdové náklady (menší počet kvalifikovanějších pracovníků).

A jaké přinesl konkrétní výhody:

• zmizely prostoje při zadávání nářezového plánu do letmé pily;

• vzrostla operativnost na stanovišti letmé pily, kdy – spatří-li obsluha poškození panelu (do pily vstupuje nekonečný panel), může se pokusit přesunout některý z kratších panelů, který má naději, že bude uříznut správně, mezi aktuálně řezané: výsledkem jsou menší ztráty, a tudíž vyšší efektivita práce;

• lze nyní bez potíží vytvářet i složité stohovací plány, což dovoluje dále zvýšit efektivitu výroby: obsluha se věnuje pouze kritickým místům, rutinní postupy vykonává počítač a nářezový plán je zároveň automaticky přenesen zpátky na pilu;

• dosáhlo se lepšího přehledu o výrobě, jsou k dispozici informace, co bylo vyráběno a jak dlouho výroba trvala, jaký byl originální nářezový plán, co udělala obsluha: to vše přispívá k lepší organizaci práce a usnadňuje vyhledávání rezerv.

• Dále by bylo možné analyzovat údaje o obsluze a poruchách, ale tyto analýzy zákazník nepožadoval. Lze si představit jejich použití k hodnocení pracovníků, k řešení technických problémů podle jejich četnosti, ke sledování reklamací apod.

Jak to vidí zákazník v číslech:

• jedna hodina prostoje linky představuje ztrátu z nerealizované produkce ve výši asi 120 000 korun;

• je-li odstraněna jedna hodina prostoje týdně, znamená to za rok nárůst produkce v hodnotě asi šest miliónů korun;

• zákazník odhaduje, že se modernizace systému zaplatila ještě před předáním do trvalého užívání (zde je třeba mít na zřeteli, že informační a řídicí systém byl tvořen přibližně jeden rok a instalován postupně: prvotní efekt byl tudíž menší).