Ing. Jiří Matějec Ing. Petr Zobaník Ing. Petr Říha Ondřej Galík Martin Dvořák

FAKULTA

DOPRAVNÍ

ČVUT | KONVIKTSKÁ 20, 11000 PRAHA 1

ITS v podmínkách dopravně-telekomunikačního prostředí ČR (802/210/108) Technická zpráva za rok 2004

Doc. Dr. Ing. Miroslav Svítek

Ing. Jiří Matějec

Doc. Ing. Zdeněk Votruba, CSc.

Ing. Petr Zobaník

Ing. František Kopecký

Ing. Petr Říha

Ing. Tomáš Tvrzský

Ondřej Galík

Ing. Miloslav Věžník

Martin Dvořák

Ing. Jan Čábelka, CSc. Doc. Ing. Mirko Novák, DrSc. Prof. Ing. Pavel Přibyl, CSc.

VERZE 1.0

ITS v podmínkách dopravně-telekomunikačního prostředí ČR (projekt č. 802/210/108) zpráva za rok 2004

Obsah: 1. Úvod................................................................................................................................................3 2. Tvorba softwarového nástroje pro návrh ITS systémů pomocí ITS architektury...................4 2.1. Úvod do problematiky tvorby návrhového nástroje pro ITS.....................................................4 2.2. Popis rozhraní pro návrh ITS systému ....................................................................................6 2.2.1. Schémata návrhového nástroje ITS .................................................................................6 2.2.2. Realizace návrhového nástroje ITS............................................................................... 18 3. Vytvoření sady příkladů návrhu ITS systému pomocí ITS architektury a pomocí návrhového nástroje ...................................................................................................................... 26 3.1. Příklad 1: Odbavovací systém a placení jízdného................................................................ 26 3.1.1. Úvod .............................................................................................................................. 26 3.1.2. Uživatelské potřeby ....................................................................................................... 33 3.1.3. Zpracování příkladu pomocí návrhového softwaru ....................................................... 48 3.2. Ostatní příklady..................................................................................................................... 54 3.2.1. Příklad 2: Digitální tachograf ......................................................................................... 54 3.2.2. Příklad 3: Multimodální terminál - překladiště ............................................................... 54 3.2.3. Příklad 4: Železniční doprava ........................................................................................ 54 3.2.4. Příklad 5: Poskytování aktuálních dopravních informací .............................................. 55 4. Vazba ITS architektury a organizační struktury dopravy ČR................................................. 56 4.1. Infrastruktura sběru dopravních informací ............................................................................ 56 4.2. Vazba organizační struktury a ITS architektury ve veřejné dopravě .................................... 67 5. Vytvoření koordinačního centra ............................................................................................... 70 5.1. Koordinační centrum............................................................................................................. 70 5.2. Rozhraní pro komunikaci týmu řešitelů................................................................................. 70 5.3. ITS portál............................................................................................................................... 71 6. Závěr ............................................................................................................................................ 72 7. Literatura ..................................................................................................................................... 73

2


1. Úvod Návrhový software umožňuje libovolné seskupování funkcí do fyzických celků dle dané aplikace, kde fyzickým celkem může být již existující část systému, organizační jednotka, atd. Zvolený postup umožňuje modelovat různé hierarchické struktury systému, kde ke každé vrstvě jsou přiřazeny funkce a výsledkem modelování je získání informačních vazeb mezi jednotlivými vrstvami tak, aby logika ITS systému a tedy i jeho užitné vlastnosti zůstaly zachovány. To samé je možné pro různé organizace, kde ke každé organizaci jsou přiřazeny funkce a softwarový nástroj navrhne, jaké informace si musí organizace vyměňovat, aby logika systému zůstala neporušena. Pomocí navrženého softwarového nástroje byla vytvořena řada praktických příkladů, které byly podrobně rozebrány na úrovni jednotlivých funkcí i datových toků (byl proveden jejich výběr dle zadání) i na úrovni organizačních jednotek. Softwarový nástroj umožňuje tyto příklady ukládat, měnit, atd. Vznikne tak sada řešení, která lze obměňovat dle požadavků na ITS systém. Softwarový nástroj se stává expertním systémem, který má uloženy řešené příklady, které je možno porovnávat a na kterých je možno i sledovat ekonomické náklady a přínosy (účinnost ITS systémů). Jako v minulých letech byly výsledky projektu umístěny na portál www.itsportal.cz, kam bude přidán i vytvořený softwarový nástroj. Tento nástroj může být využíván odborníky na ITS i širokou odbornou veřejností.

3


2. Tvorba softwarového nástroje pro návrh ITS systémů pomocí ITS architektury 2.1. Úvod do problematiky tvorby návrhového nástroje pro ITS ITS architektura je zachycena v podobě relační databáze, jejíž popis byl již zpracován v předchozích zprávách. Vzhledem k rozsahu zpracované ITS architektury vyvstala potřeba použití nástroje, který by nad databází prováděl potřebné vyhledávací, výběrové a zobrazovací operace. Požadavek na realizaci tohoto nástroje vycházel také z praktických zkušeností při přípravě příkladů využití ITS architektury v praxi. Softwarový nástroj byl řešen jako víceuživatelský systém, který je napojen přímo na databázi ITS architektury, s možností přístupu jak registrovaných, tak neregistrovaných uživatelů. Proto byly pro realizaci vybrány následující technologie: • skriptovací jazyk php • databázový server mysql • webový server Apache • programy html2ps, htmldocs, ps2pdf – převod html kódu do postscriptu, převod postscriptu do formátu pdf

Skriptovací jazyk php a obecně realizace prostřednictvím webového rozhraní byla vybrána z několika důvodů. Prvním a velice důležitým aspektem je rychlost vývoje, která je výrazně kratší než při použití např. programovacího jazyka C nebo C++. Již samotný charakter webového rozhraní je ideální pro nasazení ve víceuživatelském systému. Systém je přístupný odkudkoliv a neklade žádné nároky na softwarové vybavení klientské stanice. Dalším důvodem pro serverové řešení systému jsou aktualizace. Při aktualizacích opět nejsou kladeny žádné požadavky na klientské vybavení – z hlediska uživatele se tudíž systém jeví jako bezúdržbový. Softwarový nástroj zahrnuje volbu uživatelských potřeb, ze kterých vzejde funkční architektura, kde propojením funkcí informačními toky vcházejícími nebo vycházejícími z funkcí vznikne informační architektura.

4


Obr 1: Editační rozhraní ITS

Pro tvorbu vlastní databáze ITS architektury bylo vytvořeno rozhraní jehož prostřednictvím byla realizována editace databáze. Toto rozhraní bylo využívalo stejného principu víceuživatelské týmové práce. Toto rozhraní bylo popsáno v předchozích zprávách.

Obr 2: Rozhraní ITS portálu

5


ITS portál je místem, které obsahuje informace a odkazy na projekty související

s

problematikou inteligentních dopravních systémů.

2.2. Popis rozhraní pro návrh ITS systému V následující kapitole je popsáno rozhraní pro práci s architekturou ITS. Budou popsány jednotlivé moduly, ze kterých je rozhraní složeno. Popis modulů bude proveden zhruba v takovém pořadí, v jakém uživatel přijde s daným modulem do styku.

2.2.1. Schémata návrhového nástroje ITS Prvním krokem je vybrání z veřejně přístupných projektů, tj. z těch projektů, které byly připraveny přímo řešitelským týmem ITS architektury nebo ve spolupráci s řešitelským týmem. Tyto projekty jsou uzamčeny pro jakékoliv úpravy a editace a slouží jako výchozí bod pro tvorbu vlastního projektu. Pokud je uživatel registrován a do systému se přihlásí, má navíc možnost výběru z vlastních dokončených nebo rozpracovaných projektů. Další možností je vytvoření zcela nového projektu.

Obr 3: Moduly pro výběr projektu

6


Načtení projektu se skládá ze tří kroků. Prvním je deklarace stavových proměnných, dále proběhne jejich nastavení. Tím je modul inicializován a má všechny potřebné informace pro načtení správného projektu.

Obr 4: Modul načtení projektu

Správu projektů, tj. jejich vytváření, ukládání, mazání, obsluhuje modul pro správu projektů. Pro vytvoření nového projektu uživatel vyplní potřebné údaje o projektu, jako jsou jeho název, popis a jiné. Poté je založen nový prázdný projekt. V případě, že nastala při zakládání chyba je vypsáno chybové hlášení. Uložení projektu je možné pouze pro registrované uživatele a uživatel se stává jeho vlastníkem. Vlastník je oprávněn s projektem provádět veškeré operace. Uložení projektu jako... je volba, která je vhodná například v okamžiku, kdy má uživatel otevřený a upravený nějaký z veřejných projektů a chce si provedené úpravy uložit. Protože však není oprávněn veřejný projekt jakkoliv upravovat, uloží jej jako projekt nový. Uzavřením projektu se uvolní veškeré nastavené stavové proměnné. Smazání projektu vymaže aktuálně otevřený projekt z databáze, tato volba je nevratná a proto je vhodné se před smazáním ujistit o správnosti rozhodnutí.

7


Obr 5: Moduly pro správu projektu

8


Při každé změně, každé volbě uživatele dojde ke znovunačtení aplikace – jedná se o stavovou aplikaci. Pro efektivní údržbu rozhraní je vhodné, aby veškeré inicializace stavových proměnných, autentifikace a větvení chodu aplikace bylo realizováno pokud možno v jednom místě, přes které aplikace při každé změně stavu musí projít. Proto byl systém navržen tak, jak ukazuje následující diagram. Systém sestává ze čtyř hlavních modulů. Modul pro výběr projektu a modul pro správu projektů a jejich načítání (viz. popis výše), dále potom návrhové moduly a moduly pro zobrazování.

Obr 6: Schéma fungování webového rozhraní

Jak již bylo uvedeno výše, rozhraní je stavovou aplikací, pro jedním z nejdůležitějších modulů je modul právě pro nastavování obecných stavových proměnných. V tomto modulu se mimo jiné nastavuje jazyková mutace, identita uživatele a řada dalších informací.

9


Obr 7: Modul nastavení prostředí

Výše zmiňovaná autentifikace je obsluhována autentifikačním modulem. Uživatel je po zadání svých přístupových údajů identifikován proti záznamu v databázi. Pokud se přístupové údaje shodují s těmi, které jsou zadány v databázi registrovaných uživatelů, je autentifikace úspěšná a přihlášení je dokončeno. V opačném případě je vypsáno hlášení o nesprávnosti zadaných údajů. Pokud není uživatel přihlášen má statut tzv. Implicitního uživatele, tedy uživatele bez jakýchkoliv přístupových práv. Modul autentifikace taktéž obstarává odhlašování ze systému.

10


Obr 8: Modul autentifikace

11


Modul akce je jádrem návrhového systému. Stará se o větvení chodu algoritmu a spouštění jednotlivých požadovaných modulů. Následující diagram znázorňuje způsob, jakým je chod aplikace větven.

Obr 9: Modul akce

12


Modul pro zobrazování má za úkol generovat z projektů grafické a tabulkové výstupy. Grafický výstup je ve formátu png, který nezávislý na hardware a softwarové platformě. Navíc není tento formát chráněn žádným patentem a může být tudíž volně užíván. Tabulkové výstupy jsou ve formátu HTML.

Obr 10:

Modul pro zobrazování

13


Moduly pro návrh zajišťují samotný průběh návrhu projektu. Postupně se přes zvolené uživatelské potřeby uživatel dostane k upřesnění výběru funkcí a datových toků. Kdykoliv v průběhu návrhu lze projekt uložit a vrátit se k němu později. Série následujících diagramů znázorňuje celý tento návrhový proces.

Obr 11:

Moduly pro návrh

14


Obr 12:

Obr 13:

Výběr uživatelských potřeb

Upřesnění zvolené uživatelské potřeby 15


Obr 14:

Obr 15:

Výběr funkcí

Upřesnění zvolené funkce

16


Obr 16:

Obr 17:

Výběr datových toků

Upřesnění datového toku

17


2.2.2. Realizace návrhového nástroje ITS Samotná realizace softwarového nástroje pro návrh ITS projektů na základě vybraných uživatelských potřeb byla již od počátku uvažována s cílem intuitivního návrhové rozhraní, které po každého uživatele, jak z oblasti dopravní telematiky, tak i z oblasti široké veřejnosti, bude poskytovat jednoduché a příjemné ovládání, které povede k využitelným výstupům se snadnou pozdější použitelností. Následující část popisuje jednotlivé prvky softwarového nástroje a možnosti při navrhování projektů ITS s jeho pomocí, včetně popisů jednotlivých položek menu. Softwarový nástroj je zpřístupněn na stránkách ITS portálu (www.itsportal.cz)

Úvodní stránka Po otevření softwarového nástroje se načte úvodní obrazovka, která se skládá ze tří základních částí: • login-logout – část softwaru sloužící pro přihlášení registrovaných uživatelů (jsou-li přihlášeni, pak pro jejich odhlášení) a pro změnu jazykové mutace software. Na obrázku je přihlášen uživatel „ITS user“ , je tedy zpřístupněná jen volba LOGOUT (=odhlásit uživatele ze systému), a je zvolená česká jazyková mutace. • menu – levý sloupec software slouží pro základní navigaci aplikací a zůstává neměnný po celou dobu práce v aplikaci. Skládá se z těchto základních oddílů: −

Projekty – vytvoření nového projektu, nebo otevření již uloženého projektu.

−

Odkazy – odkazy na www stránky související s problematikou ITS

−

Home – návrat na úvodní stránku

−

Prohlížení architektury – vazby na prohlížení architektury přes ITS rozhraní ITSprohlížečky na portálu ITS. Možnost procházet jednotlivé funkce architektury ITS, datové toky, jak logické, tak fyzické a subsystémy.

−

Nápověda – podrobná nápověda prací v softwarovém nástroji, která uživatelům pomůže v případě jakýkoliv potíží při práci se softwarovým nástrojem.

• work – hlavní pracovní část, ve které se odehrávají veškeré práce spojené s návrhem, správou, exportem řešeného projektu ITS projektu

18


Obr 18:

Úvodní stránka

19


Výběr projektů Po zvolení akce „PROJEKTY – otevřít“ se do části „WORK“ zobrazí seznam projektů, které jsou uživateli přístupné. Na obrázku je přihlášen uživatel „ITS user“, kterému se zobrazují jak jeho osobní projekty, které jsou vázané na jeho přihlášení (nezobrazují se tedy jiným uživatelům), tak i veřejné projekty, které se zobrazují každému uživateli. U každého projektu je možnost volby ho otevřít pro práci nebo, má-li na něj uživatel práva, jeho smazání. Status projektu znamená, v jakém stavu je návrh projektu. Nepřihlášený uživatel může založit libovolný vlastní projekt, ale není mu dána možnost ho do systému uložit.

Obr 19:

Výběr projektů registrovaného uživatele

20


Detail vybraného projektu Po zvolení „otevřít“ projekt „MANAGEMENT VEŘEJNÉ DOPRAVY - Odbavovací systém a placení jízdného“ se do části „work“ zobrazí pracovní část softwarového nástroje, jenž se skládá ze čtyř složek, které jsou přístupné z nového spodního menu. Jsou to: • Návrh • Správa • Info • Zobrazení Detail projektu je v informační složce. V této složce není možné provádět žádné změny, slouží pro informaci o projektu. Obsahuje název a popis projektu, informace o statutu a vlastníkovi a statistiku projektu se základními údaji o počtu jednotlivých složek a datu poslední úpravy.

Obr 20:

Detail vybraného projektu 21


Správa projektu Zvolením volby „správa“ z menu pracovních složek se otevře do pracovní části složka pro správu informací o projektu. Zde uživatel může měnit tyto údaje o otevřeném projektu: • Název – editace stávajícího názvu projektu • Popis - editace stávajícího popisu projektu • Status – změna statutu projektu Provedené změny uživatel uloží tlačítkem „provést změny“ Ve správě projektu lze také provést operaci „uložit jako“, kdy se vyplněním požadovaného názvu projektu a uložením tlačítkem „uložit“ provede založení nového projektu pod zadaným jménem, který obsahuje veškeré informace, které měl původní projekt. Původní projekt samozřejmě zůstává nezměněný.

Obr 21:

Správa projektu

22


Návrh projektu Zvolením volby „návrh“ z menu pracovních složek se otevře do pracovní části složka pro vlastní návrh projektu. Jedná se o nejdůležitější část softwarového nástroje. V prvním kroku, výběr uživatelských potřeb, je část „work“ rozdělena do dvou částí. Těmi jsou části: • Vybrané uživatelské potřeby – přehled uživatelských potřeb zahrnutých do projektu s možností jejich: −

schválení (uživatel shledal potřebu pro něj za uzavřenou a označil si ji z důvodu snadné orientace při příští práci na projektu. Uživatel je tímto informován, že uživatelskou potřebu si již upravil dle vlastních požadavků a nemusí se k ní již vracet)

−

zobrazení informace o uživatelské potřebě

−

rozbalení detailu potřeby (zobrazí se vlastní funkce zahrnuté do uživatelské potřeby s možností výpisu jejich detailů, nebo jejich odebrání)

−

odebrání uživatelské potřeby (z projektu bude odebrána zvolená uživatelská potřeba a bude zahrnuta zpět do pole nevybraných uživatelských potřeb)

• Nevybrané uživatelské potřeby – uživatel si z nabídky nevybraných uživatelských potřeb zvolí takové, které chce zahrnou do svého projektu. Označí je a tlačítkem „přidat označené“ je přesune do pole vybraných uživatelských potřeb.

Je-li uživatel hotov s výběrem uživatelských potřeb, tak se tlačítkem „pokračuj“ posune do dalšího kroku návrhu projektu. Jedná se o krok návrhu funkcí, který je svou strukturou obdobný návrhu uživatelských potřeb, jen se v poli vybrané funkce zobrazí všechny funkce příslušné vybraným uživatelským potřebám z kroku prvního a je možno provést libovolné změny v těchto funkcích, úpravy vlastních datových toků, nebo je možno přidat libovolnou funkci z architektury ITS. Je-li uživatel hotov s výběrem jednotlivých funkcí, tak se tlačítkem „pokračuj“ posune do dalšího kroku návrhu projektu. Jedná se o krok návrhu datových toků, který je svou strukturou obdobný krokům předešlým. Uživatel má možnost projít si datové toky, které zvolil tím, že v krocích předchozích vybral uživatelské potřeby a funkce, a je mu dána možnost upravit výběr těchto toků jak přidáním libovolného toku, tak odstraněním toku, který byl zařazen na základě předchozích kroků návrhu. Výhodou je stálé propojení s ITS prohlížečkou přes levou část „menu“, kde je umožněno stálé nahlížení do podrobností ITS architektury. Všechny změny je možno průběžně ukládat tlačítkem „ulož změny“ 23


Obr 22:

Návrh projektu, výběr uživatelských potřeb

24


Zobrazení projektu Zvolením volby „zobrazení“ z menu pracovních složek se otevře do pracovní části složka pro zobrazení navrženého projektu. Uživateli je poskytnuta možnost volby mezi těmito zobrazeními: • Stromová struktura vybraných funkcí – zvolením této volby zobrazení projektu dojde k vygenerování a zobrazení obrázku se stromovou strukturu všech funkcí, které byly zahrnuty do projektu ve složce „návrh“ . • Přehled vybraných uživatelských potřeb, funkcí, datových toků – výpis položek do tabulky s možností volby formátu: −

html

−

pdf

Obr 23:

Zobrazení projektu

25


3. Vytvoření sady příkladů návrhu ITS systému pomocí ITS architektury a pomocí návrhového nástroje Na základě vytvořeného softwarového nástroje a zkušeností řešitelského týmu z minulých let, byly vytvořeny vzorové příklady, jak využívat ITS architekturu pro návrh jednotlivých ITS systémů dle požadavků uživatelů zejména ze státní správy a veřejné samosprávy. V následujících kapitolách je podrobně rozebrán návrh vzorového příkladu za využití architektury ITS.

3.1. Příklad 1: Odbavovací systém a placení jízdného 3.1.1. Úvod Uvedený příklad se zabývá použitím ITS architektury pro odbavovací systémy a placení jízdného ve veřejné dopravě. Ukazuje se, že nové technologie vytlačí stávající systémy založené na papírovém jízdním dokladu a přispějí tak k vyššímu využití veřejné dopravy. V této oblasti se uplatňují v zásadě tři technologie:

• Odbavovací systémy na principu magnetické karty • Odbavovací systémy na principu čipové karty • Odbavovací systémy na bázi mobilního telefonu

Odbavovací systémy na principu magnetické karty Systém pracuje na principu plastové karty (na zadní straně tmavohnědý magnetický pásek) a čtecího zařízení (elektromagnetická nahrávací i mazací hlava). Na magnetické pásce karty jsou ve stopách zaznamenány identifikační údaje o kartě, dopravci a množství peněz na jízdné. Cestující při vstupu do dopravního prostředku nebo prostoru protáhne kartu čtecím zařízením na jehož základě se:

• kontroluje platnost karty • odepíše se příslušná výše jízdného z předkládané hodnoty ve formě jednotek.

26


Použití magnetických karet je možné kombinovat se systémy popsanými u jízdenkových systémů. Magnetické karty přinesly v době zavádění řadu výhod, ale systém měl i řadu nevýhod a slabin nimž patří zejména:

• možnost falzifikace a poškození karty, • pořizovací cena systému je poměrně vysoká, • problematické použití pro starší občany nebo krátkodobé využití hromadné dopravy • (návštěvník města, cizinec atd.), • vizuální kontrola správnosti označení jízdenky a výpočtu jízdného není možná, • systémy vykazovaly mnohdy velkou nespolehlivost vlivem poškození karet, • systém nedával potřebná data pro rozúčtování jako dnes již dávají čipové karty. V současné době je již systém magnetických karet překonán systémem čipových karet, proto ho již nelze doporučovat jako perspektivní a spolehlivý odbavovací systém.

Odbavovací systémy na principu čipových karet Základem karty je křemíkový čip obsahující identifikační údaje a záznam pro aplikace, dále v kartě je integrována anténa v samotném tělese karty. To nevyžaduje vlastní energetický zdroj, energie pro čip se získává při přiložení ke čtecímu zařízení pomocí elektromagnetické indukce. Karta je inteligentním paměťovým médiem s vysokým stupněm zabezpečení a proto je její využití bezpečné k mnoha dalším aplikacím. V dopravních systémech jsou čipové karty jednotným jízdním dokladem. Jejich využití je bezpečné a jako identifikátor umožňují další aplikace:

• časové jízdenky, • elektronický ekvivalent časové jízdenky s platností na tarifní systém pro dané období, • elektronická peněženka tzv. „hodnotová karta“: −

karta se zaplacenou zálohou, doplňovatelná,

−

ze zálohy se odečítá výše jednotlivého jízdného,

−

sleva oproti hotovostní platbě, 27


• kombinace časové jízdenky /„elektronické peněženky“.

Odbavovací systémy na bázi mobilního telefonu Elektronický platební systém pro multimodální dopravní služby s použitím mobilních telefonů. Řešením tohoto systému elektronického placení se zabýval např. projekt TELEPAY. Zahrnuje použití mobilních telefonů k placení jízdného v městské hromadné dopravě, při platbách na parkovištích, silničních poplatcích (např. mýtném) apod. Pro transakci virtuální elektronické jízdenky používá technologie GSM a SMS/WAP a umožňuje:

• Získání informací o vhodném spoji před cestou • Zakoupení jízdenky • Doručení jízdenky • Zaplacení jízdenky Spojením dopravních informací se službami, které umožňují zakoupení elektronické jízdenky z mobilního telefonu se současnými funkcemi, získají cestující vlastnící mobilní telefon přístup ke kvalitním dopravním službám s přesnými informacemi o cestě a také možnost okamžité koupě odpovídající jízdenky, která může být na žádost ihned potvrzena. Z tohoto důvodu lze v „otevřeném“ systému inkasování jízdného považovat tuto elektronickou jízdenku po určitý čas jako platnou bez potřeby dalšího ověřování. V „uzavřeném“ systému si uživatelé musí potvrzovat jízdenku a otevírat turniket se ověřování opírá o komunikační technologie krátkého dosahu (např. Bluetooth), které umožňují bezkontaktní operace mezi mobilními telefony a pevným zařízením. Výhody systému odbavení na bázi mobilního telefonu:

• nepřetržitý interoperabilní prodej jízdenek • rozšíření existujícího mobilního platebního systému v dopravních službách • jednoduchá úprava zařízení • vzrůstající využívání veřejné dopravy příležitostnými a mezinárodními cestujícími • vzrůstající tržby veřejných dopravních operátorů • rapidní snížení počtu automatů na výdej jízdenek (o více než 50%) 28


• menší manipulace s penězi (zlevnění pro operátory) • platební systém je vytvořen na základě již ověřených metod používajících operace GSM roamingu • nevyžaduje specifickou infrastrukturu • umožní elektronické prodávání jízdenek na meziměstských autobusových linkách • zvýší tržby operátorů infrastruktury díky zařízení harmonizovaného platebního systému • v elektronickém systému inkasování jízdného se nebudou používat žádné další doplňky (jako např. magnetický proužek nebo smart karta) • nabízí možnost zahrnutí maloobchodních aplikací (např. prodejní automaty) • umožňuje jednoduchý přístup cestujícím (méně hledání) • žádné časové ztráty při řazení do front • žádné riziko při zaplacení nepřesného poplatku • mobilní telekomunikační operátoři mohou poskytnout odborný posudek a služby mobilních plateb jako například účtování, bezpečnost platby • nabízí obchodní příležitosti pro telekomunikační operátory jako poskytovatele služeb (jízdenky, dopravní informace, atd.) • zvýšení všeobecného použití mobilní telekomunikace a souvisejících existujících služeb (SMS, WAP)

29


Obr 24:

Příklad fyzické architektury pro odbavovací systém a placení jízdného (MANAGEMENT VEŘEJNÉ DOPRAVY - Problematika jízdného)

Fyzická architektura uvedeného příkladu reprezentuje jednotlivé komponenty systému a fyzické datové toky mezi nimi. Jízdní doklad musí vždy existovat a to v takové podobě, aby jednoznačně prokázal zaplacení jízdného při kontrole. Papírová forma není nezbytná ale musí být zajištěna možnost kontroly zaplacení jízdného a zúčtování nákladů na cestovné veřejnou dopravou při pracovních cestách. Vždy by měla být zachována možnost zaplacení jízdného přímo ve vozidle veřejné dopravy. 30


Základní úroveň interoperability Na jedné kartě může být uloženo i několik aplikací současně. Mezi základní aplikace patří časové jízdné a „elektronická peněženka“ (peněžní vklad na kartě jako forma kreditu). Základní možností pro dosažení interoperability je sdílení elektronické peněženky. Nutnými podmínkami pro ni jsou: • Jednotná datová struktura elektronické peněženky. • Jednotné způsob používání peněženky. • Jednotné klíče pro vstup do elektronické peněženky spravované nezávislou institucí • (pravděpodobně krajský úřad nebo krajský koordinátor dopravy, popřípadě celostátní • instituce). • Jednotnou datovou větu pro výměnu dat (pro clearing).

Vyšší úroveň interoperability Vyšší úroveň předpokládá jednotnou tarifní politiku dopravců, jednotnou datovou strukturu na kartě a jednotné klíče. K tomuto cíli zatím žádné aktivity v oblasti celostátní (nebo dokonce mezinárodní) interoperability v České republice nesměřují. Doporučujeme zahájit na tomto poli intenzivní jednání všech zainteresovaných partnerů, aby bylo dosaženo celostátního konsensu týkajícího se budoucího rozvoje v této oblasti. Je třeba zabránit roztříštěnosti řešení. Rezervace místenky může být provedena: • Jako služba na přepážce • Pomocí SMS • Pomocí Internetové aplikace Validace jízdního dokladu ve vozidle je proces, který je nutný pro následnou kontrolu a zúčtování jízdného. Informace o validaci zaslaná do databáze je cennou informací o vytížení vozidla.

31


Obr 25:

Struktura standardizačního procesu

Poř. čís.

Číslo dokumentu

Název dokumentu

1

ENV1545-1

Identification card systems: Surface transport applications: Part 1 – Elementary data types, general codes and general data elements

2

ISO7816-1

Identification Cards – Integrated Circuit Cards with Contacts: Part 1 – Physical Characteristics

3

ISO7816-2

Part 2 – Dimension and location of contacts

4

ISO7816-3

Part 3 – Electronic signals and transmission protocol

5

ISO7816-4

Part 4 – Inter-Industry commands for interchange

6

ISO7816-5

Part 5 – Numbering systems and registration procedure for application identifiers

7

ISO7816-6

Part 6 – Inter-Industry data elements

8

ISO10373-3

Identification cards – Test methods – Part 3: Integrated circuit(s) cards with contacts and related interface devices

9

ISO10373-5

Identification cards -- Test methods -- Part 6: Proximity cards

10

ISO 11770-1

Information technology – Security techniques – Key management: Part 1 – Framework

11

ISO 11770-2

Part 2 – Mechanisms using asymmetric techniques

32


Poř. čís.

Číslo dokumentu

Název dokumentu

12

ISO14443-1

Identification Cards – Contactless integrated circuit cards – Proximity Cards (PICC): Part 1 - Physical Characteristics

13

ISO14443-2

Part 2 – Radio Frequency power and signal interface

14

ISO14443-3

Part 3 – Initialisation and Anticollision

15

ISO 14816

Road Traffic and Transport Telematics (RTTT), Automatic vehicle and equipment identification, Numbering and data structures

16

CEN TC 224/WG 11

IOPTA – Interoperable Public Transport Application

17

CEN TC 278/WG 3

IFMSA – Interoperable Public Transport Fare Management System Architecture

Tab 1: Související normy

3.1.2. Uživatelské potřeby Obecné požadavky na odbavovací systém: Odbavovací systém ve veřejné dopravě je základní styčná plocha mezi dopravcem a cestujícími. Systém odbavení přímo ovlivňuje to, jak cestující vnímají dopravní společnost a její služby. Očekávání cestujícího od odbavovacího systému: • produkty uspokojující jeho potřeby • spolehlivost, rychlost • snadná pochopitelnost a použitelnost • snadný přístup k získání jízdního dokladu • jednoduchý přestup mezi různými druhy dopravy a různými operátory

Požadované vlastnosti odbavovacího systému: • rychlost - rychlé transakce při nastupování i nákupu. • jednoduchost - snadné pochopení a použití cestujícími i zaměstnanci dopravce, uživatelsky příjemný. • bezpečnost - bezpečné prostředí pro tržby, ochrana osobních údajů, minimalizace možnosti podvodů • ekonomičnost - efektivní správa, údržba, investice. • spolehlivost - snadná údržba, splnění norem spolehlivosti. • informace, data - data pro plánování služeb, marketing, financování. • flexibilita – snadná adaptace na změny věrnostních systémů, strategií a integraci s jinými systémy. 33


Komponenty odbavovacího systému: • jízdní doklad - jízdenka, žeton, hotovost, časová průkazka, magnetická nebo čipová karta, mobilní telefon apod. • odbavovací zařízení a technologie - automaty, terminály, čtečky apod. • proces odbavení - platba při nástupu, platba při výstupu, doklad o jízdě apod. • tarify - jízdné podle ujeté vzdálenosti, jednotné jízdné, přestupy, slevy apod. Jednotlivé komponenty odbavovacího systému jsou úzce propojeny a změny jedné komponenty zpravidla vyvolají změny dalších komponent. Odbavovací systém musí být podporován distribucí jízdních dokladů, zpracováním vybraného jízdného, informačním systémem atd. Na základě uvedených obecných požadavků na odbavovací systém byly vydefinovány následující uživatelské potřeby, které souvisí s odbavením cestujících a placením jízdného. Ke každé uživatelské potřebě jsou přiřazeny funkce, které ji realizují. Uživatelská potřeba 4.1.3-A Systém bude vydávat potvrzení o zaplacení a registrovat údaje související s využitím služeb. Funkce 1.3. Elektronické transakce 1.3.7. Provedení platby Uživatelská potřeba 4.1.4-A Systém bude zajišťovat řízení komplexních služeb v oblasti jízdného (např. realizaci politiky dynamického jízdného, časově odlišeného jízdného, bude zohledňovat sociální, komerční a ekologické aspekty atd.) Funkce 1.1. Uzavření kontraktu 1.1.1. Uzavření elektronického kontraktu 1.3. Elektronické transakce 1.3.5. Výpočet poplatku za službu 1.3.6. Kontrola platby 1.6. Management tarifů a přístupových práv 1.6.1. Management tarifu

34


Uživatelská potřeba 4.1.5-A Systém umožní rozdělení příjmů mezi několik operátorů. Funkce 1.1. Uzavření kontraktu 1.1.1. Uzavření elektronického kontraktu 1.4. Příjmy operátorům 1.4.1. Rozdělení příjmů 1.4.2. Platby na konta operátorů

Uživatelská potřeba 4.1.6-A Systém umožní souhrnnou platbu za služby poskytnuté několika vzájemně propojenými dopravními systémy. Funkce 1.1. Uzavření kontraktu 1.1.1. Uzavření elektronického kontraktu 1.2. Správy kont uživatelů 1.2.1. Aktuální stav uživatelského konta 1.2.2. Odečtení platby z uživatelského konta 1.3. Elektronické transakce 1.3.3. Kontroly kontraktu 1.3.4. Informace a návody 1.3.5. Výpočet poplatku za službu 1.3.6. Kontrola platby 1.3.7. Provedení platby 1.4. Příjmy operátorům 1.4.1. Rozdělení příjmů 1.5. Zabezpečení proti chybám systému 1.5.2. Detekce narušitele platby 1.5.3. Detekce narušitele 4.2. Plánování služeb veřejné dopravy 4.2.3. Problematika jízdného

35


Uživatelská potřeba 4.2.4-A Systém by měl sloužit autoritě odpovědné za operování platebně-odbavovacího systému k řešení problematiky sběru a zúčtování malých poplatků. Funkce 4.3. Zajištění správy veřejné osobní dopravy 4.3.9. Správa vlastností jízdenek Uživatelská potřeba 4.2.5-A Systém má umožnit cestujícím změnu platnosti jejich jízdenek Funkce 4.3. Zajištění správy veřejné osobní dopravy 4.3.9. Správa vlastností jízdenek Uživatelská potřeba 4.2.6-A Systém bude disponovat černou listinou (záznamem o odcizených, ztracených a neoprávněně použitých platebních kartách). Funkce 1.5. Zabezpečení proti chybám systému 1.5.2. Detekce narušitele platby 1.5.3. Detekce narušitele Uživatelská potřeba 4.2.7-A Systém bude uskutečňovat věrnostní programy (dopravní či další služby?). Funkce 1.2. Správy kont uživatelů 1.2.3. Informace o transakcích a věrnostních programech Uživatelská potřeba 7.3.1.4 Systém bude schopen upravovat jízdné veřejné hromadné dopravy dle dohodnuté cenové strategie. Funkce 1.6. Management tarifů a přístupových práv 3.1.5. Řízení dopravním zařízením 3.1.5.1. Poskytování řízení dopravy 3.1.5.5. Výstupní ovládání/informace 3.3. Řízení poptávky 36


3.3.2. Realizace strategie řízení poptávky Uživatelská potřeba 7.3.10-A Systém bude schopen uplatňovat různé strategie v oblasti stanovení plateb, s dopadem na kolísání tarifů mýtného, parkovného, popř. jízdného ve veřejných dopravních prostředcích. Funkce 1.6. Management tarifů a přístupových práv 1.6.1. Management tarifu 4.2. Plánování služeb veřejné dopravy 4.2.3. Problematika jízdného

Obr 26:

Funkční architektura pro odbavovací systém a placení jízdného ve veřejné dopravě. Vygenerováno softwarovým nástrojem ITS projekty.

37


Obr 27:

Obr 28:

Související funkce. Vygenerováno softwarovým nástrojem ITS projekty.

Pokračování souvisejících funkcí. Vygenerováno softwarovým nástrojem ITS projekty.

38


Informační architektura pro odbavovací systém a placení jízdného ve veřejné dopravě Realizující funkce

Datové toky vstupní

terminátory

Datové toky výstupní

terminátory

1.1. Uzavření kontraktu

cst.ep_kontrakt_data

[T] Cestující

ep_kontrakt_registrace

[T] Externí poskytovatel služeb

ep.eps_kontrakt_statistika

[T] Operátor ITS systému

ep.opr_kontrakt_statistika

[T] Cestující

ep.cst_kontrakt ep.cst_sluzba_informace 1.1.1. Uzavření elektronického kontraktu

cst.ep_kontrakt_data

[T] Cestující

ep_kontrakt_registrace


ep.cst_kontrakt

[T] Cestující

ep.cst_sluzba_informace 1.2. Správy kont uživatelů

opr.ep_vernostni_programy

[T] Cestující

ep.rv_transakce_ucet

cst.ep_ucet_vstup

ep_precerpani_oznameni

ep_ucet_stav

ep_dodany_ucet

ep_transakce_informace

ep_transakce_prikaz

ep_uzivatel_transakce_historie

ep.cst_ucet_spravni_problem

[T] Cestující

ep.cst_vernostni_informace ep.cst_platba_data 1.2.1. Aktuální stav uživatelského konta

ep_naklad_ucet_prikaz

[T] Cestující

cst.ep_kontrakt_vyber

ep_dodany_ucet

[T] Finanční středisko

cst.ep_nahrat_parametr

ep.cst_ucet_spravni_problem

cst.ep_uzivatel_id

ep.cst_kontrakt_seznam

ep_kontrakt

ep.fis_stav_uctu_zadost

fis.ep_ucet_stav

[T] Cestující

ep.fis_nahrat_ucet_prikaz 1.2.2. Odečtení platby z uživatelského konta

ep_ucet_stav

ep_debet_ucet_prikaz

ep_transakce_informace


[T] Cestující

ep.cst_precerpani_oznameni 1.2.3. Informace o transakcích a věrnostních programech

opr.ep_vernostni_programy


ep.cst_ucet_stav

cst.ep_transakce_informace_zadost

[T] Cestující

ep.cst_vernostni_informace ep.cst_transakce_historie

ep_ucet_stav ep_uzivatel_transakce_historie

39

[T] Cestující




terminátory


terminátory

1.3. Elektronické transakce

rdc.ep_platba_vstup

[T] Řidič

ep.nd-platba_potvrzeni

[T] Cestující

cst.ep_platba_vstup

[T] Cestující

ep.md_infrastruktura_pouzivani_informace

[T] Řidič

dpr.ep_charakteristiky

[T] Dopravní prostředek

ep.rv_dopravni_prostredek_id_zadost

md.ep_volna_jizda_zadost

ep_transakce_registrace

md.ep_doprava_podminky

ep_transakce_podvod_vstup

rv.ep_dopravni_prostredek_data

ep.rdc_platba_vystup

ep_kontrakt

ep.cst_platba_vystup

ep_sluzba_tarif

ep.rv_sluzba_cena

ci.ep_sluzba_data

ep.rv_dopravni_prostredek_data ep.cst_vystupy

1.3.3. Kontroly kontraktu

md.ep_volna_jizda_zadost

ep_nezakonna_akce_oznameni

ep_kontrakt

ep_sluzba_id

ep_sluzba_id

ep_uzivatel_id

ep_uzivatel_pristupova_prava

ep_dopravni_prostredek_data

ep_uzivatel_id ep_dopravni_prostredek_data 1.3.4. Informace a návody

rdc.ep_kontrakt_vyber

[T] Řidič

ep_dohoda_

[T] Řidič

rdc.ep_vybrana_sluzba

[T] Cestující


[T] Cestující

cst.ep_kontrakt_vyber

ep_vybrana_sluzba_data

cst.ep_vybrana_sluzba

ep_sluzba_poplatek

ep_kontrakt

ep_sluzba_id

ep_platba_stav

ep_uzivatel_id

ep_uzivatel_pristupova_prava

ep_dopravni_prostredek_data

ep_uzivatel_id

ep.rdc_platba_informace_pruvodce

ci.ep_sluzba_data

ep.cst_platba_informace_pruvodce ep.rv_sluzba_cena ep_sluzba_data

40




1.3.5. Výpočet poplatku za službu


terminátory


terminátory

ep_sluzba_poplatek

rv.ep_dopravni_prostredek_pozice ep_kontrakt ep_vybrana_sluzba_data ep_sluzba_tarif ep_dopravni_prostredek_data

1.3.6. Kontrola platby

ep_kontrakt

ep_platba_stav

ep_vybrana_sluzba_data ep_transakce_informace 1.3.7. Provedení platby

rdc.ep_platba

[T] Řidič

ep.nd-platba_potvrzeni

[T] Řidič

cst.ep_platba

[T] Cestující

ep_dohoda_

[T] Cestující

ep_pristup_odmitnut


ep_kontrakt

ep_transakce_registrace

ep_sluzba_poplatek

ep.rdc_platba_prijeti ep.rdc_platba_zadost ep.cst_platba_prijeti ep.cst_platba_zadost

1.4. Příjmy operátorům

ep.eps_transakce_analyza


opr.ep_transakcni_informace_zadost

ep.fis_transakce


ep_operator_transakce_historie

ep.opr_transakce_analyza


eps.ep_transakcni_informace_zadost


ep_transakce_informace 1.4.1. Rozdělení příjmů

ep_sluzba_definice

ep_operator_prijem

ep_transakce_informace 1.4.2. Platby na konta operátorů

ep_operator_prijem

ep_transakce_prikaz ep.fis_transakce

41





1.5. Zabezpečení proti chybám systému

terminátory


terminátory


ep.md_nehoda_varovani

[T] Řidič

ep_pristupova_kriteria

ep_podvod_vystup

ep_podvod_vstup

ep.rdc_podvod_odhaleni


ep.rdc_zastav_prikaz

ep_dodany_ucet ep_transakce_podvod_vstup 1.5.2. Detekce narušitele platby

ep_dohoda_

ep_pristup_odmitnut

ep_cerna_listina

ep_cerna_listina_aktualizace

ep_kontrakt

ep_blok_volny_prikaz

ep_podvod_historie

ep_podvod_oznameni


ep.rdc_podvod_odhaleni

ep_precerpani_oznameni ep_sluzba_id ep_dodany_ucet ep_uzivatel_id 1.5.3. Detekce narušitele 1.6. Management tarifů a přístupových práv


ep_blok_volny_prikaz

ep_prestupek_podvod_odhaleni

ep_podvod_oznameni

eps.ep_pristupova_kriteria


ep_pristup_kriteria_aktualizace

eps.ep_tarifni_cleneni


ep_tarifni_cleneni

opr.ep_pristupova_kriteria opr.ep_tarifni_cleneni vd.ep_jizdne_schemata vd.ep_vybrana_sluzba_na_pozadani vd.ep_vybrana_sluzba_sdileni_dopravniho_ prostredku md.ep_poplatek_aktualizace_zadost

42

[T] Řidič




terminátory


1.6.1. Management tarifu

eps.ep_tarifni_cleneni


ep_tarifni_cleneni

opr.ep_tarifni_cleneni


vd.ep_jizdne_schemata vd.ep_vybrana_sluzba_na_pozadani vd.ep_vybrana_sluzba_sdileni_dopravniho_ prostredku md.ep_poplatek_aktualizace_zadost

3.1.5. Řízení dopravním zařízením

zs.md_pohotovost_zadost

md.ep_pristup_kriteria

msy.mpr_krizovatka_zadost

md.vd_cesta_data

opr.ods_doprava_prikazy

md.rv_rizeni_regulace

pds.doprava_management_strategie

md.rv_rychlost_nastaveni

cst.vyskyt_chodce

md.pd_smernice_a_oznameni_

dpz.lokalni_doprava_data

md_vozovy_park_obsazeni_limity

dpr.vvo_lokalni_priorita_zadost

md_vybaveni_chyba

vd.md_dopravni_prostredek_priorita_zadost

md_vybaveni_data

md_vozovy_park_obsazeni

md_strategie_pro_management_pozadavku

md_dopravni_tok_vuz_umisteni

md_doprava_management_strategie

md_vstupy_management_pozadavku

rdc.doprava_prikazy

md_servisni_oblast_obsazeni

mpr.msy_krizovatka_tlumeni

md_strategie_a_predpoved

ods.opr_doprava_odezva

md_doprava_prostredi_vstupy


md_doprava_tok_management_data

cst.doprava_prikazy

md_doprava_incident_zadost pd.md_varovani_zprava

43

terminátory




terminátory


terminátory

3.1.5.1. Poskytování řízení dopravy

zs.md_pohotovost_cesta_zadost

[T] Přidružený dopravní systém

md_vybaveni_data

[T] Multimodální systém


md_operator_management_dopravy_odezva


vd.md_dopravni_prostredek_priorita_zadost

md_vystupy_pro_most_a_tunel

md_pozadavek_management_strategie

md_odezva_chyba

md_incident_strategie_zadost

md_rychlost_nastaveni

md_vstupy_most_a_tunel

md_rychlost_hodnota

md_operator_management_dopravy_zadost

md_strategie_pro_management_pozadavku

md_parkovani_strategie

md_doprava_management_zadost

md_planovany_zmeny_management_dopra vy_zadost

md_doprava_management_strategie

md_predpovedena_data_dopravni_site


md_staticka_data

md_management_jizdniho_pruhu

mpr.msy_krizovatka_tlumeni

md_doprava_prostredi_vstupy md_doprava_tok_management_data md_doprava_management_odezva md_cleneni_strategie pd.md_doprava_data 3.1.5.5. Výstupní ovládání / informace

zs.md_pohotovost_lokalni_priorita_zadost

md_ovladac_stav

msy.mpr_krizovatka_zadost

md_vybaveni_stav

cst.vyskyt_chodce

md_doprava_management_odezva

dpz.lokalni_doprava_vyskyt_data

rdc.doprava_prikazy

dpr.vvo_lokalni_priorita_zadost

cst.doprava_prikazy

md_vozovy_park_obsazeni_prikazy md_incident_varovani_prikazy md_servisni_oblast_obsazeni_prikazy md_rychlost_prikazy md_doprava_management_zadost pd.md_varovani_zprava

44




terminátory


3.3. Řízení poptávky

ep.md_infrastruktura_pouzivani_informace

md.ep_poplatek_aktualizace_zadost

atm.atmosfericke_podminky

vd.md_zadost_zmeny

msy.msy_pozadavek_vstupy

md.ci_politika_strategie

opr.pce_management_pozadavku_vstupy

md_vstupy_management_pozadavku

din.politika_doprava

md_udrzba_strategie

vd.md_verejna_doprava_incident_data_pro_management_pozadavku

dst.eps_pozadavek_data

vd.md_sluzby_a_jizdne

dci.eps_pozadavek_data

vd.md_sluzba_variace

pce.opr_managent_pozadavku_vystupy

md_pozadavek_management_data_o_prostredi

md.din_cestovani_informace

md_incident_data_pro_management_pozadavku md_udrzba_data_pro_koordinaci_ md_doprava_vystupy_pro_management_pozadavku ci.md_informace_doprava

3.3.2. Realizace strategie řízení poptávky

md_pozadavek_management_strategie_prikazy

md.ep_poplatek_aktualizace_zadost

md_pozadavek_pozadovana_data

md.vd_zadost_pozadavek_sluzba_zmena

md_pozadavek_strategie_pro_uziti

md.vd_zadost_jizdne md.ci_politika_strategie md_pozadavek_management_strategie md_pozadavek_management_strategie_odezva md_udrzba_strategie md_parkovani_strategie md_zadost_pozadavek_strategie md_cleneni_strategie dst.eps_pozadavek_data dci.eps_pozadavek_data md.din_cestovani_informace

45

terminátory




terminátory


terminátory

4.2. Plánování služeb veřejné dopravy

md.vd_data_prenos


vd.ep_jizdne_schemata


md.vd_zadost_pozadavek_sluzba_zmena


vd.md_sluzby_a_jizdne


md.vd_zadost_jizdne


vd.ci_verejna_doprava_dostupne_sluzby


md.vd_zadost_incident_sluzba_zmena


vd.ci_aktualni_jizdne

[T] Cestující

eps.ona_planovane_udalosti

[T] Cestující

msy.msy_planovani

msy.msy_planovani

pvd.opr_odezva

opr.pvd_planovani_strategie

pds.verejna_doprava_planovani

opr.pvd_verejna_doprava_planovani_vstupy

vpa.cst_plan

pds.planovani cst.vpa_potreby vd_udrzba_plany 4.2.3. Problematika jízdného

md.vd_zadost_jizdne


vd.ep_jizdne_schemata

opr.pvd_jizdne_strategie

vd.md_aktualni_jizdne

vd_strategie_jizdneho

vd.ci_aktualni_jizdne

vd_verejna_doprava_sluzby

46




terminátory


terminátory

4.3. Zajištění správy veřejné osobní dopravy

msy.msy_sluzba_detaily


vd.ep_verejna_doprava_zvlastni_sluzby

[T] Řidič

udr.plany

[T] Organizace údržby

vd.pd_podvod_oznameni


opr.pvd_dopravni_proud_data_zadost


vd_udrzba_plany

[T] Organizace údržby

pdc.infrastruktura_status

[T] Povrch dopravní cesty

vd_sluzba_na_vyzadani


pds.plany


rvd.rdc_planovani


cst.uvd_verejna_doprava_sluzby_pozadave k

[T] Cestující

msy.msy_sluzba_detaily_pozadavek

[T] Cestující

[T] Dopravní instituce

udr.plany

[T] Dopravní instituce

cst.uvd_jizdne_charakteristiky

pvd.opr_dopravni_proud_data

cst.uvd_doprava_data

pds.plany

din_verejna_doprava_dopravni_proud_data_ zadost

uvd.cst_sluzba_informace din_verejna_doprava_dopravni_proud_data

vd_alarm_a_vykon vd_alarm_popis vd_pozorovany_vykon 4.3.9. Správa vlastností jízdenek

cst.uvd_jizdne_charakteristiky

[T] Cestující

vd.pd_jizdne_podvod_data uvd.cst_jizdne_charakteristiky

Tab 2: Informační architektura pro odbavovací systém a placení jízdného ve veřejné dopravě

47

[T] Cestující


3.1.3. Zpracování příkladu pomocí návrhového softwaru Ze známých uživatelských potřeby budeme vycházet při řešení příkladu „Odbavovací systém a placení jízdného“ pomocí softwarového nástroje pro řešení ITS příkladů. V jednotlivých krocích bude popsán přesný postup k řešení.

Úvodní stránka Po otevření softwarového nástroje provedeme přihlášení do systému a zvolíme v části „menu“ akci „Projekty-otevřít“, jelikož projekt jsme již předem založili.

Obr 29:

Úvodní stránka

48


Výběr projektů (po přihlášení uživatele) V části „work“ se zobrazí všechny naše projekty a také projekty veřejné. Najdeme si projekt „MANAGEMENT VEŘEJNÉ DOPRAVY - Odbavovací systém a placení jízdného“ a zvolíme akci „otevřít“.

Obr 30:

Výběr projektů (po přihlášení uživatele)

49


Detail vybraného projektu Kliknutím na odkaz složky „info“ lze zobrazit stav projektu včetně jeho kompletního popisu, statutu statistiky přístupu atd.

Obr 31:

Detail projektu

50


Správa projektu Kliknutím do složky „správa“ můžeme provést snadnou editaci popisových informací o zvoleném projektu, změnit jeho status či vytvořit duplicitní projekt s jiným názvem. Nebo celý projekt smazat.

Obr 32:

Správa projektu

51


Návrh projektu Otevřením složky „návrh“ si zobrazíme v prvním kroku uživatelské potřeby. V horní části se zobrazují vybrané uživatelské potřeby a ve spodní části uživatelské potřeby, jenž zatím do projektu nebyly zařazeny. Vybereme se požadované uživatelské potřeby a tlačítkem “pokračuj“ vstoupíme do druhého kroku sekce „návrh“, kde můžeme upřesnit výběr funkcí a dále ve kroku třetím datové toky. Projekt nezapomeneme ukládat.

Obr 33:

Návrh projektu

52


Zobrazení projektu Ve složce „zobrazení“ si zvolíme výstup ze software. Vygenerované diagramy funkcí jsou ukázány o kapitolu výše.

Obr 34:

Zobrazení projektu

Závěr návrhu pomocí návrhového nástroje ITS Použitím softwarového nástroje pro tvorbu projektů ITS dojde ke značnému zpřehlednění a zjednodušené jinak ne zcela přehledné práce, jakou bylo vybírání správných funkcí a datových toků. Jelikož softwarový nástroj je neustále aktuální, již ze samotného principu navržení celého systému, je jeho výhodou nemožnost pracovat v navrhování projektu ITS s neaktuálními daty. Možnost správy vlastních projektů, počínaje možností ukládat práci v průběhu návrhu a vracet se k ní později, nastavovat si u položek status o rozpracování, konče nejen možností multiplatformně kompatibilního generování výstupů či provázanost

53


s ITS prohlížečkou, vede nejen k přehlednému způsobu práce při navrhování projektů ITS, ale i k snadnému poznávání problematiky návrhu ITS projektů.

3.2. Ostatní příklady 3.2.1. Příklad 2: Digitální tachograf Digitální tachograf je v prvé řadě systém sloužící státní správě ke zvýšení kvality dohledu nad dodržováním bezpečnostních pravidel v silničním provozu. Systém bude v plné funkčnosti sloužit státním orgánům všech členských států EU (např. MD ČR) ke kontrole výkonů řidičů, dodržování doby odpočinku, překračování rychlosti atd. včetně jízd provedených vozidlem i v minulosti. Digitální tachograf však také umožní řidičům a dopravcům snadno získávat data o provedených jízdách a importováním do informačního systému získají datový podklad pro zpracování knihy jízd. Zpracovaný příklad je v příloze 1.

3.2.2. Příklad 3: Multimodální terminál - překladiště Všude tam, kde dochází k lokální kumulaci potřeb po přepravě, ať již ve smyslu odesílání, odběru zboží či kombinaci obojího, vznikají podmínky pro výstavbu terminálů či logistických center. Pro jednoduchost demonstrace příkladu multimodálního terminálu se v další práce vymezíme na problém terminálu ve smyslu překladiště. Zpracovaný příklad je v příloze 2.

3.2.3. Příklad 4: Železniční doprava Organizování, řízení a dohlížení železniční dopravy v ČR je podporováno komplexem systémů, subsystémů a aplikací dopravní telematiky hlavního dopravce (ČD, a,s,). Součástí tohoto komplexu jsou systémy podporující sledování, organizování a řízení nákladní dopravy, respektive přepravy zboží. Organizace železniční dopravy, vlastní organizační struktura, řízení provozu atd., prochází dynamickým vývojem. To ovlivňuje koncepci, správu, ale i rozvíjení systémů, subsystémů a aplikací dopravní telematiky podporující organizování, a řízení přepravy zboží po železnici. Vstup ČR do EU vytváří nové podmínky pro přepravu zboží po železnici. Splnění direktiv EU umožní vstup více dopravcům na železniční infrastrukturu. Své požadavky má i podpora kombinovaným druhům dopravy zboží v niž právě železnice má své postavení. Podmínkou naplnění cílů evropské a národní dopravní politiky je efektivní práce s informacemi tak, aby služby železniční dopravy byly dostatečně využívány. V praxi jde o vytvoření interoperabilního

dopravně telematického systému

podpory procesu, zahrnující možnost tvorby informačních vazeb mezi systémy, subsystémy 54


a aplikacemi v celém dopravně-přepravním řetězci. Na příkladu rozkladu problematiky IS/IT podpory procesu NP ČD bude problematika tvorby architektury přiblížena. Zpracovaný příklad je v příloze 3.

3.2.4. Příklad 5: Poskytování aktuálních dopravních informací Dopravní informace jsou nástrojem zvyšování bezpečnosti silničního provozu, ovlivňování chování jeho účastníků, nástrojem řízení, ovlivňování a přesouvání dopravy. Stále narůstající provoz a s ním spojená zvyšující se hustota provozu mají vliv na přibývající dopravní zácpy a přerušování dopravy na silnicích, zvyšující se nehodovost včetně jejich následků na životech, zdraví a majetku a v neposlední řadě i rostoucí dopady na životní prostředí. Fungující dopravní systém má přitom zásadní význam pro společenský i ekonomický rozvoj, zachování “trvalé mobility” je klíčovým faktorem tohoto rozvoje. Zpracovaný příklad je v příloze 4.

55


4. Vazba ITS architektury a organizační struktury dopravy ČR 4.1. Infrastruktura sběru dopravních informací Infrastruktura sběru dopravních informací je tvořena: Subjekty s prioritou poskytovaných informací I.: Policie ČR, Hasičský záchranný sbor, Zdravotní záchranná služba, Obecní policie, dobrovolní dopravní zpravodajové, Silniční správní úřady, Správci komunikací, Ředitelství silnic a dálnic ČR, Český hydrometeorologický ústav, dopravně-telematické (ITS) systémy Subjekty s prioritou poskytovaných informací II. Dopravní podniky, Celní správa, Podniky Povodí, Vodoprávní úřady, Správci sítí, Pořadatelé akcí, Dopravci a přepravci, Přepravci nadměrných a nebezpečných nákladů, Letecká záchranná služba, Taxislužba, Kurýrní služba Subjekty s prioritou poskytovaných informací III. Cechovní a profesní sdružení, Autokluby, Ministerstva, Asociace a společenství

56


Název

Policie České republiky - Centrum dopravních informací

Zřizovatel, řídící složka

Ministerstvo vnitra, Policejní prezidium České republiky

Organizační členění

Centrální pracoviště Praha

Předpis

činnost upravena zákonem č. 283/1991 Sb. ve znění pozdějších předpisů, dále interním aktem řízení Policejního prezidia ČR č.59/2003 Sb. A-I. Omezení, A-II. Kongesce, A-III. Sjízdnost, A-VI. Nebezpečí, AVII. Čekací doby

Dopravní informace

P-II.4. Bezpečnost

Informační systém

intranetový systém Logos, vlastní informační systém s exportem dopravních informací prostřednictvím Českého rozhlasu

Formát dat

vlastní, nestandardní z části volný textový

GIS

vlastní mapové podklady Geobáze

Charakteristika dopravních informací

poskytuje jako jeden z hlavních subjektů aktuální ověřené informace o nejzávažnějších událostech z hlediska bezpečnosti a plynulosti silničního provozu

Význam subjektu v systému

velký, zejména po zkvalitnění a prohloubení dosavadní činnosti v oblasti sběru a zpracování informací z kompetence Policie ČR

Vliv

řidiči, IZS

Tab 3: Subjekty infrastruktury sběru dopravních informací

Název

Ministerstvo vnitra, Policie České republiky - preventivní informační skupiny


Policejní prezidium České republiky, Krajské správy Policie České republiky, Okresní ředitelství , Policie České republiky, Městské ředitelství Policie České republiky


1x Policejní prezidium, 8x krajské správy, 73x okresní ředitelství, 3x městské ředitelství

Předpis

činnost upravena zákonem č. 283/1991 Sb. ve znění pozdějších předpisů

Dopravní informace

P-I. O komunikacích, P-II. O provozu, P-III. O účastnících, P-IV. O vozidlech O-III. Cestovní


Bez vlastního informačního systému

Formát dat

nedefinovaný

GIS Charakteristika dopravních informací

poskytuje informace do médií v oblasti působnosti, chybí celostátní koordinace a systémový přístup


velký z hlediska preventivního působení ve srovnání s dalšími subjekty prakticky nejvýznamnější

Vliv

všichni účastníci silničního provozu


57


Název

Silniční správní úřady


Ministerstvo dopravy - odbor pozemních komunikací, Krajské úřady - odbory dopravy, Obecní úřady obcí s rozšířenou působností - odbory dopravy, Obecní úřady pověřených obcí - stavební úřady


1x Ministerstvo, 14x Krajské úřady, 204x Obce s rozšířenou působností, 180x Pověřené obce

Předpis

činnost upravena zákonem č. 13/1997 Sb. ve znění pozdějších předpisů a zákony č. 128 a č.129/2000 Sb. A-I.4 Omezení., A-I.5 Úprava značení

Dopravní informace

P-I. O komunikacích, P-II.4. Bezpečnost O-III. Cestovní


neexistuje vlastní informační systém na úrovni silničních správních úřadů

Formát dat

nedefinovaný

GIS

staničení, přístup není sjednocen


informace o vydaných správních rozhodnutích o uzavírkách a omezení obecného užívání "na vědomí" (mimo jiné i CDI PČR), cílené zveřejňování dopravních informací neexistuje


podstatný hlediska odpovědnosti za rozhodnutí o omezení obecného užívání, relativně podstatný i z hlediska prevence

Vliv

především řidiči, IZS


Název

Správci komunikací


Ředitelství silnic a dálnic, a.s.- SSÚD, Krajské úřady - SÚS, Městské a Obecní úřady - Technické služby


13 x SSÚD, 29x SÚS, další desítky subjektů na úrovni Technických služeb

Předpis

činnost upravena zákonem č. 13/1997 Sb. ve znění pozdějších předpisů A-I. Omezení., A-III. Sjízdnost, A-IV. Povětrnostní vlivy, počasí

Dopravní informace

P-I. O komunikacích, P-II.4. Bezpečnost


webová aplikace ŘSD ČR pro zimní zpravodajskou službu

Formát dat

standardní

GIS

ISSDS ČR


informace pilotně poskytovali poprvé v rámci projektu vědy a výzkumu „Metodika ovlivňování chování účastníků silničního provozu prostřednictvím médií“ , v letošním roce je zaváděna definitivní referenční aplikace pro ZZS, stále provozují stávající systém ranních telefonických dispečinků


Velký vliv z hlediska sjízdnosti, významný z hlediska omezení, malý z hlediska prevence

Vliv

především řidiči, využití informací v IZS


58


Název

Ředitelství silnic a dálnic ČR


Ministerstvo dopravy, Ředitelství silnic a dálnic, generální ředitelství


1x Generální ředitelství, 2x závody (Praha, Brno)

Předpis

činnost upravena zákonem č.13/1997 Sb. ve znění pozdějších předpisů a č. 291/2000 Sb. A-I.4. Omezení uzavírka, průjezdnost, A-IV. Počasí meteodata

Dopravní informace

P-I. O komunikacích, O-III. Cestovní

Informační systémy

Viz výše uvedený popis procesních schémat informačního systému pro dálnice

Formát dat

vlastní blízký standardu

GIS

ISSDS ČR


od 1. prosince 2003 poskytuje přehled uzavírek na dálnicích na internetu, zveřejňuje i informace o zimní sjízdnosti, na základě usnesení vlády buduje středisko dopravních informací ŘSD


velký význam mělo by se stát centrálním subjektem z hlediska sběru a zpracování informací pro celou ČR

Vliv

řidiči, IZS


Název

Hasičský záchranný sbor


Ministerstvo vnitra, Hasičský záchranný sbor, generální ředitelství


1x Generální ředitelství, 14x Krajská ředitelství Hasičského záchranného sboru

Předpis

činnost upravena zákonem č.238/2000 Sb. ve znění pozdějších předpisů A-I. Omezení,

Dopravní informace

P-II. O provozu, I-IV. O vozidlech O-III. Cestovní


automatický export dat ze systému operačních středisek

Formát dat

vlastní

GIS

v řešení, možno nalézt společný standard


dosud neposkytuje, informace od HZS jsou předběžného charakteru, připravena je koncepční úprava systému operačních středisek, zároveň HZS potřebuje on line propojení na systém sběru informací o omezení obecného užívání komunikací


velký význam byť jde o informace předběžné

Vliv

řidiči, IZS, v menší míře ostatní účastníci


59


Název

Městské a obecní policie


jednotlivé městské a obecní úřady

Organizační členění Předpis

upravena zákonem č.553/1991 Sb. ve znění pozdějších předpisů A-I. Omezení, A-II. Kongesce, A-III. Sjízdnost, A-V. Parkování

Dopravní informace

P-I. O komunikacích, P-II. O provozu, P-III. O účastnících O-IV. Turistické


není

Formát dat

univerzální internetový systém sběru informací

GIS



dosud poskytuje jen výjimečně většinou vybraným médiím v oblasti svojí působnosti, Městská policie zejména pokud vlastní kamerový systém a operační středisko je významným subjektem pro poskytování informací ve městech


velký význam v celém průřezu poskytovaných informací, možnost předávání i obrazových informací v případě existence kamerového systému

Vliv

všichni účastníci silničního provozu, IZS


Název

Správci sítí


Soukromé společnosti, společnosti zřizované městy, sdružením obcí apod.


Plyn - osm regionálních distributorů, Elektřina - osm regionálních distributorů z nichž je 5 součástí společnosti ČEZ, Voda - není struktura, Teplo - není struktura, Ostatní - struktura částečná Český telecom, České Radiokomunikace)

Předpis A-I.4. Uzavírka, omezení průjezdnosti (Havárie sítí) Dopravní informace Informační systém

není

Formát dat


GIS



informace o aktuálních předem nenaplánovatelných událostech poruch sítí s vlivem na provoz na pozemních komunikacích


malý význam, je velmi málo situací má významnější vliv na silniční provoz, výjimkou jsou Praha a velká města, kde je vysoká koncentrace sítí i pozemních komunikací

Vliv

řidiči, IZS, popřípadě další účastníci silničního provozu

Tab 10:

Subjekty infrastruktury sběru dopravních informací

60


Název

Český hydrometeorologický ústav


Ministerstvo životního prostředí, Český hydrometeorologický ústav, centrála


Centrála Praha, sedm regionálních poboček

Předpis

nařízení vlády Československé republiky č. 96/1953 Sb., zákon č. 130/1974 Sb. (úplné znění č. 458/1992 Sb.) o předpovědní službě, dále vyhláška MŽP č.41/1992 Sb. o ochraně ovzduší A-IV. Počasí

Dopravní informace Informační systém

přímé propojení systémů

Formát dat

vlastní, předmětem dalšího řešení

GIS Charakteristika dopravních informací

subjekt zpracovává specifické informace silniční meteorologie, zatím je účastníkům silničního provozu neposkytuje


velký význam z hlediska počasí a povětrnostních vlivů

Vliv

všichni účastníci silničního provozu, IZS

Tab 11:


Název

Dopravní podnik


Městský úřad, soukromá společnost, atd.

Organizační členění Předpis A-I. Omezení, A-II. Kongesce, Dopravní informace

P-I. O komunikacích O-I. Cestovní


nemají

Formát dat


GIS



dosud poskytuje jen výjimečně, ve městech je určitým doplňkem Městské policie, v rámci příměstské dopravy může poskytovat informace aktuálního charakteru, důležité je i propojení informací o provozu hromadné dopravy z hlediska jejího využití, možnost zavedení systému sledování flotily vozidel a vyhodnocování jízdních dob


menší význam , doplňkový charakter

Vliv

řidiči, v případě informací o provozu hromadné dopravy i chodci

Tab 12:


61


Název

Přepravci nadměrných nákladů


soukromá společnost

Organizační členění Předpis A-I. Omezení, A-II. Kongesce, Dopravní informace Informační systém

nemají

Formát dat


GIS



dosud poskytuje jen výjimečně, cílem je zavedení on-line sledování nadměrných nákladů prostřednictvím průběžné komunikace s posádkou


střední význam , doplňkový charakter

Vliv

řidiči

Tab 13:


Název

Pořadatelé akcí


různé subjekty

Organizační členění Předpis A-I. Omezení, A-V.I. Parkování Dopravní informace Informační systém

nemají

Formát dat


GIS



dosud poskytuje jen výjimečně, cílem je zavedení on-line informační spolupráce s pořadateli velkých akcí s přímým (cyklistické závody) či nepřímým (výstavy a veletrhy, sportovní akce, demonstrace, atd.). vlivem na silniční provoz


střední význam , doplňkový charakter

Vliv

řidiči, ostatní účastníci

Tab 14:


62


Název

Podniky Povodí


Ministerstvo zemědělství, Ministerstvo životního prostředí


Povodí Labe, Povodí Vltavy, Povodí Ohře, Povodí Moravy, Povodí Odry

Předpis

upraveno zákonem č. 305/2000 Sb. a č. 254/2001 Sb. ve znění pozdějších předpisů A-I.3. Překážka provozu, A-I.4. Uzavírka, průjezdnost

Dopravní informace O-IV. Turistické Informační systém

dílčí informační systém pro sledování průtoků a stupňů povodňové aktivity

Formát dat

univerzální internetový systém sběru informací i přímé propojení systémů

GIS

univerzální internetový systém sběru informací i přímé propojení systémů


poskytuje předběžné informace o SPA, dále informace o prognózách vývoje a o záplavových územích


velký význam v okamžiku záplav

Vliv

řidiči, ostatní účastníci

Tab 15:


Název

Vodoprávní úřady


Krajské úřady, odbory životního prostředí a zemědělství


od 1.1.2004 vodoprávní úřad na úrovni krajů přebírá kompetence v tomto kraji, 14 úřadů

Předpis

upraveno zákonem č. 305/2000 Sb. a č. 254/20001 Sb. ve znění pozdějších předpisů

Dopravní informace O-IV. Všeobecné Informační systém

Není

Formát dat GIS Charakteristika dopravních informací

poskytuje pouze podpůrné informace pro realizaci koncepce ovlivňování chování účastníků silničního provozu v době povodní, zpracovává povodňové plány na úrovni kraje, tyto obsahují informace o záplavových územích, o ohrožených komunikacích a také o povodňových orgánech všech stupňů


ve vztahu k účastníkům silničního provozu přímý význam malý, informační podpora pro IZS v době krize

Vliv

Přímý žádný

Tab 16:


63


Název

Celní správa


Generální ředitelství cel, regionální celní ředitelství


Generální ředitelství cel, 8x celní ředitelství

Předpis

upraveno zákonem č. 13/1993 Sb., v úplném znění č. 1/2002 Sb. A-VII. Čekací doby

Dopravní informace

P-II.3. Právní podmínky O-IV. Všeobecné, O-III. Cestovní


Není

Formát dat


GIS



role tohoto subjektu v rámci poskytování dopravních informací je jen v situaci o regulace a opatřeních na hraničních přechodech (např. slintavka a kulhavka)


malý význam po vstupu do EU

Vliv

řidiči

Tab 17:


Název

Horská služba


Občanské sdružení Horská služba ČR


sedm oblastí

Předpis A-I. Omezení, A-III. Sjízdnost, A-IV. Počasí, A-V. Parkování Dopravní informace O-IV. Turistické Informační systém

není

Formát dat


GIS



subjekt může poskytovat informace spojené s horskými centry, a to zejména v zimní turistické sezóně např. s parkováním


malý význam, doplňkové informace

Vliv

řidiči, ostatní účastníci silničního provozu

Tab 18:


64


Název

Informační centra


Městský úřad, nezisková organizace, soukromý subjekt, atd.

Organizační členění Předpis A-I. Omezení, A-V. Parkování Dopravní informace O-III. Cestovní, O-IV. Turistické Informační systém

Jsou částečné systémy bez garantované vazby na dopravní a turistické informace

Formát dat


GIS



subjekt může poskytovat informace spojené s pořádáním akcí a tím vyvolaným omezením obecného užívání, dále informace turistického charakteru


Malý až střední význam

Vliv


Tab 19:


Název

Národní parky, Chráněné krajinné oblasti


Ministerstvo životního prostředí, Správa CHKO ČR


Ministerstvo životního prostředí, 4x Správa národního parku, 15x Správa CHKO

Předpis A-I. Omezení, A-V. Parkování Dopravní informace O-III. Cestovní, O-IV. Turistické Informační systém

není

Formát dat


GIS



subjekt může poskytovat informace spojené s omezením obecného užívání z důvodu ochrany přírody v daném území, dále informace turistického charakteru


malý význam

Vliv


Tab 20:


65


Název

Zdravotní záchranná služba, Letecká záchranná služba


Ministerstvo zdravotnictví, Krajské úřady, Městské úřady, sdružení HEMS


Krajská územní střediska, další složky na úrovni okresů

Předpis A-I. Omezení Dopravní informace O-III. Bezpečnost Informační systém

Dílčí systémy bez centrálního propojení, částečně využitelný systém napojený na tel. č. 112

Formát dat


GIS



subjekt může poskytovat informace spojené s omezením obecného užívání z důvodu aktuální události, jeho hlavním úkolem je však zachraňovat životy


malý význam, přednostně plní jiné funkce

Vliv

řidiči

Tab 21:


Název

Asistenční služby


soukromá společnost


regionální pobočky

Předpis A-I. Omezení Dopravní informace

P-II. O provozu, P-IV. O vozidlech O-I. Všeobecné, O-II. Servisní, O-III. Cestovní, O-IV. Turistické

Komunikační systém

Vlastní informační systémy, propojení na subsystém poskytovatele informačních služeb je věcí obchodních motivů

Formát dat GIS Charakteristika dopravních informací

subjekt může poskytovat sám nebo zprostředkovaně širokou škálu dopravních informací aktuálních, preventivních i ostatních


velký význam, zejména s ohledem na cílené zaměření na danou problematiku

Vliv

řidiči

Tab 22:


Cílem je napojení ITS architektury na organizační strukturu ČR pro několik ITS aplikací. Jednotlivé subsystémy budou reprezentovat jednotlivé organizační jednotky a budou též

66


vyjadřovat hierarchické uspořádání a přenos informací jak horizontálním, tak vertikálním směrem.

4.2. Vazba organizační struktury a ITS architektury ve veřejné dopravě Státní odborný dozor v silniční dopravě Zákon č.111/1994 Sb. o silniční dopravě ve znění pozdějších předpisů stanoví kdo vykonává státní odborný dozor a vrchní státní dozor a současně stanoví práva a povinnosti pracovníků státního odborného dozoru. Státní odborný dozor v silniční dopravě vykonávají : • dopravní úřady, • celní úřady, • Ministerstvo dopravy. Ministerstvo dopravy vykonává státní odborný dozor v mezinárodní autobusové dopravě. Dopravní úřady a celní úřady vykonávají ve svém správním obvodu státní odborný dozor ve všech věcech, které nenáleží Ministerstvu dopravy. V případě celních úřadů je výkon státního odborného dozoru

dále vymezen na výkon dozoru nad prací osádek vozidel

v mezinárodní silniční nákladní dopravě a ve věcech mezinárodní dopravy osob a mohou podávat dopravním úřadům návrhy na zahájení řízení o uložení pokuty podle §35. Při výkonu státního odborného dozoru pověření pracovníci dozírají, zda: • dopravci, • odesilatelé, • řidiči dodržují podmínky a plní povinnosti stanovené tímto zákonem a zda provozují dopravu podle uděleného povolení. Předmětem kontroly v oblasti dopravy osob jsou následující povinnosti uložené dopravci : • vedení záznamu o provozu vozidla, • platnost technických prohlídek měření emisí, • označení vozidla, • dodržování ustanovení přepravního řádu, 67


• předkládání a schvalování jízdního řádu, • údržbu označníku zastávky a dalšího zastávkového vybavení, • dodržování podmínek pro provozování linkové osobní dopravy, • při použití finančních prostředků na zajištění dopravní obslužnosti veřejnou linkovou dopravou z rozpočtu kraje, nebo ze státního rozpočtu.

Při výkonu vrchního státního dozoru MD dozírá na výkon státního odborného dozoru vykonávaného dopravními úřady.

Státní dozor ve věcech drah Zákon č.266/1994 Sb. o dráhách ve znění pozdějších předpisů stanoví kdo vykonává státní dozor ve věcech drah a současně stanovuje předmět výkonu státního dozoru. Státní dozor ve věcech drah vykonávají : • Drážní úřad, • Drážní inspekce, • obce v přenesené působnosti. Vrchní státní dozor ve věcech drah vykonává MD při kterém vykonává činnost náležející státnímu dozoru a dále dozírá nad výkonem státního dozoru ve věci drah vykonávaným Drážním úřadem a obcemi. Při výkonu státního odborného dozoru pověřené osoby dozírají, zda : • vlastník dráhy, • provozovatel dráhy, • dopravce dodržuje a plní svoje povinnosti stanovené právními předpisy. Předmětem kontroly je zejména : • provozování drážní dopravy v souladu s platnou licencí, • dodržování povinností při přepravě nebezpečných věcí, • splnění požadavků na odbornou a zdravotní způsobilost osob zaměstnávaných při provozování drážní dopravy a používání drážních vozidel se schválenou způsobilostí, 68


• splnění požadavků při vzniku mimořádných událostí v drážní dopravě, • plnění opatření k předcházení vzniku mimořádných událostí, • financování dopravní obslužnosti (tato povinnost je dána vyhláškou č.36/2001 Sb. o prokazatelné ztrátě ve veřejné drážní dopravě a o vymezení souběžné veřejné osobní dopravy).

Obr 35:

Schéma vazby organizační struktury a ITS architektury ve veřejné dopravě 69


5. Vytvoření koordinačního centra 5.1. Koordinační centrum Cílem tohoto pracovního úkolu je vytvoření koordinačního centra složeného z řešitelského týmu tak, aby došlo k sjednocení náplně výzkumu, vývoje a vzdělání v oblasti dopravní telematiky v ČR.

5.2. Rozhraní pro komunikaci týmu řešitelů Pro snadnou komunikaci v řešitelském týmu bylo zprovozněno diskusní fórum, které umožňuje členům týmu rozesílání hromadných emailů, zakládání nových témat k diskusi, připomínkování jednotlivých příspěvků (www.itsportal.cz/forum).

Obr 36:

Rozhraní pro komunikaci týmu řešitelů – diskusní fórum ITS portálu

70


5.3. ITS portál ITS portál obsahuje odkazy na nejrůznější informace týkající se projektové činnosti, společností působících v oblasti dopravních systémů a telematiky, časopisů zabývajících se problematikou dopravy, telematických projektů uvedených do praxe a další. ITS portál dále slouží jako nástroj pro procházení a prohlížení ITS architektury. Tímto spojuje v kompaktní celek logickou a fyzickou část architektury, zjednodušuje a zrychluje orientaci a práci s architekturou. Členové týmu podílející se na projektu ITS architektury, kteří mají zřízen přístup do editačního rozhraní, se mohou do tohoto rozhraní přihlašovat přímo z portálu. ITS portál se nachází na adrese www.itsportal.cz nebo www.its-portal.cz

Obr 37:

ITS portál, oddíl o telematice

71


6. Závěr V roce 2005 řešitelé předpokládají zpracování manuálu a učebního textu pro uživatele systému, uspořádání výukových kurzů zahrnujících různé příklady návrhu ITS systému dle vytvořené architektury a softwarového nástroje a zpracování architektur pro všechny národní pilotní projekty zahrnutých do programu CONNECT (ČR je vedoucím pro celý CONNECT v oblasti ITS architektury). Tímto vznikne řada praktických příkladů, které budou i realizovány jako pilotní projekty a bude možno tak porovnat ekonomické přínosy ITS architektury a zároveň vyzkoušet, jak stejné či podobně zpracované ITS architektury přispívají k informačnímu propojení jednotlivých zemí.

72


7. Literatura [1]

M. Svítek: Flight Telematics, Workshop R&D, CEATS Research, Development and Simulation Centre, Budapešť, 2003.

[2]

F. Kopecký, M. Svítek: Transport of Dangerous and Oversized Goods, Proceedings of Workshop ČVUT 2003, 1200 -1201, Praha 2003.

[3]

M. Svítek: The ITS Applications Using the GNSS System, Proceedings of Workshop ČVUT 2003, 1198 -1199, Praha 2003.

[4]

M. Svítek: Architektura ITS v ČR, mezinárodní konference ITS'03, Praha 2003.

[5]

M. Svítek, F. Kopecký: Údaj o reálné poloze opravního elementu v dopravnětelematických aplikacích, mezinárodní konference ITS'03, Praha 2003.

[6]

L. Mandík, M. Svítek: Elektronické mýtné na bázi GNSS/CN, mezinárodní konference ITS'03, Praha 2003.

[7]

F. Kopecký, M. Svítek: Základní principy rozvoje železniční telematiky, mezinárodní konference ITS'03, Praha 2003.

[8]

J. Matějec, J. Čábelka, M. Svítek: Telematika intermodální dopravy, mezinárodní konference ITS'03, Praha 2003.

[9]

M. Svítek: Towards to Telematics, Zeszyty Naukowe Politechniky Slaskiej 2002, Transport z.45, nr kol. 1570, ISSN 0209-3324, pp 39-45, 2003.

[10]

F. Kopecký, M. Svítek: Synchronizace informací v ITS, seminář odbavovací systémy v integrované veřejné dopravě, PVT, a.s., CDV, SDT ČR a SDP, 2003.

[11]

M. Svítek: Galileo - Evropský satelitní navigační systém, Telekomunikační zpravodaj č.7, Testcom, 2003.

[12]

M. Svítek: Monitoring and control of hazardous goods with GNSS, Galileo for an enlarged Europe, Warsaw, 2003.

[13]

M. Svítek: Architektura ITS v ČR, Doprava a telekomunikace pro 3. tisíciletí, konference k 10. výročí založení Fakulty dopravní ČVUT, Praha, 2003.

[14]

M. Svítek: Architecture of the Transport Telematics Applications Using the GNSS, International MultiConference in Computer Science & Engineering, International

73


Conference on Information and Knowledge Engineering (IKE'03), Las Vegas, USA, 2003. [15]

M. Svítek: Výsledky projektů vědy a výzkumu MD ČR, seminář Rozvoj ITS na železnici, KPM, a.s., 2003.

[16]

M. Svítek, Z. Votruba: Telematické architektury pro multimodální dopravu, mezinárodní konference CZ-Intermodal 2003 "Intermodální doprava před vstupem ČR do EU", Universita Pardubice, 2003.

[17]

M. Svítek, Z. Votruba: Telematická architektura na příkladu vybraného regionu Telematics Architecture - a regional case study, mezinárodní konference Development of Transport Infrastructure within the Carpathian Euroregion and its Impact on the Regions, Zemplínská Šírava - Kaluža, Slovensko, 2003.

[18]

M. Svítek: Architecture of Intelligent Transport Systems and Services, TST 03, Transport Systems Telematics, 3. international conference, Katowice - Ustron, Polsko, 2003, ISBN 83-917156-1-2.

[19]

M. Svítek: Architecture of Intelligent Transport Systems and Services, ITS World Congress in Madrid, Madrid 2003.

[20]

M. Svítek, J. Matějec, M. Pichl: Platební systémy v dopravě, Teleinformatika 2003.

[21]

M. Svítek, M. Pichl: Inteligentní dopravní systémy - národní a Evropské projekty, NISAINVEX, Liberec, 2003

[22]

M. Pichl, M. Svítek: Telematika v železniční dopravě s ohledem na harmonizovaný a synchronizovaný rozvoj ITS v Evropě, Vědeckotechnický sborník Českých drah č. 16, 2003, str. 21-26, ISSN 1211-2321.

[23]

Výsledky projektu E-MERGE www.e-merge.org

[24]

Přibyl P. a kol.: Studie dopravní telematiky na území hl. m. Prahy. Praha, Eltodo červen 2001.

[25]

Přibyl P., Svítek M.: Inteligentní dopravní systémy. Praha, BEN 2001.

[26]

M. Svítek, Pelikán E.: Monitoring and Control of Dangerous Goods Transport, TRANSTEC 2004, The Transport Science & Technology Congress, Athens, September 2004.

[27]

M. Svítek: Elektronické mýtné - rychle, ale ne zbrkle, Ekonom, č.34, 2004.

[28]

M. Svítek, M. Jánešová: Elektronické platby v dopravě, Informatika a informační technologie, I&IT 2004, Universita Matěja Bela, Banská Bystrica, 2004.

74


[29]

M. Svítek, E. Pelikán: Monitoring and Control of Dangerous Goods Transport, Neural Network World (NNW) 3-4, 2004, pp. 303-312.

[30]

M. Svítek, M. Jánešová: Systems for Electronic Fee Collection, Košice 2004, Sixth International Scientific Conference Electronic Computers and Informatics ECI 2004, Košice - Herľany, Slovakia, 2004, Košice.

[31]

M.

Svítek:

Architektura

systému

tísňového

volání

(e-call),

Technologies&Prosperity, 5/2004. [32]

J. Veselý, M. Svítek: Including of ITS into national information system architecture of the Czech Republic, Transport Systems Telematics TST04, 4th International Conference, Katowice-Ustron, Poland, 2004.

[33]

M. Svítek, L. Pejša, B. Kadleček: In-vehicle weight in motion system, Transport Systems Telematics TST04, 4th International Conference, Katowice-Ustron, Poland, 2004.

[34]

M. Svítek: ITS architektura ČR, konference Věda o dopravě, ČVUT FD, Praha 2004.

[35]

P. Přibyl, M. Svítek: RDS/TMC v ČR, strategická sekce, světový ITS kongres Nagoya 2004, Japonsko.

[36]

M. Svítek, K. Uhlíková: Informační systém pro monitorování a kontrolu přepravy nebezpečných

nákladů,

Současnost

a

budoucnost

krizového

řízení,

7.

mezinárodní konference, T-Soft, Praha, 2004. [37]

V. Svoboda M. Svítek: Telematika nad dopravními sítěmi, Monografie ČVUT, Praha 2004, 263 stran, ISBN 80-01-03087-3.

[38]

P. Přibyl, M. Svítek: Telematika na transporte, BEN, Moskva, 550 stran, 2004, ISBN 80-7300-100-4.

75


76

Ing. Jiří Matějec Ing. Petr Zobaník Ing. Petr Říha Ondřej Galík Martin Dvořák

Recommend Documents