Informační systém pro správu vozového parku. Bc. Jiří Strašák

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Informační systém pro správu vozového parku Bc. Jiří Strašák

Vedoucí práce: Ing. Josef Semrád

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 13. května 2011

Poděkování Na tomto místě bych rád poděkoval svým rodičům, babičce a přítelkyni, kteří mě podporovali po celou dobu studia a při realizaci této práce. Dále bych rád poděkoval Ing. Josefu Semrádovi za vedení diplomové práce.

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 13. 5. 2011

.............................................................

Abstract This thesis deals with the issue of the administration of the wagon stock. The aim of the thesis is to analyse, suggest and implement informational system for the support of the administration of the wagon stock with regard to minimalize the costs connected with the running of the vehicles. The proposed system will cooperate with the chosen GPS unit in order to collect information about the location of the vehicles, show the actual location on the interactive map and generate the book of journeys.

Abstrakt Tato diplomová práce se zabývá problematikou správy vozového parku. Cílem práce je analyzovat, navrhnout a implementovat informační systém pro podporu správy vozového parku s ohledem na minimalizaci nákladů spojených s provozem vozidel. Navržený systém bude umět spolupracovat s vybranou GPS jednotkou za účelem sběru informací o poloze vozidel, zobrazení aktuální polohy na interaktivní mapě a generování knihy jízd.

ix

Obsah 1 Úvod 1.1 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Důvody vedoucí ke vzniku . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2

2 Správa vozového parku

5

3 Úvodní studie 3.1 Rozdělení systémů . . . . . . . . . . . . . . . . . . . . . 3.1.1 Desktopová aplikace . . . . . . . . . . . . . . . . 3.1.2 Klient–server aplikace . . . . . . . . . . . . . . . 3.1.3 Jednouživatelský systém . . . . . . . . . . . . . . 3.1.4 Víceuživatelský systém . . . . . . . . . . . . . . . 3.1.5 Nižší třída systémů pro správu vozového parku . 3.1.6 Střední třída systémů pro správu vozového parku 3.1.7 Vyšší třída systémů pro správu vozového parku . 3.2 Distribuce aplikace . . . . . . . . . . . . . . . . . . . . . 3.2.1 Softwarový balík . . . . . . . . . . . . . . . . . . 3.2.2 Software jako služba . . . . . . . . . . . . . . . . 3.3 Požadavky na aplikaci . . . . . . . . . . . . . . . . . . . 3.4 Technologie . . . . . . . . . . . . . . . . . . . . . . . . . 4 Existující řešení 4.1 yMonitor . . . . . . . . . 4.2 T-Cars Fleet Managemet 4.3 CarNet . . . . . . . . . . . 4.4 Webdispečink . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

7 . 7 . 7 . 8 . 8 . 8 . 8 . 9 . 9 . 9 . 9 . 9 . 10 . 12

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

13 13 14 15 16

5 Analýza 5.1 Koncepce systému . . . . . . . . . . . . 5.2 Role v systému . . . . . . . . . . . . . . 5.2.1 Klient . . . . . . . . . . . . . . . 5.2.1.1 Hlídání vozidel . . . . . 5.2.1.2 Správa vozového parku 5.2.2 Vozidlo . . . . . . . . . . . . . . 5.2.2.1 Auto . . . . . . . . . . 5.2.2.2 Vůz . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

19 19 20 21 21 21 21 21 22

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

xi

. . . .

5.2.2.3 Pool . . . . . . . . . . . . . 5.2.2.4 Služební . . . . . . . . . . . 5.2.3 Uživatelské role . . . . . . . . . . . . 5.2.3.1 Uživatel . . . . . . . . . . . 5.2.3.2 Správce . . . . . . . . . . . 5.2.3.3 Řidič . . . . . . . . . . . . Funkční celky . . . . . . . . . . . . . . . . . 5.3.1 Správa uživatelů . . . . . . . . . . . 5.3.2 Správa vozidel . . . . . . . . . . . . 5.3.3 Správa dokumentů . . . . . . . . . . 5.3.4 Správa nákladových faktur . . . . . 5.3.5 Správa tankovacích karet . . . . . . 5.3.6 Interní autopůjčovna . . . . . . . . . 5.3.7 Poloha vozidel a kniha jízd . . . . . 5.3.8 Přehledy a statistiky . . . . . . . . . GSM/GPRS/GPS jednotka CVPL-G204-A 5.4.1 Popis jednotky . . . . . . . . . . . . 5.4.2 Zhodnocení jednotky . . . . . . . . . 5.4.3 Konfigurace jednotky . . . . . . . . 5.4.4 Komunikační protokol . . . . . . . . 5.4.4.1 „Prolomení“protokolu . . . 5.4.4.2 Specifikace . . . . . . . . . 5.4.4.3 Chování . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

22 23 23 23 23 24 24 25 25 25 26 27 28 29 30 30 30 32 33 33 34 35 37

6 Návrh 6.1 Datová část . . . . . . . . . . . . . . . . . . 6.2 Uživatelské rozhraní . . . . . . . . . . . . . 6.2.1 Nabídka . . . . . . . . . . . . . . . . 6.2.2 Formulář . . . . . . . . . . . . . . . 6.2.3 Přehled . . . . . . . . . . . . . . . . 6.2.4 Detail . . . . . . . . . . . . . . . . . 6.2.5 Ostatní . . . . . . . . . . . . . . . . 6.3 Výkonné jádro . . . . . . . . . . . . . . . . 6.3.1 Architektura . . . . . . . . . . . . . 6.3.2 Sestavení aplikace . . . . . . . . . . 6.3.3 Konfigurace systému . . . . . . . . . 6.3.4 Inicializace systému . . . . . . . . . 6.3.5 Uživatelská práva a omezení . . . . . 6.3.6 Uživatelské datové typy a validátory 6.4 Aplikace pro komunikaci s GPS jednotkama 6.4.1 Pohyb vozidla . . . . . . . . . . . . . 6.4.2 Koncepce . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

39 39 40 41 41 42 42 42 42 43 44 45 45 46 47 47 48 49

5.3

5.4

7 Implementace 7.1 Základní informace . . . . . . . . . . . . . . . . 7.2 Nasazení . . . . . . . . . . . . . . . . . . . . . . 7.3 Zajímavé řešené problémy . . . . . . . . . . . . 7.3.1 Automatické načítání tříd pro PHP . . . 7.3.2 Kniha jízd . . . . . . . . . . . . . . . . . 7.3.3 Pohyb vozidla ve vymezených oblastech

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

51 51 52 52 52 55 56

8 Testování 8.1 Testování kódu . . . . . . . . . . . . . . . . . . . . . 8.2 Testování sestavení aplikace . . . . . . . . . . . . . . 8.3 Testování aplikace pro komunikaci s GPS jednotkami 8.4 Akceptační test . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

59 59 59 59 60

. . . . . .

. . . . . .

9 Srovnání a zhodnocení

61

10 Závěr

63

A GSM/GPRS/GPS jednotka CVPL-G204-A 67 A.1 Zapojení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 A.2 Prvotní konfigurace pomocí SMS zpráv . . . . . . . . . . . . . . . . . . . . . . 68 B Datový model

71

C Kniha jízd

75

D Ukázka uživatelského rozhraní existujících řešení

77

E UML diagramy

85

Seznam obrázků 1.1 1.2 1.3

Stav nastavení pravidel Fleet Managementu – rok 2010 . . . . . . . . . . . . . Stav využití telematiky – rok 2010 . . . . . . . . . . . . . . . . . . . . . . . . Stav využití IS – rok 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 3 3

2.1

Vývojová stádia telematických sledovacích systémů . . . . . . . . . . . . . . .

6

5.1 5.2 5.3 5.4 5.5 5.6 5.7

Hierarchie vozidel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stavový diagram role vůz . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stavový diagram role vůz . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSM/GPRS/GPS jednotka CVPL-G204-A . . . . . . . . . . . . . . . . . . Dodávaná obslužná aplikace pro GPS jednotky . . . . . . . . . . . . . . . . Diagram nasazení – komunikace jednotky s dodávanou aplikací . . . . . . . Diagram nasazení – komunikace jednotky s dodávanou aplikací přes prostředníka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

22 23 28 31 32 34

. 35

6.1 6.2 6.3

Hlavní rozdělení obrazovky systému . . . . . . . . . . . . . . . . . . . . . . . 41 Architektura aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Stavový diagram pohybu vozidla . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.1

Diagram nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

A.1 Význam konektorů jednotky . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 A.2 Schéma zapojení jednotky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 B.1 Datový model systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 C.1 Ukázka zobrazení jízdy na interaktivní mapě . . . . . . . . . . . . . . . . . . 75 D.1 D.2 D.3 D.4 D.5 D.6 D.7 D.8

Ukázka Ukázka Ukázka Ukázka Ukázka Ukázka Ukázka Ukázka

č. 1 č. 2 č. 3 č. 1 č. 2 č. 1 č. 2 č. 3

uživatelského uživatelského uživatelského uživatelského uživatelského uživatelského uživatelského uživatelského

rozhraní rozhraní rozhraní rozhraní rozhraní rozhraní rozhraní rozhraní

systému systému systému systému systému systému systému systému

yMonitor . . . yMonitor . . . yMonitor . . . CarNet . . . . CarNet . . . . Webdispečink Webdispečink Webdispečink

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

77 78 79 80 80 81 82 83

E.1 Diagram komponent výkonného jádra systému . . . . . . . . . . . . . . . . . 85

xv

E.2 Diagram hierarchie grafických komponent . . . . . . . . . . . . . . . . . . . . 86 E.3 Diagram hierarchie událostí (zpráv) GPS jednotek . . . . . . . . . . . . . . . 87

Seznam tabulek 5.1

Hierarchie rolí v systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

9.1

Porovnání možností existujících systémů s navrhovaným . . . . . . . . . . . . 62

B.1 Entity datového modelu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 C.1 Ukázka vygenerované knihy jízd z jednoho dne . . . . . . . . . . . . . . . . . 76

xvii

Věnováno na památku mé maminky.

Kapitola 1

Úvod V současné době probíhá nasazování různých informačních technologií téměř do všech odvětví lidské činnosti. Od jejich využívání se očekává především ulehčení, zrychlení a zefektivnění práce. Lze však nalézt další přínosy a využití. Je třeba zmínit, že samotné nasazení správné informační technologie automaticky nezaručuje dosažení kýžených výsledků. Nezřídka se stává, že dochází k efektu opačnému a situace se stává ještě horší než byla. Příčin a faktorů ovlivňujících úspěch nasazení konkrétní informační technologie je mnoho. Selhání může být způsobeno samotnými lidmi, kdy není využíván veškerý potenciál řešení nebo je řešení používáno nevhodným způsobem. Na druhé straně může selhání způsobit technologie samotná. V případě informačního systému (který jinak splňuje všechny kladené funkční požadavky) může být třeba nevhodně navržené uživatelské rozhraní či nesrozumitelné vazby – jedná se třeba o drobnosti, ale mohou odradit spoustu jeho potenciálních uživatelů. Z hlediska společnosti s vlastním vozovým parkem může nasazení vhodného informačního systému přínést užitek v podobě možnosti kontroly vynaložených nákladů spojených s provozem vozidel. Důsledné monitorování, kontrola a nastavení vhodných parametrů vozového parku může posloužit právě pro optimalizaci vynaložených nákladů. Systémy určené pro podporu správy vozového parku zpravidla plní roli centrální evidence, jež obsahuje všechny nezbytně nutné informace o vozovém parku a jeho stavu. Mezi tyto informace lze zařadit samotná vozidla, řidiče, nákladové faktury, výpisy transakcí z tankovacích karet, knihy jízd, apod. V současné době, kdy je signálem GSM pokryt (s nadsázkou) téměř celý civilizovaný svět a technologie GPS je volně dostupná, se nepředpokládá ani žádný jiný způsob pro generování knihy jízd, než s pomocí těchto technologií.

1.1

Cíl práce

Cílem práce je analyzovat, navrhnout a implementovat informační systém určený pro podporu správy vozového parku s ohledem na minimalizaci (optimalizaci) nákladů spojených s provozem vozidel. Aplikace bude koncipována jako víceuživatelská, webová aplikace s modelem distribuce software jako služba. Součástí této práce není analýza, návrh a implementace části aplikace určené pro provozovatele služby.

1

2

KAPITOLA 1. ÚVOD

Obrázek 1.1: Stav nastavení pravidel Fleet Managementu – rok 2010 (zdroj [11], graficky upraveno)

Navržený systém bude umět spolupracovat s vybraným typem GPS jednotky za účelem sběru informací o poloze vozidel, zobrazení aktuální polohy na interaktivní mapě a generování knihy jízd. Spolupráce s GPS jednotkou bude vyžadovat popis komunikačního protokolu (pokud nebude znám) a vytvoření vhodné aplikace. Systém bude navržen pro dvě skupiny potenciálních zákazníků. První skupinu budou představovat společnosti, které budou chtít mít komplexní systém pro podporu správy vozového parku. Druhou skupinu budou tvořit společnosti a jednotlivci, kteří budou chtít mít přehled pouze o poloze a pohybu svého vozidla a využívat tak systém jako další prvek zabezpečení. Aby se systém stal úspěšným je potřeba přinést další nové nápady pro podporu správy vozového parku.

1.2

Důvody vedoucí ke vzniku

V současnosti existuje celá řada systémů nabízejících podporu pro správu vozového parku. Jejich hrubé rozdělení je zmíněno v sekci 3.1, v kapitole 4 jsou popsána vybraná řešení. Hlavním důvodem pro vznik tohoto systému je vytvoření další alternativy k existujícím řešením a následně jej nabízet nejen firmám, ale i jednotlivcům. Mohlo by se zdát, že vývoj dalšího podobného systému je zbytečný. Avšak podle zjištění v [11] jen: • 45% společností má jasně stanovená pravidla ohledně správy firemních vozidel (graf 1.1) • 44% společností využívá telematiku (graf 1.2) • 17% společností využívá nějaký informační systém (graf 1.3)

1.2. DŮVODY VEDOUCÍ KE VZNIKU

Obrázek 1.2: Stav využití telematiky – rok 2010 (zdroj [11], graficky upraveno)

Obrázek 1.3: Stav využití IS – rok 2010 (zdroj [11], graficky upraveno)

3

4

KAPITOLA 1. ÚVOD

Kapitola 2

Správa vozového parku Správa vozového parku (Fleet management) je sám o sobě velice široký pojem. Jednoduše jej lze definovat jako řadu různorodých činností souvisejících s pořízením, správou, sledováním, obnovou a odpisem vozidel ve vozových parcích firem.[10][12] Komplexní správa vozového parku plní dle [10] tyto funkce1 : strategické • definování potřeb na vozový park • pořízení vozového parku • nastavení podmínek s dodavateli • návrhy úsporných opatření • spolupráce s personalisty na vozové politice (car policy) • jednání s dodavateli operativní • objednávání vozidel • sledování vyjednaných podmínek • kontrola účinnosti úsporných opatření • sledování trhu v oblasti vozů i služeb • kontrola ukazatelů – ujeté kilometry, pojistné události, průměrná spotřeba, atd. • předávání a přebírání vozidel • kontrola úrovně opotřebení vozidel při převzetí, případně škodní komise • kontrola faktur • reporting • zajištění náhraních vozů • likvidace pojistných událostí 1

ve skutečnosti je pojem správa vozového parku tak široký, že se dají vymyslet stovky dalších funkcí

5

6

KAPITOLA 2. SPRÁVA VOZOVÉHO PARKU

Obrázek 2.1: Vývojová stádia telematických sledovacích systémů (zdroj [15], graficky upraveno)

Často se termínem Fleet Management označují informační systémy určené pro sledování a monitorování vozidel pomocí technologie GPS s on-line nebo off-line připojením. V tomto případě už se však jedná o hodně úzkou specifikaci a hovoří se spíše o telematických sledovacích systémech. Vývojová stádia těchto systémů, jenž se odlišují množstvím poskytovaných funkcí, jsou shrnuta na obrázku 2.1. Zaměňování těchto termínů lze vidět v kontrastu u společností nabízejících komplexní řešení v oblasti správy vozového parku a společností nabízejících „jen“ IT systémy pro podporu Fleet Managementu. Důkazem toho mohou být existující řešení popsané v kapitole 4 – všechny nějakým způsobem řeší problematiku správy vozového parku, ale v omezené míře (podle druhého výkladu pojmu). Ať už je však výklad pojmu jakýkoliv, jedno mají společné – výsledek by měl vést ke snižování nákladů na provoz firemních vozidel (při dodržování interních předpisů a bezpečnosti zaměstnanců).[10]

Kapitola 3

Úvodní studie 3.1

Rozdělení systémů

Systémy lze rozdělit podle více kritérií: • typ aplikace – desktopová aplikace – klient–server aplikace • počet uživatelů – jednouživatelský systém – víceuživatelský systém • funkce podpory správy vozového parku – systémy nižší třídy – systémy střední třídy – systémy vyšší třídy

3.1.1

Desktopová aplikace

Pojmem desktopová aplikace se označuje software, který je instalován na pevném disku osobního počítače, ze kterého je i spouštěn. Může být určen pro jednoho nebo pro více uživatelů. V případě více uživatelů je tedy nutné, aby měl každý uživatel vlastní instalaci. Určitou výhodou takovéto aplikace je její dostupnost – není závislá na připojení do žádné sítě a je možné ji používat kdykoliv a kdekoliv. Největší nevýhodou je bezesporu téměř nulová podpora pro sdílení informací v případě víceuživatelského nasazení (každý uživatel pracuje lokálně).

7

8

KAPITOLA 3. ÚVODNÍ STUDIE

3.1.2

Klient–server aplikace

Klient–server aplikace jsou zpravidla víceuživatelské systémy. Podle možností klienta se dají ještě rozdělit na: tlustý klient – zpravidla obsahuje kompletní aplikační logiku, strana serveru slouží jen jako úložiště a ke sdílení informací tenký klient – stará se jen o prezentaci dat získaných ze serveru, veškerá aplikační logika je umístěna na serveru Webová aplikace je asi nejznámějším příkladem tohoto typu aplikace. Internetový prohlížeč slouží jako tenký klient. Zprostředkovává požadavky na server (webový) a stará se jen o zobrazení získaných informací. Veškerá aplikační logika je umístěna na serveru. Výhodou webových aplikací je jednoznačně platformová nezávislost (pomineme-li použití nějaké specifické technologie – např. Microsoft ActiveX). Další je dostupnost webového prohlížeče – v současné době je součástí každého moderního operačního systému. Nevýhodou je nedostupnost v případě výpadku připojení do sítě a v porovnání třeba s desktopovou aplikací i o něčo delší odezva na uživatelské vstupy. Jako úložiště se ve většině případů používá nějaká relační, případně objektová databáze.

3.1.3

Jednouživatelský systém

Jednouživatelským systémem se rozumí aplikace určená pro práci právě jednoho uživatele na jedné pracovní stanici. Spolupráce více uživatelů může spočívat například ve sdílení datových souborů.

3.1.4

Víceuživatelský systém

Víceuživatelský systém označuje aplikaci, která může být v reálném čase používána více uživateli. Uživatelé mohou pracovat na různých ulohách, ale mohou také spolupracovat na úloze jedné. Tento typ aplikace povětšinou také vyžaduje nějaký způsob autentizace a autorizace.

3.1.5

Nižší třída systémů pro správu vozového parku

Do této kategorie se dají zařadit nástroje, jenž poskytují jen nejzákladnější funkce pro podporu fleet managementu (dá-li se tomu v tomto případě tak vůbec říkat), jako evidenci vozidel, evidenci nákladů, případně jednoduché vykazování knihy jízd. Se systémy této kategorie se lze setkat zejména u malých společností s velmi malým vozovým parkem. Ve většině případů se jedná o jednouživatelské desktopové aplikace. Nezřídka bývá takovýto systém realizován jako sešit tabulkového procesoru (Microsoft Excel, OpenOffice.org Calc, apod.).

3.2. DISTRIBUCE APLIKACE

3.1.6

9

Střední třída systémů pro správu vozového parku

Systémy této třídy zvládají správu rozsáhlejších vozových parků. Obsahují daleko propracovanější evidenci vozidel, řidičů, dokumentů, veškerých nákladů souvisejících s provozem vozidel, dále manažerské přehledy a mohou obsahovat i sledování vozidel pomocí technologie GPS.

3.1.7

Vyšší třída systémů pro správu vozového parku

Tuto třídu tvoří rozsáhlé, vysoce kvalitní systémy. Samozřejmě nabízejí všechny funkce (avšak propracovanější) jako systémy v nižších třídách. Navíc mohou disponovat sofistikovanými funkcemi pro plánování, logistiku, propojení se systémy třetích stran, úplnou správou objednávek a zakázek, dispečinkem, atd.

3.2

Distribuce aplikace

Důležitým kritériem návrhu systému, jelikož může ovlivnit i celkovou koncepci a celý návrh, je i případný model distribuce. Vhodnými kandidáty modelu pro distribuci se nabízí: • softwarový balík • software jako služba

3.2.1

Softwarový balík

Softwarový balík je asi nejznámější model distribuce aplikace. Zákazník si koupí licenci a aplikaci provozuje na svém vlastním zařízení. Tento způsob má řadu výhod: • provoz systému je zajišťován klientem (ať už samotným nebo formou technické podpory) • jednoduchá realizace úprav dle individuálních požadavků klienta • „nižší“ nároky na zabezpečení – z principu se nelze dostat k datům jiného klienta

3.2.2

Software jako služba

Software jako služba (Software as a Service, SaaS) je model distribuce aplikací (především informačních systému a webových aplikací), kdy zákazník neplatí za licenci, ale za určitý poplatek si ji pronajímá. V případě systému pro správu vozového parku se mohou poplatky odvíjet například od počtu registrovaných uživatelů, vozidel či od používaných funkcí systému. Důležité je, že aplikace samotná běží na zařízeních provozovatele. V případě tohoto modelu, hraje významnou roli v návrhu i to, jakým způsobem, respektive v kolika instancích aplikace poběží. Z pohledu klienta je toto rozhodnutí zcela transparentní. V úvahu připadají tři možnosti (režimy):

10


• jedna instance, jeden klient – aplikace koncipována stejně jako „softwarový balík“, pouze poběží u provozovatele • jedna instance, více klientů – sehrává důležitou roli při návrhu (databáze, bezpečnost) • více instancí, na každou omezený počet klientů – rozdělení zátěže předchozího způsobu

3.3

Požadavky na aplikaci

Vyvíjená aplikace pro podporu správy vozového parku bude určena společnostem a jednotlivcům (dále jen klientům), jenž žádný takovýto systém buď vůbec nepoužívají nebo používají jiný, který jim z nějakého důvodu nevyhovuje. Systém bude vhodný zejména pro klienty, s malými až středně velkými vozovými parky, tvořenými především osobními vozy a dodávkami, kteří chtějí mít přehled o stavu svého vozového parku či chtějí jen sledovat polohu svých vozidel. Nasazení aplikace nebude nejvhodnější u velkých autodopravců, kde se dají předpokládat hodně specifické požadavky na správu vozového parku – například celkové plánování a logistika. Systém bude realizován jako webová aplikace (3.1.2) s modelem distribuce software jako služba popsaným v 3.2.2 v režimu jedna instance, více klientů, případně více instancí, na každou omezený počet klientů (oba režimy jsou z hlediska návrhu totožné). Tím, že bude aplikace přístupná z globální sítě internet a vzhledem k charakteru informací, které budou v systému evidovány, bude systém provozován výhradně přes zabezpečený protokol https. Uživatelé budou před vstupem do aplikace ověřeni klientským kódem, uživatelským jménem a heslem. Jelikož bude více klientů sdílet jednu instanci aplikace, bude muset být brán velký důraz na celkové zabezpečení. Díky formě distribuce aplikace bude systém rozdělen na dvě části: • klientská • operátorská Je nutno znovu dodat, že se tato práce zabývá pouze klientskou částí. Systém by měl ulehčovat správu vozového parku. Z hlediska správy vozového parku jsou proto na systém kladeny tyto funkční požadavky: • správa vozidel • správa uživatelů • správa dokumentů • evidence nákladů na provoz vozidla • interní autopůjčovna tzv. „pool“ vozidel • služební vozidla • evidence předávacích protokolů

3.3. POŽADAVKY NA APLIKACI

11

• importy výpisů tankovacích karet • informace o poloze vozidel pomocí technologie GPS • kniha jízd • manažerské přehledy spojené s náklady na provoz vozidla Zárověn je kladen důraz i na tyto nefunkční požadavky: • rychlost • dostupnost • bezpečnost • odolnost vůči chybám • nezávislost na konkrétním internetovém prohlížeči • vysoký komfort uživatelského rozhraní • využití v co největší míře open–source nástrojů a prostředků Základní entitou systému bude bezesporu vozidlo, které se bude vyskytovat ve čtyřech různých rolích. Každá role pak bude mít v rámci vozového parku jiné možnosti využití. Jaká role bude přiřazena vozidlu, bude záviset i na roli klienta. V systému budou existovat dvě klientské role (pojmenované jednoduše dle jejich funkčnosti): • hlídání vozidel • správa vozového parku Každý klient typu správa vozového parku bude mít svého správce vozového parku. Bude se jednat o uživatele, který může jakkoliv manipulovat se všemi vozidly, kontrolovat ukazatele, schvalovat rezervace, přiřazovat služební vozy, přidávat dokumenty, faktury, informace o tankování atd. V systému bude realizována interní autopůjčovna (rezervační systém) pro tzv. „pool“ vozidla. Proces rezervace bude probíhat ve dvou krocích. Uživatel, který si bude chtít vůz půjčit, si volné vozidlo zarezervuje a bude čekat na vyjádření správce. Správce bude moci rezervaci potvrdit nebo zamítnout. Dalším druhem rezervací bude přiřazení služebního vozidla konkrétnímu uživateli. Uživatel, který má přiřazen služební vůz, bude mít k tomuto vozidlu přístupné funkce jako správce (v poněkud omezené míře). K oběma typům rezervací bude možno přiložit předávací protokoly. Aplikace bude schopna zpracovávat údaje o poloze vozidla z GSM/GPRS/GPS jednotky CVPL-G204-A umístěné ve vozidle v reálném čase. Bude možné zobrazovat aktuální polohu a jednotlivé jízdy v minulosti na interaktivní mapě. Použití jednotky spolu se systémem bude sloužit i jako bezpečnostní prvek. Nabídne kontrolu dosažení/opuštění definovaných oblastí, pohyb vozidla mimo povolenou dobu a signál nouze. Klient, přesněji některý jeho

12


uživatel, bude v případě, kdy dojde k definované události informován pomocí SMS zprávy. Komponenta systému, která by realizovala samotné odesílání zpráv pomocí hardwarové SMS brány, nebude součástí této práce – jedná se o již realizovanou komplexnější aplikaci, ke které bude přistupováno pomocí webové služby. Aby byl klient úplně odstíněn od jednotky, bude její kompletní aktivace, tj. konfigurace a spárování s vozidlem řešena stranou provozovatele (operátora). Důvod je zřejmý – předcházení problemům s neodborným zásahem.

3.4

Technologie

V kapitole 3.3 jsou uvedeny základní požadavky na systém, kde je uvedeno, že systém bude realizován jako webová aplikace. Aplikace bude nainstalována na webovém serveru, bude komunikovat s databázovým serverem a uživatelé k ní budou přistupovat pomocí internetového prohlížeče. Webová aplikace bude realizována ve skriptovacím jazyce PHP5. Pro splnění všech požadavků bude navrhnut a implementován vlastní framework určený (speciálně) pro realizaci informačních systémů. Při jeho realizaci bude kladen velký důraz zejména na jednoduchost a rychlost vývoje, modulárnost, bezpečnost a použitelnost. Jako datové úložiště bude sloužit objektově–relační databázový systém PostgreSQL. Objektově relační mapování bude realizováno pomocí ORM Doctrine2. Pro dosažení vysokého uživatelského komfortu bude využito JavaSriptu. Pro efektivní práci s ním pak framework jQuery a jQueryUI. Pro potřebu mapových podkladů bude využit projekt OpenStreetMap a OpenLayers. Aplikace pro komunikaci s GPS jednotkama, bude napsána v programovacím jazyce Java.

Kapitola 4

Existující řešení Tato kapitola obsahuje popis vybraných existujících systémů určených pro podporu správy vozového parku. Všechna popsaná řešení jsou komerční, realizována jako webové aplikace, nabízené formou software jako služba a lze je zařadit do skupiny telematických systémů. Pro vlastní zhodnocení, popis a výsledné porovnání všech systémů by bylo zapotřebí mít tyto služby přístupné – zaplacené (ne všechny nabízejí demo přístup) a alespoň chvíli je aktivně využívat. Z tohoto důvodu je popis každého systému a veškerých jeho funkcí převzat bez dalších úprav z oficiálních obchodních materiálů provozovatele a je nechán v jeho původním názvosloví. Pro porovnání byla vybrána tato řešení: • yMonitor [16] • T-Cars Fleet Managemet [13] • CarNet [2] • Webdispečink [4]

4.1

yMonitor

Systém yMonitor funguje na základě technologie GPS (Global Positioning System), která umožňuje zjistit polohu monitorovací jednotky kdekoliv na zeměkouli s přesností na několik málo metrů. Sesbírané informace o poloze se ukládají do monitorovací jednotky instalované ve vozidle, a pravidelně sa odesílají prostřednictvím mobilní sítě GSM – přesněji datovým prenosem GPRS na servery služby yMonitor k zpracování. Všechna data se ukládají na serverech této monitorovací služby, uživatelé tedy nepotřebují žádné zvláštní vybavení kromě počítače nebo mobilního telefonu s připojením na internet, aby zjistili okamžitou polohu jejich vozidel, ať jsou kdekoliv v Evropě – za předpokladu využití roamingových služeb.

13

14

KAPITOLA 4. EXISTUJÍCÍ ŘEŠENÍ

Celého procesu sběru, přenosu a zpracování se tedy zúčastňuje mobilní operátor, monitorovací jednotka a poskytovatel služby yMonitor. Uživatel tak může bez zbytečných investic do hardware a software využívat služby, které jsou non-stop aktualizovány a spravovány pod dohledem odborníků. Provozovatelem deklarované funkce: • měsíční vyhodnocování kompletních provozních nákladů vozidla • generování knihy jízd • zobrazení polohy vozidel a jízd na mapě • rozlišování firemní a soukromé jízdy • management tankování s vyhodnocováním spotřeby • zadávání a vyhodnocování nákladů na servis vozidel • sledování servisních intervalů podle času nebo km s upozorněním • nákladové sledování oprav a údržby • import a zpracování dat z tankovacích karet • možnost měření teploty nebo skutečné spotřeby paliva • výpočet diet a kapesného • statistické zpracování záznamů o provozu vozidla • denní zasílání výkazů o provozu vozidel na email • možnost SMS notifikace při vjezdu/výjezdu ze sledované oblasti • možnost služby Routing – nastavení tras jízdy s alarmem při odchýlení • uživatelské nastavení přístupových práv, přidávání dalších vozidel • SMS notifikace při vzniku předdefinované situace

4.2

T-Cars Fleet Managemet

T-Cars Fleet Managemet je internetová aplikace sloužící jako efektivní nástroj pro správu vozového parku, jeho monitorování v reálném čase, pokročilý reporting a intuitivní práci uživatele v dnešním informačním světě. Kombinací vlastností výkonné palubní jednotky a internetové aplikace jsou maximálně využívány systémové zdroje a minimalizovány náklady na provoz systému. Maximální využívání systémových zdrojů má za následek efektivnější využití drahocenného času správců autoparku. T-Cars Fleet Management pracuje v reálném čase, což znamená, že veškeré události

4.3. CARNET

15

jsou zpracovávány přímo v palubní jednotce a ihned oznámeny v centrálním systému. Následkem je okamžitá reakce na sledovaný parametr vozidla a tím i možnost urychlení všech následných procesů. Provozovatelem deklarované funkce: • zobrazení vozidel v reálném čase na interaktivní mapě • uživatelské body zájmu, body průjezdu, plánované trasy, odchýlení od trasy • vyhledání místa, optimální trasy, nejbližších vozidel, nejbližších řidičů • elektronická kniha jízd dle řidiče, vozidla • rozlišení soukromých a služebních jízd • náklady, cena na km provozu, prodlení, max. a průměrná rychlost, průměrná spotřeba • cestovní příkazy a náhrady • systém varování pomocí info panelu, email, SMS – rychlost, průjezdy, nouze, atd. • servisní plán pro plánování správy parku – prohlídky, servis, pojištění, pneu, leasing, atd. • reporty, statistiky, analýzy více než 40 vstupů • kalendář reportů – automatické nastavení rozesílání reportů emailem • správa základních dat – organizační struktura, řidiči, vozidla, body zájmu, trasy, atd. • uživatelské nastavení významu jednotlivých vstupů a výstupů jednotky • importy/exporty dat • importy karetních systémů – informace o tankování a dalších nákladech • elektronická identifikace řidiče • oblast – vjezd do a výjezd z oblasti, nedosažení oblasti, neopuštění oblasti • sledování – kontrola odchýlení vozidla od definované trasy

4.3

CarNet

Systém CarNet je určen pro zákazníky, kteří chtějí mít svá vozidla stále pod kontrolou a ušetřit tak na provozních nákladech svého autoparku. Systém v reálném čase sleduje a zaznamenává jízdní parametry jako polohu, rychlost, stavy vstupů a další veličiny, které pak přenáší do GPS centra. Z centra jsou data vzápětí přenesena k zákazníkovi, kde se provádí jejich zpracování a vyhodnocení. Zákazník tak získává dokonalý přehled o svém vozovém parku a možnost snadno pracovat se všemi potřebnými informacemi.

16


Přínosem systému CarNet je především snížení provozních nákladů autoparku a díky tomu i rychlá návratnost investice do systému. Za zmínku stojí i jednoduché ovládání systému, které zvládne běžný uživatel PC. Provozovatelem deklarované funkce: • generování knihy jízd • rozlišení služebních a soukromých jízd • možnost importu údajů o tankování • evidence nákladů spojených s provozem vozidla • bezkontaktní identifikace řidiče • široké možnosti úprav knihy jízd – změna a doplnění účelu, sloučení a rozdělení jízd, korekce tachometru

4.4

Webdispečink

Webdispečink je internetová aplikace pro správu vozového parku obsahující funkce: elektronická kniha jízd, sledování vozidel (dispečink, dispečerské pracoviště), optimalizace dopravy, cestovní náhrady, a další. Využívá se nejmodernějších technologii GPS a GSM. Díky technologii GPS dokáže systém určit přesnou polohu vozidel, prostřednictvím GSM sítě se tyto informace dostanou v reálném čase k uživateli. Uživatel k samotné práci potřebuje pouze připojení k internetu a prohlížeč www stránek. Internetový dispečink je kompletním překlopením dispečerského pracoviště na webovou platformu s velmi jednoduchým intuitivním ovládáním. V žádném případě nejde o pouhou tvorbu knihy jízd a zpožděný přístup k informacím tak charakteristické pro současná polovičatá řešení evidence pohybu vozidel. Na základě letitých znalostí potřeb provozovatelů autoparků byly do internetového dispečinku implementovány všechny relevantní funkce včetně telemetrických údajů vozidel jako je spotřeba, otáčky motoru, stav tachometru, teplota přepravního prostoru atd., což je dáno schopností jednotek LUPUS číst údaje z elektronické sběrnice nákladních a užitkových vozidel téměř všech značek. Uživatel pracuje s vozidly skutečně on-line kdekoliv včetně zahraničí. Třídí si vozidla po skupinách, střediscích apod. včetně vyhodnocení libovolných statistik. Zadává tzv. body dosažení (nakládka, vykládka, . . . ), o čemž může být informován kdokoliv další prostřednictvím zprávy na mobilní telefon a nebo využívá funkci optimální vozidlo do místa určení. Systém importuje data z elektronických výpisů všech karet na PHM a umožňuje export dat do dalších ekonomických programů nebo jen jako výtisk pro potřeby vlastního účetnictví. Provozovatelem deklarované funkce: • kompletní dispečerské pracoviště • zobrazení vozidel v reálném čase na interaktivní mapě

4.4. WEBDISPEČINK

• elektronická kniha jízd • rozlišení soukromých a služebních jízd • import a zpracování dat z tankovacích karet • plánování tras, optimalizace rozvozů a svozů zboží • cestovní náhrady • podklady pro diety • exporty dat • elektronická identifikace řidiče • statistiky různých ukazatelů

17

18


Kapitola 5

Analýza V této kapitole je popsána základní analýza systému pro správu vozového parku. Zejména jeho koncepce (část 5.1), skupiny rolí a jejich úloha v systému (část 5.2), funkční požadavky (část 5.3) a podrobnější popis použité GPS jednotky (část 5.4). Je třeba zdůraznit, že by se dalo navrhnout obrovské množství dalších funkcí a případů užití pro podporu správy vozového parku a bezesporu by našly i své uplatnění. Díky navrhované koncepci systému je však bohužel téměř nereálné pokrýt potřeby všech společností a jejich požadavky na správu vozového parku. Z tohoto důvodu budou popsány jen skupiny funkcí, které by měly vyhovovat co největšímu počtu potenciálních klientů. Systém, zejména jeho návrh a implementace, by pak měl brát v potaz i případné požadavky na další rozšiřování funkčnosti.

5.1

Koncepce systému

Navrhovaný systém budou tvořit dvě aplikace: • uživatelská aplikace • aplikace pro komunikaci a obsluhu GPS jednotek Uživatelská aplikace (považujme ji za systém samotný), jak již bylo několikrát řečeno, bude realizována jako webová aplikace. Systém bude tvořen datovou a aplikační částí. Datovou část bude představovat relační databáze. Aplikační část bude tvořena výkonným jádrem a realizací jednotlivých funkčních požadavků. Architektura aplikace pro komunikaci a obsluhu GPS jednotek bude klient–server. Klient bude v tomto případě samotná GPS jednotka umístěná ve vozidle. Server bude řešit veškerou komunikaci s jednotkami a reagovat na vzniklé události. Aby systém dostál definovaných požadavků, bude využívat i další aplikace a služby. Konkrétně bude využívána: • interaktivní mapa světa • služba reverzní geolokace

19

20

KAPITOLA 5. ANALÝZA

• služba SMS brány Jedním s požadavků na systém je i zobrazování polohy a jízd vozidel na interaktivní mapě světa. S mapou samotnou se bude pracovat pouze na straně klienta, v jeho internetovém prohlížeči. Využitím mapového API však bude možné předávat získaná data i do systému a tam s nima dále nakládat. GPS jednotka bude posílat informace o poloze vozidla ve formě zeměpisných souřadnic – zeměpisnou šířku a délku. Pro knihu jízd je však důležitý i slovní popis místa. Ten bude získáván právě pomocí služby reverzní geolokace. Je třeba zmínit, že použití této služby, respektive jejich výsledků, nemusí být úplně přesné a záleží především na obsáhlosti databáze služby. Jelikož bude GPS jednotka sloužit i jako bezpečnostní prvek, bude muset nějakým způsobem uživatele upozorňovat na potencionální porušení bezpečnostních pravidel. Aby byl uživatel upozorněn včas, bude upozornění realizováno zasláním předem definované SMS zprávy na uvedené telefonní číslo. K tomuto účelu bude využita právě služba SMS brány.

5.2

Role v systému

V systému se budou vyskytovat tři skupiny rolí: • klient • vozidlo • uživatel Významem jednotlivých rolí je odlišit a zpřístupnit různé případy užití. Nejdůležitější skupinou je skupina klient, od které se odvíjí i plánované využití systému, a která určuje i možné role ve skupinách vozidlo a uživatel. Hierarchie rolí v systému je zachycena v tabulce 5.1. Tabulka 5.1: Hierarchie rolí v systému Klient Vozidlo

Hlídání vozidel auto

Správa vozového parku vůz pool služební

Uživatel uživatel

správce řidič

5.2. ROLE V SYSTÉMU

5.2.1

21

Klient

Systém by se mohl teoreticky bez klientských rolí úplně obejít a požadovaná funkčnost by mohla být přístupná jen na základě rolí uživatelských. Role v této skupině však určují, za jakým způsobem bude systém využíván a v kompletní verzi bude rovněž hrát roli i při platbě za službu. Budou rozlišovány dvě klientské role: • hlídání vozidel • správa vozového parku 5.2.1.1

Hlídání vozidel

Ne všichni klienti budou chtít využívat komplexní systém pro správu vozového parku, ale spokojí se jen s funkcionalitou týkající se polohy vozidla a knihy jízd. Tento klient si nebude moci spravovat vlastní vozidla sám, ale budou mu registrována na základě požadavku (objednávky) provozovatelem systému. Z tohoto vyplývá povinná instalace GPS jednotky u všech jeho evidovaných vozidel. 5.2.1.2

Správa vozového parku

Tento typ klienta bude mít přístupnou kompletní funkcionalitu správy vozového parku. Používání GPS jednotek už je v tomto případě volitelné. V případě nepoužívání jednotek je pak funkcionalita týkající se polohy vozidel nevyužita.

5.2.2

Vozidlo

Vozidlo, hlavní entita systému, bez které jeho používání postráda veškerý smysl, se bude vyskytovat v několika rolích. Každá role bude určovat jeho úlohu v rámci vozového parku. Bude se vyskytovat ve čtyřech rolích: • auto • vůz • pool • služební Hierarchire rolí je znázorněna na obrázku 5.1. 5.2.2.1

Auto

U této role vozidla bude možno sledovat pouze polohu vozidla a kontrolovat knihu jízd. K tomuto vozidlu tedy nelze evidovat žádné další informace.

22


Obrázek 5.1: Hierarchie vozidel

5.2.2.2

Vůz

Určuje vozidlo bez dalšího specifického využití ve vozovém parku. Od této role jsou odvozeny i typy vozidel pool a služební. Tento typ (a i typy odvozené) bude spravovat sám správce vozového parku. K těmto vozidlům bude možné evidovat: • dokumenty • faktury • výpisy z tankování Vůz se bude během svého „života“ vyskytovat v následujících stavech: • v provozu – s vozidlem může být libovolně nakládáno • mimo provoz – vozidlo je dočasně mimo provoz a nelze uskutečnit některé požadavky (nemůže být půjčeno v interní autopůjčovně) • vyřazen – vozidlo již není součástí vozového parku, nelze s ním nijak manipulovat, dostupné jsou jen informace z minulosti a není možné přidávat nové Stavový diagram vozu je uveden na obrázku 5.2. 5.2.2.3

Pool

Bude se jednat o vozidlo, které je v rámci společnosti určeno pro využívaní zaměstnanci například k plnění služebních jízd. Vozidlo se bude „půjčovat“ prostřednictvím interní autopůjčovny (rezervačního systému).

5.2. ROLE V SYSTÉMU

23

Obrázek 5.2: Stavový diagram role vůz

5.2.2.4

Služební

Vozidlo v této roli bude moci být přiřazeno konkrétnímu uživateli k užívání. Uživatel, který bude mít takovéto vozidlo přiřazeno, bude k němu moci sám evidovat dokumenty, faktury a výpisy z tankování. Přiřazovat jej bude správce vozového parku.

5.2.3

Uživatelské role

Systém bude využívaný více uživateli, kteří budou mít různá oprávnění. Z tohoto důvodu je nutné uživatele rozdělit do skupin podle příslušných oprávnění. V systému budou tyto uživatelské role: • uživatel • správce • řidič 5.2.3.1

Uživatel

• zobrazení evidovaných vozidel • zobrazení polohy vozidel • zobrazení knihy jízd vozidel • nastavení polohy vozidel (oblasti pohybu, povolená doba pohybu) 5.2.3.2

Správce

• správa uživatelů (řidičů) • správa vozidel • správa dokumentů • správa nákladových faktur

24


• importy výpisů z tankovacích karet • správa interní autopůjčovny • přiřazování služebních vozidel • zobrazení polohy vozidel • zobrazení knihy jízd vozidel • nastavení polohy vozidel (oblasti pohybu, povolená doba pohybu) • zobrazení manažerských přehledů

5.2.3.3

Řidič

• rezervace pool vozidel • zobrazení vlastních rezervací pool vozidel • v případě přiřazeného služebního vozidla může přidávat dokumenty, nákladové faktury, výpisy z tankovacích karet, může zobrazovat jeho knihu jízd a kalibrovat stav tachometru

5.3

Funkční celky

V této části textu jsou popsány jednotlivé funkční celky týkající se pouze správy vozového parku. Není zde tedy uveden žádný popis funkcí výkonného jádra aplikace. Systém pro správu vozového parku bude tvořen těmito funkčními celky: • správa uživatelů • správa vozidel • správa dokumentů • správa nákladových faktur • správa tankovacích karet • interní autopůjčovna • poloha vozidel a kniha jízd • přehledy a statistiky

5.3. FUNKČNÍ CELKY

5.3.1

25

Správa uživatelů

Do systému budou mít přístup pouze registrovaní uživatelé a budou moci využívat jen ty funkce, ke kterým budou mít oprávnění – budou mít přiřazenu některou z uživatelských rolí. Uživatelé se budou do systému přihlašovat pomocí klientského jména, uživatelského jméne a hesla. První uživatel bude vždy vytvořen při registraci klienta. V závislosti na typu klienta to bude buď správce nebo uživatel. Správa uživatelů se bude skládat z těchto funkcí: • přehled uživatelů • zobrazení detailu uživatele • vytvoření nového uživatele • editace uživatele • zrušení uživatele • vygenerování nového přístupového hesla

5.3.2

Správa vozidel

Skupina funkcí bude sloužit k základní evidenci vozidel a bude obsahovat tyto funkce: • přehled vozidel • zobrazení detailu vozidla • přidání nového vozidla • editace vozidla • kalibrace stavu tachometru • krátkodobé vyřazení vozidla z provozu • vyřazení vozidla z vozového parku • přiřazení služebního vozidla uživateli • evidence předávacích protokolů u služebních vozidel (při převzetí a navrácení vozidla)

5.3.3

Správa dokumentů

V průběhu provozu vozidla bude vznikat celá řada dokumentů, které bude potřeba uchovávat pro další využití (např. manuál k vozidlu, kopie VTP, atd.). Dokumentem se bude rozumět jakákoliv textová informace zadaná přímo v systému či přiložený jakýkoliv soubor (nebo obojí dohromady). Dokumenty bude možno třídit do složek (katogorií), které bude vytvářet sám správce. Jeden dokument bude moci být přiřazen do více složek. Kategorie budou sdíleny v rámci klienta. Správa dokumentů se bude skládat z těchto funkcí:

26


• přehled složek dokumentů • založení nové složky • editace složky • odstranění složky • zobrazení detailu složky • vytvoření nového dokumentu • editace dokumentu • odstranění dokumentu • zobrazení dokumentů

5.3.4

Správa nákladových faktur

Jelikož se ve finále od správy vozového parku očekává celkové snižování nákladů na provoz firemních vozidel, je nutné tyto náklady nějakým způsobem evidovat. Tento požadavek na funkčnost nemá v žádném případě konkurovat specializovanému účetnímu programu a proto budou u faktur evidovány jen nezbytně nutné informace, aby bylo možné sledovat náklady na provoz vozidla. K faktuře bude možné přidávat přílohy (naskenovaná faktura, apod.). Správa nákladových faktur se bude skládat z těchto funkcí: • přehled typů nákladů • přídání nového typu nákladu • editace typu nákladu • zrušení typu nákladu • přehled faktur • vložení nové faktury • editace faktury • detail faktury • odstranění (stornování) faktury


5.3.5

27

Správa tankovacích karet

Spotřeba pohonných hmot (a nejen těch) je dalším nákladem na provoz vozidla. Proto bude systém umožňovat import výpisů transakcí z tankovacích karet různých společností (CCS, OMV, SHELL, atd.). Výhody používání tankovacích karet není třeba nijak zvlášt rozvádět. Mezi největší výhody jejich používání jednoznačně patří podrobná evidence provedených transakcí. Samotné tankovací karty budou muset být v systému evidovány (alespoň základní informace, minimálně však číslo karty) a budou moci být přiřazeny ke konkrétnímu vozidlu. Požadavek na evidenci karet je oprávněný – je potřeba nějakým způsobem spárovat transakce, jelikož je ve výpisu transakcí uvedeno1 buď číslo tankovací karty nebo SPZ vozidla nebo obojí. Protože může při importu dojít k problémům s párováním, budou stanoveny priority pro párování transakcí: 1. k vozidlu, podle SPZ vozidla 2. k vozidlu, podle přířazené tankovací karty 3. k tankovací kartě 4. ke klientovi Ve výpisu transakcí se mohou vyskytovat i další důležité informace a ukazatele: • podle kódu zboží půjde náklady dále rozdělit na pohonné hmoty, provozní kapaliny, mytí, atd. • informace o stavu tachometru – může odpadat ruční kalibrace stavu tachometru v systému Problematikou v této funkčnosti je zejména rozdílný formát výpisů transakcí jednotlivých provozovatelů a také neidentická množina obsažených informací. Z tohoto důvodu bude pro evidenci vybrána právě společná množina informací. Pro využívání této funkčnosti je tedy nezbytně nutné, aby klient tankovací karty aktivně využíval. Správa tankovacích karet se bude skládat z těchto funkcí: • přehled tankovacích karet • přidání tankovací karty • odstranění tankovací karty • detail tankovací karty • přířazení tankovací karty k vozidlu • import výpisů z tankovacích karet 1

záleží na konkrétní společnosti nabízející tankovací karty a na formátu výpisu

28


Obrázek 5.3: Stavový diagram role vůz

5.3.6

Interní autopůjčovna

V mnoha vozozových parcích se vyskytují vozidla, jež nejsou přiřazena konkrétnímu uživateli (zaměstnanci) jako služební, ale slouží všem zaměstnancům pro plnění jejich úkolů (např. služební jízdy) – jedná se o tzv. „pool“ vozidla. Uživatelé si budou moci tato vozidla zapůjčit (rezervovat) pomoci jednoduchého rezervačního systému. Rezervace vozidel se bude skládat ze dvou kroků: • uživatel provede požadavek na rezervaci • správce rezervaci schválí nebo zamítne Pokud bude rezervace ve fázi požadavku nebo bude schválená, bude vozidlo v tomto termínu blokováno. Logicky tedy nebude možné provést další rezervace v překrývajících se termínech. Rezervace (naplánovaná i schválená) bude moci být stornována (pokud ještě neběží) a vozidlo tím pádem odblokováno. Doba, na kterou bude vozidlo rezervováno nepůjde lehce změnit – rezervace se bude muset stornovat a vytvořit nová. Při předávání vozidla bude možné ke konkrétní rezervaci evidovat předávací protokoly při převzetí a navrácení. Stavový diagram rezervace je na obrázku 5.3. Interní autopůjčovna se bude skládat z těchto funkcí: • vytvoření rezervace • přehled využívání vozidel • přehled rezervací čekajících na schválení • přehled aktuálně probíhajících rezervací


29

• archiv rezervací • správa rezervací (schválení, zamítnutí, storno) • evidence předávacích protokolů (při převzití a navrácení vozidla)

5.3.7

Poloha vozidel a kniha jízd

Sledování polohy a kontrola knihy jízd jsou další možnosti jak snížit náklady na provoz vozového parku (odhalení „černých jízd“, neoptimální trasy, atd.). Nehledě pak na to, že vést evidenci o provozu vozidel (knihu jízd) je povinností každého tuzemského dopravce provozujícího silniční dopravu. Tato povinnost se netýká osobních vozidel používaných dopravcem k silniční dopravě pro vlastní potřebu.[5] Z daňového hlediska je však třeba umět doložit spotřebu pohonných hmot vynaloženou v souvislosti s provozem automobilů. Dle § 24 zákona č. 586/1992 Sb., o daních z příjmů, ve znění pozdějších předpisů, jsou výdajem (nákladem) na dosažení, zajištění a udržení příjmů, výdaje na pracovní cesty v podobě výdajů na pohonné hmoty spotřebované silničním motorovým vozidlem zahrnutým v obchodním majetku poplatníka nebo v nájmu.[5] Ke sledování polohy vozidla bude využita GPS jednotka, která bude v reálném čase přenášet periodicky informace o poloze vozidla do systému. Na základě získaných informací o poloze bude generována kniha jízd. V systému se bude dát zobrazit na interaktivní mapě aktuální poloha vozidel, ale také konkrétní jízda. Použití GPS jednotky bude sloužit i jako prvek zabezpečení vozidla. K vozidlu budou moci být přířazeny oblasti, ve kterých se bude moci pohybovat. Oblasti budou vytvářeny pomocí interaktivní mapy. Při opuštění oblasti či při jejím dosažení bude možné odeslat varovnou SMS zprávu. Dalším prvkem zabezpečení bude kontrola pohybu v zakázanou dobu, bude signalizováno opět SMS zprávou. Poloha vozidel a kniha jízd se bude skládat z těchto funkcí: • zobrazení polohy (aktuální i v minulosti) vozidel na mapě • zobrazení knihy jízd • zobrazení konkrétní jízdy na mapě • správa povolených oblastí pohybu vozidla (vytvoření, zrušení, přiřazení oblasti k vozidlu) • nastavení povolené doby pohybu vozidla Tato funkčnost bude samozřejmě dostupná jen u vozidel, která budou používat GPS jednotku pro zjišťování polohy.

30


5.3.8

Přehledy a statistiky

Hlavním přínosem použití systému, jak už bylo několikrát zmíněno, by mělo být celkové snížení nákladů na provoz vozového parku. O kolik se ve výsledku skutečné náklady sníží, je už však záležitostí především správce vozového parku a nastavené politiky vozového parku. Jen samotná evidence všech možných informací není pro správu vozového parku dostačující. Je potřeba získané údaje nějakým způsobem kontrolovat a porovnávat. Z tohoto důvodu je kladen požadavek na funkce týkající se různých přehledů a statistik souvisejících s provozem vozidla. Přehledů a statistik se dá vymyslet nespočetné množství a ještě v různých variantách, proto bude tato funkčnost popsána jen pomocí jakýchsi tématických celků, které bude potřeba sledovat: • využití vozidel • spotřeba pohonných hmot • náklady na provoz vozidel • nájezdy kilometrů

5.4 5.4.1

GSM/GPRS/GPS jednotka CVPL-G204-A Popis jednotky

Jedná se o jednotku (tracker) založenou na GSM/GPRS2 síti a GPS satelitní navigaci, určenou převážně pro hlídání, respektive sledování vozidel3 . Jednotka poskytuje v dostatečném rozsahu funkce pro zabezpečení, sledování polohy, odposlouchávání a nouzovou signalizaci. Tracker je vidět na obrázku 5.4. Funkce jednotky: • sledování polohy (periodické i ad-hoc) • zabezpečení a alarmy – detekce nastartování (otočený klíček v zapalování) – detekce otevření dveří – detekce odpojeni baterie – detekce pohybu – překročení definované oblasti – překročení maximální definované rychlosti – odpojení palivového a napájecího systému • odposlouchávání zvuků z prostředí vozidla 2

k provozu je tedy potřeba aktivní SIM karta od některého mobilního operátora jejímu využití pro sledování čehokoliv jiného však nic nebrání – jen nemusí být využity všechny její funkce 3

5.4. GSM/GPRS/GPS JEDNOTKA CVPL-G204-A

31

Obrázek 5.4: GSM/GPRS/GPS jednotka CVPL-G204-A

• nouzová signalizace Ne všechny funkce však budou využity. Některé se navzájem vylučují (viz pracovní režimy), jiné pak nejsou úplně dostačující a navíc budou některé „zneužity“ pro získání (či simulaci) další funkčnosti. Pracovní režimy jednotky: • monitor • tracker Režim monitor slouží pouze k odposlouchávání komunikace v prostoru vozidla pomocí připojeného mikrofonu. Tracker (je nastaven jako výchozí) slouží ke sledování polohy, zabezpečení a k nouzové signalizaci. Sledování je možné ve dvou „komunikačních“ režimech: • SMS • internet V případě SMS režimu, uživatel odesílá předem definované SMS zprávy na telefonní číslo jednotky, která mu rovněž pomocí SMS zpráv odpovídá. Režim internet využívá pro komunikaci protokol TCP/IP pomocí GPRS mobilní sítě. K jednotkám je dodávána obslužná aplikace (obrázek 5.5) pracující v tomto režimu. Jedná se však o aplikaci uzavřenou, desktopovou a jednouživatelskou. Diky těmto vlastnostem tak nemá její širší využití téměř žádný užitek. Tento režim je však pro další používání rozhodně zajímavější minimálně z těchto důvodů: • koncový uživatel je úplně odstíněn od jednotky • přijatá data se následně jednodušeji zpracovávají, na rozdíl od SMS zpráv

32


Obrázek 5.5: Dodávaná obslužná aplikace pro GPS jednotky

5.4.2

Zhodnocení jednotky

Použitá jednotka má řadu výhod a nevýhod:

U U U U U D D D D D D

jednoduchá montáž jednoduchá konfigurace záložní baterie možnosti zabezpečení přesnost zaměření pozice

uzavřený (nedokumentovaný, neznámý) komunikační protokol (jeho „prolomení“ je uvedeno v sekci 5.4.4) absence interní paměti pro ukládání „stavů“ (důležité v případě výpadku GSM sítě či při roamingu) nelze přepínat soukromé/služební jízdy nelze připojit na sběrnici vozidla nelze spolehlivě detekovat začátek jízdy nelze automaticky dynamicky upravovat periodu odesílání informací o poloze


5.4.3

33

Konfigurace jednotky

Počáteční konfigurace se musí vždy provádět pomocí SMS zpráv. Aby jednotka korektně pracovala, musí být splněny tyto požadavky: • SIM karta musí mít vypnuté zadávání PIN kódu • nesmí být nastaveno žádné přesměrování4 hovoru Samotná konfigurace pomocí SMS zpráv, pro požadovanou funkčnost v této práci, se stáva z těchto kroků: 1. inicializace 2. změna hesla (defaultní je 123456) 3. nastavení administrátorského telefonního čísla 4. získání IMEI jednotky (důležité pro párování jednotka–vozidlo) 5. nastavení APN pro GPRS 6. pokud to mobilní síť vyžaduje, pak i nastavení uživatelského jména a hesla pro připojení k internetu 7. nastavení IP adresy a portu serveru (aplikace pro zpracování komunikace) 8. přepnutí komunikace na režim internet 9. prvotní nastavení periodického odesílaní polohy Jednotka vždy na každou zprávu odpovídá opět pomocí SMS zprávy. Na dotaz odpoví, příkaz potvrdí – ať už selhal nebo se provedl. Příklad prvotní konfigurace jednotky pomocí SMS zpráv je uveden v příloze A.2 na straně 68.

5.4.4

Komunikační protokol

Pro další potřeby systému, budou jednotky pracovat výhradně v režimu internet. Jak již bylo shrnuto v sekci 5.4.2, komunikační protokol je uzavřený a není tedy nijak a hlavně nikde dokumentovaný. Pro další využití je tedy nezbytně nutné znát jeho: • specifikaci – popis a význam zpráv • chování – reakce na zprávy

34


Obrázek 5.6: Diagram nasazení – komunikace jednotky s dodávanou aplikací

5.4.4.1

„Prolomení“ protokolu

Ke zjištění komunikačního protokolu dobře posloužila dodávaná obslužná aplikace a jedna aktivní (a správně nastavená) jednotka. Nasazení této aplikace s jednotkou je zobrazeno na obrázku 5.6. Samotné odhalování protokolu spočívalo v normálním používání aplikace a odposlechu s pomocí třetí strany (Man in the middle). Zkrátka a jednoduše řečeno: Byly vyzkoušeny a zaznamenány (zdokumentovány) všechny příkazy/dotazy na připojenou GPS jednotku, které aplikace umožňuje a rovněž i jejich případné odpovědi a reakce. Pro zachycení komunikace byly navrženy dva postupy: • využití aplikace Wireshark • vytvoření aplikace prostředníka Aplikace Wireshark je určena (mimo jiné) pro zachytávání a analýzu síťové komunikace. Její použití poodkrylo podstatný detail – jedná se o plain text protokol. Pro jeho detailní dokumentaci se však ukázala jako nepříliš vhodná – zejména příliš „hrubá“ a zdlouhavá. Wireshark slouží k zachytávání jednotlivých paketů a získává tak až zbytečně moc informací (hlavičky nižších vrstev referenčního modelu ISO/OSI). Potřebné informace jsou pak až v samotné „datové oblasti“ paketu. Mnohem vhodnějším způsobem bylo vytvoření jednoduché aplikace využívající TCP/IP sockety a vytvořit tak jakéhosi prostředníka (transparentní proxy). Jednotka se nepřipojuje přímo do obslužné aplikace, ale k proxy a ta teprve do aplikace (viz obrázek 5.7). Samotný prostředník pak správně propojuje příslušné vstupní a výstupní proudy a komunikaci přehledně zaznamenává. Získané poznatky ohledně protokolu jsou založeny čistě na výše popsaném experimentu. V průběhu používání jednotek může tedy dojít k následujícím situacím: • význam některých zpráv nebude úplně korektní • objeví se nové chování • objeví se nové typy zpráv 4

zejména musí být vypnut často použivaný registr zmeškaných hovorů či hlasová schránka


35

Obrázek 5.7: Diagram nasazení – komunikace jednotky s dodávanou aplikací přes prostředníka 5.4.4.2

Specifikace

Jak již bylo zmíněno v předchozí sekci 5.4.4.1, jedná se o textový (poměrně jednoduchý) protokol. Zprávy protokolu se dají (zhruba) rozdělit do tří základních skupin: • řídící • informativní • nastavovací Následující text popisuje jen ty zprávy, které budou využity pro potřeby aplikace. Ostatní nebudou potřeba vůbec nebo bude jejich role plněna jinak. Pro případnou dokumentaci všech zpráv stačí opět použít navrhovanou metodu v předchozí části. Řídící

Odesílá jednotka. Existují dvě zprávy:

• inicializace • udržování spojení Inicializace Význam: Posílá se pouze jednou za spojení, slouží jako inicializační během připojení jednotky k serverové části. Formát zprávy: ##,imei:,A; Odpověď: LOAD Parametry: imei jedinečné výrobní číslo jednotky Udržování spojení Význam: Posílá se periodicky, slouží k udržení TCP relace. Formát zprávy: ; Odpověď: ON Parametry: imei jedinečné výrobní číslo jednotky

36


Informativní Odesílá jednotka. Informují server o nastalé události, případně potvrzují některé nastavení. Důležité je, že po jejich příjmu není zasílána zpět žádná odpověď. Vyskytují se ve dvou variantách v zavislosti na dostupnosti GPS signálu: s informací o poloze imei:<1>,<2>,<3>,<4>,F,<5>,A,<6>,<7>,<8>,<9>,<10>,; bez informace o poloze imei:<1>,<2>,<3>,<4>,L,; Význam jednotlivých proměnných: 1. jedinečné výrobní číslo jednotky (IMEI) 2. specifikace zprávy 3. časová známka (YYMMDDHHMM) 4. administrátorské telefonní číslo 5. nadmořská výška v milimetrech 6. zeměpisná šířka 7. rozlišení severní (N) a jižní (S) zeměpisné šířky 8. zeměpisná délka 9. rozlišení vychodní (E) a západní (W) zeměpisné délky 10. rychlost v námořních mílích Specifikace zprávy: tracker – periodická informace o poloze help me – alarm, zmačknutí nouzového tlačítka acc alarm – alarm, detekce otočeného klíčku v zapalování (nastartované vozidlo) lt – potvrzení zapnutí zabezpečovacího režimu mt – potvrzení vypnutí zabezpečovacího režimu lf – selhání zapnutí zabezpečovacího režimu ac alarm – alarm, odpojení autobaterie door alarm – alarm, detekce otevření dveří et – potrvzení zrušení alarmu


37

Nastavovací Odesílá serverová část. Slouží k nastavení/ovládání jednotky. U některých zpráv jednotka posílá zpět případné potvrzení. Existují dva druhy těchto zpráv: zapínající **,imei:,<specifikace> upravující **,imei:,<specifikace>,<parametr> Specifikace zprávy: E – vypnutí (jakéhokoliv) alarmu L – zapnutí zabezpečovacího režimu M – vypnutí zabezpečovacího režimu C – upravuje periodu odesílání informací o poloze 5.4.4.3

Chování

Díky metodě popsané v 5.4.4.1 byl zjištěn nejen formát, ale rovněž i chování jednotky. Získané poznatky se týkají zejména alarmů: • jakýkoliv vyvolaný alarm odesílá upozornění s periodou tři minuty, dokud není vypnut příslušnou zprávou • existují dva druhy alarmů – provozní – zapínají a vypínají se jednotlivě – bezpečnostní – jejich vyvolání je podmíněno zapnutým zabezpečovacím (ARM) režimem. Vypnutí alarmu se podaří vždy. Nové zapnutí selže v případě (zpráva selhání zapnutí zabezpečovacího režimu), že podnět (např. stále otočený klíček v zapalování) alarmu stále přetrvává. Zjištěné chování musí brát v potaz aplikace, která bude řešit komunikaci s jednotkami. Chování bezpečnostního alarmu otočený klíček v zapalování bude zřejmě hrát významnou roli ve zjišťování stavu pohybu vozidla a v následném generování knihy jízd. Se stavem pohybu vozidla bude silně souviset i dynamická úprava periody odesílání informace o poloze vozidla.

38


Kapitola 6

Návrh 6.1

Datová část

Jako datové úložiště bude použita relační databáze PostgreSQL a nepředpokládá se použití systému jiného. V databázi budou ukládána pouze data, která přímo souvisí se systémem pro správu vozového parku a jeho deklarovanými funkcemi. V databázi nebudou ukládány žádné metadata nutná pro běh samotné aplikace. Pro pohodlnou a efektivní práci s databází bude použit framework Doctrine 2. Jedná se o framework pro objektově–relační mapování (ORM) určený pro PHP 5.3. V použití ORM lze obecně spatřit řadu výhod a nevýhod:

U U U U D D D

může přinést odstínění od konkrétního databázového systému usnadňuje provádění CRUD1 operací automatická konverze rozdílných datových typů mezi databázovým systémem a programovacím jazykem dovoluje využití dědičnosti a polymorfismu ikdyž to relační databáze nepodporuje

další vrstva v systému → vzniká další režie a zejména nároky na paměť nemusí podporovat všechny konstrukty relační databáze schéma se zpravidla definuje 2x – pro DDL a mapování

Díky zvolenému ORM frameworku je ovlivněn i výsledný datový model. Doctrine 2 v současné době (duben 2011) neumožňuje provést mapování v případě, že cizí klíč je zároveň i klíčem primárním nebo jeho částí. Tento problém je vyřešen jednoduše vytvořením syntetického primárního klíče a cizí klíč se pak stává klíčem kandidátním. Dalším problémem je reprezentace ISA hierarchie v návrhu a tím vlastně dědičnost. Aby bylo možné používat správně dědičnost i v Doctrine 2, je potřeba vždy u každé rodičovské 1

Create, Rread, Update, Delete operace

39

40

KAPITOLA 6. NÁVRH

entitní relace definovat nový atribut, tzv. discriminator. Hodnota tohoto atributu, zpravidla krátký textový řetězec, slouží právě k rozlišení konkrétního podtypu – v definici mapování řetězec určuje odvozenou entitu. Zajímavé je, ale i pochopitelné, že v tomto případě nedochází k předchozímu problému s cizím klíčem zárověň jako primárním. Samotný PostgreSQL je na tuto situaci dobře připraven – podporuje dědičnost tabulek, ale sám framework toho neumí využít. Zjednodušený datový model bez atributů, zachycující jen vazby mezi entitami je uveden na obrázku B.1. Kompletní datový model je pro svoji rozsáhlost umístěn pouze na přiloženém CD. Popis entit datového modelu je uveden v tabulce B.1. Při návrh datového modelu bylo samozřejmostí dodržování 3.NF a správná definice indexů.

6.2

Uživatelské rozhraní

Kvalitně a efektivně navržené uživatelské prostředí je rovněž důležitým kritériem pro případný úspěch aplikace. Kvalitně navržené rozhraní by mělo splňovat tato kritéria: • bezproblémová orientace uživatele • potřebné nástroje v dané situaci jsou vždy k dispozici • možnost individuálního přizbůsobení vzhledu aplikace • odolnost vůči neplatným vstupům ze strany uživatele • systém vždy uvádí, co vyžaduje a co vykonává Prvním předpokladem při návrhu uživatelského rozhraní je logické rozdělení obrazovky aplikace na několik celků, které se budou navzájem doplňovat. Prostředí bude rozděleno na čtyři části (obrázek 6.1): • hlavička s hlavním menu • sloupec hlavního obsahu • pravý sloupec pro dodatečné informace a nástroje • patička s případnými stavovými informacemi Obsah jednotlivých celků nelze brát zcela dogmaticky. Jejich obsah se bude skládat z komponent. Komponenty budou navzájem nezávislé, ale budou se tématicky doplňovat. To, co bude který celek obsahovat, bude dáno konfigurací. Každý celek bude moci být tvořen více libovolnými komponentami a každá komponenta bude moci být libovolně umístěna. Komponenty obsahu se dají rozdělit do pěti skupin: • nabídka • formulář • přehled

6.2. UŽIVATELSKÉ ROZHRANÍ

41

Obrázek 6.1: Hlavní rozdělení obrazovky systému

• detail • ostatní K zobrazení aplikace se bude využívat celá plocha okna prohlížeče. Problematické může být zobrazení při nižším rozlišení monitoru či menším rozměru okna. Šířka hlavního obsahového sloupce nemusí být dostatečná pro přehledné zobrazení všech informací. Z tohoto důvodu bude mít celé rozvržení nastavenu nějakou rozumnou minimální šířku i za cenu dodatečného horizontálního posouvání obsahu okna.

6.2.1

Nabídka

Úkolem nabídky (menu) je umožnit rychlý a intuitivní přechod k dalším funkcím systému. Aplikaci zpravidla tvoří jedna hlavní (stálá a nezávislá) a více vedlejších nabídek. Vedlejší nabídky už jsou většinou závislé na konkrétním funkčním celku. Položky nabídek se budou zobrazovat jen na základě oprávnění přihlášeného uživatele.

6.2.2

Formulář

Úlohou formulářů je přijímat uživatelský vstup v přívětivé formě a jeho odesláním vykonat nějakou operaci (akci). Formuláře se dají teoreticky rozdělit do dvou skupin: • pro definici záznamů – vytváření nových nebo editace existujících záznamů • pro zobrazování záznamů – různé filtrační a vyhledávací formuláře

42

KAPITOLA 6. NÁVRH

U všech formulářů budou platit stejná pravidla. Každá položka formuláře bude podléhat určitým kontrolám. Pokud tyto kontroly nebudou splněny, formulář nesmí být dále zpracován. Při nesplnění požadovaných kritérií musí být zobrazeno zdůvodnění toho, co selhalo. Uživatel musí mít možnost zadané údaje opravit a formulář znovu odeslat. Samozřejmé je předvyplnění už jednou zadaných údajů.

6.2.3

Přehled

Přehled bude určen pro zobrazení seznamu libovolných záznamů. Zobrazení přehledu bude vždy realizováno formou tabulky. Jeden řádek tabulky bude představovat právě jeden záznam. Pro potřeby manipulace se záznamem bude možné přehled doplnit i o patřičné nástroje reprezentované názornou ikonou. Tyto nástroje se budou zobrazovat jen na základě oprávnění přihlášeného uživatele. Protože se dá předpokládat využití přehledů i v jiných aplikacích, bude umožněno přehled vyexportovat do formátu CSV nebo XLS.

6.2.4

Detail

Detail je komponenta, která bude zobrazovat veškeré údaje evidované k jednomu konkrétnímu záznamu. K detailu se ve většině případů budou pojit i další závislé záznamy. Informace o záznamu bude povětšinou zobrazovány formou tabulky, kde dvojice název–hodnota bude tvořit její řádek. Součástí detailu bude moci být i nabídka dostupných akcí (nástrojů), zobrazovat se budou opět na základě oprávnění přihlášeného uživatele.

6.2.5

Ostatní

Ne všechny komponenty lze zařadit do výše popsaných skupin. Tuto skupinou budou tvořit komponenty, které se budou lišit svým vzhledem, chováním, či nepůjdou nijak dostatečně zobecnit. Mezi tuto formu obsahu budou například patřit komponenty pro zobrazování map.

6.3

Výkonné jádro

V současné době existuje obrovské množství lepších či horších, vhodných či méně vhodných PHP frameworků (Zend, Nette, CakePHP, Symphony, atd.) pro vývoj webových aplikací. Použití existujících řešení má své světlé, ale i stinné stránky. Mezi kladné vlastnosti jednoznačně patří široká uživatelská základna, časem ověřená kvalita a ve většině případů i technická podpora ze strany vývojářů. Naproti tomu, překážkou u stávajících řešení může (do jisté míry a ne u všech) být jejich technologická zastaralost, přílišná univerzálnost či nevyhovující koncepce. Srovnáním a testováním známých PHP frameworků se zabývá například článek [7].

6.3. VÝKONNÉ JÁDRO

43

Pro tento informační systém bude navrženo nové, vlastní řešení. Návrh frameworku se pokusí spojit ty nejlepší vlastnosti a myšlenky známých řešení s nápady vlastními. Na framework budou kladeny tyto požadavky: • rychlost • bezpečnost • modulárnost • znovupoužitelnost • robustnost • variabilita • jednoduché použití • rychlý vývoj aplikací

6.3.1

Architektura

Architektura aplikace bude ideově vycházet z klasického návrhové vzoru Model–View– Controller (MVC). Protože se MVC ve své původní podobě téměř nepoužívá a role a vztahy jednotlivých vrstev jsou chápány dost volně, bude se v tomto případě dát hovořit spíše o jeho derivátu Model–View–Presenter (MVP). Ve zkratce jsou úlohy jednotlivých vrstev následující: • model – představuje doménovou logiku, zajišťuje manipulaci s daty a přístup k nim • view – převádí data reprezentovaná modelem do podoby vhodné k prezentaci • presenter – seznamuje view s modelem a realizuje uživatelské akce Dále je potřeba zmínit, že se bude jednat o variantu tzv. pasivní view. V této variantě view nebude nikdy komunikovat přímo s modelem, ale data mu bude předávat presenter. Samotné view a presentery budou realizovány jako znovupoužitelné komponenty. Model bude představovat ORM Doctrine 2 a vrstvu objektů pro přístup k datům (data–access–object, DAO). Protože bude existovat více druhů různých požadavků, budou existovat ještě další nadřazené vrstvy. Na nejvyšší úrovni to bude delegátor požadavků, který bude mít za úkol vybírat správný kontrolér. Tyto kontroléry ve druhé vrstvě už budou realizovat obsluhu konkrétního požadavku. Při návrhu se bude počítat s kontroléry obsluhujícími tyto požadavky: • načtení celé stránky • načtení části stránky • stažení souboru Architektura jádra je naznačena na obrázku 6.2.

44

KAPITOLA 6. NÁVRH

Obrázek 6.2: Architektura aplikace – vyšší řídící vrstva a MVP

6.3.2

Sestavení aplikace

Úkolem jádra je především vykonávání rutinních úloh a poskytnutí dalších prostředků pro usnadnění realizace výsledné aplikace. V sekci 6.3.1 je popsána architektura a zmíněny její tři komponenty. Model představuje konkrétní doménovou (business) logiku. Realizaci doménové logiky však nelze zobecnit a už vůbec ji nelze popsat na úrovni jádra. Komponenty presenter a view představují tzv. prezentační vrstvu a ta už může být dostatečně zobecněna a popsána. Sekce 6.2 popisuje základní uživatelské rozhraní a také rozdělení prvků do skupin. Při troše odvahy se dá říci, že různé informační systémy jsou složeny z velké části právě z různých variant těchto prvků. Jádro tedy bude poskytovat podporu pro realizaci a jednoduchou obsluhu těchto komponent: • nabídka • formulář • přehled • detail • obecná šablona Aby byly splněny požadavky na rozvržení uživatelského rozhraní, bude navíc existovat komponenta stránka, která se bude chovat jako kontejner pro ostatní prvky a bude je umisťovat na konkrétní pozici. Řešení pomocí předpřipravených komponent přináší řadu výhod a nevýhod. Výhodou je především to, že komponenty budou malé a budou plnit jeden konkrétní problém. Odpadá starost vytvářet HTML šablony a také budou zautomatizovány rutinní operace (např. validace a konverze dat – viz sekce 6.3.6). Řešení rovněž přináší velkou variabilitu a modularitu celého systému. Nezávislost jednotlivých komponent může být někdy i na škodu. Některá data mohou být v jednom požadavku vyžadována vícekrát v různých komponentách. Problém však může být řešitelný využitím vhodného cachovacího mechanismu.

6.3. VÝKONNÉ JÁDRO

45

Největším problém může být požadavek na specifické chování komponenty či celého systému, který nebyl zachycen už při prvotním návrhu. Nezbyde tak nic jiného, než vytvořit třeba novou komponentu se specifickým chováním. Mnoha problémům se však dá vyhnout kvalitní analýzou a návrhem. Výsledná aplikace bude sestavena z nezávislých komponent na základě konfigurace popsané v sekci 6.3.3.

6.3.3

Konfigurace systému

Aby byla navržená architektura dostatečně modulární a variabilní, bude „sestavení“ jednotlivých „obrazovek“ systému realizováno na základě externí konfigurace. Konfigurace systému se bude dát teoreticky rozdělit na „systémovou“ a „aplikační“. První skupina bude představovat informace nezbytně nutné pro běh samotné aplikace (přistupové údaje k databázi, emailovému účtu, cesty, atd.). Aplikační konfigurace bude definovat samotné komponenty a také to, jaké komponenty budou umístěny na konkrétní obrazovce. Jak pro komponenty, tak pro stránky bude možné nadefinovat oprávnění pro uživatelské role, přidat další požadavky na omezení přístupu a také definovat handlery pro odchytávání vyjímek. Nabízí se několik možností konfigurace: • XML • YAML • JSON • INI • databáze • ve zdrojovém kódu Každá z vyjmenovaných možností má své klady i zápory. Popisovat je detailně však postrádá smysl. Určitě by nebyl problém realizovat systém tak, aby bylo možné využívat libovolný způsob, avšak systém bude používat konfiguraci pouze pomocí XML dokumentů. Načítání konfigurace z externích zdrojů při každém požadavku znovu, by znamenalo v případě PHP zbytečnou režii navíc. Z tohoto důvodu a díky tomu, že je PHP jazyk skriptovací a nekompiluje se, bude prováděn jakýsi „překlad“ do jeho nativního kódu jen jednou.

6.3.4

Inicializace systému

Pro správný běh systému je důležité, aby byly dostupné potřebné knihovny, načtena konfigurace a nakonfigurovány a inicializovány další komponenty systému. Inicializace systému se bude provádět při každém požadavku. Pořadí jednotlivých akcí je: 1. zavedení minimálního jádra systému

46

KAPITOLA 6. NÁVRH

2. inicializace a spuštení automatického načítání PHP tříd 3. načtení externí konfigurace 4. konfigurace Doctrine 2 a připojení k databázi 5. spuštění delegátora požadavků

6.3.5

Uživatelská práva a omezení

Díky tomu, že bude v systému existovat více rolí, je důležité, aby jádro automaticky kontrolovalo oprávnění k jednotlivým funkcím. V systému budou použity dva způsoby kontroly oprávnění: • uživatelská role • omezení Každý uživatel v systému bude moci mít přiřazeno více uživatelských rolí. Každá uživatelská role bude moci využívat nějakou podskupinu funkcí. Protože se v systému bude vyskytovat více skupin rolí, budou pro jemnější rozlišení oprávnění použity tzv. „omezení“. Pod omezením si lze představit jednoduchou proceduru, která bude mít za úkol ověřit, jestli je splněn určitý předpoklad – například jestli se jedná o typ klienta Správa vozového parku. Ke každé stránce či komponentě bude možné připojit libovolné množství omezení a uživatelských rolí. Omezení bude možné využívat i kdekoliv přímo v kódu aplikace. Protože se jedna stránka může skládat z více komponent a jak u stránky, tak u komponenty mohou být nastavena různá omezení, mohla by zbytečně vznikat další režie díky jejich opakované kontrole. Z tohoto důvodu se nikdy nebude při jednom požadavku provádět opakovaná kontrola stejného omezení. Logika vyhodnocení oprávnění je jednoduchá. Postupuje se od stránky ke komponentám a nejprve jsou kontrolovány uživatelská práva a pak omezení. Oprávnění vyhovují, pokud má uživatel přířazenu alespoň jednu požadovanou uživatelskou roli a byla splněna všechna omezení. Je obecně těžké říci, jak bude systém reagovat na nesplnění některého oprávnění. Reakce systému se bude lišit i podle toho, v jakém okamžiku k nesplnění dojde. Pro různé situace nesplnění požadovaných oprávnění lze definovat jakési obecné scénáře: • stránka – uživatelská role ∗ nepřihlášený uživatel bude přesměrován na přihlašovací stránku ∗ přihlášený uživatel bude informován o nedostatečných právech – oprávnění ∗ uživatel bude informován o tom, že nemá potřebná oprávnění • komponenta

6.4. APLIKACE PRO KOMUNIKACI S GPS JEDNOTKAMA

47

– uživatelská role ∗ komponenta se nezobrazí – oprávnění ∗ komponenta se nezobrazí Každé omezení ale může při splnění/nesplnění reagovat různě. Pro představu, může dojít k přesměrování na jakoukoliv jinou stránku a uživatel ani nemusí vědět, že nebyla nějaká skutečnost splněna – takovéto omezení pak slouží k větvení.

6.3.6

Uživatelské datové typy a validátory

Systém bude získávat různá data od uživatele, se kterými bude nějakým způsobem dále nakládáno. Reprezentace (formát) těchto dat se však v systému, potažmo v celém prostředí zpravidla liší od reprezentace jakou používá uživatel – různá národní prostředí a zvyklosti. V žádném případě nepřipadá v úvahu omezit uživatele na zadávání dat v přesně definovaném formátu. Bohužel je PHP dynamicky typovaný jazyk, sám v základu neumí provádět potřebné konverze automaticky a neobsahuje ani základní podporu pro práci s formuláři. Funkcí pro konverzi už však nabízí dostatek. Z těchto důvodů bude jádro obsahovat i prostředky pro práci s uživatelskými datovými typy. Tyto prostředky budou mít za úkol provádět konverzi z uživatelské formy do formy prostředí a naopak. Datových typů bude moci být vytvořeno neomezené množství. S datovými typy souvisejí i validátory. Aby mohla být provedena konverze z uživatelské formy, musí být nejdřív ověřeno, zda je převod vůbec možný. Každý datový typ je tedy zároveň i validátorem. Ke konkrétnímu prvku bude možné připojit další validátory (např. minimální délka řetězce, číslo v intervalu, atd.). Zadaná data jsou správná, pokud projdou všemi validátory. Uživatelské datové typy a validátory budou využívány především u webových formulářů.

6.4

Aplikace pro komunikaci s GPS jednotkama

Spolupráce systému s GPS jednotkami má uživateli přinést informace o aktuální poloze vozidel, umožnit generovat knihu jízd a také plnit úlohu bezpečnostního prvku. Aby systém splnil kladené požadavky v dostatečném rozsahu a kvalitě, nevystačí si jen s využitím funkcí samotné jednotky a jednoduchou aplikací, která by pouze ukládala informace o poloze do databáze. Z důvodů popsaných v části 5.4 je tedy nutné navrhnout a realizovat obslužnou aplikaci, na kterou budou kladeny tyto požadavky: funkční • dynamická úprava periody odesílání informací o poloze • správná detekce začátku a konce jízd • podpora pro reverzni geolokaci

48

KAPITOLA 6. NÁVRH

• odesílání SMS zpráv při definovaných událostech • ukládání získaných dat do databáze nefunkční • víceuživatelská (bude se připojovat více jednotek) • rychlá • robustní

6.4.1

Pohyb vozidla

Aby bylo možné realizovat požadavky na dynamickou úpravu periody odesílání informací o poloze a správnou detekci začátku a konce, je nutné definovat stavy pohybu vozidla a přechody mezi nimi. V úvahu připadají tyto stavy: • neurčený – v tomto stavu se nachází vozidlo, pokud nelze s jistotou určit stav jiný a navíc ještě nelze zjistit předchozí stav. Setrvává v něm zpravidla chvíli po navázání spojení s aplikací, do doby, než je spuštěna detekce stavu pohybu a získána odpověď. Následujícím stavem může být pouze stojí nebo jízda. • stojí – definuje stav, kdy je vozidlo v klidovém stavu (stojí). Může přejít do stavu jízda (pokud je motor nastartován) nebo pohyb (pokud rychlost překročí definovanou dolní mez). • jízda – je regulérní stav pohybu, kdy bylo vozidlo nastartováno a probíhá tedy jízda. Jízda může přejít pouze do stavu stojí a to pouze tehdy, pokud byl vypnut motor vozidla. • pohyb – je další stav pohybu, ale nedošlo k němu nastartováním vozidla (např. je vozidlo odtahováno). Může přejít do stavu jízda (pokud bude motor nastartován) nebo stojí (pokud rychlost klesne pod definovanou dolní mez). Stavový diagram je zachycen na obrázku 6.3 Jsou-li definovány stavy pohybu a přechody mezi nimi, může být realizován požadavek na dynamickou změnu periody odesílání informací o poloze. Požadavek na toto chování je zcela oprávněný. V případě, že vozidlo stojí, není potřeba odesílat informaci tak často a naopak, když je v pohybu tak co nejčastěji – aby byly údaje v knize jízd co nejpřesnější. Perioda se bude upravovat při přechodu do stavu jízda a stojí. Měnit periodu jen na základě aktuální rychlosti je nevhodné. Aktuální rychlost vozidla může být nulová, ale přesto může vykonávat jízdu (např. stojí na křižovatce, popojíždí, atd.). Dalším problémem by mohlo být automatické generování knihy jízd – mohla by být zbytečně „rozkouskovaná“ na více menších jízd. V sekci 5.4.4 je popsán komunikační protokol, význam zpráv a chování jednotky. Pro detekci stavu pohybu vozidla bude „zneužit“ zabezpečovací (ARM) režim. Pokud je tento režim aktivní (a jednotka je správně zapojena), tak dochází při nastartování vozidla k vyvoláni alarmu detekce otočeného klíčku v zapalování (acc alarm) – máme tak detekován začátek jízdy.

6.4. APLIKACE PRO KOMUNIKACI S GPS JEDNOTKAMA

49

Obrázek 6.3: Stavový diagram pohybu vozidla

Horší situace je však v rozpoznání konce jízdy. K tomuto bude opět využito vlastností ARM režimu. ARM režim může být kdykoliv (a vždy s úspěchem) vypnut. Pokud se jej však pokusíme znovu zapnout a existuje situace, která má za následek vyvolání patřičného bezpečnostního alarmu, jeho aktivace selže (zpráva selhání zapnutí zabezpečovacího režimu – lf). Toto chování je klíčem ke správné detekci ukončení jízdy vozidla.

6.4.2

Koncepce

Architektura aplikace pro komunikaci s GPS jednotkama bude klient–server, kde klienta představuje samotná GPS jednotka. Server bude čekat na příchozí TCP/IP spojení na předem definovaném portu. Po připojení jednotky vytvoří nový obslužný „subsystém“ určený pouze pro komunikaci s konkrétní jednotkou. Obslužný subsystém bude tvořen třemi vlákny určenými pro: • příjem zpráv – receiver • odesílání zpráv – sender • detekci stavu pohybu vozidla – motion detector Protože se bude připojovat více klientů a používat operace blokující čtení, je požadavek na využití vláken oprávněný. Receiver bude přijímat zprávy odeslané jednotkou a na základě typu zajišťovat i jejich obsluhu (každý typ zprávy bude mít svou vlastní obsluhu). Posílání zpráv jednotce bude probíhat pomocí sdílené blokující fronty, z níž bude zprávy vybírat a odesílat sender. V sekci 6.4.1 je popsáno, jak lze detekovat ukončení jízdy vozidla. Tuto úlohu bude plnit motion detector. Jeho úloha bude spočívat v periodickém zasílání požadavků na zapnutí ARM režimu. Podobně jako u dynamické změny periody odesílání informací o poloze se

50

KAPITOLA 6. NÁVRH

bude v závislosti na stavu pohybu vozidla měnit i perioda pokusů aktivace tohoto režimu. Z jakou přesností bude detekováno zastavení vozidla (přechod ze stavu jízda do stojí), bude záležet právě na délce této periody. Před samotnou „aktivní“ komunikací bude muset být nejdříve provedeno spárování jednotky s vozidlem. Párování bude probíhat na základě imei čísla, které je obsaženo ve všech typech zpráv (viz sekce 5.4.4). Protože zprávy mohou chodit v libovolném pořadí, je nezbytně nutné provádět pokus o spárování v obsluze všech typů zpráv. Pokud ke spárování nedojde, bude obslužný subsystém jednotky bezprostředně ukončen. Požadavky na podporu reverzní geolokace a odesílání SMS zpráv při definovaných událostech jsou již záležitostí obsluhy konkrétní zprávy.

Kapitola 7

Implementace 7.1

Základní informace

Systém pro podporu správy vozového parku (jeho uživatelská část) je realizovaný jako webová aplikace s předpokládným modelem distribuce software jako služba. Aplikace je napsána ve skriptovacím jazyku PHP ve verzi 5.3 a využívá veškeré jeho „nové“ vlastnosti, zejména vylepšený objektový model a jmenné prostory. V tomto jazyce je realizována celá aplikační logika. Prezentační vrstva je realizována pomocí znovupoužitelných komponent. Doménová logika využívá pro perzistenci dat objektově–relační–mapování Doctrine 2. Pro potřebu interaktivních mapových podkladů byl zvolen projekt OpenStreetMap a OpenLayers. Rovněž byl využit JavaScript a s ním spojená technologie AJAX, bez kterého by bylo téměř nemožné realizovat některé požadavky. Druhou část systému tvoří aplikace pro komunikaci s vybraným typem GPS jednotky, realizováná jako serverová služba. Tato aplikace je napsána v programovacím jazyce JAVA. Úkolem aplikace je zpracovávat data z GPS jednotek. K reverzní geolokaci využívá rovněž projekt OpenStreetMap, konkrétně službu Nominatim. Aplikace umí pro nadefinované událostí odesílat SMS zprávy. Využívá k tomu další službu, se kterou komunikuje prostřednictvým webové služby. Systém pro svůj běh vyžaduje: • HTTP server Apache 2.2 s modulem rewrite • PostgreSQL alespoň ve verzi 8.4 • Java Runtime Environment alespoň verze 1.5 • PHP 5.3 a moduly: – PHP PDO – PHP Mcrypt – Gettext

51

52

KAPITOLA 7. IMPLEMENTACE

7.2

Nasazení

Popsat nasazení systému tak, jak bude provozován ve skutečnosti není jednoduché. Zejména je problematické popsat na jakých zařízeních vlastně poběží a kolik jich vlastně bude vyžadovat. Naproti tomu je ale přesně definováno, jaké prostředky bude potřebovat pro svůj běh. Diagram nasazení je velmi obecně popsán na obrázku 7.1. Důležitá je oblast Informační systém pro správu vozového parku, která popisuje řešený systém. Systém se dá rozložit na čtyři subsystémy: • webový – Apache HTTP Server • datový – PostgreSQL • datové úložiště – síťový filesystém • GPS Tracker server – GPS Tracker Service Každý subsystém představuje potřebný prostředek, ale neříká nic o tom, jak bude realizován uvnitř. U webového může být nasazena nějaka forma vyrovnání zátěže (load balancing), u datového se může uvažovat o replikaci, apod. V zásadě tedy mohou všechny subsystémy běžet i na jednom výkonějším serveru.

7.3 7.3.1

Zajímavé řešené problémy Automatické načítání tříd pro PHP

Narozdíl od programovacího jazyka JAVA nedefinuje PHP žádnou logickou strukturu zdrojových kódů. Při realizaci rozsáhlejších projektů tak může vznikat chaos při jejich strukturalizaci a hlavně pak při jejich vzájemném propojování (linkování). Tyto problémy se dají rešit různě a na různých úrovních. Základem jsou dobře strukturované funkční celky a definované vrstvy – linkování musí mít řád a v žádném případě by neměla vzniknout propletená pavučina. Nejprimitivnějším způsobem je využít jazykový konstrukt include (respektive jeho varianty) pro veškeré linkování ručně. Pokud není aplikace vyvíjena objektově, pak je tato možnost jediná. Pokud je však aplikace realizována objektově, může být lepším, ale zbytečně náročným, řešením načtení všech požadovaných tříd při startu aplikace pomocí nějaké funkce. PHP ve verzi 5 doznalo značných změn. Asi nejzásadnější změnou je kompletně přepracovaný objektový model, který se tak více přiblížil ostatním jazykům (ale pořad je zaostalejší). Dále přinesla funkci __autoload, která je volána interpretem automaticky v případě, že vyžadovaná třída dosud nebyla načtena. Verze 5.3 přináší podporu jmenných prostorů (nemusí být vůbec využívány), ale pořád zůstáva nutnost řešit načítání tříd – jmenný prostor nijak neurčuje cestu ke třídě. Většina současných PHP frameworků poskytuje vlastní podporu pro načítání tříd za běhu a není tomu jinak ani u tohoto systému. Myšlenka realizace spočívá ve využití interní

7.3. ZAJÍMAVÉ ŘEŠENÉ PROBLÉMY

53

Obrázek 7.1: Diagram nasazení

funkce token_get_all, která provede lexikální analýzu předaného zdrojového kódu a vrátí seznam všech jeho lexikálních elementů. Pro potřeby automatického načítání je potřeba znát pouze název třídy nebo interfacu (nic jiného PHP nezná, dále se pojmem třída rozumí i interface) včetně jmenného prostoru a cestu k nim. Vůbec není potřeba znát jejich definici (obsah), vystačí si pouze z jejich deklarací. Při procházení získaných lexikálních elementů se stačí zaměřit pouze na tyto (jsou to interní konstanty PHP): • T_NAMESPACE – klíčové slovo namespace • T_NS_SEPARATOR – oddělovač jmenného prostoru \ • T_STRING – libovolný řetězec, který není klíčovým slovem • T_CLASS – klíčové slovo class

54


• T_INTERFACE – klíčové slovo interface • ; – znak ukončení příkazu V algoritmu 1 se používá pole lexelms, které představuje jednotlivé lexikální elementy získané pomocí funkce token_get_all. Každý element obsahuje jeho identifikaci (vlastnost element) a jeho hodnotu (vlastnost value). Proměnná i určuje index pole aktuálně zpracovávaného elementu, ns název nalezeného jmenného prostoru a isN s indikuje jeho nalezení. Množina classes představuje nalezené třídy v zadaném zdrojovém kódu. Algoritmus 1 Získání deklerací tříd pomocí lexikálního analyzátoru 1. ns := ε 2. isN s := false 3. classes := ∅ 4. for každý lexikální element l ∈ lexelms do 5. i ← index v seznamu aktuálního elementu 6. if l.element = T_NAMESPACE then 7. ns := ε 8. isN s := true 9. else if isN s = true then 10. if l.element = T_NS_SEPARATOR then 11. ns := ns+ T_NS_SEPARATOR 12. else if l.element = T_STRING then 13. ns := ns + l.value 14. else if l.element = ’;’ then 15. ns := ns+ T_NS_SEPARATOR 16. isN s := false 17. end if 18. else if l.element = T_CLASS or l.element = T_INTERFACE then 19. class := ns + lexelms[i + 2].value 20. classes.put(class) 21. end if 22. end for Algoritmus předpokládá správnou syntaxi zdrojového kódu. Pro nalezení tříd a interfaců se využívá těchto skutečností: • pokud je nalezena definice jmenného prostoru (T_NAMESPACE), pak všechny následují nalezené řetězce (T_STRING) a oddělovače jmeného prostoru (T_NS_SEPARATOR) až po nalezení znaku ukončení příkazu (;) tvoří kompletní název jmenného prostoru • pokud je nalezena deklarace třídy (T_CLASS) nebo interfacu (T_INTERFACE), tak následující lexikální element je bílý znak (nezajímavý) a po něm zákonitě následuje vyžadovaný název • v jednom zdrojovém souboru může být definováno více tříd a interfaců, ale i jmenných prostorů


7.3.2

55

Kniha jízd

Propojení systému s GPS jednotkou přináší pouze informaci o poloze konkrétního vozidla v konkrétní dobu. Aby bylo možné vůbec generovat použitelnou knihu jízd, je potřeba: • detekovat správně stavy pohybu vozidla • převést informaci o poloze (zeměpisné souřadnice) na název konkrétního místa (revezní geolokaci) • počítat délku jízdy Správná detekce stavu pohybu vozidla Řešení prvního bodu je uvedeno v části 6.4.1. Při každé příchozí zprávě s informací o poloze vozidla je do databáze uložen i stav jeho pohybu. Reverzní geolokace Ke splnění druhého bodu je využita služba Nominatim projektu OpenStreetMap. Její použití a získání výsledku je triviální – stačí pouze vytvořit HTTP požadavek metodou GET na správnou url, se správnymi parametry. Výsledek je pak obsažen v odpovědi. Je potřeba říci, že výsledek nemusí být stoprocentně správný – databáze služby neobsahuje nekonečně mnoho bodů, v nejhorším případě vrací nejbližší známou lokalitu. V žádosti se vyskytuje celkem pět parametrů: • format – udáva formát v jakém bude odpověď, možnosti jsou json nebo xml • lat – zeměpisná šířka zadaná jako reálné číslo ve stupních • lon – zeměpisná délka zadaná jako reálné číslo ve stupních • zoom – celé číslo v rozsahu 1 až 18 udává jak podrobná bude odpověď • addressdetails – určuje, jestli bude v odpovědi element address, hodnota může být 1 nebo 0 Ukázka žádosti a odpovědi: HTTP GET požadavek http://nominatim.openstreetmap.org/ reverse?format=json&lat=50.105082&lon=14.451955&zoom=18&addressdetails=1 HTTP odpověď ve formátu JSON { "place_id":"1369135", "licence":"Data Copyright OpenStreetMap Contributors, ...", "osm_type":"node", "osm_id":"296788390", "lat":"50.1049925",

56


"lon":"14.4520857", "display_name":"1425/42, U Průhonu, Holešovice, Praha, ...", "address": { "house_number":"1425/42", "road":"U Průhonu", "suburb":"Holešovice", "city":"Praha", "administrative": "Hlavní město Praha", "county":"Hlavní město Praha", "state":"Praha", "postcode":"17000", "country":"Česká republika", "country_code":"cz" } }

Vzdálenost dvou zeměpisných bodů Vybraná GPS jednotka není žádným způsobem spojena se sběrnicí vozidla. Díky tomu tedy není možné získat informaci o přesné délce jízdy a jediným řešením je tedy délku počítat. Protože budou informace o poloze získávány s nějakou periodou, bude dostačující, když se vzdálenost bude počítat jako nejkratší vzdálenost dvou bodů na kouli. Ujetá vzdálenost tak bude mít jen informativní charakter. Pro výpočet vzdálenosti dvou bodů A a B na kouli je použita ortodroma, což je je oblouk vedený po povrchu přímo nad vlastní spojovací přímkou. Délka ortodromy d se vypočítá dosazením souřadnic do kosinové věty sférické trigonometrie (předpokládá se počítání v radiánech): d = arccos (sin ϕ1 sin ϕ2 + cos ϕ1 cos ϕ2 cos (|λ2 − λ1 |)) · r (7.1) kde ϕ1 a ϕ2 jsou zeměpisné šířky bodů A a B, λ1 a λ2 zeměpisné délky bodů A a B, r je poloměr Země. Generování Algoritmus 2 pro vygenerování knihy jízd je velice jednoduchý. Na svém vstupu předpokládá seznam bodů polohy points. Na jeho výstupu je seznam všech nalezených jízd rides. Aby uvedený postup pracoval správně, je nutné aby správně fungovala detekce stavu pohybu vozidel. Rozdhodující jsou stavy RIDE a STOP. Proměnná isRide indikuje detekovaný začátek jízdy.

7.3.3

Pohyb vozidla ve vymezených oblastech

Samotná GPS jednotka dokáže indikovat dosažení/opuštění definované oblasti. Bohužel se však tato oblast definuje pouze jako obdelníková (zadává se horní levý a pravý dolní roh) a navíc smí být nastavena pouze jedna oblast. Z tohoto důvodu bylo potřeba přenést zodpovědnost za tento požadavek na aplikaci komunikující s GPS jednotkama.


57

Algoritmus 2 Generování knihy jízd 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.

rides := new List() isRide := false for každý bod p ∈ points do if p.state = RIDE then if isRide = false then ride := new Ride() rides.add(ride) end if rides.last().add(p) else if p.state = STOP then if isRide = true then rides.last().add(p) isRide :=false end if end if end for

Uživatel si může pomocí interaktivní mapy vytvořit libovolný počet polygonálních oblastí a nastavit je jako zóny pohybu vozidel. Pro detekci vozidla uvnitř polygonové oblasti byl využit algoritmus pro testování polohy bodu vůči polygonu, popsaný v [6] na straně 564. Protože oblast může být vytvořena jako konvexní, stejně tak i nekonvexní polygon, je použita varianta sledování paprsku. Princip této metody je takový, že je z daného bodu (v našem případě aktuální poloha vozidla) výslána polopřímka (paprsek) libovolným směrem a počítá se, kolikrát je protnuta hranice mnohoúhelníku. Je-li hranice protnuta v lichém počtu případů, je vozidlo uvnitř oblasti, v sudém počtu je pak vně. Protože vozidlo může mít přiřazeno více oblastí pohybu, jsou vyhodnocovány postupně všechny oblasti. Nalézá-li se alespoň v jedné z nich, pak je to vyhodnoceno jako pohyb uvnitř oblasti. Aby bylo zaručené správné fungování algoritmu i v mezních případech, kdy paprsek protíná vrchol polygonu nebo je rovnoběžný z některou z jeho hran, jsou navíc ještě aplikována pravidla popsaná v [3].

58


Kapitola 8

Testování 8.1

Testování kódu

Systém byl podrobně testován v průběhu celého jeho vývoje metodou White–Box. Díky dobře navrženému modulárnímu jádru a vlastně celé koncepci aplikace bylo testování velice jednoduché. Na začátku všeho byly důkladně otestovány jednotlivé části jádra. Při realizaci jednotlivých funkčních požadavků už mohlo být testování zaměřeno pouze na jejich správné chování a odezvu. Pokud byla v průběhu testování nalezena chyba v prostředcích jádra, byla samozřejmě opravena.

8.2

Testování sestavení aplikace

V části 6.3.2 je popsán způsob, jakým se sestavuje výsledná aplikace. Tato část testů tedy spočívala v kontrole správného obsahu jednotlivých obrazovek (složení stránky z kompoment), přechodů mezi obrazovkami a správně nastavených uživatelských oprávnění. Pokud byla nalezena neshoda s požadavky, bylo sestavení upraveno jen editací příslušných konfiguračních souborů (viz části 6.3.3 a 6.3.5).

8.3

Testování aplikace pro komunikaci s GPS jednotkami

Tato část testování byla časově nejnáročnější. Probíhala ve třech fázích: • imaginární jednotka • reálná jednotka • v provozu První fáze testování probíhala bez potřeby použít jednotku. Díky tomu, že je komunikační protokol jednotky textový, bylo testování realizováno s pomocí aplikace telnet. S pomocí kterého se připojovalo k aplikaci. Smyslem tohoto testování bylo ověřit správnou identifikaci zpráv a zkontrolovat, jestli se volá jejich správná obsluha.

59

60

KAPITOLA 8. TESTOVÁNÍ

S první fází testování by se dalo vystačit, ale bylo by zapotřebí nadefinovat správné scénáře s reakcí jednotky, což by bylo časově náročné a zajisté i zdrojem chyb. Z tohoto důvodu bylo zvoleno testování s reálnou jednotkou. Jednotka však nebyla umístěna ve vozidle, ale byla zapojena „na stole“. V této fázi už byly testovány a vyhodnocovány všechny reakce jednotky a obslužné aplikace. Ve druhé fázi byla odladěna obsluha zpráv a upřesněno chování jednotky. Aby byly vyloučeny případné další nedostatky, bylo potřeba provést dlouhodobé testování, ale už v reálném nasazení. Z tohoto důvodu byly jednotky umístěny do třech vozidel, u kterých byl zajištěn pravidelný provoz. Aplikace zaznamenávala veškerou komunikaci pro pozdější vyhodnocování. Kontrolována byla správná reakce na zprávy a především správná detekce začátku a konce jízdy (popsáno v 6.4.1).

8.4

Akceptační test

Akceptačními testy bylo provedeno ověření, zda byly splněny všechny funkční požadavky kladené na systém. V současné době (květen 2011) běží část aplikace (konkrétně funkčnost pro typ klienta Hlídání vozidel) v pilotním testovacím režimu. V systému je registrováno 7 klientů a je evidovaných 9 vozidel s aktivní GPS jednotkou.

Kapitola 9

Srovnání a zhodnocení V kapitole 4 bylo provedeno seznámení s vybranými rešeními. Rovněž bylo zmíněno, proč je těžké provést důkladné testování a ověření jejich deklarovaných funkcí. Rešeršní část obsahovala informace převzaté z oficiálních obchodních materiálů provozovatele. Aby bylo možné provést alespoň základní porovnání jednotlivých systému s navrženým řešením, jsou funkce popsány jen jako jakési tématické okruhy, které nezacházejí do přílišných detailů. Porovnání systémů je uvedeno v tabulce 9.1. Na základě srovnání tématických okruhů funkčností, lze řící, že všechny systémy splňují požadavky na komplexní správu vozového parku. Řící jaké řešení je nejvhodnější z hlediska funkčnosti nelze. Subjektivně se jeví jako nejpropropracovanější, co se týka koncepce celé aplikace, řešení yMonitor. Aplikace má kvalitně navržené a propracované uživatelské rozhraní a orientace v něm je bezproblémová. Řešení CarNet zase nabízí propracované řešení knihy jízd, ale zaostává v koncepci uživatelského rozhraní a horší orientaci v systému. Nejhorší koncepci uživatelského rozhrání a i jeho grafickou úpravu má řešení Webdispečink. Systém je nepřehledný a nesrozumitelný. Řešení T-Cars Fleet Managemet nemůže být hodnoceno, protože do něj nebyl získán přístup. Všechny systémy jsou z hlediska funkčnosti téměř identické. V případě navrhovaného řešení však nebylo možné realizovat některé důležité funkce. Jedná se zejména o funkce, které využívají vybranou GPS jednotku – přepínaní typu jízdy přímo z vozidla, vzdálená indentifikace řidiče a získávání dalších dat z GPS jednotek. Navrhované řešení (zatím) žádným způsobem neumožňuje manipulovat s knihou jízd (spojování a rozdělování jízd, určení důvodu jízdy, apod.). Dohledat učel jízdy však lze na základě rezervace vozidla v interní autopůjčovně. Dalším nedostatkem může být absence plánování tras. Nelze tedy detekovat případné odbočení od naplánované trasy v reálném čase, ale až na základě kontroly knihy jízd. Jdou však definovat oblasti, ve kterých se vozidlo smí pohybovat. Výhodou navrženého řešení je bezpochyby rozdělení systému pro dva rozdílné typy klientů. Systém tak mohou využívat i jednotlivci (ale i společnosti) jen za účelem dalšího zabezpečení vozidla bez obsažení, pro ně nepotřebných funkcí.

61

KAPITOLA 9. SROVNÁNÍ A ZHODNOCENÍ

CarNet

Webdispečink

Navrhované řešení

Funkce kniha jízd poloha vozidel na mapě služební/osobní jízda další data z jednotek identifikace řidiče kalibrace stavu tachometru SMS notifikace plánování tras náklady na provoz management tankování import transakcí tankovacích karet diety a kapesné servisní plánování evidence dokumentů interní autopůjčovna předávací protokoly přehledy a statistiky možnost využití systému jen jako bezpečnostního prvku bez další funkčnosti

T-Cars Fleet Managemet

Tabulka 9.1: Porovnání možností existujících systémů s navrhovaným

yMonitor

62

4 4 4 4 4 4 4 4 4 4

4 4 4 4 4 4 4 4 4 4

4 4 4 4 4 7 4 4 4 4

4 4 4 4 4 7 4 7 4 4

4 4 7 7 7 4 4 7 4 4

4

4

4

4

4

4 4 7 7 7 4

4 4 7 7 7 4

7 4 7 7 7 4

4 7 7 4 7 4

7 7 4 4 4 4

7

7

7

7

4

Kapitola 10

Závěr Tato diplomová práce se zabývala problematikou správy vozového parku. V rámci vyprácování bylo prostudováno velké množství dostupných informací o Fleet Managementu. Na základě získaných informací byl navrhnut a implementován informační systém pro podporu správy vozového parku s ohledem na minimalizaci nákladů spojených s provozem vozidel. Samotnému návrhu aplikace předcházela analýza požadavků. Při jejím provádění hrály roli požadavky správců vozových parků a také inspirace v existujících řešeních. Některá řešení jsou popsána v kapitole 4. Při vypracovávání byly čerpány informace z [10], [12], [11], [8], [9], [14] a [1]. Na základě získaných poznatků byl navrhnut systém, který bude podporovat: • správu vozidel • správu uživatelů • správa dokumentů • evidenci nákladů spojených s provozem vozidla • interní autopůjčovnu tzv. „pool“ vozidel • služební vozidla • evidenci předávacích protokolů • importy výpisů tankovacích karet • získávání informací o poloze vozidel pomocí technologie GPS • na základě získaných informací o poloze generování knihy jízd • manažerské přehledy spojené s náklady na provoz vozidla Pro potřebu zjišťování polohy vozidel byla využita GSM/GPRS/GPS jednotka CVPLG204-A. Protože se jedná o uzavřenou technologii, byl uveden postup, jak byl zjištěn a popsán komunikační protokol.

63

64

KAPITOLA 10. ZÁVĚR

Na základě analýzy bylo přistoupeno k samotnému návrhu systému. V prvé řadě bylo navrženo výkonné jádro pro webovou aplikaci a poté datový model problematiky. Po těchto krocích následoval návrh samotných funkcí systému. Výsledkem práce je systém určený pro podporu správy vozového parku. Systém je určen pro dva druhy potenciálních klientů – pro správu vozového parku a hlídání vozidel. Systém tvoří dvě aplikace. První aplikace je samotný informační systém (jeho uživatelská část), realizovaný jako webová aplikace. Druhá aplikace slouží pro komunikaci s GPS jednotkami. Jejím úkolem je zpracování získaných dat o poloze vozidel. Díky vlastnostem vybrané jednotky slouží tato aplikace také k rozšíření a nahrazení (funkce zabezpečení) jejích funkcí a zároveň přidává funkce nové (spolehlivá detekce začátku a konce jízdy a s tím dynamická úprava periody odesílání informací o poloze). V současné době (květen 2011) běží část aplikace (konkrétně funkčnost pro typ klienta Hlídání vozidel) v pilotním testovacím režimu. V systému je registrováno 7 klientů a je evidovaných 9 vozidel s aktivní GPS jednotkou. Na systému však zbývá ještě hodně práce, zejména v části určené pro provozovatele systému. Systém je navržen tak, aby jej bylo možné jednoduše rozšířit o další funkcionalitu týkající se podpory správy vozového parku. Jmenovitě je v plánu zavedení podpory pro další GPS jednotky a zdokonalení generování knihy jízd. Dále plánování, kontrola a optimalizace tras, vytvoření verze určené pro chytré mobilní telefony, atd.

Literatura [1] AZ MOBILITY. Optimalizace celkových nákladů vlastnění (CNV) [online]. Dostupné z: . [2] CARNET MONITOROVÁNÍ VOZIDEL, spol. s r. o. CarNet. , stav z 25. 4. 2011. [3] Dan Sunday. Fast Winding Number Inclusion of a Point in a Polygon [online]. Dostupné z: . [4] HI Software Development, spol. s r. o. Webdispečink. , stav z 25. 4. 2011. [5] Ing. Vladimír Hruška. Evidence (kniha) jízd [online]. [cit. 21. 4. 2011]. Dostupné z: . [6] Jiří Žára, Bedřich Beneš, Petr Felkel a Jiří Sochor. Moderní počítačová grafika. Brno : Computer Press s.r.o, první edition, 2004. ISBN 80-251-0454-0. [7] Petr Daněk. Velký test PHP frameworků: Zend, Nette, PHP a RoR [online]. 2008. [cit. 21. 4. 2011]. Dostupné z: . [8] Radek Mužík. Fleet Management v praxi – Obecný pohled na problematiku FM [online]. 2007. Dostupné z: . [9] Radek Mužík. Fleet Management v praxi – Efektivita provozu firemního autoparku a jak ji měřit [online]. 2007. Dostupné z: . [10] Radim Kozel. I střední a malé firmy mohou mít kvalitní fleet management! [online]. 2010. [cit. 21. 4. 2011]. prezentace z konference Fleet Management 2010. Dostupné z: . [11] Radovan Mužík. Klíčové parametry efektivního Fleet Managementu [online]. 2010. [cit. 21. 4. 2011]. prezentace z konference Fleet Management 2010. Dostupné z: .

65

66

LITERATURA

[12] Roman Macháček. Fleet management [online]. 2010. [cit. 21. 4. 2011]. prezentace z konference Fleet Management 2010. Dostupné z: . [13] T-Cars System, spol. s r. o. T-Cars Fleet Managemet. , stav z 25. 4. 2011. [14] Tomáš Johánek. Software pomůže nejen se správou vozového parku [online]. 2010. Dostupné z: . [15] YMS, a. s. Čo je Fleet Controlling? [online]. [cit. 21. 4. 2011]. Dostupné z: . [16] ySystem, spol. s r. o. yMonitor. , stav z 25. 4. 2011.

Příloha A

GSM/GPRS/GPS jednotka CVPL-G204-A

A.1

Zapojení

Obrázek A.1: Význam konektorů jednotky

67

68

PŘÍLOHA A. GSM/GPRS/GPS JEDNOTKA CVPL-G204-A

Obrázek A.2: Schéma zapojení jednotky

A.2

Prvotní konfigurace pomocí SMS zpráv

Inicializace Formát zprávy begin Příkaz begin123456 Odpověď begin ok!

Nastavení administrátorského telefonního čísla Formát zprávy admin Příkaz admin123456 00420775123456 Odpověď admin ok!

A.2. PRVOTNÍ KONFIGURACE POMOCÍ SMS ZPRÁV

Získání IMEI jednotky Formát zprávy imei Dotaz imei123456 Odpověď imei:354779034444431

Nastavení APN pro GPRS Formát zprávy APN Příkaz APN123456 data.vodafone.cz Odpověď APN ok!

Nastavení IP adresy a portu serveru Formát zprávy adminip <port> Příkaz adminip123456 90.185.242.207 9000 Odpověď adminip ok!

Přepnutí komunikace na režim internet Formát zprávy GPRS Příkaz GPRS123456 Odpověď GPRS ok!

Nastavení periodického odesílaní polohy Formát zprávy fix<jednotka>n Příkaz fix120s***n123456 Odpověď Tracker is activated!

69

70

PŘÍLOHA A. GSM/GPRS/GPS JEDNOTKA CVPL-G204-A

Příloha B

Datový model

71

72

PŘÍLOHA B. DATOVÝ MODEL

Obrázek B.1: Datový model systému (hodně zjednodušený kvůli názornosti)

73 Tabulka B.1: Entity datového modelu Název sys_l10n sys_log sys_role sys_user sys_user_login_log sys_user_roles address address_state car_factory car_model file file_data file_mime_type fm_car fm_car_fleet fm_car_pool fm_car_user fm_car_category fm_category_cars fm_car_disabled fm_car_tachometer fm_car_transfer fm_transfer_protocol fm_car_users fm_client fm_client_type fm_client_type_roles fm_client_user fm_document_generic fm_document_files fm_document fm_document_category fm_category_documents fm_fuel_card fm_fuel_card_import fm_fuel_card_import_item fm_invoice fm_invoice_category fm_reservation_request fm_reservation_result fm_tracker_setup fm_tracker fm_tracker_area fm_tracker_area_point fm_tracker_has_area fm_tracker_stop

Popis dostupné lokalizace v systému systémový log uživatelské role uživatel Log přihlašení uživatelů přiřazení uživatelských rolí uživateli adresa číselník států automobilka modely automobilky metada souboru data souboru mime–typy auta vozidla pool vozidla služební vozidla skupiny vozidel přiřazení vozidel do skupin krátkodobé vyřazení vozidla z provozu stav tachometru vozidla předávací protokol pro konkrétní rezervaci detail předávacích protokolů přidělená služební vozidla klienti v systému typ klienta uživatelské role klienta uživatel klienta obecná definice dokumentu soubory připojené k obecnému dokumentu konkrétní dokument kategorie konkrétního dokumentu přiřazení dokumentů do kategorií tankovací karty importy transakcí tankovacích karet jednotlivé transakce z tankovacích karet nákladové faktury skupiny nákladových faktur požadavy na rezervaci vozidla vyřízené rezervace konfigurace gps jednotek informace o poloze z gps jednotky oblasti určené pro pohyb vozidla body oblastí přiřazení vozidla do oblasti intervaly zákazu pohybu

74

PŘÍLOHA B. DATOVÝ MODEL

Příloha C

Kniha jízd

Obrázek C.1: Ukázka zobrazení jízdy na interaktivní mapě

75

76

PŘÍLOHA C. KNIHA JÍZD Tabulka C.1: Ukázka vygenerované knihy jízd z jednoho dne

Čas

Odkud–kam

Vzdálenost

00:25

cz Vítkov Vítkov Opavská

00:15:03

00:40

cz Fulnek Moravské Vlkovice 46211

8 km

06:27


00:31:34

06:58

cz Odry Odry 647

15 km

07:05

cz Odry Odry 647

00:30:04

07:35

cz Studénka Nová Horka 46431

24 km

07:47

cz Studénka Nová Horka 46431

00:09:03

07:56

cz Studénka Studénka nad Odrou 46427

4 km

08:28

cz Studénka Studénka nad Odrou 46427

00:14:23

08:42

cz Studénka Butovice 464

5 km

09:03


00:03:03

09:06


1 km

09:12


00:18:02

09:30

cz Bílovec Bílovec-město Jeremenkova

12 km

10:03

cz Bílovec Bílovec-město Jeremenkova

00:12:02

10:15

cz Bílovec Bílovec-město Pod Strání

2 km

10:26

cz Bílovec Bílovec-město Pod Strání

00:21:03

10:47

cz Stará Ves nad Ondřejnicí Stará Ves nad Ondřejnicí 48615

18 km

10:55

cz Stará Ves nad Ondřejnicí Stará Ves nad Ondřejnicí 48615

00:15:02

11:10

cz Petřvald Petřvald u Nového Jičína 4806

5 km

11:22


00:30:03

11:52

cz Frýdek-Místek Lískovec u Frýdku-Místku 477

23 km

11:55


00:18:03

12:13

cz Frýdek-Místek Místek 28. října

5 km

13:24

cz Frýdek-Místek Místek 28. října

00:12:02

13:36

cz Frýdek-Místek Frýdek El. Krásnohorské

4 km

13:44


00:18:50

14:02

cz Paskov Oprechtice ve Slezsku 4841

12 km

14:18


00:03:02

14:21


1 km

14:36


00:09:04

14:45

cz Brušperk Brušperk 486

5 km

15:11


00:06:02

15:17


1 km

15:27


00:15:03

15:42


9 km

15:53


00:53:51

16:47


41 km

17:34


00:03:04

17:37


1 km

Max. rychlost

Prům. rychlost

70 km/h

29 km/h

57 km/h

28 km/h

84 km/h

47 km/h

54 km/h

26 km/h

57 km/h

16 km/h

37 km/h

9 km/h

112 km/h

37 km/h

52 km/h

8 km/h

105 km/h

51 km/h

71 km/h

17 km/h

104 km/h

44 km/h

65 km/h

13 km/h

67 km/h

21 km/h

72 km/h

38 km/h

32 km/h

4 km/h

100 km/h

30 km/h

17 km/h

5 km/h

87 km/h

34 km/h

103 km/h

46 km/h

31 km/h

13 km/h

Příloha D

Ukázka uživatelského rozhraní existujících řešení

Obrázek D.1: Ukázka č. 1 uživatelského rozhraní systému yMonitor

77

78

PŘÍLOHA D. UKÁZKA UŽIVATELSKÉHO ROZHRANÍ EXISTUJÍCÍCH ŘEŠENÍ


79


80


Obrázek D.4: Ukázka č. 1 uživatelského rozhraní systému CarNet

Obrázek D.5: Ukázka č. 2 uživatelského rozhraní systému CarNet

81

Obrázek D.6: Ukázka č. 1 uživatelského rozhraní systému Webdispečink

82



83


84


Příloha E

UML diagramy

Obrázek E.1: Diagram komponent výkonného jádra systému

85

86

PŘÍLOHA E. UML DIAGRAMY

Obrázek E.2: Diagram hierarchie grafických komponent

87

Obrázek E.3: Diagram hierarchie událostí (zpráv) GPS jednotek

Informační systém pro správu vozového parku. Bc. Jiří Strašák

Recommend Documents