PROJEKTOVÁNÍ ŘÍDICÍCH SYSTÉMU Učební texty

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.
Rozpis problému
Řešitel
(dodavatel
PRS)
Spolupráce při
vypracování
Studie nabídky
Vypracování
nabídky
Sledován
í vývoje
PRS
Kontrakt
Nabídka
Požadavky
uživatele
Poptávka
Investor
Analýza
problému
Rozpracování
Vývoj
závazné systémové
specifikace
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.
Rozpis problému
Studie nabídky
Spolupráce při
vypracování
Sledování
vývoje PRS
Vypracování
projektu
s rozpracováním
poptávek
subdodavatelům
Vývoj
Příprava
nabídek
Subdodavatelé
Přípravná fáze projektu
Kontrakty
Kontrakt
Nabídky
Vypracování
nabídky
Poptávky
Hlavní
dodavatel
Nabídka
Požadavky
uživatele
Poptávka
Investor
Analýza
problému
Vývojové
práce
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
Popis úlohy a cílů
Přehledný popis
Dokumenty pro
průběh
projektových prací
Analýza situace
Popis systému
Požadavky
Popis funkce
Odborná koncepce
řešení
Celková
koncepce
Algoritmy
řešení
Systémový návrh
Alternativy
řešení
Popis komponentů
automatizačního
systému
SW
Poptávky a
nabídky
Závazný
dokument
HW
Organizační
struktura
Rozhraní
Popis projektu
Senzory, aktory
Časové a
cenové údaje
HMI
Rozhodování
mezi
alternativami
Výsledný návrh
Pomocné nástroje
návrhu
Plánování testů
Programové
prostředky
Další dokumentace
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 vzduchotechniky. 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 kondenzá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 havarijní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 vstupvý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í zvyklostmi 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 technologický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é hodnoty 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í technologické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
-
update SW
•
2 - 5% ročně z celkové ceny HW
• 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
- centrální dokumentování nákladů
- dálková parametrizace požadovaných hodnot
b) další úspory
úspory energií
- sledování maximálního výkonu a ekonomické připínání
- optimalizace start – stop režimu
- redukce času provozu
cca
cca
cca
22%
5%
1%
cca
6%
5 – 15%
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
v DM
0
přístroje, SW, zabudování
- 100 000
- 120 000
------------------------------------------------ 100 000
- 120 000
Investiční náklady
1
přístroje, SW, zabudování
obsluha 5%, údržba 5%
úspora energií
další úspory
Netto Cash-Flow
2
přístroje, SW, zabudování
obsluha, údržba
úspora energií
další úspory
Netto Cash – Flow
3
přístroje, SW, zabudování
obsluha, údržba
úspora energií
další úspory
Netto Cash – Flow
4
přístroje, SW, zabudování
obsluha, údržba
úspora energií
další úspory
Netto Cash – Flow
Alternativa B
v DM
0
- 40 000
-10 000
- 10 000
5 000
5 000
0
10 000
-------------------------------------------------- 5 000
- 35 000
- 100 000
- 200 000
-30 000
- 30 000
35 000
35 000
0
10 000
------------------------------------------------- 95 000
- 185 000
0
0
- 30 000
- 30 000
70 000
70 000
0
100 000
-----------------------------------------------40 000
140 000
0
0
- 30 000
- 30 000
100 000
100 000
0
70 000
------------------------------------------------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.