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

Transkript

1

2

3 Č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

4

5 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.

6

7 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

8

9 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

10

11 Obsah 1 Úvod Cíl práce Důvody vedoucí ke vzniku Správa vozového parku 5 3 Úvodní studie Rozdělení systémů Desktopová aplikace Klient server aplikace Jednouživatelský systém Víceuživatelský systém Nižší třída systémů pro správu vozového parku Střední třída systémů pro správu vozového parku Vyšší třída systémů pro správu vozového parku Distribuce aplikace Softwarový balík Software jako služba Požadavky na aplikaci Technologie Existující řešení ymonitor T-Cars Fleet Managemet CarNet Webdispečink Analýza Koncepce systému Role v systému Klient Hlídání vozidel Správa vozového parku Vozidlo Auto Vůz xi

12 Pool Služební Uživatelské role Uživatel Správce Řidič Funkční 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 GSM/GPRS/GPS jednotka CVPL-G204-A Popis jednotky Zhodnocení jednotky Konfigurace jednotky Komunikační protokol Prolomení protokolu Specifikace Chování Návrh Datová část Uživatelské rozhraní Nabídka Formulář Přehled Detail Ostatní Výkonné jádro Architektura Sestavení aplikace Konfigurace systému Inicializace systému Uživatelská práva a omezení Uživatelské datové typy a validátory Aplikace pro komunikaci s GPS jednotkama Pohyb vozidla Koncepce

13 7 Implementace Základní informace Nasazení Zajímavé řešené problémy Automatické načítání tříd pro PHP Kniha jízd Pohyb vozidla ve vymezených oblastech Testování Testování kódu Testování sestavení aplikace Testování aplikace pro komunikaci s GPS jednotkami Akceptační test Srovnání a zhodnocení Závěr 63 A GSM/GPRS/GPS jednotka CVPL-G204-A 67 A.1 Zapojení A.2 Prvotní konfigurace pomocí SMS zpráv 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

14

15 Seznam obrázků 1.1 Stav nastavení pravidel Fleet Managementu rok Stav využití telematiky rok Stav využití IS rok Vývojová stádia telematických sledovacích systémů 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 Hlavní rozdělení obrazovky systému Architektura aplikace Stavový diagram pohybu vozidla Diagram nasazení A.1 Význam konektorů jednotky A.2 Schéma zapojení jednotky B.1 Datový model systému C.1 Ukázka zobrazení jízdy na interaktivní mapě D.1 Ukázka č. 1 uživatelského rozhraní systému ymonitor D.2 Ukázka č. 2 uživatelského rozhraní systému ymonitor D.3 Ukázka č. 3 uživatelského rozhraní systému ymonitor D.4 Ukázka č. 1 uživatelského rozhraní systému CarNet D.5 Ukázka č. 2 uživatelského rozhraní systému CarNet D.6 Ukázka č. 1 uživatelského rozhraní systému Webdispečink D.7 Ukázka č. 2 uživatelského rozhraní systému Webdispečink D.8 Ukázka č. 3 uživatelského rozhraní systému Webdispečink E.1 Diagram komponent výkonného jádra systému xv

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

17 Seznam tabulek 5.1 Hierarchie rolí v systému Porovnání možností existujících systémů s navrhovaným B.1 Entity datového modelu C.1 Ukázka vygenerované knihy jízd z jednoho dne xvii

18

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

20

21 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

22 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)

23 1.2. DŮVODY VEDOUCÍ KE VZNIKU 3 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)

24 4 KAPITOLA 1. ÚVOD

25 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 funkce 1 : strategické operativní 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 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

26 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]

27 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 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

28 8 KAPITOLA 3. ÚVODNÍ STUDIE 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 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ů 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 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.).

29 3.2. DISTRIBUCE APLIKACE 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 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 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 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):

30 10 KAPITOLA 3. ÚVODNÍ STUDIE 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 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ů

31 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

32 12 KAPITOLA 3. ÚVODNÍ STUDIE 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.

33 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

34 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 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

35 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, , 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ů em 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.

36 16 KAPITOLA 4. EXISTUJÍCÍ ŘEŠENÍ 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ě

37 4.4. WEBDISPEČINK 17 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ů

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

39 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

40 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 Hlídání vozidel Správa vozového parku Vozidlo auto vůz pool služební Uživatel uživatel správce řidič

41 5.2. ROLE V SYSTÉMU 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 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 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 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 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.

42 22 KAPITOLA 5. ANALÝZA Obrázek 5.1: Hierarchie vozidel 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 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).

43 5.2. ROLE V SYSTÉMU 23 Obrázek 5.2: Stavový diagram role vůz 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 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č Uživatel zobrazení evidovaných vozidel zobrazení polohy vozidel zobrazení knihy jízd vozidel nastavení polohy vozidel (oblasti pohybu, povolená doba pohybu) Správce správa uživatelů (řidičů) správa vozidel správa dokumentů správa nákladových faktur

44 24 KAPITOLA 5. ANALÝZA 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ů Ř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

45 5.3. FUNKČNÍ CELKY 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 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) 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í:

46 26 KAPITOLA 5. ANALÝZA 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ů 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

47 5.3. FUNKČNÍ CELKY 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í uvedeno 1 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

48 28 KAPITOLA 5. ANALÝZA Obrázek 5.3: Stavový diagram role vůz 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í

49 5.3. FUNKČNÍ CELKY 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) 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.

50 30 KAPITOLA 5. ANALÝZA 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 GSM/GPRS/GPS jednotka CVPL-G204-A Popis jednotky Jedná se o jednotku (tracker) založenou na GSM/GPRS 2 síti a GPS satelitní navigaci, určenou převážně pro hlídání, respektive sledování vozidel 3. 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 3 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

51 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

52 32 KAPITOLA 5. ANALÝZA Obrázek 5.5: Dodávaná obslužná aplikace pro GPS jednotky Zhodnocení jednotky Použitá jednotka má řadu výhod a nevýhod: U jednoduchá montáž U jednoduchá konfigurace U záložní baterie U možnosti zabezpečení U přesnost zaměření pozice D uzavřený (nedokumentovaný, neznámý) komunikační protokol (jeho prolomení je uvedeno v sekci 5.4.4) D absence interní paměti pro ukládání stavů (důležité v případě výpadku GSM sítě či při roamingu) D nelze přepínat soukromé/služební jízdy D nelze připojit na sběrnici vozidla D nelze spolehlivě detekovat začátek jízdy D nelze automaticky dynamicky upravovat periodu odesílání informací o poloze

53 5.4. GSM/GPRS/GPS JEDNOTKA CVPL-G204-A 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 ) 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ě 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

54 34 KAPITOLA 5. ANALÝZA Obrázek 5.6: Diagram nasazení komunikace jednotky s dodávanou aplikací 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

55 5.4. GSM/GPRS/GPS JEDNOTKA CVPL-G204-A 35 Obrázek 5.7: Diagram nasazení komunikace jednotky s dodávanou aplikací přes prostředníka Specifikace Jak již bylo zmíněno v předchozí sekci , 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:<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: <imei>; Odpověď: ON Parametry: imei jedinečné výrobní číslo jednotky

56 36 KAPITOLA 5. ANALÝZA 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

57 5.4. GSM/GPRS/GPS JEDNOTKA CVPL-G204-A 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:<imei>,<specifikace> upravující **,imei:<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 Chování Díky metodě popsané v 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.

58 38 KAPITOLA 5. ANALÝZA

59 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: může přinést odstínění od konkrétního databázového systému usnadňuje provádění CRUD 1 operací U automatická konverze rozdílných datových typů mezi databázovým systémem a programovacím jazykem U dovoluje využití dědičnosti a polymorfismu ikdyž to relační databáze nepodporuje D další vrstva v systému vzniká další režie a zejména nároky na paměť D nemusí podporovat všechny konstrukty relační databáze D 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

60 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

61 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 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 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

62 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ů 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 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 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].

63 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í 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.

64 44 KAPITOLA 6. NÁVRH Obrázek 6.2: Architektura aplikace vyšší řídící vrstva a MVP 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 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.

65 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 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, ové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 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

66 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ů 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í komponenta uživatel bude informován o tom, že nemá potřebná oprávnění

67 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í 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

68 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í 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 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.

69 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 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 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

70 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.

71 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

72 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 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í

73 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

74 54 KAPITOLA 7. IMPLEMENTACE 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. isns := 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. isns := true 9. else if isns = 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. isns := 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ů

75 7.3. ZAJÍMAVÉ ŘEŠENÉ PROBLÉMY 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 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 reverse?format=json&lat= &lon= &zoom=18&addressdetails=1 HTTP odpověď ve formátu JSON { "place_id":" ", "licence":"data Copyright OpenStreetMap Contributors,...", "osm_type":"node", "osm_id":" ", "lat":" ",

76 56 KAPITOLA 7. IMPLEMENTACE "lon":" ", "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 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.

77 7.3. ZAJÍMAVÉ ŘEŠENÉ PROBLÉMY 57 Algoritmus 2 Generování knihy jízd 1. rides := new List() 2. isride := false 3. for každý bod p points do 4. if p.state = RIDE then 5. if isride = false then 6. ride := new Ride() 7. rides.add(ride) 8. end if 9. rides.last().add(p) 10. else if p.state = STOP then 11. if isride = true then 12. rides.last().add(p) 13. isride :=false 14. end if 15. end if 16. 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].

78 58 KAPITOLA 7. IMPLEMENTACE

79 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 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 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

80 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.

81 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

82 62 KAPITOLA 9. SROVNÁNÍ A ZHODNOCENÍ Tabulka 9.1: Porovnání možností existujících systémů s navrhovaným Funkce ymonitor T-Cars Fleet Managemet CarNet Webdispečink Navrhované řešení 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

83 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 CVPL- G204-A. Protože se jedná o uzavřenou technologii, byl uveden postup, jak byl zjištěn a popsán komunikační protokol. 63

84 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.

85 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 [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 [5] Ing. Vladimír Hruška. Evidence (kniha) jízd [online]. [cit ]. 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, ISBN [7] Petr Daněk. Velký test PHP frameworků: Zend, Nette, PHP a RoR [online] [cit ]. Dostupné z: < velky-test-php-frameworku-zend-nette-php-a-ror/>. [8] Radek Mužík. Fleet Management v praxi Obecný pohled na problematiku FM [online] Dostupné z: < default.aspx>. [9] Radek Mužík. Fleet Management v praxi Efektivita provozu firemního autoparku a jak ji měřit [online] Dostupné z: < 2011/cs/use/2/default.aspx>. [10] Radim Kozel. I střední a malé firmy mohou mít kvalitní fleet management! [online] [cit ]. prezentace z konference Fleet Management Dostupné z: < [11] Radovan Mužík. Klíčové parametry efektivního Fleet Managementu [online] [cit ]. prezentace z konference Fleet Management Dostupné z: <http: //present.blueevents.eu/fleetmanagement/2010/b8_muzik.pdf>. 65

86 66 LITERATURA [12] Roman Macháček. Fleet management [online] [cit ]. prezentace z konference Fleet Management Dostupné z: < FleetManagement/2010/B7_Machacek.pdf>. [13] T-Cars System, spol. s r. o. T-Cars Fleet Managemet. < stav z [14] Tomáš Johánek. Software pomůže nejen se správou vozového parku [online] Dostupné z: < default.aspx>. [15] YMS, a. s. Čo je Fleet Controlling? [online]. [cit ]. Dostupné z: <http: // [16] ysystem, spol. s r. o. ymonitor. < stav z

87 Příloha A GSM/GPRS/GPS jednotka CVPL-G204-A A.1 Zapojení Obrázek A.1: Význam konektorů jednotky 67

88 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 begin<heslo> begin begin ok! Formát zprávy Příkaz Odpověď Nastavení administrátorského telefonního čísla Formát zprávy admin<heslo> <telefonni_cislo_v_mezinarodnim_formatu> admin admin ok! Příkaz Odpověď

89 A.2. PRVOTNÍ KONFIGURACE POMOCÍ SMS ZPRÁV 69 Získání IMEI jednotky imei<heslo> imei imei: Formát zprávy Dotaz Odpověď Nastavení APN pro GPRS APN<heslo> <apn> APN data.vodafone.cz APN ok! Formát zprávy Příkaz Odpověď Nastavení IP adresy a portu serveru Formát zprávy adminip<heslo> <ip> <port> adminip adminip ok! Příkaz Odpověď Přepnutí komunikace na režim internet Formát zprávy GPRS<heslo> GPRS GPRS ok! Příkaz Odpověď Nastavení periodického odesílaní polohy Formát zprávy fix<hodnota><jednotka><opakovani>n<heslo> fix120s***n Tracker is activated! Příkaz Odpověď

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

91 Příloha B Datový model 71

92 72 PŘÍLOHA B. DATOVÝ MODEL Obrázek B.1: Datový model systému (hodně zjednodušený kvůli názornosti)

93 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

94 74 PŘÍLOHA B. DATOVÝ MODEL

95 Příloha C Kniha jízd Obrázek C.1: Ukázka zobrazení jízdy na interaktivní mapě 75

96 76 PŘÍLOHA C. KNIHA JÍZD Tabulka C.1: Ukázka vygenerované knihy jízd z jednoho dne Čas Odkud kam Vzdálenost Max. rychlost 00:25 cz Vítkov Vítkov Opavská 00:15:03 00:40 cz Fulnek Moravské Vlkovice km 06:27 cz Fulnek Moravské Vlkovice :31:34 06:58 cz Odry Odry km 07:05 cz Odry Odry :30:04 07:35 cz Studénka Nová Horka km 07:47 cz Studénka Nová Horka :09:03 07:56 cz Studénka Studénka nad Odrou km 08:28 cz Studénka Studénka nad Odrou :14:23 08:42 cz Studénka Butovice km 09:03 cz Studénka Butovice :03:03 09:06 cz Studénka Butovice km 09:12 cz Studénka Butovice :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í km 10:55 cz Stará Ves nad Ondřejnicí Stará Ves nad Ondřejnicí :15:02 11:10 cz Petřvald Petřvald u Nového Jičína km 11:22 cz Petřvald Petřvald u Nového Jičína :30:03 11:52 cz Frýdek-Místek Lískovec u Frýdku-Místku km 11:55 cz Frýdek-Místek Lískovec u Frýdku-Místku :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 cz Frýdek-Místek Lískovec u Frýdku-Místku :18:50 14:02 cz Paskov Oprechtice ve Slezsku km 14:18 cz Paskov Oprechtice ve Slezsku :03:02 14:21 cz Paskov Oprechtice ve Slezsku km 14:36 cz Paskov Oprechtice ve Slezsku :09:04 14:45 cz Brušperk Brušperk km 15:11 cz Brušperk Brušperk :06:02 15:17 cz Brušperk Brušperk km 15:27 cz Brušperk Brušperk :15:03 15:42 cz Petřvald Petřvald u Nového Jičína km 15:53 cz Petřvald Petřvald u Nového Jičína :53:51 16:47 cz Fulnek Moravské Vlkovice km 17:34 cz Fulnek Moravské Vlkovice :03:04 17:37 cz Fulnek Moravské Vlkovice km 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

97 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

98 78 PŘÍLOHA D. UKÁZKA UŽIVATELSKÉHO ROZHRANÍ EXISTUJÍCÍCH ŘEŠENÍ Obrázek D.2: Ukázka č. 2 uživatelského rozhraní systému ymonitor

99 Obrázek D.3: Ukázka č. 3 uživatelského rozhraní systému ymonitor 79

100 80 PŘÍLOHA D. UKÁZKA UŽIVATELSKÉHO ROZHRANÍ EXISTUJÍCÍCH ŘEŠENÍ 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

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

102 82 PŘÍLOHA D. UKÁZKA UŽIVATELSKÉHO ROZHRANÍ EXISTUJÍCÍCH ŘEŠENÍ Obrázek D.7: Ukázka č. 2 uživatelského rozhraní systému Webdispečink

103 Obrázek D.8: Ukázka č. 3 uživatelského rozhraní systému Webdispečink 83

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

105 Příloha E UML diagramy Obrázek E.1: Diagram komponent výkonného jádra systému 85

106 86 PŘÍLOHA E. UML DIAGRAMY Obrázek E.2: Diagram hierarchie grafických komponent