ZADÁVACÍ DOKUMENTACE VEŘEJNÉ ZAKÁZKY

ZADÁVACÍ DOKUMENTACE VEŘEJNÉ ZAKÁZKY

ve smyslu § 28 odst. 1 písm. b) zákona č. 134/2016 Sb., o zadávání veřejných zakázek

(dále jen „ZZVZ“)

Veřejná zakázka na služby

zadávaná dle § 56 ZZVZ:

Realizace a provozní zajištění zóny placeného stání Teplice formou poskytnutí služby

Zadávací řízení:

Otevřené řízení

Veřejná zakázka:

Nadlimitní veřejná zakázka

Zadavatel veřejné zakázky:

Statutární město Teplice

náměstí Svobody 2/2

415 95 Teplice

IČO: 00266621

Příloha zadávací dokumentace:

Xxxxxxx x. 0: Technické podmínky zadavatele

1 Definice pojmů a zkratky

Pojem	Výklad pojmu
Abonent	Osoba (fyzická či právnická) podnikající, mající sídlo nebo místo podnikání v RO. Abonent je typ externího uživatele.
RV	Registr vozidel vedený Ministerstvem dopravy ČR podle zákona 56/2001 Sb.
Člověkoden	Jednotka pracovní kapacity. Efektivně vynaložená práce pracovníkem, který je odborníkem v příslušné oblasti, po dobu 8 hodin.
Člověkoměsíc	Jednotka pracovní kapacity. Kapacita jednoho člověkoměsíce se rovná kapacitě 21 člověkodnů (průměrný počet pracovních dnů v kalendářním měsíci).
Dodavatel	Subjekt, který zajišťuje pro Zadavatele plnění podle Xxxxxxx.
Dostupnost SZPS	Dostupnost SZPS je definována jako procentuální podíl času v kalendářním měsíci, po který byl SZPS plně funkční vůči celkovému času mimo plánované odstávky, po který měl být v daném měsíci funkční (tzn. 24 hodin každý den, vyjma dobu plánovaných odstávek odsouhlasených Zadavatelem).
Dostupnost PIS	Dostupnost PIS je definována jako procentuální podíl času v kalendářním měsíci, po který byl PIS plně funkční vůči celkovému času mimo plánované odstávky, po který měl být v daném měsíci funkční (tzn. 24 hodin každý den, vyjma dobu plánovaných odstávek odsouhlasených Zadavatelem).
Dostupnost technické podpory	Dostupnost technické podpory definuje časové limity pro přijetí a vyřešení Požadavku na Servisní zásah. Dostupnost technické podpory je definována ve vztahu k prioritě Požadavku na Servisní zásah. Měří se v časových jednotkách.
Drobný rozvoj PIS	Úpravy PIS za účelem udržení či optimalizace jeho funkčnosti, které nemění rozsah funkcionality, ale mění nebo doplňují již implementované vlastnosti PIS.
DSZPS	Dílčí systémy zóny placeného stání: • Parkovací automaty • Informační stojany a informační tabule ● Závorové systémy SZPS podporuje činnosti a spravuje data v dílčích oblastech PIS: ● správa parametrů a vymezení jednotlivých Úseků ZPS, ● správa jednotlivých zařízení ZPS (parkovací automaty a závorové systémy) ● správy dlouhodobých oprávnění, ● nástroje pro řešení porušení pravidel, ● odhalování přestupků, ● vyúčtování, ● statistiky.

Pojem	Výklad pojmu
Helpdesk	Systém pro zadávání Požadavků na Servisní zásah pro interní uživatele. Každý požadavek se skládá z priority a oblasti, které se týká. Dodavatel přijímá informace z Helpdesku a podle priority zahájí činnost v souladu s kap. 7. níže, případně se specifickými podmínkami stanovenými pro příslušný druh Periodické služby. Do Helpdesku má přístup též Zákaznické centrum, které má možnost zadat požadavek na základě podnětů od zákazníků.
Hotline	Telefonní linka určená Dodavatelem pro zadávání Požadavků na Servisní zásah pro interní uživatele. Dodavatel přijímá informace z Xxxxxxx a podle priority zahájí činnost v souladu s kap. 7. níže, případně se specifickými podmínkami stanovenými pro příslušný druh Periodické služby.
Lustrace	Zjištění provozovatele vozidla v registru vozidel.
Metodika výdeje POP	Metodika výdeje POP se vztahuje k typu POP a určuje, za jakých podmínek žádost o POP daného typu může být schválena a podmínky a parametry POP vytvořených na základě dané žádosti. Metodika výdeje POP je stanovená MSMT.
MSMT	Magistrát statutárního města Teplice
Mobilní monitoring ZPS	Monitoring ZPS prostřednictvím Zařízení pro mobilní monitoring ZPS.
Monitoring ZPS	Sběr dat o ZPS zaměřený na: ● dokumentaci vozidel parkujících v ZPS, ● kontrolu dodržování pravidel platných v ZPS, spočívající ve zjišťování Podezření ze spáchání přestupku, ● předání dokumentace Podezření ze spáchání přestupku při Parkování pro Odhalení přestupku a následné řešení, ● sběr dat pro statistiky a analýzy Parkování vozidel.
MP	Městská policie Teplice
Návštěvník	Řidič silničního motorového vozidla, které parkuje v ZPS v režimu §23, odstavec 1., písm. a) zákona 13/1997 Sb. Návštěvník je typ externího uživatele.
Nepovinný platební kanál VPH	Nepovinným platebním kanálem VPH jsou všechny Platební kanály, které budou dostupné pro placení Parkovného prostřednictvím VPH, kromě Platebních karet VPH.
Odhalení přestupku	Konstatování oprávněné osoby, že podklady o Podezření ze spáchání přestupku poskytnuté PIS jsou relevantní a že se jedná o Přestupek ZPS
OpenID	Otevřený standard popisující decentralizovaný způsob autentizace uživatelů, který odstraňuje potřebu na straně provozovatele služby poskytovat a vyvíjet vlastní systémy pro autentizaci, a který rovněž samotným uživatelům služby umožňuje konsolidaci jejich digitálních identit. OpenID má tvar unikátního URL, ke kterému je přiřazeno heslo.

Pojem	Výklad pojmu
OSU	Osobní stránky uživatele ZPS. OSU jsou neveřejnou částí portálu ZPS, která umožňuje registrovaným uživatelům přístup k jejich parkovacím oprávněním a dalším k nim vztaženým informacím. V projektu a dále je také užitý pojem „webshop“
Parkovací automat (PA)	Zařízení instalované na místních komunikacích sloužící k úhradě Parkovného.
Parkovací lístek (PL)	Papírový doklad o zaplacení Parkovného vydávaný Parkovacím automatem vázaný na RZ, slouží jako kontrolní doklad osvědčující zaplacení Parkovného. PL je jednou z forem osvědčení o POP.
Parkovací oblast (PO)	Parkovací oblast vymezuje území platnosti Parkovacího oprávnění a obsahuje Úseky ZPS určené pro Parkování s Parkovacím oprávněním (POP). Vymezení PO je provedeno právním předpisem statutárního města Teplice – nařízením.
Parkovací oprávnění (POP)	Oprávnění Rezidenta, Vlastníka nemovitosti, Abonenta, či Návštěvníka k Parkování vozidla v rámci ZPS v souladu s jeho pravidly. Slouží k prokazování zaplacení ceny za Parkování (Parkovného) vozidla Rezidenta, Vlastníka nemovitosti, Abonenta, či Návštěvníka v ZPS. Má formu záznamu v evidenci Parkovacích oprávnění vázanou na RZ vozidla uloženou v PIS. Tento záznam slouží jako základní informace pro ověření respektování pravidel Parkování v ZPS, tj. poskytuje informaci, zda daná RZ na daném místě a v daném čase parkuje oprávněně. POP je vždy právě jednoho typu. K typu POP se vztahují Pravidla ZPS platná pro všechny POP daného typu. POP vznikají na základě schválených žádostí uživatelů. Žádosti jsou schvalovány buď automatickým procesem (např. žádosti podané prostřednictvím PA na krátkodobé Parkování) nebo manuálním procesem pověřenými pracovníky. Podmínky schválení žádostí jsou součástí Pravidel ZPS. Podle typu vznikají POP buď automaticky (např. dlouhodobá POP pro Rezidenty, Vlastníky nemovitosti a Abonenty, krátkodobá POP pro Návštěvníky zaplacením prostřednictvím PA nebo VPH) nebo manuálním zadáním uživatelů s přístupem ke schválené žádosti (různé typy návštěvnických POP pro umožnění Parkování vymezeným kategoriím uživatelů – zásobování, hotely, péče o seniory, bezpečnostní složky, integrovaný záchranný systém,…).
Parkovací relace	Jednotlivé, časově omezené placené Parkování vozidla Návštěvníka v souladu s Pravidly ZPS. V PIS je evidováno formou záznamu v evidenci POP vázanou na RZ vozidla a tato informace slouží k prokazování zaplacení Parkovného vozidla Návštěvníka v ZPS.
Parkovací režim	Režim Parkování v daném Úseku. Rozlišuje se rezidentní (Parkování vozidel podle zákona 13/1997 Sb. §23, odstavec 1 písmena c – Rezident, Vlastník nemovitosti), abonentní (Parkování vozidel podle zákona 13/1997 Sb. §23, odstavec 1 písmena c – Abonent), návštěvnický (Parkování vozidel podle zákona 13/1997 Sb. §23, odstavec 1 písmeno a). V ZPS je možné společné parkování všech Parkovacích režimů na každém Úseku ZPS.

Pojem	Výklad pojmu
Parkovací technologie	Souhrnný pojem pro Parkovací automaty, Závorové systémy, informační tabule a informační stojany.
Parkování	Stání silničního motorového vozidla v ZPS.
Parkovné	Cena za použití parkovacího stání v ZPS.
Periodické služby	Souhrnný pojem pro Službu PIS a Službu Technického vybavení.
Platební kanál	Způsob úhrady Parkovného a Parkovacích oprávnění. Uvažovanými Platebními kanály, které mohou být využity v rámci plnění veřejné zakázky, jsou: ● hotovost na PA, ● hotovost na výdejnách POP, ● platební karty na PA, ● platební karty na výdejnách POP, ● platební karty VPH, ● platební karty OSU, ● „fleetové či palivové“ karty VPH, ● platba bankovním převodem, Technické podmínky Zadavatele dále specifikují, které z výše uvedených Platebních kanálů musí být povinně poskytnuty v rámci plnění veřejné zakázky.
Platební terminál	Platební terminály jsou zařízení či aplikace k bezpečnému provádění plateb platebními kartami.
PN	Product number – jednoznačné označení produktu/zařízení speciálním kódem.
Podezření ze spáchání přestupku	Zjištění, že RZ vozidla zaznamenaného Monitoringem ZPS není v databázi RZ vozidel majících platné Parkovací oprávnění nebo platnou Parkovací relaci.
Pochůzkový monitoring	Monitoring ZPS prostřednictvím Zařízení pro pochůzkový monitoring ZPS.
Povolená ztráta dat	V SZPS vznikají data průběžně v režimu 24x7, tj. i mimo provoz ZPS. Povolená ztráta dat (viz systémový parametr SZPS_DATA) stanovuje, že v případě havárie SZPS musí být schopen obnovit všechna data starší vzhledem k času havárie, než stanovuje tento systémový parametr.
Požadavek na Servisní zásah	Požadavek na provedení Servisního zásahu spadajícího do jedné z níže uvedených kategorií dle stupně priority dle kapitoly 7.
Pravidla ZPS	Soubor pravidel definovaný Metodikou výdeje POP, nařízením SMT dle § 23 zákona č. 13/1997 Sb. o pozemních komunikacích a dopravním značením osazeným na pozemních komunikacích.
Provozovatel Platebního kanálu	Subjekt, který zúčtovává a vybírá Parkovné a úhrady za POP vybrané prostřednictvím Platebního kanálu. Provozovatelem

Pojem	Výklad pojmu
	Platebního kanálu je pro Platební kanál VPH (či případně pro další nepovinné Platební kanály, které Dodavatel nabídne nad rámec povinných Platebních kanálů VPH) Dodavatel, pro Platební kanály platební karty na výdejnách POP a hotovost na výdejnách POP je Provozovatelem Platebního kanálu MSMT. Parkovné a úhrady za POP Provozovatel Platebního kanálu vybírá na účet a jménem SMT.
Přestupek ZPS	Porušení pravidel Parkování platných v ZPS naplňující skutkovou podstatu přestupku podle příslušných zákonných norem.
Přímá platba	Platba provedená na Správcovský účet Dodavatele v rámci Platebních kanálů zajišťovaných Dodavatelem.
Rezident	Fyzická osoba mající trvalý pobyt v RO. Rezident je typ externího uživatele.
Rezidentní oblast (RO)	Oblast, která je ve vztahu ke konkrétní osobě územím: 1) ve kterém se nachází adresa trvalého pobytu nebo adresa nemovitosti této konkrétní osoby; 2) nebo ve kterém se nachází adresa sídla nebo provozovny této konkrétní osoby. Rezidentní oblasti se nepřekrývají. Jedna Rezidentní oblast může patřit do více Parkovacích oblastí.
Režim služby	Režim služby definuje časový rozsah poskytování služby, např.: 24x7 – služba je poskytována trvale (24 hodin, 7 dní v týdnu, celý rok), 10x5 – služba je poskytována v pracovní dny v pracovní době v rozsahu 10 hodin od 8:00 do 18:00,
XXX	Xxxxxxx obyvatel – jeden ze základních registrů.
ROS	Registr osob – jeden ze základních registrů.
RUIAN	Registr územní identifikace a adres nemovitostí – jeden ze základních registrů.
RV	Registr silničních vozidel podle zákona 56/2001 Sb.
RZ	Registrační značka vozidla ve smyslu zákona č. 56/2001 Sb.
Servisní zásah	Provedení zásahu či jiného úkonu ze strany Dodavatele, kterým bude zajištěno odstranění závady, celkové nebo jen částečné nedostupnosti či omezení funkčnosti SZPS nebo jeho jednotlivých komponent anebo provedení úpravy SZPS či jeho jednotlivých komponent na základě požadavku Zadavatele spočívající ve změně v provozním prostředí, změně aplikace, parametrů nebo dat směřující k naplnění funkčnosti SZPS. Není-li možno nedostatek odstranit jinak, zahrnuje povinnost Dodavatele provést Servisní zásah rovněž povinnost příslušnou věc vyměnit za věc novou, která bude splňovat stanovené požadavky a která umožní obnovit funkčnost SZPS v plném rozsahu; věc může být rovněž vyměněna za věc vyšší třídy či jakosti, která splňuje podmínky stanovení

Pojem	Výklad pojmu
	v těchto Technických podmínkách Zadavatele, zejm. není-li již původní věc na trhu dostupná.
Služba PIS	Služba spočívající v poskytnutí (ve formě umožnění užívání prostřednictvím vzdáleného přístupu), správě a provozu PIS, jejíž obsah je specifikován zejména v kap. 3.5., 3.7., 5.2., 5.3., 5.4. a 5.5. těchto Technických podmínek Zadavatele.
Služba Technického vybavení	Služba spočívající v poskytnutí (pronájmu), správě, údržbě a provozu PA, ZS, informačních stojanů a informačních tabulí a Zařízení pro pochůzkový monitoring (společně jako Technické vybavení), přičemž obsah této služby je specifikován zejména v kap. 3.1., 3.2., 3.3., 3.4., 5.1. a 5.5. těchto Technických podmínek Zadavatele.
Smlouva	Smlouva na veřejnou zakázku, uzavřená mezi Zadavatelem (coby „Objednatelem“) a Dodavatelem na základě zadávacího řízení, jehož zadávací dokumentace jsou tyto Technické podmínky Zadavatele součástí. Tyto Technické podmínky Zadavatele se uzavřením Xxxxxxx stanou její přílohou.
SMT	Statutární město Teplice, které je příjemcem plateb ze ZPS a zároveň zřizovatelem a provozovatelem ZPS.
SZPS	Systém zóny placeného stání
Správcovský účet	Bankovní účet Dodavatele pro příjem úhrad Parkovného na Platebním kanálu platební karty VPH, popřípadě jiných, Dodavatelem SZPS zvolených Platebních kanálech. Dodavatel přijímá úhrady výhradně jménem a na účet SMT. Správcovský účet musí být výhradně určen pro příjem výše uvedených úhrad.
Úroveň ztráty dat	Úroveň ztráty dat stanovuje, za jaký maximální časový úsek mohou být ztraceny změny v datech. Měří se v časových jednotkách. Př: úroveň 1 hod znamená, že systém musí být schopen obnovit data s maximální ztrátou změn v datech za poslední 1 hodinu. Úroveň 0 min znamená, že systém musí být schopen obnovit data se všemi změnami, které v něm byly provedeny.
Úsek ZPS	Základní prostorový prvek ZPS (zpravidla část místní komunikace mezi křižovatkami), na kterém je provozována ZPS.
Virtuální parkovací hodiny (VPH)	Internetová/mobilní aplikace umožňující úhradu Parkovného pomocí chytrých mobilních telefonů či internetových aplikací.
Virtuální parkovací lístek (VPL)	Elektronický doklad o zaplacení Parkovného vázaný na RZ vozidla vydávaný SZPS prostřednictvím VPH či SMS, slouží jako kontrolní doklad pro ověření respektování Pravidel ZPS.
Vlastník nemovitosti	Fyzická osoba vlastnící nemovitost v RO.
Vstupní testovací verze PIS (VTV)	Vstupní testovací verze PIS je verze PIS instalovaná na testovací infrastruktuře Dodavatele. VTV musí mít implementovány funkce pro: ● podporu procesu vydávání a změn Parkovacích oprávnění,

Pojem	Výklad pojmu
	● srovnání záznamů o Parkování s Parkovacími oprávněními a Parkovacími relacemi, ● podporu procesu odhalování přestupků, ● reporting, ● zúčtování Parkovného. Musí umožnit Zadavateli se zorientovat ve stavu PIS, aby mohl co nejrychleji upřesnit své požadavky na PIS.
Výzva	Pokyn Zadavatele k realizaci Jednorázového plnění ve smyslu odst. 10.1. Smlouvy.
Zadavatel	Zadavatel této veřejné zakázky, tedy Statutární město Teplice
Zařízení pro pochůzkový monitoring	Kontrolní zařízení (např. chytrý mobilní telefon), které umožňuje provádět při pochůzkové činnosti Monitoring ZPS, komunikovat s PIS včetně pořizování fotodokumentace v požadovaném množství a kvalitě. Zároveň plní funkci sběru dopravně inženýrských dat a sledování stavu dopravního značení.
Závorový systém (ZS)	Zařízení pro automatizovaný režim registrace parkujících vozidel a automatizovaný režim úhrady parkovného s využitím elektrických závor na vjezdu a na výjezdu z parkoviště a doplněný o automatickou pokladnu.
Záznam o parkování	Datový záznam o zjištění přítomnosti vozidla s danou RZ na daném místě a v daném čase.
Zóna placeného stání (ZPS)	Souvislé území města, kde je stání silničního motorového vozidla regulováno systémem placeného stání podle §23 zákona č. 13/1997- Sb.

2 Předmět veřejné zakázky

2.1 Východiska

Předmětem poptávané dodávky je služba zajišťující realizaci zóny placeného stání (ZPS) na vymezeném území SMT spočívající v osazení Parkovacích technologií a dodání souvisejících informačních systémů (Parkovací Informační Systém – PIS) pro SMT a MSMT v souvislosti s řízením a správy klíčových informací v oblasti parkování silničních motorových vozidel. Konkrétně se jedná oblasti:

1. správa Parkovacích technologií a jejich propojení na PIS,

2. správa informací a pravidel souvisejících s organizací dopravy v klidu,

3. správa a evidence Parkovacích oprávnění,

4. správa vč. zúčtování plateb Parkového prostřednictvím Platebních kanálů,

5. aplikace a Zařízení pro pochůzkový monitoring pro MP.

Připravovaná první etapa zahrne v roce 2023 asi 2.000 parkovacích míst a asi 1.500 rezidentů a abonentů. Předmětem veřejné zakázky je také dílčí rozšiřování systému ZPS (v budoucnu je možné rovněž rozšíření systému ZPS na celé území SMT) a připravenost na budoucí integraci dalších forem monitoringu (zejm. se uvažuje o zavedení monitoringu prostřednictvím vozidel nesoucích snímací zařízení).

2.2 Obecné základní požadavky

● Veškeré dodávky, součásti parkovacích automatů, parkovacích technologií, HW i SW vybavení, které budou součásti PIS budou dodány ve formě poskytnutých služeb (jako software as service, tj. HW i SW plně ve správě Dodavatele mimo informační zázemí SMT). Dodávky musí být provedeny bez vyvolání významné zátěže na současnou informační infrastrukturu SMT (HW nebo SW);

● použitá infrastruktura a softwarová architektura (systémové schéma) musí být zdokumentována v rozsahu, který umožní zadavateli posoudit její technickou způsobilost a úplnost pro požadovaný záměr.

Územní rozsah a orientační umístění Parkovacích technologií pro úvodní plnění je obsažen

v Příloze č. 1 - Projekt zony placeneho stani Teplice 012023 A2-V6.pdf

Cíle nového systému:

• Minimální nároky na magistrát / město Teplice

• Externí financování

• Rozšíření stávajícího systému

• Modernizace parkovacího systému a všech činností

Omezení:

• Nutno respektovat právní prostředí České republiky

• Výkon státní moci není přenositelný na externí subjekty

• Přístup k základním registrům a RV je limitován na státní správu

Možná východiska:

• Maximální automatizace procesů

• Minimální podíl lidské práce

2.3 Základní dělba kompetencí / činností

SZPS musí být připraven na budoucí rozvoj, který ale nesmí vyžadovat změny v DSZPS vyjma změny nastavitelných parametrů. Jeho součástí proto musí být standardní rozhraní, prostřednictvím kterého budou DSZPS s SZPS komunikovat.

SZPS musí být připraven poskytovat vybraná data pomocí API, XML a datasetů jako OpenData. Rozsah poskytovaných dat bude stanovován postupně podle požadavků SMT.

SZPS musí umožňovat v režimu Drobného rozvoje PIS otevření standardních komunikačních rozhraní tak, aby bylo možné nad SZPS stavět další aplikace, ať už v režii města nebo třetí strany.

SZPS je základním zdrojem informací o oprávněních a cenách. Potřebují-li dílčí systémy takovou informaci, primárně ji získávají ze SZPS.

Obr. 1 Ideové schéma rolí SZPS a jeho vztahů k ostatním systémům.

Zadavatel zde uvádí představu, jak může být SZPS koncipován. Je na Dodavateli, jaké zvolí konkrétní řešení, budou-li splněny požadavky na plnění kladené ze strany Zadavatele.

2.4 Přehled a popis základních informačních systémů a vybavení používaných Zadavatelem

Pro lepší informovanost Xxxxxxxxxx, zejm. pro případ, že poskytnutí plnění ze strany Dodavatele bude vyžadovat propojení na stávající informační systémy či vybavení Zadavatele, uvádí Zadavatel tento stručný přehled:

Finanční odbor: Používá ekonomický systém ORSOFT Radnice, dodavatel ORTEX, Hradec Králové. Vlastní komunikace (předpisy – platby – pokladna, banka) tohoto systému probíhá se systémem GEOVAP (správa a vymáhání pohledávek), ten komunikuje se systémem VITA – přestupky.

Odbor správních činností – oddělení přestupků: Oddělení ke své činnosti používá program Vita – přestupky, který je propojen se spisovou službou E-spis a programem finančního odboru. Program Vita – přestupky se používá výhradně pro zpracování jednotlivě oznámených přestupkových případů.

Městská policie – SW na přestupky má vlastní a žádná další zařízení jako tablety, mobily apod. nemá.

2.5 Vlastní předmět veřejné zakázky

Dodavatel bude v rámci plnění předmětu veřejné zakázky povinen poskytnout Zadavateli

počáteční jednorázové plnění spočívající v:

• Parkovacích technologiích:

o 30 kusech Parkovacích automatů

o 14 kusech informačních stojanů

o 11 kusech informačních tabulí

o 1 kompletu Závorového systému;

• 4 kusech Zařízení pro pochůzkový monitoring;

• poskytnutí PIS vč. jeho zavedení (nastavení a implementace v rozsahu potřebném pro ZPS)

o modul správy parametrů a vymezení jednotlivých Parkovacích úseků,

o modul správy jednotlivých DSZPS,

o modul správy dlouhodobých Parkovacích oprávnění,

o modul nástroje pro dokumentaci a řešení porušení pravidel

o modul nástroje pro odhalování přestupků,

o modul vyúčtování,

o modul statistiky.

Dále bude Dodavatel poskytovat Zadavateli Periodické služby spočívající v:

● Službě Technického vybavení, sestávající se zejména z:

o správy, provozu, technické údržby a podpory Parkovacích technologií, včetně zajištění komunikace s PIS, doplňování spotřebního materiálu apod.,

o zajištění zúčtování plateb a správy finančních prostředků z vybraného Parkovného prostřednictvím Platebních kanálů napojených na PIS,

o správy, provozu a údržby Zařízení pro pochůzkový monitoring.

● Službě PIS, sestávající se zejména z:

o poskytnutí (ve formě umožnění užívání prostřednictvím vzdáleného přístupu)

a provozu PIS,

o zajištění zúčtování plateb a správy finančních prostředků z vybraného Parkovného prostřednictvím Platebních kanálů napojených na PIS,

o technické a uživatelské podpoře PIS, včetně provádění Servisních zásahů ve

vztahu k PIS, zálohování a obnovy,

o zajištění správy všech parametrů SZPS, ke kterým má přístup (výhrada zákonných omezení),

o Drobném rozvoji a podpoře aplikace PIS,

o zajištění všech komunikačních služeb mezi Parkovacími technologiemi a PIS.

Na vyžádání (na základě výzvy Zadavatele) poskytne Dodavatel dále jednorázová plnění

spočívající v:

● dodávce dalších PA, závorového systému, informačních tabulí nebo informačních stojanů nebo přemístění existujících PA, informačních tabulí nebo informačních stojanů,

● dodávce dalších Zařízení pro pochůzkový monitoring.

Detailní popis požadavků na dodávky, jednorázová plnění a služby SZPS je uveden v kapitole Povinné technické podmínky a je členěn do kapitol, které odpovídají výše uvedeným dílčím částem plnění veřejné zakázky na SZPS.

3 Povinné technické podmínky

3.1 Parkovací automaty

č.	Podmínka	Způsob doložení
1.	Dodavatel SZPS dodá Parkovací automaty splňující požadované technické podmínky, a to v počtu uvedeném části 2.5. těchto Technických podmínek zadavatele.	Prohlášení Dodavatele
2.	Dodavatel dodané Parkovací automaty instaluje dle Projektu instalace PA, který mu poskytne Zadavatel nejpozději 30 dnů před předpokládaným zprovozněním SZPS, a to včetně úprav povrchu v bezprostředním okolí PA.
3.	Dodavatel uvede instalované PA do provozu včetně nastavení provozních parametrů dle požadavků Zadavatele v termínu dle Smlouvy.
4.	Plnění dle bodů 1. až 3. výše budou zprovozněná k užívání, což bude potvrzeno Zadavatelem v akceptačním řízení upraveném v čl. 6. Smlouvy.
5.	Povolení k osazení pevné překážky na pozemní komunikaci zajistí Zadavatel nejpozději 30 dní před termínem, kdy má dle Smlouvy dojít k dodání Parkovací technologie (vč. její instalace, propojení a implementace v rámci PIS).
6.	Dodávky PA musí splňovat veškeré požadavky vyplývající z národní legislativy, legislativy ES a příslušných technických norem ČSN, ČSN EN a ČSN ISO.
7.	Parkovací automaty musí splňovat požadavky dle následujících standardů: • ČSN EN 12414 – Zařízení ke kontrole parkování vozidel – Automaty pro platbu a výdej Parkovacích lístků – Technické a funkční požadavky
8.	Veškeré komunikace PA s PIS budou probíhat formou zabezpečených webových služeb. Zadavatel neurčuje zda mezi PA a PIS bude integrován vlastní SW výrobce PA.
9.	Veškeré plnění realizované formou dodávky bude řádně zdokumentováno. Dokumentace včetně dokumentace skutečného provedení bude předána Zadavateli. Součásti akceptačního protokolu dodávek PA je vždy i dokumentace skutečného provedení stavby včetně geodetického zaměření.

10.	PIS musí být schopen přijímat, ukládat a zpracovávat minimálně: • zjištění provozního stavu libovolného PA k datu a času s časovou tolerancí danou systémovým parametrem, minimálně: ❖ Aktivní (+ stavové informace, např. Stav zásoby papíru pro tisk PL). ❖ Porucha + typ poruchy. ❖ Odstavený. ❖ Otevřený (otevření plánované = Servisní zásah, otevření neplánované = neautorizovaný zásah). • Stav Parkovného vybraného podle Platebních kanálů. • Stav zdroje elektrické energie. • Pravidelné hlášení každého PA ve lhůtě max. 24 hodin.
11.	Parkovací automat musí poskytovat automatické detekční funkce pro specifické stavy, které ON-LINE posílá do PIS: • Výběr hotovosti (autorizované otevření prostoru s pokladnou). • Autorizovaný zásah (autorizované otevření servisního prostoru, údržba, oprava). • Neoprávněný zásah (násilné otevření jakéhokoli prostoru). • Neautorizovaný zásah (nepovolený zásah do HW, SW, firmware …). • Závada (automatická detekce). Následně po detekci stavu proběhne: • Záznam do vlastní paměti, • Přenos informace do PIS, Obranná reakce (např. reset při závadě).
12.	Při dostupnosti PIS v prostředí veřejného internetu musí být informace o Parkovacích relacích předány z PA do PIS v časovém limitu daném systémovým parametrem PA_T_REL2PIS.
13.	Parkovací automat musí splňovat požadavky na provedení: • Provedení pro venkovní prostředí (déšť, sníh, slunce). • Maximální hloubka zástavby je 0,7 m. • Doba životnosti Parkovacího automatu – min. 10 let. • Minimální úroveň recyklovatelnosti použitých materiálů – 80%. • Alfanumerická klávesnice umožňující zadat RZ v latince.

	• Identifikační číslo PA – jednoznačné, unikátní. • Informace a komunikace v jazyce českém, německém a anglickém.
14.	Parkovací automat musí splňovat požadavky na systémové podmínky: • PA musí mít autonomní nezávislé napájení bez nároků na připojení k veřejné energetické síti. • PA musí mít funkce řízení spotřeby, tj. minimálně musí být schopen provozu v režimu nízké spotřeby v obdobích klidu a musí být schopen přechodu do aktivního stavu za dobu max. 2 sec. • PA musí být prostřednictvím webových služeb připojen k PIS. • Synchronizace času s centrálním systémem.
15.	Parkovací automat musí poskytovat testovací funkce pro: • mince – test testovacími mincemi nominálních hodnot, • bezkontaktní platební karty – test testovacími kartami akceptovaných standardů • platební karty – test testovacími kartami akceptovaných standardů (pokud je parkovací automat jimi vybaven) V rámci procesu testování proběhne: • tisk servisního kontrolního lístku, • záznam do vlastní paměti, • přenos informace do PIS za dobu max. 10 sec.
16.	PA musí umožnit zadat informace o Parkovací relaci v rozsahu: • volba jazyka • RZ • délka Parkovací relace (viz ČSN EN 12414) • platební kanál PA musí být schopen ověřit oprávněnost Parkovací relace z hlediska limitů platných v Úseku ZPS pro danou RZ (tj. musí být schopen odmítnout zadání parkovací relace pro danou RZ pokud ji platná pravidla nedovolují). Rozhraní pro ověření oprávněnosti parkování poskytuje PIS. Případné odmítnutí nebo časové omezení Parkovací relace musí PA sdělit parkujícímu do PA_T_ODMITNUTI (hodnota parametru viz tabulka požadovaných systémových parametrů)
17.	Dodavatel SZPS je povinen zajistit, aby PA stanovoval cenu za Parkovací relaci podle ceníku spravovaného PIS.

18. PA musí umožnit zaplatit cenu za Parkovací relaci. • hotově nejméně v 8 nominálních hodnotách se zabezpečeným vhozem mincemi v Kč (1,2,5,10,20,50Kč) a EUR (1,2Eur), • bezkontaktními platebními kartami minimálně VISA a Mastercard, případně čipovými kontaktními kartami VISA a Mastercard • DS je povinen nabídnout PA umožňující dovybavení čtečkou karty dle standardu ISO/IEC 14443 pro její využití pro placení Parkovného a veškerý potřebný SW a licence (pokud to nebude umožněno již splněním požadavku dle předchozí odrážky).

3.2 Informační stojany

č.	Podmínka	Způsob doložení
19.	Dodavatel je povinen dodat informační parkovací stojany v designu a provedení stanoveném Zadavatelem. Vlastní grafické provedení zajistí Dodavatel a podléhá schválení Zadavatele, které musí být učiněno nejpozději 15 dnů před plánovanou instalaci stojanu. Vzor informačního stojanu – pouze ilustrativní:	Prohlášení Dodavatele
20.	Povolení k osazení pevné překážky na pozemní komunikaci zajistí Zadavatel nejpozději 30 dní před termínem, kdy má dle Smlouvy dojít k dodání Parkovací technologie (vč. její instalace, propojení a implementace v rámci PIS).

21.	Rozměry informačního stojanu (čtyřboký hranol se zakrytím) budou 40 x 30 x 180 cm
22.	Ukotvení stojanu se přepokládá na betonový základ 50x50x50 cm, nebo pomocí hmoždinek a vrutů. Pokud bude stojan osazen do prostoru zeleně, bude povinnosti Dodavatele zajistit zpevnění plochy pomocí betonové dlažby a parkových obrubníků.
23.	Materiál stojanu bude ocelový plech s povrchovou úpravou zaručující 10-letou životnost a současně možnost změny polepu v intervalu 1 x ročně. Polep musí umožnit odstranění vandalských napadení – zejména užití barvy ve spreji, případně přelepy samolepkami.

3.3 Informační tabule

č.	Podmínka	Způsob doložení
24.	Dodavatel je povinen dodat informační tabule v designu a provedení stanoveném zadavatelem. Vlastní grafické provedení zajistí Dodavatel a podléhá schválení Zadavatele, které musí být učiněno nejpozději 15 dnů před plánovanou instalaci stojanu. Vzor informační tabule – pouze ilustrativní:	Prohlášení Dodavatele
25.	Povolení k osazení tabulí na sloupy veřejného osvětlení, nebo trakčního vedení zajistí Zadavatel nejpozději 30 dní před termínem, kdy má dle Smlouvy dojít k dodání Parkovací technologie (vč. její instalace, propojení a implementace v rámci PIS).
26.	Rozměry informačních tabulí budou 50x50 cm
27.	Upevnění tabulí na sloupy VO / trakčního vedení bude pomocí standardních objímek a úchytů používaných pro dopravní značení.

28. Materiál tabulí bude ocelový plech s povrchovou úpravou zaručující 10-letou životnost a současně možnost změny polepu v intervalu 1 x ročně. Provedení tabulí bude obsahovat lemování podobně jako běžné dopravní značení.

3.4 Závorové systémy

č.	Podmínka	Způsob doložení
29.	Základní obsah realizace • 1 x automatická pokladna v blízkosti vjezdu/výjezdu umístěná pod přístřeškem. • Závorový systém (vjezd, výjezd) umístěný na ostrůvku společně s kamerami pro čtení RZ a vjezdovým a výjezdovým stojanem. Kamery pro čtení RZ budou umístěny přímo dole na ostrůvku. • Na vjezdu u parkoviště bude LED návěstidlo s informací VOLNO / OBSAZENO. Systém bude muset umět generovat informaci (protokol) ke zpracování obsazenosti do informačních tabulí externího navigačního systému, který tyto informace bude přebírat z PIS. • Integrace závorového systému do PIS zajišťující kompletní datovou vazbu mezi ZS a PIS, a to od úrovně jednotlivých transakcí. • Nutné minimálně hlasové propojení parkoviště na Dodavatele. • Součásti realizace je také stavební připravenost včetně nezbytných přípojek NN, případně připojení do sítě internetu, pokud nebude použito GPS připojení. • Požadovaná dostupnost služby je totožná jako v případě Parkovacích automatů: PA_DOSTUP. • Závorový systém bude umožňovat bezkontaktní a bezhotovostní platby prostřednictvím systémů 3. stran. • Pokud není uvedeno jinak, platí pro Závorové systémy všechny ostatní podmínky definované výše pro Parkovací automaty – zejména komunikace s PIS, dostupnost transakčních informací, provozních stavů, bezhotovostních plateb a podobně.	Prohlášení Dodavatele
30.	Požadované funkce automatické pokladny: V platebním terminálu (pokladně) bude možné platit v hotovosti, a to mincemi CZK + 1€ a 2€ a bankovkami 100 – 1000 Kč. Vydávat bude pokladna jen mince v množství maximálně možném v souladu s platnou

	legislativou (do úměrného počtu vydaných mincí). Pokladna bude taktéž umožňovat platbu bankovní kartou v bezkontaktním styku a klasickou formou za použití klávesnice s PIN. Pokladna bude disponovat přehledným, nejméně 2 řádkovým displejem, či grafickým displejem. Pokladna musí umět vytisknout daňový doklad, kdy tento doklad musí být odlišný od parkovacího lístku. Ostatní požadavky: • Přepínání minimálně 3 druhů jazyků (výchozí čeština, dále angličtina a němčina). • Dorozumívací zařízení VoIP umožňující připojení na pracoviště Dodavatele. • Prosvětlený LCD displej o min. velikosti 2x 20 znaků.
31.	Vjezdový stojan: • Výdejní mechanizmus kartového papírového lístku pro krátkodobé parkování s čárovým kódem či jiným nositelem informace o parkovací relaci, kdy výdej lístku včetně vytištění /kódování časových údajů, RZ vozidla a unikátního čísla lístku musí být menší jak 2,0 sec • Systém proti zneužití funkce stojanu, tj. aktivace stojanu je možná pouze v přítomnosti vozidla na indukční smyčce, včetně hlášení, jestliže vozidlo nevjede do parkingu • Funkci úsporný režim, kdy v klidovém stavu musí stojan odebírat maximálně 30 W, bez vyhřívání • Zásobník lístků pro minimálně 10.000 ks ve 2 boxech vždy po minimálně 5.000 ks lístků, s automatickým přepínáním, je-li jeden box prázdný • Rozměr papírového lístku musí být cca ve velikosti kreditní karty, přičemž maximální délka lístku musí být 86 mm a jeho šířka 55 mm, váha použitého papíru musí být minimálně 160g/m2, s možností barevného potisku • Prosvětlený LCD displej o velikosti minimálně 2 x 20 znaků • Prosvětlené tlačítko pro výdej lístků • Dorozumívací zařízení VoIP umožňující připojení na pracoviště Dodavatele
32.	Výjezdový stojan: • Polykací čtecí jednotku papírového lístku pro krátkodobé parkování s nosičem informace o parkovací relaci s možností čtení ze všech 4 stran, kdy rychlost příjmu lístku musí být max. do 0,7 sec,

	kdy vložení lístku je možné provést libovolnou stranou • Stojan musí umožňovat "spolknutí parkovacího lístku" • Funkci úsporný režim, kdy v klidovém stavu musí stojan odebírat maximálně 30 W, bez vyhřívání • Zásobník „polknutých“ lístků pro uložení minimálně 5.000 ks použitých lístků • Prosvětlený LCD displej o velikosti minimálně 2 x 20 znaků • Dorozumívací zařízení VoIP umožňující připojení na pracoviště Dodavatele
33.	Kamery pro čtení registračních značek: • Progresivní skenování v rozlišení nejméně 725 x 480 pro zajištění kvality obrazu a čtení • Infrapřisvícení pomocí LED (850 nm), délka impulsu při čtení RZ vozidla 1ms • Plnou integraci do řídícího serveru parkovacího systému a prostřednictvím něho do systému PIS • Spolehlivost čtení RZ min. 96 % • Možnost „bezlístkového“ odbavení uživatelů registrovaných v PIS s následným proúčtováním přes PIS
34.	Závorový stojan / závora: • Délka břevna až do max. 3,5 m, rovné, hliníkové provedení • Doba otevření / zavření do max. 1,3 sec při délce břevna do 3,0 m • Možnost manuálního ovládání přímo ze stojanu • Automatické, mechanické i elektrické zablokování břevna v koncových pozicích • Vylamovací mechanizmus v případě nárazu vozidlem • Sledování vylomení břevna • Rozhraní pro komunikaci s kontrolním stojanem • Alarmové hlášení v případě poruchy stojanu, a to i v případě výpadku dat či el. energie • Závoře se musí, při výpadku napájení, automaticky zvednout do polohy minimálně 50° (tak ať projede vozidlo do 3,5 t) • Závora se musí samovolně, při naražení do předmětu pod ní, automaticky zvednout nahoru

3.5 Zařízení pro pochůzkový monitoring

č.	Podmínka	Způsob doložení
35.	Dodavatel dodá 4 ks HW mobilních zařízení (MZ) pro strážníky MP pro ruční monitoring parkování, které poslouží pro sběr potřebných dat pro další zpracování podezření na spáchání přestupku na místě, nebo prostřednictvím správního odboru. Poskytovatel PIS zajistí jak dodávku zařízení, tak i jejich údržbu s výhradou dobíjení akumulátorů a konektivity potřebné pro výměnu dat mezi MP a PIS. • Zařízení bude poskytovat minimálně tyto funkce: 1. standardní hlasové, datové funkce a lokalizační funkce mobilního telefonu v sítích GSM; 2. fotoaparát s implementovaným OCR modulem pro čtení RZ a její převod do textového řetězce • Maximální hmotnost zařízení nesmí překročit 500g, a to bez případných periferií. • Provozní teplota zařízení musí být v rozmezí -20°C až 50°C. • Zařízení musí vyhovovat odolnosti vůči pádu dle standardů MIL-STD- 810F, a to pro opakovaný pád z výšky minimálně 1,2m. • Zařízení musí splňovat podmínky stupně krytí dle standardu IEC 60529 minimálně IP54. • Rozlišení dotykového displeje musí být minimálně 720 x 1440 px. • Úhlopříčka displeje musí činit minimálně 5,5“. • Datové přenosy minimálně třídy 5G. • Wi-fi a/b/g/n/ac • Bluetooth třída 5.0. • Kapacita baterie musí zajistit výdrž alespoň 12 hod. bez potřeby dobíjení po celou dobu své životnosti. Počet „přečtených RZ“ a následně zpracovaných přenosů je 1.200, z toho u 240 je předpoklad pořízení dokumentace pro přestupkové řízení. Dodávka baterií musí být zajištěna po dobu životnosti zařízení, a to alespoň 4 roky. • Vnitřní využitelná paměť zařízení musí činit alespoň 32 GB. • Operační paměť zařízení musí činit alespoň 3 GB.	Prohlášení Dodavatele

• Paměťové karty dle obvyklých standardů SD / SDHC, MMC. Maximální podporovaná velikost karty nesmí být nižší než 32GB.

• Zařízení musí obsahovat GPS modul.

• Se zařízením musí být dodáván stylus pro ovládání v rukavicích a/nebo rukavice se speciální plochou pro ovládání displeje.

• Rozlišení fotografií minimálně 5 Mpx

• Funkce automatického ostření.

• Blesk/přisvětlovací dioda účinná v okruhu alespoň

3m.

3.6 Parkovací informační systém

3.6.1 Základní požadavky na PIS

č.	Podmínka	Způsob doložení
36.	Dodavatel je povinen dodat takové řešení, které zajistí dostupnost SZPS v úrovni systémového parametru SZPS_DOST. Pro vyloučení pochybností se uvádí, že na míru dostupnosti nemá vliv skutečnost, zda ze strany Zadavatele došlo k zadání Požadavku na Servisní zásah; zajištění požadované míry dostupnosti je výlučně na odpovědnosti Dodavatele.	Prohlášení Dodavatele
37.	Navržené řešení musí splňovat obecně definované „Požadované systémové parametry“, jedná se hlavně o tyto parametry: ● SZPS_PREL Počet záznamů Parkovacích relací ● SZPS_ZOP Počet Záznamů o parkování (Monitoring ZPS) ● SZPS_DOST Minimální dostupnost SZPS ● SZPS_DATA Povolená ztráta dat ● SZPS_VRATKA Lhůta pro vrácení nerozpoznaných plateb na Správcovském účtu ● SZPS_KONTROLA Lhůta pro vnitřní zpracování dotazu na oprávněnost Parkování dané RZ v daném čase na daném místě.
38.	Z hlediska výkonnostních parametrů musí být SZPS navržen tak, že bude schopen s rezervou uvedené parametry zajistit, bez ohledu na výpadky nebo problémy HW a SW infrastruktury na straně Dodavatele. Dodavatel je plně požadovanými parametry (vč. parametrů týkajících se úrovně provozu a servisu, tzv. XXX) a je na jeho odpovědnosti navrhnout HW a SW architekturu tak, aby byl dostupný a plně funkční (dle požadavků v této dokumentaci) v souladu požadovanými parametry.

39.	PIS musí být navržen a musí splňovat, resp. umožnit splnit, je-li k tomu potřeba součinnost zadavatele nebo třetí strany, všechny povinnosti dle právního řádu, včetně povinností v oblasti ochrany osobních údajů a jiných dat, kybernetické bezpečnosti, informačních systémů veřejné správy apod., které vyplývají zejména (nikoliv výlučně) ze zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů, zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů, a nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne 27. dubna 2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů).	Prohlášení Dodavatele Spadá-li nabízené řešení pod definici cloud computingu dle zákona č. 365/2000 Sb., předloží dodavatel v rámci nabídky doklad o tom, že nabízené řešení bylo řádně zapsáno coby nabídka cloud computingu v katalogu cloud computingu.
	Dodavatel je povinen dokumentovat splnění těchto požadavků, zejména přijatá bezpečnostní opatření, a na vyžádání tuto dokumentaci předložit Zadavateli.
40.	Návrh infrastruktury musí být dokumentován v rozsahu, který umožní Zadavateli mít dostatečný přehled o navrhované infrastruktuře a posoudit její technický návrh a úplnost. Dodavatel je povinen tuto dokumentaci na vyžádání předložit Zadavateli.	Prohlášení Dodavatele

3.6.2 Realizace PIS

V rámci realizace PIS je požadována dodávka minimálně následujících služeb:

č.	Podmínka	Způsob doložení
41.	Dodavatel navrhne akceptační testy na základě zadávací dokumentace a tyto podléhají schválení Zadavatele.	Prohlášení Dodavatele
42.	Před uvedením systému PIS do ostrého provozu je nutné, aby Dodavatel v součinnosti se Zadavatelem realizoval
	všechny testovací scénáře a akceptační testy byly úspěšně
	provedeny.
43.	Dodavatel je povinen uvést systém do produktivního provozu, zajistit potřebná nastavení a přístupy pro
	všechny pracovníky Zadavatele, a to při minimalizaci
	dopadů na provoz Zadavatele.

3.7 Obecné požadavky na PIS

č.	Podmínka	Způsob doložení
44.	Veškeré komunikace PIS s vlastními moduly, DSZPS a externími aplikacemi jimi iniciované, musí probíhat prostřednictvím zabezpečených webových služeb s využitím standardních šifrovacích algoritmů a kontrolou validity a integrity přenášených dat.	Prohlášení Dodavatele

	Veškerá komunikace s externími aplikacemi musí být logována pro případný audit a řešení problémů.
45.	PIS musí být synchronizován na externí časový zdroj. Externím časovým zdrojem bude standardní NTP server, který může sloužit pro veškeré komponenty řešení.
46.	PIS musí být dokumentován v rozsahu, který umožní Zadavateli mít dostatečný přehled o vlastnostech PIS a možnostech jeho dalšího rozvoje.

3.7.1 Komunikace s externími systémy a DSZPS

č.	Podmínka	Způsob doložení
47.	PIS musí být schopen získávat data ze základních registrů ROB, ROS, RUIAN. Zadavatel poskytne veškerou potřebnou součinnost. Případné zpoždění připojení PIS k registrům ROB, ROS, RUIAN však nesmí mít vliv na možnost PIS používat v požadovaných termínech. V takovém případě musí mít PIS uživatelské rozhraní, které umožní potřebná data vkládat a ověřovat je pomocí fyzických dokladů.	Dodavatel popíše způsob a podmínky získávání dat ze základních registrů ROB, ROS, RUIAN. Odkaz na prvek aplikační architektury, subset LDM a proces BPM.
48.	PIS musí být schopen hromadně odesílat zprávy prostřednictvím emailů. Odesílání emailů může být zajištěno přímo v SZPS nebo externí službou. V případě využití externí služby náklady platí Dodavatel.	Odkaz na prvek aplikační architektury, subset LDM a proces BPM.
49.	V rámci dodávky PIS musí být dodány webové služby pro příjem dat o Parkovacích relacích, zajišťující požadavky uvedené v sekci „Parkovací relace“, s kapacitou danou systémovým parametrem SZPS_PREL.	Odkaz na prvek aplikační architektury, subset LDM a proces BPM. Popis rozhraní webové služby.
50.	V rámci dodávky PIS musí být dodány webové služby pro příjem dat o záznamech o Parkování zajišťující, s kapacitou danou systémovým parametrem SZPS_ZOP.	Odkaz na prvek aplikační architektury a na prvky LDM a PM.
51.	PIS poskytne DSZPS a externím systémům zabezpečenou webovou službu pro ověřování oprávněnosti Parkování RZ v daném čase a na daném místě. Vnitřní zpracování dotazu musí být kratší než systémový parametr SZPS_KONTROLA	SZPS Popis webové služby.

3.7.2 Konfigurace PIS

č.	Podmínka	Způsob doložení
52.	PIS musí umožňovat správu informací o území, ve kterém budou ZPS provozovány. V první řadě jde o evidenci ulic,	Prohlášení Dodavatele. Odkaz na prvek aplikační
	adres (čísel popisných a orientačních včetně zeměpisných	architektury a na prvky LDM
	souřadnic) a městských částí.	a PM.
53.	PIS musí umožňovat správu Parkovacích oblastí, Rezidentních oblastí a Úseků ZPS. Musí udržovat plnou
	historii vztahů mezi oblastmi a Úseky ZPS.

	Základní a nejmenší územní jednotkou ZPS je Úsek ZPS. Úseky ZPS se nesmí překrývat. Jeden Úsek ZPS je část jedné ulice patřící právě do jedné Parkovací oblasti, pro kterou platí jednotná pravidla Parkování. Úsek ZPS může být dále členěn na části a to z důvodu odlišení parkovacích stání, jednoznačného vymezení křižovatkami a odlišení jiných částí ulice, které k Parkování neslouží (vjezdy, vyhrazená parkovací stání,…). Každému Úseku ZPS jsou přiřazeny minimálně následující parametry: - Rezidentní oblast, - Parkovací oblast, - ulice, - adresy, - počet parkovacích míst a jejich typ (podélné, šikmé, kolmé), - provozní doba, - ceník POP, - ceník návštěvnického Parkovného, - maximální doba Parkování Návštěvníků, - hranice Úseku ZPS, - Výluky z režimu parkování (zvláštní užívání, zákazy vyplývající z obecné úpravy provozu, pevné překážky, …).
54.	PIS musí umožňovat správu informací o dopravních značkách souvisejících se ZPS. Informace o dopravní značce musí mít minimálně parametry: - typ, - zeměpisné souřadnice, - historie platnosti, - aktuální fotodokumentace - historie fotodokumentace.
55.	PIS musí umožňovat vizualizaci Úseků ZPS, částí Úseků ZPS, Parkovacích oblastí, Rezidentních oblastí, ulic, adres, dopravních značek a dalších objektů (např. Parkovacích automatů) jako vrstev na mapovém podkladu.
56.	PIS musí umožňovat správu ceníků POP a uchovávat plnou historii cen. Cena POP musí být parametrem minimálně délky platnosti POP, kategorie vozidla (emise, délek, …), kategorie oblasti, účelu Parkování, pořadí RZ daného subjektu a typu POP (dimenze ceníku).
57.	PIS musí umožňovat správu ceníků návštěvnického Parkování a uchovávat plnou historii cen. Cena musí být parametrem minimálně délky Parkování, období Parkování, kategorie vozidla (emise, délka, …), kategorie uživatele a kategorie Úseku (dimenze ceníku).

58.	Dimenze ceníku musí mít charakter číselníků a musí je být možno spravovat přes uživatelské rozhraní PIS.
59.	PIS musí umožňovat správu Parkovacích technologií a jejich přiřazení konkrétním Úsekům. Každá Parkovací technologie může být přiřazena k více Úsekům.

3.7.3 Parkovací oprávnění

č.	Podmínka	Způsob doložení
60.	Žádosti o POP mohou být podávány prostřednictvím externích systémů. PIS pro tento účel externím systémům poskytne webové služby. PIS musí mít funkcionalitu také pro manuální zpracování žádostí o POP. Žádost může mít tištěnou nebo elektronickou formu. Které typy žádostí o POP se zpracovávají manuálně, obsah žádosti, podmínky schválení a obsah osvědčení je stanoveno metodikou ZPS SMT. Ke schválené žádosti vystavuje PIS výhradně pro potřebu držitele POP osvědčení, které obsahuje údaje o držiteli, územní rozsah platnosti, časovou platnost a RZ.	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury a na prvky LDM a PM. Popis rozhraní webové služby.
61.	PIS musí mít funkcionalitu pro automatické zpracování elektronických žádostí o POP. Které typy žádostí o POP se zpracovávají automaticky, obsah žádosti, podmínky schválení a obsah osvědčení je stanoveno metodikou ZPS SMT. Žádosti mohou být podávány i prostřednictvím externích systémů. PIS pro tento účel externím systémům poskytne webové služby. Typickými příklady žádostí schvalovaných automatickým procesem jsou žádosti o krátkodobé návštěvnické Parkování podané prostřednictvím PA nebo VPH. I tyto žádosti ale mohou být odmítnuty, např. pro přečerpání časového limitu Parkování dané RZ v oblasti. Ke schválené žádosti vystavuje PIS výhradně pro potřebu držitele POP osvědčení, které obsahuje údaje o držiteli, územní rozsah platnosti, časovou platnost a RZ.
62.	PIS musí mít funkcionalitu pro manuální vytváření POP na základě schválených žádostí a úhrady POP. K vydanému POP vystavuje PIS výhradně pro potřebu držitele POP osvědčení, které obsahuje číslo žádosti, územní rozsah platnosti, časovou platnost a RZ. Osvědčení má formu stejnou, jako žádost (tištěná nebo elektronická). Typickými příklady manuálního vytváření jsou POP vytvářená na základě žádostí, které zakládají pouze právo uživatele POP vytvářet, ale jinak POP automaticky nevznikají (např. pečovatelská POP, zásobovací POP, …).
63.	PIS musí mít funkcionalitu pro automatické vytváření POP na základě schválených žádostí a úhrady POP. K vydanému POP vystavuje PIS výhradně pro potřebu držitele POP osvědčení, které obsahuje číslo žádosti,

	územní rozsah platnosti, časovou platnost a RZ. Osvědčení má formu stejnou, jako žádost (tištěná nebo elektronická). Typickými příklady automatického vytváření POP jsou POP vytvářená na základě schválených žádostí Rezidentů, Vlastníků nemovitostí, Abonentů a žádostí z PA a VPH.
64.	K jedné žádosti může být vydáno více POP, ke každému POP může být přiřazena jedna nebo více RZ, avšak za podmínky, že pro parkování v daném okamžiku může být využita pouze 1 konkrétní RZ. K jedné RZ může být vydáno více POP.
65.	PIS musí mít funkcionalitu pro vydávání POP pro Parkovací oblasti a celé ZPS pro Rezidenty podle místa trvalého pobytu, vždy v souladu s nařízením SMT o zřízení ZPS a platnou metodikou pro vydávání POP vydanou SMT.
66.	Ke schváleným žádostem musí umožnit PIS evidovat naskenované přílohy.
67.	Úhrady za POP se provádějí na základě vystavených předpisů úhrady. Předpis může mít elektronickou i tištěnou formu. Platnost POP začíná dnem úplné úhrady nebo dnem požadovaného počátku platnosti POP. Rozhodující je pozdější datum. PIS musí umožnit přiřazovat POP úhrady provedené hotově nebo platební kartou na výdejnách POP nebo bankovním převodem. PIS musí umožňovat načítat data o platebních transakcích ve standardních formátech (XML, ABO).
68.	PIS musí umožnit podání žádosti o změnu parametrů POP při splnění podmínek stanovených metodikou ZPS. Mohou se měnit parametry, délka platnosti a dočasně RZ. Změna parametrů se provádí na základě žádosti podané na výdejně POP, prostřednictvím OSU nebo prostřednictvím externích systémů. PIS poskytne externím systémům pro jednotlivé změny webové služby. Schválení žádosti o prodloužení POP vyžaduje ověření splnění podmínek stejných jako při žádosti o nové POP. Nové POP je pak vytvořeno na základě schválené žádosti a úhrady za prodloužení podle předpisu. Automatické ověření trvalého bydliště resp. sídla provozovny musí být prováděno systémově proti základním registrům. Při zkrácení platnosti POP vystaví PIS předpis na vratku podle metodiky ZPS. Dočasná změna RZ je zpoplatněna podle ceníku.
69.	PIS musí umožňovat aktivní upozorňování držitele POP na blížící se expiraci POP prostřednictvím elektronických kanálů. Držitel musí sám zadat příslušné adresy, tj. mobil nebo email při podávání žádosti, prostřednictvím OSU nebo externími kanály. PIS poskytne pro zadání kontaktních údajů externím systémům zabezpečenou webovou službu. Informace proběhne nejméně jednou, a to ve lhůtě podle nastavitelného parametru.

3.7.4 Parkovací relace

č.	Podmínka	Způsob doložení
70.	PIS musí poskytovat webové služby pro podání žádosti o Parkovací relaci prostřednictvím PA, ZS, VPH nebo externího systému. PIS vrací informaci o časovém rozsahu schválení. Webové služby musí umožnit zajistit, aby informace o Parkovací relaci v PIS odpovídaly stavu procesu na PA, ZS, VPH či v externím systému, který může být jak dokončen tak přerušen. Zdrojem informací o výši Parkovného je primárně PIS, protože Parkovné může záviset nejenom na místě a čase, ale i na RZ. PIS proto musí podporovat dvoustupňový proces vzniku parkovací relace, tj. nejdříve schválení včetně podmínek (časový rozsah a Parkovné) a založení Parkovací relace na základě garance zaplacení. Garancí zaplacení se míní, že parkovací relace bude do PIS přijata pouze tehdy, když se Provozovatel platebního kanálu, tj. příjemce úhrady za parkovací relaci, neodmítnutelně prostřednictvím elektronického podpisu, včetně časového razítka zaváže, že Provozovateli ZPS v plné výši odvede Parkovné za tuto parkovací relaci.	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury a na prvky LDM a PM. Popis rozhraní webových služeb. Popis zajištění neodmítnutelnosti garance.
71.	PIS musí umožnit ve lhůtě dané parametrem systému po ukončení Parkovací relace její prodloužení na PA, ZS, VPH nebo externím systému a poskytne k tomu webovou službu.	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury a na prvky LDM a PM. Popis rozhraní webové služby.
72.	PIS musí být připraven pro evidenci parkovacích relací se zahraniční RZ. Systém kódování je vyžadován jeden z UTF standardů, doporučen je UTF-8.	Prohlášení Dodavatele.

3.7.5 Monitoring

č.	Podmínka	Způsob doložení
73.	PIS musí být připraven přijímat informace o Parkování vozidel ze systémů DSZPS (Záznamy o parkování) a porovnávat je s POP. V případě, že nenalezne k Záznamu o parkování platné POP, záznamy o parkování označí. PIS pro DSZPS poskytne webovou službu, kterou bude Záznamy o parkování přijímat. Po dobu stanovenou systémovým parametrem musí PIS evidovat všechny záznamy o Parkování. Parametry záznamu o Parkování jsou:	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury a na prvky LDM a PM. Popis rozhraní webové služby.
	● místo Parkování určené úsekem GNSS souřadnice,
	● datum a čas,
	● RZ vozidla (v případě nerozpoznání, údaj „neurčené vozidlo“).

74.	PIS musí poskytovat informace MP pro místní vyšetření záznamů o parkování, ke kterým nebylo nalezeno POP. PIS pro tento účel poskytne jak webovou službu pro externí systémy, uživatelské rozhraní a také mobilní zařízení.
75.	V případě, že Záznam o parkování, ke kterému nebylo nalezeno platné POP, byl pořízen na Úseku ZPS, na kterém je potřeba provést opakované zjištění s časovým odstupem daným systémovým parametrem, PIS musí dohledávat následné Záznamy o parkování bez platného POP a sdružovat je do jednoho Podezření ze spáchání přestupku. V případě, že Záznam o parkování, ke kterému nebylo nalezeno platné POP, byl pořízen na Úseku ZPS, který nevyžaduje opakované zjištění, PIS založí Podezření ze spáchání přestupku.
76.	Stane-li se Záznam o parkování Podezřením ze spáchání přestupku, musí k němu PIS umožnit doplnit rozšiřující parametry: ● fotografie s detailem RZ, ● datum a čas pořízení fotografie s detailem RZ, ● situační fotografie parkujícího vozidla včetně vodorovného dopravního značení (VDZ), ● datum a čas pořízení situační fotografie parkujícího vozidla, ● situační fotografie dokumentující stav dopravního značení upravující Parkování na daném Úseku ZPS, ● datum a čas pořízení situační fotografie dopravního značení, ● adresa místa podezření ze spáchání přestupku (ulice, číslo popisné). PIS pro DSZPS poskytne webovou službu, kterou bude rozšiřující parametry přijímat.
77.	Z Podezření ze spáchání přestupku, které se odehrálo na jednom místě v nepřerušované řadě Záznamů o parkování z daného místa, PIS musí vytvořit dokumentační balíčky obsahující všechny dokumenty potřebné pro odhalení a řešení přestupku.

3.7.6 Uživatelé

č.	Podmínka	Způsob doložení
78.	PIS musí umožňovat nezávislou správu interních uživatelů. Interní uživatelé jsou zařazováni do skupin uživatelů, ke kterým jsou přiřazována práva k funkcím PIS. Interní uživatelé mají přiřazena také práva k datům podle jejich organizačního zařazení.	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury a na prvky LDM a PM.

79.	Autentizace interních uživatelů musí být dostatečně bezpečná, aby nebylo možné zpochybňovat záznamy o činnosti (logování) interní uživatele v PIS. Včetně možnosti odesílání formátovaných (číselník zpráva a přesný formát) auditovacích zpráv do nadřízeného systému pro zpracovávání bezpečnostních logů (SIEM).	Prohlášení Dodavatele. Popis metody autentizace
80.	PIS musí zajistit zaznamenání (logování) všech podstatných činností interního uživatele, především autorství dat v PIS a přístup k osobním údajům. Včetně možnosti odesílání formátovaných (číselník zpráva a přesný formát) auditovacích zpráv do nadřízeného systému pro zpracovávání bezpečnostních logů (SIEM).	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury a na prvky LDM a PM.
81.	PIS musí umožnit správu externích uživatelů přistupujících k OSU. V případě, že externí uživatel má mít přístup přes OSU k POP, musí dojít k ověření jeho totožnosti a vztahu uživatele k subjektu, kterému bylo POP vydáno (fyzická osoba, statutární orgán, …). Ověřování totožnosti bude probíhat prostřednictvím Portálu národního bodu pro identifikaci a autentizaci v souladu se zákonem č. 250/2017 Sb., o elektronické identifikaci, ve znění pozdějších předpisů, nebo na výdejnách POP. Po ověření totožnosti bude uživateli zřízen uživatelský účet a vydány / předány přihlašovací údaje. Autentizace externích uživatelů při přístupu na OSU je prováděna s minimální bezpečnostní úrovní uživatelské jméno/heslo. PIS musí také umožnit autentizaci externího uživatele prostřednictvím využití služby Národní identity občana v souladu se zákonem č. 250/2017 Sb., o elektronické identifikaci, ve znění pozdějších předpisů. Musí však také umožnit autentizaci prostřednictvím OpenID.
82.	PIS musí zpřístupnit zabezpečenou webovou službu pro zablokování uživatelského účtu interního i externího uživatele.

3.7.7 Zúčtování

č.	Podmínka	Způsob doložení
83.	PIS musí umožnit zúčtování všech POP včetně Parkovacích relací po její úhradě libovolným Platebním	Prohlášení Dodavatele. Odkaz na prvek aplikační
	kanálem. Zúčtováním se míní, že u každé Parkovací relace	architektury a na prvky LDM
	je zaznamenáno, kdy, v jaké výši a jakým Platebním kanálem byla uhrazena.	a PM.
84.	PIS musí umožnit k jakémukoliv datu vytvořit přehled zúčtování Parkovacích relací podle jednotlivých Platebních
	kanálů a jejich provozovatelů. Současně je nutno umožnit
	přehledy zúčtování Parkovacích relací s využitím
	filtrovacích a třídicích nástrojů, které se odvíjejí od všech
	evidovaných parametrů každé Parkovací relace.

3.7.8 Reporting

č.	Podmínka	Způsob doložení
85.	Součástí PIS musí být datový sklad, který bude trvale evidovat všechny podstatné informace vzniklé při provozu ZPS, a to po dobu minimálně 10 let. Za podstatné informace jsou považovány informace o POP, Parkovacích relacích, Záznamech o Parkování (bez fotodokumentace), Podezřeních na přestupek, odhalených přestupcích včetně jejich vazeb na číselníky a informace Helpdesku. Informace z Parkovacích relací a ze záznamů o Parkování je třeba evidovat anonymizované (vyjma Záznamů spojených s Podezřením na přestupek). Anonymizace RZ znamená nahrazení RZ jiným jedinečným časově závislým kódem.	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury a na prvky LDM a PM. Dodavatel SZPS popíše způsob anonymizace RZ.
86.	Datový sklad musí zajišťovat tvorbu reportů minimálně o:	Prohlášení Dodavatele
	● Parkovacích relacích agregovaných po Úsecích ZPS, časovém období, dnech v týdnu a typu uživatele,
	● Parkovacích relacích agregovaných po typu Parkovací relace,
	● Záznamech o parkování agregovaných po Úsecích ZPS, časovém období a dnech v týdnu,
	● výpočtu počtu parkujících a počtu platících po Úsecích ZPS, časovém období a dnech v týdnu (využívání Parkovacích stání a podíl platících vozidel),
	● nástrojích úhrady Parkovného (PA, VPH, POP, …) a formě úhrady (hotově, bankovní kartou, …) a dnech a měsících (efektivita nástroje a formy úhrady),
	● Parkovacích relacích agregovaných po jednotlivých PA a dnech a měsících (efektivita PA),
	● Odhalených přestupcích,
	● respektovanosti ZPS (průměrný podíl oprávněných Parkování ke všem Parkováním v ZPS),
87.	PIS musí poskytovat provozní reporty minimálně o: ● stavu vyúčtování s provozovateli Platebních kanálů, ● vypočtené obsazenosti Parkovacích stání, ● provozních stavech PA.
88.	PIS musí zajistit přístup ve všem datům v datovém skladě v reálném čase.

3.7.9 Portál ZPS

č.	Podmínka	Způsob doložení
89.	Součástí ZPS musí být portál ZPS. Grafická podoba portálu musí obsahovat logotyp SMT a bude odsouhlasena Zadavatelem nejpozději 30 dní před termínem, kdy má dle Smlouvy dojít ke zprovoznění PIS v produkčním provozu. Grafický manuál SMT poskytne Zadavatel do 15 dnů od podpisu smlouvy. Portál ZPS musí mít nejméně 2 nezávislé oblasti: ● veřejné informace a redakční systém, ● osobní stránky uživatele ZPS (OSU).	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury a na prvky PM.
90.	Součástí veřejných informací musí být i informace o umístění parkovacích Úseků ZPS, Parkovacích automatů, Parkovném a časových platností realizovaných jako zapínatelné vrstvy na mapovém podkladu.
91.	Osobní stránky uživatele OSU musí umožnit provádět minimálně činnosti: ● Podávání žádostí o prodloužení a zkrácení POP. ● Dočasná změna RZ. ● Evidence žádostí o POP včetně údajů o způsobu úhrady. ● Evidence POP. V detailu POP musí být zobrazeny údaje o ceně, časové a prostorové platnosti a historie změn parametrů POP. ● Platby za POP Platebním kanálem „Platební karta OSU“ a bankovním převodem. ● Správa uživatelského účtu. Uživatel musí mít možnost spravovat údaje: uživatelské jméno, heslo, jméno příjmení, email.

3.7.10 Virtuální parkovací hodiny

č.	Podmínka	Způsob doložení
92.	Dodavatel musí dodat VPH, tj. aplikaci pro zahajování a ukončování Parkovacích relací provozovanou na zařízeních s běžnými operačními systémy pro chytré mobilní telefony (Android, iOS). VPH musí uživateli v administrační části umožnit registrovat nejméně 3 RZ, nejméně 3 platební prostředky a emailovou adresu pro zasílání VPL a zpráv z SZPS. Minimálně musí být možno používat k úhradám Parkovného platební karty VISA a Mastercard.	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury.
93.	Uživatelské rozhraní VPH musí být minimálně v jazycích čeština, němčina a angličtina.	Prohlášení Dodavatele

94.	VPH musí zajistit předání informací o Parkovací relaci do PIS dle parametru SZPS_VPH1.
95.	VPH musí uživateli umožnit řešit odmítnutí žádosti o Parkovací relaci ještě před zaplacením.	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury a na prvky PM.
96.	VPH musí umožnit prodloužení a ukončení Parkovací relace, je-li to podle Pravidel ZPS určených SMT možné.
97.	VPH musí být připraven pro doplňování dalších Platebních kanálů.	Prohlášení Dodavatele
98.	VPH musí umožnit nastavení připomenutí končící Parkovací relace a nastavená připomenutí zajistit.	Prohlášení Dodavatele. Odkaz na prvek aplikační architektury a na prvky PM.
99.	VPH musí podporovat geolokaci a nabízet k založení Parkovací relace nejbližší parkovací Úseky ZPS.
100.	VPH musí zajistit odeslání VPL na nastavenou email adresu. Obsah a formát VPL bude stanoven Zadavatelem jako součást připomínek k VTV.
101.	VPH musí komunikovat s PIS pomocí standardního rozhraní webových služeb jak pro výměnu dat o Parkovacích relacích, tak při úhradách Parkovného Platebními kanály. Všechna tato rozhraní musí být možné využívat i aplikacemi 3. stran.

3.8 Zavedení PIS

č.	Podmínka	Způsob doložení
102.	Dodavatel SZPS musí provést nastavení PIS podle požadavků Zadavatele v oblastech: ● ceníky POP, ● ceníky Parkovného, ● vymezení Úseků ZPS a jejich částí, ● vymezení Rezidentních oblastí, ● vymezení Parkovacích oblastí, ● přiřazení Parkovacích automatů Úsekům ZPS, ● umístění svislého dopravního značení a jeho přiřazení k Úsekům ZPS, ● číselníky (Platební kanály, typy platebních prostředků, typy POP), ● skupiny uživatelů a skupinová přístupová práva k funkcím a datům, ● případné další potřebné nastavení PIS provede Dodavatel na základě jím vyžádané konzultace se Zadavatelem.	Prohlášení Dodavatele

	Podklady pro nastavení podle této podmínky poskytuje Zadavatel.
103.	Dodavatel musí provést nastavení PIS podle skutečnosti: ● Ulice, ● Xxxxxx.
104.	Dodavatel musí v nabídce předložit scénář akceptace PIS. Scénář musí pokrývat všechny funkční oblasti PIS, tj.: ● Konfigurace PIS, ● Parkovací oprávnění, ● Parkovací relace, ● Monitoring, ● Přestupky, ● Uživatelé, ● Portál ZPS, ● Zúčtování, ● Reporting, ● Virtuální parkovací hodiny. Jednotlivé kroky scénáře akceptace musí zajistit ověření splnění všech povinných technických podmínek. U každého kroku scénáře musí být popsáno, jak bude krok prováděn, měřen a hodnocen. Scénář musí obsahovat kritéria akceptace vycházející z bodového ohodnocení jednotlivých kroků.				Scénář akceptace je součástí nabídky.
		Body	Název	Popis vlastnosti produktu
		0	OK	Bez chyb a bez výhrad.
		1	Akceptovatelné	Bez chyb, ale s výhradami k uživatelskému rozhraní či grafice.
		2	Neakceptovatelné	Bez chyb, ale vlastnost nesplňuje parametry v takové míře, že je v praxi nepoužitelná.
		3	Chyba	Chyba
		4	Null	Vlastnost není implementována
	Plná akceptace PIS vyžaduje výsledky testů jednotlivých kroků v rozmezí 0-1. Akceptace s výhradami může obsahovat max. 3 výsledky kroků hodnocené 2 body. Ve výhradách musí být pro kroky hodnocené 2 body stanoveno, do kdy budou upraveny.

105.	Dodavatel musí pro potřebu školení zaměstnanců zpřístupnit školící verzi PIS se zcela oddělenou databází. Školící verze PIS musí obsahovat moduly PIS, se kterými pracují vnitřní uživatelé PIS, tj.: ● Parkovací oprávnění ● Monitoring ● Přestupky ● Zúčtování ● Reporting Školící verze musí být k dispozici pro první školení uživatelů.	Prohlášení Dodavatele
106.	VTV musí umožnit Zadavateli se zorientovat ve stavu PIS, aby mohl co nejrychleji upřesnit své požadavky na PIS. Dodavatel musí Zadavateli po dobu práce s VTV poskytovat bezodkladné konzultace přítomným pracovníkem.
107.	Dodavatel musí zapracovat požadavky Zadavatele na úpravu VTV předané do 14 dní od zpřístupnění VTV. Požadavky Zadavatele budou pouze upřesněním vlastností PIS v rámci povinných technických podmínek.	Prohlášení Dodavatele

4 Jednorázová plnění

4.1 Rozšíření ZPS

č.	Podmínka	Způsob doložení
108.	Na základě výzvy k doplnění ZPS je Dodavatel SZPS povinen dodat vybavení specifikované ve Výzvě.	Prohlášení Dodavatele
109.	Výzvu je Objednatel oprávněn učinit nejpozději do 5 let ode dne účinnosti Smlouvy.
110.	Technické podmínky dodávky v rámci Jednorázového plnění jsou totožné jako v případě počáteční dodávky.

5 Periodické služby

5.1 Požadavky na servisní služby v oblasti parkovacích automatů, závorových systémů a informačních panelů a tabulí (Služba Technického vybavení)

5.1.1 Provoz parkovacích automatů (PA) a závorových systémů (ZS)

č.	Podmínka	Způsob doložení
111.	Dostupnost služby PA a ZS nesmí klesnout pod hodnotu systémového parametru PA_DOSTUP dle požadavku SLA v kapitole 6. níže. Pro vyloučení pochybností se uvádí, že na míru dostupnosti nemá vliv skutečnost, zda ze strany Zadavatele došlo k zadání Požadavku na Servisní zásah; zajištění požadované míry dostupnosti je výlučně na odpovědnosti Dodavatele.	Prohlášení Dodavatele
112.	Všechny provozované PA a ZS musí být schopny zpracovat data o množství Parkovacích relací daném systémovým parametrem PARK_REL.
113.	Požadované Režimy služby: Modul správy PA na PIS - Režim služby 24x7. Dostupnost služby PA a ZS – Režim služby 24x7. Pro účely provedení Servisního zásahu však bude uplatněn Režim služby 10x5 (pondělí až pátek, 8:00 – 18:00 hod.) Kategorizace požadavků na Servisní zásah (upřesnění obecné kategorizace dle kapitoly 7. níže): Incident: • Není funkční výměna dat mezi PA a PIS. High: • PA je zcela nefunkční – nelze provést žádnou Parkovací relaci. • PA se nepřihlásil do PIS déle než 24 hodin. Medium: • Nelze zaplatit Parkovací relaci jedním z Platebních kanálů. Ostatní Platební kanály jsou funkční. • PA vykazuje estetické vady při zachování plné funkčnosti PA. Low: Změna nastavení parametrů PA. Požadavky s prioritou Incident se předávají telefonicky prostřednictvím Hotline, ostatní prostřednictvím Helpdesku.
114.	Dodavatel SZPS každý měsíc předloží Zprávu z provozu PA. Měsíční zpráva musí obsahovat:

• Počet PA a ZS ve správě Dodavatele k 1. a k poslednímu dni příslušného měsíce.

• Plánované a neplánované výpadky v dodávaných službách.

• Výjimečné/mimořádné události v dodávaných službách.

• Konkrétní míra naplnění SLA včetně slovního hodnocení podle kapitoly 7.

5.1.2 Provoz informačních stojanů a informačních tabulí

č.	Podmínka	Způsob doložení
115.	Dodavatel je povinen udržovat informační stojany i informační tabule v dobrém technickém stavu a dbát na bezpečnost vůči účastníkům provozu na pozemních komunikacích a na správnost a čitelnost uváděných dat.	Prohlášení Dodavatele
116.	Změnu polepu informační tabule je Dodavatel povinen provést ve lhůtě 30 dnů od obdržení pokynu Zadavatele. Do 15 dnů od obdržení pokynu Zadavatele předloží Dodavatel SZPS grafický návrh. Lhůta pro vyjádření Zadavatele činí 5 dnů.
117.	Incident: • Vyvrácený informační stojan nebo uvolněná informační tabule zasahující do průchozích či průjezdních profilů High: • Informační stojan či informační tabule je z více než 50 % přelepen(a), či jinak znemožněná čitelnost informací. Medium: • Přelepení informačního stojanu nebo informační tabule či jiná znemožnění čitelnosti informací je menší než 50 % plochy • Informační stojan nebo informační tabule je znečištěn(a), nebo lokálně polepen(a)/posprejován(a). Low: Změna polepu. Požadavky s prioritou Incident se předávají telefonicky prostřednictvím Hotline, ostatní prostřednictvím Helpdesku.

5.2 Požadavky na servisní služby v oblasti PIS

Součástí poptávky jsou i servisní služby v oblasti infrastruktury, řešící veškeré výpadky a závady dle stanovených SLA projektu (viz kapitola 6).

Minimální požadavky na servisní služby infrastruktury:

č.	Podmínka	Způsob doložení
118.	Dodavatel musí zajistit dodržování požadovaných SLA a záručních podmínek dle zadávací dokumentace pro celý předmět veřejné zakázky.	Prohlášení Dodavatele
119.	Součástí servisních služeb je i proaktivní monitoring infrastruktury a včasné varování před možnými problémy infrastruktury, s možností využití stávajících monitorovacích nástrojů Dodavatele.
120.	Součástí servisních služeb jsou pravidelná údržba, profylaxe a prevence systému.
121.	Dodavatel dle svého uvážení doplní v nabídce další servisní služby, které jsou dle jeho názoru nezbytné pro úspěšnou realizaci zakázky.
122.	Dodavatel zajistí správu a technickou podporu dodávané služby tak, aby zajistil dostupnost PIS podle parametru SZPS_DOST a vnitřní zpracování dotazů podle parametru SZPS_KONTROLA. Pro vyloučení pochybností se uvádí, že na míru dostupnosti nemá vliv skutečnost, zda ze strany Zadavatele došlo k zadání Požadavku na Servisní zásah; zajištění požadované míry dostupnosti je výlučně na odpovědnosti Dodavatele.
123.	Dostupnost technické podpory pro kategorie Incident a High musí být zajištěna v Režimu služby 24x7, pro ostatní kategorie v režimu 10x5.

5.3 Technická a uživatelská podpora PIS

č.	Podmínka	Způsob doložení
124.	Dostupnost technické podpory PIS pro kategorii High a Incident musí být zajištěna v Režimu služby 24x7, pro ostatní kategorie v režimu 10x5.	Prohlášení Dodavatele
125.	Požadavky na Servisní zásahy musí být zajištěny podle kapitoly „Kategorizace Servisních zásahů“ (kap. 7. níže). Kategorizace Servisních zásahů High může být použita pouze pro případ nedostupností PIS nebo chybné funkčnosti při vyřizování žádostí o POP nebo změnu parametrů POP a pro případ nedostupností či chybné funkčnosti VPH. Požadavky s prioritou High se předávají telefonicky prostřednictvím Hotline nebo Helpdeskem.
126.	Součástí PIS musí být Helpdesk pro evidenci Požadavků na Servisní zásahy, Drobný rozvoj, Podporu aplikace PIS a podporu uživatelů a stavu jejich řešení. Každý Požadavek na Servisní zásah, Drobný rozvoj PIS, podporu

	aplikace PIS a podporu uživatelů, musí být zaznamenán do Helpdesku.
127.	Dodavatel každý měsíc předloží zprávu z provozu. Měsíční zpráva musí obsahovat: ● plánované a neplánované výpadky v dodávaných službách, ● výjimečné/mimořádné události v dodávaných službách.

5.4 Drobný rozvoj a podpora aplikace PIS

č.	Podmínka	Způsob doložení
128.	Dodavatel musí garantovat trvalou pohotovostní kapacitu pracovníků pro Drobný rozvoj PIS, Podporu aplikace PIS a řízení v rozsahu daném systémovým parametrem SZPS_DROZV. Požadavky na Drobný rozvoj PIS a Podporu aplikace PIS budou zadávány do Helpdesk systému a zařazovány do připravovaných verzí. Požadavky Zadavatele přesahující v daném měsíci rozsah daný systémovým parametrem SZPS_DROZV není Dodavatel povinen provést. Při převzetí požadavku na Drobný rozvoj PIS a Podporu aplikace PIS uvede Dodavatel předpokládanou potřebnou kapacitu pracovníků pro realizaci požadavku a termín dokončení.	Prohlášení Dodavatele
129.	Dodavatel bude měsíčně předkládat výkaz prací provedených v souvislosti s podporou PIS, tj. výkaz Servisních zásahů, Drobného rozvoje PIS, Podpory aplikace PIS a podpory uživatelů. Výkaz prací bude sloužit k evidenci rozsahu poskytnutých služeb Drobného rozvoje PIS, Podpory aplikace PIS a podpory uživatelů. Výkaz bude dále sloužit ke kontrole řešení splnění Požadavků na Servisní zásahy.
130.	Dodavatel zajistí průběžné úpravy PIS v návaznosti na změny právního prostředí ČR a to ve lhůtě nejpozději 30 dnů před nabytím účinnosti příslušného právního předpisu.

5.5 Správa finančních prostředků z vybraného Parkovného

č.	Podmínka	Způsob doložení
131.	Veškeré neidentifikované platby na Správcovských účtech musí být odesílateli vráceny do termínu daném systémovým parametrem SZPS_VRATKA.	Prohlášení Dodavatele

6 Požadované systémové parametry

Kód	Popis	jednotka	hodnota
PA_T_REL2PIS	Limit pro odeslání informací o Parkovací relaci do PIS	sekunda	2
PA_T_ODMITNU TI	Limit pro oznámení odmítnutí či omezení Parkovací relace pro danou RZ parkujícímu řidiči	sekunda	5
PA_DOSTUP	Dostupnost služby PA (PA_DOSTUP) Stanovená jako ((součet počtu hodin v měsíci, kdy byly jednotlivé PA dostupné) / (součet hodin v měsíci, kdy měly být jednotlivé PA dostupné)) x 100 %	%	99,5
PARK_REL	Denní počet záznamů Parkovacích relací	Parkovací relace / PA / den	200
SZPS_PREL	Počet záznamů Parkovacích relací	Den	15 000
SZPS_ZOP	Počet záznamů o Parkování (Monitoring ZPS)	Den	36 000
SZPS_DROZV	Garantovaná kapacita techniků pro drobný rozvoj PIS	Člověkoden /měsíc	4
SZPS_DOST	Minimální dostupnost PIS	%	99,5
SZPS_DATA	Povolená ztráta dat	minuta	301
SZPS_VRATKA	Lhůta pro vrácení nerozpoznaných plateb na Správcovském účtu	den	7
SZPS_KONTROLA	Lhůta pro vnitřní zpracování dotazu na oprávněnost parkování dané RZ v daném čase na daném místě	sekunda	0,5
SZPS_VPH1	Max. doba, za kterou musí VPH předat informaci o založení PR do PIS	sekunda	10

7 Kategorizace Servisních zásahů

Kategorie	Kritérium pro kategorizaci2	Lhůta pro zahájení řešení	Lhůta pro vyřešení Servisního zásahu
Incident	Porucha, která výrazně omezuje použití SZPS	Servisní zásah musí být zahájen	Servisní zásah musí být vyřešen

1 Pokud dodavatel v nabídce nabídl nižší hodnotu povolené ztráty dat, bude platit hodnota obsažená v jeho nabídce, tedy hodnota

v Technických podmínkách nabízených uchazečem.

2 U konkrétních Periodických služeb může být kritérium zpřesněno

	Zadavatelem, nebo jej činí nedostupný v oblastech, pro Zadavatele kritických.	do 30 minut od nahlášení.	(porucha musí být v plném rozsahu odstraněna) do 24 hodin od nahlášení.
High	Porucha, která závažně omezuje použití jednotlivé části SZPS.	Servisní zásah musí být zahájen (opravu je nutno zahájit) do 2 hodin od nahlášení Požadavku na Servisní zásah.	Servisní zásah musí být vyřešen (opravu je nutno dokončit) do 24 hodin od nahlášení Požadavku na Servisní zásah.
Medium	Porucha, která částečně omezuje použití části SZPS.	Servisní zásah musí být zahájen (opravu je třeba zahájit) do 4 hodin od nahlášení Požadavku na Servisní zásah.	Servisní zásah musí být vyřešen (opravu je nutno dokončit) do 48 hodin od nahlášení Požadavku Servisní zásah.
Low	Požadavek na změnu funkčnosti či nastavení provozních parametrů části SZPS.	Zahájit Servisní zásah je nutno do 7 dní od nahlášení Požadavku na Servisní zásah	Vyřešit požadavek na Servisní zásah je nutno do 14 dní od nahlášení Požadavku na Servisní zásah (tedy v této lhůtě musí být proveden požadavek na změnu funkčnosti či nastavení provozních parametrů části SZPD).

Kategorizaci servisních zásahů stanovuje Zadavatel. Všechny časy se počítají od nahlášení servisního požadavku. Čas přijetí požadavku je časem potvrzení o zahájení řešení servisního požadavku v Helpdesk systému, případně okamžik nahlášení telefonicky prostřednictvím Hotline, čas vyřešení je čas záznamu o vyřešení servisního požadavku v Helpdesk systému.

Lhůta pro zahájení Servisního zásahu se vždy počítá pouze v rámci Režimu služby (tzn., je-li např. Režim služby nastaven od 8:00 do 20:00, běží lhůta pro zahájení Servisního zásahu vždy pouze v rámci tohoto intervalu).

Není-li výše stanoveno jinak, je Požadavek na Servisní zásah sdělován prostřednictvím

Helpdesku.

Plánované odstávky je nutno směřovat výhradně do času od 01:00 do 05:00 hodin. Mimo tuto dobu pak výhradě se souhlasem Zadavatele.