Textová podoba smlouvy Smlouva č. 6587235: Inteligentní dispečink DPKV - servisní

                        Příloha č. 2
                                       Projekt

                   Dopravní podnik města Karlovy Vary -
   “Řídící informační systém pro MHD na území města Karlovy Vary

                                        (RIS)”
                             (Inteligentní dispečink)

                    Popis nabízeného technického řešení

Revize dokumentu

Revize Datum   Provedl          Popis změn
               L. Hlaváček, J.  První release dokumentu
1  03.5. 2018  Smejkal

                                Stránka 1 z 51
Obsah

Revize dokumentu................................................................................................................................... 1
Použité zkratky: ....................................................................................................................................... 4
A Detailní návrh cílového stavu .............................................................................................................. 5

      A.1. Celkový popis........................................................................................................................... 5
      A.1.1 Obecné vlastnosti dodávaného systému .............................................................................. 7
      A.1.2 Požadavky na ICT (HW a systémový SW) ............................................................................ 11
   A.2. Implementační služby (kapitola 4. TS)....................................................................................... 12
      A.2.1 Obecné požadavky (kapitola 4.1 TS) ................................................................................... 12
      A.2.2 Zpracování prováděcí dokumentace (kapitola 4.2 TS) ........................................................ 13
      A.2.3 Dodávky a implementace ................................................................................................... 15
      A.2.4 Testovací prostředí (kapitola 4.5 TS) .................................................................................. 16
B Detailní popis funkčních vlastností nabízeného plnění ..................................................................... 16
      B.1 Sledování a zobrazování okamžité geografické polohy (kapitola 3.2 TS) .............................. 16
      B.2 Monitoring plánovaného provozu vozidel pravidelné dopravy a automatické vyhodnocování
      odchylek od jízdního řádu (kapitola 3.3 TS) .................................................................................. 19
      B.3 Automatické upozorňování na neplánované a kritické stavy v provozu (kapitola 3.4 TS) .... 19
      B.4 Vzdálené ovládání inteligentních zastávek – integrace (kapitola 3.5 TS).............................. 20
      B.5 Dopřesnění polohy (kapitola 3.6 TS) ...................................................................................... 21
      B.6 Nástroje pro zpětný monitoring provozu a statistické vyhodnocení dat (kapitola 3.7 TS) .... 22
      B.7 Systém dálkového nahrávání a vyčítání dat na vozovnách (kapitola 3.8 TS) ........................ 23
      B.8 Systém sledování a vyhodnocování provozních dat (kapitola 3.9 TS)................................... 30
      B.9 Sledování ujetých kilometrů (kapitola 3.10 TS) ..................................................................... 31
      B.10 Architektura systému (kapitola 3.11 TS) ............................................................................. 33
C Detailní harmonogram projektu (kapitola 4.3 TS)............................................................................. 42
D Návrh akceptačních scénářů a způsobu provedení akceptačních testů (kapitola 4.6 TS) ................ 43
      D.1. Akceptační testy, zkušební provoz......................................................................................... 43
      D.2. Testovací prostředí................................................................................................................ 46
      D.3. Fáze přechodu do ostrého provozu ....................................................................................... 46
E Detailní popis navrhovaných školení (kapitola 4.4 TS) ...................................................................... 46
F Detailní popis způsobu odstraňování záručních vad a pozáručního servisu (kapitola 5.1 TS) .......... 48
      F.1. Záruční servis ......................................................................................................................... 48
      F.2. Helpdeskový systém .............................................................................................................. 49
      F.3. Pozáruční servis ..................................................................................................................... 50

                                                     Stránka 2 z 51
G Detailní popis podpory provozu (kapitola 5.2 TS)............................................................................. 50
                                                     Stránka 3 z 51
Použité zkratky:

ZD - Zadávací dokumentace
PP - Palubní počítač
GUI - Grafické uživatelské rozhraní
IS - Informační systém
ICT - Informační a komunikační technologie
HW - Hardware
SW - Software
DPKV - Dopravní podnik města Karlovy Vary
API - Rozhraní pro programování aplikací
CPU - Centrální procesorová jednotka
GPS - Globální polohový systém
RTC - Hodiny reálného času
IZ - inteligentní zastávka
JŘ - jízdní řád
TS – Technická specifikace (Část 3 ZD_Technická specifikace_Inteligentní dispečink DPKV.docx)

                                                     Stránka 4 z 51
A Detailní návrh cílového stavu

A.1. Celkový popis

Cílovým stavem nabízeného řešení je zřízení centrálního jednotného prostředí pro uživatele
obsahujícího moduly dodávaného systému včetně komunikačních modulů. Centrální prostředí bude
komunikovat se všemi vozidly zařazenými do systému, všemi inteligentními zastávkami zařazenými
do systému (IZ), externími zdroji dat a systémy 3. stran. Základní komponentní model je uveden na
obr. č. 1.
Nabízené řešení systému RIS (Inteligentní dispečink) je postaveno na skupině SW komponent
systému BUDIS, výrobce Bustec s.r.o. BLANSKO.
Systém BUDIS je modulární dispečerský systém zaměřený na veřejnou dopravu, vyvíjený společností
Bustec s.r.o.. Obsahuje komponenty pro dispečink, off-line datové přenosy, on-line datové a textové
přenosy, modul pro sledování a vyhodnocování dopravních a vozidlových dat, administrační a
konfigurační nástroje, komponenty pro tvorbu uživatelských reportů a rozhraní na další systémy jak
společnosti Bustec s.r.o. (například nástroje pro přípravu dat do informačních panelů vozidel) tak
externí aplikace třetích stran (např. nástroje pro přípravu jízdních řádů). Systém spolupracuje s
vozidlovými systémy společnosti Bustec s.r.o.., a inteligentními zastávkami a systémy 3.stran pomocí
definovaného API.
Záměrem systému “BUDIS” je vytvoření komplexního integrovaného systému odrážejícího potřeby
jak dopravní společnosti - dispečerů, řidičů a manažerů, tak potřeby cestujících ve vozech a na
zastávkách.

                                                     Stránka 5 z 51
Obr. č. 1 – Komponentní model nabízeného řešení.

Externí zdroj dat JŘ,                              BUDIS
služeb, rozpisů řidičů                      Modul Dispečink

                               Modul Nahrávání a vyčítání dat off-line

                               Modul Datové importy

                               Modul On-line komunikace                     Externí systémy
                                                                                 3.stran

Inteligentní zastávky             Modul textové a datové zprávy
          (IZ)                 Modul Vyhodnocování dat a reporty

                               Modul Řízení IZ

                               Modul API pro externí systémy

                               Modul administrace, správa uživatelů a práv

                               Modul Příprava dat

                               Vozidlový IS

Name:     Model komponent
Author:   jsmejkal
Version:  1.0
Created:  26.04.2018 16:01:08
Updated:  04.05.2018 9:28:10

BUDIS:
Základní komponenta na nejvyšší úrovni navrhovaného řešení. BUDIS zahrnuje moduly
uvedené v diagramu. BUDIS je postaven na architektuře klient-server.

                                           Stránka 6 z 51
         Externí zdroj dat JŘ, služeb, rozpisů řidičů:

         Základním zdrojem externích dat (data spravovaná systémy 3.stran) je interní aplikace DPKV
         pro správu JŘ, rozpisů služeb a řidičů. Tato data jsou do systému BUDIS importována na
         základě plánovaného procesu nebo na vyžádání operátora.

         Inteligentní zastávky (IZ):

         Součástí navrhovaného řešení je API pro komunikaci s inteligentními zastávkami. API bude
         připraveno dle specifikace předané zadavatelem.

         Vozidlový IS:

         Součástí navrhovaného řešení je on-line a off-line komunikace s vozidlovými IS všech vozidel
         zařazených do systému. On-line komunikace je založena na GSM a UDP packetech, Off-line
         komunikace pro nahrávání a vyčítání dat je založena na přenosu (synchronizaci) souborů
         technologií R-Sync.

         Externí systémy 3.stran:

         Součástí navrhovaného řešení je API pro komunikaci s externími systémy 3.stran. Návrh
         předpokládá jednotné řešení API pro všechny uvažované externí systémy.

A.1.1 Obecné vlastnosti dodávaného systému

Mezi základní obecné vlastnosti systému BUDIS patří:

    - Modularita
    - Architektura klient - server
    - Prezentace dat nad mapovým podkladem, formou tabulek, formou formulářů, reportů
    - Exporty do csv, pdf formátů
    - Nástroje pro filtraci dat
    - Uživatelské nastavení GUI
    - On-line a Off-line komunikace s vozidly
    - Komunikace s externími systémy
    - Nezávislé API
    - Tvorba uživatelských reportů
    - Historie všech provedených změn
    - Řízení přístupu založené na rolích
    - Notifikace vybraných událostí

Komponenty pro vyhodnocování dopravních a vozidlových dat poskytují nástroje pro přehledné
zobrazení vybraných dopravních a provozních informací v určeném časovém intervalu. Modul využívá
dat přenášených on-line i off-line z vozidlových systémů. Modul poskytuje řadu nástrojů pro filtraci,
výběry a seskupení dat včetně uživatelsky definovaných filtrů a uživatelské tvorby reportů.

                                                     Stránka 7 z 51
Komponenty pro komunikaci s vozidlovými systémy zajišťují jak on-line komunikaci datovou a
hlasovou, tak off-line komunikaci – přenos dat ve vozovnách.

Systém BUDIS disponuje řadou komunikačních rozhraní na systémy třetích stran. Typickými
rozhraními, kterými je systém “BUDIS” vybaven, jsou rozhraní na systémy připravující data jízdních
řádů, systémy připravující data pro informační panely na zastávkách a v terminálech případně externí
systémy pro vyhodnocování a diagnostiku provozních a vozidlových dat.

Systém “BUDIS” poskytuje dále nástroje pro exporty dat – přehledů, reportů, statistik do
standardních formátů typu CSV, PDF, Excel. (verze jsou vždy upřesněny v prováděcí dokumentaci
projektu).

Systém “BUDIS” je vybaven správou přístupových práv založenou na rolích / skupinách a jejich
přidělení k uživatelům.Rozlišení přístupu je provedeno podle jednotlivých modulů, případně jejich
částí a podle úrovní přístupu:

    - Čtenář: přístup pouze pro prohlížení dat
    - Editor: přístup pro provádění změn v datech modulu
    - Správce dat: přístup pro správu konfiguračních dat a přípravu dat modulu
    - Administrátor: přístup pro administraci uživatelů, správu přístupových práv a monitoring a

         správu centrálních procesů

Systém “BUDIS” ukládá historii všech uživatelsky provedených změn v datech, historii přístupů
uživatelů, historii všech provedených aktualizací vozidlového systému a historii všech dopravních a
provozních dat vozidel a poskytuje nástroje pro jejich zpětné vyhledání.

Klienti systému BUDIS umožňují spuštění aplikace na několika počítačích s odlišnou konfigurací (každá
instance muže mít např. jinak nastavené filrty, jinak upravené přehledy apod.).

Systém “BUDIS” je vybaven uživatelsky konfigurovatelnou komponentou poskytující notifikace
vybraných událostí určeným pracovníkům cestou e-mailových zpráv.

Systém BUDIS je vyvíjen jako systém otevřený pro komunikaci se systémy třetích stran. K tomuto
účelu je vybaven API, které umožňuje systémům třetích stran přístup k datům a funkcím BUDIS.

Prezentační vrstva systému BUDIS:

    Prezentační vrstva systému BUDISje tvořena WIN klientem pracujícím v prostředí běžného PC.
    Interakci s uživatelem zajišťuje grafické uživatelské rozhraní (GUI) postavené na technologii
    DevExpress umožňující sestavení komfortního prostředí pro prezentaci dat s možností
    uživatelského přizpůsobení. WIN klient komunikuje s databází prostřednictvím metod aplikačního
    serveru BUDIS.

    Následující obrázky ukazují vybrané možnosti – příklady filtrace přehledů (gridů) a uživatelského
    přizpůsobení v aplikaci WIN klient systému BUDIS:

    Fulltextová filtrace dat

                                                     Stránka 8 z 51
   Tabulka může být vybavena nástrojem pro výběr řádků pomocí fulltextového vyhledávání
   zadaného řetězce. Vyhledávání nalezne všechny řádky, v nichž se vyskytuje hledaný řetězec
   v některém ze sloupců. Hledání nerozlišuje velká a malá písmena a vyhledává zadaný řetězec
   znaků kdekoliv v textu. Tlačítkem „Smazat“ dojde ke zrušení aktuálního filtru.

Filtrace dat podle hodnot ve sloupci
   Tabulka může být vybavena nástrojem pro filtraci řádků podle hodnot ve vybraném sloupci.
   Po kliknutí na ikonu filtru se zobrazí seznam hodnot, ze kterého lze vybrat požadované
   položky.

Filtrace dat zadáním hodnot ve sloupci
   Tabulka může být vybavena nástrojem pro filtraci řádků zadáním řetězce do prázdného řádku
   a pole příslušného sloupce. Standardně je hledán výskyt zadaného řetězce v hodnotách
   sloupce zleva. Podmínku lze však upravit v nástroji „Editace filtru“. Hledání nerozlišuje velká
   a malá písmena.

Editace filtru
   Nástroj „Editace filtru“ umožňuje upravit vybranou filtrační podmínku. Lze změnit zadanou
   hodnotu, operátor a název sloupce, jehož hodnoty mají být prohledávány. Lze přidávat a
   ubírat další dílčí podmínky. Pokud je zapnuta volba „Ukládat nastavení tabulek“, aplikace si
                                               Stránka 9 z 51
zapamatuje sestavený filtr a ten je možné kdykoliv použít jednoduchým výběrem
z rozbalovacího seznamu uložených filtrů. Editaci filtru lze vyvolat kliknutím pravého tlačítka
myši do libovolného místa záhlaví tabulky nebo tlačítkem vpravo dole pod tabulkou. Filtr lze
také zrušit výběrem položky „Zrušit filtr“.

Editor filtru umožňuje sestavení podmínky pro výběr záznamů dle požadavku uživatele.
Nástroj umožňuje výběr sloupců, operátorů a hodnot, ze kterých je sestavena výsledná
podmínka. Tlačítkem „+“ lze přidat další podmínku. Tlačítkem „x“ lze odebrat podmínku.
Kliknutí na název sloupce zobrazí výběr sloupců. Kliknutí na název operátoru zobrazí výběr
operátorů. Kliknutí na hodnotu zobrazí pole pro zápis hodnoty nebo výběr hodnot ze
seznamu hodnot.

Doplnění sloupců do tabulky
                                           Stránka 10 z 51
         Tabulka může být vybavena nástrojem pro doplnění sloupců. Aktivace nástroje se provádí
         kliknutím pravého tlačítka myši do libovolného místa v záhlaví tabulky a výběrem položky
         „Výběr sloupce“. Zobrazí se dialog „Přizpůsobeni“. Doplnění sloupce se provádí výběrem
         řádku a tažením myši na místo v záhlaví tabulky, kam se má sloupec vložit.

A.1.2 Požadavky na ICT (HW a systémový SW)
Dodávaný systému bude provozován na ICT Zadavatele. Pro zajištění provozu komponent systému
BUDIS je vyžadováno následující ICT prostředí:

    • Server pro centrální aplikační server BUDIS
    • Server pro centrální databázi BUDIS
    • PC pro server Vozovna (pouze pokud je server Vozovna umístěn na jiném uzlu než centrální

         aplikační server)
    • PC pro klienty BUDIS
    • LAN pro komunikaci klientů BUDIS s aplikačním serverem, pro komunikaci serveru Vozovna

         s aplikačním serverem a pro komunikaci aplikačního serveru s databázovým serverem
         (aplikační, databázový, vozovnový server mohou běžet na jednom uzlu)
    • WIFI síť se všemi potřebnými komponentami pro komunikaci mezi vozidly a serverem
         Vozovny
    • GSM síťse všemi potřebnými komponentami pro komunikaci mezi vozidly a centrálním
         aplikačním serverem v celém rozsahu území
    • Licence operačních systémů serverů a PC

                                                    Stránka 11 z 51
    • Licence databázového serveru včetně potřebných licencí pro připojení klientů („Call“ licence
         nebo jiné řešení)

    • Zajištěné zálohování všech serverů (řešení zálohování není součástí nabídky)
    • Zajištěné zdvojení klíčových prvků ICT v případě požadavku na vysokou dostupnost systému

         (High availability)

Požadavky na klíčové komponenty ICT:

Server pro Aplikační server BUDIS:

    - Fyzický nebo virtuální uzel
    - Disková kapacita 300GB (výhledově při ukládání záznamů z kamer 2TB)
    - Paměť: 16GB
    - Operační systém: Windows Server 2016
Server pro Databázový server BUDIS:

    - Fyzický nebo virtuální uzel
    - Disková kapacita 100GB
    - Paměť: 16GB
    - Operační systém: Windows Server 2016
    - Databázový systém: MS SQL 2016
    - Licence pro počet uživatelů: teoreticky je to součet počtu připojených vozů, počet

         připojených zastávkových panelů, uživatelů dispečinku a 5 pro správce serveru – počítá se
         každý koncový uživatel, lepší je licence per procesor
Server pro Vozovnový server BUDIS:

    - Fyzický nebo virtuální uzel
    - Disková kapacita 100GB
    - Paměť: 4GB
    - Operační systém: min. Win 7
PC pro klienty BUDIS:

    - Fyzický nebo virtuální uzel
    - Disková kapacita 1GB
    - Paměť: 4GB
    - Operační systém: min. Win 7

A.2. Implementační služby (kapitola 4. TS)

A.2.1 Obecnépožadavky (kapitola 4.1 TS)

Dodavatel provede následující implementační práce na dodaných komponentech a případně dalších
zařízeních. Implementační práce dodavatele zahrnuje veškeré činnosti a prostředky, které jsou
nezbytné pro provedení díla v rozsahu doporučeném výrobci a dle tzv. nejlepších praktik, i v případě,

                                                    Stránka 12 z 51
pokud nejsou explicitně uvedeny, ale jsou pro realizaci předmětu plnění podstatné. Implementační
služby budou poskytnuty minimálně v následujícím rozsahu:

•  Zajištění projektového vedení realizace předmětu plnění.

•  Zpracování prováděcí dokumentace, která představuje projektovou dokumentaci, podle

   které se projekt bude realizovat. Součástí zpracování prováděcí dokumentace je mj.

   provedení předimplementační analýzy a zpracování finálního návrhu cílového stavu.

•  Dodávku nabízených zařízení a kompletní implementaci řešení splňující povinné

   parametry technického řešení,

•  Provedení školení,

•  Zajištění zkušebního provozu,

•  Provedení akceptačních testů,

•  Zpracování provozní dokumentace v rozsahu detailního popisu skutečného provedení a

   popisu činností běžné údržby a administrace systémů a činností pro spolehlivé zajištění

   provozu.

•  Předání do ostrého provozu,

Náklady na provedení implementačních služeb jsou zahrnuty v nabídkové ceně k položce, ke které se
vztahují.

Veškerá dokumentace bude zhotovena výhradně v českém jazyce, bude dodána ve 2x kopiích
v elektronické formě ve standartních formátech (např. MS Office) používaných zadavatelem na
datovém nosiči a 1x kopii v papírové formě.

A.2.2 Zpracování prováděcí dokumentace (kapitola 4.2 TS)

Dodavatel před zahájením implementačních prací zpracuje prováděcí dokumentaci, která bude
důsledně vycházet z předimplementační analýzy a bude zahrnovat všechny aktivity potřebné pro
řádné zajištění implementace předmětu plnění.

Jako podklad pro zpracování prováděcí dokumentace provede dodavatel předimplementační analýzu,
která bude zohledňovat stávající prostředí zadavatele ve vztahu ke konkrétnímu nabízenému plnění
dodavatele, zejména pak s ohledem na použité technické řešení, minimálně pro následující oblasti:

•  Analýza možností napojení připojovaných systémů.

•  Analýza provozních režimů jednotlivých technologií a návrh nastavení.

•  Analýza nároků dodávaných systémů na ukládání a zálohování dat, toky a objemy dat,

   nároky na výpočetní kapacity s ohledem na implementaci systému pro vzdálené ovládání

   IZ, rozhraní API, včetně specifikace objemu předpokládaných datových toků mezi

   systémem IZ a systémem RIS.

•  Požadavky na uživatelské prostředí – způsob ovládání, požadované funkce.

•  Požadavky na rekonfiguraci stávajících systémů ve vztahu k plánovanému využití.

•  Dopady implementace na dostupnost a funkčnost stávajících služeb.

•  Požadované součinnosti Zadavatele.

•  Návrh opatření k odstranění neshod zjištěných v průběhu analýzy.

                                  Stránka 13 z 51
Prováděcí dokumentace musí zohlednit podmínky stávajícího stavu, požadavky cílového stavu dle
zadávací dokumentace a konkrétního technického řešení nabízeného uchazečem a musí obsahovat
minimálně tyto části:

•  Detailní popis cílového stavu včetně funkcionalit jednotlivých částí systému,

•  Způsob zajištění dodávek a služeb,

•  Způsob zajištění koordinace realizace předmětu plnění s běžným provozem,

•  Detailní návrh a popis postupu implementace předmětu plnění,

•  Detailní popis zajištění bezpečnosti informací,

•  Detailní harmonogram projektu včetně uvedení kritických milníků,

•  Vazby na stávající systémy a jejich konfigurace,

•  Návrh akceptačních kritérií a akceptačních testů,

•  Detailní popis navrhovaných školení.

•  Obsah a rozsah provozní dokumentace.

Prováděcí dokumentace musí být před zahájením realizace dalších etap plnění výslovně schválena
zadavatelem.

Prováděcí dokumentace bude před ukončením zkušebního provozu aktualizována dle skutečného
stavu a následně bude součástí provozní dokumentace.

Součástí prováděcí dokumentace musí být i kompletní dokumentace (popis) otevřeného API rozhraní
pro výměnu dat s jinými systémy. Pojem otevřené API rozhraní je zde použito v běžně užívaném
smyslu, tedy, že popis API rozhraní bude veřejný a API rozhraní bude využitelné třetími stranami bez
jakýchkoliv licenčních nebo technických omezení v plném rozsahu poptávané funkčnosti.

V rámci předimplementační analýzy a zpracování prováděcí dokumentace budou prováděny
minimálně tyto činnosti:

   • Sběr požadavků
   • Analýza
   • Návrh řešení (architektura, datové a funkční modely, návrhy GUI, stavové diagramy)
   • Návrh fáze testování (testovací plán, testovací scénáře, vlastní testování )
   • Návrh nasazení (plán postupu nasazení, plán pilotního provozu, plán datové migrace,

       plán školení a nasazení)
   • Návrh postupu konfigurací
   • Návrh typu a rozsahu dokumentace
   • Návrh projektového řízení (organizační struktura projektu, komunikační schema,

       podrobné harmonogramy, řízení změnových požadavků, řízení realizace a nasazení,
       řízení změnových požadavků)

Veškeré požadavky uvedené v zadávací dokumentaci budou v rámci předimplementační analýzy a
zpracování prováděcí dokumentace řádně prodiskutovány a upřesněny se zadavatelem. Pokud budou
nalezeny požadavky, jejichž pokrytí není z technické části nabídky zřejmé nebo může být
interpretované rozdílným způsobem, budou v prováděcí dokumentaci upřesněny a návrh řešení bude
patřičným způsobem upraven.

   Stránka 14 z 51
Prováděcí dokumentace bude předložena zadavateli k připomínkovému řízení. V rámci
připomínkového řízení proběhne sběr všech připomínek zadavatele, jejich konsultace a vyjasnění a
zapracování do prováděcí dokumentace.

    Požadovaná součinnost zadavatele:

    - Poskytování konsultací během předimplementační analýzy a během připomínkového řízení
    - Poskytování potřebných dokumentů, materiálů, podkladů během předimplementační analýzy

         a připomínkového řízení
    - Prostudování prováděcí dokumentace
    - Schválení prováděcí dokumentace.

A.2.3 Dodávky a implementace

Výchozí činností pro dodávky nabízeného systému je zprovoznění ICT - infrastruktury potřebné pro
provoz dodávaného systému (viz bod 1.5.1 Harmonogramu - Ganttův graf). Dodavatel bude pro
splnění tohoto úkolu poskytovat součinnost ve formě poskytování informací a dokumentace pro
zadavatele. Vlastní zprovoznění ICT provede zadavatel (zprovoznění vyžaduje administrační práva
k ICT zadavatele, která vlastní výhradně pracovníci zadavatele).

Po zprovoznění ICT následuje fáze postupného dodávání, instalace, zprovoznění a ověření modulů
dodávaného systému. Zde navrhujeme dodání ve 4 částech (A, B, C, D), které se částečně překrývají
(viz Harmonogram - Ganttův graf - body 1.5.2, 1.5.3, 1.5.4).

V rámci implementace každé části budou provedeny následující práce:

    - Instalace modulu
    - Nastavení – konfigurace modulu
    - Ověření funkčnosti – otestování dodavatelem v produkčním prostředí.

Jednotlivé části systému A, B, C, D mají následující obsah:

   Část A:

    - Modul Administrace a správy uživatelů
    - Modul Nahrávání a vyčítání dat
    - Modul Datové importy – Import jízdních řádů
    - Modul On-line komunikace
    - Modul Dispečink – Sledování a zobrazování okamžité geografické polohy

   Část B:

    - Modul Textové a datové zprávy
    - Modul Dispečink – Automatické vyhodnocování odchylek od jízdního řádu
    - Modul Přípravy dat – Správa zájmových bodů
    - Modul Řízení IZ

                                                    Stránka 15 z 51
   Část C:
    - Modul Vyhodnocování a reporty – Zpětný monitoring provozu a statistické vyhodnocení dat
    - Modul Vyhodnocování a reporty – Systém sledování a vyhodnocování provozních dat
    - Modul Vyhodnocování a reporty - Ukládání záznamů dopravních událostí
    - Modul Vyhodnocování a reporty – Sledování ujetých kilometrů
   Část D:
    - Modul Dispečink – Dopřesnění polohy
    - Modul Dispečink – Automatické upozorňování na neplánované a kritické stavy
    - Modul API pro externí systémy

    Požadovaná součinnost zadavatele:
    - Příprava a zprovoznění požadované ICT
    - Zajištění potřebného přístupu dodavatele k ICT
    - Pohotovost a případná účast administrátora ICT
    - Zajištění testovacích jízd pro dodavatele pro ověření přenosu dat mezi vozidly a centrální

         částí systému (řidič, vozidlo)
    - Zajištění povolení pro dodavatele pro provedení testů v určeném časovém a obsahovém

         rozsahu.

A.2.4Testovací prostředí (kapitola 4.5 TS)

Dodavatel nevyžaduje zřízení testovacího prostředí. Testování dodavého systému provede dodavatel
na produkční infrastruktuře. Součinnost Zadavatele spočívá v udělení souhlasu s provedením testů
v předem oznámeném časovém rozpětí a předem oznámeném obsahu testů.

B Detailní popis funkčních vlastností nabízeného plnění

B.1Sledování a zobrazování okamžité geografické polohy(kapitola 3.2 TS)

Systém RIS zajistí příjem GPS dat z palubních jednotek vozidel (vybavených nebo připojených k
modulu GPS) a jejich zpracování. Palubní jednotka poskytuje následující data ve formátu UDP paketu:
a) Evidenční číslo vozu
b) Řidič
c) Kurz
d) Linka

                                                    Stránka 16 z 51
e) Spoj
f) Čas začátku a konce spoje
g) Konečná zastávka
h) GPS údaje (NMEA)
i) ID aktuální zastávky
j) Odchylka od JŘ
k) Aktuální rychlost
Systém RIS zajistí zobrazení polohy na mapovém podkladu dispečerského klienta.
Systém RIS zajistí zobrazení tabulky celkového vozového parku s informacemi o průběhu jízdy a stavu
vozidla (ve vozovně, v provozu, neaktivní, apod.).
Systém RIS zajistí zpracování dat ze všech vybavených (vypravených) vozidel v provozu – systém musí
být otevřený pro dodatečné rozšíření o sledování dalších vozidel bez nutnosti pořízení dalších modulů
nebo součinnosti dodavatele.
Systém RIS musí při detailním zobrazení vozidla ukázat směr jízdy vozidla, vztah vozidla k jízdnímu
řádu, jméno řidiče, apod.
Systém RIS zajistí přehledné zobrazení všech (nebo pouze dispečerem vybraných) linek v liniovém
vedení linek s kurzem a vybarvením vozů dle zpoždění/předjetí (ve více úrovních) ve vztahu k
jízdnímu řádu.
Systém RIS zajistí liniové zobrazení, to musí respektovat skutečnou strukturu vedení linek (včetně
zachování proporcionality vzdálenosti mezi zastávkami) a musí umožnit zobrazení všech vozidel v
dané zastávce.

Modul On-line komunikace:
Modul On-line komunikace zajišťuje On-line přenos dat mezi vozidly a centrální částí systému.
Zajišťuje data pro moduly Dispečink a Vyhodnocování a reporty.

Přenos on-line datových zpráv mezi vozidly a centrálním serverem je realizován prostřednictvím GSM
sítě s výjimkou vybraných zpráv, které slouží zejména k ovládání radiové hlasové komunikace. Ty jsou
přenášeny poradiové síti.
Všechny zprávy jsou ukládány v úložišti serveru BUDIS pro další využití zejména moduly „Dispečink“ a
„Vyhodnocování dat a reporty“.

Všechny zprávy jsou jednoznačně označeny časovou značkou, pořadovým číslemzprávy a aktuální
polohou (kromě zpráv u nichž je poloha definována jiným způsobem).

Komunikaci popisuje následující zjednodušené schema:

                                                    Stránka 17 z 51
Vozidlový SW On-line       BUDIS - Aplikační       BUDIS- modul
     komunikace
                      GSM  server             LAN  Dispečink

                                                    BUDIS - modul
                                                   Vyhodnocování a

                                                         reporty

                           BUDIS - API             LAN / WAN        Externí systémy

Datový přenos vozidlo – server BUDIS

Vozidla odesílají on-line datové zprávy automaticky v nastaveném časovém intervalu, po zadání údajů
řidičem, dle jízdního řádu nebo podle požadavků z dispečerské aplikace:

    - Přihlašovací údaje řidiče a jejich změny,
    - ID vozidla, číslo řidiče, ID kurzu, ID linky, ID cíle, ID směru, ID služby a jejich změny,
    - Poloha vozidla v požadovaném (dynamickém) intervalu,
    - Časový údaj s číslem zastávky o prvním otevření dveří v zastávce (příjezd do zastávky),
    - Časový údaj s číslem zastávky o každém dalším otevření dveří v dané zastávce,
    - Časový údaj s číslem zastávky a aktuálním předjetím/zpožděním při odjezdu ze zastávky,
    - Časový údaj průjezdu definovaným kontrolním bodem s jeho číslem,
    - Definované chybové (alarmové) zprávy,
    - Přenos krátkých stavových (předdefinovaných) zpráv (STATUS),
    - Přenos textových zpráv o délce 140 znaků,
    - Data o čase vypnutí a opětovném zapnutí označovačů jízdenek s příznakem, zda se jednalo

         vypnutí kontrolorem nebo řidičem vozidla,
    - Odhlášení řidiče na konci nebo v průběhu služby.

Vozidla přijímají z dispečerského pracoviště následující on-line datové zprávy:

    - informace o aktivaci definovaných (v PP uložených) objízdných trasách aktivovaných
    - dispečerem,
    - obecná zpráva, jednosměrná komunikace dispečer – cestující ve vozidlech MHD (přímé
    - odeslání textové zprávy na informační panely vozidel MHD s českou diakritikou),
    - dálkové spuštění přednastavených (uložených) hlasových i textových zpráv v salonu vozidla
    - s možností výběru libovolné skupiny vozidel – podle trakce, linky, úseku a výřezu území,
    - přenos krátkých stavových (předdefinovaných) zpráv (STATUS),
    - přenos krátkých textových zpráv o velikosti až 140 znaků české diakritiky (obdoba služby SMS
    - v GSM systémech),

Systém BUDIS zajišťuje přenos vybraných dat – souborů (např. zvukové soubory, videa apod.)
z centrálního úložiště systému BUDIS do vozidel také prostřednictvím GSM sítě (kromě přenosu na

                                                    Stránka 18 z 51
vozovnách prostřednictvím wi-fi sítě). Přenos je založen na tzv. aktualizačních balíčcích připravených
nástroji systému BUDIS a synchronizaci souborů.

Datový přenos - server BUDIS – modul Dispečink a modul Vyhodnocování a reporty

Modul Dispečink a modul Vyhodnocování a reporty čerpají data pro prezentaci z databáze systému
BUDIS pomocí metod pro přístup do databáze poskytovaných aplikačním serverem.

B.2Monitoring plánovaného provozu vozidel pravidelné dopravy a automatické
vyhodnocování odchylek od jízdního řádu(kapitola 3.3 TS)

Systém RIS umožní import jízdních řádů do databáze dopravního dispečinku - data JŘ, rozpisy služeb,
řidičů a vozidel jsou připravovány v interní aplikaci DPKV. Zadavatel před zahájením realizace
poskytne popis struktury dat ve formátu XML.
Systém RIS umožní porovnání reálného provozu s jízdním řádem v reálném čase (s maximální latencí
odpovídající frekvenci přijímaných dat z vozidel).
V případech, kdy dané vozidlo mělo již být podle JŘ v zastávce, ale nedošla z něho zpráva „příjezd od
zastávky“, začne dispečerská aplikace automaticky dopočítávat zpoždění v intervalu 10 sek.
Systém RIS umožní sledování plnění jízdního řádu, kde vyhodnocení aktuální polohy vozidla s jízdním
řádem a informování o odchylce v reálném čase bude vyjádřeno barevnými odstíny s časovým
údajem. Barvy musí být voleny s ohledem na jednoznačnost a možné zkreslení na různých druzích
monitorů a musí být uživatelsky nastavitelné.

B.3 Automatické upozorňování na neplánované a kritické stavy v provozu(kapitola 3.4
TS)

Systém RIS umožní sledování a vyhodnocování návazností spojů podle pravidel zadaných v SW JŘ
nebo s uživatelsky nastavitelnými proměnnými a automatické odesílání zpráv na vozidla při zpoždění
navazujících spojů.
Ohrožené návaznosti budou vyhodnoceny automaticky v definovaných dopravních uzlech nebo
zastávkách a zobrazeny formou upozornění dispečerům.
Systém RIS umožní identifikovat na základě aktuálního zpoždění vozidla a délky vyrovnávacího času
na následující konečné nekonání odjezdu z konečné včas a upozornit dispečera.
Systém RIS umožní upozornit dispečera na nekonaný odjezd z výchozí zastávky.
V případě ohrožení poskytnutí bezpečností přestávky (nebo její zákonné délky), systém RIS musí být
schopen průběžně identifikovat ohrožení poskytnutí bezpečnostní přestávky v následující konečné u
všech vozidel v provozu dle jízdního řádu a upozornit dispečera.
Systém RIS musí umožnit zaslat automaticky generované zprávy na vozidlo dle času a místa, a to jako
aktivaci uložených hlasových hlášení, tak i zobrazení uložených textových zpráv na vnitřní displeje
vozidla a na vnější informační LED panely vozidla.
Systém RIS musí umožnit zadat oprávněnému pracovníkovi formou tabulkového formuláře proměnné,
které mu umožní v dané zastávce a v daném časovém období nastavit pravidla pro sledování
návaznosti spojů. Základními parametry jsou:

                                                    Stránka 19 z 51
a)  poslední známá poloha vybraného spoje vůči jízdnímu řádu,

b)  definice časové odchylky od JŘ, do které je sledovaná návaznost spojů,

c)  definice zastávky, ve které je návaznost sledována,

d)  definice linek/spojů, pro které je návaznost sledována,

e)  časové údaje musí být možné zadat ve formátu hh:mm:ss,

B.4Vzdálené ovládání inteligentních zastávek– integrace(kapitola 3.5 TS)

Součástí předmětu plnění je integrace systému inteligentních zastávek (dále jen „IZ“) pomocí API
rozhraní tak, aby prostřednictvím systému RIS bylo možné ovládat systém IZ. Systém IZ není součástí
předmětu plnění.

Popis funkcí, které budou dostupné z IZ prostřednictvím API:

a)  Systém RIS umožní automatické odesílání informací o předpokládaných odjezdech a to jak

    pravidelných, tak záložních nebo vložených spojů mimo JŘ bez nutnosti (ale s možností)

    zásahu uživatele.

b)  Systém RIS umožní automatické označení odjezdu (textem za cílovou stanicí) „vůz v

    koloně“, pokud vozidlo nezměnilo po stanovenou dobu polohu.

c)  Systém RIS umožní ovládání zobrazování celoplošných (celoobrazovkových) informací.

d)  Systém RIS umožní ovládání spodního řádku pro zobrazování dopravních informací.

e)  Systém RIS umožní zobrazování obrazu kamer IZ, v případě, že konkrétní IZ kameru

    obsahuje.

f)  Systém RIS umožní přímý hlasový vstup dispečera do panelu, nebo skupiny panelů

    (hlášení cestujícím).

g)  Systém RIS umožní sestavení a přehrání hlášení z prefabrikovaných hlášení (nahraných

    zvukových souborů) na panelu nebo skupině panelů.

h)  Systém RIS bude obsahovat datová rozhraní potřebná pro přebírání dat v dohodnutých

    formátech z datového úložiště (zejména off-line jízdní řády).

i)  Systém RIS bude obsahovat datová rozhraní potřebná pro řízení provozu IZ, včetně

    možnosti pro získávání chybových a varovných hlášení.

j)  Systém RIS bude obsahovat datová rozhraní pro řízení zvukového provozu (tvorba

    zvukových záznamů, import zvukových souborů, funkce text-to-speech), včetně

    automatické synchronizace dat mezi IZ a úložištěm zvuků, s možností volby pro časy a

    frekvence synchronizace.

k)  Systém RIS umožní vzdálenou správu IZ (například individuální či hromadná

    parametrizace, hromadná či individuální distribuce různých typů souborů potřebných pro

    provoz IZ, vzdálený restart operačního systému nebo aplikací jedné nebo skupiny IZ

    apod.) včetně sběru informací o IZ, především stavových informací o komponentech

    informačního panelu a jejich provozu, vnitřní a venkovní teplotě, hodnoty osvitoměru,

    aktuálně zobrazovaných informacích a případně o závadách souvisejících s tímto

    zobrazením, (ne)provedení posledních n-operací po panelu požadovaných, použití

    slepeckého hlásiče apod.

                              Stránka 20 z 51
l)  Systém RIS umožní tvorbu a řízení grafických výstupů – na IZ je možné zaslat

    celoobrazovkové nebo grafické informace včetně jednoduchých animací.

m)  Systém RIS umožní střídání jednotlivých obrazovek v uživatelem definovaném cyklu (na

    základě časového kritéria, odjezd konkrétního spoje ze zastávky, vazba na konkrétní text

    dopravní informace na spodním řádku apod.).

n)  Systém RIS umožní správu přednastavení zobrazení dle kalendáře událostí a časové osy

    pro panely, tj. sestavení akustických hlášení, sestavení scénářů pro dispečerský řádek a

    scénářů pro změny obrazovek (sada může obsahovat i kombinaci uvedených typů

    informací).

o)  Systém RIS musí umožnit zadat časové platnosti zobrazované zprávy nebo hlášení, a to

    rozsah „platí od/do data a času“ a v rámci daného rozsahu pak ještě možnost nastavení

    omezení jen na vybrané dny v týdnu. U zvuků a běžících textů musí SW umožnit nastavit

    interval, ve kterém budou informace zobrazeny/přehrány, včetně možnosti nastavení

    kontinuálního přehrávání nebo zobrazení/přehrávání s uživatelsky nastavitelnou mezerou.

p)  Systém RIS musí umožnit dodatečnou editaci sady informací včetně možnosti

    předčasného zrušení, použití vytvořené sady jako šablony pro vytvoření nové sady.

q)  Systém RIS umožní uživatelem definované ovlivnění předpokládaných časů odjezdů

    zejména pro:

•   možnost skrytí jednoho konkrétního spoje/vozidla/linky na části nebo celé trase (SW

    nabídne zastávky po trase) anebo v určitém časovém úseku,

•   možnost stanovení předpokládaného zpoždění v určitém místě nebo úseku,

•   možnost doplnění libovolného textu za název cílové stanice,

•   možnost editace příznaku nízkopodlažního nebo bezbariérově přístupného spoje.

r)  Systém RIS umožní okamžitou aktualizaci dat, s možnosti centrálně řízeného odesílání na

    všechny IZ a odesílání do libovolně volitelných skupin (i do jednotlivých) IZ.

s)  Všechny funkce budou přiměřeně použitelné i pro tzv. virtuální IZ (zastávky, které nejsou

    fyzicky osazeny informačními panely, ale data budou zveřejňována (předávána) jiným

    aplikacím – např. webové nebo mobilní aplikace).

Popis API rozhraní bude dodavateli předán při zahájení etapy č. 1. „Předimplementační analýza“,
protože konkrétní technické řešení API rozhraní bude zadavateli známé až po výběru dodavatele na
systém IZ. V případě, že z důvodů mimo kontrolu zadavatele, nebude možné předat dokumentaci API
rozhraní při zahájení etapy č. 1, bude část předmětu plnění vymezená v této kapitole 3.5 realizována
samostatně, tzn. že se na tuto část plnění nebude vztahovat harmonogram realizace dle čl. 4.3 a
návazné sankce.

B.5Dopřesnění polohy(kapitola 3.6 TS)

Jízdní řád je sestaven z příjezdů a odjezdů vozidel v zastávkách nebo kontrolních bodech (neveřejné
zastávky). V těchto bodech je možné určit aktuální (skutečné) zpoždění.
Funkcionalita systému bude doplněna o výpočet predikovaného zpoždění, který umožní zpřesňovat
aktuální zpoždění na základě pohybu vozidla v mezizastávkovém úseku.

                                                    Stránka 21 z 51
Logika výpočtu bude založena na pevném intervalu 10 sek., přestože vozidla posílají svoji polohu v
dynamickém intervalu 10 sek.

Vypočtená odchylka bude uváděna jako tzv. „predikovaná“ a bude se v systému RIS držet samostatně
od odchylky reálné, jenž bude vycházet z vyhodnocení v zastávce – první otevření dveří příjezd,
poslední zavření dveří a uvedení vozidla do pohybu odjezd. Systém bude robustně dimenzován na
neustálý přepočet zpráv o pozicích ze všech vozidel DPKV s ohledem na aktuální a předpokládaný
budoucí počet vozidel (předpokládá se přibližně 9 000 zpráv na vozidlo a den) a současně umožní
technickým pracovníkům DPKV upravovat zadání pro výpočet až na úroveň jednotlivých linek a
mezizastávkových úseků.

Ve výsledku se bude v jednotlivých modulech systému RIS pracovat s dvojí odchylkou vozidla:

a)  statistika plnění jízdního řádu vychází z údajů reálné odchylky,

b)  vyhodnocování a úprava času pro řízení dopravy (řešení návazností a informace pro IZ) z

    predikované odchylky.

Aplikace umožní i manuální zásah dispečera v modulu anomálií.

Při výpočtu předpokládaných odjezdů, a to nejen z nejbližší následující zastávky, ale i z dalších
zastávek aktuálního linkospoje a linkospojů navazujících v rámci předepsané služby, bude kladen
důraz na:

a)  jízdy vozidel nočních linek – překryv platností jízdních řádů     všední

    den/sobota/neděle/státní svátek,

b)  jízdy tzv. polookružních linek, kdy uprostřed trasy je fiktivní konečná,

c)  zohlednění vyrovnávacích dob na konečné, čekacích dob v průběhu trasy a jízdních dob

    režijních výjezdů, zátahů a přejezdů,

d)  zohlednění skutečných jízdních dob pro danou část a typ dne za poslední (uživatelsky

    definovatelné) období (tzv. „učící režim“),

e)  polohu vozidla v mezizastávkovém úseku včetně situace, kdy vozidlo za uživatelem

    definovaný čas nezměnilo svoji GPS polohu o více než maximální hodnotu stanovenou

    uživatelem.

Při předání (zobrazení) vypočítaných dat o předpokládaných odjezdech systém RIS umožní uživatelem
definovanou eliminaci předpokládaných předčasných odjezdů (odjezd dříve, než stanoví jízdní řád) s
ohledem na předpokládané vyčkání vozidla do času odjezdu v nejbližší zastávce.

Výpočet a zobrazení předpokládaných odjezdů bude prováděno nejen u vozidel zajišťujících v rámci
svojí služby předepsané odjezdy, ale také u vozidel posilových spojů a spojů náhradní dopravy
neuvedených v jízdním řádu a řazených operativně.

Hodnota pro zaokrouhlování predikovaného zpoždění na celé minuty (např. do 30 sek. „dolů“, od 30
sek. „nahoru“) bude uživatelsky nastavitelný parametr.

Vstupní údaje, parametry a algoritmus výpočtu mohou být ze strany zadavatele přiměřeně změněny
v závislosti na skutečnostech (nap. na základě dodavatelem navržené datové struktury) zjištěných v
průběhu přípravy realizace (předimplementační analýzy).

B.6Nástroje pro zpětný monitoring provozu a statistické vyhodnocení dat(kapitola 3.7
TS)

                                                    Stránka 22 z 51
Systém RIS bude archivovat přenášená data o provozu vozidel dopravy minimálně 24 měsíců.

Systém RIS bude umožňovat exporty dat z databáze a statistické vyhodnocení provozu (realizovaného
dopravního výkonu) jednotlivých linek nebo jednotlivých kurzů na základě volitelných parametrů
(např. časové období, místa, řidiče apod.) ve formátu umožňujícím další zpracování běžným
kancelářským SW (formát .xlsx apod.):

a)  dodržení jízdních dob (na linkách, v mezizastávkovém úseku apod.),

b)  vyhodnocení průměrné cestovní rychlosti,

c)  odjezdy podle jízdního řádu (podle linek, zastávek),

d)  odchylky od jízdního řádu,

e)  využití zastávek na znamení,

f)  výkony řidičů,

Systém RIS bude umožňovat automatické zasílání denního reportu na emailové adresy vybraných
uživatelů.

B.7Systém dálkového nahrávání a vyčítání dat na vozovnách(kapitola 3.8 TS)

Součástí systému RIS je i systém pro nahrávání i vyčítání (obousměrná komunikace) dat ve vozovnách
(off-line data), to bude umožněno automaticky i manuálním povelem. Systém umožní aktualizaci
celého vozového parku v rámci odstavné doby vozidla na provozovně.

Definice a nastavení přenosů dat pro vozidla bude realizováno pomocí klientských pracovišť. Budou-
li k přenosu připravena platná data pro vozidlo, bude zahájen jejich přenos. Následně, budou-li ve
vozidle přítomna data, bude zahájen i jejich přenos a to zcela automaticky.

Systém bude uživateli poskytovat minimálně následující informace o průběhu nahrávání dat do
vozidlových jednotek:

a)  aktuální stav (vozy, verze, rozsah nahraných dat),

b)  avízo o nenahraných vozech k času „nejpozději“,

c)  možnost označení nenahraného vozu (např. „odstaveno“),

d)  možnost opakovaného pokusu o nahrávání systému pomocí Wi-Fi,

e)  možnost zadání informace o manuálním nahrání (použití USB),

f)  historie nahrávání dle vozů,

g)  logování uživatelských zásahů do řídícího SW (vkládání dat, změny, apod.),

Systém bude umožňovat řízení uživatelského přístupu alespoň s těmito úrovněmi

a)  Čtenář - s nejnižším stupněm oprávnění - je mu umožněno prohlížení listu vozidel.

    Nemůže provádět změny.

b)  Editor - se střední úrovní oprávnění, oproti čtenáři je oprávněn spravovat data v rámci

    vozovny (např. správa listu vozidel vozovny).

c)  Správce - správce aplikace s možností provádět přípravu dat, nahrávání dat do všech

    vozidel DPMB, definovat profily a spravovat listy všech vozidel.

                                  Stránka 23 z 51
d)           Admin - IT administrátor - nejvyšší stupeň oprávnění, v jeho kompetenci je správa

             systému a přidělování oprávnění.

Systém umožní práci s daty, se kterými pracují komponenty ve vozidle (firmware, data, jízdní řády,
hlášení, panely atd.). Verze firmwaru a dat jednotlivých komponent budou pro zajištění funkcionality
použity ve správné kombinaci verzí. Je důležité, aby data obsahovala vzájemně kompatibilní verze
firmwarů a dat komponent RIS. Data mohou být definována a umístěna do systému pouze
uživatelem s oprávněním minimálně Správce.

Systém umožní práci s profily, kdy jsou jednotlivá vozidla přiřazena k definovaným profilům. Profil
definuje v daném časovém okamžiku aktuálně platná data vozidla a dále volitelně příští data pro
přenos do vozidla.

Uživatel bude mít možnost pomocí filtru zobrazit list vozidel podle zvolených pravidel, filtrovat lze
podle položek listu vozidel:

a)           číslo vozovny,

b)           číslo vozu,

c)           aktivní (např. zobrazit pouze vozidla v dosahu Wi-Fi sítě),

d)           režim (např. zobrazit pouze vyřazená vozidla apod.),

e)           profil (např. zobrazit pouze vozidla s profilem XYZ),

f)           stav aktualizace (sledování aktuálnosti Dat ve vozidle/připravená Data k aktualizaci),

g)           možnost u konkrétních vozidel zablokovat aktualizaci Dat proti přehrání „DŘÍVE NEŽ“ a

             možnost aktualizace jen pro toto vozidlo (např. zvláštní jízdy apod.)

h)           možnost zobrazení jedné velké přehledové tabulky po vozidlech s verzemi dat dle

             jednotlivých komponent,

i)           možnost exportních sestav,

j)           historie aktualizací (např. denní přehled, archiv časů přehrání databází jednotlivých

             vozidel apod.).

Po připojení k Wi-Fi infrastruktuře vozovny proběhne kontrola aktuálnosti dat. V případě připravené
nové aktualizace dat proběhne jejich aktualizace dle následujících priorit (zadavatel požaduje
možnost pořadí priorit uživatelsky měnit a to jak pro všechna vozidla, tak pro skupiny vozidel -
vozovna, uživatelsky definované skupin apod., nebo pro jednotlivá vozidla v listu vozidla):

    Do vozu

a)           data JŘ,

b)           prodej jízdenek (vstupy),

c)           prodej jízdenek (výstupy),

d)           data hlásiče,

e)           panely,

f)           verze SW/FW (palubní počítač, ostatní komponenty),

g)           další textové a grafické soubory (např. návody k obsluze, informace pro řidiče, mapové

             podklady apod.),

h)           videosekvence pro LCD.

    Z vozu

                                         Stránka 24 z 51
a)  log dopravních událostí,

b)  log kritických událostí,

c)  log palubního systému,

d)  radiový log,

e)  dopravní a přepravní průzkumy,

f)  aktivní preference – chybový protokol (průjezdy dle přihlašovacích bodů v JŘ s

    chybnou nebo žádnou odezvou systému aktivní preference) – do tabulky,

g)  tržby z prodeje jízdenek,

h)  stavová a chybová hlášení funkce RIS – do tabulky

i)  záznam z kamer (výhledově),

Systém pro řízení nahrávání/vyčítání dat umožní označení povinných dat, bez jejichž aktualizace je
vozidlo „nenahrané“.

                                 Stránka 25 z 51
Základní popis procesu off-line přenosů do / z vozidla
    Základní schema off-line přenosů dat do / z vozidla je znázorněno pomocí následujícího

diagramu:

                                                    Stránka 26 z 51
      Zdoje dat                            BUDIS server           BUDIS vozovna           Palubní systém
   «datastore»                          Import dat ze zdrojů
Externí zdroje dat                                                03 Příprava dat pro            04 Přenos
   «datastore»                             01 Automatické             kolekci vozů        aktualizačního balíčku
Interní zdroje dat                            vytvoření
                                                                                                  do vozu
   «datastore»                          aktualizačního balíčku
 Externí systém                                                                           05 - Aktualizace
                                         02 Ruční vytvoření                                 zařízení vozu
     sledování                          aktualizačního balíčku
                                                                  07 Přenos logů na        06 Vytvoření
                                         08 Sledování procesu       server BUDIS          přenosových,
                                        aktualizace a stavů vozů                          aktualizačních,
                                                                                            dopravních,
                                        Sledování dopravních a                            provozních logů
                                         provozních parametrů

                                                                       09 Manuální        10 Manuální načtení
                                                                         vytvoření        aktualizačního balíčku

                                                                  aktualizačního balíčku        z USB disku
                                                                       na USB disku

                                                                     12 Manuální          11 Manuální uložení
                                                                  načtení logů z USB        logů na USB disk

                                                                          disku

Name: BUDIS - Off-line Update Model CZ
Author: jsmejkal
Version: 1.0
Created: 02.05.2018 10:43:29
Updated: 02.05.2018 10:44:05

Import dat ze zdrojů

                                        Stránka 27 z 51
    Rozhraní systému BUDIS zajišťující automatický (nebo na vyžádání) import dat pro informační
    systém vozu – zejména z interní aplikace DPKV, případně z jiných datových zdrojů, jejich
    transformaci do formátu palubního počítače společnosti Bustec s.r.o. a uložení do datového
    úložiště serveru BUDIS.

    Interní zdroje dat:
    Dalšími zdroji dat pro vozidlový systém mohou být například:
    - SW nástroje společnosti Bustec s.r.o. pro pořízení a správu dat pro vozidlové informační

         panely
    - SW nástroje společnosti Bustec s.r.o. pro správu zájmových bodů
    Systém BUDIS bude případně doplněn o další rozhraní zajišťující přenos dat z dalších zde
    nespecifikovaných zdrojů, pokud budou tyto zdroje použity.

01 Automatické vytvoření aktualizačního balíčku

    Funkce systému BUDIS zajišťující automatické vytvoření a naplánování aktualizačního balíčku.
    Funkce navazuje na funkci 10 BUDIS server: Data import. Balíček je připraven dle
    přednastaveného profilu vztaženého k typu aktualizačních dat (např. jízdní řády lze aktualizovat
    pravidelně automaticky každý den nebo na vyžádání operátora dle profilu). Systém BUDIS
    umožňuje určit pořadí aktualizací vozů nastavením parametrů pro přenosy (výběr trakce, výběr
    vozovny, výběr skupiny vozů, výběr jednotlivých vozů) dle požadavků zadávací dokumentace a
    prováděcí dokumentace. Aktualizační balíček je uložen v úložišti serveru BUDIS. Balíček obsahuje
    aktualizační soubory ve vazbě na odpovídající zařízení vozu, výčet vozů dle vozoven, datum
    začátku platnosti, případně další data zajišťující prioritu provedení aktualizací dle příslušného
    profilu nebo ručního nastavení.

02 Ruční vytvoření aktualizačního balíčku

    Funkce systému BUDIS zajišťující ruční sestavení, vytvoření a naplánování aktualizačního balíčku.
    Operátor vybírá aktualizační soubory, příslušná zařízení dle konfigurace (vybavení vozu) a seznam
    vozů. Určuje datum a čas začátku platnosti a případně a další priority. Systém BUDIS umožňuje
    určit pořadí aktualizací vozů nastavením konfigurace (výběr trakce, výběr vozovny, výběr skupiny
    vozů, výběr jednotlivých vozů, určení akzuálně platných dat – souborů, určení připravených dat s
    paltností v budoucnosti, určení času spuštění aktualizace). Funkce bude vyhovovat požadavkům
    zadávací dokumentace. Funkci lze využít zejména pro aktualizace na vyžádání (např. aktualizace
    FW). Aktualizační balíček je uložen v úložišti serveru BUDIS.

    Funkce je určena zejména pro přenos dat typu:

    - Data hlásiče
    - Data a SW pro panely
    - FW zařízení vozidel
    - Multimediální a řídící soubory pro LCD panely
    - další soubory potřebné pro prostředí vozidlového IS (návody, pokyny pro řidiče apod.)

    Systém BUDIS je připraven pro přenos jakýchkoliv souborů do prostředí vozidlového IS, které jsou
    předem vytvořeny a zařazeny do aktualizačního balíčku.

03 Příprava dat pro kolekci vozů

                                                    Stránka 28 z 51
    Funkce systému BUDIS – komponenta BUDIS Vozovna zajišťující přenos aktualizačních balíčků
    z centrálního úložiště serveru BUDIS do dočasného úložiště vozovny a jeho transformaci do
    formátu potřebného pro PP. Funkce pracuje automaticky v prostředí PC vozovny v nastavených
    intervalech nebo ji lze spustit na vyžádání. Funkce připraví aktualizační data pro seznam vozů
    zajíždějících do příslušné vozovny případně rozdělený do skupin dle připraveného balíčku
    (profilu).

04 Přenos aktualizačních dat do vozu

    Funkce Vozidlového SW: Přenos off-line dat z vozovny do vozidla je prováděn automaticky po
    příjezdu vozidla do určené vozovny prostřednictvím wi-fi sítě vozovny (nebo GSM) podle
    nastavené konfigurace. Komunikaci zahajuje automaticky Vozidlový SW. Pokud jsou v úložišti
    Vozovny připravena nová data pro příslušný vůz, proběhne přenos dat do prostředí vozu. Proces
    přenosu dat do prostředí vozu poskytuje zpětně přenosový log.

    Automatický off-line přenos dat do / z vozu je možné opakovat v případě neúspěšného průběhu.

05 Aktualizace zařízení vozu

    Funkce Vozidlového SW navazující na funkci „04 Přenos dat do vozu“. Funkce zajišťuje
    vyhodnocení datumu začátku platnosti aktualizačních souborů. Pokud nastane datum platnosti,
    funkce provede distribuci aktualizačních souborů v rámci prostředí vozu a spuštění příslušných
    aktualizací pomocí řídícího souboru. Proces poskytuje zpětne aktualizační log.

06Vytvoření logů

    Funkce Vozidlového SW zajišťující vytvoření přenosových a aktualizačních logů a jejich uložení
    v prostředí vozidlového systému.

07 Přenos logů na server BUDIS

    Funkce systému BUDIS zajišťující přenos logů (přenosový log, aktualizační log) z úložiště
    palubního počítače přes server vozovny do centrálního úložiště BUDIS serveru. Pokud jsou v
    prostředí vozu připraveny další logy a soubory jako např.:

    - Logy dopravních událostí
    - Logy kritických událostí
    - Logy vozidlového systému
    - případně další soubory dle požadavků a technických možností,

    jsou přeneseny přes úložiště vozovny na server BUDIS.

08 Sledování procesu aktualizace stavů vozu

    Funkce systému BUDIS (App serveru a Win klienta) poskytující nástroje pro sledování průběhu a
    stavu aktualizací a pro sledování stavu vozů a sledování stavu aktualizačních balíčků. Jednotlivé

                                                    Stránka 29 z 51
    stavy jsou barevně odlišeny, funkce poskytují rozsáhlé možnosti filtrace a uspořádání dat včetně
    uživatelsky definovaných filtrů.

    Funkce sledování stavu aktualizací a stavu vozidel poskytuje zejména následující informace:

    - Aktuální přehled stavu procesu přenosu dat a aktualizací zařízení (rozsah provedených
         aktualizací, stav k plánovanému času dokončení, přenesená data včetně verzí)

    - Aktuální přehled stavu vozů a jejich zařízení (celkový stav vozu, stavy zařízení, verze dat)
    - Historie všech provedených aktualizací
    - Historie průběhu aktualizací

    Aplikace BUDIS umožňuje vyřadit z procesu aktualizace určené vozy (např. Nenahrané vozy).

    Logy přenesené na centrální server BUDIS mohou být dále využity jako zdroj dat pro Sledování
    dopravních a provozních parametrů a přes odpovídající API mohou být využívány Externími
    systémy sledování.

09 Manuální vytvoření aktualizačního balíčku na USB disk

    Funkce systému BUDIS zajišťující ruční vytvoření dat pro PP na tzv. „USB klíčence“. Jde o USB disk
    na kterém jsou uloženy potřebné aktualizační soubory a řídící soubor určující PP práci s daty. USB
    disk je ručně přenesen do příslušných vozidel. vozidla a vložen odpaPP příslušného vozu a je
    ručně spuštěn import dat. Vozidlový SW zajišťuje i v tomto případě korektní návratové přenosové
    a aktualizační logy. Využití funkce se předpokládá v situaci selhání wi-fi sítě nebo v případě
    naléhavé potřeby.

10 Manuální načtení aktualizačního balíčku z USB disku

    Funkce načte data z vloženého USB disku a uloží je do úložiště palubního počítače. Zde je spuštěn
    standardní aktualizační proces – 05 Aktualizace zařízení vozu včetně příslušného logování.

11 Manuální uložení logů na USB disk

    Logy vytvoření v prostředí palubního počítače lze uložit také na USB disk a manuálně přenést na
    vozovnu (případně centrální server).

12 Manuální načtení logů z USB disku

    Logy lze manuálně načíst z USB disku do prostředí BUDIS vozovna a odtud jsou dále přeneseny na
    centrální server.

B.8Systém sledování a vyhodnocování provozních dat(kapitola 3.9 TS)

Systém sledování a vyhodnocování provozních dat umožní alespoň následující funkce:

a)  automatické vyhodnocování ujetých km v členění na typ výkonu,

b)  vyhodnocení zadaných parametrů vyčtených z vozidel po příjezdu do vozovny,

    Stránka 30 z 51
c)  na základě logů GPS poloh vyčtených z paměti palubního počítače nad mapou správu

    (nastavení nebo korekci) zájmových bodů DPKV.

K zájmovým bodům patří zejména:

a)  body pro realizaci preference na světelných křižovatkách,

b)  body pro vyhlašování doplňkových informací cestujícím,

c)  přihlašovací body zastávek,

d)  body pro změnu nastavení palubní informatiky,

e)  body pro kontrolu vyhlášení zastávky (aktuálně je používáno dveřní kritérium),

f)  další body, které může zadavatel definovat později.

Systém umožní ověření správnosti zadaných bodů a funkčnosti simulací jízdy vozidla na mapovém
podkladu na zkušebním pracovišti před uložením dat do palubních počítačů vozidel.

Systém umožní ukládání záznamů (Log) dopravních událostí. Do tohoto logu budou zapisovány údaje
související především s dopravními informacemi o lince. Perioda zápisů, které nejsou vztaženy ke
konkrétnímu úkonu, bude 0,5 sek. (uživatelsky definovatelný parametr):

a)  ID vozidla

b)  skutečná poloha dle GPS,

c)  aktuální rychlost (dle GPS) a azimut,

d)  linka/kurz/směr/cíl (pouze při změně),

e)  ujetá vzdálenost (na základě GPS),

f)  vyhlášení aktuální zastávky/čas otevření dveří,

g)  uzavření dveří/vyhlášení následující zastávky,

h)  vyslané požadavky do řadičů SSZ a přijaté odezvy,

i)  práce řidiče s terminálem (přihlášení do systému, hovorová a datová komunikace, ruční

    posun zastávky),

j)  výpadky a poruchy jednotlivých komponent palubního systému,

B.9Sledování ujetých kilometrů(kapitola 3.10 TS)

Sledování ujetých kilometrů pro jejich vykazování dle požadavků zadavatele (linkové, manipulační,
komerční, režijní, atd.) požaduje zadavatel zajistit v rozsahu definovaném následujícím schématem.
Dělení (označení) trasy bude v souladu s režimem jízdy zadaným v palubním počítači:

a)  Stání vozidla na odstavné ploše - počáteční km

b)  Pohyb vozidla z odstavné plochy - manipulační km

c)  Výjezd vozidla z vozovny na linku - výjezdové km

d)  Začátek výkonu na lince dle JŘ - linkové km

e)  Přejezd vozidla na jinou linku - přejezdové km

f)  Začátek výkonu na (nové) lince dle JŘ - linkové km

                                 Stránka 31 z 51
g)  Konec výkonu na lince dle JŘ - zátahové km

h)  Příjezd vozidla do vozovny - manipulační km

i)  Odstavení vozidla (tankování, prohlídka, mytí apod.)

V případě zkušebních, komerčních a dalších druhů jízd vozidel MHD se uplatní přiměřeně výše
uvedený princip s využitím dalších kategorií provozních km.

Zdroje dat pro sledování kilometrů:

a)  data z palubního počítače (jízdní řád, GPS poloha, odjezd ze zastávky),

b)  data o službách řidičů a vypravení vozidel.

U vozidel, kde nemá palubní počítač k dispozici data z tachografu nebo CAN sběrnice lze pro
výjezdové, přejezdové, linkové a zátahové km využít skutečnosti, že všechny mezizastávkové
vzdálenosti sítě MHD jsou změřeny kalibrovaným měřidlem a na základě informací o odjezdech
ze zastávek je možné přiřadit vzdálenosti k jednotlivým úsekům, případně je možné využít data z GPS.

Vyhodnocení dat - pro potřeby vyhodnocení budou z vozidel přenášena následující data:

a)  číslo vozu (základní údaj),

b)  datum a čas přihlášení a odhlášení řidiče,

c)  zadaný kurz,

d)  číslo řidiče,

e)  ujeté km dle typu výkonu a druhu dopravy,

f)  časové a polohové údaje potřebné k definici jednotlivých úseků.

Statistické výstupy budou poskytovány min. do MS Excel (verze bude upřesněna v Realizačním
projektu), s možností filtrování nadlimitních hodnot, možností řazení dle jednotlivých kritérií,
statistika km dle vozu, linky, řidiče.

Modul vyhodnocování dat a reporty:

Vyhodnocování dat z vozů je jeden z modulů systému BUDIS. Do systému jsou načítány jak on-line
zprávy tak off-line logy načítané po příjezdu vozu na vozovnu.

Systém BUDIS obsahuje kompletní nastavení logovacího podsystému PP. Pomocí konfigurace lze určit
jaká data a v jakých situacích (uplynutí časové prodlevy, událost, …) budou zasílána buď datovými
přenosy nebo ukládány do off-line logů. Konfigurace vytvořená v systému BUDIS je přenášena na PP,
který podle konfigurace provádí požadované operace. Konfigurace bude umožňovat nastavení všech
parametrů sběru a kategorizace dat požadovaných v ZD, pokud to technické prostředky vozidel
umožní.

Vyhodnocovací část obsahuje funkcionalitu pro automatické vyhodnocování definovaných mezních
hodnot. Toto nastavení je navázáno na konfiguraci logovacího modulu. Nasbíraná data (z on-line
přenosů a off-line logů) lze snadno filtrovat a procházet podle všech parametrů, které jsou součástí
systému BUDIS a ke kterým mají k logovaným datům logický vztah (např. linka, vozidlo, lokalita,
časové období, typ informace, apod.). Data lze zobrazit společně s pohybem vozů i v mapové části
aplikace. Rychlost animace lze měnit dle potřeby.

                                     Stránka 32 z 51
Klient systému BUDIS umožňuje uživateli přizpůsobení přehledů (gridů) svým potřebám – nastavení
požadované filtrace, doplněním, vyřazením, přeskupením sloupců v přehledů, nastavením seskupení.
Pro úlohy, které není již možné pokrýt těmito standardními nástroji gridů nabízí klient BUDIS tvorbu
uživatelských reportů pomocí standardní komponenty Reporting prostředí DevExpress. Komponenta
umožňuje snadno sestavit report určením datového zdroje, sestavením layoutu reportu, určením
setřídění a seskupení atd.

B.10Architektura systému(kapitola 3.11 TS)

Systém RIS bude používat třívrstvou architekturu, tzn. aplikační logika bude implementována na
úrovni aplikačního serveru (bude tedy jednotná pro všechny klienty), data budou ukládaná
v databázi, pro ovládání systému bude k dispozici klient (dispečerská aplikace). Systém “BUDIS”
používá následující vrstvy:

    • Databázová vrstva: je reprezentována databázovým serverem zajišťujícím uložení a výběry
         popisných strukturovaných dat. Dodaný databázový server bude typu Microsoft SQL server.

    • Aplikační vrstva: je reprezentována aplikačním serverem obsahujícím většinu aplikační logiky.
         Tuto společnou logiku využívají klienti BUDIS.

    • Prezentační vrstva: je reprezentována klientem BUDIS poskytujícím GUI pro prezentaci dat a
         využívajícím aplikační server.

    • Externí systémy: externí systémy přistupují k datům a funkcím systému BUDIS přes API, které
         je součástí aplikační vrstvy aplikačního serveru.

    • Vozidlové systémy: vozidlové systémy komunikují se systémem BUDIS obousměrně přes API
         aplikačního serveru BUDIS.

Datová vrstva: BUDIS databázový server                   Externí systémy
 Aplikační vrstva: BUDIS aplikační server               Vozidlové systémy

     Prezentační vrstva: BUDIS klient

Name: BUDIS System Architecture - CZ
Author: jsmejkal
Version: 1.0
Created: 26.04.2018 16:43:39
Updated: 26.04.2018 16:44:33

                                       Stránka 33 z 51
Systém RIS bude konstruován modulárně, realizací dodatečných modulů bude možné postupně
rozšiřovat funkce systému (serverové i uživatelské části) bez nutnosti přestavby celého řešení.

Jednotlivé moduly uživatelského rozhraní budou moci být spuštěny nezávisle na sobě na více
počítačích zároveň.

Systém RIS bude zabezpečen proti neoprávněnému přístupu k datům a jednotlivým částem systému
implementací standardních uživatelských práv.

Systém RIS umožní dodatečné rozšíření o sledování dalších vozidel, bez omezení počtu.

Systém RIS bude obsahovat rozhraní API, které umožní definovaným způsobem komunikovat s
dalšími systémy a aplikacemi. Rozhraní API umožní poskytování dat třetím stranám a to ve variantách
průběžné publikace dat nebo publikace na dotaz třetí strany. Přesná struktura výstupů bude
dohodnuta se zadavatelem v rámci předimplementační analýzy v závislosti na dodavatelem zvoleném
řešeních jednotlivých součástí systému. Zadavatel musí být schopen a oprávněn na základě předané
API dokumentace realizovat sám, nebo prostřednictvím třetí strany využití funkcí systému RIS. V
případě pochybností ohledně API rozhraní je zadavatel oprávněn nechat posoudit úroveň a rozsah
předávané API dokumentace nezávislou autoritou.

Systém RIS umožní archivaci veškerých datových údajů minimálně 24 měsíců, postupné umazávání
dat je možné s výjimkou dat označených příznakem nehodové či jiné nestandardní události – tato
data bude možné odmazat až na příkaz zmocněného pracovníka zadavatele.

Dispečerský klient umožní monitorování a řízení celého systému v jednotném a přehledném
graficky orientovaném uživatelském prostředí. Uživatelské rozhraní bude snadno ovladatelné,
intuitivní a přehledné. Aplikace dispečerského klienta budou provozované na PC (není součástí
předmětu plnění) s OS kompatibilním se stávající platformou DPKV. Dispečerský program umožní
„profilování“ – tj. každému klientovi se na libovolném klientském PC zobrazí po přihlášení takové
nastavení oken, sloupců, filtrace atd., jaké bylo nastaveno při jeho předchozím odhlášení.

Dispečerský klient umožní na základě polohy vozidla (nebo místa v mapě) a vybraného typu události
zobrazit nabídku vhodných dopravních opatření a nabídku jejich realizace (např. odeslání zpráv na
palubní počítač, přenastavení palubního počítače apod.). Strukturovaná nabídka dopravních opatření
bude uživatelsky editovatelná, aby ji bylo možné za provozu uživatelsky rozšiřovat.

Dispečerský klient bude poskytovat následující základní pohledy:

a)  Grafická část (mapa) - sledovaná vozidla budou zobrazena nad referenčním mapovým

    podkladem (plán linek, plán města, ortofotomapa), standardní funkčnost zahrnuje

    nástroje pro pohyb v mapě, změnu měřítka, zobrazení předdefinovaných výřezů, změnu

    referenční vrstvy, volbu zobrazovaných objektů a vyhledání vozidla.

b)  Liniové zobrazení - sledovaná vozidla budou seřazena dle jednotlivých linek s

    proporcionálním zobrazením (dle jízdní doby a vzdálenosti zastávek) rozmístěna na

    trasách jednotlivých linek.

c)  Tabulková forma - seznamy vozidel budou poskytovat přehledové i podrobné informace,

    zobrazená data bude možné filtrovat a řadit podle sledovaných parametrů (trakce,

    odchylka od jízdního řádu apod.).

Jednotlivé typy zobrazení (všechna okna) spolu vzájemně korespondují a dodržují jednotnou
symboliku a pravidla pro zobrazení jednotlivých typů událostí a objektů (např. barevné rozlišení typu
vozidla, zařazení do skupiny apod.). Zobrazení bude funkčně provázané (např. v mapě bude možné
vybrat vozidla a pro ně následně vyvolat podrobné informace v tabulkovém nebo liniovém zobrazení
apod.).

Obrazovka liniového zobrazení umožní alespoň následující:

                                 Stránka 34 z 51
a)  liniové zobrazení se zobrazením informací o spojích,

b)  liniové zobrazení bude odpovídat skutečné vzdálenosti mezi zastávkami,

c)  za kurzem se bude uvádět i odchylka od JŘ s víceúrovňovým barevným odlišením (min. 3

    hodnoty pro předjetí, 3 hodnoty pro zpoždění, včas dle JŘ – shodné s obrazovkou

    mapového podkladu),

d)  po označení vozidla se zobrazí další informace: dle hlavní obrazovky včetně možnosti

    okamžitého zahájení hovoru s označeným vozidlem, možnosti odeslání předdefinované

    nebo dispečerem napsané zprávy, zobrazení jízdního řádu včetně historie vztahu vozidla k

    jízdnímu řádu,

e)  slučování souhlasných směrů v jeden dominantní (základní) s odbočkami z něj,

f)  možnost volit mezi horizontálním a vertikálním zobrazením,

g)  grafické odlišení definovaných skupin speciálních vozidel.

Obrazovka mapového podkladu umožní alespoň následující:

a)  možnost přepnutí zobrazení mapa/ortofotomapa,

b)  zobrazení vozidel včetně zobrazení v barevném schématu dle nastavení, s víceúrovňovým

    barevným odlišením (min. 3 hodnoty pro předjetí, 3 hodnoty pro zpoždění, včas dle JŘ –

    shodné s obrazovkou liniového podkladu),

c)  identifikace vozidla na mapě: číslo vozu/linka/kurz/odchylka od JŘ v minutách,

d)  po označení vozidla se zobrazí další informace: dle hlavní obrazovky včetně možnosti

    okamžitého zahájení hovoru s označeným vozidlem, možnosti odeslání předdefinované

    nebo dispečerem napsané zprávy, zobrazení jízdního řádu včetně historie vztahu vozidla k

    jízdnímu řádu,

e)  zobrazení všech nebo vybraných linek (výběr linek podle typu) nebo podle individuálně

    nastavitelného filtru),

f)  vymezení požadované oblasti na mapě,

g)  možnost definice průjezdných bodů objízdné trasy (křižovatka, výhybka) a jejich odeslání

    na vozidlo,

h)  zobrazení grafického měřítka pro každé z možných měřítek mapy ve vhodných jednotkách

    (m, příp. km),

i)  změna měřítka mapy v krocích kolečkem myši,

j)  posun mapy uchopením (levé tlačítko nebo kolečko myši),

k)  sledování aktuálně vybraného vozidla,

l)  zobrazení dalších vrstev nad mapou:

    • linky, zastávky,

    • výluky a aktuální provozní omezení,

    • jízdenkové automaty,

    • elektronické informační panely, inteligentní zastávky a další obdobná
        zobrazovací zařízení,

    • řízené křižovatky,

                             Stránka 35 z 51
m)  mapový klient bude připraven i na rozšíření zobrazovaných funkcí, které vzniknou s

    propojením s dalšími dispečinky (hustota a události v dopravě, informace o průjezdu

    sypačů apod.),

n)  mapový klient bude připraven na možnost záznamu dočasných nebo trvalých změn

    provedených operativně uživatelem a to ve všech výše uvedených vrstvách.

Podokna úloh - všechny obrazovky dispečerského klienta budou obsahovat nástrojovou lištu, která
umožní dispečerům v jednotlivých modulech (tabulkové, mapové nebo liniové zobrazení) nastavovat
požadované filtry nebo parametry jednotlivých funkcí, alespoň v rozsahu:

a)  tabulka pro nastavení pravidel pro odesílání zpráv navazujícím spojům,

b)  nastavení filtrů pro zobrazení vozidel: ID vozidla, typ vozidla, linka, kurz, řidič, zastávka,

    přihlášené vozy, nepřihlášené vozy, zpožděná/předjetá vozidla, zpožděná/předjetá vozidla

    nad stanovenou mez (mezní hodnota konfigurovatelná nejméně s přesností na 10

    sekund),

c)  tabulkový výpis vozidel,

d)  možnost zobrazit jízdní řád daného kurzu - tato funkce musí být umožněna i v menu pod

    pravým tlačítkem myši při označení konkrétního vozidla,

e)  filtr STATUSových zpráv,

f)  dispečerský deník (poznámky dispečerů k vozidlům nebo událostem),

g)  vytváření dynamických skupin s možností výběru volání/odeslání zprávy,

h)  vytváření scénářů pro odesílání zpráv (typy zpráv, obsah, mailové adresy),

i)  vytváření scénářů pro automatické informování dispečera o anomáliích (např. předčasný

    odjezd ze zastávky, zpoždění nad stanovenou mez, ztráta komunikace po dobu delší než

    stanovenou apod.)

j)  dohled nad funkčností vozidlových komponent,

k)  okno pro nastavení parametrů statistických výstupů (linka, úsek, zastávka, datum, čas,

    předjetí, zpoždění, ostatní anomálie)

l)  volba cíle hlášení dispečera (řidič/salon vozidla/vně vozidla) - tato funkce musí být

    umožněna i pod pravým tlačítkem myši při označení konkrétního vozidla nebo skupiny,

m)  okno datové komunikace s vozidlem pro možnost odeslání textu na jednotlivé

    zobrazovače a nastavení palubní informatiky vozidla,

Spuštění vybraných modulů SW centrálního dispečinku na externím PC bude možné individuálně
povolit pro každého uživatele (např. v režimu čtenář/omezený přístup/bez omezení).

Modul Textové a datové zprávy:

Modul Textové a datové zprávy zajišťuje vybrané funkcionality pro modul Dispečink.

Modul Textové a datové zprávy umožňuje výměnu textových a datových zpráv mezi vozidly a
dispečinkem. Modul rozlišuje textové zprávy nevyžadující potvrzení a textové zprávy vyžadující
potvrzení. Součástí modulu jsou také datové zprávy odesílané jak z vozidla do dispečinku tak z
dispečinku do vozidla. Specifickou kategorií datových zpráv jsou emergency zprávy a chybové zprávy.
Modul vyžaduje provedení výchozí konfigurace dle konkrétní implementace.

                                                    Stránka 36 z 51
Základní funkce poskytované tímto modulem:
    - Správa předdefinovaných textových a datových zpráv,
    - Odeslání textové a datové zprávy z centrálního pracoviště vybraným vozům,
    - Sestavení a odeslání ad-hoc textové zprávy dispečerem,
    - Odesílání datových (telemetrických) zpráv z vozidel do centra,
    - Centrální přehledy textových a datových zpráv.
    - Upozornění na nedodržování rychlostních limitů,
    - Odesílání chybových zpráv vz vozidel
    - Přehledy zpráv v dispečinku dle jednotlivých kategorií a dalších filtračních možností.
    - Propojení textových a datových zpráv s moduly dispečinku,
    - Potvrzování textových zpráv řidičem,
    - Konfigurace telemetrických zpráv a předdefinovaných textových zpráv dle konkrétních
         požadavků
    - Specifické možnosti filtrace a sestavení přehledů zpráv dle konkrétních požadavků.

Ukázky GUI modulu určeného pro správu Textových a datových zpráv:

        Obr. 4: Výběr skupiny cílových vozidel pro odeslání zprávy pomocí tzn. Bounding boxu:

        Obr. 5: Výběr textové zprávy ze seznamu předdefinovaných zpráv( zprávy ze šablony):
        Zprávy jsou rozšířeny o možnosti multimediálního obsahu (audio, video)

                                                    Stránka 37 z 51
        Obr. 6: Sestavení nové textové zprávy “ad-hoc”:

Modul Administrace, správa uživatelů a přístupových práv:
Modul Administrace, správa uživatelů a práv zajišťuje následující základní funkcionality:

    • Správu uživatelů
    • Správu přístupových práv

                                                    Stránka 38 z 51
    • Správu vozidel a jejich zařízení
    • Nastavení rozsahu a četnosti logování dat
    • Konfigurace on-line přenosů, textových a datových zpráv
    • Správu centrálních serverových procesů
Uživatelé přistupují k funkcím a datům systému přes GUI klientů systému BUDIS. Přístup každého
uživatele podléhá autentizaci a autorizaci. Proces autentizace kontroluje identitu uživatele na základě
zadání uživatelského jména a hesla a proces autorizace vyhodnocuje uživatelská práva.
Jednotlivým uživatelům jsou přiděleny role odpovídající požadovaným funkcím a nabídkám v
aplikacích. Definice přiřazení uživatelských práv je uživatelská funkce dostupná z GUI pro
administrátora systému.
Modul Příprava dat:
Modul Příprava dat zajišťuje přípravu vybraných dat v systému BUDIS.
    • Data pro palubní počítač a vozidlové LED panely;
    • Data pro hlásiče
    • Data zájmových bodů.
    Následující obrázky obsahují ukázky GUI SW VISE vyvinutého společností Bustec s.r.o., určeného
    k přípravě dat pro individuální zařízení vozidel - např. LED panely, hlásiče:

                              Obr.2: příprava hlasových oznámení pro určené skupiny

                                                    Stránka 39 z 51
Obr 2: Konfigurace – audio kanálu
           Stránka 40 z 51
                              Obr. 3: Příprava fontů pro vnější a vnitřní LED panely

                              Obr. 4: Příprava textů pro vnější a vnitřní LED panely
    Pro přípravu dat určených pro LCD panely (monitory) lze použít jakýkoliv SVG editor.

Modul API pro externí systémy:
Součástí systému BUDIS bude API určené pro externí systémy. Přesný rozsah a specifikace
jednotlivých metod API bude upřesněna v rámci předimplementační analýzy.
API umožní definovaným způsobem komunikovat s dalšími systémy a aplikacemi. Rozhraní API
umožní poskytování dat třetím stranám ve variantách průběžné publikace dat nebo publikace na
dotaz třetí strany.
API bude využitelné určenými 3. stranami bez jakýchkoliv technických omezení a licenčních omezení.
Pro zabezpeční přístupu k API bude použita tzv. „basic autentisation“ - základní úroveň pomocí
přiděleného jména a hesla.

                                                    Stránka 41 z 51
C Detailní harmonogram projektu(kapitola 4.3 TS)

Dodavatel zajistí projektové vedení po celou dobu realizace zakázky osobou odpovědnou za realizaci
předmětu plnění, která bude hlavní kontaktní osobou a která bude přítomna při všech jednáních
týkajících se projektu.

Dodavatel zajistí dodržení následujícího harmonogramu plnění. Údaj D značí datum účinnosti
smlouvy o dílo. Čísla značí počet kalendářních dnů.

Etapa  Etapa projektu – činnost                                  Zahájení  Ukončení
č..                                                              etapy     etapy

1      Předimplementační analýza a zhotovení Prováděcí dokumentace D       D+14

2      Předání Prováděcí dokumentace Zadavateli, připomínkové řízení D+14  D+14

3      Zapracování připomínek a předání finální verze Prováděcí  D+14      D+20
       dokumentace – akceptace Zadavatelem

4      Dodávky a implementace                                    D+20      D+90

5      Školení uživatelů a administrátorů                        D+20      D+90

6      Zkušební provoz                                           D+60      D+90

7      Akceptační testy                                          D+60      D+90

8      Zahájení plného provozu                                   D+90      -

Podrobný harmonogram dodavatele je zpracován ve formě hierarchického seznamu úkolů, který je
doplněn Ganttovým grafem.

Výchozím datumem – mezníkem pro zahájení prací v harmonogramu v této nabídce je uveden datum
účinnosti smlouvy, který je namodelován na 1.6.2018. V případě jiného datumu účinnosti smlouvy
bude celý harmonogram upraven dle aktuální situace.

                                           Stránka 42 z 51
Harmonogram – Ganttův graf:

D Návrh akceptačních scénářů a způsobu provedení akceptačních
testů(kapitola 4.6 TS)

D.1. Akceptační testy, zkušební provoz
Součástí akceptačních testů je ověření (otestování) veškerých požadovaných funkcí a parametrů
všech dodávaných zařízení.
O provedení akceptace a jejím výsledku bude vyhotoven písemný protokol.
Dodavatel zajistí podporu zkušebnímu provozu v délce 30 dnů včetně technické podpory minimálně 2
specialistů na dodané řešení s dojezdem maximálně do 4 hodin od nahlášení požadavku v pracovní
den v době od 8 h do 17h.
Přechodem do ostrého provozu se rozumí okamžik úspěšné akceptace díla včetně vypořádání všech
vad a nedodělků.
Zkušební provoz a akceptační testování bude provedeno po zprovoznění všech částí systému a
proškolení uživatelů. Časový odstup provedení akceptačních testů od školení uživatelů by měl být
minimální.

    • Zkušební provoz a akceptační testování proběhne na produkční instanci RIS;
                                                    Stránka 43 z 51
 • Do zkušebního provozu a akceptačního testování budou zařazena vybraná vozidla
     v omezeném počtu, maximálně 8;

 • Pro zkušební provoz a akceptační testování modulu „Řízení IZ“ bude zadavatelem zajištěno
     API poskytované systémem IZ;

 • Způsob reportování připomínek zjištěných během akceptačních testů bude přesně stanoven.
     Bude využit helpdeskový systém dodavatele nebo e-mailová komunikace. Obsah a struktura
     reportovaného hlášení budou přesně stanoveny;

 • Reportování zjištěných připomínek a chyb bude prováděno průběžně okamžitě po zjištění
     příslušného nedostatku.

Ověření (akceptace) dodaného řešení bude provedena vůči zadávací dokumentaci a prováděcí
dokumentaci formou akceptačních testů. Výsledek bude stvrzen Akceptačním protokolem
s uvedením závěru positivním „uvést do provozu“ nebo negativním „neuvést do provozu“.
Přípustný bude i závěr „uvést do provozu s podmínkami“ v případě, kdy budou zjištěny
nepodstatné nedostatky, které nebudou bránit zahájení provozu. V tomto případě bude sepsán
přesný a jednoznačný soupis nedostatků se stanovením termínu pro jejich odstranění.

Pokud bude závěr akceptační fáze negativní, budou vyspecifikovány úpravy systému, úpravy
budou provedeny a bude provedeno nové kolo akceptačního testování.

Základní akceptační plán a scénáře:

Akceptační scénáře pro část „Zprovoznění ICT“:

 - Ověření dostupnosti centrálního serveru z prostředí sítě DPKV;
 - Ověření dostupnosti centrálního serveru vzdáleným přístupem z prostředí dodavatele;
 - Ověření dostupnosti centrálního serveru z prostředí vozidlového systému přes WIFI;
 - Ověření komunikace vozidlového systému a centrálního serveru přes GSM.

Akceptační scénáře pro část A:

 - Ověření funkčnosti správy uživatelů;
 - Ověření funkčnosti správy přístupových práv;
 - Ověření funkčnosti správy centrálních procesů;
 - Ověření funkčnosti konfigurace modulu Nahrávání a vyčítání dat;
 - Ověření funkčnosti manuálního sestavení aktualizačního balíčku;
 - Ověření funkčnosti provedení aktualizace vozidla;
 - Ověření funkčnosti monitoringu aktualizací;
 - Ověření datových importů – naplánovaný proces a na vyžádání;
 - Ověření funkčnosti konfigurace on-line přenosů – datové zprávy;
 - Ověření přenosu datových zpráv z vozidel na centrální server;
 - Ověření funkčnosti modul Dispečink:

          o Zobrazování aktuální polohy vozidel na mapě
          o Základní mapové funkce (posun, zoom, …)
          o Ovládání mapových vrstev

Část B:

                                                 Stránka 44 z 51
 - Ověření funkčnosti konfigurace textových zpráv;
 - Ověření správy předdefinovaných textových zpráv;
 - Ověření přenosu textových zpráv z dispečinku do vozidel a zpět;
 - Ověření potvrzování textových zpráv;
 - Ověření funkčnosti modul Dispečink:

          o Automatické vyhodnocování odchylek od jízdního řádu a jejich zobrazení
 - Ověření funkčnosti modulu Přípravy dat:

          o Správa zájmových bodů
          o Simulace
 - Ověření funkčnosti modulu Řízení IZ:
          o Prověření všech implementovaných metod API

Část C:

 - Ověření funkčnosti modulu Vyhodnocování a reporty:
          o Zpětný monitoring provozu a statistické vyhodnocení dat
          o Systém sledování a vyhodnocování provozních dat
          o Ukládání záznamů dopravních událostí
          o Sledování ujetých kilometrů

Část D:

 - Ověřování funkčnosti modulu Dispečink:
          o Dopřesnění polohy
          o Automatické upozorňování na neplánované a kritické stavy

 - Ověření modulu API pro externí systémy:
          o Prověření všech implementovaných metod API

Milníkem pro přechod do další fáze realizace je ukončení zkušebního provozu a všech
akceptačních testů s positivními výsledky. Dokumentaci k této fázi tvoří souhrn všech
Akceptačních protokolů.

Doplnění Akceptačních testů do plného rozsahu bude provedeno v rámci předimplementační
analýzy a zpracování prováděcí dokumentace.

 Požadovaná součinnost zadavatele:

 - Výběr uživatelů pro akceptační testy
 - Zajištění účasti uživatelů na akceptačních testech
 - Zajištění proškolení uživatelů ve způsobu reportování připomínek v rámci akceptačních testů
 - Zajištění dalšího personálu potřebného k provedení akceptačních testů (řidiči atd.)
 - Zajištění potřebné techniky k provedení akceptačních testů (tramvaje, potřebná ICT)

                                                 Stránka 45 z 51
D.2. Testovací prostředí

Dodavatel nevyžaduje zřízení testovacího prostředí. Testování dodavého systému provede dodavatel
na produkční infrastruktuře. Součinnost Zadavatele spočívá v udělení souhlasu s provedením testů
v předem oznámeném časovém rozpětí a předem oznámeném obsahu testů.

D.3. Fáze přechodu do ostrého provozu

Přechodem do ostrého provozu se rozumí okamžik úspěšné akceptace díla včetně vypořádání všech
vad a nedodělků.
Po dosažení kladného výsledku akceptační fáze bude následovat fáze uvedení do provozu, která
sestává z následujících přípravných činností (příprava plného provozu):

         • Vyčištění databáze od dat z předchozích fází (školení, akceptační testy)
         • Doškolení uživatelů (v případě potřeby)
         • Příprava produkčních dat
         • Rozšíření konfigurací systémi na celoplošný provoz
Závěrečným milníkem je zahájení plného provozu. Dosažení milníku bude doloženo Písemně –
Protokolem o uvedení systému do plného provozu. Dokument zpracuje a vystaví zadavatel.

    Požadovaná součinnost zadavatele:
    - Výběr uživatelů pro doškolení
    - Zajištění účasti uživatelů na školení
    - Zajištění technického zázemí školení – místnost, technika, přístup do potřebné ICT
    - Poskytnutí všech potřebných produkčních dat
    - Zpracování a vystavení protokolu o uvedení systému do plného provozu.

E Detailní popis navrhovaných školení(kapitola 4.4 TS)

Dodavatel zajistí školení pracovníků Zadavatele – dispečerů/administrátorů – na zařízení a systémy,
dodávané v rámci této veřejné zakázky, a to minimálně v rozsahu předávané provozní dokumentace.

                                                    Stránka 46 z 51
Školení zajistí seznámení pracovníků Zadavatele se všemi podstatnými částmi díla v rozsahu
potřebném pro provoz, údržbu a identifikaci nestandardních stavů systému a jejich příčin a
pracovníkům bude vystaveno osvědčení o školení s uvedením rozsahu školení.
Minimální rozsah školení je 16 hodin.
Školení bude probíhat v sídle Zadavatele.
Předpokládá se účast max. 10 účastníků.

Školení uživatelů navrhujeme zařadit k jednotlivým částem implementovaného systému dle
harmonogramu před provedením akceptačních testů. Důvodem je znalost a tím pádem i způsobilost
uživatelů k provedení akceptačních testů jednotlivých částí.

    - Školení bude provedeno na provozní ICT a provozní instanci dodaného systému;
    - Časový rozsah uvedený v harmonogramu převyšuje předpokládaný počet hodin školení.

         Důvodem je možnost zadavatele upřesnit přesné načasování školení dle časových možností
         uživatelů (dovolené, služební cesty apod.) a možnostech poskytnutí ICT pro školení.
         Předpokládáme max. 3 hodiny na školení jednoho tématu a možnost odškolení více témat
         v jednom dni.
    - Místo konání školení bude v prostorách zadavatele (zadavatel poskytne vhodnou místnost
         s připojením do sítě)
    - Školení jsou rozdělena do částí dle dodávek modulů a implementaci – viz harmonogram.

   Základní plán školení uživatelů:

   Školení bude rozděleno na 4 části dle dodávaných částí systému. Po provedení školení uživatelů
   budou následovat akceptační testy.

   Část A:

    - Modul Administrace a správy uživatelů
    - Modul Nahrávání a vyčítání dat
    - Modul Datové importy – Import jízdních řádů
    - Modul On-line komunikace
    - Modul Dispečink – Sledování a zobrazování okamžité geografické polohy

   Celkový rozsah školení části A: 8 hodin

   Část B:

    - Modul Textové a datové zprávy
    - Modul Dispečink – Automatické vyhodnocování odchylek od jízdního řádu
    - Modul Přípravy dat – Správa zájmových bodů
    - Modul Řízení IZ

    Celkový rozsah školení části B: 8 hodiny

                                                    Stránka 47 z 51
   Část C:
    - Modul Vyhodnocování a reporty – Zpětný monitoring provozu a statistické vyhodnocení dat
    - Modul Vyhodnocování a reporty – Systém sledování a vyhodnocování provozních dat
    - Modul Vyhodnocování a reporty - Ukládání záznamů dopravních událostí
    - Modul Vyhodnocování a reporty – Sledování ujetých kilometrů
    Celkový rozsah školení části B: 8 hodin
   Část D:
    - Modul Dispečink – Dopřesnění polohy
    - Modul Dispečink – Automatické upozorňování na neplánované a kritické stavy
    - Modul API pro externí systémy
    Celkový rozsah školení části B: 8 hodin

    Požadovaná součinnost zadavatele:
    - Výběr uživatelů dle tématu školení
    - Zajištění účasti uživatelů na školení
    - Zajištění technického zázemí školení – místnost, technika,
    - Zajištění pogtřební ingfrastruktury (ICT) – předpokládáme produkční ICT (nebudou zřízeny

         testovací instance ICT ani dodávaného systému)
    - PC pro účastníky školení s instalací BUDIS klienta

F Detailní popis způsobu odstraňování záručních vad a pozáručního
servisu(kapitola 5.1 TS)

F.1. Záruční servis

Dodavatel poskytuje záruku na veškeré dodané technologie v délce trvání 24 měsíců od okamžiku
předání do plného (produkčního) provozu.
Dodavatel poskytuje bezplatný (zahrnutý v ceně zakázky) přístup k aktualizacím software a firmware
dodaných komodit minimálně po dobu záruky.
Veškeré opravy po dobu záruky budou provedeny bez dalších nákladů pro zadavatele.
Veškeré komponenty, náhradní díly a práce, poskytnuté v rámci záruky budou poskytnuty bezplatně.

                                                    Stránka 48 z 51
Není-li uvedeno u konkrétní komodity jinak, provede dodavatel záruční opravu do pěti pracovních dní
nebo poskytnutí náhradního prvku shodných nebo lepších parametrů po dobu opravy.
Po dobu 60 měsíců od předání díla jako celku do plného provozu, garantuje dodavatel běžnou
dostupnost náhradních komponentů a dostupnost servisu.
Záruční servis je poskytován dle Smlouvy o dílo článek IX. Záruka za jakost a přílohy č. 1 Technická
specifikace článku 5.1 Požadavky na záruky a servisní podmínky.

Podmínky poskytování záruk:
    a) Zhotovitel odpovídá za to, že se předané dílo shoduje ve svých aspektech s funkčními
         vlastnostmi specifikovanými v předané uživatelské dokumentaci.
    b) Uživatel je odpovědný za to, aby se s uživatelskou dokumentací seznámil a na případné
         nejasnosti se dotázal.
    c) Zhotovitel garantuje plnou funkcionalitu díla pouze za předpokladu, že budou uživatelem
         splněny minimální systémové požadavky, které určuje zhotovitel.
    d) Zhotovitel odpovídá pouze za funkčnost aktuálních verzí SW, ke kterým mají přístup jen
         uživatelé po uhrazení ceny licencí, resp. aktualizací.
    e) Zhotovitel neodpovídá za vady starších verzí SW ani za jejich případnou nekompatibilitu s
         novými softwarovými či hardwarovými prostředky.
    f) Zhotovitel není povinen provádět technickou podporu, vývoj ani údržbu starších verzí SW.
         Podmínkou vzniku nároku na záruku je instalace SW pracovníkem zhotovitele.
    g) Záruka se vztahuje na výrobní vady médií a příruček.
    h) Uživatel je povinen pravidelně provádět zálohy dat a jejich archivování, včetně kontroly
         bezchybnosti vytvořené zálohy.
    i) Zhotovitel neodpovídá za ztrátu či poškození dat, která nebyla správně zálohována.
    j) Nároky ze záruky nevzniknou, pokud byla vada SW způsobena vyšší mocí, nehodou,
         neodbornou instalací, špatným nebo nesprávným používáním či používáním na nevhodném
         či zavirovaném hardwaru, nebo v kombinaci s jiným softwarem, který negativně ovlivňuje
         chování dodaného SW nebo který je v rozporu s TECHNICKÝMI POŽADAVKY uvedenými v
         dokumentaci.
    k) Za závadu dodaného SW nelze označit skutečnost, že dodaný SW nepracuje na hardwaru,
         který nebyl dostupný v okamžiku předání SW.
    l) Zhotovitel neodpovídá za správnou funkci SW v případě, že je provozován na počítači spolu s
         programy jiných výrobců, které svou funkcí či podstatou brání korektnímu chování dodaného
         SW.
    m) Zhotovitel neodpovídá za správnou funkci dodaného SW v případě, že je provozován na
         chybně konfigurovaném počítači či v prostředí nesprávně funkčního operačního systému.

F.2. Helpdeskový systém

Hlášení servisní požadavků bude Zadavatel provádět pomocí helpdeskového systému s on-line
přístupem pro kompletní správu požadavků včetně uchování historie požadavků a jejich řešení. .
Provozní doba helpdeskového systému bude 8-17 hod. v pracovních dnech.

                                                    Stránka 49 z 51
Zhotovitel poskytne svůj helpdeskový systém pro hlášení a sledování záručních, pozáručních
incidentů a požadavků na podporu provozu. Helpdeskový systém je postaven na produktech JIRA
společnosti Atlassian ( http://www.myjira.cz/index.html ).
Workflow systému bude nakonfigurováno pro on-line přístup uživatelů. Přesné workflow bude
specifikováno v rámci předimplementační analýzy a prováděcí dokumentace.

F.3. Pozáruční servis

Pozáruční servis je poskytován po dobu od ukončení záruční doby po dobu 36 měsíců. Celkem je tedy
servis poskytován (záruční plus pozáruční) po dobu 60 měsíců od datumu převzetí díla. Požadavky,
které jsou předmětem pozáručního servisu hlásí zhotovitel prostřednictvím helpdeskového systému
Zhotovitele. Zhotovitel každý požadavek na pozáruční servis vyhodnotí a navrhne řešení. Pro
realizaci řešení musí dojít k dohodě mezi zadavatelem a dodavatelem pro každý jednotlivý případ
obsahující předmět plnění, způsob realizace, termín a cenu.

G Detailní popis podpory provozu(kapitola 5.2 TS)

Provozní dokumentace bude popisovat detailně konfiguraci zhotoveného díla a jeho vazby na
stávající systémy.
Provozní dokumentace bude vycházet z prováděcí dokumentace, která bude před předáním do
provozu aktualizovaná dle skutečného stavu.
Součástí provozní dokumentace bude popis úkonů doporučené údržby a specifikace intervalů jejích
provádění a další dokumentaci v rozsahu stanoveném v prováděcí dokumentaci.
Dodavatel bude zajišťovat pravidelné aktualizace software (maintenance) a podporu provozu.

Podpora provozu je poskytována dle Smlouvy o zabezpečení podpory provozu. Podpora provozu je
poskytována po dobu 48 měsíců od data převzetí systému zadavatelem.
Podpora provozu díla obsahuje provádění jednak pravidelných činností a dále činností na vyžádání
Zadavatele.

         Pravidelné činností:

         • Pravidelné monitorování provozu dodaného systému (1x týdně 4 hod);
         • Aktualizace dodaného SW (maintenance).
         Činnosti na vyžádání Zadavatele:

         • Poskytování konsultací;
         • Konsultace a návrhy řešení změnových požadavků;
         • Poskytování mimozáručních servisních zásahů;

                                                    Stránka 50 z 51
         • Školení nových verzí SW a doškolování nových uživatelů.
Požadavek na podporu provozu (vyžádání Zadavatele) musí být zadán do helpdeskového systému
zhotovitele. Zhotovitel dle závažnosti požadavku poskytne požadovanou službu nebo navrhne jiné
opatření v přiměřené době. Přednostní způsob poskytnutí podpory je konsultace nebo zásah
vzdáleným přístupem k systému. Ve výjmečných – opodstatněných případech může být vyžádána
osobní podpora v místě zadavatele. Poskytnutí této podpory vždy podléhá souhlasu zhotovitele.

                                                    Stránka 51 z 51