PROJEKTOVÁNÍ ŘÍDICÍCH SYSTÉMU

Učební texty - Přednášky

I. Úvod do Projektování řídicích systémů

1. Základní pojmy

Projekt Projekt je záměr k řešení nějaké definované úlohy člověkem.

Automatizační projekt (Projekt řídicího systému PRS) PRS je pak záměr k řešení úlohy automatizace něčeho (stroje, výrobní linky, technologického a jiného procesu ) inženýrem - projektantem.

Výsledkem PRS je systém řízení procesu (Projekt řídicího procesu PRS).

Pozn. Již na tomto první pojmu je vidět, že PRS je jednak záměr, jednak výsledek řešení tohoto záměru.

Na obr. 1 je Automatizační projekt (PRS) ukázán v souvislostech se svým okolím. Dle normy DIN 69901 systém řízení procesu je charakterizován :

- cílem, který má být dosažen

- omezeními, kterými je projektant limitován při inženýrských krocích, vedoucích k dosažení cíle projektu

- jedinečností řešení (plynoucího z toho, že sice existují třídy podobných projektů, avšak každý projekt z této třídy je vzhledem ke svým specifikům unikátní)

Obr. 1 Definování PRS (projektu řídicího systému)

U projektů automatizace přistupují k těmto obecným vlastnostem projektů jako takových ještě tyto fenomény :

- spolupráce a nezbytná komunikace inženýrů nejrůznějších oborů

- nezbytné využití nejnovějších prvků a metod řešení podúloh projektu a z toho plynoucí značný stupeň rizika úspěšnosti projektu řídicího systému

- dopad na obsluhu, zaměstnanost

- dopad na organizaci řídicí činnosti podniku, ve kterém je PRS nasazen

2. Typy projektů řídicích systémů

Pokusme se rozdělit PRS dle dvou úrovní abstrakce (dvou různých klasifikačních kategorií- pohledů). Prvním klasifikačním pohledem nechť je stupeň inovace projekční práce. Dle tohoto hlediska rozeznáváme

- výzkumné projekty (charakterizované vysokým stupněm inovačních řešení a netradičních postupů)

- vývojové projekty (ve kterých se uplatňují osvědčené projektantské postupy, ale využívá se nových technik a technologií)

Druhým klasifikačním hlediskem je klasifikace dle povahy předmětu projektu. Pak rozeznáváme vývojové projekty

- pro vývoj produktu ( jde o vývoj technického produktu, kde předmětem automatizačního projektu je kupř. automatizace stroje, na kterém se produkt vyrábí)

- pro vývoj zařízení ( když se jedná o automatizaci velkých a složitých technických zařízení a čas pro realizaci projektu je od 1 do 5 let)

3. Přípravná fáze projektu

U každého projektu je definován začátek a konec projektu. Začátek je určen momentem, kdy byla hotova všechna rozhodnutí o realizaci projektu a nalezeny a definovány zdroje (omezení). Konec projektu je pak dán uvedením do provozu a předáním realizace investorovi nebo uživateli.

Ve skutečnosti ještě před definovaným začátkem projektu probíhají intenzivní činnosti, mající přímý vztah k definování i řešení projektu. Na obr.2 jsou tyto činnosti znázorněny. Říká se jim přípravná fáze projektu.

Obr. 2 Přípravná fáze projektu

U výzkumného projektu obsahují tyto práce rozpracování návrhu , u průmyslového vývojového projektu to je zhotovení nabídky, ve které se odhadnou potřebné prostředky a termíny zamýšleného projektu. U velkých automatizačních projektů to je Feasibility study (studie realizovatelnosti projektu).

Přípravná fáze projektu je poznamenána na jedné straně lehkostí a entuziasmem tvoření nového díla na špičkové technice, na druhé straně si je každý projektant vědom toho, že jen určitá část (malá část) této práce skutečně povede k realizaci. Přípravnou fází jediného projektu totiž procházejí všichni účastníci výběrového řízení, které je na projekt vypsáno a jenom jeden dodavatel bude realizátorem projektu (dostane zakázku).

Odhad nákladů a časového horizontu je o to složitější, čím větší je inovační rámec projektu. U těchto odhadů se může vycházet

- z parametrů (nákladů, doby trvání) analogických projektů (jsou-li k disposici)

- z poznatků expertů

- z počítačové podpory projektování (CASE systémy)

4. Závěrečná fáze projektu

Podobně jako přípravná fáze projektu začíná již dlouho před termínem začátku projektu, po termínu ukončení projektu hovoříme ještě o závěrečné nebo dobíhající fázi projektu, kdy probíhá fáze sledování chodu projektu řídicího systému a probíhají některé dokončovací a reklamační práce, případně úpravy projektu s ohledem na nutné změny a inovace technologie. Na obr.3 jsou všechny tři fáze PRS znázorněny v přibližných časových a objemových proporcích.

Obr.3 Časový průběh projektu

Práce, probíhající v závěrečné fázi projektu řídicího systému se dají kategorizovat na

- korektury

- změny - rozšiřující práce nad rámec projektu

Korektury je nutné provést, pokud po uvedení do chodu se objeví závady, které brání chodu PRS. Změny se musí provést tehdy, pokud stávající projekt nefunguje s prvkem nebo systémem, který původně v projektu nebyl, ale bylo nutné ho tam zaimplementovat (nic jiného nebylo k disposici ap.). Rozšiřující práce nad rámec projektu se dělají tehdy, je-li z průběhu řešení projektu jasné, že by výrazně zlepšily výsledek PRS.

5. Organizace projekční práce

Při organizaci práce na projektu, musí projekční firma vycházet z toho, že má nějakou organizační strukturu a že projekt, jehož řešení právě organizuje má omezenou délku trvání. Proto při organizaci projektu vystupují do pořadí tyto jevy :

- druh a objem projektu (zejména termín)

- nezbytnost spolupráce jednotlivých oddělení (profesí)

- důležitost projektu pro budoucnost projekční organizace (firmy)

Z toho plynou následující formy organizace projekční práce:

- řešení v obvyklé organizační struktuře (v tom případě vedoucí oddělení se automaticky stává vedoucím projektu)

- maticová organizační forma z obr. 4

Obr.4 Maticová organizační forma řešení projektu

- task-force organizační forma (po dobu trvání projektu jsou pracovníci různých odd. vyčleněni do zvláštního týmu pro řešení projektu, přičemž jsou podřízeni odbornému i disciplinárnímu řízení vedoucího projektu a po skončení projektu se vracejí do svých oddělení)

Tato organizace je smysluplná při velkých projektech.

Bez ohledu na to, jaká organizační struktura je zvolena, vlastní výstavba týmu je hierarchická a může být znázorněna např. schématem z obr. 5.

Obr. 5 Maticová organizační struktura

Příklad 1.

Dále si ukažme, jak vypadají jednotlivé fáze PRS na jednoduchém příkladu projektu vývoje a realizaci řídicího systému soustavy světly řízených křižovatek.

Přípravná fáze projektu V tomto případě přípravná fáze probíhá u investora, kterým bude příslušný odbor vedení města nebo místní části. Diskuse, činnosti, které budou tvořit podstatnou část přípravné fáze projektu jsou tyto :

- předběžné diskuse a šetření (kupř. s pomocí měření propustnosti křižovatky) o zvýšení propustnosti křižovatky a zabránění frontám

- zhotovení předběžného zadání a odhad ceny a termínu

- předložení návrhu pro schvalovací řízení

Jestliže pak bude pozitivně rozhodnuto o realizaci (a financování) projektu, začne řešení vlastního Projektu požadavkem na odbor plánování, aby rozpracoval dopravní koncepci. Spolu s úlohou (řízení křižovatky) pak tvoří podklad pro rozpracování projektu. Tento požadavek, formou zakázky je pak předán nějaké firmě (pokud není vypsáno konkursní řízení). Tato firma se pak stává hlavním dodavatelem, který je zodpovědný za celou zakázku investorovi. Může však zadat kooperujícím firmám dílčí zakázky na řešení dílčích úloh projektu. Od toho okamžiku se v projektu současně objevují obě organizační schémata. Jak hierarchické schéma obr. 6a, tak maticové schéma 6b) .

Obr. 6a Hierarchická organizační struktura

Obr. 6b Maticová organizační struktura

Příklad 2.

Dohlížení a řízení plynovodu

Požadavkem je nasazení moderního PCS, který by umožnil obsluze plynovodu dohlížení a řízení s podporou počítače, sledování procesu na barevných obrazovkách s možností vizualizace všech proměnných a akční zásahy do všech akčních členů.

Projekt se bude vyvíjet tak, že nejprve bude vypracována úvodní studie. Tým inženýrů provede v rámci této studie úvodní fázi projektu. V tomto týmu jsou jednak inženýři provozovatele plynovodu, jednak inženýři dodavatele systému.

Přípravná fáze se skládá :

- analýza současných a očekávaných vlastností plynovodu

- koncepce možných automatizačních postupů a hrubý návrh automatizační struktury

- rozepsání HW a SW konfigurace (komponent) jako podklady pro cenovou a termínovou nabídku (poptávku)

Výsledky této studie pak vedou k rozhodnutí o osudu projektu. Pokud se rozhodne kladně, stejný tým, jaký vypracoval studii vypracuje detailní popis úlohy (požadavky na stávající a požadované podsystémy jako např. HW, oper.s., uživatelský SW) a koncepci řešení (popis funkcí automatizačního systému z hlediska uživatele, definuje podsystémy, popíše rozhraní atd.). Tyto podklady pak tvoří "závazný" dokument pro všechny další práce i pro kooperující firmy.

Pro řešení projektu bude zvolena taková organizační struktura, která je na obr. 4 (podobná struktura by mohla být i organizační strukturou kupř. projektu stavby obytného domu).

Arbitrem (vedoucím projektu) je tým úvodní studie. Jednotliví dodavatelé tvoří vertikální struktury maticové organizace. Tým úvodní studie nemá žádné faktické kompetence, ale má hlavní slovo v technickém vedení záměru projektu.

Projekt byl realizován za 4 roky od předložení úvodní studie. kromě stavební firmy tam působilo ještě 5 firem (2 HW a 3 SW). Celkový objem práce činil asi 45 člověkoroků.

Obr. 6c Organizační struktura projektu stavby plynovodu

6. Inženýrské práce, související s řešením PRS

Inženýrské práce PRS, ale v podstatě každého technického projektu, se dají rozdělit takto :

- Vývoj systému (PRS) Vývoj začíná prakticky okamžitě spolu s úvodním záměrem, pokračuje intenzívně v úvodní fázi projektu a končí uvedením do chodu.

- Projekt management (vedení projektu)

t.j. plánování, řízení a kontrola technického a organizačního vedení projektu s požadavkem, aby projekt, který má být realizován splnil cenové , časové a samozřejmě i funkční předpoklady. Dle normy DIN 69901 projekt management zahrnuje všechny vedoucí role při vývoji a realizaci projektu.

- Zajištění kvality tato činnost slouží k zajištění kvality PRS, t.j. spolehlivosti, efektivnosti řešení, trvanlivosti ap. Zajištění kvality obsahuje dva různé druhy činností :

- plánování postupů při vývoji PRS tak, aby se dosáhlo požadavků na kvalitu

- kontroly kvality během prací na projektu, zda dobře naplánované postupy, které by měly vést ke kvalitnímu provedení projektu jsou také krok za krokem dodrženy

- Správa verzí projektu (verse a jejich správa - administrace)

Pod tím se rozumí veškerá správa dílčích výsledků s jejich různými variantami. Někdy se tato část inženýrských prací v anglické literatuře označuje jako "configuration management" tedy správa jednotlivých konfigurací projektu (což je však trochu speciálnější činnost než správa verzí)

- Dohled a ošetřování

Tato činnost přísně vzato nepatří přímo mezi inženýrské činnosti při PRS, neboť jak víme, vlastní projekt končí uvedením do chodu. Zároveň však vzhledem k obr.3 tyto činnosti pratří k závěrečné fázi PRS

Práce v závěrečné fázi projektu se dále dělí na

- technický dozor a ošetřování

- vedení technického dozoru a ošetřování

- zajištění kvality

- správa versí technického dozoru a ošetřování

Na obr. 7 je nakresleno schéma inženýrských prací souvisejících s řešením PRS

obr. 7 Schéma inženýrských prací na PRS

Dříve se kladl důraz především nebo dokonce pouze na technický vývoj a technické vyřešení projektu. Po mnoha zkušenostech, mnohdy trpkých se pochopilo, že celé schéma z obr. 7, tedy komplex těchto činností zobrazuje inženýrské činnosti PRS, a že význam těchto "další činností" vedle Vývoje má tím větší význam, o čím větší a složitější projekt se jedná.

Zvláště u velkých projektů, jakým je kupř. výše uvedený projekt automatizace plynovodu, kdy jde o velký a složitý objem SW prací je velmi aktuální činnost správa verzí projektu. Na obr. 8 je znázorněn význam pojmů verze a varianty.

obr.8 Správa verzí a variant v PRS

(zatímco je platná vždy jen jedna verze řešení, existuje několik platných variant v daném čase)

Například u projektu ŘS křižovatek, pro každou skupinu (nebo dokonce pro každou křižovatku) bude nějaká platná varianta jisté platné verse ŘS.

Správa konfigurací tvoří speciální třídu správy versí a variant PRS. Jde o to, že v určitém časovém okamžiku v řešení projektu (až po dokončení úvodní fáze projektu) je třeba projekt "zmrazit", protože pro další práce musí všichni účastníci pracovat se stejnými výchozími podmínkami. Správa těchto verzí a variant (konfigurací) se nazývá správou konfigurací. Samozřejmě je třeba v dalším průběhu projektu dělat různé změny, bez kterých by projekt nepostoupil. Správa konfigurací slouží k tomu, aby tyto změny přiřadila platné konfiguraci a měla je pod kontrolou.

8. Výčet jednotlivých činností

Zde ve větších detailech popišme jednotlivé třídy inženýrských činností pro PRS z obr.7. Opět se ale přidržme časového sledu průběhu projektu, t.j. sledujme tyto činnosti od přípravné fáze, přes vlastní fázi řešení projektu až po závěrečnou fázi PRS.

Přípravná fáze 1. stanovení cíle, definování úlohy, výčet podstatných požadavků

2. analýza požadavků, provádění analýzy situace

3. analýza vzájemných vztahů, informační toky a případně sestavení modelu procesu

4. hledání a rozhodnutí o možné koncepci řešení automatizační úlohy

5. hledání a definování struktury HW - SW systému, analýza, výhody a nevýhody alternativních struktur a výběr jedné struktury

6. plánování průběhu projektu , t.j. definování možné organizace projektu, definování časových a cenových horizontů, stanovení struktury projektu (histogramy, diagramy toků ap.)

7. hrubé plánování nutných zdrojů (finanční zdroje, personální obsazení )

8. plánování řízení kvality, t.j. požadavky na zajištění kvality projektu a jeho realizace

Ke všem těmto činnostem v přípravné fázi je sice třeba přistupovat zodpovědně, avšak hloubka rozpracování nesmí být příliš velká z ohledem na to, že náklady na tuto fázi projektu jdou do režie podniku v případě, že se projekt nerealizuje.

Z toho plyne, že v případě získání zakázky na PRS, všechny tyto činnosti 1. - 8. přípravné fáze musí být znovu posouzeny a rozpracovány ve větších detailech a doplněny následujícími činnostmi:

9. hrubý návrh automatizačních funkcí, které budou realizovány SW

10. podrobný návrh SW t.j. rozpracování automatizačních programů

11. hrubý návrh přístrojového vybavení (HW počítačů, busy, senzory, aktory)

12. řízení projektu a kontrola, t.j. uvolnění pracovních postupů, dozor nad splněním požadavků , kontrola dodržení plánovaných nákladů a termínů a další

13. kontrola kvality projekčních prací

14. správa všech variant a verzí SW a HW komponentů

15. dokumentování všech výsledků vývojových prací

16. kódování programů a SW testy

17. rozmístění HW komponentů, obvodový návrh pro umístění senzorů a aktorů, zhotovení propojovacího plánu a plánu kabeláže

18. zkoušky senzorů a aktorů

19. integrování HW a SW, test HW-SW konfigurace

20. napojení HW-SW kombinace na proces, zkoušky plnění automatizačních funkcí

21. zkušební provoz, vyhodnocení zkoušek a zaškolení obsluhy uživatele a předání

Závěrečná fáze projektu pak obsahuje následující činnosti:

22. provádění testů k identifikaci chyb, když nastaly výpadky PRS během provozu

23. odstraňování chyb v HW a SW

24. správa verzí a konfigurací SW a HW celků, které vznikly v závěrečné fázi projektu v důsledku odstraňování chyb HW a SW

25. definování požadavků při přáních uživatele na změny a rozšíření

26. hledání možných řešení pro splnění těchto požadavků

27. plánování provedení těchto změn, zhodnocení časové a finanční náročnosti

28. nový vývoj projektu v těch dílčích částech projektu, ve kterých byly provedeny výše uvedené změny

29. kontrola skutečných nákladů na tyto změny

30. kontrola, zda i po provedených změnách projektu byly dodrženy požadavky na jeho kvalitu

31. správa všech verzí a variant, které vznikly v rámci změn a opravy chyb v závěrečné fázi projektu

32. doprovodná dokumentace všech výsledků odstraňování výpadků a chyb, dokumentování změn a rozšíření

33. SW test všech SW produktů nasazených v závěrečné fázi

34. zkoušení přístrojů pro dohlížení na proces

35. SW - HW integrace

36. připojení procesu k této inovované verzi PRS, předávací testy,

Z výše uvedeného je patrná náročnost a komplexní složení závěrečné fáze, ve které probíhají v případě potřeby v podstatě stejné inženýrské činnosti jako v hlavní fázi projektu. To se týká především činností správa verzí a variant a řízení kvality.

9. Činnosti a dokumenty, týkající se vztahů mezi investorem a dodavatelem.

Vztahy jsou definovány kontraktem v písemné podobě, u malých akcí i ústně. Žádná závazná forma kontraktu. Současně s definováním těchto vztahů je definováno i rozdělení kontraktu na řešitele.

Ukažme si definování vztahů investor - dodavatel na příkladu projektu řídicího systému pro elektrárnu.

Provozovatel elektrárny (energetický podnik ap.) zde investor (odběratel ap.) vypracuje, na základě interní studie, požadavky ze strany uživatele (investora, provozovatele) na řídicí systém. Tento dokument může být nazván zadáním (Lastenheft). Tvoří podklad pro definování m.j. subdodavatelů a konečně i hlavního dodavatele a jejich vzájemných rolí při budoucí případné realizaci projektu. V tomto případě uvažujme jen jednoho investora a jen jednoho nositele zakázky (spolunositelé nemají kontrakty s investorem, ale s generálním dodavatelem). Protože zadání nemůže do detailů popisovat všechny činnosti a požadavky, musí po získání zakázky investor a hlavní dodavatel vypracovat závazný dokument, popisující detailně zadání projektu ( Pflichtenheft). Na obr.9 jsou tyto činnosti a jim odpovídající dokumenty popsány.

Investor

Analýza problému

Požadavky uživatele

Rozpis problému

Studie nabídky

Spolupráce při vypracování

Sledování vývoje PRS

Popt

ávka

Nab

ídka

Kon

trak

t

Řešitel (dodavatel

PRS)

Vypracování nabídky

Rozpracování závazné systémové specifikace

Vývoj

Přípravná fáze projektu Hlavní fáze (projekt)

Obr.9 Činnosti a dokumenty na počátku projektu mezi smluvními partnery.

Jako druhý příklad je zde projekt automatizace křižovatek. Ve dvou ohledech se vztahy odběratel - dodavatelé budou lišit od předešlého příkladu.

- vedle hlavního dodavatele budou ještě další dodavatelé

- odběratel má oddělení, které nejen stanoví požadavky na řídicí systém, ale je schopno i realizovat část nebo celý projekt (kupř. SW).

V tomto případě není nutné rozdělit fázi zadání úlohy do fáze vypracování "Lastenheft" a následně "Pflichtenheft". Může být vypracován přímo závazný dokument ( Pflichtenheft). Obr.10 ukazuje, činnosti jednotlivých stran a tomu odpovídající dokumenty.

Investor

Analýza problému

Požadavky uživatele

Rozpis problému

Studie nabídky

Spolupráce při vypracování

Sledování vývoje PRS

Popt

ávka

Nab

ídka

Kon

trakt

Hlavní dodavatel

Vypracování nabídky

Vypracování projektu s rozpracováním poptávek subdodavatelům

Vývoj

Popt

ávky

Nab

ídky

Kon

trakt

y

Subdodavatelé Příprava

nabídek Vývojové

práce

Přípravná fáze projektu Hlavní fáze (projekt)

Obr.10 Činnosti a dokumenty úvodní fáze dodavatelsko - odběratelských vztahů pro příklad projektu automatizace křižovatek

10. Modely popisu inženýrských činností projektantské práce

10.1. Fázové modely Výčet inženýrských činností tak, jak jsme ho provedli v kapitole 8. není dost přehledný a pro účely projektu tudíž nemá velký význam. Jednoduché grafické vyjádření rozdělení doby projektu na jednotlivé fáze může být daleko přehlednější, byť zjednodušující. Toto grafické vyjádření se nazývá fázový modelem a používá se v projektantské praxi často .Na obr. 11 jsou vedle sebe nakresleny v tabulce 4 fázové modely. Protože tvorba fázového modelu nepodléhá ustáleným konvencím nebo normám a doporučením, je možné různé dělení i pojmenování jednotlivých fází u různých projekčních organizací. Společnou nevýhodou všech fázových modelů je to, že popisují jen regulérní průběh projektu. Při nutných změnách a z toho plynoucích skoků zpět nejsou schopny tuto skutečnost zobrazit.

Obr. 11 Porovnání fázových modelů různých projekčních organizací

10.2 Kaskádové modely Tyto modely odstraňují nevýhodu fázových modelů, co se týče zpětných skoků. Jednotlivé fáze se zapisují do diagonály pomyslného obdélníku. Standardní sekvence činností je znázorněna pohybem směrem shora dolů. Kroky zpět jsou možné z každé fáze do libovolné předchozí fáze.

Obr. 12 Kaskádový model inženýrských činností

10.3 Rozhodovací modely Dosavadní modely popisují jen činnosti, resp. sled činností, nikoli rozhodování, třebaže právě rozhodování je pro kreativní činnosti charakteristické. Rozhodování kombinované s posloupností činností popisuje dobře vývojový diagram. Obr. 13

Obr. 13 Rozhodovací model k popisu postupu při kreativních činnostech koncepce řešení a strukturování systému činností.

Je zde potřeba rozlišovat mezi

- hledáním a nalézáním specializovaných koncepcí a metod k principiálnímu řešení daného automatizačního problému

- návrhem SW-HW konfigurace, která tyto koncepce a metody realizuje

Kupř. u regulační úlohy je možné jasně tyto dva pohledy rozlišit. Na jedné straně je potřeba definovat koncepci syntézy regulačního obvodu (stavový regulátor, jeho syntéza - určení parametrů), na druhé straně je nutné tuto regulační koncepci realizovat pomocí určité HW-SW konfigurace. Na obr. 13 je zřejmé, že zpětné

smyčky mohou fungovat mnohonásobně, což odráží skutečnost změn v projektu a fakt učení se v průběhu řešení projektu.

10.4 Projekční modely (aplikační modely) Dosavadními modely jsme popsali jen oblasti technického řešení Vývoje a Dohlížení a ošetřování PRS. Modely, které popisují tyto a všechny další inženýrské činnosti projekční práce (viz pětiúhelník) se nazývají projekční modely a uživatelské modely.

Obr. 14 Projekční model inženýrských činností

Na obr. 14 je jako příklad uveden projekční model. V jeho střední části jsou uvedeny činnosti "Vývoj" a "Dohled a Ošetřování". Nalevo je "Vedení projektu" napravo zbývající inženýrské činnosti "Správa verzí/variant" a "Zabezpečení kvality". Silné čáry mezi bloky znázorňují vzájemné vazby (v jistých ohledech značně silná vzájemná působení jednotlivých činností na sebe).

Činnost "Vývoj" je na tomto schematu rozdělena do dvou stupňů. Nejprve je rozdělena do "Requirements Engineering", HW-SW-system-project " a do bloku "Implementation". Každá z těchto činností je pak dále specifikována. Jednotlivé bloky, popisující inženýrské činnosti jsou propojeny vertikálními vazbami jak shora dolů, tak zdola nahoru, čímž je řečeno to, že realizace prostým postupem shora dolů od požadavků, přes SW-HW návrh až k realizaci je zjednodušením problému, který v praxi nemusí být vždy realizovatelný. Jde o to, že tento model lépe vystihuje skutečnost učení se v pozdějších fázích projektu. Model z obr.14 však je stejně ještě zjednodušením vzájemných vazeb, protože ve skutečnosti vazby mohou jít od každé činnosti ke všem ostatním.

V dalším výkladu se budeme zabývat detaily jednotlivých činností v projekčním modelu.

10.4.1.Vývoj

Na obr.14 je tato činnost popsána 3 bloky. V praxi je tato činnost rovněž zpravidla dělena a odráží se v organizační struktuře odd. Vývoj. Jde o

- t.zv. Requirements Engineering. Z hlediska klasických technických oborů jde o fázi v přípravě projektu a na počátku projekčních prací.

- systémový návrh (zde na mnoha místech označovaný jako SW-HW návrh

- implementace (implementace systémového návrhu včetně testů, syntézy a kontroly validity (správnosti)

Requirements Engineering Na obr.15 je tato činnost popsána ještě detailněji. Rozlišují se zde dvě kategorie činností:

- definování úlohy a specifikace systémových požadavků

- technicky orientovaná koncepce řešení výše uvedené úlohy, s modelováním a funkční specifikací - Functional Specification ( specifikace funkcí vycházející ze systémových požadavků)

Obr. 15 Diagram Requirements Engineering

Definování (podrobný popis) úlohy je nutné provést na prvním místě. Přitom se jedná o celou definici úlohy (systémové požadavky) a ne pouze o požadavky na řešení kupř. jen SW nebo HW. Výsledkem této činnosti Requirements Engineering je" Lasten" nebo "Pflichtenheft".

Jak vypadá tato činnost (Requirements Eng.) u příkladů, které jsme zatím probrali:

- u projektu automatizace křižovatek se koncipuje v rámci RE metoda řešení dopravní situace

- u projektu PRS plynovodu se koncipují metody měření, řízení a dohlížení na chod plynovodu

Pro tyto činnosti se někdy požaduje tvorba modelu (analytického nebo simulačního).

Obě kategorie požadavků, které jsou na počátku koncipovány jako obecné, na řešení nezávislé, se po stanovení technické koncepce musí často této technické koncepci (technickému řešení) přizpůsobovat.

Systémový návrh

Systémový návrh má za úkol vyprojektovat takovou HW-SW konfiguraci, která je schopna realizovat systémové požadavky, stanovené v předcházející fázi RE. Systémová návrh začíná vývojem struktury, t.j. definováním hrubé struktury HW-SW kombinace (také označovaný jako systémová architektura). Přitom již musí být určeno, které části systému budou určeny pro které technologické celky. Poté se musí rozhodnout zda a které části budou řešeny (u případu PRS) nezávislými (autonomními) regulátory a které řídicím systémem. Rovněž musí padnout zásadní

rozhodnutí, zda automatizační systém (PRS) bude řešen jako soubor PLC nebo jako PCS ap.

Dle obr.14 dělí se systémový návrh na 2 směry návrhu

- hrubý a podrobný SW návrh pro použitý řídicí počítač nebo PLC

- hrubý a podrobný HW projekt HW

Implementace

Fáze vývoje nazvaná implementace se rovněž dělí do dvou směrů

- realizace podrobného SW návrhu v příslušném jazyce

- vypracování podkladů pro HW řešení (propojovací schéma, Querverweisungliste ap.). Do této fáze dále patří testování jednotlivých podprogramů , integrování (agregování) SW, napojení na technologický (a jiný) proces, funkční zkoušky a spuštění provozu PRS. Fáze validace je ověřením funkčních schopností PRS dle požadavků RE.

Vývoj pomocných systémů

Oblast Vývoje PRS sebou často přináší ještě další, pomocné úkoly, které bezprostředně nejsou realizací vlastního díla, ale slouží k realizaci. Jedná se o vývoj pomocných přípravků pro oživování, testovacích programů, pomocného vybavení operátorského stanoviště, studijních materiálů pro zaškolení obsluhy ap.

11. Modely inženýrských vývojových činností vycházející z principu postupného zjemňování kroků

11.1 Princip postupného zjemňování kroků

Tento postup se dá uplatnit u každé vývojové činnosti. Jde o postupné detailizování pohledu na úlohu. Na obr. 6 je tento princip ukázán na úloze koncepce technického řešení. V první úrovni jsou vytvořeny různé koncepce a oblasti řešení. Ve druhém kroku se hledají koncepce pro tyto oblasti řešení, přičemž jsou definována dílčí řešení. V dalším kroku jsou koncipována tato dílčí řešení a jsou definovány postupy řešení. Ty jsou pak v dalším kroku blíže zkoumány pomocí definování algoritmů řešení. Tímto způsobem vznikne hierarchie komponentů řešení,které jsou přiřazeny vždy jednotlivým koncepčním úrovním.

Obr. 16 Použití principu postupného zjemňování kroků

Z grafu je vidět, že zpětné kroky jsou možné, že činnosti neprobíhají jen v přímém směru shora dolů. Stejným způsobem se dá tento postup (model) uplatnit i kupř. na fázi Systémový návrh. To je ukázáno na obr. 17.

Obr.17 k příkladu modelu systémového návrhu

11.3 Model systémových úrovní

Jedná se o další ze způsobů tvorby modelu projekčních prací. Nebude v této části přednášek uváděn.

12. Dokumentování při průběhu PRS

12.1 Úloha tvorby dokumentace

Jak již bylo několikrát řečeno, funkce dokumentace PRS nabývá stále většího významu v průběhu řešení PRS i v jeho závěrečné fázi. V mnoha případech její funkce není doceněna ke škodě investora i dodavatele. Zejména u složitých a velkých projektů však bez dobré, úplné, aktuální a konzistentní dokumentace je realizace projektu ohrožena.

Dokumentování má v průběhu projektování řídicího systému následující úkoly :

- musí sloužit projektantům, pracujícím na projektu jako zdroj aktuálních informací o stavu projektu

- musí zprostředkovat komunikaci mezi účastníky projektu

- musí umožnit správu verzí a variant, řízení (management) projektu a zajištění kvality

Po ukončení projektu, slouží dokumentace k zajištění provozu a fáze dohlížení a ošetřování projektu. Pro důležitost, jakou technická dokumentace v každém (nejen automatizačním) projektu má, kladou se na ní následující požadavky:

- čitelnost a srozumitelnost, pokud možno bez speciálních znalostí a zkušenotí

- srozumitelnost vztahů, průběhů, způsobů ap.

- úplnost, t.j. popis všech relevantních aspektů projektu

- jednoznačnost, t.j. žádný prostor pro různé interetace, a s tím související jasné definování pojmů

- musí být vnitřně konzistentní bez protiřečení

12.2 Prostředky dokumentování

Za účelem splnění výše uvedených požadavků se používají následující 4 prostředky tvorby dokumentace:

a) verbální

Je pochopitelná, přirozená, avšak ztrnulá. Obtížně použitelná o sobě k dokumentování technického díla. Používá se kupř. v právnické oblasti.

b) grafická

2 nebo 3 dimenzionální grafika, srozumitelná, velmi běžná a pochopitelná, doplnitelná textem. Nutné doplnit vysvětlivky použitých grafických symbolů.

c) formuláře, tabulky ap.

d) formální

Popis vychází z formálních popisů (matematické formule, výrazy ve vyšších program.jazycích. Výhodou je , že popis je jednoznačný a stručný, nevýhodou je , že je nesrozumitelná pro osoby neznalé tohoto formalizmu.

12.3 Způsoby dokumentování

Celková dokumentace o PRS se dá vyjádřit tabulkou Tab. 1.

Zásadně ji lze rozdělit na

- vývojovou dokumentaci

- výsledná dokumentace (která vychází z vývojové dokumentace)

- dokumentaci řízení projektu

- další dokumentaci ( pro provoz, dohled, zaškolení obsluhy, marketing ap.)

Vývojová dokumentace

Dokumentace o produktu

Dokumentace o kvalitě a vedení projektu

Další dokumentace

Popis úlohy a cílů

Analýza situace

Požadavky

Odborná koncepce řešení

Celková koncepce

Algoritmy řešení

Systémový návrh

Alternativy řešení

Rozhodování mezi alternativami

Výsledný návrh

Pomocné nástroje návrhu

Plánování testů

Programové prostředky

Přehledný popis

Popis systému

Popis funkce

Popis komponentů automatizačního systému

SW

HW

Rozhraní

Senzory, aktory

HMI

Dokumenty pro průběh projektových prací

Poptávky a nabídky

Závazný dokument

Organizační struktura

Popis projektu

Časové a cenové údaje

Dokumenty pro rozhodování

Odhad ceny

Nabídky

Dokumenty ke kvalitě

Doporučení a postup

Zprávy o zkouškách a kontrolách

Tab. 1 Celková dokumentace PRS

12.3.1 Problémy, související s tvorbou dokumentace

Přes velký význam, který je dokumentaci přikládán (a který skutečně v průběhu projektování i v jeho závěrečné fázi má), současná tvorba projekční dokumentace má značné nedostatky. Ty mají asi následující příčiny:

- vývojoví pracovníci nejsou pro tvorbu dokumentace ani vyškoleni, ani motivováni

- časový tlak, který každý projekt provází odsouvá práci na dokumentaci

- průběžná aktualizace dokumentace je prakticky nemožná

Z těchto a možná i dalších důvodů byla v minulosti projekční dokumentace často zhotovována až po projektu (a měla svoji funkci převážně v závěrečné fázi projektu).

12.3.2 Způsoby eliminace problémů se zhotovování projekční dokumentace.

1. Vydání pravidel zhotovování dokumentace (způsob, obsah, rozsah a termín zhotovení). Slabinou tohoto způsobu eliminace je to, že je těžké ho činit závazným a dodržovat, zejména v časově kritické fázi projektu (a to jsou prakticky všechny fáze, všech projektů).

2. Nasazení SW pro tvorbu dokumentace off - line (není dostatečně efektivní, opět stojí čas a nedodržuje se, předpokládá ovládnutí systémů, ne vždy uživatelsky příjemných ap.)

3. Nasazení on-line SW pro současný vývoj a tvorbu projekční dokumentace. Výchozím bodem je použití specializovaných jazyků, které umožňují formulování vývojových kroků a souvislostí a které umožňují projekční informace soustřeďovat v jediné databázi. Tvorba dokumentace se pak provádí pomocí programu (generátor), který obsah databáze využívá pro tvorbu různých způsobů popisu PRS.

Je jasné, že v dnešní době jsou všechny předpoklady pro rozšíření posledně jmenovaného způsobu tvorby projekční dokumentace. Vykazují proti výše jmenovaným způsobům tyto nesporné výhody :

- v libovolném okamžiku v průběhu projektu mohou být dokumenty použity pro rozhodovací fázi i jako pracovní dokumentace

- je stále aktuální, neboť aktualizace databáze je automatická

- změny se provádějí bez vícepráce

- veškerá dokumentace je vytvořena jednotným způsobem

- kontrolu kvality je možné provádět v libovolném okamžiku, protože všechny potřebné dokumenty jsou stále k disposici

- výpisem celkové dokumentace je možné zjistit v každé fázi projektu stav rozpracovanosti PRS

- použitím různých způsobů popisu mohou být vyzdvihnuty různé aspekty díla (projektu)

13. Popis technologie horkovodní výměníkové stanice tepla

14. Technologický popis parní předávací stanice Parní předávací stanice zajišťuje zásobování velkých celků (budov, závodů, apod.)

teplem získávaným z páry v centrálním rozvodu. Činnost stanice je založena na tepelné výměně mezi přiváděnou párou a vodou, která je využívána buď přímo pro ústřední vytápění jako topná voda (TV), nebo jako medium pro ohřev teplé užitkové vody (TUV).

Technologický projekt parní předávací stanice v objektu SZZ1 na Dominikánském náměstí v Brně předpokládá uspořádání podle technologického schématu v příloze 1. Stanice je napájena párou z centrálního rozvodu, která je nejprve redukována na tlak 0.4MPa abs. a pak přivedena do rozdělovače páry, kde se rozděluje do tří paraleních větví. V každé z nich je zařazen jeden stojatý kondenzační výměník pára-voda typu Glazer, jehož výkon lze plynule a nezávisle na ostatních výměnících měnit v rozsahu 0 až 100%. Plynulé regulace výkonu se dosahuje změnou efektivní plochy výměníku při jeho zaplavování kondenzátem. Pomocí regulačních ventilů zařazených v jednotlivých větvích potrubí odvádějícího kondenzát z výměníků je možno měnit výšku hladiny kondenzátu a v konečném důsledku i výkon. Z výměníků je kondenzát odváděn společným potrubím přes kalník a měřič kondenzátu do nádrže, odkud je pak odčerpáván zálohovaným čerpadlem mimo stanici do sběrného potrubí kondenzátu. Teplem, které se uvolní při kondenzaci páry, je ohřívána voda v systému kapilár jednotlivých výměníků, jejíž cirkulaci zajišťují tři samostatná oběhová čerpadla.

Paralelně řazené výměníky V1 a V2 jsou určeny pro ohřev TV zatímco výměník V3 je vyhrazen pro přípravu TUV. Ukazuje se, že takovéto řešení je výhodnější než kdyby všechny tři výměníky byly napojeny na společný okruh TV a z něho byla teprve odbočku ohřívána TUV. Díky tomuto uspořádání je totiž možné řídit ohřev TV a TUV prakticky nezávisle, což sebou přináší značnou úsporu energie a také možnost pružněji reagovat na prudké změny v odběru TUV. Potrubí TV vede od výměníků V1 a V2 přes hydraulický anuloid do rozdělovače TV, kde se dělí do čtyř nezávislých topných větví a to:

• jižní větev (J) • severní větev (S) • přízemní větev (P) • větev pro ohřev vzduchu v kanálu vzduchotechniky (VZT) V každé větvi je zařazena směšovací klapka (v případě vzduchotechniky směšovací

ventil) a cirkulační čerpadlo. Ve směšovací klapce resp. ventilu dochází k mísení TV z rozdělovače s ochlazenou TV vracející se zpět z příslušné topné větve. Teplota TV, ktará proudí do topné větve a množství TV odebírané z rozdělovače lze měnit polohou směšovací klapky resp. ventilu.

Větví VZT je přiváděna TV do výměníku voda-vzduch umístěném v kanálu vzducho-techniky. V kanálu vzduchotechniky je umístěn ventilátor pro nasávání vzduchu zvenčí a uzavírací klapka, pomocí které lze kanál uzavřít v případě namrzání výměníku. Hydraulický anuloid zařazený v potrubí TV mezi rozdělovačem a výměníky V1 a V2 zajišťuje vyrovnání rozdílu v množství TV dodávané čerpadly výměníků a TV odebírané rozdělovačem. V případě nulového odběru TV dochází v anuloidu k tzv. hydraulickému zkratu. Voda cirkuluje pouze v potrubí mezi hydraulickým anuloidem a výměníky V1 a V2.

Pro přípravu TUV je, jak už bylo dříve uvedeno, určen samostatný výměník (V3), který prostřednictvím dalšího výměníku voda-voda, označeného v příloze č.1 jako DOHŘEV TUV, zajišťuje potřebné množství TUV. Při přípravě TUV je také využíváno zbytkové teplo z kon-denzátu k jejímu předehřevu, prostřednictvím dalšího výměníku voda-voda (PŘEDEHŘEV TUV). Kromě zmíněných výměníků a cirkulačního čerpadla, které zajišťuje neustálou ob-

měnu TUV v potrubí i při nulovém odběru, je v okruhu zařazena také dvojice paralelních nádrží. Jejich zařazení do okruhu má za následek zvýšení tepelné kapacity systému a tedy i větší schopnost vypořádat se s odběrovými špičkami. Studená voda je do okruhu TUV přiváděna v místě mezi cirkulačním čerpadlem a vstupem do výměníku pro předehřev TUV.

Důležitým zařízením parní předávací stanice je také expanzní a doplňovací souprava (EDS). Jedná se v podstatě o autonomní systém s vlastní řídící elektronikou, který zajišťuje doplňování resp. odebírání TV tak, aby se její tlak v potrubí předávací stanice pohyboval v určitém volitelném pásmu. Řídící elektronika EDS je schopna rozpoznávat některé havarijní stavy rozvodu TV (netěsnost potrubí, dlouhodobé přehřátí, apod.). Informaci o vzniku hava-rijního stavu předává řídící systém EDS v podobě binárního signálu.

14.1. Rozbor požadavků na HW sestavu řídicího systému Aby bylo možné navrhnout HW sestavu řídicího systému pro řízení parní předávací

stanice, je třeba pro její řízení znát potřebný typ a počet vstupů a výstupů systému. Počet a typ potřebných vstupů a výstupů závisí na počtu a typu použitých čidel, akčních členů a vstup-výstupních zařízení pro styk s obsluhou (tlačítka,signalizace) a ostatními řídicími systémy (EDS). O tom, jaké akční členy je třeba k systému připojit, zcela rozhoduje technologické řešení parní předávací stanice. Jsou to tyto akční členy: • redukční servoventil, pomocí kterého je pára redukována na tlak 0.4MPa abs. • servoventily na potrubí kondenzátu jednotlivých výměníků, pomocí kterých se dá plynule

měnit jejich výkon • směšovací klapky resp. ventil pro řízení teplot TV v jednotlivých topných větvích • veškerá čerpadla • ventilátor v kanálu vzduchotechniky • uzavírací klapka v kanálu vzduchotechniky pro jeho uzavření při namrzání výměníku

voda-vzduch Volba vstup-výstupních zařízení pro styk s obsluhou a ostatními systémy se řídí zvyk-

lostmi používanými při řízení technologických procesů: • zařízení pro zadávání žádané hodnoty teploty místnosti v přízemí • havarijní signalizace (světelná) • havarijní signalizace (akustická) • kvitační tlačítko • ústupové tlačítko • porucha EDS

Volba většiny čidel závisí na tom, které veličiny musí řídicí systém měřit, aby byl

schopen zajistit dodržení technologického postupu. Pro sledování všech technologicky důležitých veličin této konkrétní stanice je třeba použít následujících čidel: • čidlo tlaku páry v rozdělovači

- zajišťuje zpětnou vazbu pro regulaci tlaku páry v rozdělovači na hodnotu danou tech-nologickými požadavky

• čidla teploty vody na výstupech z jednotlivých výměníků - slouží jednak pro omezení teploty výstupní vody z výměníků na max. 95°C

(při překročení je vyhlášen havarijní stav) - mohou také sloužit pro měření teploty výstupní vody jako pomocné regulované veličiny a

přispět tak ke zkvalitnění regulačního pochodu

• čidlo teploty TUV za výměníkem voda-voda pro předehřev TUV - poskytuje řídicímu systému informaci o tom, jestli náhodou nedošlo kvůli malému

odběru TUV k jejímu přehřátí nad požadovanou teplotu (V případě, že dojde k přehřátí, zajistí řídicí systém vypnutí cirkulačního čerpadla kondenzátu pro předehřev TUV.)

• čidlo teploty kondenzátu v nádrži - poskytuje řídicímu systému informaci o tom, jestli teplota kondenzátu není příliš nízká

pro předehřev TUV (V případě, že tato teplota klesne pod určitou mez, systém zajistí vypnutí čerpadla kondenzátu pro předehřev TUV.)

• čidlo teploty TUV za nádržemi - poskytuje zpětnou vazbu pro regulaci teploty TUV na požadovanou hodnotu

• čidlo teploty vzduchu v kanále vzduchotechniky - poskytuje zpětnou vazbu pro regulaci této teploty na požadovanou hodnotu

• čidla teploty TV v severní a jižní větvi - poskytuje zpětnou vazbu pro regulaci této teploty na požadovanou hodnotu Poznámka: Severní větev a jižní větev jsou tzv. ekvitermní větve. To znamená, že požadované hod-

noty teplot TV v jednotlivých větvích se počítají na základě příslušných venkovních teplot (na severní a na jižní straně) pomocí tzv. ekvitermních křivek.

• čidla venkovních teplot na severní a na jižní straně - slouží jako podklad pro výpočet žádaných hodnot teplot TV v jednotlivých ekvitermních

větvích • čidlo teploty místnosti v přízemí

- poskytuje zpětnou vazbu pro regulaci této teploty na žádanou hodnotu • trojice hladinových spínačů v nádrži kondenzátu (horní, střední a dolní úroveň)

- poskytují dohromady tříúrovňový údaj o stavu hladiny kondenzátu v nádrži (Na základě těchto údajů systém ovládá čerpadla kondenzátu ze stanice, případně čerpadlo pro předehřev TUV.)

• teplotní spínač na zpětné potrubí TV ve větvi VZT - spíná při teplotě <5°C. Tento stav nastane při nežádoucím podchlazení výměníku, kdy

hrozí jeho namrzání, případně zamrznutí. (Systém v takovémto případě musí zajistit uzavření klapky a vypnutí ventilátoru v kanálu VZT a současně otevřít naplno směšovací ventil pro odmrazení výměníku. Tomuto opatření se říká protimrazová ochrana - PMO.)

• teplotní spínač pro indikaci překročení max. teploty stanice - v případě sepnutí systém vyhlásí havarijní stav

• zaplavení stanice - v případě sepnutí systém vyhlásí havarijní stav

• pomocné kontakty stykačů u všech čerpadel a u ventilátoru - informují systém o tom, jestli došlo k sepnutí stykačů, či nikoliv

• kontakty koncového spínače servopohonu uzavírací klapky v kanálu VZT - informuje systém o skutečné poloze klapky

Použití některých čidel není zdůvodněno přímo požadavkem na dodržení tech-nologického postupu, ale pouze snahou zajistit řídicímu systému více informací o řízeném procesu za účelem zkvalitnění a zrychlení regulačního pochodu. Jsou to: • čidlo teploty TV ve větvi VZT • čidlo teploty TV ve větvi P • čidlo teploty TUV před nádržemi • čidlo teploty TV na rozdělovači

Příslušné teploty mohou být řídicím systémem využívány jako pomocné regulované

veličiny.

15. Ekonomická rozvaha jako součást projekčních prací Součástí automatizačního projektu PRS (projektu řídicího systému) je také ekonomická rozvaha. Tato rozvaha bere v úvahu jak investiční náklady, tak roční neinvestiční náklady. Ekonomickou rozvahu ukážeme na projektu systému zásobování teplem. Úkolem je stanovit ekonomickou rozvahu řídicího systému včetně procesní instrumentace a ročních nákladů na provoz a inovaci HW/SW. Náklady v tomto případě dělíme na :

a) investiční náklady a. náklady na přípravné práce na projektu ( úvodní studie, podrobná specifikace

úkolu, výběrové řízení, dohled nad projektem) b. náklady na hardware (řídicí system s periferiemi, distribuované řídicí systémy,

výkonové členy, procesní instrumentace, elektroinstalace) c. náklady na SW ( operační system, automatizační aplikační SW, pomocný SW) d. náklady na inženýrské práce ( projekční práce, uvedení do chodu, zaškolení

obsluhy, tvorba dokumentace, náklady na testy) e. vnitřní náklady ( náklady na stavební přípravu, náklady na velín, nábytek)

b) roční provozní náklady a. náklady na operátora b. náklady na údržbu řídicího systému, včetně procesní instrumentace – 5% ročně

z investičních nákladů na HW c. náklady na update SW- 5% z investičních nákladů na SW d. pronájem veřejných telekomunikačních linek e. energie pro provoz ŘS

V následujícím uveďme odhad těchto nákladů na modelovém řídicím systému. Odhad nákladů vychází z údajů několika výrobců. Pro pochopení vlastní metody ekonomické rozvahy nejsou důležité absolutní částky za jednotlivé položky v EUR, ale jejich skladba, poměr a procentuální údaje. Ad a) Odhad investičních nákladů

- řídicí systém s centrální WS, vč. operačního systému a základního aplikačního SW, grafický SW a SW pro projektování systému (včetně konfigurování a uvedení do chodu)

65 000,- EUR + 22,- EUR/datový bod

- nutné periferie, vč. instalace, oživení 1 050,- EUR/ přístroj

- vstupní/výstupní jednotky, vč. SW 54,- EUR/datový bod

- pomocný SW (hlídání mezních hodnot, automatické najíždění dle čas. Programu, cyklické funkce, reakce na špičkovou zátěž, statistiky pro zpracování historických dat)

1 900,- EUR/funkci - projektování, uvedení do chodu, testy funkcí

700,-EUR/funkci - zkušební provoz, tvorby dokumentace

7,-EUR/datový bod Další dodatečné náklady na případné doplnění HW/SW je třeba ještě dodat.

Ad b) Odhad provozních nákladů - osobní náklady na obsluhu(operátor)

35 000,- EUR/rok - servis

• 2 - 5% ročně z celkové ceny HW - update SW

• 2 – 5% ročně z celkové ceny SW - náklady na energie na provoz celého automatizačního systému

• 1% ročně z celkové ceny HW Náklady za pronájem veřejných telekomunikačních linek je třeba dodat s aktuálními cenami. Odhad úspor, souvisejících se zavedením projektu automatizačního systému je dost obtížné obecně vyčíslit. Jde on to, že velká část těchto úspor se projevuje spíše dlouhodobě, jako např.:

- prodloužení životnosti zařízení - redukce výpadků a poruch - lepší ovladatelnost procesu - vyšší uživatelský komfort

Na druhé straně lze vyčíslit úspory, které vzniknou zavedením automatizačního projektu v důsledku úspor energie, jak je patrné z následujícího přehledu:

a) úspory, plynoucí ze základních funkcí řídicího systému úspory energií - redukce teploty o 10C 5% (důvodem je lepší regulace ) - ekvitermní regulace 3 – 20% - časové řízení 5 – 20% (denní, týdenní a roční programy) - noční režim 1 – 5% - útlumový režim 1 – 2% - míchání vzduchu pomocí klapek 1 – 2% ( přepínání odvozené od entalpie) - míchání vzduchu pomocí klapek 1 – 2% (přepínání odvozené od teploty) - snížení tlaku 3 – 12% - volné noční chlazení 1 – 5% - přepínání kotle 1 – 3% Každý systém nemá možnost využít všech metod úspor, zde jde o komplexní pohled na možné vyčíslitelné úspory. úspory nákladů na personál - dálkové sledování technologie cca 22% - centrální dokumentování nákladů cca 5% - dálková parametrizace požadovaných hodnot cca 1% b) další úspory úspory energií - sledování maximálního výkonu a ekonomické připínání cca 6% - optimalizace start – stop režimu 5 – 15% - redukce času provozu 3- 10%

- statistické vyhodnocení těžko kvantifikovat materiálové úspory - snížení nákladů na provedení dozorny (velína) cca 32%

15.1 Metody pro vyhodnocení ekonomiky projektu V současnosti se používají následující metody pro vyhodnocení ekonomiky projektu. Jde o : - payback – method ( se započítáváním doby amortizace) - NPV – method ( se započítáním „rendite“-úrokové míry, NPV je Net Present Value)

Payback – method vypočítává dobu návratnosti, tedy čas, ve kterém se investice vrátí v důsledku úspor. Metoda není vhodná, pokud chceme provozovat projekt nad dobu amortizace. Doba amortizace se počítá takto: I n = ---------- K – k kde n = doba amortizace v rocích I = jednorázové investiční náklady K= roční úspory v důsledku zavedení investice k = roční náklady na provoz investice Investiční záměr je dle této metody akceptovatelný, vychází-li doba amortizace do 3 let. U investic ve veřejné sféře je akceptovatelná doba amortizace do 8 let, v průmyslu však jen do 3 let. Na druhé straně u NPV metody se berou v potaz kapitálové náklady a aktuální hodnota investice v důsledku ročního výnosu kapitálového vkladu (rendity) po celou dobu životnosti investice. Výsledkem NPV metody je hodnota PW (Present Worth- aktuální hodnota): n PW = Σ Ft . (1 – i) –t t=1 kde : PW = současná hodnota investice n = doba životnosti v rocích t = doba v rocích od uvedení do chodu Ft = celkové náklady minus úspory v roce t (netto Cash - Flow ???) i = roční výnos kapitálového vkladu (rendita) Vnitřní rendita investice se vypočítá z PW = 0. Doporučuje se nejprve spočítat návratnost investice podle prvního způsobu (payback – method) a pokud vyjde doba n větší než 3 roky, je možné vypočítat dle druhé metody aktuální hodnotu investice v následných létech. Na dalším příkladu si ukažme, jak z těchto ekonomických úvah lze rozhodnout o výběru řídicího systému ze dvou možných variant. Mějme dva řídicí systémy, které mají určitou různou počáteční investiční hodnotu a dále různé dodatečné investice v průběhu doby životnosti a různé odhadované možnosti úspor energie apod. Levnější systém není možné inovovat dodatečnými náklady za účelem plně automatického chodu bez obsluhy. Na příkladu

se ukáže, že zdánlivě levnější systém bude pro investora nákladnějším vzhledem k tomu, že dražší systém uspoří na nákladech na obsluhu. Rok Náklady/Činnosti/Příčiny Alternativa A Alternativa B v DM v DM 0 přístroje, SW, zabudování - 100 000 - 120 000 ------------------------------------------------ Investiční náklady - 100 000 - 120 000 1 přístroje, SW, zabudování 0 - 40 000 obsluha 5%, údržba 5% -10 000 - 10 000 úspora energií 5 000 5 000 další úspory 0 10 000 -------------------------------------------------- Netto Cash-Flow - 5 000 - 35 000 2 přístroje, SW, zabudování - 100 000 - 200 000 obsluha, údržba -30 000 - 30 000 úspora energií 35 000 35 000 další úspory 0 10 000 ------------------------------------------------- Netto Cash – Flow - 95 000 - 185 000 3 přístroje, SW, zabudování 0 0 obsluha, údržba - 30 000 - 30 000

úspora energií 70 000 70 000 další úspory 0 100 000 ------------------------------------------------ Netto Cash – Flow 40 000 140 000

4 přístroje, SW, zabudování 0 0 obsluha, údržba - 30 000 - 30 000

úspora energií 100 000 100 000 další úspory 0 70 000 ------------------------------------------------- Netto Cash – Flow 70 000 140 000

5 Netto Cash – Flow 70 000 140 000 6 Netto Cash – Flow 70 000 140 000 7 Netto Cash – Flow 70 000 140 000 Jak je vidět, po uvedení základních investičních celků do chodu v roce 0 a po počátečních dvou letech, ve kterých dochází k dobudování obou systémů, přičemž varianta B má výrazně vyšší investiční náklady, začne se ve 3. roce provozu projevovat výhody flexibility dražší varianty B a to v tzv. dalších úsporách. Jde zřejmě o úspory platů operátora plně automatické

stanice, vyšší produktivity práce s variantou B a vyšší spolehlivosti varianty B, kdy nedochází k výpadkům a tudíž ke ztrátám v platbách za přerušené dodávky tepla. Na tomto příkladu lze ukázat též jednu z metod výpočtu doby amortizace. Ukažme ji na Variantě B. Netto náklady ve fázi investiční ( 1. a 2. rok) - 340 000 Netto Cash – Flow od 3. roku dále 140 000 Z toho : 340 000 : 140 000 = 2,5 roků Investiční období 2 roky ----------------------------- Doba amortizace 4,5 let Je vidět, že payback metoda se svým vztahem

I n = ---------- K – k Je použita pro Cash – Flow od 3. roku dále, avšak o první dva roky, ve kterých je investor v záporu je nutné výsledek payback metody zvýšit.