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

Účel dokumentu

Tento dokument „Prístup k projektu“ bol vypracovaný v súlade s § 10 vyhlášky č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke.

Jeho účelom je poskytnúť ucelený opis prípravy a realizácie projektu „Zavedenie inteligentného systému zberu a spracovania dát v obci Huncovce“ z pohľadu aktuálneho a budúceho stavu, ako aj navrhovaného riešenia.

Dokument obsahuje:

• architektúru riešenia projektu (biznis, aplikačná, dátová, technologická a infraštruktúrna vrstva),
• opis bezpečnostných aspektov a spracovania údajov,
• návrh na implementáciu, prevádzku a údržbu výstupov projektu,
• ako aj požiadavky na prevádzkové aspekty, dodávku a preberanie riešenia.

Dokument zároveň slúži ako vstup pre ďalšie manažérske výstupy projektu a je súčasťou povinnej projektovej dokumentácie v zmysle platnej legislatívy.

1. Použité skratky a pojmy

Tabuľka 1 Použité skratky

2. Konvencie pre typy požiadaviek (príklady)

V rámci projektu sa budú používať nasledovné konvencie pre označovanie požiadaviek:

• Funkcionálne požiadavky (FR) – požiadavky súvisiace s funkcionalitou riešenia budú označené ako FRxx, kde xx je poradové číslo (napr. FR01: Zariadenie bude schopné počítať prechádzajúce vozidlá).
• Nefunkcionálne požiadavky (NR) – požiadavky vyjadrujúce kvalitatívne alebo výkonové parametre budú označené ako NRxx (napr. NR01: Dostupnosť systému bude min. 95 % ročne).

V prípade potreby budú ďalšie typy požiadaviek (napr. legislatívne, bezpečnostné alebo prevádzkové) označené jednotne v spolupráci s projektovým tímom a objednávateľom.

Konvencie budú uplatnené aj v súvisiacich dokumentoch ako sú Katalóg požiadaviek (I-04) a ďalšia projektová dokumentácia.

3. Popis navrhovaného riešenia

Navrhované riešenie vychádza z výsledkov MCA analýzy v dokumente I-02 Projektový zámer. Predstavuje samostatné IoT riešenie, ktoré slúži na zber, spracovanie a využitie dát pre potreby rozhodovania samosprávy obce Huncovce.

Architektúra riešenia je navrhnutá ako viacvrstvový model, ktorý pozostáva z:

• Technologickej vrstvy: IoT senzory (29 zariadení) umiestnené v 12 lokalitách obce zabezpečujú zber dát o pohybe osôb a vozidiel, cyklistov a vybraných častiach verejného priestoru. Dáta sú prenášané na spracovanie do zabezpečeného prostredia – buď lokálneho alebo cloudového, v závislosti od typu zariadenia a technológie.
• Aplikačnej vrstvy: Softvérový komponent dodávateľa zabezpečuje agregáciu, anonymizáciu, vizualizáciu a export dát vo formáte XML. Výstupy sú sprístupnené prostredníctvom webového rozhrania pre pracovníkov obce a oprávnených používateľov.
• Biznis vrstvy: Výstupy z riešenia slúžia na podporu kvalifikovaného rozhodovania v oblastiach dopravného manažmentu, plánovania investícií, prevencie vzniku čiernych skládok a efektívnej správy verejných priestorov. Prínos riešenia spočíva v možnosti získať relevantné dáta pre strategické aj operatívne rozhodovanie na úrovni obce.

Riešenie je navrhnuté ako samostatný, modulárny a rozšíriteľný systém, ktorý nezasahuje do existujúcich informačných systémov verejnej správy a nevyžaduje migráciu dát. Nie je napojené na centrálne registre ani ISVS.

4. Architektúra riešenia projektu

Architektúra riešenia bola spracovaná v súlade s metodikou MIRRI SR, pomocou modelovacieho jazyka ArchiMate vo verzii 3.1. Projekt nepredstavuje budovanie ani rozvoj ISVS, nevyžaduje migráciu do vládneho cloudu ani integráciu s inými systémami verejnej správy. Riešenie je koncipované ako samostatný IoT systém na zber a spracovanie dát pre potreby rozhodovania samosprávy.

AS IS stav:

Obec Huncovce aktuálne nedisponuje žiadnym systémom na automatizovaný zber a spracovanie dát z verejného priestoru. Rozhodovanie o údržbe, investíciách a bezpečnostných opatreniach sa realizuje výhradne na základe pozorovania v teréne a podnetov od občanov.

TO BE stav:

Navrhované riešenie pozostáva z nasadenia 29 IoT senzorických zariadení v 12 lokalitách obce. Tieto zariadenia budú zabezpečovať zber údajov o pohybe osôb, vozidiel a cyklistov, ako aj o vyťaženosti parkovacích plôch. Cieľom je získavať relevantné informácie o dianí vo verejnom priestore, ktoré umožnia obci kvalifikovane rozhodovať o plánovaných investíciách, dopravných opatreniach a ďalšom rozvoji územia. Získané dáta budú spracované, agregované a exportované vo formáte XML pre ďalšie využitie v rámci analytických a rozhodovacích procesov.

Dáta budú anonymizované, agregované a exportované vo formáte XML. Softvérová platforma zabezpečí vizualizáciu a interpretáciu dát prostredníctvom zabezpečeného webového rozhrania. Výstupy budú slúžiť na podporu rozhodovania samosprávy a zlepšenie plánovania služieb pre občanov.

Architektúra riešenia bola spracovaná ako trojvrstvový model (biznis, aplikačná, technologická) a je súčasťou prílohy tejto dokumentácie vo formátoch PNG a ArchiMate XML.

Realizáciou projektu vzniká nový samostatný eGovernment komponent, ktorý bude sprístupnený v súlade s požiadavkami MetaIS. Nejde o ISVS, ale o podporné analytické riešenie pre zlepšenie rozhodovania a výkonnosti samosprávy. Projekt nebude napojený na centrálne registre ani spoločné moduly.

4.1 Biznis vrstva

4.1.1 AS IS stav

V súčasnom stave je rozhodovanie obce Huncovce založené prevažne na subjektívnom vyhodnocovaní podnetov, skúsenostiach a osobných obhliadkach zo strany starostu alebo poslancov obecného zastupiteľstva. Zber dát o stave územia, pohybe osôb, doprave alebo využívaní verejných priestorov neexistuje. Neexistujú ani digitalizované podporné služby, ktoré by umožnili objektívnu analýzu a zdieľanie relevantných údajov medzi obecnými orgánmi.

• 
  
  1. 
     
     1. 
        
        1. 
           
           1. Identifikované životné situácie (ŽS):
• ŽS 1: Plánovanie drobnej infraštruktúry (napr. priechody pre chodcov, lavičky, osvetlenie)
• ŽS 2: Organizácia komunálnych služieb (údržba komunikácií, vývoz odpadu)
• ŽS 3: Reakcia na podnety občanov (zber návrhov, riešenie problémov)
  1. 
     
     1. 
        
        1. 
           
           1. Koncové služby:

• V súčasnosti nie sú dostupné digitalizované koncové služby.
• Komunikácia prebieha výlučne osobne, telefonicky alebo e-mailom.

• Procesný popis (ŽS: Plánovanie priechodu):
  • 
    
    • 
      
      • Prijatie podnetu od občana
      • Terénna obhliadka starostu (≈ 2 hod.)
      • Diskusia na obecnom zastupiteľstve (≈ 2 týždne)
      • Schvaľovanie návrhu a rozhodnutie
• Optimalizačné príležitosti:

• Zavedenie automatického zberu dát (namiesto obhliadok)
• Zníženie potreby duplicít v podnetoch a subjektívnych rozhodnutí
• Vytvorenie dátového základu pre strategické rozhodovanie

Obrázok 1 – stav AS IS

4.1.2 TO BE stav – budúca biznis architektúra

Projekt predpokladá zavedenie inteligentného systému zberu a spracovania dát (IoT), ktorý bude poskytovať obci výstupy v pravidelných cykloch (napr. mesačne). Tieto údaje budú podkladom pre rozhodovanie v rámci bežnej prevádzky obce. Vďaka dostupným dátam bude môcť obec konať proaktívne a efektívnejšie plánovať investície a zásahy.

• A - Hlavné zmeny:
• Zber, agregácia a export údajov prostredníctvom existujúceho softvéru, pričom výstupy budú sprístupňované v zmysle Prílohy č. 11 výzvy  (štandardy pre integráciu)
• Zavedenie pravidelného dátového výstupu pre vedenie obce
• Rozhodovanie bude podložené agregovanými faktami (nie subjektívnym názorom)

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

Tabuľka 2 Prehľad koncových služieb – TO BE

Všetky koncové služby budú evidované v MetaIS s fázou životného cyklu Plánovaná a budú mať nastavené SLA parametre – cieľová dostupnosť 98,5 %, spoľahlivosť ≤ 1 incident/mesiac.

Proces TO BE (ŽS: Plánovanie priechodu):

• 
  
  • 
    
    • 
      
      • Automatizovaný zber údajov cez IoT senzory
      • Agregácia a export dát do pravidelných výstupov
      • Zobrazenie trendov cez rozhranie pre vedenie obce
      • Rozhodnutie na úrovni OZ alebo starostu

• Očakávané metriky TO BE:

Tabuľka 3 Očakávané metriky

• Porovnanie AS IS a TO BE

Tabuľka 4 Porovnanie AS IS a TO BE

Nasledujúci diagram zobrazuje stav biznis vrstvy architektúry po realizácii projektu (TO BE):

• Aktér (koncový používateľ):

• Business Actor: Obec Huncovce
  → predstavuje vedenie obce, ktoré využíva výstupy systému na podporu rozhodovania.
• Biznis proces:

• Business Process: Rozhodovanie na základe dát
  → nový, dátami podložený proces, ktorý nahrádza predchádzajúce manuálne a subjektívne rozhodovanie.
• Koncová služba:

• Business Object: Agregované dáta o mobilite, priestore a podnetoch
  → reprezentuje interný výstup systému, ktorý slúži ako podklad pre rozhodovanie.
  → Je to výstup dátového spracovania – nie je priamo verejná služba, ale podkladová.

• Vzťahy medzi prvkami:

• Obec Huncovce realizuje proces Rozhodovanie na základe dát
• Proces využíva objekt Agregované dáta, ktoré pochádzajú zo spracovania výstupov systému
• Ide o interný proces podporený technológiou a aplikáciami, ktoré sú modelované v nižších vrstvách

• Záver:

Tento model zobrazuje jednoduchý, ale účinný biznis pohľad:

• jeden aktér (obec),
• jeden proces (rozhodovanie),
• a jeho podkladový výstup (agregované dáta).

Model je v súlade s cieľom projektu – umožniť obci prijímať rozhodnutia založené na skutočných údajoch.

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

• 
  
  • 
    
    • Jazyková podpora a lokalizácia
• Systém na zber a spracovanie dát v navrhovanom riešení neobsahuje používateľské rozhranie určené pre verejnosť, ale slúži ako interný analytický nástroj pre potreby obce. Výstupy systému budú poskytované vo forme agregovaných dátových exportov (napr. XML, CSV, prehľadové reporty), ktoré budú slúžiť ako podklad pre rozhodovanie vedenia obce.
• Z tohto dôvodu sa nepredpokladá potreba lokalizácie používateľského rozhrania do viacerých jazykov.
• V prípade, že v budúcnosti vznikne potreba zdieľať výstupy systému smerom k verejnosti (napr. cez webové dashboardy), bude jazyková podpora riešená v nadväzujúcich projektoch alebo úpravou výstupnej vrstvy (napr. dvojjazyčné prehľady SK/EN).

5. Aplikačná vrstva

• AS IS stav – aplikačná vrstva

Popis:
V súčasnosti obec Huncovce nemá vybudovaný žiadny informačný systém, ktorý by podporoval rozhodovanie na základe dát zo senzorických zariadení. Nie je evidovaný žiadny samostatný ISVS ani aplikačný modul, ktorý by plnil túto funkciu. Zber dát z územia obce sa realizuje prevažne manuálne – pozorovaním, obhliadkami a neformálnymi hláseniami od občanov.

Aplikačné komponenty:

• Neexistujúce – AS IS stav predstavuje nulový stav aplikačnej architektúry v predmetnej oblasti.
• Neexistuje ani aplikačná služba na podporu rozhodovania, analytiky ani automatizovaného spracovania údajov.

• TO BE stav – aplikačná vrstva

Popis:
Projektom sa vytvorí jednoduchý aplikovaný komponent – Systém na zber a spracovanie dát, ktorý bude samostatným riešením obce. Tento komponent bude:

• agregovať údaje zo senzorických zariadení (kamery ako senzory)
• exportovať ich vo formáte XML na účely reportingu a rozhodovania
• dáta budú anonymizované a agregované, systém nebude identifikovať osoby

Vzťahy na biznis architektúru:

• Aplikačný komponent podporuje biznis službu: Rozhodovanie na základe dát o stave verejného priestoru
• Prepája sa s aktérmi: vedenie obce, technické služby, investičný pracovník

Aplikačné komponenty a služby (Archimate pojmy):

• Application Component: Systém na zber a spracovanie dát
• Application Function: Agregácia, anonymizácia, export dát
• Application Interface: Užívateľské rozhranie pre export/report (napr. XML súbory)
• Application Service: Podpora rozhodovania o údržbe, bezpečnosti a investíciách

Vzťah na externé prostredie:

• V tejto fáze projekt nemá integrácie na centrálne ISVS ani moduly eGov
• Možný budúci rozvoj (napr. prepojenie na UVO, GIS systémy) nie je súčasťou tohto projektu

Obrázok 3 Model aplikačnej architektúry – TO BE

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

Obec Huncovce v súčasnosti nedisponuje ISVS, ktorý by zabezpečoval zber a spracovanie údajov z prostredia obce

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

Tabuľka 5 Rozsah informačných systémov TO BE

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

Obec Huncovce v súčasnosti nevyužíva žiadne nadrezortné ani spoločné ISVS podľa zákona č. 305/2013 Z. z.

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

V rámci realizácie projektu nie sú plánované integrácie na nadrezortné ISVS ani spoločné moduly podľa zákona č. 305/2013 Z. z. Riešenie funguje ako samostatný systém pre zber dát a lokálnu podporu rozhodovania bez väzby na centrálne systémy.

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

Projekt nepočíta s využívaním služieb iných ISVS ani integráciou na externé ISVS. Navrhované riešenie je samostatné a nespolieha sa na výmenu údajov so systémami tretích strán.

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

V rámci projektu nebude budovaný nový ISVS evidovaný v MetaIS, preto tabuľka nie je vyplnená.
Navrhované riešenie tvorí samostatný aplikačný systém obce Huncovce na zber a spracovanie dát (IoT zariadenia, lokálny systém). Tento systém poskytuje aplikačné služby na podporu rozhodovania, avšak nepredstavuje ISVS v zmysle zákona o e-Governmente.

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

V rámci projektu nebude vytvorený nový ISVS ani budované aplikačné služby integrované s externými ISVS alebo spoločnými modulmi podľa zákona č. 305/2013 Z. z.
Riešenie funguje ako lokálny informačný systém obce a nevyužíva centrálne komponenty e-Governmentu (napr. CAMP, elektronické formuláre, autentifikáciu používateľov).
Integrácia s tretími stranami alebo SaaS službami nie je v tomto projekte plánovaná.

• 
  
  • 
    
    • Poskytovanie údajov z ISVS do IS CSRÚ – TO BE a Konzumovanie údajov z IS CSRU – TO BE

Projekt nebude poskytovať ani konzumovať údaje z/do IS CSRÚ.
Riešenie je navrhnuté ako samostatne fungujúci systém v rámci obce a nevyžaduje výmenu referenčných údajov so štátnymi registrami.
Všetky dáta sú spracovávané v rámci miestneho systému na úrovni obce a nemajú väzbu na objekty evidencie evidované v CSRÚ.

6. Dátová vrstva

6.1 Údaje v správe organizácie – AS IS

Obec Huncovce dnes neprevádzkuje žiadny informačný systém, ktorý by evidoval údaje o mobilite, vyťaženosti verejných priestranstiev či incidentoch. Údaje vznikajú ad-hoc (vizuálne kontroly, podnety občanov) a nie sú zhromažďované v strojovo-spracovateľnej podobe.

• Dátová architektúra: neexistuje; k objektom evidencie (OE) ani vzťahom medzi nimi nie je vytvorený logický model.
• Riadenie životného cyklu údajov: procesy vytvárania, validácie, ukladania a archivácie dát nie sú zavedené; v organizácii absentuje rola dátového kurátora.
• Manažment údajov: neformalizovaný, nevykonáva sa systematické zálohovanie ani kontrola kvality údajov.

• 6.2 Údaje v správe organizácie – TO BE

Projekt zavádza samostatný lokálny systém na zber a spracovanie dát (IoT senzory → aplikačný komponent). Údaje budú anonymizované, agregované a exportované vo formáte XML/CSV.

.

Tabuľka 5 To BE opatrenia

• 
  
  • 
    
    • i. Dátový rozsah projektu - Prehľad objektov evidencie - TO BE

Tabuľka 6 Dátový rozsah

Obrázok 4 Zjednodušený doménový model

• Proces riadenia dát

1. Zber – IoT zariadenia odosielajú záznamy každú minútu.
2. Validácia – služba kontroluje formát, duplicity, rozsahy.
3. Ukladanie – surové dáta v lokálnej DB (30 dní); agregácie v tabuľke AggregatedStatistic.
4. Export – mesačne sa generuje XML/CSV do adresára \\DataExports\YYYY-MM.
5. Archivácia – agregované súbory sa zálohujú na externé úložisko (3 roky).
6. Kvalita – dátový kurátor kvartálne vyhodnotí chybovosť, v prípade odchýlok aktualizuje metodiku.

Tabuľka 7 Roly  a zodpovednosti

Poznámka k CSRÚ a referenčným údajom

Projekt nevytvára ani nekonzumuje referenčné údaje (CSRÚ). V budúcnosti je možné vyhlásiť štatistické agregáty za otvorené údaje (úroveň 3★) – bude riešené samostatným rozvojovým projektom.

• 
  
  • 
    
    • i. Referenčné údaje

Projekt „IoT systém na zber a spracovanie dát pre obec Huncovce“:

• nepracuje s údajmi, ktoré by sa v zmysle § 3 písm. f) zákona č. 95/2019 Z. z. kvalifikovali ako -referenčné údaje,
• nevyužíva žiadne existujúce referenčné registre (napr. RFO, RPO, RPI) a nepredpokladá zdieľanie údajov s IS CSRÚ,
• vytvára výlučne lokálne štatistické záznamy o pohybe osôb, vozidiel a vyťaženosti verejných priestranstiev; tieto dáta nie sú jedinečné k subjektom evidencie a nie sú určené na ich úradné preukazovanie.

• a) Kvalita údajov v zdrojových registroch

Nevzťahuje sa – projekt nepoužíva referenčné registre ani nevytvára nové registre.

• b) Dôvod pre nevyhlasovanie referenčných údajov

• Zaznamenávané počty osôb či vozidiel nie sú viazané na konkrétny právny subjekt; nemajú charakter identifikačných údajov, ktorých správnosť by sa predpokladala zo zákona.
• Údaje slúžia výlučne na interné rozhodovanie obce a nepredkladajú sa iným orgánom verejnej moci.
• c) Poskytovatelia/konzumenti v CSRU

Nepredpokladá sa – projekt nevstupuje do dátových tokov Modulu procesnej integrácie a integrácie údajov (IS CSRÚ).

• d) Legislatíva a procesy

Neaplikuje sa: projekt nemení legislatívne povinnosti občanov/podnikateľov, keďže nevyžaduje žiadne podania ani výpisy; údaje sú generované plne automaticky obcou.

• e) Návrh na vyhlásenie referenčných údajov – Tabuľka sa nevyplňuje

V rámci realizácie projektu sa nedefinujú objekty evidencie určené na vyhlásenie za referenčné. Tabuľka ostáva prázdna.

Zhrnutie: Vzhľadom na charakter zozbieraných dát (anonymné agregované štatistiky) a lokálne využitie, projekt nepredpokladá vyhlásenie nových referenčných údajov ani zapojenie sa do centrálnej platformy dátovej integrácie.

• 
  
  • 
    
    • ii. Kvalita a čistenie údajov

1. 
   
   1. 
      
      1. 
         
         1. Zhodnotenie objektov evidencie z pohľadu dátovej kvality

Projekt realizuje zber štruktúrovaných údajov pomocou senzorických zariadení (IoT kamery ako senzory). Tieto údaje budú slúžiť na podporu rozhodovania v oblasti správy verejných priestorov, mobility a plánovania infraštruktúry, napríklad vyhodnocovanie vyťaženosti cyklotrás, frekvencie prejazdov vozidiel alebo pohybu osôb v určených lokalitách.

Hoci údaje neobsahujú osobné identifikátory a sú anonymné, ich správnosť, úplnosť a konzistentnosť sú kľúčové pre zabezpečenie ich využiteľnosti v rozhodovacích procesoch. Projekt preto implementuje základné opatrenia pre kvalitu údajov vrátane validácie vstupov, kontroly duplicít a kontroly logickej konzistencie (napr. časové a priestorové súvislosti záznamov).

Tabuľka 8 Kvalita a čistenie údajov

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

Tabuľka 9 Kvalita a čistenie údajov

• 
  
  • 
    
    • iii. Otvorené údaje

V rámci realizácie projektu budú vybrané údaje zozbierané prostredníctvom IoT senzorov sprístupnené ako otvorené údaje v súlade s požiadavkami vyhlášky č. 78/2020 Z. z. Zverejňované budú najmä údaje o vyťaženosti cyklotrás, počtoch pohybujúcich sa osôb a vozidiel vo vybraných lokalitách. Údaje budú publikované v štandardizovanom formáte (napr. CSV, JSON) s interoperabilitou úrovne 3★ a budú aktualizované v mesačnej periodicite. Cieľom je umožniť verejnosti, odborníkom a samospráve lepšie porozumieť využívaniu verejného priestoru a podporiť dátovo podložené rozhodovanie.

Tabuľka 10 Objekty evidencie, ktoré budú sprístupnené ako otvorené údaje

• 
  
  • 
    
    • iv. Analytické údaje

V rámci projektu budú vybrané objekty evidencie spracované aj na analytické účely. Cieľom je podporiť dátovo podložené rozhodovanie samosprávy, zlepšiť plánovanie služieb a infraštruktúry a identifikovať využívanie verejného priestoru. Analytické výstupy budú zamerané najmä na pohyb osôb a vozidiel vo verejnom priestore. Údaje budú spracovávané v súlade s princípmi pseudonymizácie a anonymizácie, aby bola zachovaná ochrana osobných údajov. Rozsah údajov bude prispôsobený potrebám verejného rozhodovania, pričom atribúty budú navrhnuté tak, aby ich bolo možné využiť aj pre ďalšie analytické aktivity v rámci verejnej správy.

Tabuľka 11 Objekty evidencie, ktoré budú projektom pripravené pre analytické účely

• 
  
  • 
    
    • v. Moje údaje

Projekt neuchováva údaje viazané na konkrétne fyzické alebo právnické osoby, ktoré by spadali pod definíciu „Mojich údajov“ podľa § 17 zákona č. 305/2013 Z. z. o e-Governmente.

Zberané a spracovávané údaje sú anonymizované, určené výhradne na účely plánovania, rozhodovania a optimalizácie verejných služieb obce. Údaje nemajú väzbu na konkrétne osoby, nie sú súčasťou individuálnych konaní, a nie sú prístupné subjektom údajov v zmysle služby Moje údaje.

7. Technologická vrstva

• 
  
  • 
    
    • i. Prehľad technologického stavu - AS IS

AS IS stav:
Obec v súčasnosti nedisponuje technologickou infraštruktúrou na zber, ukladanie a analýzu dát z verejných priestorov. Neexistuje serverová infraštruktúra určená pre takéto účely, ani komunikačné prepojenia pre IoT zariadenia. Výpočtové prostriedky obce slúžia len na základné administratívne úlohy.

TO BE stav:
Projekt navrhuje vybudovanie samostatnej technologickej vrstvy podporujúcej zber a spracovanie dát z verejného priestoru obce. Riešenie bude založené na fyzických senzorických zariadeniach pripojených do obecnej siete (optickej a WiFi), ktoré budú odosielať štruktúrované výstupy do lokálneho úložiska.

Hlavné prvky budúceho stavu:

• Zberové zariadenia (senzory s analytickou funkcionalitou) umiestnené v teréne
• Komunikačné prepojenia: primárne optická sieť, doplnkovo WiFi pripojenie podľa lokality
• Lokálny server zabezpečujúci ukladanie výstupov, inštalovaný v rámci obecného úradu
• Prístup k výstupom bude možný cez webové rozhranie obce (zabezpečí si obec), pričom výstupy budú exportované v štruktúrovanom formáte
• Prevádzkové prostredie:
  • Vývojové a testovacie prostredie nebude samostatne zriadené – riešenie bude nasadené priamo ako produkčné, vzhľadom na rozsah a typ projektu
  • Produkčné prostredie bude tvoriť obecný server s potrebným softvérom, zálohovaním a monitorovaním prevádzky

Architektonické rozhodnutia:

• Riešenie bude lokálne hostované, nezávislé od prostredia vládneho cloudu.
• Nevyužitie cloudových služieb je zdôvodnené tým, že ide o jednoduché a samostatne prevádzkované IoT riešenie, ktoré si nevyžaduje škálovanie, vysokú dostupnosť ani služby IaaS, PaaS či SaaS z katalógu vládneho cloudu.
• Systém však technicky umožňuje budúcu integráciu alebo presun do cloudového prostredia, ak sa obec rozhodne rozvíjať svoje digitálne služby.

Prepojenie na aplikačnú vrstvu:
Dáta zo senzorických zariadení budú odosielané do lokálneho úložiska, ktoré tvorí základnú infraštruktúru pre ďalšie spracovanie, export do externých rozhraní a vizualizáciu.

Obrázok 5 Technologická vrstva

• 
  
  • 
    
    • ii. Požiadavky na výkonnostné parametre, kapacitné požiadavky – TO BE

Tabuľka 12 Požiadavky na výkonnostné parametre, kapacitné požiadavky TO BE

• 
  
  • 
    
    • iii. Návrh riešenia technologickej architektúry

Tabuľka 13  Návrh riešenia technologickej architektúry

Tabuľka 14 Návrh riešenia technologickej architektúry

Licencie:

• Axxon One Edge licence – 29 kanálov (trvalá)
• Docker CE – open-source
• PostgreSQL 16 – open-source
• Windows 11 Pro (server HW)

Technologická architektúra vedome kombinuje lokálne nasadenie s cloud-ready kontajnerizáciou. To dáva obci:

• nízke prevádzkové náklady (žiadne mesačné poplatky za IaaS),
• plnú kontrolu nad dátami,
• možnosť budúcej migrácie do vládneho cloudu bez nutnosti refaktoringu kódu.

Tým sú naplnené odporúčania NKIVS aj požiadavka vyhlášky 401/2023 Z. z. na moderné, rozšíriteľné a štandardizované IKT riešenia.

Obrázok 6 Návrh technologickej architektúry

• 
  
  • 
    
    • iv. Využívanie služieb z katalógu služieb vládneho cloudu

V rámci tohto projektu nie je plánované využitie služieb z katalógu služieb vládneho cloudu. Dôvodom je, že riešenie nepredstavuje nový ISVS ani sa neintegruje do existujúcich ISVS. Projekt využíva lokálnu infraštruktúru obce

Obrázok 7 Model stavu TO BE (archimate)

8. Bezpečnostná architektúra+

AS IS stav

Tabuľka 15 Bezpečnostná architektúra AS IS

TO BE – cieľový stav
 

Tabuľka 16  Bezpečnostná architektúra TO BE

Súlad s legislatívou a štandardami
 

Tabuľka 17  Súlad s legislatívou a štandardami

Postupy na zabezpečenie dôvernosti, integrity a dostupnosti (CIA)

Tabuľka 18   Postupy na zabezpečenie dôvernosti, integrity a dostupnosti

Bezpečnostný projekt:
Vzhľadom na rozšírenie IT infraštruktúry obce o nové IoT komponenty, edge computing zariadenia a zabezpečený prenos dát, bude existujúci bezpečnostný projekt aktualizovaný.

Cieľom je zabezpečiť, že všetky nové technologické aktíva a súvisiace procesy budú zaradené do systému riadenia bezpečnosti v súlade so zákonom č. 69/2018 Z. z., vyhláškou č. 179/2020 Z. z. a nariadením GDPR.

Aktualizáciu BP zabezpečí externý zmluvný partner obce (aktuálne spoločnosť Osobnyudaj.sk), ktorý už garantuje správu súčasného bezpečnostného projektu a výkon zodpovednej osoby (DPO).

Role a správa prístupov

Tabuľka 19    Role a správa prístupov

Autentifikácia:

• SSH kľúče + 2FA (TOTP) pre externé prístupy.
• Interná sieť – LAN prístup chránený port-security (MAC whitelisting) a 802.1X.

9. Závislosti na ostatné ISVS / projekty

Projekt nevytvára nový informačný systém verejnej správy (ISVS) ani nerozširuje existujúci ISVS iným spôsobom ako formálnym priradením k webovej stránke obce, ktorá je vedená v MetaIS ako ISVS.
Projekt je implementovaný ako samostatné riešenie zamerané na zber a spracovanie dát pomocou IoT senzorov a je plne funkčný bez integrácie s inými komponentmi e-Governmentu alebo externými ISVS.
Neexistujú ani technologické alebo procesné väzby na iné prebiehajúce alebo plánované projekty financované z verejných zdrojov.

10. Zdrojové kódy

Projekt nepočíta s vývojom vlastného aplikačného softvéru, ktorý by podliehal povinnosti dodania zdrojových kódov v zmysle § 15 písm. d) zákona č. 95/2019 Z.z.

Nasadzované riešenie využíva štandardné softvérové komponenty (napr. webové rozhranie, analytické nástroje) dodávané ako súčasť hardvérového riešenia (IoT kamery ako senzory).

Obec Huncovce bude požadovať:

• plnú prevádzkovú dokumentáciu dodaného riešenia,
• licencie potrebné na používanie a správu systému,
• zmluvné ošetrenie práva na zmenu dodávateľa bez technologickej alebo licenčnej závislosti (predchádzanie vendor lock-in).

Ustanovenia o právach k softvérovým komponentom a dokumentácii budú súčasťou Zmluvy o dielo a SLA zmluvy s dodávateľom.

11. Prevádzka a údržba

AS-IS stav:

V súčasnosti obec Huncovce nezabezpečuje prevádzku obdobného systému. Správa IT infraštruktúry obce je vykonávaná externou odbornou osobou na ad hoc báze, vrátane evidencie porúch. Obec nemá zavedený systém manažmentu služieb podpory (napr. helpdesk), úroveň poskytovaných služieb (SLA) nie je formálne definovaná. Neexistuje ani centralizovaná evidencia technických komponentov alebo štandardizovaný postup obnovy dát po výpadku.

TO-BE stav:

Po realizácii projektu bude systém prevádzkovaný v modely, ktorý zohľadní rozsah dodaného riešenia, technické možnosti obce a dostupné finančné zdroje. Predpokladá sa, že správa systému bude zabezpečená kombináciou interných kapacít obce a externej podpory formou servisnej zmluvy (SLA) s dodávateľom riešenia. Úroveň poskytovaných služieb vrátane dostupnosti systému, času reakcie na incidenty a obnovy dát bude definovaná v rámci tejto zmluvy.

Funkčnosť zariadení bude priebežne monitorovaná zo strany povereného zamestnanca obce, ktorý bude zároveň koordinovať technickú podporu. Predpokladá sa nasadenie 29 zariadení (IoT senzorov) vo viacerých lokalitách v správe obce. V prípade poruchy bude riešenie zabezpečené cez kontaktovanie externého správcu.

Zálohovanie tabuľkových výstupov z dát bude zabezpečené obcou, videodáta sa nebudú zálohovať. Obnova systému a dát po výpadku bude predmetom SLA. Helpdesk systém pre používateľov sa nepredpokladá, keďže výstupy budú primárne slúžiť interne pre rozhodovanie vedenia obce.

Systém manažmentu služieb:

Obec aktuálne nevyužíva samostatný informačný systém pre manažment služieb podpory. V súčasnosti sa neplánuje ani jeho nasadenie, keďže rozsah podporovaných služieb nevyžaduje plnohodnotný ticketovací systém.

Požiadavky na prevádzku a údržbu cieľového riešenia:

• Zabezpečenie technickej správy systému externým partnerom alebo kombinovaným modelom s obcou
• Základná evidencia incidentov a porúch (napr. v podobe záznamov vedených správcom)
• Zmluvne dohodnuté SLA parametre pre reakčný čas a opravu
• Priebežné monitorovanie funkčnosti zo strany obce
• Pravidelné ukladanie dátových výstupov vo forme open data
• Možnosť obnovy systému a dát po výpadku
• Kapacitná pripravenosť na správu ~29 zariadení rozmiestnených v teréne

• 
  
  • 
    
    • i. Prevádzkové požiadavky

Podpora používateľov a prevádzky systému bude zabezpečená kombináciou interných kapacít obce a externého dodávateľa, s cieľom zabezpečiť základnú prevádzkovú stabilitu, rýchlu reakciu na incidenty a odborné riešenie technických problémov.

Podpora L1 (1. úroveň):
Základná podpora bude realizovaná priamo povereným zamestnancom obce alebo externým IT správcom, ktorý aktuálne spravuje infraštruktúru obce. Ten bude zodpovedný za kontrolu funkčnosti zariadení (napr. prístup k dátam, kontrola výpadkov, základné nastavenia), a tiež za evidenciu incidentov. Podpora L1 bude fungovať ad hoc formou bez jednotného kontaktného miesta (helpdesku), vzhľadom na jednoduchý charakter systému a obmedzený okruh používateľov.

Podpora L2 (2. úroveň):
V prípade potreby eskalácie incidentu (napr. výpadky systému, poruchy zariadení, straty dát), bude problém postúpený technickému tímu externého dodávateľa, ktorý bude mať na základe servisnej zmluvy (SLA) povinnosť diagnostikovať problém, identifikovať jeho príčinu a vykonať potrebné opatrenia na jeho vyriešenie. Táto úroveň nebude komunikovať priamo s používateľmi, ale s pracovníkom obce zodpovedným za prevádzku systému.

Podpora L3 (3. úroveň):
Najzložitejšie problémy, ktoré si vyžadujú zásah do architektúry systému, špecifické aktualizácie softvéru alebo hĺbkovú analýzu dát, budú riešené na tretej úrovni podpory dodávateľom riešenia alebo jeho technologickým partnerom. Podmienky podpory L3 budú definované v SLA a súvisia s garanciami obnovy funkčnosti systému a dostupnosti odborných kapacít.

Podpora infraštruktúrnych služieb:
Prevádzka systému bude postavená na technickej infraštruktúre obce, ktorá zahŕňa stabilné internetové pripojenie, server na ukladanie dát a existujúcu sieťovú infraštruktúru. Zodpovednosť za základnú prevádzku týchto služieb nesie obec prostredníctvom svojho IT správcu. Cloudové služby sa aktuálne neplánujú využívať. Spôsob komunikácie s poskytovateľmi služieb (napr. internetové pripojenie) zostáva v zodpovednosti obce, podobne ako pri iných bežne využívaných systémoch.

• 
  
  • 
    
    • ii. Úrovne podpory používateľov

zodpovednosti obce, podobne ako pri iných bežne využívaných systémoch.

Tabuľka 20    Úrovne podpory používateľov

• 
  
  • 
    
    • iii. Riešenie incidentov – SLA parametre

Parametre služby riešenia incidentov v prevádzke sú špecifikované na základe určenia priority incidentu pomocou kombinácie jeho naliehavosti a dopadu podľa najlepších skúseností z praxe (best practice) z oblasti manažmentu IT služieb (  Information Technology Infrastructure Library - ITIL V3) nasledovným spôsobom:

Incident - za incident je považovaná každá nahlásená alebo inak zistená relevantná skutočnosť týkajúca sa aktíva (informačného systému) alebo jeho časti, ktorého nedostupnosť alebo nefunkčnosť má vplyv na poskytovanie služieb.

Tabuľka 21  Klasifikácia Naliehavosti incidentu

Tabuľka 22 Klasifikácia Závažnosti incidentu

Určenie priority incidentu je kombináciou dopadu a naliehavosti podľa nasledovnej matice:

Tabuľka 23  Určenie priority incidentu

Parametre služby Riešenia incidentov v prevádzke:

Tabuľka 24 Parametre služby Riešenia incidentov v prevádzke

Vysvetlivky k tabuľke

1. Reakčná doba – čas medzi nahlásením incidentu verejným obstarávateľom na helpdesk úrovne L3 a jeho prevzatím na riešenie.
2. DKVI (Doba konečného vyriešenia incidentu) – čas od nahlásenia incidentu po obnovenie plnej funkčnosti prostredia; do DKVI sa nezapočítava čas potrebný na nevyhnutnú súčinnosť verejného obstarávateľa.
3. Spoľahlivosť – maximálny počet incidentov danej priority za kalendárny mesiac; každá ďalšia chyba nad limit sa počíta ako začatý deň omeškania. Duplicitné alebo technicky súvisiace incidenty zadané v rámci jedného pracovného dňa (8 h) sa považujú za jeden incident.
4. Incidenty nahlásené v testovacom prostredí majú prioritu 3 alebo nižšiu a vzťahujú sa len na dostupnosť tohto prostredia.

Poznámka: Uvedené SLA parametre sa nevzťahujú na:

• 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 úprav (nad paušál).
  Pre tieto služby budú dohodnuté osobitné parametre dodávky.

1. 
   
   1. Požadovaná dostupnosť IS:

Tabuľka 25     Požadovaná dostupnosť

12. Požiadavky na personál

Z hľadiska prevádzky budovaného systému (TO BE) bude zabezpečenie prevádzkových činností realizované kombináciou interných kapacít obce a externého dodávateľa technickej podpory (formou SLA zmluvy). Vzhľadom na rozsah projektu a neexistenciu samostatného IT oddelenia obec plánuje nasledovné rozdelenie zodpovedností:

• Interné kapacity obce:
• 1 pracovník poverený správou dát (napr. referent správy majetku alebo pracovník stavebného úradu), ktorý bude oprávnený pristupovať k analytickému nástroju, interpretovať výstupy a podávať návrhy rozhodnutí vedeniu obce.
• 1 pracovník s kompetenciou nahlasovať incidenty a komunikovať s technickou podporou (napr. zamestnanec obecného úradu, prípadne administratívny pracovník poverený touto agendou).
• Externý dodávateľ (cez SLA zmluvu):

• technická podpora 2. a 3. úrovne (L2, L3) pre správu systému, riešenie incidentov, aktualizáciu softvéru, údržbu a prípadné opravy.
• dohľad nad funkčnosťou systému a zabezpečenie súladu s požadovanými SLA parametrami.

• Požiadavky na školenia a certifikáty:
• Používatelia (interní pracovníci obce):

• zaškolenie v oblasti čítania a interpretácie dát zo systému (napr. počty pohybov, dopravná záťaž, monitoring zón),
• školenie pre nahlasovanie incidentov cez helpdesk,
• základné oboznámenie s ochranou osobných údajov (ak sa spracúvajú pseudonymizované dáta alebo metaúdaje).

• Pracovníci podpory a prevádzky (externý dodávateľ):

• dodávateľ preukáže odbornú spôsobilosť prostredníctvom referencií a interných kvalifikácií,
• nie je požadované formálne certifikovanie (napr. ISO), ale musí byť schopný garantovať požadované úrovne SLA.

.

13. Implementácia a preberanie výstupov projektu

Vzhľadom na charakter projektu, ktorého hlavným predmetom je dodanie a inštalácia IoT zariadení  a nasadenie edge computing technológie, obec zvolila metódu realizácie typu waterfall s prvkami metódy agile.

Tento prístup umožňuje:

• jasne definovať fázy projektu (príprava, implementácia, testovanie, nasadenie),
• zároveň však ponecháva priestor na inkrementálne nasadzovanie jednotlivých lokalít (napr. testovacie nasadenie v jednej lokalite a následná optimalizácia pred plošným nasadením).

V súlade s vyhláškou č. 401/2023 Z. z. obec posúdila možnosť realizácie prostredníctvom inkrementov, pričom navrhované riešenie je technicky rozdeliteľné do logických celkov podľa lokalít alebo typov analyzovaných dát (napr. mobilita, monitoring skládok, pohyb v noci).

Každý inkrement bude obsahovať:

• fázu implementácie (montáž zariadení, konfigurácia softvéru),
• testovanie funkčnosti a dátového toku,
• nasadenie do produkcie (súborový export, úložisko, zálohovanie).

Týmto prístupom bude umožnené:

• priebežné overovanie funkcionality a spätnej väzby zo strany používateľov (interní zamestnanci obce),
• zníženie rizika zlyhania celého projektu,
• flexibilné dolaďovanie nastavení v ďalších častiach obce.

Z dôvodu, že projekt neobsahuje vývoj informačných systémov ISVS ani integráciu na iné centrálne systémy (napr. vládny cloud), ale ide o nasadenie samostatnej technickej infraštruktúry, je realizácia po inkrementoch technicky uskutočniteľná a zároveň organizačne výhodná.

Dopad na harmonogram:

• Harmonogram bude členený na sériu čiastkových nasadení, ktoré umožňujú paralelné práce v jednotlivých lokalitách,
• Preberanie výstupov sa bude realizovať priebežne po otestovaní funkčnosti v danej lokalite,
• Záverečné overenie bude zamerané na súlad so špecifikovaným rozsahom dát a funkcionalít.

14. Prílohy

• 
  
  • 
    
    • Bez príloh