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

V súlade s Vyhláškou 401/2023 Z.z. je dokument I-03 Prístup k projektu určený na rozpracovanie detailných informácií prípravy projektu Moderné technológie - Energetická optimalizácia prevádzkovania verejných budov prostredníctvom inteligentného merania z pohľadu aktuálneho stavu, budúceho stavu a navrhovaného riešenia.

Dokument Prístup k projektu v zmysle vyššie uvedenej vyhlášky obsahuje opis navrhovaného riešenia, architektúru riešenia projektu na úrovni biznis vrstvy, aplikačnej vrstvy, dátovej vrstvy, technologickej vrstvy, infraštruktúry navrhovaného riešenia, bezpečnostnej architektúry, špecifikáciu údajov spracovaných v projekte, čistenie údajov, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy. Dodávané riešenie je v súlade so zákonom. Zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu.

2.1Použité skratky a pojmy

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

Hlavné kategórie požiadaviek v zmysle katalógu požiadaviek, rozdeľujeme na funkčné, nefunkčné a technické. Podskupiny v hlavných kategóriách je možné rozšíriť v závislosti od potrieb projektu:

Funkcionálne (používateľské) požiadavky majú nasledovnú konvenciu:

FRxx

• U          – užívateľská požiadavka
• R          – označenie požiadavky
• xx         – číslo požiadavky

Nefunkčné (kvalitatívne, výkonové - Non Functional Requirements - NFR) požiadavky majú nasledovnú konvenciu:

NRxx

• N          – nefukčná požiadavka (NFR)
• R          – označenie požiadavky
• xx         – číslo požiadavky

Ostatné typy požiadaviek môžu byť ďalej definované objednávateľom/PM.

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-04.

3.Popis navrhovaného riešenia

Popisuje riešenie pre energetický manažment a manažmentu správy budov v prevádzke Prešovského kraja.

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

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

IS Energetický manažment budov:

Inštalácia meracích IoT senzorov do budov, ktoré budú posielať namerané dáta cez existujúcu infraštruktúru budov do IS.
Uložené údaje v aplikačnom servery budú dostupné pre ďalšie spracovanie vrátane ich dostupnosti cez štandardy otvorených dát (Open API).

Meranie vybraných veličín v potrebných malých časových intervaloch je základom pri podpore efektívneho využívania energií na potrebných miestach. Z nameraných veličín s dostatočne rýchlou analýzou, je možné namodelovať správanie sa spotrebiteľov energie i samotnej budovy.

Okrem „vyrobenia“ modelu, takéto meranie ukáže anomálie, poruchy i neštandardné správanie sa spotrebiteľov. Sledovaním spotreby energie s prenosom na diaľku získame nástroj, ktorý umožňuje ušetriť energiu.

Vytvorením modelu budovy vytvoríme referenčný priebeh, ku ktorému je možné v budúcnosti vzťahovať novú spotrebu energie, ktorú dosiahneme po vykonaní úsporných opatrení.

Základné potreby sú zabezpečenie tepelnej pohody, dostupnosť elektrickej energie a pitnej úžitkovej vody a teda základné sledované parametre sú:

• Elektrická energia - je využívaná v každej organizácii a budove. Ak je nejaká budova napojená aspoň na jeden druh energie, tak s najväčšou pravdepodobnosťou to bude elektrická energia.

Výhody sledovania spotreby elektrickej energie:

• meranie zaťaženia jednotlivých fáz
• meranie činnej, jalovej a zdanlivej energie v minútových intervaloch
• sledovanie štvrťhodinového maxima, rezervovanej kapacity s predikciou možného prekročenia objednanej hodnoty
• sledovanie spotreby rôznych spotrebičov, identifikácia najväčších spotrebičov s následnou možnosťou zamerania sa na najväčší spotrebič elektrickej energie
• vyhodnotiť spotrebu elektrickej energie na osvetlenie so súčasným meraním intenzity osvetlenia z dôvodu dodržiavania hygienických podmienok
• vyhodnotiť spotrebu energie na kompresory, ventilátory a ďalšie spotrebiče, ktoré sú súčasťou systémov vetrania a klimatizácie
• neštandardné zapínanie a vypínanie spotrebičov pri nesprávnom nastavení riadiaceho parametra
• nameranie zvýšenej spotreby u starších spotrebičov a návrh na ich výmenu
• na základe výstražných upozornení poruchy v elektrickej sieti
• pri výpočtoch, ktoré budú slúžiť na porovnávanie spotrieb jednotlivých organizácií mesta
• pri kontrole projektov EPC a projektov financovaných z eurofondov

• Nakupované teplo pre potreby vykurovania budov - energia vo forme tepla je dodávaná k odberateľom zo systému centralizovaného zásobovania.

Výhody sledovania spotreby tepla:

• využitie informácie o spotrebe tepla pri výpočte účinnosti výroby tepla
• pri rozdelení tepla na teplo na vykurovanie a teplo na prípravu teplej vody
• pri rozdelení tepla na teplo na jednotlivé vetvy, vetranie a klimatizáciu, výrobu tepla v slnečných kolektoroch, atď.
• pri výpočte ceny tepla, pri rôznych kalkuláciách, atď.
• pri výpočtoch, ktoré budú slúžiť na porovnávanie spotrieb jednotlivých zariadení PSK
• pri kontrole projektov EPC a projektov financovaných z eurofondov

• Spotreba vody / TÚV - Teplá voda je vyrábaná v zdroji tepla (kotolni) a dodávaná rozvodmi až k odberateľovi (konečnému spotrebiteľovi). Teplá voda je na odbernom mieste meraná fakturačným vodomerom.
• Vnútorné prostredie - teplota, vlhkosť a koncentrácia CO2.
• Potreba tepla / chladu - vnútorná teplota / vonkajšia teplota - porovnávaním vnútorných teplôt s vonkajšími je možné určiť tepelné straty objektu a potrebu tepla alebo chladu pre zabezpečenie tepelnej pohody objektu.

Výhody sledovania a merania pomocou IoT senzorov:

• detekciu poruchových stavov u zariadení
• identifikáciu abnormálnych stavov zariadení
• odhaľovanie chýb obsluhy a jej kontrolu
• detekciu spotreby v čase, keď by malo byť zariadenie mimo prevádzky
• zisťovanie stavov zariadení (on/off)
• identifikáciu časov zapnutia a vypnutia zariadení
• identifikáciu prekročenia maximálnej a minimálnej hodnoty nameraných veličín

IoT senzory:

• Smartmeter:
  • meranie spotreby elektrickej energie,
  • priebehové meranie napätí a prúdov na troch fázach s presnosťou merania ± 1%
  • pasívne meranie prúdu prúdovými svorkami (rôzne prúdové zaťaženia 30 - 600A)
• Plyn IoT:
  • meranie spotreby plyny
  • meranie impulzného výstupu
• Voda IoT:
  • meranie spotreby vody
  • meranie impulzného výstupu
• Meranie teploty a vlhkosti exteriér:
  • meranie teploty v rozsahu -40°C až 80°C s presnosťou ± 0,2°C.
  • meranie relatívnej vlhkosti v rozsahu 0 – 99,9% s presnosťou ± 2%.
• Meranie teploty, vlhkosti interiér:
  • meranie teploty v rozsahu 0°C až 50°C s presnosťou ± 0,2°C.
  • meranie relatívnej vlhkosti v rozsahu 0 – 85% s presnosťou ± 2%.
• Meranie teploty, vlhkosti a CO2:
  • meranie teploty v rozsahu 0°C až 50°C s presnosťou ± 0,2°C.
  • meranie relatívnej vlhkosti v rozsahu 0 – 85% s presnosťou ± 2%.
  • meranie úrovne CO2 v rozsahu 0 – 2000ppm s presnosťou ± 50ppm.

4.Architektúra riešenia projektu

4.1Biznis vrstva

Súčasný pohľad na biznis architektúru prezentuje akým spôsobom je v súčasnosti riešená agenda Prešovského samosprávneho kraja z oblasti Energetického manažmentu a manažmentu budov.
 

Zamestnanci PSK využívajú pre správu majetku a pasportizáciu objektov zavedený softvérový nástroj T-Mapy, ktorý je nedostatočný a z dlhodobého hľadiska neudržateľný. Práca s nástrojom je neefektívna, nie je možnosť vypĺňania / dopĺňania nevyhnutných informácií týkajúcich sa objektov / budov v správe PSK. Napĺňanie softvérovej platformy novými / aktuálnymi informáciami naráža na prekážky v podobe personálneho a odborného zabezpečenia. Chýba jednoduchá filtrácia, reporting, export a ďalšia práca s analýzou dát. Neexistuje možnosť Business Inteligence analýzy, riadenie procesov nad majetkom, poskytovanie manažérskych informácií, evidencia, sledovanie, plánovanie, hospodárenie,  správa, údržba, opravy, investičná činnosť  (inv.dlh ...) a ďalšie činnosti. Absentuje tiež prepojenie na ekonomický SW (OC,ZC, inventúry), existujúce datasety, dostupné referenčné registre, GIS.

V oblasti energetického manažmentu úrad nevyužíva žiadne softvérové nástroje. Niektoré budovy majú nainštalované IoT zariadenia, avšak neexistuje softvérová platforma pre zber, uchovávanie údajov, spracovanie a vizualizáciu údajov.  Súčasný systém získavania informácií od správcov budov je neaktuálny v čase a dostupný na rôznych miestach. Ich vzájomné prepojenie, ktoré by prinášalo synergický efekt v úsporách energie a lepšom manažmente správy budov, nie je v súčasnosti možné realizovať.  

Navrhovaná softvérová platforma pre podporu tvorby, spracovania, využívania a prepájania dát v oblasti energetiky a správy budov PSK s využitím IoT riešení bude riešiť všetky kľúčové problémy užívateľov a zároveň odstráni príčiny problémov, s ktorými sa momentálne stretávajú kľúčoví používatelia.

Budúci pohľad:

Možnosti uplatnenia energetického manažmentu a manažmentu správy budov predstavujú významný priestor pre riadenie podporných činností PSK. Monitorovať spotrebu energií vo verejných budovách PSK a navrhovať opatrenia na jej znižovanie využívaním SMART nástrojov a uplatňovanie facility managementu prináša rôzne benefity: 

• cielené akčné plány do zníženia energetickej náročnosti budov, zníženia nákladov na prevádzku a zároveň výstupy slúžia aj ako rozhodovací nástroj v mnohých operatívnych problémoch v rámci podporných činností PSK;
• po uplynutí relatívne krátkeho času je možné dosiahnutie optimálnej prevádzky energetických zariadení, čo sa v konečnom dôsledku prejaví v znížení nákladov na energiu;
• úspory prevádzkových nákladov a zároveň zaistenie týchto činností zabezpečí aj vyššiu výkonnosť a hospodárnejšie nakladanie s verejnými zdrojmi; 
• výsledky projektu budú využité na úrovni riadenia PSK a to v stratégii riadenia investícií, v územnoplánovacej politike, správe nehnuteľností, finančnom plánovaní, oceňovaní investícií, v zaobchádzaní s údajmi a v tvorbe verejných politík;
• podpora rozvoja miest i regiónu PSK prostredníctvom implementácie inovatívnych technologických a netechnologických riešení a inteligentného riadenia;
• rýchlejšie odhaľovanie rôznych technických porúch, únikov, havárií atď.; 
• zavedenie jednotného systému a postupov oblasti hospodárenia s energiami v zariadeniach v majetku PSK;  
• podpora pri príprave projektov na úsporu energie;
• práca s prevádzkovateľmi energetických zariadení a pod.;
• predpokladaný prenos dát a zdieľanie príkladov dobrej praxe v rámci pripravovaného národného projektu "Kapacity pre regióny" (vznik krajských a regionálnych centier udržateľnej energetiky); 
• hospodárnejšie využívanie priestorov, nehnuteľností, inventára PSK.

Obrázok 1 Schéma technologickej, aplikačnej a prezentačnej vrstvy ÚPSK

Obrázok 2 Schéma budúcej business architektúry

Za podpory online dát zo senzorov a ich vyhodnoteniu a včasnému upozorneniu príslušných správcov je možné predísť škodám na majetku.

1. senzory posielajú online dáta na spracovanie
2. dáta sa analyzujú (cleansing/clearing dát)
3. vyhodnocujú sa dáta voči nastaveným pravidlám na nezvyčajné hodnoty
4. na základe nezvyčajných hodnôt zo senzorov sa posiela notifikácia správcovi
5. správca vykoná včas potrebné úkony na zabránenie škodám

Obrázok 4 Úspora na energetickom managemente

Energeticky manažment objektov dokáže dodať reporty rôzneho druhu o spotrebovaných energiách a tak je možné optimalizovať nákup energii a taktiež riadiť spotrebu energií na základe online dát zo senzorov a správneho časovania.

1. dáta sa analyzujú (cleansing/clearing dát)
2. vyhodnocujú sa dáta voči nastaveným pravidlám (pre riadenie spotreby energii)
3. úprava v spotrebe energii na základe vyhodnotených pravidiel
4. príprava nadefinovaných reportov
5. výber optimálnych energetických balíkov od dodávateľa na základe reportov

Obrázok 5 Modely biznis architektúry pre ENM a MSB

V rámci podpory správy majetku a energetického manažmentu PSK bude zavedený IS pre správu dát zo senzorov, rozšírenie funkcií v ENM ako automatická správa objektov, generovanie reportov, zobrazovanie online stavu objektov a podpora správy majetku. Automatizácia a digitalizácia v tejto oblasti podporí a uľahčí riešenie agendy PSK, prevádzky budov, správy energií, tvorby politík a pod.

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

4.1.2Jazyková podpora a lokalizácia

Všetky GUI obrazovky IS a reporty budú dodané v slovenskom jazyku. Riešenie musí podporovať multi-jazyčnosť v prípade potreby do budúcnosti pridať aj iný jazyk.u.

4.2Aplikačná vrstva

Obrázok 6 Model AS IS aplikačnej architektúry

Obrázok 7 Model To BE aplikačnej architektúry

• IS Energeticky management a management budov
  • Údržba – údržba a evidencia odberných miest, notifikácie na termíny, hodnoty a pod.
  • Správa budov – evidencia objektov/majetku/zariadení/vyhradených technických zariadení, správa majetku, dokumentov
  • Vizualizácia dát – reporty, vizualizácia dát
  • Energeticky management – vyúčtovanie nákladov prenajímaných priestorov, vyhodnocovanie spotrieb energii a automatizovaný reporting
  • IoT – zber dát
• API vrstva
  • verejné API - OpenAPI - umožní prístup k vybraným informáciám formou API 
  • neverejné API
• Dávkové spracovanie dát/reportov – modul na dávkové spracovanie dát neovplyvňujúci chod IS systémov
• Integračný modul – genericky modul na integráciu riešenia
  •  IAM – integrácia na centrálnu správu a autentifikáciu a autorizáciu užívateľov kraja
  •  IoT – integrácia na IoT zariadenia
  •  Integration API – integrácia na externe systémy
    • Kataster portál
    • SPIN
    • DMS

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

Projekt nebude využívať nadrezortné ISVS

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

Irelevantné.

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

Irelevantné..

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

Uveďte v nasledujúcej tabuľke budované aplikačné služby, realizáciu koncových služieb aplikačnou službou, koncová služba by mala byť realizovaná aspoň jednou aplikačnou službou (KS môžu realizovať aj viaceré aplikačné služby). Všetky aplikačné služby a ich vzťah na koncové služby musia byť evidované v MetaIS.

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

• AS (Kód MetaIS)	Názov AS	Realizuje ISVS (kód MetaIS)	Poskytujúca alebo Konzumujúca	Integrácia cez CAMP	Integrácia s IS tretích strán	SaaS	Integrácia na AS poskytovateľan (kód MetaIS)
  as_66188	Implementácia OpenAPI a OpenData riešení		Poskytovaná / Konzumujúcac_typ_cloud_sluzba_as.1	Áno/Nie	Áno/Nie	Áno/Nie

• Obrázok 7 Integrácie na IS CSRÚ – ref. príklad
  
   

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

4.2.9Konzumovanie údajov z IS CSRU – TO BE

4.3Dátová vrstva

Popis dát, ktoré PSK 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. PSK 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.
• 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, evidencie majetku, rozpočítavanie energií a pod.

4.3.1Údaje v správe organizácie

• Proces riadenia pre manažment údajov musí byť zavedený nad informačnými systémami, ktoré obsahujú objekty evidencie a budú riešené v projekte.
• Po organizačnej stránke je podmienkou zavedenie role dátového kurátora (dátový architekt) v organizácii, v rozsahu ako ju definuje strategická priorita Manažment údajov a strategická priorita Otvorené údaje, ktorý bude zodpovedný za koncept systematického manažmentu údajov a úpravu organizačnej štruktúry smerom k vytvoreniu rezortnej dátovej kancelárie.

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

Pre budované informačné systémy vytvorte tzv. doménový model, ktorý definuje návrh dátových prvkov súvisiacich s projektom.

• Úlohou doménového modelu je vizuálne znázorniť rozsah predmetných údajov daného projektu, pričom je možné abstrahovať od nepodstatných detailov. Je platformovo nezávislý (nie je určený pre konkrétny programovací jazyk),
• V nasledujúcej tabuľke uveďte a popíšte Objekty Evidencie (ďalej len OE) v jednotlivých ISVS/registroch súvisiace s projektom.
• Doménový model by mal byť v súlade s existujúcim Centrálnym modelom údajov verejnej správy (viac informácií na: https://mirri.gov.sk/sekcie/informatizacia/egovernment/datova-kancelaria/interoperabilita/ a https://metais.vicepremier.gov.sk/publicspace?pageId=59836112.).
• Pre modelovanie doménového modelu je potrebné stiahnuť si Centrálny model údajov verejnej správy v preferovanej distribúcii a v novom modeli použiť existujúce dátové prvky, ak tieto patria do domény projektu. Z technického pohľadu je odporučený jazyk UML (pre zjednodušený doménový model môžete použiť aj jazyk ArchiMate).
• V prípade, že sa používa dátový prvok z Centrálneho dátového modelu je nutné použiť skrátenú formu URI identifikátora daného prvku, napr. pper:PhysicalPerson je skrátený tvar https://data.gov.sk/def/ontology/physical-person/PhysicalPerson

ID OE	Objekt evidencie - názov	Objekt evidencie - popis	Referencovateľný identifikátor URI dátového prvku
			(Ak nie je priradené URI uveďte „Nemá“)
			Obrázok 8 Doménový model - príklad Obrázok 9 Zjednodušený doménový model - príklad

4.3.3Referenčné údaje

Nerelevantné. Projekt nevyužíva referenčné údaje.

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

Nerelevantné. Projekt nevyužíva referenčné údaje.

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

4.3.4Kvalita a čistenie údajov

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

Projekt neimplementuje procesy kvality a čistenia údajov.

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

Nerelevantné

4.3.5Otvorené údaje

Pri tvorbe otvorených dát požadujeme zabezpečiť kompatibilitu s centrálnym portálom otvorených dát MIRRI SR - data.slovensko.sk.

Dodávateľ musí v rámci projektu zabezpečiť vytvorenie lokálneho katalógu otvorených dát (LKOD) podľa štandardu DCAT-AP-SK2.0 (https://github.com/datova-kancelaria/dcat-ap-sk-2.0), alebo SPARQL Endpoint, sprístupniť datasety data.slovensko.sk, a registrovať LKOD do centrálneho Národného katalógu otvorených údajov (dostupný na data.gov.sk).

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 CSV, XML, ODS, JSON

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

Automatizované publikovanie otvorených údajov v kvalite 5★ (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.

4.3.6Analytické údaje

PSK neplánuje integráciu modulov na sprístupňovanie údajov pre analytické jednotky a pre špeciálne organizačné útvary orgánov verejnej moci.

4.3.7Moje údaje

Realizáciou projektu nebudú spracovávané údaje, ktoré spĺňajú charakter definície mojich údajov.

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

4.4Technologická vrstva

4.4.1Prehľad technologického stavu - AS IS

Hypervisor – virtualizačná  platforma, ktorá je schopná virtuálne prevádzkovať viacero virtuálnych serverov na jednom HW serveri. 

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

LPWAN

• IoT zariadenia pre zber dát – energie – voda, zemný plyn, elektrická energia, teplo, vnútorné prostredie, vonkajšie počasie (meteostanice) 
• Gateway  - lokálne prenosové brány LoRAWAN, WiFi, SIGFOX  

Serverová infraštruktúra/cloud platform – generická platforma, na ktorú je možné nasadiť riešenie v kontainerizovateľnej forme, čo umožní v budúcnosti dané riešenie jednoducho premiestniť na vlastný server alebo iné cloudové riešenie. Daná platforma má vyriešené všetky infra potreby ako archivácia, backup, škálovateľnosť prostredia.

• Containers – riešenie možné nasadiť v kontainerizovanej forme (docker, virtual machine) od aplikačných serverov až po databázu. Možnosť škálovať riešenie v prípade potreby horizontálne aj vertikálne.

Infarštrukturálne komponenty

• WAF (Web application firewall) - Chráni webové aplikácie filtrovaním a monitorovaním HTTP prevádzky medzi webovou aplikáciou a internetom. Typicky chráni webové aplikácie pred útokmi, ako sú cross-site request forgery (CSRF), cross-site scripting (XSS), vkladanie súborov a SQL injection, okrem iných.

4.4.3Návrh riešenia technologickej architektúry

Obrázok LPWAN

Technologická časť pre IoT smartmetering bude vychádzať z vybudovania Low Power Wide Area Network (LPWAN) siete, dodania a inštalácie hardvéru pre energetický monitoring objektov, kvalitu vnútorného a vonkajšieho prostredia. Hardvér pre meranie a sledovanie požadovaných parametrov objektov a okolia bude kombináciou IoT snímačov a smart meračov. Zber a posielanie údajov bude cez vybudovanú prenosovú sieť, odkiaľ budú údaje následne smerované do softvérovej platformy pre ich spracovanie, uchovávanie, vizualizovanie a vyhodnocovanie. Meranie spotrieb energií a iných parametrov objektov bude automatizované a diaľkové v pravidelných časových.

Je požadované vybudovať vlastnú LPWAN sieť, ktorá bude zameraná na splnenie kľúčových požiadaviek internetu vecí, ako je bezpečná obojsmerná komunikácia, mobilita a variabilita. Vybudovaná sieť musí disponovať pásmom 169 MHz, ktoré vďaka nižšej frekvencii a vyššiemu vysielaciemu výkonu (až do 500 mW) umožňuje lepšiu komunikáciu v ťažko dostupných podmienkach a taktiež pásmom 868 MHz pre dostatočný rozsah a škálu nasadenia IoT snímačov. Takáto kombinácia frekvenčných pásiem poskytne bezproblémovú spoluprácu medzi smart meradlami, zariadeniami, dostatočné pokrytie prenosový signálom a variabilitu z pohľadu ďalšieho rozvoja a smerovanie smartmeteringu.

Sieťová architektúra LPWAN bude využívať viacnásobnú hviezdicovú topológiu alebo samostatné ostrovy, kde brány budú jednotlivými transparentnými mostami medzi koncovými zariadeniami a centrálnym sieťovým serverom v backende. Zo sieťového servera budú údaje smerované do aplikačného servera, kde budú údaje z jednotlivých koncových zariadení spracovávané, uchovávané, vizualizované a vyhodnocované. Uložené údaje v aplikačnom servery budú taktiež dostupné pre ďalšie spracovanie cez štandardy otvorených dát (Open API), ktoré sú bližšie opísané v softvérovej časti.

Transparentný most, ktorý prijíma správy z koncových zariadení a preposiela ich na sieťový server. Každá základňová stanica je registrovaná na sieťovom serveri a vyžaduje nepretržité pripojenie do verejného internetu. Jednotlivé základňové stanice budú inštalované na objektoch zadávateľa v jednotlivých lokalitách tak, aby bolo zabezpečené pokrytie signálom celého areálu.

Koncové zariadenia pomocou, ktorých budú získavané údaje o spotrebách energií, kvalite prostredia a komforte v objektoch. Zariadenia budú vo forme snímačov, prevodníkov alebo komplexných smartmetrov. Údaje zo zariadení budú bezdrôtovo posielané na základňové stanice v pravidelných časových intervaloch. Je požadované, aby IoT zariadenia a meradlá ako vodomery a merače tepla (DN25 a vyššie), ktoré budú inštalované v odľahlých a náročne dostupných častiach areálu, disponovali 169 MHz komunikačným pásmom.

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

Nerelevantné. Vládny cloud nebude využívaný.

4.5Bezpečnostná architektúra

Bezpečnostná architektúra s dotknutými právnymi normami a zároveň s technickými normami, ktoré stanovujú úroveň potrebnej bezpečnosti IS,  pre manipuláciu so samotnými dátami, alebo technické/technologické/personálne zabezpečenie samotnej výpočtovej techniky/HW vybavenia bude v súlade s:

• 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
• Zákon č. 45/2011 Z.z. o kritickej infraštruktúre
• Vyhláška 78/2020 Z. z., Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu o štandardoch pre informačné technológie verejnej správy
• Vyhláška 179/2020 Z. z., Úradu podpredsedu vlády Slovenskej republiky pre investície a informatizáciu, ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy
• vyhláška č. 158/2018 Z. z. Úradu na ochranu osobných údajov Slovenskej republiky o postupe pri posudzovaní vplyvu na ochranu osobných údajov
• Nariadenie Európskeho parlamentu a Rady (EÚ) 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov)
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.

Bezpečnosť bude riešená v súlade so schválenou koncepciou rozvoja IS v PSK.

Bezpečnostné štandardy:

Štandardy pre architektúru pre riadenia – Riadenie Informačnej bezpečnosti, rizikový manažment pre oblasť informačnej bezpečnosti, Kontrolný mechanizmus riadenia informačnej bezpečnosti

Minimálne technické bezpečnostné štandardy – ochrana proti škodlivému softvéru, firewall, aktualizácia softvéru, monitorovanie, periodické hodnotenie zraniteľnosti, zálohovanie, požiadavky na fyzické ukladanie záloh, identifikácia a autorizácia

Technologickú vrstvu zabezpečí nasadenie cloudovej platformy.

Prístup k aplikačnému rozhraniu bude prostredníctvom zabezpečeného protokolu HTTPS. Komunikácia medzi klientami a servermi bude šifrovaná šifrovacím algoritmom, ktorý je všeobecne považovaný za bezpečný, dôveryhodný a nie je známy prípad jeho prelomenia.

Autentizácia používateľov bude voči aplikačnej databáze a dostupnému doménovému radiču and IAM modulu (SAML / OIDC protokol).

• IS bude umožňovať nastavenie prístupových práv na jednotlivé funkcionality IS a zároveň v členení na spravované objekty a typy údajov v IAM module PSK.

5.Závislosti na ostatné ISVS / projekty

Sumárny prehľad všetkých projektov, programov a informačných systémov (ISVS), od ktorých je realizácia pripravovaného projektu závislá mapuje tabuľka nižšie.

6.Zdrojové kódy

Dané riešenie predpokladá kúpu už existujúceho proprietárneho softwaru bez zdrojových kódov.

Doplňte požiadavky na zdrojové kódy (napr. zo vzorovej zmluvy). Aké druhy, formy a štruktúry zdrojových kódov požadujte odovzdať. Stručne popíšte aj spôsob ich preberania, periodicitu (pri akých míľnikoch) a spôsob archivácie,
Doplňte pravidlá pre preberanie, správu a archiváciu zdrojových kódov a tieto pravidlá následne preniesť do Zmluvy o dielo alebo zmluvy na podporu (ZoD/SLA).
Naviažte preberanie/odovzdávanie zdrojových kódov na fakturačné míľniky.
Navrhnite spôsob, ako predísť „Vendor lock-in“ = t.j. dodávané riešenie musí byť v súlade so Zákonom o ITVS (ktorý „vendor lock-in“ nepovoľuje). Následne ustanovenia predchádzaniu vendor-lockinu musia byť zahrnuté aj v ZoD a SLA.
Usmernenia pre oblasť zdrojových kódov:

• Metodické usmernenie č. 024077/2023 – o kvalite zdrojových kódov a balíkov softvéru zverejnené na stránke: https://mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/
• Inštrukcie k EUPL licenciám: https://commission.europa.eu/content/european-union-public-licence_en

7.Prevádzka a údržba

ISVS budú prevádzkované dodávateľom v zmysle SLA zmluvy. Údržbu a správu hardvéru bude rovnako vykonávať dodávateľ IS.

SLA zmluva bude podpísaná na obdobie minimálne 5 rokov.
 

Obsahom SLA zmluvy bude poskytovanie pravidelných služieb pre podporu a zabezpečenie prevádzky a údržby:
 

• realizácia servisných zásahov podľa požiadaviek (riešenie požiadaviek na zmenu konfigurácie),
• činnosti a práce nevyhnutné pre zachovanie funkčnosti a prevádzkyschopnosti Informačného systému
• podpora pri realizácii rozvojových zásahov (riešenie požiadaviek),
• poskytovanie telefonických konzultácií pre pracovníkov Objednávateľa,
• odstraňovanie vád komponentov a modulov v požadovanej kvalite,
• podpora pri realizácii prevádzkových zásahov,
• realizácia pravidelných preventívnych zásahov,
• realizácia servisných zásahov (riešenie incidentov) v prípade nefunkčnosti Informačného systému alebo jeho komponentov, služby údržby, konfigurácie, malých zmien a doplnenia ISVS,
• dostupnosť služby pre zapracovanie požiadaviek objednávateľa a analýzu požiadaviek,

7.1Prevádzkové požiadavky

7.1.1Úrovne podpory používateľov

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

• L1 podpory IS (Level 1, priamy kontakt užívateľa) - jednotný kontaktný bod verejného obstarávateľa – Centrum podpory používateľov (zabezpečuje prevádzkovateľ IS a DataCentrum).
  Začiatočná úroveň podpory, ktorá je zodpovedná za riešenie základných problémov a požiadaviek koncových užívateľov a ďalšie služby vyžadujúce základnú úroveň technickej podpory. Základnou funkciou podpory 1. stupňa je zhromaždiť informácie, previesť základnú analýzu a určiť príčinu problému a jeho klasifikáciu. Typicky sú v úrovni L1 riešené priamočiare a jednoduché problémy a základné diagnostiky, overenie dostupnosti jednotlivých vrstiev infraštruktúry (sieťové, operačné, vizualizačné, aplikačné atď.) a základné užívateľské problémy (typicky zabudnutie hesla), overovanie nastavení SW a HW atď.
• L2 a L3 podpory IS (Level 2/3, postúpenie požiadaviek od L1) - na základe zmluvy o podpore IS (zabezpečuje úspešný uchádzač).

Pre služby podpory sú definované takéto SLA:

1. Help Desk je dostupný pre vybrané skupiny užívateľov cez telefón a email, incidenty

Dostupnosť L2/L3 podpory pre IS je 8x5 (8 hodín x 5 dní od 8:00h do 16:00h počas pracovných dní)

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.

Vysvetlivky k tabuľke

(1) Reakčná doba je čas medzi nahlásením incidentu verejným obstarávateľom (vrátane užívateľov IS, ktorí nie sú v pracovnoprávnom vzťahu s verejným obstarávateľom) na helpdesk úrovne L3 a jeho prevzatím na riešenie.

(2) DKVI znamená obnovenie štandardnej prevádzky - čas medzi nahlásením incidentu verejným obstarávateľom a vyriešením incidentu úspešným uchádzačom (do doby, kedy je funkčnosť prostredia znovu obnovená v plnom rozsahu). Doba konečného vyriešenia incidentu od nahlásenia incidentu verejným obstarávateľom (DKVI) sa počíta počas celého dňa. Do tejto doby sa nezarátava čas potrebný na nevyhnutnú súčinnosť verejného obstarávateľa, ak je potrebná pre vyriešenie incidentu. V prípade potreby je úspešný uchádzač oprávnený požadovať od verejného obstarávateľa schválenie riešenia incidentu.

(3) Maximálny počet incidentov za kalendárny mesiac. Každá ďalšia chyba nad stanovený limit spoľahlivosti sa počíta ako začatý deň omeškania bez odstránenia vady alebo incidentu. Duplicitné alebo technicky súvisiace incidenty (zadané v rámci jedného pracovného dňa, počas pracovného času 8 hodín) sú považované ako jeden incident.

(4) Incidenty nahlásené verejným obstarávateľom úspešnému uchádzačovi v rámci testovacieho prostredia majú prioritu 3 a nižšiu

Vzťahujú sa výhradne k dostupnosti testovacieho prostredia. Za incident na testovacom prostredí sa nepovažuje incident vztiahnutý k práve testovanej funkcionalite.

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

• 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ť IS nesmie byť menšia ako 99%, pričom za nedostupnosť nie je považovaný čas plánovanej, vopred ohlásenej a vzájomne odsúhlasenej údržby, výpadky spôsobené zariadeniami tretích strán, nedostupnosť systému v dôsledku prác na základe objednávky/požiadavky Objednávateľa.

Požiadavky na zálohovanie:

Zálohovanie produkčného prostredia prebehne vždy po každej implementovanej a akceptovanej zmene IS prostredníctvom zazálohovania celého virtuálneho servera v ktorom nastala zmena. Záloha musí byť geograficky umiestnená mimo miesta prevádzky serverov.

• Zálohovanie dát uložených na serveroch a najmä v DBMS (SQL databáze) musia byť zálohované automaticky na základe pravidiel nastavených administrátorom minimálne 1 x denne formou prírastkových záloh, min. 2x týždenne plná záloha údajov. Minimálne 1 x týždenne musí byť vykonaná záloha v podobe úplnej zálohy virtualizovaného prostredia.

7.2.2RTO (Recovery Time Objective)

Požadované RTO je 24 hodín.

7.2.3RPO (Recovery Point Objective)

Požadované RPO je 24 hodín.

8.Požiadavky na personál

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 poskytnutému riešeniu 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 - Užívateľská príručka

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

• administrátora systému – rozsah min. 2 dni pre 2 účastníkov
• kľúčových užívateľov – rozsah min. 10 dní 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 Z. z., MIRRI SR o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy 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ť agilne 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.

Akceptácia a akceptačné testovanie 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:

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

10.Prílohy

Bez príloh

• 
  Strana 23/23