ŽILINSKà UNIVERZITA V ŽILINE Diplomová práca Obsah ... - Utc.sk
ŽILINSKà UNIVERZITA V ŽILINE Diplomová práca Obsah ... - Utc.sk ŽILINSKà UNIVERZITA V ŽILINE Diplomová práca Obsah ... - Utc.sk
ŽILINSKÁ UNIVERZITA V ŽILINEDiplomová prácadatabáza čoskoro zahltila značnú časť úložného priestoru na diskoch DB servera. Pretoz hľadiska optimalizácie nieje potreba niektoré časové rady zakaždým prepočítavaťa archivovať, plne postačuje v tomto prípade vytvoriť tzv. fiktívne časové rady ktoré sabudú definovať matematickým predpisom a až v prípade keď ich je treba sa z prvotnýchčasových rád prepočítajú. Typickým príkladom je časová rada reprezentujúca odchýlku,ktorej archivácie nieje potrebná lebo je ju vždy jednoduché vypočítať ako rozdiel pánuspotreby a skutočnou spotrebou EE.Kvôli prehľadnosti archivačného systému by mal tento archív podporovaťzlučovanie jednotlivých časových rád do tzv. scenárov (skupín časových rád). Tietoscenáre bude musieť byť možné hierarchicky organizovať formou stromu. Jedna časovárada sa bude môcť nachádzať vo viacerých takto vytvorených scenárov. Nad scenármialebo skupinami scenárov bude systém podporovať tvorbu bilancií a kalkulácii. Každýscenár bude podliehať kontrole na úroveň prístupu užívateľa pri ktorom bude môcť byťdefinované ktoré skupiny osôb budú mať k nemu povolený prístup (napríklad ibaskupina z obchodného dispečingu a pod.).Obr. 7.1. Návrh štruktúry DB archívuKVES 48
ŽILINSKÁ UNIVERZITA V ŽILINEDiplomová práca7.3. Návrh aplikačného SW energetického dispečinguSW aplikácia energetického dispečingu musí byť postavená na architektúre klient –server s podporou pre paralelne pracujúcich užívateľov systému s kontrolou vzájomnejvýlučnosti prístupu k zdieľaným údajom. Klienti budú priamo energetický dispečeripracujúci na smeny. Preto musí celý komplex (centrála, aplikácia a podporná výpočtovátechnika) byť schopný nepretržitej prevádzky 24 hodín denne a 365 dní v roku. Z tohodôvodu by mal byť nainštalovaný náhradný zdroj elektrickej energie garantujúcipokrytie výpadku napájania v dĺžke minimálne 2 hodiny.Hlavnou úlohou aplikácie energetického dispečingu bude v reálnom čase sledovanie,vizualizácia a monitorovanie komplexných energetických informácií (spotreba EE,odchýlka atď.), taktiež polohy jednotlivých HDV, všetko na úrovni minútových údajov.Zobrazovanie údajov v reálnom čase by malo byť riešené na strane klientov v plnomgrafickom užívateľskom prostredí. Tí budú kontrolovať celkový odber EE z hľadiskadojednaných výkonov t. j. podľa dojednaného DDZ a kritérií, ktoré naplánovala zobchodoval obchodný dispečing. V prípade ak by tento ober nemal byť dodržaný t.j.železničný prepravca by spôsoboval odchýlku voči dojednanému množstvu elektriny.Musí energetický dispečing v spolupráci s prevádzkovým vlakovým dispečingompriaznivo ovplyvniť spotrebu EE vzájomnou organizáciou riadenia prevádzky. Takýmtospôsobom ED minimalizuje prekročenia dojednaných parametrov v danom časovomintervale.Zobrazovanie údajov ako napríklad odchýlok by malo byť na strane klienta grafickéa číselné v členení podľa prevádzkovateľov distribučných sústav a sumárnej odchýlky.Najdôležitejšie sledované veličiny budú zobrazované na table dispečera z jednominútovýchúdajov spotreby a v prípade prekročenia sledovaných parametrov musíaplikácia ED automaticky obsluhu upozorniť (najvhodnejšie alarmom) na pre možnosťregulačného zásahu.7.4. Návrh aplikačného SW obchodného dispečinguAplikácia obchodného dispečingu bude informačný systém pre podporuobchodovania s elektrinou na liberalizovanom trhu so zámerom dlhodobej optimalizácienákladov na zabezpečenie elektrickej energie. Aplikácia bude musieť podporovaťsprávu dvojstranných zmlúv a burzových obchodov s elektrinou. V rámci podpornýchnástrojov pre proces obchodovania musí umožniť stanovenie rôzneho časového trvaniaKVES 49
- Page 1: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 4 and 5: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 6 and 7: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 8 and 9: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 10 and 11: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 14 and 15: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 16 and 17: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 18 and 19: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 20 and 21: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 22 and 23: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 24 and 25: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 26 and 27: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 28 and 29: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 30 and 31: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 32 and 33: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 34 and 35: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 36 and 37: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 38 and 39: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 40 and 41: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 42 and 43: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 44 and 45: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 48 and 49: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 50 and 51: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 52 and 53: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 54 and 55: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 56 and 57: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 58 and 59: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
- Page 60: ŽILINSKÁ UNIVERZITA V ŽILINEDipl
ŽILINSKÁ <strong>UNIVERZITA</strong> V ŽILINEDiplomová prácadatabáza čo<strong>sk</strong>oro zahltila značnú časť úložného priestoru na di<strong>sk</strong>och DB servera. Pretoz hľadi<strong>sk</strong>a optimalizácie nieje potreba niektoré časové rady zakaždým prepočítavaťa archivovať, plne postačuje v tomto prípade vytvoriť tzv. fiktívne časové rady ktoré sabudú definovať matematickým predpisom a až v prípade keď ich je treba sa z prvotnýchčasových rád prepočítajú. Typickým príkladom je časová rada reprezentujúca odchýlku,ktorej archivácie nieje potrebná lebo je ju vždy jednoduché vypočítať ako rozdiel pánuspotreby a <strong>sk</strong>utočnou spotrebou EE.Kvôli prehľadnosti archivačného systému by mal tento archív podporovaťzlučovanie jednotlivých časových rád do tzv. scenárov (<strong>sk</strong>upín časových rád). Tietoscenáre bude musieť byť možné hierarchicky organizovať formou stromu. Jedna časovárada sa bude môcť nachádzať vo viacerých takto vytvorených scenárov. Nad scenármialebo <strong>sk</strong>upinami scenárov bude systém podporovať tvorbu bilancií a kalkulácii. Každýscenár bude podliehať kontrole na úroveň prístupu užívateľa pri ktorom bude môcť byťdefinované ktoré <strong>sk</strong>upiny osôb budú mať k nemu povolený prístup (napríklad iba<strong>sk</strong>upina z obchodného dispečingu a pod.).Obr. 7.1. Návrh štruktúry DB archívuKVES 48
Change language