Obsah (11)

§ 140§ 167§ 170§ 8§ 175§ 2§ 171§ 173§ 24§ 10§ 42

Bratislava 16. 03. 2020 Číslo: 14434-6000/2019-OD Úrad pre verejné obstarávanie ako ústredný orgán štátnej správy pre verejné obstarávanie

§ 140

a orgán príslušný

§ 167ods.

2 písm. b) zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov vo veci námietok záujemcu XX (ďalej len „navrhovateľ“) v právnom zastúpení advokátskou kanceláriou XY smerujúcich

§ 170ods.

3 písm. b) zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov proti podmienkam uvedeným v iných dokumentoch potrebných na vypracovanie ponuky poskytnutých kontrolovaným vo verejnej súťaži na predmet nadlimitnej zákazky „Tarifno-informačné zabezpečenie integrovaného dopravného systému autobusov východnej časti Košického samosprávneho kraja, Referenčné číslo: ARRIVA MI-NZ-VS-2019-TIS“, vyhlásenej verejným obstarávateľom

§ 8zákona č.

343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov ARRIVA Michalovce, a.s., Lastomírska 1, 071 80 Michalovce IČO: 36214078 (ďalej len „kontrolovaný“) vo Vestníku verejného obstarávania č. 172/2019 dňa

2. 2019 pod značkou 23392 – MST a v Úradnom vestníku Európskej únie č. 2019/S 162-397826, dňa
4. 2019 vydáva toto rozhodnutie: Úrad pre verejné obstarávanie nariaďuje kontrolovanému

§ 175ods.

1 písm. b) zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov zrušiť verejnú súťaž na predmet zákazky ,,Tarifno-informačné zabezpečenie integrovaného dopravného systému autobusov východnej časti Košického samosprávneho kraja, Referenčné číslo: ARRIVA MI-NZ-VS-2019-TIS“ vyhlásenú verejným obstarávateľom

§ 8zákona č.

343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov ARRIVA Michalovce, a.s., Lastomírska 1, 071 80 Michalovce IČO: 36214078 vo Vestníku verejného obstarávania č. 172/2019 dňa

2. 2019 pod značkou 23392 – MST a v Úradnom vestníku Európskej únie č. 2019/S 162-397826 dňa
4. 2019, a to do 30 dní odo dňa nadobudnutia právoplatnosti tohto rozhodnutia. Odôvodnenie:
5. Navrhovateľ doručil dňa
7. 2019 Úradu pre verejné obstarávanie (ďalej len „úrad“) námietky v elektronickej podobe

osobitného predpisu 1 prostredníctvom Ústredného portálu verejnej správy smerujúce

§ 170ods.

3 písm. b) zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej len „zákon o verejnom obstarávaní“) proti podmienkam uvedeným v iných dokumentoch potrebných na vypracovanie ponuky poskytnutých kontrolovaným. Navrhovateľ doručil kontrolovanému námietky dňa

2. 2019 cez informačný systém prostredníctvom ktorého sa realizovala predmetná verejná súťaž, a to prostredníctvom informačného systému ELENA.
3. Úrad uvádza, že dňa
5. 2019 nadobudol účinnosť zákon č. 345/2018 Z. z., ktorým sa mení a dopĺňa zákon o verejnom obstarávaní.
6. Námietky navrhovateľa boli doručené úradu a kontrolovanému v lehote a podobe

§ 170ods.

4 a v podobe

§ 170ods.

8 a obsahujú všetky náležitosti a prílohy námietok

§ 170ods.

5 zákona o verejnom obstarávaní. Navrhovateľ doručil úradu námietky v zmysle § 170 ods. 1 písm. b) zákona o verejnom obstarávaní, ako záujemca.

§ 2ods.

5 písm. b) zákona o verejnom obstarávaní, na účely tohto zákona sa rozumie záujemcom hospodársky subjekt, ktorý má záujem o účasť vo verejnom obstarávaní. Za preukázanie záujmu o účasť vo verejnom obstarávaní je možné považovať skutočnosť, že konkrétny subjekt pristúpil k prevzatiu súťažných podkladov a následnému oboznámeniu sa s ich obsahom.2 Z obsahu predložených námietok má úrad za preukázané, že navrhovateľ sa so znením súťažných podkladov primerane oboznámil. Preskúmaním dokumentácie kontrolovaného úrad súčasne zistil, že navrhovateľ bol zaradený medzi záujemcov dňa 02. 09. 2019. 4.

ust. § 172 ods. 1 zákona o verejnom obstarávaní, s podaním námietok je navrhovateľ povinný zložiť na účet úradu kauciu; táto povinnosť sa nevzťahuje na orgán štátnej správy

§ 170ods.

1 písm. e). Kaucia musí byť pripísaná na účet úradu najneskôr pracovný deň nasledujúci po uplynutí lehoty na doručenie námietok

§ 170ods.

2. Z ust. § 172 ods. 2 zákona o verejnom obstarávaní vyplýva, že navrhovateľ bol v danom prípade povinný s podaním námietok zložiť na účet úradu kauciu vo výške 2 235,87 EUR, čo zodpovedá 0,1 % z predpokladanej hodnoty zákazky, ktorá bola stanovená v celkovej hodnote 2 235 871,67 - EUR bez DPH.
3. Úrad lustráciou účtu úradu zistil, že navrhovateľ s podaním námietok zložil na účet úradu dňa
5. 2019 kauciu vo výške 2 235,87 EUR.
6. Na základe vyššie uvedených skutočností má úrad za to, že s podaním námietok navrhovateľa boli splnené procesné podmienky pre konanie vo veci. Námietky navrhovateľa Zákon č. 305/2013 Z. z. o elektronickej podobe výkonu pôsobnosti orgánov verejnej moci a o zmene a doplnení niektorých zákonov (zákon o e-Governmente) v znení neskorších predpisov. 2 porov. napr. rozhodnutie Rady Úradu pre verejné obstarávanie č. 7467-9000/2018 zo dňa
8. 2018 1 2
9. Navrhovateľ v úvode svojich námietok poukazuje na zamietnutie žiadosti o nápravu zo dňa
11. 2019 v časti navrhovateľom požadovaného poskytnutia interface, kde sa okrem iného uvádza, cit.: ,,odôvodnenie neposkytnutia/nezverejnenia interface ako súčasť zadávacej dokumentácie verejného obstarávania v rámci jednotlivých požiadaviek, viď otázky nižšie: Verejný obstarávateľ' vo svojich tarifno-informačných systémoch používa SW a HW komponenty/moduly/prvky/systémy od viacerých dodávateľov YY, YY, YY obstarané v rôznych časových obdobiach a za rôznych obchodných podmienok. Prepojenia medzi jednotlivými modulmi sú založené na proprietárnych protokoloch, tak ako to v čase obstarávania týchto systémov bolo obvyklé (a čiastočne je používané aj v súčasnosti) v obdobných systémoch v EÚ. Používané komunikačné protokoly predstavujú obchodné tajomstvo jednotlivých dodávateľov a ich zverejňovanie je limitované príslušnými právnymi predpismi (Obchodný zákonník, Autorský zákon, Zmluvy). Verejný obstarávateľ aj na základe postupov iných obdobných verejných obstarávaní uzavrel s jednotlivými dodávateľmi dohodu o poskytnutí potrebnej dokumentácie výlučne víťaznému uchádzačovi na základe podpísanej zmluvy (NDA) o ochrane poskytnutých informácií. Tento postup je tiež v súlade s Rozhodnutím ÚVO č. 143566000/2018-OD zo dňa 23.04.2019 https://www.uvo.gov.sk/prehlad-rozhodnuti-onamietkach/document/5501, ktoré takýto postup akceptuje cit. bod
12. Rozhodnutia ...Na stanovenie ponuky nie je potrebné poznať tento protokol. Zložitosť komunikačného protokolu môže mať vplyv na cenu realizácie, ale tá sa dá odhadnúť z požadovaných operácií...“ Navrhovateľ s postupom kontrolovaného nesúhlasí a uvádza, že z predmetného rozhodnutia úradu č. 14356-6000/2018-OD zo dňa
14. 2019 vyplýva, že úrad nariadil zrušiť uvedený postup zadávania zákazky nakoľko vyhodnotil, že postup kedy nebol poskytnutý interface je nedostatočný pre riadnu prípravu ponuky. Navrhovateľ má za to, že kontrolovaný koná v rozpore s vlastným tvrdením uvedeným vo svojom zamietnutí žiadosti o nápravu. Navrhovateľ je toho názoru, že ak na riadnu prípravu ponuky postačuje odhad požadovaných operácií, tak tento mal byť poskytnutý v rámci opisu predmetu zákazky. Navrhovateľ uvádza, že takýto odhad však nebol zo strany kontrolovaného poskytnutý a dodáva, že nie je možné opis predmetu zákazky a jeho technické špecifikácie, ktoré sú potrebné na vypracovanie ponuky, nepredvídateľne dopĺňať odhadmi na strane záujemcov, resp. uchádzačov.
15. Navrhovateľ v súvislosti s tvrdeniami kontrolovaného ohľadne uplatnenia modelu zmluvy (NDA) o ochrane poskytnutých informácií uvádza, že kontrolovaný má rôzne možnosti použitia modelu NDA zmluvy, ktorého príkladom môže byť postup Dopravného podniku Hradec Králové, kedy predmetný verejný obstarávateľ poskytol údaje všetkým uchádzačom po podpise NDA zmluvy. Navrhovateľ konštatuje, že v predmetnej súťaži boli poskytnuté parametre o systémoch spoločnosti YY, ktoré kontrolovaný tvrdí, že nemôže poskytnúť. Navrhovateľ má za to, že z uvedeného je zrejmé, že kontrolovaný buď uvedené nechce poskytnúť, resp. svojím predchádzajúcim postupom v rámci zmluvného vzťahu so spoločnosťou YY a inými dodávateľmi vytvoril umelo taký stav, že v súčasnosti predmetné interface nemôžu byť poskytnuté. Navrhovateľ poukazujúc na systémy spoločnosti YY uvádza, že existuje precedens, kedy ani dodávateľ nevznášal voči verejnému akékoľvek nároky v súvislosti s poskytnutím interface svojich systémov iným uchádzačom. Navrhovateľ ďalej uvádza, že poskytnutie údajov o existujúcich systémoch v rámci prostredia verejného obstarávateľa je možné a v súlade so 3 zákonom o verejnom obstarávaní. Navrhovateľ poukazuje na súťaž na predmet zákazky "Ostatné systémy ZVJS SW", Referenčné číslo: ZVJS 01/2019, vyhlásené Oznámením o vyhlásení verejného obstarávania v európskom vestníku dňa 06.08.2019 pod zn.: 2019/S 150369984, vo vestníku úradu č. 22472 MSS, Vestník č. 160/2019 - 07.08.2019, kedy Generálne riaditeľstvo zboru väzenskej a justičnej stráže priamo aplikovalo predmetný model, kedy detaily opisu predmetu zákazky sa poskytujú len uchádzačom po predchádzajúcom podpise NDA zmluvy. S poukazom na vyššie uvedené navrhovateľ v celom rozsahu zotrváva na tvrdeniach uvedených v podanej žiadosti o nápravu zo dňa
17. 2019 a zastáva názor, že bez poskytnutia interface nie je možné pripraviť ponuku. Navrhovateľ má za to, že kontrolovaný vytvára umelo situáciu vendor lock in, nakoľko len existujúci dodávatelia majú informácie o doterajšom prostredí a parametroch kariet, čítačiek a iných parametroch predmetu zákazky. Navrhovateľ považuje postup kontrolovaného za nezákonný, kedy okrem iného nedostatočne popisuje predmet zákazky a zároveň porušuje princípy verejného obstarávania (najmä princíp rovnakého zaobchádzania a nediskriminácie uchádzačov). V kontexte vyššie uvedeného tak považuje navrhovateľ v tejto časti postup kontrolovaného za nezákonný.
18. Navrhovateľ ďalej s poukazom na tvrdenie kontrolovaného, že kontrolovaný používa čipové karty Mifare Classic, Mifare DESFire EV1 a Mifare DESFire EV2 uvádza, že kontrolovaný už ďalšie informácie neposkytol. Navrhovateľ ďalej uvádza, že požadoval dátové štruktúry karty a popis práce s kartou a je toho názoru, že ide tak o nedostatočnú špecifikáciu, čo potvrdil aj úrad, v rozhodnutí č. 14356-6000/2018-OD zo dňa
20. 2019 na str. 10, kde sa okrem iného uvádza, cit.: ,,Kontrolovaný síce v prílohe 3 súťažných podkladov uvádza, že požaduje podporu čipových kariet Mifare Classic, Mifare DESFire EV1 a Mifare DESFire EV2, ale tie majú svoje ďalšie varianty vzhľadom na množstvo a organizáciu pamäte, ktorou disponujú. Zabezpečenie podpory rôznych variantov kariet zvyšuje prácnosť realizácie, a tým aj cenu. Na toto poukázal aj navrhovateľ vo svojej sťažnosti adresovanej ÚVO. Z uvedeného vyplýva, že opis predmetu zákazky nie je úplný a jednoznačný, resp. neumožňuje predloženie porovnateľných ponúk". Navrhovateľ dodáva, že ide o citáciu z odborného stanoviska, ktoré si úrad zabezpečil za účelom objektívneho a vecne správneho rozhodnutia o tam podaných námietkam.
21. Navrhovateľ ďalej poukazuje na zamietnutie žiadosti o nápravu, kde sa uvádza cit.: ,,Odpoveď verejného obstarávateľa k otázke č. 18: Verejný obstarávateľ trvá na svojej odpovedi. K argumentu, že operačný systém Windows je najpoužívanejší nielen vo svete ale aj na Slovensku uvádza, že ho považuje za ničím nepodložené tvrdenie, Verejný obstarávateľ trvá na tom, že požiadavka voľne šíriteľného OS nie je diskriminačná, keďže sú tieto systémy k dispozícii na stiahnutie bezplatne akémukoľvek uchádzačovi. Verejný obstarávateľ dôrazne odmieta tvrdenia uchádzača, že sa požiadavkou snaží preferovať akéhokoľvek dodávateľa“. Navrhovateľ zastáva názor, že práve skutočnosťou, že kontrolovaný neumožňuje predloženie technického riešenia aj na technológii Windows preferuje konkrétnych dodávateľov. Navrhovateľ dáva do pozornosti úradu, že v rámci podanej žiadosti o nápravu nežiadal navrhovateľ o umožnenie predloženia len technického riešenia na platforme Windows, ale žiadal len rozšírenie platforiem aj o platformu Windows. Navrhovateľ uvádza, že ak majú platiť tvrdenia kontrolovaného o tom, že sa snaží v rámci predmetnej súťaže zabezpečiť čo najširší okruh subjektov schopných predložiť ponuku, tak práve na základe uvedeného by platforma Windows mala byť kontrolovaným umožnená. 4 Navrhovateľ ďalej uvádza, že kontrolovaný v rámci zamietnutia žiadosti o nápravu neuviedol žiadne technické argumenty, pre ktoré by nebolo možné akceptovať technické riešenie na platforme Windows. Navrhovateľ vyjadruje názor, že, práve systémy bežiace na platforme Windows sú s vysokou mierou pravdepodobnosti nasadené aj u kontrolovaného.
22. Navrhovateľ ďalej uvádza, že predmet zákazky tvoria už existujúce systémy a nejde o vytvorenie nového systému na kľúč. Navrhovateľ má za to, že tým, že kontrolovaný definuje určitú platformu, významným spôsobom zužuje okruh subjektov, ktoré sú schopné dodať požadované technické riešenie. Navrhovateľ má za to, že kontrolovaný v prípade zúženia okruhu subjektov oprávnených prihlásiť sa do verejného obstarávania, resp. realizovať predmet zákazky znáša dôkazné bremeno, aby odôvodnil prečo pristupuje k zúženiu hospodárskej súťaže a dodáva, že kontrolovaný v žiadnom svojom vyjadrení neuviedol argumenty prečo neumožňuje aj platformu Windows. V tejto súvislosti navrhovateľ poukazuje na tú skutočnosť, že kontrolovaný patrí do skupiny Arriva a v rámci predmetnej skupiny ARRIVA MORAVA a.s. (Česká republika) vyhlásila obdobné verejné obstarávanie, v ktorom umožnila aj technickú platformu Windows. Navrhovateľ vyjadruje názor, že ide pritom o typovo rovnakého dopravcu ako navrhovateľ, teda linkovú medzimestskú dopravu, pričom obaja dopravcovia (ako členovia skupiny Arriva) patria tomu istému majiteľovi (Deutche Bahn, Nemecko). Navrhovateľ uvádza, že obaja dopravcovia majú teda zhodné potreby na odbavovací systém: nástup cestujúcich prednými dverami, predaj cestovných lístkov vodičom, akceptácia bankových platobných kariet a dopravných čipových kariet, ovládanie periférií a pod. Navrhovateľ dáva do pozornosti, že v rámci ARRIVA TRANSPORT ČR (ARRIVA MORAVA, ARRIVA CITY a pod.) má nasadených viac ako 1 500 ks odbavovacích zariadení, dokonca s vyššou funkcionalitou ako požaduje kontrolovaný. Navrhovateľ ďalej uvádza, že v týchto odbavovacích zariadeniach používa operačný systém Windows a za viac ako 5 rokov prevádzky nebola navrhovateľovi vznesená ani jedna požiadavka na to, aby bol operačný systém voľne šíriteľný a ani jedna požiadavka na úpravu zdrojových kódov operačného systému. Navrhovateľ má za to, že operačný systém Windows sa neviaže na jediného dodávateľa, ako nesprávne tvrdí kontrolovaný, práve naopak, systém Windows umožňuje inštalovať aplikácie tretích strán, čo aj kontrolovaný v súťažných podkladoch požadoval a bolo to i jedno z kritérií na vyhodnotenie ponúk. Navrhovateľ vyjadruje názor, že kontrolovaný - ako člen skupiny Arriva - má vedomosť o tom, že navrhovateľ vo svojich riešeniach používa operačný systém Windows a aj preto je požiadavka kontrolovaného ohľadne operačného systému jednoznačne diskriminačná a priamo poškodzujúca navrhovateľa.
23. Navrhovateľ má za to, že postup kontrolovaného je účelový a v rozpore s princípmi verejného obstarávania. Navrhovateľ uvádza, že ak by mali platiť vyjadrenia kontrolovaného o tom, že má záujem o to, aby bol okruh subjektov spôsobilých predložiť ponuku čo najširší, neexistuje technický argument, pre ktorý by nemala byť akceptovaná aj technická platforma Windows.
24. Navrhovateľ v rámci petitu námietok navrhuje, aby úrad rozhodol

: § 175 ods. 1 písm. a) zákona o verejnom obstarávaní a rozhodnutím nariadil odstrániť protiprávny stav tým, že kontrolovaný upraví, resp. doplní súťažné podklady o navrhovateľom požadovaný rozsah informácií, so súčasným predĺžením lehoty na predloženie ponuky a alternatívne navrhuje, aby 5 úrad rozhodol

§ 175ods.

1 písm. b) zákona o verejnom obstarávaní a rozhodnutím zrušil verejné obstarávanie a následne, aby kontrolovaný vyhlásil nové verejné obstarávanie s rovnakým predmetom zákazky, avšak s doplnenými súťažnými podkladmi o navrhovateľom požadovaný rozsah informácií. Začiatok konania o preskúmanie úkonov kontrolovaného na základe námietok 15.

§ 171ods.

1 zákona o verejnom obstarávaní sa konanie o preskúmanie úkonov kontrolovaného na základe námietok začína dňom doručenia námietok úradu. Na základe uvedeného úrad konštatuje, že predmetné konanie o preskúmanie úkonov kontrolovaného na základe námietok začalo dňa 17. 10. 2019. 16.

§ 173ods.

1 písm. a) zákona o verejnom obstarávaní je kontrolovaný povinný doručiť úradu písomné vyjadrenie k podaným námietkam a kompletnú dokumentáciu

§ 24

zákona o verejnom obstarávaní v origináli do siedmich dní odo dňa doručenia námietok, ak ide o konanie o preskúmanie úkonov kontrolovaného na základe námietok. Úrad dokumentom zo dňa

2. 2019 č. 14434-6000/2019-OD-L označeným ako ,,Informácia o začatí konania o preskúmanie úkonov kontrolovaného na základe námietok a žiadosť o doručenie písomného vyjadrenia k podaným námietkam a kompletnej dokumentácie v origináli“ vyzval kontrolovaného na doručenie písomného vyjadrenia k podaným námietkam a dokumentácie v origináli a zároveň vyzval kontrolovaného, aby zriadil úradu prístup do elektronického prostriedku použitého na elektronickú komunikáciu. Kontrolovaný dňa
4. 2019 doručil úradu písomné vyjadrenie k námietkam spolu s dokumentáciou v origináli. Úrad skonštatoval, že predloženú dokumentáciu nebolo možné považovať za kompletnú a dokumentom č. 144346000/2019-OD-P zo dňa
6. 2019 prerušil konanie o preskúmanie úkonov kontrolovaného na základe námietok. Kontrolovaný dňa
8. 2019 zriadil úradu prístup do elektronického prostriedku použitého na elektronickú komunikáciu systému ELENA, a teda doplnil úradu dokumentáciu k predmetnej verejnej súťaži. Preskúmaním doručenej, resp. sprístupnenej dokumentácie úrad zistil, že predložená dokumentácia je kompletná. Písomné vyjadrenie kontrolovaného k námietkam
9. Kontrolovaný vo vyjadrení k námietkam k tvrdeniu navrhovateľa, že úrad nariadil zrušiť uvedený postup zadávania zákazky nakoľko vyhodnotil, že postup kedy nebol poskytnutý interface je nedostatočný pre riadnu prípravu ponuky uvádza, že dané tvrdenie nie je pravdivé a poukazuje na čl. 34 rozhodnutia úradu č. 14356-6000/2018-OD zo dňa
11. 2019, kde je uvedené, cit.: ,,Samotný opis rozhraní k SAM modulu a autentifikačný kľúč k SAM modulu sú určite potrebné pri realizácii zákazky, ale nie aj na ponuky. Opis údajových štruktúr na čipovej karte a prístupové kľúče k čipovej karte tiež nie je nevyhnutné poznať na predloženie ponuky, ale až pri realizácii zákazky. Opis procesov práce s čipovou kartou je na predloženie ponuky potrebné poznať na úrovni vymenovania operácii s čipovými kartami. Opis údajových rozhraní na kartový back-office, čiže rozhranie k softvéru prevádzkovanému v riadiacom počítači vo vozidle, je zase potrebné poznať až pri realizácii zákazky“. 6
12. K argumentácii navrhovateľa ohľadne uplatnenia modelu zmluvy (NDA) o ochrane poskytnutých informácií, pričom navrhovateľ uvádza, že kontrolovaný má rôzne možnosti použitia modelu NDA zmluvy a ako príklad navrhovateľ uvádza postup Dopravného podniku Hradec Králové, kedy predmetný verejný obstarávateľ poskytol údaje všetkým uchádzačom po podpise NDA zmluvy, kontrolovaný uvádza, že akceptuje existenciu aj iných možností použitia modelu NDA zmluvy v zmysle opisu navrhovateľa v konkrétnych prípadoch. Poukazujúc na príklad uvedený navrhovateľom kontrolovaný uvádza, že v danom príklade išlo o poskytnutie podrobných údajov o karte Mifare Classic, ktorej bezpečnosť bola už aj tak prelomená v roku 2009 a tento typ karty v DPHK, ale aj u iných vydavateľov dožíva, je nahrádzaný inými bezpečnejšími typmi kariet. V predmetnom verejnom obstarávaní však kontrolovaný vychádza z existujúceho právneho stavu, kedy úrad v rozhodnutí č. 14356-6000/2018-OD zo dňa
14. 2019 exaktne popísal v bodoch 34.,
15. a 36., že uvedenými informácia nie je potrebné disponovať v etape predkladania ponúk a uchádzači potrebujú tieto informácie až v momente realizácie projektu. Kontrolovaný má za to, že sprístupnenie informácií víťaznému uchádzačovi na základe NDA je tak v súlade s platnou legislatívou a rozhodnutím úradu č. 14356-6000/2018OD a kontrolovaný si vybral túto možnosť ako vhodnú z hľadiska právneho, obchodného aj administratívneho.
16. Kontrolovaný vo vzťahu k tvrdeniu navrhovateľa, kde navrhovateľ uvádza, že postup poskytnutia údajov o existujúcich systémoch v rámci prostredia verejného obstarávateľa je možný aj v súlade so zákonom o verejnom obstarávaní, poukazujúc na oznámenie o vyhlásení verejného obstarávania v európskom vestníku dňa 06.08.2019 pod zn.: 2019/S 150-369984, vo vestníku úradu č. 22472 MSS, Vestník č. 160/2019 - 07.08.2019, kedy Generálne riaditeľstvo zboru väzenskej a justičnej stráže priamo aplikovalo predmetný model, kedy detaily opisu predmetu zákazky sa poskytujú len uchádzačom po predchádzajúcom podpise NDA zmluvy uvádza, že odmieta tvrdenie navrhovateľa o nezákonnom postupe, ktorý mal byť spôsobený tým, že kontrolovaný si z dvoch zákonne rovnocenných alternatív vybral inú možnosť ako požaduje jeden konkrétny uchádzač. Kontrolovaný ďalej uvádza, že odmieta tvrdenie navrhovateľa, že kontrolovaný porušuje princípy verejného obstarávania alebo, že „umelo vytvára situáciu vendor lock in“. Kontrolovaný má za to, že dôkazom, že ide o nepravdivé tvrdenie je skutočnosť, že na každú žiadosť o vysvetlenie súťažných podkladov bolo poskytnuté vysvetlenie a zároveň primerane predĺžená lehota na podanie ponuky a dodáva, že všetky potrebné údaje na vypracovanie ponuky dostal každý uchádzač a podrobnú špecifikáciu potrebnú pre realizáciu predmetu zákazky dostane víťazný uchádzač nezávisle od výsledku obstarávania, čím

názoru kontrolovaného nedochádza k diskriminácii.

1. Kontrolovaný ohľadom navrhovateľom namietaného postupu, v zmysle ktorého kontrolovaný neposkytol detailnejšiu špecifikáciu čipových kariet Mifare Classic, Mifare DESFire EV1 a Mifare DESFire, pričom navrhovateľ požadoval dátové štruktúry karty a popis práce s kartou uvádza, že v nadväznosti na žiadosť o vysvetlenie zo dňa
3. 2019 doplnil požadované informácie vo vysvetlení súťažných podkladov zverejnenom dňa
7. Ďalej kontrolovaný v súvislosti s tvrdením navrhovateľa, že kontrolovaný neumožňuje predloženie technického riešenia aj na technológii Windows preferuje konkrétnych dodávateľov 7 uvádza, že štandardný procesorový modul CPU využívaný v embedded systémoch umožňuje fungovanie rôznych operačných systémov: Windows, Linux, Android a pod. Kontrolovaný uvádza, že ak navrhovateľ ponúka aplikáciu vytvorenú

bežných kvalitatívnych a bezpečnostných štandardov, táto je tvorená aj s ohľadom na portabilitu, t. j. prevádzkovanie na rôznych platformách operačných systémov.

kontrolovaného s ohľadom na túto skutočnosť portácia jeho aplikácie na „open source“ operačného systému nemôže spôsobiť významné navýšenie nákladov vo vzťahu k celkovej predpokladanej hodnote predmetnej zákazky. Kontrolovaný zároveň trvá na kvalitatívnej požiadavke na operačný systém z hľadiska „open source“, nakoľko je táto požiadavka v súlade s internou politikou Skupiny ARRIVA Slovakia najmä, nie však výlučne z hľadiska bezpečnosti jej systémov. Kontrolovaný uvádza, že doba životného cyklu operačného systému Windows je časovo obmedzená a po jeho ukončení môžu vzniknúť bezpečnostné riziká, ktoré by kontrolovaný nedokázal ovplyvniť. Vzhľadom na predpokladanú životnosť systému, ktorý je predmetom verejného obstarávania, ide o skutočnosť, ktorá môže reálne nastať. Na rozdiel od „open source“ operačného systému nie je možné pri operačnom systéme Windows poskytnúť zdrojové kódy akémukoľvek novému dodávateľovi na odstránenie týchto bezpečnostných chýb v operačnom systéme. Kontrolovaný má za to, že operačný systém Windows embedded a jeho použitie v palubných počítačoch nie je v súlade so stratégiou ARRIVA na Slovensku a všetky dopravné podniky majú palubné počítače výlučne na ,,open source“ riešení, čiže voľne šíriteľnom, ktoré umožňuje ďalšie úpravy a prispôsobenia programu, ktoré vyžaduje objednávateľ dopravy ako aj dopravca

ľubovôle a s použitím bežne dostupných nástrojov. Kontrolovaný dodáva, že všetky periférie použité vo vozidlách by mali spĺňať štandardy https://itxpt.org/. ktoré sú odporúčané v Arriva UK. Kontrolovaný má za to, že použitím Windows ako platformy pre palubné počítače, by mala spoločnosť Arriva nesúlad v perifériách. Taktiež ďalšie úpravy, by boli možné len s takými nástrojmi, ktoré sú povolené od spoločnosti Microsoft.

kontrolovaného pri použití Windows ako platformy, by sa museli zariadenia meniť omnoho častejšie, nakoľko sú závislé len od spoločnosti, ktorá pokiaľ bude chcieť, neumožní podporu starších zariadení. Kontrolovaný má za to, že riešenie na báze „open source“ je bežné riešenie, ktoré okrem navrhovateľa nerozporovali iní uchádzači a dokonca aj sám navrhovateľ na svojej webstránke uvádza podporu systémov na báze „open source“ operačných systémov.

1. Kontrolovaný záverom dodáva, že ak má navrhovateľ vedomosti o tom že kontrolovaný používa vo svojich riešeniach systémy Windows, tak musí aj vedieť, že žiadny dopravca Arrivy na Slovensku, ich nemá vo svojich perifériách vo vozidlách, čo je jeden z dôvodov vylúčenia tejto platformy. Zistenia úradu
2. Kontrolovaný vyhlásil vo Vestníku verejného obstarávania č. 172/2019 dňa
4. 2019 pod značkou 23392 – MST a v Úradnom vestníku Európskej únie č. 2019/S 162-397826 dňa
6. 2019 verejnú súťaž na predmet nadlimitnej zákazky „Tarifno-informačné zabezpečenie integrovaného dopravného systému autobusov východnej časti Košického samosprávneho kraja, Referenčné číslo: ARRIVA MI-NZ-VS-2019-TIS“. V závislosti od predmetu zákazky, typu kontrolovaného a predpokladanej hodnoty zákazky vo výške 2 235 871,67,- Eur bez DPH ide 8 o nadlimitnú zákazky na dodanie tovaru. V lehote na predkladanie ponúk, t. j. do
8. 2019 do 09.00 hod. resp. na základe oznámenia o dodatočných informáciách zverejnenom vo Vestníku č. 42/2020 dňa
10. 2020 pod označením 10051 – IOX, t. j. v lehote na predkladanie ponúk do
12. 2020 do 09.00 hod. nepredložil ponuku žiaden zo štyroch záujemcov. Navrhovateľ podal dňa
14. 2019 žiadosť o nápravu v zmysle § 164 ods. 1 písm. b) zákona o verejnom obstarávaní. Kontrolovaný dňa
16. 2019 predmetnej žiadosti o nápravu čiastočne vyhovel a čiastočne žiadosť o nápravu zamietol, pričom v nadväznosti na zamietnutie žiadosti o nápravu navrhovateľ doručil dňa
18. 2019 kontrolovanému i úradu námietky smerujúce

§ 170ods.

3 písm. b) zákona o verejnom obstarávaní proti podmienkam uvedeným v iných dokumentoch potrebných na vypracovanie žiadosti o účasť, ponuky alebo návrhu poskytnutých kontrolovaným.

1. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 1: Palubný počítač HW, Palubný počítač SW pre PAD a MHD (Položka č. 1-2 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy)“ súťažných podkladov sa uvádza, cit.: ,,Podrobná špecifikácia výkonnostných a funkčných požiadaviek pre dodávku a montáž 199 ks palubného počítača
3. Základný opis 1.1 Verejný obstarávateľ obstaráva technologické riadiace zariadenie označované ako palubný počítač (ďalej len „PP") vozidla s príslušenstvom: tlačiareň a čítačka bezkontaktných čipových kariet vrátane kariet

štandardu EMV. 1.2 Zariadenie je primárne určené na predaj cestovných lístkov vrátane storna a ostatné, nižšie uvedené súvisiace činnosti spojené so systémom verejnej osobnej dopravy / ďalej VOD / vo vozidlách prímestskej a mestskej hromadnej dopravy (ďalej len „PAD a MHD"). 1.3 Zariadenie bude slúžiť aj pre centrálnu správu a riadenie jednotlivých periférií a subsystémov ďalej definovaných vo funkčnej a technickej špecifikácii a zber, vyhodnocovanie a prenos dát do centrálneho riadiaceho systému dopravcu v celkovom počte 199 kusov. 1.4 PP musí byť dodaný ako komplexné systémové plnenie, t. j. bude dodaný vrátane montáže s využitím prípravy na jeho osadenie, príslušného komunikačného zariadenia (napr. rozvodná doska) a príslušnej kabeláže a príslušného programového vybavenia s platnými podmienkami prepravného poriadku autobusovej dopravy verejného obstarávateľa uvedených na www.arrivami.sk 1.5 Verejný obstarávateľ požaduje zabezpečiť komunikáciu s dopravným dispečingom ARRIVA Michalovce, a.s. implementáciou používaného interface tak, aby bolo zabezpečené jednotné ovládanie a vzájomná komunikácia medzi vozidlami, dispečingom a ostatnými perifériami

dnešného jestvujúceho stavu ARRIVA Michalovce, a.s. 1.6 Všetky vynútené hardvérové, softvérové a firmwarové úpravy na strane ARRIVA Michalovce, a.s., ktoré majú zabezpečiť jednotné ovládanie a vzájomnú komunikáciu medzi vozidlami, dispečingom, ostatnými perifériami a backofficom dopravcu, musia byť započítané do ponuky. 2. Funkčné požiadavky na palubný počítač 2.1 všeobecné požiadavky na palubný počítač (PP) 9 2.1.1 slúži ako riadiaca a pamäťová jednotka pre ukladanie dát pre jednotlivé periférne zariadenia vo vozidlách dopravcu - tlačiarne, čítačky, označovače, komunikačný modul, informačné tabule, hlásiče zastávok. 2.1.2 predaj cestovných lístkov v platnej tarife PAD a MHD k dňu predloženia ponuky 2.1.3 platba v hotovosti 2.1.4 platba dopravnou kartou 2.1.5 platba bankovou kartou 2.1.6 kontrola platnosti elektronického cestovného lístka na dopravnej karte (dáta z čítačky bezkontaktnej čipovej karty) 2.1.7 kontrola platnosti papierového lístka s 2D kódom (dáta z čítačky 2D kódu) 2.1.8 kontrola zablokovaných dopravných kariet 2.1.9 akceptácia cestovných lístkov predávaných cez internet 2.1.10 evidencia tržby z predaných cestovných lístkov 2.1.11 on-line sledovanie a posielanie polohy vozidla 2.1.12 on-line vyhodnocovanie polohy vozidla a zobrazenie meškania/nadbiehania pre vodiča 2.1.13 spracovanie a posielanie dát pre informačné tabule 2.1.14 spracovanie a posielanie dát pre zvukové hlásiče 2.1.15 zobrazenie zastávok na mapovom podklade 2.1.16 nahrávanie vstupných dát (cestovné poriadky, tarify, informačné tabule, zvukové hlásiče) z centrálneho systému cez WiFi a cez 3G/4G modem 2.1.17 vyčítavanie záznamov o predaných cestovných lístkov do centrálneho systému cez WiFi a cez 3G/4G modem 2.1.18 zabezpečenie proti neoprávnenej manipulácii (prihlásenie vodiča) 2.2 ako základné programové vybavenie zariadenia sa požaduje: 2.2.1 zariadenie umožňuje poskytovať percentuálnu zľavu z cestovného lístka na základe evidencie o zaplatení poplatku za využívanie zľavového systému 2.2.2 zariadenie disponuje plnohodnotným voľne šíriteľným, upravovateľným vzdialene aktualizovateľným operačným systémom 2.2.3 zariadenie umožňuje poskytovať prestup, pričom cena prestupného lístka je daná doplatkom na základe súčtu tarifných kilometrov obidvoch odjazdených úsekov 2.2.4 zariadenie zachováva funkčnosť dátovo-komunikačných kanálov dopravcom používaných služieb (dispečerské pracovisko, exporty do ekonomických softvérov, zúčtovanie, ...) 2.2.5 konfigurovateľnosť dodávaného systému je zabezpečená pomocou back-office aplikácií pričom vykonané úpravy tarifného systému sú aktualizovateľné v zariadeniach na diaľku 2.2.6 pomocou backofficu je možné prepínať medzi podporou zónového, kilometrického, pásmového, časového tarifného systému 2.2.7 zariadenie umožňuje prechod medzi viacerými typmi tarifných systémov v rámci jedného spoja 2.2.8 zariadenie podporuje použitie odchýlkovej ceny medzi dvomi definovanými zastávkami spoja 2.2.9 zariadenie umožňuje konfigurovateľný mechanizmus hlásenia zastávok do vozidla 2.2.10 ovládanie jednotlivých periférií umiestnených vo vozidle - čítačky, označovače, tlačiarne, komunikačný 10 modul, informačné tabule, hlásič pre nevidomých 2.2.11 identifikácia vozidla - palubný počítač vo vozidle musí niesť identifikačné znaky príslušného vozidla, t. j. evidenčné číslo vozidla 2.2.12 príprava a prenos vstupných dát pre PP, ktoré obsahujú: a) grafikon (cestovné poriadky) b) tarify a ceny c) zablokované čipové karty, služby predávané cez internet d) informácie zobrazované na informačných tabuliach e) hlasové informácie hlásené cestujúcim f) databázy pre obsluhu informačných prostriedkov vo vozidle:  informačné tabule  hlásiče zastávok  ďalšie dopravné informácie g) služby vodičov h) plán služieb vodičov a vozidiel 2.2.13 PP musí spolupracovať s dispečingom a sledovať: a) zapínanie b) vypínanie c) stavové správy v aktuálnom rozsahu d) ovládanie hlasovej komunikácie e) generovanie vopred definovaných textových správ 2.2.14 PP musí zabezpečiť: a) sledovanie polohy vozidla  súradnice polohy vozidla  meškanie spoja  nadbiehanie spoja  prepínanie zastávok

aktuálnej polohy vozidla

1. b)zasielanie textových správ na centrálny dispečing
2. c)príjem textových správ do vozidla  vybranému vodičovi  všetkým vodičom  vybranej skupine vodičov - na vybranej linke - na spojoch predchádzajúcich vybraným úsekom
3. d)monitorovanie stavu všetkých riadiacich, informačných a tarifných elektronických zariadení vo vozidle, pre prípad potreby realizovať výmenu nefunkčných zariadení alebo vozidla
4. e)riadenie informačného systému vozidla formou:  riadenia zobrazovania informácii na všetkých informačných tabuliach vozidla  riadenia hlásenia cestujúcim cez vozidlovú audio sústavu 2.2.15 vstupné a výstupné dáta z PP zabezpečia:
5. a)zber a záznam dát technologických procesov vozidla
6. b)dátový prenos prostredníctvom WiFi a GSM siete 11  vo vozovni dopravcu medzi vozidlom a výpravňou (rozpoznanie vozidla a aktualizáciu dát informačného a vybavovacieho systému počas doby vozidla vo výpravni bez zásahu človeka) 2.2.16 vstupné a výstupné dáta pre PP používané verejným obstarávateľom:
7. a)grafikon
8. b)údaje pre akustické a optické systémy musia spĺňať štandardy zariadení používaných v súčasnosti vo vozidlách verejného obstarávateľa 2.2.17 všetky vstupné dáta musia umožňovať pracovať minimálne s dvoma časovými platnosťami, ktoré sa súčasne nahrajú do PP a automaticky prepnú

nastavenej časovej platnosti, pričom každý typ dát musí mať vlastnú platnosť 2.3 požiadavky z hľadiska vodiča: 2.3.1 PP musí umožňovať prácu v automatickom režime, t.j. po prihlásení vodiča čipovou kartou (možnosť voľby linky, trasy, smeru v závislosti od dňa služby) a prihlásení vodiča nastaví plánovanú službu a

času, polohy a vybranej služby vozidla PP automaticky prepína zastávky, nastavuje spoje až do skončenia služby 2.3.2 podpora navigácie vodiča formou mapových podkladov 2.3.3 informácie o aktuálnej službe - začiatok, koniec, zoznam spojov, prejazdy a iné plánované činnosti, ktoré sú zadané v popise služby 2.3.4 PP počas jazdy poskytuje vodičovi informácie o priebehu jazdy (meškanie, nadbiehanie) 2.3.5 PP umožňuje operatívne zmeny plánovanej trasy linky, služby 2.3.6 PP umožňuje komunikáciu medzi vodičom a dispečingom formou textových správ vrátane posielania núdzových hlásení 2.3.7 PP poskytuje informácie o pripravenosti vozidla na prácu z pohľadu funkčnosti všetkých elektronických zariadení, ktoré riadi - HW funkčnosť, aktuálna verzia SW, aktuálna verzia dát; funkčnosť je zobrazená jednoduchým spôsobom - funkčný, čiastočne funkčný, nefunkčný 2.3.8 PP musí obsahovať ochranu proti zneužitiu minimálne takým spôsobom, že systém je aktívny až po prihlásení a identifikácii vodiča osobným identifikačným kľúčom (služobná bezkontaktná čipová karta); systém súčasne musí umožniť aj tzv. 2 stupňovú autentifikáciu - karta a PIN 2.3.9 poskytovanie zobrazenia stavu zariadení v prípade poruchy - systémový monitoring vo vozidle pre vodiča 2.3.10 umožniť blokovanie (odblokovanie) výdaja lístkov pri mimoriadnej preprave 2.4 požiadavky z hľadiska prevádzkovateľa systému: 2.4.1 systém musí umožňovať kontinuálne udržiavanie prevádzkyschopného stavu, t. j. umožniť jednoduchú výmenu periférnych zariadení bez akéhokoľvek manuálneho nastavovania identifikačných a prevádzkových parametrov 2.4.2 PP musí zabezpečiť nastaviteľnú tlač lístkov 2.4.3 PP musí neustále vykonávať zálohu ukladaných - sledovaných dát pre prípad poškodenia úložnej pamäte, prípadne iných častí PP, alebo systému, pričom záložná pamäť musí mať kapacitu v minimálnom rozsahu 30 kalendárnych dní prevádzky 2.4.4 systém musí monitorovať stav zariadení (SW aplikácia v zariadeniach, HW status) a vykonávať indikáciu v prípade poruchy prevádzkovateľovi systému 12 2.4.5 z hľadiska ergonomických vlastností musí mať PP uchytenie umožňujúce jeho prestavenie v ľubovoľnom vertikálnom a aj horizontálnom smere tak, aby mal každý vodič možnosť individuálne si prestaviť zorný a pracovný uhol potrebný na obsluhu PP 2.4.6 nábeh systému (PP) do 40 sekúnd po stlačením ,,štart", so zvukovou signalizáciou nábehu 2.5 požiadavky z hľadiska tarifného vybavenia cestujúcich a prepravnej kontroly: 2.5.1 z hľadiska ergonomických vlastností musí mať PP uchytenie umožňujúce jeho častí tlačiarne a čítačky čipových kariet, EMV kariet a príp. čítačky 2D kódu- umiestniť tak, aby mal cestujúci prístup potrebný pre priloženie karty k čítačke kariet a prevzatie vytlačeného papierového lístka. 2.5.2 PP musí umožniť blokovať a aj odblokovať výdaj lístkov 2.5.3 v prípade kontroly CL

požiadaviek dopravcu; PP musí umožniť poskytnúť všetky dopravcom požadované informácie o všetkých vykonaných kontrolách, minimálne v obsahu kód zastávky, služobné číslo revízora, ktorý výdaj lístkov zablokoval pre ďalšie použitie počas výkonu kontroly 2.5.4 poskytnúť prepravnému kontrolórovi zoznam predpokladaného počtu ľudí vo vozidle aj s výstupnými zastávkami 2.5.5 PP poskytuje informácie o počte predaných CL na aktuálnom spoji, prenos údajov sa uskutoční bezdrôtovým spôsobom pri príjazde vozidla do vozovne, resp. cez GSM sieť 3. Technické (výkonnostné a funkčné) požiadavky 3.1 on-line bezdrôtová dátová komunikácia prostredníctvom technológie 3G/4G a WIFI s centrálnym dispečingom 3.2 komunikačné rozhrania integrované v PP (tvoriace jeden celok): 3.2.1 WiFi 802.11 a/b/g/n 3.2.2 4G/3G modem 3.2.3 RS 485 3.2.4 USB 2.0 HS 3.2.5 ethernet 10/100/1000Mbps 3.3 priemyselné prevedenie vhodné do vozidiel (prašnosť, otrasy, teplotné podmienky) 3.4 výkonný viacjadrový procesor na báze ARM 3.4.1 možnosť integrovať navigačný systém pre vodičov 3.4.2 2D, 3D grafická akcelerácia 3.4.3 doba nábehu zariadenia do funkčnosti prihlásenia vodičom do 40 sekúnd 3.5 ovládanie pomocou dotykového kapacitného displeja: 3.5.1 s veľkosťou minimálne 10" 3.5.2 s rozlíšením minimálne 1024 x 600 pixelov 3.5.3 s dobrou čitateľnosťou za zhoršených svetelných podmienok (svietivosť min. 500 Cd/m2) 3.5.4 bezpečnostné tvrdené sklo (kalené) - min. hrúbka 3 mm 3.5.5 povrchová úprava antiglare 3.5.6 kapacitný dotykový panel odolný voči RF rušeniu 10V/m 3.5.7 životnosť displeja - min. 30 000 hodín 3.5.8 detekcia okolitého jasu s možnosťou automatickej zmeny podsvietenia displeja 13 3.6 pamäť: 3.6.1 RAM - min. 1 GB 3.6.2 interná FLASH pamäť - min. 4 GB 3.6.3 priemyselná SLC SD karta - min. 512 MB 3.6.4 rozšíriteľná interná FLASH pamäť pomocou mSATA modulu 3.7 audio informačný systém: 3.7.1 interný digitálny mikrofón 3.7.2 interný reproduktor 3.7.3 možnosť pripojenia externého mikrofónu 3.7.4 nezávislé externé výkonové audio kanály - min. 2 3.8 jednoduchá montáž s využitím prípravy na jeho osadenie 3.9 umiestnenie na držiak s flexibilným polohovaním PP vo všetkých smeroch so zaslepením otvoru existujúceho PP 3.10 napájanie: 3.10.1 nominálne napätie s palubnej siete vozidla 24 V 3.10.2 pracovné napätie 10 V - 36 V 3.10.3 prepäťová ochrana do 36 V 3.10.4 záložná batéria ako interná súčasť PP pre účely: a) korektného vypnutia PP pri úplnej strate štandardného napájania bez straty aktuálnych údajov b) záložná batéria umožňujúca udržať zariadenie v prevádzke pri výpadku napájania po dobu min. 30 minút, počas ktorých zariadenie pošle informáciu o výpadku, polohu zariadenia a zabezpečí korektné ukončenie činnosti a spoľahlivé uloženie dát c) umožňujúca po štandardnom vypnutí,

požiadaviek dopravcu, zobúdzanie zariadenia a priebežné informovanie o aktuálnej polohe zariadenia, minimálne po dobu 3 pracovných dní 3.11 pracovné teploty minimálne -20 °C ... +60°C 3.12 relatívna vlhkosť vzduchu 5% - 85% bez kondenzácie 3.13 sledovanie polohy vozidla:

1. a)pomocou systému GPS a GLONASS s hardvérovou podporou GALILEO
2. b)externá anténa 3.14 bezpečnostný modul - min. 4 x SAM slot 3.15 EMC certifikát 3.16 certifikát krytia IP 43 3.17 pripojenie napájanie a externých zariadení pomocou priemyselných konektorov 4 Požiadavky na komunikáciu systému 4.1 komunikácia medzi PP a systémom dopravcu je zložená a pracuje nasledovne: 4.1.1 komunikačný modul v PP a vysielacia/prijímacia anténa 4.1.2 komunikačný modul na príjazde do jednotlivých vozovní pre komunikáciu s PP na jednotlivých vozidlách 4.2 všetky PP musia dokázať komunikovať s Dispečerským riadiacim systémom v reálnom čase 4.3 v prechodnom období (v období modernizácie tarifného systému) musí byť celý systém plne funkčný 14 4.4 Komunikácia (vyčítavanie údajov) musí byť zabezpečená aj v tzv. sleep mode 4.5 Komunikácia musí byť zabezpečená minimálne WPA2 šifrovaním, alebo MAC filtráciou“. 25. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 2: Tlačiareň cestovných lístkov s čítačkou BČK, čítačkou EMV kariet a čítačkou 2D kódu (Položka č. 1-2 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy)“ súťažných podkladov sa uvádza, cit.: ,,Špecifikácia tlačiarní cestovných lístkov s čítačkou BČK vrátane čítačky EMV kariet a 2D kódu pre dodávku a montáž 199 ks k PP 1. všeobecné požiadavky na tlačiareň cestovných lístkov zariadenie pre tlač papierových cestovných lístkov vo vozidlách PAD a MHD 2. požadované funkčné charakteristiky a technické (výkonnostné) parametre: 2.1 priemyselné prevedenie vhodné do vozidiel (prašnosť, otrasy, teplotné podmienky) 2.2 ergonomický dizajn 2.3 tlačiareň cestovných lístkov 2.3.1 vysoko-rýchlostný, odolný mechanizmus tlače 2.3.2 farebný displej pre zobrazenie informácie cestujúcemu 2.3.3 komunikačné rozhranie Ethernet s priemyselnými konektormi 2.3.4 rýchlosť tlače - min. 150 mm/s (10 lístkov do 15s) 2.3.5 životnosť tlačovej hlavy - min. 1x108 bodov 2.3.6 životnosť rezačky - min. 1 x 106 zárezov 2.4 čítačka BČK 2.4.1 ISO 14443 A, B 2.4.2 kompatibilné s existujúcim systémom dopravných kariet (kalkulácia nákladov na zabezpečenie kompatibility v cene zariadenia)
3. a)Mifare Classic
4. b)Mifare DESFire EV1
5. c)Mifare DESFire EV2 2.5. čítačka EMV kariet 2.5.1 platba bankovou kartou (bezkontaktné platby) 2.6. čítačka 2D kódu 2.6.1 čítanie QR kódu“. 26. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 3: Komunikačná jednotka (Položka č. 1-2 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy)“ súťažných podkladov sa uvádza, cit.: ,,Dodávka a montáž 199 ks komunikačnej jednotky 1. Komunikačná jednotka 1.1 všeobecné požiadavky na komunikačnú jednotku 1.1.1 zariadenie pre pripojenie ovládaných periférnych zariadení k palubnému počítaču vo vozidlách PAD a MHD 1.2 požadované funkčné charakteristiky a technické (výkonnostné) parametre: 1.2.1 priemyselné prevedenie vhodné do vozidiel (prašnosť, otrasy, teplotné podmienky) 15 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 ethernetový switch - min. 5 port s konektormi s aretáciou (napr. push/pull) 1-wire - min. 3 digital input - min. 4 digital output - min. 2 RS 485“. 27. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 4: Podstava (Položka č. 1-2 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy)“ súťažných podkladov sa uvádza, cit.: ,,Dodávka montáž 199 ks pre PP a tlačiareň 1. Podstava + pokladňa 1.1 všeobecné požiadavky na podstavu 1.1.1 zariadenie pre uchytenie palubného počítača a tlačiarne s čítačkou kariet vo vozidlách PAD a MHD 1.1.2 uzamykateľná pokladňa s priehradkami na mince 1.2 Požadované funkčné charakteristiky a technické (výkonnostné) parametre: 1.2.1 nastaviteľné držiaky, ktoré umožňujú prispôsobiť polohu displeja palubného počítača potrebám vodiča a počas inštalácie prispôsobiť natočením polohu tlačiarne s čítačkou kariet potrebám cestujúcich“. 28. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 5: Personalizačné pracovisko (zákaznícke pracovisko) Položka č. 3 Prílohy č. 2 súťažných podkladov/Príloha č. 1 Zmluvy“ súťažných podkladov sa uvádza, cit.: ,,Dodávka a montáž 6 ks zariadení pre grafickú a elektronickú personalizáciu bezkontaktných čipových kariet (BČK) používaných PAD a MHD, zvyčajne označované ako personalizačné pracovisko 1. všeobecné požiadavky na inštaláciu predmetu zákazky do predpredajných pokladní dopravcu 1.1 požadované technické výkonnostné parametre: 2. tlačiareň pre potlač kariet 2.1 termosublimačná 2.2 jednostranná/obojstranná farebná tlač 2.3 rozlíšenie - min 300 x 600 dpi 2.4 konektivita – USB 3. čítačka BČK 3.1 čítanie kariet - ISO 14443 3.2 konektivita – USB 4. Fotopracovisko 4.1 rozlíšenie - min 8 Mpx 4.2 konektivita – USB 16 5. požadované funkčné charakteristiky: Tlačiareň na grafickú potlač BČK - termosublimačná - jednostranná/obojstranná farebná tlač - rozlíšenie - min 300 x 600 dpi - konektivita – USB Čítačka BČK - čítanie kariet - ISO 14443 A, B - konektivita – USB - bezpečnostný modul - min. 1x SAM slot Digitálny fotoaparát - rozlíšenie - min. 8 Mpx - konektivita – USB - fotografia na jeden klik (bez nakláňania, zaostrovania) Grafická a elektronická personalizácia BČK - editovateľná šablóna pre grafickú potlač - grafická potlač karty

vytvorenej šablóny - zápis údajov vydavateľa karty - zápis údajov držiteľa karty Personálny počítač - procesor Intel Core i5 – 7500 - frekvencia od 3,4 GHz - vyrovnávacia pamäť od 6 MB - pevný disk SSD min. 256 GB - pamäť DDR4 min. 8 GB - sieťový adaptér 10/100/1000 Mbit/s - rozhrania min. 4x USB 3.0 z toho min. 2x na prednom paneli 1x RJ45 1x HDMI 1x VGA - OS Windows 10 64-bit - LCD monitor min. 21,5" - záložný zdroj s výstupným výkonom min. 700 VA 6. fotografia 6.1 fotografia na jeden klik (bez nakláňania, zaostrovania) 7. grafická personalizácia dopravných kariet 7.1 vytvorenie šablóny pre potlač karty 17 7.2 potlač karty

vytvorenej šablóny

1. elektronická personalizácia dopravných kariet 8.1 zápis údajov vydavateľa karty 8.2 zápis údajov držiteľa karty“.
2. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 6: Vozidlový informačný systém“ súťažných podkladov sa uvádza, cit.: ,,Logický celok 6: Vozidlový informačný systém Dodávka a montáž pre autobusy PAD a MHD: - vonkajšej-bočnej informačnej tabule 171 ks (Položka č. 4 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy), - vonkajšej-zadnej informačnej tabule 173 ks (Položka č. 5 a 9 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy), - tabule vnútornej min. 19" 30 ks (Položka č. 6 a 10 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy), - tabule vnútornej min. 29" 143 ks (Položka č. 7 a 11 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy).
3. Zariadenia vo vozidlách PAD pre zobrazenie čísla linky, názvu cieľovej zastávky, názvu nácestných zastávok a ďalších informácií pre cestujúcich na zastávkach a vo vozidlách, zvyčajne označované ako „vozidlový informačný systém“.
4. Obstarávateľ požaduje zariadenia dodať vrátane držiakov, kabeláže, montáže, pripojenia na palubný počítač vozidla vrátane príslušného programového vybavenia.
5. Požadované funkčné charakteristiky a technické (výkonnostné) parametre: 3.1 priemyselné prevedenie vhodné do vozidiel (prašnosť, otrasy, teplotné podmienky) 3.2 automatické nastavenie jasu v závislosti od okolitých svetelných podmienok 3.3 certifikát pre použitie vo verejnej doprave 3.4 parametre pre LED panely 3.4.1 vysoká svietivosť LED - min 500 mcd 3.4.2 široký vyžarovací uhol LED - min 120o 3.4.3 konektivita - RS485, ethernet 3.4.4 bočný informačný LED panel , min. počet bodov 19 x 120 3.4.5 zadný informačný LED panel, min. počet bodov 19 x 32 3.4.6 vnútorný informačný LCD panel
6. parametre pre LCD panely 4.1 svietivosť min19" LCD- min 250 cd/m2 4.2 rozlíšenie min19" LCD- min 1400x 900 bodov 4.3 svietivosť min 29" LCD- min 1000 cd/m2 4.4 rozlíšenie min29" LCD- min 1900 x 500 bodov 4.5 veľkosť displeja - min 19‘‘ a min 29" 18 4.6 kontrast min 4500:1 4.7 pozorovací uhol min 175” / 175” ( horizontál ny/verti kál ny) 4.8 automatické nastavenie jasu ( integrované optické čidlo) 4.9 certifikát - spĺňa príslušné smernice a normy pre použitie vo vozidlách verejnej dopravy 4.10 informačný LCD panel je riadený Palubným počítačom vozidla 4.11 zmena informácii na LCD panely: súčasťou LCD panela je schopnosť zmeny multimédií a prehratie aplikácie LCD panela prostredníctvom riadiaceho palubného počítača aj s využitím jeho GSM prenosu 4.12 konektivita – ethernet“.
7. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 7: Vozidlový kamerový systém (Položka č. 8 a 12 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy)“ súťažných podkladov sa uvádza, cit.: ,,Dodávka a montáž 173 ks kamerový systém do autobusov prímestskej a mestskej dopravy
8. všeobecné požiadavky na kamerový systém do vozidiel PAD a MHD 1.1 zariadenia pre nahrávanie kamerových záznamov vo vozidlách PAD a MHD, zvyčajne označované ako „vozidlový kamerový systém" 1.2 verejný obstarávateľ požaduje zariadenia dodať vrátane držiakov, kabeláže, montáže, pripojenia na palubný počítač vozidla vrátane príslušného programového vybavenia
9. požadované funkčné charakteristiky a technické (výkonnostné) parametre: 2.1 priemyselné prevedenie vhodné do vozidiel (prašnosť, otrasy, teplotné podmienky)modulárna zostava záznamového kamerového systému 2.2 rozhranie pre integráciu do nadradeného systému vozidla 2.3 možnosť nezávislého nasadenia alebo ako súčasť vozidlového informačného systému 2.4 prehrávanie záznamov z vozidla

zadaných kritérií - dátum hodina, vozidlo, kamera, pri splnení legislatívnych požiadaviek vyplývajúcich zo Zákona o ochrane osobných údajov 2.5 počet kamier v jednom vozidle minimálne - 2 + 1 (predná ) 2.6 veľkosť úložiska - min. 1 TB SSD 2.7 komunikácia - ethernet 100 Mbit/s 2.8 napájanie - cez zbernicu ethernet (PoE) 2.9 príslušenstvo - prevodník napájania z palubnej siete vozidla na napájanie kamery (zbernica IEEE 802.3af)

1. požadované parametre pre HW zariadenia do vozidla 3.1 napájanie z palubnej siete vozidla 24 V 3.2 pracovné napätie 10 ... 36 V 3.3 rozsah pracovných teplôt - 20 0C ...+60 0C 3.4 relatívna vlhkosť vzduchu 5 % ... 85% bez kondenzácie“.
2. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 8: Dodávka a inštalácia servera (HW a SW) Položka č. 13 – 27 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy)“ súťažných podkladov sa uvádza, cit.: ,,Dodávka a inštalácia servera v konfigurácii
3. Produkčný Server v konfigurácii: 19 1.1 Procesor: 1x Intel® Xeon® Gold 5115 2.4G, 10C/20T, 10.4GT/s 2UPI, 14M Cache, Turbo, HT (85W) DDR4-2400 - s min. výkonom 15 000 bodov

benchmarku PassMark® Software CPU Benchmark k 1.8.2019 1.2 Šasi: v prevedení rack, možnosť osadenia do 16 x 2.5" SAS/SATA/NL-SAS/SSD hot-plug diskov 1.3 Štandardný predný kryt 1.4 Operačná pamäť: 6x32GB RDIMM 2666MT/s Dual Rank modul (192GB) - možnosť rozšírenia na min. 384GB pri použití 1 CPU a 32GB modulov 1.5 Management karta: možnosť úplnej vzdialenej správy, prístup k BlOS-u servera 1.6 Harddisky: 7x 1.2TB 10K RPM SAS 12Gbps 512n 2.5in Hot-plug harddisk 1.7 Radič: Integrovaný hardvérový radič pevných diskov (RAID Controller) s 2 GB batériou zálohovanej cache, prípadne iná/obdobná ochrana cache pred výpadkom napájania; s podporou RAID 0, 1, 5, 6, 10 1.8 Interná DVD-ROM mechanika 1.9 Zdroj: Dual, Hot-plug, Redundant Power Supply (1+1), 750W - redundantný zdroj 1.10 Napájacie káble: 2x C13 to C14, PDU Style, 10 AMP, 2m 1.11 Sieťová karta: Broadcom 5720 QP 1 Gb Network Daughter Card (4 porty) 1.12 Sieťová karta: Broadcom 5720 DP 1Gb Network Interface Card (2 porty) 1.13 Koľajnice na montáž do racku s možnosťou vysunutia servera z racku, vrátane ramena na správu kabeláže 1.14 Záruka: poruchu je možné nahlasovať 24 hodín denne, 7 dní v týždni, pričom následný servisný zásah prevedie servisný technik výrobcu zariadenia do 4 hodín od nahlásenia poruchy (t. j. oprava do 4 hodín v čase dostupnosti služby pre Slovensko), a to na mieste inštalácie zariadenia, servis v trvaní minimálne 60 mesiacov od dodania zariadenia 1.15 Stojanový rozvádzač: 42U, 600x1000 predné a zadné dvere perforované 1.16 Rozvodný panel: PDU Rozvodný panel 19", 8 x IEC320 C13

1. UPS - záložný zdroj 2.1 UPS, 5000VA, prevedenie rack 2.2 line-interactive, vrátane Network management card pre manažment po LAN 2.3 záruka na UPS min. 3 roky, záruka na batériu min. 2 roky
2. NAS - diskové úložisko 3.1 Dátové úložisko - externá pozícia pre 5x 2,5/3,5“ SATA III HDD/SSD 3.2 CPU Intel Atom Quad-core 2.4GHz 3.3 4x GLAN, 4x USB 3.0, 2x eSATA, 1x PCIe 3.0 slot 3.4 5x 6TB HDD WD60EFRX - alebo ekvivalent SSD vhodné do NAS
3. Upgrade existujúceho servera 4.1 4x Certifikované pevné disky pre server DELL PowerEdge T110II: Kit - 2TB 7.2K RPM SATA 6Gbps 3.5in Cabled Hard Drive 4.2 2x 8GB 1600MHz ECC Low Voltage Module pre PE T110II
4. Externé zálohovacie zariadenie 20 5.1 Externý box pre HDD, pripojiteľný cez USB 3.0, vrátane USB 3.0 kábla, 4ks cartridge enterprise pevných diskov SATA o veľkosti 2TB/ks, ktoré je možné použiť ako vymeniteľné „náplne“ do externého boxu 5.2 Poruchu pre externý HDD je možné nahlasovať 9 hodín denne, počas pracovných dní; servis bude uskutočnený v nasledujúci pracovný deň po identifikovaní závady, Servis bude v trvaní minimálne 60 mesiacov od dodania zariadenia
5. Sieťový prepínač 6.1 4x TP-LINK T1600G-28TS JetStream™, 24-Port Gigabit Smart Switch, 4xSFP ports alebo ekvivalent 6.2 Static Routing, Tag-based VLAN, STP/RSTP/MST 6.3 CNS opt. Duplex patch kábel 9/125, LC/LC, 3m 6.4 7x TP-LINK TL-SM311LS MiniGbic/SFP modul - alebo ekvivalent kompatibilný so zariadením dodaným

bodu 6.

2. Licencie Virtuálne prostredie + backup 7.1 SW Vmware vSphere 6 Standard plus pre 1 CPU + Support & Subscripriton 1 rok 7.2 Virtualizačný softvér - licencia pre 1 CPU, Verejný obstarávateľ požaduje konkrétne tento softvér, vzhľadom na to, že v súčasnosti využíva tento softvér na svojej infraštruktúre, predmet tohto verejného obstarávania je rozšírením súčasnej infraštruktúry a verejný obstarávateľ nemá možnosť meniť celú technológiu virtualizácie s dopadom na náročné migrácie virtuálnych serverov do iného virtuálneho prostredia; zároveň verejný obstarávateľ požaduje zastrešenie novododaného servera a jeho virtuálneho prostredia do súčasného centralizovaného manažmentu virtuálneho prostredia (vCenter) 7.3 SW Veeam Availability Suite ENT, Veeam Availability Suite Enterprise for Vmware (includes Backup & Replication Enterprise + Veeam ONE), vrátane supportu a subscription na 1 rok 7.4 Zálohovací softvér - licencia pre 1CPU zálohovaného servera, Verejný obstarávateľ požaduje konkrétne tento softvér, vzhľadom na to, že v súčasnosti využíva tento softvér na zálohovanie serverov v pôvodnej infraštruktúre a nemá možnosť zmeniť technológiu zálohovania
3. Licencie Microsoft 8.1 SW MS WINDOWS Server 2016 Standard 2Core - Licencie operačného systému pre fyzický server (pre min. 2 CPU jedného servera), ktoré budú plne podporovať virtualizáciu a ktoré zároveň licenčne pokryjú operačné systémy pre min. 6 virtuálnych serverov bežiacich na tomto fyzickom serveri. Zároveň je nutné, aby licencia nebola viazaná na použitie iba na tomto konkrétnom fyzickom serveri (teda, nemá sa jednať o licenciu tzv. OEM, a to z dôvodu umožnenia migrácie virtuálnych serverov na iný fyzický server). Požaduje sa dodanie nových licencií, nie tzv. recyklovaných 8.2 SW MS WINDOWS Server 2016 User CAL - Klientske licencie na prístup na server pre klientské zariadenia, kompatibilné s dodaným operačným systémom. Je nutné, aby licencia nebola viazaná na použitie iba na tomto konkrétnom fyzickom serveri (teda, nemá sa jednať 21 o licenciu tzv. OEM, a to z dôvodu umožnenia migrácie virtuálnych serverov na iný fyzický server). Požaduje sa dodanie nových licencií, nie tzv. recyklovaných. Počet kusov: 70 8.3 SW MS WINDOWS RDS 2016 User CAL - Klientské licencie na prístup na server prostredníctvom vzdialenej plochy - „REMOTE DESKTOP SERVICES", kompatibilné s dodaným operačným systémom. Je nutné, aby licencia nebola viazaná na použitie iba na tomto konkrétnom fyzickom serveri (teda, nemá sa jednať o licenciu tzv. OEM, a to z dôvodu umožnenia migrácie virtuálnych serverov na iný fyzický server). Požaduje sa dodanie nových licencií, nie tzv. recyklovaných. Počet kusov: 20
4. Inštalačné a konfiguračné práce 9.1 Analýza prostredia 9.2 Inštalácia ESXi Host - (Upgr. Firmware, konfigurácia RAID, nastavenie BIOS, Management) 9.3 Konfigurácia UPS 9.4 Inštalácia Vma1 9.5 Konfigurácia NAS 9.6 Konfigurácia Switchov 4x 9.7 Fyzické osadenie do rack 9.8 RACK: 1x SV,2x Switche, UPS + EBM, / osadenie, zakáblovanie, otestovanie 9.9 Príprava prostredia na migráciu 9.10 Príprava prostredia na migráciu z FZ P2V 9.11 Príprava prostredia na migráciu z Vmware 9.12 Backup Server Veeam 9.13 Analýza nastavenia Backupov, periodicita, retenčné politiky 9.14 Inštalácia a konfigurácia VEEAM Backup 9.15 1x inštalácia Veeam Proxy na produkčnom SW 9.16 Nastavenie BCK jobov 9.17 Inštalácia a konfigurácia Veeam ONE 9.18 Dokumentácia, Zaškolenie obsluhy
5. Migrácia existujúcich serverov do nového prostredia + upgrade obslužného softvéru 10.1 Migrácia 7 existujúcich serverov na nový server. Migráciu je potrebné vykonať mimo pracovnej doby, t.j. v Pondelok - Piatok v čase od 18.00 - 7.00 hod, alebo počas dní pracovného pokoja - Sobota, Nedeľa. 10.2 Produkčný softvér musí spĺňať nariadenia európskej smernice na ochranu osobných údajov (GDPR) 10.3 Autentifikácia užívateľov (obsluhy) a priradenie roly (oprávnenia) musí byť cez adresárovú službu obstarávateľa (Active Directory)“.
6. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 9: WiFi vo vozidle (Položka č. 28 – 29 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy)“ súťažných podkladov sa uvádza, cit.: ,,Dodávka a montáž 198 ks WIFI do autobusov prímestskej doprav
7. Všeobecné požiadavky na WiFi do vozidiel PAD a MHD 22 1.1 zariadenia pre pripojenie do internetu cez WiFi vo vozidlách PAD a MHD, zvyčajne označované ako „WiFi vo vozidle" 1.2 verejný obstarávateľ požaduje zariadenia dodať vrátane držiakov, kabeláže, montáže, pripojenia na palubný počítač vozidla vrátane príslušného programového vybavenia
8. požadované funkčné charakteristiky a technické (výkonnostné) parametre: 2.1 priemyselné prevedenie vhodné do vozidiel (prašnosť, otrasy, teplotné podmienky) 2.2 prístupový bod pracujúci v normách 802.11 b, g, n, 2.3 LTE 4G/3G modem 2.4 samostatná/oddelená sieť od ostatných informačných systémov vozidla 2.5 počet súčasne pripojených užívateľov - min 60 2.6 vzdialená správa prístupových bodov 2.7 filtrovanie obsahu (možnosť blokovania stránok/domén) 2.8 reporting/štatistika - počet užívateľov, čas pripojenia, objem prenesených dát, typy pripojených zariadení. 2.9 sieťový manažment pre WiFi AP
9. požadované parametre pre HW zariadenia do vozidla 3.
10. napájanie z palubnej siete vozidla 24 V 3.
11. pracovné napätie 10 ... 36 V 3.
12. rozsah pracovných teplôt - 30 0C ...+70 0C 3.
13. relatívna vlhkosť vzduchu 5 % ... 85% bez kondenzácie 3.
14. stupeň ochrany IP 20“.
15. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 10: Inštalácia predmetu zákazky náklady za inštaláciu predmetu zákazky musia byť zahrnuté v cenách položiek 1 - 29 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy.“ súťažných podkladov sa uvádza, cit.: ,,Inštalácia predmetu zákazky (obstarávaných systémov) do autobusov prímestskej a mestskej dopravy
16. všeobecné požiadavky na inštaláciu predmetu zákazky do vozidiel PAD a MHD 1.1 verejný obstarávateľ’ požaduje zariadenia dodať vrátane montáže obstarávaných zariadení do vozidiel PAD a MHD 1.2 verejný obstarávate!’ požaduje, aby osoby vykonávajúce inštaláciu spĺňali požiadavky na odbornú spôsobilosť pracovníkov v elektrotechnike v zmysle platných právnych predpisov 1.3 dodávka a inštalácia musí zahŕňať 1.3.1 dodávku súvisiaceho montážneho a inštalačného materiálu a káblových rozvodov 1.3.2 montáž a inštalácia systému 1.3.3 odskúšanie funkčnosti a prevádzkyschopnosti systému - Integráciu a interaktivitu dodaného tovaru s existujúcim vybavovacím systémom. (Tarifný systém, CL, dopravné karty, hotovostne a bezhotovostné platby a pod.), t.j. príprava podkladov pre palubný počítač a spracovanie dát zo strojčeka vo využívajúcom dopravnom IS - Integráciu a interaktivitu dodaného tovaru s existujúcim rozúčtovaním centrom a akceptáciou kariet jeho členov 23 - Interaktivitu dodaného tovaru s existujúcim riadiacim dispečerským systémom Interaktivitu dodaného tovaru s ďalším existujúcim hardvérovým a softvérovým vybavením verejného obstarávateľa, ako odchodové a príchodové tabule, vozidlové tabule, revízorské čítačky a informačnými systémami pre cestujúcich - Interaktivitu dodaného tovaru s existujúcim riešením importu a exportu ekonomických systémov 1.3.4 realizácia skúšobnej prevádzky – testovanie“.
17. V časti C ,,Opis predmetu zákazky“ bod ,,Logický celok 11: Školenie Náklady za školenie musia byť zahrnuté v cenách položiek 1 - 29 Prílohy č. 2 Súťažných podkladov/Príloha č. 1 Zmluvy“ súťažných podkladov sa uvádza, cit: ,,Školenie k predmetu zákazky (obstarávaným systémom) do autobusov prímestskej a mestskej dopravy
18. všeobecné požiadavky na školenie k predmetu zákazky (obstarávaných systémov) do vozidiel PAD a MHD 1.1 verejný obstarávateľ’ požaduje minimálne 2 základné školenia zamestnancov verejného obstarávateľa na úrovni bežnej prevádzky PP, obslužný SW, SW pre BO, základná profylaktika 1.2 verejný obstarávateľ’ požaduje minimálne 1 školenie na úrovni administrátora pre PP, SW pre BO, základný servis 1.3 verejný obstarávateľ’ požaduje školenia vykonať v sídle verejného obstarávateľa 1.4 vyškolené osoby dostanú certifikát s popisom činností, ktoré môžu vykonávať 1.5 verejný obstarávateľ’ požaduje pre účely školenia počas doby školenia vybavenie pre 1 ks školiace pracovisko, ktoré obsahuje PP s pripojením na napájanie 220 V a pripojenými periférnymi zariadeniami. 2.1 Služby Súčasťou predmetu zákazky musia byť nasledovné služby: 2.1.1 doprava predmetu zákazky na miesta plnenia uvedené v bode A-6.
19. 2.1.2 zabezpečiť inštaláciu/montáž predmetu zákazky v mieste dodania, 2.1.3 zabezpečiť uvedenie predmetu zákazky do prevádzky - oživenie technológie v mieste dodania, 2.1.4 zrealizovať skúšobnú prevádzku - testovanie prevádzky za účasti Kupujúceho, 2.1.5 vykonať zaškolenie písomne vopred vybraných zamestnancov Kupujúceho, 2.1.6 odovzdať Kupujúcemu technickú a sprievodnú dokumentáciu k predmetu zákazky v slovenskom, príp. českom jazyku (technický opis zariadenia, certifikáty, atesty, vyhlásenia o zhode, návod na obsluhu a údržbu, záručné podmienky, preberací protokol, protokol o zaškolení personálu). 2.2 Ekvivalent 2.2.1 Verejný obstarávateľ’ umožňuje predloženie ekvivalentu za nasledovných podmienok: - predložený ekvivalent bude obsahovať kvalitatívne výhodnejšie parametre ako sú požiadavky verejného obstarávateľa na predmet zákazky, alebo 24 - predložený ekvivalent bude zabezpečovať výhodnejšie funkcionality a funkčnosť predmetu zákazky ako sú požiadavky verejného obstarávateľa na funkčnosť predmetu zákazky/zmluvy. 2.2.2 Pre predložený ekvivalent následne platí: - nesmie vyžadovať iné vedľajšie náklady, ktoré by musel zabezpečiť verejný obstarávateľ v rámci súčinnosti viažucej sa k plneniu predmetu zmluvy, ktorá bola výsledkom verejného obstarávania ako prijatie ekvivalentu, a - prijatím predloženého ekvivalentu nesmie dôjsť k zvýšeným priamym alebo nepriamym nákladom vyplývajúcim z užívania dodaného predmetu zmluvy. 2.2.3 Ak súťažné podklady alebo iné dokumenty poskytnuté záujemcom v procese verejného obstarávania obsahujú odkaz na konkrétneho výrobcu, výrobný postup, obchodné označenie, patent, typ, oblasť alebo miesto pôvodu alebo výroby, verejný obstarávate!’ takýto odkaz dopĺňa slovami „alebo ekvivalentný". 2.2.4 Verejný obstarávateľ’ nevylúči ponuku uchádzača v súvislosti s predložením ekvivalentu vo väzbe na § 42 ods. 3 ZVO, ak predložený ekvivalent bude spĺňať podmienky

bodu 2.2.1 a 2.2.

2. Množstvo predmetu zákazky Množstvá jednotlivých položiek sú uvedené v Prílohe č. 2 súťažných podkladov.
3. Hodnotenie splnenia požiadaviek na vlastnosti 4.1 Príslušnými dokladmi

bodov A.17.3 a A.17.4 podkladov a technickou prezentáciou predmetu zákazky

bodu 4.3.4 tejto kapitoly musí uchádzač preukázať, že ponúkaný predmet zákazky spĺňa požiadavky na predmet zákazky uvedené v kapitole C. Opis predmetu zákazky. 4.2 Ponuka musí byť predložená na všetky položky. 4.3 Technická prezentácia predmetu zákazky uskutočnená na základe výzvy verejného obstarávateľa: Uchádzači, ktorí predložili ponuku, a ktorých ponuky budú vyhodnocované z hľadiska splnenia požiadaviek verejného obstarávateľa na predmet zákazky, budú verejným obstarávateľom vyzvaní na praktickú technickú prezentáciu ponúkaného predmetu zákazky - uchádzačom ponúkaného tarifno- informačného systému, za účelom preukázania splnenia požiadaviek na predmet zákazky. Technická prezentácia bude vykonaná za prítomnosti uchádzača, ktorého ponuka bude vyhodnocovaná. Každý uchádzač, ktorého ponuka bude vyhodnocovaná sa musí zúčastniť technickej prezentácie vlastného systému. Uchádzač alebo poverený zástupca uchádzača, ktorý sa zúčastní technickej prezentácie, predloží pre tento účel vlastný ponúkaný tarifno-informačný systém, ktorý je predmetom zákazky. Nesplnenie povinností uchádzača vo vzťahu na prezentáciu systému predmetu zákazky bude považované za nepreukázanie splnenia požiadaviek na predmet zákazky. Súčasťou technickej prezentácie bude ukážka funkčnosti tabúľ’ LCD a LED ako aj spolupráca s palubným počítačom. 25 Výzva na technickú prezentáciu bude uchádzačom odoslaná minimálne 5 pracovných dní pred termínom jej konania. Všetky náklady uchádzača spojené s technickou prezentáciou znáša uchádzač. Ak sa pri technickej prezentácii preukázateľne nepotvrdí funkčnosť tarifno-informačného systému ponúkaného uchádzačom, alebo splnenie požiadaviek uvedených v bode 4.3.4 má sa za to, že ponuka uchádzača nespĺňa požiadavky verejného obstarávateľa na predmet zákazky a bude z verejnej súťaže vylúčená. 4.3.1 Komisia - minimálne zloženie Praktické preukázanie funkčnosti tarifno-informačného systému bude preverené komisiou, pozostávajúcou zo zástupcov verejného obstarávateľa. 4.3.2 Miesto technickej prezentácie Prezentácia sa uskutoční na adrese: ARRIVA Michalovce, a.s., Lastomírska 1, 07801 Michalovce. 4.3.3 Postup pri testovaní: Technická prezentácia bude spočívať v praktickej ukážke požadovaných vlastností systému v podmienkach, ktoré sa blížia podmienkam reálnej prevádzky systému. Uchádzač predvedie funkčnosť tarifno-informačného systému na náhodne vybranej vzorke dát vo vozidle (kvôli hodnoteniu čitateľnosti displeja, funkčnosti GPS, funkčnosti 3G/4G modemu, a pod.), ktoré sa pohybuje po skutočnej trase linky. Výber konkrétnej linky je samostatným rozhodnutím uchádzača, pričom podklady získa na stráne www.arrivami.sk . Ostatné potrebné údaje získava uchádzač vlastnými prostriedkami (napr. GPS súradnice). Platba bankovou kartou sa odprezentuje nad referenčným systémom uchádzača. Vrátane vlastnej SIM karty pre dátový prenos. Komunikáciu s centrálnym systémom uchádzač odprezentuje voči svojmu centrálnemu systému. Nabitie kreditu karty odprezentuje uchádzač na svojom systéme plnenia kariet. Výšku kreditu sa dozvie pri prezentácii. Uchádzač počas prezentácie odprezentuje čítanie 2D kódu na ním vytlačenom QR kóde. Ukážka technickej prezentácie Wifi a kamerového systému môže byť prezentovaná zvlášť. 4.3.4 Hodnotenie spôsobom SPLNIL (A) / NESPLNIL (N) Posudzovať sa bude splnenie nasledovných požiadaviek na predmet zákazky:

1. a)vizuálne hodnotenie PP - spôsob ovládania PP prostredníctvom touchu - uchádzač preukazuje splnenie technickej požiadavky požadovanej verejným obstarávateľom v bode 3.5, Logický celok: Palubný počítač HW, Palubný počítač SW - zobrazenie údajov na displeji PP – čitateľnosť - uchádzač preukazuje splnenie technickej požiadavky požadovanej verejným obstarávateľom v bode 3.5.3, Logický celok: Palubný počítač HW, Palubný počítač SW - možnosť nastavenia ergonomickej polohy palubného počítača - uchytenie a jeho možnosť prestavenia v ľubovoľnom vertikálnom a aj horizontálnom smere a možnosť individuálneho prestavenia zorného a pracovného uhla potrebného na obsluhu - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.4.5, Logický celok: Palubný počítač HW, Palubný počítač SW
2. b)kontrola vybraných technických parametrov PP - veľkosť displeja - minimálne 10 " 26 - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 3.5.1, Logický celok: Palubný počítač HW, Palubný počítač SW - SD karta - min. 512 MB - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 3.6.3, Logický celok: Palubný počítač HW, Palubný počítač SW - napájacie konektory s ľahkou možnosťou odpojenia bez možnosti samovoľného vypadnutia - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 3.17, Logický celok: Palubný počítač HW, Palubný počítač SW - priemyselné ethernetové konektory minimálne push-pull - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 1.2.2, Logický celok: Komunikačná jednotka - predvedenie funkčnosti záložnej batérie - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bode 3.10.4, Logický celok: Palubný počítač HW, Palubný počítač SW
3. c)zakúpenie cestovného lístka, platba v hotovosti - zapnutie zariadenia tlačidlom štart - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.4.6, Logický celok: Palubný počítač HW, Palubný počítač SW - zvuková indikácia začiatku štartovania zariadenia - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.4.6, Logický celok: Palubný počítač HW, Palubný počítač SW - obrazovka na prihlásenie vodiča sa zobrazí do 40 sekúnd od zvukového signálu - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bodoch 2.4.6 a 3.4.3, Logický celok: Palubný počítač HW, Palubný počítač SW - prihlásenie vodiča kartou alebo zadaním kombinácie Login / PIN - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.3.8, Logický celok: Palubný počítač HW, Palubný počítač SW - zadanie linka, spoj, alebo turnus, alebo príkaz - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.3.1, Logický celok: Palubný počítač HW, Palubný počítač SW - vstup do režimu výdaja lístkov - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.3.1, Logický celok: Palubný počítač HW, Palubný počítač SW - výber výstupnej zastávky - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.3.1, Logický celok: Palubný počítač HW, Palubný počítač SW - výber tarify - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.3.1, Logický celok: Palubný počítač HW, Palubný počítač SW - predaj cestovného lístka - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bodoch 1.2., 2.1.2 (platbou v hotovosti 2.1.3) Logický celok: Palubný počítač HW, Palubný počítač SW 27 - tlač 10 kusov lístkov s rýchlosťou tlače do 15s (na lístok do 1.5s) uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.3.4, Logický celok: Tlačiareň cestovných lístkov s čítačkou BČK, čítačkou EMV kariet a čítačkou 2D kódu
4. d)zakúpenie cestovného lístka, platba dopravnou kartou - zobrazenie informácie o karte (kontrola výšky kreditu, kontrola nezaznačenej jazdy) - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bode 2.1.4. a v bode 2.1.6, Logický celok: Palubný počítač HW, Palubný počítač SW - akceptácia karty MF Classic (funkčnosť transakcie) - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bode bode 2.1.4, bode 2.1.6, Logický celok: Palubný počítač HW, Palubný počítač SW a v bode 2.4.2, Logický celok: Tlačiareň cestovných lístkov s čítačkou BČK, čítačkou EMV kariet a čítačkou 2D kódu - akceptácia karty MF DESFire (funkčnosť transakcie) - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bode 2.1.4, bode 2.1.6, Logický celok: Palubný počítač HW, Palubný počítač SW a v bode 2.4.2, Logický celok: Tlačiareň cestovných lístkov s čítačkou BČK, čítačkou EMV kariet a čítačkou 2D kódu - zobrazenie informácie o karte (kontrola zmenenej výšky kreditu, kontrola označenia jazdy) - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bode 2.1.4, bode 2.1.6, bode 2.1.7, Logický celok: Palubný počítač HW, Palubný počítač SW - práca so SAM modulom (funkčnosť) - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bode 2.1.4, bode 2.1.6, Logický celok: Palubný počítač HW, Palubný počítač SW a v bode 2.4.2, Logický celok: Tlačiareň cestovných lístkov s čítačkou BČK, čítačkou EMV kariet a čítačkou 2D kódu
5. e)zakúpenie cestovného lístka, platba bankovou kartou - voľba tarify - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.1.2 Logický celok: Palubný počítač HW, Palubný počítač SW - platba za papierový lístok akceptáciou bankovej karty (funkčnosť transakcie) - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.1.5 Logický celok: Palubný počítač HW, Palubný počítač SW - storno vykonanej transakcie - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 1.2., Logický celok: Palubný počítač HW, Palubný počítač SW - overenie platby bankovou kartou v PP a banke - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.1.5, Logický celok: Palubný počítač HW, Palubný počítač SW
6. f)kontrola snímania 2D kódu - voľba snímania 2D kódu 28 - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.6, Logický celok: Tlačiareň cestovných lístkov s čítačkou BČK, čítačkou EMV kariet a čítačkou 2D kódu - kontrola zosnímania papierového lístka s 2D kódom (funkčnosť transakcie ) - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.6, Logický celok: Tlačiareň cestovných lístkov s čítačkou BČK, čítačkou EMV kariet a čítačkou 2D kódu - zobrazenie obsahu 2D kódu na obrazovku - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 2.6, Logický celok: Tlačiareň cestovných lístkov s čítačkou BČK, čítačkou EMV kariet a čítačkou 2D kódu
7. g)kontrola komunikácie WiFi a 3G/4G - nahrávanie vstupných dát cez WiFi (cestovné poriadky, turnusy, tarify) z centrálneho systému - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bodoch 3.1, 3.2. a v bode 4.1.2. Logický celok: Palubný počítač HW, Palubný počítač SW - vyčítavanie záznamov o predaných lístkoch cez 3G/4G modem do centrálneho systému - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bodoch 3.1, 3.2 a požiadavky v bode 4.1.2. Logický celok: Palubný počítač HW, Palubný počítač SW
8. h)evidencia tržby z predaných cestovných lístkov - evidencia tržby s rozdelením na hotovosť, dopravná karta, banková karta - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bodoch 2.1.10 a 2.5.5 Logický celok: Palubný počítač HW, Palubný počítač SW
9. i)on-line sledovanie a vyhodnocovanie polohy vozidla - posielanie polohy vozidla do centrálneho systému - uchádzač preukazuje splnenie požiadavky požadovanej verejným obstarávateľom v bode 1.1 oddiel I. Prenos informácií medzi vozidlom a centrálnym riadiacim systémom a požiadaviek v bodoch 1.5, 2.1.11, 2.1.12, 4.2. Logický celok: Palubný počítač HW, Palubný počítač SW - zobrazenie meškania/nadbiehania na centrálnom systéme - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bodoch 2.1.12, 3.1., 4.2. Logický celok: Palubný počítač HW, Palubný počítač SW
10. j)navigačný systém pre vodiča - zobrazenie mapového podkladu vodičovi - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bodoch 2.1.15, 2.2.14 a bode 2.3.2, Logický celok: Palubný počítač HW, Palubný počítač SW - zobrazenie polohy vozidla na mapovom podklade - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bodoch 2.1.15, 2.2.14 a bode 2.3.2, Logický celok: Palubný počítač HW, Palubný počítač SW - overenie zobrazovania zastávok aktuálneho spoja na mapovom podklade 29 - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bodoch 2.1.15, 2.2.14 a bode 2.3.2, Logický celok: Palubný počítač HW, Palubný počítač SW
11. k)funkčnosť informačných tabúľ - ukážka súčinnosti všetkých informačných tabúľ spolu s palubným počítačom - uchádzač preukazuje splnenie požiadaviek požadovaných verejným obstarávateľom v bode 2.1.13. Logický celok: Palubný počítač HW, Palubný počítač SW a v bode 3.4. Logický celok: Vozidlový informačný systém 4.3.5 Z technickej prezentácie, jej priebehu a výsledku bude zhotovený zápis a videozáznam, ktorý bude súčasťou dokumentácie verejného obstarávania. Prezentované systémy jednotlivých uchádzačov, predložené na účely technickej prezentácie predmetu zákazky 4.4 Členovia komisie budú posudzovať splnenie požiadaviek na predmet zákazky spôsobom určenia, a to SPLNIL (A) / NESPLNIL (N). 4.5 Tí uchádzači, ktorí boli pri posudzovaní splnenia požiadaviek na predmet zákazky hodnotení aspoň raz vyjadrením NESPLNIL (N), nesplnili požiadavky verejného obstarávateľa na predmet zákazky. 4.6 Ponuka, ktorá nespĺňa požiadavky na predmet zákazky uvedené v oznámení o vyhlásení verejného obstarávania a v súťažných podkladoch alebo náležitosti ponuky, bude vylúčená z postupu verejného obstarávania. 35. Úrad uvádza, že navrhovateľ dňa 01. 10. 2019 doručil kontrolovanému žiadosť o nápravu. Kontrolovaný dňa 07. 10. 2019 žiadosť o nápravu čiastočne vybavil a zároveň žiadosť o nápravu čiastočne zamietol. Úrad poukazuje na nižšie uvedenú otázku navrhovateľa obsiahnutú v žiadosti o nápravu zo dňa 01. 10. 2019 a odpoveď kontrolovaného na uvedenú otázku v rámci zamietnutia žiadosti o nápravu zo dňa 07. 10. 2019, v kontexte predchádzajúcej otázky v žiadosti o vysvetlenie súťažných podkladov a následnej odpovede, kde sa uvádza nasledovné, cit.: ,,Otázka č. 18: článku 2. Funkčné požadavky na palubný počítač bod 2.2.2. Zadavatel uvádí požadavek na palubní počítač „zarízení disponuje plnohodnotným, volne širitelným, upravovatelným vzdáleně aktualizovatelným operačním systémem. Tento požadavek vnímáme jako diskriminační. V našich odbavovacích zařízeních používáme operační systém Windows (Microsoft), který je plnohodnotný, vzdáleně aktualizovatelný a upravovatelný. Není však volne širitelný. Může uchazeč použít operační systém Windows? Odpoveď verejného obstarávateľa k otázke č. 18: Verejný obstarávateľ’ trvá na požiadavke voľne šíriteľného operačného systému s na základe licenčných podmienok voľne dostupnými zdrojovými kódmi. Verejný obstarávateľ trvá na požiadavke, aby mohol v budúcnosti nakladať, aktualizovať a upravovať operačný systém a z dôvodu zamedzenia viazanosti na 1 dodávateľa. Kým v prípade počtu akceptovaných bánk verejný obstarávateľ uvádza, že neobmedzuje čestnú hospodársku súťaž v uvedenom prípade tomu tak nie je. V tejto súvislosti uvádzame, že nie je rozhodujúci typ operačného systému, ale dôležitý je typ aplikácie a jej zdrojové kódy. Zároveň uvádzame, že operačný systém Windows je najpoužívanejší OS nielen vo svete ale aj Slovensku 30 a teda uvedená argumentácia verejného obstarávateľa je úplne nelogická a celkom zjavne slúži len k tomu, aby bolo umožnené predloženie technického riešenia už existujúceho dodávateľa a nie akékoľvek iné. K otázke č. 18: Žiadame, aby verejný obstarávateľ umožnil aj použitie operačného systému Windows. Odpoveď verejného obstarávateľa k otázke č. 18: Verejný obstarávateľ trvá na svojej odpovedi. K argumentu, že „operačný systém Windows je najpoužívanejší nielen vo svete ale aj na Slovensku" uvádza, že ho považuje za ničím nepodložené tvrdenie, Verejný obstarávateľ trvá na tom, že požiadavka voľne šíriteľného OS nie je diskriminačná, keďže sú tieto systémy k dispozícii na stiahnutie bezplatne akémukoľvek uchádzačovi. Verejný obstarávateľ’ dôrazne odmieta tvrdenia uchádzača, že sa požiadavkou snaží preferovať akéhokoľvek dodávateľa“. Úrad uvádza, že text explicitne obsiahnutý v zamietnutí žiadosti o nápravu a zároveň text naň nadväzujúci je uvedený v námietkach v bode 11 tohto rozhodnutia. 36. Úrad uvádza, že navrhovateľ dňa 01. 10. 2019 doručil kontrolovanému žiadosť o nápravu. Kontrolovaný dňa 07. 10. 2019 žiadosť o nápravu čiastočne vybavil a zároveň žiadosť o nápravu čiastočne zamietol. Úrad uvádza, že text obsiahnutý v zamietnutí žiadosti o nápravu a zároveň text nachádzajúci sa v námietkach navrhovateľa (bod 8 rozhodnutia) je nasledovný, cit.: ,,Odôvodnenie neposkytnutia/nezverejnenia interface ako súčasť zadávacej dokumentácie verejného obstarávania v rámci jednotlivých požiadaviek, viď otázky nižšie: Verejný obstarávateľ vo svojich tarifno – informačných systémoch používa SW a HW komponenty/moduly/prvky/systémy od viacerých dodávateľov YY, YY, YY obstarané v rôznych časových obdobiach a za rôznych obchodných podmienok. Prepojenia medzi jednotlivými modulmi sú založené na proprietárnych protokoloch, tak ako to v čase obstarávania týchto systémov bolo obvyklé (a čiastočne je používané aj v súčasnosti) v obdobných systémoch v EÚ. Používané komunikačná protokoly predstavujú obchodné tajomstvo jednotlivých dodávateľov a ich zverejňovanie je limitované príslušnými právnymi predpismi (Obchodný zákonník, Autorský zákon, Zmluvy). Verejný obstarávate' aj na základe postupov iných obdobných verejných obstarávaní uzavrel s jednotlivými dodávateľmi dohodu o poskytnutí potrebnej dokumentácie výlučne víťaznému uchádzačovi na základe podpísanej zmluvy (NDA) o ochrane poskytnutých informácií. Tento postup je tiež v súlade s Rozhodnutím ÚVO č. 143566000/2018-OD zo dňa 23.04.2019 https://www.uvo.gov.sk/prehlad-rozhodnuti-onamietkach/document/5501, ktoré takýto postup akceptuje cit. bod 36. Rozhodnutia ... Na stanovenie ponuky nie je potrebné poznať tento protokol. Zložitosť komunikačného protokolu môže mať vplyv na cenu realizácie, ale tá sa dá odhadnúť z požadovaných operácií.“ 37. V dokumente ,,Žiadosť o nápravu“ doručenej kontrolovanému zo strany navrhovateľa dňa 17. 10. 2019 sa uvádza cit.: ,,(...) Verejný obstarávateľ v rámci opisu predmetu zákazky a vysvetlení súťažných podkladov uviedol, že používa čipové karty Mifare Classic, Mifare DESFire EV1 a Mifare DESFire EV2. Podrobnosti o parametroch čipových kariet však verejný obstarávateľ 31 neuviedol. Úrad pre verejné obstarávanie v bode 10 rozhodnutia č. 14356-6000/2018-OD zo dňa 23.04.2019 uvádza, že v prípade ak sa využívajú čipové karty rámci zákazky zabezpečenia tarifno-informačné zabezpečenie integrovaného dopravného systému , má verejný obstarávateľ povinnosť definovať jednotlivé parametre používaných čipových kariet. Návrh žiadateľa na vybavenie žiadosti o nápravu. V kontexte uvedeného týmto žiadame, aby verejný obstarávateľ stanovil podrobnejšie parametre používaných čipových kariet Mifare Classic, Mifare DESFire EV1 a Mifare DESFire EV2“. 38. Kontrolovaný v reakcii na ,,Žiadosť o nápravu“ doručenú dňa 17. 10. 2019, kontrolovaný doručil navrhovateľovi dňa 23. 10. 2019 dokument označený ,,Vec: Doplňujúca informácia č. 10 Vysvetlenie súťažných podkladov“, kde sa uvádza nasledovné, cit.: ,,Dňa 17.10.2019 bola verejnému obstarávateľovi prostredníctvom komunikačného systému ELENA doručená žiadosť o nápravu v rámci vyššie uvedeného verejného obstarávania. Verejný obstarávateľ má za to, že charakter otázok zo strany žiadateľa vykazoval znaky žiadosti o vysvetlenie stanovísk verejného obstarávateľa na doručené žiadosti o vysvetlenie súťažných podkladov resp. dokumentov verejného obstarávania a teda svojimi odpoveďami na tieto doplňujúce otázky, verejný obstarávateľ upresnil už zverejnené odpovede. Na základe uvedeného, otázky uvedené v žiadosti o nápravu a odpovede k nim, ktoré majú charakter doplnenia už poskytnutých stanovísk k žiadostiam o vysvetlenie súťažných podkladov resp. dokumentov zákazky, verejný obstarávateľ zverejní všetkým známym záujemcom v komunikačnom systéme ELENA ako aj v profile verejného obstarávateľa ako Doplňujúcu informáciu č. 10: Vysvetlenie súťažných podkladov. Opis rozhodujúcich skutočností a označenie dôkazov (citácia): „Verejný obstarávateľ v rámci opisu predmetu zákazky a vysvetlení súťažných podkladov uviedol, že používa čipové karty Mifare Classic, Mifare DESFire a Mifare DEsFire EV2. Podrobnosti o parametroch čipových kariet však verejný obstarávateľ neuviedol. Úrad pre verejné obstarávanie v bode 10 rozhodnutia č. 14356-6000/2018-OD zo dňa 23.04.2019 uvádza, že v prípade ak sa využívajú čipové karty v rámci zákazky zabezpečenia tarifno - informačného zabezpečenia integrovaného dopravného systému, má verejný obstarávateľ povinnosť definovať jednotlivé parametre používaných čipových kariet. V kontexte uvedeného týmto žiadame, aby verejný obstarávateľ stanovil podrobnejšie parametre používaných čipových kariet Mifare Classic, Mifare DESFire a Mifare DESFire EV2. Stanovisko verejného obstarávateľa: výsledok vybavenia žiadosti o nápravu: Bezkontaktná čipová karta (BČK) sa používa ako personalizovaný nosič elektronickej peňaženky (EP), jednorazového cestovného lístka (JCL) a predplatného cestovného lístka (PCL). Z EP je možné zakúpiť JCL pre majiteľa karty ako aj pre spolucestujúcich, PCL je možné zakúpiť len pre majiteľa karty. V prípade straty je možné kartu zablokovať. Po zablokovaní je možné údaje preniesť na novú kartu (duplikát). Na základe zmluvy o akceptácii je možné kartu použiť aj u iných dopravcov. Technické parametre používaných čipových kariet sú definované v dokumentoch výrobcu týchto kariet, spoločnosti NXP Semiconductors (https://www.nxp.com/) Mifare Classic https://www.nxp.com/docs/en/data-sheet/MF1S70YYX V1.pdf 32 Mifare DESFire EV1 https://www.nxp.com/docs/en/data-sheet/MF3ICDX21 41 81 SDS.pdf Mifare DESFire EV2 https://www.nxp.com/docs/en/data-sheet/MF3DX2 MF3DHX2 SDS.pdf Na základe uvedených špecifikácií sú na karte vytvorené dátové objekty, ktoré umožňujú na kartu zapisovať a z karty čítať údaje potrebné na použitie karty ako nosič JCL, PCL a EP. Dátové objekty obsahujú nasledovné dáta: Dáta držiteľa karty - meno a priezvisko držiteľa BČK - dátum narodenia držiteľa BČK - kód zákazníka - dátum platnosti kódu zákazníka Dáta pre PCL - kód dopravnej siete - kód dopravcu – identifikátor predajcu PCL - začiatok platnosti PCL - dátum a čas - koniec platnosti PCL - dátum a čas - kód zákazníka - dospelý, žiak, študent, dôchodca - kód tarify - 30 dňový, 90 dňový, 365 dňový - obmedzenie platnosti na dni v týždni - bez obmedzenia, pracovné dni - obmedzenie platnosti na linky - bez obmedzenia, nočné spoje - cena PCL - elektronický podpis dát Dáta pre JCL - kód dopravnej siete - kód dopravcu – identifikátor predajcu JCL - kód linky - identifikátor linky - kód spoja - identifikátor spoja - začiatok platnosti JCL - dátum a čas - čas platnosti - kód nástupnej zastávky - kód výstupnej zastávky - kód zákazníka - dospelý, žiak, študent, dôchodca - kód tarify - cena JCL - elektronický podpis dát Dáta pre EP - aktuálny zostatok Prístup k dátam na karte je založený na prístupových šifrovacích kľúčoch a otvorených šifrovacích algoritmoch (karty Mifare DESFire) v zmysle špecifikácie výrobcu karty. Šifrovacie kľúče sú uložené v bezpečnostnom module (Secure Access Module,SAM), ktorý vykonáva potrebné šifrovacie operácie (autentifikácia, podpisovanie, šifrovanie, dešifrovanie). SAM modul komunikuje s kartou protokolom popísaným v dokumentoch výrobcu karty, v súlade s normou ISO 7816“. 39. Úrad rozhodnutím č. 14434-6000/2019-OD-S zo dňa 08. 01. 2020 prerušil v súlade s § 173 ods. 8 zákona o verejnom obstarávaní konanie o preskúmanie úkonov kontrolovaného na základe námietok za účelom získania odborného stanoviska. Úrad žiadosťou o poskytnutie 33 odborného stanoviska v predmetnej veci so zreteľom na odborný a technický charakter namietaných skutočností požiadal o odborné stanovisko X X. 40. Úrad v liste ,,Žiadosť o odborné stanovisko“ č. 14434-6000/2019-OD-OS zo dňa 17. 01. 2020 požiadal X X o zodpovedanie nasledujúcich otázok v podobe písomného odborného stanoviska, cit.: ,,Predmet danej zákazky pre obstarávané služby je bližšie špecifikovaný v časti C „Opis predmetu zákazky“ súťažných podkladov. Pre správne posúdenie skutočností relevantných pre konanie je potrebné zodpovedať odborné otázky v oblasti dopravných informačných systémov. Z uvedeného dôvodu si Vás dovoľujeme požiadať o poskytnutie odborného stanoviska k nasledovným otázkam: 1. Je opis predmetu zákazky úplný a dostatočne jednoznačný na predloženie relevantných porovnateľných ponúk, resp. je technická špecifikácia dostatočná na vypracovanie relevantnej cenovej ponuky? 2.
12. a)Ako by ste v kontexte súťažných podkladov, berúc do úvahy žiadosť o nápravu zo dňa 01. 10. 2019, výsledok vybavenia žiadosti o nápravu/zamietnutie zo dňa 07. 10. 2019, žiadosť o nápravu zo dňa 17. 10. 2019, vysvetlenie súťažných podkladov zo dňa 23. 10. 2019 a námietky navrhovateľa charakterizovali pojem „interface“?
13. b)Je postup kontrolovaného, kedy ako súčasť súťažných podkladov nebol poskytnutý interface, dostatočný na účely vypracovania a predloženia relevantnej cenovej ponuky? 3. Je technická špecifikácia používania čipových kariet Mifare Classic, Mifare DESFire a Mifare DESFire EV2 v kontexte súťažných podkladov, berúc do úvahy žiadosť o nápravu zo dňa 01. 10. 2019, výsledok vybavenia žiadosti o nápravu/zamietnutie zo dňa 07. 10. 2019, žiadosť o nápravu zo dňa 17. 10. 2019, vysvetlenie súťažných podkladov zo dňa 23. 10. 2019 a námietky navrhovateľa, dostatočne jednoznačná na vypracovanie relevantnej cenovej ponuky? 4. Spĺňa operačný systém Windows požiadavku v zmysle bodu 2.2.2 súťažných podkladov (str. 23), a je teda plnohodnotným voľne šíriteľným, upravovateľným vzdialene aktualizovaným operačným systémom? Zároveň si Vás dovoľujeme požiadať o odôvodnenie Vašich odpovedí a o prípadné postrehy vo väzbe k uvedeným otázkam“. 41. Dňa 21. 01. 2020 doručil X X úradu prostredníctvom elektronickej komunikácie e-mail s nasledovným znením, cit.: ,,Ďakujem za žiadosť a dokumenty. Musím Vás však, v dôsledku iných povinností, požiadať, o predĺženie lehoty na vypracovanie odborného stanoviska“. 34 42. Úrad v nadväznosti na žiadosť X X informoval kontrolovaného dokumentom č. 144346000/2019-OD-L1 zo dňa 27. 01. 2020 a navrhovateľa dokumentom č. 14434-6000/2019-ODL2 zo dňa 27. 01. 2020 o predĺžení lehoty na doručenie odborného stanoviska

§ 173ods.

8 zákona o verejnom obstarávaní a informoval kontrolovaného i navrhovateľa, že v zmysle § 173 ods. 8 zákona o verejnom obstarávaní predlžuje lehotu na doručenie odborného stanoviska úradu o ďalších 30 dní. t. j . najneskôr v zmysle § 21 ods. 1 zákona o verejnom obstarávaní do 09. 03. 2020 a skonštatoval, že od vydania rozhodnutia o prerušení konania č. 144346000/2019-OD-S zo dňa 08. 01. 2020 do doručenia odborného stanoviska úradu lehota

§ 175ods.

5 neplynie. 43. Úrad dňa 27. 01. 2020 dokumentom č. 14434-6000/2019-OD-L3 doručil X X ,,Odpoveď na žiadosť o predĺženie termínu na doručenie odborného stanoviska zo dňa 21. 01. 2020“, kde okrem iného uviedol nasledovné, cit.: ,,V kontexte Vašej žiadosti o predĺženie termínu, resp. lehoty na doručenie odborného stanoviska úradu, Vám týmto oznamujeme, že žiadosti sa vyhovuje“. 44. Dňa 06. 03. 2020 bolo úradu listinne doručené odborné stanovisko vo veci žiadosti o odborné stanovisko vypracované X X v ktorom odborník uviedol nasledovné, cit.: ,,Otázka 1 Predmet zákazky pozostáva zo siedmich častí:  Logický celok 1: Palubný počítač HW, Palubný počítač SW pre PAD a MHD (199

1. ks) Logický celok 2: Tlačiareň cestovných lístkov s čítačkou BOK, čítačkou EMV kariet a čítačkou 2D kódu (199
2. ks) Logický celok 3: Komunikačná jednotka (199
3. ks) Logický celok 4: Podstava (199
4. ks) Logický celok 5: Personalizačné pracovisko (zákaznícke pracovisko) (6
5. ks) Logický celok 6: Vozidlový informačný systém  Logický celok 7: Vozidlový kamerový systém (173
6. ks) Logický celok 8: Dodávka a inštalácia servera (HW a SW)  Logický celok 9: WiFi vo vozidle (198
7. ks) Logický celok 10: Inštalácia predmetu zákazky  Logický celok 11: Školenie Logický celok 1 sa týka palubného počítača, pričom pod palubným počítačom sa tu nerozumie iba počítač s generickým softvérovým vybavením, ktorý by sa dal dodať ako hotový produkt, t. j. bez ďalšieho vývoja, ale aj komplexný softvérový systém na predaj cestovných lístkov a sledovanie trasy vozidla. Zásadný problém opisu tejto časti predmetnej zákazky je, že kontrolovaný softvérové vybavenie palubného počítača pokladá za priamo komerčne dostupný softvérový systém, ktorý je priamo použiteľný bez ďalšieho vývoja alebo len s malými zásahmi, a nie za špecializovaný softvér na objednávku, ktorého dodaniu musí predchádzať vývojový proces na základe špecifických požiadaviek kontrolovaného. Kontrolovaný nikde v opise 35 predmetu zákazky neuvádza, že objednáva vývoj softvéru. Tento pojem nefiguruje ani v údajovom slovníku zákazky. Vývoj softvéru je potrebný v dvoch líniách: na zabezpečenie funkcií, ktoré kontrolovaný špecifikoval v prílohe č. 6 súťažných podkladov, a na zabezpečenie prepojenia s jestvujúcim softvérovým vybavením. Špecifikácia funkcií je pomerne rozsiahla a detailná, ale mnohé jej položky nie sú úplne jasné, resp. ich splnenie vyžaduje spresnenie a ďalšie údaje. Napríklad, položka „2.1.9 akceptácia cestovných lístkov predávaných cez internet” nedefinuje, formu cestovných lístkov predávaných cez internet, čím zostáva nejasné, ako ich palubný počítač má rozpoznať a akceptovať. Položky „2.1.13 spracovanie a posielanie dát pre informačné tabule” a „2.1.14 spracovanie a posielanie dát pre zvukové hlásiče” nedefinujú z čoho pozostávajú údaje pre informačné tabule, resp. zvukové hlásiče. Položka „2.2.3 zariadenie umožňuje poskytovať prestup, pričom cena prestupného lístka je daná doplatkom na základe súčtu tarifných kilometrov obidvoch odjazdených úsekov” nedefinuje presne, ako má byť implementovaný výpočet ceny, resp. ako sa prepočítajú kilometre na peniaze. Tarifné systémy spomenuté v položke „2.2.6 pomocou backofficu je možné prepínať medzi podporou zónového, kilometrického, pásmového, časového tarifného systému” nie sú nikde definované. Položka „2.2.7 zariadenie umožňuje prechod medzi viacerými typmi tarifných systémov v rámci jedného spoja” nedefinuje, čo znamená prechod medzi viacerými typmi tarifných systémov v rámci jedného spoja, ani ako sa má uskutočniť. Položka „2.2.8 zariadenie podporuje použitie odchýlkovej ceny medzi dvomi definovanými zastávkami spoja” nedefinuje, čo je odchýlková cena, ani ako čo znamená jej použitie. Toto by bolo prijateľné, ak by daná špecifikácia bola pokladaná za hrubú alebo rámcovú špecifikáciu požiadaviek, a ak by sa predpokladala jej konkretizácia v rámci vývoja softvéru. Toto však zo súťažných podkladov nevyplýva. Z hľadiska prepojenia s jestvujúcim softvérovým vybavením kontrolovaného, dôležité je povedať, že prepojenie vlastne znamená vývoj špecializovanej časti softvérového systému palubného počítača, ktorý toto prepojenie zabezpečí. Prepojenie nie je potrebné len na centrálny riadiaci systém, ako kontrolovaný uvádza, ale aj na zvukové hlásiče, ako vyplýva z položky „2.1.14 spracovanie a posielanie dát pre zvukové hlásiče”. Pritom nie je jasné, ani aké údaje majú byť posielané, ani v akom formáte, a ani cez aké rozhranie. Podobne je to s položkou „2.2.9 zariadenie umožňuje konfigurovateľný mechanizmus hlásenia zastávok do vozidla”, ktorá sa možno týka hlásičov, resp. softvérového systému, ktorý ich ovláda, alebo nejakého ďalšieho systému. Takisto položka 2.2.15 vstupné a výstupné dáta z PP zabezpečia:
8. a)zber a záznam dát technologických procesov vozidla
9. b)dátový prenos prostredníctvom WiFi a GSM siete • vo vozovni dopravcu medzi vozidlom a výpravňou (rozpoznanie vozidla a aktualizáciu dát informačného a vybavovacieho systému počas doby vozidla vo výpravni bez zásahu človeka) vyžaduje získavanie údajov technologických procesov vozidla, pričom nie je jasné, z akého systému sa tieto údaje majú získať. Tiež nie je jasné, či je „výpravňa” to isté, ako centrálny riadiaci systém. Rozhranie medzi systémom palubného počítača nemá byť iba údajové, ale aj riadiace, čo vyplýva z položky 2.2.13: 2.2.13 PP musí spolupracovať s dispečingom a sledovať: 36
10. a)zapínanie
11. b)vypínanie
12. c)stavové správy v aktuálnom rozsahu
13. d)ovládanie hlasovej komunikácie
14. e)generovanie vopred definovaných textových správ Na realizáciu tohto všetkého je potrebná minimálne podrobná špecifikácia rozhraní jestvujúcich systémov kontrolovaného a formátov údajov, ktoré tieto systémy používajú pri komunikácií s externými systémami, k čomu sa kontrolovaný v súťažných podkladoch vôbec nevyjadruje. Až v reakcií na žiadosť o nápravu zo dňa 7. 10. 2019 kontrolovaný uvádza, že s dodávateľmi týchto systémov uzavrel dohodu o poskytnutí potrebnej dokumentácie výlučne víťaznému uchádzačovi na základe podpísanej zmluvy (NDA) o ochrane poskytnutých informácií. Keďže presnosť a úplnosť dokumentácie voči tomu, čo je skutočne implementované v softvérovom systéme, nikdy nie je zaručená, otázne je, či toto víťaznému uchádzačovi bude postačovať, resp. či nebude potrebná súčinnosť dodávateľov jestvujúcich systémov kontrolovaného. Ku kvalifikovanému odhadu zložitosti softvéru, ktorý má byť vytvorený, a tým aj k stanoveniu kvalifikovanej cenovej ponuky, chýbajú údaje o typoch kariet, ktoré majú byť podporené. Kontrolovaný síce uvádza, že požaduje kompatibilitu s jestvujúcim systémom dopravných kariet a uvádza Mifare Classic, Mifare DESFire EV1 a Mifare DESFire EV2 ako typy kariet, ale tie majú svoje ďalšie varianty vzhľadom na množstvo a organizáciu pamäte, ktorou disponujú. Zabezpečenie podpory rôznych variantov kariet zvyšuje prácnosť realizácie, a tým aj cenu. V reakcií na žiadosť o nápravu zo dňa 7. 10. 2019 kontrolovaný uvádza odkazy na technickú špecifikáciu výrobcu čipových kariet Mifare, ale ani tam nespresňuje varianty, ktoré používa. Na základe uvedeného možno konštatovať, že opis logického celku 1 predmetu zákazky, uvedený v časti C súťažných podkladov, nie je úplný a jednoznačný a jeho technická špecifikácia nie je dostatočná na vypracovanie relevantných cenových ponúk. Zásadným problémom je, že kontrolovaný zákazku formuluje v zmysle objednania generického softvérového vybavenia, pričom v skutočnosti ide o vývoj komplexného softvérového systému na predaj cestovných lístkov a sledovanie trasy vozidla a rozhraní tohto systému na jestvujúce systémy kontrolovaného. Tieto systémy a ich charakteristika nie sú jasne uvedené, čo bráni odhadu rozsahu práce potrebnej na realizáciu príslušných rozhraní. Logický celok 5 sa týka personalizačného pracoviska (zákazníckeho pracoviska). Prvých päť položiek predstavujú hardvér, ale zvyšné tri položky, t. j.: 6. fotografia 6.1 fotografia na jeden klik (bez nakláňania, zaostrovania) 7. grafická personalizácia dopravných kariet 7.1 vytvorenie šablóny pre potlač karty 7.2 potlač karty

vytvorenej šablóny 8 elektronická personalizácia dopravných kariet 8.1 zápis údajov vydavateľa karty 8.2 zápis údajov držiteľa karty vystihujú možnosti, ktoré by toto pracovisko malo poskytovať, a ktoré sa nedajú dosiahnuť bez implementácie zodpovedajúceho softvérového systému. Kontrolovaný však nikde explicitne neuvádza požiadavku na takýto softvérový systém. Navyše, uvedené požiadavky funkčnosť 37 takého softvérového systému nevystihujú dostatočne presne, aby bolo možné stanoviť relevantnú cenovú ponuku. Logický celok 6 nesie názov „Vozidlový informačný systém”, ale obsahuje iba hardvérové položky. Pod informačným systémom sa bežne rozumie softvérový systém na spracovanie informácií. Logický celok 8 sa týka dodávky a inštalácia servera (hardvéru a softvéru). Bod 10 tohoto logického celku sa týka migrácie existujúcich serverov do nového prostredia a aktualizácie obslužného softvéru. Kontrolovaný vôbec neuvádza charakteristiku súčasného stavu, čo znemožňuje kvalifikovaný odhad nákladnosti migrácie. Logický celok 11 sa týka školenia. Bod 4.3 sa týka technickej prezentácie predmetu zákazky uskutočnenej na základe výzvy verejného obstarávateľa. Zásadným problémom je, že kontrolovaný požaduje prezentáciu objednávaného softvérového systému už vo fáze vyhodnocovania ponúk, resp. pred jeho implementáciou. Pravdou je, že by úspešný uchádzač mal mať za sebou vývoj podobných softvérových systémov, a že by jeden z nich mal byť schopný demonštrovať, avšak to neznamená, že by ten systém musel mať všetky charakteristiky objednávaného systému. Navyše, kontrolovaný vyžaduje, aby uchádzači naplnili systém údajmi o trase a tarife jednej z liniek, ktoré prevádzkuje. Pritom im ponúka verejne dostupný prepravný poriadok. Pri prezentácii nesmie dôjsť k chybe, inak uchádzač bude vylúčený. Toto by zvlášť zvýhodnilo dodávateľa pôvodného systému, ak by sa verejného obstarávania zúčastnil, ktorý nielen má údaje v štruktúrovanej forme, ale ich má aj priamo v systéme, a navyše ich má aj dlhodobo odskúšané. Opis logických celkov 2, 3, 4, 7, 9 a 10 uvedený v časti C súťažných podkladov sa javí ako úplný a jednoznačný a postačuje na vypracovanie relevantných cenových ponúk. Otázka 2 (

1. a)Použitie pojmu „interface”, čiže „rozhranie”, v súťažných podkladoch a v nadväzujúcich dokumentoch je v súlade s obvyklým významom tohto pojmu vo vývoji softvéru. Rozhranie predstavuje takú časť softvérového systému, prostredníctvom ktorej sa zabezpečuje komunikácia iných softvérových systémov s daným softvérovým systémom (výmena údajov) alebo jeho ovládanie (riadenie) z iných softvérových systémov. Rozhranie je, na rozdiel od zvyšku systému, sprístupnené navonok. (
2. b)Na vypracovanie relevantnej cenovej ponuky nie je potrebné sprístupnenie rozhrania jestvujúcich softvérových systémov kontrolovaného, s ktorými má objednávaný softvérový systém palubného počítača spolupracovať, v zmysle sprístupnenia príslušnej časti zdrojového kódu. Dokonca nie je potrebný ani jeho detailný opis. Potrebná je však charakteristika jestvujúcich systémov kontrolovaného, s ktorými softvérový systém palubného počítača má spolupracovať, resp. všetkých požadovaných rozhraní na tieto systémy tak, aby bolo možné odhadnúť náročnosť ich podpory. Otázka 3 Odpoveď na túto otázku je obsiahnutá v odpovedi na otázku 1 v časti týkajúcej sa logického celku 1 (ku koncu tejto časti). 38 Otázka 4 Operačný systém Windows je plnohodnotným operačným systémom, ktorý sa aktualizuje vzdialene. Nie je však voľne šíriteľný, a ani voľne upravovateľný. Nie je obvyklé, aby aplikačný softvér, akým je aj softvérový systém palubného počítača, vyžadoval zmeny v operačnom systéme. Z vyjadrenia kontrolovaného nevyplýva, že v minulosti takéto zmeny vo voľne šíriteľných a upravovateľných operačných systémoch potreboval. Kontrolovaný vyjadruje obavy z bezpečnostných rizík, ale bližšie ich nešpecifikuje. Kontrolovaný zároveň tvrdí, že by mu použitím operačného systému Windows vznikol „nesúlad v perifériách”, avšak čo toto vlastne znamená zostáva nejasné. Rovnako nie je jasné, čo znamená, že „ďalšie úpravy by boli možné len s takými nástrojmi, ktoré sú povolené od spoločnosti Microsoft”, ako ani na aké úpravy kontrolovaný myslí. Kontrolovaný tiež namieta, že by sa pri použití operačného systému Windows zariadenia museli meniť oveľa častejšie, lebo výrobca operačného systému sa môže rozhodnúť tieto zariadenia prestať podporovať. Aj keď toto je technicky možné, aktualizácie operačného systému Windows zatiaľ takéto obmedzenia nezavádzali. Skôr sa môže stať, že daná verzia operačného systému Windows prestane byť udržiavaná, a tým aj aktualizovaná, ako sa to už stalo s verziami Windows XP a Windows 7, čo však neznemožní fungovanie starších zariadení. Za povšimnutie stojí, že kontrolovaný v logických celkoch 5 a 8 priamo požaduje operačný systém Windows pri osobnom počítači („OS Windows 10 64-bit”), resp. serveri („SW MS WINDOWS Server 2016 Standard 2Core”, „SW MS WINDOWS Server 2016 User CAL” a „SW MS WINDOWS RDS 2016 User CAL”)“. Právny rámec 45.

§ 10ods.

2 zákona o verejnom obstarávaní verejný obstarávateľ a obstarávateľ musia dodržať princíp rovnakého zaobchádzania, princíp nediskriminácie hospodárskych subjektov, princíp transparentnosti, princíp proporcionality a princíp hospodárnosti a efektívnosti. 46.

§ 42ods.

1 zákona o verejnom obstarávaní súťažné podklady sú písomné, grafické alebo iné podklady obsahujúce podrobné vymedzenie predmetu zákazky. V súťažných podkladoch verejný obstarávateľ a obstarávateľ uvedú všetky okolnosti, ktoré budú dôležité na plnenie zmluvy a na vypracovanie ponuky. Opis predmetu zákazky môže odkazovať aj na osobitný postup alebo metódu výroby alebo poskytovania požadovaných tovarov, stavebných prác alebo služieb, ako aj na osobitný postup inej fázy ich životného cyklu, a to aj vtedy, ak tieto faktory netvoria súčasť ich hmotnej podstaty, musia však súvisieť s predmetom zákazky a byť primerané jej hodnote a cieľom. Predmet zákazky musí verejný obstarávateľ a obstarávateľ opísať jednoznačne, úplne a nestranne na základe technických požiadaviek

prílohy č. 3 Technické požiadavky

1. a)zohľadnia požiadavky dostupnosti pre osoby so zdravotným postihnutím a riešenia vhodné pre všetkých užívateľov okrem náležite odôvodnených prípadov; ak právne záväzné akty Európskej únie ustanovujú záväzné požiadavky dostupnosti pre osoby so zdravotným postihnutím alebo riešenia vhodné pre všetkých užívateľov, v technických požiadavkách verejný obstarávateľ a obstarávateľ uvedú odkaz na príslušné právne záväzné akty Európskej únie, 39
2. b)musia byť určené tak, aby bol zabezpečený rovnaký prístup pre všetkých uchádzačov alebo záujemcov a zabezpečená hospodárska súťaž. 47.

§ 42ods.

2 písm.

1. a)zákona o verejnom obstarávaní verejný obstarávateľ a obstarávateľ vypracujú opis predmetu zákazky na základe výkonnostných a funkčných požiadaviek, ktoré môžu zahŕňať environmentálne charakteristiky; technické požiadavky sa musia určiť tak, aby boli zrejmé všetky podmienky a okolnosti dôležité na vypracovanie ponuky. Právne posúdenie úradom Úrad preskúmal postup kontrolovaného v predmetnom verejnom obstarávaní v rozsahu namietaných skutočností a po zhodnotení všetkých podkladov, najmä dokumentácie predloženej kontrolovaným, vyjadrenia kontrolovaného, navrhovateľom namietaných skutočností a odborného stanoviska konštatuje nasledovné: 48. Úrad ohľadne namietaných skutočností navrhovateľa týkajúcich sa neposkytnutia/nezverejnenia interface ako súčasti dokumentácie zo strany kontrolovaného (bod 8 rozhodnutia) a argumentácie navrhovateľa, kde navrhovateľ dáva do pozornosti rôzne možnosti použitia modelu NDA zmluvy o ochrane poskytnutých informácií a uvedením príkladov sa navrhovateľ odvoláva na verejné obstarávania, kedy verejní obstarávatelia poskytli údaje o technických parametroch systémov existujúcich dodávateľov všetkým uchádzačom po podpise NDA zmluvy, a nie len úspešnému uchádzačovi, pričom navrhovateľ má za to, že súčasní dodávatelia majú informácie o doterajšom prostredí a parametroch kariet, čítačiek a iných parametroch predmetu zákazky a postup kontrolovaného je nezákonný (bod 9 rozhodnutia), poukazuje na odborné stanovisko, konkrétne na odpovede na otázky č. 2a) a 2b). Otázky č. 2a) a 2b) žiadosti o odborné stanovisko zneli nasledovne, cit.: ,,
2. a)Ako by ste v kontexte súťažných podkladov, berúc do úvahy žiadosť o nápravu zo dňa 01. 10. 2019, výsledok vybavenia žiadosti o nápravu/zamietnutie zo dňa 07. 10. 2019, žiadosť o nápravu zo dňa 17. 10. 2019, vysvetlenie súťažných podkladov zo dňa 23. 10. 2019 a námietky navrhovateľa charakterizovali pojem „interface“?
3. b)Je postup kontrolovaného, kedy ako súčasť súťažných podkladov nebol poskytnutý interface, dostatočný na účely vypracovania a predloženia relevantnej cenovej ponuky?“ Úrad uvádza, že odpovede na uvedené otázky sú nasledovné, cit.: ,,(
4. a)Použitie pojmu „interface”, čiže „rozhranie”, v súťažných podkladoch a v nadväzujúcich dokumentoch je v súlade s obvyklým významom tohto pojmu vo vývoji softvéru. Rozhranie predstavuje takú časť softvérového systému, prostredníctvom ktorej sa zabezpečuje komunikácia iných softvérových systémov s daným softvérovým systémom (výmena údajov) alebo jeho ovládanie (riadenie) z iných softvérových systémov. Rozhranie je, na rozdiel od zvyšku systému, sprístupnené navonok. (
5. b)Na vypracovanie relevantnej cenovej ponuky nie je potrebné sprístupnenie rozhrania jestvujúcich softvérových systémov kontrolovaného, s ktorými má objednávaný softvérový systém palubného počítača spolupracovať, v zmysle sprístupnenia príslušnej 40 časti zdrojového kódu. Dokonca nie je potrebný ani jeho detailný opis. Potrebná je však charakteristika jestvujúcich systémov kontrolovaného, s ktorými softvérový systém palubného počítača má spolupracovať, resp. všetkých požadovaných rozhraní na tieto systémy tak, aby bolo možné odhadnúť náročnosť ich podpory“. Úrad vychádzajúc z odborného stanoviska, zdôrazňujúc odpoveď na otázku č. 2
6. b)konštatuje, že na vypracovanie relevantnej cenovej ponuky zo strany navrhovateľa nie je potrebné sprístupnenie rozhrania jestvujúcich softvérových systémov kontrolovaného, s ktorými má objednávaný softvérový systém palubného počítača spolupracovať, v zmysle sprístupnenia príslušnej časti zdrojového kódu a nie je potrebný ani jeho detailný opis. Úrad ohľadne argumentácie navrhovateľa týkajúcej sa NDA zmluvy o ochrane poskytnutých informácií uvádza, že nakoľko na vypracovanie relevantnej cenovej ponuky zo strany navrhovateľa nie je potrebné sprístupnenie rozhrania jestvujúcich softvérových systémov kontrolovaného s ktorými má objednávaný softvérový systém palubného počítača spolupracovať, v zmysle sprístupnenia príslušnej časti zdrojového kódu a nie je potrebný ani jeho detailný opis, model uzavretia NDA zmluvy, ktorý zvolil kontrolovaný, vzhľadom na skutočnosť, že uzatvorenie NDA zmluvy medzi kontrolovaným a úspešným uchádzačom a tomu nadväzujúce poskytnutie rozhraní jestvujúcich softvérových systémov kontrolovaného voči úspešnému uchádzačovi, nespôsobuje situáciu, kedy navrhovateľovi nie je umožnené vypracovať relevantnú cenovú ponuku. Inak povedané, v predmetnej verejnej súťaži model uzavretia NDA zmluvy medzi kontrolovaným a úspešným uchádzačom nespôsobuje pre navrhovateľa nemožnosť vypracovania relevantnej cenovej ponuky, keďže na vypracovanie relevantnej cenovej ponuky zo strany navrhovateľa nie je potrebné sprístupnenie rozhrania jestvujúcich softvérových systémov kontrolovaného, a teda v danom prípade, model uzavretia NDA zmluvy zvolený kontrolovaným nemá v zmysle vyššie uvedeného vplyv na vypracovanie relevantnej cenovej ponuky. Úrad vo vzťahu k argumentácii navrhovateľa, kde navrhovateľ poukazuje na rozhodnutie úradu č. 14356-6000/2018-OD zo dňa 23. 04. 2019, pričom navrhovateľ zastáva názor, že úrad v predmetnom rozhodnutí zrušil verejnú súťaž z dôvodu, že kontrolovaný v rámci súťažných podkladov neposkytol interface uvádza, že v predmetnom rozhodnutí úrad o. i. skonštatoval, že kontrolovaný mal povinnosť v súťažných podkladoch uviesť aj požiadavku na tvorbu softvéru, ktorý bude prevádzkovaný na samostatných čítačkách a ktorý úspešný uchádzač bude musieť zhotoviť a tiež informáciu, či požaduje dodanie SAM modulov, ak dodanie SAM modulov požaduje, pričom je povinnosťou kontrolovaného uviesť s akými charakteristikami majú byť SAM moduly dodané. Úrad teda v uvedenom rozhodnutí žiadnym spôsobom neskonštatoval, že by dôvodom zrušenia verejnej súťaže bolo neposkytnutie interface zo strany kontrolovaného, úrad skonštatoval porušenie § 10 ods. 2 v spojení s § 42 ods. 1 zákona o verejnom obstarávaní, spočívajúce v neposkytnutí súťažných podkladov, ktoré obsahujú jednoznačný, úplný, nestranný a transparentne spracovaný opis predmetu zákazky. Úrad považuje vyššie uvedené namietané skutočnosti v kontexte uvedeného za neopodstatnené. 41 49. Úrad ohľadom namietaných skutočností navrhovateľa, že kontrolovaný nedostatočne popisuje predmet zákazky a zároveň porušuje princípy verejného obstarávania ako aj tvrdení navrhovateľa, že kontrolovaný v prípade kariet Mifare Classic, Mifare DESFire EV1 a Mifare DESFire EV2 neuviedol dátové štruktúry karty a popis práce s kartou, čo

názoru navrhovateľa spôsobuje nedostatočnú špecifikáciu, poukazuje na odborné stanovisko, kde sa na otázku č.1 cit.: ,,Je opis predmetu zákazky úplný a dostatočne jednoznačný na predloženie relevantných porovnateľných ponúk, resp. je technická špecifikácia dostatočná na vypracovanie relevantnej cenovej ponuky?“, uvádza nasledovná odpoveď, cit.: ,,Predmet zákazky pozostáva zo siedmich častí:  Logický celok 1: Palubný počítač HW, Palubný počítač SW pre PAD a MHD (199

1. ks) Logický celok 2: Tlačiareň cestovných lístkov s čítačkou BOK, čítačkou EMV kariet a čítačkou 2D kódu (199
2. ks) Logický celok 3: Komunikačná jednotka (199
3. ks) Logický celok 4: Podstava (199
4. ks) Logický celok 5: Personalizačné pracovisko (zákaznícke pracovisko) (6
5. ks) Logický celok 6: Vozidlový informačný systém  Logický celok 7: Vozidlový kamerový systém (173
6. ks) Logický celok 8: Dodávka a inštalácia servera (HW a SW)  Logický celok 9: WiFi vo vozidle (198
7. ks) Logický celok 10: Inštalácia predmetu zákazky  Logický celok 11: Školenie Logický celok 1 sa týka palubného počítača, pričom pod palubným počítačom sa tu nerozumie iba počítač s generickým softvérovým vybavením, ktorý by sa dal dodať ako hotový produkt, t. j. bez ďalšieho vývoja, ale aj komplexný softvérový systém na predaj cestovných lístkov a sledovanie trasy vozidla. Zásadný problém opisu tejto časti predmetnej zákazky je, že kontrolovaný softvérové vybavenie palubného počítača pokladá za priamo komerčne dostupný softvérový systém, ktorý je priamo použiteľný bez ďalšieho vývoja alebo len s malými zásahmi, a nie za špecializovaný softvér na objednávku, ktorého dodaniu musí predchádzať vývojový proces na základe špecifických požiadaviek kontrolovaného. Kontrolovaný nikde v opise predmetu zákazky neuvádza, že objednáva vývoj softvéru. Tento pojem nefiguruje ani v údajovom slovníku zákazky. Vývoj softvéru je potrebný v dvoch líniách: na zabezpečenie funkcií, ktoré kontrolovaný špecifikoval v prílohe č. 6 súťažných podkladov, a na zabezpečenie prepojenia s jestvujúcim softvérovým vybavením. Špecifikácia funkcií je pomerne rozsiahla a detailná, ale mnohé jej položky nie sú úplne jasné, resp. ich splnenie vyžaduje spresnenie a ďalšie údaje. Napríklad, položka „2.1.9 akceptácia cestovných lístkov predávaných cez internet” nedefinuje, formu cestovných lístkov predávaných cez internet, čím zostáva nejasné, ako ich palubný počítač má rozpoznať a akceptovať. Položky „2.1.13 spracovanie a posielanie dát pre informačné tabule” a „2.1.14 spracovanie a posielanie dát pre zvukové hlásiče” nedefinujú z čoho pozostávajú údaje pre informačné tabule, resp. zvukové hlásiče. Položka „2.2.3 zariadenie umožňuje poskytovať prestup, pričom cena prestupného lístka je daná doplatkom na základe súčtu 42 tarifných kilometrov obidvoch odjazdených úsekov” nedefinuje presne, ako má byť implementovaný výpočet ceny, resp. ako sa prepočítajú kilometre na peniaze. Tarifné systémy spomenuté v položke „2.2.6 pomocou backofficu je možné prepínať medzi podporou zónového, kilometrického, pásmového, časového tarifného systému” nie sú nikde definované. Položka „2.2.7 zariadenie umožňuje prechod medzi viacerými typmi tarifných systémov v rámci jedného spoja” nedefinuje, čo znamená prechod medzi viacerými typmi tarifných systémov v rámci jedného spoja, ani ako sa má uskutočniť. Položka „2.2.8 zariadenie podporuje použitie odchýlkovej ceny medzi dvomi definovanými zastávkami spoja” nedefinuje, čo je odchýlková cena, ani ako čo znamená jej použitie. Toto by bolo prijateľné, ak by daná špecifikácia bola pokladaná za hrubú alebo rámcovú špecifikáciu požiadaviek, a ak by sa predpokladala jej konkretizácia v rámci vývoja softvéru. Toto však zo súťažných podkladov nevyplýva. Z hľadiska prepojenia s jestvujúcim softvérovým vybavením kontrolovaného, dôležité je povedať, že prepojenie vlastne znamená vývoj špecializovanej časti softvérového systému palubného počítača, ktorý toto prepojenie zabezpečí. Prepojenie nie je potrebné len na centrálny riadiaci systém, ako kontrolovaný uvádza, ale aj na zvukové hlásiče, ako vyplýva z položky „2.1.14 spracovanie a posielanie dát pre zvukové hlásiče”. Pritom nie je jasné, ani aké údaje majú byť posielané, ani v akom formáte, a ani cez aké rozhranie. Podobne je to s položkou „2.2.9 zariadenie umožňuje konfigurovateľný mechanizmus hlásenia zastávok do vozidla”, ktorá sa možno týka hlásičov, resp. softvérového systému, ktorý ich ovláda, alebo nejakého ďalšieho systému. Takisto položka 2.2.15 vstupné a výstupné dáta z PP zabezpečia:
8. a)zber a záznam dát technologických procesov vozidla
9. b)dátový prenos prostredníctvom WiFi a GSM siete • vo vozovni dopravcu medzi vozidlom a výpravňou (rozpoznanie vozidla a aktualizáciu dát informačného a vybavovacieho systému počas doby vozidla vo výpravni bez zásahu človeka) vyžaduje získavanie údajov technologických procesov vozidla, pričom nie je jasné, z akého systému sa tieto údaje majú získať. Tiež nie je jasné, či je „výpravňa” to isté, ako centrálny riadiaci systém. Rozhranie medzi systémom palubného počítača nemá byť iba údajové, ale aj riadiace, čo vyplýva z položky 2.2.13: 2.2.13 PP musí spolupracovať s dispečingom a sledovať:
10. a)zapínanie
11. b)vypínanie
12. c)stavové správy v aktuálnom rozsahu
13. d)ovládanie hlasovej komunikácie
14. e)generovanie vopred definovaných textových správ Na realizáciu tohto všetkého je potrebná minimálne podrobná špecifikácia rozhraní jestvujúcich systémov kontrolovaného a formátov údajov, ktoré tieto systémy používajú pri komunikácií s externými systémami, k čomu sa kontrolovaný v súťažných podkladoch vôbec nevyjadruje. Až v reakcií na žiadosť o nápravu zo dňa 7. 10. 2019 kontrolovaný uvádza, že s dodávateľmi týchto systémov uzavrel dohodu o poskytnutí potrebnej dokumentácie výlučne víťaznému uchádzačovi na základe podpísanej zmluvy (NDA) o ochrane poskytnutých informácií. Keďže presnosť a úplnosť dokumentácie voči tomu, čo je skutočne implementované v softvérovom 43 systéme, nikdy nie je zaručená, otázne je, či toto víťaznému uchádzačovi bude postačovať, resp. či nebude potrebná súčinnosť dodávateľov jestvujúcich systémov kontrolovaného. Ku kvalifikovanému odhadu zložitosti softvéru, ktorý má byť vytvorený, a tým aj k stanoveniu kvalifikovanej cenovej ponuky, chýbajú údaje o typoch kariet, ktoré majú byť podporené. Kontrolovaný síce uvádza, že požaduje kompatibilitu s jestvujúcim systémom dopravných kariet a uvádza Mifare Classic, Mifare DESFire EV1 a Mifare DESFire EV2 ako typy kariet, ale tie majú svoje ďalšie varianty vzhľadom na množstvo a organizáciu pamäte, ktorou disponujú. Zabezpečenie podpory rôznych variantov kariet zvyšuje prácnosť realizácie, a tým aj cenu. V reakcií na žiadosť o nápravu zo dňa 7. 10. 2019 kontrolovaný uvádza odkazy na technickú špecifikáciu výrobcu čipových kariet Mifare, ale ani