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 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, prevádzku a údržbu výstupov projektu, prevádzkové požiadavky, požiadavky na zdrojové kódy. Dodávané riešenie musí byť v súlade s platnou legislatívou. Zároveň opisuje aj implementáciu projektu a preberanie výstupov projektu.

2.1Použité skratky a pojmy

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

V rámci projektu budú definované tri základné typy požiadaviek:

Funkčné (používateľské) požiadavky majú nasledovnú konvenciu:

     Fxx

          F    – funkčná požiadavka

          xx   – číslo požiadavky

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

     Nxx

          N   – nefunkčná požiadavka (NFR)

          xx   – číslo požiadavky

Technické požiadavky majú nasledovnú konvenciu:

     Txx

          T    – technická požiadavka

          xx   – číslo požiadavky

3. POPIS NAVRHOVANÉHO RIEŠENIA

Projekt je realizovaný na základe výzvy: „Podpora rozvoja tvorby, spracovania, využívania a prepájania dát v rámci verejnej správy pre inteligentné rozhodovanie, plánovanie a správu“, kód výzvy: PSK-MIRRI-619-2024-ITI-EFRR (ďalej len „Výzva“).

Projekt sa bude venovať nasledovným prioritám v rámci Programu Slovensko:

Priorita: 1P1 Veda, výskum a inovácie

Špecifický cieľ: RSO1.2 Využívanie prínosov digitalizácie pre občanov, podniky, výskumné organizácie a orgány verejnej správy

Opatrenie: 1.2.2. Podpora budovania inteligentných miest a regiónov

Priorita: 5P1 Moderné regióny

Špecifický cieľ: RSO 5.1 Podpora integrovaného a inkluzívneho sociálneho, hospodárskeho a environmentálneho rozvoja, kultúry, prírodného dedičstva, udržateľného cestovného ruchu a bezpečnosti v mestských oblastiach

Opatrenie: 5.1.3 Investície do bezpečného fyzického prostredia obcí, miest a regiónov

Projekt sleduje nasledovné ciele na základe poskytnutých finančných prostriedkov z výzvy:

1. Zabezpečenie rozvoja mesta prostredníctvom implementácie inovatívnych technologických a netechnologických riešení a inteligentného riadenia v rámci podpory rozvoja tvorby, spracovania, využívania a prepájania dát v rámci verejnej správy, najmä rozvoja dátových platforiem, využívania priestorových a otvorených dát a súvisiacich nástrojov s pridanou hodnotou pre inteligentné rozhodovanie a správu mesta, proaktívnych elektronických služieb, ako aj poskytovanie služieb občanom a podnikateľom, vrátane získavania poznatkov o aktuálnom stave dostupnosti a využívania dát v rámci verejnej správy, budovania špecifických kapacít a infraštruktúry.
2. Dosiahnuť podstatné zlepšenie kvality života všetkých občanov, a to prostredníctvom systémových riešení, racionalizáciou a zefektívnením agendy inteligentného rozvoja miest a regiónov v podmienkach SR v súlade aj s Akčným plánom inteligentných miest a regiónov na roky 2023 – 2026, ktorý bol schválený uznesením vlády SR č. 310 z 12. júna 2023.
3. Budovanie infraštruktúry opatrení na predchádzanie problémových javov a napätia, zabezpečenie verejného poriadku, ochrany zdravia a majetku v obciach a regiónoch prostredníctvom podpory aktivít subjektov územnej samosprávy

Realizácia projektu bude pozostávať z dodávky štyroch samostatných celkov, ktoré sa navzájom dopĺňajú a v čase na seba nadväzujú. Ide o nasledovné 4 celky:

1. Analýza dátových zdrojov pre inteligentné systémy mesta Žilina umiestnených na sieti verejného osvetlenia

2. Optické senzory a bezpečnostné kamery

3. Inteligentné senzory

4. Analytický informačný systém na podporu riadenia samosprávnych procesov

1. Analýza dátových zdrojov pre inteligentné systémy mesta Žilina umiestnených na sieti verejného osvetlenia

Opis súčasného stavu

Mesto Žilina je prevádzkovateľom verejného osvetlenia, ktoré je pripojené na tzv. zdroj trvalého napájania. V praxi to znamená, že elektrická energia v sieti trvalého napájania nie je spustená iba v čase, kedy sú zdroje verejného osvetlenia zapnuté, ale počas celého dňa. Tento prístup o.i. umožňuje využívať verejné osvetlenie aj v čase mimoriadnych svetelných podmienok (napríklad počas búrky) a nastavovať využívanie svetelného osvetlenia podľa skutočnej potreby, nie v stanovenom intervale. Zdroj trvalého napájania okrem toho umožňuje prenos dát. Na rozdiel od napájania počas vybraného času je možné dátový prenos realizovať počas celého dňa. Údaje zo senzorov prevádzkovaných na sieti verejného osvetlenia sú tak permanentným zdrojom aktuálnych údajov, ktoré je možné využívať pre tvorbu, spracovanie, využívanie a prepájanie dát v rámci verejnej správy pre inteligentné rozhodovanie, plánovanie a správu.

Mesto spravuje 9044 svetelných bodov. Na uvedených svetelných bodoch alebo v ich blízkosti sú na mestom vlastnenej infraštruktúre umiestnené:

 a) Senzory/zariadenia na zber dát

Každý senzor/zariadenie je napojený na zdroj trvalého napätia alebo zdroj napätia, ktoré umožňuje zber údajov zo senzorov. V prípade senzorov na verejnom osvetlení s permanentným napájaním ide o  zber dát online, v prípade senzorov na verejnom osvetlení s bežným napájaním ide o zber dát v čase, keď je k dispozícii elektrické pripojenie.

Senzory sú rôzneho typu, pričom podľa jednotlivého typu je následne možné definovať, aký typ dát sú senzory schopné získavať a zasielať ich inteligentným systémom mesta na spracovanie.

 b) Technológie na umiestnenie senzorov/zariadení na zber dát

Ide o sériu technických zariadení, ktoré umožňujú pripojenie nových senzorov na stĺpy verejného osvetlenia resp. v ich blízkosti.

V rámci zákazky bude zdokumentované priestorové rozloženie siete verejného osvetlenia (určenie polohy jednotlivých svetelných bodov/svetelných miest na styku so zemou s presnosťou na 30 cm; v prípade, že svetelný bod/miesto nie je pevne spojené zo zemou t.j. je mimo stožiaru alebo stĺpu verejného osvetlenia, bude zameraný voči úrovni terénu s poznámkou o výške umiestnenia v 3D súradniciach X, Y, Z v súradnicovom systéme WGS84). Priestorová poloha bude determinovaná iba pre 3764 svetelných bodov definovaných verejným obstarávateľom. Verejný obstarávateľ bude poskytovať určenie priestorovej polohy nasledovných svetelných bodov:

• 4425 svetelných bodov určených v rámci zákazky „Zvýšenie energetickej efektívnosti sústavy verejného osvetlenia v meste Žilina“
• 855 ks svetelných bodov určených v rámci zákazky „Lampové regulátory“

Pre každý svetelný bod/miesto (celkom 9044 svetelných bodov/miest) bude vykonaná analýza umiestnenia dátového zdroja (senzora) resp. analýza umiestnenia viacerých dátových zdrojov – senzorov – napájaných a inštalovaných na svetelných bodoch/ alebo technológií na umiestnenie senzorov/zariadení na zber dát.

Každé zariadenie – senzor – napájané a inštalované na svetelných bodoch/miestach bude mať determinovanú priestorovú väzbu na priestorovú polohu svetelného bodu/miesta. V prípade, že senzor nie je inštalovaný na svetelnom bode/mieste formou fyzického uchytenia o stožiar alebo stĺp verejného osvetlenia, ale na iných prvkoch sústavy verejného osvetlenia, budú tieto prvky priestorovo determinované samostatne.

Pre každý senzor/zariadenie na zber dát bude spracovaná fotodokumentácia aj s jeho fyzickým uchytením, identifikáciou typu zariadenia (napríklad informačná tabuľa, LED tabuľa, kamera, meteostanica, rozhlas, dopravná signalizácia, merač dopravy atď.), identifikáciou dodávateľa/výrobcu (napr. prostredníctvom výrobného alebo servisného štítku – v prípade, že nebude identifikácia možná, poskytne súčinnosť verejný obstarávateľ sprístupnením technickej dokumentácie), uvedením rozmerov, výšky umiestnenia, spôsobu uchytenia a iných dôležitých informácií o senzore/zariadení.

Z pohľadu napájania bude identifikovaný bod napojenia zariadenia (rozvodnica, stožiarová svorkovnica, svorky vzdušného vedenia a iné), spôsob napojenia, istenia a spotreba zariadenia (prostredníctvom výrobného štítku alebo meraním, v prípade že to nebude možné bude nutná súčinnosť mesta Žilina).

Z uvedených údajov musí byť zrejmé, aký typ dát je možné pre konkrétnu lokalitu získať tak, aby na základe tejto analýzy mohol byť realizovaný návrh:

• Rozmiestnenia nových senzorov
• Premiestnenia existujúcich senzorov
• Návrh usporiadania dátových tokov pre spracovanie, využívanie a prepájanie dát v rámci verejnej správy pre inteligentné rozhodovanie, plánovanie a správu

Výsledkom realizácie zákazky bude kompletná dokumentácia rozmiestnenia svetelných bodov/miest, k nim previazaných senzorov/zariadení, ako aj dokumentácia voľných technických bodov napojenia pre umiestnenie ďalších senzorov/zariadení v podobe:

• Vhodne zvoleného dokumentu (word, excel)
• Súboru s determináciou priestorového umiestnenia (napr. vo formáte shp).

2. Optické senzory a bezpečnostné kamery

Položky zákazky sú uvedené v súlade s Výzvou a sú určené pre nasledovné opatrenia:

1.2.2. Podpora budovania inteligentných miest a regiónov

5.1.3 Investície do bezpečného fyzického prostredia obcí, miest a regiónov

Položky označené ako „Opatrenie 1.2.2“ musia spĺňať nasledovnú podmienku:

• Nejde o zariadenia, ktoré slúžia primárne len na zaznamenávanie obrazu
• V prípade, že položky vytvárajú otvorené dáta, musia byť tieto dáta kompatibilné s centrálnym portálom otvorených dát MIRRI SR - data.slovensko.sk
• V prípade, že položky nevytvárajú otvorené dáta, musí byť zabezpečený súlad týchto dát so štandardami uvedenými v prílohe č. 11 Výzvy: Konsolidovaná analytická vrstva (opis štandardov pre integráciu), ktorej úplné znenie je uvedené na konci tohto Opisu predmetu zákazky.

Položky označené ako „Opatrenie 5.1.3“ musia spĺňať nasledovnú podmienku:

• Ide o optické zariadenia, určené na prevenciu kriminality

Pre účely zákazky verejný obstarávateľ uvádza, že všetky zariadenia budú inštalované na objektoch, ktoré sú:

• v jeho vlastníctve a budú mať zabezpečený prívod elektrickej energie. Rovnako budú mať zabezpečený prístup k trvalému napájaniu elektrickou energiou.
• nebudú v jeho vlastníctve, ale verejný obstarávateľ zabezpečí súhlas vlastníka na umiestnenie hnuteľnej veci

Verejný obstarávateľ požaduje dodávku nasledovných typov zariadení – položiek:

• IoT zariadenie detekcie dopravy TYP1 (Opatrenie 1.2.2)
• IoT zariadenie detekcie dopravy TYP2 (Opatrenie 1.2.2)
• IoT zariadenie monitoringu bezpečnosti (Opatrenie 5.1.3)
• Riadiaca a monitorovacia jednotka IoT zariadenia -  TYP1 (Opatrenie 1.2.2)
• Riadiaca a monitorovacia jednotka IoT zariadenia -  TYP2 (Opatrenie 1.2.2)
• Rozvádzač pre IoT zariadenie monitoringu bezpečnosti (290 ks pre Opatrenie 1.2.2 a 15 ks pre opatrenie 5.1.3)
• Rozhranie pre analytické operácie riadenia dopravy a monitoringu bezpečnosti (Opatrenie 1.2.2).

Senzory budú umiestnené na území mesta Žilina v katastrálnych územiach: Žilina, Bytčica, Závodie, Bánová, Strážov, Žilinská Lehota, Považský Chlmec, Vranie, Budatín, Brodno, Zádubnie, Zástranie, Trnové a Mojšova Lúčka.

Podrobné požiadavky na jednotlivé zariadenia sú uvedené v podrobne prílohe Opis predmetu zákazky. Pre každé zariadenie si verejný obstarávateľ vyhradzuje právo na to overiť, či ponúkaný tovar spĺňa príslušné parametre, a to napríklad kontrolou technických listov, výrobných listov, overením u výrobcu alebo požiadavkou na predvedenie funkčnosti zariadenia.

3. Inteligentné senzory

Položky zákazky sú uvedené v súlade s Výzvou a sú určené pre nasledovné opatrenia:

     1.2.2. Podpora budovania inteligentných miest a regiónov

Pre účely zákazky verejný obstarávateľ uvádza, že všetky zariadenia budú inštalované na objektoch, ktoré sú:

• v jeho vlastníctve a budú mať zabezpečený prívod elektrickej energie. Rovnako budú mať zabezpečený prístup k trvalému napájaniu elektrickou energiou.
• nebudú v jeho vlastníctve, ale verejný obstarávateľ zabezpečí súhlas vlastníka na umiestnenie hnuteľnej veci

Verejný obstarávateľ požaduje dodávku nasledovných typov zariadení – položiek:

• senzor vlhkosti pôdy
• meteostanica
• snímač vodnej hladiny
• záplavový senzor
• SMART senzor
• SMART modul (LC modul)
• SMART modul meraní (PM modul)

Senzory budú umiestnené na území mesta Žilina v katastrálnych územiach: Žilina, Bytčica, Závodie, Bánová, Strážov, Žilinská Lehota, Považský Chlmec, Vranie, Budatín, Brodno, Zádubnie, Zástranie, Trnové a Mojšova Lúčka.

Podrobné požiadavky na jednotlivé zariadenia sú uvedené v podrobne prílohe Opis predmetu zákazky.

4. Analytický informačný systém na podporu riadenia samosprávnych procesov

Predmetom zákazky je vyhotovenie softvérového programu – diela v podobe informačného systému pod názvom „Inteligentný systém analýz a riadenia (ISAR)“.

Tento informačný systém bude umožňovať zber a vyhodnocovanie údajov z optických a inteligentných senzorov, ktoré budú do systému distribuované prostredníctvom internetového pripojenia cez komunikačné rozhrania. Informačný systém bude implementovať inovatívne technologické a netechnologické riešenia inteligentného riadenia v rámci podpory rozvoja tvorby, spracovania, využívania a prepájania dát v rámci verejnej správy, najmä rozvoja dátových platforiem, využívania priestorových a otvorených dát a súvisiacich nástrojov s pridanou hodnotou pre inteligentné rozhodovanie a správu mesta, proaktívnych elektronických služieb, ako aj poskytovanie služieb občanom a podnikateľom, vrátane získavania poznatkov o aktuálnom stave dostupnosti a využívania dát v rámci verejnej správy, budovania špecifických kapacít a infraštruktúry.

Predmetom realizácie bude vyhotovenie informačného systému vrátane dodávky potrebných licencií a ich konfigurácie, ktorý musí spĺňať zoznam požiadaviek, ktoré sú uvedené v prílohe Opis predmetu zákazky.

4. ARCHITEKTÚRA RIEŠENIA PROJEKTU

Realizácia projektu bude zahŕňať budovanie nového ISVS a jeho prepojenie s existujúcimi resp. budovanými ISVS mesta Žilina a súčasne nákup HW. Z toho dôvodu budú navrhnuté všetky vrstvy architektúry (biznis, aplikačná, technologická).

Pred uvedením a detailným popisom zvoleného navrhovaného riešenia boli vyhodnotené alternatívy riešenia pre každú vrstvu architektúry.

Architektúra navrhovaného riešenia projektu je v súlade s funkčnými, nefunkčnými a technickými požiadavkami definovanými v katalógu požiadaviek (M-05 Analýza nákladov a prínosov - BC/CBA, karta: Katalóg požiadaviek).

Obsah tejto kapitoly je tiež prehľadom realizácie výstupu M-06 - aktualizácia evidencie e-Government komponentov v MetaIS. Mesto Žilina tak plní výstupom M-06 povinnosti orgánu riadenia sprístupňovať a aktualizovať informácie o informačných technológiách verejnej správy prostredníctvom MetaIS bezodkladne podľa § 12 ods. 1 písm. b) zákona č. 95/2019 Z.z.

4.1 Biznis vrstva

V tejto kapitole je spracované detailnejšie rozpracovanie zvolenej alternatívy riešenia v biznis vrstve architektúry. Sú uvedené e-Government komponenty – Koncové služby, ktoré budú výstupom projektu, a ktoré sú zaevidované v MetaIS v rámci výstupu M-06.

Z pohľadu biznis vrstvy mesto Žilina v súčasnosti poskytuje nevyhnutné údaje formou otvorených dát zo svojich prevádzkových systémov. Formou otvorených dát neposkytuje údaje zo senzorov prevádzkovaných na území mesta; uvedené senzory je možné prehliadať na jednoduchom mapovom zobrazení, avšak bez možnosti získavania detailnejších informáciách pre občanov, podnikateľov alebo iné OVM.

Z pohľadu využívania analýz dát zo senzorov resp. kombinovaných analýz dát zo senzorov a iných agendových systémov mesta nie sú tieto údaje nijakým spôsobom vytvárané a zdieľané s verejnosťou.

Projekt sa týka nasledovných prioritných životných situácií, kedy buď priamo podporuje získavanie údajov občanmi alebo zrýchľuje rozhodovacie procesy mesta:

Nasledovný obrázok znázorňuje TO BE stav biznis vrstvy, pričom v rámci projektu pribudnú tri koncové služby určené pre občanov, podnikateľov a OVM:

• Publikovanie otvorených dát senzorov
• Publikovanie výsledkov analýz a štatistík
• Vizuálne publikovanie výsledkov analýz a štatistík

Obrázok 1 Znázornenie TO BE biznis vrstvy

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

V nasledujúcej tabuľke uveďte prehľad budovaných a rozvíjaných Koncových služieb. Údaje o koncových službách treba zapísať do MetaIS ako súčasť výstupu M-06.

Tabuľka 1 Prehľad koncových služieb - budúci stav (TO BE)

4.1.2 Jazyková podpora a lokalizácia

Vizuálne rozhrania koncových služieb musia byť dostupné v slovenskom a anglickom jazyku s možnosťou dopracovať ďalšie jazykové mutácie. Správcovské rozhrania musia byť k dispozícii pre koncových používateľov (zamestnancov mesta) v slovenskom jazyku, nástroje určené pre IT adminov môžu byť v odôvodnených prípadoch (open source, perzistentný softvér) v anglickom jazyku.

Dokumentácia projektu musí byť spracovaná výhradne v slovenskom alebo českom jazyku. Rovnako používateľské návody pre používateľov koncových služieb musia byť k dispozícii v slovenskom jazyku. Koncové služby projektu budú dostupné aj pre používateľov z iných členských štátov EÚ.

4.2 Aplikačná vrstva

V tejto kapitole je detailnejšie rozpracovaná aplikačná vrstva architektúry.

Obsahuje prehľad e-Government komponentov – Aplikačných služieb, Informačných systémov a ich podsystémov a ich vzájomných vzťahov, ktoré budú výstupom projektu (dodané nové alebo zmenené) a ktoré sú zaevidované v MetaIS v rámci výstupu M-06 (Evidencia e-Government komponentov v MetaIS).

V prehľade sú uvedené a v MetaIS v rámci výstupu M-06 evidujte aj vzťahy Aplikačných služieb, ktoré budú slúžiť Koncovým službám. Taktiež uveďte Aplikačné služby poskytované na externú integráciu a tiež konzumné integračné Aplikačné služby a ich vzťahy na poskytované služby iných systémov, hlavne spoločných modulov.

Predmetom realizácie budú nové aplikačné služby, ktoré:

• Slúžia koncovým službám projektu
• Sú určené ako aplikačné služby pre interných zamestnancov mesta

Podrobnosti o aplikačných službách uvádza nasledovný obrázok:

Obrázok 2 Rozpracovanie detailov budúcej (TO BE) aplikačnej architektúry a závislostí (dátových tokov) medzi externými komponentmi mesta

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

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

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

Predmetom projektu nie je realizácia rozvoja ISVS, z toho dôvodov nie sú popísané AS IS využívané nadrezortné a spoločné ISVS.

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

ISVS vyhotovený v rámci projektu nie je plánovaný na integráciu na nadrezortné ISVS – spoločné moduly podľa zákona č. 305/2013 Z.z. o e-Governmente.

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

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

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

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

Projekt nebude poskytovať údaje do do IS Centrálna platforma dátovej integrácie (IS CPDI, kód MetaIS=isvs_5836, pôvodné IS CSRÚ).

4.2.9 Konzumovanie údajov z IS CSRU – TO BE

ISVS budovaný v rámci projektu nebude konzumovať údaje z IS Centrálna platforma dátovej integrácie (IS CPDI, kód MetaIS=isvs_5836, pôvodné IS CSRÚ); v prípade potreby bude využívať integrácie iných ISVS realizovaných v rámci mesta na prístup k týmto údajom.

4.3 Dátová vrstva

4.3.1 Údaje v správe organizácie

V nasledujúcej tabuľke sú uvedené a popísané Objekty Evidencie (ďalej len OE) v jednotlivých ISVS/registroch súvisiace s projektom – AS IS stav –.

V číslovaní objektov evidencie nie je chyba. Ide o unikátne identifikátory evidované v rámci mesta. Tie objekty evidencie, ktoré nie sú predmetom projektu nie sú v tabuľke uvedené.

Finálny rozsah spracovania OE bude stanovený v realizačnej etape Analýza a dizajn.

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

4.3.3 Referenčné údaje

Predmetov projektu nebude vytvorenie referenčných údajov.

4.3.4 Kvalita a čistenie údajov

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

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

Potrebné personálne kapacity pre zabezpečenie riadenia dátovej kvality:  

4.3.5 Otvorené údaje

V nasledujúcej tabuľke sú uvedené objekty evidencie, ktoré budú realizáciou projektu sprístupnené ako otvorené údaje.

4.3.6 Analytické údaje

Analytické údaje sú údaje, ktoré sú hromadne získavané zo zdrojových registrov a iných zdrojov dát pre ich hromadné spracovanie a vyhodnotenie s cieľom zistenia trendov, faktov a vzorcov v získaných dátach popisujúcich skúmanú oblasť pre účely realizácie legislatívnej iniciatívy, tvorby štátnej politiky, skúmania problematiky v určitej oblasti a navrhovaní opatrení na riešenie rôznych otázok, hodnotenia výsledkov a kvality výkonu verejnej moci. V priestore verejnej správy sa jedná o dátové zdroje, ktoré sú vytvárané a spravované jednotlivými organizáciami za účelom podpory služieb verejnej správy, služieb vo verejnom záujme alebo verejných služieb. Tieto údaje môžeme okrem uvedenej primárnej funkcie využiť aj na analytické spracovanie tak, aby verejná správa dokázala využívať svoje údaje pre potreby prípravy analýz, na podporu rozhodovania, riadenia a lepší návrh politík. Podmienkou pre plné využitie potenciálu údajov vo verejnej správe je ich poznanie (informácie o dátových zdrojoch, ich obsahu a atribútoch) a zabezpečenie prístupu k analytickým údajom pre analytické jednotky.

V súlade s podmienkami používania údajov pri analytickej činnosti uvedenými na web stránkach MIRRI budú tieto dáta analyticky spracovávané až po pseudonymizovaní alebo anonymizovaní osobných alebo citlivých údajov. Predpokladá sa, že najvhodnejší spôsob pseudonymizácie a anonymizácie bude navrhnutý vo fáze detailného návrhu riešenia a preto ich nebolo potrebné v tejto prípravnej fáze špecifikovať ani obmedzovať rozsah atribútov datasetu poskytnutého pre analytické spracovanie.

4.3.7 Moje údaje

Predmetom projektu nebude vytvorenie OE označovaných ako "Moje údaje".

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

Súhrnná tabuľka pre kategorizáciu údajov dotknutých projektom z pohľadu využiteľnosti týchto údajov.

4.4 Technologická vrstva

Alternatívy na úrovni technologickej architektúry reflektujú alternatívy vypracované na základe „nadradenej“ architektonickej aplikačnej vrstvy.

Výstupmi projektu budú technologické zariadenia (hardvérové vybavenie), ktoré bude prostredníctvom existujúcej technologickej infraštruktúry napájané a bude zabezpečená jeho konektivita do centrálneho dátového bodu prostredníctvom existujúcej prenosovej dátovej infraštruktúry.

Softvérové centrálne inštalované výstupy projektu budú prevádzkované na vlastnej existujúcej infraštruktúre Mesta Žilina, nakoľko je táto infraštruktúra dostatočne výkonná a implementácia softvéru na tejto infraštruktúre zabezpečí jeho bezproblémovú integráciu na interné i externé ISVS.

                Návrh TO BE technologickej architektúry je uvedený na nasledovnom obrázku:

Obrázok 3 Rozpracovanie detailov budúcej (TO BE) technologickej architektúry

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

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

V projekte nebudú využívané služby vládneho cloudu.

4.5 Bezpečnostná architektúra

Bezpečnostná architektúra je daná projektom „Zvýšenie úrovne kybernetickej bezpečnosti - Mesto Žilina“, ktorý v súčasnosti mesto Žilina realizuje z prostriedkov výzvy Podpora v oblasti kybernetickej a informačnej bezpečnosti na regionálnej úrovni – verejná správa, číslo výzvy: PSK-MIRRI-611-2024-DV-EFRR.

Základný náčrt architektúry je znázornený na nasledovnom obrázku, pričom celé opatrenia riešenia kybernetickej a informačnej bezpečnosti budú aplikované aj na tento projekt.

Obrázok 4 Aplikačná architektúra systému kybernetickej bezpečnosti mesta Žilina aplikovaná na všetky prvky projektu

Určenie obsahu bezpečnostných opatrení:

5. ZÁVISLOSTI NA OSTATNÉ ISVS / PROJEKTY

6. ZDROJOVÉ KÓDY

Všetky zdrojové kódy, ktoré vzniknú v rámci projektu pre aplikačné časti riešenia a ich dokumentácia podľa § 15 ods. d) zákona č. 95/2019 Z.z.. Rovnako bude definovaná požiadavka zabezpečenia dispozičných práv (licencií) k zdrojovým kódom, ich dokumentácii a projektovým výstupom zhotovených dodávateľom.  

Doplňte požiadavky na zdrojové kódy (zo vzorovej zmluvy):

Zhotoviteľ je povinný pri akceptácii Informačného systému alebo jeho časti odovzdať Objednávateľovi Vytvorený zdrojový kód v jeho úplnej aktuálnej podobe, zapečatený, na neprepisovateľnom technickom nosiči dát s označením časti a verzie Informačného systému, ktorej sa týka. Za odovzdanie Vytvoreného zdrojového kódu Objednávateľovi sa na účely tejto Zmluvy o dielo rozumie odovzdanie technického nosiča dát Oprávnenej osobe Objednávateľa. O odovzdaní a prevzatí technického nosiča dát bude oboma Zmluvnými stranami spísaný a podpísaný preberací protokol.

Vytvorený zdrojový kód  Informačného systému (s výnimkou Modulu) vrátane jeho dokumentácie bude prístupný v režime podľa § 31 ods. 4 písm. b) Vyhlášky č. 78/2020 (s obmedzenou dostupnosťou pre orgán vedenia a orgány riadenia v zmysle Zákona o ITVS – vytvorený zdrojový kód je dostupný len pre orgán vedenia a orgány riadenia); týmto nie je dotknutý osobitný právny režim vzťahujúci sa na Preexistentný zdrojový kód. Objednávateľ je oprávnený sprístupniť Vytvorený zdrojový kód okrem orgánov podľa predchádzajúcej vety aj tretím osobám, ale len na špecifický účel, na základe riadne uzatvorenej písomnej zmluvy o mlčanlivosti a ochrane dôverných informácií.

Vytvorený zdrojový kód musí byť v podobe, ktorá zaručuje možnosť overenia, že je kompletný a v správnej verzii, t. j. v takej, ktorá umožňuje kompiláciu, inštaláciu, spustenie a overenie funkcionality, a to vrátane kompletnej dokumentácie zdrojového kódu (napr. interfejsov a pod.) takejto Informačného systému alebo jeho časti. Zároveň odovzdaný Vytvorený zdrojový kód musí byť pokrytý testami (aspoň na 90%) a dosahovať rating kvality (statická analýza kódu) podľa CodeClimate/CodeQL a pod. (minimálne stupňa B).

Pre zamedzenie pochybností, povinnosti Zhotoviteľa týkajúce sa Vytvoreného zdrojového kódu platí i na akékoľvek opravy, zmeny, doplnenia, upgrade alebo update Vytvoreného zdrojového kódu a/alebo vyššie uvedenej dokumentácie, ku ktorým dôjde pri plnení tejto Zmluvy o dielo alebo v rámci záručných opráv. Vytvorené zdrojové kódy budú vytvorené vyexportovaním z produkčného prostredia a budú odovzdané Objednávateľovi na elektronickom médiu v zapečatenom obale. Zhotoviteľ je povinný umožniť Objednávateľovi pri odovzdávaní Vytvoreného zdrojového kódu, pred zapečatením obalu, skontrolovať v priestoroch Objednávateľa prítomnosť Vytvoreného zdrojového kódu na odovzdávanom elektronickom médiu.

Nebezpečenstvo poškodenia zdrojových kódov prechádza na Objednávateľa momentom prevzatia Informačného systému alebo jeho časti, pričom Objednávateľ sa zaväzuje uložiť zdrojové kódy takým spôsobom, aby zamedzil akémukoľvek neoprávnenému prístupu tretej osoby. Momentom platnosti SLA zmluvy umožní Objednávateľ poskytovateľovi, za predpokladu, že to je nevyhnutné, prístup k Vytvorenému zdrojovému kódu výlučne na účely plnenia povinností z  uzatvorenej SLA zmluvy.

Zmluvné strany sa dohodli, že pokiaľ Zhotoviteľ vytvorí v rámci plnenia tejto Zmluvy o dielo pre Objednávateľa SW, ktorý je  počítačovým programom chráneným autorským právom alebo jeho časť, prevzatím Diela udeľuje Zhotoviteľ Objednávateľovi súhlas používať taký počítačový program (s výnimkou Modulu na ktorý sa vzťahujú osobitné podmienky) ako licenciu nevýhradnú, časovo neobmedzenú (po dobu trvania majetkových autorských práv), územne obmedzenú na územie Slovenskej republiky, v neobmedzenom rozsahu (najmä na neobmedzený počet zariadení a užívateľov) a na všetky spôsoby použitia najmä v súlade s § 19 ods. 4 Autorského zákona na účel, pre ktorý bolo Dielo vytvorené podľa tejto Zmluvy o dielo. Špecifikácia počítačových programov vytvorených Zhotoviteľom podľa tejto Zmluvy o dielo tvorí prílohu č. 6  tejto Zmluvy o dielo. Objednávateľ je bez potreby akéhokoľvek ďalšieho povolenia Zhotoviteľa oprávnený udeliť inému orgánu verejnej správy Slovenskej republiky sublicenciu na použitie počítačového programu v súlade s účelom na aký bude Dielo vytvorené, vrátane subjektov ovládaných v zmysle § 66a Obchodného zákonníka alebo subjektov zriadených orgánom verejnej správy  za účelom plnenia úloh vo verejnom záujme (bez ohľadu na právnu formu), pokiaľ to nie je v rozpore s pravidlami na ochranu hospodárskej súťaže.

7. PREVÁDZKA A ÚDRŽBA

7.1 Prevádzkové požiadavky

Podpora prevádzky a používateľov bude realizovaná cez 3 úrovne podpory, s nasledujúcim označením a obsahom činnosti:

• Podpora L1 (podpora 1. stupňa - Level 1) - začiatočná úroveň podpory, ktorej základnou funkciou 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ď. Je zabezpečovaná  prostredníctvom pracoviska jednotného kontaktného miesta.

• Podpora L2 (podpora 2. stupňa – Level 2 -  postúpenie požiadaviek od L1) – riešiteľské tímy s hlbšou technologickou znalosťou danej oblasti. Riešitelia na úrovni Podpory L2 nekomunikujú priamo s koncovým užívateľom, ale sú zodpovední za poskytovanie súčinnosti riešiteľom 1. úrovne podpory pri riešení eskalovaného hlásenia, čo mimo iného obsahuje aj spätnú kontrolu a podrobnejšiu analýzu zistených dát predaných riešiteľom 1. úrovne podpory. Výstupom takejto kontroly môže byť potvrdenie, upresnenie, alebo prehodnotenie hlásenia v závislosti na potrebách Objednávateľa. Primárnym cieľom riešiteľov na úrovni Podpory L2 je dostať Hlásenie čo najskôr pod kontrolu a následne ho vyriešiť - s možnosťou eskalácie na vyššiu úroveň podpory – Podpora L3.

• Podpora L3 (podpora 3. stupňa) - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobtiažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.

Typické zodpovednosti za realizáciu podpory sú:

• L1 (Level 1: priamy kontakt zákazníka) - jednotný kontaktný bod je zvyčajne zabezpečovaný pracoviskom v správe správcu informačného systému, ak nedeleguje túto činnosť na špecializovanú organizáciu v jeho zriaďovacej pôsobnosti alebo výnimočne na externého dodávateľa.
• L2 (Level 2: postúpenie požiadaviek od L1) - riešiteľské tímy s hlbšou znalosťou prevádzkovaného systému sú zvyčajne tvorené pracovníkmi prevádzkovateľa informačného systému – buď pracovníkmi správcu alebo pracovníkmi špecializovanej organizácie v jeho zriaďovacej pôsobnosti. Časť špecializovaných prác môže byť za definovaných podmienok prenesená aj na externého dodávateľa.
• L3 (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o podpore inf. systému zvyčajne zabezpečuje externý dodávateľ, ktorý má potrebné kapacity a kvalifikovaný personál pre riešenie prevádzkových incidentov a servisných požiadaviek.

Prehľad očakávaného riešenia zabezpečenia podpory používateľov a prevádzky, hlavné zodpovednosti a očakávanú úroveň poskytovaných služieb:

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 zákazníka) - jednotný kontaktný bod verejného obstarávateľa – IS Solution manager, ktorý je v správe verejného obstarávateľa a v prípade jeho nedostupnosti Centrum podpory používateľov (zabezpečuje prevádzkovateľ IS a DataCentrum).
• L2 podpory IS (Level 2, postúpenie požiadaviek od L1) - vybraná skupina garantov, so znalosťou IS (zabezpečuje prevádzkovateľ IS – verejný obstarávateľ v spolupráci s externým dodávateľom).
• L3 podpory IS (Level 3, postúpenie požiadaviek od L2) - na základe zmluvy o podpore IS (zabezpečuje úspešný uchádzač).

Definícia:

• Podpora L1 (podpora 1. stupňa) - 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ď.
• Podpora L2 (podpora 2. stupňa) – riešiteľské tímy s hlbšou technologickou znalosťou danej oblasti. Riešitelia na úrovni Podpory L2 nekomunikujú priamo s koncovým užívateľom, ale sú zodpovední za poskytovanie súčinnosti riešiteľom 1. úrovne podpory pri riešení eskalovaného hlásenia, čo mimo iného obsahuje aj spätnú kontrolu a podrobnejšiu analýzu zistených dát predaných riešiteľom 1. úrovne podpory. Výstupom takejto kontroly môže byť potvrdenie, upresnenie, alebo prehodnotenie hlásenia v závislosti na potrebách Objednávateľa. Primárnym cieľom riešiteľov na úrovni Podpory L2 je dostať Hlásenie čo najskôr pod kontrolu a následne ho vyriešiť - s možnosťou eskalácie na vyššiu úroveň podpory – Podpora L3.
• Podpora L3 (podpora 3. stupňa) - Podpora 3. stupňa predstavuje najvyššiu úroveň podpory pre riešenie tých najobťiažnejších Hlásení, vrátane prevádzania hĺbkových analýz a riešenie extrémnych prípadov.

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

• Help Desk je dostupný cez IS a pre vybrané skupiny užívateľov cez telefón a email, incidenty sú evidované v ,
• Dostupnosť 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.2 Riešenie incidentov – SLA parametre

Označenie naliehavosti incidentu:

možný dopad:

 Výpočet priority incidentu je kombináciou dopadu a naliehavosti v súlade s best practices ITIL V3 uvedený v nasledovnej matici:

Vyžadované reakčné doby:

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 (Doba konečného vyriešenia incidentu) - znamená čas obnovenia štandardnej prevádzky - čas medzi nahlásením incidentu verejným obstarávateľom a vyriešením incidentu poskytovateľom podpory (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 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 poskytovateľ podpory oprávnený požadovať od verejného obstarávateľa schválenie riešenia incidentu.

(3) Spoľahlivosť - 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 poskytovateľovi podpory v rámci testovacieho prostredia majú prioritu 3 a nižšiu. Vzťahujú sa výhradne k dostupnosti testovacieho prostredia. Za incident v 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.2 Požadovaná dostupnosť IS:

7.2.1 Dostupnosť (Availability)

Dostupnosť (Availability) je pojem z oblasti riadenia bezpečnosti v organizácii. Dostupnosť znamená, že dáta sú prístupné v okamihu jej potreby. Narušenie dostupnosti sa označuje ako nežiaduce zničenie (destruction) alebo nedostupnosť. Dostupnosť je zvyčajne vyjadrená ako percento času v danom období, obvykle za rok. Orientačný zoznam dostupnosti je uvedený v nasledovnom prehľade:

• 90% dostupnosť znamená výpadok 36,5 dňa
• 95% dostupnosť znamená výpadok 18,25 dňa
• 98% dostupnosť znamená výpadok 7,30 dňa
• 99% dostupnosť znamená výpadok 3,65 dňa
• 99,5% dostupnosť znamená výpadok 1,83 dňa
• 99,8% dostupnosť znamená výpadok 17,52 hodín
• 99,9% (“tri deviatky”) dostupnosť znamená výpadok 8,76 hodín
• 99,99% (“štyri deviatky”) dostupnosť znamená výpadok 52,6 minút
• 99,999% (“päť deviatok”) dostupnosť znamená výpadok 5,26 minút
• 99,9999% (“šesť deviatok”) dostupnosť znamená výpadok 31,5 sekúnd

Hoci je obvyklé uvádzať dostupnosť v percentách, presnejšie ukazovatele sú vyjadrením doby obnovenia systému a na množstvo dát, o ktoré môžeme prísť:

• RTO (Recovery Time Objective) - doba obnovenia systému, t.j. za ako dlho po výpadku musí byť systém funkčný (pre bližšie info klik na nadpis)
• RPO (Recovery Point Objective)- aké množstvo dát môže byť stratené od vymedzeného okamihu
• Recovery Time - čas potrebný k obnove

Riešenie dostupnosti v praxi: Nedostupnosť dát je jedným z rizík, ktorý môže postihnúť každú organizáciu. Dostupnosť je jedným s kľúčových požiadaviek na každý dôležitý informačný systém a vplyv na dostupnosť má mnoho faktorov, napríklad:

• Dostupnosť servera
• Dostupnosť pripojenie k internetu
• Dostupnosť databázy
• Dostupnosť webových stránok

V prípade, že je časť softvér alebo infraštruktúra zabezpečovaná externe (napr. hosting, webhosting), prenáša sa zodpovednosť za dostupnosť týchto komponentov na dodávateľa.

7.2.2 RTO (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.3 RPO (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 tá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

Pre účely realizácie projektu bude zriadený Riadiaci výbor (RV) realizátora projektu minimálne v nasledovnom zložení:

• Predseda RV: Ing. Martin Kapitulík
• Biznis vlastník: Bude prijatý nový zamestnanec
• Zástupca prevádzky: Ing. Filip Švec
• Projektový manažér realizátora projektu (Objednávateľa) (PM): Ing. Miroslava Buznová

Pre účely realizácie projektu bude zriadený Projektový tím realizátora projektu:

• IT architekt: Ing. Filip Švec
• kľúčový používateľ: Amir Alkassiri
• IT analytik a biznis analytik: Bude prijatý nový zamestnanec
• biznis vlastník: Bude prijatý nový zamestnanec
• projektový manažér: Ing. Miroslava Buznová

• manažér kvality: Bude zabezpečený externými zdrojmi.

9. IMPLEMENTÁCIA A PREBERANIE VÝSTUPOV PROJEKTU

Projekt bude realizovaný metódou Waterfall s logickými nadväznosťami realizácie jednotlivých modulov na základe funkčnej a technickej špecifikácie vypracovanej v rámci prípravy projektu.

Tento prístup bol zvolený nakoľko projekt má jasne definované ciele, postupy a rozdelenie práce.

Funkčné požiadavky boli definované v katalógu požiadaviek, pričom je projekt rozdelený do troch inkrementov. Každý inkrement pozostáva z troch realizačných fáz:

• Analýza a dizajn
• Implementácia a testovanie
• Nasadenie (ktoré sa v jednom mesiaci prekrýva s predchádzajúcou realizačnou fázou, nakoľko pri nasadení môžu byť požadované drobné implementačné úpravy a testy).

Každá z uvedených realizačných fáz je samostatným fakturačným míľnikom projektu, pričom k nej musí byť spracovaný preberací protokol. Finálne odovzdanie výstupu projektu (diela) je zakončené finálnou akceptáciou diela so samostatným preberacím protokolom. Pri podpise tohto finálneho protokolu začína plynúť záruka na dielo.

Výsledkov projekt budú:

• Projektové výstupy v zmysle vyhlášky 401/2023 o riadení projektov. V prípade, že predmetom realizácie bude dielo (oceniteľné práva a/alebo zdrojový kód), získa Mesto Žilina právo vykonávať autorské práva k tomuto dielu, vrátane výhradnej a územne neobmedzenej licencie. Tieto podmienky sa nevzťahujú na tzv. krabicový softvér, ktorý je predávaný ako produkt či už realizátora alebo tretej strany.
• kompletná dokumentácia rozmiestnenia svetelných bodov/miest, k nim previazaných senzorov/zariadení, ako aj dokumentácia voľných technických bodov napojenia pre umiestnenie ďalších senzorov/zariadení v podobe:
  • Vhodne zvoleného dokumentu (word, excel)
  • Súboru s determináciou priestorového umiestnenia (napr. vo formáte shp).
• 290 IoT zariadení detekcie dopravy (optických senzorov) vrátane riadiacich a monitorovacích jednotiek a rozvádzačov
• 15 bezpečnostných kamier, ktoré svojim záberom zvýšia úroveň bezpečnosti na plochách v rámci mesta Žilina v celkovom rozsahu 17 800 m² vrátane rozvádzačov
• Inteligentné senzory
  •  16 senzorov vlhkosti pôdy
  •  15 meteostaníc
  •  8 snímačov vodnej hladiny
  •  36 záplavových senzorov
  •  205 SMART senzorov
  •  59 SMAR modulov meraní
• Nový ISVS: Inteligentný systém analýz a riadenia (ISAR)

10. PRÍLOHY

Dokument neobsahuje prílohy.