České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce
Bakalářská práce
Simulace řídicího algoritmu systému DIRC Petr Slavotínek
Vedoucí práce: Ing. Richard Šusta, Ph.D.
Studijní program: Softwarové technologie a management, bakalářský Obor: Web a multimédia 16. května 2011
iv
Poděkování Tímto bych chtěl poděkovat Ing. Richardu Šustovi Ph. D. za nedocenitelné rady, které mi během tvorby práce poskytoval. Poděkování patří také zaměstnancům společnosti Enesa a.s. za jejich spolupráci a mé rodině a nejbliţším přátelům za jejich podporu po celou dobu studia. v
vi
Prohlášení Prohlašuji, ţe jsem práci vypracoval samostatně a pouţil jsem pouze podklady uvedené v přiloţeném seznamu. Nemám závaţný důvod proti uţití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Jablonci nad Nisou dne 12. 5. 2011
………………………………….
vii
viii
Abstract This thesis deals with implementation of an application that serves as a standalone extension of the system for individual room temperature control named DIRC. Principles of building automation are described in the first chapter, followed by an analysis of software part of DIRC, especially its database and description of data collection and storing to a database of Enesa a.s. company. It is concluded by the creation of an algorithm for backward calculation of a curve of required temperature and by designing of a web application used for data analysis and visualization.
Abstrakt Práce se zabývá návrhem a implementací aplikace, která slouţí jako nadstavba systému pro individuální řízení vytápění místností s názvem DIRC. V první části jsou popsány základy problematiky automatizace řízení budov. Následně je analyzována softwarová část systému DIRC, především databáze a popsán sběr jeho dat na datové úloţiště společnosti Enesa a.s.. Posledním krokem je tvorba algoritmu pro zpětné získání průběhu poţadované teploty a návrh webové aplikace slouţící k analýze a vizualizaci získaných dat.
ix
x
Obsah 1
Úvod ........................................................................................................................................ 1 1.1 Popis problému .................................................................................................................... 1 1.2 Cíle práce............................................................................................................................. 1 1.3 Shrnutí obsahu ..................................................................................................................... 2
2
Automatizace řízení budov ...................................................................................................... 3 2.1 Vytápění budov ................................................................................................................... 4 2.2 Princip automatické regulace .............................................................................................. 5 2.3 Regulace zdroje tepla .......................................................................................................... 6 2.3.1 Regulace pokojovým termostatem v referenční místnosti .......................................... 6 2.3.2 Ekvitermní regulace .................................................................................................... 6 2.4 Regulace otopných těles ...................................................................................................... 7 2.4.1 Termostatické hlavice ................................................................................................. 7 2.4.2
Elektronická zónová regulace ..................................................................................... 7
2.5 Prediktivní regulace tepla .................................................................................................... 8 2.6 Příklady skutečných řešení .................................................................................................. 9 2.6.1 Etatherm...................................................................................................................... 9 2.6.2 Trasco ......................................................................................................................... 9 2.6.3 M.E.R.......................................................................................................................... 9 3
Systém DIRC ......................................................................................................................... 11 3.1 Funkční úrovně systému DIRC ......................................................................................... 11 3.1.1 Správní úroveň .......................................................................................................... 12 3.1.2 Řídicí úroveň ............................................................................................................ 13 3.1.3 Transakční úroveň .................................................................................................... 13 3.1.4 Zónová úroveň .......................................................................................................... 13 3.2 Regulace teploty ................................................................................................................ 13 3.3 Spolupráce systému DIRC a ekvitermního regulátoru ...................................................... 14 3.4 Předpoklady pro správnou funkčnost systému DIRC........................................................ 14 3.5 Řízení zóny systémem DIRC ............................................................................................ 15 3.5.1 Důleţité pojmy ......................................................................................................... 15 3.5.2 Schéma řízení systémem DIRC ................................................................................ 15 3.5.3 Poţadovaný stav v zóně ............................................................................................ 16 3.5.4 Poţadovaný stav „dle programu“ ............................................................................. 17
xi
3.5.5 3.5.6 3.5.7 3.5.8 3.5.9
Teplotní reţimy vytápění ......................................................................................... 18 Určení poţadované teploty ....................................................................................... 18 Programová reference a tepelná a programová reference ........................................ 19 Skupiny .................................................................................................................... 19 Teplotní náběhová rampa, doba poklesu a hysterze ................................................. 19
3.6 Nedostatky systému DIRC ................................................................................................ 20 3.7 Analýza systému DIRC..................................................................................................... 21 3.7.1 Databáze ................................................................................................................... 21 Sestavení simulačního algoritmu .......................................................................................... 27
4
4.1 Výběr technologie ............................................................................................................. 27 4.2 Získávání dat ..................................................................................................................... 28 4.3 Zpracování dat .................................................................................................................. 29 4.3.1 Struktura databázových tabulek ............................................................................... 30 4.3.2
Simulační algoritmus ............................................................................................... 32
Webová aplikace pro analýzu dat .......................................................................................... 37
5
5.1 Poţadavky zadavatele ....................................................................................................... 37 5.1.1 Grafy ........................................................................................................................ 37 5.1.2
Tabulková data ......................................................................................................... 38
5.2 Architektura aplikace ........................................................................................................ 42 5.3 Plánovaná budoucí rozšíření ............................................................................................. 44 Testování ............................................................................................................................... 45
6
6.1 Testování s umělými daty ................................................................................................. 45 6.2 Testování s reálnými daty ................................................................................................. 45 6.3 Závěry z testování ............................................................................................................. 46 7
Závěr ..................................................................................................................................... 47
8
Seznam pouţité literatury ...................................................................................................... 49
9
Seznam pouţitých zkratek ..................................................................................................... 51
Příloha A ........................................................................................................................................ 53 Příloha B ........................................................................................................................................ 57 Příloha C ........................................................................................................................................ 59 Příloha D ........................................................................................................................................ 61
xii
Seznam obrázků Obr. 1. Obecné schéma systému řízení budov.................................................................................. 4 Obr. 2. Schéma příkladu ústředního vytápění ................................................................................. 5 Obr. 3. Blokové schéma regulované soustavy .................................................................................. 6 Obr. 4. Příklad soustavy ekvitermních křivek .................................................................................. 6 Obr. 5. Schéma zónové regulace ...................................................................................................... 8 Obr. 6. Schéma úrovní systému DIRC ........................................................................................... 12 Obr. 7. Blokové schéma systému DIRC ......................................................................................... 15 Obr. 8. Porovnání průběhu poţadované ......................................................................................... 20 Obr. 9. Zobrazení průběhu teploty v uţivatelském prostředí systému DIRC ................................. 21 Obr. 10. Diagram konfiguračních tabulek systému DIRC ............................................................. 22 Obr. 11. Diagram záznamových tabulek systému DIRC ................................................................ 24 Obr. 12. Schéma přenosu dat mezi databázemi .............................................................................. 29 Obr. 13. Diagram databáze „DIRCAnalysis“ ................................................................................. 30 Obr. 14. Průběh poţadované teploty včetně poţadovaných stavů.................................................. 31 Obr. 15. Diagram nasazení ............................................................................................................. 36 Obr. 16. Závislost teploty na čase, porovnání skutečné a poţadované teploty .............................. 38 Obr. 17. Závislost míry přetápění a nedotápění na procentu doby ................................................. 38 Obr. 18. Reálný vývoj teploty v zóně a hodnoty skutečné teploty ................................................. 39 Obr. 19. Spolupráce Modelu, View a Presenteru ........................................................................... 44
xiii
xiv
1 Úvod Tato práce vychází z oboru automatizace vytápění budov, který se v dnešní době těší stále větší popularitě. Jedním z řešení pro individuální řízení vytápění místností je i systém DIRC od společnosti DOT CONTROLS a.s, jehoţ rozboru je věnována podstatná část práce.
1.1 Popis problému Systém DIRC se z důvodu své nízké pořizovací ceny vyuţívá především ve velkých komplexech budov, jakými jsou například školy nebo nemocnice. Jeho uţivatelské rozhraní umoţňuje přehledným způsobem konfigurovat vytápěcí programy pro jednotlivé místnosti. Nabízí však nedostatečné nástroje pro zobrazení statistik a grafů průběhů poţadované a skutečné teploty. Vyhledávání chybně nastavených místností se zejména při jejich větším počtu stává velice obtíţným a časově náročným úkolem.
1.2 Cíle práce Společnost Enesa a.s. proto poţaduje vytvoření samostatné nadstavby v podobě webové aplikace. Software systému DIRC není moţné rozšířit, protoţe společnost DOT CONTROLS a.s. odmítá poskytnutí jeho zdrojového kódu. Nadstavba umoţní analýzu a optimalizaci individuálního řízení teplot uvnitř místností, coţ by mělo vést ke snadnějšímu odhalování chyb v nastavení systému DIRC i ke sníţení spotřeby energie vynaloţené na vytápění. Jejímu vytvoření musí předcházet důkladná analýza moţností systému DIRC a jeho softwarové části. Důraz bude kladen především na databázi systému, na jejichţ základech bude nový nástroj vystavěn. Hlavním úkolem práce je vytvoření algoritmu pro zpětné získání průběhu poţadované teploty a teplotních reţimů vytápění, jeţ systém DIRC ukládá v nevyhovující podobě. Bude nutné otestovat správnost běhu algoritmu na reálných datech. Vypočtená data budou základem jednoduchých algoritmů, jejichţ výstupy pomohou zaměstnancům společnosti Enesa a.s. k nalezení nesprávně nakonfigurovaných místností. Výsledky budou zobrazovány ve webové aplikaci, která prozatím bude poskytovat pouze základní funkce. Do budoucna se počítá s jejím rozšiřováním a obohacováním o pokročilé nástroje jako například automatizace vyhledávání chybných konfigurací.
1
1.3 Shrnutí obsahu V první části práce je nastíněna problematika spojená s automatizací řízení moderních budov – bude věnována především vytápění. V další kapitole je představen systém DIRC a uvedeny jeho moţnosti i nedostatky, které jsou hlavním podnětem pro vytvoření nové aplikace. Její vývoj je rozčleněn do několika kroků. Patří mezi ně sběr dat ze systému DIRC, implementace algoritmu pro zpětný výpočet průběhu poţadované teploty, způsob uloţení takto získaných dat a návrh webové aplikace pro jejich analýzu a vizualizaci.
2
2 Automatizace řízení budov Celá následující kapitola je shrnutím informací, které jsem získal z odborné literatury a především z odborných článků umístěných na internetu. Alespoň částečné nastudování problematiky týkající se automatizace budov mi následně pomohlo lépe proniknout do funkcí systému DIRC. V posledních letech dochází k rozvoji vědního oboru nazývaného automatizace budov, který se zabývá projektováním takzvaných inteligentních budov a systémů v nich pouţívaných. Vznik oboru umoţnil aţ nástup moderních vyspělých počítačů a softwarových systémů a důvěra lidí v jejich vysokou spolehlivost. Účelem inteligentních budov je zjednodušit řízení jejich chodu a osamostatnit řídicí systémy a technologie od lidských zásahů. V budově je instalována soustava hardwarových a softwarových distribuovaných komponent, které spolu navzájem komunikují a svými zásahy ovlivňují vnitřní klimatické podmínky, osvětlení, zabezpečení a mnoho dalších faktorů. Systémy starající se především o kontrolu a úpravu teploty, vlhkosti a proudění vzduchu se označují anglickou zkratkou HVAC1 [1]. Správná volba a nastavení automatizačních systémů by měla vést ke sníţení spotřeby energie a velikosti personálu nutného k obsluze systémů budovy. Jednotlivé komponenty se rozdělují do několika vrstev (Obr. 1.). Ve vrchních vrstvách se nacházejí univerzální komponenty a s postupným zanořováním se více specifikují. Komunikace mezi jednotlivými vrstvami v současné době neprobíhá pomocí standardizovaných protokolů. Záleţí pouze na výrobci konkrétního zařízení, jaký protokol zvolí. Společnosti často vyvíjejí svůj vlastní protokol, a tudíţ jich existuje celá řada. Nejvyšším článkem systému obvykle bývá řídicí počítač, který obsahuje samotný řídicí software označovaný jako Building Management System (BMS), neboli systém správy budov. Zprostředkovává komunikaci mezi odlišnými protokoly vrstev a uţivatelům většinou poskytuje grafické rozhraní pro kompletní nastavení systému, přehled aktuálních i historických měřených dat a moţnost nastavit si pravidla a omezení, při jejichţ porušení je pověřená osoba upozorněna výstrahou, emailem nebo i SMS zprávou. Moderní systémy zprávy budov poskytují webová rozhraní, která umoţňují ovládání chodu budovy téměř odkudkoliv. 1
HVAC – Heating, Ventilation and Air-Conditioning
3
Systém DIRC, který je výchozím bodem mé práce, umoţňuje řídit pouze teplotu v interiérech objektů, a proto se budu nadále věnovat jediné oblasti z problematiky řízení inteligentních budov, kterou je vytápění.
Obr. 1. Obecné schéma systému řízení budov
2.1 Vytápění budov Automatizace vytápění budov přináší mnoho výhod – asi nejvýznamnější z nich je úspora energie vynaloţené na vytápění. Pouhá instalace řídicího systému však sníţení výdajů na spotřebu energie nezajistí. Instalaci musí předcházet pečlivý výběr systému a následně jeho nastavení, které nejlépe vyhovuje konkrétním podmínkám budovy. Efektivita a rychlost vytápění se liší pro kaţdou budovu. Velký vliv na ni má mimo jiné pouţitý materiál nebo způsob vytápění. Rozdílných výsledků je dosaţeno například s elektrickým přímotopem nebo s ústředním vytápěním. Rozlišují se dva hlavní způsoby vytápění – lokální a ústřední. Lokální vytápění je jednodušší a vyţaduje přítomnost místního zdroje tepla v kaţdé místnosti, jejíţ interiér chceme ohřívat. Výkon topidla je většinou manuálně regulován v závislosti na teplotě v místnosti. Sloţitější, ale také rozšířenější ústřední vytápění obsahuje jeden zdroj tepla pro všechny místnosti (Obr. 2.).
4
Zdrojem tepla obvykle bývá plynový či elektrický kotel nebo kotel na tuhá paliva. V kotli produkovaným teplem se ohřívá nejčastěji voda, která se čerpadlem vhání do sítě potrubí. Ohřátá topná voda je následně přivedena do radiátorů umístěných v jednotlivých místnostech. Radiátory se instalují do nejchladnějších míst pokojů – pod okna, coţ zajistí dostatečné proudění vzduchu a tím i jeho ohřev. Topné vody se mimo vytápění vyuţívá i k ohřevu uţitkové vody ve speciálních nádrţích. V následujících podkapitolách se budu zabývat pouze ústředním vytápěním.
Obr. 2. Schéma příkladu ústředního vytápění (obázek převzat z http://wiki.diyfaq.org.uk)
2.2 Princip automatické regulace Dříve neţ se přesunu k regulaci ústředního vytápění, stručně zmíním obecný princip automatické regulace. V regulované soustavě (Obr. 3.) se nachází senzor, regulátor a akční člen. Senzor umístěný v nějakém prostředí snímá měřenou veličinu y. Naměřenou hodnotu předá řídicímu obvodu – regulátoru, který ji porovná s poţadovanou hodnotou w. Na základě výsledku porovnání dojde k zásahu akčního členu, čímţ se reguluje veličina y. [11] Vytápění je nezbytné regulovat pro dosaţení co nejniţší spotřeby tepla. Rozlišuje se regulace zdroje tepla (např. kotel) a regulace otopných těles (např. radiátor). [9], [10] 5
Obr. 3. Blokové schéma regulované soustavy
2.3 Regulace zdroje tepla Ke zdroji tepla lze připojit termostat, který snímá aktuální teplotu topné vody a v závislosti na ní kotel zapíná a vypíná. Pokles spotřeby tepla se totiţ projeví růstem teploty topné vody.
2.3.1 Regulace pokojovým termostatem v referenční místnosti V menších stavbách, především rodinných domech, se setkáme s regulací pokojovým termostatem v referenční místnosti. Termostat na základě naměřené pokojové teploty posílá zdroji tepla povely s poţadavky zvýšení nebo omezení výkonu. Referenční místnost je nutné vytápět vţdy, kdyţ je poţadováno vytápění jiných místností, coţ nelze povaţovat za energeticky úsporné.
Teplota topné vody [°C]
Ekvitermní křivky pro různé teploty místnosti 100 80 60
25 °C 20 °C
40
15 °C
20 -20
-15
-10
-5
0
5
10
15
20
Venkovní teplota [°C]
Obr. 4. Příklad soustavy ekvitermních křivek
2.3.2 Ekvitermní regulace Kotel lze vybavit ekvitermním regulátorem, jenţ přizpůsobí výkon otopné soustavy okamţité venkovní teplotě. Čím je venkovní teplota niţší, tím dochází k větším tepelným 6
ztrátám. Pokud poţadujeme zachování konstantní teploty v místnosti, je nutné dodávat více tepla, čehoţ docílíme vyšší teplotou topné vody. Pro popis vzájemné závislosti teploty topné vody, teploty v místnosti a venkovní teploty se pouţívají soustavy ekvitermních křivek (Obr. 4.). [15]
2.4 Regulace otopných těles Regulace otopných těles nespočívá v úpravě teploty topné vody, ale v nastavení jejího průtoku radiátory. Umoţňuje tak šetrnější nakládání s energií neţ regulace zdroje tepla. Jejím nejjednodušším způsobem je ruční regulace, která se provádí otevíráním a uzavíráním kohoutů radiátoru. Není-li kohoutem delší dobu otočeno, můţe vlivem usazování vodního kamene dojít k jeho úplnému znehybnění.
2.4.1 Termostatické hlavice Alternativní řešení k ruční regulaci nabízejí termostatické hlavice. Nevyţadují ţádný zdroj energie, protoţe teplotní čidlo funguje na principu tepelné roztaţnosti látek. Na hlavici se nastaví poţadovaná pokojová teplota. Pokud je její skutečná hodnota niţší, ventil se otevře a do radiátoru začne proudit topná voda. Také termostatickým hlavicím hrozí zatuhnutí při delší době nečinnosti. [12]
2.4.2 Elektronická zónová regulace Rozvoj moderní elektroniky umoţnil vznik elektronické zónové regulace, která přinesla mnoho výhod například v podobě pohodlného ovládání a větších úspor energie. Zónová regulace je zaloţena na individuálním kontrolování a úpravě teploty v kaţdé místnosti objektu. Zónová regulace se často označuje anglickou zkratkou IRC2. [13] V kaţdé místnosti, kterou si přejeme individuálně kontrolovat, je instalován snímač aktuální teploty. V co nejkratších pravidelných intervalech odesílá naměřené hodnoty do zónového regulátoru, který porovnává skutečné a poţadované hodnoty pro aktuální okamţik. Informaci o poţadované teplotě regulátor získá z řídicí jednotky. Ze zónového regulátoru putuje signál do elektronické hlavice umístěné na otopném tělese, jímţ bývá nástěnný radiátor nebo systém podlahového vytápění. Signál v sobě nese příkaz k uzavření nebo otevření hlavice. Pokročilejší systémy umoţňují propojení zónového regulátoru s kotlem. Při nedostatečné teplotě topné vody je prostřednictvím regulátoru zvýšen výkon kotle. (Obr. 5.) Aktuální poţadovanou teplotu systém vypočítá z časového programu konkrétní zóny. V programu jsou zaneseny teplotní poţadavky pro průběh celého dne. Lze definovat ne2
IRC – Individual Room Control – Individuální regulace místností
7
závislé programy pro kaţdý den v týdnu. Individuální zónové programy přinášejí nejznatelnější úspory energie. Místnost je totiţ vytápěna jen době, kdy je to skutečně vyţadováno. Uţivatel například v programu nastaví, aby v nočních hodinách a v denní době, kdy není místnost vyuţívána lidmi, byla vytápěna na niţší teplotu neţ v čase, kdy je obývána.
Obr. 5. Schéma zónové regulace
Systémy můţeme rozlišit podle druhu komunikace na drátové a bezdrátové. V případě, ţe chceme rozšířit stávající systém vytápění o individuální zónovou regulaci, doporučuje se pouţití bezdrátových systémů, u nichţ odpadají potíţe s instalací vodičů. Naopak drátové systémy poskytují neustálý přívod napájení k elektrickým hlavicím otopných těles a proto není potřeba pravidelně vyměňovat baterie jako je tomu u bezdrátových systémů. Při volbě elektrických hlavic máme moţnost vybírat mezi termopohony a servopohony. Termopohon vychází z principu termostatické hlavice. Nabízí však pouze dva reţimy zapnuto a vypnuto. Přivedením proudu do termopohonu dojde k uzavření ventilu. Není-li termopohon napájen, ventil zůstává otevřený, do otopného tělesa proudí topná voda a místnost je vytápěna. Termopohony se vyznačují dlouhou reakční dobou. Technicky vyspělejší servopohony umoţňují plynulou regulaci toku topné vody otopným tělesem. Jsou vybaveny motorkem, který otáčením radiátorového ventilu mění míru jeho škrcení. Servopohony nevyţadují stálý přísun elektrické energie. Při přerušení dodávky proudu zůstane hlavice v poslední poloze, dokud napájení není obnoveno.
2.5 Prediktivní regulace tepla Prediktivní regulace tepla představuje budoucnost v oblasti vytápění budov. Kombinuje informace získané z předpovědí počasí a tepelného modelu budovy a na jejich základě předpovídá vývoj teploty uvnitř jednotlivých místností. Venkovní teplota v největší míře ovlivňuje teplotu vzduchu v místnostech. Pokud je znám její budoucí vývoj, lze včasnou regulací výkonu tepelného zdroje zabránit náhlému nedotápění nebo přetápění uvnitř budovy. Dosavadní testy vyuţití prediktivní regulace tepla ukazují její veliký potenciál, pře8
devším díky zvýšením úspor energie. Jeden z testů s překvapivě dobrými výsledky byl uskutečněn i na osmipatrové budově ČVUT v Praze v roce 2009. [14]
2.6 Příklady skutečných řešení Na českém trhu lze nalézt poměrně velké mnoţství firem, které nabízejí vlastní hardwarové i softwarové komponenty tvořící kompletní systémy pro regulaci tepla v individuálních místnostech. Jednou z nich je i společnost DOT CONTROLS a.s., která nabízí systém DIRC. Jeho princip detailněji popisuji v další kapitole.
2.6.1 Etatherm Moravská společnost Etatherm s.r.o. je autorem stejnojmenného systému, jenţ lze pouţít pro regulaci teplovodních i přímotopných elektrických soustav. Regulace se programuje přes počítačový software, který je na stránkách společnosti volně ke staţení. Výhodou systému Etatherm je pouţití servopohonů, které jsou oproti termopohonům šetrnější, co se spotřeby energie týče. Podrobnější informace můţe případný zájemce nalézt na internetových stránkách www.etatherm.cz.
2.6.2 Trasco Alternativu poskytují systémy od firmy Trasco, spol. s r. o., které jsou rozděleny do kategorií podle poţadovaného rozsahu regulace. Výrobce uvádí, ţe jeho produkt je při dvakrát aţ čtyřikrát niţší ceně kvalitativně srovnatelný se systémy nejznámějších světových firem jakými jsou Siemens nebo Johnson and Controls. Detailnější popis systémů Trasco lze nalézt na internetových stránkách www.trasco.cz.
2.6.3 M.E.R. Systém zónové regulace společnosti M.E.R. s.r.o. (www.mer.cz) vyuţívá univerzální řídicí jednotku UNISMAR. Jeho vizualizační program umoţňuje náhled na půdorys vytápěného objektu s přehledným zobrazením aktuálních poţadovaných a skutečných teplot v kaţdé místnosti.
9
10
3 Systém DIRC Systém DIRC (Distruibuted Independent Room Control) slouţí pro individuální zónovou regulaci ve středně velkých objektech. V současnosti nalézá největší uplatnění především ve školách, mateřských školkách a nemocnicích. Dodává jej společnost DOT CONTROLS a.s., která sídlí ve Starém Městě u Uherského Hradiště. Firma se zabývá projektováním, výrobou, instalacemi a opravami elektronických zařízení, poskytováním a poradenstvím v oblasti hardware a software a montáţemi, opravami a rekonstrukcemi chladicích zařízení a tepelných čerpadel. Internetovou prezentaci společnosti DOT CONTROLS a.s. lze nalézt na adrese www.dotweb.cz. Na uvedených stránkách je k dispozici podrobný manuál k systému DIRC. [8] Systém DIRC je vyuţíván společností Enesa a.s., jejíţ zákazníci chtějí dosáhnout sníţení nákladů na vytápění zavedením zónové regulace ve svých objektech. Enesa zvolila systém DIRC jako svůj hlavní nástroj z důvodu jeho nízké ceny a snadné instalace na jiţ existující síť ústředního vytápění v budovách. Tato kapitola je rozdělena na několik částí. V první popisuji architekturu systému DIRC, způsob, jakým ovlivňuje teplotu v místnostech a jeho integraci se stávajícími topnými systémy v budovách. Jednu podkapitolu jsem věnoval řízení místností systémem. Shrnuje, jaké mají uţivatelé moţnosti při nastavování poţadované teploty a jak je tato teplota pro daný okamţik vyhodnocována systémem DIRC. Zde jsem čerpal z manuálu systému a z konzultací s jeho autory ze společnosti DOT CONTROLS a.s.. Následuje shrnutí nedostatků systému, které vedly k vytvoření jeho nadstavby. V poslední části se zabývám jeho analýzou. Jedná se jiţ o mou vlastní práci, která se týká především databáze systému. Bylo nutné ji důkladně prozkoumat, protoţe se jedná o jedinou část systému DIRC, ke které bude mít nová aplikace přístup. S pouţitím pouze databázových tabulek by mělo být moţné zpětně sestavit průběh poţadované teploty a vyhodnotit správnost konfigurace místností.
3.1 Funkční úrovně systému DIRC Systém DIRC je rozčleněn na čtyři funkční úrovně (Obr. 6.), které se nazývají správní, řídicí, transakční a zónová. Kaţdá poskytuje některé regulační funkce a spolupracuje s ostatními. Rozdělení je uţitečné při návrhu aplikace a při tvorbě hierarchie distribuovaného řízení. 11
V dalším textu je pojmem zóna označován kaţdý prostor, ve kterém je zamýšleno řídit teplotu systémem DIRC. Nejčastěji se jedná o některou z místností objektu.
Obr. 6. Schéma úrovní systému DIRC
3.1.1 Správní úroveň Správní úroveň představuje nejvyšší úroveň v hierarchii a má za úkol poskytovat uţivatelské rozhraní pro přístup k aplikaci, nastavení systému a zobrazení jeho stavu. Uchovává konfigurační a dlouhodobou monitorovací databázi.
12
3.1.2 Řídicí úroveň Druhá, řídicí úroveň odpovídá za dodrţování poţadované teploty v zónách. Neustále vypočítává aktuální poţadavky na stav a teplotu zóny a výsledky předává transakční úrovni. Teplotu v čase můţe regulovat naprosto samostatně a nezávisle na úrovni správní. Správní i řídicí úroveň je pokryta jednou komponentou. Jedná se o jednotku IPC-9K, která je tvořena průmyslovým počítačem. Chová se jako webový server, a proto se k uţivatelskému přístupu pouţívá libovolné PC zapojené do stejné sítě jako ona a webový prohlíţeč s nainstalovaným prostředím Java JRE.
3.1.3 Transakční úroveň Transakční úroveň dostává od řídicí úrovně poţadavky na stav aktuátorů a teplotu v zóně. Neustálým porovnáváním poţadované a skutečné teploty v zóně a řízením aktuátorů se snaţí dosáhnout stanovené poţadované teploty. Transakční jednotka TRU-9K-xy je s nadřazenou řídicí jednotkou propojena pomocí sběrnice dOutsideLink nebo Ethernet a s podřízenými zónovými jednotkami sběrnicí dPowerLink, pro které zároveň slouţí jako zdroj napájení.
3.1.4 Zónová úroveň Zónová úroveň je v hierarchii úrovní postavena nejníţe. Jejím úkolem je měřit aktuální skutečnou teplotu a zjištěné hodnoty odesílat do transakční úrovně. Od té naopak přijímá poţadavky na spínání proudu do termopohonů pro dosaţení skutečné regulace teploty. Úroveň se také stará o zjišťování problémů a chyb na termopohonech. Komponentou pokrývající zónovou úroveň je jednotka PRE-BI-9K-xy. Je umístěna v kaţdé řízené místnosti a stará se o měření teploty a ovládání termopohonů. Mezi komponenty zónové úrovně se řadí i digitální snímače teploty a termopohony, které se připojují k zónovým jednotkám.
3.2 Regulace teploty Nejčastějším způsobem, jakým DIRC teplot reguluje, je změna míry škrcení ventilu otopného tělesa. Obvykle jím bývá radiátor nebo systém podlahového vytápění. Prvek, který zásah na ventilu provádí, se v této souvislosti nazývá aktuátor nebo hlavice. Ve většině případů se jedná o termopohon umístěný na ventilové armatuře radiátoru nebo rozdělovač podlahového vytápění. Působení na ventil, tedy jeho uzavření nebo otevření, má vliv na mnoţství teplé vody přiváděné do topného členu. Teplá voda způsobí zahřátí radiátoru nebo podlahového systému, který následně začne ohřívat vzduch, a tak dochází ke zvyšo13
vání teploty v místnosti. Pro regulaci teploty vody, která je do topných členů přiváděna, v dnešní době nejčastěji slouţí ekvitermní regulátor.
3.3 Spolupráce systému DIRC a ekvitermního regulátoru Systém DIRC ţádným způsobem nemusí přímo komunikovat s ekvitermním regulátorem. Oba prvky vytápěcího systému mohou spolupracovat pouze prostřednictvím topné vody. Je-li topná voda spotřebovávána k vytápění, její teplota klesá a ekvitermní regulátor musí dát povel zdroji tepla k zahájení jejího ohřevu. Pokud je skutečná teplota v místnostech stejná nebo vyšší neţ poţadavek, systém DIRC uzavírá ventily topných členů, topná voda není spotřebovávána a její teplota tak stoupá. Regulátor o tom informuje zdroj tepla, jenţ ohřev topné vody zastaví. Z tohoto principu vyplývá, ţe topnou vodou není zbytečně plýtváno, a také ţe zdroj tepla pracuje, jen kdyţ je to skutečně vyţadováno. Dosahuje se úspory energie vynaloţené na dodávku tepla do objektu. Dojde-li k chybě na ekvitermním regulátoru nebo zdroji tepla a vznikne tak nedostatek ohřáté topné vody k vytápění místností, objeví se veliké odchylky mezi skutečnou a poţadovanou teplotou. Systém DIRC totiţ nemá moţnost se o vzniklé poruše dovědět. Neustále se snaţí přivádět ohřátou topnou vodu, ta však není k dispozici. Umoţní-li to technické podmínky, je výhodné systém DIRC a ekvitermní regulátor komunikačně propojit.
3.4 Předpoklady pro správnou funkčnost systému DIRC Pro bezchybnou práci systému DIRC musí uţivatel manuálně zadat:
čas reálného vyuţití řízených místností lidmi,
poţadovanou teplotu pro zajištění tepelné pohody v průběhu této doby,
alespoň základní tepelnou charakteristiku těchto prostor.
Skutečná aktuální teplota, která je posledním důleţitým ukazatelem při rozhodování systému, je snímána automaticky v krátkých pravidelných intervalech. Jak jiţ bylo zmíněno, systém DIRC přímo neovlivňuje ohřev topné vody. Proto se její dostatečné mnoţství řadí mezi podstatné předpoklady správné funkčnosti systému.
14
3.5 Řízení zóny systémem DIRC V této podkapitole popisuji procesy spojené s řízením individuálních zón systémem DIRC. Uvádím zde všechny informace potřebné pro úspěšnou analýzu algoritmu řídícího vytápění v místnostech.
Obr. 7. Blokové schéma systému DIRC
3.5.1 Důležité pojmy Pojem
Vysvětlení
Doména
Celkový řízený objekt, například škola nebo nemocnice. Můţe se jednat o soustavu více budov. V kaţdé doméně je instalována jedna správní jednotka. Doména se skládá z jednotlivých zón.
Zóna
Individuální řízená místnost. Zóna je identifikována budovou, ve které se nachází a svým označením. Součástí identifikace můţe být i patro budovy, kde je zóna umístěna.
Aktuátor
Prvek měnící míru škrcení ventilu topného členu. Jinak také hlavice nebo termopohon. Můţe být v aktivním stavu (teče jím proud, ventily se uzavírají, radiátor netopí a teplota se sniţuje) nebo v neaktivním stavu (proud jím neteče, ventily se otevírají, radiátor topí a teplota se zvyšuje).
3.5.2 Schéma řízení systémem DIRC Na začátek popíšu zjednodušené schéma řízení zóny systémem DIRC. Uţivatelé nastavují atributy, podle nichţ se řídicí algoritmus orientuje. Atributy jsou uloţeny v konfigurač15
ních tabulkách databáze systému. Historie všech uskutečněných zásahů je ukládána do ţurnálové tabulky. Řídicí algoritmus v pravidelných několikasekundových intervalech snímá skutečnou teplotu v zóně a porovnává ji s aktuálním poţadavkem vypočítaným na základě konfiguračních atributů. Podle výsledku porovnání dává příkazy k otevření nebo uzavření aktuátorů. Vţdy jednou za hodinu systém do monitorovací tabulky uloţí aktuální stav v zóně. Ten obsahuje informace o skutečné a poţadované teplotě a stav kaţdého aktuátoru, který je zde umístěn. (Obr. 7.)
3.5.3 Požadovaný stav v zóně Systém DIRC umoţňuje pomocí uţivatelského rozhraní v podobě webové aplikace nastavit průběh vytápění pro kaţdou zónu samostatně. Základem tohoto nastavení je určení poţadovaného stavu, podle kterého se orientuje řídicí úroveň při výpočtu poţadované teploty. Rozlišuje se standardní období, svátkový stav, aperiodické poţadavky, výjimečné období a letní reţim. Uţivatel má moţnost přiřadit ke kaţdému období různý poţadovaný stav. Systém DIRC se sám rozhodne, jaké období je v daný okamţik platné a pouţije jeho stav. Období
Popis
Standardní období
Vyskytuje se nejčastěji. Platí vţdy, kdyţ neprobíhá jiné období.
Svátkový stav
Platí jednak během předem definovaných státních svátků, ale i během uţivatelsky zadaných svátků. Svátky jsou určeny dnem v roce, ve kterém nabírají platnosti. Zadávají se pro celou doménu společně. Není moţné přiřadit svátek individuální zóně.
Aperiodické požadavky
Mají vyšší prioritu, neţ standardní období a svátkový stav. Určují se počátečním a konečným datem s přesností na minuty. Vytvářejí se buď pro individuální zóny nebo pro skupiny zón. Uplatnění nalézají především v hotelových pokojích, jejichţ vyuţití není obvykle předem známé. Aperiodické poţadavky jsou v podstatě zobecněním výjimečného období.
Výjimečné období
Upřednostňuje se před aperiodickými poţadavky. Vyuţívá se především pro vytyčení prázdnin a dovolených, kdy místnost není lidmi obývána a není nutné ji vytápět. Ve starších verzích systému DIRC bylo definováno s přesností na dny. Nové verze umoţňují zadat rozmezí s přesností na minuty.
Letní režim
Aktivuje se mimo topnou sezónu pro celou doménu. Kaţdá zóna na letní reţim reaguje individuálně jedním ze dvou způsobů. Buď přejde do neaktivního stavu (V zóně nedochází k regulaci teploty.) nebo letní reţim ignoruje a dále reguluje teplotu. Má nejvyšší prioritu.
16
Existuje devět stavů, které lze přiřadit kaţdému z prvních čtyř uvedených období. Jedinou výjimkou je standardní stav, jejţ není moţné nastavit u standardního období. Nepřiřadil-li uţivatel k období ţádný stav, automaticky se pouţije stav „neaktivní“. Stav
Popis
Neaktivní
Aktuátory v dané zóně jsou vţdy ve stavu neaktivní a teplota v zóně by se měla zvyšovat. Přesnou aktuální poţadovanou teplotu není potřeba vypočítávat a ani není moţné ji určit.
Aktivní
Aktuátory v dané zóně jsou vţdy ve stavu aktivní a teplota v zóně by se měla sniţovat. Přesnou aktuální poţadovanou teplotu není potřeba vypočítávat a ani není moţné ji určit.
Zvyšovat teplotu
Stav, při kterém by teplota v zóně měla být neustále zvyšována. Aktuátory jsou otevřené, neboli neaktivní. Přesnou aktuální poţadovanou teplotu není potřeba vypočítávat a ani není moţné ji určit. Tento stav je v podstatě totoţný s neaktivním stavem.
Snižovat teplotu
Stav, při kterém by teplota v zóně měla být neustále sniţována. Aktuátory jsou zavřené, neboli aktivní. Přesnou aktuální poţadovanou teplotu není potřeba vypočítávat a ani není moţné ji určit. Tento stav je v podstatě totoţný s aktivním stavem.
V provozu
V místnosti by měla být stále udrţována jedna konstantní teplota. Její hodnota je určena poţadovanou provozní teplotou.
Mimo provoz
V místnosti by měla být stále udrţována jedna konstantní teplota. Její hodnota je určena poţadovanou mimo provozní teplotou.
Dle programu
Poţadovaná teplota se můţe s časem měnit. Její hodnota je vypočítána podle zadaného vyuţití místnosti lidmi. Jedná se o nejčastější stav, proto je detailněji popsán dále.
Útlum
V místnosti by měla být stále udrţována jedna konstantní teplota. Její hodnota je určena poţadovanou útlumovou teplotou.
Standardní
Pouţije se stav zadaný u standardního období. Nelze jej přiřadit standardnímu období.
3.5.4 Požadovaný stav „dle programu“ Poţadovaný stav „dle programu“ je nejčastěji vyuţívaným stavem zón. Je zaloţen na definování skutečného vyuţití místnosti lidmi v čase. Umoţňuje nastavit aţ osm různých teplotních poţadavků během jednoho dne. První poţadavek začíná v 0 hodin 0 minut, ostatní jsou určeny počátečním časem. Kaţdý poţadavek má přiřazenu teplotu, které by v předepsaný čas mělo být dosaţeno. Teplota můţe být zadána buď přímo číselně nebo lépe odkazem na jeden z teplotních reţimů. 17
Stav „dle programu“ lze dále rozdělit podle typů. Typ „denní“ vyţaduje zadání poţadavků pro jediný den, které se následně kaţdý den opakuje. Při zvolení „týdenního“ typu je nutné zadat poţadavky zvlášť pro kaţdý den v týdnu. „čtrnáctidenní“ typ se vyuţívá, je-li obsazení místnosti odlišné v sudé a liché kalendářní týdny. Poslední typ se nazývá „pracovní“ a rozlišuje jedno zadání poţadavků pro všechny pracovní dny a jedno pro dny víkendové. Není-li program zadán, pak systém po celý den udrţuje mimo provozní teplotu.
3.5.5 Teplotní režimy vytápění V systému DIRC jsou rozlišovány tři rozdílné teplotní reţimy vytápění, které by měli stačit k pokrytí provozního vyuţití všech místností. Kaţdému lze přiřadit poţadovanou teplotu. Prvním je „provozní“ reţim nastavovaný pro časové rozpětí, ve kterém je místnost vyuţívána lidmi. Další reţim se označuje jako „mimo provozní“. Odpovídá době, kdy místnost není vyuţívána (například v noci). Jemu přiřazená teplota bývá logicky niţší neţ teplota přiřazená provoznímu reţimu. Poslední, „útlumový“ reţim, zpravidla mívá nastavenu ještě niţší teplotu neţ mimo provozní reţim. Vyuţívá se v případech, kdy není potřeba místnost vytápět delší dobu. Ve školách proto uplatnění nalezne nejčastěji o víkendech nebo o prázdninách.
3.5.6 Určení požadované teploty Určení aktuálně poţadované teploty je proces, který má přesně definovaná pravidla. Systém tak bezpečně pozná jakou hodnotu pouţít. 1. Má-li se systém řídit stavem „dle programu“ a je-li u právě platného poţadavku zadána teplota číselně, vyuţije se tato hodnota. 2. Je-li teplota u poţadavku zadána odkazem na teplotní reţim nebo platí-li jeden ze stavů „v provozu“, „mimo provoz“ a „útlum“, systém vyhledá hodnotu teploty tohoto reţimu určenou přímo pro danou zónu. 3. Není-li tato hodnota zadána, vyuţije se teplota definovaná provozním určením. Provozní určení zóny udává způsob jejího vyuţití pomocí předepsaných výchozích teplot. Rozlišují se provozní určení vytvořené uţivatelem a provozní určení předepsané vyhláškami č. 410/2005 Sb. [21] a č. 6/2003 Sb. [22]. 4. Pokud není vyplněno ani provozní určení, řídí se systém pevně stanovenými výchozími hodnotami. Pro provozní teplotu tato hodnota činí 20 °C. Mimo provozní a útlumová teplota je pak o 3 °C niţší, neţ by byla právě poţadovaná provozní teplota.
18
3.5.7 Programová reference a tepelná a programová reference Ve většině případů odpovídá jedna reálná místnost právě jedné zóně v systému DIRC. Velké místnosti však mohou být rozděleny do více zón. Jedna z nich se poté volí jako referenční a ostatní zóny se na ní odkazují. Tepelná a programová reference znamená, ţe zóna není vybavena vlastním snímačem teploty. Skutečnou naměřenou teplotu a většinu nastavení přebírá od zóny referenční. Programová reference se vyuţívá u zón opatřených vlastním snímačem teploty, které spadají pod větší místnosti. Přebírají nastavení časového programu od zóny, na níţ závisejí.
3.5.8 Skupiny Pro hromadnou změnu atributů zón slouţí skupiny. Kaţdý uţivatel pracuje se svými vlastními skupinami. Do skupin je moţné přidávat budovy, podlaţí i jednotlivé zóny. Je-li přidána budova, pak jsou automaticky zahrnuty všechny zóny patřící do této budovy. Na stejném principu je zaloţeno přidávání podlaţí. Skupina můţe obsahovat libovolný počet členů. Provedení změny v nastavení na skupině má za následek změnu nastavení kaţdé zóny, která je jejím členem.
3.5.9 Teplotní náběhová rampa, doba poklesu a hystereze Náběhová rampa představuje postupné poţadované lineární zvyšování teploty vzduchu v místnosti v čase. Je vypočítána pomocí atributu zóny „strmost náběhu“ tak, aby bylo poţadované teploty dosaţeno přesně v daný čas bez nutnosti brát v úvahu dostatečné předstihy či přesahy. Strmost náběhu udává předpokládanou schopnost topného systému zóny zvyšovat teplotu při vytápění. Zadává se ve stupních Celsia za hodinu. Čím je strmost niţší, tím musí vytápění začít dříve. Systém DIRC je schopný začít vytápět aţ dvanáct hodin před okamţikem, kdy má být dosaţeno poţadované teploty. Výpočet počátečního bodu náběhové rampy probíhá s ohledem na moţný přechod do jiného programu, stavu nebo období. Přesné dosaţení vyšší teploty má přednost před poklesem na niţší teplotu. Krátkodobého útlumu teploty zaneseného v programu tak nemusí být úplně dosaţeno. (Obr. 8.) Doba poklesu udává předpokládanou schopnost místnosti udrţet si aktuální teplotu i nějaký čas po uzavření radiátorů. Zadává se v minutách a říká, jakou dobu před přechodem na niţší teplotu se má systém přestat řídit aktuální poţadovanou teplotou. Místo ní se začne orientovat podle následující niţší teploty. Při výpočtu křivky průběhu poţadované teploty se nejprve aplikují poklesy teploty a teprve poté se vypočítá náběhová rampa. 19
Hystereze udává ve stupních Celsia absolutní minimální hodnotu rozdílu mezi poţadovanou a skutečnou teplotou v zóně. Musí jí být dosaţeno, aby došlo k regulačnímu zásahu na termopohonu – jeho otevření nebo uzavření. Denní program Program uložený v systému
Vypočítaný průběh požadované teploty
23
Teplota [°C]
22 21 20 19 18 17 0:00
2:00
4:00
6:00
8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 0:00 Čas [hod]
Obr. 8. Porovnání průběhu požadované teploty zadaného uživatelem do programu a vypočítaného systémem DIRC s ohledem na strmost náběhu (1°C za hodinu) a doby poklesu (60 minut)
3.6 Nedostatky systému DIRC Vizualizační software systému DIRC poskytuje přehledné rozhraní pro nastavení individuálních zón, není však jiţ příliš vhodný pro analýzu naměřených aktuálních a historických dat. Program nenabízí téměř ţádné moţnosti zobrazení grafů. Jediný nástroj umoţňuje pouze generování historických grafů s křivkami poţadované a skutečné teploty (Obr. 9.). Mohou být zobrazeny pouze pro jedinou zónu a jsou rozděleny po jednotlivých dnech. Kaţdá křivka jednoho grafu vzniká propojením 24 záznamů, které jsou během dne v zóně v pravidelných hodinových intervalech pořízeny. Křivka poţadované teploty je značně zkreslená, protoţe neukazuje přesné časy změn poţadovaných teplot. (Záznamy jsou pořizovány bez ohledu na přechod na jinou poţadovanou teplotu.) Zaměstnanci společnosti Enesa tudíţ nemohou vykonávat dostatečnou analýzu průběhů vytápění, na jejímţ základě by byli schopni optimalizovat nastavení zón. Vyţadují proto vytvoření nového nástroje, který by jim umoţnil hromadně zkoumat všechny zóny vybrané domény.
20
Společnost Enesa není vlastníkem vizualizačního softwaru systému DIRC a firma DOT CONTROLS odmítá poskytnutí jeho zdrojového kódu. Z tohoto důvodu je nutné vytvořit zcela novou aplikaci. Měla by přistupovat k datům uloţeným v databázích domén a provádět s nimi výpočty poţadované společností Enesa.
Obr. 9. Zobrazení historického průběhu požadované a skutečné teploty v uživatelském prostředí systému DIRC
3.7 Analýza systému DIRC Společnost DOT CONTROLS poskytla společnosti Enesa pouze přístup k databázím domén, které spadají pod její správu. Algoritmus zpětně simulující chod řídicího algoritmu systému DIRC a zjišťující průběh poţadované teploty tak můţe vycházet pouze z těchto zpřístupněných dat. Proto se v následující podkapitole budu věnovat především popisu databázových tabulek, jejich vzájemných vztahů a důsledků, které z databáze vyplývají pro simulační algoritmus. Manuál systému DIRC je určen především pro uţivatele, proto o vnitřní softwarové architektuře nic neříká. V podkapitole tak vycházím z konzultací s programátory systému a především z vlastních poznatků.
3.7.1 Databáze Společnost DOT CONTROLS shromaţďuje a zpřístupňuje data ze všech domén v jedné centrální MySQL databázi. Tabulky jsou ve formátu MyISAM [16], který nepodporuje cizí klíče. Ze všech tabulek, které kaţdá doména obsahuje, je deset z nich významných pro zpětnou rekonstrukci algoritmu. Lze je rozdělit do dvou hlavních skupin podle způsobu jakým se v nich ukládají data na tabulky konfigurační a záznamové.
21
3.7.1.1 Konfigurační tabulky Konfigurační tabulky zobrazují vţdy aktuální nastavení objektů. Objektem je v této souvislosti myšlena například doména, budova, zóna, aperiodický poţadavek, svátek, provozní určení a podobně. Data uvnitř tabulek se neustále mění – přibývají a ubývají řádky a dochází i ke změnám v obsahu sloupců. Jejich diagram ukazuje Obr. 10. Jak jsem jiţ zmínil, pouţití enginu MyISAM neumoţňuje existenci cizích klíčů, coţ povaţuji za nedostatek. Ţádná z tabulek neobsahuje jednoduchý automaticky generovaný číselný primární klíč, který by usnadnil propojení tabulek. Primární klíče jsou často sloţené a v podobě řetězců. Uţivatelské prostředí systému DIRC navíc umoţňuje jejich změnu, k níţ poměrně často dochází. Přepsání primárního klíče má v mnoha případech za následek zásah do ostatních tabulek. Tento fakt mi při sestavování rekonstrukčního algoritmu mnohokrát ztíţil práci.
Obr. 10. Diagram konfiguračních tabulek systému DIRC (místo „{doména}“ je v názvu tabulky uveden jednoznačný identifikátor domény)
V následujícím přehledu uvádím význam konfiguračních tabulek a problémy, které přinášejí. Jednotlivé atributy popisuji v Příloha A. 22
Tabulka
Popis
Domény mlevel
Shrnuje vlastnosti společné pro celou doménu, jako je její název nebo příznak informující o aktivním letním reţimu. Neobsahuje ţádný primární klíč ani jednoznačné sloupce. Data jsou po řádcích uloţena způsobem: název atributu – hodnota.
Budov building
Obsahuje seznam budov v doméně. Primárním klíčem je řetězec představující název budovy. Přejmenování budovy ovlivní také tabulku podlaţí, zón, členů skupin, aperiodických poţadavků a monitorovacích záznamů.
Podlaží floor
Obsahuje seznam podlaţí v budovách. Dvojice řetězců název budovy a název podlaţí tvoří primární klíč. Přejmenování podlaţí ovlivní tabulku zón a členů skupin.
Zón zone
Obsahuje seznam všech zón domény a jejich kompletní konfiguraci zahrnující poţadované stavy rozdílných období, definici vyuţití zóny v průběhu dní, její základní tepelnou charakteristiku a existuje-li, pak také název referenční zóny a typ reference. Sloţený primární klíč sestává z dvojice řetězců název zóny a název budovy. Zónu lze přejmenovat nebo přesunout do jiné budovy či podlaţí. Obě akce mají vliv na tabulku členů skupin, aperiodických poţadavků i monitorovacích záznamů. Zastává-li přejmenovaná zóna funkci referenční zóny, musí být přepsán také atribut „referenční zóna“ u příslušných zón.
Provozních určení assigning
Uchovává seznam provozních určení a jím přidělených provozních, mimo provozních a útlumových teplot. Primární klíč tvoří typ provozního určení a jeho název. Typ říká, zda se jedná o provozní určení legislativní, dle normy ČSN nebo vytvořené uţivatelem.
Členů skupin group_member
Obsahuje zařazení zón do uţivatelských skupin. Primární klíč se skládá ze všech pěti sloupců tabulky. Zahrnuje název skupiny, jejího vlastníka, název budovy, název podlaţí a název zóny. Zóny lze zařadit třemi způsoby:
Zapsáním budovy – všechny zóny spadající do dané budovy jsou členy skupiny.
Zapsáním budovy a podlaţí – všechny zóny patřící do dané budovy a podlaţí se stávají členy skupiny.
Zapsáním budovy a zóny – daná zóna je členem skupiny. Skupina můţe obsahovat libovolné mnoţství členů. Svátků feast
Obsahuje seznam státních i uţivatelem zadaných svátků. Primární klíč tvoří dvojice rok a datum svátku ve formátu UNIX timestamp – udává počet sekund uplynulých od 1.1.1970. Po uplynutí platnosti svátku je tento automaticky z tabulky odstraněn.
Aperiodických požadavků
Její primární klíč tvoří počáteční datum ve formátu UNIX timestamp, název objektu a vlastník, který poţadavek vytvořil. Objektem můţe být buď název
aperiodic
skupiny nebo konkrétní zóna určená dvojicí název budovy a název zóny. Dal-
23
Tabulka
Popis šími atributy aperiodického poţadavku jsou konečné datum ve formátu UNIX timestamp a poţadovaný stav v zóně po dobu jeho platnosti. Proběhnuté poţadavky jsou z tabulky automaticky mazány.
3.7.1.2 Záznamové tabulky Do záznamových tabulek se data pouze průběţně doplňují. Stávající řádky se nemění. Existuje tabulka monitorovacích a ţurnálových záznamů. Jejich diagram ukazuje Obr. 11.
Obr. 11. Diagram záznamových tabulek systému DIRC (místo „{doména}“ je v názvu tabulky uveden jednoznačný identifikátor domény)
Tabulka monitorovacích záznamů – mon Shromaţďují se v ní monitorovací záznamy pro všechny zóny v doméně. Pořizují se pravidelně kaţdou hodinu. Primární klíč je tvořen trojicí čas pořízení ve formátu UNIX timestamp, název budovy a název zóny. Po přejmenování budovy nebo zóny nebo po přesunu zóny do jiné budovy, je nutné změnit odpovídající sloupce názvu zóny a budovy u příslušných záznamů. V databázi řídicí jednotky domény by mělo dojít k přepsání všech ovlivněných záznamů. Avšak při velkém mnoţství takovýchto záznamů můţe nastat situace, kdy jednotka nemá dostatek paměti a některé záznamy se nepřejmenují. Do centrální databáze společnost DOT CONTROLS doplňuje pouze nové záznamy. Existující řádky zůstávají v nezměněné podobě, tedy se starým názvem. Mezi další atributy monitorovacích záznamů patří aktuální poţadovaná a skutečná teplota v zóně, čas stáří informace v sekundách – je-li větší, neţ 120 sekund, povaţuje se zóna za nedostupnou a celý záznam je nutné ignorovat. Důleţité jsou také bitové příznaky zóny a jednotlivých aktuátorů, které se mohou v místnosti vyskytovat aţ čtyři. Informují napří-
24
klad o poruchách a aktivitách hlavic. Jejich celkový přehled s vysvětlivkami je uveden v Příloha B. Jak jsem jiţ dříve zmínil v podkapitole 3.5.7, zóně je moţné nastavit tepelnou a programovou referenci. I v takovém případě se monitorovací záznamy pro danou zónu ukládají. Atribut aktuální skutečné teploty má však nepravděpodobnou hodnotu a příznak zóny úmyslně hlásí chybu. Naměřené veličiny je proto nutné vyhledat pro zónu, která je nastavena jako referenční. Komplikovaná situace nastává, je-li potřeba získat historické monitorovací záznamy zóny, které byla v minulosti nastavena jiná referenční zóna a zúčastněné zóny byly navíc přejmenovány. Za nevýhodou povaţuji, ţe jsou záznamy pořizovány pouze v pravidelných intervalech bez ohledu na změnu aktuální poţadované teploty. Při jejich propojování tak dochází ke zkreslení v úsecích teplotní náběhové rampy a skokového poklesu na niţší poţadovanou teplotu. V tabulce také postrádám sloupec s informací o poţadovaném stavu, který platil v době vytvoření záznamu. Odstraněním těchto dvou nedostatků by teoreticky odpadla nutnost vytvářet celý simulační algoritmus. Tabulka žurnálových záznamů – journal Ţurnál uchovává informace o všech uţivatelských zásazích do systému a o některých akcích vykonávaných automaticky systémem DIRC. Právě tato tabulka umoţňuje postupným čtením a skládáním záznamů zpětně sestavit podobu konfigurace poţadované zóny v libovolném historickém čase. Primární klíč tvoří datum a čas provedení zásahu zapsaný jako počet milisekund uplynulých od 1.1.1970. Záznam také sděluje o jaký typ zásahu se jednalo, na jakém objektu k němu došlo, který uţivatel jej uskutečnil a jaká byla hodnota změněného atributu před ním. Nové verze systému DIRC ukládají také nové hodnoty změněného atributu. Společnost DOT CONTROLS však prozatím neplánuje obnovení starých verzí, a proto nemohu tuto informaci ve své práci vyuţít. Mezi uţivatelské zásahy se řadí především změny atributů objektů a mazání, přidávání či přejmenování objektů. Akce jako přihlášení uţivatele do systému jsou pro mé potřeby nepodstatné. Automatické zásahy systému se oproti uţivatelským vyskytují o mnoho méně. Systém sám maţe svátky a aperiodické poţadavky ihned po jejich proběhnutí. V případě aperiodických poţadavků do ţurnálové tabulky ukládá všechny údaje potřebné pro jejich zpětné sestavení. Rozmezí výjimečného období, které se ukládá v podobě dvou atributů v konfiguraci zóny, je měsíc po ukončení období také automaticky vynulováno, aby nemohlo dojít k jeho opakování i příští rok. Vynulování však není nikde zaznamenáno, coţ 25
nese negativní následky. Tento jediný nedostatek zabraňuje vytvoření spolehlivého algoritmu, který by rekonstruoval řídicí algoritmus od libovolného historického data. Dojde-li k systémovému vynulování výjimečného období a následně k vytvoření nového, nenese ţurnálový záznam informaci o rozsahu předchozího období – toho, které jiţ proběhlo a bylo smazáno. Spolehlivá data o přesném průběhu poţadované teploty tak mohou být k dispozici aţ od okamţiku nasazení simulačního algoritmu a maximálně jeden měsíc nazpět.
26
4 Sestavení simulačního algoritmu V kapitole popisuji technologii, kterou jsem vybral pro vytvoření simulačního algoritmu a proces získávání dat z domén. Část textu je věnována databázi, která musela pro jeho účely vzniknout. Poslední úsek tvoří popis postupu při návrhu algoritmu. Jedná se o stěţejní část mé práce. Výstupem algoritmu je průběh poţadované teploty včetně jeho rozdělení na reţimy vytápění, jeţ jsou důleţitým ukazatelem při následné analýze. Jeho běh je nezávislý na webové aplikaci pro rozbor dat.
4.1 Výběr technologie Prvním krokem byl výběr programovacího jazyka pro vytvoření poţadovaného algoritmu. Z jazyků, které jsem znal, a které připadaly v úvahu mohu jmenovat Javu a PHP. Skriptovací jazyk PHP3 [17] jsem rychle zamítl. Bylo zřejmé, ţe simulační algoritmus bude velice náročný na výpočet a k tomu jazyk určený především pro tvorbu dynamických internetových stránek není příliš vhodný. Ladění kódu v PHP je navíc velice obtíţné. Společnost Enesa zakoupila server Microsoft Hyper-V Server 2008 určený pro virtualizaci strojů. Pomocí něj byly vytvořeny dva virtuální stroje. Jeden slouţí jako webový server s operačním systémem Microsoft Windows Web Server 2008 s nainstalovaným prostředím Internet Infomation Services 7.5. Na druhý byla umístěna databáze. Běţí zde Microsoft Windows Server 2008 Enterprise s databázovým serverem SQL Server 2008 Standard Edition. Celkové schéma ukazuje diagram nasazení na Obr. 15. Mezi kandidáty proto vstoupil také .NET framework verze 4 [19]. Nemyslím si, ţe mám dostatečné znalosti a zkušenosti, abych mohl mezi sebou porovnávat technologie .NET a Java – konkrétně Java EE4 [18] a říct, která z nich je povaţována za lepší, či vhodnější. Konečné rozhodnutí pro prostředí .NET však povaţuji za daných okolností za správné a po dokončení práce jej nelituji, i kdyţ jsem se s ním do jejího začátku nikdy nesetkal. Uvedu důvody, které vedly k výběru této technologie:
3 4
Pouţití jazyka Java by navíc vyţadovalo zakoupení aplikačního serveru pro komerční uţití, jehoţ licence jsou velice nákladné.
PHP – PHP: Hypertext Preprocessor Java EE – Java Enterprise Edition
27
Byla zaručena dobrá kompatibilita .NET frameworku s Windows Serverem a SQL Serverem.
Společnost Enesa zakoupila vývojové prostředí Microsoft Visual Studio 2010, proto pouţití placeného IDE nebylo překáţkou.
V neposlední řadě jsem také získal moţnost proniknout do nové, a v dnešní době stále populárnější, technologie.
Prostředí .NET nabízí několik programovacích jazyků, které lze k vývoji vyuţít. Rozhodl jsem se pro jazyk C#, který vznikl speciálně pro tuto platformu a je z nich povaţován za nejvyspělejší. Základní syntaxí se velice podobá Javě, ale zahrnuje v sobě rysy i z mnoha dalších jazyků, přičemţ si uchovává jednoduchost a čistotu [3].
4.2 Získávání dat V této podkapitole popisuji proces, jakým se získávají nezpracovaná data z jednotlivých domén a následně přenášejí do datového úloţiště společnosti Enesa. Přenos probíhá ve dvou krocích. (Obr. 12.) 1) Přenos: doména – databáze „BMS“ společnosti DOT CONTROLS Data ze všech domén jsou shromaţďována v MySQL databázi společnosti DOT CONTROLS s názvem „BMS“. Nejdéle jednou za 48 hodin dochází ke zkontaktování domény s databází a transferu dat. Přenos tabulek probíhá jednou ze tří metod. Záznamové tabulky – monitorovací a ţurnálová – se nahrávají inkrementální metodou. To znamená, ţe jsou přenesena pouze nová data, která zatím nejsou v databázi uloţena. Na ostatní tabulky je aplikována metoda absolutní s archivací změn nebo bez ní. Databázová tabulka je před zahájením přenosu vyprázdněna a poté zcela nově naplněna. Pro kaţdou doménu existují samostatné tabulky, jejichţ názvy se řídí následující jmennou konvencí: zzeda_{zkrácený název domény}_sd_{druh tabulky} Zkratka EDA vznikla z anglických slov Early Data Approach. Písmena SD označují název systému Smart DIRC. 2) Přenos: databáze „BMS“ – databáze společnosti Enesa Poţadavkem společnosti Enesa bylo, aby se data shromaţďovala v nezměněné podobě také na jejím datovém úloţišti. Proto byla vytvořena přesná kopie databáze „BMS“ pouze s jediným rozdílem. Nejedná se o databázi MySQL ale Microsoft SQL. V pravidelných hodinových intervalech je kontrolováno, zda došlo k aktualizaci tabulek některé z domén uloţených v databázi „BMS“. Případně jsou obnovené tabulky přeneseny na server společnosti Enesa za pouţití stejných přenosových metod, kterými se data získávají z domén. 28
Tabulky na serveru společnosti Enesa si zachovávají stejné názvy, které nesou v databázi „BMS“. Původně bylo zamýšleno, aby nedocházelo k jinému vnějšímu zásahu do této databáze. Vytvořil jsem další databázi pojmenovanou „DIRCAnalysis“, do níţ se ukládají data získaná aplikací simulačního algoritmu. Její struktura je popsána v podkapitole 4.3.1. Nástroj k analyzování musí přistupovat do obou databází, aby nedocházelo ke zbytečné duplikaci nezpracovaných dat. Naráţí se zde však na problém s neodpovídajícími monitorovacími záznamy po přejmenování zóny nebo budovy, který jsem popisoval v podkapitole 3.7.1.2. Proto jsem se rozhodl přepisovat potřebné primární klíče tabulek monitorovacích záznamů.
Obr. 12. Schéma přenosu dat mezi databázemi systému DIRC, společnosti Enesa a společnosti DOT CONTROLS
4.3 Zpracování dat Před začátkem psaní samotného algoritmu jsem se snaţil provést co nejdůkladnější analýzu systému DIRC, abych odhalil všechny potíţe a neobvyklé situace, které mohou nastat. Ale i během vývoje a následného testování jsem několikrát narazil na nové problémy, o kterých jsem do té doby nevěděl. Aţ dlouhodobější provoz nástroje pro analýzu dat dokáţe odhalit všechny chyby a algoritmus bude moţné vyladit do spolehlivě fungující podoby. Během práce také musela být párkrát pozměněna struktura databáze. V následujících odstavcích proto popisuji konečnou podobu tabulek databáze „DIRCAnalysis“ a simulačního algoritmu.
29
4.3.1 Struktura databázových tabulek Největším nedostatkem návrhu systému DIRC je dle mého názoru absence jednoduchých numerických primárních klíčů, čemuţ jsem se ve své aplikaci chtěl vyvarovat. Z hlediska simulačního algoritmu byl návrh databáze přímočarý, proto jsem vypustil návrh doménového modelu, kterým by se mělo při modelování sloţitých systémů začínat. Databázový diagram ukazuje Obr. 13. ExceptionLogger Column Name
UpdateLogger Data Type
Column Name
Data Type
exceptionLogId
int
updateLogId
bigint
exception
nvarchar(MAX)
updateDate
datetime
dateGmt
datetime
lastTableCreateDate
datetime
Domains
Buildings
Column Name
Data Type
domainId
int
domainNameShort
varchar(10)
domainNameLong
varchar(100)
lastUpdate
datetime
monTableRows
int
enabled
bit
Column Name
FK_Buildings_Domains
ZoneData
Floors Data Type
buildingId
int
domainId
int
buildingName
varchar(10)
Column Name FK_Floors_Buildings
Data Type
floorId
int
buildingId
int
floorName
varchar(10)
FK_Zones_Floors
Zones
Column Name
Data Type
Column Name
zoneDataId
bigint
zoneId
int
sourceDate
datetime
floorId
int
zoneId
int
zoneName
varchar(10)
tempWanted
smallint
lastAnalysis
datetime
tempActual
smallint
state
smallint
Column Name
Data Type
length
float
refHistoryId
int
steepness
smallint
zoneId
int
refZoneId
int
fromGmt
datetime
FK_ZoneData_Zones
Data Type
FK_RefZonesHistory_Zones_RefZone FK_RefZonesHistory_Zones_Zone
RefZonesHistory
Obr. 13. Diagram databáze „DIRCAnalysis“
Pro potřeby nástroje pro analýzu dat bylo nutné vytvořit hierarchické uspořádání objektů ve formě: doména – budova – podlaţí – zóna, které modeluje reálnou situaci v řízených komplexech. V systému DIRC není zóna podlaţím jednoznačně určena, ale pro přehlednost jsem se jej rozhodl do hierarchické struktury zařadit. Kaţdý objekt je v rámci své tabulky („Domains“, „Buildings“, „Floors“, „Zones“) rozlišen automaticky generovaným identifikátorem. Obsahuje také název, kterým je určen v systému DIRC. Doména zahrnuje celé jméno i jeho zkrácenou verzi, jeţ se dosazuje do názvu tabulek systému. Objekty doména a zóna jsou doplněny o atributy usnadňující běh simulačního algoritmu. Pomáhají určit časové období, na které se má algoritmus aplikovat. Tabulky jsou mezi sebou propojeny cizími klíči. 30
Návrhu struktury tabulky pro ukládání dat („ZoneData“) získaných aplikací simulačního algoritmu předcházelo důkladné zkoumání výpočtů pro jejich analýzu poţadovaných společností Enesa. Jejich detailnější popis uvádím v podkapitole 5.1.2.1. Výstupem simulačního algoritmu je průběh poţadované teploty v zóně, který představuje graf závislosti teploty na čase včetně informace, o jaký stav (provozní, mimo provozní, apod.) se v daném úseku jednalo. Pro přesnou definici úseku je nutné znát jeho časové rozmezí, počáteční a konečnou poţadovanou teplotu a poţadovaný stav. Údaje o počáteční a konečné teplotě jsou dostačující, protoţe systém DIRC umoţňuje pouze lineární nárůst teploty, viz kapitola 3.5.9. Po rozboru algoritmů a sestavení obecných vzorců, které se v nich pouţívají, jsem vybral nejčastěji se opakující veličiny. Patří mezi ně počáteční čas a datum úseku, počáteční poţadovaná teplota, počáteční skutečná naměřená teplota, poţadovaný stav, délka úseku v sekundách a strmost náběhu ve stupních Celsia za hodinu. (Obr. 14.) Z uvedených hodnot lze jednoduchým výpočtem získat i konečný čas a datum úseku a konečnou poţadovanou teplotu. Počáteční skutečná naměřená teplota se počítá lineární interpolací z časově předcházejícího a následujícího monitorovacího záznamu. Důvod jejího pouţití vysvětluji v kapitole 5.1.2.
Teplota [°C]
Režim vytápění [M] … Mimo provoz [P] … Provoz [N] … Náběh
21,5 21,0 20,5 20,0 19,5 19,0 18,5 18,0 17,5
Průběh požadované teploty Požadovaná teplota [P]
3 [N]
Vysvětlivky 1 … Počáteční čas úseku (4:00:00) 2 … Počáteční požadovaná teplota (18,0 °C) 3 … Požadovaný stav (Náběh) 4 … Strmost náběhu (0,5 °C / hod.) 5 … Délka úseku (21600 s)
2 1 [M]
4
[M]
5
0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 0:00 Čas
Obr. 14. Průběh požadované teploty včetně požadovaných stavů jednotlivých režimů vypočítaný simulačním algoritmem
Jedna z tabulek („UpdateLogger“) loguje aktualizaci databáze. Díky svým sloupcům usnadňuje vyhledávání nově přidaných tabulek do kopie databáze „BMS“ na serveru společnosti Enesa. Nutností bylo přidat vlastní, velice zjednodušenou podobu ţurnálové tabulky („RefZonesHistory“). Jejím cílem je pouze zachytit historické změny referenčních zón, jejichţ refe-
31
rence byla typu tepelná a programová. Velice usnadňuje vyhledávání příslušných monitorovacích záznamů pro dané zóny. Poslední tabulka („ExceptionLogger“) slouţí pro ukládání výjimek vzniklých za běhu simulačního algoritmu. Zón je v současné době veliké mnoţství (více neţ dvanáct tisíc, a další budou průběţně přibývat), proto by bylo časově velice náročné testovat kaţdou zvlášť. Dojde-li při běhu algoritmu k chybě, nejsou uloţena vypočítaná data, ale pouze informace o vzniklém problému. Ta prozrazuje podstatu chyby a v které části algoritmu a na které zóně k ní došlo.
4.3.2 Simulační algoritmus Výsledný program sestává ze dvou částí. Úkolem první je aktualizovat databázi „DIRCAnalysis“ do podoby, která odpovídá databázi „BMS“. Druhá část vypočítává průběh poţadované teploty. Společným rysem obou je potřeba pravidelného automatického spouštění. Framework .NET nabízí několik moţností, jak lze automatického vykonání programu dosáhnout. Proto bylo nutné vybrat nejvhodnější způsob.
5 6
Jednou z moţností bylo implementovat program jako kombinaci sluţby Windows s časovačem. Sluţby Windows jsou aplikace neustále běţící na pozadí operačního systému Windows, které lze automaticky spouštět při jeho startu, a které nevyţadují další uţivatelské zásahy. Časovače umoţňují vykonání metody v poţadovaných intervalech. Kombinace těchto technologií je však jiţ k dispozici v podobě Plánovače úloh (Windows Task Scheduler), který poskytuje pohodlnější rozhraní pro nastavení časových intervalů.
Pomocí plánovače úloh se většinou spouští klasická konzolová aplikace, která vykoná potřebné algoritmy. Toto řešení by umoţnilo vyuţít technologii ORM5, která vývojáře odstiňuje od práce s databází a přistupuje pouze k doménovému modelu systému. Překáţkou se zde však stává velké mnoţství tabulek (více neţ tisíc), jejichţ struktura se opakuje. Jedním z příkladů ORM je Entity Framework 4, který poskytuje řešení pro daný problém: mapování jednoho objektu na více tabulek stejné struktury6. Avšak toto řešení je pouţitelné pouze v případě, ţe tabulky nezávisí na jiných tabulkách, coţ databázový model systému DIRC nesplňuje. Jediným východiskem by bylo napsání vlastních SQL dotazů. Implementace konzolové aplikace by také znamenala velice častou komunikaci mezi ní a databází a přenášení velkého mnoţství dat.
ORM – Objektově relační mapování (Object Relational Mapping) Známé pod anglickou zkratkou MEST – Multiple Entity Sets per Type
32
Dále se nabízelo vyuţít databázových uloţených procedur, které Microsoft SQL server podporuje. Jejich automatické spouštění lze zajistit pomocí sluţby SQL Server Agent. Obsahem procedur je jeden nebo více příkazů v jazyce TransactSQL, které jsou postupně vykonávány [4]. Jazyk Transact-SQL rozšiřuje standardní SQL například o lokální proměnné, větvení na základě podmínek, cyklus while a matematické funkce. Rychlost operování procedur s daty je nejvyšší moţná, protoţe běţí přímo uvnitř databázového serveru. Nehodí se však příliš k provádění sloţitých výpočetních operací a manipulování s řetězci.
Microsoft SQL server od verze 2005 integruje takzvané CLR (Common Language Runtime), které umoţňuje spouštění kódu napsaného v některém z jazyků .NET frameworku přímo uvnitř databázového serveru v podobě procedur, funkcí, triggerů a podobně. Vývojář tak můţe vyuţít předností těchto jazyků jako je objektový přístup či veliké mnoţství existujících knihoven. Více o moţnostech SQL CLR pojednává [5] nebo [6]. Přístup je vhodné pouţít v případě vývoje algoritmů náročných na výpočet a s častým přístupem k datům uloţených v databázi.
Vzhledem k výše uvedeným důvodům jsem se rozhodl pro technologii SQL CLR. Algoritmus je spouštěn kaţdý den v noci, kdy je server nejméně vyuţíván. Jeho krátkodobé zatíţení by tak uţivatele nemělo vůbec omezovat. Popisu algoritmů nevěnuji mnoho textu, i kdyţ představují hlavní výsledek mé práce. Jejich detailní popis by byl sloţitý a rozsáhlý a nemyslím si, ţe by přispěl k jejich lepšímu pochopení. Uvádím zde proto jejich popis z pohledu jednotlivých akcí, které postupně vykonávají. Kompletní diagram tříd a zdrojové kódy zahrnující dokumentaci jsou k nalezení na přiloţeném CD. Aktualizace databáze První část algoritmu se stará o aktualizaci databáze „DIRCAnalysis“ do podoby odpovídající kopii databáze „BMS“ na serveru společnosti Enesa. Aktualizaci je nutné spustit pokaţdé před zahájením výpočtu průběhu poţadované teploty. Spočívá v nalezení následujících uţivatelských zásahů, ke kterým došlo od poslední aktualizace a jejich aplikací na uloţené objekty:
Přejmenování budovy, podlaţí nebo zóny – Dojde k upravení jména změněného objektu v příslušné tabulce.
Smazání budovy, podlaţí nebo zóny – Daný objekt je i se všemi svými potomky z hierarchické struktury odstraněn.
Vytvoření budovy, podlaţí nebo zóny – Objekt je přidán do databáze a zařazen na odpovídající místo v hierarchické struktuře.
33
Přidání nové domény – Zkontroluje se přítomnost všech potřebných tabulek a případně dojde k uloţení všech objektů do databáze.
Nakonec je do tabulky “UpdateLogger“ přidán záznam o proběhnutí aktualizace. Výpočet průběhu požadované teploty Druhá část je zodpovědná za výpočet průběhu poţadované teploty pro danou zónu a v zadaném časovém intervalu. Algoritmus je ve výsledku velice sloţitý především kvůli značné provázanosti tabulek systému DIRC a skutečnosti, ţe jeden uţivatelský zásah můţe mít vliv na několik objektů najednou. Algoritmus vychází z aktuální podoby konfiguračních tabulek, z nichţ sestaví konfiguraci zóny zahrnující všechny atributy, které mohou ovlivnit výpočet poţadované teploty. Na ni postupně zpětně aplikuje změny prováděné uţivateli. Změny se získávají z tabulky ţurnálových záznamů. Dělí se na tři typy:
Změny, které mají vliv pouze na konfiguraci.
Změny, které ovlivní konfiguraci a vyţadují opětovné nalezení ţurnálových záznamů podle její nové podoby.
Změny, které ovlivní časové období aktuálního výpočtu. Do této kategorie spadá pouze záznam o vytvoření právě analyzované zóny.
V průběhu aplikování změn si program samostatně sestavuje tabulku změn referenčních zón. Období mezi dvěma změnami je definované jednotnou konfigurací, podle které se vypočítá průběh poţadované teploty následujícím způsobem: 1. 2. 3. 4. 5.
Průběh se určí podle stavu standardního a svátkového období. Pozmění se podle případných aperiodických poţadavků. Přidá se výjimečné období pokud nějaké existuje. Aplikují se teplotní poklesy. Doplní se teplotní náběhová rampa.
Nakonec jsou všechna období sloučena a výsledný průběh je uloţen do databáze. V běţných situacích algoritmus probíhá rychle. Avšak v případech jako změna referenční zóny nebo přejmenování objektu dochází k volání rekurzivních funkcí, které jeho běh zpomalují. Přístup k datům Pro připojení k databázi se vyuţívá třída System.Data.SqlClient.SqlConnection. Parametrem jejího konstruktoru je takzvaný connection string – řetězec obsahující především informace o serveru, databázi a uţivateli. Procedury však běţí přímo na databázovém
34
serveru, a proto je moţné vyuţít „připojení uvnitř procesu7“. Docílí se ho zapsáním connection string ve tvaru „context connection=true“. Výhodou je, ţe odpadá potřeba pouţít protokol a transportní vrstvu jako u klasického připojení klienta k databázi a tím dochází ke zvýšení rychlosti připojení. Program vyţaduje přístup ke dvěma databázím, ale procedury mohou být umístěny pouze na jedné z nich. Rozhodl jsem se za výchozí označit kopii databáze „BMS“, s níţ probíhá komunikace mnohem častěji. K databázi „DIRCAnalysis“ jiţ však není moţné přistupovat prostřednictvím „připojení uvnitř procesu“. Veškeré operace s daty se vykonávají voláním dotazů v jazyce SQL. Po vzoru objektově relačního mapování jsem vytvořil třídy, jejichţ instance reprezentují řádky jednotlivých tabulek. Pokračoval jsem implementací metod, které je ukládají nebo čtou z databáze. V případě databáze „DIRCAnalysis“ se jedná téměř pouze o základní CRUD8 operace. Tabulky systému DIRC vyţadují větší mnoţství dotazů, z nichţ je naprostá většina čtecího typu. Dotazy jsou optimalizovány tak, aby z tabulek vybíraly pouze ty sloupce, které jsou v daném případě relevantní. K vykonání dotazu slouţí třída System.Data.SqlClient.SqlCommand, jejíţ konstruktor vyţaduje řetězec s dotazem a instanci připojení SqlConnection. Je vhodné otevřít toto připojení pouze jednou na začátku a provádět nad ním všechny SQL příkazy. Před ukončením procedury je důleţité připojení uzavřít. Program ale vyţaduje přístup k databázovým datům z mnoha tříd, proto jsem se rozhodl umístit všechny metody operující s daty do jediné třídy typu Singleton. Návrhový vzor Singleton zajistí, ţe v celém programu existuje pouze jediná její instance. Jedním z jejich atributů je právě připojení k databázi, které můţe být otevřeno pouze jednou a následně pouţito v libovolné metodě. Toto řešení přineslo i nevýhodu v podobě nepřehlednosti kódu. V jediné třídě je totiţ umístěno veliké mnoţství metod, které spolu často nesouvisí. Rozhraní Program poskytuje rozhraní v podobě pěti uloţených procedur. První slouţí k aktualizaci databáze „DIRCAnalysis“. Zbývající vypočítávají průběh poţadované teploty a liší se počtem parametrů. Existuje procedura pro uskutečnění výpočtu na všech doménách, na konkrétní doméně, na konkrétní zóně a na konkrétní zóně v uţivatelem zadaném časovém intervalu.
7 8
„Připojení uvnitř procesu“ – anglicky „In-process connection“ CRUD – Create, Retrieve, Update, Delete – vytvoření, čtení, obnovení a smazání
35
36
Obr. 15. Diagram nasazení ukazuje umístění webové aplikace, databází „BMS“ a „DIRCAnalysis“ a simulačního algoritmu v podobě uložených procedur na serveru společnosti Enesa
5 Webová aplikace pro analýzu dat V kapitole popisuji webovou aplikaci slouţící k analýze získaných dat. Svým uţivatelům by měla pomoci při vyhledávání nevhodně nastavených zón a alespoň napovědět, v čem chyba konfigurace spočívá. Z důvodu obtíţné předchozí části a mnoha problémů, které se při jejím zpracovávání vyskytly, se mi nepodařilo aplikaci včas zcela dokončit. V současné době (květen – červen 2011) pokračuji na její implementaci.
5.1 Požadavky zadavatele Aplikace by měla umoţnit výběr konkrétní domény, budovy či jediné zóny na níţ uţivatel poţaduje provedení analýzy. Pro kaţdou zónu spadající do výběru se zobrazí výsledky analýzy za specifikovaný časový interval. Dělí se podle typu na tabulková data a grafy. Společným rysem jednoho druhu grafu a tabulkových dat je rozdělení výpočtů dle reţimů, pro které platí. Ty se zcela neshodují s teplotními reţimy vytápění uvedenými v kapitole 3.5.5. Rozlišují se následující reţimy:
Provozní – Je totoţný s provozním reţimem vytápění.
Mimo provozní – Zahrnuje mimo provozní a útlumový reţim vytápění.
Náběhový – Pokrývá úseky představující teplotní náběhovou rampu.
Nestandardní – Jde se o souhrnný reţim pro stavy „aktivní“, „neaktivní“, „zvyšovat teplotu“ a „sniţovat teplotu“, u nichţ nelze přesně určit poţadovanou teplotu.
Celkem – Shrnuje všechny předchozí reţimy.
5.1.1 Grafy Pro potřeby analýzy dat vyţaduje společnost Enesa dva druhy grafů. První představuje závislost teploty na čase, viz Obr. 16. Zobrazuje jednu křivku pro průběh poţadované teploty a jednu pro průběh skutečné naměřené teploty. Druhý graf je moţné popsat jako závislost míry přetápění nebo nedotápění na procentu doby v reţimu. Jinými slovy – jaké procento doby daného reţimu docházelo k přetápění o daný počet stupňů Celsia. Graf ukazuje Obr. 17.
37
Průbě požadované s skutečné teploty
Teplota [°C]
Požadovaná teplota
Skutečná teplota
21,5 20,5 19,5 18,5 17,5 0:00
12:00
0:00
12:00
0:00
Čas
Obr. 16. Závislost teploty na čase, porovnání skutečné a požadované teploty
Závislost míry přetápění na procentu doby režimu
Míra přetápění [°C]
Přetápění 5 4 3 2 1 0 -1 -2 0 -3 -4 -5
10
20
30
40
Nedotápění
50
60
70
80
90
100
Procento doby [%]
Obr. 17. Závislost míry přetápění a nedotápění na procentu doby
5.1.2 Tabulková data Tabulková data poskytují statistické informace, které uţivateli pomáhají odhalit chybně nakonfigurované zóny. Jejich struktura je znázorněna v Příloha C. Pro jejich kalkulaci se vyuţívá dat získaných algoritmem pro výpočet průběhu poţadované teploty v kombinaci s monitorovacími záznamy pořízenými systémem DIRC. Obě kolekce se promíchají a záznamy se chronologicky seřadí od nejstaršího k nejnovějšímu. Tento přístup jsem pouţil především z důvodu úspory místa v databázi. Jiným řešením by bylo rozdělit průběh poţadované teploty na kratší úseky. Jejich začátek by byl určen buď datem pořízení monitorovacího záznamu nebo přechodem na jiný poţadovaný reţim vytápění. (Případně zachováním reţimu, ale změnou poţadované teploty.) Poté by ale docházelo ke zbytečné duplikaci dat a velkému nárůstu jejich mnoţství. Z monitorovacích záznamů je nutné vyloučit neplatné záznamy. Nejprve se naleznou pomocí příslušných u nich uvedených příznaků zóny a aktuátorů. Jejich přehled je uveden 38
v Příloha B. Můţe však také dojít k úplnému přerušení komunikace někde mezi čidlem a řídicí jednotkou systému DIRC při snímání teploty nebo ke ztrátě některých dat při jejich přenosu do databáze „BMS“. Poté tedy data nejsou vůbec nalezena. Po dohodě se zadavatelem byla stanovena tolerance jednoho neexistujícího záznamu v řadě. Vyskytneli se záznamů více, je nutné celý úsek vypadlých dat označit za chybný a v analýze s ním nepočítat.
Teplota [°C]
Vývoj teploty v zóně měřený v pětiminutových intervalech 24,9 24,5 24,1 23,7 23,3 22,9 22,5 22,1 21,7 21,3 20,9 20,5 0:00
Data logger DIRC
3:00
6:00
9:00
12:00
15:00
18:00
21:00
0:00
Čas
Obr. 18. Reálný vývoj teploty v zóně (červeně) a hodnoty skutečné teploty naměřené systémem DIRC
Některé z algoritmů pracují se spojitým průběhem skutečné teploty. Systém DIRC však poskytuje pouze hodinová měření, jeţ se získávají odečtením hodnoty z čidla v době měření. Nejedná se tedy o průměrnou teplotu za poslední hodinu. Nejjednodušší moţností jak získat spojitý průběh skutečné teploty je předpokládat její lineární vývoj mezi pořízenými záznamy a počítat s jistou chybou. Pomocí samostatného senzoru9 jsem v několika místnostech změřil průběh skutečné teploty se zápisem po pěti minutách, abych zjistil, jak se reálně vyvíjí. Část výsledku společně s porovnáním s hodnotami ze systému DIRC ukazuje Obr. 18. Několik rozdílných hodnot obou měření bylo způsobeno nejspíše trochu odlišným umístěním čidel. Lze vyčíst, ţe se teplota během hodinových intervalů aţ na pár výjimek měnila lineárně. V těch výjimečných případech docházelo k odchylce o maximálně tři desetiny stupně Celsia. Jelikoţ vyvíjený nástroj má slouţit k usnadnění práce a nikoliv například k vyhodnocování dosaţených úspor, je tato malá chyba přijatelná. Lineární interpolace je také oproti jiným interpolacím v daném případě vhodnější, protoţe bude často aplikována 9
Teploměr data logger Comet R0110E – více na: http://www.cometsystem.cz/dataloggery-teplota.htm
39
na data dlouhého časového období a pro mnoho zón najednou. Její výpočet tak bude zároveň rychlejší. Rozdíl mezi lineární a jinou interpolací by se projevil především při výpočtu průsečíků průběhu poţadované a skutečné teploty. Algoritmy mají umoţňovat nanastavení libovolné tolerance odchylky skutečné teploty od poţadované, čímţ se odfiltrují úseky, kde dochází ke kmitání skutečné teploty okolo poţadované a výrazně se sníţí počet jejich průsečíků. Způsob řešení byl diskutován a schválen zaměstnanci společnosti Enesa pro první verze aplikace. Jejich cílem není dosáhnout přesného kopírování průběhu poţadované teploty skutečnou teplotou, coţ ani není moţné, ale pouze se mu co nejvíce přiblíţit zejména v provozním reţimu vytápění. Tento úkol by nepatrné odchylky vzniklé při výpočtu neměly ohrozit. 5.1.2.1 Algoritmy pro výpočet tabulkových dat V následujících odstavcích uvádím výčet algoritmů slouţících k výpočtu tabulkových dat. U kaţdého je napsán jeho účel a obecný vzorec pro získání hodnoty xy, kde y je pořadové číslo algoritmu. Nejprve uvedu seznam proměnných, které ve vzorcích vystupují. Úsek zde představuje souvislý interval s jedním reţimem, jednou počáteční teplotou a nulovou nebo konstantní strmostí náběhu. Rozlišují se indexem i. Počet úseků nebo monitorovacích záznamů v reţimu je označen n.
TOTAL_LENGTH – Celková délka všech úseků daného reţimu.
DATEi – Počáteční datum úseku nebo datum pořízení monitorovacího záznamu systémem DIRC. U prvního úseku (záznamu) je rovno nule. U ostatních se zapisuje jako počet sekund uplynulých od prvního.
LENGTHi – Délka úseku v sekundách.
TEMP_WANTEDi – Počáteční poţadovaná teplota úseku ve stupních Celsia.
TEMP_ACTUALi – Skutečná teplota na začátku úseku nebo teplota monitorovacího záznamu pořízeného systémem DIRC ve stupních Celsia.
STEEPNESSi – Strmost náběhu v úseku ve stupních Celsia za hodinu.
1) Procento času v režimu Udává, kolik procent z celkové délky analyzovaného období zabral daný reţim. Počítá se pouze z dat průběhu poţadované teploty. Informace můţe pomoci odhalit zóny, ve kterých je zbytečně dlouhou dobu zapnut provozní reţim.
40
2) Průměrná požadovaná teplota Počítá se jako váţený průměr teplot jednotlivých úseků. Rovněţ vyuţívá pouze data průběhu poţadované teploty. Porovnává se s průměrnou skutečnou teplotou.
3) Průměrná skutečná teplota Počítá se aritmetickým průměrem teplot naměřených systémem DIRC. Porovnává se s průměrnou poţadovanou teplotou.
4) Rozdíl požadované a skutečné teploty Získá se prostým odečtením průměrné poţadované a průměrné skutečné teploty. Výsledek by se měl co nejvíce blíţit nule. Zóna, u které toto neplatí, má pravděpodobně špatně nakonfigurované základní tepelné charakteristiky.
5) Doba překročení a nedosažení požadavku Zde je vyuţita kombinovaná kolekce dat průběhu poţadované teploty a monitorovacích záznamů. Kolekce je postupně procházena a vţdy u dvou sousedních prvků dochází k porovnání poţadované a skutečné teploty – počítá se jejich odchylka δi. Mohou nastat čtyři různé situace:
Odchylka obou je rovna nule – Nedošlo k překročení ani nedosaţení poţadavku.
Jedna nebo obě odchylky jsou kladné – Poţadavek byl překročen. Algoritmus zvýší dobu překročení.
Jedna nebo obě odchylky jsou záporné – Poţadavek nebyl dosaţen. Algoritmus zvýší dobu nedosaţení.
Jedna odchylka je kladná a druhá záporná – Poţadavek byl v daném úseku překročen i nedosaţen. Musí se vypočítat čas t, ve kterém došlo k protnutí křivky poţadované a skutečné teploty podle vzorce:
Doba by se správně měla přibliţovat nule. Důleţité je omezit přetápění především v provozním a náběhovém reţimu, během nichţ bývá spotřebováno nejvíce energie.
41
6) Doba zavření hlavic (aktuátorů) Vyuţívá příznaky aktuátorů uvedené u monitorovacích záznamů informující o otevřenosti nebo uzavřenosti hlavic. Algoritmus postupně prochází záznamy a počítá aktuátory, které byly v daný okamţik uzavřené – platí pro kaţdou hlavici v zóně. Konečný výsledek vydělí celkovým počtem záznamů vynásobeným mnoţstvím hlavic instalovaných v zóně. V podstatě říká, po jakou dobu nedocházelo k vytápění v zóně. Pro dosaţení co nejvyšších úspor by měla být co nejniţší. 7) Průměrná odchylka od požadavku Vychází z kolekce záznamů obsahující průsečíky získané po vykonání algoritmu číslo pět. Postupně ji prochází a počítá váţený průměr odchylek poţadovaných teplot od skutečných.
8) Maximální odchylka od požadavku Počítá se pro překročení i nedosaţení poţadavku. V obou případech se vyuţívá obdobného způsobu jejího určení. Ve stejné kolekci jako v předchozím případě je vyhledána nejvyšší odchylka překročení poţadavku. Nedošlo-li k ţádnému překročení, vyhledá se odchylka jeho nejmenšího nedosaţení.
5.2 Architektura aplikace Webový nástroj pro analýzu dat je navrţen jako n-vrstvá webová aplikace. Blíţe popíšu význam jednotlivých vrstev a způsob jakým jsou řešeny. Vrstva pro přístup k datům Jejím jediným úkolem je přistupovat k datovému úloţišti a získávat z něj nebo naopak ukládat do něj objekty doménového modelu, takzvané entity. Obvykle pro všechny entity implementuje základní CRUD operace. Neobsahuje ţádnou business logiku. Nadřazené business vrstvě pouze poskytuje interface shrnující všechny metody. Datová vrstva aplikace je navrţena pomocí vzoru repozitář10. Pro přístup k samotné databázi je vyuţit framework pro objektově relační mapování s názvem Entity Framework 4. I kdyţ je k dispozici nová verze frameworku s označením 4.1, rozhodl jsem se ji nepouţít. 10
Repository Pattern – Více v [7]
42
Trpí totiţ podstatnými nedostatky jako je obtíţné pouţití výčtového typu či nemoţnost volat uloţené databázové procedury. Naopak vývojáři nabízí nový způsob mapování entit na databázové tabulky. Namísto tradičního XML souboru se vyuţívá kódu napsaného přímo v programovacím jazyce. Business vrstva Jedná se o nejdůleţitější vrstvu aplikace. Drţí v sobě doménový model, který převádí objekty reálného světa do tříd a jejich instancí. Třídy definují své vlastnosti, chování v podobě metod, které lze na nich volat a vztahy k ostatním třídám. Dělí se na dva typy – entitní a hodnotové, takzvané „value objects“. Entity mohou existovat samy o sobě a lze je od sebe jednoznačně odlišit. Hodnotové objekty se vţdy váţí k některé entitě. Mezi entitní typy prozatím patří doména, budova, podlaţí a zóna. Případem hodnotových objektů jsou naměřená a vypočítaná data. S rozšiřováním aplikace se bude model postupně rozrůstat. Servisní vrstva Servisní vrstva vyplňuje prostor mezi business a prezentační vrstvou. Funguje na jednoduchém principu zasílání dotazů (poţadavků) business vrstvě a vracení odpovědí prezentační vrstvě. Označuje se jako Messaging Pattern. Její interface definuje operace, které můţe klient volat. Prezentační vrstva Poskytuje grafické uţivatelské rozhraní, jehoţ prostřednictvím se aplikace ovládá. Pro její implementaci je pouţit framework Visual WebGUI [20] slouţící k rychlému a jednoduchému vývoji bohatých internetových aplikací11. Framework vychází z technologie tradičních desktopových aplikací prostředí .NET známé pod názvem WinForms. Webová aplikace se tak vyvíjí téměř totoţným způsobem a sama se stará o zapojení ajaxu a dalších, dnes jiţ nezbytných, technologií. Výhodou a zároveň nevýhodou frameworku je naprosté odstínění vývojáře od HTTP dotazů a odpovědí. Vývojové prostředí Visual Studio umoţňuje aplikaci vytvářet pomocí tradičního designéra. Jednotlivé prvky stránek se vybírají z palety a umisťují na plátno. Funkčním prvkům jsou následně přiřazeny akce a události. Tento postup je velice rychlý, ale zároveň přináší řadu nevýhod. Za největší povaţuji opakování kódu a s tím související jeho špatnou udrţovatelnost. Do prezentační vrstvy je proto zapojen vzor Model-View-Presenter (Obr. 19), který logicky odděluje jednotlivé části prezentační vrstvy a navíc umoţňuje jejich testování. Jak jiţ jeho název napovídá, skládá se z: 11
Modelu – Představuje data, která se mají uţivateli prezentovat.
RIA – Rich Internet Application – Bohaté internetové aplikace
43
View – Z presenteru získává model, který následně zobrazuje. Naopak mu přeposílá uţivatelský vstup.
Presenteru – Zpracovává uţivatelský vstup a do view odesílá získaný model.
Obr. 19. Spolupráce Modelu, View a Presenteru
5.3 Plánovaná budoucí rozšíření První verze aplikace bude slouţit pouze k provedení základní analýzy dat, jejíţ poţadavky jsou zmíněny výše. Plánuje se doplnit nástroj o automatickou detekci chyb na základě uţivatelem definovaných omezení. Spočívala by v pravidelném vyhledávání porušení těchto omezení a po přihlášení by o nich uţivatele informovala. Omezením by například mohlo být dosaţení stanovené maximální nebo minimální skutečné teploty v zóně. Jiný typ by umoţňoval automatické počítání tabulkových dat z kapitoly 5.1.2.1 a jejich porovnávání se zadanými hodnotami. Společnost Enesa by v rámci této aplikace chtěla svým zákazníkům nabídnout komunikační portál pro jednoduché hlášení chyb a pokládání dotazů a poţadavků.
44
6 Testování Algoritmus pro zpětnou simulaci chodu řídicího algoritmu systému DIRC jsem testoval s umělými i reálnými daty. Hlavní překáţkou jednoznačnému vyhodnocení správného chodu algoritmu bylo velké mnoţství proměnných, které do něj vstupují. Jejich hodnoty v kombinaci s aktuálním časem mají vliv na rozdílné vyhodnocování průběhu poţadované teploty. Liší se také reakce algoritmu na uţivatelské změny nastavení v závislosti na aktuální konfiguraci zóny.
6.1 Testování s umělými daty Vzhledem k výše uvedeným důvodům se umělá data ukázala být vhodná pouze pro testování samostatných základních částí programu. Těmi je myšlen například výběr poţadovaného stavu dané konfigurace zóny, výpočet poţadované teploty, výběr jednoho ze čtrnácti programů vytápění na základě data a korektní rozparsování řetězce, který jej reprezentuje, do čitelné podoby. Značný vliv na správný chod algoritmu má vyhledávání dat v databázi. SQL dotazy se dynamicky sestavují podle konfigurace zóny a poţadovaného časového intervalu. Pro jejich částečné ověření jsem vytvořil tabulky fiktivní domény, jejíţ data jsem mohl libovolně upravovat. Z důvodu závislosti na databázi musela většina testování probíhat spouštěním uloţených procedur na databázovém serveru a porovnáváním získaných výstupů s předpokládanými.
6.2 Testování s reálnými daty Hlavní chyby a nedostatky algoritmu pomohlo odhalit testování s reálnými daty. Jak jsem zmínil v úvodu kapitoly, existuje mnoho kombinací atributů konfigurace zóny. Počet zón převyšuje dvanáct tisíc, a proto se mi podařilo otestovat pouze jejich malou část. Stále tak mohou nastat situace, na které jsem dosud nenarazil, a v nichţ se algoritmus zachová nekorektně. Budoucí uţivatelé aplikace pro analýzu dat byli na tuto skutečnost upozorněni. V případě chyby je aplikace upozorní na moţné nepřesnosti. Jediná moţnost, jak správně ověřit chod algoritmu, je porovnat zpětně vypočtený průběh poţadované teploty s hodnotami pořízenými systémem DIRC. Monitorovací záznamy, 45
které v pravidelných hodinových intervalech ukládá, obsahují kromě informace o skutečné teplotě také hodnotu poţadované teploty. Pro účely porovnání jsem vytvořil samostatnou proceduru, která porovná zadaný časový interval a zobrazí výsledky. Testování bude probíhat i za běhu aplikace. V grafu závislosti teploty na čase bude mimo průběhu poţadované a skutečné teploty jednotlivými body zobrazena poţadovaná teplota zaznamenaná systémem DIRC. Tyto body by měly leţet přesně na křivce průběhu poţadované teploty.
6.3 Závěry z testování Testování pomohlo odhalit většinu závaţných chyb v algoritmu. Ale teprve dlouhodobější pouţívání aplikace pro analýzu dat povede k odstranění zbývajících. V průběhu testování jsem nalezl také několik nedostatků systému DIRC. Systém umoţňuje uţivateli zapsat zlomové časy programu vytápění v přeházeném pořadí, coţ vede k jeho špatnému vyhodnocení a neţádoucímu průběhu vytápění.
46
7 Závěr Cílem práce bylo vytvořit nadstavbu systému DIRC v podobě webové aplikace, která by společnosti Enesa a.s. usnadňovala vyhledávání chybně nakonfigurovaných místností. Za chyby jsou v tomto ohledu povaţovány především nepřesně zadané vytápěcí programy a nevhodně zvolené tepelné charakteristiky místností. Práce byla rozdělena do dvou částí. V první byl vytvořen algoritmus simulující chod řídicího algoritmu systému DIRC, jehoţ výstupem je historický průběh poţadované teploty. Byl otestován s umělými i reálnými daty. Je však obtíţné určit, zda byly odhaleny všechny jeho nedostatky. Vstupem řídicího algoritmu je totiţ velké mnoţství atributů, které se vzájemně ovlivňují, a je proto moţné, ţe dosud nebyla zadána taková jejich kombinace, která způsobí nesprávný běh simulačního algoritmu. Testování tak bude pokračovat i za provozu. Druhým krokem bylo vytvoření webové aplikace pro analýzu a vizualizaci dat. Z důvodu mnoha problémů, ke kterým došlo během první části, se mi nepodařilo ji zcela dokončit. Její vývoj pokračuje a počítá se s nasazením první verze do konce června 2011. Aplikace bude i poté vylepšována a rozšiřována o další funkce. Analýza systému DIRC a následná implementace simulačního algoritmu pomohla odhalit některé jeho chyby a podivné chování v určitých situacích. Autor systému – společnost DOT CONTROLS a.s. – hodlá tyto nedostatky do vydání nových verzí odstranit. Architektura systému je dle mého názoru špatně navrţená, coţ se projevuje především na databázi, jejíţ tabulky nejsou normalizované. Primární klíče tvoří většinou řetězce, dochází k jejich opakovanému výskytu napříč tabulkami a také jsou často přepisovány uţivateli. Projekt mě přivedl k .NET frameworku, o kterém jsem donedávna pouze slýchával. Technologie se mi zalíbila a prozatím se mi nepodařilo objevit ţádné její větší nedostatky. Především jsem spokojen s vysokou úrovní dokumentace a literatury, která byla pro mě, jako naprostého začátečníka, často vyhledávaným pomocníkem. Do budoucna bych rád pokračoval v prozkoumávání frameworku a zdokonalování se ve vývoji .NET aplikací. Poprvé se mi také naskytla příleţitost navazovat na jiţ hotový software. Ověřil jsem si, ţe téměř neexistující dokumentace a nepromyšlený návrh architektury značně ztěţují práci. O to víc jsem se ale snaţil těchto chyb vyvarovat a svůj úkol vykonat co nejlépe. Hlavním důvodem, proč mě práce na projektu bavila, bylo vědomí, ţe není zbytečná, ale naopak se bude jednat o v praxi vyuţívaný nástroj.
47
48
8 Seznam použité literatury Knižní zdroje [1] HAINES, Roger W.; HITTLE, Douglas C. Control Systems for Heating, Ventilating, and Air Conditioning. Sixth Edition. New York : Springer Science+Business Media, Inc., 2003. ISBN 0-387-30521-1. [2] KUČERA, Petr; ŘEHÁNEK, Jaroslav; ŠAFRÁNEK, Jaroslav; JANOUŠ, Antonín. Tepelně-technické a energetické vlastnosti budov. 1. Praha : Grada, 2003. ISBN 80-7169-582-3. [3] TROELSEN, Andrew. Pro C# 2010 and the .NET 4 Platform Fifth Edition. New Zork : Apress, 2010. ISBN 978-1-4302-2549-2. [4] COLES, Michael. Pro T-SQL 2008 Programmer’s Guide. New York : Apress, 2008. 34534 s. ISBN 978-1-4302-1001-6. [5] DEWSON, Robin; SKINNER, Julian. Pro SQL Server 2005 Assemblies. New York : Apress, 2006. ISBN 1-59059-566-1. [6] COMINGORE, Derek; HINSON, Douglas. Professional SQL Server 2005 CLR Programming : with Stored Procedures, Functions, Triggers, Aggregates, and Types. Indianapolis : Wiley Publishing, Inc., 2007. ISBN 978-0-470-05403-1. [7] MILLETT, Scott. Professional ASP.NET Design Patterns. Indianapolis : Wiley Publishing, Inc., 2010. ISBN 978-0-470-29278-5. Manuály [8] DOT smartDIRC manuál. DOT CONTROLS a.s., 2010. 82 s. Internetové zdroje [9] Etatherm.cz [online]. [cit. 2011-01-20]. Obecně o regulaci vytápění. Dostupné z WWW:
. [10] BAŠTA, PH.D., Doc. Ing. Jiří. Možnosti moderních způsobů regulace. Český instalatér [online]. 2007, 4, [cit. 2011-01-20]. Dostupný z WWW: . [11] VLČEK, Ing. Jiří. Regulace teploty v budovách - teoretická základna. 2.4.2007, [cit. 2011-01-20]. Dostupný z WWW: .
49
[12] MATZ, PH.D., Ing. Václav. Využití termostatických ventilů a termostatických hlavic pro regulaci vytápění. 21.9.2009, [cit. 2011-01-20]. Dostupný z WWW: . [13] MATZ, PH.D., Ing. Václav. Zónové regulační systémy a jejich využití při úsporném efektivním vytápění. 25.1.2010, [cit. 2011-01-20]. Dostupný z WWW: . [14] ŠIROKÝ, Jan; PRÍVARA, Samuel; FERKL, Lukáš. Model Predictive Control of Building Heating System. 2010, [cit. 2011-01-20]. Dostupný z WWW: . [15] MATZ, PH.D., Ing. Václav. Ekvitermní regulace – princip a využití v systémech regulace vytápění. 8.3.2010, [cit. 2011-01-20]. Dostupný z WWW: . [16] MySQL [online]. 2011 [cit. 2011-05-10]. The MyISAM Storage Engine. Dostupné z WWW: . [17] PHP: Hypertext Preprocessor [online]. 2011 [cit. 2011-05-11]. Dostupné z WWW: . [18] The Java EE 6 Tutorial [online]. 2011-03-01 [cit. 2011-05-11]. Java Platform, Enterprise Edition (Java EE) Technical Documentation. Dostupné z WWW: . [19] MSDN Library [online]. 2011 [cit. 2011-05-11]. .NET Framework 4. Dostupné z WWW: . [20] Visual WebGui Knowledge Base [online]. 2011 [cit. 2011-05-11]. Dostupné z WWW: . Vyhlášky [21] Česko. Vyhláška ze dne 4. Října 2005 o hygienických poţadavcích na prostory a provoz zařízení a provozoven pro výchovu a vzdělávání dětí a mladistvých. In Sbírka zákonů, Česká republika. 2005, částka 141, 410, s. 7478-7488. Dostupný také z WWW: . [22] Česko. Vyhláška ze dne 16. prosince 2002, kterou se stanoví hygienické limity chemických, fyzikálních a biologických ukazatelů pro vnitřní prostředí pobytových místností a některých staveb. In Sbírka zákonů, Česká republika. 2003, částka 4, 6, s. 121-125. Dostupný také z WWW: . 50
9 Seznam použitých zkratek BMS
Building Management System
CLR
Common Language Runtime
CRUD
Create, Read, Update and Delete
ČSN
Československé technické normy
DIRC
Distributed Independent Room Control
GMT
Greenwich Mean Time
HTTP
Hypertext Transfer Protocol
HVAC
Heating, Ventilating and Air Conditioning
IDE
Integrated Development Environment
IRC
Individual Room Control
ISAM
Indexed Sequential Access Method
Java EE
Java Enterprise Edition
JRE
Java Runtime Environment
ORM
Object-Relational Mapping
PHP
PHP: Hypertext Preprocessor
RIA
Rich Internet Application
SQL
Structured Query Language
XML
Extensible Markup Language
51
52
Příloha A Hlavní databázové tabulky systému DIRC Příloha obsahuje stručný popis podstatných sloupců konfiguračních i záznamových tabulek.
Konfigurační tabulky Tabulka konfigurace domény (mlevel) Sloupec
Význam
ATTR
Název vlastnosti domény. Důleţité jsou vlastnosti „DomainNameShort“ – jednoznačný identifikátor domény a „SummerMode“ – příznak určující, zda se doména nachází v letním reţimu.
VALUE
Hodnota vlastnosti.
Tabulka budov (building) Sloupec
Význam
BUILDING
Textový název budovy.
Tabulka podlaží (floor) Sloupec
Význam
BUILDING
Textový název budovy, v níţ se podlaţí nachází.
FLOOR
Textový název podlaţí.
Tabulka zón (zone) Sloupec
Význam
BUILDING
Textový název budovy, v níţ se zóna nachází.
FLOOR
Textový název podlaţí, v němţ se zóna nachází.
ZONE
Textový název zóny. Unikátní v rámci budovy.
REF_ZONE
Textový název referenční zóny.
REF_TYPE
Typ reference.
53
Sloupec
Význam 1 – Programová, 2 – Tepelná a programová.
WANTED_STATE_STANDARD
Stav standardního období. 0 – Neaktivní, 1 – Akivní, 2 – Zvyšovat teplotu, 3 – Sniţovat teplotu, 4 – V provozu, 5 – Mimo provoz, 6 – Dle programu, 7 – Útlum.
WANTED_STATE_ABNORMAL
Stav výjimečného období. Hodnoty jsou stejné jako u WANTED_STATE_STANDARD. Navíc stav 8 – Standardní.
WANTED_STATE_FEAST
Stav svátkového období. Hodnoty jsou stejné _ABNORMAL.
jako
u
WANTED_STATE-
ABNORMAL_FROM
Začátek výjimečného období.
ABNORAML_TO
Konec výjimečného období.
ASSIGNING
Provozní určení zóny. Řetězec tvaru „SOURCE/NAME“.
DEFAULT_TEMP_IN_SERVICE
Výchozí poţadovaná provozní teplota v desetinách stupně Celsia.
DEFAULT_TEMP_OUT_OF_SERVICE
Výchozí poţadovaná mimo provozní teplota v desetinách stupně Celsia.
DEFAULT_TEMP_INHIBIT
Výchozí poţadovaná útlumová teplota v desetinách stupně Celsia.
SUMMER_MODE_REACTION
Způsob reakce na aktivní letní reţim. 0 – Regulovat dle konfigurace, 1 – Neprovádět regulaci.
STEEPNESS
Strmost náběhu ve stupních Celsia za hodinu.
DRIFT
Doba doběhu v minutách.
PROGRAM_TYPE
Typ programu. 0 – Vţdy v provozu, 1 – Denní (Pouţívá PROGRAM_1.), 2 – Týdenní (Pouţívá PROGRAM_1 aţ 7.), 3 – Čtrnáctidenní (Pouţívá PROGRAM_1 aţ 7 pro liché týdny a PROGRAM 8 aţ 14 pro sudé týdny.), 4 – Pracovní (Pouţívá PROGRAM_1 pro pracovní dny a PROGRAM_6 pro víkendové dny.) 5 – Vţdy mimo provoz, 6 – Vţdy v útlumu.
PROGRAM_1 .. 14
Definice programu. Řetězec tvaru „Teplota : Čas : Teplota : Čas : Teplota …“, kde teplota můţe být zadána přímo číselnou hodnotou nebo odkazem na teplotní reţim a čas je zapsán počtem minut, které uběhly od půlnoci.
54
Tabulka skupin (drc_group) Sloupec
Význam
GROUP_NAME
Textový název skupiny.
OWNER
Autor skupiny.
Tabulka členů skupin (group_member) Sloupec
Význam
GROUP_NAME
Textový název skupiny.
OWNER
Autor skupiny.
BUILDING
Textový název budovy, která je členem skupiny.
FLOOR
Textový název podlaţí, které je členem skupiny. Pouţívá se v kombinaci s budovou.
ZONE
Textový název zóny, které je členem skupiny. Pouţívá se v kombinaci s budovou.
Tabulka provozních určení Sloupec
Význam
SOURCE
Typ provozního určení. 0 – Dle normy ČSN, 1 – Uţivatelské, 2 – Legislativní.
NAME
Textový název provozního učení.
TEMP_IN_SERVICE
Poţadovaná provozní teplota.
TEMP_OUT_OF_SERVICE
Poţadovaná mimo provozní teplota.
TEMP_INHIBIT
Poţadovaná útlumová teplota.
Tabulka svátků (feast) Sloupec
Význam
YEAR
Rok, pro který je svátek definován.
FESAT_DAY
Datum a čas začátku svátku ve formátu UNIX timestamp v GMT.
FIXED
Typ svátku. 0 – Uţivatelsky definovaný, 1 – Státní, 2 – Neplatný státní.
Tabulka aperiodických požadavků Sloupec
Význam
FROM_GMT
Datum a čas začátku poţadavku ve formátu UNIX timestamp v GMT.
TO_GMT
Datum a čas konce poţadavku ve formátu UNIX timestamp v GMT.
OBJECT_NAME
Objekt, pro který je poţadavek určen. Je jím buď skupina, pak nese její název, nebo konkrétní zóna, pak má tvar „BUILDING/ZONE“.
55
Sloupec
Význam
OWNER
Autor poţadavku.
WANTED_STATE
Poţadovaný stav během poţadavku. Hodnoty jsou stejné jako u WANTED_STATE_ABNORMAL v tabulce zón.
Záznamové tabulky Tabulka monitorovacích záznamů (mon) Sloupec
Význam
SOURCE_GMT
Datum pořízení monitorovací záznamu ve formátu UNIX timestamp v GMT.
BUILDING
Textový název budovy.
ZONE
Textový název zóny, pro kterou byl záznam pořízen.
TEMP_ACTUAL
Skutečná teplota v zóně v době pořízení záznamu v desetinách stupně Celsia.
TEMP_WANTED
Poţadovaná teplota v zóně v době pořízení záznamu v desetinách stupně Celsia.
ACT_AGE
Stáří informace v sekundách. Při hodnotě nad 120 sekund se záznam povaţuje za neplatný.
ACT_FLAGS
Bitové příznaky zóny. Viz příloha B.
A1_ACT_FLAGS
Bitové příznaky prvního aktuátoru. Viz příloha B.
A2_ACT_FLAGS
Bitové příznaky druhého aktuátoru. Viz příloha B.
A3_ACT_FLAGS
Bitové příznaky třetího aktuátoru. Viz příloha B.
A4_ACT_FLAGS
Bitové příznaky čtvrtého aktuátoru. Viz příloha B.
Tabulka žurnálových záznamů (journal) Sloupec
Význam
SOURCE_GMT
Datum provedení uţivatelského zásahu do systému ve formátu počtu milisekund uplynulých od 1.1.1970 v GMT.
ITEM_TYPE
Identifikace zásahu. Říká, jakého atributu se týkala. Kompletní seznam moţných zásahů je k dispozici ve slovníku na přiloţeném CD.
ITEM_ID
Identifikace objektu, na němţ byl zásah proveden.
USER_NAME
Autor provedeného zásahu.
ACTION_TYPE
Typ zásahu. 0x01 – Změna atributu, 0x02 – Smazání objektu, 0x03 – Přidání objektu, 0x04 – Přejmenování objektu, 0x11 – Skupinová změna atributu (Provedena nad skupino zón.), 0x21 – Zaznamenání hodnot atributů před smazáním objektu.
OLD_VALUE
Původní hodnota atributu před provedením zásahu převedená na řetězec.
NEW_VALUE
Nová hodnota atributu po provedení zásahu převedená na řetězec.
56
Příloha B Bitové příznaky zóny a aktuátorů Příznaky zóny (ACT_FLAGS) Název
Hodnota
Význam
CONFIG_ERROR
0x01
Chyba konfigurace. Celý záznam je nutné ignorovat.
PRIMETHERMO_ERROR
0x02
Chyba lokálního nebo vzdáleného vztaţného snímače. Sloupec TEMP_ACTUAL je nutné ignorovat.
LOCALTHERMO_ERROR
0x04
Chyba lokálního snímače zóny. U zón s tepelnou referencí není tento příznak povaţován za chybu. Sloupec TEMP_ACTUAL je však vţdy nutné ignorovat.
TANTIFREEZE
0x10
Zabírala proti mrazová ochrana na úrovni transakční jednotky. Regulátor dělal vše pro zvýšení teploty nad 5°C.
SELECT_TEMP
0x20
0 – Nedochází k porovnávání mezi poţadovanou a skutečnou teplotou. 1 – Dochází k porovnávání.
WANT_RELATIVE
0x40
Při ZONEFLAG_ACT_SELECT_TEMP = 0 0 – Poţadavek zóny definován absolutně (aktivní / neaktivní). 1 – Poţadavek zóny definován relativně (zvyšovat / sniţovat teplotu). Při ZONEFLAG_ACT_SELECT_TEMP = 1 0 – Poţadovaná teplota je hlavní. 1 – Poţadovaná teplota je alternativní.
ACTIVE_LOW
0x80
Při ZONEFLAG_ACT_WANT_RELATIVE = 0 0 – Neaktivní aktuátory. 1 – Aktivní aktuátory. Při ZONEFLAG_ACT_ WANT_RELATIVE = 1 0 – Snaha zvyšovat teplotu. 1 – Snaha sniţovat teplotu.
(ZONEFLAG_ACT_...)
57
Příznaky aktuátorů (Ax_ACT_FLAGS) Název
Hodnota
Význam
ACTIVE
0x01
0 – Aktuátor byl neaktivní. 1 – Aktuátor byl aktivní.
QUASISTABLE
0x02
Nevýznamné.
OVERCURRENT
0x04
Byl detekován nadproud v aktuátoru.
UNDERCURRENT
0x08
Byl detekován podproud v aktuátoru. Lze předpokládat, ţe nefunguje a je neustále aktivní.
ZANTIFREEZE
0x10
Zabírala proti mrazová ochrana na úrovni zónové jednotky. Regulátor dělal vše pro zvýšení teploty nad 5°C.
ANTIBLOCK
0x20
V době pořízení záznamu probíhalo protáčení aktuátoru, aby se předešlo zarůstání ventilů.
TESTING
0x40
Probíhalo testování aktuátoru.
(ACTFLAG_ACT_...)
58
Příloha C Struktura tabulky pro analýzu dat Pozn.: Tabulka je rozdělena pouze z důvodu nedostatku prostoru. Tabulka 1 První část tabulky pro analýzu dat.
Režim
Procento času v režimu [%]
Průměrná teplota [°C] Požadovaná
Skutečná
Rozdíl požadované a skutečné teploty [°C]
Doba překročení požadavku [s]
[%]
Provozní Mimo provozní Náběhový Nestandardní Celkem
Tabulka 2 Druhá část tabulky pro analýzu dat.
Režim
Doba nedosažení požadavku [s]
[%]
Doba zavření hlavic [%]
Průměrná odchylka od požadavku [°C] Přetápí
Nedotápí
Celkem
Maximální odchylka od požadavku [°C] Přetápí
Nedotápí
Provozní Mimo provozní Náběhový Nestandardní Celkem
59
60
Příloha D Obsah přiloženého CD text/ slavopet_2011bach.docx slavopet_2011bach.pdf src/ algorithm/ web_application/ sql/ deploy.pdf uml/ readme.txt
- adresář obsahující text bakalářské práce - zdrojový text ve formátu .docx - text pro tisk ve formátu .pdf - adresář obsahující zdrojové soubory - zdrojové kódy simulačního algoritmu - zdrojové kódy webové aplikace - SQL skripty pro vytvoření ukázkových databází - instalační příručka popisující deploy uloţených procedur na databázový server - adresář obsahující UML diagramy tříd - popis adresářů na CD
61
