Ing. Karel Kraus Ing. Jaroslav Zvára Ing. Ondřej Galík Ing. Martin Dvořák

Transkript

1 F AKULTA DOPRAVNÍ Č VUT K ONVIKTSKÁ 20, P RAHA 1 ITS v podmínkách dopravnětelekomunikačního prostředí ČR (802/210/108) Technická zpráva za rok 2005 Doc. Dr. Ing. Miroslav Svítek Prof. Ing. Zdeněk Votruba, CSc. Ing. František Kopecký Ing. Tomáš Tvrzský Ing. Miloslav Věžník Prof. Ing. Mirko Novák, DrSc. Prof. Ing. Pavel Přibyl, CSc. Ing. Karel Kraus Ing. Jaroslav Zvára Ing. Ondřej Galík Ing. Martin Dvořák VERZE 1.0

2 Obsah: 1. Úvod Budoucnost ITS architektury a její správa Metodika využití ITS architektury při návrhu telematických aplikací Metodika využití ITS architektury Popis uživatelských potřeb Popis funkční architektury systému Popis informační architektury Pilotní projekty Monitorování dopravní infrastruktury a řízení dopravy - pilotní vybavení silničního tunelu ITS systémy Dopravně-informační centrum města Prahy a středočeského kraje Dopravní informační stojany použitelné nevidomými a slabozrakými Poskytování informací o dopravním spojení pro nevidomé a těžce zrakově postižené občany Clearingové centrum veřejné osobní dopravy Dopravně-řídící centrum Ostrava Informační systém pro přepravu nebezpečných nákladů Systém tísňového volání (E-CALL) Závěr Literatura...62 Příloha 1 - Metodika využívání a rozšiřování ITS architektury při praktickém návrhu projektu Příloha 2 - Aplikace národní architektury ITS pro realizaci systémů dopravní telematiky - Silnice a dálnice sítě pozemních komunikací ČR - POSTUPY A PŘÍKLADY...65 Příloha 3 - Aplikace národní architektury ITS pro realizaci systémů dopravní telematiky - Jednotný systém dopravních informací pro ČR schválený usnesením Vlády ČR č. 590 ze dne Příloha 4 - Technické podmínky: Dopravní telematika silnice a dálnice ČR

3 1. Úvod S ohledem na navržené pilotní projekty v rámci programu CONNECT, byly tyto projekty analyzovány a pro tyto projekty byla vytvořena ITS architektura tak, aby bylo dosaženo vzájemné komunikace mezi jednotlivými ITS aplikacemi (pilotními projekty). U každého pilotního projektu byly vybrány uživatelské potřeby, kterých se pilotní projekt týká. Tyto uživatelské potřeby byly pomocí návrhového softwaru zadány a převedeny do podoby funkční a informační architektury. Zároveň bylo pomocí návrhového softwaru stanoveno okolí ITS systému (tzv. terminátoři). U každé vytvořené ITS architektury pilotního projektu byla provedena předběžná analýza jednotlivých procesů a architektura pilotního projektu byla konzultována s odborníky na danou problematiku. Pokud byla objevena nesrovnalost, či pokud byla nalezena chybějící funkce nebo informační vazba, byly tyto chybějící prvky do ITS architektury ČR přidány. Tímto způsobem lze dálkově upravovat ITS architekturu ČR (pokud daný subjekt má přístupová práva) a ITS architektura ČR se tak stává živým dokumentem, který je možno kontinuálně upravovat, pokud se objeví nová aplikace, atd. Metodika pro další správu a údržbu ITS architektury ČR vychází z modulární koncepce navržené databáze ITS architektury i navrženého softwarového nástroje. Softwarový návrhový nástroj využívá aktuální stav databáze ITS architektury, tedy při přidání nových funkcí, uživatelských potřeb, nových informačních vazeb je možno tyto nové položky ihned využívat při návrhu konkrétní aplikace. Z výše uvedené analýzy vyplývá, že aktualizace a správa ITS architektury ČR se omezuje pouze na aktualizaci a správu databáze ITS architektury, tedy databáze, uživatelských potřeb, databáze funkcí, databáze databází ITS systému, databáze informačních toků, databáze terminátorů, databáze fyzických subsystémů a databáze fyzických komunikačních toků. Všechny zmíněné databáze jsou číslovány pomocí identifikátorů (ID) tak, aby byly vzájemně provázány a aby bylo možno vložit do systému nový prvek (uživatelskou potřebu, databázi, funkci, informační tok, terminátor, fyzický subsystém, fyzický komunikační tok). Aktualizace jednotlivých prvků ITS databáze je možno provést i dálkově přes www rozhraní. Každý, kdo chce provést změnu, musí mít přiděleno jméno a heslo. Jednotlivé změny jsou archivovány a dle provedených změn jsou číslovány verze ITS architektury. Pokud bude provedená změna schválena koordinační skupinou, bude platit nová verze architektury s novým identifikačním číslem. Tato změněná architektura nahradí starší verzi ITS architektury. Zároveň nová verze ITS architektury bude využita jak v softwarovém nástroji pro návrh ITS aplikací, tak bude zobrazena na www rozhraní 3

4 Aby se ITS architektura ČR stala živým a používaným dokumentem, byla začleněna do připravovaných Technických podmínek (TP). TP jsou připravovány jak pro telematiku silnic a dálnic, tak pro telematiku ve městech. Zadání TP pro telematiku silnic a dálnic bylo učiněno ze strany Ředitelství silnic a dálnic. Řešitelé těchto TP jsou v kontaktu s řešiteli tohoto projektu a mnohé principy z ITS architektury byly do těchto TP promítnuty. Řešitel TP pro telematiku silnic a dálnic společnost Eltodo byla zároveň subdodavatelem projektu ITS v dopravně-telekomunikačním prostředí ČR. Tímto byla zajištěna kontinuita mezi tímto projektem a připravovaným legislativním rámcem ve formě TP. Na základě této spolupráce byla vytvořena příloha TP, která řeší konkrétní ITS architekturu všech telematických aplikacích silnic a dálnic. Obdobná situace je u dalšího významného projektu ČR, kterým je Jednotný systém sběru dopravních informací, kdy hlavní řešitel byl též subdodavatelem tohoto projektu a vytvořil detailní architekturu navrženého systému sběru dopravních informací, která je též v souladu s ITS architekturou ČR. Podobným způsobem je možno pokračovat v problematice telematiky měst, což je již dohodnuto s řešitelem těchto TP. Při každém podrobném příkladu se ukáže nutnost změn či doplnění ITS architektury ČR. Tyto změny jsou již k dispozici dalším řešitelům a dochází tak k dokumentaci ITS aplikací. ITS architektura v tomto pojetí se stává expertním systémem, který zaznamenává vzorové aplikace a dle nich ITS architekturu upravuje. Z tohoto důvodu není vhodné ITS architekturu standardizovat, protože jde o stále se měnící dokument. Co však lze standardizovat, je postup (technické podmínky), že řešitel nových ITS aplikací by měl vycházet z ITS architektury, zpracovat projekt dle návrhového softwaru a ten dále a konkrétně rozpracovávat. Pokud nastanou obtíže, měl by řešitel projektu požádat o rozšíření či úpravu ITS architektury ČR. U projektů EU typu Connect, je využití ITS architektury péro pilotní projekty povinné. Aby ITS architektura byla dále rozšiřována, byl v roce 2005 vytvořen podrobný manuál k návrhovému softwarovému nástroji. Tento manuál doplňuje softwarový nástroj o jednoduché instrukce a o základní principy využití ITS architektury ČR. Tento manuál spolu s vzorovými příklady (pilotní projekty Connect) se stává studijním materiálem pro širokou odbornou veřejnost a s použitím volně dostupných zdrojů (návrhový software, ITS architektura na je možno provádět návrh ITS aplikací. Řešitel FD ČVUT uzavřel se zadavatele MD ČR smlouvu, že všechny zprávy, software, portál vytvořený v rámci tohoto projektu budou k dispozici široké veřejnosti po dobu dvou let. Během této doby budou schváleny připravované Technické podmínky, které se odkazují na 4

5 výsledky tohoto projektu. Pokud budou TP schváleny, bude třeba formou finančního příspěvku řešit další správu a údržbu ITS architektury. Koordinační centrum ITS je založeno na vytvoření ITS portálu na adrese: kde jsou umístěny všechny zprávy tohoto projektu a kde je též umístěno grafické rozhraní databáze ITS architektury ČR. Prostřednictvím tohoto rozhraní je možno procházet ITS architekturou a zobrazovat její jednotlivé prvky - funkce, databáze, informační vazby, fyzické subsystémy, fyzické komunikační vazby, požadavky uživatelů. Dále je možno zobrazit k jednotlivým prvkům ITS architektury prvky ITS datového registru a jednotlivé ITS standardy včetně popisu těchto standardů. Tato část může být využívána jednotlivými organizacemi státní správy a veřejné samosprávy. Na ITS portálu je umístěn i softwarový nástroj s podrobným manuálem i vzorovými příklady, který umožňuje lepší zobrazování databází ITS architektury. Pomocí volně dostupných dokumentů a softwaru je možno provádět návrh ITS aplikací, což byl základní cíl projektu ITS v dopravně-telekomunikačním prostředí ČR. Další část koordinačního centra zahrnuje vazby na řešené projekty v EU i na další projekty MD, které se týkají ITS systémů. Prostřednictvím tohoto portálu se bude moci odborná veřejnost seznámit s výsledky řešení všech projektů financovaných z rozpočtu zadavatele a nebude docházet k duplicitním řešením v jednotlivých projektech. ITS portál obsahuje i vazby na organizace zabývající se ITS i na odborné časopisy, slovník pojmů, atd. 2. Budoucnost ITS architektury a její správa Naprosto zásadním a klíčovým se ukazuje přístup k ITS architektuře skrze tzv. moduly nebo též balíčky služeb a vybavení. Balíček služeb nám dává přístup ke zjednodušenému náhledu na architekturu. Balíčky služeb jsou sestavovány tak, aby společně nebo samostatně obsluhovaly nějaký definovaný problém z reálného světa problematiky dopravy. Balíčky služeb sdružují jeden nebo více balíčků vybavení, které jsou vzájemně mezi sebou či mezi vnějšími objekty (terminátory) pospojovány datovými toky. Balíčky vybavení jsou nositeli dílčích služeb, které zajišťují obsluhu dané problematiky. Jsou to stavební kameny modulárního přístupu k architektuře. Zároveň jsou také zjemněním fyzické ITS architektury, která obaluje nejnižší, logickou, úroveň. Jedná se o technicky reálně implementovatelné části architektury. Z tohoto důvodu mohou být uchopeny pro určování výnosových a nákladových ohodnocení, výpočty účinnosti telematických systémů. Potřeba hodnocení účinnosti ITS systémů byla také důvodem ke vzniku balíčků vybavení resp. služeb. K popisu balíčků je 5

6 nutné balíčky parametrizovat vhodnými a smysluplnými atributy, které poslouží ke kvantitativnímu hodnocení konkrétních ITS systémů. Balíček vybavení je souhrnem hardwarové a softwarové implementace konkrétních funkcí definovaných v balíčku. Díky vhodné parametrizaci však nejsme odkázáni jen na jedinou implementaci, ale můžeme nastavit libovolné požadované nároky kladené na balíček. Takováto míra volnosti v procesu návrhu však klade vysoké nároky na relevanci atributů, kterými je balíček popsán. Úkol definování vhodných parametrů je zcela zásadní pro další rozvoj ITS architektury ČR a v následující výzkumné činnosti stojí na předních příčkách zájmu. V průběhu výzkumné činnosti v oblasti ITS architektury se začínaly objevovat stále častěji otázky spojené s problematikou praktického nasazení architektury resp. otázky týkající se tvorby nástrojů pro podporu rozhodování na základě kvalitativního vyjádření ať už formou ekonomických ukazatelů (parametrů), které jsou primárním hlediskem, či formou informačně časových závislostí komunikace mezi balíčky, nároky na komunikační kanál. Máme-li vhodně definované parametry balíčků, pak lze přistoupit k popisu přínosů spojených s použitím balíčků služeb a vybavení. Flexibilita ITS architektury je velice důležitá, protože architektura musí obsáhnout velice širokou paletu možných ITS řešení a implementací, která mohou být realizována nejen nezávisle na geografické poloze ITS systému, ale i v poměrně širokém časovém horizontu (desítky let). Důsledkem této všeobjímavosti a obecnosti se architektura stává velice složitou na pochopení jak ve svém celku, tak především v dílčích oblastech (jednotlivé makrofunkce, subsystémy). V takovém stavu je architektura prakticky reálně použitelná pro výběr optimálního řešení aktuálních dopravních problémů pouze s přispěním řady softwarových nástrojů. Aby byla poskytnuta průhlednost a přehled ve funkcionalitách, které mohou být využity v procesu návrhu ITS systému, a které nám ITS architektura nabízí, byly definovány balíčky služeb a vybavení. Balíčky služeb poskytují přístupný pohled na národní architekturu skrze reálná a běžně dostupná technická řešení. V každé oblasti byly definováno několik balíčků služeb, které nabízejí výběr služeb v závislosti na nejrůznějších nákladech. Balíčky služeb mohou být rozděleny do kategorií podle dostupnosti technického řešení. Existuje celá škála balíčků od těch nejjednodušších až po vysoce pokročilé a náročné služby, které v daném čase nemusí ještě být běžně dostupné. Některé balíčky se mohou vyvíjet v tom smyslu, že jsou budovány z jednoduchých a dostupných balíčků. Tímto lze dospět k poměrně složitým službám, aniž by hrozilo, že pro příliš velkou složitost nebude daný balíček přehledný a schopný svého dalšího vývoje. Je však podstatné podotknout, že balíčky služeb spíše než koncept na řešení problému slouží jako ilustrativní pohled na architekturu. Možných způsobů implementace různých dopravních problémů je nekonečné v porovnání s několika málo balíčky služeb. Balíčky služeb jsou 6

7 nástrojem, který umožňuje specifikovat dané či obdobné služby na základě definice ITS architektury. Jde o získání obecného poznání toho, jaké vztahy jsou mezi reálným technickým řešením a architekturou. Implementace rozhraní pro úpravu a manipulaci s daty je realizována formou webového rozhraní. Toto řešení bylo zvoleno z důvodu potřeby zajištění neustálého přístupu uživatelů k ITS databázi, sdílení dat a koordinaci prací na architektuře. Protože je systém modulární, lze jej libovolně modifikovat podle aktuálních požadavků uživatelů a tím přispět ke kvalitě jejich práce. Vstup do systému je umožněn pouze autorizovaným uživatelům. Každý uživatel je oprávněn provádět jen ty operace, ke kterým má přidělena potřebná práva. Návrh řešení softwarové aplikace pro návrh projektů v ITS v rámci dopravnětelekomunikačního prostředí České republiky je uvažován i pro budoucí rozvoj telematiky v České republice a jeho fáze vývoje internetové aplikace není dosud zcela ukončena. Uvažuje se o rozšíření o nové funkce, propojení s jednotlivými uživateli aplikačního software na bázi internetové komunikace. Tím by se do aplikace začlenila i funkce ITS diskusního fóra, které je v nynější verzi od samotného software oddělena jako zvláštní modul. Uvažuje se v následujících krocích vývoje integrace jednotlivých, zatím oddělených, modulů, nejen začlenění již zmíněného diskusního fóra, ale i o integraci samotného software zobrazující model architektury editační software architektury a dalších připravovaných modulů, zejména takových, které se týkají legislativního rámce ITS, jednotlivých legislativních norem a nařízení, včetně návaznosti na legislativní normy Evropské unie, které jsou pro realizaci ITS v České republice závazné. Touto integrací by vznikl komplexní software pro návrh ITS projektů v oblasti České republiky sdružující skupiny uživatelů diskutujících nad návrhy projektů, s on-line návazností na veřejný i soukromý sektor. Výhoda tohoto navrhovaného řešení spočívá právě zejména v řešení on-line internetové aplikace, kdy jednotliví uživatelé přizvaní k řešení projektů ITS mohou v reálném čase diskutovat o řešeném projektu. Další výhodou takového řešení je fakt, že všichni uživatelé pracují se stejnými aktuálními daty. V horizontu vzdálenější budoucnosti se uvažuje i o vývoji ITS software jakožto software nikoli na bázi internetové aplikace, ale na bázi uživatelského software pro prostředí multipratformních osobních počítačů. Tato varianta je z hlediska vývoje mnohem náročnější než řešení pomocí on-line internetové aplikace a přináší s sebou mnohé výhody, ale i nevýhody. Hlavní výhodou takového řešení je zejména možnost provozovat systémově i graficky náročnější prostředky pro návrh projektů ITS, kvalitnější a rozsáhlejší vizualizaci výstupů. Je uvažováno při takovém řešení s aktualizací nainstalovaného software, zejména prvků týkajících se legislativy, změn architektury a jednotlivých zpracovávaných projektů. Uživatel při spuštění software by svolil s aktualizací, která by se automaticky provedla, aniž by uživatel musel do aktualizačního procesu zasahovat. Tímto krokem je zajištěn požadavek 7

8 na práci s aktuálními daty, i když je patrné, že při řešení pomocí internetové aplikace jde o aktuální data již z principu. Tato nevýhoda by byla ošetřena tím, že by aplikace sama kontrolovala nejaktuálnější data porovnáním nainstalovaných dat a dat na aktualizačním serveru i během práce uživatele na návrhu projektu, nejen při startu aplikace. Jelikož ale tato varianta návrhového software je výhodná z hlediska možnosti práce s velkými objemy dat, náročnějšími grafickými výstupy, pohodlnějšími prvky pro uživatele, je již ze svého principu náročnější na správu aktuálních dat a možnost diskusních fór uživatelů. Aktuální data by se dle návrhu řešila formou aktualizačních balíčků, jejichž samotnou aktualizaci by si hlídal návrhový software sám, ale otázka diskusních fór uživatelů, členů jednotlivých projektů ze sektorů státních i soukromých, by byla řešena formou internetových on-line diskusních fór. Obě varianty řešení aplikace by umožňovala samozřejmě rozesílání informací o aktuálních stavech v projektech, kterých jsou uživatelé členy. Poučením se z výsledku ostatních ITS architektur, zhodnocením jejich výsledků, vyplývá snaha o aplikaci nového a uživatelsky zaměřeného řešení, jenž povede k rozvoji takového ITS software, který bude integrovat nejen funkce spojené s prohlížením architektury jako celku, možností editace či tvoření vlastních podarchitektur, ale hlavní myšlenka je dbát zejména na propojení jednotlivých členů týmů, jejich koordinace, zaměření na vlastní, již zcela konkrétní a realizovatelné ITS projekty s návazností například i na orgány státní správy a samosprávy. Vytvořit takový nástroj, jehož výstupem bude kvalitní, realizovatelný a prospěšný ITS projekt odpovídající představám navrhovatelů, orgánů veřejného sektoru a zejména i budoucím uživatelům. Výhledovým cílem tvorby návrhového nástroje je vytvoření takového softwarového řešení, které bude zcela postačovat potřebám uživatelů, subjektů navrhujících jednotlivé ITS systémy, jak z hlediska rozsahu funkčností, tak v neposlední řadě v kvalitě a přehlednosti vlastního prostředí. Metodicky lze správu ITS v ČR pojmout tak, že prostřednictvím rozhraní pro správu databáze ITS architektury lze přijímat požadavky na dílčí změny určitých oblastí architektury. Tyto požadavky mohou přicházet i ze strany samotných uživatelů ITS architektury. Každý takový přijatý požadavek bude diskutován a v případě, že bude relevantní, tak správce databáze může tento požadavek postoupit do dalšího kola diskuze mezi členy týmu starajícího se o ITS architekturu ČR. V poslední fázi dojde k samotnému zapracování požadavku buď v jeho původní podobě či ve formě, která se procesem integrace do architektury ustálila. Jedná se tedy ve své podstatě o koordinované zpracování pozměňovacích návrhů na úrovni správce ITS architektury. 8

9 3. Metodika využití ITS architektury při návrhu telematických aplikací 3.1. Metodika využití ITS architektury Metodika využití ITS architektury je založena na znalosti vstupních podmínek, na základě kterých hodláme do návrhu ITS systému vstupovat. Tyto vstupní podmínky jsou určeny následujícími elementy: uživatelské potřeby platné standardy a normy, které se dotýkají oblasti návrhu ITS systému informační architektura ITS systému funkční architektura ITS systému fyzická architektura ITS systému Mimo jiné je nutné také připomenout, že podstatná je i znalost vnějšího okolí navrhovaného ITS systému. Toto okolí je tvořeno tzv. terminátory a přenosem informací mezi terminátory a ITS systémem. Ukázkou typického terminátoru je Řidič. Terminátor Řidič reprezentuje lidskou bytost, která je oprávněna k řízení registrovaného dopravního prostředku na dopravní síti. Terminátor Řidič zahrnuje řidiče individuálního osobního vozidla, nákladního vozidla, vozidla veřejné dopravy či vozidla bezpečnostních a záchranných složek. Terminátor Řidič iniciuje žádost a získává informace od ITS systému. Uspořádání terminátorů v ITS architektuře je hierarchické. Na příkladu Řidiče lze ukázat tyto podřazené terminátory: Řidič pohotovostního vozidla - terminátor reprezentující řidiče oprávněného pro řízení pohotovostního vozidla. Řidič nákladního vozidla - terminátor reprezentující řidiče, který má oprávnění k řízení nákladního vozidla. Řidič vozidla přepravující nebezpečný náklad - terminátor reprezentující osobu pověřenou k řízení vozidla přepravujícího nebezpečný náklad. Řidič osobního vozidla - terminátor reprezentující osobu mající oprávnění řídit osobní vozidlo. Řidič vozidla veřejné dopravy - terminátor reprezentující řidiče, majícího oprávnění k řízení vozidla veřejné dopravy. 9

10 Obr 1: Kontextový diagram Každý terminátor je v ITS architektuře, kromě své pozice vůči ostatním terminátorům, charakterizován také svými vstupními a výstupními datovými toky. Prvním krokem při definici vstupních podmínek je definice a popis uživatelských potřeb kladených na ITS systém. Uživatelské potřeby jsou podobně jako terminátory v ITS architektuře zachyceny hierarchicky. ITS architektura definuje okolo 160 hlavních uživatelských potřeb. Uživatelská potřeba je v podstatě mapování určitých funkcí ITS architektury do jednoho elementu tzv. uživatelské potřeby. Použití uživatelských potřeb pro návrh ITS systému je základem metodiky využití ITS architektury pro návrh ITS systémů a většina zahraničních architektur inteligentních dopravních systémů vychází právě z tohoto přístupu. Uživatelské potřeby totiž představují jakousi konkretizaci obecného návrhu ITS architektury a napomáhají k usnadnění procesu návrhu ITS systému. Následujícím krokem při definici vstupních podmínek pro návrh ITS systému je popis funkční a informační architektury systému. Jak již bylo předesláno, funkční architektura je již v tomto kroku téměř určena právě definicí uživatelských potřeb. Nyní přišel okamžik pro možná zjemnění výběru funkcí z množiny dané uživatelskými potřebami odstraňováním nepotřebných nebo nadbytečných funkcí nebo naopak přidáním scházející funkcionality. Než se přejde k dalšímu kroku, kterým je popis informační architektury je dobré si uvědomit, jak vlastně tento proces návrhu vstupních podmínek při pohledu z vnějšku vypadá. Nejprve jsme architekturu zjednodušili nástrojem v podobě uživatelských potřeb. Nástrojem, kterým jsme snížili stupeň abstrakce formou slučování funkcí ve větší skupiny a následně interpretací 10

11 významu těchto skupin. V následných krocích však tyto celky dekomponujeme v jednotlivé funkce, přestáváme vnímat interpretaci uživatelských potřeb, jako tomu bylo na začátku návrhu podmínek, ale postupně vnímáme větší a složitější detaily návrhu. Měníme rozlišovací úroveň a skrze tuto optiku vnímání se zpětně vracíme k ITS architektuře se vší obecností a abstrakcí. Dalším článkem v procesu návrhu je popis informační architektury. Platí stejné zákonitosti, stejné relace. Vztah informační a funkční architektury je analogický ke vztahu funkční architektury a uživatelských potřeb. Opět zde máme mapování funkcí na příslušné datové toky. Analogickým postupem odstraňování respektive přidávání nepotřebných respektive scházejících datových toků dochází k dalšímu zjemňování optiky, pod kterou vytváříme podmínky pro návrh ITS systému Popis uživatelských potřeb Na zjednodušeném příkladu návrhu ITS systému placení mýta si budeme ilustrovat postup popisu uživatelských potřeb. Systém placení mýta umožňuje aplikaci nejrůznějších metod zpoplatnění pomocí různých platebních technologií, přičemž zaplacení poplatku může probíhat za jízdy. Každou transakci doprovází zpětná vazba, upozorňující na současný stav zákazníkova účtu. Záznam o platbě je zasílán systému správy mýtného, který musí potvrdit její správnost a na tomto podkladě zákazníkovi zasílá v pravidelných intervalech detailní výpisy proběhlých transakcí. Systém správy mýtného zajišťuje platby a řídí elektronický převod z ověřených finančních zdrojů zákazníka k operátorovi dopravně-přepravního systému. Tento systém umožňuje registraci cestujících/řidičů a podporuje různé druhy elektronických plateb za dopravní služby v rámci již existujících. Systém odešle informaci o transakci na zákazníkovo konto a obdrží fakturu (pro dodatečnou platbu), tzn. na účet finanční instituce se připíše částka, která byla odečtena jako úhrada ze zákazníkova konta. Předpokladem zajištění těchto operací je komunikace se systémem výběru mýta. Systém dále určuje a spravuje strukturu zpoplatnění a ve spolupráci se systémem managementu řízení dopravy zajišťuje uplatňování politiky zpoplatnění dopravní infrastruktury. Elektronické finanční transakce, v nichž tento systém hraje roli prostředníka mezi zákazníkem a finanční institucí, budou vedeny jako přísně důvěrné. Ze seznamu uživatelských potřeb, které jsou v ITS architektuře uvedeny provedeme výběr podle našich požadavků, které klademe na požadovaný ITS systém (vždy je uvedeno číslo uživatelské potřeby a její popis): Systém bude schopen využívat celou škálu platebních metod, buď elektronických nebo manuálních, včetně využití centrálního účtu spolu s pozdními 11

12 platbami (post-payment), centrálního účtu na bázi předplatného, účtu ve vozidle, atd Systém bude spravovat údaje o zákazníkovi (jako jsou identifikace zákazníka, jeho práva, údaje týkající se účtu atd.) a z těchto údajů bude vycházet při sestavování podmínek kontraktu Systém bude mít minimální dopad na plynulost silničního provozu, tzn. doba transakce bude omezená Systém bude klást na řidiče za jízdy minimální nároky Systém nebude ohrožovat bezpečnost cestujících ve vozidle ani obsluhu v blízkosti zařízení, například obsluhu boxů pro vybírání mýtného A - Služba zajišťuje transakční zpracování dat, a to i v průběhu nasazení záložních zdrojů. Tímto je zaručena integrita elektronických finančních transakcí A - Systém podá cestujícímu veškeré informace o transakci v konkrétním čase a bude schopen je zaslat zpět (na základě přístupového kódu) A - Systém bude vydávat potvrzení o zaplacení a registrovat údaje související s využitím služeb Systém bude zajišťovat vzájemnou výměnu informací mezi stanicí pro výběr mýtného a vozidlem Počet nesprávných transakcí provedených systémem bude minimální (např. pravděpodobnost nepřesné transakce je nižší než 10e-6, pravděpodobnost chybné transakce je nižší než 10e-8) 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.) Systém bude shromažďovat průkazné důkazy o nezaplacení mýtného i jiných nelegálních finančních transakcích A - Systém umožní rozdělení příjmů mezi několik operátorů A - Systém umožní souhrnnou platbu za služby poskytnuté několika vzájemně propojenými dopravními systémy A - V kontrolním uzlu systém umožní (někdy automaticky) výběr z konkurenčních nabídek. 12

13 4.1.8-A - Systém bude zajišťovat výměnu informací o transakcích s finančními institucemi, aby tak umožnil realizaci plateb Popis funkční architektury systému Výběr uživatelských potřeb nám definuje množinu funkcí z funkční architektury ITS. Definice makrofunkcí byla provedena v rámci projektu KAREN, kde bylo definováno osm základních makrofunkcí. V rámci projektu ACTIF byla přidána devátá makrofunkce týkající se dopravně-přepravních databází. Každou makrofunkci je možno dále dekomponovat na funkce, podfunkce. Obr 2: Dekompozice makrofunkce Na níže uvedeném diagramu je hierarchická struktura použitých funkcí v našem ukázkovém příkladu návrhu ITS systému. 13

14 Obr 3: ITS systém výběru elektronického mýta 14

15 Funkční architektura je relačně svázána s datovým registrem, o kterém se zmíním v následujících kapitolách. ITS datový registr přiřazuje elementům ITS architektury konkretní informace o aplikacích vybudovaných na základě použití vybraných funkcí, včetně technického řešení těchto aplikací, organizačního zajištění, informací o tvůrcích a správcích již realizovaných projektů Popis informační architektury Informační architektura zachycuje vzájemné informační vazby mezi jednotlivými makrofunkcemi, funkcemi, podfunkcemi vlastního ITS systému včetně informačních vazeb jednotlivých makrofunkcí, funkcí, podfunkcí s jednotlivými terminátory ITS systému. V současné době můžeme zaznamenat v ITS architektuře na 1600 datových toků. Datové toky nejsou uspořádány hierarchicky jako jsou funkce nebo uživatelské potřeby. Pro datové toky byla vytvořena jednoduchá pravidla jejich pojmenovávání. Podle těchto pravidel lze již ze samotného názvu datového toku usoudit v jaké oblasti ITS architektury se uplatňuje, odkud vystupuje a kam vstupuje. Dokonce je názvoslovím podchycen i typ elementu do kterého resp. ze kterého vystupuje. Datové toky totiž můžeme pozorovat nejen mezi funkcemi na nejrůznějších úrovních, ale i mezi funkcemi a terminátory. Konvence značení datových toků je následující: zkr1.zkr2_popis, kde zkr1 je zkratkou zdroje informační vazby, zkr2 je zkratkou cíle informační vazby a popis charakterizuje krátkou identifikaci informační vazby. Zkratky názvů terminátorů jsou tvořeny vždy třemi písmeny, zkratky makrofunkcí jsou tvořeny vždy dvěma písmeny. Pro ilustraci jsou v následující tabulce uvedeny zkratky makrofunkcí, základních kamenů ITS architektury. Makrofunkce zkratka 1. Elektronické vybírání poplatků ep 2. Zabezpečení bezpečnostních a záchranných služeb zs 3. Management dopravy md 4. Management veřejné osobní dopravy vd 5. Podpora řízení vozidla rv 6. Poskytování cestovních informací ci 7. Podpora dohledu pd 8. Management nákladní dopravy nd 9. Dopravně-přepravní databáze db 15

16 Následující diagram zobrazuje informační vazby mezi jednotlivými makrofunkcemi a terminátory ITS systému. Obr 4: Diagram informačních vazeb mezi makrofunkcemi 16

17 Vrátíme-li se k našemu ilustračnímu příkladu ITS systému elektronického mýta, pak po výběru a selekci funkcí se v našem systému uplatní 65 datových toků. Datové toky pro architekturu nemusí mít pouze význam znázornění směru toku informací a obecný obsah přenášené informace. Mohou se stát základním prvkem ve složitém přechodu od statického pojetí ITS architektur. Ve většině zemí, kde byly národní architektury zpracovávány a budovány, se vývoj zastavil právě před důležitou fází přechodu k tzv. dynamické architektuře inteligentních dopravních systémů. Důležitou roli v tomto přechodu hrají datové toky právě z důvodu jejich možné parametrizace. Využitím jejich vlastnosti, kterou je přenos informace a tudíž vyjádřením vzájemného vztahu mezi jednotlivými elementy, lze vhodnou parametrizací těchto vazeb dosáhnout dynamického přístupu. Parametrizace je proveditelná v obecné rovině a lze přiřazovat libovolné typy parametrů od vyjádření účinnosti přenosu informace až po ekonomické vyjádření efektivity existence daných funkcí či terminátorů v systému. Navíc se zde nabízí myšlenka realizace ITS architektury prostřednictvím Petriho sítí. Navíc i interpretace přechodů a míst nemusí být statická a lze si představit paralelně několik Petriho sítí, různě interpretované ITS architektury. Níže uvedený přehled příkladů má jednotnou strukturu. V úvodu je představen projekt, jeho název a stručný popis. Následuje detailní rozpis uživatelských potřeb ve formě tabulkového výpisu. Ke většině uživatelských potřeb je také přiložen hierarchický diagram ilustrující grafickou formou strukturu uživatelské potřeby. Při budování ITS systému by byla provedena v dalším kroku redukce nadbytečných funkcí. K tomuto kroku je však nutná poměrně detailní představa o nově bodovém ITS systému, a proto od tohoto detailního řešení upustíme. Na závěr každého příkladu je uvedeno shrnutí všech použitých funkcí, které byly vybrány skrze uživatelské potřeby. Toto shrnutí je opět formou přehledné stromové struktury funkcí ITS architektury Pilotní projekty Monitorování dopravní infrastruktury a řízení dopravy - pilotní vybavení silničního tunelu ITS systémy. Projekt je zaměřen na dobudování telematických aplikací v silničním tunelu Hřebeč. Jedná se o tunel dlouhý cca 580 m na silnici I/35 (E 442), která slouží pro tranzitní dopravu jako alternativa k dálnici D1 a je vedena severní částí ČR, s denní intenzitu cca voz/den (3 500 nákladních/den). Cílem projektu je zařazení tohoto tunelu, po stránce vybavení, mezi evropské standardy a zajistit tak řidičům komfortní a bezpečný průjezd. Tunel 17

18 nebude mít svůj lokální velín, ale informace budou přeneseny do vzdáleného dispečinku a odtud bude probíhat nezbytné řízení a informování. Uživatelská potřeba Systém umožňuje sběr dopravních dat, pro silniční síť používá analýzy a prognózy Sběr dopravních dat Sledování parkovacích kapacit Správa dopravních dat Řízení dopravním zařízením Sledování stavu dopravy 4.1 Sledování vozidlového parku veřejné osobní dopravy Odhad parametrů vozidla Uživatelská potřeba Systém neumožní provést cokoli, co může vést ke snížení bezpečnosti Řízení dopravním zařízením Výstupní ovládání/informace Uživatelská potřeba A Systém umožní dopravnímu centru, operátorovi řídit, (dálkovým ovládáním), jednotlivé dopravní značení nebo celé skupiny dopravních značení (jako pouliční světla, Proměnné znakové zprávy,...) 3.1 Dopravní řízení Řízení dopravním zařízením Výstupní ovládání/informace Operátorský vstup 18

19 Uživatelská potřeba Systém by měl poskytovat řídící a kontrolní hodnoty pro znečištění v tunelech, tj. vozidlová překážka, detekce požáru, znečištění ovzduší a uzavírky. 3.6 Management mostů a tunelů Stav tunelu Vstup operátora pro řízení tunelů a mostů Výstupní informace - tunel Uživatelská potřeba A Služba umožní kdykoli převzít ruční řízení operátorovi. 3.1 Dopravní řízení Řízení dopravním zařízením Operátorský vstup 3.6 Management mostů a tunelů Vstup operátora pro řízení tunelů a mostů Uživatelská potřeba Systém bude schopen omezit detekci mimořádné události na minimum. 2.1 Řízení tísňové či krizové situace 3.2 Management nehodových/krizových událostí Detekce události Identifikace a klasifikace události 19

20 Uživatelská potřeba Systém bude schopen ověřit, zda skutečně došlo k nehodě, a tím eliminovat falešný poplach Identifikace a klasifikace nehod Zpracování informací o nehodách Sdílení dat během záchranné akce 3.2 Management nehodových/krizových událostí Identifikace a klasifikace události Uživatelská potřeba Systém je schopen navrhnout jeden nebo více postupů při zpracování dopravní událostí Plánování záchranných akcí 3.2 Management nehodových/krizových událostí Ocenění události a stanovení odezvy Uživatelská potřeba Systém bude schopen vybírat poplatky za užívání úseků cest, mostů či tunelů aj., na základě určitých výnosů (např. vyhláška o zpoplatnění). 1.6 Management tarifů a přístupových práv 3.3 Řízení poptávky Realizace strategie řízení poptávky 20

21 Obr 5: Celkové shrnutí použitých funkcí v řešeném příkladu. 21

22 Dopravně-informační centrum města Prahy a středočeského kraje. Projekt řeší realizaci nadstavby nad stávajícími diverzifikovanými systémy řízení v Praze a ve Středočeském kraji. Cílem je vytvoření jednotného informačního prostředí, které sbírá data a informace z dopravy a informace ekologické. Tyto informace jsou převedeny do jednotného databázového prostředí, které bude pro tento účel vytvořeno. Hlavním výstupem projektu je vytvoření integrujícího dopravně informačního centra, které bude poskytovat informace o situaci v regionu Prahy a Středočeského kraje pro uživatele komunikací, pro příslušné úřady a hlavně pro regionální centra v sousedních krajích a zemích, takže bude možné reagovat na dopravní, resp. Ekologickou situaci směrováním vozidel na jiné trasy. Vytváří se tak základ pro přeshraniční spolupráci ve středoevropském regionu. Uživatelská potřeba Systém umožňuje sběr dopravních dat, pro silniční síť používá analýzy a prognózy Sběr dopravních dat Sledování parkovacích kapacit Správa dopravních dat Řízení dopravním zařízením Sledování stavu dopravy 4.1 Sledování vozidlového parku veřejné osobní dopravy Odhad parametrů vozidla Uživatelská potřeba Systém bude schopen všem řidičům podat informaci o omezení silničního provozu, trvání cesty atd. 6.2 Plánování cesty Výběr a definice rezervace 6.3 Podpora cesty Informování a vedení uživatele 22

23 Uživatelská potřeba Systém bude poskytovat operátorům informace o řízení. 6.2 Plánování cesty Operátorské rozhraní (GTP) 6.3 Podpora cesty Rozhraní pro operátora cestovních informací Uživatelská potřeba Systém bude schopen podat informaci spojenou s jinými dopravními mody, např. jízdním řádu veřejné dopravy, odstavných parkovištích (P&R) apod. 6.2 Plánování cesty Návrh alternativní cesty Plánování multi-modální cesty Uživatelská potřeba Systém bude schopen shromažďovat a ukládat údaje o každé nehodě, např. bude registrovat místo, druh a závažnost nehody, počet a typ zúčastněných vozidel, potřebný počet a typ pohotovostních vozidel atd Identifikace a klasifikace nehod Zpracování informací o nehodách Plánování záchranných akcí 3.2 Management nehodových/krizových událostí Identifikace a klasifikace události Zpracování dat o událostech 23

24 Uživatelská potřeba Systém umožní řídit silniční dopravu takovým způsobem, že environmentální hodnoty (tj. ovzduší a hluk) znečištění mohou být redukovány. 3.1 Dopravní řízení Řízení dopravním zařízením Poskytování řízení dopravy 3.4 Poskytnutí informací o prostředí Správa dat o prostředí Uživatelská potřeba Systém bude schopen poskytnout cestovní informaci o jiných dopravních modech, jednak v zájmu rozšíření nabídky, jednak pro případ vzniku neobvyklé situace, např. stávky, sportovní či kulturní akce, za nepříznivých povětrnostních podmínek atd. 6.2 Plánování cesty Návrh alternativní cesty Uživatelská potřeba Systém bude poskytovat aktualizované dopravní a cestovní informace na úrovni místní, regionální, státní i zahraniční. 6.2 Plánování cesty Návrh alternativní cesty Uživatelská potřeba Systém poskytne cestovní informace, které mohou obsahovat ceny, jízdné, incidenty, dopravní práce, předpovědi a nynější dopravní situace, řízení dopravy, požadavky řízení, místní varování, zvláštní události, povětrnostní podmínky, hotely atd. 24

25 3.1.5 Řízení dopravním zařízením Poskytování řízení dopravy Výstupní ovládání/informace 3.4 Poskytnutí informací o prostředí Správa dat o prostředí 6.2 Plánování cesty Návrh alternativní cesty Výběr a definice rezervace 6.3 Podpora cesty Určení mimořádné události Uživatelská potřeba A Pro konkrétní destinace bude systém schopen doporučit cestujícím trasu v kombinaci různých dopravních modů. 6.2 Plánování cesty Návrh alternativní cesty Uživatelská potřeba A Systém bude schopen poskytnout informace spojené s cestováním (hotely, turistické informace atd.) 6.2 Plánování cesty Definice základních kritérií Návrh informací souvisejících s cestou 25

26 Uživatelská potřeba Systém bude schopen cestujícího informovat o běžné průměrné jízdní době mezi dvěma pevně stanovenými body Výběr a definice rezervace 6.3 Podpora cesty Informování a vedení uživatele Uživatelská potřeba Systém bude zajišťovat informace týkající se aktuální situace na odstavných parkovištích (P&R) a v parkovacích terminálech. 6.2 Plánování cesty Návrh alternativní cesty 6.3 Podpora cesty Informování a vedení uživatele Uživatelská potřeba Systém by měl být schopen předpovídat krátko, středně a dlouhodobé cesty produkující zátěž na životní prostředí (atmosférické a hlukové) zatížení v důsledku dopravy a počasí. 3.4 Poskytnutí informací o prostředí Předpověď vlivu na životní prostředí Uživatelská potřeba Systém umožnuje nalézt a identifikovat záchranná vozidla v dopravní síti Řízení záchranného vozidla 26

27 Obr 6: Celkové shrnutí použitých funkcí v řešeném příkladu. 27

28 Dopravní informační stojany použitelné nevidomými a slabozrakými Ve spolupráci s organizací ROPID - Regionálním organizátorem Pražské integrované dopravy, bude v roce 2003 dokončeno propojení vlakové a autobusové dopravy včetně zobrazení poznámek k vyhledaným spojením. Pro použití informačního stojanu nevidomými bude jeho ovládání prováděno 6-ti tlačítky, umístěnými na těle stojanu nebo povely vysílače nevidomých VPN01. Hlasový výstup v češtině a angličtině bude kombinací namluvených sekvencí s generovaným hlasovým výstupem na reproduktorech, umístěných v těle stojanu. Samoobslužné informační stojany jsou v současnosti využívány na mnoha místech ČR. Software pracuje pod všemi operačními systémy MS Windows a umožňuje vyhledávat optimální spojení až v 6-ti různých kategoriích doprav - autobusové, vlakové, letecké ČSA a v několika MHD. Vyhledávání spojení respektuje samozřejmě časová omezení, umožňuje vyhledávat spojení předchozí i následující. Aktualizovaná data jsou stahována jednotlivými uživateli z internetových stránek Celostátního informačního systému jízdních řádů, garantovaným ČR. Samoobslužné stojany nejsou v současnosti vybaveny žádnými prostředky, umožňujícími jejich nezávislé použití nevidomými a slabozrakými osobami. Přizpůsobení nejnovějších informačních stojanů spolu se softwarem Dopravního Informačního Systému je v současné době navrženo a bylo po připomínkách odsouhlaseno Sjednocenou organizací nevidomých a slabozrakých (SONS). Uživatelská potřeba Systém umožňuje sběr dopravních dat, pro silniční síť používá analýzy a prognózy Sběr dopravních dat Sledování parkovacích kapacit Správa dopravních dat Řízení dopravním zařízením Sledování stavu dopravy 4.1 Sledování vozidlového parku veřejné osobní dopravy Odhad parametrů vozidla 28

29 Uživatelská potřeba Systém bude poskytovat informace v podobě grafického znázornění či textu. Grafická forma bude tedy disponovat jak mapou, tak i textem Plánování multi-modální cesty Tvorba cestovního itineráře Uživatelská potřeba Systém bude schopen cestujícího informovat o běžné průměrné jízdní době mezi dvěma pevně stanovenými body Výběr a definice rezervace 6.3 Podpora cesty Informování a vedení uživatele Uživatelská potřeba Systém bude poskytovat cestujícím popis doporučených tras do blíže určených destinací. 29

30 6.2 Plánování cesty Plánování multi-modální cesty Tvorba cestovního itineráře 6.3 Podpora cesty Informování a vedení uživatele Uživatelská potřeba Systém bude schopen poskytnout cestovní informaci o jiných dopravních modech, jednak v zájmu rozšíření nabídky, jednak pro případ vzniku neobvyklé situace, např. stávky, sportovní či kulturní akce, za nepříznivých povětrnostních podmínek atd. 6.2 Plánování cesty Návrh alternativní cesty Uživatelská potřeba Systém bude poskytovat aktualizované dopravní a cestovní informace na úrovni místní, regionální, státní i zahraniční. 6.2 Plánování cesty Návrh alternativní cesty Uživatelská potřeba Systém poskytne cestovní informace, které mohou obsahovat ceny, jízdné, incidenty, dopravní práce, předpovědi a nynější dopravní situace, řízení dopravy, požadavky řízení, místní varování, zvláštní události, povětrnostní podmínky, hotely atd Řízení dopravním zařízením Poskytování řízení dopravy Výstupní ovládání/informace 3.4 Poskytnutí informací o prostředí Správa dat o prostředí 30

31 6.2 Plánování cesty Návrh alternativní cesty Výběr a definice rezervace 6.3 Podpora cesty Určení mimořádné události Uživatelská potřeba A Pro konkrétní destinace bude systém schopen doporučit cestujícím trasu v kombinaci různých dopravních modů. 6.2 Plánování cesty Návrh alternativní cesty Uživatelská potřeba A Systém bude schopen poskytnout informace spojené s cestováním (hotely, turistické informace atd.) 6.2 Plánování cesty Definice základních kritérií Návrh informací souvisejících s cestou Uživatelská potřeba Systém bude poskytovat informace o zrušených letech, odjezdech vlaků, autobusů a lodí (z důvodu stávky, na základě nepříznivých povětrnostních podmínek aj.). 6.2 Plánování cesty 31

32 6.2.3 Návrh alternativní cesty 6.3 Podpora cesty Určení mimořádné události Uživatelská potřeba V místě výstupu poskytne systém informaci, buď v národním jazyce nebo v jakémkoli cizím jazyce, který si uživatel zvolí Definice základních kritérií Návrh alternativní cesty Výběr a definice rezervace Plánování multi-modální cesty Provedení rezervace a platby Určení mimořádné události Informování a vedení uživatele Uživatelská potřeba Systém bude poskytovat cyklistům a pěším informace o vhodných trasách. 6.2 Plánování cesty Definice cestovních dat Výběr a definice rezervace 6.3 Podpora cesty Informování a vedení uživatele 32

33 Obr 7: Celkové shrnutí použitých funkcí v řešeném příkladu. 33

34 Poskytování informací o dopravním spojení pro nevidomé a těžce zrakově postižené občany Aplikace pro poskytování informací o dopravním spojení provozovaná na internetové adrese bude upravena tak, aby mohla být využívána nevidomými a jinak těžce zrakově postiženými občany. Pro nevidomé a jinak těžce zrakově postižené občany bude upravená aplikace k dispozici na adrese Úpravy budou realizovány v souladu s projektem občanského sdružení Sjednocená organizace nevidomých a slabozrakých České republiky (SONS) - Blind Friendly Web a standardy vydanými mezinárodním konsorciem W3C, vydávajícím normy v oblasti internetových technologií. Uživatelská potřeba A Systém umožní sdílení informací dopravním manažerům a úřadům. 3.1 Dopravní řízení Správa dopravních dat 3.2 Management nehodových/krizových událostí Zpracování dat o událostech 4.3 Zajištění správy veřejné osobní dopravy Zpracování údajů o provozu veřejné dopravy 9.1 Vyhledávání v databázi 9.2 Zpracování dat 9.3 Správa přístupu do databáze Uživatelská potřeba A Cestujícím hromadné veřejné dopravy bude systém podávat průběžně aktualizované informace o cestě. 6.2 Plánování cesty Návrh alternativní cesty 34

35 6.3 Podpora cesty Informování a vedení uživatele Uživatelská potřeba Systém bude schopen cestujícího informovat o běžné průměrné jízdní době mezi dvěma pevně stanovenými body Výběr a definice rezervace 6.3 Podpora cesty Informování a vedení uživatele Uživatelská potřeba AS Systém bude schopen uložit podrobnosti zákazníkova požadavku nezávisle na jiném fyzickém výstupním zařízení. 6.1 Nastavení a definice cesty Uživatelská potřeba Systém bude poskytovat cestujícím popis doporučených tras do blíže určených destinací. 6.2 Plánování cesty Plánování multi-modální cesty Tvorba cestovního itineráře 6.3 Podpora cesty Informování a vedení uživatele 35

36 Uživatelská potřeba Systém bude schopen předem vypočítat předpokládanou dobu jízdy po zvolené trase. 6.2 Plánování cesty Návrh alternativní cesty Plánování multi-modální cesty Tvorba cestovního itineráře Obr 8: Celkové shrnutí použitých funkcí v řešeném příkladu. 36

37 Clearingové centrum veřejné osobní dopravy Cílem je vytvořit prostředí, které umožní křížové používání bezdotykových čipových karet s nahranou elektronickou peněženkou mezi dopravci, tzn. že zákazník bude mít jen jednu jedinou kartu, kterou bude používat u všech participantů tohoto prostředí. Součástí prostředí je: unifikovaná sada bezpečnostních klíčů umožňující čtení karet vydaných různými dopravci unifikovaná podoba aplikace elektronické peněženky clearingové centrum, které na základě zpracování transakcí z jednotlivých akceptačních míst (tj. míst, kde lze elektronickou peněženku dobít či s ní zaplatit) určí, jaké částky si mají jednotliví dopravci přeúčtovat díky tomu, že cestující může zaplatit za jízdu v dopravním prostředku jednoho dopravce elektronickou peněženkou, kterou si nabil u jiného dopravce. Clearingové centrum bude též podporovat různé bezpečnostní mechanizmy (distribuce seznamu zakázaných karet, hlídání návaznosti zůstatků karet vzhledem k transakcím atd.) V pilotním projektu jde o zapojení dvou dopravních společností, které jsou již dnes vybaveny těmito kartami a každý samostatně nabízí možnost nahrát si na ni elektronickou peněženku. Dále jde též o zapojení železnice, která bude figurovat pouze v roli akceptátora elektronických peněženek, nebude tedy umožňovat jejich dobití ani ve vlacích ani na nástupištích. Uživatelská potřeba Systém bude schopen využívat celou škálu platebních metod, buď elektronických nebo manuálních, včetně využití centrálního účtu spolu s pozdními platbami (post-payment), centrálního účtu na bázi předplatného, účtu ve vozidle, atd. 1.1 Uzavření kontraktu Uzavření elektronického kontraktu 1.2 Správy kont uživatelů Aktuální stav uživatelského konta Odečtení platby z uživatelského konta 1.3 Elektronické transakce Kontroly kontraktu Výpočet poplatku za službu Provedení platby 1.4 Příjmy operátorům Rozdělení příjmů 1.5 Zabezpečení proti chybám systému Detekce narušitele platby Detekce narušitele Vozidlové jednotky elektronických transakcí 37

38 5.8 Integrace vozidla v dopravním systému Uživatelská potřeba Systém bude spravovat údaje o zákazníkovi (jako jsou identifikace zákazníka, jeho práva, údaje týkající se účtu atd.) a z těchto údajů bude vycházet při sestavování podmínek kontraktu. 1.1 Uzavření kontraktu Uzavření elektronického kontraktu Přehled kontraktů 1.2 Správy kont uživatelů Aktuální stav uživatelského konta Odečtení platby z uživatelského konta Informace o transakcích a věrnostních programech 1.3 Elektronické transakce Identifikace uživatele Kontroly kontraktu Informace a návody Výpočet poplatku za službu Kontrola platby Provedení platby 1.4 Příjmy operátorům Informování operátorů o transakcích 1.5 Zabezpečení proti chybám systému Kontrola uživatelů Detekce narušitele platby Detekce narušitele 1.6 Management tarifů a přístupových práv Management přístupových práv 38

39 Uživatelská potřeba A Služba zajišťuje transakční zpracování dat, a to i v průběhu nasazení záložních zdrojů. Tímto je zaručena integrita elektronických finančních transakcí. 1.1 Uzavření kontraktu Uzavření elektronického kontraktu Přehled kontraktů 1.2 Správy kont uživatelů Aktuální stav uživatelského konta Odečtení platby z uživatelského konta Informace o transakcích a věrnostních programech 1.3 Elektronické transakce 39

40 1.3.4 Informace a návody Výpočet poplatku za službu Kontrola platby Provedení platby 1.4 Příjmy operátorům Rozdělení příjmů Platby na konta operátorů 1.5 Zabezpečení proti chybám systému Detekce narušitele platby Detekce narušitele Uživatelská potřeba A Systém podá cestujícímu veškeré informace o transakci v konkrétním čase a bude schopen je zaslat zpět (na základě přístupového kódu). 1.1 Uzavření kontraktu Uzavření elektronického kontraktu 1.2 Správy kont uživatelů Aktuální stav uživatelského konta Odečtení platby z uživatelského konta Informace o transakcích a věrnostních programech 40

41 1.3 Elektronické transakce Provedení platby Uživatelská potřeba A Systém bude vydávat potvrzení o zaplacení a registrovat údaje související s využitím služeb. 1.3 Elektronické transakce Provedení platby Uživatelská potřeba Počet nesprávných transakcí provedených systémem bude minimální (např. pravděpodobnost nepřesné transakce je nižší než 10e-6, pravděpodobnost chybné transakce je nižší než 10e-8). 1.1 Uzavření kontraktu Uzavření elektronického kontraktu Přehled kontraktů 1.2 Správy kont uživatelů Aktuální stav uživatelského konta Odečtení platby z uživatelského konta Informace o transakcích a věrnostních programech 1.3 Elektronické transakce Identifikace uživatele Kontroly kontraktu Výpočet poplatku za službu Kontrola platby Provedení platby 1.4 Příjmy operátorům Rozdělení příjmů Platby na konta operátorů 1.5 Zabezpečení proti chybám systému Detekce narušitele platby 41

42 1.5.3 Detekce narušitele Uživatelská potřeba Systém by měl poskytovat cestujícímu cenu jízdného (za cestu) před tím než dojde k akceptaci této služby tak, jak je nabízena (pokud se nejedná o službu zdarma). 4.3 Zajištění správy veřejné osobní dopravy Management sdílení dopravního prostředku Uživatelská potřeba A Systém umožní rozdělení příjmů mezi několik operátorů. 42

43 1.1 Uzavření kontraktu Uzavření elektronického kontraktu 1.4 Příjmy operátorům Rozdělení příjmů Platby na konta operátorů Uživatelská potřeba 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). 1.5 Zabezpečení proti chybám systému Detekce narušitele platby Detekce narušitele Uživatelská potřeba A Systém bude uskutečňovat věrnostní programy (dopravní či další služby?). 1.2 Správy kont uživatelů Informace o transakcích a věrnostních programech Uživatelská potřeba Systém bude schopen upravovat jízdné veřejné hromadné dopravy dle dohodnuté cenové strategie. 1.6 Management tarifů a přístupových práv Řízení dopravním zařízením Poskytování řízení dopravy Výstupní ovládání/informace 3.3 Řízení poptávky Realizace strategie řízení poptávky 43

44 Uživatelská potřeba Systém poskytne spojení mezi operátorem vozového parku a příslušnými institucemi v oblasti přenosu a registrace dat a plateb. 8.2 Řízení dop. prostředků dopravců Řízení dopravních operací Řízení zdrojů dopravce Řízení dopravních prostředků a vybavení 44

45 Obr 9: Celkové shrnutí použitých funkcí v řešeném příkladu. 45

46 Dopravně-řídící centrum Ostrava Pilotní projekt dopravně řídicího centra (DŘC) s krajskou působnosti na MSK (Moravskoslezský kraj) logicky navazuje na podobná řídící centra na trase VI. multimodálního koridoru, kterým bude zajišťována dopravní komunikace mezi regiony a členskými státy a taktéž podpora telematickým informačním systémům v dopravních sítích MSK. Předmětem řešení projektu je integrace stávajících informačních systémů v městských a státních organizacích (dopravní podniky, správci silnic, podniky technických služeb) a následně v dopravních společnostech na území MSK do jednoho místa DŘC. Na tomto řídícím místě bude prováděna správa rozsáhlé databáze dopravních informací od státních a samosprávných orgánů, městských a státních podniků, odkud se budou distribuovat požadovaná data prostřednictvím internetu, operátorů mobilních přístrojů a ostatních informačních systémů všem uživatelům dopravy. Důležitou funkci bude DŘC plnit rovněž v předávání on-line dopravních informací pracovišti integrovaného záchranného systému v Ostravě (Centrum tísňového volání). Zřízením DŘC se rovněž vytváří podmínky pro: zvýšení bezpečnosti městského silničního provozu, zmírnění negativních účinků v dopravě na životní prostředí ve městě, zvýšení efektivnosti dopravy i kapacity na přetížených úsecích, zlepšování kvality poskytovaných služeb v dopravě, zmírnění negativních účinků dopravy na životní prostředí, snižování časových ztrát způsobených kongescemi, zavádění integrovaného systému řízení dopravy ve městech, optimalizace návrhu přestupních uzlů integrované osobní veřejné dopravy a podpora integrovaných systémů osobní veřejné dopravy, telematická podpora rozvoje dopravně-zbožových center v regionech, podpora integrovanému řízení bezpečnosti a ochrany MSK, čímž se naplňuje Regionální operační program MSK pro nové dopravní projekty. Uživatelská potřeba Systém by měl být schopen tvořit statistiku údržby pro užívanou cestu, kerá bude ohodnocovat potřeby (náklady) prováděné údržby 3.5 Management silniční údržby Údržba v dlouhém čase 46

47 3.5.6 Sběr dat o údržbě Uživatelská potřeba Systém může být schopen monitoringu životního prostředí s funkcí archivace těchto dat (ovzduší a hluk) exhalace a upozorňuje na překročení prahových hodnot. 3.4 Poskytnutí informací o prostředí Sledování hluku Uživatelská potřeba Systém by měl být schopen měřit viditelnou vzdálenost a detekovat snížení viditelnosti z důvodu zhoršeného počasí a znečištění (nikoliv z důvodu setmění) 3.4 Poskytnutí informací o prostředí Sledování znečištění ovzduší Uživatelská potřeba A Systém bude schopen pracovat v reálném čase s daty nebo předpovídat situace s odpovídajícími historickými daty. 3.1 Dopravní řízení Správa dopravních dat Uživatelská potřeba Systém bude schopen poskytnout včasnou, přesnou, spolehlivou a jasně formulovanou cestovní informaci, kdykoli to bude v zájmu jeho uživatele. 6.3 Podpora cesty Informování a vedení uživatele 47

48 Uživatelská potřeba Systém bude schopen podat informaci o alternativních trasách, které jsou rychlejší, levnější, kratší, malebnější atd. 6.1 Nastavení a definice cesty 6.2 Plánování cesty Definice základních kritérií Uživatelská potřeba Systém umožní plánování cesty dle priorit cestujícího (dopravní prostředek, čas odjezdu/příjezdu, volba silniční trasy atd.). 6.1 Nastavení a definice cesty 6.2 Plánování cesty Definice cestovních dat Definice základních kritérií 6.4 Ohodnocení/vyhodnocení cesty Uživatelská potřeba V případě zjištění problémové situace na dopravní síti bude systém schopen nabídnout alternativní řešení při volbě trasy či změnu dopravního modu. 6.2 Plánování cesty Návrh alternativní cesty 6.3 Podpora cesty Určení mimořádné události Informování a vedení uživatele 48

49 Uživatelská potřeba Systém bude schopen zobrazit alternativní trasy na monitorech v místě přestupu z jednoho dopravního modu na druhý a v turistických informačních centrech. 6.3 Podpora cesty Informování a vedení uživatele Uživatelská potřeba Systém umožňuje ovládání silniční dopravy tak, aby byla umožněna redukce dopravních kongescí (cestovní doby) Řízení dopravním zařízením Poskytování řízení dopravy Výstupní ovládání/informace Uživatelská potřeba A Systém umožní dopravnímu centru, operátorovi řídit, (dálkovým ovládáním), jednotlivé dopravní značení nebo celé skupiny dopravních značení (jako pouliční světla, Proměnné znakové zprávy,...) 3.1 Dopravní řízení Řízení dopravním zařízením Výstupní ovládání/informace Operátorský vstup Uživatelská potřeba A 49

50 Systém umožní dopravní řízení podle různých kritérií, v městská a meziměstské síti, stejně tak jako v městském/meziměstském rozhraní. 3.1 Dopravní řízení Sběr dopravních dat Sledování parkovacích kapacit Predikce a tvorba strategií Správa dopravních dat Řízení dopravním zařízením Poskytování řízení dopravy Získávání stavu dopravy v oblasti Plánování dopravy Stav parkovišť Řízení rychlostí Výstupní ovládání/informace Řízení dopravního proudu Operátorský vstup Porušení řídicích povelů Statická data Sledování stavu dopravy 50

51 51

52 Obr 10: Celkové shrnutí použitých funkcí v řešeném příkladu. 52

53 Informační systém pro přepravu nebezpečných nákladů Uživatelská potřeba Systém bude schopen monitorovat pohyb nebezpečného nákladu a v případě mimořádné události poskytne odpovídající asistenci Řízení záchranných akcí Uživatelská potřeba Systém má umět zjistit, které vozidlo bylo zapleteno do nehody, identifikovat jeho posici a náklad a generovat stav nouze automatickým varováním. 4.4 Řízení vozidel veřejné osobní dopravy Optimalizace řízených procesů Uživatelská potřeba Systém má umět doporučit službu nouzové pomoci pro každé nebezpečné zboží, které bylo zapleteno do nehody. 4.4 Řízení vozidel veřejné osobní dopravy Optimalizace řízených procesů 8.2 Řízení dop. prostředků dopravců Řízení dopravních operací Řízení a sledování dopravních operací Řešení nehod Uživatelská potřeba AS Jednotlivé systémy si budou předávat informace o pohybu a stavu nebezpečného nákladu srozumitelnou formou dohodnutou všemi zúčastněnými stranami. 8.2 Řízení dop. prostředků dopravců Řízení dopravních operací Řízení a sledování dopravních operací Řešení nehod 53

54 Uživatelská potřeba Systém neumožní provést cokoli, co může vést ke snížení bezpečnosti Řízení dopravním zařízením Výstupní ovládání/informace Uživatelská potřeba Systém bude schopen během celé cesty sledovat fyzický i nefyzický stav nákladu. 8.1 Řízení logistických procesů a nákladní dopravy Správa dopravně přepravních operací 8.2 Řízení dop. prostředků dopravců Řízení dopravních operací Plánování a příprava dopravních operací Řízení a sledování dopravních operací Příprava/přenos informací z/do dop. prostředku Uživatelská potřeba Systém bude schopen predikovat čas příjezdu. 8.1 Řízení logistických procesů a nákladní dopravy Výběr dodavatele dopravních služeb 8.2 Řízení dop. prostředků dopravců Řízení dopravních operací Plánování a příprava dopravních operací Příprava a tvorba modelu plánu cesty a manipulace Řízení a sledování dopravních operací Příprava/přenos informací z/do dop. prostředku Řízení zadání přepravní činnosti Příprava cesty 54

55 Uživatelská potřeba Systém bude schopen poskytnout vyhovující trasy pro "abnormální" vozidla, tzn. nadrozměrná, s vyšší hmotností, s nebezpečným nákladem atd Příprava a tvorba modelu plánu cesty a manipulace Řízení zadání přepravní činnosti Příprava cesty Uživatelská potřeba Systém bude schopen stanovit zpoždění v plánovaném čase příjezdu a předat jej do centra řízení vozidlového parku. 8.2 Řízení dop. prostředků dopravců Řízení dopravních operací Řízení a sledování dopravních operací Ohodnocení podmínek dopravy Uživatelská potřeba Systém bude schopen dálkově nastavit teplotu a vlhkost v nákladní jednotce během přepravy. 8.3 Řízení dopravních prostředků/ řidičů/ nákladu/ vybavení Monitorování prostředků Monitorování nákladu/zboží 55

56 Obr 11: Celkové shrnutí použitých funkcí v řešeném příkladu Systém tísňového volání (E-CALL) Uživatelská potřeba Systém by měl být schopen umožnit nouzové volání Navázání tísňového volání 4.1 Sledování vozidlového parku veřejné osobní dopravy Komunikace s vozidlem Uživatelská potřeba Systém bude schopen detekovat kolizi vozidla, lokalizovat jej a automaticky vyslat signál tísňového volání Identifikace a klasifikace nehod Zpracování informací o nehodách Plánování záchranných akcí 4.1 Sledování vozidlového parku veřejné osobní dopravy Komunikace s vozidlem 56

57 Uživatelská potřeba Systém bude schopen vozidlo lokalizovat a na základě příkazu uživatele vozidla vyslat signál tísňového volání Identifikace a klasifikace nehod Zpracování informací o nehodách Plánování záchranných akcí Identifikace a klasifikace události Uživatelská potřeba Systém bude schopen obratem potvrdit příjem řidičova tísňového volání Identifikace a klasifikace nehod Zpráva o průběhu záchranné akce 4.1 Sledování vozidlového parku veřejné osobní dopravy Komunikace s vozidlem Uživatelská potřeba Systém bude schopen identifikovat řidiče či vozidlo vysílající signál tísňového volání Identifikace a klasifikace nehod 4.1 Sledování vozidlového parku veřejné osobní dopravy Komunikace s vozidlem Uživatelská potřeba Systém bude schopen zaslat signál nouzového volání v případě poškození některé z důležitých součástí vozidla, a v případě jiných tísňových stavů Identifikace a klasifikace nehod Zpracování informací o nehodách 57

58 Plánování záchranných akcí Uživatelská potřeba A Systém bude zajišťovat výměnu informací o nehodě se záchranou službou a zákonnými orgány v reálném čase, přičemž doba potřebná k záchraně řidiče žádajícího pomoc bude omezena na minimum. Služba bude od systému požadovat zajištění interoperability mezi systémy záchranné služby a policie (v rámci jednotného informačního rozhraní). 2.1 Řízení tísňové či krizové situace Řízení záchranných akcí Zpráva o průběhu záchranné akce Uživatelská potřeba Systém zajistí zelenou vlnu pro průjezd pohotovostních vozidel Plánování záchranných akcí Řízení záchranného vozidla Uživatelská potřeba A Systém bude schopen zjistit a identifikovat povahu a množství nebezpečného nákladu u vozidel projíždějících po předem určené trase, a tím ověřit, zda stav nákladu není v rozporu s platnými předpisy. 7.1 Detekce porušení pravidel Evidence pravidel a předpisů Kontrola souladu 8.2 Řízení dop. prostředků dopravců Řízení dopravních operací Plánování a příprava dopravních operací Uživatelská potřeba Systém bude shromažďovat a třídit tísňová volání cestujících na silniční síti pomocí různých druhů komunikace (např. silničních, dálničních a mobilních telefonů, (automatických) tísňových alarmů uvnitř vozidla atd.) Identifikace a klasifikace nehod Zpracování informací o nehodách 58

59 2.1.5 Sdílení dat během záchranné akce Uživatelská potřeba Systém bude schopen ověřit, zda skutečně došlo k nehodě, a tím eliminovat falešný poplach Identifikace a klasifikace nehod Zpracování informací o nehodách Sdílení dat během záchranné akce 3.2 Management nehodových/krizových událostí Identifikace a klasifikace události Uživatelská potřeba Systém je schopen navrhnout jeden nebo více postupů při zpracování dopravní událostí Plánování záchranných akcí 3.2 Management nehodových/krizových událostí Ocenění události a stanovení odezvy Uživatelská potřeba Systém umožňuje nalézt a identifikovat záchranná vozidla v dopravní síti Řízení záchranného vozidla Uživatelská potřeba Systém bude schopen vyslat volání o pomoc 59

60 5.5 Bezpečnostní pohotovost Přivolání pomoci 5.8 Integrace vozidla v dopravním systému Asistenční služby Uživatelská potřeba Systém bude schopen vozidlo lokalizovat a zaslat signál tísňového volání pohotovostní službě na základě příkazu osoby uvnitř vozidla Identifikace a klasifikace nehod Zpracování informací o nehodách Plánování záchranných akcí 8.3 Řízení dopravních prostředků/ řidičů/ nákladu/ vybavení Monitorování prostředků Monitorování nákladu/zboží 60

61 Obr 12: Celkové shrnutí použitých funkcí v řešeném příkladu. 4. Závěr Následující část obsahuje stručný výčet dosažených výsledků za rok 2005: 61