MAGISTRÁT MĚSTA ÚSTÍ NAD LABEM

Transkript

1 MAGISTRÁT MĚSTA ÚSTÍ NAD LABEM VELKÁ HRADEBNÍ ÚSTÍ NAD LABEM ODBOR ROZVOJE MĚSTA Oddělení přípravy a realizace investic VÁŠ DOPIS ZNAČKY/ZE DNE EVID. Č. NAŠE ZNAČKA VYŘIZUJE/ LINKA V ÚSTÍ NAD LABEM MM/ORM/143767/13 ORM/OPRI/205/2014 Mgr.Zíka/kl Věc: Elektronický odbavovací systém pro cestující dodatečná informace č. 3 K Vaší žádosti o poskytnutí dodatečné informace ze dne uvádíme následující: 1. Zadávací dokumentace - str. 15, čl (1) výměna terminálu a náběh terminálu do funkčního stavu. DOTAZ: Předmětem nabídky má být několik provedení validátorů. U předních dveří mohou být zařízení samostatné nebo sloučené. Ze zadávací dokumentace není zřejmé u jakého provedení validátoru a jakým způsobem chce zadavatel hodnotit toto kritérium, když uchazeči mohou nabídnout různá řešení, např. provedení validátoru integrovanou s nebo externí tiskárnou? Předpokládáme správně, že pokud některý z uchazečů nabídne validátor s externí tiskárnou, tak se do času výměny a náběhu terminálu bude započítávat čas na výměnu a náběh jak validátoru tak i externí tiskárny? Pro hodnocení tohoto dílčího kritéria bude zadavatel hodnotit rychlost výměny terminálu s tiskárnou na tisk a výdej jízdních dokladů. Za předpokladu, že bude předmětem nabídky terminál s externí tiskárnou, tak se do času výměny a náběhu terminálu bude započítávat i čas na výměnu a náběh externí tiskárny. TELEFON INTERNET: Dle OZV č. 45/1996 o závazných částech územního plánu statutárního města Ústí nad

2 2 2. Zadávací dokumentace - str. 15, čl (2) Doba náběhu celého systému, tj. včetně terminálů pro cestující. Bude posuzována doba náběhu celého systému u plně vybaveného vozidla se 3 dveřmi, dle zadávací dokumentace. Zadavatel bude posuzovat čas od resetu systému po plnou funkcionalitu celého systému, tj. plná funkcionalita všech komponent odbavovacího a informačního systému. Maximální bodové hodnocení získá uchazeč, který nabídne požadovanou bodu náběhu celého systému do 120 sekund či kratší. DOTAZ: Žádáme o upřesnění, jakým způsobem bude probíhat hodnocení tohoto kritéria? Předpokládá se, že uchazeči budu muset předvést plně funkční systém na jednom vozidle? Zástavbu do vozidla zadavatel nevyžaduje. Pro hodnocení toho dílčího kritéria si uchazeči připraví sestavu celého systému, která bude odpovídat zadávacím požadavkům na plně vybavené vozidlo se 3 dveřmi. 3. Zadávací dokumentace - str. 15, čl (3) Předvedení funkčního odbavovacího zařízení s vestavěnou čtečkou bezkontaktních čipových karet a EMV karet. Provedení reálných dopravních transakcí nabízenou bezkontaktní čipovou kartou. Provedení reálných platebních transakcí minimálně 2 ks karet VISA a 2 ks karet MasterCard vydaných alespoň dvěma českými (případně zahraničními) bankami v libovolné kombinaci vydavatel vs. Karetní asociace. DOTAZ: Zadavatel mimo jiné požaduje i provedení reálných dopravních transakcí nabízenou bezkontaktní čipovou kartou. Předpokládáme správně, že pro ověření tohoto kritéria bude využita bezkontaktní čipová karta připravená uchazečem? Pro hodnocení toho dílčího kritéria bude použita bezkontaktní čipová karta připravená uchazečem. 4. Zadávací dokumentace - Technická specifikace - str. 6, čl. 3. Současný stav Modifikace v rámci tohoto projektu se bude týkat systému SKELETON od firmy FS Software, s.r.o. v oblasti výstupů z jednotlivých modulů do softwarů dodavatele OIS pro palubní systémy vozidel a ostatní informační systémy a dále pak formátu vstupních dat z OIS do SKELETONU DOTAZ: Žádáme o upřesnění jaké výstupy z jednotlivých modulů do sw dodavatele OIS se budou používat. Jaký je požadovaný formát vstupních dat z OIS do SKELETONU? Požadavek byl, přenášet co možná nejvíce parametrů provozu vozidla, tak aby bylo možné přidat či odebrat jednotlivé parametry (např. GPS pozice, otevření-zavření dveří, stav paliva atd.). Data by se měla automaticky ukládat do tabulek DB např. FireBird nebo v případě hostovaného úložiště do mysql či MSSQL.

3 3 5. Zadávací dokumentace - Technická specifikace - str. 6, čl. 3. Stávající přenosový systém zabezpečovaný firmou KonekTel, a.s., Pardubice bude zachován. DOTAZ: Žádáme o upřesnění, zda je požadována vazba mezi stávajícím přenosovým systém a OIS? Pokud ano, tak prosíme o předání detailního popisu systému, včetně popisu rozhraní a komunikačního protokolu. Žádná vazba mezi stávajícím přenosovým systémem a OIS není požadována, požadujeme zachování radiokomunikace. 6. Zadávací dokumentace - Technická specifikace - str. 8, čl Z hlediska předpokládaného budování integrovaného dopravního systému Ústeckého kraje se předpokládá interoperabilita s dalšími kartovými systémy (In- Karta ČD, karta ostatních příměstských a městských dopravců) pro veřejnou dopravu s totožnou úrovní bezpečnosti a důvěryhodnosti. Dále se počítá s využitím bezkontaktních čipových karet pro neziskové organizace Statutárního města Ústí nad Labem. DOTAZ: Žádáme o upřesnění, zda má být akceptace těchto karet předmětem nabídky nebo lze tento požadavek chápat tak, aby systém umožnil pozdější rozvoj o akceptaci těchto karet? Za předpokladu, že má být akceptace karet ostatních příměstských a městských dopravců ostatních příměstských a městských dopravců předmětem nabídky, žádáme o jednoznačné upřesnění o jaké karty se jedná (typ karty, využívá SAM? Pokud ano, tak má být SAM také předmětem plnění?) Prosíme o dodání popisu karet, struktur a jejich aplikací. Implementace dalších kartových systémů není předmětem nabídky. Postačí prohlášení uchazeče, že nabízený systém je dostatečně dimenzován na další rozvoj související s předpokládanou interoperabilitou s dalšími kartovými systémy. 7. Zadávací dokumentace - Technická specifikace - str. 8, čl odbavení cestujících na SMS jízdenku, jízdenku zakoupenou pomocí aplikace SEJF a na jízdenku zakoupenou u řidiče dopravního prostředku, DOTAZ: Žádáme o upřesnění, jak probíhá odbavení na SMS jízdenku? Jak probíhá kontrola SMS jízdenky (a přes jaké rozhraní)? Jak probíhá kontrola jízdenky zakoupené pomocí aplikace SEJF (přes jaké rozhraní)? Jakými způsoby bude probíhat nákup jízdenky u řidiče (požaduje se odbavení cestujícího s platbou v hotovosti)? Kdo bude volit druh jízdenky (řidič nebo cestující)? Bude požadováno odbavení více cestujících najednou? Kontrola jízdenky probíhá tak, že řidič zadá hash manuálně na terminálu palubního počítače. Platba v hotovosti u řidiče není požadována. Druh jízdenky volí cestující na displeji terminálu. Systém musí umožnit odbavení více cestujících najednou. 8. Zadávací dokumentace - Technická specifikace - str. 8, čl náběh terminálu do plné funkcionality při výpadku napájení kratším než 9 hodin: bez aktualizace dat do 3 vteřin; náběh terminálu do plné funkcionality při výpadku napájení delším než 9

4 4 hodin, bez aktualizace dat do 30 vteřin, udržení SAM modulu v odemčeném - autentizovaném stavu při výpadku napájení kratším než 9 hodin, Stejný požadavek je uveden i v čl a DOTAZ: Žádáme zadavatele o vysvětlení, z jakého důvodu požaduje udržovat SAM v autentizovaném stavu po tak nestandardně dlouhou dobu (při výpadku napájení kratším než 9 hodin)? Dle našeho odborného názoru je tento požadavek v rozporu s bezpečnostní politikou. V případě krádeže terminálu se SAM modulem v odemčeném stavu se tímto výrazně navyšuje bezpečnostní riziko pro neoprávněnou manipulaci. Doporučujeme omezit tuto dobu na max. 5 min, která plně postačuje pro pokrytí případných krátkodobých výpadků napájení a v případě krádeže přitom není dostatek času na případné zneužití. Dále upozorňujeme zadavatele na rozpor v zadávací dokumentaci, kdy v tomto článku zadavatel požaduje náběh terminálu do plné funkcionality při výpadku napájení delším než 9 hodin, bez aktualizace dat do 30 vteřin. V hodnotících kritériích však připouští jako vyhovující i náběh terminálu do 70 sekund. Žádáme zadavatele o potvrzení, že bude akceptováno řešení s náběhem terminálu do 70 sekund. Zadavatel upravuje znění Technické specifikace v bodech a takto náběh terminálu do plné funkcionality při výpadku napájení kratším než 15 min: bez aktualizace dat do 3 vteřin; náběh terminálu do plné funkcionality při výpadku napájení delším než 15 min, bez aktualizace dat do 70 vteřin, udržení SAM modulu v odemčeném - autentizovaném stavu při výpadku napájení kratším než 15 min. 9. Zadávací dokumentace - Technická specifikace - str. 12, čl Centrální bezpečnostní infrastruktura bude uchovávat kryptografické klíče v kryptografických HW modulech (HSM), zajišťuje inicializaci (odemykání) SAM ve čtecích terminálech (např. po zapnutí čtečky nebo po vyčerpání limitu transakcí) a přímo on-line provádí některé citlivé operace s kartou DOTAZ: Žádáme zadavatele o upřesnění, co se stane, když bude HSM nedostupné? HSM zajišťuje pouze prvotní inicializaci SAM, při nasazení do vozidla se SAM již nemusí autentizovat k HSM? Jaké citlivé operace s kartou provádí on-line? U vozidlového SAM zajišťuje HSM pouze prvotní inicializaci SAM, provozní autentizace po zapnutí čtečky s nastavením počtu transakcí se předpokládá u revizorského SAM. Bude-li HSM nedostupné, nebude možno provádět revizorskou kontrolu (po vyčerpání již nastaveného limitu). Citlivé on-line operace s kartou provádí HSM při personalizaci karty. 10. Zadávací dokumentace - Technická specifikace - str. 15, čl Aplikační software bude mít minimálně následující vlastnosti: identifikoval čipové karty ISIC DOTAZ: Co je myšleno pod tímto požadavkem? Jak si zadavatel představuje proces identifikace čipové karty ISIC? Co musí aplikační sw číst z této karty? Identifikací karty ISIC je myšleno přečtení UID karty, SW tedy bude z karty ISIC číst pouze UID.

5 5 11. Zadávací dokumentace - Technická specifikace - str. 15, čl Aplikační software bude mít minimálně následující vlastnosti: - byl zajištěn export dat držitelů předplatných časových jízdenek ze stávajícího softwaru dopravce do nového software. DOTAZ: Žádáme zadavatele o poskytnutí formátu a struktury dat tohoto exportu. Ze stávajícího SW lze na zakázku vytvořit exportní soubor položek požadují nový SW a to ve formátu CSV (oddělovač ;) 12. Zadávací dokumentace - Technická specifikace - str. 14, čl (dtto str. 31 čl. 4.12) 8 ks čteček bezkontaktních čipových karet (komunikační modul) obousměrná komunikace mezi kartou a PC, zápis a čtení dat bezkontaktních karet podle ISO A/B; připojení k PC přes USB, příprava na akceptaci bezkontaktních bankovních karet VISA PaWave a MC PayPass. DOTAZ: Požaduje zadavatel integrované řešení do jedné čtečky, nebo připouští i oddělené řešení, tedy čtečku bezkontaktních čipových karet ISO a bezkontaktní platební terminál pro práci s bezkontaktními platebními kartami? Zadavatel požaduje funkcionalitu, způsob technického řešení je na uchazeči. 13. Zadávací dokumentace - Technická specifikace - str. 18, čl V rámci IDS ÚK budou vydávána jednotná data pro odbavovací systémy, obsahující definice IDS (čísla zón, přiřazení zastávek do zón, tarifní jednice, seznam všech jízdních dokladů IDS); software musí zajistit import těchto dat do systému pro přípravu dat pro odbavovací systém. DOTAZ: Jaký bude formát dat? Prosíme o zaslání příkladu struktury těchto dat. Informace, které poskytne Ústecký kraj zadavateli, budou následně (do ) uveřejněny na profilu zadavatele. 14. Zadávací dokumentace - Technická specifikace - str. 19, čl Pořízení HW a SW pro vybavení 2 stanic lanové dráhy. Zařízení musí být plně kompatibilní vozidlovým informačním systémem DOTAZ: Zadavatel požaduje, že zařízení musí být plně kompatibilní s vozidlovým informačním systémem. Při prohlídce místa plnění však spíše vyplynul požadavek na zajištění kompatibility se stávajícím systémem používaným pro odbavení ve stanici lanové dráhy. Žádáme o upřesnění rozsahu požadované kompatibility s vozidlovým informačním systémem a se stávajícím odbavovacím systémem lanové dráhy. Dále žádáme o podrobnější popis požadovaného způsobu odbavení ve stanici lanové dráhy. Na základě provedeného místního šetření by nebylo vhodné umisťovat do prostorů lanové

6 6 dráhy Větruše odbavovací zařízení stejné jako bude ve vozech, neboť zde odbavení probíhá odlišným způsobem. Požadujeme, aby odbavení probíhalo dle následujících způsobů na obou pokladnách lanové dráhy Větruše: - placení v hotovosti jako dosud - platební terminálem pro běžné platební karty - platební terminál pro elektronickou peněženku Platební terminály umístit u pokladen a s doplněním displeje pro kontrolou výše ceny za jízdné pro cestujícího i staničníka. Na základě těchto plateb obdrží cestující jízdenku s čarovým kódem, která je nutná pro průchod turnikety lanové dráhy. Tyto platby musí být evidovány v sestavách prodejních PC lanové dráhy, tržby musí spadat mezi tržby lanové dráhy. Je to z důvodu evidence prodejů, statistiky přepravených osob atp. Dále pak pro vyhodnocování tržeb z provozu lanové dráhy Větruše. Vše musí spolupracovat se stávajícím nebo popřípadě jiným kompatibilním softwarem a hardwarem. (Pokladní systém, jeho program dodávala firma Aproks s.r.o. Praha). Předpokládá se, že na lanové dráze Větruše se nebudou uznávat žádné časové předplatní jízdenky ani jízdenky pro jednotlivou jízdu. Lanová dráha Větruše má svůj Tarif, kde se jízdenky zakupují přímo ve stanicích lanové dráhy. 15. Zadávací dokumentace - Technická specifikace - str. 20, čl Maximální délka odbavení na čipovou kartu nebo SMS jízdenku je max. 1,5 2 sekundy. DOTAZ: Jak probíhá odbavení na SMS jízdenku? Jaké rozhraní a protokol se využívá? Je tím myšleno základní odbavení na čipovou kartu, jako je odbavení z elektronické peněženky či kontrola platnosti časového kupónu nebo i dobití e-shopové transakce? V časovém limitu 1,5 2 sekundy musí být provedeno odbavení z elektronické peněženky nebo kontrola platnosti časového kupónu. 16. Zadávací dokumentace - Technická specifikace - str. 22, čl Odpojovač: Zařízení pro filtrování napájecích špiček v rámci palubní sítě vozidla. DOTAZ: Je výrazem odpojovač míněno zařízení, které filtruje celou síť vozidla, tedy všechny špičky, které vygeneruje elektrický agregát vozu? Pod pojmem filtrace špiček si představujeme zabránění tomu, aby byla potlačena krátkodobá přepětí. Žádáme o podrobnější upřesnění požadovaných funkcionalit tohoto odpojovače. Ano, výrazem odpojovač je míněno zařízení, které filtruje celou síť vozidla, tedy všechny špičky, které vygeneruje elektrický agregát vozu, přičemž pojmem filtrace špiček je myšleno potlačení krátkodobého přepětí. 17. Zadávací dokumentace - Technická specifikace - str. 22, čl datové přenosy VOICE IP (datové přenosy, přenos hlasu), DOTAZ: Připouští zadavatel řešení obdobnou službou např. PushToTalk? Zadavatel připouští řešení obdobnou službou.

7 7 18. Zadávací dokumentace - Technická specifikace - str. 23, čl Vybavení druhých a dalších dveří bude jednotné. Je popsaná funkcionalita, která musí být zabezpečená u druhých a dalších dveří - čtečka EMV karet DOTAZ: Jakým způsobem zadavatel zamýšlí přepravní kontrolu odbavených cestujících s EMV kartami, když u druhých a dalších dveří nejsou validátory vybavené tiskárnou pro tisk jízdního dokladu? Zadavatel upřesňuje, že EMV čtečky bezkontaktních bankovních karet u druhých a dalších dveří jsou zamýšleny pro další fáze rozvoje řešení. Zadavatel potvrzuje, že pomocí bezkontaktní bankovní karty je možné odbavení pouze u předních dveří, kde je validátor s tiskárnou, který po uhrazení jízdného bezkontaktní bankovní kartou vydá doklad o zaplacení jízdného. 19. Zadávací dokumentace - Technická specifikace - str. 26, čl. 4.7 Systém musí umožnit zobrazení SMS jízdenek a časových kupónů (aplikace SEJF), které si cestující zakoupil. DOTAZ: Žádáme o předání specifikace rozhraní a protokolu k systému SMS jízdenek a k aplikaci SEJF Dopravce má uzavřený smluvní vztah s Dodavatelem SMS Jízdenek, datových jízdenek a elektronických časových kuponů se společností Erika, a.s. Na základě tohoto smluvního vztahu jsou zaměstnanci dopravce vybaveni mobilní aplikací pro mobilní telefony na platformě Android (aktuálně Samsung S III), která slouží zaměstnancům dopravce ke kontrole SMS jízdenek a datových jízdenek prostřednictvím kontrolního kódu, Hasch kódu či telefonního čísla a elektronických časových kuponů prostřednictvím QR kódu. Pro kontrolu řidičem vozidla jsou SMS jízdenky a datové jízdenky opatřeny kontrolním kódem, který generuje sám systém. Součástí systému je i webové rozhraní umožňující administraci systému, statistické i finanční výstupy, atd. Celý systém funguje jako proprietární řešení Dodavatele. Zajištění součinnosti je odpovědností dopravce, který má tuto skutečnost ošetřenu smluvně s Dodavatelem těchto systémů. Technické detaily mohou být sděleny až po uzavření NDA s Dodavatelem, protože se jedná o unikátní technické řešení Dodavatele. Pro přípravu nabídky zveřejňujeme relevantní část rozhraní, specifikace rozhraní je neveřejná, jedná se o součást řešení dodaného třetí stranou. Část rozhraní: Komunikace: HTTPS, nutný klientský certifikát typ rozhraní: SOAP nebo RestAPI Dostupné funkce: string VALIDATE(string HASHCode, int Type) funkce zpracovává vstupní parametry HASHCode (kód sejmutý z jízdenky) a Type (typ jízdenky/časového kupónu) dle našeho číselníku. Funkce vrací hodnotu buď VALID nebo INVALID, v případě neplatné jízdenky za pomlčkou následuje důvod neplatnosti.

8 8 20. Zadávací dokumentace - Technická specifikace - str. 26, čl. 4.7 Zajištění hostingu e-shopu vybraného dopravcem. DOTAZ: Zadavatel v čl požaduje dodání 1 ks centrální server e-shop a zároveň v tomto článku požaduje zajištění hostingu e-shopu vybraného dopravcem. Chápeme to správně tak, že HW bude umístěn k danému hostingu (tedy hosting zajistí pouze rychlé připojení)? Bude zadavatel při výběru hostingu pro e-shop respektovat technické požadavky pro takový systém definované uchazečem Zadavatel zajistí hosting pro e-shop v souladu s technickými požadavky definovanými v nabídce úspěšného uchazeče. 21. Zadávací dokumentace - Technická specifikace - str. 26, čl. 4.7 E-shop musí umožnit zobrazení transakcí pro cestující, kteří použili bezkontaktní bankovní kartu, vydanou minimálně asociacemi VISA a MasterCard. DOTAZ: Žádáme o upřesnění, zda Zadavatel požaduje zobrazení transakcí z bezkontaktní bankovní karty ve vozidle (anonymní prodej) nebo e-shopových transakcí k danému účtu? Pro případ, že by zadavatel požadoval zobrazení transakcí z bezkontaktní bankovní karty ve vozidle, tak prosíme o upřesnění, jakým způsobem zadavatel zamýšlí tuto realizaci. Dle našich znalostí banka neposkytuje informace o cestujícím v transakci s jeho kartou (bezpečnostní politika banky). V systému E-shop tak nebude možné provádět párování transakce bankovní bezkontaktní kartou a cestujícího. E-shop musí umožnit zobrazení transakce bankovní kartou provedené při nákupu, např. časových kupónů přes e-shop. Transakce pořízené bezkontaktní bankovní kartou na odbavovacím zařízení si držitel bankovní karty může zobrazit v prostředí Internetového bankovnictví, případně v aplikaci Smartbanking na mobilních telefonech. 22. Zadávací dokumentace - Technická specifikace - str. 27, čl Přenos dat v provozovnách provozovatele bude zajištěn wifi soustavou, minimálně o dvou switch, z toho jeden bude umístěn v prostoru příjezdu vozidel do provozovny dopravce. DOTAZ: Při prohlídce místa plnění nám bylo sděleno, že zadavatel má představu o pokrytí WiFi signálem ve větším rozsahu, než jen v prostoru příjezdu vozidel do provozoven. Žádáme o potvrzení této informace. Za předpokladu požadavku na zajištění většího pokrytí prosíme o předání plánu vozoven s vyznačenými plochami, kde je požadováno zajištění pokrytí WiFi signálem. Ano, zadavatel má požadavek na pokrytí nejen prostoru příjezdu vozidel do provozoven viz plánky. Plánky budou uveřejněny na profilu zadavatele (do ).

9 9 23. Zadávací dokumentace - Technická specifikace - str. 31, čl ks revizorských čteček včetně příslušenství (pouzdro a nabíječka) s těmito vlastnostmi: o multifunkční zařízení umožňující kontrolu čipových karet, bezkontaktních bankovních karet VISA/MasterCard DOTAZ 1): Upřesněte, prosím, pojem předpokládaný způsob revizorské kontroly při odbavení cestujících pomocí bezkontaktní bankovní karty. Ze zadání není zřejmé, že kontrola odbavení platební bankovní kartou je uvedena v evidenci činností revizora. DOTAZ 2): Chápeme správně pojem multifunkční zařízení revizorské čtečky jako sestavu logických a fyzických komponent, která umožní načítat data z bezkontaktní platební karty, aniž by došlo ke kompromitaci bezpečnostních požadavků karetních asociací (Visa a Mastercard) pro práci s platebními kartami a zejména s číslem karty (standard PCI DSS)? 1) Revizorská kontrola bankovní karty není předmětem tohoto výběrového řízení, ale revizorská čtečka musí být schopna v budoucnu číst číslo bankovní karty. Součastí tohoto výběrového řízení je pouze odbavení cestujícího na jednotlivou jízdu placenou bankovní kartou, při kterém cestující obdrží tištěný doklad, který bude předmětem kontroly v rámci toho výběrového řízení. 2) Uchazeč pojem multifunkční zařízení chápe správně. 24. Zadávací dokumentace - Technická specifikace - str. 31, čl software na vyhodnocení činnosti PK bude vyhotoven na bázi webovské aplikace, přístupné z internetového prohlížeče DOTAZ: Žádáme o vysvětlení z jakého důvodu je pouze u této části back-office požadován software na bázi webové aplikace (software na vyhodnocení činnosti PK)? Připouští zadavatel možnost nabídnout kvalitativně a technicky obdobné řešení, které naplní zadavatelem požadovanou funkcionalitu? Zadavatel připouští možnost nabídnout kvalitativně a technicky obdobné řešení. 25. Zadávací dokumentace - Technická specifikace - str. 32, čl Komunikace s řídící jednotkou odbavovacího systému ve vozidle MHD. DOTAZ: Žádáme o upřesnění jaká data se požadují přenášet mezi řídící jednotkou a kontrolním zařízení? Je na uchazeči, jaká data bude přenášet mezi řídící jednotkou a kontrolním zařízením. Cílem je, aby revizor měl všechny potřebné informace k posouzení, zda má cestující platný jízdní doklad. 26. Zadávací dokumentace - Technická specifikace - str. 33, čl Přístup k aktuální databázi prodaných jízdenek a karet se požaduje prostřednictvím mobilní sítě GSM pro účely mobilní přepravní kontroly.

10 10 DOTAZ: Žádáme o upřesnění jakou databázi má zadavatel na mysli (seznam prodaných jízdenek ve vozidle)? Je tím myšlena databáze bankovních karet, na které byla provedena platba za jízdenku ve vozidle? Ano, jedná se o seznam prodaných jízdenek ve vozidle a platných časových kupónech. Cestující, který si zakoupí jízdní doklad pomocí bankovní karty se bude prokazovat papírovým jízdním dokladem, který při zakoupení dostane. 27. Příloha č. 3 Zadávací dokumentace Smlouva o dílo - str. 10, čl. XI. Prohlášení zhotovitele 1) Zhotovitel garantuje zachování funkčnosti stávajícího technologického a technického zařízení ve vozidlech objednatele v novém systému, tzn. Palubní počítač BS100, informační systém a řídící jednotka ZJ 01 viz "Technické zadání veřejné zakázky" odstavec "Popis rozmístění komponentů odbavovacího zařízení ve vozidlech MHD" po dobu zkušebního provozu s cestujícími. Dále garantuje napojení. Dále garantuje, že nový odbavovací systém musí funkčně navazovat na technologie a technická zařízení provozované ve vozidlech provozovatele., tzn. vnitřní informační panely BS 120, BS 170, vnější informační panely BS 210, BT 519 BUSTEC (výrobce BUSE Blansko, BUSTEC). DOTAZ 1) V požadovaném prohlášení zadavatel požaduje zachování funkčnosti stávajícího technologického a technického zařízení ve vozidlech objednatele v novém systému, tzn. Palubní počítač BS100 informační systém a řídící jednotka ZJ 01. Řídící jednotka ZJ 01 však není uvedena v Technickém zadání veřejné zakázky odstavec "Popis rozmístění komponentů odbavovacího zařízení ve vozidlech MHD" a dle našich znalostí není ve vozech zadavatele instalována. Upraví zadavatel toto prohlášení, aby odpovídalo skutečnému stavu? DOTAZ 2) Žádáme o upřesnění, jakým způsobem bude probíhat zkušební provoz nového systému, když má uchazeč garantovat zachování funkčnosti stávajícího palubního počítače BS100, který by ale měl být v novém systému nahrazen základní řídící jednotkou EOS? 1) Řídící jednotka ZJ 01 je zařízení, které posílá informace do validátorů ve vozech, tedy se jedná o pomocné zařízení zajišťující informace od palubního počítače přes toto zařízení do validátoru. Dnes už by to mělo vše fungovat napřímo i bez tohoto zařízení. Dalo by se upravit, že bylo míněno, že tato jednotka bude nahrazena inteligentní základní řídící jednotkou EOS, a proto není uvedena samostatně v rozmístění komponentů odbavovacího zařízení ve vozidlech MHD. 2) Způsob zkušebního provozu navrhne uchazeč, je to plně v jeho kompetenci. 28. Příloha č. 3 Zadávací dokumentace Smlouva o dílo - str. 10, čl. XI. Prohlášení zhotovitele 2) Objednatel výslovně požaduje, že zhotovitel musí čestným prohlášením garantovat zachování funkčnosti těchto zařízení v novém systému. Po přechodné období (v době montážních prací, instalaci nového systému a zkušebního provozu) musí být zajištěno odbavení cestujících stávajícími papírovými jízdenkami o šíři 34 mm na zařízení NJ 24C. DOTAZ 1) Při prohlídce místa plnění nám bylo sděleno, že nový odbavovací systém by měl být instalován na tyče a v prostorech u řidiče, kde jsou nyní umístěna zařízení NJ 24C. Žádáme o potvrzení této informace a zároveň o upřesnění, jakým způsobem bude probíhat

11 11 zkušební provoz, když má být zároveň zajištěno odbavení cestujících stávajícími papírovými jízdenkami o šíři 34 mm na zařízení NJ 24C a přitom bez demontáže těchto zařízení není prostor, kam by bylo možné nová zařízení instalovat? DOTAZ 2) Připouští zadavatel možnost, aby zhotovitel při montáži zařízení NJ 24C demontoval, za předpokladu, že nově instalovaná zařízení umožní odbavení cestujících stávajícími papírovými jízdenkami o šíři 34 mm? 1) Způsob zkušebního provozu navrhne uchazeč, je to plně v jeho kompetenci. 2) Způsob zkušebního provozu navrhne uchazeč, je to plně v jeho kompetenci. S pozdravem Ing. Eva Šartnerová vedoucí Odboru rozvoje města Magistrátu města Ústí nad Labem