Příloha k průběžné zprávě za rok 2015

Příloha k průběžné zprávě za rok 2015

Číslo projektu: TE02000077 Název projektu: Smart Regions – Buildings and Settlements Information Modelling, Technology and Infrastructure for Sustainable Development

Číslo výstupu: TE02000077DV012 Název výstupu: Development of a mathematical model and implementation of a test SW tool for the thermal-hydraulic calculation including elements of renewable energy

Datum dosažení: 31. 12. 2015

Předkládá: Název organizace:

ORTEP, s.r.o.

Jméno řešitele:

Ing. Jan Havelka CSc., Ing. Roman Polach a kol.

TAČR – CK – Smart Regions - WP3 – TE02000077DV012 - Příloha k průběžné zprávě za rok 2015

Obsah 1

ÚVOD .............................................................................................................................................. 7

2

Popis výchozího SW produktu MOP ............................................................................................... 8 2.1

Princip činnosti a struktura dat .............................................................................................. 8

2.1.1

Konvence pojmenování listů ............................................................................................. 9

2.1.2

Hierarchie objektů ............................................................................................................. 9

2.1.3

Možnosti zadávání vstupních parametrů ........................................................................ 15

2.1.4

Zadávání časových řad ..................................................................................................... 15

2.1.5

Definice výpočetního intervalu........................................................................................ 16

2.2

Grafické rozhraní MOPED .................................................................................................... 18

2.2.1

Základ práce s MOPED ..................................................................................................... 19

2.2.2

Načtení a analýza geografických dat ............................................................................... 19

2.2.3

Objekty, které lze zobrazovat a editovat ......................................................................... 20

2.2.4

Vlastnosti mapového zobrazení ...................................................................................... 21

2.2.5

Podkladové mapy ............................................................................................................ 22

2.2.6

Rozložení oken aplikace ................................................................................................... 23

2.2.7

Dialog: Volba počítaných výstupních parametrů ............................................................ 23

2.2.8

Dialog: Volba cest pro tlakový diagram ........................................................................... 25

2.2.9

Dialog: Zadání neuronového modelu spotřeby ............................................................... 29

2.2.9.1

Zadání spotřeby s využitím neuronového modelu ................................................. 29

2.2.9.2

Výpočet spotřeby s využitím neuronového modelu ............................................... 30

2.2.10

Okno: Návrhová tabulka.............................................................................................. 31

2.2.11

Okno: Návrhová mapa................................................................................................. 32

2.2.12

Okno: Zadávání průběhu dynamických parametrů ..................................................... 34

2.2.13

Okno: Výsledková tabulka ........................................................................................... 36

2.2.14

Okno: Výsledková mapa .............................................................................................. 36

2.2.15

Okno: Zobrazení tlakového diagramu ......................................................................... 39

2.2.16

Okno: Zobrazení diagramu čerpadla ........................................................................... 39

2.2.17

Okno: Zobrazení průběhu dynamických parametrů ................................................... 41 strana 2


2.3

Výpočtový model ................................................................................................................. 41

2.3.1

Základní úloha.................................................................................................................. 41

2.3.1.1

Zadání...................................................................................................................... 42

2.3.1.2

Příprava vstupních dat ............................................................................................ 43

List „Síť“ – globální nastavení celé sítě ................................................................................ 43 List „P“ – úseky potrubí ........................................................................................................ 43 List „Zdr“ – zdroje ................................................................................................................ 43 List „Sp“ – spotřebiče ........................................................................................................... 43 List „Uz“ – běžné uzly ........................................................................................................... 43 List „KP“ – katalog potrubí ................................................................................................... 44 2.3.1.3

Výpočet stacionárního modelu ............................................................................... 44

2.3.1.4

Výsledky .................................................................................................................. 45

2.3.2

Popis výpočtového modelu sítí ........................................................................................ 45 Výpočet průtoků v přívodní větvi......................................................................................... 45 Výpočet průtoků ve vratné větvi.......................................................................................... 46 Tepelný výkon zdroje a tepelné ztráty ................................................................................. 46 Čerpadla ............................................................................................................................... 46 Škrticí armatury.................................................................................................................... 46 Zkraty ................................................................................................................................... 46 Směšovací uzly ..................................................................................................................... 46

3

2.3.3

Výpočet tepelné sítě s více zdroji a okruhy ..................................................................... 46

2.3.4

Specifické vlastnosti výpočtu parní tepelné sítě ............................................................. 49

Implementační projekt REGIOS offline ......................................................................................... 51 3.1

Kompatibilita mezi MOP a REGIOS ...................................................................................... 52

3.1.1 3.2

Dokumentace REGIOS offline .......................................................................................... 54 Nezávislý režim aplikace ...................................................................................................... 55

3.2.1

Datová struktura uloženého modelu............................................................................... 57

3.2.1.1

Strategie ukládání dat do tabulek ........................................................................... 57 strana 3


3.2.1.2

Struktura tabulek .................................................................................................... 57

3.2.1.3

Atomicita čtení a zápisu modelů ............................................................................. 59

3.2.1.4

Řešení problematiky maximální délky uloženého parametru v databázi ............... 59

3.2.2

Nástroj pro aktualizaci formátu uloženého modelu ........................................................ 59

3.2.3

Řešení neočekávaných problémů v uloženém modelu ................................................... 60

3.2.4

Vytváření nových modelů v nezávislém režimu .............................................................. 60

3.2.5

Porovnávání modelů, zobrazení externích průběhů, map a diagramů ........................... 62

3.2.5.1

Interní reprezentace odkazů na externí modely: ................................................... 62

3.2.5.2

Uživatelské rozhraní pro externí modely ................................................................ 63

3.2.6 3.3

Výměna nastavení uživatelského rozhraní mezi modely ................................................ 64 Singulární vstupy, singulární výstupy, vzorce, odkazy ......................................................... 65

3.3.1

Princip použití singulárních vstupů a princip plnění singulárních výstupů ...................... 68

3.3.1.1

Zacházení se singulárními parametry společné pro MOP i REGIOS ........................ 68

3.3.1.2

Zacházení se singulárními parametry specifické pouze pro REGIOS ...................... 69

3.3.2

Vzorce a odkazy, rozhraní pro jejich editaci .................................................................... 69

3.3.2.1

Dialog editace / zobrazení vzorců ........................................................................... 69

3.3.2.2

Vyvolání dialogu editace / zobrazení vzorce........................................................... 71

3.3.3

Rozhraní editace definic / metainformací singulárních parametrů ................................ 71

3.3.3.1 3.3.4 3.4

Dialog editace definice konkrétního parametru ..................................................... 72

Rozhraní editace a zobrazení hodnot singulárních parametrů ....................................... 74 Vylepšení stávajících technologických prvků ....................................................................... 75

3.4.1

Dopravní zpoždění zdrojů v dynamickém výpočtu .......................................................... 75

3.4.2

Řízení zdrojů podle požadovaného výkonu ..................................................................... 76

3.4.2.1 3.4.3 3.5

Algoritmus implementace řízení zdrojů .................................................................. 77

Generátor výstupní teploty ............................................................................................. 78 Rozhraní specializovaných výpočetních objektů ................................................................. 78

3.5.1

Objekt statického akumulátoru ....................................................................................... 78

3.5.2

Objekty specializovaných spotřebičů .............................................................................. 79

3.5.3

Objekty specializovaných zdrojů ..................................................................................... 79 strana 4


3.6

Vylepšení obecných schopností ........................................................................................... 80

3.6.1

Výpočtově neutrální sada dat .......................................................................................... 80

3.6.2

Konfigurovatelné jednotky veličin ................................................................................... 81

3.6.3

Nemodální výsledkový dialog a časově specifická varování ............................................ 83

3.7

Vylepšení uživatelského rozhraní......................................................................................... 86

3.7.1

Grafické zadávání vstupů ................................................................................................. 86

3.7.2

Obalové křivky tlakového diagramu ................................................................................ 87

3.7.3

Zobrazení denních, hodinových a dalších průměrů......................................................... 88

3.7.3.1 3.7.4

Přehledné dialogy pro výběr řad k návrhu a zobrazení výsledků .................................... 90

3.7.5

Přizpůsobitelné dialogy ovládání vybraných vstupů ....................................................... 93

3.8

Řešení problémů letního času ............................................................................................. 97

3.8.1 3.9

Konverze specifikace času ............................................................................................... 99 Specifické algoritmy, schema, DLL knihovny, „háčky“ ....................................................... 101

3.9.1

Fixní „schéma“ modelu .................................................................................................. 101

3.9.2

„Háčky“ a obecné napojení algoritmů z DLL knihoven .................................................. 104

3.9.2.1 4

Rozhraní pro zobrazování průměrů ........................................................................ 89

Příklad konkrétní „destinační“ vrstvy ................................................................... 105

Implementační projekt REGIOS online ....................................................................................... 107 4.1

Kompatibilita s MOPem a REGIOSem offline ..................................................................... 107

4.1.1 4.2

Dokumentace REGIOS online ........................................................................................ 107 Režimy práce: simulační, predikční, analytický .................................................................. 108

4.2.1

Rozhraní přechodu do predikčního a analytického režimu ........................................... 109

4.2.1.1

Predikční režim ..................................................................................................... 109

4.2.1.2

Analytický režim .................................................................................................... 111

4.2.2

„Online“ veličiny pro návaznost na reálný běh modelovaného systému ...................... 112

4.2.2.1 4.2.3

Rozhraní pro definici „online veličin: .................................................................... 114

Transformace: verifikace, dopočet vyhlazení online veličin .......................................... 115

4.2.3.1

Editace (definic) transformací ............................................................................... 123

4.2.3.2

Hlášení o výsledcích transformací......................................................................... 124

4.2.4

Načtení predikovaných online veličin a jejich vazba na vstupy modelu ....................... 125 strana 5


4.3

Systém korekcí modelu spotřeby podle aktuálních online veličin ..................................... 126

4.4

Inteligentní aktualizace predikce – Kontinuální prediktor ................................................. 127

4.4.1 4.5

Automatická aktualizace predikce – Periodický kontinuální prediktor ......................... 128 Aktualizace analýzy ............................................................................................................ 129

4.5.1 4.6

Automatická aktualizace analýzy................................................................................... 129 Sekundární databázový zdroj online veličin....................................................................... 130

4.6.1

MeaCopy – Periodické plnění sekundárního zdroje dat z primárního zdroje dat ......... 132

4.6.2

Hromadný přesun dat mezi kopiemi zdrojů online dat ................................................. 133

4.6.2.1

Formát výměnných souborů ................................................................................. 133

4.6.2.2

Nástroj MeaDown ................................................................................................. 134

4.6.2.3

Nástroj MeaUp ...................................................................................................... 135

4.7 4.7.1

Posílání výstupních teplot do technologie ......................................................................... 137 GvtScan – Zpřístupnění vypočtených hodnot v reálném čase ...................................... 137

strana 6


1

ÚVOD

Balíček WP3 je zaměřen na vývoj a následnou implementaci SW nástrojů pro denní přípravu provozu a optimalizaci malých lokálních tepelných sítí ve zkoumaných „inteligentních“ regionech. Vyvíjený SW byl nazván REGIOS a bude umožňovat vzájemné propojení nejrůznějších technologických prvků na straně výroby, transportu a spotřeby tepla včetně vybraných prvků zkoumaných v ostatních balíčcích celého projektu. Předkládaná technická zpráva obsahuje implementační projekt nově vyvíjeného SW REGIOS. Dokument je rozdělen do tří částí, na popis stávajícího SW MOP, popis SW REGIOS off-line a popis SW REGIOS on-line. Tyto tři části zároveň odpovídají třem vývojovým úrovním vyvíjeného SW. Z hlediska celkového zasazení těchto činností do kontextu celého projektu a balíčku WP3, tak uvedená zpráva představuje dosažení výstupu TE02000077DV012 „Vývoj matematického modelu a jeho implementace“ vzniklého v rámci aktivit A 3.1 „Implementace prvků výroby, transportu a spotřeby tepla“ a A 3.2 „Modelovaní a simulace toků energie v pilotních lokalitách pomocí nového SW“

strana 7


2

Popis výchozího SW produktu MOP

MOP je softwarový nástroj pro optimalizaci stávajících a návrh nových tepelných sítí, založený na komplexních tepelně-hydraulických výpočtech. Slouží pro řešení inženýrských, projektových a optimalizačních úloh spojených s dimenzováním potrubí, čerpadel, redukčních a směšovacích stanic a zkratů, pro analýzu přerozdělení průtoku a výpočet tlakových poměrů. Základem nástroje MOP je schopnost modelování: o

vodních a parních tepelných sítí,

o

složitých topologických struktur s více okruhy a více zdroji tepla,

o

rozsáhlých sítí se ztrátou oběhového množství,

o

čerpacích, redukčních a směšovacích stanic, zkratů a uzavíracích armatur,

o

celkové energetické bilance včetně výpočtu tepelných ztrát,

o

proudění přehřáté i mokré páry včetně výpočtu odvodu kondenzátu,

o

dynamických jevů v soustavách,

o

modelování dynamického chování spotřeby tepla (výkon, teplota vratu) pomocí neuronových sítí.

MOP umožňuje jak grafickou editaci a prohlížení dat, tak možnost přípravy a zpracování dat na úrovni tabulek tabulkového procesoru. Import dat je možné provádět z různých systémů GIS a export výsledků zahrnuje širokou nabídku SQL databází. Nástroj dále nabízí prostředky výrazně usnadňující tvorbu pravoúhlých výpočtových schémat.

2.1 Princip činnosti a struktura dat Vstupy i výstupy modelu MOP jsou zapouzdřeny v sešitu XLS. V tomto sešitu jsou v zásadě 3 sady listů: sada návrhových listů představujících vstupy výpočtu, sada výsledkových listů představujících výstupy výpočtu a volitelně sada uživatelských listů, do kterých je možné pomocí vzorců a odkazů vybudovat nadřazené ovládání vstupů, zpracování výstupů, případně kombinace obojího nebo zřetězení s dalším software zpracovávající data modelu. List návrhové či výsledkové sady obsahuje informace o daném typu objektu. Každá instance daného typu objektu odpovídá jednomu řádku listu. Sloupce jsou rozděleny do 3 kategorií: Identifikační parametry, vstupní parametry a výstupní parametry. Listy návrhové sady neobsahují výstupní parametry. Instance výsledkové sady buď odpovídají instanci návrhové sady (stejné hodnoty identifikačních a vstupních parametrů) nebo vznikají až během výpočtu. strana 8


Z prostředí Excel lze při otevřeném sešitu obsahujícím model MOP vyvolat následující činnosti:  výpočet modelu;  přechod do grafického rozhraní MOPED;  spuštění doplňujícího modulu, např. importu z GIS, exportu do SQL databáze apod. – nebo spuštění dílčího dialogu rozhraní MOPED.

2.1.1 Konvence pojmenování listů Názvy výstupních listů končí znakem „+“. Názvy listů vztahujících se k parním typům objektů, které mají jinou strukturu parametrů než jejich vodní ekvivalenty, začínají znakem „.“

2.1.2 Hierarchie objektů Objekt „síť“ slouží k zadávání parametrů společných pro celou síť počítaného modelu. Objekt síť může být v modelu jen jeden. Některé typy objektů se považují za odvozené od nějakého rodičovského typu: Zdroje, spotřebiče, směšovací uzly, zkraty, odvaděče kondenzátu a běžné uzly mají společný rodičovský typ „obecný uzel“. Úseky potrubí, čerpadla, škrtící a uzavírací armatury mají společný rodičovský typ „větev“. Kromě objektu sítě mají všechny objekty identifikační parametry (nejčastěji jen jeden). Jejich kombinace musí být jednoznačná mezi všemi objekty daného rodičovského typu, tj. např. ani žádný spotřebič nesmí mít stejný název se zdrojem. Typy zdroj a spotřebič mají různý význam při modelování primární a sekundární sítě. Pro primární síť spotřebiče představují předávací stanice; v sekundární síti jsou předávací stanice naopak reprezentovány zdroji. Čerpadla, škrtící a uzavírací armatury jsou považovány (kromě své specifické funkce) za potrubí nulové délky, tj. mají nulové teplené a hydraulické ztráty. Nápověda k zadávání jednotlivých parametrů se zobrazí v bublině při najetí myší nad buňku s názvem parametru. MOP používá tento výčet neabstraktních (koncových) typů objektů MOP (jako pod-body jsou uvedeny nejdůležitější vstupní parametry):  Síť vodní o Časové určení výpočtu o Název referenčního zdroje o Sezóna (Sezóna může být topná (1) nebo letní (0). Má vliv na spotřebu pouze v případě použití neuronového modelu.) o Teplota vzduchu o Teplota zeminy o HKST (Hladina konstantního statického tlaku) strana 9




  





o Uzel pro HKST (Uzel, pro který se určuje poměr rozevření tlaků nad HKST) o Poměr nad HKST (Poměr rozevření tlaků nad HKST v daném uzlu: Např. „1“ znamená udržování konstantního tlaku ve vratu.) o dP v uzlu (Požadovaný rozdíl tlaků ve vybraném uzlu) o Uzel s dP (Název uzlu, v kterém je udržován požadovaný rozdíl tlaků: Je-li zadáno „!CALC“, je tento uzel určen automaticky jako hydraulicky nejvzdálenější spotřebitel. Případné automatické určení uzlu probíhá pouze v části sítě, která obsahuje uzel se zadaným poměrem nad HKST a je ohraničena funkčními (správně umístěnými) škrtícími armaturami.) Síť parní o Časové určení výpočtu o Název referenčního zdroje o Sezóna (Sezóna může být topná (1) nebo letní (0). Má vliv na spotřebu pouze v případě použití neuronového modelu.) o Teplota vzduchu o Teplota zeminy o Přetlak v přívodu (Přetlak páry v přívodním (výstupním) potrubí referenčního zdroje) o Přetlak ve vratu (Přetlak vratného kondenzátu ve vstupním potrubí referenčního zdroje) Běžný uzel vodní o Nadmořská výška Běžný uzel parní o Nadmořská výška Zdroj vodní o Nadmořská výška o Podíl zdroje na celkovém průtoku (Podíl zdroje na celkovém průtoku všemi spotřebiči: Pro výpočet je prioritní průtok spotřebiči, ten se může měnit a zdroje se přizpůsobují v zadaném poměru. Součet koeficientů všech zdrojů musí být roven 1. Případně může mít jeden zdroj uvedeno „!CALC“, značící dorovnání sumy do hodnoty 1.) o Poměr průtoku vratu / přívodu (U referenčního zdroje je povinně „!CALC“. U ostatních je povinně číselná hodnota, která definuje průtok vratem daného zdroje na základě vztahu: Průtok vratu = Poměr * Průtok přívodu. Pomocí tohoto parametru se nepřímo zadává množství doplňované či odpouštěné vody. Při poměru 1 se nedoplňuje ani neodpouští žádná voda. Při poměru menším než 1 se voda doplňuje, při poměru větším než 1 se voda ve zdroji odpouští.) o Požadovaná teplota výstupu Zdroj parní o Nadmořská výška o Podíl zdroje na celkovém průtoku o Poměr průtoku vratu ku průtoku přívodu o Požadovaná entalpie výstupu Spotřebič vodní o Nadmořská výška o Požadovaný příkon spotřebiče (Je-li použita kategorie spotřeby s neuronovým modelem, považuje se zadaná hodnota za násobný koeficient výkonu daného neuronovým modelem, strana 10


navíc je výsledná hodnota výkonu vydělena sumou koeficientů všech spotřebičů příslušejících k dané kategorii.) o Kategorie spotřeby (Název kategorie spotřeby přiřazující násobný koeficient příkonu zadávaný v seznamu kategorií a skrze kategorii také eventuálně neuronový model výkonu: Je-li místo názvu zadáno „!NONE“, je koeficient považován za roven 1.) o Ztráta oběhové vody (Podíl průtoku spotřebičem, který se ztrácí (na výstupu spotřebiče) a není vracen zpět do sítě: Odpovídající ztráta tepla není zahrnována do příkonu spotřebiče, ale do výstupu „Ztráty tepla z nevracení média“.) o Požadovaná teplota výstupu (Teplota vratu oběhové vody u spotřebiče: Je-li uvedeno „!GLB“, použije se implicitní nastavení sítě. Je-li uvedeno „!CALC“, musí být zadán rozdíl teplot nebo neuronový model. Je-li uvedena hodnota teploty vratu, musí být naopak pro rozdíl teplot zadáno „!CALC“ a nesmí být použit neuronový model. Doporučeno je spíše zadávat rozdíl teplot.) o Požadovaný rozdíl teplot (Rozdíl teploty přívodu a vratu oběhové vody: Je-li uvedeno „!GLB“, použije se implicitní nastavení sítě. Je-li uvedeno „!CALC“, musí být zadána teplota vratu nebo neuronový model. Je-li uvedena hodnota rozdílu teplot, musí být naopak pro teplotu vratu zadáno „!CALC“ a nesmí být použit neuronový model.)  Spotřebič parní o Nadmořská výška o Požadovaný příkon spotřebiče (Je-li použita kategorie spotřeby s neuronovým modelem, považuje se zadaná hodnota za násobný koeficient výkonu daného neuronovým modelem, navíc je výsledná hodnota výkonu vydělena sumou koeficientů všech spotřebičů příslušejících k dané kategorii.) o Kategorie spotřeby (Název kategorie spotřeby přiřazující násobný koeficient příkonu zadávaný v seznamu kategorií a skrze kategorii také eventuálně neuronový model výkonu: Je-li místo názvu zadáno „!NONE“, je koeficient považován za roven 1.) o Ztráta kondenzátu (Podíl průtoku spotřebičem, který se ztrácí (na výstupu spotřebiče) a není vracen zpět do sítě: Odpovídající ztráta tepla není zahrnována do příkonu spotřebiče, ale do výstupu „Ztráty tepla z nevracení média“.) o Požadovaná entalpie výstupu (Entalpie vratu u spotřebiče: Je-li uvedeno „!GLB“, použije se implicitní nastavení sítě. Je-li uvedeno „!CALC“, musí být zadán rozdíl entalpií nebo neuronový model. Je-li uvedena hodnota entalpie vratu, musí být naopak pro rozdíl entalpií zadáno „!CALC“ a nesmí být použit neuronový model. Doporučeno je spíše zadávat rozdíl entalpií.) o Požadovaný rozdíl entalpií (Rozdíl entalpií u spotřebiče: Je-li uvedeno „!GLB“, použije se implicitní nastavení sítě. Je-li uvedeno „!CALC“, musí být zadána entalpie vratu nebo neuronový model. Je-li uvedena hodnota rozdílu entalpií, musí být naopak pro entalpii vratu zadáno „!CALC“ a nesmí být použit neuronový model.)  Odvaděč kondenzátu o Nadmořská výška o Ztráta odvedeného kondenzátu (Podíl průtoku odvedeného kondenzátu, který se ztrácí a není vracen zpět do sítě: Odpovídající ztráta tepla je zahrnována do výstupu „Ztráty tepla z nevracení média“.) strana 11


 Směšovací uzel o Nadmořská výška o Požadovaná teplota za směšováním  Zkrat o Nadmořská výška o Požadovaná teplota vratu za zkratem (Teplota namíchaného vratu za zkratem: Je-li uvedeno „!CALC“, musí být zadán požadovaným průtok zkratem. Je-li hodnota teploty vratu za zkratem zadána, musí být naopak pro průtok zkratem zadáno „!CALC“) o Požadovaný průtok zkratem (Průtok zkratem: Je-li uvedeno „!CALC“, musí být zadána požadovaná teplota vratu za zkratem. Je-li hodnota průtoku zkratem zadána, musí být naopak pro teplotu vratu za zkratem zadáno „!CALC“)  Čerpadlo o Název počátečního uzlu o Název koncového uzlu o Přívod: Rozdíl tlaků (Rozdíl tlaků mezi výtlakem a sáním čerpadla v přívodu: V přívodu probíhá čerpání vždy od počátečního ke koncovému uzlu. Pokud voda proudí opačně, čerpadlo nepracuje. Zadáme-li rozdíl tlaků nulový, čerpadlo nepracuje. Čerpadlo je vyřazeno, pokud je umístěno v okruhu. Je-li uvedeno „!JOIN“, zařízení v přívodu neexistuje a počáteční a koncový uzel jsou spojeny, bez tepelných či hydraulických ztrát. (Pak také musí být i v ostatních parametrech přívodu uvedeno „!JOIN“.)) o Vrat: Rozdíl tlaků (Rozdíl tlaků mezi výtlakem a sáním čerpadla ve vratu: Ve vratném potrubí probíhá čerpání vždy od koncového uzlu k počátečnímu. Pokud voda proudí opačně, čerpadlo nepracuje. Zadáme-li rozdíl tlaků nulový, čerpadlo nepracuje. Čerpadlo je vyřazeno, pokud je umístěno v okruhu. Je-li uvedeno „!JOIN“, zařízení ve vratu neexistuje a počáteční a koncový uzel jsou spojeny, bez tepelných či hydraulických ztrát. (Pak také musí být i v ostatních parametrech vratu uvedeno „!JOIN“.))  Uzavírací armatura vodní o Název počátečního uzlu o Název koncového uzlu o Přívod: Stav armatury (Stav armatury může být otevřeno (1) nebo zavřeno (0). Je-li uvedeno „!JOIN“, zařízení v přívodu neexistuje a počáteční a koncový uzel jsou spojeny, bez tepelných či hydraulických ztrát. (Pak také musí být i v ostatních parametrech přívodu uvedeno „!JOIN“.)) o Vrat: Stav armatury (Stav armatury může být otevřeno (1) nebo zavřeno (0). Je-li uvedeno „!JOIN“, zařízení ve vratu neexistuje a počáteční a koncový uzel jsou spojeny, bez tepelných či hydraulických ztrát. (Pak také musí být i v ostatních parametrech vratu uvedeno „!JOIN“.))  Uzavírací armatura parní o Název počátečního uzlu o Název koncového uzlu o Přívod: Stav armatury (Stav armatury může být otevřeno (1) nebo zavřeno (0). Je-li uvedeno „!JOIN“, zařízení v přívodu neexistuje a počáteční a koncový uzel jsou spojeny, bez strana 12


tepelných či hydraulických ztrát. (Pak také musí být i v ostatních parametrech přívodu uvedeno „!JOIN“.)) o Vrat: Stav armatury (Stav armatury může být otevřeno (1) nebo zavřeno (0). Je-li uvedeno „!JOIN“, zařízení ve vratu neexistuje a počáteční a koncový uzel jsou spojeny, bez tepelných či hydraulických ztrát. (Pak také musí být i v ostatních parametrech vratu uvedeno „!JOIN“.))  Škrtící armatura vodní o Název počátečního uzlu o Název koncového uzlu o Přívod: Regulovaný přetlak (Hodnota, na níž bude tlak regulován: V přívodu se škrtící armatura chová jako redukce (tj. reguluje přetlak za armaturou - v koncovém uzlu). Pokud médium proudí opačně, zařízení neškrtí. Zadání vyššího přetlaku, než jaký je v počátečním uzlu, způsobí, že zařízení neškrtí. Škrcení je vyřazeno, pokud je armatura umístěna v okruhu nebo pokud (v parní síti) směřuje koncovým uzlem k referenčnímu uzlu nebo (ve vodní síti) pokud směřuje koncovým uzlem k uzlu se zadaným poměrem nad HKST či k uzlu se zadaným rozdílem tlaků. Je-li uvedeno „!JOIN“, zařízení v přívodu neexistuje a počáteční a koncový uzel jsou spojeny, bez tepelných či hydraulických ztrát. (Pak také musí být i v ostatních parametrech přívodu uvedeno „!JOIN“.)) o Vrat: Regulovaný přetlak (Hodnota, na níž bude přetlak regulován: Ve vratu se škrtící armatura chová jako přepouštění (tj. reguluje tlak před armaturou - v koncovém uzlu). Pokud médium proudí opačně, zařízení neškrtí. Zadání nižšího přetlaku, než jaký je v počátečním uzlu, způsobí, že zařízení neškrtí. Škrcení je vyřazeno, pokud je armatura umístěna v okruhu nebo pokud (v parní síti) směřuje koncovým uzlem k referenčnímu uzlu nebo (ve vodní síti) pokud směřuje koncovým uzlem k uzlu se zadaným poměrem nad HKST či k uzlu se zadaným rozdílem tlaků. Je-li uvedeno „!JOIN“, zařízení ve vratu neexistuje a počáteční a koncový uzel jsou spojeny, bez tepelných či hydraulických ztrát. (Pak také musí být i v ostatních parametrech vratu uvedeno „!JOIN“.))  Škrtící armatura parní o Název počátečního uzlu o Název koncového uzlu o Přívod: Regulovaný přetlak (Hodnota, na níž bude tlak regulován: V přívodu se škrtící armatura chová jako redukce (tj. reguluje přetlak za armaturou - v koncovém uzlu). Pokud médium proudí opačně, zařízení neškrtí. Zadání vyššího přetlaku, než jaký je v počátečním uzlu, způsobí, že zařízení neškrtí. Škrcení je vyřazeno, pokud je armatura umístěna v okruhu nebo pokud (v parní síti) směřuje koncovým uzlem k referenčnímu uzlu nebo (ve vodní síti) pokud směřuje koncovým uzlem k uzlu se zadaným poměrem nad HKST či k uzlu se zadaným rozdílem tlaků. Je-li uvedeno „!JOIN“, zařízení v přívodu neexistuje a počáteční a koncový uzel jsou spojeny, bez tepelných či hydraulických ztrát. (Pak také musí být i v ostatních parametrech přívodu uvedeno „!JOIN“.)) o Vrat: Regulovaný přetlak (Hodnota, na níž bude přetlak regulován: Ve vratu se škrtící armatura chová jako přepouštění (tj. reguluje tlak před armaturou - v koncovém uzlu). Pokud médium proudí opačně, zařízení neškrtí. Zadání nižšího přetlaku, než jaký je v počátečním uzlu, způsobí, že zařízení neškrtí. Škrcení je vyřazeno, pokud je armatura strana 13










 

umístěna v okruhu nebo pokud (v parní síti) směřuje koncovým uzlem k referenčnímu uzlu nebo (ve vodní síti) pokud směřuje koncovým uzlem k uzlu se zadaným poměrem nad HKST či k uzlu se zadaným rozdílem tlaků. Je-li uvedeno „!JOIN“, zařízení ve vratu neexistuje a počáteční a koncový uzel jsou spojeny, bez tepelných či hydraulických ztrát. (Pak také musí být i v ostatních parametrech vratu uvedeno „!JOIN“.)) Potrubní úsek vodní o Název počátečního uzlu o Název koncového uzlu o Přívod: Katalogové označení (Název typu potrubí – označení položky v katalogu potrubí: Pokud je „!NONE“, nelze v žádných parametrech přívodu používat řetězec „!CAT“ (resp. „!GLB“ u teploty okolí).) o Přívod: Délka o Vrat: Katalogové označení (Název typu potrubí – označení položky v katalogu potrubí: Pokud je „!NONE“, nelze v žádných parametrech vratu používat řetězec „!CAT“.) o Vrat: Délka Potrubní úsek parní o Název počátečního uzlu o Název koncového uzlu o Přívod: Katalogové označení (Název typu potrubí – označení položky v katalogu potrubí: Pokud je „!NONE“, nelze v žádných parametrech přívodu používat řetězec „!CAT“ (resp. „!GLB“ u teploty okolí).) o Přívod: Délka o Vrat: Katalogové označení (Název typu potrubí – označení položky v katalogu potrubí: Pokud je „!NONE“, nelze v žádných parametrech vratu používat řetězec „!CAT“.) o Vrat: Délka Kategorie spotřeby vodní o Koeficient příkonu (Násobný koeficient velikosti spotřeby) o Korekce teploty vratu (Aditivní korekce teploty vratu) o Neuronový model spotřeby (Název neuronového modelu spotřeby: Pokud není zadáno „!NONE“, je příkon spotřebiče dán produktem výstupu výkonové neuronové sítě, koeficientu příkonu kategorie a normovaného koeficientu výkonu konkrétního spotřebiče. Pak také jak požadovaný rozdíl teplot, tak teplota vratu spotřebičů používajících neuronový model musejí být zadány „!CALC“.) Kategorie spotřeby parní o Koeficient příkonu (Násobný koeficient velikosti spotřeby) o Korekce entalpie vratu (Aditivní korekce entalpie vratu) o Neuronový model spotřeby (Název neuronového modelu spotřeby: Pokud není zadáno „!NONE“, je příkon spotřebiče dán produktem výstupu výkonové neuronové sítě, koeficientu příkonu kategorie a normovaného koeficientu výkonu konkrétního spotřebiče. Pak také jak požadovaný rozdíl teplot tak teplota vratu spotřebičů používajících neuronový model musejí být zadány „!CALC“.) Neuronový model spotřeby Položka katalogu potrubí strana 14


o o o o

    

Vnitřní průměr potrubí Drsnost potrubí Dzet (Součinitel pro výpočet součtu místních odporů SUMA DZETA z délky úseku) Typ teploty okolí (Typ vztažné teploty okolí pro výpočet tepelných ztrát: zem (0) nebo vzduch (1)) o Přívod: Tepelný odpor (Tepelný odpor přívodu mezi teplonosnou látkou a okolím) o Vrat: Tepelný odpor (Tepelný odpor vratu mezi teplonosnou látkou a okolím) Položka katalogu čerpadel HNS cesta Flexibilní cesta Výčtová cesta Filtr výstupů

2.1.3 Možnosti zadávání vstupních parametrů Jednotlivé vstupní parametry je možné vyplnit buď hodnotou (číslo, řetězec, časová řada čísel) nebo u některých položek náhradním řetězcem. U všech řetězcových hodnot jsou rozlišována malá a velká písmena. Náhradní řetězce mohou nabývat následujících hodnot: !GLB

Použije se odpovídající hodnota z objektu sítě

!CAT

Použije se odpovídající hodnota z katalogu potrubí

!CALC

Hodnota je výsledkem výpočtu nebo je doplněna automaticky (např. měrná tepelná kapacita vody).

!NONE

Hodnota není zadána – např. u potrubí či čerpadel bez katalogového typu.

!JOIN

Dané zařízení není v přívodu či vratu přítomno, počáteční a koncový uzel jsou přímo spojeny (bez hydraulických či tepelných ztrát).

Nápovědu, jaké hodnoty může buňka nést, lze společně s podrobnějším popisem významu vstupního parametru nalézt v bublině, která se zobrazí při najetí myši nad buňku s názvem parametru (jak v Excel, tak v oknech MOPED).

2.1.4 Zadávání časových řad V případě dynamického výpočtu1 je u těch parametrů, které v komentáři obsahují nápovědu „řada“, např. „(reálné číslo / řada)“, možné zadávat časovou řadu. Časová řada se celá zadává ve zvláštním

1

Nepovažuje se za chybu ani zadání časové řady ve „stacionárním výpočtu bez určení času“ – čas výpočtu je pak považován za „kdesi daleko v minulosti“ a jako hodnota se bere jako první hodnota řady.

strana 15


formátu do buňky příslušného parametru. Formát je dvojího typu, buď jako nepravidelná řada (soubor lomových bodů): { <čas> , ; <čas> , ... } nebo jako pravidelná řada (rastr s pevným krokem): { @ ; <čas_počátku> ; , ... } (pro oba typy formátu platí: všechny mezery jsou nepovinné a můžou být vždy i vícenásobné). Oba typy lze použít pro vstupy. Výstupy budou vždy v druhém uvedeném typu formátu. Druhý typ je detekován znakem „@“ hned za „{“ (resp. po případných mezerách). Všude, kde je v dynamickém výpočtu očekávána řada, lze vždy zadat i prosté číslo – konstantní průběh pro celý interval výpočtu. Není chybou zadání průběhu časově mimo zadaný interval výpočtu: krajní hodnoty jsou extrapolovány neomezeně do minulosti a budoucnosti. Jednotlivé položky formátu časové řady jsou následující:

celé číslo značící délku kroku ve formátu [m]m[:[s]s] (obsah hranatých závorek je nepovinný; [m]m minuty a [s]s sekundy)

<čas>

časový okamžik hodnoty – datum a čas ve formátu YYYY-[M]M-[D]D [h]h:[m]m[:[s]s] (obsah hranatých závorek je nepovinný; YYYY je rok, [M]M měsíc, [D]D den, [h]h hodiny, [m]m minuty a [s]s sekundy)

<čas_počátku>

časový okamžik první hodnoty řady – datum a čas ve formátu YYYY-[M]M-[D]D [h]h:[m]m[:[s]s] (obsah hranatých závorek je nepovinný; YYYY je rok, [M]M měsíc, [D]D den, [h]h hodiny, [m]m minuty a [s]s sekundy)

hodnota v daném časovém okamžiku – reálné číslo (desetinným oddělovačem je tečka!)

buď prostá hodnota v daném časovém okamžiku: nebo hodnota s pravou limitou: ] <pravá_limita> nebo hodnota s levou limitou: [

2.1.5 Definice výpočetního intervalu Výpočetní interval určuje, zda bude výpočet stacionární či dynamický a zadává případné časové okamžiky výpočtu. Nastavuje v objektu „síť“ parametrem „Časové určení výpočtu“. strana 16


Existují 4 možnosti zadání:  stacionární výpočet bez specifikace konkrétního časového okamžiku: !NONE (nevýhodou tohoto zadání je nemožnost použít neuronové modely spotřeby)  stacionární výpočet se specifikací konkrétního časového okamžiku: _ YYYY-[M]M-[D]D [h]h:[m]m[:[s]s]  Okamžik intervalu: YYYY je rok, [M]M měsíc, [D]D den, [h]h hodiny, [m]m minuty a [s]s jsou sekundy (údaje se využijí pouze při použití neuronového modelu a to na určení denního času a dne v týdnu);  dynamický výpočet zadaný pomocí počátku a konce časového intervalu: YYYY-[M]M-[D]D [h]h:[m]m[:[s]s] .. YYYY-[M]M-[D]D [h]h:[m]m[:[s]s] @ [m]m[:[s]s] / A      

první časový údaj značí počátek intervalu a druhý jeho konec; YYYY je rok, [M]M měsíc, [D]D den, [h]h hodiny, [m]m minuty a [s]s jsou sekundy; údaj za znakem „@“ je délka kroku; údaj za znakem „/“ je celočíselný poměr délky kroku oproti délce podkroku; obsah hranatých závorek je nepovinný; mezery kolem řetězce „..“ a kolem znaků „@“ a „/“ jsou nepovinné a mohou být vícenásobné;  mezera mezi datem a časem může být vícenásobná;  dynamický výpočet zadaný pomocí počátku a délky časového intervalu: YYYY-[M]M-[D]D [h]h:[m]m[:[s]s] # N @ [m]m[:[s]s] / A        

první časový údaj značí počátek intervalu; YYYY je rok, [M]M měsíc, [D]D den, [h]h hodiny, [m]m minuty a [s]s jsou sekundy; údaj za znakem „#“ značí počet kroků od zadaného počátku intervalu; údaj za znakem „@“ je délka kroku; údaj za znakem „/“ je celočíselný poměr délky kroku oproti délce podkroku; obsah hranatých závorek je nepovinný; mezery kolem znaku „#“ a kolem znaků „@“ a „/“ jsou nepovinné a mohou být vícenásobné; mezera mezi datem a časem může být vícenásobná;

Délka kroku představuje viditelný interval mezi spočtenými hodnotami. Délka podkroku se vztahuje k výpočtu: Pro jeden viditelný krok výsledků může být spočteno několik výpočetních podkroků z důvodu vyšší přesnosti dynamických jevů v síti. strana 17


Dynamický výpočet nelze kombinovat z žádnou rozšířenou úlohou (tj. zadání !CALC v parametru „Výkon referenčního zdroje“ či „Teplota vratu v referenčním zdroji“). V Případě dynamického výpočtu se vybrané méně důležité výstupní parametry modelu nepočítají! Pozn.: Dynamický interval o délce 1 kroku se oproti stacionárnímu výpočtu s určením specifického času liší tím, že výsledné hodnoty jsou ve formátu řady, byť jednoprvkové.

2.2 Grafické rozhraní MOPED MOPED je komplexní grafická nadstavba umožňující editaci vstupních dat a prohlížení výsledků ve skutečném geografickém zobrazení počítané tepelné sítě. Obr. 1 – Snímek obrazovky hlavního okna aplikace

MOPED umožňuje o

editaci všech vstupních dat MOP včetně topologie, hydraulických poměrů, průběhu dynamických parametrů, katalogu potrubí, katalogu čerpadel, apod.,

o

vytváření nových větví, uzlů, zdrojů, čerpadel a dalších objektů MOP,

o

editaci cest pro tlakový diagram,

o

výpočet modelu,

o

zobrazení tlakového diagramu v m n. m. i v kPa,

o

zobrazení diagramu čerpadla s charakteristikami a pracovním bodem,

o

komfortní zobrazování výsledků výpočtu s využitím geografického zobrazení počítaného modelu včetně možnosti zobrazení podkladových map, grafy dynamických parametrů, strana 18


vyznačení hodnot parametrů v mapě v barevné škále (rozložení rychlostí, teplot, tlaků a dalších parametrů), vyznačení cest v mapě. Máme-li k dispozici geografickou informaci o prostorovém vedení jednotlivých potrubních úseků, pak MOPED tuto informaci využije. Pokud není informace o prostorovém vedení jednotlivých potrubních úseků k dispozici (a není tedy u žádného úseku vyplněna), aplikaci MOPED je přesto možné používat – v tomto případě si grafickou informaci „vymyslí“ (s ohledem na topologii danou počátečními a koncovými uzly větví) a tuto je dále možno upravovat.

2.2.1 Základ práce s MOPED Spuštění rozhraní MOPED se provádí z Tabulkového front-endu (v prostředí tabulkového procesoru), pomocí nabídky MOP, volbou Otevřít v MOP. Pro editační účely vyžaduje pouze vstupní data MOP. Pokud nejsou k dispozici v okamžiku spuštění (tj. vstupní listy jsou prázdné nebo neexistují nebo jsou vadné), nemůže MOP nabídnout editaci modelu a následné uložení (bude však fungovat alespoň v režimu zobrazování výsledkového modelu). Pokud ale listy budou existovat a budou korektní s minimálně vyplněným řádkem sítě (vodní či parní), bude MOPED v návrhových oknech nabízet prázdnou síť s možností zadávat globální parametry a vytvářet nové objekty modelu a ty pak dále normálně editovat, mazat, atd. a výsledek umožní uložit. Pro zobrazovací účely vyžaduje korektně vyplněné výstupní listy. Pokud tato data nejsou k dispozici v okamžiku spuštění – tj. všechny potřebné soubory budou prázdné, bude MOPED v zobrazovacím okně ukazovat prázdnou síť bez možnosti dalších smysluplných zobrazovacích funkcí. Ukončit MOPED je možné dvěma způsoby. Volbou z nabídky Soubor → Uložit a zavřít dojde k aktualizaci modelu v sešitu tabulkového procesoru podle aktuálního stavu modelu v MOPEDu. Druhým způsobem je standardní ukončení aplikace (případně volbou z nabídky Soubor → Zavřít), při kterém jsou zachována původní data v sešitu tabulkového procesoru, případně – pokud byl model v MOPEDu uložen volbou z nabídky Soubor → Uložit – stav modelu v okamžiku posledního uložení. Pro vytvoření nového modelu lze použít šablony Example.cs\Prazdny.voda.xls nebo Example.cs\Prazdny.-para.xls, které jsou součástí dodávky. Tuto šablonu je možné zkopírovat a z kopie spustit MOPED. V něm pak lze vytvořit model přidáváním jednotlivých prvků standardními prostředky a např. s využitím podkladové mapy.

2.2.2 Načtení a analýza geografických dat Na začátku svého běhu aplikace načte příslušná data převzatá z tabulkového procesoru a provede jejich základní analýzu. Analýza spočívá v určení souhlasnosti / nesouhlasnosti geometrie s definovanou orientací větve pomocí počátečního a koncového uzlu a v případné opravě souřadnic na sebe napojených krajů úseků a bodových objektů. Analýza umí zpracovat 3 různé situace: strana 19


1. Jsou vyplněny geometrie všech úseků a pozice všech bodových objektů, tj. uzlů (včetně zdrojů, spotřebičů, atd.), čerpadel a armatur. V tom případě se pouze zkoumá souhlasnost geometrické orientace větve a jsou provedeny případné korekce na sebe napojených krajů úseků a bodových objektů. Pokud jsou souřadnice v naprosté shodě a orientace geometrie všech úseků je souhlasná (což je např. vždy, pokud nebyl model uložen MOPED následně měněn), provede se analýza rychleji. 2. Pokud jsou vyplněny geometrie všech úseků ale žádné pozice uzlů, čerpadel a armatur, určuje analýza nejen souhlasnost orientace úseků, ale i pozice bodových objektů (uzlů, čerpadel a armatur). Nastavení parametrů ovlivňujících průběh analýzy je možné provést z nabídky Nastavení → Konfigurace. Tam je také stručně popsán význam jednotlivých parametrů. V případě, že orientace větví a všechny souřadnice jsou v naprosté vzájemné shodě, provádí se zjednodušená analýza (v podstatě jen doplnění souřadnic pro uzly, čerpadla a armatury) a výše uvedené nastavení dialogu se neuplatní. 3. Pokud nejsou vyplněny geometrie žádných úseků ani pozice žádných bodových objektů, analýza si veškeré geografické informace „vymyslí“. Analýza neumí zpracovat situace, pokud jsou vyplněny jen geometrie některých úseků nebo pozice jen některých bodových objektů, nebo pokud jsou určeny pozice bodových objektů ale již ne geometrie úseků. Nadále, tj. během interaktivní práce s MOPEDem jsou všechny geometrie úseku (instrukce LINESTRING) interpretovány vždy jako sled vrcholů od počátečního uzlu ke koncovému.

2.2.3 Objekty, které lze zobrazovat a editovat MOPED je určen především ke grafické reprezentaci modelu. Dokáže zobrazovat (a editovat) následující typy objektů:  potrubní úseky – potrubní úsek je reprezentován po-částech-lineární čarou; úsek spojuje vždy dva uzly  uzly (obecně) – pojmem obecný uzel se označuje buď běžný uzel, spotřebič, zdroj, zkrat nebo směšovací uzel; uzel je v mapě reprezentován bodem  běžné uzly – uzel, ve kterém chceme pouze sledovat výstupní parametry; může také sloužit k oddělení dvou úseků různých parametrů  zdroje – parní nebo vodní zdroje  spotřebiče – parní nebo vodní spotřebiče, případně parní sítě i odvaděče kondenzátu  zkraty – uzly se zkratováním přívodní vody do vratu  směšovací uzly – uzly se směšováním vratné vody do přívodu strana 20


 čerpadla, škrtící armatury, uzavírací armatury – čerpadla a armatury jsou objekty spojující dva uzly (podobně jako potrubní úseky), jsou ale v MOPEDu reprezentovány jako bodové objekty (kvůli jejich zanedbatelné délce) Zvláštností zobrazení uzavíracích armatur je barevné odlišení stavu armatury: červená (stále zavřeno, 0), zelená (stále otevřeno, 1), světle šedá (!JOIN), tmavě šedá (jiná hodnota nebo nevyplněno), modrofialová (v případě dynamického výpočtu: časová řada obsahující nestejné stavy)  parametry sítě – globální parametry sítě a modelu jsou v MOPEDu reprezentovány jako parametry „objektu síť“ Další typy objektů nemají grafickou reprezentaci a jsou zpřístupněny okny „Návrhová tabulka“ a „Výsledková tabulka“.

2.2.4 Vlastnosti mapového zobrazení Tyto funkce jsou přístupné jak v editačním okně „Návrhová mapa“, tak zobrazení „Výsledkové mapy“: 

Vykreslení sítě včetně všech objektů (běžný uzel, zdroj, spotřebič, zkrat, směšovací uzel, úsek potrubí, čerpadlo, uzavírací armatura, škrtící armatura) – Úseky potrubí jsou vykresleny počástech-lineární čárou, tj. budou zachovány vrcholy uvnitř úseků. Ostatní objekty (bodové) jsou vykresleny malým kroužkem (běžné uzly) nebo vhodným symbolem v pozici jejich umístění.



Všechny tyto vykreslené objekty jsou senzitivní na klepnutí myší. Po klepnutí (v základním režimu) jsou tyto objekty zobrazené jako „označené“ a jejich parametry jsou zobrazeny v bočním panelu okna. Aby byly zpřístupněny i objekty, které leží velmi blízko sebe (v aktuálním nastavení přiblížení) nebo přímo „na sobě“, je možné mezi objekty překrytými v jednom místě přepínat klepnutím pravým tlačítkem myši.



V bočním panelu jsou zobrazovány parametry aktuálně vybraného objektu. V návrhové mapě jsou zobrazeny vstupní parametry a ve výsledkové mapě jsou zobrazeny jak vstupní, tak výstupní parametry. Pokud není vybrán žádný objekt, boční panel zobrazuje globální parametry sítě. U dynamických parametrů lze klepnutím na symbol křivky zobrazit časový průběh v grafu. V případě parametru globálního intervalu dynamického výpočtu lze klepnutím na symbol hodin zobrazit dialog nastavení intervalu.



Zobrazená mapa umožňuje posun všemi čtyřmi směry a také umí měnit úroveň přiblížení (funkce „přiblížit k bodu“, „oddálit od bodu“, „přiblížit / oddálit tažením“, „přiblížit oknem“ a „zobrazit celý rozsah“).



Jak v návrhové tak ve výsledkové mapě je přístupná funkce vyhledávání objektů podle jejich názvu (či jiného parametru). Hledání probíhá na základě zadání ve vyhledávacím dialogu: Uživatel zadá třídu objektu a identifikátor objektu (název), případně hodnotu jiného parametru (a zvolí také název tohoto parametru). strana 21




Lze zobrazovat podkladové mapy na pozadí sítě.

2.2.5 Podkladové mapy Okna mapového zobrazení umožňují zobrazit volitelně jednu či více podkladových map. Volby, které podkladové mapy v daném okně zobrazit a v jakém pořadí kreslení přes sebe, lze nastavit v dialogu Zobrazení → Podkladové mapy → Viditelnost a pořadí. Pokud požadujeme zobrazovat v nově otevřených oknech implicitně nějaké podkladové mapy, abychom je nemuseli vybírat opakovaně v každém okně, lze použít nastavení v dialogu Zobrazení → Podkladové mapy → Implicitní viditelnost a pořadí. V tomto dialogu je také možné provést nastavení podkladových map pro všechna aktuálně otevřená mapová okna zároveň. Podkladová mapa může být typu „offline“ nebo WMS. Offline podkladová mapa je definována jako odkaz na soubor s obrázkem v souborovém systému se zapamatovaným umístěním v souřadném systému (včetně případného pootočení). Definice offline podkladových map se udržuje s modelem MOP, nicméně společně pro všechna mapová okna. Správa offline podkladových map se provádí v zobrazovacím režimu „Úprava zobrazení podkladových map“: K dispozici jsou volby „Přidat podkladovou mapu“, „Odebrat podkladovou mapu“, „Vyhledat podkladovou mapu“ a „Transformace podkladové mapy“. Transformace offline podkladových map umožňuje pro podkladový obrázek měnit pozici, velikost a pootočení vzhledem k mapě sítě pomocí řídicích bodů. Dle požadavku na kombinaci transformací (posun, velikost, rotace) vyžaduje zadání určitého počtu řídicích bodů. Řídicí body jsou buď zdrojové (určují pozici v podkladovém obrázku) nebo cílové (určují pozici v mapě sítě). Dialog transformace zobrazuje nápovědu pro zadání potřebných informací pro danou transformaci. Definice WMS podkladové mapy je nastavení online mapy standardu WMS 1.3.0, jak je definován konsorciem OGC. Tyto mapy (pokud jsou nastaveny jako viditelné) se pro dané mapové okno stahují z internetu při každé změně výřezu či velikosti okna. Definice se uchovávají pro všechny modely společně a lze je spravovat z dialogu vyvolaného z nabídky Nastavení → Služby WMS: 

Jednotlivé definice lze vytvářet, mazat, editovat a klonovat, podobně jako profily importu v modulu GISimport. Stejně tak jim lze nastavit úroveň „uživatelskou“ (definice je uložena ve složkách nastavení konkrétního uživatele), „globální“ (definice nastavená administrátorem pro sdílení více uživateli – profil je značen ikonou žlutého zámku) nebo „implicitní“ (nastavená dodavatelem systému MOP – profil je značen ikonou červeného zámku).



Při zadávání definice je třeba nejprve vyplnit základ URL adresy WMS služby. Po té je možné stiskem tlačítka Zjistit schopnosti WMS služby provést dotaz na WMS server a dle jeho odpovědi zvolit konfiguraci mapy: vybrat jednotlivé nabízené vrstvy a jejich styly, formáty, apod. Pro obrázek mapy poskytovaný serverem lze ještě bez ohledu strana 22


na formát aplikovat koeficient neprůhlednosti, kterým lze příliš výrazné barevné či kontrastní obrázky ztlumit (koeficient < 1) pro větší přehlednost zobrazení sítě. WMS podkladové mapy jsou závislé na správném nastavení vstupního parametru sítě Souřadný systém. Pokud je zadaný souřadný systém nekompatibilní s danou definovanou WMS podkladovou mapou (nebo není vyplněn vůbec či chybně), tak se název dotyčné mapy v dialozích Viditelnost a pořadí a Implicitní viditelnost a pořadí zobrazuje červeně. Poznámka: Některé WMS podkladové mapy neukazují obsah ve všech úrovních přiblížení. Některé poskytují obrázek jen při vysokém nebo naopak nízkém přiblížení. Toto není vada aplikace, ale vlastnost některých veřejných WMS služeb.

2.2.6 Rozložení oken aplikace MOPED nabízí své funkce ve specializovaných oknech. Tato okna je možno otevřít z nabídky Zobrazit. V této nabídce jsou všechny položky odpovídající specializovaným oknům MOPED:  návrhová mapa,  návrhová tabulka,  editace cest pro tlakový diagram,  návrh průběhu dynamických vstupních parametrů vč. grafického náhledu,  výsledková mapa,  výsledková tabulka,  výsledný průběh dynamických vstupních i výstupních parametrů vč. grafu,  zobrazení tlakového diagramu ve dvou variantách – v m n. m. a v kPa,  zobrazení diagramu čerpadla (charakteristik a pracovního bodu). Uživatel může mít otevřeno více oken kteréhokoliv typu. Návrhová okna mezi sebou automaticky synchronizují změny modelu. Pozice, velikost a nastavení otevřených oken v MOPEDu se ukládá společně s modelem. Některé typy oken přidávají do hlavní aplikační nabídky Zobrazení, které obsahuje volby upřesňující zobrazení daného okna. Návrhová okna přidávají navíc nabídku Editace, které shrnuje všechny povolené editační operace, které toto okno nabízí. Některé typy oken také rozšiřují nabídku panelu nástrojů hlavního okna aplikace. Tlačítka panelu nástrojů jsou vždy podmnožinou položek nabídky. Proto se v následujícím popisu omezujeme pouze na položky nabídky.

2.2.7 Dialog: Volba počítaných výstupních parametrů Pokud není vhodné počítat všechny výstupní parametry, které MOP spočítat umí (což je vhodné např. při snaze minimalizovat paměťové nároky při dynamickém výpočtu), lze pomocí dialogu vyvolaného z nabídky Otevřít položkou Filtry výstupů určit, které výstupní parametry počítat a které ne. strana 23


Obr. 2 – Snímek obrazovky okna editace filtrů výstupních veličin

Nastavení se provádí jednotlivě pro každý typ objektů sítě (včetně uzlů cest tlakového diagramu). Pro časté použití jsou předdefinovány dva základní filtry (pro všechny typy objektů): „none“ (nepočítá se žádný výstupní parametr) a „all“ (počítají se všechny výstupní parametry).

strana 24


Obr. 3 – Snímek obrazovky okna editace vybraného filtru výstupních veličin

Zvolený filtr ze seznamu lze upravit a smazat, nebo lze vytvořit pro daný typ objektu filtr nový. Pro daný filtr se zaškrtávají názvy těch výstupních parametrů, které se mají počítat. Volba, zda se uchovává seznam zaškrtnutých či nezaškrtnutých parametrů, má význam jen pro případ, že v budoucnu přibude nový výstupní parametr. Po potvrzení hlavního dialogu tlačítkem Potvrdit je nastavení filtru uloženo, avšak pro projevení změn je ještě třeba provést výpočet modelu. V sešitu jsou filtry uloženy v listech „FC“, „VC“ a „HC“ (které jsou ale neviditelné a není je doporučováno upravovat ručně). Dále pak lze všem konkrétním objektům v síti (včetně celé sítě samotné) přiřadit jeden z takto definovaných filtrů pro daný typ objektu.

2.2.8 Dialog: Volba cest pro tlakový diagram Cesty pro tlakový diagram lze zadat z dialogu vyvolaného z nabídky Otevřít položkou Cesty pro tlakový diagram. Dialog nabízí úpravu stávajících cest nebo jejich smazání a také vytvoření nové cesty – jednoho ze 3 typů. strana 25


Obr. 4 – Snímek obrazovky okna editace cest pro tlakový diagram

Každá cesta umožňuje zadávat svůj název a směr vykreslení v tlakovém diagramu: vpravo nebo vlevo. Prvním typem je výčtová cesta – její výhodou je možnost zadat nestandardní počátek viditelnosti a též je možné měnit směr vykreslení cesty vpravo / vlevo i v průběhu cesty. Tyto výhody jsou vykompenzovány nutností měnit cestu kdykoliv dojde ke změně topologie části sítě, přes kterou cesta prochází. Zadání začíná volbou počátečního uzlu a dále pokračuje postupným přidáváním na sebe navazujících větví. Výběrem uzlu v políčku Počátek viditelnosti lze zvolit uzel, od kterého se bude cesta v tlakovém diagramu vykreslovat (pokud nezadáme jinak, tak je to první uzel cesty). Tím lze dosáhnout správné volby staničení počátku vykreslované cesty s ohledem na okruhy, protože počáteční uzel cesty má staničení nastavené vždy podle vzdálenosti od referenčního uzlu. Toto nastavení je užitečné např. pro vykreslování odboček sítě za okruhem. Dále lze pro cestu zvolit jeden z předdefinovaných filtrů výstupů. Takto definovanou cestu lze buď uložit, nebo ji převést na tzv. flexibilní cestu (viz níže).

strana 26


Obr. 5 – Snímek obrazovky okna editace výčtové cesty

Dalším typem cesty je flexibilní cesta. Nemá zmíněné výhody výčtové cesty ale ani její nevýhodu – je odolná proti změně topologie – je zadávaná počátečním a koncovým uzlem. Protože v zokruhovaných sítích může existovat více cest mezi dvěma uzly, nabízí možnost definovat seznam zakázaných (neprůchozích) větví. Zadání začíná volbou jak počátečního tak koncového uzlu a následně je doplněno volbou zakázaných větví. Dále lze pro cestu zvolit jeden z předdefinovaných filtrů výstupů. Flexibilní cestu lze také převést na cestu výčtovou, pokud je počáteční uzel i počátkem viditelnosti a cesta nikdy nemění svůj směr.

strana 27


Obr. 6 – Snímek obrazovky okna editace flexibilní cesty

Třetím typem je HNS cesta. Tato cesta je automaticky definována jako vedoucí od ref. zdroje k hydraulicky nejvzdálenějšímu spotřebiči. U tohoto typu cesty lze volit pouze směr vykreslení a jeden z předdefinovaných filtrů výstupů. Obr. 7 – Snímek obrazovky okna editace cesty k hydraulicky nejvzdálenějšímu spotřebiči

Po potvrzení editačních dialogů tlačítkem Potvrdit jsou nové definice cest uloženy. Pro projevení změn ve výsledných datech (např. v tlakovém diagramu) je ještě třeba provést výpočet modelu. V sešitu jsou cesty uloženy v listu „FV“ (který je neviditelný a není ho doporučeno upravovat ručně).

strana 28


2.2.9 Dialog: Zadání neuronového modelu spotřeby Pokud potřebujeme modelovat dynamické chování soustavy, můžeme volitelně využít neuronové modely spotřeby. To vyžaduje mít k dispozici naučené neuronové sítě výkonu a teploty vratu (resp. entalpie kondenzátu v případě parní sítě) spotřebitelských oblastí. Ty nejsou součástí dodávky MOP, ale lze si objednat dodání naučených neuronových modelů samostatně. 2.2.9.1

Zadání spotřeby s využitím neuronového modelu

V případě využití neuronového modelu, je třeba použít buď dynamický výpočet nebo režim stacionárního výpočtu s určením časového okamžiku výpočtu, jelikož vstupy neuronového modelu zahrnují specifikace denního času a dnu v týdnu (viz dále). Obr. 8 – Snímek obrazovky okna editace neuronových modelů spotřeby

Pro zadání konkrétního neuronového modelu se pro danou kategorii (např. reprezentující určitou oblast spotřeby) vloží pomocí dialogu vyvolaného z nabídky Neuronové modely spotřeby sada neuronových sítí (zvlášť pro výkon a teplotu vratu (resp. entalpie kondenzátu), zvlášť pro topnou a letní sezónu) a odkazem z objektu kategorie spotřeby se tento neuronový model naváže na konkrétní kategorii. Jednotlivým spotřebičům s přiřazenou takovouto kategorií se pak odlišně počítá výkon a teplota vratu (resp. entalpie kondenzátu): 

Co se týče chování teploty vratu / entalpie kondenzátu, musí být u spotřebiče zadáno „!CALC“ jak u požadovaného rozdílu teplot (resp. rozdílu entalpií), tak u požadované teploty vratu (resp. entalpie kondenzátu). Teplota je plně řízena výstupem z neuronové sítě teploty vratu / entalpie kondenzátu (s případnou aditivní korekcí zadávanou v rámci kategorie spotřeby).



Výkonově je hodnota v MW zadávaná u spotřebičů považována za koeficient výsledku neuronové sítě výkonu a tento koeficient je normován na sumu těchto koeficientů všech spotřebičů příslušejících ke stejné kategorii. Jinak řečeno výkonově neuronová síť udává strana 29


celkový okamžitý výkon všech spotřebičů dané kategorie dohromady a tento výkon je rozdělen na jednotlivé spotřebiče v poměru jejich příkonů zadávaných v MW. Dále se, stejně jako v případě bez použití neuronového modelu, použije další korekční multiplikativní koeficient zadávaný v rámci kategorie spotřeby. Správa neuronových modelů je (vedle jejich přiřazení ke kategoriím v listu „KSp“ ve sloupci „Neuronový model spotřeby“) ovládána z dialogu otevíraného pomocí položky nabídky Neuronový model spotřeby (v nabídce MOP v Excelu i v nabídce Otevřít v MOPED): Z tohoto dialogu lze přidávat, mazat a upravovat jednotlivé neuronové modely. Úprava a nové zadání probíhají v dialogu, kde pro daný neuronový model lze ze souborů načíst jednotlivé neuronové sítě: Obr. 9 – Snímek obrazovky okna editace konkrétního neuronového modelu spotřeby

Každý neuronový model sestává ze čtyř neuronových sítí: 

výkonové neuronové sítě pro topnou sezónu,



výkonové neuronové sítě pro letní sezónu,



neuronové sítě teploty vratu (resp. entalpie kondenzátu) pro topnou sezónu a



neuronové sítě teploty vratu (resp. entalpie kondenzátu) pro letní sezónu.

Každá z těchto sítí je složena ze tří souborů společného názvu, avšak s odlišnými příponami (FANN, PSGM a BNDR). 2.2.9.2

Výpočet spotřeby s využitím neuronového modelu

Dynamický výpočet spotřeby s využitím neuronového modelu zahrnuje vlivy: -

okamžité teploty vzduchu, strana 30


-

klouzavého průměru teploty vzduchu za poslední 3 dny (pouze pro model výkonu),

-

sezónu (zadávanou globálně na úrovni objektu sítě),

-

denní čas,

-

den v týdnu (pouze pro model výkonu),

-

okamžitá teplota přívodu (pouze pro model teploty vratu / entalpie kondenzátu).

Klouzavý průměr teploty vzduchu ideálně vyžaduje zadaný průběh venkovní teploty nejen v časovém intervalu výpočtu, ale navíc 3 dny před začátkem intervalu výpočtu. Klouzavý průměr teploty vzduchu za poslední 3 dny lze navíc sledovat jako vypočítaný parametr objektu sítě.

2.2.10 Okno: Návrhová tabulka Okno „Návrhová tabulka“ obsahuje v levé části strom určený k výběru typu objektů. V pravé části pak zobrazuje tabulku existujících objektů vybraného typu. Řádky jsou tvořeny jednotlivými objekty. Sloupce obsahují identifikační a vstupní parametry, které je možné měnit. Význam tohoto okna je především v možnosti editace negrafických objektů, např. položek katalogu potrubí. V nabídce Editace je možné vyvolat operace pro tyto negrafické objekty: přidání nového objektu a smazání existujících objektů. Obr. 10 – Snímek obrazovky okna návrhové tabulky

Vedle tradiční práce se schránkou (kopírovat / vložit) je v nabídce Editace k dispozici položka Vyplnit hodnotou.

strana 31


2.2.11 Okno: Návrhová mapa Okno „Návrhová mapa“ doplňuje do základních aplikačních nabídek dvě nové nabídky: Zobrazení a Editace. Nabídka Zobrazení obsahuje – mimo již zmíněných obecných možností mapového zobrazení – možnost diagnostického pohledu na výsledky analýzy (viz obdobná funkce u výsledkové mapy), volby pro nastavení popisků zobrazených objektů a položku pro odvození okna výsledkové mapy se stejným výřezem pohledu na síť a klonování okna. V nabídce Editace je možné vyvolat tyto operace: 

Otestovat konzistenci modelu – z hlediska MOPEDu je konzistentním modelem rozuměn model, který je možné uložit. Není tím zajištěno, že model je správný z hlediska korektního výpočtu.



Vytvoření uzlu – umožňuje vytvořit v síti nový uzel (tj. buď běžný uzel, zdroj, spotřebič, zkrat nebo směšovací uzel); uživatel zvolí typ uzlu a po té klepne na konkrétní místo sítě, kde má být objekt vytvořen. (Souřadnice lze měnit kdykoli poté ručně číselně v rámci modifikace parametr objektu.) Nový uzel je ihned po vytvoření označen, takže je možné rovnou zadávat parametry (např. i hned změnit souřadnice). Některé parametry mají již přednastavenu obvyklou hodnotu. Obr. 11 – Snímek obrazovky okna návrhové mapy



Vytvoření úseku potrubí – před zvolením této položky uživatel vybere jeden z uzlů, mezi kterými chce úsek vytvořit, po té zvolí tuto položku (položka reaguje „zaskočením“ a zvýrazněním zvoleného prvního uzlu) a dále vybere druhý uzel a opět zvolí tuto položku strana 32


nabídky (či tlačítko nástrojové lišty). V případě, že si uživatel vytváření úseku rozmyslel, ponechá označený první uzel (případně ho znovu vybere) a opětovně zvolí položku vytváření úseků – tím je i operace zrušena. V případě potvrzení operace je vložena geometrie lineární čáry. (Uživatel si může geometrii úseku pomocí přidávání, ubírání a modifikace dalších vrcholů měnit ihned potom, stejně jako kdykoliv později pomocí standardních nástrojů.) Nový úsek je ihned po vytvoření označen, takže je možné rovnou zadávat parametry. Některé parametry mají již přednastavenu obvyklou hodnotu. 

Vložení čerpadla či armatury – je postupováno takto: Před zvolením této položky uživatel označí potrubní úsek, na jehož okraji chce čerpadlo či armaturu vložit. Uživatel zvolí tuto položku a zadá, jaký typ objektu chce vytvářet (čerpadlo, škrtící armatura, uzavírací armatura). Ve stejném dialogu také určí, na kterém konci úseku a ve kterém směru se má objekt vložit. (Pozn.: Orientace čerpadla nebo škrtící armatury od počátečního ke koncovému bodu má vliv na funkčnost daného objektu během výpočtu.) Nový objekt je ihned po vytvoření označen, takže je možné rovnou zadávat parametry. Některé parametry mají již přednastavenu obvyklou hodnotu.



Smazání objektu – pokud je vybrán úsek potrubí, je smazán. Pokud je vybráno čerpadlo nebo armatura, je uživatel dotázán, který z krajních uzlů také smazat. Pokud je vybrán uzel (tj. běžný uzel, zdroj, spotřebič, zkrat, směšovací uzel), nebude smazán, pokud to není jeden z následujících případů: o na uzel nenavazují žádné větve (tj. úseky potrubí, ani čerpadla či armatury) – uzel pak bude smazán, o na uzel navazují právě 2 úseky potrubí a žádná čerpadla / armatury – proběhne sloučení úseků v jediný úsek: Uživatel je dotázán, který ze dvou existujících úseků se má stát tím, jehož parametry získá výsledný sloučený úsek. Po potvrzení vznikne úsek, který přejímá parametry ze zvoleného úseku – včetně názvu... Pouze parametr délky může být volitelně sečten ze zadaných délek původních úseků, pokud je to možné.



Konverze typu uzlů – konvertuje zvolený uzel nějakého podtypu obecného uzlu na jiný podtyp obecného uzlu. Uživatel je dotázán na nový typ. Pokud má starý a nový podtyp nějaké shodné parametry, budou pro tyto parametry přeneseny hodnoty do nového objektu.



Přesouvání bodových objektů (uzlů – zdrojů, spotřebičů, zkratů, směšovacích uzlů, běžných uzlů – a čerpadel a armatur): uživatel označí objekt, který chce přesunout, zvolí položku přesunutí a klepne do mapy na novou pozici objektu. Všechny navazující objekty včetně úseků a dalších „bodových“ objektů se tímto automaticky taky opraví, co se týče pozice, příp. tvaru úseků.



Změna tvaru potrubí – pokud je označen úsek potrubí, tak tato volba způsobí, že návrhová mapa přejde do zvláštního režimu editace tvaru potrubí. V tomto režimu lze označovat jednotlivé vrcholy a spojnice mezi nimi. Zároveň přibydou do nabídky a panelu nástrojů další volby (tento režim lze opětovně zrušit stejnou volbou):

strana 33




Přidat vrchol – pokud je označena spojnice vrcholů, dojde k vytvoření nového vrcholu v její půlce.



Ubrat vrchol – pokud je označen vrchol, je odebrán. Okolní vrcholy jsou spojeny spojnicí.



Přesunout vrchol – pokud je označen vrchol, po zvolení této volby uživatel dalším klepnutím do mapy zvolí nové umístění tohoto vrcholu (analogie k přesunu bodového objektu – uzlu nebo čerpadla / armatury)



Rozdělit úsek ve vrcholu – pokud je označen vrchol, dojde touto volbou k jeho nahrazení uzlem (uživatel je dotázán na jeho typ) – tudíž k rozdělení úseku na dva nové. Nově vzniklé úseky budou mít (až na geometrii, id, délku, výšky a počáteční a koncový uzel) zděděné hodnoty parametrů od původního úseku; touto akcí se zároveň ukončí režim editace tvaru potrubí. Výška nového uzlu může být volitelně odhadnuta z výšek okolních uzlů a poměru délky úseků, pokud je to možné.



Pozn.: První a poslední vrchol (tj. krajní uzly úseku) nejsou modifikovatelné – nelze je smazat ani přesunout.

Během editace MOPED zachovává grafickou návaznost sítě: Např. pokud přesuneme uzel, změní se i souřadnice krajních vrcholů přilehlých úseků potrubí, vložených čerpadel a armatur, atp. MOPED povolí vytváření objektů pouze těch typů, které jsou slučitelné s daným typem sítě (vodní / parní). Při zadávání geometrie potrubí pomocí přímé editace v buňce tohoto parametru lze použít následující trik: V případě, že instrukci LINESTRING bezprostředně předchází znak „-“ (minus), je zadaný sled vrcholů interpretován pozpátku. Obsah tohoto parametru je vzápětí změněn na formu bez znaku „-“ a se standardním směrem interpretace (tj. od počátečního uzlu ke koncovému).

2.2.12 Okno: Zadávání průběhu dynamických parametrů Klepnutím na symbol křivky v buňce vstupního parametru (ať již v návrhové mapě či v návrhové tabulce) či stisknutím kombinace Ctrl+G na buňce je možné editovat vstupní parametr jako řadu (včetně náhledu grafu časového průběhu). To je možné pro parametry, které mají v uvedených oknech v příslušné buňce v nápovědě v odstavci „Povolené hodnoty:“ uvedenu položku „reálné číslo / řada“. Editovat vstupní parametr je možné ve třech různých formátech:   

jako konstantní průběh po celé období jako nepravidelnou řadu (sérii lomových bodů v libovolných časech), jako pravidelnou řadu (soubor hodnot v časovém rastru s pevným krokem).

Editaci průběhu nelze vyvolat, pokud vstupní parametr nepovoluje zadávání časové řady.

strana 34


Při použití systémové schránky na přenos hodnot číselných řad se používá interně formát textové tabulky (sloupce oddělené tabelátorem, řádky oddělené znaky CR-LF) kompatibilní s většinou ostatních aplikací. V případě nepravidelné řady tato tabulka obsahuje sloupce: vlastní hodnota, levá limita (v případě, že je odlišná od vlastní hodnoty), pravá limita (v případě, že je odlišná od vlastní hodnoty), datum a čas hodnoty. V případě řady jiného typu se používá pouze 1. sloupec. Obr. 12 – Snímek obrazovky okna návrhové řady

strana 35


2.2.13 Okno: Výsledková tabulka Obr. 13 – Snímek obrazovky okna výsledkové tabulky

Okno „Výsledková tabulka“ obsahuje v levé části strom určený k výběru typu objektů. V pravé části pak zobrazuje tabulku existujících objektů vybraného typu. Řádky jsou tvořeny jednotlivými objekty. Sloupce obsahují identifikační, vstupní a výstupní parametry. Je možné ve stromu typů objektů zvolit společného předka několika typů. V takovém případě jsou zobrazeny všechny vyhovující objekty, s těmi parametry, které mají společné.

2.2.14 Okno: Výsledková mapa Okno výsledkové mapy doplňuje do základních aplikačních nabídek novou nabídku Zobrazení, které obsahuje – mimo již zmíněných obecných možností mapového zobrazení – volby pro přepínání druhu pohledu na síť, volby pro nastavení popisků zobrazených objektů a položku pro odvození okna návrhové mapy se stejným výřezem pohledu na síť a klonování okna. Druh pohledu na síť může být jeden z následujících: 

Základní pohled – obsahuje zobrazené všechny grafické objekty sítě (pro vybraný objekt se v pravé části zobrazují hodnoty – s výjimkou nespočítaných hodnot definovaných v příslušném filtru výstupů)

strana 36


Obr. 14 – Snímek obrazovky okna výsledkové mapy



Zobrazení topologického grafu („network plot“) – navíc k základnímu pohledu zobrazuje u úseků podkladové čáry, barvou odpovídající hodnotě vybraného parametru úseku. K dispozici je také dialog pro výběr tohoto parametru a zadání barevné škály a odpovídajících rozsahů hodnot ke každé barvě. Pro parametry směrového typu je hodnota zobrazována v absolutní hodnotě s vykreslením příslušného směru (od počátečního ke koncovému uzlu potrubí nebo obráceně). Obr. 15 – Snímek obrazovky okna výsledkové mapy zobrazující topologický graf

strana 37




Topologické zobrazení cest – navíc k základnímu pohledu zobrazuje u úseků podkladové čáry, barvou odpovídající cestě, která daným úsekem prochází. K dispozici je dialog pro výběr cest a přiřazení barev k těmto cestám. V tomto režimu je v nabídce Zobrazení přístupná také položka Odvodit obsahující volby pro otevření okna tlakového diagramu (v m n. m. nebo kPa) se stejnými cestami a k nim přiřazenými barvami, jako jsou zobrazeny v tomto okně. Obr. 16 – Snímek obrazovky okna výsledkové mapy zobrazující topologii cest pro tlakový diagram



Topologické zobrazení pro diagnostiku problémů nalezených geografickou analýzou – navíc k základnímu pohledu zobrazuje odlišně geometrii úseků, které byly v počáteční analýze opraveny (tyto původní geometrie však nejsou citlivé na označování myší).

strana 38


2.2.15 Okno: Zobrazení tlakového diagramu Obr. 17 – Snímek obrazovky okna tlakového diagramu v m n. m.

Tlakový diagram lze zobrazit ve dvou variantách, a to v m n. m. a v kPa. V obou variantách zobrazuje tlakové čáry přívodu a vratu. Ve variantě m n. m. navíc čáry odparu a maximálního přetlaku pro přívod i vrat a úroveň terénu. Z okna lze vyvolat dialog na výběr cest, které se mají zobrazit, a k nim přiřazených barev. V nabídce Zobrazení je volba Odvodit pro otevření výsledkové mapy s topologickým zobrazením cest, které zobrazuje stejné cesty a barvy, jako aktuální okno tlakového diagramu. Tlakový diagram je možné vytisknout pomocí položky nabídky Zobrazení → Tisk.

2.2.16 Okno: Zobrazení diagramu čerpadla Okno diagramu čerpadla zobrazuje charakteristiky čerpadla (jmenovitou charakteristiku, minimální charakteristiku, křivku minimálního průtoku a křivky maximálního průtoku) a pracovní bod čerpadla (s případnou trajektorií v dynamickém režimu) v grafu s osami objemového průtoku a měrné energie čerpadla.

strana 39


Obr. 18 – Snímek obrazovky okna diagramu provozu skupiny čerpadel

V případě většího maximálního počtu čerpadel se zobrazují i celkové charakteristiky pro počet čerpadel 1 až maximální počet, přičemž zvýrazněny jsou charakteristiky pro aktuální počet paralelně pracujících čerpadel, který se v případě dynamického výpočtu může při pohybu zobrazení v čase měnit. Vykreslení charakteristik vychází ze spočteného počtu čerpadel ve skupině a vykreslení pracovního bodu (a jeho případné trajektorie) vychází z hodnot čerpaného rozdílu tlaků, hmotnostního průtoku čerpadlem a střední hustoty vody.

strana 40


2.2.17 Okno: Zobrazení průběhu dynamických parametrů Obr. 19 – Snímek obrazovky okna výsledkových řad

Klepnutím na symbol křivky v buňce vstupního či výstupního parametru (ať již ve výsledkové mapě, ve výsledkové tabulce nebo v tlakovém diagramu) či stisknutím kombinace Ctrl+G na buňce je možné zobrazit vstupní parametr jako řadu – včetně grafu časového průběhu. Funkce zobrazení průběhu není dostupná, pokud parametr výsledný parametr neobsahuje řadu (ani konstantní průběh). V zobrazení řad modelu je vždy použit výpočetní časový rastr globálního intervalu, a to i v případě zobrazení vstupů, se kterými byly výsledky počítány. Lze použít funkci kopírování hodnot celé řady do schránky (včetně časové specifikace kroků); formát je shodný s případem okna návrhu řady.

2.3 Výpočtový model 2.3.1 Základní úloha Základní princip výpočtu MOP bude vysvětlen na příkladu jednoduché vodní tepelné sítě.

strana 41


Obr. 20 – Základní úloha při výpočtu vodní tepelné sítě - Vzor.voda.1vetev.xls

2.3.1.1

Zadání

Mějme vodní tepelnou síť tvořenou jedním zdrojem, jednou větví a jedním spotřebičem. Zjednodušené schéma takové sítě je zobrazeno na obr. 20 a příslušná vstupní a výstupní data jsou součástí vzorového pracovního souboru ”Vzor.voda.1vetev.xls”. Naším úkolem je provést výpočet tepelných a tlakových ztrát pro okamžitou teplotu venkovního vzduchu –12°C, výstupní teplotu ze zdroje 135°C a předpokládaný příkon spotřebiče 30 MW při vychlazení primární vody o 70°C. Dále předpokládejme 5% ztrátu oběhového množství.

strana 42


Pro jednoduchost předpokládejme, že tepelná síť je umístěna v rovině, takže vliv hydrostatického tlaku zanedbáváme. 2.3.1.2

Příprava vstupních dat

Pokud nechceme či nemůžeme použít zadávání sítě v grafickém prostředí MOPED, tak příprava vstupních dat spočívá ve vyplnění sloupců listů s oranžovými „oušky“ pracovního souboru ”Vzor.voda.1vetev.xls”. V našem případě jde o vyplnění listů „Síť“, „P“, „Zdr“, „Sp“, „Uz“ a „KP“. List „Síť“ – globální nastavení celé sítě Při zadávání listu sítě hraje hlavní úlohu volba referenčního zdroje a parametrů řízení tlakových poměrů. Parametry řízení tlaků jsou zadávány pomocí hladiny konstantního statického tlaku (HKST) a uzlu, v kterém je hladina udržována, dále pomocí poměru rozevření tlakového diagramu nad a pod touto hladinou a pomocí tlakové diference ve vybraném uzlu sítě. Pro jednoduchost je výpočet vodní tepelné sítě prováděn pro konstantní měrnou tepelnou kapacitu vody, která je rovněž zadávána v listu sítě. Kromě těchto hlavních globálních parametrů lze v tomto listu ještě zadat další parametry, které je možno v případě potřeby ještě individuálně modifikovat v dalších listech. Jde o výchozí rozdíl teplot primární oběhové vody na spotřebičích, výchozí nadmořskou výšku, teplotu zeminy a okolního vzduchu. List „P“ – úseky potrubí Při zadávání jednotlivých potrubních úseků existuje pouze několik málo „povinných“ parametrů, ostatní jsou získány buď z katalogu potrubí nebo z listu sítě. Mezi povinné parametry patří počáteční a koncový uzel, identifikátor typu potrubí pro odkaz do katalogu potrubí a délka úseku. List „Zdr“ – zdroje V tomto listu se pro každý zdroj zadávají výstupní teploty ze zdrojů a podíl jednotlivých zdrojů na celkovém průtočném množství sítí. Dále vyplníme výšku, stejně jako u ostatních uzlů. List „Sp“ – spotřebiče Další list, který je třeba vyplnit je list popisující jednotlivé spotřebiče. Zadává se název uzlu spotřebiče, jeho příkon, vychlazení a ztráta oběhového množství. MOP umožňuje výpočet s různým oběhovým množstvím v přívodní a vratné větvi, přičemž ztráty oběhového množství umožňuje zadat právě pro spotřebiče. Dále vyplníme výšku, stejně jako u ostatních uzlů. List „Uz“ – běžné uzly V tomto listu vyplňujeme jen uzly, které nejsou speciálním typem uzlů (tj. mimo spotřebiče, zdroje, směšovací uzly, zkraty, odvaděče kondenzátu… Podstatné je zadat výšku uzlu. Můžeme též využít funkci z nabídky MOP → Doplnit uzly, která všechny uzly, které jsou odkazované z větví (úseků, čerpadel, armatur) a které dosud neexistují v listech uzlů (běžné uzly, zdroje, strana 43


spotřebiče, …) nově do listu běžných uzlů doplní (a zvýrazní tyto nové uzly barevně) – pak již stačí doplnit jen výšky uzlů… List „KP“ – katalog potrubí Tento list musí obsahovat minimálně ty typy potrubí, které jsou použity v listu úseků potrubí. Poznámka: Následující schéma pro názornost zařazuje jednotlivé prvky sítě do pojmových skupin, a to ze dvou pohledů: z pohledu výpočtového (topologického) a z pohledu zobrazení v MOPEDu (geometrického): Topologický význam:

Geometrický význam:

2.3.1.3

„obecný uzel“

„větev“

Zdroj, běžný uzel, spotřebič, zkrat, směšovací uzel, odvaděč kondenzátu

Čerpadlo, uzavírací armatura, škrtící armatura

„bodový prvek“

„netopologický objekt“ Potrubní úsek

Typ potrubí, typ čerpadla, kategorie spotřeby, …

„liniový prvek“

„negeometrický prvek“

Výpočet stacionárního modelu

Výpočet MOP se primárně snaží dodržet požadovaný příkon jednotlivých spotřebičů. Pro pevně zvolený rozdíl teplot na jednotlivých spotřebičích a konstantní měrnou tepelnou kapacitu vody jsou spočítány požadované průtoky tepelnou sítí. MOP hledá rovnováhu mezi rozložením teplot, tlaků a průtoků v síti při pevně zvolených výstupních parametrů ze zdroje (výstupní teplota, vstupní a výstupní přetlak). Základní stacionární výpočtová úloha MOP tedy vychází ze znalosti požadovaných příkonů jednotlivých spotřebičů tepla a jejich individuálně zadaného vychlazení. Výsledkem výpočtu je potom požadovaný výkon zdroje s respektováním ztrát tepla, ztrát oběhového množství a výsledná teplota vratné větve na vstupu do zdroje. Při řešení této úlohy je třeba v listu sítě zadat u položky Výkon referenčního zdroje a Teplota vratu v referenčním zdroji odkazový řetězec „!CALC“. Požaduje-li uživatel opačnou úlohu, tj. určení teplotních, tlakových a průtokových poměrů v tepelné síti při zadaném výkonu zdroje, popř. zadané teplotě vratu, musí v listu sítě zadat u položky Výkon referenčního zdroje popř. Teplota vratu v referenčním zdroji požadované hodnoty. Při výpočtu tlakových poměrů v síti vychází MOP z dodržení požadované tlakové diference ve zvoleném uzlu a z usazení podle HKST. V případě nedostatečně zadané tlakové dispozice ve zvoleném uzlu může dojít i k překřížení tlakového diagramu. Chce-li uživatel dodržet tlak, popř. tlakovou diferenci v libovolném místě sítě, musí tak provést postupným přestavováním výstupních tlaků ve zvoleném uzlu. V případě vzoru Vzor.voda.1vetev.xls je v listu sítě u parametru „uzel s dP“ uveden strana 44


řídicí řetězec „!CALC“, který vede k tomu, že MOP automaticky hledá hydraulicky nejvzdálenější spotřebič (nikoliv obecný uzel) a v něm dodržuje požadovanou tlakovou dispozici. 2.3.1.4

Výsledky

Výsledky výpočtu jsou rozděleny do několika listů pracovního souboru „Vzor.voda.1vetev.xls“, které mají názvy odpovídající vstupním listům, avšak s příponou „+“ a jejich „ouška“ jsou podbarvena zeleně. List „Síť+“ mimo jiné obsahuje základní tepelnou bilanci počítané sítě. Rozděluje celkové tepelné energie v systému na teplo přivedené ve zdrojích a teplo odvedené v síti a na spotřebičích. Při výpočtu ohřevu doplňované vody a ztrát tepla z nevracení kondenzátu MOP vztahuje tepelnou energii na teplotu (popř. entalpii) a přetlak doplňované vody. Mezi výstupy najdeme nejdůležitější hodnoty potrubí ovlivňující hydraulický stav sítě. Jsou zde spočtené průtoky, rychlosti proudění, tlakové ztráty, hydraulické odpory a změny hydrostatického tlaku. Vše je zpracováno zvlášť pro přívodní a vratnou větev. Dále jsou ve výstupních listech úseků teplotní parametry sítě. Najdeme zde teploty (u parních sítí i entalpie, entropie a suchost páry), tepelné odpory a tepelné ztráty jednotlivých větví a to zvlášť pro přívodní a vratnou větev. Pro uzly sítě výstupy obsahují přetlaky ve všech uzlových bodech sítě a dále shrnují základní údaje o zdrojích a spotřebičích včetně teplot, tlaků, průtoků a tepelných energií. Zvláštními výstupy jsou dopravní zpoždění mezi každým spotřebičem a zdrojem tepla. V případě více zdrojů tepla dokáže MOP určit podíl vody od jednotlivých zdrojů včetně dopravních zpoždění.

2.3.2 Popis výpočtového modelu sítí Každá tepelná síť pro MOP je tvořena třemi základními typy objektů – zdroji, větvemi a spotřebiči. Zdroj je objekt, ve kterém je teplo do systému přiváděno a spotřebič objekt, ve kterém je teplo ze systému naopak odebíráno. Teplo přiváděné ve zdrojích včetně průtočného množství má znaménko ”–”. Naopak teplo odváděné včetně průtoku spotřebiči má znaménko ”+”. Topologie sítě je zadávána pomocí dvojic větví, přívodní a vratné, daných společným počátečním a koncovým uzlem. Průtok v přívodní větvi je kladný, pokud v ní teče voda od počátečního uzlu ke koncovému, v opačném případě má průtok znaménko ”–”. Ve vratné větvi je průtok kladný pokud voda teče od koncového uzlu k počátečnímu. Výpočet průtoků v přívodní větvi Průtokové poměry v přívodních větvích jsou dány chováním spotřebičů, tj. jejich tepelným příkonem a rozdílem teplot (popř. entalpií). Jednotlivé zdroje se podílejí na krytí celkového potřebného průtoku v přívodních větvích v definovaném poměru. Spotřebič svým požadovaným průtokem reaguje na parametry v přívodní větvi. strana 45


Výpočet průtoků ve vratné větvi V síti může docházet na spotřebičích ke ztrátám oběhové vody (popř. kondenzátu). V přívodu tedy mohou být jiné průtoky, než ve vratu. Na základě parametrů v přívodu jsou spočteny ztráty vody (popř. kondenzátu). Přerozdělení průtoku mezi zdroji ve vratné větvi se děje podle poměru průtoků zadaných v listu zdrojů. Pro náš případ s jedním zdrojem se voda doplňuje pouze v referenčním zdroji. Výstupní teploty ze zdrojů nereagují již na parametry vratné větve. Tepelný výkon zdroje a tepelné ztráty Tepelný výkon zdroje je dán součtem tepla potřebného na ohřátí vratného množství vody a doplňované vody. Celkové tepelné ztráty jsou dány, jednak ztrátami tepla (např. tepelnou izolací) a ztrátami množství teplonosné látky. Ohřev doplňované vody i ztráta tepla způsobená ztrátami množství je vztahována na globální teplotu, popř. entalpii doplňované vody. Čerpadla Čerpadlo čerpá vždy od počátečního uzlu ke koncovému v přívodu, ve vratu naopak. Dojde-li k opačnému proudění, čerpadlo nepracuje. Škrticí armatury Škrcení je zadáváno hodnotou požadovaného přetlaku. Je možné v přívodní větvi dodatečně regulovat pouze tlak za škrticí armaturou – tedy na koncovém uzlu (redukce) a ve vratu před škrticí armaturou – též v koncovém uzlu (přepouštění). Z tohoto důvodu se škrtící armatura chová v přívodu pouze jako redukční stanice a ve vratu jako přepouštěcí stanice. Koncový uzel škrtící armatury musí být orientován do oblasti sítě bez uzlu se zadaným poměrem nad HKST a bez uzlu se zadaným dP. Škrtící armatura nepracuje v okruhu Zkraty Jedná se o možnost zkratování přívodní vody do vratu. Tento uzel je dán požadovanou výstupní teplotou vratu za zkratem nebo zkratovacím průtokem a názvem příslušného uzlu. Směšovací uzly Jedná se o možnost směšování mezi vratným a přívodním potrubím. Tento uzel je dán požadovanou výstupní teplotou přívodu za směšovacím uzlem a názvem příslušného uzlu.

2.3.3 Výpočet tepelné sítě s více zdroji a okruhy Na následujícím obr. 21 je znázorněn příklad se složitější vodní tepelnou sítí s více okruhy, viz vzorový soubor ”Vzor.voda.xls”. Jde o fiktivní síť, ve které jsme se pokusili uplatnit různé objekty dostupné pro výpočetní jádro MOP.

strana 46


Obr. 21 – Schéma vodní tepelné sítě s více zdroji a okruhy - Vzor.voda.xls

strana 47


Obr. 22 – Tlakový diagram v kPa pro tepelnou síť z obr. 21

Jde o tepelnou síť se 3 zdroji, 9 spotřebiči, 2 směšovacími uzly a 34 větvemi. Jména uzlů jsou uvedena tučným písmem a identifikátory větví podtrženými čísly. Orientace větví, která je dána počátečním a koncovým uzlem a je znázorněna šipkou. Větve, u kterých rozlišujeme parametry přívodu a vratu, mají vrat označený čárkovanou šipkou. První dva zdroje jsou zadány v listu zdrojů. Zdroj Z1 je referenčním zdrojem (viz list sítě). U zdroje Z2 se automaticky předpokládá, že poměr mezi průtokem ve vratu a přívodu je roven 1. Zdroj Z3 je zadán s poměrem průtoku vratu k průtoku přívodu rovným 1. Zdroje jsou tedy v tomto případě zadány tak, že voda se doplňuje pouze v referenčním zdroji. Tepelná síť dále obsahuje 9 spotřebičů zadaných v listu spotřebičů a 2 směšovací uzly U1 a SO4 upravující postupně teplotu na 130 °C a 120 °C. Směšovací uzly jsou zadány v listu směšovacích uzlů. Prvních 31 větví je tvořeno potrubními úseky, větev 32 představuje čerpadlo umístěné v přívodní větvi, větev 33 čerpadlo ve vratné větvi. Větev 34 představuje přepouštěcí stanici ve vratné větvi a větev 35 redukční stanici v přívodu. Tepelná síť obsahuje celkem 5 okruhů, z nichž třetí okruh slouží k modelování třítrubkového vedení ve větvi 11 a 12 a čtvrtý okruh k modelování čtyřtrubkového vedení ve větvích 13 a 14. Příslušné tlakové diagramy v kPa a v m n. m. jsou pak uvedeny na obrázcích 3 a 4. Tyto jsou zároveň součástí vzorového pracovního souboru. Pro demonstraci vlivu nadmořské výšky je v tomto strana 48


vzorovém příkladu namodelován kopec mezi uzly U1 a SO4. Z tohoto důvodu vzniká v modelované tepelné síti potřeba čerpání před a redukování tlaku za kopcem ve směru proudění. Obr. 23 – Tlakový diagram v m n. m. pro tepelnou síť z obr. 21

2.3.4 Specifické vlastnosti výpočtu parní tepelné sítě Základní rozdíl při výpočtu parních tepelných sítí spočívá v tom, že výpočet je prováděn v proměnných (p, h) tj. (přetlak, entalpie). Je to z toho důvodu, že proměnné (p, T), které využíváme u výpočtu vodních tepelných sítí, nejsou schopny popsat oblast vlhké páry. Filozofie základní úlohy a ostatních úloh zůstává stejná. Rovněž formáty vstupních a výstupních souborů jsou obdobné, pouze místo teploty je třeba zadávat entalpii. Výstupní soubor teplotních parametrů pak obsahuje kromě údajů o teplotě páry i další údaje o entropii, entalpii a suchosti páry. Parních sítě jsou v dynamickém výpočtu modelovány jako posloupnost stacionárních stavů. Vedle přenosu páry v přívodním potrubí a kondenzátu ve vratném potrubí modeluje výpočet i generování, stékání a odvádění kondenzátu v přívodním potrubí. Z toho důvodu se může průtok páry v přívodním potrubí lišit v počátečním a koncovém uzlu. Generovaný kondenzát pak stéká po spádu přívodního potrubí. V rámci modelu není odváděn tento stékaný přívodní kondenzát jen v odvaděči kondenzátu (kde lze volit podíl ztraceného a vraceného kondenzátu), ale u každého uzlu (běžného strana 49


uzlu, spotřebiče, zdroje), pokud je níže, než okolní uzly, a to vždy ze 100 % na kanál. To je v podstatě indikace, že je potřeba do tohoto bodu vložit odvaděč, jinak dojde k zavodnění přívodního potrubí. Specifické vlastnosti výpočtu parní tepelné sítě budou vysvětleny na příkladu přenosu 15 MW tepla 8800 m dlouhým parním napaječem o průměru DN 300 s deseti uzlovými body s různou výškou. Tepelný napaječ je zobrazen na obr. 23. Obr. 25 – Zjednodušené schéma výpočtu parního tepelného napaječe

Pro výpočet parní sítě jsme zvolili na výstupu ze zdroje mírně přehřátou páru o 1600 kPa a entalpii 2800 kJ/kg. Tato pára přechází po prvních třech úsecích do mokré oblasti. Pokud pára podkročí mezní suchost, kdy je vlhkost ještě zcela unášena proudící parou, generuje se na dvě přívodní potrubí kondenzát. Ten stéká po spádu potrubí a v uzlech O1 a O8 je odváděn odvaděči kondenzátu se zvolenými ztrátami do vratného (kondenzátního) potrubí. Při malé průtoku kondenzátu muže dokonce docházet k postupnému ohřívání kondenzátu směrem ke zdroji. Výsledné tlakové poměry je pak i pro parní síť možné sledovat v tlakovém diagramu vykresleném v kPa. strana 50


3

Implementační projekt REGIOS offline

V této kapitole jsou modrým textem vyznačeny části, které není třeba implementovat pro splnění cílů projektu – ale mohou být volitelně implementovány v budoucnu

Nový SW systém REGIOS bude nejprve vyvinut ve variantě offline (nazývaném též „simulační“). Později bude REGIOS rozšířen na „online“ (neboli „predikční a analytický“). Tato kapitola popisuje fázi „offline“. V obou fázích REGIOS zachovává společný kód s MOPem a některými funkcemi obohacuje i MOP(ED) pro stávající zákazníky MOP (např. „nezávislý režim“, „singulární“ vstupy a výstupy, vylepšení stávající technologie, vylepšení uživatelského rozhraní a řešení problémů letního času – technicky vše z kapitoly 3 s výjimkou podkapitoly 3.9.2 a použití hodnoty „!EXT“ je použitelné i čistě v MOP!). Hlavní aplikací REGIOSu bude „REGIOS Prediktor“2. Principiálně se REGIOS od MOPu liší tím, že obsahuje kód specifický pro danou oblast nasazení – konkrétní teplárenskou soustavu (tzv. „destinaci“). Pro maximální čistotu implementace se veškerý specifický kód umístí do souboru jedné či několika DLL-knihoven a obecný kód aplikace (tj. shodný s MOPED) zůstane ve vlastním souboru EXE, který bude vykonávat specifický kód z DLL v předem daných oblastech (tzv. „háčky“). Na každém háčku se kód vykoná, pokud daná DLL existuje, či se pokračuje bez tohoto kódu, pokud neexistuje. Pro každé specifické nasazení REGIOS budou vytvořeny kompilační dávky build a deploy (vedle existujících build_MOP a deploy_MOP), tedy např.: build_REGIOS_NLIS-KOVEC, build_REGIOS_..., deploy_ REGIOS_NLISKOVEC, deploy_REGIOS_.... Samotný Moped.exe (fakticky stejný pro MOP a REGIOS) bude trvale přejmenován na ModEdVw.exe (pro MOP i REGIOS). Při kompilaci REGIOS dávkami bude ve složce bin vytvořen soubor DestSpec.cfg, který bude obsahovat buď 3 položky (1) název aplikační sady (text musí být zcela shodný s textem, který vrací funkce GetAppSuiteTitle() knihovny uvedené v bodu 2), (2) název hlavní destinačně-specifické DLL, (3) název souboru destinačně-specifického „schématu“ („schéma“ – viz podkapitola 3.9.1) nebo 3*N položek. V případě, že obsahuje více než 3 položky, považují se položky za dvojice {(1), (2), (3)} a při startu aplikace dojde k zobrazení interaktivního dialogu, kde si uživatel vybere z nabízených dvojic položek [zřetězených: (1) + „ – “(2) + „ & “ + (3)], čímž dojde k volbě příslušné sady položek

2

Alternativně lze uvažovat o pojmenování hlavní aplikace shodně s názvem celého produktu, tj. lze hovořit o aplikaci „REGIOS“ a také o aplikaci „MOP“.

strana 51


(1)&(2)&(3). Hlavní destinačně-specifická DLL bude mít pro každou destinaci jiný název, aby šly kompilovat destinace vedle sebe – Ta, která má být použita, se určí obsahem 2. položky konfiguračního souboru DestSpec.cfg. I pro MOP bude zavedena takováto DLL, ale bude degenerovaná – bude obsahovat jen „identifikační“ funkce (viz následující podkapitola 3.1). Analogicky i soubor „schématu“ bude mít pro každou destinaci jiný název, aby šly kompilovat destinace vedle sebe – Ten, který má být použit, se určí obsahem 3. položky konfiguračního souboru DestSpec.cfg. I pro MOP bude zaveden soubor „schématu“, ale bude degenerovaný – všechny tabulky bude mít zcela prázdné. V dávkách build, deploy a employ REGIOSu budou oproti dávkám MOPu odstraněny: spustitelné soubory OSave, OLoad, XSave, XLoad, jiné než české manuály, profily importu, importní vzory, vzory modelů („.xls“ i „.model“) a modely-šablony (kromě těch specifických pro danou destinaci).

3.1 Kompatibilita mezi MOP a REGIOS Datový formát modelů MOP a REGIOS je tentýž. I přes to, že model pro REGIOS pravděpodobně nepůjde MOPem přepočítat (pokud bude obsahovat „!EXT“ – viz podkapitola 3.3.1) a model MOPu půjde přepočítat REGIOSem, jen když bude obsahovat povinné elementy dané „schématem“ (viz podkapitola 3.9.1), půjdou modely vzájemně otevřít a prohlížet v druhém systému! Z toho vyplývá, že dále popisované definice „singulárních“ vstupů a výstupů modelu bude součástí formátu jak MOP, taky REGIOS. V kódu MOPED (a GISimport, atd.) je třeba minimalizovat použití slov „MOP“ a „MOPED“ v dialozích, hlášeních zobrazovaných uživateli a dalších textech. Lze např. tato slova vynechat či je nahradit neutrálním „Aplikace“ (místo „MOPED“) nebo „systém“ (místo „MOP“). Speciální výrazy jako „MOPtřída“ lze nahradit prostým „třída“ (nebo lépe „typ objektu“). Pokud to nepůjde jinak nebo na vhodných místech obecně lze použít místo „MOP“ a „MOPED“ statické proměnné OAppTitle a OAppSuiteTitle, které jsou spolu s ONotMop4Lic naplněny při startu aplikace voláním (dle konfiguračního souboru bin\DestSpec.cfg nalezené) hlavní destinační DLL – konkrétně tzv. „identifikačních“ funkcí (které jsou [na rozdíl od „háčků“ – viz kapitola 3.9.2] pro každou hlavní destinační DLL povinné): 

string GetAppTitle() → [„MOPED“, „Prediktor“],



string GetAppSuiteTitle() → [„MOP“, „REGIOS“],



bool GetIfNotMop4Lic() → [false pro MOP, true pro REGIOS - slouží pouze pro kontrolu bitu MOP / REGIOS v HW-klíči – viz dále].

Pokud funkce GetIfNotMop4Lic() vrací „false“, nesmí DLL obsahovat žádné jiné funkce mimo „identifikačních“. Vedle toho bude ještě statická proměnná OAppSuiteDestination a DLL funkce 

string GetAppSuiteDestination() vracející pod-specifikaci k GetAppSuiteTitle(), tj. např. „Nový Lískovec“.

strana 52


Použití OAppSuiteDestination bude minimální (snad jen dialogu „O aplikaci“ a titulní lišta hlavního okna aplikace), ale tam kde bude, bude použito takto: String.IsNullOrEmpty(OAppSuiteDestination) ? OAppSuiteTitle : (OAppSuiteTitle + „ “ + OAppSuiteDestination), tj. pro MOP může hlavní destinační DLL ve funkci GetAppSuiteDestination() vracet prázdný řetězec. Další z (povinných) „identifikačních“ funkcí hlavní destinační DLL a odpovídajících statických proměnných budou:  (string) OUserCfgDirName, GetUserCfgDirName() – podsložka ve složce uživatele pro uchování uživatelských konfiguračních souborů (dosud v MOPu bylo „Mop“, nově např. „Regios_NLisk“)  (string) OVersionDestMod, GetFullVersionString() – tato funkce je povinná pro ty DLL, které ve funkci GetIfNotMop4Lic() vracejí „true“ a naopak nesmí existovat v DLL, které ve funkci GetIfNotMop4Lic() vracejí „false“; Pro GetIfNotMop4Lic() = „true“: zatímco DLL funkce vrací kompletní řetězec verze (např. „20.1.5.1“), tak do proměnné OVersionDestMod se uloží jen poslední (čtvrtá) položka specifikace verze (tj. zde „.1“ [tj. včetně tečky]). Zároveň je proveden test zda GetFullVersionString() začíná řetězcem {GlobVersion.Version() + „.“(!)} a pokud ne, aplikace selže. Motivací je rozlišení verze výsledného produktu, pokud je nezměněn základní kód hlavní aplikace, ale je změněn kód specifický pro destinaci, tj. kód hlavní destinační DLL, nebo případných dalších DLL navázaných skrze hlavní destinační DLL. Důvodem uvedeného testu (a případného selhání aplikace) je snaha nezapomenout na snížení 4 položky verze při zvýšení verze GlobVersion.Version(). Pro GetIfNotMop4Lic() = „false“: OVersionDestMod bude vždy naplněno prázdným řetězcem. Použití proměnné OVersionDestMod je výlučně v dialogu „O aplikaci“ (zde se tedy použije GlobVersion.Version() + OVersionDestMod), jinde zůstane používáno pouze původní GlobVersion.Version(), tj. např. pro všechny účely verzování formátu, apod. Co se týče ochrany HW-klíčem, v konfiguračním řetězci licence vzniknou 2 nové bity: bit „MOP“ (ale inverzně kódovaný kvůli kompatibilitě!) a bit „REGIOS“. Každý zákazník bude mít aktivován pouze 1 z těchto bitů, pouze servisní pracovníci dodavatele budou moci být vybaveni HW-klíčem s aktivovanými oběma bity. Dále bude bit „Moped“ konfiguračního řetězce přejmenován (v okně konfigurace licence utility CDB i v dokumentaci k licenční ochraně) na „Moped / Prediktor“. Ve funkci testování shody vlastností licence je ke stávajícím testům potřeba přidat ještě následující:  Je-li ONotMop4Lic = true, vyžaduje je nastaven bit „REGIOS“.  Je-li ONotMop4Lic = false, vyžaduje je nastaven bit „MOP“. Viditelnost položek nabídky (příp. tlačítek nástrojové lišty) souvisejících s REGIOS online (tj. „Nová predikce“, „Nová analýza“, „Načíst předpověď počasí“, příp. „Aktualizovat zobrazení online veličin“, apod.) nebudou záviset na hodnotě ONotMop4Lic ani na existenci či výsledku jiné funkce v hlavní destinační DLL, ale bude záviset na konkrétním nastavení konfiguračního souboru hlavní aplikace – viz kapitola 4.2.

strana 53


Uživatelská konfigurace se hledá na cestě, jejíž poslední složkou byla dosud „Mop“. Nově se konfigurace bude hledat na této cestě končící složkou s názvem shodným s hodnotou proměnné OUserCfgDirName. Základ názvu hlavního konfiguračního souboru hlavní aplikace (tj. Moped / Prediktor) – pro Moped bylo dosud napevno „Moped“ či odvozeno od názvu spustitelného souboru – bude nově napevno „UI“. (Celý název konfiguračního souboru je z tohoto základu vytvořen obvykle, tj.: základ + fragment + „.cfg“, kde fragment je „“, „-user“ či „-default“ (stejný mechanismus jako dosud v MOP)). Konfigurační soubor hlavní aplikace bude mít v MOP i RGIOS vždy totožný formát - bude obsahovat pouze obecná nastavení aplikace – společná pro všechny destinace. Destinace mohou mít libovolné množství vlastních specifických konfiguračních souborů. Pozn.: Konfigurační soubory se nebudou ani při vývoji plést mezi jednotlivými destinacemi, protože: 1. uživatelské konfigurační soubory („*-user.cfg“) jsou umístěny ve složce specifické pro destinaci; 2. globální („*.cfg“) a implicitní („*-default.cfg“) konfigurační soubory ve složkách Deploy a Employ složkách budou spolu s celým zbytkem distribuce produktu v oddělených podsložkách (dle názvu destinace); 3. globální („*.cfg“) a implicitní („*-default.cfg“) konfigurační soubory ve složce Develop sice mají stejné umístění, ale to nevadí, protože pro vývoj a ladění je stejně nutné nejprve vyvolat build-dávku příslušné destinace (již jen např. kvůli generování DestSpec.cfg) Je sice možné zajistit kompatibilitu s původního Moped-user.cfg a etc\Moped.cfg přejmenováním konfiguračního souboru v rané fázi startu hlavní aplikace [v metodě GlobalSettings.CorrectErrors_Compat002(), na jejím začátku – ještě před případnými opravami obsahu!], ale vzhledem k tomu, že přejmenování může selhat v případě nedostatečných oprávnění k souboru a vzhledem k tomu, že jde o výjimečné jednorázové přejmenování, ponecháme operaci na uživateli / administrátorovi.

3.1.1 Dokumentace REGIOS offline 1) Nejprve je potřeba přestrukturovat dokumentaci k MOPu: Ve výsledku budou 2 manuály MOPu základní a dodatkový:  Základní manuál bude obsahovat vše, co nesouvisí s prací v Excel, tj. všeobecné informace (úvod, instalace, technologie), práce v Moped, nástroje (GISimport, SQLexport, Scalagen) a část dokumentu „Tipy a triky“, které se nevztahují k Excelu. Název souboru základního manuálu nebude obsahovat řetězce MOP, MOPED, REGIOS či PREDIKTOR.  Dodatkový manuál bude popisovat zbytek stávající dokumentace, který nebyl zahrnut do nového Základního manuálu, tj. záležitosti týkající se Excel (např. i interní reprezentaci takových hodnot, jako je „časové určení výpočtu“, protože to je pro uživatele běžně přístupné jen v Excelu).

strana 54


2) Jelikož se funkčnost REGIOS bude z velké části shodovat s funkčností MOP, nemá smysl duplikovat části dokumentace. Dokumentace (manuál – „Uživatelská příručka“) REGIOS bude primárně pojata jako dodatkový dokument k Základnímu manuálu MOP, tj. je třeba:  rozšířit Základní manuál MOPu o informace o nových věcech, které budou i součástí MOP, tj. především nezávislý režim, soubory „.model“, „singulární vstupy“ a „singulární výstupy“, vyměňování „desktopů“, souběžné zobrazení více modelů, vylepšení technologických elementů a vylepšení GUI…  do manuálu REGIOS dávat jen ty věci, které jsou navíc oproti MOPu (a manuálu MOP)… tj. důrazně se odkazovat na manuál MOP. V Základním manuálu je tedy třeba zcela eliminovat použití slov „MOP“ a „MOPED“ (nahradit to neutrálním „systém“ / „software“ / „aplikace“, apod.)

3.2 Nezávislý režim aplikace Pro REGIOS bude vyvinut nový nezávislý režim aplikace (prozatím existuje jen závislý), který nebude potřebovat Excel. Namísto toho bude používat uložení ve vlastním (čistě SQLite) souboru (přípona „.model“), který bude fakticky čisté souborové úložiště databáze SQLite. Prozatím bude moci být v 1 souboru uložen jen právě 1 model. Pro kompatibilitu s případným budoucím rozšířením formátu o schopnost ukládat více modelů do 1 souboru, bude na to formát připraven – viz dále: existence sloupců om_info::id, om_info::name, om_model::id, om_model::name, avšak prozatím tyto sloupce v souborech „.model“ ponesou vždy zvláštní hodnotu „@@@“. Nezávislý režim mohou používat i uživatelé MOP, ale pro REGIOS bude preferovaný. Nicméně se zdá, že veškeré REGIOSí funkčnosti, včetně neuronových sítí (jsou i v Excelu i v souborech „.model“ v textové podobě), aj., budou přístupné z obou režimů – ze závislého i z nezávislého… Pouze u relativních cest k souborům offline podkladových map je třeba udělat ošetření: (1) V nezávislém režimu při uložení do jiného souboru než je aktuální (zejména do souboru v jiné složce) se případná relativní cesta přepočítá na relativní vzhledem k případně novému umístění souboru (když to není na stejném disku jako soubor offline podkladové mapy, bude absolutní – již nyní to tak funguje); (2) Při přechodu do nezávislého režimu, tj. při funkci exportu modelu do souboru „.model“ (v závislém režimu), se případná relativní cesta přepočítá na relativní vzhledem k umístění nového „.model“ souboru (když to není na stejném disku, bude absolutní – již nyní to tak funguje), nicméně pouze dočasně – po dokončení exportu je tvar cesty vrácen na původní. MOPEDu v závislém režimu přibydou k funkcím „Uložit“ a „Zavřít“ ještě funkce „Exportovat do souboru ‚.model‘“ a „Importovat ze souboru ‚.model‘“ – takto lze převádět modely mezi „.xls“ a „.model“. (Pro import se nejprve z kopie vzoru Prazdny.*.xls otevře Moped.) Tyto funkce budou z velké části sdílet kód s funkcemi „Otevřít“, „Uložit“, „Uložit jako…“ nezávislého režimu (viz dále). Při strana 55


exportu do souboru „.model“ bude zobrazeno důrazné varování, že budou ztraceny všechny vzorce, propoje, formátování (barvy, rámečky, …) MOPED / Prediktor bude mít v nezávislém režimu znepřístupněné funkce „Exportovat do souboru ‚.model‘“ a „Importovat ze souboru ‚.model‘“. Místo exportu a importu budou existovat nové funkce „Otevřít ze souboru“, „Uložit jako (do souboru)“ a zůstane již existující „Uložit“, ovšem s odlišnou implementací. Při požadavku „Otevřít“, „Uložit“, „Uložit jako…“ nejprve aplikace provede test kompatibility. Test spočívá v porovnání [om_info.version_index & kaskádově om_info::bugfix_release] čísel s očekávanými (aktuální verzí formátu podporovanou MOPem / REGIOSem)… pokud je [om_info.version_index & kaskádově om_info::bugfix_release] menší, ohlásí „Operaci nelze provést, dokud nebude proveden update formátu souboru. Chcete provést update formátu nyní? ANO/NE…“ (v případě ANO zavolá externí utilitu MODELadmin – viz dále – pro update formátu – tj. se 3 parametry příkazové řádky:   

, , „autoupdate“

– a po jejím ukončení znovu opakuje pokus o operaci („Otevřít“, „Uložit“, „Uložit jako…“)); pokud je [om_info.version_index & kaskádově om_info::bugfix_release] větší, ohlásí „Operaci nelze provést, je nutný update systému MOP / REGIOS…“; jinak operaci provede… V nabídce Soubor bude (vedle položek Otevřít, Uložit, Uložit jako…) existovat položka Nový – toto bude vždy vytvářet nový model v simulačním režimu. Pro budoucí predikční a analytický model budou určeny jiné položky. Položka Nový bude obsahovat podnabídku – viz kapitola 3.2.4… Při startu MOPEDu / Prediktoru bez parametrů příkazové řádky se automaticky načte 1. položka v podnabídce Nový, tj. model s nejnižším číslem „####_“ v prefixu souboru. Nový model v databázi vznikne tím, že se tento model (byť prázdný) uloží… V případě pouhého „Uložit“ (na rozdíl od „Uložit jako (do souboru)“ a „Uložit jako (do databáze)“) se v případě nového (dosud neuloženého) modelu zobrazí dotaz, jestli do souboru nebo do databáze a následně příslušný dialog „Uložit jako (…)“… Pozn. Při „Otevřít“ bude automaticky (není třeba explicitně programovat) použita rychlá SimpleGeoMagnetize… Při startu MOPEDu / Prediktoru s jedním parametrem příkazové řádky se tento parametr považuje za cestu k souboru „.model“ a nezávislý režim se inicializuje s (regulérním) otevřením modelu z tohoto souboru. (Uživatel si pak bude moci asociovat typ souborů s příponou „.model“ s aplikací REGIOS a otevírat soubory „.model“ v aplikaci Prediktor poklepáním na položku souboru…) Parametr bude automaticky detekován na zadání relativní či absolutní cesty. Případná relativní cesta se vyhodnocuje nikoli k umístění aplikace, ale k „aktuální složce“, ze které je aplikace spuštěna.

strana 56


3.2.1 Datová struktura uloženého modelu 3.2.1.1

Strategie ukládání dat do tabulek

Problematika, jak ukládat objekty do databáze, se nazývá Objektově-relační mapování. Klíčová je metodika vazby objektu na řádek tabulky (resp. vždy 1 řádku ve více tabulkách) ve vztahu k dědičností generovanou hierarchií tříd objektů. Existují v zásadě 3 strategie (modely) vyjádření dědičnosti v tabulkách: 

Table Per Hierarchy (TPH),



Table Per Type (TPT),



Table Per Concrete Class (TPC).

V TPH bychom všechny třídy objektů MOP ukládali do jediné tabulky, tato tabulka by mj. obsahovala boolovské sloupce jako např. „is_consumer“, které by určovaly, zda-li jsou jiné konkrétní sloupce používané, či ne (tj. je-li např. uzel spotřebičem apod.). V TPT existuje tabulka pro každou třídu objektů MOP, tedy i pro abstraktní… sloupce se tedy nikde neduplikují, řádky mezi tabulkami jsou provázány vzdálenými klíči představujícími dědičnost. V TPC jsou tabulky pouze pro neabstraktní / koncové třídy objektů MOP a tudíž jsou „společné“ sloupce předků duplikovány – tedy ani zde není uložena informace o tom, že představují vlastně tentýž atribut předka. Jelikož nad databází nebudou žádné složité dotazy, modely MOPu / REGIOSu se víceméně ukládají a načítají vcelku, zvolíme strategii TPC! 3.2.1.2

Struktura tabulek

Struktura tabulek v souboru bude následující: Tabulka om_info --- obsahuje vždy jen jeden řádek! string id NOT NULL UNIQUE --- id složiště (obsahuje „@@@“ u souboru „.model“) string name NOT NULL UNIQUE --- uživatelský název složiště (obsahuje „@@@“ u souboru „.model“) int version_index NOT NULL --- index major+minor verze „formátu“ (tj. odpovídá přímo proměnné MajMinVersionIndex) int bugfix_release NOT NULL --- 3. část verze „formátu“ (bugfix release; odpovídá přímo proměnné Bugfixrelease) strana 57


string comment --- standardně obsahuje „created / fmt-updated by MODELadmin at yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z'“ int maxparlength --- maximální velikost vstupních, výstupních a identifikačních parametrů (nelze měnit, zapsáno při vytvoření souboru) (prozatím, při použití SQLite, je nastavena vždy na 1 miliardu) Tabulka om_model string id NOT NULL UNIQUE --- id modelu (obsahuje „@@@“ u souboru „.model“) string name NOT NULL UNIQUE --- uživatelský název modelu (obsahuje „@@@“ u souboru „.model“) string changed --- datum a čas poslední změny ve formátu yyyy'-'MM''dd'T'HH':'mm':'ss'Z' Tabulka omc_d_*** pro všechny koncové (tj. neabstraktní) třídy objektů MOP s iname=*** uchovávající „dmis“(návrhové) instance: string model_id NOT NULL --- id modelu string omp_+++ --- identifikační / vstupní parametr s iname=+++ (je třeba, aby byly všechny sloupce parametrů typu string, protože (1) interně v moped / prediktoru je to taky tak, (2) i číselné vstupy mohou nést např. „!GLB“…) ….. opakovat „string omp_+++“ pro všechny identifikační / vstupní parametry dané třídy objektů MOP (v pořadí stejném jako v XLS, tj. dle DisplayOrder) Tabulka omc_r_*** pro všechny koncové (tj. neabstraktní) třídy objektů MOP s iname=*** uchovávající „rmis“(výsledkové) instance: string model_id NOT NULL --- id modelu string omp_+++ --- identifikační / vstupní / výstupní parametr s iname=+++ (je třeba, aby byly všechny sloupce parametrů typu string, protože (1) interně v moped / prediktoru je to taky tak, (2) i číselné vstupy mohou nést např. „!GLB“…) ….. opakovat „string omp_+++“ pro všechny identifikační / vstupní / výstupní parametry dané třídy objektů MOP (v pořadí stejném jako v XLS, tj. dle DisplayOrder) Tabulka om_desktop pro uložení „desktopu“ modelu string model_id NOT NULL --- id modelu

strana 58


string formclass --- název třídy podřízeného okna (to samé, co 1. sloupec sudých řádků listu „Dsk“ v XLS), pro hlavní okno se uvádí NULL string formdata --- bezpečně zřetězená (StringExt.SaveJoin) specifikace podřízeného okna (to samé co liché řádky v listu „Dsk“ v XLS) Kód aplikace bude upraven, aby vedle existujícího MajMinVersionIndex a BugfixRelease nesl ještě OldestDbCompatibleMajMinVersionIndex a OldestDbCompatibleBugfixrelease, které budou porovnávány při načítání modelu:  Pokud bude splněno (version_index + 1e-6 * bugfix_release < GlobVersion.OldestDbCompatibleMajMinVersionIndex + 1e-6 * GlobVersion.OldestDbCompatibleBugfixrelease), bude vyžádána externí konverze formátu na nový.  Pokud bude splněno (version_index + 1e-6 * bugfix_release > GlobVersion.MajMinVersionIndex + 1e-6 * GlobVersion.Bugfixrelease), bude to považováno za neopravitelnou chybu. Pozn.: Není třeba řešit otázku, zda ukládat do databáze vše či jen vstupy. Vždy ukládáme vše. Uživatel si výstupy může smazat položkou Smazat výsledky v nabídce Výpočet. 3.2.1.3

Atomicita čtení a zápisu modelů

Není třeba mít zamčený SQLite-soubor (či model v databázi), ze kterého je otevřený model po celou dobu otevření, je třeba ale třeba ošetřit konflikty během fáze ukládání / načítání. 

Soubor SQLite: Zamykání pro konflikty „čtení × zápis“, „zápis × čtení“, „zápis × zápis“ budou vyřešeny pomocí standardních mechanismů SQLite (http://www.sqlite.org/lockingv3.html). Pro to je třeba, aby celý zápis / čtení byly ucelené SQL transakce.



Model v databázovém složišti: Řešení pro SQLite by mělo být analogicky účinné i pro vzdálené databáze.

3.2.1.4

Řešení problematiky maximální délky uloženého parametru v databázi

V současné době je v ObjectAdapter.cs předpřipravena funkce getMaxCellLength. Tu je třeba upravit, aby v nezávislém režimu dávala hodnotu přečtenou z om_info::maxparlength. Ostatní funkce (canload / load / save / saveAs / export… / import…) objektového adaptéru budou také (v nezávislém režimu aplikace) používat funkci getMaxCellLength.

3.2.2 Nástroj pro aktualizaci formátu uloženého modelu Vytváření a update (na novou verzi „formátu“) struktur bude zajišťovat samostatná utilita MODELadmin: strana 59


 POUZE Pokud je spuštěna bez parametrů (tj. samostatně), dá uživateli vybrat soubor … Umožní zadat i neexistující soubor (pak bude vytvořen nový);  Zobrazí editovatelné položky „adonetprovider“ a „connecstring“ (buď předaný na příkazové řádce jako 1. a 2. parametr nebo vybraný v předchozím kroku)… uživatel může změnit např. jméno a heslo na privilegovaný přístup… aplikace zřetelně zobrazuje hlášení, že „připojovací řetězec se z bezpečnostních důvodů (např. administrátorské heslo) nikam neukládá“…;  Pokud byl zvolen dosud neexistující soubor, je tento nyní vytvořen – včetně nastavení om_info::maxparlength (jelikož zatím používáme pouze SQLite, je to vždy 1 miliarda)  Pokud je jako 3. parametr příkazové řádky uveden text „autoupdate“, provede se vlastní update formátu… pokud je 3. parametr prázdný, pokračuje interaktivním výběrem operací (viz dále)… pokud je 3. parametr jiný, hlásí chybu;  Interaktivně nechá uživatele vybrat operaci se souborem (prozatím bude podporována jediná operace, ale v budoucnu možná přibydou další): o

Update formátu souboru na aktuální.

Pozn.: Utilita MODELadmin bude jako nejstarší podporovaný formát mít nikoli 1. formát použitý REGIOS, ale bezprostředně předchozí formát MOP, aby mohl být mechanismus utility zpočátku vůbec implementován.

3.2.3 Řešení neočekávaných problémů v uloženém modelu Díky tomu, že soubory „.model“ budou standardní úložiště SQLite databáze, půjdou na nich dělat různé triky, např. pomocí programu SQLITE (příkazová řádka) nebo softwaru SQLiteStudio (pohodlný software s grafickým uživatelským rozhraním). Pomocí těchto triků bude možné např. opravovat poškození souborů vzniklé chybou aplikace MOPED / Prediktor nebo provádět operace, na které zatím aplikace nestačí nebo s kterými se při implementaci nepočítalo. Příkladem mohou být nějaké konkrétní hromadné operace nad objekty modelu. Nějaké praktické příklady bude vhodné popsat do dokumentu MOP Tips&tricks.doc. Proto bude vhodné dodávat volně šiřitelné programy SQLite.exe a SQLiteStudio společně s MOP / REGIOS. Je tedy třeba umístit distribuční soubory SQLiteStudio na cestu Source\ Install\SQLiteTools\sqlitestudio-3.0.1.zip a je třeba získat soubor SQLite.exe a následně ho umístit do složky Source\Install\SQLiteTools.

3.2.4 Vytváření nových modelů v nezávislém režimu Položka nabídky Soubor → Nový (jako „Nový [model | soubor]“ - nikoli „Nová“ – stejně také máme „Prazdny.voda.xls“…) – a také tlačítko Nový na nástrojové liště – bude mít podnabídku (U prvku strana 60


ToolStripButton to znamená změna na ToolStripDropDownButton). Tato podnabídka bude mít položky: Pro MOP „Prázdný (voda)“ a „Prázdný (pára)“ a pro REGIOS např. „Nový Lískovec 2015“. Když uživatel toto použije, tak se načte model z předdefinované pozice (viz dále), podobně jako při „Otevřít“ (tj. včetně kontroly na fixní věci dle „schématu“), ale v titulku okna nebude uvedený název ani cesta k souboru (nicméně tam může být něco jako >>Nový neuložený model „Nový Lískovec 2015“<<) a bude se pamatovat, že je to dosud neuložený model. To způsobí, že normální „Uložit“ vyvolá místo sebe „Uložit jako…“. Po uložení se cesta v titulku vyplní a příznak „dosud neuloženo“ se zruší. Při použití šablony bude tato šablona-model zkontrolována, zda splňuje určitá kritéria. Pokud je nesplňuje, bude změněna (pouze v paměti, nikoli jako uložený soubor) tak, aby kritéria splňovala. Zároveň o tom bude zobrazena uživateli varující zpráva, že daná šablona není uložena v pořádku. Mezi tato kritéria bude patřit: 

Šablona-model musí být v simulačním režimu (režimy aplikace – viz kap. 4.2).



Šablona nesmí obsahovat řady.



Šablona by neměla obsahovat výsledkovou sadu dat.



Šablona by neměla obsahovat hodnoty „online“ veličin, přestože samotné definice obsahovat může. („online“ veličiny – viz kap. 4.2.2).

Modely, které budou nabízeny v podnabídce, budou modely uložené v bin\new\, dále v etc\new\ a také v <user_settings_folder>\\new\ …přesněji řečeno ve všech třech těchto případech se nejprve hledá v „new.cs-CZ“, pokud tato složka vůbec neexistuje (je jedno jestli je prázdná, ale záleží na tom, jestli existuje!), tak se hledá v „new.cs“ a pokud ani tento neexistuje, tak se hledá v „new“; …ještě přesněji řečeno: foreach (cfgpath in new string { usersettingpath + "\\" + UserSettingsFolderName()/*"MOP"|"REGIOS"*/, appuppath + "\\etc", appuppath + "\\bin" }) { CultureInfo ci = System.Threading.Thread.CurrentThread.CurrentUICulture; for(;;) { if FolderExists(cfgpath + "\\" + ci.Name) { LoadAllModelsToSubmenu(cfgpath + "\\" + ci.Name); break; } if (ci == ci.Parent) break; ci = ci.Parent } } SortModelsInSubmenu();

Je otázka, jak se bude lokalizace modelů-šablon v praxi používat:

strana 61


 REGIOS: Poangličtěné modely-šablony českým zákazníkům REGIOS vlastně dodávat nebudeme, pak je otázka, jestli používat bin\new.cs\ či bin\new\, prakticky je to jedno. Zavedeme ale konvenci: Pokud sada modelů-šablon jako celek splňuje, že neobsahuje žádné jazykově / kulturně specifické hodnoty, umístíme celou sadu do bin\new\. Pokud obsahuje hodnoty specifické pro češtinu, umístíme celou sadu do bin\new.cs\. Pokud by obsahovala hodnoty specifické pro angličtinu, umístili bychom celou sadu do bin\new.en\!  MOP: Námi dodávané originální (české) modely-šablony budou v bin\new.cs\ a poangličtěné budou v bin\new\. (České a poangličtělé se liší minimálně, jen v předdefinovaném názvu sítě, protože na rozdíl od vzorů Excelu Prazdny.*.xls neobsahuje soubor „*.model“ titulky sloupců, uživatelské názvy tabulek [listů], nicméně do budoucna se mohou jazykové varianty lišit ještě něčím jiným…) Do podnabídky se dají názvy nalezených modelů (1) bez cesty, (2) bez přípony, (3) všechna podtržítka jsou nahrazena mezerami, (4) ignoruje se prvních 5 znaků názvu, které musejí být „####_“ (kde # je číslice). Toto číslo #### indikuje pořadí, ve kterém budou položky v podnabídce setříděny. Námi dodávané modelyšablony budou dodávány (ve složce Deploy) s následujícími prefixy: pro MOP: „4000_“ (Prázdný_(voda).xls), „5000_“ (Prázdný_(pára).xls) a pro REGIOS „5000_“ (např. Nový_Lískovec_2015.xls). Modely Prazdny_(voda).xls a Prazdny_(pára).xls nebudou úplně prázdné, ale bude v nich „standardní sada“ filtrů („all“ a „none“ pro všechny listové třídy). Tyto modely budou stacionární, nebudou mít otevřena žádná podřízená okna, výstupy budou smazané a vstupy nebudou nést řady (čísla budou jakési „implicitní“ hodnoty). Interval bude nastaven na dynamický výpočet – 3 dny od 1. 1. 2222.

3.2.5 Porovnávání modelů, zobrazení externích průběhů, map a diagramů Poznámka: jde o něco jiného než „souběžné zobrazení“ online veličin – v predikčním a analytickém režimu aplikace! Všechny funkce budou přístupné i v závislém režimu! (pouze odkazované / externí modely musejí být nezávislé) 3.2.5.1

Interní reprezentace odkazů na externí modely:

Aby šly externí modely používat, musejí se nejprve zaregistrovat do „tabulky registrovaných externích modelů“ („REM“). strana 62


REM pro každý externí model obsahuje: (1) [int] extmodref_id (automaticky generované kladné celé číslo; pro uživatele neviditelné; „0“ je rezervovaná pro aktuálně otevřený model; záporné hodnoty jsou rezervovány pro budoucí speciální použití; číslo bude mezi registrovanými modely unikátní), (2) [string] extmodref_title (uživatelem zadávané; musí být mezi registrovanými modely unikátní; nesmí být null ani prázdný řetězec; null je rezervován pro aktuálně otevřený model a případné budoucí [extmodref_id < 0]; implicitně předvyplněné názvem souboru bez cesty, příp. u složiště názvem modelu ve složišti), (3) id_modelu (viz níže), (4) id_složiště (viz níže), (5) GrInstances ext_rmis (celý balík všech výsledkových (identifikačních, vstupních i výstupních) parametrů daného externího modelu; načte se vždy celý s přidáním záznamu do REM) Dvojice {[string id_modelu] a [string id_složiště]} prozatím mohou nabývat jen těchto kombinací hodnot:  odkaz na aktuální model, tj. pro [extmodref_id = 0]: id_modelu = NULL && id_složiště = NULL 

odkaz na externí model v souboru „.model“ souboru [extmodref_id > 0]: id_modelu = NULL && id_složiště = absolutní_nebo_relativní_cesta_k_model_souboru

V budoucnu možná přibude možnost:  odkaz na externí model ve složišti [extmodref_id > 0]: id_modelu = id_modelu_uvnitř_složiště && id_složiště = id_složiště K jednotlivým:  oknům typu výsledková mapa, výsledková tabulka, tlakový diagram v m n. m., tlakový diagram v kPa, diagram čerpadla a 

názvům parametrů v seznamu zobrazovaných parametrů v oknech typu výsledkové řady

musí přibýt jeden (z / do nastavení „desktopu“ čtený / ukládaný) parametr: extmodref_id. Tabulka registrovaných externích modelů se musí ukládat spolu s „desktopem“ modelu! 3.2.5.2

Uživatelské rozhraní pro externí modely

V hlavním okně aplikace přibude na nástrojové liště (před zelenými tlačítky pro otevření nových podřízených oken) tlačítko [ale s DisplayStyle = Image@Text] a v nabídce Otevřít (před zelenými položkami) položka nabídky [normální]. Oba tyto prvky mají vždy stejný Image i Text; na klepnutí vyvolají dialog „managementu externích odkazů“; po zavření dialogu se do prvku vepíše text z extmodref_title zvolené varianty (pokud je [extmodref_id = 0], vepíše se text „interní“, pro [extmodref_id = -1] se vepíše „online“. Text bude pro [extmodref_id = 0] černý a ne-tučný, pro [extmodref_id = -1] zelený, bold a italics a pro ostatní [extmodref_id > 0] červený a tučný. strana 63


„Uživatelský název externího modelu“ extmodref_title (nebo text „online“ pro [extmodref_id = -1] či prázdný řetězec pro [extmodref_id = 0]) bude použit:  v závorce jako přípona textu v titulku oken map / tabulek / tlakových diagramů,  v závorce jako přípona textu ve viditelném názvu parametru zobrazované v oknech řad. Pokud bude z externího okna otevírané jiné okno (např. funkcí Odvodit, či otevřením okna řady z okna mapy / tabulky), bude se také vztahovat k aktuálně vybranému modelu! Při každém načtení modelu se dle REM naplní ext_rmis. Dialog managementu externích odkazů (odpovídající REM) bude umět: 1. přidat nový záznam do REM (OpenDialog - ze souboru „.model“, později ze složiště), 2. smazat záznam z REM, 3. označit záznam z REM jako „aktivní [pro otevírání nových oken]“, 4. změnit záznamu extmodref_title (kromě aktuálně otevřeného modelu; se zachováním unikátnosti), 5. aktualizovat ext_rmis daného záznamu REM nebo i všech záznamů, 6. bude u každého záznamu z REM zobrazovat, kolik oken se odkazuje na daný model (celý) a kolik parametrů (jednotlivých; z oken řad) se odkazuje na jakýkoliv parametr z daného modelu; 7. Pro případy přesunutí odkazovaných modelů (resp. v budoucnu: přejmenování modelů ve složišti či přejmenování složiště) bude dialog umět i u existujícího REM záznamu změnit id_modelu a id_složiště… u cesty k souboru „.model“ souboru to bude dělat jako u dialogu otevření souboru offline podkladové mapy, tedy umožní otevřít dialog pro cestu k souboru a následně se zeptá, zda se má uchovat cesta relativní či absolutní… Teoreticky by dialog mohl měnit id_modelu a id_složiště z NULL na ne-NULL a obráceně bez omezení, čímž by umožnil dělat z interních odkazů externí a obráceně, ale to by bylo pro uživatele trochu matoucí, nesouvisí to s primárním účelem dialogu, jímž je reakce na přesunutí modelu (apod.) a navíc není zřejmý praktický význam takových změn…

3.2.6 Výměna nastavení uživatelského rozhraní mezi modely Pro vyměňování nastavení „desktopu“ (uložené rozložení oken a další nastavení rozhraní aplikace) mezi modely je potřeba mít možnost aktualizovat v modelu toto nastavení ze souboru a naopak i možnost uložení samostatného „desktopu“ do souboru. Bude existovat samostatný typ souborů, které mají vnitřně vlastně stejnou strukturu jako modely, ale vůbec neobsahují (ani prázdné) tabulky omc_d_* a omc_r_*. Je třeba, aby tyto soubory „desktopu“ strana 64


byly odlišitelné i z vnějšku od modelů: u souborů to bude příponou „.moddsk“. Při otevírání souboru „.model“ bude hlášena chyba, pokud neexistují tabulky omc_d_* a omc_r_*; při otevírání souboru „.moddsk“ bude hlášeno varování (a vše mimo informací vztahujících se k „desktopu“ bude ignorováno), pokud tabulky omc_d_* a omc_r_* existují.

3.3 Singulární vstupy, singulární výstupy, vzorce, odkazy Toto bude implementované a funkční jak v MOP, tak REGIOS (v MOP pouze nebude fungovat „!EXT“). Nyní (v MOP) se konkrétní parametr konkrétní třídy (potřebný např. při identifikaci řady v okně zobrazení řad) identifikuje na třech úrovních: 1. V paměti je reprezentován instancí (označme ji „mip“) třídy MopInstanceParameter, zapouzdřující dvojici: „mi“ - reference na instanci třídy MopInstance a „mp“ reference na instanci třídy MopParameter; 2. Pro perzistentní uložení (např. do „desktopu“ modelu) se použije výraz (mip.mi.classof.iname, mip.mi.getStorableIdentification().SafeJoin(), mip.mp.iname ).SafeJoin() ...kde SafeJoin je zřetězení s oddělovačem „^“ s předchozím nahrazením znaků „\“ za „\b“, „#“ za „\n“ a „^“ za „\s“ (případných 0 prvků je reprezentováno řetězcem „#“) …a kde funkce getStorableIdentification() vrací hodnoty jednotlivých setříděných identifikačních parametrů jako pole; 3. Pro účely zobrazení uživateli se použije funkce mip. getFullInstanceParamTitle(), jež vrací String.Format("{0}: {1} [{2}]", (String.IsNullOrEmpty(mip.mi.getReadableIdentification()) ? mip.mi.classof.title : String.Format("{0} \"{1}\"", mip.mi.classof.title, mip.mi.getReadableIdentification())),mip.mp.title_unique, mip.mp.unit) …kde mi.getReadableIdentification() vracející mezerou oddělené hodnoty setříděných identifikačních parametrů. Nově budou zavedeny tzv. singulární vstupy a singulární výstupy. (Stávající vstupy a výstupy budeme pro rozlišení dále nazývat ne-singulární.) Tyto objekty se budou navenek uživateli jevit jako přidružené parametry ke konkrétní instanci nějakého typu objektu, ale ve skutečnosti to budou samostatné objekty s parametrem nesoucím konkrétní hodnotu. Aby tyto „singulární parametry“ vytvářeli iluzi přidružení k objektu, budou mít upraveny „3. úroveň“ identifikace (metodu getFullInstanceParamTitle()) a některé další pomocné metody – viz níže. Kvůli „singulárním parametrům“ bude třeba typu PhysCategory zavést vedle identifikátoru (iname) také uživatelsky viditelný název (title), který navíc musí být lokalizovaný. Nové třídy „singulární vstup“ a „singulární výstup“ se vyznačují společným předkem „singulární parametr“. (Společný předek zajišťuje unikátnost trojice identifikačních parametrů a tím i efektivní „3. úrovně“ identifikace.) „Singulární parametr“ (iname: „singular“, title [česky]: „Singulární parametr“, title [anglicky]: „Singular parameter“) je abstraktní předek s následujícími parametry:  [identifikační parametr; text] class (title [česky]: „Typ objektu“, title [anglicky]: „Object type“, comment [česky]: „Interní invariantní identifikátor typu objektu: Neměl by být strana 65










nikdy zadáván ručně, ale pouze skrze příslušné dialogy.“, comment [anglicky]: „Internal invariant identifier of the object type: It should be never set manually. Only corresponding dialog should be used to set it.“) – iname třídy objektu, ke které se formálně vztahuje - přidružuje [identifikační parametr; text] instance (title [česky]: „Identifikace objektu“, title [anglicky]: „Object identification“, comment [česky] = „Uspořádaný seznam hodnot identifikačních parametrů objektu oddělených znakem '^': V názvech větví musejí být nahrazeny některé znaky, a to postupně: '\' -> '\b', '#' -> '\n', '^' -> '\s'. Prázdný řetězec je reprezentován znakem '#'.“, comment [anglicky] = „Ordered object identification parameters values list separated by '^' character: Some branch name characters must be replaced, in this order: '\' -> '\b', '#' -> '\n', '^' -> '\s'. Empty list is represented by '#' character.“) – seznam id instance objektů (zřetězený metodou SafeJoin()3), ke kterému se formálně vztahuje (pro účely zobrazení „3. úrovně“ identifikace se nejprve použije reverzní funkce SafeSplit…) [identifikační parametr; text] title (title [česky]: „Název parametru“, title [anglicky]: „Parameter name“, comment [česky] = „Uživatelsky viditelný název parametru“, comment [anglicky] = „User visible name of the parameter“) – uživatelský název („title“) objektu parametru (vztahující se jednoznačně k třídě + instanci objektu… mimo jedinečnosti tohoto názvu mezi singulárními parametry vztahujícími se k dané instanci – již zajištěné tím, že je to trojice identifikačních parametrů – zde explicitně požadujeme, aby title nebyl shodný s title_unique žádného ne-singulárního parametru MopClass dané classof) [vstupní parametr; text] physcat (title [česky]: „Fyzikální kategorie“, title [anglicky]: „Physical category“, comment [česky]: „Interní invariantní identifikátor fyzikální kategorie: Neměl by být nikdy zadáván ručně, ale pouze skrze příslušné dialogy.“, comment [anglicky]: „Internal invariant identifier of the physical category: It should be never set manually. Only corresponding dialog should be used to set it.“) – identifikátor (iname) fyzikální kategorie (identifikátor musí být z pole PhysCategory.Template, nikoli tedy speciální fixní kategorie „=“ či „-„ rezervované pro nečíselné a celočíselné hodnoty) …Je možné, že pro REGIOS budou potřeba zavést nové kategorie: Ty se zavedou i do MOP (do pole PhysCategory.Template)! [vstupní parametr; integer] order (title [česky]: „Pořadí zobrazení“, title [anglicky]: „Display order“, comment nedefinován) – DisplayOrder [integer] pořadí zobrazení jak v oknech návrhové / výsledkové tabulky, tak v oknech návrhové / výsledkové mapy (editační dialogy metainformací – viz dále – zajišťují, aby vstupy měly vždy nižší hodnotu

3

Tímto se funkce SafeJoin dostává definicí oddělovačů a náhrad vedle použití při uložení „desktopu“ aplikace a při ukládání .NET Framework Settings též do ukládání hodnot modelu, což ještě zvyšuje důležitost již tak důležitého požadavku na neměnnost jejího formátu.

strana 66


než výstupy a výstupy nižší než „online“; jinak pomocí pořadí mohou být míchány libovolně singulární parametry mezi ne-singulární)  [vstupní parametr; text] comment (title [česky]: „Komentář“, title [anglicky]: „Comment“, comment [česky] = „Uživatelsky viditelný komentář (v bublině nápovědy k názvu parametru)“, comment [anglicky] = „User visible comment (in the tooltip bubble of the parameter name)“) – komentář (zobrazovaný v nápovědné „bublině“) Potomek „Singulární výstup“ (iname: „outsingular“, title [česky]: „Singulární výstup“, title [anglicky]: „Singular output“) přidává parametry:  [vstupní parametr; text] recipe (title [česky]: „Předpis“, title [anglicky]: „Recipe“ , comment [česky] = ‚Může obsahovat buď vzorec (začínající znaky „!!“) nebo libovolnou „konstantní“ hodnotu (nezačínající znaky „!!“).‘, comment [anglicky] = ‚This can be a formula (starting with „!!“ characters) or a constant value (not starting with „!!“ characters).‘) – předpis – definici toho, čím se má u plnit hodnota (může obsahovat „!! vzorec“ (viz dále), konstantu (bez znaků „!!“) či (pouze u REGIOS) „!EXT“)  [výstupní parametr; doubleseries] value (title [česky]: „Hodnota“, title [anglicky]: „Value“, comment nedefinován) – hodnota parametru (vždy typu DoubleSeries!) Potomek „Singulární vstup“ (iname: „insingular“, title [česky]: „Singulární vstup“, title [anglicky]: „Singular input“) přidává parametry:  [vstupní parametr; doubleseries] value (title [česky]: „Hodnota“, title [anglicky]: „Value“, comment nedefinován) – hodnota parametru (vždy typu DoubleSeries!)  [vstupní parametr; text] surrogates (title [česky]: „Náhradní hodnoty“, title [anglicky]: „Surrogate values“ , comment [česky] = ‚Seznam povolených náhradních hodnot (včetně počátečních znaků „!“) zřetězených bez oddělovače‘, comment [anglicky] = ‚List of allowed surrogate values (including „!“ as first characters) concatenated without a delimiter‘) – seznam náhradních (vykřičníkových) hodnot – položky vždy začínají vykřičníkem a dále mohou obsahovat jen ASCII písmena anglické abecedy; seznam je bez oddělovačů, protože položky jsou již přirozeně odděleny vykřičníkem. Náhradní hodnoty prozatím nebudou sloužit k přímé kontrole validity hodnoty vstupu, mohou být však využity konkrétním vzorcem ke specifickým účelům. Prozatím: abychom nemuseli mít další vstupní parametry podrobněji specifikující metainformace parametru (ale i z jiných důvodů), tak uděláme určité zjednodušující rozhodnutí: Singulární parametr vždy smí nést řadu (toleruje tedy automaticky i číselnou konstantu), ale není určen k zadávání textu (s výjimkou náhradních [začínajících vykřičníkem] hodnot – ať již těch definovaných v metainformacích, či [pouze v REGIOS] „!EXT“ (schopnost nést „!EXT“ není definována metainformacemi, a to ani u nesingulárních parametrů)) Na 1. a 2. úrovni identifikace se pro singulární parametry nic nemění. Aby se ale singulární parametry tvářily pro uživatele jako parametry přidružené k instancím typu běžných objektů, je potřeba kamufláže dosáhnout úpravou následujících funkcí:  funkce getFullInstanceParamTitle namísto obvyklého výsledku bude pro singulární parametry vracet 3-kompozici složenou z hodnot (!) instance typu „singulární parametr““: [hodnota identifikačního parametru „třída objektu“ což je iname] převedeno na title + [hodnota identifikačního parametru „seznam id instance objektu“] strana 67


ale dekódovaná pomocí SafeSplit a zřetězená s mezerami a uzavřená do uvozovek + [„: “] + [hodnota identifikačního parametru „uživatelský název objektu“] + [„ [“] + [jednotka dekódovaná dle vstupního parametru fyzikální kategorie] + [„]“]  obdobně budou modifikovány budoucí funkce getEffectiveObjectClass a getEffectivePhyscategory, které normálně berou mopinstance.classof.title a mopparameter.physcategory.title [„title“ dosud v physcategory MOP zatím neexistoval, pro REGIOS je třeba doplnit], budou pro singulární parametry místo toho vracet [hodnota identifikačního parametru „třída objektu“ což je iname] převedeno na title a [hodnota vstupního parametru „fyzikální kategorie“ což je iname fyzikální kategorie] převedeno na title fyzikální kategorie…  …? Pozn.: Převod z iname na title ve výše uvedeném postupu se použije i na externě zobrazené singulární parametry. Je proto nutné, aby externě použité modely byly v téže (tj. aktuální) verzi formátu souboru modelu – tj. při načítání externího modelu bude stejně jako při otevírání souboru modelu kontrolováno, zda je formát aktuální a případně bude zavolána utilita MODELadmin pro aktualizaci tohoto formátu… Všem typům singulárních objektů bude přiřazen atribut „SuggestAsInvisible“, který způsobí, že třída nebude zobrazovaná v oknech návrhové a výsledkové tabulky, jelikož pro editaci definic singulárních parametrů bude určen samostatný dialog. 4 excelovské listy odpovídající „singulárním“ vstupům a výstupům (oba to jsou vstupní listy! Také ale mají svůj výstupní ekvivalent) jsou neviditelné (např. jako listy cest). Názvy listů budou: „Svst“, „Svýst“, „Svst+“, „Svýst+“ (a anglicky: „Sin“, „Sout“, „Sin+“, „Sout+“).

3.3.1 Princip použití singulárních vstupů a princip plnění singulárních výstupů 3.3.1.1

Zacházení se singulárními parametry společné pro MOP i REGIOS

Ne-singulární vstupy (pouze!) reálně-číselného charakteru (tj. pouze vstupy, explicitně umožňující (mimo jiné) zadávat reálná čísla či reálné řady) mohou místo hodnoty (včetně dosavadních náhradních hodnot začínajících jedním vykřičníkem) nést „!! “ (viz níže). Vzorec zde ale může nést vedle operací a konstant odkazy na singulární vstupy (pouze!) – kteréžto jsou vždy reálněčíselného charakteru. Pozor! Ne-singulární vstupy se vzorcem musejí být plněny až těsně před výpočtem tak, aby se nepřepsal vzorec hodnotou a to ani ve výsledkové kopii vstupů! Singulární výstupy budou mít ve vstupním parametru „předpis“ hodnotu, která bude obsahovat buď „!! “ či konstantu (tj. bez znaků „!!“). V případě vzorce, může tento obsahovat vedle operací a konstant odkazy (ale odkazy jen na ne-singulární výstupy a singulární či ne-singulární vstupy (nicméně vstupy z výsledkového modelu!) – a opět pouze reálně-číselného charakteru – což je ale např. u singulárních vstupů vždy)

strana 68


3.3.1.2

Zacházení se singulárními parametry specifické pouze pro REGIOS

Ne-singulární vstupy reálně-číselného charakteru mohou mít místo hodnoty „!EXT“ (Hodnota „!EXT“ nebude popsaná v dokumentaci MOP ale jen v dokumentaci REGIOS.) Tato zvláštní hodnota indikuje, že zadání objektu je injektováno „externím“ kódem DLL v některém z „háčků“. Singulární výstupy mohou mít v „předpisu“ mimo „!! “ či konstanty také „!EXT“. Tato zvláštní hodnota indikuje, že výsledná hodnota je vyplněna „externím“ kódem DLL v některém z „háčků“.

3.3.2 Vzorce a odkazy, rozhraní pro jejich editaci Vzorec je výraz složený z vestavěných operací (zpočátku malá sada operátorů, zatím žádné „funkce“), konstant (zatím jen reálné číslo, tj. nikoli string, int či řada) a odkazů na parametry (dle umístění vzorce omezený seznam možných odkazovaných MopInstanceParameter-ů: Ne-singulární vstupy mohou odkazovat jen na singulární vstupy; singulární výstupy mohou odkazovat jen na singulární vstupy, ne-singulární vstupy a ne-singulární výstupy) 3.3.2.1

Dialog editace / zobrazení vzorců

Bude existovat speciální editační dialog vzorců (plně editovatelný návrhový režim a „pro čtení“ výsledkový režim), který přeloží odkaz z „2. úrovně“ identifikace MopInstanceParameteru na „3. úroveň“, konstanty přeloží do lokálního formátu ((a případně nahradí symbol operace za lokalizovaný slovní popis, např. „+“ na „součet dvou následujících“)) [ale interně udržuje „2. úroveň“ identifikace odkazů, invariantní formát konstant a originální znaky operací] a který neumožní úplně volnou textovou editaci. Bude překládat interně použitou „polskou“ notaci do „zobrazovací“ infixové notace (a při uložení obráceně). Bude použit FlowLayoutPanel přidávající / ubírající objekty typu Label (s .AutoSize = true, s barevným pozadím .BackColor, případným tučným fontem ve .Font a s .BorderStyle = BorderStyle.FixedSingle) pomocí funkcí .Controls.Add() a .Controls.RemoveAt(). Zobrazovaná infixová notace bude mít vlastnost, že každý operátor se svými parametry okolo bude vždy uzávorkován. Nebude použito žádných prvků k vložení do vzorce nebo smazání do vzorce. Namísto toho může uživatel označit libovolnou celou závorku či jednotlivý operand (konstantu či odkaz) a toto editovat – nahradit jiným výrazem (konstantou, odkazem, operací [prozatím na konstantách „0“ a „0“). To vyžaduje, aby v kterémkoliv okamžiku editační prvek vzorce něco obsahoval, byť předchozí hodnotu, nebo např. konstantu „0“. Při editaci / vkládání odkazu na parametr bude v dialogu k dispozici panel umožňující výběr tohoto parametru. Panel bude mít podobné filtrační prvky jako výsledkový dialog popisovaný v kapitole 3.7.4.

strana 69


Dialog bude pracovat ve dvou režimech (A) jako odkazy bude nabízet jen singulární vstupy, (B) jako odkazy bude nabízet singulární vstupy, ne-singulární vstupy reálně-číselného charakteru a nesingulární výstupy typů „reálné číslo“ či „reálná řada“. Interní syntaxe vzorců bude dána funkcí SafeJoin()4 použitou na pole tokenů prefixové [neobrácené (!) „polské“] notace, kde token může být:  Operátor (podporujeme zatím jen binární operace) --- speciální znak „+“. „-“, „*“, „/“ nebo „?“ („?“ je speciální binární operátor [podobný SQL operátoru ifnull nebo C# operátoru „??“] vracející 1. operand, pokud to ovšem není náhradní {začínající vykřičníkem} hodnota, v takovém případě vrací 2. operand) 

Konstanta --- řetězec začínající číslicí a tvořící platné reálné číslo v invariantním formátu; (Nebudeme umožňovat zadávat zde přímo konstantní řadu – toho lze analogicky dosáhnout zavedením singulárního parametru, což je přehlednější)



Odkaz --- předřazený řetězec „link:“5 + „2. úroveň“ identifikace objektu MopInstanceParameter

Výpočet probíhá vždy v základních jednotkách SI, protože jak u ne-singulárních tak u singulárních parametrů máme díky zadanému „vstupnímu parametru fyzikální kategorie“ k dispozici hodnoty toBaseSIcoef a toBaseSIcorr. Informaci, že „(na rozdíl od zbytku rozhraní systému MOP / REGIOS) výpočet probíhá vždy v základních jednotkách SI“ bude dialog uživateli výrazně zobrazovat. Proto bude třeba v interním poli PhysCategory.Template vedle existující specifikace „unit“ přidat ještě specifikaci „baseunit“, která bude zobrazovaná právě v tomto dialogu. Vlastní výpočet dle vzorce probíhá procházením pole tokenů „polské“ notace a plněním C# Expression Tree, následným doplněním hodnot za formální parametry představující MopInstanceParametery a konečně spuštěním příslušného Expression Tree.

4

V dokumentaci bude uveden formát vzorů (stejně jako je nyní popisován formát řad či časového intervalu). V rámci popisu formátu vzorců bude uvedeno, že pole tokenů prefixové notace je odděleno znakem '^', že v jednotlivých tokenech musejí být nahrazeny některé znaky, a to postupně: '\' -> '\b', '#' -> '\n', '^' -> '\s' a že prázdný řetězec je reprezentován znakem '#'. 5

Řetězec „link:“ by nebyl teoreticky nutný, ale kvůli případnému rozšíření syntaxe v budoucnu o další typy tokenů přijmeme rozpoznávací pravidlo: Postupně: (1) Je-li prvním znakem tokenu arabská číslice, jedná se o číselnou konstantu; (2) Je-li prvním znakem písmeno anglické abecedy, nalezneme prefix končící znakem „:“ a dle toho vyhodnotíme zbytek řetězce (pro prefix „link:“ rozpoznáme odkaz na MopInstanceParameter); (3) Je-li prvním znakem jiný znak, hledá se v seznamu povolených operátorů – není-li nalezen, jde o chybu.

strana 70


3.3.2.2

Vyvolání dialogu editace / zobrazení vzorce

Ve všech oknech (mapy, tabulky, tlakové diagramy…), které v buňce zobrazují hodnoty vstupních parametrů (ať již návrhové či výsledkové sady) bude v případě zobrazení hodnoty reálně-číselného charakteru (ještě před (!) případným symbolem editace řady) zobrazen (velmi úzký – bude u většiny vstupů, taky aby nepřekážel) symbol: 3 čtvercové tečky nad sebou (v návrhových oknech oranžově, ve výsledkových zeleně). Klepnutí na tento symbol (nebo klávesová zkratka, např. Ctrl+J) vyvolá dialog editace / zobrazení vzorců (viz výše) – v režimu „A“ – z výsledkových oken navíc v read-only režimu. Pokud při otevření dialogu hodnota v buňce není vzorcem, zobrazí se dotaz, zda hodnotu smazat. Při odmítnutí není dialog zobrazen. Při zavírání dialogu je obsah vždy akceptován, byť by vzorec obsahoval pouze konstantu. Pozn.: Dialogy editace / zobrazení vzorců nebudou otevírány přímo z nabídky Excel, jsou přístupná pouze uvnitř MOPED / Prediktoru. Tj. podobně jako editace / zobrazení časových řad jsou součástí funkční nesymetrie mezi rozhraním Excel a MOPED, nicméně i na úrovni Excel editace / zobrazení možné je, bohužel s nutností práce s nelokalizovanými reálnými čísly a vnitřními identifikátory (iname) typů objektů a parametrů… Jelikož máme dialog na editaci / zobrazení vzorců a u buněk schopných nést vzorec máme vždy symboly vyvolávající tento dialog, je možné zařadit vzorce ke „komplexním“ hodnotám, tak aby uživatel aplikace nikdy nepřišel do styku s interními identifikátory (inames), ale vždy jen s uživatelskými názvy (titles) typů objektů a parametrů. (V Excelu s tím bohužel nic nenaděláme.) Toho dosáhneme: 

rozšířením výčtového typu „ParValueComplexity“ o nový prvek „Formula“,



přidáním lokalizovaného řetězce „(vzorec)“ [anglicky „(formula)“] a jeho použitím při ownerdraw-kreslení buněk,



rozšířením metody IsParValueComplex(MopParametr mp, string mpvalue) o test na vzorce: vrací hodnotu ParValueComplexity.Formula, pokud parametr mp je schopný nést vzorec (tj. zobrazuje symbol vzorce) a zároveň hodnota mpvalue skutečně nese vzorec (začíná „!!“, tj. např. „!EXT“ nikoli!) …Na pořadí testů výsledek nezávisí, test lze umístit kamkoliv do funkce…

(Dosud „komplexní“ hodnoty byly zavedeny hlavně kvůli nelokalizovaným reálným číslům, nově bude jejich účel i zabránit styku uživatele s inames…)

3.3.3 Rozhraní editace definic / metainformací singulárních parametrů Nejen že v rámci editace definice singulárních vstupů nebude možné editovat vlastní hodnotu, ale v rámci editace definice singulárních výstupů nebude (!) editace „předpisu“. Předpis se bude editovat jako hodnota „fiktivního“ vstupního parametru, který je vždy do páru s fiktivním výstupním parametrem nesoucím vlastní hodnotu singulárního výstupu. Tento fiktivní parametr bude mít strana 71


implementačně podobu pseudo-parametru (na rozdíl od fiktivního parametru hodnoty, který se bude jevit jako regulérní parametr). Tento fiktivní parametr ponese některé stejné metainformace (fyzikální jednotka, identifikace přidružené instance) jako výstupní parametr nesoucí vlastní hodnotu. Některé metainformace má ale jiné, nicméně automaticky odvozené: 

titlercp = title + lokalizovaný sufix [anglicky: „ (recipe)“, česky: „ (předpis)“];



DisplayOrderrcp = DisplayOrder – ½;



commentrcp = comment s předřazeným textem [lokalizovaným] „Předpis pro plnění výstupního parametru {0}, který nese následující komentář:\n\n{1}“,

čemuž je třeba trochu napomoci dalšími podmínkami: 

Title žádného parametru, ať již ne-singulárního nebo singulárního [zadaný title vlastní hodnoty] nesmí končit na lokalizovaný sufix [anglicky: „ (recipe)“, česky: „ (předpis)“];



DisplayOrder ať již ne-singulární, nebo singulární [zadaný] musí být vždy celočíselný.

Předpis se pak edituje stejnými prostředky, jako hodnoty parametrů (singulárních a ne-singulárních) (až na fakt, že – vzhledem že půjde o pseudo-parametr – neplní hodnotu, ale předpis), DisplayOrder však zajišťuje, že v rámci vstupní sady budou „předpisové“ fiktivní parametry řazeny na konci a v rámci výstupní sady budou vždy těsně před fiktivním parametrem nesoucím vlastní hodnotu singulárního parametru. V nabídce Otevřít přibude položka Definice singulárních parametrů. Ta bude otevírat dialog se dvěma záložkami: „Singulární vstupy“ a „Singulární výstupy“. V každé záložce bude zobrazen seznam singulárních parametrů, ale ne ve formě jejich celého 3-složkového „uživatelského názvu“, ale ve stromu se třemi úrovněmi (dle 3 složek „uživatelského názvu“), tj. typ objektu / identifikace instance objektu / název parametru. Strom bude implicitně ve zcela „rozbalené“ podobě. Dále budou v dialogu tlačítka pro vytvoření nové definice parametru, smazání definice parametru a úpravy definice parametru. Tlačítka vytvoření nové definice parametru a úpravy definice parametru otevírají další dialog: 3.3.3.1

Dialog editace definice konkrétního parametru

Dialog se částečně liší pro vstupy a výstupy. V tomto dialogu se informace zobrazují / editují vždy v uživatelsky vhodné formě: tj. 

překládají se iname třídy objektu na title třídy objektu,



identifikační parametry instance se zadává v několika políčkách (jejich počet dle počtu identifikačních parametrů nejprve zvolené třídy),



fyzikální kategorie také nebude reprezentována inamem, ale titlem. strana 72


Se změnou zvolené fyzikální kategorie bude dialog zobrazovat (needitovatelné položky) vlastnosti zvolené fyzikální kategorie: 

formát čísla,



koeficient do základní jednotky SI,



aditivní korekce do základní jednotky SI



a označení jednotky.

Dialog neumožní zvolit jinou fyzikální kategorii, než nějakou z pole PhysCategory[] Teplate, tj. umožní použít jen regulérní kategorii pro reálná čísla. DisplayOrder bude hlídán, aby u singulárního vstupu byl menší než jakýkoliv singulární či nesingulární výstup a u singulárního výstupu byl větší, než jakýkoli singulární či ne-singulární vstup a zároveň menší než jakákoliv „online“ veličina (viz „online“ veličiny). U DisplayOrder bude navíc v rozbalovací nabídce k textovému políčku nabízen (ale ne nucen) seznam (pouze jako nápověda, nikoli pro skutečné zvolení položky – tj. podobně jako odhad délky u úseku) zřetězených trojic {„vst.“ / „výst.“ [lokalizovaně!] + title + DisplayOrder} všech (singulárních i nesingulárních) parametrů dané třídy. Pozn.: Tyto dialogy nenastavují hodnotu ani „předpis“. Seznam náhradních (vykřičníkových) hodnot (pouze u singulárních vstupů) bude zobrazován jako seznam (pod sebou) s možností přidávat, odebírat a editovat existující položky (s tím, že u všech zadávaných položek musí být splněno, že začínají vykřičníkem (pokud ne, je „!“ automaticky přidán) a jinak obsahují pouze velká písmena anglické abecedy). Je třeba přidat nový zvláštní režim volání MOPED pro editaci definic singulárních parametrů z Excelu – zcela analogicky, jako již existují režimy pro editaci cest, filtrů výstupů, apod. Je sice trochu divné dávat uživateli rozhraní pro definici singulárních parametrů z Excelu, když v Excel nemá přístupné rozhraní pro editaci / zobrazení vzorců, které jediné mohou tyto singulární parametry využít, ale: (1)

Zpřístupnění editace / zobrazení vzorců z Excel je ekvivalentní zpřístupnění editace / zobrazení řad z Excelu, které v současnosti také neumožňujeme (především kvůli nutnosti předávat MOPEDu informace o aktivní buňce Excelu, což sice lze, ale dosud se to nikde nepoužívalo; u řad se k tomu přidal argument, že forma oken je nemodální „podřízené okno“, což u vzorců neplatí, tak je to modální dialog, takže tam je argument nepřidávat do rozhraní Excel trochu slabší než u řad),

(2)

Nezamezujeme editaci / zobrazení vzorců (ani řad) z Excel zcela, pouze nezajišťujeme komfort lokalizace reálných čísel a převodu interních identifikátorů (iname) na uživatelsky přívětivé názvy (titles), kdežto u neumožnění editace definic singulárních parametrů z Excelu bychom uživateli tuto možnost v Excel vzali zcela (pokud strana 73


nepočítáme obskurní možnost zviditelnění „velmi skrytých“ listů pomocí editoru VisualBasic).

3.3.4 Rozhraní editace a zobrazení hodnot singulárních parametrů Aplikace bude zajišťovat, aby singulární parametry splňovaly obě následující podmínky:  Singulární parametr smí být přidružen jen k existující instanci. (Tato podmínka není fatální, ale vyžadujeme ji kvůli uživatelské přehlednosti a také kvůli zjednodušení implementace oken návrhové / výsledkové tabulky a návrhové / výsledkové mapy, kdy řádky tvoří pouze skutečně existující instance objektů) Při vytváření definice nového singulárního parametru či při úpravě metainformací o singulárním parametru dialog nepovolí potvrzení, pokud daná instance neexistuje. Při smazání instance (ať již explicitně uživatelem vyžádané či v rámci vedlejšího efektu jiné operace), bude uživatel upozorněn, že budou smazány i singulární parametry (a kolik, příp. jejich plné identifikace „3. úrovně“) a je zobrazen dotaz, zda toto mazání (všeho) opravdu provést. Také bude vhodné provést kontrolu na „osiřelé“ singulární parametry při každém načtení modelu a případné nálezy smazat (s oznámením uživateli).  Singulární parametr smí být přidružen jen k instanci třídy, která se zobrazuje v návrhové tabulce či mapě (tj. efektivně stačí: „která se zobrazuje v návrhové tabulce“). Tj. daná třída musí mít atributy splňující (SuggestAsInvisible = false) && (NoDesign = false). V rámci oken tlakových diagramů není třeba zobrazovat žádné singulární parametry, protože k „uzlům cest“ nelze singulární parametr přidružit. V rámci oken návrhové / výsledkové mapy budou u dané instance případné existující singulární vstupy (včetně „předpisů“ výstupů) zařazeny mezi běžné vstupy (dle DisplayOrder) a analogicky případné existující singulární výstupy budou zařazeny mezi běžné výstupy (dle DisplayOrder). V rámci oken  návrhové tabulky budou pro každou zobrazovanou třídu (prvek stromu v levé části okna) prohledány všechny singulární vstupy i výstupy (obojí: výstupy kvůli editaci „předpisů“)…  výsledkové tabulky budou pro každou zobrazovanou třídu (prvek stromu v levé části okna) prohledány všechny singulární vstupy i výstupy (obojí: kopie vstupů jsou i ve výsledkové sadě)… … a pro každý takový singulární parametr bude vytvořen (dle DisplayOrder) i vlastní sloupec, jehož buňky budou ale pro instance s nepřidruženým příslušným singulárním parametrem začerněny a budou zcela (včetně paste, kliků na symboly, apod.) needitovatelné. Jinak ovládání nezačerněných buněk zůstane standardní, včetně takových věcí, jako je v okně návrhové tabulky zobrazení případného symbolu řady u „předpisu“ singulárního výstupu (jelikož lze, i když to nebude běžné, zadat předpis konstantou, kteroužto {jelikož to není vzorec} může být i řada). Výjimkou je přidání následujícího: strana 74


 U singulárních výstupů (pouze!) bude (v oknech návrhové tabulky / mapy oranžově, v oknech výsledkové tabulky / mapy zeleně) v buňce hodnoty, ještě před (!) případným symbolem řady, zobrazen (velmi úzký – bude u většiny vstupů, tak aby nepřekážel) symbol: 3 čtvercové tečky nad sebou. Klepnutí na tento symbol (nebo klávesová zkratka, např. Ctrl+J) vyvolá dialog editace / zobrazení vzorců – v režimu „B“ – z okna výsledkové tabulky / mapy navíc v režimu „jen pro čtení“. Singulární výstupy (a v rámci výsledkové řady i singulární vstupy) budou zpřístupněny pro export dat pomocí modulu SQLexport. Je však vhodné přiřadit (stejně jako v jiných částech grafického rozhraní aplikace) tyto vstupy ne-singulárním objektům, na které odkazují. Tj. při editaci podprofilu exportu pro danou třídu bude k přiřazení cílového sloupce databázové tabulky nabídnuta každá položka (singulární parametr), který existuje alespoň pro 1 instanci dané třídy. Pro instance této třídy, které daný singulární parametr nemají, bude do databázové tabulky zapisováno vždy NULL.

3.4 Vylepšení stávajících technologických prvků Tato kapitola popisuje změny, které budou vylepšovat stávající technologické elementy MOP, aby byly lépe využitelné pro potřeby systému REGIOS. Všechny tyto funkce budou také k dispozici v rámci MOP.

3.4.1 Dopravní zpoždění zdrojů v dynamickém výpočtu MOP v současnosti nepočítá výsledné hodnoty dopravního zpoždění spotřebičů. Pro REGIOS by však takové hodnoty byly užitečné. Problémem není vlastní výpočtový algoritmus, ale formát výsledků. Výsledné dopravní zpoždění na spotřebiči se ve stacionárním výpočtu nyní ukládá do jediné buňky jako sada oddělených tripletů hodnot {identifikátor zdroje; poměr průtoku od daného zdroje; dopravní zpoždění v minutách od daného zdroje}. Tento formát je nevhodný z několika důvodů:  Hodnoty jsou vždy uvedené s desetinnou tečkou, namísto použití lokalizovaného formátu podle aktuálního prostředí (Moped, XLS);  Na rozdíl od všech ostatních vypočítaných hodnot, kdy je počet desetinných míst konfigurovatelně určen transformací výsledných hodnot po výpočtu, je hodnotám zpoždění přímo ve výpočtu osekán počet desetinných míst…  Vlastní hodnota zpoždění je v minutách a na rozdíl od ostatních hodnot zpoždění (na zdroji, zpoždění úseků) není konfigurovatelná skrze mechanismus fyzikálních kategorií;  Formát hodnoty v současnosti neumožňuje nést řadu a ani po jeho přizpůsobení by případné vnořené řady trpěly nedostatkem kapacity délky použitého řetězce. Zejména z posledního důvodu je nutné formát zpoždění spotřeby zcela přetvořit. Nový formát bude odstraňovat veškeré nestandardní jevy okolo starého formátu a všechny výše uvedené problémy. Formát bude postaven na principu „čistě výstupních objektů“, který již je použit u objektů typu „uzel cesty“ použitého jako datová základna pro tlakové diagramy. strana 75


Nový formát bude založen na novém typu objektu: „Dopravní zpoždění spotřeby“. Protože je potřeba zachovat kompatibilitu s MOPem, musí být tento typ objektů (s veškerými v této podkapitole popisovanými změnami) zařazen i do formátu MOP. Na úrovni MOP sešitu XLS bude pro tento typ objektu vytvořen nový list „Zp+“ (v anglické lokalizaci „De+“). List v XLS bude normálně viditelný (na rozdíl od listu „uzlů spotřeby“, který plní pouze roli datové základny pro zobrazené tlakové diagramy). Objekt „Dopravní zpoždění spotřeby“ bude mít identifikační parametry „from_source“, „to_consumer“ a výstupní parametry „coef“ a „taud“. Ty budou plněny namísto dosavadního parametru „taudstring“ spotřebičů, který bude zrušen. V MOPED budou nové typy objektů „Dopravní zpoždění spotřeby“ standardně vidět v samostatné položce v oknech výsledkových tabulek. Dále budou (pouze ve výsledkových mapách) tyto hodnoty vidět jako „pseudo-parametry“ objektů „spotřebič“. Zde bude existovat nepravidelnost: počet pseudo-parametrů u spotřebiče nebude předem znám, protože nebude znám počet zdrojů, ze kterého pochází médium přicházející do spotřebiče. Pouze se vždy tyto parametry vyskytují ve dvojici „koeficient“ a „vlastní hodnota zpoždění“. Následně může být kód modelu a souvisejících datových „adaptérů“ výrazně pročištěn. Management kolem ZpozdeniOdJednotlivychZdroju v MopModelAdapter (za běhu kompilovaný kód) bude zrušen. Příznak „EmptyIfDynamicsOn“ bude zrušen. V důsledku toho lze smazat metodě isEmptyDueToSpecialFlag [2 varianty] parametr mp_emptyIfDynamicsOn a tudíž i nadále nepotřebný parametr „dynamics“ (plněný v za-běhu-kompilované metodě) příznakem „isdyn4emptying“ (ten s tímto také zrušit) v metodě RetrieveParams (té také zrušit parametr „isdyn4emptying“!) a dále zrušit proměnnou „dynamics“ v metodě „isIntentionallyEmpty“... Pak je také nutné metodám Compiled_FilterModel_RetrievePa-rams, Compiled_PathEditModel_RetrieveParams, Compiled_NeuroModel_RetrieveParams a Compiled_MainModel_RetrieveParams ubrat 1. booleovský parametr... Celkově pak může být celý kód aplikace očištěn (mimo vlastní výpočet modelu) od tříd ZpozdeniOdZdroje, ZpozdeniOdZdrojeN a ZpozdeniOdJednot-livychZdroju a enumu OutValueType bude odebrána položka ZpozdeniOdZdroju.

3.4.2 Řízení zdrojů podle požadovaného výkonu Je třeba mít možnost zadávat zdroje nikoli pouze podílem průtoku, ale i absolutním výkonem. Zároveň je ale vhodné ponechat i možnost zadávat podíl průtoku (protože o tom víme, že vždy konverguje, u výkonu to není jisté). Dosavadní pravidla vztahující se k zadávání podílu průtoku budou zrušena (kontrola na sumu rovnou 1; kontrola na sumu s výjimkou zdroje s „!CALC“ na < 1; pravidlo použití „!CALC“). Tomu bude odpovídat úprava komentáře k parametru „Podíl průtoku“. Zároveň makra kompatibility zajistí, aby případná hodnota „!CALC“ v „podílu průtoku“ byl nahrazen takovým číslem, aby součet podílů průtoku všech zdrojů byl roven 1. Zavedeme 3 nové parametry: „Pořadí nasazení“, „Požadovaný výkon zdroje“, „Požadovaný průtok zdrojem“. V tomto pořadí budou vsazeny před parametr „Podíl na celkovém průtoku“. Makra kompatibility tyto 3 nové parametry naplní takto: Pořadí „1“, zbylé dva parametry budou „!CALC“. strana 76


Parametr „Pořadí nasazení“ bude využíván jak u zdrojů daných výkonem či absolutním průtokem, tak u zdrojů daných poměrem průtoku (u těch zejména při využití obou druhů zdrojů v jedné síti). Protože průtok pro všechny zdroje může být celkově vyšší než spotřeba v síti, je třeba nějak určit, které zdroje budou svůj výkon uplatňovat prioritně. Čím nižší hodnota „pořadí“, tím vyšší priorita. Abychom mohli zadávat i časovou řadu, nemůžeme omezovat hodnotu „pořadí“ na celá čísla, jsou to tedy obecně „reálná čísla či řada“, tj. např. vč. záporných hodnot. Každý zdroj bude muset mít z trojice parametrů [„Požadovaný výkon“, „Požadovaný průtok“, „Podíl průtoku“] zadán právě 1 parametr hodnotou a zbylé 2 parametry „!CALC“. Počítá se s tím, že zadání nemusí být dodrženo, dle zadaného pořadí… Je žádoucí, aby se algoritmus vypořádal i se shodnou hodnotu „Pořadí nasazení“ u více zdrojů. Jelikož v tomto případě není vhodné, aby případné navýšení / snížení bylo na zdroje uplatněno rovnoměrně, např. protože by při snížení průtoku u některých zdrojů mohlo podkročit nulu, musí se případné navýšení / snížení redistribuovat mezi zdroji v poměru k původnímu (nesníženému / nenavýšenému) průtoku. 3.4.2.1

Algoritmus implementace řízení zdrojů

Během výpočtu je nyní na počátku vnější iterace vyhodnocován celkový průtok sítí (víceméně spotřeba) a zadané podíly průtoků jednotlivými zdroji a na základě toho jsou určeny průtoky jednotlivými zdroji. V tomto místě lze také určit průtok zdrojem přímo ze zadání požadovaného průtoku, případně s pomocí hodnot teplot přívodu a vratu (z minulé iterace) z požadovaného výkonu. Máme tedy požadavky na (absolutní) průtok pro všechny zdroje. Následně ho uplatníme až do výše celkového průtoku v síti, dle zadaného pořadí zdrojů – tj.: 1. Pokud bude celkový průtok v síti vyšší než suma požadovaných průtoků zdroji, bude průtok navýšen u zdroje s nejvyšším „pořadím“. 2. Pokud bude celkový průtok v síti nižší než suma požadovaných průtoků zdroji, bude průtok snížen u zdroje s nejvyšším „pořadím“… Pokud by byl sražen až na nulu, pokračuje se stejně u zdroje s druhým nejvyšším pořadím…, atd. případně s dalšími zdroji dle snižující se hodnoty „pořadí“. Při zadání stejného „Pořadí nasazení“ u více zdrojů se případné navýšení / ponížení průtoku zdrojem mezi těmito zdroji přerozdělí proporčně vzhledem k poměru původních průtoků. To má vedlejší efekt: Pokud budou zdroje zadány „Poměrem k celkovému průtoku“, není potřeba sumu těchto poměrů při zadání normovat na 1, přesto budou poměry vždy zachovány (Pokud tedy budou mít všechny zdroje shodné „pořadí nasazení“).

strana 77


3.4.3 Generátor výstupní teploty Generátory výstupní teploty (GVT) budou výpočetní subsystémy REGIOS (nikoli tedy MOP), které nahrazují zadání výstupní teploty ze zdroje složitějším výpočtem (zatímco ve vstupním parametru výstupní teploty ze zdroje bude uvedeno „!EXT“). Základem pro výpočet výstupní teploty bude tzv. „předvídaná teplota okolí“, což je teplota okolí, ale nikoli přímá hodnota, ale klouzavý průměr v budoucím intervalu. Velikost průměrovacího okna, stejně tak jako jeho vzdálenost v čase od aktuálně počítaného kroku bude závislá jak na daných specifikách spotřebitelské oblasti, která je přilehlá k danému zdroji (převážně střední dopravní zpoždění od paty oblasti k těžišti spotřeby), tak na aktuálním průtoku touto oblastí… Kvůli „předvídané teplotě okolí“ je třeba, aby teplota okolí byla jak v predikčním, tak v analytickém režimu transformována v širším intervalu (směrem do budoucna), než je výpočetní interval modelu. Stejně tak v simulačním režimu je vhodné nastavit teplotu okolí až za konec výpočetního intervalu Z „předvídané teplota okolí“ bude nalezena výstupní teplota v tzv. „teplotním diagramu“. Teplotní diagram je pole definované kódem DLL (ať již zafixované v kódu, či otevřené z konfiguračního souboru), které několika různým „předvídaným teplota okolí“ přiřazuje výstupní teplotu ze zdroje. Pokud je aktuální „předvídaná teplota okolí“ v kroku výpočtu někde mezi dvěma prvky tohoto pole, je výsledek lineárně interpolován. Pokud je hodnota pod spodní či nad horní mezí definovanou tímto polem, je výsledek protažen konstantně z dané mezní výsledné hodnoty. Lze si dále na konkrétních soustavách představit kritéria korekcí, které v určitých mezích budou výslednou teplotu výstupu dále zvyšovat či snižovat, např. v závislosti na výkonu k dispozici.

3.5 Rozhraní specializovaných výpočetních objektů V této kapitole jsou stručně popsány návrhy rozhraní pro specializované výpočetní objekty, které budou implementovány v dalších fázích projektu.

3.5.1 Objekt statického akumulátoru Vedle předpokládaných specializovaných zdrojů, které vnitřně zahrnují statický akumulátor, bude potřeba implementovat i samostatný objekt statického akumulátoru. Na rozdíl od ostatních specializovaných technologických objektů (zdroje, spotřebiče), které lze implementovat v rámci současného formátu modelu jen jako řídicí nadstavbu existujících objektů MOP / REGIOS, bude muset být akumulátor implementován jako nový samostatný objekt, tudíž je potřeba modifikovat společný formát modelu MOP / REGIOS, tj. objekt akumulátoru bude k dispozici i v MOP (na rozdíl od specializovaných spotřebičů a zdrojů). Rozhraním do sítě soustavy bude u akumulátoru obecně toto: Vstupy budou: strana 78




průtok přívodem vstupující větvě



teplota na výstupu přívodu vstupující větve,



tlak na výstupu přívodu vstupující větve.

Výstupy budou: 

průtok z/do akumulátoru (z akumulátoru: kladný, do akumulátoru: záporný),



teplota vystupující z akumulátoru (pouze v případě kladného průtoku).

Dále bude akumulátor mít zadané některé konstrukční parametry, jako např. kapacitu. Mezi další, „volné“, vstupy patří parametry řídící nabíjení a vybíjení a iniciální parametry (nesmějí být zadány řadou, ale jen konstantou) zahrnující „iniciální teplotu“ a „iniciální objem“.

3.5.2 Objekty specializovaných spotřebičů Specializované spotřebiče nebudou využívat technologii neuronových sítí, ale jejich výkonové chování a chování teploty vratu / vychlazení bude definováno jinak. Bude implementován typ „budova / skupina budov“. Výkonové chování objektu a chování teploty vratu / vychlazení bude definováno pomocí fyzikálně-technologického modulu budovy, který zahrnuje jak teplo využité k vytápění, tak ohřev teplé užitkové vody. Výstupem ze specializovaného spotřebiče je dvojice {příkon; teplota vratu}. Vstupem je stav sítě { teplota přívodu }, různé konstrukční parametry a nakonec volné parametry, zejména { teplota okolí }.

3.5.3 Objekty specializovaných zdrojů Definujeme vektor P zcela fixních „konstrukčních“ parametrů objektu. Nemusí jít přímo o fyzikální popis, ale i vyšší abstrakci – postačující pro body 2 a 3 – viz níže… Definujme vektor S „neměnných“ parametrů stavu sítě S = (teplota okolí, sluneční jas, teplota vratu na vstupu do zdroje) a vektor X „volných“ parametrů zdroje (vše co potřebuje zdroj vědět navíc k S, aby určil jednoznačně výkon zdroje a teplotu přívodu. Poznámka: Průtok (či výkon) zdroje je volný parametr, nikoli neměnný stav sítě, protože obecně je určován nadřazenou optimalizací [i přes to, že třeba s jediným zdrojem je průtok fakticky daný].) Zdroj je v zásadě definován těmito informacemi: 1. definice obsahu vektorů S, X a P;

strana 79


2. definice pracovní oblasti6 v proměnných X, S, a P – tj. pro která (S, P, X) funguje níže popsaná funkce {výkon; teplota přívodu} – tj. prakticky nejlépe rozsah X v závislosti na (S, P) [obecně vnitřní oblast libovolného počtu obecných křivek, např. 4 obecných křivek výkon_min, výkon_max, teplota_přívodu_min, teplota_přívodu_max; trochu úžeji třeba obecný čtyřúhelník, speciálně obdélník (např. plynový kotel či termo-solární článek s akumulátorem a výměníkem)] 3. definice funkce {výkon; teplota přívodu} v závislosti na (S, P, X) a definice inverzní funkce X v závislosti na (S, P, výkon, teplota přívodu). Budou implementovány typy „foto-termický (termo-solární) zdroj“, „bioplynová stanice“, případně možná „tepelné čerpadlo“.

3.6 Vylepšení obecných schopností 3.6.1 Výpočtově neutrální sada dat Vedle návrhové a výsledkové sady vznikne ještě třetí sada – „(výpočtově) neutrální“. Vedle tabulek omc_d_* a omc_r_* souborů „.model“ vzniknou pro neutrální třídy ještě tabulky omc_x_*. V souborech „.xls“ budou „ouška“ listů odpovídající neutrálním třídám mít světle modrou barvu podbarvení. Třídy patřící do neutrální sady mají atribut „CalcNeutral“ a nemohou existovat v návrhové či výsledkové sadě (což zkontroluje metoda checkInstancesConsistency). Třídy s atributem „CalcNeutral“ nemohou mít výstupní parametry. Kód jednotlivých oken bude přijímat vedle mis (u výsledkových oken naplněno rmis, u návrhových dmis) i neutrální sadu xmis. Tam kde bude okno konzumovat sadu mis v režimu jen-pro-čtení, lze použít za běhu generovaný IEnumerable objekt sjednocení mis a xmis. Objekty neutrální sady se někdy chovají jako návrhové, jindy jako výsledkové a někdy jako ani jedno z toho… Je třeba tuto sadu uchovávat, načítat a ukládat (z / do „.xls“ i z / do souboru „.model“). Sada nebude přístupná pro import dat pomocí GISimport. Je však možné ji zpřístupnit do exportu dat pomocí SQLexport (v případě singulárních objektů: přes fiktivní přiřazení ne-singulárním objektům – viz singulární parametry obecně). V rámci výpočtově neutrální sady budou existovat objekty uživatelských formulářů a jejich prvků, dále „online“ veličiny a „online“ transformace.

6

Vlastní určení pracovního bodu není řešeno v rámci implementace zdroje, ale v rámci nadřazeného algoritmu REGIOS využívajícího např. optimalizace řazení zdrojů, GVT, apod. …tj. nadřazený kód garantuje, že funkce {výkon; teplota přívodu} i inverzní funkce budou volány jen na definičním oboru!

strana 80


3.6.2 Konfigurovatelné jednotky veličin Je nutné, aby všechny typy vstupních i výstupních veličin měly konfigurovatelnou jednotku. Např. dle místních zvyklostí by uživatelé mohli používat průtoky buď v t/h nebo v kg/s. Prakticky se to bude konfigurovat na úrovni kategorií veličin. Spolu s každou jednotkou se vždy musí nastavit i koeficienty to_basesi_coef a to_basesi_corr. Speciální fixní kategorie „?“, „-“ a „=“ nebudou mít konfigurovatelnou jednotku, to_basesi_coef ani to_basesi_corr. Teoreticky by bylo možné soubor „.model“ ukládat vždy v základních jednotkách a při prezentaci uživateli je přepočítávat na zvolené jednotky. Problémem je, že při ukládání do souboru „.xls“ toto použít nelze, jelikož sešit Excel slouží nejen jako úložiště vstupů a výstupů, ale i jako prezentační rozhraní pro uživatele. Druhým problémem je, že při přepočtu výsledků mezi uživatelskými jednotkami by se narušoval daný numerický formát. Řešením prvního problému je ukládat data stále v uživatelských jednotkách, ale zároveň s modelem (soubor „.model“ i sešit „.xls“) ukládat i zvolenou konfiguraci nastavení jednotek všech veličin. Řešením druhého problému je uchovávat sadu nastavení jednotek zvlášť pro návrhovou a výsledkovou sadu. Přibydou listy „J“ a „J+“ („jednotky“) [anglicky: „U“ a „U+“] („units“), implicitně neviditelné. Tyto listy budou obsahovat sloupce: (1) vnitřní identifikátor fyzikální kategorie, (2) text zvolené jednotky, (3) násobný koeficient převodu do základní SI jednotky, (4) aditivní korekce převodu do základní SI jednotky. List „J“ se nebude editovat přímo, ale prostřednictvím dialogu Prediktor / MOPED vyvolávaného z nabídky Otevřít. List „J+“ bude duplikován ze svého ekvivalentu v návrhové sadě v okamžiku výpočtu – konkrétně ještě před plněním vstupů výpočtu. Jednotlivé položky listů „J“ a „J+“ budou odpovídat typu objektů UserUnit, který bude mít atribut SuggestAsInvisible = true. Samotné parametry objektů typu UserUnit nesmí mít fyzikální typ s konfigurovatelnou jednotkou! Typ objektů UserUnit (iname = „unit“, title [česky] = „Jednotka“, title [anglicky] = „Unit“) bude mít parametry: 

[identifikační parametr; text] physcat (title [česky] = „Fyzikální kategorie“, title [anglicky] = „Physical category“, comment [česky] = „Interní invariantní identifikátor fyzikální kategorie: Neměl by být nikdy zadáván ručně, ale pouze skrze příslušné dialogy.“, comment [anglicky] = „Internal invariant identifier of the physical category: It should be never set manually. Only corresponding dialog should be used to set it.“) – vnitřní identifikátor fyzikální kategorie



[vstupní parametr; text] unittext (title [česky] = „Text jednotky“, title [anglicky] = „Unit text“, comment nedefinován) – text zvolené jednotky



[vstupní parametr; double] to_basesi_coef (title [česky] = „Koeficient do zákl.“, title [anglicky] = „Coefficient to base“, comment [česky] = „Násobný koeficient pro přepočet do základní jednotky SI“, comment [anglicky] = „Multiplicative coefficient for conversion to base SI unit“) – multiplikativní koeficient převodu dané jednotky do základní SI jednotky strana 81




[vstupní parametr; double] to_basesi_corr (title [česky] = „Korekce do zákl.“, title [anglicky] = „Correction to base“, comment [česky] = „Aditivní korekce pro přepočet do základní jednotky SI (až po násobení multiplikativním koeficientem)“, comment [anglicky] = „Aditive correction for coversion to base SI unit (after multiplicative coefficient used)“) – aditivní korekce převodu dané jednotky do základní SI jednotky

Pro každou ne-speciální fyzikální kategorii musí každý model vždy právě jeden objekt typu UserUnit. Při otevírání modelu bude kontrolováno, zda nějaká jednotka chybí, či zda není použita neexistující kategorie. V případě neexistující kategorie je takovýto objekt jednotky ignorován, ale je o tom uživateli zobrazeno varovné hlášení. Při chybějící jednotce pro existující ne-speciální fyzikální kategorii je doplněna „implicitní (ne-základní) jednotka“ pro danou kategorii a je o tomto doplnění uživateli zobrazeno hlášení. Při každém otevření modelu (ať již z „.xls“ či ze souboru „.model“) se načte i seznam objektů UserUnit, spolu s návrhovou a výsledkovou sadou zvlášť. Při každé změně jednotky v dialogu budou všem parametrům všech objektů vstupní a také neutrální (!) sady změněna hodnota (včetně singulárních vstupů s dynamicky definovanou kategorií) – přepočtena z předchozích uživatelských jednotek do základních SI jednotek a následně do nových uživatelských jednotek. Navíc je třeba přestat považovat obsah buněk druhých řádek všech listů sešitu „.xls“ čistě za hlavičku. Tyto řádky sice není třeba nikdy číst (případná jejich ruční změna nebude mít žádný efekt), ale všechny tyto druhé řádky se budou zapisovat vždy se zápisem dat! Zapisován při každém zápisu však bude jen obsah těchto buněk, nikoli formát (barva, aj.). Zároveň je třeba se v aplikaci zbavit všech pevných závislostí na konkrétní jednotce – jak v kódu, tak v rozhraní Excel, apod.: Např. je třeba eliminovat všechny výskyty jednotek "m.n.m" a "kPa" u názvů tlakových diagramů… V kódu budou i nadále uloženy (ne-základní) uživatelské jednotky, ale budou považovány za (a přejmenovány na) „implicitní uživatelské jednotky“ – pro všechny fyzikální kategorie. Nově se použijí ve dvou případech: (1) v Moped: při chybějící kategorii (viz text výše) a také (2) v makrech kompatibility při založení základní sady jednotek v „J“ a „J+“. [Lze si také do budoucna představit i uživatelskou nastavitelnost těchto implicitních jednotek: přesun těchto definic z kódu do sady konfiguračních souborů (buď pouze implicitní konfigurační soubor nebo trojice souborů implicitní, globální a uživatelský) Ovšem takové řešení nebude mít vliv na bod (2), tj. požití v makrech kompatibility. Typ UserUnit bude mít nastaven atribut „NotInSchema“, aby se neukládal do schématu. To je z toho důvodu, že ve schématu by měly mít logicky objekty UserUnit dvě neslučitelné funkce: za prvé by vždy fixovaly změnu uživatelských jednotek (což navíc asi nikdy nechceme) a za druhé by definovaly strana 82


jednotky, ve kterých jsou ve schématu uloženy hodnoty. Proto pro přehlednost rozhodneme, že objekty UserUnit ve schématu nebudou a: 1. Objekty UserUnit nejdou schématem fixovat; 2. Jednotka hodnot uložených přímo ve schématu je základní jednotka7 SI pro danou kategorii. Všem (aspolu s MOP či REGIOS) dodávaným vzorovým variantám, ať již v souborech „.xls“ nebo „.model“ (včetně „prázdných“ vzorů „.xls“ a „prázdných“ šablon-modelů) bude doplněna sada definic implicitních (v současnosti v MOPu používaných) jednotek UserUnit (analogicky k již podobně použité sadě výstupních filtrů „all“ a „none“). Již MOP umí konfigurovat numerický formát jednotlivých fyzikálních kategorií. Toto nastavení je ale implicitní, globální či per-user. Nyní by bylo pro jednoduchost asi vhodné toto nastavení předělat na per-model a sjednotit ho s konfigurací jednotek. Makra kompatibility do každého modelu vloží nastavení numerických formátů dle nastavení MOPEDu – ale nikoli per-user či globálního nastavení, ale jen implicitního nastavení.

3.6.3 Nemodální výsledkový dialog a časově specifická varování Stávající modální dialog zobrazovaný po dokončení výpočtu je třeba nahradit znovu-vyvolatelným oknem. Obsah dialogu se bude uchovávat, tj. dialog bude zobrazen hned po výpočtu, ale nemodálně, a půjde také i kdykoliv jindy otevřít ručně z aplikační nabídky (také nemodálně). Vždy bude možná maximálně jedna instance tohoto typu okna: Pokud je okno již zobrazeno, aplikace se do něj pouze přepne (pokud je minimalizované, tak se při tom de-minimalizuje). Navíc k obsahu bude případné otevřené okno ukládané i v rámci „desktopu“ modelu. Nějakým způsobem je třeba uživateli zdůraznit, že ten později vyvolaný dialog s uchovanými hlášeními (informace / upozornění / varování / nefatální chyby) obsahuje hlášení z naposledy úspěšně dokončeného výpočtu, nikoli tedy z případných následných výpočtů, které skončili fatální chybou a tudíž se ani neuložily výsledky. Ideální místo pro tuto zmínku je přímo v tomto okně (ale mimo vlastní texty hlášení). Nyní mají jednotlivá hlášení danou úroveň závažnosti (severity level) 0-4, ale ta se uživateli zobrazuje pouze ve formě stylu textu (barva, styl fontu, …). Toto rozlišení zůstane zachované, ale zároveň se úroveň hlášení zobrazí také číselně.

7

Teoreticky si lze představit též použití „implicitní uživatelské jednotky“, avšak tuto je možné v budoucnu měnit a určitě nechceme, aby se tím rozbily existující „schémata“.

strana 83


Obsah dialogu se bude uchovávat v objektech typu CalcMessage0 / CalcMessage1 / CalcMessage2 (což bude „čistě výstupní“ objekt, stejně jako např. objekt „uzlu cesty“; také bude mít příznak nezobrazování v okně výsledkové tabulky), které jsou společně potomky typu CalcMessage. Objekty se budou ukládat do souborů „.model“ v tabulkách omc_r_calcmessage0, omc_r_calcmessage1, omc_r_calcmessage2 a do souboru „.xls“ se budou ukládat do listů „VHl0+“ / „VHl1+“ / „VHl2+“ [anglicky „CMsg0+“ / „CMsg1+“ / „CMsg2+“] (vnitřní názvy budou „o_calcmessage0“, „o_calcmessage1“, „o_calcmessage2“; barva „oušek“ listů bude standardní zelená určená pro výsledky; listy však budou implicitně neviditelné). Abstraktní typ CalcMessage (iname = „calcmessage“, title [česky] = „Zpráva výpočtu“, title [anglicky] = „Calculation message“; atributy „WaterInstancesAllowed“ = false a „SteamInstancesAllowed“ = false, „NoDesign“ = true, „SuggestAsInvisible“ = true) bude mít pouze 2 parametry a oba identifikační (i když první z nich by mohl být z funkčního hlediska i výstupní, ale pak bychom museli změnit pořadí prvního a druhého sloupce, což by bylo zejména pro typy CalcMessage1 a CalcMessage2 nepřehledné): 

Úroveň závažnosti (iname = „severity_level“, title [česky] = „Úroveň závažnosti“, title [anglicky] = „Severity level“, comment nedefinován) – číslo vyjadřující závažnost (a nepřímo pořadí v zobrazení) daného hlášení;



Text vlastního hlášení (iname = „message_text“, title [česky] = „Text“, title [anglicky] = „Text“, comment nedefinován) – text, v případě potomků CalcMessage0 kompletní, v případě ostatních potomků uvozující následnou hodnotu.

Typ CalcMessage0 (potomek typu CalcMessage; iname = „calcmessage0“, title [česky] = „Prostá zpráva výpočtu“, title [anglicky] = „Plain calculation message“; atributy „NoDesign“ = true, „SuggestAsInvisible“ = true) nebude přidávat k předkovi žádné další parametry, pouze (stejně jako ostatní potomci přidává atributy „WaterInstancesAllowed“ = true a „SteamInstancesAllowed“ = true). Typ CalcMessage1 (potomek typu CalcMessage; iname = „calcmessage1“, title [česky] = „Zpráva výpočtu s číslem“, title [anglicky] = „Calculation message with a number“; atributy „NoDesign“ = true, „SuggestAsInvisible“ = true) přidává výstupní atribut: 

Číselná hodnota k textu hlášení (iname = „attached_number“, title [česky] = „Hodnota“, title [anglicky] = „Value“, comment nedefinován) – vyjadřující číselnou hodnotu vztahující se k hlášení – např. k hlášení „Počet spotřebičů“ skutečný počet spotřebičů.

Typ CalcMessage2 (potomek typu CalcMessage; iname = „calcmessage2“, title [česky] = „Zpráva výpočtu s řadou“, title [anglicky] = „Calculation message with a series“; atributy „NoDesign“ = true, „SuggestAsInvisible“ = true) přidává výstupní atribut: 

Hodnota typu číselné řady k textu hlášení (iname = „attached_series“, title [česky] = „Hodnota“, title [anglicky] = „Value“, comment nedefinován) – vyjadřující hodnotu ve formě číselné řady vztahující se k hlášení – např. k hlášení „Počet okruhů“ skutečný počet funkčních okruhů v daném kroku dynamického výpočtu či k hlášení „Nepodařilo se dodržet výstupní strana 84


teplotu na spotřebiči“ řadu vyjadřující časovou relevanci varování – hodnotou „1“ kroky, ke kterým se varování vztahuje, přičemž pro ostatní kroky bude mít řada hodnotu „0“. (Přirozeně v tom případě řada bude mít alespoň někde hodnotu 1, jinak by příslušné hlášení vůbec nebylo generováno.) Pozn.: Z důvodů implementace plnění výstupních parametrů ve výpočtu modelu je nutné, aby i v případě stacionárního výpočtu byly typy CalcMessage1 a CalcMessage2 oddělené, přestože oba nesou ve třetím sloupci konstantní hodnotu a nikoli řadu. V dialogu nastavení aplikace umožnit nastavit, aby se volitelně (ale pouze když nenastane žádná chyba ani žádné varování) dialog po dokončení výpočtu automaticky nezobrazoval8. Vlastní okno obsahující oznámení / varování / chyby bude v sobě kombinovat všechny typy CalcMessage0, CalcMessage1 i CalcMessage2 – ve formě jediné tabulky - co řádek, to hlášení. Úroveň závažnosti bude v 1. sloupci. Text hlášení bude v 2. sloupci (zároveň bude zbarven / nastylován dle úrovně závažnosti). Pokud půjde o typ CalcMessage0, bude buňka 3. sloupce prázdná. Pokud půjde o typ CalcMessage1 bude 3. sloupec nést číselnou hodnotu a pokud půjde o typ CalcMessage3, ponese 3. sloupec v případě stacionárního výpočtu taktéž číselnou hodnotu, ale v případě dynamického výpočtu ponese buňku s textem „náhradní hodnoty“ spolu se zeleným symbolem řady vyvolávajícím dialog výběru zobrazení řady (stejně jako buňky v podřízených oknech výsledkové mapy a tabulky). V případě přímého volání výpočtu z Excelu, případně při explicitním vyvolání tohoto okna přímo z Excelu, budou tyto symboly nepřístupné (neviditelné). Pořadí jednotlivých hlášení v tabulce (a tudíž pořadí objektů typu CalcMessage) nebude nést žádnou podstatnou informaci (stejně jako nenese pořadí žádných jiných objektů), nicméně tyto objekty budou generovány tak, aby hlášení s nejvyšší úrovní závažnosti byla zobrazena nahoře. Vlastností tohoto řešení bude, že text hlášení zůstává nezměněn, pokud uživatel aktualizuje systém na novější verzi (která by mohla text hlášení změnit) nebo přepne z jedné jazykové verze na jinou. Změny se každopádně projeví až po novém (úspěšném) přepočtu modelu. Bude zaveden nový speciální režim volání aplikace MOPED/Prediktor, který zobrazí tento dialog, ale modálně! Do nabídky Mop v Excelu přibyde volba vyvolávající tento režim. Zároveň ani v dynamickém výpočtu nebude v případě volání z Excelu možné vyvolat dialog zobrazení řad z buněk nesoucích řadu.

8

Neměl by to být problém ani pro stávající uživatele MOP, ani pokud používají výpočet vyvolávaný z Excelu, protože MOPED je v současnosti součástí všech dodávek MOP a do budoucna bude také MOPED povinnou součástí dodávky. Pokud by tomu tak nebylo, byli by uživatelé odkázáni na ruční změnu konfiguračního souboru nebo by bylo potřeba implementovat speciální režim volání MOPED pro zobrazení konfiguračního dialogu…

strana 85


Ideální by bylo, kdyby ta hlášení, která se nevztahují k mimořádné situaci při výpočtu (tj. zejména k varováním a chybovým hlášením) ani k informaci o úspěchu výpočtu byla přesunuta mimo objekty CalcMessage[#], logicky do výstupních parametrů objektu „Síť“. Jedná se o hlášení, která jsou zobrazena (alespoň po úspěšném) výpočtu vždy. Jde zejména o počty elementů daného typu v síti.

3.7 Vylepšení uživatelského rozhraní Tato kapitola popisuje změny, které budou výhodou pro zadávání konkrétních singulárních vstupů a přehlednou volbu zobrazení singulárních výstupů, ale obecně se singulárními parametry nesouvisejí a jsou plně využitelné i pro ne-singulární vstupy a výstupy. Všechny tyto funkce budou také k dispozici v rámci MOP.

3.7.1 Grafické zadávání vstupů Grafické zadávání bude moci být použito na jakýkoliv vstup, pro některé konkrétní (např. venkovní teplota) se však předpokládá častější použití. Návrhové okno vstupní řady bude mít pro následující typy řad (v režimu „výběru“, který dosud neměl v okně návrhu řady žádný význam, a který bude pro návrhové okno označen jako režim „změny“) následující funkce: (Pozn.: Všechny následující popisy činností myši – klepnutí, tažení, atd. – se provádějí primárním [tj. dle nastavení systému; většinou levým] tlačítkem myši.)  Řada typu konstanta: klepnutím do grafu dojde k nastavení konstanty na Y-hodnotu klepnutí. Pro jemnější nastavení, resp. větší jistotu uživatele při nastavování bude hodnota změněna při události mouse-down a také při každé události mouse-move v případě down-stavu tlačítka.  Řada typu „lomové body“ (nepravidelná řada): 1. Klepnutím do grafu (bez shift či ctrl) dojde (pouze v případě, že je v epsilon-vzdálenosti od X-souřadnice kreslení přítomen alespoň jeden lomový bod; pokud je jich více, vezme se nejbližší) ke změně hodnoty tohoto lomového bodu na Y-hodnotu klepnutí. I pokud byla původní hodnota lomového bodu nespojitá, bude nová hodnota spojitá. 2. Klepnutím do grafu (se shift) dojde k vložení nového lomového bodu do času odpovídajícího X-hodnotě klepnutí a s hodnotou (spojitou) Y-hodnoty klepnutí. 3. Klepnutím do grafu (s ctrl) dojde (pouze v případě, že je v epsilon-vzdálenosti od Xsouřadnice kreslení přítomen právě jeden lomový bod) k jeho smazání (pokud to ovšem nebude jediný lomový bod řady!). Analogicky k mazání lomového bodu z textového zobrazení řady nebude zobrazen dialog potvrzení, aby uživatel mohl operaci odmítnout. strana 86


Pozn.: Epsilon v předchozích 2 odstavcích bude shodné s epsilon použitým v citlivosti klepnutí v mapě, v mapových oknech. Pozn.: Pro body (1) a (2): Pro jemnější nastavení, resp. větší jistotu uživatele při nastavování bude hodnota změněna při události mouse-down a také při každé události mouse-move v případě down-stavu tlačítka; přesněji: Aktualizuje se hodnota dle Y-souřadnice a časový okamžik dle X-souřadnice, ale lomový bod zůstává tentýž jako při iniciální mouse-down události. V případě takové změny X-souřadnice, která změní pořadí lomových bodů, bude sada lomových bodů přetříděna, aby byla zachována vzestupnost časového údaje. Pro konzistenci s ovládáním mapových oken (a také pro snadnou práci uživatelů, kteří nemají zažitý význam modifikátorů shift- a ctrl- při ovládání tohoto okna) budou vedle režimu výběru (tlačítko nástrojové lišty + položka nabídky s obrázkem šipky) zavedeny ještě další 2 režimy pro vkládání nových hodnot (obrázek šipky se symbolem „+“) a mazání hodnot (obrázek šipky se symbolem „-“), které budou mít pouze jednu funkci – a to buď (2) nebo (3), ale bez modifikátorů shift- a ctrl-…  Řada typu „rastr“ (pravidelná řada): Při události mouse-down na komponentě grafu se činnost aktivuje, při události mouse-up (ale nejen na komponentě grafu, ale pokud možno kdekoliv v okně) se činnost deaktivuje. Činností rozumíme následující: (Označme M délku kroku rastru editované řady.) Pokud se kurzor myši pohne (událost mouse-move) nebo při započetí činnosti (událost mouse-down) nad komponentou grafu, a pokud není o více než M/2 nalevo od času 1. hodnoty rastru a také není o více než M/2 napravo od času poslední hodnoty rastru, bude jeho X-souřadnice zaokrouhlena na nejbližší časovou hodnotu rastru a tato příslušná hodnota bude okamžitě přepsána (bez přerušení činnosti) hodnotou odpovídající Y-souřadnici kurzoru. V případě, že uživatel během činnosti provede rychlý pohyb myší po grafu, budou položky rastru přeskočené metodou vyvolávanou na mouse-move doplněny lineární interpolací s použitím předchozích hodnot této metody…

3.7.2 Obalové křivky tlakového diagramu V obou typech talkového diagramu se budou k hlavním hodnotám tlaku v přívodu a vratu kreslit obalové křivky. Tj. přibude 8 nových výstupních parametrů k typu „uzel cesty“: 

Horní obalová křivka tlaku přívodu,



dolní obalová křivka tlaku přívodu,

strana 87




horní obalová křivka tlaku vratu,



dolní obalová křivka tlaku vratu,



horní obalová křivka tlakové čáry (v m n. m.) přívodu,



dolní obalová křivka tlakové čáry (v m n. m.) přívodu,



horní obalová křivka tlakové čáry (v m n. m.) vratu,



dolní obalová křivka tlakové čáry (v m n. m.) vratu.

(Teoreticky by se daly tyto hodnoty počítat až při zobrazení [analogií metody GetMinMaxPolylineParValues] a nemusely by vzniknout nové výstupní parametry, ale to by příliš výpočetně zatěžovalo zobrazení tlakového diagramu.) DisplayOrder těchto nových parametrů bude vyšší než u všech stávajících parametrů typu „Uzel cesty“. Tím bude zachována kompatibilita s kódem tlakového diagramu ve VBA používaného v MOP. Makra kompatibility vytvoří tyto sloupce v příslušném listu XLS. Tyto parametry budou plněny i ve stacionárním výpočtu MOP, obalová křivka pak bude mít stejnou hodnotu, jako vlastní hodnota, ke které se vztahuje. (Alternativně bychom mohli plnit tyto nové parametry jen v dynamice [tj. zavést příznak statResultEmpty jako analogie dynResultEmpty], ale to je ošklivé a zatěžuje to dalším rozhodováním kód tlakového diagramu.) Tlakový diagram by mohl zobrazit vždy nejdřív (tenké) obalové křivky a až pak vlastní hodnotu (aby ve stacionárním modelu MOP nebyly obalové křivky vidět), ale v legendě bude vhodné mít obalové křivky až na konci, a jelikož je v komponentě NPlot pořadí vykreslení křivky a prvku legendy svázané, tak to takto není možné. Tudíž explicitně pro stacionární stav obalové křivky nezobrazíme vůbec. Do „spodní legendy“ [vysvětlující typy čar] se obalové křivky pro přehlednost promítnou vždy jen jednou položkou (ač jde o 4 křivky).

3.7.3 Zobrazení denních, hodinových a dalších průměrů Předpokladem pro implementaci průměrování je nutné zajistit, aby samotný interval výpočtu (včetně určení délky výpočetního kroku) splňoval určitá kritéria, která dosud (v MOPu) splňovat nemusel. Jde o to, aby velikost kroku celočíselně dělila délku 1 dne a navíc aby počáteční i koncový čas intervalu byly od počátku dne vzdáleny o celočíselný násobek kroku. Tato kritéria bude kontrolovat: 1. Dialog změny výpočetního intervalu (který nepovolí potvrzení tlačítkem „Ok“, pokud kritéria nejsou splněna); 2. Proces výpočtu na svém začátku (v případě nesplnění kritérií neprovede výpočet a ohlásí uživateli chybové hlášení se srozumitelným popisem). Výpočet toto kontroluje navíc k dialogu pro případ ruční editace specifikace intervalu např. v Excelu. strana 88


Při rozhodování uživatele na základě výpočtu modelu je velmi často potřeba zobrazit hodinové, denní či jiné průměry. Jelikož všechny hodnoty ve zvoleném kroku mají význam „analogového průměru“ za dobu od okamžiku předchozího času kroku po okamžik daného kroku, použijeme tento princip „časové značky“ analogového průměru i pro „vyšší“ průměry. Aby tedy např. hodinový průměr byl analogovým průměrem za celou hodinu, tak např. v případě kroku délky 5 minut bude hodinový průměr počítán jako průměr z 5ti-minutových průměrů s „časovou značkou“ XXh:05m, XXh:10m, … (XX+1)h:00m. Zároveň tento hodinový průměr ponese „časovou značku“ (XX+1):00. V případě denního průměru budou průměrovány např. 5ti-minutové průměry YYd 00h:05m, YYd 00h:10m, … (YYd+1) 00h:00m a výsledek ponese časovou značku (YY+1)d 00:00. Velikost zvoleného průměrovacího okna musí být vždy celočíselný (nejméně dvoj-) násobek velikosti kroku výpočtu výsledkové sady. Zároveň musí velikost zvoleného průměrovacího okna celočíselně dělit délku 1 dne. Tímto druhým kritériem je pak definováno ukotvení počátků/konců daných průměrovacích oken k času 00h:00m každého dne, tj. nikoli vzhledem k počátku výpočetního intervalu. To dále vyžaduje definici průměrů, když některé z hodnot v daném průměrovacím okně nejsou k dispozici. To může nastat v těchto případech: 

Hodnota v daném časovém kroku je neplatná (NaN).



Čas v průměrovacím oknu je před počátkem či za koncem výpočetního intervalu.

Pro tyto případy definujeme průměr tak, že průměrujeme pouze ty hodnoty, které máme k dispozici. Pro zobrazení v grafu je výše uvedený princip dostatečný. Při zobrazení v textovém seznamu by bylo však vhodné několik vylepšení: 1. [Následující mechanismus by měl jít vypnout v dialogu nastavení aplikace] V případě času (YY +1)d 00h:00m by bylo vhodné zobrazit čas jako YYd 24h:00m, aby se denní průměr zobrazoval s datem dne, ke kterému se vztahuje. Analogická situace v řádu hodin je zobrazována v pořádku, protože průměr od 0h do 1h intuitivně uživatel vnímá jako 1. hodinu dne. 2. V případě použití „vyšších“ průměrů je potřeba, aby seznam obsahoval časové značky pouze těchto průměrů, nikoli opakující se hodnoty v krocích výpočtu. 3. Dále je i v případě vyšších průměrů zachovat mechanismus označení příslušné položky v textovém seznamu při umístění „ukazatele“ pozice do grafu, tj. označit v seznamu vždy nejbližší vyšší nebo shodný čas ve vztahu k časové značce ukazatele. 3.7.3.1

Rozhraní pro zobrazování průměrů

Prvním krokem je implementace reprezentace průměrované i neprůměrované řady v podřízeném okně výsledkové řady (kód společný s oknem pro návrhovou řadu bude ošetřen, aby se následující strana 89


týkalo skutečně jen výsledkové řady): Interní reprezentace zobrazované položky v okně výsledkové řady bude nést vedle plné identifikace MopInstanceParameteru (1., resp. 2. úroveň identifikace) ještě průměrovací příznak typu List – seznam průměrovacích oken ve formě počtu minut průměrovacího okna, přičemž neprůměrované hodnoty (resp. hodnoty s významem průměru dle velikosti kroku výpočtu) nesou ale vždy hodnotu „0“! Tento průměrovací příznak se ukládá spolu s „desktopem“ modelu a je ošetřena kompatibilita s předchozími verzemi „desktopu“, které tento příznak neobsahovaly. Při přidání nové řady do okna je tato řada přidána vždy bez průměrování. Následně může být pomocí tlačítka okna změněna tato specifikace mezi neprůměrováním a specifickým průměrováním. Tlačítko vyvolá jednoduchý dialog, jehož dominantním prvkem bude CheckedListBox, obsahující všechny možné kombinace prvků průměrovacího příznaku (přepočtené z počtu minut na formát HH:mm) vyhovující kritériím (násobí krok, dělí den – viz výše) a prvky průměrovacího příznaku aktuálně zvolené řady v něm budou zaškrtnuty. Jako první položka je vždy položka nezprůměrovaných hodnot „přímá hodnota“, ovšem nemusí být nutně zaškrtnutá. Pro zvolené položky průměrovacího příznaku se vykresluje čára grafu okna s atributem Pen nastaveným takto: DashStyle = System.Drawing.Drawing2D.DashStyle.Dash; DashPattern = new float[] { NS, 1 };

Kde NS je podíl velikosti zvoleného průměrovacího okna a výpočetního kroku. V textovém seznamu hodnot okna je hodnota odpovídající první zaškrtnuté položce průměrovacího příznaku zobrazena normálně, případné hodnoty pro ostatní zaškrtnuté položky průměrovacího příznaku jsou zobrazeny za hodnotou v závorce (vzájemně oddělené středníkem) – bez specifikace, o který průměrovací interval jde. Okno výsledkových řad musí v reakci na přepočet modelu zkontrolovat, zda nedošlo ke změně kroku výpočtu, a pokud ano, zda nebyla porušena kritéria průměrovacích příznaků (násobí krok, dělí den – viz výše) žádných zobrazených veličin. V případě porušení vyřadí konfliktní položky z průměrovacího příznaku a oznámí to uživateli.

3.7.4 Přehledné dialogy pro výběr řad k návrhu a zobrazení výsledků Toto není nutné implementovat, ale je to poněkud přímější cesta k dohledání parametru (dle jeho názvu, zejména dle identifikace instance objektu, ke kterému se vztahuje) k zobrazení jeho průběhu, než např. přes okna návrhové / výsledkové tabulky… Přibude rozhraní „Návrhový dialog“ a „Výsledkový dialog“ (nejen do REGIOS Prediktoru ale i do MOP MOPEDu). Ikony tlačítek v nástrojové liště a ikony položek v nabídce vyvolávajících tyto dialogy budou shodné se symboly řady (oranžové a zelené). Názvy těchto tlačítek v nástrojové liště a položek v nabídce budou „Zadání řad“ a „Výsledné řady“. strana 90


Pozn.: Pro kompatibilitu se stacionárním modelem MOP: Sice bychom mohli nechat návrhový a výsledkový dialog přístupný vždy, ale (stejně jako u zobrazení symbolu řady v buňkách) budeme preferovat přehlednost (dle myšlenky, že možnost mít zadanou řadu ve stacionárním modelu je skutečně spíše než žádaná vlastnost úlitbou kompatibilitě, protože (a) při přepnutí do statiky, nechceme automaticky měnit vstupy (to nikdy neděláme!), (b) chceme, aby výpočet nějak smysluplně proběhl). Tedy: Při stacionárním nastavení návrhové sady bude tlačítko nástrojové lišty (resp. položka nabídky) návrhového dialogu nepřístupný (neaktivní, nikoli neviditelný). A při stacionárním nastavení výsledkové sady bude tlačítko nástrojové lišty (resp. položka nabídky) výsledkového dialogu nepřístupný (neaktivní, nikoli neviditelný). „Výsledkový dialog“ bude obsahovat filtry (ve formě comboboxu typu DropDownList, tj. textové pole s rozbalovací nabídkou ale bez vlastní editace textu): (3) dle „třídy objektu“ (přičemž první položka značí „všechny třídy“ a je zobrazena např. jako prázdný řetězec), (4) dle „instance“ (přičemž první položka značí „všechny instance“ [dané třídy vybrané v prvním filtru, případně všech tříd v případě volby první položky prvního filtru] a je zobrazena např. jako prázdný řetězec), (5) dle fyzikální kategorie (přičemž první položka značí „všechny fyzikální kategorie“ a je zobrazena např. jako prázdný řetězec), (6) jestli je parametr vstupní nebo výstupní či všechny typy parametrů (identifikační nikoli; v budoucnu – v REGIOS online přibydou „online“ veličiny; první položka bude mít význam „všechny typy parametrů“ a je zobrazena např. jako prázdný řetězec). Obsahuje 2 seznamy typu ListBox: Pravý obsahuje seznam zvolených položek (parametrů) k zobrazení, levý obsahuje seznam všech (dle filtrů) nabízených položek (parametrů), s výjimkou těch, co již byly vybrány do pravého seznamu9. „Návrhový dialog“ bude obsahovat filtry (ve formě comboboxu typu DropDownList, tj. textové pole s rozbalovací nabídkou ale bez vlastní editace textu):

9

Kvůli shodnému ovládání s dialogem definice uživatelských formulářů je vhodné zvážit, zda tento levý seznam nemá obsahovat parametry všechny (tj. nejen ty dosud nevybrané). Pak by položky, které jsou již vybrány (tj. existují v pravém seznamu), byly v levém seznamu zobrazeny šedou barvou a zároveň (tady by byla přece jen odchylka od dialogu definic uživatelských formulářů) by tyto položky již duplicitně přidat do pravého seznamu nešly. Také by možná bylo zajímavé (analogicky k dialogu definic uživatelských formulářů) barvit zeleně ty položky levého seznamu, které sice neexistují v pravém seznamu, ale již jsou otevřené v nějakém okně výsledkových řad.

strana 91


(1) dle „třídy objektu“ (přičemž první položka značí „všechny třídy“ a je zobrazena např. jako prázdný řetězec), (2) dle „instance“ (přičemž první položka značí „všechny instance“ [dané třídy vybrané v prvním filtru, případně všech tříd v případě volby první položky prvního filtru] a je zobrazena např. jako prázdný řetězec), (3) dle fyzikální kategorie (přičemž první položka značí „všechny fyzikální kategorie“ a je zobrazena např. jako prázdný řetězec), Dialogy budou vyvolávané z nabídky Otevřít a z odpovídajících tlačítek nástrojové lišty. (Pro zobrazení externích modelů budou také v odpovídajících „externích“ tlačítek nástrojové lišty a podnabídkách nabídky Otevřít…). Návrhový dialog: bude mít jen „levý“ seznam (ListBox) - vybrat půjde jen jedna položka, následně – místo přidání do nějakého „pravého“ seznamu“ – se předpokládá již jen potvrzení tlačítkem „OK“ (protože umíme editovat jen jeden parametr v okně návrhové řady).10 Návrhový dialog: Ze zobrazení budou vyjmuty ty (ne-singulární) vstupní parametry, které nemohou nést řadu. Ze zobrazení budou dále vždy vyjmuty ty vstupní parametry, které jsou „fixní“ důsledkem uvedení ve „schématu“. Mělo by být ve shodě, že parametr je nabízen v návrhovém dialogu právě tehdy, když má v okně návrhové tabulky / mapy v buňce uveden oranžový symbol „řady“. Navíc by to nemělo záviset na aktuální hodnotě, ale na stálejší charakteristice, např. zda je fixní, zda může nést řadu, apod. Výsledkový dialog: Ze zobrazení (pravého i levého seznamu) vždy vyjme jakékoliv výstupní parametry odfiltrované pomocí výstupních filtrů. Také ze zobrazení budou vyjmuty ty (ne-singulární) vstupní parametry, které nemohou nést řadu. Dále ze zobrazení budou vždy vyjmuty ty vstupní parametry, které jsou „fixní“ (důsledkem uvedení ve „schématu“). Mělo by být ve shodě, že parametr je nabízen ve výsledkovém dialogu právě tehdy, když má v okně výsledkové mapy / tabulky v buňce uveden zelený symbol „řady“. Navíc by to nemělo záviset na aktuální hodnotě, ale na stálejší charakteristice, např. zda je fixní, zda může nést řadu, apod. V rámci návrhového dialogu a výsledkového dialogu budou parametry uvedené v levém seznamu (v rámci aktuálního nastavení filtračních nastavení) v pořadí svého DisplayOrder. Výsledkový dialog nebude obsahovat tlačítka na změnu pořadí parametrů zvolených k zobrazení ani nástroje na definici / změnu barvy jejich čar, protože tyto nástroje má okno výsledkových řad, a tyto zde jsou navíc použitelné i pro jiný způsob přidání řady do okna (pomocí symbolu řady v buňkách výsledkové mapy / tabulky).

10

Eventuálně by bylo možné (pro analogii ovládání s dialogem definic uživatelských formulářů) zobrazovat zeleně ty položky, které již jsou otevřené v nějakém okně návrhu řady.

strana 92


Po potvrzení výsledkového dialogu je vzápětí zobrazen (již implementovaný) dialog pro výběr existujícího / nového okna výsledných řad… Z okna zobrazení výsledkových řad bude možno (buď tlačítkem, nebo položkou v nabídce Editace) vyvolat výsledkový dialog, který bude mít několik zvláštností:  Bude mít před-vybrané ty parametry, které jsou zobrazeny v okně zobrazení výsledkových řad, ze kterého byl dialog vyvolán. (Toto bude indikováno i obsažením informace, včetně názvu tohoto okna zobrazení řad v titulku výsledkového dialogu.)  Po odsouhlasení dialogu nebude zobrazen dialog pro výběr existujícího / nového okna výsledných řad, ale bude modifikován obsah okna, ze kterého byl dialog vyvolán. (Původní obsah tohoto okna zobrazení řad bude zrušen.)

3.7.5 Přizpůsobitelné dialogy ovládání vybraných vstupů V případě většího množství singulárních vstupů se jejich zadávání bude stávat velmi nepřehledným. Bylo by vhodné umět zadávat některé skupiny vstupů sdruženě přehledně na jednom místě. Proto vytvoříme systém uživatelské definice zadávacích (případně kombinovaně i výsledkových) formulářů. Definice těchto formulářů se budou ukládat spolu s modelem. Zároveň potřebné formuláře budou před-navrženy a zafixovány pomocí „schématu“. Definice těchto formulářů budou prakticky obsahovat jen odkazy na existující parametry (jako u oken řad, ale navíc se specifikací, zda se jedná o návrhovou či výsledkovou sadu) + souřadnice kde se ve formuláři má „dvoj-buňka“ parametru zobrazit. („Dvoj-buňka“ má vlevo buňku hlavičky [title a comment v bublině nápovědy; barvy textu a podkladu analogicky oknům návrhové či výsledkové mapy a tabulky, tj. bude z barvy „hlavičky“ zřejmé i to, zda jde o vstup v návrhové sadě (tmavě oranžová), vstup ve výsledkové sadě (světle oranžová) či výstup ve výsledkové řadě (světle zelená)], vpravo buňku vlastní hodnotu [chování opět analogicky oknům návrhové či výsledkové mapy a tabulky].) Formulář bude ošetřen pro případy, kdy: 

výsledková sada bude prázdná (pokud uživatel provede „Smazat výsledky“) či



odkazovaný singulární parametr či instance objektu nesoucího odkazovaný nesingulární parametr přestane existovat.

Vedle „dvoj-buněk“ odkazů na parametry bude formulář umět zobrazovat libovolné textové popisky – prozatím pouze s definovatelným textem a případným stylem (tučné, kurzíva, podtržené). Barva bude zatím vždy černá a velikost fixní. V nabídce Otevřít přibyde položka Definice dialogů: bude vyvolávat modální dialog se seznamem definovaných formulářů a s tlačítky pro 

vytváření nového formuláře,

strana 93




smazání existujícího formuláře (včetně obsažených prvků),



editaci existujícího formuláře a



klonování existujícího formuláře (včetně obsažných prvků).

Dialog by při svém otevření mohl kontrolovat, zda existují nějaké definované prvky pro neexistující formulář a v takovém případě by zobrazoval uživateli dotaz na jejich smazání. Jelikož v praxi toto může nastat jen neodborným zásahem a v zásadě nám takováto chyba nevadí, nebudeme toto implementovat. Tlačítka pro vytvoření nového formuláře, pro editaci formuláře a pro klonování formuláře budou vyvolávat další dialog vlastní editace konkrétního okna: Tento dialog bude podobný „výsledkovému dialogu“. Dialog bude zároveň editovat objekty formulářů i jejich prvků. Bude obsahovat: 

Editační pole textu názvu formuláře



2 seznamy (ListBox) parametrů: levý se všemi (případně filtrovanými) parametry a pravý se zvolenými parametry. Bude použita 3. úroveň identifikace parametrů, v pravém seznamu navíc zkombinovaná se souřadnicemi. Pravý seznam bude moci obsahovat i položky „štítků“ a v tom případě bude zobrazovat text štítku spolu se specifikací stylu. Levý seznam bude mít rozlišeny položky barevně (černě ty, co nejsou ještě v žádném formuláři; zeleně ty, co nejsou v tomto formuláři, ale jsou v jiném formuláři; šedě ty, co jsou v tomto formuláři, bez ohledu na to, zda jsou ještě i v jiných formulářích)



Editační pole textu štítku a 6 prvků RadioButton na nastavení stylů (tučné: ano/ne, kurzíva: ano/ne, podtržené: ano/ne)



Tlačítka:



o

[aktivní pouze pokud je v levém seznamu zvolena nějaká položka] přidání zvolené položky levého seznamu do pravého (při tom budou zohledněny právě zadané souřadnice),

o

[aktivní pouze pokud je zadán neprázdný text štítku] přidání štítku se zvoleným textem a stylem do pravého seznamu (při tom budou zohledněny právě zadané souřadnice) a

o

[aktivní pouze pokud je v pravém seznamu zvolena nějaká položka] odebrání položky z pravého seznamu.

Filtry (ve formě comboboxu typu DropDownList, tj. textové pole s rozbalovací nabídkou ale bez vlastní editace textu): strana 94




o

dle „třídy objektu“ (přičemž první položka značí „všechny třídy“ a je zobrazena např. jako prázdný řetězec),

o

dle „instance“ (přičemž první položka značí „všechny instance“ [dané třídy vybrané v prvním filtru, případně všech tříd v případě volby první položky prvního filtru] a je zobrazena např. jako prázdný řetězec),

o

dle fyzikální kategorie (přičemž první položka značí „všechny fyzikální kategorie“ a je zobrazena např. jako prázdný řetězec),

o

jestli je parametr vstupní nebo výstupní či všechny typy parametrů (identifikační nikoli; v budoucnu – v REGIOS online přibydou „online“ veličiny; první položka bude mít význam „všechny typy parametrů“ a je zobrazena např. jako prázdný řetězec).

2 prvky editace souřadnic (X a Y) typu NumericUpDown – editované souřadnice budou „logické“, tj. jednotka bude fiktivní (a v budoucnu případně kódem měnitelná) – pro přepočet do fyzických souřadnic bude násobena konstantou [která bude o něco vyšší než standardní výška „dvoj-buňky“] a bude navíc přičtena jiná konstanta reprezentující „nepřístupný“ levý / horní okraj formuláře. Každopádně při každém přidání parametru či štítku do pravého seznamu se automaticky Y-souřadnice zvýší o 1.

Obě tlačítka pro přidání prvku (parametru / štítku) budou neaktivní, pokud souřadnice v daném formuláři budou již obsazeny. V nabídce Otevřít budou pod čarou uvedeny názvy dosud definovaných dialogů. Tyto položky po stisknutí zobrazí příslušný dialog. Navržený dialog se zobrazí v takové velikosti, jaká je minimální velikost (včetně vhodných okrajů) pro to, aby se tam vešly všechny prvky. Tato implicitní velikost bude zároveň maximální. Jinak ale uživatel ale bude moci oknu volně měnit velikost. Při změně velikosti bude v okně zobrazen horizontální a/nebo vertikální posuvník. Tím bude možné ve zmenšeném výřezu zobrazovat jakoukoli pravoúhlou část dialogu. Vyvolání konkrétního typu dialogu bude možné vícenásobně (např. pro možnost mít zobrazeno více malých výřezů téhož dialogu). Rozložení (pozice a velikost) těchto konkrétních oken bude ukládáno spolu s „desktopem“ modelu. Definice dialogů musejí být regulérní objekty, které je možné ukládat s modelem a také ukládat do schématu (a tím bránit jejich úpravě a smazání v modelu)! Kdyby to nebyly regulérní objekty, ale jen součást „desktopu“, tak by nemohly být fixovány schématem. Tj. budou zavedeny typy objektů UserForm, UserFormParameter, UserFormLabel a abstraktní UserFormItem. Objekty těchto typů budou moci existovat pouze v neutrální sadě, tj. třídy budou mít nastavený příznak „CalcNeutral“ = true. UserForm (iname = „form“ , title [česky]: „Formulář“, title [anglicky]: „Form“) bude mít jediný parametr:

strana 95




[identifikační parametr; text] form_title (title [česky]: „Název“, title [anglicky]: „Title“, comment nedefinován) – název okna, který bude použit v titulku zobrazeného okna a také v položce nabídky, která daný dialog bude vyvolávat (v rámci dialogu je možné použít znak „&“ jako navigační akcelerátor)

UserFormItem (iname = „form_item“ , title [česky]: „Prvek formuláře“, title [anglicky]: „Form item“ , WaterInstancesAllowed = false, SteamInstancesAllowed = false) bude mít parametry: 

[identifikační parametr; text] form (title [česky]: „Název formuláře“, title [anglicky]: „Form title“, comment nedefinován) – odkaz na název okna, ve kterém se parametr má zobrazovat



[vstupní parametr; double] pos_x (title [česky]: „Souřadnice X“, title [anglicky]: „X coordinate“, comment nedefinován) – souřadnice X levého horního rohu prvku



[vstupní parametr; double] pos_y (title [česky]: „Souřadnice Y“, title [anglicky]: „Y coordinate“, comment nedefinován) – souřadnice Y levého horního rohu prvku

UserFormParameter (potomek typu UserFormItem; iname = „form_param“ , title [česky]: „Parametr formuláře“, title [anglicky]: „Form parameter“) bude mít parametry: (Následuje čtveřice parametrů reprezentující odkaz na MopInstanceParameter včetně sady, ve které je obsažen, ve formě analogické 2. úrovni identifikace. Jelikož se může hodit mít daný parametr v okně uveden vícekrát, nebude tato identifikace čtveřicí identifikačních parametrů.) 

[vstupní parametr; int] set (title [česky]: „Sada“, title [anglicky]: „Set“, comment [česky] = „V které sadě je daný objekt s parametrem: Hodnota '0' značí návrhovou sadu, hodnota '1' výsledkovou a hodnota '2' výpočtově neutrální sadu.“ “, comment [anglicky] = „In which set is the object with the parameter: Value '0' means design set, value '1' means results set and value '2' means calculation neutral set.“) – sada, ve které se parametr nachází (0 – návrhová sada, 1 – výsledková sada, 2 – neutrální sada)



[vstupní parametr; text] class (title [česky]: „Typ objektu“, title [anglicky]: „Object type“, comment [česky]: „Interní invariantní identifikátor typu objektu: Neměl by být nikdy zadáván ručně, ale pouze skrze příslušné dialogy.“, comment [anglicky]: „Internal invariant identifier of the object type: It should be never set manually. Only corresponding dialog should be used to set it.“) – mip.mi.classof.iname



[vstupní parametr; text] instance (title [česky]: „Identifikace objektu“, title [anglicky]: „Object identification“, comment [česky] = „Uspořádaný seznam hodnot identifikačních parametrů objektu oddělených znakem '^': V názvech větví musejí být nahrazeny některé znaky, a to postupně: '\' -> '\b', '#' -> '\n', '^' -> '\s'. Prázdný řetězec je reprezentován znakem '#'.“, comment [anglicky] = „Ordered object identification parameters values list separated by '^' character: Some branch name characters must be replaced, in this order: '\' -> '\b', '#' -> '\n', '^' -> '\s'. Empty list is represented by '#' character.“) – mip.mi.getStorableIdentification().SafeJoin() strana 96




[vstupní parametr; text] param (title [česky]: „Parametr“, title [anglicky]: „Parameter“, comment [česky]: „Interní invariantní identifikátor parametru: Neměl by být nikdy zadáván ručně, ale pouze skrze příslušné dialogy.“, comment [anglicky]: „Internal invariant identifier of the parameter: It should be never set manually. Only corresponding dialog should be used to set it.“) – mip.mp.iname

UserFormLabel (potomek typu UserFormItem; iname = „form_label“, title [česky]: „Štítek formuláře“, title [anglicky]: „Form label“) bude mít parametry: (Jelikož se může hodit mít stejný text v okně uveden vícekrát, nebude následující parametr identifikačnímparametrem.) 

[vstupní parametr; text] text (title [česky]: „Text“, title [anglicky]: „Text“, comment nedefinován) – Text štítku



[vstupní parametr; int] bold (title [česky]: „Styl: tučný“, title [anglicky]: „Style: bold“, comment [česky] = „Tučný text: Hodnota '1' značí ano, '0' ne.“, comment [anglicky] = „Bold text: Value '1' means yes, '0' means no.“) – příznak stylu „tučný“: 0 = ne, 1 = ano



[vstupní parametr; int] italics (title [česky]: „Styl: kurzíva“, title [anglicky]: „Style: italics“, comment [česky] = „Kurzíva: Hodnota '1' značí ano, '0' ne.“, comment [anglicky] = „Italics: Value '1' means yes, '0' means no.“) – příznak stylu „kurzíva“: 0 = ne, 1 = ano



[vstupní parametr; int] underline (title [česky]: „Styl: podtržený“, title [anglicky]: „Style: underline“, comment [česky] = „Podtržený text: Hodnota '1' značí ano, '0' ne.“, comment [anglicky] = „Underlined text: Value '1' means yes, '0' means no.“) – příznak stylu „podtržený“: 0 = ne, 1 = ano

3.8 Řešení problémů letního času Řešení je důležité zejména pro implementaci REGIOS online, ale pro kompatibilitu modelů vytvořených pro REGIOS offline s REGIOS online je třeba řešení implementovat již v REGIOS offline. Primárně je třeba se řídit pravidly: 1. Přejít v interní reprezentaci všech časových údajů z lokálního času na UTC. Zároveň mít konzistentně toto indikováno ve všech proměnných typu DateTime položkou .Kind s hodnotou DateTimeKind.Utc! U všech řazení, třídění a u většiny dalších rozhodovacích situací je nutno zohledňovat čas v UTC. 2. V informacích ukládaných spolu s modelem (a případně dalších ukládaných informacích) vždy používat čas UTC a v případě uložení času jako řetězce používat navíc systematicky formát ISO 8601 (používající znaky „T“ a „Z“), tj. "yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z'" (např. "2014-1021T07:11:31Z") na rozdíl od dosavadního „lokálního“ "yyyy-MM-dd HH:mm:ss" strana 97


V případě nalezení uloženého řetězce se specifikací času bez znaků „T“ a „Z“ je vhodné reagovat chybou. Je třeba pomocí maker kompatibility MOP zkonvertovat stávající výskyty časových údajů z místního (proměnlivého dle aktuálního data mezi CentralEurope a CentralEuropeDaylightSaving) na UTC... indikovat to u každého časového údaje písmeny "T" a "Z" dle formátu ISO 8601… Makra budou volat specializovanou aplikaci Compat003. (Veškerý zdrojový kód této aplikace bude [až na opravu chyb] nadále zafixován – sdílený kód bude zduplikován.) Aplikace Compat003 načte (téměř) všechny vstupní a výstupní listy, provede modifikace návrhových i výsledkových tabulek a uloží obsah zpět do příslušných listů. Modifikace bude spočívat ve změně formátu časových údajů v parametru „Výpočetní interval“, dále ve všech vstupních i výstupních parametrech obsahujících řady (ať již zadaných lomovými body či pravidelným rastrem) a také v nahrazení časových údajů v listu „Dsk“ (časové údaje o zobrazovaném kroku výpočtu v otevřených výsledkových oknech aplikace) 3. Ve všech částech uživatelského rozhraní je třeba zobrazovat čas naopak lokální a to pro časy v období letního času lokální v SELČ a ostatní lokální v SEČ. Nicméně pro úsporu místa pro zobrazování, a také z důvodu neexistence zkratek „SEČ“ a „SELČ“ [a jejich analogií pro jiná světová časová pásma] v .NET Framework nebudou zobrazovány „přípony“ časových údajů („SEČ“ a „SELČ“, apod.)! Ač chování aplikace většinou nezávisí na lokálním čase, na některých místech je třeba respektovat hodnoty spíše vzhledem k lokálnímu formátu času, např.: 

„půlnoční čáry“ v zobrazení grafu časových řad – ty budou u přestupných dnů mít rozteč 25, resp. 23 hodin,



denní průměry hodnot: někdy průměrují místo 24 hodin, jen 23 nebo naopak 25 hodin,



hodinové průměry u přestupných dnů mohou mít pro danou hodinu 2 záznamy či naopak žádný záznam.

Je třeba zvážit, které výskyty DateTime.Now (.Kind = DateTimeKind.Local) převést na DateTime.UtcNow (.Kind = DateTimeKind.Utc)

strana 98


Při startu aplikace bude detekováno systémové lokální časové pásmo (TimeZoneInfo.Local), které bude implicitně použito na všechny konverze z / do „lokálního“ formátu času. Pokud však bude nalezen soubor etc\ForcedTimeZone.cfg (případně s vyšší prioritou soubor <user_settings_folder>\\ForcedTimeZone-user.cfg) a ten bude obsahovat 1 řádek s validním identifikátorem .Net Framework časové zóny, bude použita tato časová zóna (bude nalezena funkcí TimeZoneInfo.FindSystemTimeZoneById). Bohužel TimeZoneInfo.Local má dva nedostatky: 1. Pod Windows XP (SP3) funkce používá nesprávně pravidla pro roky starší, než rok, ke kterému se vztahuje aktuální pravidlo v systému. 2. Funkce TimeZoneInfo.ConvertTimeFromUtc pro tuto zónu vrací čas s .Kind = DateTimeKind.Local, kdežto pro ostatní zóny, např. získané funkcí TimeZoneInfo. FindSystemTimeZoneById po dosazení do funkce TimeZoneInfo.ConvertTimeFromUtc vracejí čas s .Kind = DateTimeKind.Unspecified. Oba tyto nedostatky kupodivu odstraníme použitím implicitní zóny pomocí TimeZoneInfo. FindSystemTimeZoneById(TimeZoneInfo.Local.Id) namísto pouhého TimeZoneInfo.Local!

3.8.1 Konverze specifikace času Prakticky budou probíhat následující konverze: 

Pro konverzi proměnné typu DateTime do řetězce v UTC se použije dt.ToString"yyyy'-'MM''dd'T'HH':'mm':'ss'Z'", CultureInfo.InvariantCulture) namísto dt.ToString("yyyy-MM-dd HH:mm:ss", CultureInfo.InvariantCulture) resp. dt.ToString("yyyy'-'MM'-'dd'T'HH':'mm'Z'", CultureInfo.InvariantCulture) namísto dt.ToString("yyyy-MM-dd HH:mm", CultureInfo.InvariantCulture),



Při konverzi řetězce v UTC do proměnné typu DateTime (s .Kind = DateTimeKind.Utc) se vyžaduje formát "yyyy'-'M'-'d'T'H':'m':'s'Z'", resp. "yyyy'-'M'-'d'T'H':'m'Z'", vždy včetně znaků „T“ a „Z“. Je třeba upravit výskyty volání DateTime.ParseExact(string, string, CultureInfo), DateTime.ParseExact(string, string, CultureInfo, DateTimeStyles), DateTime.Parse(string, CultureInfo),



Pro konverzi DateTime do řetězce v „lokálním“ (obecně proměnlivém SELČ / SEČ) pásmu použít TimeZoneInfo.ConvertTimeFromUtc()11. Je vhodné navíc k zobrazení lokálního času přidat příponu, pokud jde o čas nejednoznačný. Nejednoznačnost se zjistí voláním

11

Metoda TimeZoneInfo::ConvertTimeFromUtc pracuje na rozdíl od metod TimeZone::ToLocalTime and DateTime::ToLocalTime korektně, protože aplikuje pravidla přechodu z / na letní čas platná pro daný konkrétní čas, nikoli poslední platné pravidlo i na starší data.

strana 99


TimeZoneInfo::IsAmbiguousTime na již zkonvertovaný lokální čas. V případě výsledku true je třeba ještě volat funkci TimeZoneInfo::GetAmbiguousTimeOffsets vracející pole možných odchylek od UTC. Tyto odchylky převedeme na odchylky oproti základnímu času (TimeZoneInfo::BaseUtcOffset ). V případě nulové odchylky přidáme k zobrazovanému textu text „stand.“ [anglicky: „stand.“], u odchylky +1h text „letní“ [anglicky: „DST“] a u ostatních odchylek text „std.“ [anglicky: „std.“] + „ +|- hh:mm:ss“ vyjadřující tuto odchylku od TimeZoneInfo::BaseUtcOffset. 

Pro konverzi řetězce časové specifikace v lokálním „lokálním“ (obecně proměnlivém SELČ / SEČ) do DateTime (s .Kind = DateTimeKind.Utc!) pásmu by v zásadě šla použít funkce TimeZoneInfo.ConvertTimeToUtc()12. Je třeba upravit kód u výskytů volání DateTime.ParseExact (string, string, CultureInfo), DateTime.ParseExact(string, string, CultureInfo, DateTimeStyles), DateTime.Parse(string, CultureInfo). Protože však výsledek funkce ConvertTimeToUtc je obecně nejednoznačný, musíme postupovat takto: Předpokládáme, že uživatel zadává čas v dialogu (dialog editace výpočetního intervalu, dialog editace lomového bodu řady či dialog rastru pravidelné řady). Namísto hodnot z těchto dialogů budeme pro další účely používat hodnotu zadaného času v UTC. Tu získáme takto: Dialog bude mít u každé dvojice ovládacích prvků datum + čas vyhrazené ještě jedno textové pole (s rozbalovací nabídkou) cbTimeOffsetSpec. Toto pole bude většinu času nepřístupné (neaktivní). Při každé změně data či času bude provedeno následující: Zadaný datum spolu s časem bude testován funkcí TimeZoneInfo::IsInvalidTime. V případě, že tato funkce vrátí true, bude zadaný čas či datum změněn na předchozí hodnotu prvku. Dále bude zadaný datum spolu s časem testován funkcí TimeZoneInfo::IsAmbiguousTime. Pokud tato funkce vrátí false, nastaví se cbTimeOffsetSpec.Enabled na false, pokud vrátí true, nastaví se i cbTimeOffsetSpec.Enabled na true. V prvním případě bude cbTimeOffsetSpec zcela prázdný, v druhém případě se však naplní jednotlivé rozbalovací položky cbTimeOffsetSpec a hodnota prvku se nastaví na první uvedenou položku; položky se naplní z pole ambiguousOffsets, které bude výsledkem funkce TimeZoneInfo::GetAmbiguousTimeOffsets, kde každý prvek vráceného pole odpovídá jedné položce cbTimeOffsetSpec. Pro každou položku se provede konverze TimeSpan na string, a to takto: Nejprve je hodnota přepočtena na odchylku TimeZoneInfo::BaseUtcOffset namísto odchylky od UTC. Dále je převedena na formát „+|- hh:mm:ss“ a je jí předřazen text „std.“ [anglicky: „std.“] + „ “. Dále, pokud je hodnota TimeSpan shodná s TimeZoneInfo::BaseUtcOffset je hodnota nahrazena

12

Metoda TimeZoneInfo::ConvertTimeToUtc pracuje na rozdíl od metod TimeZone::ToUniversalTime and DateTime::ToUniversalTime korektně, protože aplikuje pravidla přechodu z / na letní čas platná pro daný konkrétní čas, nikoli poslední platné pravidlo i na starší data.

strana 100


textem „stand.“ [anglicky: „stand.“] a pokud je shodná s (TimeZoneInfo::BaseUtcOffset + 1h), tak je hodnota nahrazena textem „letní“ [anglicky: „DST“]. Na přepočet do UTC bude v případě (IsAmbiguousTime = true) použito volání { DateTime.SpecifyKind( localTime.Subtract(ambiguousOffsets[cbTimeOffsetSpec.SelectedIndex]), DateTimeKind.Utc) } a v případě opačném funkce ConvertTimeToUtc. K přepočtu výsledného času v UTC dojde také při ručním výběru položky v cbTimeOffsetSpec – zde je třeba zabránit rekurzivnímu volání. Od výsledného času v UTC je možno nastavovat další položky dialogu, např. čas opačného konce intervalu, délku intervalu, atd. Upozornění: Při volání ConvertTimeToUtc musí být časový parametr (1. parametr) mít .Kind = DateTimeKind.Unspecified – to je univerzální řešení, protože pokud by měl .Kind = DateTimeKind.Local, fungovala by funkce ConvertTimeToUtc jen pro zónu (2. parametr) Local, ale nikoli již pro jinou zónu (zadanou např. pomocí etc\ForcedTimeZone.cfg)!

3.9 Specifické algoritmy, schema, DLL knihovny, „háčky“ Implementace dle této kapitoly zahrnuje přirozeně implementaci všech algoritmů a související infrastruktury zajišťující „fixní“ části modelu vyžadované právě specifickými algoritmy. Jako důsledek bude dané nasazení REGIOS specifické pouze pro danou síť, resp. síť splňující určitá kritéria. Tato kritéria budou exaktně definována v souboru „schématu“ dodávaném spolu s přesně odpovídající výslednou podobou algoritmů navrch ke standardním součástem MOP.

3.9.1 Fixní „schéma“ modelu Existence objektů obsažených ve „schématu“ je nutná pro funkčnost specifických algoritmů „háčků“, ale obráceně to neplatí, „schéma“ může zahrnout více objektů, než je nutné pro „háčky“. Eventuálně tedy lze použít neprázdné „schéma“ i čistě v MOP (např. by mohlo obsahovat standardní sadu filtrů [„all“ a „none“], to by bylo užitečné např. při importu z GIS…). „Schéma modelu“ bude soubor na relativní cestě [vzhledem k plné cestě ke spustitelnému souboru aplikace] dané obsahem 2. položky souboru DestSpec.cfg. V praxi však bude umístěný ve složce „bin\“ a 2. položka souboru DestSpec.cfg bude obsahovat tedy jen přímo název souboru bez cesty. Konvence (nepovinná) pro název souboru schématu bude dst_[_<destination_ name>].schema, tedy např. dst_REGIOS_NLiskovec.schema. Pro MOP to případně bude dst_MOP.schema. Struktura „schématu“ je téměř shodná se strukturou souboru modelu nezávislého režimu. Ale bude existovat tabulková struktura jen pro návrhovou a „výpočetně neutrální“ sadu parametrů, nikoli struktura pro výsledkovou sadu a pro „desktop“. Dále bude existovat ještě drobná výjimka: Nebudou existovat tabulky pro objekty typů s atributem „NotInSchema“ (což jsou zatím tedy pouze objekty typu UserUnit). strana 101


Obsahem „schématu“ budou všechny instance objektů, které DLL-kód výpočtu vyžaduje (vč. např. všech námi předdefinovaných „singulárních“ vstupů a výstupů), či je poblíž (např. uzel úseku, když vyžadujeme ten úsek). Musí být splněna následná 2 pravidla: (1) „singulární“ vstupy a „online“ veličiny (viz REGIOS online) tam jsou uvedené vždy s výjimkou vlastní hodnoty ale jinak se všemi ostatními vstupy, (2) cesty, filtry výstupů, neuronové sítě, singulární výstupy a uživatelské formuláře tam budou uvedeny se všemi13 vstupy [tj. singulární výstupy včetně předpisu!], (3) „uživatelsky definované jednotky“ a „hlášení transformace“ být v schématu nesmějí být vůbec, (4) objekty typu „hlášení výpočtu“, či „specifikace zpoždění“ a „uzel cesty“ ve schématu přirozeně nebudou, jelikož se jedná o „čistě výstupní“ objekty, (5) prvky uživatelských formulářů budou uvedený vždy se všemi parametry a zároveň vždy všechny společně s daným samotným formulářem14, (6) u ostatních objektů (včetně takových specialit, jako jsou např. transformace [vit REGIOS online]) tam musejí být povinně identifikační vstupy, ale ostatní vstupní parametry jsou jen volitelné. „Pozitivní implikace“: Jak již bylo výše uvedeno, „schéma“ musí korespondovat s DLL-kódem formou neostré nadmnožiny: Tj. vše, co vyžaduje kód, musí být obsaženo ve schématu, obráceně to však neplatí. „Negativní implikace“: Objekty v modelu, které nejsou ve schématu, by téměř nikdy neměly výpočtu vadit (až na porušení např. logiky hydrauliky, které ale musí být ošetřeno generováním chyby při výpočtu). To, že je objekt či parametr uveden ve schématu má ještě jeden důležitý efekt: Parametr uvedený ve schématu je needitovatelný a objekt je nesmazatelný (a to včetně definice singulárních parametrů). Těsně15 po každém otevření modelu (i těsně po každém importu z GISimportu) bude načteno i „schéma“ a model bude s ním porovnán: Budou doplněny chybějící vyžadované informace (pokud

13

Toto rozhodnutí (souvisí i s mechanismem zamykání pomocí klávesových zkratek – viz dále) je dáno pouze snahou o zjednodušení rozhraní spolu s absencí důvodu, proč by tyto objekty měly jít nastavit podrobněji, než je uvedeno. Pokud by se však takový důvod našel, lze bez problémů přejít na jemnější nastavení. 14

Pokud bychom požadovali, aby uživatel měl možnost do fixovaných formulářů alespoň přidávat nové prvky (automatické zvětšení vlastního okna je již zajištěno) a případně označit některé prvky jako uživatelsky odstranitelné, bylo by alternativou mít prvky uživatelských formulářů uvedené vždy se všemi parametry, ale nikoli nutně vždy všechny a nikoli nutně spolu s objektem formuláře. 15

Porovnání bude implementováno po celkovém dokončení načtení / importu, tj. „nanucení“ objektů či hodnot parametrů „schématem“ vyvolá událost „signalChanged“.

strana 102


schéma-objekt dle id není v modelu (v mis) nalezen, doplní se, pokud je nalezen, jsou mu přepsány všechny parametry těmi z šablony, které v šabloně má uvedené; s dodatečným hlášením uživateli „Byly doplněny chybějící informace…“ či „Byly opraveny nesprávné informace…“). Během porovnávání bude všem parametrům, které jsou uvedeny ve „schématu“ ve vlastním načteném modelu (ať již byl objekt doplněn či již v modelu existoval) nastaven příznak locked = true. Dále již nebude „schéma“ v paměti drženo jinak než právě ve formě příznaků „locked“ parametrů. Efekt parametru „locked“:  Singulární vstup s locked = 1 nebude povoleno uživatelsky smazat nebo mu editovat definici (tj. nepůjde editovat nic mimo vlastní hodnoty).  Cesty, filtry výstupů, neuronové sítě a singulární výstupy s locked = 1 (všechny jejich parametry mají vždy stejnou hodnotu locked) nebude dovoleno mazat ani jakkoliv editovat.  U ostatních objektů (včetně objektů Transformace – viz kap. 4.2.3) bude zabráněna editace těch parametrů, co mají locked = true. Navíc nebude dovoleno smazat objekt, který obsahuje alespoň jeden parametr s locked = true. Naopak všemu, co není ve schématu, nebude blokována editace. (Např. uživatel vždy musí mít možnost topologicky změnit síť, aby navázal „volnou“ síť na fixované „náhradní modely zdrojů“ ve schématu.) Bylo by hezké zamčené věci nějak odlišně barevně / šrafovaně (ve všech editačních oknech) odlišit… Každopádně by jim měl být odebrán aktivní symbol „řady“, pokud by takový jinak měli nést (případně by tento symbol mohl být přítomný, ale musí být neaktivní a vizuálně též „zjevně needitovatelný“) a z tohoto důvodu by neměly být vůbec zahrnuty v nabízených parametrech v „návrhovém dialogu“. Pozn. k použití zamčení filtrů výstupů: Nepotřebné výstupy (zejména u úseků jich bude mnoho) se odfiltrují – pouze je otázka, které výstupy odfiltrovat jen v modelech-šablonách (pro funkci „Nový“) a u kterých si ještě vynutit nemožnost jejich změny uvedením ve schématu. (Pouze) pokud bude existovat konfigurační souboru etc\Tweak.cfg a v něm uveden nezakomentovaný16 řádek s textem „schemaMaintenance“17, bude aktivován režim „správy schématu“. V něm bude možné klávesovou zkratkou (ve všech relevantních návrhových oknech) změnit stav locked = 1 na 0 a obráceně – 

u celých objektů (lze vždy) klávesovou zkratkou Ctrl+Alt+A [u singulárního vstupu se však nikdy nenastaví locked = true u vlastní hodnoty],

16

Zakomentovaný řádek začíná znakem „#“.

17

Řádek nesmí kromě zmíněného textového identifikátoru obsahovat nic jiného – ani mezery či tabelátory.

strana 103




u jednotlivých [ale jen vstupních, nikoli identifikačních] parametrů (lze u všech objektů s výjimkou cest, filtrů výstupů, neuronových sítí, singulárních vstupů a singulárních výstupů) klávesovou zkratkou Ctrl+Alt+P.

Pokud je stisknuto Ctrl+Alt+A na objektu, který má jen některé parametry locked = true (opět: u singulárních vstupů nikdy neuvažujeme locked u parametru vlastní hodnoty), nastaví se všem parametrům locked = false; naopak tedy pouze pokud je u všech parametrů locked = false, nastaví se jim (opět s výjimkou vlastní hodnoty singulárního vstupu) locked=true. Šrafování se projeví okamžitě při stisku Ctrl+Alt+A či Ctrl+Alt+P. Ctrl+Alt+A reaguje v dialozích cest / filtrů výstupů / neuronových sítí / singulárních parametrů na položce dané konkrétní cesty / filtru výstupů / neuronové sítě / singulárním vstupu / singulárním výstupu a také v oknech návrhové mapy při označeném objektu a v oknech a návrhové tabulky při označených buňkách nezasahujících mimo jediný řádek. Ctrl+Alt+P reaguje v oknech návrhové mapy při označeném objektu a označených buňkách nějakých parametrů a v oknech a návrhové tabulky při označených libovolných buňkách. Také (pouze) pokud bude aktivní režim „správy schématu“, tak se při uložení modelu (nebo při zavření modelu bez uložení) zobrazí dialog, zda uložit schéma. Pokud uživatel odpoví ano, je v paměti vygenerováno nové „schéma“ dle locked všech parametrů všech instancí v mis, a toto nové „schéma“ je uloženo. Pozn.: Podobně jako hlídáme změny modelu (changedSignal), je třeba hlídat změny schématu (příznaků „locked“) [což je naštěstí výrazně jednodušší]… Je vhodné, aby při zamčení vstupního parametru, který je odkazem na identifikační parametr(y) jiného objektu, se automaticky zamkl i odkazovaný objekt (jen jeho identifikační parametry, tedy pokud již zamčený není, třeba i s více parametry…). Příklad odkazu: 

úsek potrubí → uzel,



úsek potrubí → katalog potrubí,



čerpadlo → katalog čerpadel,



síť (HKST) → uzel,



cesta → obsažený zakázaný úsek či uzel poč. viditelnosti,



transformace → příslušný „online“ či vstupní parametr (singulární či ne-singulární).

3.9.2 „Háčky“ a obecné napojení algoritmů z DLL knihoven Vlastně pouze tato podkapitola kapitoly 3 popisuje implementační prvky, které budou pouze v REGIOS offline, ale nikoli v MOP. Uvnitř výpočtu budou na několika konkrétních místech (otázka kde, bude řešena až podle konkrétních požadavků při řešení destinace, ale těch míst může být klidně fůra) zaháčkováno volání strana 104


metod z DLL… Vnitřky těchto „externích“ nebudou metod přistupovat k objektům MopInstance, apod., ale přímo k elementům a modelu výpočtu… Umístění těchto háčků bude postupně konkretizováno během implementace konkrétní destinace. Jednou zavedené háčky budou existovat v REGIOS již „navždy“, tj. i pro další destinace. Formálně tedy bude umístění háčků součástí obecného systému REGIOS a nebude specifické na destinaci. Toto bude vždy v DLL, vždy globální, nijak se neukládá do modelu „.model“. Vždy to také musí 1:1 odpovídat „schématu“ (tj. specifikace těch konkrétních objektů a singulárních parametrů, které to vyžaduje). Specifické algoritmy hydrauliky budou ve výsledku vždy napojeny na standardní vstupy MOP, tj. HKST, zadání dopravní výšky čerpadel, výstupní tlak škrtících armatur, ve finále bude hydraulika dána standardním výpočtem MOP. Budou v zásadě 2 vrstvy těchto DLL knihoven: vrstva „destinace“ a vrstva „technologie“.  Vrstva „destinace“ bude tvořena jedinou knihovnou DLL (odkazovanou relativní cestou [vzhledem k plné cestě k spustitelnému souboru aplikace] z 1. položky konfiguračního souboru bin\DestSpec.cfg, ovšem v praxi umístěnou nejlépe ve stejné složce jako spustitelný soubor aplikace – tj. pak bude v 1. položce konfiguračního souboru bin\DestSpec.cfg uveden jen název DLL bez cesty) a konfiguračními soubory destinace (teoreticky umístěnými kdekoliv, ale nejlépe buď také ve složce bin\, pokud nepředpokládáme změny uživatelem, nebo v etc\, pokud takové změny předpokládáme). Konvence (nepovinná) pro název hlavní destinačněspecifické DLL bude dst__<destination_name>.dll, tedy např. dst_REGIOS_NLiskovec.dll.  Vrstva „technologie“ bude zahrnovat různé knihovny DLL a konfigurační soubory (obecně umístěné kdekoliv, ale predikovatelně – každá daná technologie na stejném místě). Zatímco vrstva „destinace“ bude vždy specifická pro danou destinaci REGIOS, tak vrstva „technologie“ bude univerzální. (To však neznamená, že musí být dávkami deploy* generována vždy celá, naopak je vhodné generovat jen ty součásti, které budou pro danou destinaci využívány.) Přesto paradoxně obecný kód (sdílený MOPem a REGIOSem) nebude mít žádné povědomí o vrstvě „technologie“. „Technologická“ DLL budou volána výhradně z „destinačních“ DLL, nikoli z „obecného kódu“. „Destinační“ DLL budou vždy managed-code .NET Frameworku. Technologická DLL mohou být jak managed-code, tak standardní C-knihovny. 3.9.2.1

Příklad konkrétní „destinační“ vrstvy

Ještě před výpočtem se zavolá (v hlavní destinační knihovně DLL) funkce LoadConf, která provede načtení konfiguračních souborů a toto nastavení si vnitřně uchová. Tato funkce vrací string[] SpecializedSources seznam názvů zdrojů, které má uvedeny v konfiguraci, tj. zdrojů se specifickým zacházením, které tato knihovna implementuje... Načtená konfigurace definuje, který zdroj tepla je jakého typu a jaké má další specifické parametry. Dále „obecný kód“ někde uvnitř výpočtu, při inicializaci zdrojů zavolá na jednotlivé zdroje z SpecializedSources funkci (z hlavní destinační knihovny strana 105


DLL) InitSource který provede nějakou případnou inicializaci zdrojů... jinde uvnitř výpočtu obecný kód zavolá pro tyto zdroje funkci (z hlavní destinační knihovny DLL) CalcSource... nakonec po výpočtu zavolá funkci (z hlavní destinační knihovny DLL) ReleaseConf pro dealokaci dat (zejména ze souboru načtené konfigurace) provedené funkcí LoadConf. Ošetření neočekávané situace: Pokud je po návratu z LoadConf v seznamu SpecializedSources speciálně počítaných zdrojů uveden v modelu neexistující zdroj, je generováno chybové hlášení uživateli a výpočet je přerušen. (Také bychom mohli být tolerantní a jen varovat, nebo to tiše ignorovat, nic by se asi nestalo, ale stejně takový zdroj bude „fixován“ „schématem“, tak generováním chyby aspoň odhalíme nechtěné chyby při vývoji.)

strana 106


4

Implementační projekt REGIOS online

V této kapitole jsou modrým textem vyznačeny části, které není třeba implementovat pro splnění cílů projektu – ale mohou být volitelně implementovány v budoucnu

Oproti obvyklým „online“ systémům je filosofie REGIOS online založená na myšlence, že pro potřebu interaktivní predikce není potřebná jiná real-timová součást systému, než sběr „měřených“ (obecněji „online“) dat. Pokud tedy máme zajištěn zdroj online dat (označme ho „M“), vystačíme si s úpravou aplikace Prediktor, kterážto je provozována ad-hoc a nevyžaduje trvalé spuštění. V následujícím popisu implementace rozlišujeme situaci, kdy primární zdroj dat (označme ho „M1“) má schopnost poskytovat historická data v neomezeném časovém rozsahu do minulosti [konkrétněji: nemaže stará data] (pak ho značíme „M1H“) nebo tuto schopnost má, ale jen v určitém (nedostatečném) časovém rozsahu (pak ho značíme „M1L“), nebo tuto schopnost nemá vůbec a je nutno využívat pouze jeho schopnosti poskytovat (v kterémkoliv reálném okamžiku) aktuální data (pak ho označme „M1A“). Každopádně požadujeme, aby uvedené hodnoty měly formu průměru za určitý časový krok, či se z tyto průměry daly pomocí konstrukce SQL dotazu spolehlivě vytvořit. Vedle označení M1, M1A, M1L, M2H používáme dále označení „M2“, „M2X“ a „M2C“ (viz kapitola 4.6). Pro účely aplikace Prediktor považujeme za zdroj dat „M“ buď M1H (pokud tento existuje) nebo M2X (pokud tento existuje a M1H neexistuje) či M2C (pokud neexistuje M1H ani M2X). K veškerým zdrojů dat „M“ se bude přistupovat (ať již pro čtení nebo pro zápis) vždy pomocí rozhraní ADO.NET.

4.1 Kompatibilita s MOPem a REGIOSem offline Při implementaci REGIOS offline nebude vytvářena nová aplikace „na zelené louce“, ale bude pouze rozšířen REGIOS offline (fakticky systém „REGIOS“ a aplikace „Prediktor“). V některých případech může dojít i k obohacení kódu společného s MOPem. Zůstane tedy zachováno maximální sdílení kódu mezi MOP a REGIOS.

4.1.1 Dokumentace REGIOS online Dokumentace (uživatelská příručka) REGIOS bude rozšířena o popis nové funkčnosti REGIOS online, tj. popis predikčního a analytického režimu, souběžného zobrazení, „překlápěcích transformací“, administrace databází „M“ a nástrojů MeaCopy, MeaDown a MeaUp, apod.

strana 107


4.2 Režimy práce: simulační, predikční, analytický Dosavadní (jediný) režim REGIOS offline bude nadále nazýván simulačním režimem. Umožňuje i nadále modelovat situace bez vztahu na reálný stav sítě daný online veličinami. Predikční režim bude nový režim umožňující pomocí online veličin v minulosti až do současnosti namodelovat aktuální stav sítě (včetně podchycení dynamiky sítě – natopení potrubních úseků) a déle simulovat vývoj sítě v budoucnu – dle zadaných předpokládaných hodnot. Analytický režim bude umožňovat v určitém časovém intervalu v minulosti nasimulovat dle historických online-veličin někdejší stav sítě. Následně umožní měnit nastavení a sledovat důsledky, co by se stalo, kdyby byl provoz jiný. Analytický a predikční režim budou v určitém smyslu jen 2 aspekty sjednoceného predikčněanalytického režimu (prostě se zadá výpočetní interval a pomocí okamžiku predikce se interval dělí na část „minulosti“ a část „budoucnosti“… část „minulosti“ tam musí být vždy (navíc bude zajištěno, aby měla rozumnou minimální délku), kdežto část „budoucnosti“ může chybět (pak je to „analytický režim“). Uložený model nebude nést explicitní informaci, zda je v simulačním, predikčním či analytickém režimu. Tuto informaci půjde získat ze specifikace času přechodu (viz dále), který bude nabývat hodnot „nowhen“ (značící simulační režim), „future“ (značící analytický režim) či hodnoty UTC času ve formátu ISO 8601 (značící predikční režim). Nastavení přechodů do predikčního a analytického režimu se bude řídit zvláštním konfiguračním souborem aplikace Online.cfg – ve formě dvou úrovní: etc\Online.cfg a <user_settings_folder>\ \Online-user.cfg. Predikční a analytický režim bude přístupný, pouze tehdy, pokud bude v tomto konfiguračním souboru nastaven klíč EnableOnline=true (implicitně je false – při neexistenci klíče či neexistenci celého tohoto konfiguračního souboru). Pokud je true, musí být zároveň vyplněny příslušné položky (alespoň 1 připojovací řetězec; alespoň 1 šablona SQL dotazu; krok průměrovaných dat ve zdroji M). Pokud nebude EnableOnline = true, budou položky nabídky vztahující se k predikčnímu a analytickému režimu (viz následující podkapitola) nepřístupné. Obecně bude tento konfigurační soubor (vedle položky bool EnableOnline) obsahovat jeden nebo více „zdrojových bloků“. Každý zdrojový blok obsahuje 

svůj jednoznačný textový identifikátor src_id (nesmí obsahovat znak „$“),



připojovací řetězec connect_string,



šablonu SQL dotazu query (obsahující SQL dotaz využívající formální parametry %id% a %time% a vracející jedinou položku value [hodnota veličiny, kde případná neplatnost je indikovaná hodnotou NULL; vždy se předpokládá, že časový údaj %time% je v UTC – u M2 to máme zajištěno, u M1H to požadujeme!])



a specifikaci zdroji dat vlastní délce kroku step_length (v sekundách). strana 108


4.2.1 Rozhraní přechodu do predikčního a analytického režimu Podnabídka Nový v nabídce Soubor bude v REGIOS zobrazována jako „Nová simulace“. (Pokud ovšem nebude EnableOnline = true, bude vhodnější stále zobrazovat „Nový“.) 4.2.1.1

Predikční režim

Dále pod nabídkou Soubor vznikne podnabídka Nová predikce – se stejným obsahem jako má podnabídka Nová simulace. (Stejným obsahem rozumíme odkazy na tytéž předpřipravené modelyšablony, jako jsou odkazovány z podnabídky Nová simulace; tj. tyto modely-šablony jsou stále uložené jako typu „simulace“18, predikce z nich vznikne až v průběhu „přechodu do predikčního režimu“.)

18

Důvodů, proč musí být šablona v simulačním režimu, je více. Také jsou důležité další aspekty, co má či nemá model-šablona obsahovat… (1) Nutno si uvědomit, že šablony budou v praxi vznikat jako běžné modely. Pokud by model-šablona nebyl v simulačním režimu, čelili bychom známému problému vejce-slepice, tj. jak by vznikl první model v predikčním režimu? Nebylo by to nemožné, ale vyžadovalo by to ruční zásah do souboru, např. pomocí nástroje SQLiteStudio. (2) Z důvodů použití by to sice nemusel být vždy nutně simulační režim, ale je určitě potřeba, aby žádná z obsažených hodnot nebyla řada! (3) Dále je vhodné, aby model-šablona obsahoval definice všech potřebných „online“ veličin a transformací (viz dále) – zejména je nutné, aby obsahoval definice „online“ veličin a transformací, které nejsou uvedeny ve schématu! Nicméně není nutné, aby model-šablona obsahoval hodnoty těchto „online“ veličin. (Toho lze dosáhnout pomocí funkce „Smazat online veličiny“ – viz dále). (4) Není potřeba, aby model-šablona obsahovala výsledky. Pro úsporu místa je vhodné, aby je neobsahovala. Toho lze dosáhnout pomocí funkce „Smazat výsledky“. (5) Nakonec je nutné, aby šablona byla v simulačním režimu (a navíc nastavena jako stacionární) kvůli tomu, že z ní mohou být vytvářeny také simulační modely a ty v sobě nezahrnují žádný mechanismus nastavení výpočetního intervalu apod., tj. model se pro simulační režim vezme ze šablony tak jak je. Je nutné nějak automaticky zajišťovat či kontrolovat, aby šablona splňovala výše popsané podmínky, protože povolujeme uživateli si vytvářet vlastní šablony v etc\new a také v <user_settings_folder>\(Mop|Regios)\new. To lze řešit čtyřmi způsoby: Buď (A) budeme při každém použití šablony kontrolovat, zda splňuje podmínky, nebo (B) zavedeme funkci modelu „Ulož jako šablonu“ (příp. zvlášť „Ulož jako globální šablonu“ s jinou předdefinovanou implicitní složkou) [to by pak ale asi mělo kontrolovat i název modelu (počáteční číslice, atd.)], nebo

strana 109


„Přechod do predikčního režimu“ je proces, kdy se vezme topologie modelu i parametry (některé parametry budou v procesu přepsány, jiné zůstanou – jakoby „implicitní“ hodnoty), je zobrazen dialog (příp. série dialogů), v důsledku kterých se změní zejména výpočtový interval, nastaví se okamžik predikce a proběhne vlastní načtení online veličin a transformace jak do minulosti, tak do budoucnosti… Zadání časů: o

V zásadě jsou všechny 3 časy (počátek počítaného intervalu, okamžik přechodu do predikce i konec počítaného intervalu) a délka výpočetního kroku volitelné uživatelem.

o

Délka kroku: Implicitně bude délka kroku nastavená dle konfiguračního souboru. Tato délka kroku v konfiguračním bude shodná s pevnou (!19) délkou kroku online veličin zdroje dat M! Délka kroku bude moci být uživatelem nastavena pouze na kladný celočíselný násobek této implicitní délky kroku!

o

Okamžik přechodu (datum a čas) je přednastaven na aktuální datum a čas posledního okamžiku online dat20 v historických21 tabulkách databáze online dat M. Nicméně lze zadat

(C) zavedeme v modelu funkci „Zkontrolovat jako šablonu“, či (D) vytvoříme funkci „Přetvořit na šablonu“. Zvolíme (A) + v nabídce přibyde položka „Provést časový řez vstupy“, která se uživatele dotáže na čas (ze současného výpočetního intervalu) a následně změní režim na simulační (a stacionární, ale se specifickým časem [tím zadaným uživatelem] – potřebným pro neuronový model spotřeby) a všechny řady (včetně řad typu „lomové body“) zamění za konstantní hodnotu v okamžiku řezu – konverze proběhne pouze v paměti (nebudeme duplikovat funkce ukládání či exportu). Uživatel bude v dokumentaci informován, že model-šablonu vytvoří pomocí funkcí „Provést časový řez vstupy“, „Smazat výsledky“ a „Smazat hodnoty online veličin“ a následného uložení do souboru ve správné složce a se správným prefixem (viz kap. 3.2.4). 19

Zdroj dat M má délku kroku pevnou (nazvěme ji „přirozenou“), jelikož hodnoty online veličin mají význam průměru za určitý interval (např. všechny hodnoty jsou 5i-minutové „zpětné“ průměry pro danou časovou značku [v celých 5i-minutách] a objevují se v historické databázi zhruba 1x za 5 minut)! 20

To je ten správný čas „okamžiku přechodu“, nikoli tedy reálný strojový čas (ten je zcela irelevantní) nebo počátek poslední předpovědi počasí (ta má stejně granularitu v řádu dní či hodin)… Samozřejmě se může stát, že nastane mezi počátkem předpovědi a koncem online dat určitá mezera. V případě poruchy systému online dat to můžou být i dny, týdny, … ale praktičtější je hodit toto nepodložené mezi-období do budoucna, než do minulosti: V minulosti můžeme akorát tak natahovat poslední platné hodnoty a po 2 hodinách vyvolávat chybu. Kdežto v budoucnosti lze předpověď počasí snadno doplnit, navíc možná budeme chtít editaci nějakých vstupů v intervalu „minulosti“ blokovat… 21

Technicky čteme z M1H či M2, tj. jen „historická“ online data, nikdy „aktuální“ (požadujeme, aby poslední krok historických dat, nebyl příliš starý…)

strana 110


datum a čas libovolně do minulosti!. Díky tomu můžeme mít simulované predikce i do minulosti! Do reálné budoucnosti zadat datum a čas nejde. Okamžik přechodu musí být vždy v celém kroku! o

Konec intervalu má také radio-tlačítka, volící mezi konkrétním datem + časem a délkou času od „okamžiku přechodu do konce počítaného intervalu“. Implicitně je nastaven na délku času a délka času je zas implicitně nastavena dle konfiguračního souboru v jednotce sekund (např. na „1 den“), případně zvýšena na celý počet kroků. Granularita interaktivního nastavení délky je 1 krok.

o

Počátek intervalu má také radio-tlačítka, volící mezi konkrétním datem + časem a délkou času od „počátku počítaného intervalu do okamžiku přechodu“. Implicitně je nastaven na délku času a délka času je zase implicitně nastavena dle konfiguračního souboru v jednotce sekund (např. na „3 dny“), případně zvýšena na celý počet kroků. Granularita interaktivního nastavení délky je 1 krok.

o

Rozdíl mezi počátkem a okamžikem přechodu musí být minimálně N sekund (zadáno v konfiguračním souboru). Konec intervalu musí být alespoň o 1 krok dále, než je okamžik přechodu.

Proces transformace rozeznává 2 intervaly: „minulost“ a „budoucnost“. „Minulost“ je od počátku intervalu (včetně) do okamžiku přechodu (včetně). „Budoucnost“ je od okamžiku přechodu (ale mimo něj!) až do konce intervalu (včetně). Parametry tedy mohou mít transformaci „minulosti“, „budoucnosti“, obě nebo žádnou… Jakmile aplikace přejde do predikčního (či analytického) režimu, bude blokovat jakoukoliv změnu vstupního parametru „Výpočetní interval“ (počáteční a koncový čas a délka kroku výpočtu). Nebude také žádná možnost, jak by uživatel mohl změnit „okamžik přechodu“. Pokud chce uživatel např. prodloužit počítaný interval dále do budoucnosti a nechce přitom vytvářet novou predikci (kvůli zachování ručních nastavení provedených po přechodu do predikce), použije funkci aktualizace predikce – viz kap. 4.4. Zatímco počátek a konec výpočtového intervalu se ukládají v rámci vstupního parametru „interval“ modelu, čas „okamžiku přechodu do predikce“ se ukládá pouze v rámci „desktopu“ (v predikčním režimu řetězcem "yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z'", v analytickém režimu náhradním řetězcem „future“ a v simulačním režimu [a v MOP] náhradním řetězcem „nowhen“). Dále je možno uvažovat o okamžiku současnosti („Now“, aktuální systémový čas), který by mohla jednotlivá okna návrhu řad a zobrazení výsledkových řad zobrazovat jako svislou čáru v grafu… Takový čas by se neukládal nikde. 4.2.1.2

Analytický režim

Přechod do analytického režimu je prováděn z podnabídky Nová analýza – se stejným obsahem jako má podnabídka Nová simulace a Nová predikce. (Stejným obsahem rozumíme odkazy na tytéž předpřipravené modely-šablony, jako jsou odkazovány z podnabídky Nová simulace a Nová predikce;

strana 111


tj. tyto modely-šablony jsou stále uložené jako typu „simulace“, analýza z nich vznikne až v průběhu „přechodu do analytického režimu“.) Proces je shodný s přechodem do predikce až na:

4.2.2

o

Vzniklý model nemá zadán čas přechodu (resp. okamžik přechodu nikde není uživatelsky vidět, do „desktopu“ se ukládá náhradní hodnotou „future“ a je možno si ho představit jako shodný či větší než je okamžik konce intervalu)22

o

Dialog přechodu neobsahuje čas přechodu. Obsahuje radio-tlačítka pro variantu zadávání délkou období nebo zadáním času počátku intervalu. Čas konce intervalu je zadáván vždy. Přepínač je implicitně nastaven na „délku období“ a tato délka je zase implicitně nastavena dle konfiguračního souboru v jednotce sekund (např. na „3 dny“). Čas konce intervalu je implicitně nastaven na aktuální datum a čas posledního okamžiku online dat v historických tabulkách databáze online dat M.

„Online“ veličiny pro návaznost na reálný běh modelovaného systému

„Online“ veličiny budou součástí „neutrální“ sady. Typu „online“ veličina bude přiřazen atribut „SuggestAsInvisible“, který způsobí, že třída nebude zobrazovaná v oknech návrhové tabulky a výsledkové tabulky, jelikož pro editaci definic „online“ veličin je určen dialog singulárních parametrů. Po provedení akcí „Nová predikce“ či „Nová analýza“ jsou naplněny nejen některé vstupní (ať již singulární či ne-singulární) parametry modelu, ale také (všechny) „online“ veličiny. Hodnoty „online“ veličin se z demonstračních důvodů také ukládají spolu s modelem. Tyto veličiny jsou přímo obrazy online veličin z databáze online dat „M“, či je z nich odvozena (ať již výpočtovým vzorcem, nahrazením výpadků, filtrací, či kombinací uvedeného). Ač nebudou „online“ veličiny součástí návrhové sady dmis, ale neutrální sady xmis, v „REM“ tabulce budou součástí položky s extmodref_id = 0. Přestože jsou online veličiny podobné spíše singulárním vstupům (způsobem plnění ze zdroje dat M), jsou také podobné výsledkům – např. tím, že její položky jsou zcela needitovatelné, a tudíž jsou určeny pouze k zobrazování! Online veličiny však také nejsou úplně ekvivalentem externích modelů:

22

Jelikož v analytickém režimu nelze uživatelsky měnit interval, nemusíme se ani bát, že by bylo potřeba měnit tento fiktivní okamžik přechodu. Nicméně v MOPu (tj. efektivně v simulačním režimu) by bylo možné změnit interval v Excel beze změny času „okamžiku přechodu“, proto je nutné místo fiktivního času někdy před začátkem intervalu ukládat „okamžik přechodu“ náhradní hodnotou „nowhen“ (mohlo by se to značit „past“, ale přeci jen: část „budoucnosti“predikčního intervalu nemusí být algoritmicky shodná s intervalem simulačního režimu). A pak i v analytickém režimu použijeme náhradní hodnotu („future“) namísto např. času okamžiku konce výpočetního intervalu, pro případ, že bychom v budoucnu chtěli i REGIOS propojit s Excelem v závislém režimu a chtěli pak předejít konfliktu při změně výpočetního intervalu analytického režimu v Excelu.

strana 112


Není to celý model (teoreticky externí model může být úplně jiný), ale vztahuje se vždy k současnému modelu (tím, že instance objektů, ke kterým se online data vztahují, by měly být fixovány „schématem“). Zároveň nemá smysl z uloženého modelu externě zobrazovat jeho online veličiny, ty jsou pouze obrazem skutečných online-hodnot v době uložení tohoto modelu. Online veličiny se (na rozdíl od externích modelů, které se zobrazují pomocí samostatných ikon v nabídce / na nástrojové liště) (ale pouze v predikčním a analytickém režimu) zobrazují v rámci oken (výsledkové tabulky / mapy) současného modelu jako světle modře podbarvené buňky; dále se zobrazují v okně výsledkových řad a jsou dostupné z výsledkového dialogu, kde mají také odpovídající položku „online“ filtru typu veličiny. Online veličiny nebudou zobrazeny v „návrhovém dialogu“, ani v oknech návrhové tabulky / mapy. V oknech výsledkové tabulky / mapy budou „online“ veličiny uvedené až na konci – za výstupy (hlavně kvůli udržitelnosti DisplayOrder…). DisplayOrder „online“ veličin musí být větší než DisplayOrder jakéhokoliv vstupu či výstupu a u „schématem zafixovaných“ online veličin bude začínat na hodnotě cca 1.000.000 * 1000… Bude vhodné, aby se „online“ veličiny, které mají stejný „fyzikální smysl“, jako existující vstupy / výstupy nějakého konkrétního elementu, jmenovaly podobně – tj. aby např. měly až na suffix „ (online)“ stejnou efektivní „3. úroveň identifikace“. Tím se např. ve „výsledkovém dialogu“ budou zobrazeny bezprostředně pod sebou (pokud budou zapnuté filtry jak vstupy / výstupy, tak „online“ veličiny. „Online“ veličiny budou součástí neutrální sady xmis a ponesou nový atribut (třídy objektů MOP) CalcNeutral23, který indikuje, že objekty nejsou součástí návrhové ani výsledkové sady. „Online“ veličiny budou tedy velmi podobné singulárním vstupům. Při načítání z / ukládání spolu s modelem do souboru „.model“ či sešitu „.xls“ bude mít tato třída vnitřní identifikaci listu „x_onlinesingular“ a název listu „Sonln“ [anglicky: totéž] {list bude implicitně neviditelný; „ouška“ listů budou světle modře podbarvená a na rozdíl od „Svst“ s „Svýst“ nebude existovat výsledkový ekvivalent „Sonln+“} a v souboru „.model“ bude v tabulce omc_x_onlinesingular (která bude i součástí „schématu“). V rámci objektového modelu MopElement bude každá online veličina představovaná objektem „Online veličina“ (iname = „onlinesingular“), která bude potomkem objektu „Singulární parametr“ a bude téměř shodná s třídou „Singulární vstup“ až na to, že nebude mít parametr „Náhradní hodnoty“. Zvláštností sady „online“ veličin bude, že ač jsou součástí neutrální sady, tak se během editace v aplikaci předpokládá konzistence s návrhovou sadou (jelikož jsou „online“ veličiny potomkem singulárních parametrů, udržují si existenční konzistenci s odkazovaným objektem – viz singulární parametry).

23

Do komentáře v kódu k atributu CalcNeutral přidat komentář „Nepoužívá se obecně tam, kde nepotřebujeme kopii ve výsledkové sadě, ale jen tam kde navíc neexistuje přímý vliv instancí této třídy na podobu výsledků.“ Do kontroly checkClassConsistency je potřeba přidat kontrolu, že třídy s atributem CalcNeutral nesmějí obsahovat výstupní parametry.

strana 113


Vedle položky nabídky Smazat výsledky přibude položka Smazat online veličiny (která ovšem maže pouze obsah parametrů „Hodnota“ objektů online veličin), což může být užitečné při ukládání velkého objemu dat. Vedle aktualizace externích modelů (v dialogu managementu externích odkazů) bude umožněno ručně aktualizovat všechny online veličiny. Navíc bude vedle tlačítka ruční aktualizace přepínač povolení „automatické periodické aktualizace“. Ta bude dle údajů o „periodě“ a „zpoždění za celou periodou“ v konfiguračním souboru Online.cfg pravidelně volat (v hlavním vláknu aplikace) aktualizaci zobrazení všech oken potencionálně obsahujících „online“ veličiny. Aktualizaci bude vhodné provést také při každém otevření modelu s časovou specifikací „okamžiku přechodu“ s hodnotou jinou než „nowhen“ (tj. v režimu jiném než simulačním). Pozn. Při zobrazení průběhů hodnot (ať již externích parametrů, vlastních parametrů či „online“ veličin, ať již singulárních nebo ne-singulárních) je okno zobrazení průběhu odolné proti „zmizení“ dané veličiny / parametru… Předpokládá se, že uživatel si vedle schématem zafixovaných „online“ veličin (a jejich transformací – viz dále) může definovat vlastní „online“ veličiny, včetně transformací. 4.2.2.1

Rozhraní pro definici „online veličin:

Bude upraveno rozhraní REGIOS offline pro definici singulárních veličin: Dialogu definic singulárních veličin přibude vedle záložky vstupů a výstupů ještě třetí záložka pro „online“ veličiny, která bude fungovat analogicky. Ač zobrazení hodnot „online“ veličin je aktivní jen predikčním a analytickém režimu, záložka pro definici „online“ veličin bude viditelná nejen v případě predikčního či analytického režimu, ale i v režimu simulačním, a to ze dvou důvodů: (1) kvůli možnosti přípravy definic „online“ veličin v modelech-šablonách, které jsou uloženy v simulačním režimu a až při přechodu do predikčního / analytického režimu se tento režim nastaví; (2) kvůli symetrii s přístupností dialogu (definic) transformací (důvody přístupnosti dialogu transformací – viz odstavec o přístupnosti dialogu transformací v kapitole 4.2.3). Vlastní dialog editace definice jedné online veličiny bude shodný s dialogem editace definice 1 singulárního vstupu, avšak bude postrádat prvky sloužící k editaci specifikace náhradních hodnot. Název „online“ veličiny musí být unikátní pro danou instanci (tj. vzájemně s ostatními „online“ veličinami, singulárními vstupy a singulárními výstupy) a třídu (ne-singulární identifikační, vstupní a výstupní parametry). To, že jsou „online“ veličiny uchovány v neutrální sadě, má jeden malý nedostatek: Pokud je „online“ veličina přiřazena k objektu, který (dle třídy a pole identifikačních parametrů) existuje v návrhové sadě, ale neexistuje ve výsledkové sadě, je z hlediska návrhové sady vše v pořádku, avšak ve výsledkové sadě není možnost zobrazení hodnoty takové veličiny. Zejména okno výsledkové tabulky a

strana 114


modul SQLexport musejí být ošetřeny, aby se takovou veličinu nesnažilo přiřadit neexistující instanci právě zobrazované třídy.

4.2.3 Transformace: verifikace, dopočet vyhlazení online veličin Implementace akcí „Nová predikce“ či „Nová analýza“ zahrnuje: (1) naplnění (všech) „online“ veličin a (2) vlastních (některých) vstupních (ať již singulárních či ne-singulárních) parametrů modelu. Akce 1 bude také samostatně volána při vyvolání akce „aktualizace zobrazení online veličin“. Obě akce jsou metody s parametrem, zda jde o predikci či analýzu. Tyto metody budeme nazývat „transformace“. Pozor! Pokud krok výpočtu není shodný s přirozeným krokem zdroje dat M, je nutné nejprve číst hodnoty s přirozeným krokem zdroje M a tyto zprůměrovat, a až pak provádět další činnosti transformací…! Většina online veličin se bude načítat do časového intervalu ohraničeného počátkem intervalu a koncem intervalu (a navíc transformace minulosti bude plnit data před „okamžik přechodu do predikce“ a transformace budoucnosti za „okamžikem přechodu do predikce“), nicméně obecně to omezení není, např. venkovní teplotu vzduchu bude vhodné plnit ještě 3 dny před počátek intervalu (kvůli „filtrované teplotě okolí“ potřebné pro neuronový model spotřeby) a zároveň ještě nějaký interval po konci intervalu (kvůli „předvídané teplotě okolí“ potřebné pro GVT – generátory výstupní teploty). Zatímco u vstupních parametrů se provádí jak transformace minulosti, tak transformace budoucnosti, u „online“ veličin se provádí pouze transformace minulosti. Specifikace transformace minulosti je sada několika sloupců / parametrů: 

pluspast – obsahující buď text „!EXT“ (to však není povoleno v MOP; značí např. dynamicky určený začátek časového intervalu čtení) nebo číslo – počet minut před začátkem výpočetního intervalu (musí být celočíselným násobkem „přirozeného“ kroku zdroje dat M… V případě, že není, je toto číslo bez varování uvažováno jako nejvyšší nižší celočíselný násobek „přirozeného“ kroku zdroje dat M) – definuje počátek časového intervalu načítání hodnot ze zdroje M… [Ve většině případů bude zadán 0. Pro filtrovanou teplotu okolí to bude číslo 60*24*3.]



plusfuture – obsahující buď text „!EXT“ (to však není povoleno v MOP; značí např. dynamicky určený začátek časového intervalu čtení) nebo číslo – počet minut po konci výpočetního intervalu (musí být celočíselným násobkem „přirozeného“ kroku zdroje dat M… V případě, že není, je toto číslo bez varování uvažováno jako nejvyšší nižší celočíselný násobek „přirozeného“ kroku zdroje dat M) – definuje konec časového intervalu načítání hodnot ze zdroje M… [Ve většině případů bude zadán 0. Pro filtrovanou teplotu okolí to bude číslo strana 115


nenulové.] Pro vstupy je implicitním koncem intervalu načítání dat vždy konec výpočetního intervalu a pro „online“ veličiny je to buď také konec výpočetního intervalu, nebo poslední čas hodnot zdroje M, podle toho, který čas je nižší. Oba tyto případy jsou v případě zadání nenulového plusfuture posunuty o daný počet minut dopředu. 



originspec – obsahující buď: o

text „!EXT“ (to však není povoleno v MOP; značí např. zcela jiný, nestandardní, zdroj dat),

o

text „$<src_id>$“ – kde <src_id> je identifikátor zdroje dat (pro identifikaci src_id zdrojového bloku zdroje M v konfiguračním souboru) a je identifikátor veličiny ve zdroji dat M, nebo

o

text „#<číslo>“, kde <číslo> je číslo typu double ve formátu s desetinnou tečkou – pak se nenačítá žádná hodnota ze zdroje dat M, ale hodnota je určena v daném intervalu (tj. i s respektováním „pluspast“ a „plusfuture“) rastrem vyplněným touto konstantou,

fillgap_type – obsahující buď text „!EXT“ (to však není povoleno v MOP; značí nějaký specifický způsob nahrazení) nebo řetězec – způsob nahrazení neplatného intervalu… možné hodnoty: „0“ – žádné nahrazení neplatných hodnot; „<číslo>“ [kde <číslo> je kladný počet minut] – částečné nahrazení neplatných hodnot: Pokud u neplatného intervalu jsou přítomny obě dvě krajní platné hodnoty, je provedena lineární interpolace, ale jen tehdy, pokud jsou tyto body vzdáleny max. <číslo>. Pokud jsou vzdáleny více, nebo je k dispozici jen jedna krajní platná hodnota, je tato hodnota protažena, ale max. na délku <číslo> od tohoto bodu. Pokud není k dispozici ani jedna krajní platná hodnota, nejsou neplatné hodnoty nahrazeny ničím, „-1“ – nahrazení neplatných hodnot: Pokud u neplatného intervalu jsou přítomny obě dvě krajní platné hodnoty, je provedena lineární interpolace (nezávisle na tom, jak je tento interval dlouhý!), pokud je k dispozici jedna krajní platná hodnota, je tato protažena po celý neplatný interval, a pokud není k dispozici ani jedna krajní platná hodnota, je do celého intervalu doplněna implicitní hodnota (hodnota z šablony) nebo je (v případě aktualizace predikce) ponechána hodnota, která je v současnosti v parametru (v daném kroku) nastavena24. (Další možností je doplňovat explicitně zadanou konstantu [nutno pro ni

24

Implicitní hodnotu nemůžeme využít při aktualizaci predikce, protože šablona v této chvíli není použita. (Mohli bychom si sice během vytvoření nové predikce z šablony zapamatovat absolutní cestu k šabloně, ale obecně v okamžiku aktualizace predikce tato šablona již nemusí existovat.)

strana 116


vytvořit další parametr fillgap_type_srgconst objektu Transformace], kterážto by byla vlastně editovatelná i v šabloně, tj. zachovala by se výhoda, kterou čekáme od implicitní hodnoty.),

(V případě typu „0“ a „“ jsou neplatné a nenahrazené intervaly nazývané „fatálně neplatné“) 

smooth – obsahující buď text „!EXT“ (to však není povoleno v MOP; značí např. dynamické určení velikosti průměrovacího okna nebo jiný typ průměrování) nebo číslo – specifikace šířky okna vyhlazovacího klouzavého aritmetického průměru <-N minut; +N minut>, tj. např. hodnota „0“ znamená nevyhlazovat,

Specifikace transformace budoucnosti obsahuje jediný sloupec / parametr: 

type – je to řetězec obsahující buď text „!EXT“ (to však není povoleno v MOP) nebo jednu ze dvou specifikací: specifikaci průměru nebo specifikaci konstanty. Specifikace průměru: text „@0“ (pro doplnění hodnoty konstantou – poslední hodnotou z minulosti – ať již je platná, či nikoli… výsledek má stejnou platnost) nebo text „@<číslo>“, kde <číslo> je kladný počet minut (pro doplnění hodnoty konstantou – aritmetický průměrem za období dané délky těsně před okamžikem přechodu do predikčního režimu – výsledek je platný, pokud alespoň 1 hodnota z průměrovaného intervalu je platná). Zdrojem z minulosti je až nahrazený a vyhlazený vstup v intervalu minulosti. Platnost a tedy i „fatalita“ hodnot budoucnosti je tedy již plně určena transformací minulosti. Specifikace konstanty: text „#<číslo>“, kde <číslo> je číslo typu double ve formátu s desetinnou tečkou (pro doplnění této konstanty bez ohledu na hodnoty minulosti)

V rámci transformace minulosti se provádí postupně: 1. Pokud originspec začíná znakem „$“: Načtení hodnot ze zdroje M. Interpretujeme originspec jako „$<src_id>$“. Aplikací dotazu query [pro příslušný zdrojový blok se src_id=<src_id>; pro %time% naplněný hodnotou požadované časové značky; pro %id% naplněný ] získáme v daném rastru průměrné hodnoty (s případnou neplatností indikovanou SQL hodnotou NULL). Případné neplatné hodnoty se pro účely aplikace dále udržují jako hodnota NaN. Pokud originspec je číslo: V daném rastru získáme konstantu – vždy platnou. Pokud originspec je „!EXT“: Zdrojem dat je něco jiného, nejčastěji nějakým vzorcem / algoritmem spočtená hodnota strana 117


z několika veličin (tagů), jejichž identifikace je určena kódem DLL. Do budoucna si lze představit možnost, že by originspec obsahoval přímo specifikaci více id (tagů), včetně způsobu jejich kombinace (výpočtu) do výsledné hodnoty –pomocí omezeného počtu definovaných operací. Toto by umožňovalo zadat strom operací zahrnujících aritmetické operace a podmínky, přičemž by platnost či neplatnost (v této fázi již reprezentovaná hodnotou NaN) byla automaticky odvozována ze struktury operací dle jejich charakteru (např. aritmetická operace se pro potřeby platnosti změní v logickou operaci AND, operace podmínky se změní v podmíněný výraz dvou platností, atp.). Alternativně si lze představit originspec zadávaný útržkem kódu v jazyce C#, který by byl za běhu kontrolován na bezpečnost a kompilován… Nicméně prozatím ani jedna z těchto možností implementována nebude. 2. Nahrazení výpadků dle algoritmu definovaného ve fillgap_type. 3. Vyhlazení klouzavým centrovaným aritmetickým průměrem hodnot (jen těch platných) z intervalu <-N minut; +N minut>, kde N je hodnota položky smooth specifikace transformace minulosti. Transformace budoucnosti se provádí (až na případné výjimky pro specifikaci „!EXT“) až po transformaci minulosti. Pokud není použita transformace budoucnosti, je vhodnější, aby interval výsledné veličiny byl zkrácen jen na období minulosti, než aby byl v části „budoucnost“ doplněn hodnotami „NaN“. Data ve zdroji M jsou považována za veličiny v základních jednotkách SI. Stejně tak budou v základních jednotkách případné vstupy a výsledky výpočtů „!EXT“-transformací v „háčcích“ DLL knihoven (což je v souladu i např. se systémem „vzorců“ – viz kap. 3.3.2). Je tedy třeba automaticky při plnění všech „online“ veličin provést přepočet na uživatelské jednotky. Je každopádně potřeba, aby byl uživatel informován o tom, které časové úseky kterých veličin byly neplatné a zároveň byly nahrazeny (Je vhodné uvádět také, čím byly hodnoty nahrazeny. Bude dobré setřídit tato hlášení v zobrazeném seznamu od největší sumy délek nahrazených intervalů k nejmenší.)! K tomu účelu bude vytvořeno okno (popsané v kap. 4.2.3.2), obsahující položky typu TransMessage obsahující jednotlivá hlášení. Okno s hlášeními TransMessage bude obsahovat informace o transformaci vstupů, ale nikoli „online“ veličin! Bude obsahovat informace o neplatnostech při transformaci jak minulosti, tak budoucnosti. (Protože (1) budoucnost je buď celá platná či celá neplatná, (2) budoucnost je neplatná, jen když něco v minulosti je neplatné,

strana 118


má asi smysl neplatnost budoucnosti řešit pouze přílepkem „ + budoucnost“ k textu o neplatnosti minulosti). Bude zvlášť zobrazovat „co bylo neplatné a bylo nahrazeno“ a to „co bylo neplatné a zůstalo neplatné“. Předpokládáme, že u vstupních parametrů budou transformace vždy nahrazené a vyhlazené. U „online“ veličin budeme asi nejčastěji zavádět dvojici ze stejného originspec, z nichž 1. bude nenahrazovaná a nevyhlazovaná a 2. naopak nahrazovaná a vyhlazovaná. Je vhodné, aby pomocí nějakých rozlišovacích znaků v názvu25 byly rozlišeny následující kategorie online veličin: 

surové – na které nebyla aplikována náhrada neplatných intervalů ani vyhlazení ani explicitní výpočet (možný pouze pomocí specifikace „!EXT“),



vyhlazené – na které byla aplikována náhrada neplatných intervalů i vyhlazení.

(Ostatní kombinace nahrazování / vyhlazování, tj. [nahrazené ale nevyhlazené] a [nenahrazené a vyhlazené], zřejmě nebudou příliš využívány.) Tady by se zdálo, že by se hodilo rozlišení „online“ veličin {u vstupů by to uživatele nezajímalo (navíc bychom to k nesingulárním vstupům neuměli zavést)} pomocí nějakých filtrů – tj. nový sloupec pro „online“ veličiny (obsahoval by obecně „[F][S]“ {nahrazené („filled“), vyhlazené („smoothed“)}, ale možná také jen podmnožinu kombinací: „“ / „FS“) – musel by být vždy ve shodě s transformací, která ho plní (byla by otázka, kdy to kontrolovat.. Asi při editaci on-line veličin, pokud je k ní již transformace; a vždy při editaci transformace… A „!EXT“ by kontrolovat nešlo)… Pak by to šlo použít ve filtrech výsledkového dialogu… Toto tedy nebude implmentováno! Má to poměrně omezené možnosti (také si lze představit filtraci podle typu nahrazení: fatální / nefatální / rezistentní / nerezistentní) a „online“ veličiny již jsou rozlišeny názvem. Spíše si lze představit, že v budoucnu budeme moci filtrovat na složitější výrazy, tj. např. „online veličina, co má přiřazenou transformaci se zadaným parametrem fillgap = 2“ nebo „vstup, co nemá přiřazenou žádnou transformaci“, apod., tj. bez toho, abychom „online“ veličinám nebo vstupům přidávali vlastní sloupce, které by stejně jen duplikovali (a komplikovaně kontrolovali na shodu) parametry transformace… Transformace jak vstupních parametrů, tak „online“ veličin mohou vést k tomu, že výsledný parametr bude zčásti nebo zcela obsahovat „neplatné“ NaN hodnoty. Je na uživateli, aby neplatné hodnoty v rámci vstupních parametrů pomocí ruční editace řad eliminoval, jinak nebude možné provést korektně výpočet modelu. Naopak NaN hodnoty u „online“ veličin výpočtu modelu nevadí. Nicméně

25

Jelikož bude možné, že „online“ veličina bude mít kvůli svému významu základ názvu shodný s některým vstupem, budou se dále muset odlišit obě varianty „online“ veličin od vstupu: Např. vlastní vstup bude mít pouze základ názvu, „surová“ online veličina k tomu přidá text „ (on.)“ a „doplněná a vyhlazená“ online veličina přidá text „ (on.*)“

strana 119


v praxi budeme až na naprosté výjimky pro vstupy používat nahrazení, takže NaN hodnoty budou výjimečné… nicméně je třeba, aby na to aplikace byla plně připravena. Hodnota NaN u vstupních parametrů musí být tedy v oknech aplikace ošetřena: –

u okna návrhové mapy / tabulky: Je třeba ošetřit případ zobrazení konstanty „NaN“ v buňce

–

u okna návrhové řady: Je třeba ošetřit tyto případy: konstantní hodnota NaN, hodnota NaN v rastru (na začátku, na konci, uprostřed, vícenásobně či celý interval složený jen z NaN) Je třeba ošetřit i grafickou editaci řady! …U řady typu „Lomové body“ bude vhodné hodnoty „NaN“ vůbec nepovolit! [Jejich povolení by bylo velmi komplikované (každý lineární úsek by musel mít oba souvislé konce buď oba NaN nebo oba ne-NaN), navíc je to zřejmě zbytečné – transformace nebudou produkovat řady zadané pomocí lomových bodů…]

Hodnota NaN u „online“ veličin musí být v oknech aplikace ošetřena: –

u okna výsledkové tabulky, výsledkové mapy, tlakového diagrami: Pokud je v buňce zobrazena vstupní řada, je v závislosti na zobrazovaném čase zobrazena aktuální hodnota v tomto časovém kroku. Pokud je hodnota NaN, musí být zobrazeno „NaN“. V případě zobrazení hodnot vstupního parametru v mapě v barevné škále (Network Plot) musí být hodnota NaN zobrazena jako chybějící čára (tj. stejně jako při prázdné hodnotě výstupního parametru);

–

u okna výsledkových řad: Zajistit, aby NaN bylo podporováno jak seznamem hodnot vlevo (zobrazení „NaN“), tak v grafu vpravo (přerušená čára grafu). Nutno podporovat výskyty intervalů hodnot NaN na začátku, na konci, uprostřed, vícenásobné či celý interval složený jen z NaN…

Je třeba ošetřit okna návrhové řady a okna výsledkových řad aby i izolované běžné číselné hodnoty nějakým způsobem (tečkou, krátkou čárou) zobrazovaly. Izolovanými číselnými hodnotami rozumíme buď hodnotu z obou stran obklopenou NaN nebo 1. hodnotu v řadě následovanou NaN nebo poslední hodnotu v řadě následující po NaN. Transformace „!EXT“ mohou být velmi flexibilní: Např. mohou řešit minulost a budoucnost najednou, např. u transformace venkovní teploty se nejprve vyplní minulost a podle předpovědi počasí budoucnost a následně se nesoulad v návaznosti upraví jak částečným vychýlením konce „minulosti“, tak počátku „budoucnosti“, tak aby přechod mezi nimi byl dostatečně hladký. Objekt transformace (jak vstupních parametrů, tak „online“ veličin) má položky: 

[identifikační parametr] string dest_class (title [česky]: „Typ objektu“, title [anglicky]: „Object type“, comment [česky]: „Interní invariantní identifikátor typu objektu: Neměl by být nikdy zadáván ručně, ale pouze skrze příslušné dialogy.“, comment [anglicky]: „Internal invariant identifier of the object type: It should be never set manually. Only corresponding dialog should be used to set it.“) – typ objektu (reprezentovaný iname třídy), k jehož parametru se transformace vztahuje;

strana 120




[identifikační parametr] string dest_instance (title [česky]: „Identifikace objektu“, title [anglicky]: „Object identification“, comment [česky] = „Uspořádaný seznam hodnot identifikačních parametrů objektu oddělených znakem '^': V názvech větví musejí být nahrazeny některé znaky, a to postupně: '\' -> '\b', '#' -> '\n', '^' -> '\s'. Prázdný řetězec je reprezentován znakem '#'.“, comment [anglicky] = „Ordered object identification parameters values list separated by '^' character: Some branch name characters must be replaced, in this order: '\' -> '\b', '#' -> '\n', '^' -> '\s'. Empty list is represented by '#' character.“) – zřetězené pole (funkcí SafeJoin26) hodnot identifikačních parametrů objektu, k jehož parametru se transformace vztahuje;



[identifikační parametr] string dest_param (title [česky]: „Parametr“, title [anglicky]: „Parameter“, comment [česky]: „Interní invariantní identifikátor parametru: Neměl by být nikdy zadáván ručně, ale pouze skrze příslušné dialogy.“, comment [anglicky]: „Internal invariant identifier of the parameter: It should be never set manually. Only corresponding dialog should be used to set it.“) – „iname“ parametru, ke kterému se transformace vztahuje;

(předchozí 3 parametry představují identifikaci konkrétního parametru – ať již „online“ veličiny, singulárního či ne-singulárního parametru) 

[vstupní parametr] double transpast_pluspast (title [česky] = „Rozšíření do minulosti“, title [anglicky] = „Extend to the past“, comment [česky] = „Časový interval, o který se rozšíří řada směrem do minulosti“, comment [anglicky] = „Time span of extension of the series to the past“),



[vstupní parametr] double transpast_plusfuture (title [česky] = „Rozšíření do budoucnosti“, title [anglicky] = „Extend to the future“, comment [česky] = „Časový interval, o který se rozšíří řada směrem do minulosti“, comment [anglicky] = „Time span of extension of the series to the past“),



[vstupní parametr] string transpast_originspec (title [česky] = „Původ“, title [anglicky] = „Origin“, comment [česky] = „Specifikace původu hodnot: buď text začínající znakem '$' (zbytek textu je pak identifikátor tagu v databázi, ze kterého je plněna hodnota parametru), nebo text začínající znakem '#' (zbytek textu je pak přímo číslo s desetinnou tečkou, kterým se plní hodnota parametru“, comment [anglicky] = „Value origin specification: either text starting with '$' character (then the rest of the text is identifier of the database tag, by which is parameter value filled) or text starting with '#' character (then the rest of the text is directly the number using dot as a decimal separator, by which is parameter value filled“),

26

Tímto (a také zavedením singulárních parametrů) se funkce SafeJoin dostává definicí oddělovačů a náhrad vedle použití při uložení „desktopu“ aplikace a při ukládání údajů „.NET Framework Settings“ též do ukládání hodnot modelu, což ještě zvyšuje důležitost již tak důležitého požadavku na neměnnost jejího formátu.

strana 121




[vstupní parametr] string transpast_smooth (title [česky] = „Vyhlazení“, title [anglicky] = „Smoothing“, comment [česky] = „Poloměr průměrovacího okna pro vyhlazení hodnot parametru“, comment [anglicky] = „Averaging window radius for parameter value smoothing“),



[vstupní parametr] string transpast_fillgap_type – specifikace transformace minulosti (může být prázdná, ale standardně bude vyplněná)27;



[vstupní parametr] string transfuture – specifikace transformace budoucnosti (může být prázdná)28.



[vstupní parametr] int resistency – specifikace rezistence („0“ = nerezistentní, „1“ = rezistentní) – viz kap. 4.4

Objekt transformace „online“ veličin oproti transformaci vstupních parametrů OBVYKLE NEMÁ specifikaci transformace budoucnosti (ani specifikaci rezistence), ovšem v některých případech se tato může hodit (zobrazování receptů, nepoužívané predikce počasí, apod.). Tudíž bude existovat jednotný objekt transformace pro všechny typy parametrů, vč. online veličin. U singulárních parametrů (singulárních vstupů, výstupů a online veličin) bude odkaz vedený ne na zdánlivý odkazovaný objekt (3. úroveň identifikace), ale na singulární objekt. Avšak při jakékoliv prezentaci uživateli bude toto transformováno do / z 3. úrovně identifikace. Všem typům singulárních objektů bude přiřazen atribut „SuggestAsInvisible“, který způsobí, že třída nebude zobrazovaná v oknech návrhové a výsledkové tabulky, jelikož pro editaci definic singulárních parametrů bude určen samostatný dialog. Objekty transformace budou implementovány třídou Transformation (iname = „transformation“) s atributem CalcNeutral = true (stejně jako třída „online“ veličin) a atributem „uggestAsInvisible = true (který způsobí, že třída nebude zobrazovaná v oknech návrhové a výsledkové tabulky, jelikož pro editaci definic transformací bude určen samostatný dialog). Instance třídy budou ukládány v souboru „.xls“ v listu „Tr“ [anglicky: totéž] (vnitřní identifikace „x_transformation“) {list bude implicitně neviditelný; „ouška“ listů budou světle modře podbarvená a neexistuje výsledkový ekvivalent „Tr+“} a v souboru „.model“ v tabulce omc_x_transformation. Tato tabulka bude i součástí schématu. Objekty transformace tedy budou (pouze) součástí (výpočtově) neutrální sady. Na rozdíl od případu singulárních veličin, které si kontinuálně udržují existenční konzistenci na odkazovaný objekt, nebudou transformace kontrolovat existenci cílového singulárního parametru či

27

Každopádně by bylo vhodné, aby komentáře daných parametrů obsahovaly podrobný význam povolených hodnot. 28

Každopádně by bylo vhodné, aby komentář parametru obsahoval podrobný význam povolených hodnot.

strana 122


instance objektu cílového ne-singulárního parametru – až do chvíle, kdy budou potřeba provést, tj. při vytvoření analýzy či predikce a při aktualizaci predikce. V takovém případě bude v případě neexistence cíle zobrazeno běžné modální hlášení uživateli o neexistenci cílového parametru transformace. Transformace nebudou moci být logicky zřetězovány, tudíž nezáleží na jejich pořadí. Teoreticky můžeme definovat, že transformace s originspec „!EXT“ budou provedeny až po ostatních transformacích a jejich vzájemné pořadí provedení také může být DLL kódem definováno. Pak by mohly být zřetězovány transformace s originspec „!EXT“ a to mezi sebou navzájem, nebo v návaznosti na ne-„!EXT“ transformace, avšak je potřeba brát ohled na to, zda použité výsledky jiných transformací jsou nahrazené a / nebo vyhlazené, tj. je otázka, zda bude správný zdroj pro navazující „!EXT“-transformace k dispozici. 4.2.3.1

Editace (definic) transformací

Protože se transformace mohou vztahovat i k ne-singulárním parametrům, není vhodné implementovat rozhraní editace transformací jako součást dialogu definic singulárních parametrů. Bude proto vytvořen dialog editace (definic) transformací: V nabídce aplikace Otevřít přibude položka Online transformace [anglicky: Online transformations], která vyvolá první dialog: Tento dialog bude obsahovat seznam, jehož položky budou 3. úrovně identifikací parametrů (vstupních a „online“), ke kterým se definovaná transformace vztahuje. Dále bude dialog obsahovat typická tlačítka „Nová transformace“, „Editovat transformaci“, „Smazat transformaci“, stejně jako tlačítka „Ok“ a „Zrušit“. Smazání transformace je podmíněno konfirmací uživatelem. Tlačítka „Nová transformace“, „Editovat transformaci“ vedou do druhého dialogu. Druhý dialog obsahuje vedle tlačítek „Ok“ a „Zrušit“ vlastní editační prvky konkrétní transformace: 

textové pole pro zadání typu objektu, k jehož parametru se transformace vztahuje (Pole bude volně editovatelné, ale pokud bude obsahovat něco jiného, než title existující třídy, která má alespoň 1 vstupní parametr, bude pole podbarveno oranžově a tlačítko „Ok“ bude v tom případě nepřístupné [neaktivní]. Pole bude mít rozbalovací nabídku obsahující úplný seznam povolených hodnot. Obsah tohoto pole bude po stisknutí „Ok“ převeden na iname příslušné třídy.);



textové pole pro zadání identifikace instance objektu, k jehož parametru se transformace vztahuje (Pole bude volně editovatelné, ale pokud bude obsahovat něco jiného, než validní identifikaci existující instance [třídy zvolené v prvním editačním prvku] nebo pokud je již podbarven oranžově první editační prvek, bude pole podbarveno oranžově a tlačítko „Ok“ bude v tom případě nepřístupné [neaktivní]. Pole bude mít rozbalovací nabídku obsahující úplný seznam povolených hodnot. Obsah tohoto pole bude po stisknutí „Ok“ převeden na zřetězené pole hodnot identifikačních parametrů objektu.);



textové pole pro zadání názvu (title) parametru objektu, k němuž se transformace vztahuje (Pole bude volně editovatelné, ale pokud bude obsahovat něco jiného, než validní title strana 123


parametru [třídy zvolené v prvním editačním prvku] nebo pokud je již podbarven oranžově první editační prvek, bude pole podbarveno oranžově a tlačítko „Ok“ bude v tom případě nepřístupné [neaktivní]. Pole bude mít rozbalovací nabídku obsahující úplný seznam povolených hodnot. Obsah tohoto pole bude po stisknutí „Ok“ převeden na iname zvoleného parametru třídy.); 

další textová pole pro zadání parametrů specifikace transformace minulosti a budoucnosti (a rezistence pro aktualizaci predikce), která mohou být obecně i prázdná či nést (nikoli validně pro MOP) hodnotu „!EXT“. Tato jednotlivá pole mohou být v rámci režimu „správy schématu“ individuálně zamykána (příznak locked) pomocí klávesových zkratek – podobně jako parametry běžných objektů!

Je třeba přidat nový zvláštní režim volání Prediktoru / MOPEDu pro editaci (definic) transformací z Excelu – zcela analogicky, jako již existují režimy pro editaci cest, filtrů výstupů, singulárních parametrů, apod. Dialog transformací vyvolávaný z Prediktoru / MOPEDu (a stejně tak zvláštní režim volání Prediktoru / MOPEDu pro vyvolání tohoto dialogu) bude přístupný i v simulačním režimu (ničemu to v zásadě nevadí), a to ze dvou důvodů: (1) Je třeba mít nástroj na editaci modelů-šablon, které jsou uloženy v simulačním režimu a až při přechodu do predikčního / analytického režimu se tento režim nastaví. (2) Není možné rozlišit predikční / analytický a simulační režim při práci v Excelu, takže volba na vyvolání zvláštního režimu editace transformací z Excelu musí být přístupná vždy. 4.2.3.2

Hlášení o výsledcích transformací

Výsledky transformací budou reprezentovány sadou hlášení. Tato hlášení se uchovávají perzistentně v objektech typu TransMessage uchovávaných spolu s modelem, ale v rámci „výpočetně neutrální“ sady. Okno s těmito hlášeními bude zobrazeno po přechodu do analytického či predikčního režimu (a po aktualizaci predikce). Zároveň jej lze po zavření vyvolat i zpětně po jeho zavření ručně z aplikační nabídky. Okno bude nemodální a bude se ukládat společně s „desktopem“ aplikace (pouze pozice a velikost okna). Vždy bude možná maximálně jedna instance tohoto typu okna: Pokud je okno již zobrazeno, aplikace se do něj pouze přepne (pokud je minimalizované, tak se při tom deminimalizuje). Typ objektů TransMessage bude „čistě výstupní“ objekt, stejně jako např. objekt „uzlu cesty“. Také bude mít příznak nezobrazování v okně výsledkové tabulky. Objekty se budou ukládat do souborů „.model“ v tabulkách omc_r_transmessage a do souboru „.xls“ se budou ukládat do listu „TrHl+“ [anglicky „TrMsg+“] (vnitřní název bude „x_transmessage“; barva „oušek“ listů bude světle modrá (jako u jiných listů tříd výpočetně neutrální sady); listy však budou implicitně neviditelné).

strana 124


Typ TransMessage (iname = „transmessage“, title [česky] = „Zpráva transformace“, title [anglicky] = „Transformation message“; atributy „WaterInstancesAllowed“ = true a „SteamInstancesAllowed“ = true, „NoDesign“ = true, „SuggestAsInvisible“ = true, „CalcNeutral“ = true) bude mít tyto parametry: 

[identifikační parametr; text] message_text – Text vlastního hlášení (iname = „message_text“, title [česky] = „Text“, title [anglicky] = „Text“, comment nedefinován) – kompletní text hlášení;



[vstupní parametr; int] transresult_type – určuje, zda je hlášení typu „co bylo neplatné a bylo nahrazeno“ (hodnota = „0“) nebo typu „co bylo neplatné a zůstalo neplatné“ (hodnota = „1“).

Pořadí jednotlivých hlášení v tabulce (a tudíž pořadí objektů typu TransMessage) nebude nést žádnou podstatnou informaci (stejně jako nenese pořadí žádných jiných objektů), nicméně tyto objekty budou generovány tak, aby hlášení o nejdelší sumě (původně) neplatných intervalů byla zobrazena nahoře. Vlastností tohoto řešení bude, že text hlášení zůstává nezměněn, pokud uživatel aktualizuje systém na novější verzi (která by mohla text hlášení změnit) nebo přepne z jedné jazykové verze na jinou. Změny se každopádně projeví po vytvoření nové analýzy či predikce (a po aktualizaci predikce).

4.2.4 Načtení predikovaných online veličin a jejich vazba na vstupy modelu Predikovanými online veličinami budou parametry předpovědi počasí, zejména předpověď venkovní teploty. Základní načtení predikovaných veličin se bude provádět při přechodu do predikčního režimu (a při aktualizaci predikce) – v rámci transformace budoucnosti příslušných veličin. Předpokládá se specifikace transformace budoucnosti pomocí zadání „!EXT“, tj. bude možné zpracovat předpověď počasí pouze v REGIOSu, nikoli v MOPu. Vlastní specifický kód zajistí jak načtení dat ze specifického zdroje (databáze, obecně jiná než je zdroj dat M, případně veřejný zdroj na webu), tak případnou kompenzaci granularity předpovědi s granularitou nastaveného výpočetního kroku (např. pokud je předpověď vývoje venkovní teploty uváděna po celých hodinách a výpočetní interval má krok délky 5 minut, může algoritmus provést buď lineární interpolaci, či proložení polynomem, apod.) či řešení chybějících dat na okrajích výpočetního intervalu, případně v celém intervalu. Mimo provádění načtení predikovaných dat při přechodu do predikčního režimu a při aktualizaci predikce může být potřeba vyvolat načtení predikovaných dat ručně. To v podstatě spočívá v modifikaci aktualizace predikce ovšem z jistých odchylek: 1. bez posunu okamžiku přechodu do predikce, 2. zpracování pouze transformací budoucnosti, 3. zpracování transformací pouze pro vybrané parametry (a protože předpokládáme zadání pomocí „!EXT“, neměly by tyto transformace záviset na výsledcích jiných transformací). strana 125


Samostatné načtení predikovaných dat bude vyvoláváno položkou Aktualizovat předpověď počasí z aplikační nabídky Soubor, případně tlačítkem z nástrojové lišty.

4.3 Systém korekcí modelu spotřeby podle aktuálních online veličin Principem systému korekcí bude automatické určení koeficientu výkonu spotřeby (zadávaného jako vstupní parametr kategorie spotřeby). Předpokladem pro to je, že kategorie spotřeby budou reprezentovat oblasti spotřeby s měřením výkonu (či průtoku spolu s dvojicí teplot – přívodu a vratu) v jediném bodě („pata oblasti“). Místo koeficientu spotřeby takovéto oblasti bude v příslušném parametru kategorie uvedeno „!EXT“. (Tento systém korekcí je tudíž určen jen pro REGIOS, nikoli pro MOP.) Základem ovládání systému korekcí bude přepínač – singulární vstupní parametr „řízení korekce výkonu“ pro každou separovanou oblast spotřeby. Polohy tohoto parametru jsou: 

„0“ – řízení pomocí vstupu „Ruční zadání korekce výkonu“



„–1“ – řízení pomocí dorovnání na vstupní parametr měřeného průtoku



kladné celé číslo – řízení pomocí analogie s předchozími dny

Systém korekcí bude pracovat jinak v simulačním, analytickém a predikčním režimu. Odlišnost však bude spočívat pouze v rozdílném plnění přepínače „řízení korekce výkonu“. Ten bude v simulačním režimu obsahovat vždy29 hodnotu „0“. V analytickém režimu a v intervalu minulosti predikčního režimu bude pomocí transformace minulosti naplněn hodnotou 1. V intervalu budoucnosti predikčního režimu bude plněn transformací budoucnosti hodnotou 2. Teoreticky by tento vstupní přepínač mohl být řadou typu „lomové body“ s bodem okamžiku přechodu do predikce reprezentovaným nespojitým bodem, což by umožňovalo měnit granularitu kroku, avšak jelikož změnu granularity kroku během práce v predikčním režimu neumožňujeme, může být přepínač jak řadou typu „lomové body“, tak řadou typu „rastr“. Ke každé oblasti spotřeby budou vedle parametru „řízení korekce výkonu“ zaveden: 

singulární vstupní parametr „ruční zadání korekce výkonu“,

29

Zajistit určitou hodnotu v simulačním režimu nebude jednoduché. Pomocí schématu to udělat nemůžeme, protože to by fixovalo hodnotu i v analytickém a predikčním režimu. Pomocí šablony to také není vhodné, protože šablona obecně může obsahovat cokoliv, co vyhovuje schématu. Bude to muset řešit DLL „háček“ napojený na funkci „Nová simulace / predikce / analýza“ – který ke stávající kontrole šablony přidá kontrolu na hodnotu parametru „řízení korekce výkonu“ = 0 a v případě, že není roven 0, tak je nastaven konstantně na 0 a je generována varující zpráva uživateli.

strana 126




singulární vstupní parametr „měřený průtok do oblasti“ (ten bude transformací plněn v analytickém režimu a v intervalu minulosti predikčního režimu z reálného měření průtoku)



a singulární výstupní parametr reprezentující výsledně uplatněnou korekci – označme ho „výstupní korekce“.

Při hodnotě „0“ přepínače „řízení korekce výkonu“ bude jak „výstupní korekce“ tak korekce skutečně uplatněná na objekty spotřebičů (ať již parametr průtoku či výkonu) v dané oblasti převzata z hodnoty parametru „ruční zadání korekce výkonu“. Při hodnotě „–1“ přepínače „řízení korekce výkonu“ bude výkon spotřeby objektů spotřebičů v dané oblasti nejprve zapamatován (označme tuto zapamatovanou hodnotu jako „nekorigovaný výkon“) a dále bude přepsán novou hodnotou – bude spočten z teplot a z hodnoty parametru „měřený průtok do oblasti“. Výsledná „výstupní korekce“ bude spočtena z poměru parametrů „měřený průtok do oblasti“ a „nekorigovaný výkon“. Při hodnotě N (kladné celé číslo) přepínače „řízení korekce výkonu“ bude jak „výstupní korekce“ tak korekce skutečně uplatněná na objekty spotřebičů (ať již parametr průtoku či výkonu) v dané oblasti spočtena jako průměr N hodnot X v časech (nyní – 24h), (nyní – 2 * 24h) až (nyní – N * 24h), kde X je klouzavý průměr z 2*M+1 minut z hodnot Y, kde hodnota M je definována jako konstanta destinační specifickým kódem a Y je hodnota výsledné „výstupní korekce“ v daném čase.

4.4 Inteligentní aktualizace predikce – Kontinuální prediktor Je třeba implementovat funkci „(ruční) aktualizace predikce“… V daný okamžik aplikace v predikčním režimu posune „okamžik přechodu do predikce“ na novou hodnotu času (kterou si uživatel zvolí v dialogu; přednastaven bude aktuálně poslední časový okamžik dat ve zdroji M, což bude zároveň nejvyšší povolený zadávaný čas). Aktualizace vhodně doplní stávající vstupy v intervalu od předchozího okamžiku přechodu do predikce do současného okamžiku přechodu do predikce, a upraví i vstupy v intervalu současné budoucnosti. Aplikace neprovádí30 automaticky výpočet, ale ponechá uživateli možnost dále modifikovat vstupy. Počátek i konec predikce se posune o takový čas dopředu, jaký je interval mezi předchozím okamžikem přechodu do predikce a novým okamžikem přechodu do predikce31.

30

Aplikace ani nemůže nikdy automaticky provádět výpočet, jelikož je vždy možné, že zadané vstupy jsou neplatné (NaN). 31

Alternativou by bylo posouvat pouze počátek intervalu a konec nikoli. Tím by docházelo k postupnému zkracování výpočetního intervalu. Pak by muselo být nějak řešeno podkročení nulové délky intervalu budoucnosti. Navíc by uživatel musel v tomto případě mít možnost interval ručně prodloužit, což by ale nevedlo k automatickému znovu-provedení transformace budoucnosti (zejména načtení předpovědi počasí) a bylo by

strana 127


Aktualizace predikce se ručně vyvolá z položky Aktualizovat predikci aplikační nabídky Soubor. Aktualizace nebude umožněna, pokud nový okamžik predikce je pozdější, než předchozí konec výpočetního intervalu. Pro aktualizaci predikce je důležitý parametr transformace resistency. Aktualizace predikce ponechá všechny hodnoty před předchozím okamžikem přechodu do predikce netknuté. Mezi předchozím okamžikem přechodu do predikce a novým okamžikem přechodu do predikce budou použita pravidla pro transformaci minulosti, ale s jednou odlišností: Vždy, kdy by se měla doplnit implicitní hodnota, tj. hodnota z šablony, bude hodnota z modelu před aktualizací. Aktualizace doplní hodnoty po novém okamžiku přechodu v závislosti na nastavení parametru resistency: Pokud má tento hodnotu „1“, tak ponechá hodnoty netknuté (avšak hodnoty, které je třeba doplnit vlivem posunu okamžiku konce intervalu, budou doplněny konstantně prodlouženou hodnotou v čase předchozího konce výpočetního inteervalu), ale pokud je „0“, použije metodu definovanou transformací budoucnosti. Všem vstupním parametrům, které nemají definovánu transformaci, zůstává při aktualizaci predikce hodnota nezměněna.

4.4.1 Automatická aktualizace predikce – Periodický kontinuální prediktor Aplikace půjde přepnout (pomocí zaškrtávací položky Automatická aktualizace v aplikační nabídce Soubor) do zvláštního režimu, kdy by se aktualizace predikce vyvolávala periodicky automaticky32 (a také bez dotazu na čas – vždy by byl určen jako poslední čas online dat ve zdroji M). Jednalo by se o jakýsi „online“ systém, který by navíc k běžným „online“ systémům neměl v každém okamžiku reálného času jen současné hodnoty, ale také řady obsahující předpověď do budoucna. Účel tohoto „super-online“ systému je především ulehčení práce pro uživatele průběžně sledujícího aplikaci. Naopak není vhodné tento režim používat pro automatické generování nějakých výstupů ve formě receptů, apod., protože automatické generování výstupů bez kontroly uživatelem je krajně nevhodné. (Výpočet navíc i vychází ze vstupů automaticky doplněných a upravených, zcela nezverifikovaných uživatelem.)

nutné znovu vyvolat aktualizaci predikce (či případně alespoň aktualizace předpovědi počasí). To se celkově nejeví jako vhodné řešení. Navíc není symetrické s níže popsanou aktualizací analýzy. 32

Zároveň by ale bylo nutné v tomto režimu zcela zamezit uživateli nejen měnit hodnoty vstupů, ale provádět jakoukoliv editaci v aplikaci a dokonce mu ani neumožnit posouvat či měnit velikost oken, vyvolávat jakékoliv dialogy (byť jen pro čtení).

strana 128


4.5 Aktualizace analýzy Je vhodné implementovat funkci „(ruční) aktualizace analýzy“… V daný okamžik aplikace v analytickém režimu posune jak čas počátku tak řas konce intervalu o stejný časový úsek (čas konce intervalu si uživatel zvolí v dialogu; přednastaven bude aktuálně poslední časový okamžik dat ve zdroji M, což bude zároveň nejvyšší povolený zadávaný čas). Aktualizace vhodně doplní stávající vstupy v intervalu dosud nenaplněném. Aplikace neprovádí33 automaticky výpočet, ale ponechá uživateli možnost dále modifikovat vstupy. Aktualizace analýzy se ručně vyvolá z položky Aktualizovat analýzu aplikační nabídky Soubor. Aktualizace predikce ponechá všechny hodnoty v doposud naplněném intervalu netknuté. V dosud nenaplněném intervalu budou použita pravidla pro transformaci minulosti, ale s jednou odlišností: Vždy, kdy by se měla doplnit implicitní hodnota, tj. hodnota z šablony, bude hodnota z modelu před aktualizací. Všem vstupním parametrům, které nemají definovánu transformaci minulosti, zůstává při aktualizaci predikce hodnota nezměněna.

4.5.1 Automatická aktualizace analýzy Aplikace půjde přepnout (pomocí zaškrtávací položky Automatická aktualizace v aplikační nabídce Soubor) do zvláštního režimu, kdy se aktualizace analýzy bude vyvolávat periodicky automaticky34 (a také bez dotazu na čas – vždy by byl určen jako poslední čas online dat ve zdroji M). Tímto bude simulován režim „online prohlížeče dat“: Pokud uživatel nebude potřebovat sledovat vypočtené hodnoty (např. na to dokonce z licenčních podmínek nemusí mít právo – viz příznak „Výpočet“ HW-klíče), získá tento režim poměrně rychlým sledem kroků: 1. vyvolá analytický režim a případně přenastaví délku intervalu (čímž se posune počítek intervalu, nikoli jeho konec, který zůstane implicitně nastavený na čas aktuálně posledních dat ve zdroji M), 2. pootvírá okna pro sledování průběhů řad „online“ veličin a/nebo vstupních parametrů,

33

Aplikace ani nemůže nikdy automaticky provádět výpočet, jelikož je vždy možné, že zadané vstupy jsou neplatné (NaN). 34

Zároveň je nutné v tomto režimu zcela zamezit uživateli nejen měnit hodnoty vstupů, ale provádět jakoukoliv editaci v aplikaci a dokonce mu ani neumožnit posouvat či měnit velikost oken, vyvolávat jakékoliv dialogy (byť jen pro čtení).

strana 129


3. zaškrtne položku Automatická aktualizace (čímž zároveň zafixuje rozložení oken a zabrání ruční editaci).

4.6 Sekundární databázový zdroj online veličin Sekundární zdroj dat (označme ho „M2“) může být užitečný ve dvou případech:  buď jako náhradní zdroj dat (označme ho „M2X“) vedle primárního zdroje dat M1A či M1L, tj. pokud tento nemá schopnost neomezeně nabízet historická data,  nebo jako náhrada (kopie) zdroje dat na místě, kde není zajištěn online přístup k M1H či M2X… (pak ho označme M2C) Sekundární zdroj M2X má stejný „přirozený krok“ jako primární zdroj M1A či M1L. Sekundární zdroj M2C má stejný „přirozený krok“ jako jeho „vzor“ M1H či M2X. Sekundární zdroj může nést jenom ty veličiny a ty hodnoty, jaké jsou obsaženy v primárním zdroji M1.35 Vlastní databáze M2 má poměrně jednoduchou strukturu o dvou tabulkách: tabulka indexes36 (

35

Teoreticky by bylo možné uvažovat o systému dalších vkládaných veličin a opravě hodnot existujících veličin u M2X, případně o analogické virtuální změně u M1H pomocí „overaly“ zdroje dat „MO“. (Opravy / doplňování ve zdroji dat nemá smysl dělat u M2C, protože pokud to bylo potřeba, bylo doplnění / opravy provedeny již v M2X.) „MO“ by byla forma sekundárního zdroje taková, že by obsahovala právě pouze doplněná či opravená data a při vlastním načítání by se primární zdroj M1H dat zkombinoval s MO následujícím způsobem: Pokud by měla daná online veličina (identifikovaná jednoznačným identifikátorem stejným v M1H i v MO) v daném čase (požadována by byla přesná shoda, v praxi shoda na celé sekundy) hodnotu přítomnou 

jak v M1H tak v MO, považovala by se hodnota za opravenou a načte se z MO;



jen v MO, považovala by se hodnota za doplněnou a načte se z MO;



jen v M1H, považovala by se za normální a načte se z primárního zdroje.

Pro MO by bylo třeba implementovat vše jako pro sekundární zdroj M2, s jedinou výjimkou: neběžel by nástroj MeaCopy. Nástroj MeaDown by při čtení buď rovnou kombinoval primární zdroj a „overlay“, nebo by přenášel každou z těchto databází zvlášť (pak by existoval „overaly“ i u M2X). Vlastní opravy a vkládání by bylo nejvhodnější provádět z aplikace MOPED / Prediktor, jelikož ten má již komfortní infrastrukturu pro editaci řad. Celý systém „overaly“, doplňování a oprav veličin však přesahuje zamýšlený rozsah projektu a proto nebude v rámci projektu implementován.

strana 130


id integer NOT NULL, name string NOT NULL, deadband float NOT NULL – může být NULL u všech / některých / žádných veličin ) tabulka values ( id integer NOT NULL, dt datetime NOT NULL, -- čas vždy v UTC value float -- neplatné hodnoty jsou reprezentovány hodnotou NULL ) Sloupec name tabulky indexes vyjadřuje jednak název, který bude používán při čtení z této databáze, ale také název tagu z zdroje M1 (v případě M2X) případně M2X (v případě M2C), ze kterého je daná veličina plněna nástrojem MeaCopy (v případě M2X) případně MeaUp (v případě M2C). Každá veličina ve zdroji M2 může být inkrementální či neinkrementální. Inkrementální veličina má sloupec deadband v tabulce indexes vyplněn číslem, neinkrementální hodnotou NULL. Inkrementální veličina se od neinkrementální odlišuje dvěma aspekty: 1. Při zápisu je záznam do tabulky values zapsán (rozhodující tedy není hodnota NULL či neNULL, ale existence záznamu) právě tehdy, když je časová značka přesně o půlnoci či pokud předchozí hodnota (přečtená dle pravidel následujícího bodu 2) má stejnou platnost /

36

Abychom lépe ovládali případné nové nebo naopak zrušené veličiny v databázi, mohli bychom teoreticky přidat tabulku lifetime (id integer NOT NULL, start datetime NOT NULL, stop datetime, deadband float NOT NULL) – pro každé id by byl lifetime tabulce libovolný počet záznamů, pouze by se nesměly křížit start a stop mezi záznamy a když by byl „poslední“ stop nevyplněný, jednalo by se o aktivní online veličinu (pokud by byly všechny stop vyplněné, byla by online veličina považována za deaktivovanou). Protože však použitelnost měřených veličin v REGIOS je dán existencí či neexistencí příslušné transformace v modelu a je tudíž primárně nutné v případě odstranění či přidání veličiny ve zdroji dat přidat či odstranit odkaz na příslušný tag v definicích transformací, je možné zároveň s tímto přidat (to se předpokládá jako automatický důsledek změny konfigurace MeaCopy) nebo ubrat (manuálně z obou (!) tabulek indexes a values) veličinu ze sekundárního zdroje, protože: 1.

Odkaz na neexistující měřenou veličinu by byl stejně nefunkční.

2.

Existence měřené veličiny v sekundárním zdroji je bez odkazu z transformací v aktuální verzi aplikace Prediktor funkčně zbytečná.

Z uvedených důvodů nebude tabulka lifetime implementovaná.

strana 131


neplatnost a zároveň (v případě platnosti) se hodnota od této předchozí liší o více než deadband. 2. Při čtení se čte záznam z daného časového okamžiku, ale pokud zde záznam zcela chybí (tj. jiný případ než nalezení NULL hodnoty v existujícím záznamu), čte se nejbližší předchozí (dle časové značky) existující záznam (až do nejbližší předchozí půlnoci, kde, pokud záznam také neexistuje, tak se veličina považuje za deaktivovanou37). Při čtení se tedy může vždy používat komplexnější způsob předpokládající inkrementální veličinu, který bude zároveň fungovat i na neinkrementální veličiny. To je výhodné zejména s ohledem na fakt, že v aplikaci Prediktor / MOPED (a také při čtení v aplikaci MeaCopy) bude šablona obecného SQL dotazu uložena v konfiguračním souboru. Jako sekundární zdroj nebude sloužit soubor SQLite, ale některý z client-server SŘBD, tako např. open-source PostgreSQL, Firebird či komerční MS SQL Server. Časové údaje v M2 budou vždy v UTC!

4.6.1 MeaCopy – Periodické plnění sekundárního zdroje dat z primárního zdroje dat Nástroj MeaCopy bude potřebný právě tehdy, pokud používáme kombinaci M2X a M1A nebo kombinaci M2X a M1L. Tyto dvě kombinace se liší způsobem čtení ze zdroje M1.38 MeaCopy musí znát „přirozený krok“ primárního zdroje dat M1 (bude uveden v konfiguračním souboru nástroje MeaCopy – spolu s údajem, při jakém zpoždění oproti tomuto pravidelnému kroku se má činnost provádět) a stejným krokem v reálném čase plní sekundární zdroj M2X. MeaCopy respektuje případnou inkrementální povahu veličin zapisovaných do M2X. V případě M1L nástroj vyžaduje, aby primární zdroj dat poskytoval časové údaje vždy v UTC! Mimo uvedené údaje z konfiguračního souboru: 

connect_string – připojovací řetězec,

37

A dle konkrétního případu se buď vrací NULL nebo se dle charakteru čtoucí aplikace může vrátit prázdný záznam. 38

Lišit se budou pouze v šabloně dotazu v konfiguračním souboru, kdy u M1A (na rozdíl od M1L) nebude součástí parametru dotazu časový údaj. Takový případ musí nástroj MeaCopy ošetřit. To je rozdíl oproti aplikaci Prediktor / MOPED, která může vždy existenci parametru %time% šablony dotazu bezpečně předpokládat. Na druhou stranu (opět na rozdíl od aplikace Prediktor / MOPED) může MeaCopy bezpečně předpokládat, že zdroj dat je neinkrementální. Teoreticky: Pokud by někdy bylo potřeba číst i ze zdroje M2, tj. respektovat při čtení inkrementalitu (některých) veličin, tak se tento rozdíl opět projeví pouze v konfiguračním souboru, kde bude uvedena šablona čtecího SQL dotazu (stejná jako v případě aplikace Prediktor / MOPED).

strana 132




query – čtecí šablona SQL dotazu (obsahující SQL dotaz využívající formální parametry %id% a %time% a vracející jedinou položku value [hodnota veličiny, kde případná neplatnost je indikovaná hodnotou NULL]),



step_length – délka kroku (v sekundách) a



step_shift – zpoždění (v sekundách) za každým krokem

nepotřebuje MeaCopy žádné další údaje, protože vše ostatní je již součástí obsahu cílové databáze M2X – a to: 

seznam čtených veličin (jméno tagu M1 a jméno veličiny pro čtení z M2X jsou shodná) a



hodnota deadband (s případným NULL značícím neinkrementální veličinu)

Důležité je, že při inkrementálním zápisu se testování na deadband (viz předchozí podkapitola) provádí z rozdílu aktuální hodnoty a předchozí zapsané (do M2X), nikoli předchozí přečtené (z M1).

4.6.2 Hromadný přesun dat mezi kopiemi zdrojů online dat Ať již bude či nebude implementován sekundární zdroj dat vedle primárního (tj. bude implementován M2X), bude potřeba vytvořit nástroje pro hromadný offline přesun online veličin. Je potřeba vyvinout nástroj pro stažení dat z databáze do souboru MeaDown, nástroj pro natažení dat z tohoto souboru do databáze MeaUp a též specifikovat formát tohoto souboru. Vzhledem k případné inkrementalitě bude transfer dat omezen na možnost přesouvat pouze celé dny. 4.6.2.1

Formát výměnných souborů

Formát souboru bude nezávislý na použité databázi a také nezávislý na tom, zda veličiny jsou inkrementální či nikoli. [Toho bude dosaženo tím, že bude omezen na práci s celými dny, tj. od půlnoci (včetně) do půlnoci (mimo vlastní půlnoc).] Bude založen na textové serializaci datových typů .NET Framework: 

DateTime – pro časové značky (s uživatelským formátovacím řetězcem "yyyy'-'MM''dd'T'HH':'mm':'ss'Z'" – bude použit vždy čas v UTC),



double – pro hodnoty a údaje deadband (se standardním formátovacím řetězcem „R“ a kulturní specifikací CultureInfo.InvariantCulture; případné neplatné hodnoty [v kódu reprezentované double.NaN, v databázi hodnotou NULL] budou reprezentovány řetězcem „NaN“ [ASCII / UTF-8]),



string – přímo řetězec v UTF,



případně int – pro index-identifikátory veličin strana 133


Soubor bude vždy komprimovaný ve standardizovaném formátu XZ. Soubor bude obsahovat 2 tabulky, formálně popsatelné pomocí SQL konvence jako: m_indexes ( id int NOT NULL PRIMARY KEY, name varchar NOT NULL UNIQUE] deadband double NULL ); a m_values ( dt datetime NOT NULL, id int NOT NULL, value double NULL] ) PRIMARY KEY (dt, id); 4.6.2.2

Nástroj MeaDown

Pokud bude implementován M2X, bude nástroj číst z něj, v opačném případě bude číst z primárního zdroje dat M1H. MeaDown načte z primárního (M1H) či sekundárního (M2X) zdroje dat veškeré hodnoty (včetně příznaků platnosti reprezentovaných NULL hodnotou) a jejich časové určení a uloží je do souboru. Nástroj MerDown vyžaduje, aby zdroj dat poskytoval časové údaje vždy v UTC! To je v případě M2X zajištěno. V případě M1H je to nutně vyžadováno (stejně jako to vyžaduje aplikace Premos / MOPED)! Nástroj bude používat jediný dotaz SELECT, který vrátí celou tabulku m_values setříděnou nejprve dle dt a následně dle id. V případě přenosu sekundárního zdroje dat může být zdrojovou databází M2C místo M2X. Platí pro ni totéž co pro zde popsanou M2X. MeaDown použije údaje vyplněné ve svém konfiguračním souboru: 

identifikátor databázového poskytovatele,



připojovací řetězec k zdrojové databázi,



šablonu dotazu (s proměnnými %timestart%, %timeend%, %tagnamecommalist%),



seznam identifikátorů veličin (pouze v případě M1H!) strana 134


V případě čtení z M2 si nástroj přečte seznam veličin přímo z tabulky indexes zdrojové databáze. Nástroj nepotřebuje znát „přirozený“ krok zdroje dat. MeaDown se interaktivně dotáže uživatele na: 

datum počátku exportovaného období (nikoli čas, jelikož umí exportovat jen celé dny)



datum konce exportovaného období (nikoli čas, jelikož umí exportovat jen celé dny)

Dotaz je vytvořen dosazením následujících parametrů do šablony dotazu: 

počáteční datum (bez času) do %timestart%



koncové datum (bez času) do %timeend%



seznam čárkou oddělených názvů tagů do %tagnamecommalist%.

Tyto parametry nebudou dosazeny pomocí SQL bindingu parametrů, ale přímým dosažením do řetězce – kvůli %tagnamecommalist%, který není SQL typovým parametrem. To není nevýhodou z hlediska SQL přípravy dotazu, jelikož je dotaz zpracován stejně pouze jedenkrát za běh nástroje. 4.6.2.3

Nástroj MeaUp

MeaUp načte data ze souboru uloženého nástrojem MeaDown a zapíše je do jiného sekundárního zdroje dat (M2C). Nástroj obecně bude podporovat (pomalé) SQL INSERT příkazy pro jednotlivé záznamy. Pro specifické SŘBD může však být implementována rychlejší metoda, např. pro MS SQL pomocí SqlBulkCopy: https://msdn.microsoft.com/en-us/library/vstudio/system.data.sqlclient.sqlbulkcopy%28v=vs.100% 29.aspx MeaUp použije údaje vyplněné ve svém konfiguračním souboru: 







šablonu vkládacího příkazu (ta však bude v praxi pro všechny cíle M2 totožná),

Nástroj nepotřebuje znát „přirozený“ krok zdroje dat.

strana 135


Výsledkem kopie databáze pomocí MeaDown a následně MeaUp bude vždy databáze, kde všechny veličiny mají stejnou inkrementalitu / neinkrementalitu jako v původní databázi.39 Nástroj nejprve provede 1. kontrolu: Zda pro dny časů, které jsou obsaženy v souboru, neexistuje v cílové databázi ani jeden záznam. Pokud by existoval, nástroj to srozumitelně oznámí uživateli a zápis dat neprovede. Následně provede 2. kontrolu: Zda není konflikt mezi přiřazením indexů a jmen veličin v souboru a v cílové databázi. Tato kontrola může mít jeden z následujících výsledků: (1)

Přiřazení jsou v souboru a v databázi shodná.

(2)

V cílové databázi jsou nějaká přiřazení navíc.

(3)

V souboru jsou nějaká přiřazení navíc.

(2)+(3) V databázi i v souboru jsou nějaká přiřazení navíc, ale (indexy nových veličin v souboru jsou disjunktní s novými veličinami v cílové databázi) a zároveň (názvy nových veličin v souboru jsou disjunktní s novými veličinami v cílové databázi). (4)

Existuje veličina, která má v souboru a v cílové databázi shodné jméno, ale odlišný index.

(5)

Existuje veličina, která má v souboru a v cílové databázi shodný index, ale odlišné jméno.

Libovolné kombinace (2), (3), (4), (5)… Kombinace případů se řeší rozpadem na jednotlivé případy řešené v tomto pořadí (každý bod bude proveden pro všechny případy, než se postoupí k dalšímu bodu): (5)

Příslušný Index je v cílové databázi (jak v tabulce indexes, tak v tabulce values) nahrazen novým indexem – nejnižším možným indexem, dosud nepoužitým ani v souboru ani v cílové databázi.

(4)

Index je v cílové databázi (jak v tabulce indexes, tak v tabulce values) nahrazen odpovídajícím indexem ze souboru (párování dle názvu veličiny).

(3)

Chybějící záznamy v tabulce indexes se doplní dle souboru.

39

To se týká hodnot, tj. jejich „děravosti“. Na údajích deadband v cílové databázi v podstatě nezáleží, protože ty jsou určeny jen pro zapisující MeaCopy. Zdá se tedy, že mají v cílové databázi pouze informační hodnotu. To však nemusí být pravda, pokud MeaDown + MeaUp slouží k migraci historických měření na nové místo, na kterém pak bude provozován nově i MeaCopy.

strana 136


Případy (3) budou uživateli hlášeny „oznámením“ o „aktualizaci indexů v cílové databázi“. Případy (2) budou hlášeny jako „upozornění“, že „indexy cílové databáze obsahují oproti souboru záznamy navíc“. Případy (4) budou hlášeny jako „upozornění“, o „různých indexech pro veličiny s názvy …, …, … – budou sloučeny“. Případy (5) budou hlášeny jako „upozornění“, o „stejném indexu různých veličin s názvy …x…, …x…x…, …x… – budou relokovány“. Následně se provede kopírování dat ze souboru do tabulky values.

4.7 Posílání výstupních teplot do technologie Pokud bude spolupracující řídicí systém podporovat pro účely výstupních teplot „recepty“, tj. uložené časové řady „do budoucna“, bude REGIOS mít schopnost (danou háčky v hlavní destinační DLL) jednorázově poslat určité parametry (časové řady) do vzdálené databázové tabulky (konfigurovatelné ve zvláštním destinačně-specifickém konfiguračním souboru). I pokud spolupracující řídicí systém nepodporuje „recepty“, lze takto řady zapsat do nějaké vzdálené tabulky pro zpracování nástrojem GvtScan – viz následující podkapitola 4.7.1. V tomto případě bude neplatná hodnota (v Prediktoru / MOPEDu reprezentovaná hodnotou double.NaN) do databáze ukládaná jako NULL. Délka kroku uložených receptů bude odpovídat délce kroku výpočetního intervalu. Předpokládá se, že ne všichni uživatelé budou mít oprávnění tyto řady do řídicího systému zapisovat. Z hlediska bezpečnosti je ale vhodné tyto oprávnění implementovat nikoli na úrovni aplikace REGIOS, ale na úrovni cílové tabulky pomocí nastavení oprávnění databáze, ideálně pomocí rozlišení přihlášeného uživatele v operačním systému. Vzdálená tabulka pro ukládání „receptů“ bude každopádně mít všechny časové údaje v UTC!

4.7.1 GvtScan – Zpřístupnění vypočtených hodnot v reálném čase V případě, že spolupracující řídicí systém nepodporuje „recepty“, ale REGIOS je do vzdálené tabulky ukládá, bude z této tabulky nástroj GvtScan pravidelně číst hodnoty receptů v jednotlivých krocích a publikovat je jiným způsobem. Zatím40 bude podporován způsob zápisu do „live“ SQL tabulky, která neuchovává časové značky. Jednotlivé hodnoty budou ukládány do různých sloupců stejné tabulky. Platnost bude vyjádřena zápisem hodnoty NULL. Předpokládá se, že tabulka bude mít pouze 1 řádek. Před každým zápisem bude provedeno kompletní vymazání tabulky SQL příkazem DELETE FROM . Vložení

40

Lze si představit jiné způsoby zápisu pomocí SQL, nebo zcela jiné metody, jako např. OPC, UDP, http (REST), atd.

strana 137


řádku bude provedeno vždy příkazem INSERT. Smazání a vložení řádku proběhne v jediné transakci. Hlídání vynechání zápisů bude na zodpovědnosti cílové databáze, která může použít mechanismu triggerů41. Konfigurační soubor nástroje GvtScan bude obsahovat: 







název cílové databázové tabulky,



seznam dvojic [identifikátor veličiny ve čtené tabulce receptů; název sloupce pro hodnotu v cílové tabulce],



velikost kroku (měl by být shodný s krokem uložených receptů, což je zvolená délka kroku výpočetního intervalu),



zpoždění (v sekundách) provádění zápisu za periodou celého kroku.

41

Alternativně lze zavést 1 sloupec navíc s časovou značkou, pak může databáze zjišťovat vynechané zápisy až v okamžiku potřeby právě podle této časové značky.

strana 138

Příloha k průběžné zprávě za rok 2015

Recommend Documents