Zápisnica zo stretnutia s vedúcim 19.11.2018, tím 06

Čas stretnutia: 9:00-12:20
Miesto stretnutia: FIIT STU
Téma stretnutia: Vylepšenia prototypu a možnosti simulácie
Zápisnicu vypracoval: Bc. František Ďurana

Prítomní:

Bc. Martin Činčurák
Bc. Michal Ostrodický
Bc. František Ďurana
Bc. Dávid Pavelka
Bc. Peter Pavlík
Bc. Richard Mocák
Bc. Matej Procházka

Neprítomní:

Aplikácia

postupne aktualizovať demo čo máme zatiaľ vytvorené a stavať na ňom
model a evidencia prvkov nepotrebuje GUI
json - názov, autor, čas vytvorenia simulácie a pod. - môže to byť súčasť jsonu alebo samostatne
ideálne riešenie je, aby všetci používatelia mohli vidieť všetky modely, neobmedzovať používateľovi prezerať len svoje modely
nepotrebujem tam jednoducho vôbec riešiť používateľov
ceny netreba najbližšie dva týždne
vytvoriť GUI rozhranie pre zadanie cenníka v hodinách a dňoch pre týždeň (sviatky pre daný rok budú 8. typ dňa, vytvoriť si ich zoznam v aktuálnom roku)
stačí v nastaveniach pridať možnosť nastaviť cenník a otvorí sa formulár pre cenník, ktorý sa bude používať globálne
výsledok simulácie by sa mal uložiť do databázy a potom by sa mal výsledok simulácie načítať z databázy
obmedzenie na maximálny výkon pre batériu, aby sa nevyčerpala energia hneď
pri zobrazení konkrétneho prvku bude potrebné ísť na nižšiu úroveň
riešiť prechody v čase (zimný čas na letný čas a podobne)
simulácie by mali byť minimálne tabuľkovo oddelené
výkonové charakteristiky sa nedajú vždy agregovať
časový rad je dostačujúce uložiť ako pole
transformátor dať do modelu bez toho aby sa dal zmazať, budem na ňom robiť sumár
aj transformátor bude v budúcnosti musieť mať parametre, zatiaľ obmedziť len na jeden transformátor pre model
dať transformátor už na začiatku pri vytvorení modelu a nechať ho tam aj po jeho vyčistení, nesmie mať druhú inštanciu
víkendy viem určiť zo systému, ale sviatok je viazaný na daný systém
varovanie, že prvok nie je nikde zobrazený

Simulácia:

pri batérií sledovať či je úplne nabitá alebo vybitá (dať obmedzenie vybitia na 10%, lebo úplne vybitie nie je vhodné)
ak chcem riešiť simuláciu aj na spodných úrovniach, treba riešiť aj konkrétne napojenie pre daný prvok s ostatnými prvkami v modeli
keď sú domy spojené, elektrina z batérie odíde, ak tam nie je žiaden obmedzovač
batéria môže poskytovať pomerovo podľa toho kto koľko potrebuje, aby sa v prípade veľkého odberu dostalo všetkých bez toho, že by niekoho zvýhodňovala
nastaviť podľa dňa a hodiny krivku a potom zobraziť výsledok v eurách
každá inštancia prvku môže mať iný cenník, prvok sa bude naň odkazovať
pracujeme s tým, že simulačný nástroj nemá vlastné GUI
vytvoriť simulačné jadro nezávislé tak, aby sa dalo v prípade potreby použiť externé jadro
simulácia je asynchrónna požiadavka, príde len výsledok - napríklad nejaké id výsledku simulácie
pri archivácií simulácie sa tá môže napríklad presunúť zo simulačného jadra k nám do databázy
jednou z možností je po simulácií len zmeniť vlastníka napríklad z engine na používateľa -> premapovanie
inicializačné podmienky pre simuláciu, napríklad na koľko je na začiatku nabitá batéria (začíname z 0)
možnosť prerušiť simuláciu (v budúcnosti)
jednou z možností je určiť aj maximálnu kapacitu RAM, ak budú obmedzenia
dĺžka koľko časovo trvala simulácia a veľkosť projektu (veľkostné obmedzenie) zobraziť
zatiaľ stačí len sumárne spočítať a potom to prebehnúť batériou s kontrolou či je nabitá

Alarm:

domácnosť má nastavenú určitú maximálnu kapacitu, ak ju prekročí, čaká ju pokuta - toto môže byť jedným z výpisov v logoch simulácie
optimalizácia alarmu pre jeho začiatok a koniec, nie ho len kontinuálne vypisovať (môže to byť samostatný komponent)
komponent pre zobrazovanie a zachytávanie logov, samotná simulácia to nemusí vedieť
alarm pre všetky/vybrané inštancie
pridať možnosť či chcem sledovať určitý parameter a podľa toho zobrazovať alebo nezobrazovať alarmy
mohla by byť notifikačná vrstva pre jednotlivé typy alarmov - hudba budúcnosti