Smlouvy.gov.cz



Zadavatel:KORDIS JMK, a.s.Nové sady ?. 946/30, 602 00 BrnoI?: 26298465technická ?ást zadávací dokumentacena ve?ejnou zakázku ?Elektronické odbavování cestujících – fáze 1: Modernizace odbavovacích za?ízení v?regionálních autobusech “realizovanou v?rámci projektu ?Elektronické odbavování cestujících – fáze 1: Modernizace odbavovacích za?ízení v?regionálních autobusech“PreambuleTato zadávací dokumentace je vypracována jako podklad pro podání nabídek uchaze?? v?rámci zadávacího ?ízení na dodávky zadávaného v otev?eném ?ízení ve smyslu § 56 zákona ?.?134/2016 Sb., o zadávání ve?ejn?ch zakázek (dále jen ?zákon“).Práva, povinnosti ?i podmínky v této dokumentaci neuvedené se ?ídí tímto zákonem.424497517653000Obsah TOC \o "1-3" \h \z \u 2?VOD PAGEREF _Toc492555676 \h 33VYSV?TLEN? POJM? A ZKRATEK V?ZAD?VAC? DOKUMENTACI PAGEREF _Toc492555677 \h 44OBSLU?N? SPECIFIKACE A ?E?EN? TERMIN?LU ?IDI?E OIS PAGEREF _Toc492555678 \h 54.1ODBAVOVAC? ??ST - po?Adavky na funk?nost PAGEREF _Toc492555679 \h 64.1.1Evidence a p?ihla?ování ?idi?? PAGEREF _Toc492555680 \h 64.1.2Otev?ení odpo?tu PAGEREF _Toc492555681 \h 64.1.3Ukon?ení odpo?tu PAGEREF _Toc492555682 \h 74.1.4St?ídání směny PAGEREF _Toc492555683 \h 74.1.5Turnusy na linkách v IDS JMK PAGEREF _Toc492555684 \h 74.1.6Turnusy mimo linky?IDS JMK PAGEREF _Toc492555685 \h 74.1.7Slu?ební jízda PAGEREF _Toc492555686 \h 84.1.8Odbavování cestujících PAGEREF _Toc492555687 \h 84.1.9Volba tarifu PAGEREF _Toc492555688 \h 84.1.10Volba měny a zp?sobu platby PAGEREF _Toc492555689 \h 94.1.11Jízdní doklady a jízda dle linkospoje PAGEREF _Toc492555690 \h 94.1.12Jízdní doklady a jízda dle manuálního re?imu PAGEREF _Toc492555691 \h 94.1.13Volba v?chozí a cílové zastávky na linkospoji PAGEREF _Toc492555692 \h 94.1.14Volba v?chozí zastávky pro p?estup PAGEREF _Toc492555693 \h 104.1.15Systémové jízdní doklady PAGEREF _Toc492555694 \h 104.1.16Multilístek PAGEREF _Toc492555695 \h 104.1.17Storno PAGEREF _Toc492555696 \h 104.1.18Storno jízdního dokladu PAGEREF _Toc492555697 \h 114.1.19Manipulace PAGEREF _Toc492555698 \h 114.2INFORMA?N? ??ST - po?adavky na funk?nost PAGEREF _Toc492555699 \h 124.2.1Zadání hlasového upozornění ?idi?em PAGEREF _Toc492555700 \h 124.2.2Zadávání dopravních a reklamních informací LCD PAGEREF _Toc492555701 \h 124.2.3Zadávání mimo?ádn?ch informací dispe?erem CED PAGEREF _Toc492555702 \h 124.2.4Zadávání v?lukov?ch informací PAGEREF _Toc492555703 \h 124.2.5Zobrazení okolních vozidel na LCD ?idi?e PAGEREF _Toc492555704 \h 124.2.6Spoje na zavolání PAGEREF _Toc492555705 \h 124.2.7Modul bezpe?nosti ?idi?e PAGEREF _Toc492555706 \h 134.3??D?C? ??ST PAGEREF _Toc492555707 \h 134.3.1Personifikace dopravce PAGEREF _Toc492555708 \h 134.4Komunika?ní ?ást PAGEREF _Toc492555709 \h 134.4.1Modul komunikace s?dispe?inkem CED (MSP) PAGEREF _Toc492555710 \h 134.4.2Modul preference pr?jezd? k?i?ovatek SSZ PAGEREF _Toc492555711 \h 145TECHNICK? SPECIFIKACE A ?E?EN? TERMIN?LU ?IDI?E OIS PAGEREF _Toc492555712 \h 145.1Mechanické provedení PAGEREF _Toc492555713 \h 145.2Definice HW A SW, PP OIS PAGEREF _Toc492555714 \h 145.3Po?adavky na operace bankovních a dal?ích bezkontaktních karet s?DZC PAGEREF _Toc492555715 \h 175.4Po?adavky na SW pro odbavování cestujících PAGEREF _Toc492555716 \h 205.5maximální doby pot?ebné na zobrazení platnosti jízdenky PAGEREF _Toc492555717 \h 215.6PO?ADAVKY NA TOKENIZACI BEZKONTAKTN?CH BANKOVN?CH KARET PAGEREF _Toc492555718 \h 216SPECIFIKACE A ?E?EN? OBSLU?N?HO SOFTWARE a hardware – ?BACK OFFICE“ A KOMUNIKACE PAGEREF _Toc492555719 \h 236.1Stru?n? popis stávající infrastruktury zadavatele PAGEREF _Toc492555720 \h 236.2SOFTWAROV? ?E?EN? PAGEREF _Toc492555721 \h 236.2.1Charakteristiky systému PAGEREF _Toc492555722 \h 246.2.2Zabezpe?ení systému PAGEREF _Toc492555723 \h 246.2.3Identifikace a autentizace u?ivatel? PAGEREF _Toc492555724 \h 246.2.4Oprávnění u?ivatel? PAGEREF _Toc492555725 \h 256.2.5Evidence událostí v?systému PAGEREF _Toc492555726 \h 256.2.6Datové centrum PAGEREF _Toc492555727 \h 256.3KOMUNIKACE – ZP?SOB P?ED?V?N? INFORMAC? Z?SW-BO NA PP OIS PAGEREF _Toc492555728 \h 256.3.1Stahování soubor? z?vozidel PAGEREF _Toc492555729 \h 256.3.2Nahrávání soubor? do vozidel PAGEREF _Toc492555730 \h 266.4HARDWAROV? ?E?EN? PRO SW-BO PAGEREF _Toc492555731 \h 266.4.1Po?adavky na dodávan? HW PAGEREF _Toc492555732 \h 266.4.2Disková kapacita PAGEREF _Toc492555733 \h 266.4.3UPS PAGEREF _Toc492555734 \h 276.4.4Opera?ní systém server? PAGEREF _Toc492555735 \h 277SPR?VA SYST?MU OIS V SW-BO PAGEREF _Toc492555736 \h 277.1Správa dopravních systém? PAGEREF _Toc492555737 \h 287.2Evidence za?ízení PP-OIS PAGEREF _Toc492555738 \h 287.3Evidence ?idi?? PAGEREF _Toc492555739 \h 288správa ?íselník? Tarif? a tarifní politiky PAGEREF _Toc492555740 \h 288.1P??PRAVA DAT SKUPINY TARIF? PAGEREF _Toc492555741 \h 288.2Tiskové formulá?e PAGEREF _Toc492555742 \h 298.3Jízdní ?ády, turnusy PAGEREF _Toc492555743 \h 298.4Kalendá? spoj? PAGEREF _Toc492555744 \h 298.5Slevy pro data ze za?ízení PAGEREF _Toc492555745 \h 308.6Správa karet PAGEREF _Toc492555746 \h 308.7Generování a zpracování dat PAGEREF _Toc492555747 \h 309správa ?íselník? Hlá?ení a tabel PAGEREF _Toc492555748 \h 319.1Hlási?e PAGEREF _Toc492555749 \h 319.2Tabla PAGEREF _Toc492555750 \h 319.3Doplňkové informace cestujícím PAGEREF _Toc492555751 \h 3110ZKU?EBN? PRACOVI?T? PAGEREF _Toc492555752 \h 3111?KOLEN? A ZAJI?T?N? PODPORY PAGEREF _Toc492555753 \h 3312 KOMUNIKA?N? PROTOKOLY, DIAGRAMY, DEFINICE P??SLU?N?CH SOUBOR? A GRAFICK? VZHLED PAGEREF _Toc492555754 \h 3412.1VSTUPN? SOUBOR TARIFU A J?ZDN?CH ??D? LIK PAGEREF _Toc492555755 \h 3512.1.1Zastávky PAGEREF _Toc492555756 \h 3512.1.2Informace o linkospojích PAGEREF _Toc492555757 \h 3512.1.3Jízdní ?ád PAGEREF _Toc492555758 \h 3512.1.4Tarif PAGEREF _Toc492555759 \h 3512.1.5Relace hlási? PAGEREF _Toc492555760 \h 3612.1.6Informace ?idi? PAGEREF _Toc492555761 \h 3612.1.7Informace cestující PAGEREF _Toc492555762 \h 3612.1.8Informace o p?estupu PAGEREF _Toc492555763 \h 3612.1.9Informace o návaznosti PAGEREF _Toc492555764 \h 3612.2KOMUNIKA?N? PROTOKOL MODULU MSP PAGEREF _Toc492555765 \h 3612.2.1Obecná struktura rámce zprávy PAGEREF _Toc492555766 \h 3612.2.2Podrobn? popis jednotliv?ch zpráv PAGEREF _Toc492555767 \h 3712.2.3Stavové informace PAGEREF _Toc492555768 \h 3712.2.4Periodicky zasílaná zpráva o poloze vozu PAGEREF _Toc492555769 \h 3812.2.5Odjezd ze zastávky PAGEREF _Toc492555770 \h 3912.2.6P?íjezd do zastávky PAGEREF _Toc492555771 \h 4112.2.7P?ihlá?ení vozidla do IDS PAGEREF _Toc492555772 \h 4212.2.8Odhlá?ení vozidla od IDS PAGEREF _Toc492555773 \h 4312.2.9Zadání/akceptování ?ísla linky a spoje PAGEREF _Toc492555774 \h 4412.2.10Kódové zpráva z?vozidla PAGEREF _Toc492555775 \h 4512.2.11?ádost o zaslání p?ihla?ovacích údaj? PAGEREF _Toc492555776 \h 4612.2.12Textová zpráva do vozidla PAGEREF _Toc492555777 \h 4612.2.13Seznam linkospoj? PAGEREF _Toc492555778 \h 4712.3?ASOV? OSA J?ZDY LINKOSPOJE S?VLIVEM NA PERIFERIE PAGEREF _Toc492555779 \h 4912.4GRAFICK? N?VRHY OBRAZOVEK A J?ZDN?CH DOKLAD? PAGEREF _Toc492555780 \h 5012.4.1LCD pro cestující PAGEREF _Toc492555781 \h 5012.4.2Vnit?ní LED a venkovní tabla PAGEREF _Toc492555782 \h 5112.4.3Rozvr?ení LCD pro ?idi?e PAGEREF _Toc492555783 \h 5212.4.4Vzor jízdního dokladu IDS JMK PAGEREF _Toc492555784 \h 53?VODPod pojmem ?Elektronick? odbavovací a informa?ní systém pro vozidla v?Integrovaném dopravním systému Jihomoravského kraje“ (dále jen OIS) se rozumí za?ízení pro organizaci nástupu v?etně lidské kontroly zaji??ující dodr?ování tarifních podmínek, v?dej a ozna?ování jednotliv?ch jízdenek v?systému Integrovaného dopravního systému Jihomoravského kraje (dále jen IDS JMK), za?ízení a principy pro komunikaci s?Centrálním dispe?inkem koordinátora IDS JMK (dále jen CED), komunikace s?informa?ními periferiemi pro cestující ve vozidle (dále jen tabla), komunikace s?obslu?n?m software - BackOffice pro OIS, postup? a princip? správy dat pro OIS (dále jen SW-BO).Cílem obnovy OIS je komplexní v?měna stávajícího ?e?ení OIS v?IDS JMK, jen? se skládá v?p?evá?né ?ásti ze?za?ízení Mikroelektronika USVC, napojené na r?zná tabla, hlási?e zastávek, LCD obrazovky ve vozidlech, ozna?ova?e jízdenek, p?ijíma?e povel? od nevidom?ch a podobně. Obnova se bude t?kat v?ech terminál? OIS pro ?idi?e v?jednotliv?ch vozidlech standard? IDS 1, IDS 2 a IDS 3 dle Technicko-provozních standard? IDS JMK (TPS). Obslu?ného SW-BO v?etně hardwarového vybavení v sídle spole?nosti KORDIS JMK, a.s. (koordinátora IDS JMK), nastavení propojení se softwarem CED pro informování cestujících a komunikaci ?idi?? a dispe?er? CED. Zaji?tění testovacích pracovi?? a ?kolení. VYSV?TLEN? POJM? A ZKRATEK V?ZAD?VAC? DOKUMENTACI2D -?2D kód té? zvan? jako Maticov? kód (Matrix code), zahrnuje jak QR kód tak i Aztec kód.ACK-?kladné potvrzení správně p?ijaté zprávyAGM-?automaticky generované zprávy zasílané od dispe?inku (automatic generated messages)APN-?jméno p?ístupového bodu (Access Point Name) API- zkratka pro?Application Programming Interface p?edev?ím pro CED, její? popis je a pro Chaps elektronick? odbavovací a informa?ní systém pro vozidla v?IDS JMK (globálně)B?K- bezkontaktní ?ipová kartaCAN- vozidlová ?ídící sběrnice (Controller area network)CED- centrální dispe?ink integrovaného dopravního systémuCIS- centrální informa?ní systém jízdních ?ád? (cisjr.cz)CSV- jednoduch? souborov? formát ur?en? pro v?měnu dat (comma-separated values)DZC- dopravní zú?tovací centrumEP- elektronická peně?enka v?B?KEMV- bezkontaktní ?te?ka, odbavení, transakce bezkontaktní bankovní kartou (Europay, MasterCard a?Visa), s?Off-line i On-line transakcemi do 500 K?, bez zadání tzv. PINuGIS- grafick? informa?ní systémGPRS- Slu?ba radiového p?enosu paket? v?rámci GSM (General Packet Radio Service)GPS- p?ijímací systém na ur?ení polohy objektu (Global Position System), v?p?ípadech kde se hovo?í o GPS, rozumí se tím pozi?ní a naviga?ní informace zji?těné jak ze systému GPS, tak ze systému Galileo.GNSS- globální naviga?ní satelitní systém (zahrnující systémy GPS a Galileo).GSM- digitální globální komunika?ní pro mobilní komunikaciID- identifikátorIDS JMK- Integrovan? dopravní systém Jihomoravského kraje IDS- Integrovan? dopravní systém (obecně)IMEI-?mezinárodní identifikátor mobilního za?ízení (International Mobile Equipment Identity) - unikátní ?íslo GSM/GPRS/UMTS/LTE modemu p?idělené v?robcem.JDF- jednotn? datov? formát () LCD- displej z?tekut?ch krystal? (Liquid Crystal Display)LED - světlo vyza?ující dioda (Light-Emitting Diode)LTE - technologie ur?ená pro vysokorychlostní Internet v mobilních sítích (Long Term Evolution)?MHD- Městská hromadná dopravaMP3- formát ztrátové komprese zvukov?ch soubor? zalo?eny na psychoakustickém modeluNFC- Near Field Communication technologie, umo?ňující pomocí chytr?ch telefon? a dal?ích za?ízení komunikovat s jin?mi za?ízenímiOff-line - re?im bez spojení následně zpracovávající data získaná z?provozuOn-line - re?im p?ímého p?ístupu ?i re?im p?ímé komunikace KORDIS - servisní organizace Jihomoravského kraje a města Brna pro oblast dopravyPP- palubní po?íta? umístěn? ve vozidleRBP- rozhraní pro bankovní platbySW-BO - obslu?n? software - BackOffice pro OISTCP - Transportní protokol zaji??ující spolehlivé spojení mezi koncov?mi body komunikaceTPS- Technické a provozní standardy IDS JMK ()UDP - komunika?ní protokol transportní úrovně (User Data Protokol)UMTS- Universální mobilní komunika?ní systémVLD- Ve?ejná linková dopravaV?J- vozidlová ?ídicí jednotkaXML- jazyk ur?en? pro v?měnu dat mezi aplikacemi, kter? popisuje strukturu obsahu datOBSLU?N? SPECIFIKACE A ?E?EN? TERMIN?LU ?IDI?E OISNov? zp?sob vybavení vozidla ji? stírá rozdíl mezi informa?ním a odbavovacím systémem a nově integruje komunika?ní schopnosti. Proto musí b?t jádrem systému univerzální palubní po?íta? (PP) – někdy naz?van? jako ?ídicí jednotka vozidla (V?J), kter? realizuje funkce:Odbavovací – ?innosti spojené s?placenou p?rma?ní – hlá?ení pro cestující i ?idi?e, optické informace pro cestující, reklama.?ídicí – ?innosti spojené se sledováním stavu OIS a p?ípadně i vozidla.Komunika?ní – komunikace vozidla s?okolím, zejména s?centrálním dispe?inkem (datové a hlasové).ODBAVOVAC? ??ST - po?Adavky na funk?nostV?následujícím textu je uveden popis stávajícího zp?sobu odbavení v?IDS JMK. Dodávané PP OIS musí b?t konstruováno tak, aby byly principy odbavení shodné. V?IDS JMK dle TPS se provádí odbavení bu? v?hotovosti (v?dy vydá papírovou jízdenku), platba kartou (v?dy vydá papírovou jízdenku – pou?ito zatím pouze u někter?ch ?mal?ch“ městsk?ch doprav, bezhotovostní platba EMV v?dy vydá papírovou jízdenku), nebo ?asov?m kupónem (na papíru, kartě ?i 2D kódu bez vydání jízdenky z OIS). Nástup pouze p?edními dve?mi. Kontrolu provádí ?idi?.?idi? p?i za?átku jízdy aktivuje tla?ítkem PP OIS. P?ed zahájením obsluhy za?ízení se musí ?idi? k?za?ízení p?ihlásit. P?ihla?ování se provádí pomocí identifika?ního ?ísla (ID ?idi?e) a obvykle 4místného PIN kódu (v za?ízení PP OIS musí b?t pou?it 6místn? kód). Ka?dé za?ízení PP OIS musí mít ve své paměti ulo?en seznam osob, které se mohou k?danému za?ízení p?ihlásit. Tento seznam musí b?t mo?né dálkové aktualizovat. Ukon?ení obsluhy za?ízení je provedeno odhlá?ením obsluhy od za?ízení.Evidence a p?ihla?ování ?idi??PP OIS a SW-BO musí umo?ňovat centrální vedení evidence ?idi?? a dal?ích správc? PP OIS – nap?. administrátor?, revizor?…. P?ihla?ování musí b?t mo?né jak manuálně klávesnicí tak prost?ednictvím ?te?ky karet. Evidenci ?idi?? a dal?ích správc? PP OIS musí b?t mo?né spravovat v?SW-BO a na?ítat z?externích soubor? standardu CSV a automaticky tato data v?etně ?ísel p?ístupov?ch karet p?ená?et do PP OIS. Více dle ?l. REF _Ref474698038 \r \h \* MERGEFORMAT 8.Otev?ení odpo?tuP?ed vyjetím vozidla musí ?idi? provést otev?ení odpo?tu. Tím dojde k vyti?tění po?áte?ního lístku a vstupu do re?imu odbavování. Bez otev?ení odpo?tu není mo?né odbavovat cestující.P?ed otev?ením odpo?tu musí mít ?idi? v menu otev?ení odpo?tu mo?nost provádět následující akce:zadat turnus p?ípadně ?innost v rámci vybraného turnusu,nastavit ?íslo linky a spoje (pokud není vybrán turnus),nastavit aktuální (v?chozí) zastávku na aktuálním linkospoji,nastavit papír v tiskárněNásledně za?ízení PP OIS nabídne ?idi?i v menu otev?ení odpo?tu mo?nost provést otev?ení odpo?tu.Během otev?eného odpo?tu musí mít ?idi? mo?nost provádět následující akce:odbavovat cestující,manuálně měnit aktuální zastávku na aktuálním linkospoji dle pr?běhu jízdy,vybrat turnus p?ípadně ?innost v rámci vybraného turnusu,nastavit ?íslo linky a spoje (pokud není vybrán turnus),nastavit aktuální zastávku na aktuálním linkospoji,tisknout lístky (zpo?děnka, jízdní ?ád, pr?bě?ná uzávěrka, kumulované údaje, apod.) a nastavit papír v tiskárně (posun papíru, o?ez papíru, apod.),provádět ostatní operace související s provozem vozidla a za?ízeníměnit nastavení za?ízení PP OIS (hlasitost tla?ítek, hlasitost upozornění, návratov? tarif, návratové zastávky, apod.),nastavit papír v tiskárně,uzamknout za?ízení,uzav?ít odpo?et,a dal?í provozní funkcionality.Ukon?ení odpo?tuPo ukon?ení jízdy musí za?ízení ?idi?i umo?nit uzav?ení odpo?tu. Uzav?ením odpo?tu dojde automaticky k odhlá?ení ?idi?e a p?ipraví se v?stupní data, obsahující data o proveden?ch transakcích během daného odpo?tu, které jsou následně p?eneseny do SW-BO systému, kde jsou tato data dále zpracovávána.St?ídání směnyPo ukon?ení ?idi?ovi směny (st?ídání na trase), musí PP OIS umo?nit ?idi?i provést uzav?ení odpo?tu bez ukon?ení turnusu respektive linkospoje a s?tím i související komunikace na CED a informace na tabla. Uzav?ením odpo?tu dojde automaticky k odhlá?ení ?idi?e a p?ipraví se v?stupní data, obsahující data o proveden?ch transakcích během daného odpo?tu, které je mo?né následně p?enést do SW-BO systému, kde jsou tato data dále zpracovávána.Turnusy na linkách v IDS JMKZa?ízení PP OIS musí umo?nit ?idi?i jezdit v?IDS JMK dle turnus? zadáním tzv. kurzového ?ísla, jen? na základě komunika?ního protokolu s?CED se sestaví v?PP OIS s?Off-line dat o linkách a linkospojích turnus. Turnus je definován jako seznam ?inností, které musí ?idi? vykonat během daného turnusu. V turnusu je mo?né definovat následující základní typy ?inností:za?átek turnusu,konec turnusu,linkospoj turnusu,slu?ební jízda.?innost typu slu?ební jízda musí b?t dále mo?né vyu?ívat v?PP OIS pro definici dal?ích ?inností v turnusu, jako nap?íklad P?istavení vozidla, Odstavení vozidla, P?ejezd, Bezpe?nostní p?estávka, Nocování, P?eru?ení, P?estávka na jídlo, apod., kde konkrétní ?innost je definována textov?m popisem slu?ební ?innosti.Kromě v??e uvedeného seznamu ?inností musí b?t mo?né pro dan? turnus definovat tzv. informace v turnusu. Informace v turnusu je seznam textov?ch informací, kde ka?dá textová informace má definovan? ?as, kdy se má v rámci daného turnusu zobrazit ?idi?i na displeji za?ízení PP OIS.Turnusy mimo linky?IDS JMKZa?ízení PP OIS musí ?idi?i umo?nit jezdit dle turnus? definovaného dopravcem. Turnus je definován jako seznam ?inností, které musí ?idi? vykonat během daného turnusu. V turnusu je mo?né definovat následující základní typy ?inností:za?átek turnusu,konec turnusu,linkospoj turnusu,slu?ební jízda.?innost typu slu?ební jízda musí umo?ňovat dal?í vyu?ití pro definici dal?ích ?inností v turnusu, jako nap?íklad P?istavení vozidla, Odstavení vozidla, P?ejezd, Bezpe?nostní p?estávka, Nocování, P?eru?ení, P?estávka na jídlo, apod., kde konkrétní ?innost je definována textov?m popisem slu?ební ?innosti.Kromě v??e uvedeného seznamu ?inností musí b?t mo?né pro dan? turnus definovat tzv. informace v turnusu. Informace v turnusu je seznam textov?ch informací, kde ka?dá textová informace má definovan? ?as, kdy se má v rámci daného turnusu zobrazit ?idi?i na displeji za?ízení PP OIS.Slu?ební jízdaPokud je na za?ízení PP OIS aktuální ?innost turnusu typu za?átek turnusu nebo slu?ební jízda nebo konec turnusu, tak nesmí b?t mo?né odbavovat cestující. V tomto p?ípadě za?ízení PP OIS místo do re?im? pro v?dej jízdních doklad? p?echází do re?imu slu?ební jízdy.Odbavování cestujícíchZa?ízení PP OIS musí umo?nit v?dej a odbavování ?iroké ?kály papírov?ch jízdních doklad?, jejich? vlastnosti vycházejí z definice parametr? tarif?, které musí b?t mo?né u?ivatelsky konfigurovat pomocí vstupních dat pro za?ízení. Musí umo?nit vydání minimálně 200 druh? jízdenek IDS JMK.Za?ízení PP OIS musí umo?ňovat v?dej a odbavování jízdních doklad? nejenom v rámci dopravního systému (IDS JMK), do kterého pat?í (kter? obsluhuje primárně), ale také v rámci okolních dopravních systém?. Jednotlivé podporované dopravní systémy mohou mít r?zné tarify, metody v?po?tu cen jízdného a odli?n? vzhled jízdních doklad?. Podpora více dopravních systém? také zahrnuje podporu pro v?dej a odbavování jízdních doklad? pro jízdy mezi r?zn?mi dopravními systémy. P?i jízdě z jednoho dopravního systému do druhého dopravního systému musí pro ka?d? dopravní systém vydat jeden jízdní doklad (lomen? tarif), kter? musí b?t vydán dle metody v?po?tu cen jízdného v daném tarifu pro dan? dopravní systém nebo je mo?né nap?íklad (jsou mo?né r?zné kombinace) vydat pouze jeden jízdní doklad, kter? bude vydán dle definované metody v?po?tu cen jízdného v daném tarifu (m??e b?t odli?n? od v?ech metod v?po?tu cen jízdného v ostatních dopravních systémech). Podpora více dopravních systému musí b?t u?ivatelsky konfigurovatelná pomocí vstupních dat pro za?ízení.Volba tarifuZa?ízení PP OIS musí ?idi?i umo?nit v?běr z mno?ství tarif?, jejich? nabídka musí b?t p?ehledně zobrazena na displeji za?ízení. Jednotlivé tarify musí b?t rozděleny do skupin tarif?. ?idi? vybírá skupinu tarif? z nabídky na displeji a v rámci ka?dé skupiny tarif? vybírá po?adovan? tarif. Rozdělení tarif? do skupin tarif? a po?adí tarif? v nabídce tarif? v rámci dané skupiny tarif? musí b?t u?ivatelsky konfigurovatelné pomocí vstupních dat pro za?ízení.Volba měny a zp?sobu platbyZa?ízení PP OIS musí ?idi?i umo?nit rychl? v?běr měny, ve které bude dan? jízdní doklad placen. Nabídka měn je u?ivatelsky konfigurovatelná pomocí vstupních dat pro za?ízení. Za?ízení PP OIS musí umo?nit placení ve?ker?ch jízdních doklad? hotovostně a pomocí EMV ?i EP.Jízdní doklady a jízda dle linkospojeRe?im jízdy je ur?en pro v?dej jízdních doklad? dle linkospoje a je hlavním re?imem pro odbavování cestujících, a komunikaci s CED.Jízdní doklady a jízda dle manuálního re?imuManuální re?im musí umo?ňovat ?idi?i v?dej ur?it?ch p?edem stanoven?ch jízdních doklad? s?manuálním zadáním tarifní zóny, linky a spoje. Re?im je ur?en? pro zálo?ní vozy, je? zaji??ují náhradní dopravu na linkách, jen? za?ízení PP OIS nemá ve vstupních datech. Re?im musí umo?nit manuální zadání linky a cílov?ch informací na tabla pomocí alfanumerické klávesnice PP OIS.Volba v?chozí a cílové zastávky na linkospojiRe?im jízdy umo?ní ?idi?i provádět volbu v?chozí a cílové zastávky na aktuálním linkospoji, pro kter? je dan? jízdní doklad vydán. V závislosti na metodě v?po?tu ceny vybraného tarifu je trasa mezi v?chozí a cílovou zastávkou na daném linkospoji analyzována a získané údaje jsou pou?ity pro v?po?et ceny jízdného.Standardně ?idi? vybírá pouze cílovou zastávku na aktuálním linkospoji a jako v?chozí zastávka je automaticky pou?ita aktuální zastávka. Cílovou zastávku lze zvolit v?běrem ze seznamu zastávek ?i zadáním tarifního ?ísla zastávky, a to pouze zastávku následující za aktuální zastávkou na aktuálním linkospoji. Aktuální zastávku na aktuálním linkospoji musí b?t mo?né změnit následujícími zp?soby:Automaticky na základě vstupních dat jednotliv?ch zastávek – sloupk? a to tak, ?e p?i otev?ení / uzav?ení jak?koliv dve?í v?p?íslu?né zastávce a uvedení vozidla do pohybu (změna sou?adnic o cca 50 metr?), dojde k?posunu zastávky na p?í?tí dle linkospoje. V?p?ípadě pr?jezdu bez zastavení na základě opu?tění sou?adnicového radiusu cca 250 metr?. Tento zp?sob změny aktuální zastávky se vyu?ije standardně dle pr?běhu jízdy.Vyhrazen?m tla?ítkem v re?imu jízdy, a to o jednu zastávku vp?ed ve směru jízdy ?i o jednu zastávku vzad dle aktuálního linkospoje.V menu otev?ení odpo?tu ?i v menu manipulace. Tento zp?sob změny aktuální zastávky se pou?ívá ve v?jime?n?ch p?ípadech, nap?íklad pokud je pot?eba zahájit jízdu na jiné ne? po?áte?ní zastávce daného linkospoje.V?p?ípadě, ?e vozidlo jede po jiné trase, nabízí vozidlo ?idi?i nejbli??í zastávku dle seznamu zastávek IDS JMK dle GPS.Volba v?chozí zastávky pro p?estupRe?im p?estupu, kter? je dostupn? z re?imu jízdy, musí ?idi?i umo?nit zvolit konkrétní jízdenku dle tarifu IDS JMK jen? je v?hradně p?estupní. Musí b?t mo?né jej zadat p?edev?ím z?linkospoj? je? mají nap?íklad obrat s?cestujícími.Systémové jízdní dokladyRe?im systémové jízdenky je ur?en pro v?dej systémov?ch jízdních doklad? a je doplňkov?m re?imem pro odbavování cestujících.Re?im systémové jízdenky musí ?idi?i umo?nit vydávat systémové jízdní doklady s libovolnou územní platností v daném dopravním systému, a to nezávisle na aktuálním linkospoji. Musí b?t umo?něno definování územní platnosti r?zn?mi zp?soby, jako nap?íklad zóny.Re?im systémové jízdenky musí umo?nit následující zp?soby zadávání územní platnosti:V??et zónTento zp?sob zadávání územní platnosti umo?ňuje zadat v??et zón.Zóny je mo?né vybrat ze seznamu zón ?i zadáním ?ísla zóny pro dan? dopravní systém.?asové omezení, typicky 24 hodinové, měsí?ní, ?tvrtletní atd.Pomocí API rozhraní spole?nosti CHAPS ?i server? t?etích stran, jen? umo?ní on-line vyhledání spojení na základě zadané ?idi?em v?chozí a cílové zastávky v?územní platnosti (datovém balíku CHAPS ?i server? t?etích stran, p?edev?ím v?IDSJMK), s?v?slednou cenou v?základním tarifu. P?epo?et na zlevněné a podobně bude provádět PP OIS sám. Vyhledané spojení musí b?t mo?né vytisknout k?jízdence pro cestujícího. Tyto vyhledané relace p?es API musí b?t logovány s?mo?ností následné editace v?SW-BO a p?enos? do v?ech ostatních PP OIS. Bude se jednat o tzv. U?ící re?im, kdy jednou vyhledané spojení p?es API bude nabídnuto podruhé off line re?imu, ji? z?těchto log? nap?í? v?emi PP OIS.MultilístekRe?im multilístku musí ?idi?i umo?nit v?dej několika jízdních doklad? pro více spolucestujících najednou. Vydan? jízdní doklad je tzv. multilístek, kter? v p?ípadě papírového jízdního dokladu m??e b?t zkrácen? ?i nezkrácen?. Jednotliví spolucestující v rámci jednoho multilístku mohou b?t odbavení v r?zn?ch tarifech. V?dej multilístku musí b?t mo?no u?ivatelsky konfigurovat pomocí vstupních dat pro za?ízení.StornoZa?ízení PP OIS musí umo?nit storno provedené transakce. Storno provedené transakce musí b?t mo?né provést v?centrálně u?ivatelsky definovaném ?asovém intervalu od doby provedení transakce. V?p?ípadě bezhotovostní transakce EMV ?i EP musí b?t pou?ita pro identifikaci p?íslu?ná karta. Po provedení storna je automaticky vyti?těn doklad o provedení storna. Nastavení ?asového intervalu a zp?sobu storna musí b?t mo?no u?ivatelsky konfigurovat pomocí vstupních dat pro za?ízení.Storno jízdního dokladuP?i stornu jízdního dokladu musí mít ?idi? mo?nost vybrat ?íslo stornovaného dokladu ze seznamu ?ísel doklad?, které je mo?né stornovat. K vybranému dokladu musí b?t zobrazeny podrobněj?í informace o jízdním dokladu (?íslo jízdenky/jízdenek, ?as v?deje jízdního dokladu, cena jízdního dokladu, název tarifu jízdního dokladu, apod.). Provádění storna jízdních doklad? je mo?né povolit/zakázat/zabezpe?it PIN kódem na úrovni administrace p?ístupov?ch práv ?idi??.ManipulaceBěhem otev?eného odpo?tu musí mít ?idi? p?ístup do menu manipulace. V menu manipulace musí mít ?idi? mo?nost konfigurovat za?ízení PP OIS ?i p?istupovat k dal?ím funkcím souvisejícím s provozem za?ízení PP OIS a vozidla. Během otev?eného odpo?tu musí mít ?idi? mo?nost v menu manipulace provádět p?edev?ím následující akce:změnit turnus p?ípadně ?innost v rámci vybraného turnusu,změnit ?íslo linky a spoje (pokud není vybrán turnus),změnit aktuální (v?chozí) zastávku na aktuálním linkospoji,uzamknout za?ízení PP OIS,uzav?ít odpo?et (uzav?ením odpo?tu dojde k odhlá?ení ?idi?e),p?echod do tzv. úsporného re?imu,tisknout:jízdní ?ád,v??etka,zpo?děnka,pr?bě?ná uzávěrka,vydané jízdenky,stornované jízdenky,seznam linkospoj? v?turnus?,nastavit papír v tiskárně:posun papíru,o?ez papíru,konfigurovat odbavovací systém:návratov? tarif,návratová zastávka,konfigurovat za?ízení PP OIS:hlasitost tla?ítek,hlasitost upozornění,hlasitost buzení,nastavit budík:dan? ?as,po?et minut p?ed odjezdem,vypnuto,pou?ívat kalkula?ku,pou?ívat sou?et po?tu bankovek a mincí minimálně ve dvojí měně sou?asněINFORMA?N? ??ST - po?adavky na funk?nostPalubní po?íta? OIS musí umo?nit ?idi?i a dispe?er?m CED dálkově zasílat na koncové periferie PP OIS jako tabla a hlási? zastávek p?edem prefabrikované informace ?i mimo?ádné informace z?CED, nap?íklad o mimo?ádnosti na lince, zp?sobu p?epravy a podobně. PP OIS musí b?t obsahovat audio vizuální prost?edí pro sdělování informací jak k??idi?i, tak k?cestujícím ve voze i mimo něj (venkovní repro, tabla).Zadání hlasového upozornění ?idi?emP?es menu PP OIS v?otev?eném odpo?tu musí b?t rychlá volba informací v?prefabrikovaném formátu jak pro akustick? hlási? s?mo?ností směrování p?íslu?ného audio kanálu, tak informací pro vnit?ní tabla jak LED tak LCD. Prefabrikované informace pro ?idi?e musí b?t u?ivatelsky konfigurovatelná pomocí vstupních dat pro za?ízení. PP OIS musí umo?nit z?mikrofonu ?idi?e hlasově informovat cestující vně i venku vozu.Zadávání dopravních a reklamních informací LCDJe-li v?z dle TPS vybaven LCD tablem pro cestující musí PP OIS umo?nit p?ehrávání soubor? pro tyto tabla bez jakéhokoli vlivu ?idi?e. P?enos soubor? musí b?t u?ivatelsky konfigurovatelné pomocí vstupních dat pro za?ízení.Zadávání mimo?ádn?ch informací dispe?erem CEDPP OIS musí umo?nit zobrazení informace, kterou dispe?er pomocí SW CED ode?le pro ur?itou skupinu voz? (linek, oblastí), textovou ?i kódovou informaci pro LED a LCD tabla a akustick? hlási?, jen? se bezprost?edně po p?íjmu zobrazí. Informace ponese také ?as do kdy je mimo?ádnost platná.Zadávání v?lukov?ch informacíPP OIS musí umo?nit na základě vstupních dat zobrazit informace o plánovan?ch v?lukách, je? jsou o?ekávány na linkách jeho turnusu. Tyto informace mohou b?t jak textové, tak grafické formou obrázk?. Tyto informace mohou b?t ve verzi na LCD ?idi?e, tak ve verzi pro LCD tablo cestujícím. Informace ponesou také datové a ?asové razítko platnosti v?luky (od-do, dny, ?as). P?enos soubor? musí b?t u?ivatelsky konfigurovatelné pomocí vstupních dat pro za?ízení.Zobrazení okolních vozidel na LCD ?idi?ePP OIS musí umo?nit ?idi?i zobrazení na LCD ?idi?e okolních vozidel nad mapou. Volba vozidel ?i linek bude na základě vstupních dat o návaznostech linkospoje nebo ru?ním zadáním. P?enos informací o vozidlech bude na základě API rozhraní SW CEDu a mapového podkladu, jen? bude existovat v?off-line verzi v?PP OIS (cca 250MB), tak mo?nosti On-line otev?en?ch mapov?ch podklad? nap?íklad Google mapy.Spoje na zavoláníNa základě vstupních dat linkospoj? na zavolání musí PP OIS umo?nit ?idi?i jednoduché a intuitivní vyhledávání zastávky na zavolání (p?ímé ?i pomocí na?eptáva?e), nabídne mo?né spoje s jejich odjezdy a poté umo?ní zadat i datum po?adovaného spoje. Tato objednávka je zaslána na dispe?ink, p?íp. m??e b?t do 10 minut i stornována. Spoje na zavolání jsou samostatn?m vstupním souborem, jen? umo?ní ?idi??m takto objednat spoje i mimo jejich turnus ?i linkospoj. P?enos soubor? musí b?t u?ivatelsky konfigurovatelné pomocí vstupních dat pro za?ízení.Modul bezpe?nosti ?idi?eModul ?idi?i musí umo?nit v?p?ípadě nenadálé situace kontaktovat dispe?era CED a to pomocí extérního tla?ítka Emergency jen? ode?le informa?ní zprávu na CED a sou?asně volá na CED bez zapnutého poslechu ?idi?e. Za?ízení musí také umo?ňovat ?idi?i spustit nahrávání prostoru u ?idi?e do zvukov?ch formát? po p?edem stanovenou dobu a ty následně odeslat do SW-BO. P?ístup k?těmto soubor?m musí b?t zabezpe?en. Takov?to záznam m??e vyvolat jen administrátorem povolená obsluha SW-BO.??D?C? ??STPP OIS musí umo?ňovat On-line sledování jeho funkcí obsluze SW-BO, sdělovat p?ípadné mimo?ádnosti a nepovolené manipulace. Za provozní sledování se pova?uje bě?n? chod PP OIS a jeho periferií. ?ídící ?ást musí p?edev?ím umo?nit dohledu v?SW-BO vzdálené uzav?ení odpo?tu a kontrolu tr?eb, detekovat problémy na sběrnicích PP OIS, sledování nep?imě?ené vyu?ití storna (dle nastavení), detekovat fyzické odpojení reproduktor? ve vozidle, mo?nost vzdálené změny nastavovacích informací a p?edpis? PP OIS a HW klí?e OIS, a podobně. Personifikace dopravcePP OIS a SW-BO musí umo?nit personifikaci za?ízení tak, aby bylo mo?né konfigurovat PP OIS na jednotlivé dopravce a jejich specifika. P?edev?ím je tím my?leno mo?nost odpojení / vypnutí někter?ch modul? a funkcí PP OIS jako nap?íklad hlási? zastávek, IBIS sběrnice a podobně. Personifikace m??e b?t vzdálená i lokální na PP OIS pomocí servisní karty.Komunika?ní ?ástPP OIS musí umo?ňovat za pomocí mobilního p?ipojení, je? je specifikováno v?HW ?e?ení PP, komunikaci s?SW dispe?inku CED, SW-BO, ve?ejn?m internetem, DZC apod. Automatické vy?tení dat z pokladny se provádí denně pomocí GPRS/UMTS/LTE minimálně 1x za 24 hodin. Zpětně jsou do palubního po?íta?e nahrána data pot?ebná pro vněj?í i vnit?ní panely, digitální hlá?ení, blacklist, změny jízdních ?ád? a podobně. P?ípadně ostatní aktualizace (vy?ítání tachografu). Modul komunikace s?dispe?inkem CED (MSP)MSP (modul sledování polohy) je za?ízení, které odesílá informace o poloze vozidla na SW CED. MSP umí také komunikovat s?dispe?erem CED a ?idi?em a to pomocí zpráv (obdoba SMS na mobilním telefonu) a hlasově. Dispe?er na základě takto získan?ch dat m??e lokalizovat vozidlo s?p?esností na cca 5 m a ?ídit tak dopravu v?IDS JMK. Protokol je sou?ástí zadávací dokumentace. Modul musí umo?nit rychlou volbu komunikace s?dispe?erem CED a to textovou a hlasovou – telefonní hovor. Textové informace jsou p?edem prefabrikovány a jsou sou?ástí protokolu. Telefonní ?ísla, je? PP OIS umo?ní vytá?et, budou sou?ástí nastavovacích dat. PP OIS musí umo?nit p?íjem hovor? bez omezení. Modul preference pr?jezd? k?i?ovatek SSZPP OIS a SW-BO musí umo?nit p?ipojit, nastavit a provozovat extérní radiomodem (USB, RS 485), pro ?ízení preference světelného signaliza?ního za?ízení na k?i?ovatkách (SSZ). Tyto k?i?ovatky jsou vybaveny radiomodemem pro komunikaci s?vozidly na vyhrazené frekvenci v?pásmu 450 MHz nebo 170 MHz, pomocí protokol? firmy TAIT. Samotné radiomodemy nejsou sou?ástí zakázky.TECHNICK? SPECIFIKACE A ?E?EN? TERMIN?LU ?IDI?E OISU palubního po?íta?e OIS je nutno vlastnosti rozdělit na dvě základní ?ásti:Mechanické provedení a rozlo?ení prvk? ve vozidleDefinice HW a SW vlastnostiMechanické provedeníM??e b?t dvojího typu:Kompaktní varianta standardní – komplexní jednotka PP bude mechanicky spojena v?jeden celek. Dělená varianta – vyu?itelná pro zástavbu do vozidel s??achtou pro PP OIS v?palubní desce vozidla. Typicky jde o vozidla v?robce SOR. V?p?ípadě ?e?ení této koncepce je jejich vzájemné propojení povolené maximálně dvěma kabely s?minimální délkou 1,2m. Terminál pro cestující musí b?t v?provedení na madlo vozidla s?mo?ností upevnění na horizontální i vertikální madlo.Podmínkou uspo?ádání je snadná v?měna komponent? v?p?ípadě poruchy systému. Sou?ástí dodávky musí b?t i kovová zásuvka na peníze s?minimálně ?esti p?ihrádkami na mince a papírové bankovky (zásuvka nebo jednotlivé p?ihrádky musí b?t vyjmutelné), a s?mechanick?m uzam?ením 2ks klí?k?. Zásuvka musí b?t umístěna v samostatné sk?íni, na ní? bude PP OIS oddělitelně upevněn. Sk?íň zásuvky musí mít pro spojení s?vozidlem, dostate?n? po?et děr na ?ádné mechanické upevnění k?palubní desce. Celkové rozměry sk?íně zásuvky nesmí p?esáhnout rozměry základny 310 x 290 mm. Definice HW A SW, PP OISZ?hlediska dlouhodobého rozvoje systému v?IDS JMK, je nutno systém p?íslu?ně z?hlediska HW dimenzovat:Nízkop?íkonov? palubní po?íta? typu PC s?pevnou pamětí o kapacitě minimálně 32 GB (nap?. Compact flash, SD flash, SSD disk apod.), pamětí RAM DDR 1 GB, procesor (CPU) o taktovací frekvenci minimálně 1 GHz, minimálně jedno rozhraní typu Ethernet 10/100 MHz, minimálně 2x USB (z toho jedno snadno p?ístupné pro manuální aktualizaci dat pomocí USB Flash paměti). PP OIS musí mít diskrétní HW tla?ítko pro reset PP v?p?ípadě zaseknutí PP.Doba náběhu PP OIS od zapnutí napájení, k?provoznímu re?imu (obrazovka p?ihlá?ení ?idi?e), musí b?t maximálně do 1 minuty.HW vybavení PP OIS musí umo?nit archivaci minimálně 500 tisíc údaj? o cestujících, jejich nosi?ích jízdenek a k?nim p?idělen?ch jízdenkách obsahujících fotografie o velikosti 20 kB a dal?í údaje o velkosti do 20 kB pro ka?dého cestujícího (p?edplatní jízdenky). Dále musí vybavení PP OIS umo?nit archivaci údaj? o dal?ích minimálně 500 tisících jízdenkách a k?nim p?idělen?ch nosi?ích o velikosti 1 kB (jednorázové jízdenky). Doba pot?ebná na nalezení údaje v?databázi a zobrazení na displeji nesmí p?ekro?it 500 ms.Modem GSM/GPRS/UMTS/LTE a p?ijíma? GNSS se schopností p?íjmu systém? GPS a Galileo s?p?esností minimálně 3 m CEP (Circular Error Probable – Kru?nice stejné? pravděpodobnosti).SW ?i HW trojnásobn? nezávisl? digitální hlási? zastávek zalo?en? na MPEG3 pro hlá?ení do vozu, vně vozu a k ?idi?i. Systém musí umo?nit sou?asné r?zné hlá?ení do t?í směr?. Akustickou (digitální) úst?ednu se?vstupy od jednotného mikrofonu vozidla, modulu GSM, digitálních hlási?? a od zvukové karty. Musí obsahovat digitální zesilova?e s?v?konem minimálně 4W na jeden vnit?ní reproduktor vozidla, tj. minimálně 20W na vozidlo (pokud bude kloubové), 10W na vněj?í reproduktor, integrovan? reproduktor ?idi?e. V?e p?i 4 Ω reproduktorech. ?rovně hlasitosti jednotliv?ch kanál? hlási?e SW ?ízené, dle nastavovacího p?edpisu pro v?echny PP OIS s?vazbou na HW klí? vozidla.Elektronické spína?e napájení jednotliv?ch prvk? systému v?etně elektronické pojistky a mě?ení proud? a napětí jednotliv?ch větví (tabla, ozna?ova?e jízdenek apod.). Palubní po?íta? pomocí těchto spína?? zapíná tyto periferie, které jsou pro správnou funkci systému pot?eba. Relé pro spínání nejsou povolena z?d?vodu jejich omezené ?ivotnosti a zv??ené poruchovosti. Komunika?ní rozhraní vysokorychlostní WiFi 5,8 (2,4) GHz. Vysokorychlostní rozhraní WiFi bude ur?eno pro p?enos soubor? do a z?vozidel p?i stání ve vozovnách, v?re?imu jízdy s?cestujícími m??e slou?it k?p?ipojení cestujících k?Internetu – WiFi point, pro minimálně 30 sou?asně p?ipojen?ch za?ízení.PP OIS musí obsahovat sběrnice RS 485 a minimálně jedno rozhraní Ethernet (100 Mbit/s). Dal?ími rozhraními je 2x USB, CAN, IBIS - VDV300 (IBIS), resp. ?esk? standard IPIS a roz?í?ení firmy BUSE pro p?eprogramování tabel ?ady BS xxx rychlostí a? 19,2 kbit/s.Zaji?tění systému trvalého napájení PP OIS s?mo?ností nahrávání dat na vy?ádání z?SW-BO. PP OIS bude zapojen tak, aby byl na trvalém napájení vozidla (akumulátorech) a jeho klidová (úsporná), spot?eba musí b?t men?í ne? 400 mA. Tato spot?eba m??e b?t p?ekro?ena v?době dotazu na data, kter? je odesílán / p?ijímán na server SW-BO. P?echod do úsporného re?imu, bude po u?ivatelsky volitelné ?asové prodlevě, nebo na po?adavek ?idi?e.Jmenovité napájecí napětí PP OIS: + 24 V, pracovní napájecí napětí: +17 V?a? +32 V, jmenovit? proud max. 1A (nárazově p?i tisku jízdenky / hlá?ení max. 9A/24V).PP OIS musí mít zálohování proti krátkodob?m v?padk?m napájecího napětí p?i startu vozidla. Palubní po?íta? musí b?t odoln? proti změnám v?palubní síti vznikl?ch nap?. p?i startování vozidla zejména v?zimních měsících. PP OIS musí b?t vybaveno mo?ností úplného odpojení od palubního napájení bez ztráty ?i po?kození dat a to i v?p?ípadě náhlého odpojení od palubního napájení.Provozní teplota -20°C a? +50°C (dotykov? LCD po zah?átí na provozní teplotu 0°C a? +50°C). Musí dále splňovat provoz za relativní vlhkosti do 85% p?i +40?C, nekondenzující.dotykov? LCD terminál – minimálně 10“, svítivost LCD displeje min. 500 cd/m2 – podmínkou je dobrá viditelnost na p?ímém slunci, rozli?ení minimálně 800 x 600 v?provedení s?kapacitní dotykovou obrazovkou, sou?asn? dotyk minimálně dvou prst? pro tzv. zoom, s?krycím sklem o ?í?ce min. 2 mm. Min. 16mil. barev. Pokud bude systém obsahovat klávesy mimo obrazovku, pak tyto musí b?t podsvíceny pro lep?í orientaci ?idi?e v?no?ních hodinách (zapínání m??e b?t ru?ní ?i automatické).Terminál ?idi?e musí umo?ňovat snadn? p?echod mezi re?imy servis a vyhledání spoj?, obrazovkou jízdy, obrazovkou odbavení, obrazovkou komunikace s?dispe?inkem (za tímto ú?elem doporu?ujeme pomocnou klávesnici s?klávesy: servis, jízdní ?ády, komunikace s?dispe?inkem, odbavovací systém, apod.)Systém musí mít integrováno tla?ítko ?Emergency“ pro nouzové volání na dispe?ink ?i pro p?ípad napadení ?idi?e (terminál ?idi?e ?i ukryté v?kabině ?idi?e),Volitelná zvuková indikace ?stisknuté klávesy“ na terminálu,Automatická ?i ru?ní volitelnost jasu LCD displeje terminálu ?idi?e. Podmínkou vlastnosti SW palubního ?idi?e je automatické ztlumení jasu LCD terminálu ?spo?i?“ p?i jízdě mezi zastávkami.Terminál ?idi?e, kter? bude umístěn samostatně na palubní desce autobusu, bude mo?no natá?et dle pot?eby (toto neplatí u kompaktního ?e?ení).Terminál ?idi?e musí obsahovat mikrofon a reproduktor pro komunikaci ?idi?e s?dispe?erem. Tento mikrofon musí b?t pou?iteln? i pro hlá?ení od ?idi?e k?cestujícím ve vozidle i vně.Termo tiskárna lístk? s?o?ezáva?em – p?edpokládaná ?í?ka papíru je 80 mm. Rychlostí tisku minimálně 170 mm/s, podpora tisk? 2D kód?, ?árov?ch kód?, ?ivotnost tiskové hlavy a mechaniky minimálně 120 km, ?ivotnost o?ezu minimálně 1,2 mil. Musí b?t mo?né nastavit rozsah o?ezu jízdenky od úplného o?ezu a? po ?áste?n? o?ez. Papír pro termotiskárnu je následujících základních parametr?:?í?e kotou?e:80,0 mmVněj?í pr?měr kotou?e:max. 80,0 mmVnit?ní pr?měr dutinky:1 inch = 25,4 mmVněj?í pr?měr dutinky:28,70 mmMateriál dutinky:plastStrana ur?ená k?termotisku:vněj?íPlo?ná hmotnost papíru:70-80 g / m2Tlou??ka papíru: 75-90 mikrometr?Typ termocitlivého papíru pou?it? pro testování prototypu PP OIS bude JTK AP62KS-E, p?i?em? termo tiskárna musí umo?nit tisk na papír obdobn?ch hodnot nap?íklad: JTK AP62KJ-R nebo T 7034.Pomocn? LCD displej (zákaznick? terminál) cestujícího pro zobrazení v??e platby a dal?ích údaj? pro cestujícího, minimálně 3,5“ s?minimálním rozli?ením 320 × 240 bod?, Min. 256 barev.Kamera ?i ?te?ka se schopností v?denní i no?ní době rozpoznat 2D kódy (a to jak standard QR, tak i standard Aztec), elektronické jízdenky zobrazené na 2,3“ displeji telefonu stejně jako v ti?těné podobě s?rychlosti ost?ení do 0,5 s. Musí umo?nit ?íst a dekódovat 2D kód aplikace Poseidon s?vyhodnocením platnosti na LCD PP.Kombinovaná ?te?ka bezkontaktních bankovních platebních karet a bezkontaktních ?ipov?ch karet standardu MIFARE/DESfire. Podrobná specifikace je uvedena v?oddílech REF _Ref473355890 \r \h \* MERGEFORMAT 5.3 a 6. Základní kabelové propojení s HW klí?em (nejlépe v?konektoru), se specifikací vozidla, s?mo?ností zadání?registra?ní zna?ky (pomocí admin p?ístup? nebo servisní karty), anténní modul na st?echu vozidla cca 4m kabelovém svodu (GSM/GNSS), p?ípravou p?ipojení kabelá?e pro IBIS na stávající tabla a ozna?ova? jízdenek, p?ípravou pro analogové vstupy / v?stupy (repro, ex. tla?ítka, kontakty dve?í atd.) p?ípravou pro ethernet pro pou?ití propojení LCD tabel a p?ípadn?ch validátor? pro cestující.P?ijíma? nevidomého v?prostoru p?edního ?ela vozidla, m??e b?t extérní.Hlási? informací pro nevidomého pracující na základě stisku p?ijíma?e nevidomého pracujícího na frekvencích vyu?ívan?ch hlási?i nevidom?ch dle standard? SONS (Sjednocená organizace nevidom?ch a slabozrak?ch ?R).Mechanick?m zabezpe?ením proti ne?ádoucí manipulaci – plomba.Systém pro detekci za?ízení a alarm v?p?ípadě neodborné manipulace ?i zcizení, kter? zajistí odeslání nouzového signálu v?etně poslední známé GPS i v?p?ípadě odpojení od palubního napájení. Pro p?ípad kompaktní varianty ?e?ení PP OIS je pot?eba za?ízení vybavit rozhraním pro extérní ?te?ky QR kód? a ?ipov?ch karet (B?K) dle bodu 5.3. Jedná se o ?e?ení, kde je nemo?nost p?ístupu cestujícího k?p?ilo?ení QR nebo B?K u?kompaktní varianty odbavovacího za?ízení z?d?vodu uzav?ené kabiny ?idi?e. V?kompaktní variantě ?e?ení PP OIS, je po?adováno umístnění ?tecích za?ízení pro cestující (QR a B?K), v?pravé zadní ?ásti PP OIS z?pohledu ?idi?e.Splňovat podmínky zákona ?.101/2000Sb. na ochranu osobních údaj?, ve znění pozděj?ích p?edpis?, a to v?etně v?ech proces? práce s daty z odbavovacího za?ízení.Splňovat podmínky zákona ?. 139/2011 Sb. kter?m se mění zákon ?. 284/2009 Sb., o platebním styku, ve znění zákona ?. 156/2010 Sb., a některé dal?í zákony.Splňovat podmínky Na?ízení vlády ?. 295/2010 Sb., o stanovení po?adavk? a postup? pro zaji?tění propojitelnosti elektronick?ch systém? plateb a odbavení cestujících.Po?adavky na operace bankovních a dal?ích bezkontaktních karet s?DZCOdbavovací za?ízení PP OIS musí b?t vybaveno externí ?i interní kombinovanou ?te?kou bankovních karet a karet standardu MIFARE/DESfire. Klávesnice pro zadání PIN na ?te?ce není vy?adována. Nevy?aduje se mo?nost kontaktního ?tení karet pomocí ?ipu ?i magnetického pásku. ?te?ka musí odpovídat standardu ISO 14443A a dále musí splňovat v?echny pot?ebné specifikace pro práci s?bankovními kartami vy?adované asociacemi VISA a MasterCard – tzn., musí b?t certifikována dle standard? PCI DSS a PCI PTS p?ípadně dal?ích standard? PCI (pci_security/) ve verzi platné v?den p?edání prvního kusu PP zadavateli. Rovně? musí splňovat v?echny pot?ebné certifikace vy?adované karetními asociacemi VISA a MasterCard.?te?ka musí splňovat následující specifikaci:PCI PTS securityPCI PTS 4.xEMVCo Letter of Approval - Contact Terminal Level 1Platn?EMVCo Letter of Approval - Contact Terminal Level 2Platn?EMVCo Letter of Approval - Contactless Terminal Level 1Platn?MasterCard Terminal Quality Management (TQM)Platn?LoA L2 VISA PayWave2.1.1 a vy??íLoA L2 MasterCard PayPass3.0.2 a vy??íCard reader NFC/ContactlessEMV Level 1 compliant, ISO 14443 A/BSAM 2Operating temperature-20 - +70IK index (shock protection)IK 10?te?ka dle v??e uveden?ch specifikací musí b?t vybavena softwarem vytvo?en?m a zprovozněn?m v?souladu se standardy PCI (viz v??e) a p?ípadn?mi dal?ími po?adavky karetních asociací VISA a MasterCard ve verzích platn?ch v?den p?edání prvního kusu PP zadavateli, kter? umo?ní:na?tení UID karty bankovní ?i nebankovní a jeho p?edání k?dal?ímu zpracování do SW pro kontrolu a prodej jízdních doklad?;bezkontaktní úhradu ceny jízdenky;na?tení ?ísla bankovní karty (PAN) a vytvo?ení token? dle dále uveden?ch specifikací a jeho p?edání k?dal?ímu zpracování do SW pro kontrolu a prodej jízdních doklad?;správu blacklist? token? a karet, p?edání upozornění o blacklistaci karty;na?ítání pot?ebn?ch údaj? o UID, p?ípadně token? prost?ednictvím technologie NFC a dal?í zpracování těchto údaj? obdobn?m zp?sobem jako v?p?ípadě bankovních ?i nebankovních karet.?te?ka dle v??e uveden?ch specifikací musí b?t dále dodána se SW, kter? p?i práci ?s kartami standardu MIFARE / DESfire umo?ní:ne?ifrovanou základní komunikaci s?kartami (minimálně na?tení UID a jeho p?edání k?dal?ímu zpracování do SW pro kontrolu a prodej jízdních doklad?;komunikaci s? kartami typu MIFARE/DESfire ?ifrovanou prost?ednictvím kryptovacích algoritm? umístěn?ch na minimálně ?ty?ech SAM slotech (mo?no i SW emulovan?ch);vyu?ití funkce elektronické peně?enky ulo?ené na kartě typu MIFARE/DESfire k?hrazení jízdného prost?ednictvím PP OIS;vyu?ití bankovní karty k?hrazení jízdného prost?ednictvím PP OIS;vyu?ití funkce p?edplatní jízdenky ulo?ené kartě typu MIFARE/DESfire, na?tení platnosti jízdenky a p?edání do SW pro kontrolu a prodej jízdních doklad?;Odbavovací za?ízení PP OIS musí b?t on-line propojeno s?Dopravním zú?tovacím centrem IDS JMK (DZC), odkud musí on-line (v p?ípadě dostupnosti datového p?ipojení) na?ítat informace o tokenech resp. UID karet a k?nim p?i?azen?m jízdenkám. Odbavovací za?ízení PP OIS musí b?t rovně? p?ipraveno na on-line propojení s?rozhraním pro bankovní platby (RBP) provozované subjektem p?ípadně subjekty zabezpe?ující p?edávání informací z?bankovních ?te?ek platebním ústav?m. Komunika?ní rozhraní mezi PP OIS, DZC a RBP bude vytvo?eno ve spolupráci s?dodavatelem během realizace zakázky. P?edpokládané parametry tohoto propojení, které sou?asně musí PP OIS umo?ňovat, jsou následující:na?ítání údaj? o platn?ch p?edplatn?ch jízdenkách – musí b?t umo?něno dálkové u?ivatelské nastavení ?etnosti na?ítání v?r?zn?ch denních dobách a dále náhodné zahajování na?ítání s?cílem omezit ?pi?ky, defaultně ka?d?ch 5 minut. PP IOS musí zvládat na?ítání a zpracování dat o p?edplatn?ch jízdenkách v datovém toku 200kB za 5 minut p?edstavující zakoupení 4 p?edplatn?ch jízdenek;na?ítání údaj? o platn?ch jednorázov?ch jízdenkách – mo?nost dálkového u?ivatelského nastavení ?etnosti na?ítání v?r?zn?ch denních dobách a dobách vzta?en?ch k linkospoji, defaultně ka?dou 1 minutu v??ase, kdy je PP IOS na linkospoji, ka?d?ch 10 minut, kdy je mimo linkospoj a dále 5 minut p?ed v?jezdem na linkospoj; PP IOS musí zvládat na?ítání a zpracování dat o jednorázov?ch jízdenkách v datovém toku 300 údaj? o jízdence o velikosti 1 kB za ?pi?kovou minutu – tzn. na?tení a zpracování minimálně 300 kB dat o jednorázov?ch jízdenkách za 1 minutu;PP OIS musí zvládat autodetekci rychlosti na?ítání dat a automatickou optimalizaci na?ítání dat o jízdenkách v?p?ípadě pomalej?ího p?ipojení. V?takovém p?ípadě automaticky upraví mno?ství, frekvenci a obsah na?ítání dat; nap?. omezí na?ítání jízdních doklad? jen pro zóny, kter?mi vozidlo projede.v?p?ípadě, ?e údaje o dané jízdence nebudou dostupné v?databázi, PP OIS musí umo?nit automatické / manuální on-line dotázání na platnost jízdenky a to i odlo?ené, pokud v?okam?iku kontroly nebude mo?né jízdenku zkontrolovat - nebude k?dispozici on-line p?ipojení;PP OIS musí v?p?ípadě bankovní karty p?i zakoupení jízdenky umo?nit na?tení tokenu a dal?ích k?platbě pot?ebn?ch zabezpe?en?ch údaj? ze ?te?ky, jejich p?edání do rozhraní pro bankovní platby a do DZC. P?esné formáty, obsah dat a rozhraní budou definovány p?i realizaci zakázky ve spolupráci mezi objednatelem a zhotovitelem. Pokud bude platba vy?adovat zadání PIN nebo on-line ově?ení karty, musí PP OIS umo?nit i tuto funkci. Za?ízení musí umo?nit tímto zp?sobem po?ízení 20 jízdenek za minutu a p?edání údaj? o nich do DZC a do rozhraní pro bankovní platby do 2 minut. PP OIS musí v?p?ípadě karty typu MIFARE/DESfire p?i zakoupení jízdenky umo?nit na?tení UID karty a dal?ích k?platbě pot?ebn?ch zabezpe?en?ch údaj? ze ?te?ky, jejich p?edání do DZC. Pokud bude na kartě nastavena mo?nost platby elektronickou peně?enkou, pak musí zajistit vy?tení a na?tení pot?ebn?ch dat na kartu. P?esné formáty, obsah dat a rozhraní budou definovány p?i realizaci zakázky ve spolupráci mezi objednatelem a zhotovitelem. Za?ízení musí umo?nit tímto zp?sobem po?ízení 20 jízdenek za minutu a p?edání údaj? o nich do DZC do 2 minut; zejména pro inicia?ní na?tení dat musí b?t komunikace mezi PP OIS a DZC mo?ná i p?i umístění napájeného PP OIS mimo vozidlo, a to p?ipojením prost?ednictvím WiFi nebo pevné internetové línky po kabelu RJ45 (p?ípadně p?es redukci, která musí b?t sou?ástí dodávky, pokud nebude sou?ástí dodávky p?ímo zásuvka pro tento konektor umístěná na dodaném PP OIS);PP OIS musí umět pracovat s?blacklistem token? a karet – tzn. na?íst z?DZC a RPB a kontrolovat p?i p?edkládání karet;PP OIS musí umo?nit pracovat se seznamy speciálních token? – nap?. p?i p?ilo?ení revizorské karty ke ?te?ce musí za?ízení umo?nit zablokování ozna?ova?? jízdenek a dal?ích ?te?ek karet. P?i p?edlo?ení karty administrátora umo?ní vy?tení vybran?ch druh? dat a úpravu parametr? systému dohodnut?ch p?i realizací zakázky s dodavatelem.PP OIS musí b?t vybaveno pevnou pamětí o velikosti minimálně 32 GB s?rychlostí zápisu i ?tení minimálně 30 MB/s vy?leněnou pro ulo?ení ?ifrované databáze jízdenek a fotografií dr?itel? p?edplatn?ch jízdenek IDS JMK.PP OIS musí b?t konstruováno tak, aby umo?nilo p?ipojení více bezkontaktních ?te?ek bankovních karet (minimálně 4), sběr a p?edávání dat z?nich prost?ednictvím PP OIS do DZC p?ípadně do RBP.OIS musí b?t konstruováno tak, aby softwarově i hardwarově umo?nilo bez dodate?n?ch úprav SW a HW p?ipojení samostatně fungujícího validátoru – za?ízení vybaveného ?te?kou bankovních karet s?obdobn?mi funkcemi jako ?te?ky, ozna?ova?em jízdenek a dal?ími informa?ními systémy. Minimálně musí umo?ňovat sdílení p?ístupu k?datovému propojení s?DZC a RBP a k?internetu a sdílet údaje o linkospoji, aktuální zastávce, zóně a dal?ích dopravních informacích.Po?adavky na SW pro odbavování cestujících?te?ka karet musí obsahovat certifikovanou platební aplikaci splňující po?adavky PCI a dal?í po?adavky asociací VISA a Mastercard umo?ňující?Off-line i On-line transakci do 500 K?, bez zadání PINu i s?p?ípadn?m zadáním PINu. Po?adavky na ?e?ení funk?nosti ?te?ky je uvedeno v?následujícím textu.V?p?ípadě, ?e je p?ilo?ena bankovní karta, ?te?ka zajistí generování jednoho ?i více druh? token? (otisk? karet). Hlavní tokeniza?ní algoritmus pro jízdenky IDS JMK stanovuje zadavatel bez ohledu na acquiera (zprost?edkovatelskou banku). Ostatní tokeniza?ní algoritmy si mohou nastavit dal?í subjekty prost?ednictvím zadavatele. P?i zahájení realizace zakázky zadavatel dodavateli protokolárně p?edá pot?ebná hesla a protokoly a dal?í pot?ebn? SW pro ?te?ku.P?ilo?ením bankovní karty ke ?te?ce ?te?ka vygeneruje token nebo tokeny. PP OIS v databázi prově?í, jaké jednorázové a p?edplatní jízdenky jsou k?danému tokenu p?i?azeny. PP OIS ?idi?i zobrazí fotografii dr?itele karty (pokud je k?dané jízdence povinná) a podrobnosti k?tokenu p?i?azen?m p?edplatn?m jízdenkám a to i jízdenkám neplatn?m, zablokovan?m ?i platn?m v?budoucnu dle databáze DZC. Prově?í sou?asně platnost jízdenky a zvukov?m a vizuálním signálem potvrdí platnost ?i neplatnost jízdenky.V?p?ípadě po?adavku na ově?ení fotografie PP OIS musí ?idi?i umo?nit ově?it platnost autenti?nost fotografie. Tuto funkci musí b?t mo?né dálkově povolit / zakázat. PP OIS musí umo?nit zobrazení dal?ích specifick?ch údaj? k?jízdence ?i tokenu – nap?. p?íznaky hledaná osoba, zablokovaná karta, apod.Pokud PP OIS nenajde platnou jízdenku k?danému tokenu, umo?ní prodej jízdenky. PP OIS musí umět p?i prodeji jízdenky prově?it platnost jízdních doklad? a p?edev?ím kombinovat p?edplatní a jednorázové jízdenky v?souladu s?Tarifem IDS JMK. P?i prodeji jízdenek IDS JMK musí odbavovací za?ízení PP OIS dle druhu prodávaného jízdního dokladu rozhodnout, kter? z?token? zpracuje a jak s?ním nalo?í. V?p?ípadě koupě jízdenky IDS JMK p?edá p?íslu?n? token spole?ně s?chip-data on-line nebo okam?itě p?i navázání spojení do DZC a do RBP. Mo?nost hrazení jízdného formou zaplacení jízdenky u ?idi?e (tzn. p?ímá platba) je vy?adována. PP OIS musí b?t konstruováno tak, aby bylo mo?né zajistit r?zné zp?soby plateb dle druh? jízdních doklad? nap?. v p?ípadě prodeje jin?ch jízdenek ne? IDS JMK dle po?adavk? jiného koordinátora nebo dopravce. PP IOS musí umo?nit kompatibilitu mezi tarify IDS JMK a dal?ími tarify. Na území IDS JMK musí b?t mo?né prodat jízdenku pro trasu mimo IDS JMK a naopak. Pokud dojde k?dohodě o takov?ch prodejích, budou si koordináto?i vzájemně takto prodané jízdenky dle nastaven?ch pravidel vyú?továvat a záznamy o prodan?ch jízdenkách ze spole?n?ch linek budou dostupné pro v?echny zapojené partnery. maximální doby pot?ebné na zobrazení platnosti jízdenkyP?i dodr?ení v?ech po?adavk? na PP IOS musí b?t doba mezi p?ilo?ením bankovní karty (nebo vysíla?e NFC, p?ípadně nebankovní karty vyu?ité jen jako identifikátor) ke ?te?ce a zobrazením údaj? o cestujícím a o jeho platn?ch jízdenkách p?idělen?ch ke kartě (p?ípadně o neuznání karty) na displeji PP OIS krat?í ne? 1 sekunda. Během této doby musí dojít k?p?e?tení karty, vyhledání údaj? v?databázi v?PP OIS, k?zobrazení na displeji a k?vyhodnocení platnosti jízdenky v?etně odpovídajícího zvukového signálu. P?i dodr?ení v?ech po?adavk? na PP IOS musí b?t doba mezi p?ilo?ením nebankovní karty s?nutností zápisu ke ?te?ce a zobrazením údaj? o cestujícím a o jeho platn?ch jízdenkách p?idělen?ch ke kartě (p?ípadně o neuznání karty) na displeji PP OIS krat?í ne? 2 sekundy. Během této doby musí dojít k?p?e?tení karty, vyhledání údaj? v?databázi v?PP OIS, k?zobrazení na displeji a k?vyhodnocení platnosti jízdenky v?etně odpovídajícího zvukového signálu.PO?ADAVKY NA TOKENIZACI BEZKONTAKTN?CH BANKOVN?CH KARET Sou?ástí dodávky ?te?ek musí b?t i SW knihovna nebo jin? SW, kter? umo?ní komunikaci mezi ?te?kou karet a SW t?etích stran, aby bylo mo?né online (p?ípadně po navázání komunikace) p?edat vypo?ítan? token (kryptované ?íslo karty) a dal?í související údaje – zejména ?as provedení tokenizace, typ odebrané slu?by, chip-data ze související platební transakce - dal?ím aplikacím DZC a RBP. Dodavatel musí také zajistit p?evzetí a implementaci klí?? do tokeniza?ního algoritmu zp?sobem odpovídajícím certifikaci dle PCI DSS (dle bezpe?nostních standard? karetních asociací). Obsahem zprávy ze ?te?ky je p?edev?ím token v podobě:?TOKEN=0123456789012345678901234567890123456789012345678901234567890123|“V p?ípadě chyby se vrací prázdn? Token (?TOKEN=|“). Na konci je v?dy znak pipe ?|“, aby mohly následovat dal?í tagy (?TAG1=VALUE1|TAG2=VALUE2|...TAGn=VALUEn|“).Tokenizace má následující parametry (klasifikace dle Tokenization Product Security Guidelines – viz PCI DSS):? Jednosměrná (Irreversible)? Autentiza?ní (Identifikující) Pro tyto ú?ely byl vybrán tokeniza?ní algoritmus HMAC-SHA256:Kde:?K je klí? (secret key)?m je ?íslo kreditní karty + ?asová platnost mmrr?K' je derivovan? tajn? klí??|| je konkatenace?⊕ je operace XORParametry:?H (Hash funkce): SHA 256 ?Secret key (double-length, hexadecimálně) 14 bytu?Derivovany klic K‘ = K || [14krat 0x00].?m je ?etězec o pevné délce 23 alfanumerick?ch znak? (tzn. 23 Byt?), kódování ASCII. P?ebírají se pouze znaky, které jsou viditelné na kartě. Pokud znaky chybí, doplní se nuly. P?evod z PAN musí b?t následující: Zdrojov? PAN: 5101 3650 0030 1667, Platnost: 10/17 (16 znak?) V?sledné m = ?51013650003016671017000“ Zdrojov? PAN: 5101 3650 0030 1667 123, Platnost: 10/17 (19 znak?) V?sledné m = ?51013650003016671231017“ Zdrojov? PAN: 5101 3650 0030 16, Platnost: 10/17 (14 znak?) V?sledné m = ?51013650003016101700000“ P?íklady v?po?tu HMAC s?pou?itím 14 bytového klí?e 000102030405060708090A0B0C0D KORDIS TEST#1 KEY[14]=000102030405060708090A0B0C0D DATA[23]=3531303133363530303033303136363731303137303030 HMAC-SHA256[32]=2dc02119b61e96a0b848982f47080367b3f9bf28c424229718542cb127ce13dc KORDIS TEST#2 KEY[14]=000102030405060708090A0B0C0D DATA[23]=3531303133363530303033303136363731323331303137 HMAC-SHA256[32]=58624f895d53a826e71d033a99bf0e4505bddb7dd83c5982b412bb73f50d9c87 KORDIS TEST#3 KEY[14]=000102030405060708090A0B0C0D DATA[23]=3531303133363530303033303136313031373030303030 HMAC-SHA256[32]=3504b31bc8026c55d197cf6f6a0b0c3adf9789d9f7c989a6dd7f1a4fcb8eee98 Klí? HMAC1 s KCV= C472E5 : primární klí?, aktuálně je tento klí? pou?it pro v?po?et tokenu v produk?ních terminálech;Klí? HMAC2 s KCV= 544B04 : zálo?ní klí? ?. 1 (nap?. pro p?ípad kompromitace klí?e HMAC1 nebo pro pou?ití v dal?ím regionu)Klí? HMAC3 s KCV= 3A6ED0 : zálo?ní klí? ?. 2 (nap?. pro p?ípad kompromitace klí?e HMAC1 a klí?e HMAC2 nebo pro pou?ití v dal?ím regionu)Vlastníkem bezpe?nostních klí?? je KORDIS JMK, a.s. Ten je má ve formě 2 fyzick?ch komponent v zape?etěn?ch obálkách. Ka?dá komponenta je 14 byt? dlouhá a v?sledn? klí? K se skládá pomocí operace XOR.Ty protokolárně p?edá v?hradně PCI DSS certifikovanému dodavateli, kter? zajistí nahrání klí?? pro ?ifrování a následně komponenty protokolárně vrátí vlastníkovi. SPECIFIKACE A ?E?EN? OBSLU?N?HO SOFTWARE a hardware – ?BACK OFFICE“ A KOMUNIKACEStru?n? popis stávající infrastruktury zadavatelePlatforma VMWare vSphere Essential Plus, vCenter management, 3x dualCPU servery ?ady IBM x3550M4 s 2x 8core CPU, Diskové pole ?ady IBM Storwize V3700 s redundantním host p?ipojením typu SAS k v?em provozovan?m server?m. UPS ?ady EATON 5130i. Sí?ová LAN infrastruktura s zakruhovanou páte?í zalo?ená na p?epína?ích ?ady Cisco SG500XSOFTWAROV? ?E?EN?Systém musí navr?en minimálně jako t?ívrstv? systém. Toto ?e?ení nabízí vysokou míru bezpe?nosti celého ?e?ení, centrální archivaci a distribuci p?ístupov?ch práv k jednotliv?m modul?m.Základem systému (datová vrstva) musí b?t standardizovan? databázov? systém. Tato vrstva slou?í ke shroma??ování, p?ijímání a odesílání dat aplika?ní vrstvě. Ve?kerá data systému jsou ulo?ena v této databázi.Aplika?ní vrstva musí slou?it ke zpracovávání po?adavk? z klientské vrstvy a zpracovávání operací na pozadí. Musí obsahovat ve?keré moduly pro provoz OIS v??e popsané jak pro systém IDS JMK, tak pro tarif a odbavení mimo systém IDS JMK.T?etí klientskou vrstvu musí tvo?it vlastní klientské moduly jednotliv?ch ?ástí systému – vrstva zprost?edkovává komunikaci mezi u?ivatelem a aplika?ní vrstvou. Klientská vrstva musí existovat s?lokální desktopovou verzí, tak s?verzí tenkého klienta pro vzdálen? p?ístup od dopravce.SW musí b?t modulární, kter? se skládá z díl?ích modul?, které se pou?ívají pro specifické ?innosti. Pou?ití jednotliv?ch modul? modulu je závislé na po?adavcích na funkcionalitu celého odbavovacího systému a lze tedy modul provozovat slo?en? pouze z několika modul?.Charakteristiky systémuCharakteristické rysy, které systém musí splňovat, jsou:otev?enost systému (pou?ívání standard?, práce s daty ve vhodném formátu nap?íklad XML, v?měna dat prost?ednictvím webov?ch slu?eb),modularita, ?kálovatelnost (systém jako skláda?ka, mo?nost i fyzického rozdělení na více server?, oddělení p?ístupu k dat?m),mo?nost vzdálené administrace (vzdálené spou?tění a zastavování jednotliv?ch komponent, vzdálená instalace komponent systému). snadná správa systému (ově?ování u?ivatel? z jednoho autentika?ního serveru, systém rolí a práv, automatická synchronizace klientsk?ch aplikací ze serveru),moderní trend u?ivatelského rozhraní (moderní vzhled, jednotn? vzhled a?ovládání v?ech ?ástí systému, mo?nost ukládání u?ivatelsk?ch pohled? a?nastavení).Zabezpe?ení systémuBezpe?nostní politika systému obsahuje souhrn bezpe?nostních po?adavk? na fyzické, personální, administrativní, po?íta?ové a komunika?ní úrovni. Musí respektovat po?adavky na?í legislativy i mezinárodních bezpe?nostních standard?. V systému jsou zpracovávány osobní údaje fyzick?ch osob, proto je kladen d?raz na zabezpe?ení těchto osobních údaj? v souladu s po?adavky, které vypl?vají ze zákona 101/2000 Sb. o ochraně osobních údaj?.Identifikace a autentizace u?ivatel?V?ichni u?ivatelé musí mít pro p?ístup do systému p?iděleno u?ivatelské jméno (identifikátor, ID). Toto u?ivatelské jméno zaji??uje, ?e je mo?né sledovat ?innost jednotlivc? v systému. Ka?d? u?ivatel se p?i p?ístupu do systému autentizuje pomocí hesla. Hesla jsou ulo?ena v takové podobě, ?e nikdo, v?etně správce systému, nem??e p?e?íst ulo?ené heslo.V systému je mo?né vyu?ít autentiza?ní systém ?X-krát a uzam?ení“. To znamená, ?e v p?ípadě, ?e p?ihlá?ení u?ivatele do systému je X-krát po sobě neúspě?né, tak dojde k uzam?ení ú?tu daného u?ivatele. Uzam?en? ú?et u?ivatele m??e odemknout pouze administrátor systému. Pro identifikaci a autentizaci u?ivatele do systému je mo?né vyu?ít dvoufázové identifikace. Tato dvoufázová identifikace a autentizace u?ivatele je zalo?ena na pou?ití u?ivatelského jména, hesla a osobní bezkontaktní karty u?ivatele, kterou je nutné p?ilo?it ke ?te?ce bezkontaktních karet během p?ihla?ování u?ivatele do systému; vyu?ívá se UID ?íslo karty MIFARE ?i DESfire. Toto ?íslo je mo?né na?íst pomocí ?te?ky ?i zadat ru?ně v?modulu Administrace. Po na?tení karty, zadání u?ivatelského jména a hesla, provede systém validaci dat, a pokud je identifikace a autentizace korektní, je u?ivatel p?ihlá?en do systému. Systém umo?ní volbu, kte?í u?ivatelé musí pou?ít dvoufázovou identifikaci, nemusí b?t tedy nezbytně povinná pro v?echny u?ivatele.Oprávnění u?ivatel?Ka?dému u?ivateli systému musí b?t mo?né administrátorsky p?idělit oprávnění pro práci v?systému (u?ivatelské role). Tím musí b?t zabezpe?en p?ístup u?ivatel? k dat?m a funkcím systému a zaji?těna ochrana p?ed neautorizovan?m p?ístupem. U?ivatel p?istupující p?es tenkého klienta SW-BO se musí nejprve autentizovat k doménovému serveru provozovatele, teprve poté mu je zp?ístupněna p?ihla?ovací obrazovka do systému, kde je nutné provést autentifikaci v??i SW-BO.Evidence událostí v?systémuPro provádění záznam? informujících o stavu systému. Nástroj musí rozli?ovat jednotlivé úrovně d?le?itosti zpráv. Nastavení logování musí b?t plně konfigurovatelné. Po implementaci systému musí slou?it logované soubory administrátorovi systému pro diagnostikování skryt?ch chyb a monitoringu aplikace. Logy jsou ukládány na aplika?ním serveru (logy apl. serveru) a na klientské stanici (logy z klientské stanice). Ulo?ené logy mohou b?t archivovány pro pozděj?í anal?zy. Datové centrumJeden z?hlavních po?adavk? na ?e?ení sestav je mít jednotn? p?ístup k?dat?m. Datov?m centrem rozumějme databázi, její? v?chozí model a struktura bude odpovídat po?adavk?m pro p?enos a dolování dat - archiv.Kromě v??e uvedeného musí b?t systém dále roz?i?ovateln?.KOMUNIKACE – ZP?SOB P?ED?V?N? INFORMAC? Z?SW-BO NA PP OISStandardizace p?enosu informací vychází z CEN/TS 15531-1-3 Pracovní rozhraní pro informace v reálném ?ase (SIRI – Service Interface for Real time Information); je XML protokol, kter? slou?í pro v?měnu informací v reálném ?ase ve ve?ejné dopravě. Komunikace mezi vozidlem a serverem SW-BO bude probíhat za jízdy p?evá?ně pomocí binárního protokolu. Tento zp?sob komunikace je zvolen s?ohledem na spolehlivost komunikace GSM/GPRS/UMTS/LTE a mo?né v?padky komunikace. Sou?ástí komunikace musí b?t i po?ítadlo p?enesen?ch dat pomocí GSM/GPRS/UMTS/LTE na jednotlivé PP OIS s?varováním u ur?itého po?tu p?enesen? dat v??ase.Stahování soubor? z?vozidelP?i stahování soubor? z?vozidel (mo?no nap?. odpo?ty, vybrané adresá?e, logy, apod. – dal?í etapa) musí b?t pou?ito následující ?e?ení:Stahování soubor? z?vozidel se musí primárně dít v?síti APN KORDIS JMK. Na serveru budou umístěny sekce pro r?zné dopravce. Tito je budou mít k?dispozici pro nahrávání dat do vozidel pomocí tenkého klienta SW-BO. Slu?ba pro synchronizaci dat ve vozidlech bude vyvolávána ze serveru SW-BO dle dohodnut?ch kritérií. Po dobu vy?ítání se nesmí vypnout ani V?J a ani GSM/GPRS/UMTS/LTE modem.Zp?sob aktualizace na serverech není p?edepsán. Budou pouze stanoveny doby pro aktualizace dat ve vozidlech od vytvo?ení nové verze dat a pro stanovení rychlosti vy?tení log?. Za?ízení musí umo?nit více komunika?ních tras: zejména ?ifrovanou komunikaci s?bankou (p?edávání informací o tokenech ze ?te?ek), ?ifrovanou komunikaci s?DZC a v??e uvedenou komunikace se serverem KORDIS JMK.Nahrávání soubor? do vozidelNahrávání dat (soubor?) do vozidel bude provádět SW-BO v?několika p?ípadech – vlastnosti zastávek, zvuky a aliasy pro digitální hlási?e, konfigurace chování vozidla, apod.Ze serveru SW-BO budou nahrány soubory, které mají b?t p?ená?eny na vozidlo. Jedná se o soubory související s?provozem IDS JMK, p?íp. i s?provozem dopravce (nap?. ?jízdní ?ády“, ??idi?i“, tabla, ?blacklist“, apod.). HARDWAROV? ?E?EN? PRO SW-BOZ d?vodu zabezpe?ení kompatibility provozovan?ch aplikací, zabezpe?eni kontinuity provozu datového centra a zabezpe?ení úrovně vysoké dostupnosti po?aduje zadavatel dodávku ve?kerého HW i SW se zvlá?tním z?etelem na to, aby je bylo mo?né za?lenit do ji? existující infrastruktury provozované zadavatelem a centrálně spravovat jednotně s ji? existující infrastrukturou pomocí technologicky stejn?ch nástroj?. Po?adavky na dodávan? HWSou?ástí V?J je dodávka server? které musí splňovat:Provedení do 19" rackuDuální napájeníManagement rozhraní kompatibilní s IPMI 2.0 s funkcionalitou KVM-over-LAN a media-over-LANRedundantní p?ipojení do sítě pomocí min 4x 1GE a 2x 10GE (SFP+) ethernetuRedundantní p?ipojení k stávajícímu diskovému poli i p?ipadně nově dodávan?m pomocí technologie SAS nebo FC min. 8GbitCertifikaci pro pou?it? hypervisorCelkové parametry dodávaného HW musí b?t dostate?né pro?obsluhu minimálně 1500 ks PP OIS On-line a minimálně 30 u?ivatel?m SW-BO v?jeden okam?ik p?ihlá?ení a práce s?SW-BO.Disková kapacitaPot?ebnou diskovou kapacitu je mo?né variantně dodat:Roz?í?ením stávajícího diskového pole ?ady Storwize V3700 a zabezpe?ením jeho redundantního p?ipojení ke v?em stávajícím i nově dodávan?m server?m pomocí technologie SAS nebo FC min. 8Gbit Stávající pole je v sou?asné době osazeno redundantními ?adi?i s moduly typu SAS.Dodáním nového diskového pole a zabezpe?ením redundantního p?ipojení ke v?em stávajícím i nově dodávan?m host server?m pomocí technologie SAS nebo FC min. 8Gbit nově dodávaného pole i stávajícího pole ?ady IBM Storwize V3700 tak, aby ka?d? se stávajících i nově dodávan?ch server? byl redundantně p?ipojen ke stávajícímu i nově dodávanému poli. Stávající pole je v sou?asné době osazeno redundantními ?adi?i s moduly typu SAS.Diskové pole musí splňovat/obsahovat následující funkcionality (v?etně p?ípadn?ch SW licencí, pokud jsou pot?ebné)Provedení do 19" rackuDuální napájeníPlně redundantní dual controller design s podporou automatického failoverUpgrade firmware bez v?padku IO operacíDisky typu hot-swapPodporu min RAID 0,1,5,6Redundantní host p?ipojení pomocí technologie SAS nebo FC min 8GbThin provisioned volume, Mirrored volume, Tiering (min 3 úrovně -SSD, SAS, NL-SAS), Snapshot (min. 128 ), Volume copy, Automatick? rebalancing v rámci volume. Minimálně 16GB cache na ka?d? z ?adi?? / min. 32GB celkem na diskové pole.Ve?kerá po?adovaná funkcionalita musí b?t realizována p?ímo na úrovni diskového pole, tj. je nep?ípustn? nap?. SW RAID realizovan? na serverech, zrcadlení svazk? na úrovni server?, snapshot na úrovni hypervisoru atp. Nástroje pro management pole kompatibilní se stávající infrastrukturou provozovanou zadavatelem. 5 let SW maintenance.Kapacita diskového pole musí b?t dostate?ná k?obsluze minimálně 1500 ks PP OIS a 200 u?ivatel?m SW-BO s?archivací vstupně v?stupních dat minimálně 5 let.UPSKapacita odpovídající provozu v?ech nově dodávan?ch za?ízení po dobu 20 min. Sí?ov? management modul kompatibilní s stávající infrastrukturou managementu UPS provozovanou zadavatelem. Kapacita UPS musí korespondovat s?dodávan?m HW s?dostate?nou rezervou v?konu. Sou?ástí dodávky je i úprava elektroinstalace v?místnosti provozu UPS – serverovna spole?nosti KORDIS.Opera?ní systém server?Zadavatel po?aduje dodání/roz?í?ení licence virtualiza?ní platformy tak, aby splňoval stávající funkcionality, pokr?vala ve?ker? stávající i nově dodávan? hardware a umo?ňovala správu pod jednotnou konzolí. Dodavatel zajistí SW Maintenance s?platností minimálně 5 let, pot?ebnou pro provoz SW-BO.SPR?VA SYST?MU OIS V SW-BOSprávu systému lze rozdělit na několik ?íselník?, které jsou v něm spravovány / ?ízeny. U?ivatelé zde mají p?ístup ke správě obsluhy, tarifní politiky, ú?etního systému, globálního nastavení, provozního nastavení a dal?ích funkcionalit. P?ipravují se zde p?edev?ím vstupně v?stupní data do PP-OIS. Správa musí umo?ňovat spravovat jednotlivé ?íselníky jak pro systém IDS JMK, tak pro jednotlivé dopravce samostatně na základě p?ednastaven?ch u?ivatelsk?ch práv pro jednotlivé ?íselníky. Jednotlivé ?íselníky musí obsahovat mo?nost exportu / importu obsahu ?íselníku do souboru XML; TXT a podobně), tisku obsahu. Ve?keré změny v??íselnících musí nést datum a ?as poslední změny a ID u?ivatele změny.Správa dopravních systém?Díky správě dopravních systém? lze v jednom systému rozli?it libovoln? po?et dopravních systém?, poskytovatel? a dopravc? (Dopravní systémy, Dopravci, Poskytovatelé). Prioritně bude systém v systému IDSJMK. Dopravci si k?tomuto mohou zvolit vlastní systém -p?ejezdové linky mezi systémy.Evidence za?ízení PP-OISEvidence za?ízení PP-OIS obsahuje polo?ky Evidence za?ízení, Evidence vy?tení, nevy?tená za?ízení, typ za?ízení, stav za?ízení, servisní zprávy k?za?ízení, mo?nost vzdálené aktivace/deaktivace někter?ch funkcionalit PP-OIS, nap?íklad funkci MSP, hlási?e, tabel a podobně. ?íselník bude p?ístupn? p?edev?ím administrátor?m.Evidence ?idi??Samostatná evidence ?idi?? jednotliv?ch dopravc?, kde se p?iděluje jméno a p?íjmení ?idi?e jeho osobní ?íslo (ID) a PIN pro p?ihlá?ení na PP-OIS.správa ?íselník? Tarif? a tarifní politikySada ?íselník? slou?í ke správě tarif?, měn, tiskov?ch formulá??, vztah tarifu k jízdním ?ád?m, generování i následné vy?ítání dat, atd. ?íselníky musí umo?ňovat celou ?adu nastavení a metod v?po?tu, p?edev?ím pro pou?ití v?r?zn?ch systémech (IDSJMK, KM tarif, atd.) P??PRAVA DAT SKUPINY TARIF? ?íselník musí umo?ňovat celou ?adu pravidel pro v?po?et jízdného p?edev?ím v?tarifu IDSJMK, KM tarifu, MHD tarifu a dal?ích tarif? vyu?ívající ?tvercové, trojúhelníkové p?ípadně dal?í matice v?po?tu jízdného. Tento ?íselník m??e b?t sou?asně pou?it ve vícero variantách, p?i?em? jednotlivé varianty mohou fungovat sou?asně. ?íselník slou?í ke specifikaci v?sledn?ch tarif? ur?en?ch pro v?dej papírov?ch jízdenek na za?ízeních PP-OIS. P?íprava odbavovacích tarif? pro za?ízení zahrnuje definice ceník?, tarif?, pou?ití tiskov?ch formulá?? jízdenek a nastavení jejich vzájemn?ch vazeb. ?íselník musí minimálně obsahovat jednotlivé kategorizace:ZákladníZlevněnéZTP jízdné?ákovskéStudentskéZdarma / zaměstnaneckéP?edplatní jízdnéKupóny ?asové/úsekové/zónové/oblastní aj.?íselník musí umo?ňovat zadání minimálně 5 cenov?ch měn ke ka?dé jízdence, r?zn?ch DPH pro jednotlivé jízdné, mo?nost nulového DPH p?i p?eshrani?ních jízdenek – jízda p?es dva a více stát?. ?íselník musí dále umo?ňovat speciální tarifní v?jimky, pau?ální procentuální slevy pro ur?ité kategorie jízdních doklad? (nap?. v?hotovosti, kartou), pevné p?irá?ky ke ka?dému jízdnímu dokladu.Tiskové formulá?e?íselník bude mít za úkol u?ivatelsky měnit tiskové formulá?e pro tisk jízdních doklad?, jízdních ?ád?, uzávěrek a podobně z?tiskárny PP-OIS. ?íselník musí obsahovat u?ivatelsky definované fonty písem a to jak font, velikost, tlou??ku, kurzívu, negativní zobrazení text?, rámování, podtr?ení a jiné, tak vkládání 1 ?i 2D kód? s?mo?ností definování v?po?tu kódu, proměnné s?mo?ností nastavení logiky v?po?t?. P?íkladem ?asová a datumová platnost jízdenky do s?tiskem jak QR kódu tak i Aztec kódu.Za?ízení musí umo?nit tisk kódu jízdenek dle standardu vyu?ívaného v?aplikaci POSEIDON – a to jak ve formě QR kódu tak i Aztec kódu.Jízdní ?ády, turnusy?íselník musí p?edev?ím umo?nit nahrávání a úpravu vstupních dat jízdních ?ád? ze soubor?:LIK (p?edev?ím systém IDSJMK, viz popis LIK), JDF (CIS tvar J? – ostatní systémy), a samostatně turnus? (jak pro systém IDSJMK, tak pro ostatní systémy).V jízdních ?ádech se spravují zastávky, linky a spoje, oblasti linek a p?ehledy jednotliv?ch spoj?. Správa zastávek spo?ívá v definici zastávek a jejich vzdáleností v ?íselníku. U Zastávky (sloupku) je umo?něno nastavení více parametr? pro za?ízení (r?zné názvy pro za?ízení, oblast, do které spadá, doplňkové informace pro hlási? ?i tabla, a podobně). ?ást správa linek a spoj? umo?ňuje p?i?adit spoj?m jednotlivé linky a nastavit pr?jezdné body linek. Jízdní ?ád, na úrovni spoje, definují p?i?azené ?asy p?íjezdu a odjezdu v jednotliv?ch bodech. Pokud je v systému vyu?ívána funkcionalita kalendá? spoj?, p?i?azují se linkám zna?ky ur?ující, kdy linka/spoj jezdí. Sou?ástí jízdních ?ád? je i pro systém IDSJMK v?po?tová matice jízdného. Systém dále nabízí mo?nosti rozdělení trasy linky na oblasti, nastavení v?jimek p?i?azení dopravních systém? a p?i?azení licencí pro linky. ?íselník musí umo?ňovat rychl? p?ehled s?mo?ností tzv. ?p?edpisu dat“ pro konkrétní linku, jen? doká?e po nahrání vstupních soubor? nap?. LIK ur?ité polo?ky změnit, pro odladění nap?íklad informací na tabla, hlási? a podobně. P?edpis musí umo?nit editaci v?ech spoj?, někter?ch a to bu? zápisem jednotliv?ch spoj?, nebo intervalem. Musí umět p?i?adit dal?í informace k?lince, neobsa?ené ve vstupním souboru LIK nap?íklad licenci ?i kalendá? spoj?.Pro za?ízení je mo?né definovat p?ehled ?inností jednotliv?ch linkospoj? v podobě turnus?. Informace se zobrazí na za?ízení s popisem ?innosti a uveden?m ?asem za?átku a konce ?innosti.Kalendá? spoj?Funkcionalita pro zobrazení celkového p?ehledu vybran?ch linkospoj? za ur?ité období. V?etně mo?nosti zobrazovat p?ehledy podle zvolen?ch linek a ?asového období je mo?né data generovat i podle r?zn?ch verzí historick?ch dat. Vygenerovaná data slou?í jako p?ehled pro prokazatelné ztráty dopravce, na základě kter?ch m??e uplatňovat náhrady u poskytovatele nebo objednatele dopravy.Podkladem pro generování dat do kalendá?e spoj? jsou vygenerované délky spoj? a jízdní ?ády definované sadami zna?ek pro kalendá? spoj?.Délky spoj? se generují v závislosti na vybran?ch linkách a jejich p?i?azen?ch bodech. Zna?ky kalendá?e spoj? jsou pak p?i?azeny jednotliv?m linkám a definují, kdy linka/spoj jede.V nabídce je i p?ehled nezaú?tovan?ch jízdenek, které je mo?né ru?ně editovat.Slevy pro data ze za?ízeníFunkcionalita pro dopo?ítávání slev z?vstupně / v?stupních dat podle nastaven?ch typ? slev a metod v?po?tu, které se na základě těchto v?po?t? generují. ?íselník tímto umo?ní ur?it?m druh?m jízdného p?idávat ur?ité slevy a to bu? procentuálně, pevnou sazbou, aj.Správa karetSpráva B?K spravuje sady klí??, díky kter?m lze pracovat s kartami a karetními aplikacemi v odbavovacích za?ízeních. Jedná se p?edev?ím o zahrnutí sou?asn?ch B?K v?systému IDSJMK na ?mal?ch“ městsk?ch dopravách: Kyjov, Blansko, B?eclav, Vy?kov a Znojmo. Dále je p?edpoklad vyu?ití karet pro servisní ú?ely k?otev?ení nap?íklad servisního menu pro nastavení PP-OIS. Sou?ástí bude také dodání 100 servisních karet.Generování a zpracování datModul slou?ící ke generování dat pro za?ízení v definovaném formátu. U?ivatel má mo?nost definovat obsah souboru v?běrem dat, které budou do souboru vygenerována. Kromě dat z ?íselník? definovan?ch v??e, lze nakonfigurovat datové sady v následujících ?íselnících:Seznamy osob - soubory dat obsahující v?běr osob Seznamy linek - soubory dat obsahující v?běr linek v závislosti na turnusechKonfigurace turnus? - soubory dat obsahující v?běr turnus?Seznam konfigurací tiskov?ch formulá?? - soubory dat obsahující v?běr tiskov?ch formulá??. Funkcionalita musí nabízet mo?nost definovat pro ka?d? typ za?ízení odli?n? tiskov? formulá? v jednom balíku vstupních dat.Konfigurace ?azení tarif? - soubory dat obsahující nastavení ?azení tarif? pro jednotlivá za?ízení. Sou?asně je mo?né tarify dělit do skupin.Nastavení - obecná nastavení pro za?ízení (Datum a ?as, Jazyk, Automatické uzav?ení odpo?tu atd.)Pro zpracování dat modul musí nabízet dále funkcionality:Export dat - export dat do LIK souboruImport dat - import dat t?etích stran CSV nebo XML soubor?Záloha vstupních dat - umo?ňuje zálohování vstupních dat a jejich následné obnovení ze zálohy. Dále musí SW-BO exportovat sestavy dle v?měru MF ?. 01/2004, ve znění v?měru MF ?. 02/2004 Ministerstva dopravy ?R, kter? stanovuje formát a strukturu dat pro elektronické zpracování v?stup? z odbavovacích za?ízení ve ve?ejné linkové osobní dopravě.správa ?íselník? Hlá?ení a tabelSada ?íselník? slou?í ke správě hlá?ení a zpráv pro hlási?e a tabla. Musí umo?ňovat celou ?adu nastavení p?edev?ím pro pou?ití v?r?zn?ch systémech (IDSJMK, KM tarif, atd.) Hlási?eSestavovací tabulka relací (jeden kód pro vícero frází)Profily hlasitostiDefinice obsahu hlá?ení TablaRozdělní na externí a interní tablaNastavení typ? tabel a jejich umístěníDefinice obsahu a formátu zobrazovaného textuRotace textu / měnění textu Definice jednotliv?ch obraz? v?etně p?epínáníInterval rotace a zobrazení aj.Doplňkové informace cestujícím?íselník obsluhuje p?ehrávání doplňkov?ch informací pro cestující na LCD monitorech, ?ídí jejich aktualizace na základě kalendá?ních, linkov?ch, oblastních a ?asov?ch kritérií – ?asová osa. ?íselník bude slou?it pro plánované změny těchto informací nap?íklad v?luky, reklamy a podobně. Z??íselníku bude umo?něno p?ehrávání nejenom textov?ch informací na LCD / LED tabla ale také na monitor ?idi?e (info o v?lukách), a p?edev?ím také formát? *.jpg, *.gif a pro vozidlové LCD také *.avi.ZKU?EBN? PRACOVI?T?Sou?ástí zakázky je i Vybavení zku?ebního pracovi?tě v?sídle zadavatele. Vzhledem k?udr?itelnosti projektu a nutnosti zaji?tění v?ech OIS v?provozu IDS JMK, je nutné vybavit pracovi?tě pro testování a simulaci dat na testovací stolici, ne? p?ijdou do ostrého provozu. V?sou?asné době je ve?spole?nosti KORDIS jedno testovací pracovi?tě OIS, je? musí b?t zachováno i na nov? OIS. Dodavatel zajistí dodávku dvou zku?ebních pracovi?? podle následující specifikace:38036564833500jedno pracovi?tě – specifikace: plná verze PP OIS se zaji?těním zdrojové ?ásti 220V na 24V, zaji?tění instalace stávajících tabel a periferií ze stávající zku?ební stolice v?etně kabelá?e. Nová kovová stolice s?parametry: 764540427291500druhé pracovi?tě – specifikace: plná verze PP OIS a zdrojem 220V/24V, je? bude ji? bez periferií a tabel. Nová kovová stolice s?parametry: Obě stolice musí b?t mobilní pro p?ípadné ?kolení i mimo kancelá?e a budovu KORDIS. Vybavení zku?ebního pracovi?tě zahrnuje i dodávku dvou (2) PC pot?ebného v?konu pro plnohodnotnou obsluhu PP OIS a SW-BO v?etně ?irokoúhl?ch monitor? min. 24“ s?WIN a?kancelá?sk?m balíkem Office. Dodavatel zajistí také pot?ebné zku?ební p?ístroje, mě?icí p?ístroje, p?ípravky, apod., je? budou nutné pro ově?ení správnosti zapojené kabelá?e PP OIS ve vozidle a následnou instalaci, v?e v?po?tu dvou sad.?KOLEN? A ZAJI?T?N? PODPORYDodavatel zajistí jedno ?kolení pracovník? objednatele pro lehk? terénní servis, jím? se pro ú?ely plnění Smlouvy rozumí servis PP OIS na úrovni administrátorsk?ch nastavení, kabelá?e, a ?i?tění mechanick?ch ?ástí PP OIS, konfigurace a instalace PP OIS a SW-BO na úrovni administrátora zaměstnanc? KORDISu.Dodavatel zajistí minimálně dvě ?kolení pově?en?ch osob dopravc?, je? budou provádět instalaci a p?ípravu kabelá?e pro zapojení PP OIS ve vozidlech dle instrukcí dodavatele. ?kolení proběhne v sídle KORDISu, p?ípadně na jiném ur?eném místě na území města Brna.Dodavatel zajistí minimálně dvě základní ?kolení pro PP OIS a SW-BO pro zaměstnance dopravc? a KORDIS na úrovni bě?ného provozu, základní profylaktické údr?by, pravideln?ch v??t? a importu / exportu ve?ker?ch dat, tvorby vlastních ceník?, tiskov?ch formulá??, metodiky v?po?tu jízdného, jízdního ?ádu a podobně. ?kolení proběhne v sídle KORDISu, p?ípadně na jiném ur?eném místě na území města Brna.Ve?keré pro?kolené osoby od dodavatele obdr?í certifikát s?jednotliv?mi úkony, je? mohou pro?kolené osoby provádět.14732095123000 KOMUNIKA?N? PROTOKOLY, DIAGRAMY, DEFINICE P??SLU?N?CH SOUBOR? A GRAFICK? VZHLED VSTUPN? SOUBOR TARIFU A J?ZDN?CH ??D? LIKVstupním souborem pro v?dej jízdenek na jednotliv?ch linkospojích v?etně jízdního ?ádu a dal?ích informací pro ?idi?e a cestující. Soubor LIK je prost? textov? soubor rozdělen? do několika ?ástí, odděleně oddělova?em -----END----- ?ádky, st?edníkem sloupce. Jsou-li v?popisu dvě hodnoty (tam/zpět, ano/ne), je tím my?leno, p?epínací hodnota Ture / False. U polo?ky dny kdy neplatí je my?leno zápis ve tvaru DD.MM.RRRR nebo interval DD.MM.RRRR-DD.MM.RRRR. Je-li vícero dn?, jsou odděleny ?árkou.Zastávky?íslo linky; ?íslo zastávky – uzlu dle IDSJMK; ?íslo sloupku dle IDSJMK; ?íslo CIS; ?íslo pro zvuk v?hlási?i zastávek; tarifní ?íslo; sou?adnice sloupku x; sou?adnice sloupku y; tarifní zóna; název pro display ?idi?e; název pro tisk na jízdenky; název pro vnit?ní tablo1; název pro bo?ní vněj?í tablo1; název pro ?elní tablo1; název pro vnit?ní tablo2; název pro bo?ní vněj?í tablo2; název pro ?elní tablo2; název pro vnit?ní tablo3; název pro bo?ní vněj?í tablo3; název pro ?elní tablo3; ?íslo nástupi?tě; popis sloupkuSoubor umo?ňuje pro ka?d? sloupek trojí název, jen? m??e b?t vyu?it pro zobrazení. V?chozí v?ak platí název rmace o linkospojích?íslo linky; ?íslo spoje; tarifní systém spoje; spoj veden? tam/zpět; ?íslo linky pro tablo – mo?nost t?í alfanumerick?ch znak?; ?íslo obratové linky; ?íslo obratového spoje; dny kdy neplatí obratov? spojTarifním systémem spoje je my?leno, jak bude PP OIS odbavovat. Parametr 10 je IDSJMK, 11 p?eprava zdarma, 1 km tarif, 2 kombinovan? a podobně. ?íslo obratové linky a spoje je pro p?ípad, kdy z?kone?né p?íslu?ného spoje v?z pokra?uje na linkospoji následujícím bez p?estupu cestujících, tzv. obrat s?cestujícími. Vliv na tabla, hlási? a v?dej jízdenky. Linkospoj musí ov?em existovat a b?t nahrán v?PP OIS.Jízdní ?ád?íslo linky; ?íslo spoje; tarifní ?íslo; název pro display ?idi?e; pr?jezd zastávkou ano/ne; ?as p?íjezdu ve tvaru HH:MM:SS; ?as odjezdu ve tvaru HH:MM:SS; zastávka na znamení ano/ne; zastávka nácestná ano/ne; zakázan? nástup ano/ne; zakázan? v?stup ano/ne; zastávka na zavolání ano/ne; p?evoz kol ano/ne; zobraz název 2 nebo 3Parametry v??ásti jízdní ?ád (ano/ne), mají vliv p?edev?ím na tabla, hlási?, informaci pro ?idi?e ?i zablokování v?deje jízdenky – zakázan? nástup. Zobrazení názvu 2 nebo 3 pro tabla viz Zastávky.Tarif?íslo linky; ?íslo spoje; tarifní ?íslo ze zastávky; tarifní ?íslo do zastávky; kilometrická délka; tarifní zóna ze zastávky; ID jízdního dokladu; tarifní zóna ze zastávky 2; ID jízdního dokladu 2Tarif je pro ka?d? linkospoj z ka?dé zastávky z – do, specifikován. ID platby je ?íselné ozna?ení dle hodnoty jízdenky IDSJMK vzta?ené mezi těmito dvěma zastávkami. Druhá tarifní zóna a ID dokladu se vyu?ije p?i kombinaci dvou stejn?ch princip? v?deje jízdních doklad?, ov?em?rozdíln?ch systém? (p?íklad: IDSJMK a OREDO). Tarif má charakteristiku ?tvercové tabulky.Relace hlási??íslo linky; ?íslo spoje; tarifní ?íslo zastávky; kód hlá?ení; smě?ování hlá?ení - 0 uvnit? i ven z vozu, 1 uvnit? vozu, 2 ven z?vozuKód? hlá?ení m??e b?t i několik a jsou odděleny ?árkou s?postupn?m vyhlá?enírmace ?idi??íslo linky; ?íslo spoje; tarifní ?íslo zastávky; text pro display ?idi?e; dny kdy neplatíV??et informa?ních text? pro jedno tarifní ?íslo a linkospoj m??e b?t vícero, samostatné ?ármace cestující?íslo linky; ?íslo spoje; tarifní ?íslo zastávky; text pro vnit?ní tablo pro cestující; trvale zobrazen ano/neTextová informace trvale zobrazen ano, bude na table zobrazena bez p?eru?ení po celou dobu jízdy z?tarifního ?ísla zastávky. Je-li ne, informace se st?ídá dle p?rmace o p?estupu?íslo linky; ?íslo spoje; tarifní ?íslo zastávky; název uzl?; ?ísla uzl? dotazu; ?ísla sloupk? dotazuJedná se o zobrazení odjezdového tabla zastávky na LCD table pro cestující. ?ísla dotaz? jsou tedy parametry dotaz? na API CED. ?ísel m??e b?t vícero (samostatné dotazy), oddělené ?árkou. P?edpokládá se automatická filtrace pojí?děné linky. Dotazy se mohou po dobu jízdy opakovat v?nastaven?ch rmace o návaznosti?íslo linky; ?íslo spoje; tarifní ?íslo zastávky; ?íslo p?estupní navazující linky; dny kdy neplatí V??et ?ísel navazujících linek pro jedno tarifní ?íslo a linkospoj m??e b?t vícero, samostatné ?ádky. Pou?ití p?edev?ím p?i zobrazení na jedno?ádkov?ch LED tablech pro cestující, p?ípadně LCD. Bude se jednat o alfanumerické znaky. Mo?nost také akustické informace.KOMUNIKA?N? PROTOKOL MODULU MSPObecná struktura rámce zprávyZákladním elementem p?enosu dat mezi MSP a komunika?ním serverem je tzv. zpráva (polo?ka, ….). Struktura jedné zprávy je uvedena na Obr. 1. Zprávu nese UDP datagram. Obr. 1: Struktura zprávyPrvní 4 byty zprávy p?edstavují hlavi?ku zprávy, která je identická pro v?echny zprávy.První bytem je kód zprávy. Identifikuje typ zprávy. Platí, ?e zprávy generované modulem MSP nesou kód zprávy z?rozsahu 0 – 127, zprávy generované serverem jsou z?rozsahu 128 – 255. V?jimkou jsou zprávy nesoucí potvrzení, kde je kód zprávy shodn? s?kódem zprávy, která je potvrzována.Druh? byte je ?íta?, kter? je individuální pro ka?d? typ (kód) zprávy. Po odeslání zprávy je inkrementován o 1. Má v?znam nap?. p?i monitorování ztrátovosti dat na p?enosové cestě. Nab?vá hodnot 0 a? 255.Následující dva byty p?edstavují ACK + ?as vytvo?ení zprávy. Struktura byt? je následující:Obr. 2: Struktura slova ACK + ?as vytvo?ení zprávyKa?dá zpráva m??e ?ádat potvrzení o doru?ení na server a/nebo potvrzení o p?íjmu obsluhou. Jako potvrzení je zpět odesílateli poslána stejná hlavi?ka (stejné hodnoty kódu zprávy, ?íta?e a ?asu vytvo?ení) bez těla. Pro rozli?ení jestli se jedná o ACK zprávu nebo normální zprávu slou?í bit ACK/data v ACK oblasti hlavi?ky.Podle délky zprávy rozeznáváme dva typy zpráv:zprávy s?pevnou délkou (v?dy stejn?, znám? po?et byt?),zprávy s?proměnnou délkou.Po?et byt? zpráv s?proměnnou délkou je dán prvním bytem v?oblasti dat zprávy, kter? svou hodnotou ur?uje po?et byt?, které se za tímto bytem nacházejí.Podrobn? popis jednotliv?ch zprávStavové informace Zprávu 0x01 periodicky generuje modul MSP. Zpráva je posílána na IP cílovou adresu. Zpráva generovaná modulem MSP nevy?aduje ?ádné potvrzení. Zprávu m??e i jako dotaz generovat server. Struktura zprávy odesílané z MSP:po?adí bytuhodnotapopis10x01kód zprávy2XX?íta?3-4x000xxxxACK + ?as vytvo?ení5,6XX XXpo?et následujících byt? 7XXdélka ?etězce IMEI modemu....XX … XXIMEI modemu....XX XX XX XXIP adresa vozidla....XX XXFW modulu MSP....XX XXID verze....XX XXDoba trvání GPRS/UMTS/LTE p?ipojení v?minutách....XXStav komunikace s?pokladnou:0.bit1 – komunikace je aktivní.1.-7.bitrezerva....XX XXStavové slovo USV24C ?tené povelem GetStatusPer. ....XX XX XX XXSériové ?íslo pokladny (?íslo strojku)....XX XX XX XX?íslo vozu získané z pokladny....XXDélka ?etězce nesoucího informace o vstupních datech pokladny....XX … XXInformace o vstupních datech pokladny.Periodicky zasílaná zpráva o poloze vozuZpráva je modulem MSP generována periodicky a nese informaci o aktuální poloze vozidla. Obecně zpráva nevy?aduje potvrzení. Z?d?vodu kontroly rozpadu GPRS/UMTS/LTE spojení v?ak modul MSP vy?aduje u ka?dé páté zprávy M-T.M potvrzení.Struktura zprávy odesílané do MSP:po?adí bytuhodnotapopis10x02kód zprávy2XX?íta?3-4x00xxxxx b ACK + ?as vytvo?ení 5-8XXzeměpisná ?í?ka – stupně, minuty, desetinné ?ásti minut9-12XXzeměpisná délka – stupně, minuty, desetinné ?ásti minut 13XXFix Quality 14XXHDOP15XXID DGPS stanice – horních 8 bit? 16XXID DGPS stanice – spodních 8 bit? 17XXstá?í DGPS dat v?sekundách 18XXrychlost v?uzlech krát 2 19XXazimut děleno 2 20XXstá?í GPS v?sekundáchJe-li modulem MSP po?adováno M-T-M potvrzení, je reakce od serveru následující:po?adí bytuhodnotapopis10x02kód zprávy2XX?íta?3x101xxxx bACK + ?as vytvo?eníOdjezd ze zastávkyZpráva je modulem MSP generována v?okam?iku stisku tla?ítka odjezd ze zastávky (resp. pr?jezd zastávkou). Zpráva obsahuje informace o aktuální poloze vozidla a navíc informaci o stavu tla?ítka a stavu dve?í.Zpráva po?aduje potvrzení od serveru. Struktura zprávy odesílané do MSP:po?adí bytuhodnotapopis10x03kód zprávy2XX?íta?3-4x000xxxx b nebo x001xxxx bACK + ?as vytvo?ení5-8XXzeměpisná ?í?ka – stupně, minuty, desetinné ?ásti minut9-12XXzeměpisná délka – stupně, minuty, desetinné ?ásti minut 13XXFix Quality 14XXHDOP15XXID DGPS stanice – horních 8 bit? 16XXID DGPS stanice – spodních 8 bit? 17XXstá?í DGPS dat v?sekundách 18XXrychlost v?uzlech krát 2 19XXazimut děleno 2 20XXstá?í GPS v?sekundách2100000xxx bstav tla?ítka odjezd ze zastávky, stav dve?í, v?znam bit? je následující:0. bit stav tla?ítka odjezd ze zastávky, 0 – nesepnuto, 1 – sepnuto1. bitstav p?edních dve?í, 0 - dve?e zav?eny, 1 – otev?eny2. bitstav prost?edních/zadních dve?í, 0 - dve?e zav?eny, 1 – otev?enyO?ekávaná reakce od serveru je následující:po?adí bytuhodnotapopis10x03kód zprávy2XX?íta?3-4x101xxxx bACK + ?as vytvo?eníP?íjezd do zastávkyZpráva je modulem MSP generována v?okam?iku otev?ení dve?í autobusu.Zpráva po?aduje potvrzení od serveru. Struktura zprávy odesílané do MSP:po?adí bytuhodnotapopis10x04kód zprávy2XX?íta?3-4x000xxxx b nebo x001xxxx bACK + ?as vytvo?ení 5-8XXzeměpisná ?í?ka – stupně, minuty, desetinné ?ásti minut9-12XXzeměpisná délka – stupně, minuty, desetinné ?ásti minut 13XXFix Quality 14XXHDOP - Horizontal Dilution of Position 15XXID DGPS stanice – horních 8 bit? 16XXID DGPS stanice – spodních 8 bit? 17XXstá?í DGPS dat v?sekundách 18XXrychlost v?uzlech krát 2 19XXazimut děleno 2 20XXstá?í GPS v?sekundách2100000xxx bstav tla?ítka odjezd ze zastávky, stav dve?í, v?znam bit? je následující:0. bit stav tla?ítka odjezd ze zastávky, 0 – nesepnuto, 1 – sepnuto1. bitstav p?edních dve?í, 0 - dve?e zav?eny, 1 – otev?eny2. bitstav prost?edních/zadních dve?í, 0 - dve?e zav?eny, 1 – otev?enyO?ekávaná reakce od serveru je následující:po?adí bytuhodnotapopis10x04kód zprávy2XX?íta?3-4x101xxxx bACK + ?as vytvo?eníP?ihlá?ení vozidla do IDSZpráva p?ihla?uje vozidlo, resp. ?idi?e do IDS.Struktura zprávy odesílané do MSP:po?adí bytuhodnotapopis10x05kód zprávy2XX?íta?3-4x001xxxx bACK + ?asu vytvo?ení 5XXur?uje po?et byt? zprávy za tímto bytem6000000xx b?ídící byte zprávy, v?znam bit? je následující:0. bitUr?uje, zda tato zpráva nese p?ihla?ovací údaje, ?i nikoliv. Hodnota bitu = 0 – zpráva nenese p?ihla?ovací údaje, bitu = 1 – zpráva nese p?ihla?ovací údaje1.bitDefinuje d?vod vzniku zprávy. Hodnota bitu = 0 – zpráva 5 vznikla z?d?vodu p?ihlá?ení ?idi?em.Hodnota bitu = 1 – zpráva je generována na základě vy?ádání.ostatní bity jsou nevyu?ity, nab?vají hodnoty 070 - 31den p?ihlá?ení do IDS, 80 - 12měsíc p?ihlá?ení do IDS90 - 23hodina p?ihlá?ení do IDS100 - 59minuta p?ihlá?ení do IDS110 - 59sekunda p?ihlá?ení do IDS12-15XX?íslo kurzu....XX?ísla mobilního telefonu ?idi?e....XXpo?et znak? zadaného identifika?ního ?ísla ?idi?e....XXidentifika?ního ?ísla ?idi?e O?ekávaná reakce od serveru je následující:po?adí bytuhodnotapopis10x05kód zprávy2XX?íta?3-4x101xxxx bACK + ?as vytvo?eníOdhlá?ení vozidla od IDSZpráva slou?í k?odhlá?ení p?ihlá?eného vozidla od IDS. Zpráva nemá ?ádné parametry.Struktura zprávy odesílané do MSP:po?adí bytuhodnotapopis10x06kód zprávy2XX?íta?3-4x101xxxx bACK + ?as vytvo?eníO?ekávanou odpově? tvo?í normální potvrzovací zpráva:po?adí bytuhodnotapopis10x06kód zprávy2XX?íta?3-4x101xxxx bACK + ?as vytvo?eníZadání/akceptování ?ísla linky a spojeTato zpráva je generována jednotkou MSP v?p?ípadě zadání nebo potvrzení linkospoje ?idi?em.Struktura zprávy odesílané z MSP:po?adí bytuhodnotapopis10x07kód zprávy2XX?íta?3-4x001xxxx bACK + ?as vytvo?ení 5,6XX, XX po?et následujících byt? 7,8,9XX,XX,XX?íslo kurzu 10XXindex zvoleného linkospoje v?aktuálním seznamu linkospoj?11,12XX,XXzadané ?íslo linky13,14XX,XXzadané ?íslo spoje Odpově? tvo?í normální potvrzovací zpráva.po?adí bytuhodnotapopis10x07kód zprávy2XX?íta?3-4x101xxxx bACK + ?as vytvo?eníKódové zpráva z?vozidlaProst?ednictvím této zprávy je z?modulu MSP odeslána kódová zpráva.Struktura zprávy odesílané do MSP:po?adí bytuhodnotapopis10x0Akód zprávy2XX?íta?3-4x0xxxxxx bACK + ?as vytvo?ení5XXkód zprávy Pokud je vy?adováno potvrzení, tak odpově? tvo?í normální potvrzovací zpráva:po?adí bytuhodnotapopis10x0Akód zprávy2XX?íta?3-4x1xxxxxx bACK + ?as vytvo?ení?ádost o zaslání p?ihla?ovacích údaj?Po p?ijetí této zprávy se generuje potvrzovací zprávu ACK a dále na server ode?le zprávu s?p?ihla?ovacími údaji.Struktura zprávy odesílané do MSP:po?adí bytuhodnotapopis10x85kód zprávy2XX?íta?3-4x0xxxxxx bACK + ?as vytvo?eníPokud je vy?adováno potvrzení, tak odpově? tvo?í normální potvrzovací zpráva:po?adí bytuhodnotapopis10x85kód zprávy2XX?íta?3-4x1xxxxxx bACK + ?as vytvo?eníTextová zpráva do vozidlaUmo?ňuje zaslat do vozidla textovou zprávu o délce 1 – 160 znak?, kterou si m??e ?idi? p?e?íst na displeji.Struktura zprávy:po?adí bytuhodnotapopis10x89kód zprávy2XX?íta?3-4x0xxxxxx bACK + ?as vytvo?ení5XXpo?et znak? textové zprávy (1 – 160 znak?)6-nXX1. znak textové zprávyPokud je vy?adováno potvrzení, tak odpově? tvo?í normální potvrzovací zpráva:po?adí bytuhodnotapopis10x89kód zprávy2XX?íta?3-4x1xxxxxx bACK + ?as vytvo?ení............Seznam linkospoj?Zprávu generuje server. Zpráva nese i index p?edpokládaného aktuální linkospojepo?adí bytuhodnotapopis10x8Akód zprávy2XX?íta?3-4x001xxxx bACK + ?as vytvo?ení 5-6XXXXpo?et následujících byt? 7XXd?vod vzniku zprávy0x00jako reakce na p?ihlá?ení ?idi?e0x01p?íjezd vozidla do kone?né stanice 0x02p?íjezd do kone?né stanice0x03zadání linkospoje ?idi?em8XXstav registrace vozu v?systému:0x00nep?ihlá?en 0x01nep?ihlá?en, chyba ?ísla kurzu0x02OK, 0x03více voz? na té?e slu?bě.0x04neznám? linkospoj 9XXrezerva10-12XXXXXXaktuální ?íslo kurzu vozu 13XXp?edpokládan? index aktuálního linkospoje14-15XX XX?íslo linky 1. linkospoje 16-17XX XX?íslo spoje 1. linkospoje ……Odpově? tvo?í normální potvrzovací zpráva:po?adí bytuhodnotapopis10x8Akód zprávy2XX?íta?3x1xxxxxx bACK + ?as vytvo?ení?ASOV? OSA J?ZDY LINKOSPOJE S?VLIVEM NA PERIFERIE-31623044513500Pro jízdu v?re?imu IDSJMK se p?edpokládá následující ?asová osa událostí s?vlivem na tabla a hlási?. Ve?keré parametry musí b?t jednotlivě dále modifikovatelné. GRAFICK? N?VRHY OBRAZOVEK A J?ZDN?CH DOKLAD?Ní?e jsou grafické návrhy obrazovek LCD a tabel, z?nich? je mo?né odvodit ve?keré ostatní pot?ebné obrazovky. Záměrně nejsou uvedeny ve?keré varianty, které se navíc mohou v?pr?běhu realizace zakázky měnit. Uvedené úpravy nejsou p?edmětem zakázky. Jejich podoba se m??e na základě v?robních v?bor? měnit.LCD pro cestujícíVnit?ní informa?ní LCD panel je zabudován v prostoru pro cestující u stropu vozidla. Ní?e je grafick? návrh, jen? je v?sou?asné době provozovan? v?IDSJMK v?etně dal?ího a to zastávkového tabla pro p?íjezd do p?estupního budu – v?sledná prezentace dat z?API CED. Návrhy neprezentují formu prezentace v?luk a reklamy, kde je p?edpokládáno zobrazování soubor? ?i videí. Soubory se musí st?ídat dle nastaven?ch ?asov?ch prodlev vyjma p?i změně dopravních informací ?i mimo?ádné zprávě. LCD musí minimálně umo?nit: zobrazení ?ísla linky,zobrazení názvu aktuální cílové zastávky,zobrazení názvu p?í?tí zastávky,zobrazení názvu následujících ?esti po sobě jdoucích zastávek (po projetí mizí),mo?nost pohyblivého textu,zobrazení piktogram? (nap?. ?kolní linka, apod.),dodate?né zobrazení písmena kombinace ?ísla a písmena linky,zobrazení piktogramu (nap?. p?estup, v?luka, apod.),mo?nost kombinace cizojazy?n?ch informací.-1790702032635002930525203644500-175260174625002930525179705001289050186118500-187960-46355002884170-4635500Vnit?ní LED a venkovní tablaV?návrhu se jedná p?edev?ím o pou?ití a zobrazení font?. Informa?ní panely musí splňovat zobrazení následující po?adavky: trvale zobrazuje ?íslo (písmeno, pop?. kombinaci) linky + název cílové zastávky aktuálního spoje, p?ípadně s doplňujícím textem nebo piktogramem, zobrazení ?ísla linky (p?ípadně písmena nebo kombinace obou), zobrazení názvu aktuální cílové zastávky, mo?nost p?eklápění textu, mo?nost celoplo?ného zobrazení (bez rozdělení na segment linky a segment cílové zastávky), zobrazení piktogramu (nap?. p?estup na vlak, v?luka, apod.), mo?nost inverzního zobrazení celého panelu nebo jen ?ásti. 185229524892000Rozvr?ení LCD pro ?idi?eNí?e se jedná o návrh rozlo?ení ovládacích prvk? dotykového displeje pro ?idi?e. Ovládací prvky se dají rozdělit do dvou ?ástí: Hlavní ?ást bude ve v?ech re?imech PP OIS dostupná a bude neměnná. Jedná se o hlavní rozcestník a p?epínání PP OIS do r?zn?ch re?im? ta to p?edev?ím do Menu, v?deje jízdenek, MSP, re?imu zobrazení okolních vozidel, ru?ních informací pro hlási? a tabla, mikrofonní propojení do vozidla, Emergency tla?ítko, nahrávání okolního prostoru.Vedlej?í ?ást, která se bude měnit na základě zvoleného re?imu z?hlavní ?ásti.1121410135001000Rozvr?ení ovládacích prvk? musí b?t v?SW-BO modifikovatelné a u?ivatelsky nastavovatelné. Prost?edí musí umo?ňovat p?idávat k?text?m i ikonky na základě gif soubor?. Prost?edí musí b?t intuitivní s?co mo?né nejméně kroky pro jednotlivé pravidelně pou?ívané úkony. Jedná se p?edev?ím o v?dej nejbě?něj?ích jízdenek na 2 a? 3 stisknutí. V?sledná podoba ovládacích prvk? musí b?t u?ivatelsky modifikovatelné na základě vstupních údaj? v?SW-BO.Vzor jízdního dokladu IDS JMK-23114080073500PP OIS i SW BO musí umo?ňovat celou ?adu modifikací jízdních doklad? a tiskov?ch formulá??. Ní?e je uveden? pouze vzor celé ?ady jízdních doklad? IDSJMK. Proměnné pro tiskové formulá?e jízdenek IDS JMK musí b?t u?ivatelsky v?SW-BO modifikovatelné na základě vstupních parametr?255270303276000-307911531521400013906517653000-167640-222885003115945-18034000 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download