PRÍSTUP K PROJEKTU
Vzor pre manažérsky výstup I-03
podľa vyhlášky MIRRI č. 401/2023 Z. z.

1.História dokumentu

2.Účel dokumentu

Popisuje riešenie pre projekt s názvom Zavádzanie IoT SMART riešení v meste Prešov

Dokument Prístup k projektu popisuje riešenie projektu v oblastiach:

1. Požiadaviek na architektúru riešenia – biznis vrstva, aplikačná vrstva, technologická vrstva, ...
2. Kapacitných požiadaviek na HW, SW a licencie
3. Požiadaviek na bezpečnosť riešenia
4. Požiadaviek na testovanie a akceptačné kritéria
5. Požiadaviek na prevádzku, výkonnosť, dostupnosť a zálohovanie
6. Požiadaviek na integrácie, rozhrania a spoločné komponenty
7. Požiadaviek na dokumentáciu a školenia.

Všetky požiadavky uvedené v Prístupe k projektu v príslušných kapitolách, sú v súlade s funkčnými, nefunkčnými a technickými požiadavkami uvedenými v Katalógu požiadaviek (  - I-02 BC/CBA, karta: Katalóg požiadaviek).

2.1Použité skratky a pojmy

2.2Konvencie pre typy požiadaviek (príklady)

V diagramoch tohto dokumentu sa používa konvencia Archimate čo sa týka diagramov biznisovej, aplikačnej a technickej architektúry. 

Architektúrne požiadavky používajú konvenciu:

A_AB_Oxx

• A – architektúrna požiadavka
• AB – označenie systému  (ak existuje členenie; môže byť vypustené)
• O – označenie požiadavky
• xx – číslo požiadavky

Infraštruktúrne požiadavky používajú konvenciu:

Napr.

IP_nn_ORxx

• IP – infraštruktúrna požiadavka
• nn – identifikácia  (ak existuje členenie; môže byť vypustené)
• O – označenie požiadavky
• xx – číslo požiadavky

3.Popis navrhovaného riešenia

Základným cieľom projektu je implementovať (SMART) energetický monitoring budov. Vzhľadom na značný rozsah zapojených subjektov a druh dát, architektúra celého technického riešenia by mala akcentovať potrebu automatického a efektívneho zberu dát, ich efektívnej distribúcie používateľom a práce s Big dátami.

Energetický manažment budov

Jadrom siete a riešení pre využitie internetu vecí IoT (Internet of Things) a zber Big data je technológia a sieť LoRaWAN. LoRaWAN (Long Range WAN) je rodina sieťových protokolov fyzickej (PHY) a linkovej vrstvy (MAC) OSI modelu s vlastnosťami pre väčšie priestorové pokrytie a malú energetickú náročnosť.

Sieť LoRaWAN spĺňa kľúčové požiadavky internetu vecí (IoT) ako je bezpečná obojsmerná komunikácia, nízka spotreba energie, schopnosť mobility a lokalizačné možnosti, uspôsobené šírenie signálu v budovách, robustnosť prenosu a odolnosť voči rušeniu a kompatibilitu medzi výrobcami IoT zariadení.

Požiadavky na použité koncové zariadenia (IoT):

Meranie spotreby energií:

• Meranie spotreby elektrickej energie na vstupe do objektu
• Meranie spotreby verejnej vody na vstupe do objektu
• Meranie spotreby tepla z interného zdroja tepla (priamo meračmi)
• Meranie spotreby tepla z externého zdroja tepla (nepriamo dodávateľom CZT)

Meranie parametrov vonkajšieho prostredia:

• Meranie teploty vzduchu v rozsahu -20 °C až +55 °C s presnosťou ± 0,2 K
• Meranie relatívnej vlhkosti vzduchu v rozsahu 0 % až 100 % s presnosťou ± 2 %

Meranie parametrov vnútorného priestoru:

• Meranie teploty v rozsahu -20 °C až +55 °C s presnosťou ± 0,2 K
• Meranie relatívnej vlhkosti v rozsahu 1 – 99 % s presnosťou ± 2 %RH
• Meranie úrovne CO₂ v rozsahu 0 – 5000 ppm s presnosťou ± 100 ppm

Implementácia aplikačného softvéru s cieľom:

• Energetický manažment mestských objektov;
• Automatizácia reportingu energií a sledovanie histórií spotreby;

Zoznam požadovaných datasetov poskytovaných zo systému (ENM)

4.Architektúra riešenia projektu

4.1Biznis vrstva

Cieľom projektu je podpora budovania inteligentných miest a regiónov na základe inteligentných systémov riadenia, monitorovania, prediktívnej údržby a prevencie – SMART energetický manažment budov.

Sprievodným javom je automatizácia biznis procesov týkajúcich sa energetiky, zvýšenie produktivity mestských zamestnancov, spresnenie energetických dát a eliminácia administratívnych chýb.

Platforma bude tiež poskytovať zdieľanie vybraných informácii pre občanov mesta. Spolu s nasadením IoT zariadení sa docieli zlepšenie celkovej dostupnosti dát vo verejnej správe s dôrazom na otvorené údaje, pre ďalšie spracovanie v oblasti energetického manažmentu na národnej úrovni a úrovni regiónov.

Aktuálny stav energetického manažmentu:

• Nie je zavedený diaľkový odpočet spotreby energií
• Odpočty energií sú realizované manuálne
• Spracovanie odpočtov energií je manuálne
• Nie je vybudovaná technická infraštruktúra pre obsluhu IoT zariadení
• V existujúcich IS (mesto Prešov) nie je modul pre energetický manažment
• Energetický manažment mestských budov sa nevykonáva systematicky
• Chýba koncepčný prístup k energetickej optimalizácii
• Energetický manažment jestvuje v manuálnej forme
• Energetické informácie sa redistribuujú manuálne
• Chýba IS pre energetické sledovanie a optimalizáciu

Aktuálne požiadavky:

• Zavedenie plne automatického diaľkového odpočtu energií (redukcia ľudskej sily)
• Realizácia zberu dát na báze LPWAN siete a potenciálne využitie aj pre iné mestské biznis aktivity
• Vybudovanie IS pre energetický manažment ako nadstavbu nad diaľkovým odpočtom s potenciálom budúceho doplnenia o SW moduly predikcie spotreby a optimalizácie nákladov na energie
• Automatizácia biznis procesov mesta a zníženie celkovej administratívnej záťaže na správu mesta
• Odbúranie manuálnych a opakovaných ľudských činností
• Potenciálne rozšírenie o funkcionalitu meteorologickej predpovede
• Príprava rozhrania pre zdieľanie dát do integračnej platformy mesta

Identifikácia vlastníkov procesov:

Výstupom projektu je zjednodušenie a sprehľadnenie administratívnej agendy pre vlastníka procesov (mesto) a poskytovanie údajov z jednotlivých subsystémov rozhodujúcim (interným a externým) aktérom.

Vlastníkom procesov sú :

• Mesto Prešov

Obr. 1_Biznis architektúra energetického manažmentu (ENM)

4.1.1Prehľad koncových služieb – budúci stav:

Obrázok 2 Model biznis architektúry (aktéri-koncoví používatelia, koncové služby, procesy) – príklad

4.1.2Jazyková podpora a lokalizácia

 Všetky obrazovky vizualizačného rozhrania človek-stroj (HMI), údajové reporty, pozičné značenia prvkov v rámci projektovej dokumentácie, technické správy a používateľské manuály sa vyhotovia v slovenskom jazyku.

4.2Aplikačná vrstva

Informačný systém Energetického managementu bude zložený z viacerých modulov:

• IoT – zber dát z IoT zariadení z LPWAN siete
• Energetický management – na základe dát zo senzorov
• Elektronická dokumentácia – management a úložisko pre stavebnú dokumentáciu budov
• Jednotlivé moduly sú vzájomné prepojené a údaje čerpajú zo spoločnej DBMS (SQL databázy).
• Údaje uložené v IS Energetického managementu budú dostupné prostredníctvom používateľského rozhrania IS alebo prostredníctvom štandardov otvorených dát (tzv. Open API).

IS Platforma smart City

• Integrácia dát cez open API vybraných IS mesta
• Zjednotenie užívateľského rozhrania a vizualizácie dát zo systémov mesta
• Vytvorenie rozhraní a funkčných modulov pre energetický manažment
• Vytvorenie rozhrania pre zverejňovanie údajov pre občanov a podnikateľov

Obr. 2_Model aplikačnej architektúry – Platforma mesta

4.2.1Rozsah informačných systémov – AS IS

Uveďte dotknuté ISVS a ich moduly AS IS:

4.2.2Rozsah informačných systémov – TO BE

Uveďte informácie o dotknutých ISVS z pohľadu ich ďalšej prevádzky po realizácii projektu – TO BE stav:

4.2.3Využívanie nadrezortných a spoločných ISVS – AS IS

Nerelevantné. Nie sú.

4.2.4Prehľad plánovaných integrácií ISVS na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 e-Governmente – TO BE

Nerelevantné. Nie sú.

4.2.5Prehľad plánovaného využívania iných ISVS (integrácie) – TO BE

Nerelevantné. Nie sú..

4.2.6Aplikačné služby pre realizáciu koncových služieb – TO BE

Nerelevantné. Nie sú.

4.2.7Aplikačné služby na integráciu – TO BE

4.2.8Poskytovanie údajov z ISVS do IS CSRÚ – TO BE

4.2.9Konzumovanie údajov z IS CSRU – TO BE

4.3Dátová vrstva

Každá organizácia by mala mať zavedený systematický manažment údajov (vrátane nastavenie príslušných procesov a metodík pre správu celého životného cyklu údajov) a byť schopná evidovať a spravovať údaje v strojovo-spracovateľnej podobe. V kapitolách nižšie je potrebné popísať AS IS a následne TO BE stav organizácie z pohľadu údajov, ich štruktúry a následného výkonu príslušnej agendy vo vzťahu k projektu.

4.3.1Údaje v správe organizácie

Popis dát, ktoré mesto spracováva :

• Agenda správy dokumentov a energií. Nutnosťou manuálneho zadávania údajov bez automatizovaných algoritmov pre podporu energetického manažmentu. Mesto plánuje rozšíriť funkcionality SW od ďalšie moduly riadenia a správy energetického manažmentu a zaviesť automatizovaný zber údajov z IoT senzorov.
• Dáta nie sú exportované do vyššej úrovne riadenia.
• Energetický manažment je vykonávaný konvenčne z dostupných údajov o spotrebe energie, zabehnutých štandardov a manuálnych procesov pri spracovaní agendy správy mestského majetku.
• Vykonáva manuálne a fyzické spracovanie údajov o energiách, rozpočítavanie energií a pod.
• Plánuje zaviesť integračnú platformu mesta v rámci, ktorej budú integrovaný subsystémy do jedného miesta.

4.3.2Dátový rozsah projektu - Prehľad objektov evidencie - TO BE

Obr. 3_Doménový model projektu.

Zoznam dátových objektov v doménovom modeli:

1. Merače                                         Inštalované merače energií v projekte
2. Agregátory                   Inštalované vysielače v prenosovej sieti LoRa
3. Senzory                                        Inštalované snímače parametrov vnútorného komfortu
4. Objekty                                        Zoznam sledovaných objektov (mestských objektov)
5. Používatelia                                Zoznam koncových používateľov CEM
6. Energetické Spotreby             Hodnoty spotrieb energetických médií na vstupe do objektu
7. Komfortné parametre            Hodnoty ukazovateľov vnútorného prostredia
8. Inštitúcie                                   Zoznam mestských inštitúcii (inštitúcii v projekte)
9. Reporty                                       Reporty energetických spotrieb a komfortných parametrov

4.3.3Referenčné údaje

Údaje vysielané snímačmi sú v požadovanom formáte resp. upravené do požadovaného formátu a kvality v centrále systému CEM. Projekt neimplementuje osobitné procesy na čistenie údajov.

4.3.3.1Objekty evidencie z pohľadu procesu ich vyhlásenia za referenčné

Nerelevantné.

4.3.3.2Identifikácia údajov pre konzumovanie alebo poskytovanie údajov do/z CSRU

4.3.4Kvalita a čistenie údajov

Údaje vysielané snímačmi sú v požadovanom formáte resp. upravené do požadovaného formátu a kvality v centrále systému CEM. Projekt neimplementuje osobitné procesy na čistenie údajov.

4.3.4.1Zhodnotenie objektov evidencie z pohľadu dátovej kvality

4.3.4.2Roly a predbežné personálne zabezpečenie pri riadení dátovej kvality

Tab.č.3_Riadenie dátovej kvality

4.3.5Otvorené údaje

Požadovaná kvalita:

• Automatizované publikovanie otvorených údajov v kvalite 3 (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na (data.gov.sk). Formát údajov CSV, XML
• Automatizované publikovanie otvorených údajov v kvalite 4 (Všetky datasety je potrebné registrovať v centrálnom katalógu otvorených údajov na (data.gov.sk). Formát údajov RDF, OWL, TriX, JSON

Tab.4_ Zoznam otvorených údajov – navrhovaný stav

4.3.6Analytické údaje

Projekt neuvažuje s používaním modulov na sprístupnenie údajov pre analytické jednotky a špeciálne organizačné útvary verejnej správy (za účelom podpory verejnej správy alebo vo verejnom záujme).

4.3.7Moje údaje

V projekte nebudú spracovávané údaje, ktoré majú charakter „mojich údajov“. Napr. údaje o konaní, ktoré sa týka fyzickej alebo právnickej osoby. Nebudú spracovávané množiny údajov (vrát. osobných) viažúce sa k fyzickej či právnickej osobe ako predmety evidencie povinnému subjektu (konania, žaloby, rozhodnutia, žiadosti, sťažnosti, vyjadrenia, stanoviská o ohlásení alebo iné dokumenty, ktoré vydáva povinný subjekt).

4.3.8Prehľad jednotlivých kategórií údajov

Tab.č.5_Kategorizácia údajov z podľa účelu ich využitia – navrhovaný stav

4.4Technologická vrstva

4.4.1Prehľad technologického stavu - AS IS

Navrhovaný systém ENM bude mať hierarchickú štruktúru. Najvyšší stupeň prestavuje Centrála (CEM) vo forme softvérovej technologickej platformy uspôsobenej k zberu údajov o spotrebách. Ďalej systém uvažuje s nasledovným:

• IoT zariadenia, Smartmetre, apod. budú odosielať prostredníctvom vybudovanej LPWAN siete údaje prostredníctvom jednotlivých brán (Gateways) na jednotlivé Network Servery, ktoré budú údaje prijímať a odosielať na ďalšie spracovanie do IS Energetický Management, modul IoT. Spracované údaje sú následne ukladané v DBMS systéme (databázovom serveri).
• IS Energetického managementu bude využívať Aplikačný HW (formou fyzického HW alebo cloudového prostredia). V tomto prostredí bude prevádzkovaný databázový SQL server (DBMS), aplikačný server, identity server, apod.

4.4.2Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

Softvérová technologická platforma vo forme centrály CEM bude dizajnovaná na zaťaženie súčasným pripojením niekoľkých desiatok používateľov.

Tabuľka č.6_Prehľad výkonových požiadaviek – navrhovaný stav

4.4.3Návrh riešenia technologickej architektúry

4.4.4Využívanie služieb z katalógu služieb vládneho cloudu

Obr. 4_Model aplikačno-technologickej architektúry systému

Smart monitoring s podporou IoT ISVS_14573 - Časť manažment s IoT bude mať nasledovné funkcionality:

• Evidencia objektov
• Technická dokumentácia
• Evidencia odberných miest
• Vyhodnocovanie spotrieb energií a automatizovaný reporting
• OpenAPI - umožní prístup k vybraným informáciám formou API
• Bezpečnosť a oprávnenia používateľov

V rámci projektu bude zabezpečené vytvorenie lokálneho katalógu otvorených dát (LKOD) podľa štandardu DCAT-AP-SK2.0, alebo SPARQL Endpoint, a zabezpečí sa sprístupnenie  datasetov na data.slovensko.sk.

Zároveň projekt bude pripravený na uverejňovania údajov v systéme verejných vládných platform.

Technologická časť CEM

Softvérová centrála bude implementovaná (prednostne) na cloud platforme, príp. lokálne na vlastnom hardvéri. Pri použití cloudového riešenia sa jedná o transparentné poskytnutie počítačovej infraštruktúry treťou stranou umiestnenej v dátovom centre s robustnou internetovou konektivitou a škálovateľným výpočtovým výkonom, dohodnutou úrovňou dostupnosti a zabezpečenia voči kybernetickým útokom.

Prenosovú vrstvu bude tvoriť vlastná mestská sieť typu LoRaWAN (Long Range WAN) v kombinácii s prenosom cez verejný internet. Sieť sa vybuduje špecificky pre potreby projektu, avšak bude škálovateľná a výhľadovo použiteľná aj pre ďalšie zariadenia IoT a zber technologických dát na území mesta.

Prenosové siete typu LoRa (Long Range) alebo LPWAN (Low Power Wide Area Network) poskytujú bezdrôtovú komunikáciu IoT zariadení v miestnom, regionálnom či národnom merítku. Ide v pravom zmysle slova o nízko-príkonové optimalizované pre úsporné dátové prenosy (IoT) od autonómne pracujúcich zariadení napájaných batériami (bez nutnosti externého zdroja energie). Výhodou je schopnosť prenosu údajov na veľké vzdialenosti (rádovo kilometre až desiatky kilometrov) a nízke obstarávacie a inštalačné náklady.

Popis softvéru CEM:

Cieľom nasadenia je prehľadný energetický manažment mestských objektov s cieľom automatizácie a zníženia energetických nákladov na ich prevádzku. Softvér bude obsahovať tieto vlastnosti a funkcionality:

1. Evidencia objektov

V softvéri bude možné evidovať budovy, podlažia alebo miestnosti, ktoré sú používateľom vlastnené alebo prevádzkované. Informácie o budove budú obsahovať minimálne:

• Technický popis objektu
  • Charakteristika využitia objektu
  • Stav objektu
  • Fotografie objektu
  • Evidencia vlastníka objektu
  • Evidencia ďalších štruktúrovaných informácií

1. Technická dokumentácia

Bude obsahovať informácie v nasledovnom rozsahu:

• Situácia
• Pôdorysy jednotlivých podlaží
• Minimálne 1 rez objektu pre rýchlu navigáciu
• Základné rozmery
• Podlahovú plochu

Požiadavka na spracovanie digitálnej výkresovej dokumentácie všetkých spravovaných objektov

1. Evidencia odberných miest

Softvér bude umožňovať detailnú evidenciu odberných miest, ich umiestnenie do jednotlivých objektov alebo miestností. Každé odberné miesto musí obsahovať minimálne informáciu o EIC kóde, označenie odberného miesta a jeho typ (odberateľské alebo dodávateľské), rezervovaná kapacita, rezervovaný príkon, apod. Odberné miesto bude v rámci evidencie technických zariadení obsahovať informácie o jednotlivých meradlách, ktoré sa

1. Vyhodnocovanie spotrieb energií a automatizovaný reporting

Softvér bude umožňovať automatické generovanie jednoduchých a prehľadných vyhodnotení a porovnaní spotrieb energií a služieb. Softvér bude umožňovať porovnávať spotreby aj na základe klimatických podmienok. Klimatické podmienky budú evidované priamo v softvéri (priemerné vonkajšie teploty a dennostupne). Klimatické podmienky softvér umožní importovať z externých zdrojov (excel, IoT, apod.) Softvér automaticky vyhodnotí energetickú náročnosť objektov a jednotlivé spotreby objektov na základe regresnej analýzy. Analýzy a reporty budú umožňovať porovnávať spotreby s minulými obdobiami (rok, mesiac, apod.) v technických jednotkách aj cenách (EUR) za spoločnosť, objekt alebo inej úrovne na základe evidencie objektov a zariadení. Softvér bude upozorňovať na neštandardné stavy / spotreby meradiel v detaile spoločnosti, objektu, zariadenia.

1. OpenAPI

Softvér umožní prístup k vybraným informáciám formou API (REST API vo formáte JSON) v zabezpečenej podobe alebo prostredníctvom Open API. Jedná sa najmä o informácia o spotrebách energií, meradlách ako aj evidencii objektov, technických zariadeniach alebo VTZ.

1. Bezpečnosť a oprávnenia používateľov

Softvér umožní automatické prihlasovanie používateľov prostredníctvom tzv. SSO - Single SignOn. Každý používateľ bude mať nastavené oprávnenia na úrovni spoločnosti, objektu. Každý používateľ bude mať nastavené podrobné oprávnenia prostredníctvom zadefinovaných rolí k

LoRaWAN technická špecifikácia:

• Technológia: Spread Spectrum
• Modulácia: SS Chirp - FSK
• Počet kanálov: 16
• Veľkosť správy: 256 Bytov
• Prenosové pásmo Up: 125/250 kHz
• Prenosové pásmo Down: 125 kHz
• Prenosová rýchlosť: 250bps – 50kbps
• Frekvencia ISM: 867-869MHz (ETSI)
• Vysielací výkon: 25mW / +14dBm
• Citlivosť: -140dBm
• Odolnosť voči rušeniu: Veľmi vysoká
• Zabezpečenie: Šifrovanie AES128
• Lokalizácia/Mobilita: Áno
• Typ zariadení: Trieda A, B a C

LPWAN základňové stanice (gateway):

Gateway (brány LoRaWAN) na získavanie údajov z koncových zariadení spracúvajú dáta a konvertujú ich do formy dátovej zbernice (BACnet, Modbus). Spracované dáta ďalej zasielajú cez internetové brány mestských objektov verejným internetom na centrálny server (v cloude). Brány budú inštalované v mestských objektoch s dostatočnou penetráciou vzhľadom na pokrytie (všetkých) mestských objektov signálov LoRaWAN, resp. aj na pokrytie celých areálov mestských inštitúcií (pomocou opakovačov signálu).

Požiadavky na základňové stanice LoRa:

• prenos v rádiovom nelicencovanom pásme EU868
• podpora pásma EU868 a štandardu LoRaWAN verzie 1.0.2 rev.B (alebo vyššej)
• EU 863-870 MHz, 8 kanálov, RX senzitivita -135 dBm, TX výkon 27 dBm
• vlastný operačný systém s možnosťou upgradu firmvéru
• možnosť základnej diagnostiky prenosu (spoľahlivosť, stav komunikácie ap.)
• správa zariadenia cez web rozhranie (vzdialene bez nutnosti byť na mieste inštalácie)
• konektivita Ethernet 100BASE-TX smerom na nadradený systém
• unifikované napájanie 24V AC/DC (príp. 230 V)
• ochrana krytím aspoň na úrovni IP6x

Požiadavky na koncové prvky LoRa:

Pulzné prevodníky (IoT):

• podpora pásma EU868 a štandardu LoRa/LoRaWAN (class A)
• podpora šifrovania LoRaWAN AES 128 (alebo bezpečnejší)
• prevádzková teplota -20 až +55 °C (alebo širší rozsah)
• vysielací výkon 25 mW (14 dBm)
• univerzálna montáž (nástenná, DIN)
• ochrana krytím IP65 (alebo vyššie)
• autonómne napájanie batériou

Snímače vnútorného priestoru (IoT):

• podpora pásma EU868 a štandardu Lora/LoRaWAN (class A)
• podpora šifrovania LoRaWAN AES 128
• prevádzková teplota -20 až +55 °C
• vysielací výkon 25 mW (14 dBm)
• ochrana krytím IP40 (alebo vyššie)
• autonómne napájanie batériou
• meranie CO2 v rozsahu 0-5000 ppm s presnosťou +/- 100 ppm
• meranie VOC v rozsahu 0 až 60.000 ppb s presnosťou 1 ppb
• meranie teploty v rozsahu -40 až +125 °C s presnosťou +/-0.2 K
• meranie relatívnej vlhkosti v rozsahu 1-99 % s presnosťou +/- 2 %RH

Komunikačná brána (IoT):

• podpora pásma EU868 a štandardu LoRa (class A)
• podpora šifrovania LoRaWAN AES 128 (alebo bezpečnejší)
• komunikačný protokol Modbus, min. 10 slave zariadení
• rozsah prevádzkovej teploty -20 až +55 °C
• vysielací výkon 25 mW (14 dBm)
• unifikované napájanie 10 až 24 VDC
• ochrana krytím IP6x (alebo vyššie)

Voda IoT senzor:

• meranie spotreby vody
• meranie impulzného výstupu
• kompaktné prevedenie
• napájanie z batérie
• bezdrôtová rádiová komunikácia LPWAN
• diaľková konfigurácia a dohľad

"Plyn IoT

• pripojovací závit: 5/4"" (41,9 mm)
• impulzní výstup: 10 l/imp
• typ: jazýčkový kontakt
• max. napätie: 24 V

"Teplo IoT senzor:

• meranie spotreby Tepla
• kompaktné prevedenie
• bezdrôtová rádiová komunikácia LPWAN
• diaľková konfigurácia a dohľad
• dátaloger

Meranie spotreby tepla

• napájanie z batérie/230V
• bezdrôtová rádiová komunikácia LPWAN
• diaľková konfigurácia a dohľad
• typ zariadenia Master
• meranie spotreby tepla
• kvalitný fluidikový merač energií
• výstupné rozhranie M-Bus alebo bezdrôtová rádiová komunikácia LPWAN
• napájanie z batérie/230V
• diaľková konfigurácia a dohľad
• dialkové odpočitavanie dát od Spravbytkomfort a.s.

Interiérový snímač teploty, relatívnej vlhkosti, CO₂ a barometrického tlaku

• Teplota: -40ºC až 60ºC
• CO₂: 0 až 5000 PPM
• Vlhkosť: 0% až 100%
• Barometrický tlak: 700 až 1100 mbar
• Diskrétny digitálny vstup
• Bezdrôtové monitorovanie signálu
• Krytie IP65

4.5Bezpečnostná architektúra

Medzi základné bezpečnostné pravidlá radíme prístup k používateľskému rozhraniu (UX) prostredníctvom zabezpečeného protokolu (HTTPS), používanie zabezpečeného (šifrovaného) prenosu pri zbere dát a v rámci prenosov medzi jednotlivými komunikačnými prvkami na aplikačnej, technologickej a sieťovej úrovni. Použiť treba šifrovanie, u ktorého nie je známy prípad prelomenia a  vo všeobecnosti sa považuje za bezpečný.

Bezpečnosť systému CEM sa riadi legislatívou SR v oblasti informačných systémov

• zákon č. 95/2019 Z.z. o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov
• zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov
• vyhláška č. 179/2020 Z.z., ktorou sa ustanovuje kategorizácia a obsah bezpečnostných opatrení ISVS (vyhláška Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu)

V rámci realizácie projektu je potrebné dodržiavať rámec bezpečnostných pravidiel

• Udržiavanie manažmentu kyber-bezpečnosti
• Udržiavanie aktuálnej technickej dokumentácie kyber-bezpečnosti
• Používanie šifrovanej komunikácie na všetkých úrovniach systému CEM (pokiaľ možno dosiaľ neprelomeným šifrovacím algoritmom)
• Operačný systém osobných počítačov pod ochranou antivírusu
• Súčasťou antivírusového systému má byť modul firewall
• Osobné počítače majú obsahovať modul TPM (Trusted Platform Module)
• Osobné počítače obsahujú  OS vo verzii Windows 10 alebo vyššej, príp. OS Linux/Unix/MacOS s aktuálnymi bezpečnostnými záplatami a nevypršanou bezpečnostnou podporou
• Zatvorené porty smerom do vonkajšej siete (okrem funkčne potrebných)

Autorizácia používateľského prístupu do systému CEM

• Niekoľko-úrovňové štruktúrované používateľské práva v systéme CEM (prístup do vyššej úrovne otvára prístup k ďalším objektom a funkcionalitám, neplatí smerom k nižšej úrovni prístupu)
• Obmedzenie používateľských práv iba na nevyhnutný rozsah činnosti (konkrétna budova, konkrétna profesia, konkrétna pracovná pozícia), používanie zložitých hesiel s min. počtom 10 znakov

Bezpečnostné štandardy

• Štandardy pre architektúru riadenia – riadenie Informačnej bezpečnosti, rizikový manažment pre oblasť informačnej bezpečnosti, Kontrolný mechanizmus riadenia informačnej bezpečnosti.
• Minimálne bezpečnostné štandardy – ochrana proti škodlivému softvéru, firewall, aktualizácia softvéru, monitorovanie, periodické hodnotenie zraniteľností, zálohovanie údajov, požiadavky na fyzické ukladanie záloh, identifikácia a autorizácia.

5.Závislosti na ostatné ISVS / projekty

Nejestvujú nadväznosti na informačné systémy verejnej správy (ISVS) a funkčnosť CEM nie je závislá na akýchkoľvek iných systémoch ISVS alebo technických projektoch verejnej správy.

Okrem funkcie zdieľania otvorených dát cez rozhranie LKOD (API) pre národný katalóg otvorených dát (NKOD).

6.Zdrojové kódy

Dané riešenie predpokladá kúpu už existujúceho proprietárneho softvéru bez zdrojových kódov. V prípade potreby nutnosti použitia nových zdrojových kódov bude mesto, tieto zdrojové kódy požadovať pri odovzdaní projektu. Pravidlá pre preberanie, správu a archiváciu zdrojových kódov určí mesto v ZoD.

 Dôležité usmernenie pre oblasť zdrojových kódov:

• Centrálny repozitár zdrojových kódov: https://www.zakonypreludi.sk/zz/2020-78/znenie-20200501#p31
• Overenie zdrojového kódu s cieľom jeho prepoužitia: https://www.zakonypreludi.sk/zz/2020-85/znenie-20200501#p7-3-c
• Spôsoby zverejňovania zdrojového kódu: https://www.zakonypreludi.sk/zz/2020-85/znenie-20200501#p8-9
• Inštrukcie k EUPL licenciám: https://joinup.ec.europa.eu/sites/default/files/inline-files/EUPL%201_1%20Guidelines%20SK%20Joinup.pdf

 Navrhovaný projekt vytvorí aplikáciu na báze proprietárneho softvéru so základnými funkcionalitami Energy Manager (EM) od spoločnosti Honeywell, ktoré majú charakter Open Source. Na báze EM sa vytvorí application middlware, ktorého vlastníkom sa po protokolárnom odovzdaní stáva užívateľ, resp. „vlastník procesu“, a ktorý bude mať charakter Open Source. Využitie tejto platformy (EM) spĺňa konkrétne ustanovenie Zák. č. 95/2019 (§ 15 ods. 2 písm. d).

7.Prevádzka a údržba

Doplňte popis AS IS stavu zabezpečenia prevádzky a údržby a úroveň poskytovania služieb (SLA).
Doplňte popis TO BE stavu zabezpečenia prevádzky a údržby a úroveň poskytovania služieb (SLA).
Uveďte prehľad všetkých predpokladaných požiadaviek na prevádzku a údržbu cieľového riešenia.

7.1Prevádzkové požiadavky

Systém energetického manažmentu (softvérová a hardvérová časť) bude dodaný ako komplexné dielo. Údržbu a správu hardvéru a softvéru zabezpečí dodávateľ diela na základe servisnej zmluvy SLA min. na dobu 5 rokov. Počas zmluvnej doby mesto môže vyžadovať pridávanie nových (upgrade) softvérových či hardvérových funkcií a udržiavanie (updaty) jestvujúcich softvérových funkcií vrát. odstránenia malých softvérových chýb (bugov).

Obsah servisnej zmluvy SLA:

• Vykonávanie HW servisných zásahov (on-site) podľa požiadaviek Zákazníka
• Vykonávanie SW servisných zásahov (on-site aj off-site) podľa požiadaviek Zákazníka
• Definície závad podľa závažnosti a priority na odstránenie, definície celkovej nefunkčnosti systému
• Vylúčenie zodpovednosti za poruchy spôsobené tretími stranami (mimo dosah Prevádzkovateľa a Dodávateľa)
• Manažment hlásenia závad (incidentov) v systéme, reakčné doby na vyriešenie závad
• Ojednávanie a vykonávanie HW a SW rozšírení funkčného systému (upgrady)
• Objednávanie a vykonávanie pravidelnej SW údržby systému (updaty)
• Spôsob realizácie profilaktického servisu (prevencia závad)

Prevádzkové požiadavky

Cieľom Zákazníka je dodanie kompletného a funkčného systému CEM od Dodávateľa, zabezpečenie spoľahlivej prevádzky systému po dobu 60+ mesiacov. Počas tejto doby bude Dodávateľ udržiavať systém vo funkčnom stave na základe zmluvy o úrovni údržby SLA (Service Level Agreement).

Zmluva SLA definuje rozsah údržby systému a manažment odstraňovania porúch.

Hlásenie poruchy (alarmu):

Prevádzkovateľ nahlási každú poruchu systému Dodávateľovi na vopred dohodnutý kontakt podpory jednak telefonátom kde upozorní Dodávateľa na čas poruchy a preverí doručenie ním zaslaného emailu s popisom poruchy a sprievodnými prejavmi chybového stavu.

7.1.1Úrovne podpory používateľov

Help Desk bude realizovaný cez 3 úrovne podpory, s nasledujúcim označením:

• Úrovne poruchových stavov (alarmov):

  L1 (kritický incident, Fault) = technická porucha ochromujúca väčšiu časť alebo systém ako taký
  L2 (nekritický incident, Error) = presnejšie lokalizovaný incident, neohrozujúci celý systém
  L3 (prevádzkový incident, Warning) = bežný jednotlivý incident neohrozujúci systém

  Reakčné doby podľa priority poruchy (alarmu):

  Priorita                              Reakčná doba (RD)                          Doba odstránenia poruchy (DOP)                  Spoľahlivosť (poruchy za mesiac)

  L1                           2 hodiny                               36 hodín                                              1
  L2                           4 hodiny                               72 hodín                                              4
  L3                           8 hodín                                 144 hodín                                            10

  Reakčná doba je čas od nahlásenia poruchy Používateľom (zákazníkom) po prevzatie incidentu na riešenie Dodávateľom (prevádzkovateľom) a jeho potvrdením oznámenia poruchy. Doba odstránenia poruchy (DOP) je čas od nahlásenia poruchy Dodávateľovi (prevádzkovateľovi) systému až po konečné vyriešenie poruchy (KVP) Dodávateľom (prevádzkovateľom) systému.

  Vyššie uvedené SLA parametre nebudú použité pre nasledovné služby:

• vyžiadaná systémová podpora a školenia používateľov
• aplikačné úpravy vyplývajúce z legislatívnych a metodických zmien
• budúce modernizácie (upgrady a updaty) systému nad rámec tohto dokumentu

7.1.2Riešenie incidentov – SLA parametre

Za incident je považovaná chyba IS, t.j. správanie sa v rozpore s prevádzkovou a používateľskou dokumentáciou IS. Za incident nie je považovaná chyba, ktorá nastala mimo prostredia IS napr. výpadok poskytovania konkrétnej služby Vládneho cloudu alebo komunikačnej infraštruktúry.
Označenie naliehavosti incidentu:

• Služby systémovej podpory na požiadanie (nad paušál)
• Služby realizácie aplikačných zmien vyplývajúcich z legislatívnych a metodických zmien (nad paušál)
  Pre tieto služby budú dohodnuté osobitné parametre dodávky.

7.2Požadovaná dostupnosť IS:

7.2.1Dostupnosť (Availability)

Dostupnosť ako pojem vyjadruje čas dostupnosti IS za rok. V nasledujúcej tabuľke sú uvedené bežne používané parametre dostupnosti IS, vyjadrené hodinách (dňoch) za 1 kalendárny rok prevádzky.

Dostupnosť 90 % = výpadok 36,5 dňa (876 hodín)
Dostupnosť 95 % = výpadok 18,25 dňa (438 hodín)
Dostupnosť 98 % = výpadok 7,30 dňa (175,2 hodín)
Dostupnosť 99 % = výpadok 3,65 dňa (87,6 hodín)
Dostupnosť 99,5 % = výpadok 1,83 dňa (43,92 hodín)
Dostupnosť 99,8 % = výpadok 17,52 hodín
Dostupnosť 99,9 % = výpadok 8,76 hodín

RTO (Recovery Time Objective) vyjadruje dobu na obnovenie systému, tj. Za ako dlho po výpadku musí byť obnovená prevádzka systému, aké množstvo dát môže byť stratené počas doby systému mimo prevádzky.  RPO (Recovery Point Objective) vyjadruje mieru, do akého bodu (stavu) v minulosti možno obnoviť systém, tzn. o aké množstvo dát môže prísť prevádzkovateľ systému jeho vlastným výpadkom resp. (presne) časovo ohraničenou nedostupnosťou. Recovery Time = čas do obnovenia prevádzky systému.

Nedostupnosť systému je riziko, ktorý môže postihnúť každú organizáciu a každý projekt. Dostupnosť je jednou z kľúčových technických požiadaviek na informačné systémy. Na technickú dostupnosť (prevádzky-schopnosť) systému vplýva mnoho faktorov, napríklad:

• Dostupnosť servera

• Dostupnosť databázy
• Dostupnosť prenosovej siete
• Dostupnosť verejného internetu
• Dostupnosť používateľských rozhraní
• Dostupnosť technických prvkov a koncových zariadení

V prípade, že je istá hardvérová alebo softvérová časť infraštruktúry riešená externe (hosting, cloud), prenáša sa zodpovednosť za dostupnosť týchto komponentov na dodávateľa externej služby. V tom prípade treba zmluvne vhodne ošetriť úroveň dostupnosti, ktorú bude povinný dodávateľ externej služby dodržať. Dostupnosť je zvyčajne súčasťou dohody o úrovni poskytovaných služieb (SLA).

7.2.2RTO (Recovery Time Objective)

Recovery Time Objective (zvyčajne sa požíva skratka RTO) je jeden z ukazovateľov dostupnosti dát. RTO vyjadruje množstvo času potrebné pre obnovenie dát a celej prevádzky nedostupného systému (softvér). Môže byť, v závislosti na použitej technológii, vyjadrené v sekundách, hodinách či dňoch.
Využitie RTO v praxi: Ukazovateľ RTO sa z pohľadu zákazníka využíva pre vyjadrenie doby pre obnovu dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a dobu obnovy dát znížiť až k nulovému výpadku. Existujúce technológie sa delia zhruba nasledovne:

• Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
• Asynchrónne replikácie dát - výpadok a obnova v poriadku sekúnd až minút
• Synchrónny replikácie dát - nulový výpadok

7.2.3RPO (Recovery Point Objective)

Recovery Point Objective (zvyčajne sa požíva skratka RPO) je jeden z ukazovateľov dostupnosti dát. RPO vyjadruje, do akého stavu (bodu) v minulosti možno obnoviť dáta. Inými slovami množstvo dát, o ktoré môže organizácia prísť.
Využitie RPO v praxi: Ukazovateľ RPO sa z pohľadu zákazníka využíva pre vyjadrenie množstva obnoviteľných dát. (napr. formou SLA). Na druhú stranu poskytovatelia dnes môžu voliť rôzne technológie zálohovanie, respektíve replikovanie dát a bod obnovy dát znížiť až k nulovej strate. Existujúce technológie sa delia zhruba nasledovne:

• Tradičné zálohovanie - výpadok a obnova trvá cca hodiny až dni
• Asynchrónne replikácie dát - výpadok a obnova v poriadku sekúnd až minút, strata sa blíži k nule
• Synchrónny replikácie dát - nulová strata

8.Požiadavky na personál

Pracovné pozície potrebné na implementáciu systému:

• Projektový manažér
• Manažér kvality
• IT architekt
• Dátový špecialista
• Kľúčový používateľ
• Vlastník procesov
• IT analytik

Riadenie projektu bude zabezpečovať RV a projektový tím objednávateľa. Realizáciu projektu bude zabezpečovať projektový tím dodávateľa v koordinácii s RV. Dokumentácia k systému bude obsahovať:

• dokumentáciu pre obsluhu Systémovým administrátorom – Administrátorská príručka
• dokumentáciu pre obsluhu Používateľmi vo všetkých rolách – Používateľská príručka

Školenia používateľov bude poskytnuté v rozsahu školenia:

• administrátora systému – rozsah 1 deň pre 1 účastníka
• kľúčových užívateľov – rozsah max. 20 hodín pre 10 účastníkov

Školenia koncových používateľov budú realizované vyškolenými kľúčovými používateľmi.

9.Implementácia a preberanie výstupov projektu

V zmysle Vyhlášky 401/2023 Zz o projektovom riadení bude spôsob realizácie projektu metódou waterfall. V zmysle vyhlášky 401/2023 Z. z. o projektovom riadení je možné pristupovať k realizácii projektu prostredníctvom čiastkových plnení, t.j. inkrementov, a to:

• Inkrement musí obsahovať z realizačnej fázy projektu aspoň etapu Implementácia a Testovanie a Nasadenia do produkcie; je možné ho realizovať viacerými iteráciami v závislosti od charakteru projektu a každý doručený inkrement projektu je nasadený na produkčnom prostredí informačnej technológie a je možné začať s dokončovacou fázou projektu, alebo pokračovať ďalším inkrementom.

Obr. 5_Harmonogram implementácie projektu

Testovanie a akceptácia prebehne po kompletnom ukončení školenia administrátora a kľúčových používateľov IS. Pre účely testovania IS kľúčovými používateľmi budú pripravené a dodané testovacie scenáre. Testovanie prebehne v týchto krokoch:

• Akceptačné testovanie prebehne prostredníctvom kľúčových používateľov za podpory dodávateľa
• Zistené vady IS počas testovania budú dodávateľom odstránené
• Ďalšie kolo akceptačného testovania
• Ďalšie odstránenie prípadných vád dodávateľom
• Posledné kolo akceptačného testovania
• Akceptácia riešenia v prípade úspešného akceptačného testovania
• Prevzatie IS do pilotnej prevádzky
• Odstránenie prípadných vád zistených počas pilotnej prevádzky
• Prevzatie IS do ostrej prevádzky

10.Prílohy