F AKULTA DOPRAVNÍ Č VUT K ONVIKTSKÁ 20, P RAHA 1

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 2003 Doc. Dr. Ing. Miroslav Svítek Doc. Ing. Zdeněk Votruba, CSc. Ing. František Kopecký Ing. Tomáš Tvrzský Ing. Miloslav Věžník Ing. Jan Čábelka, CSc. Doc. Ing. Mirko Novák, DrSc. Prof. Ing. Vladimír Svoboda, CSc. Prof. Ing. Pavel Přibyl, CSc. Ing. Jaroslav Veselý, CSc. Ing. Jiří Matějec Ing. Petr Zobaník Ing. Zdeněk Pliška Ing. Filip Týc Ing. Michal Šubrt Ing. Petr Říha Ing. Martin Popelík Ondřej Galík Martin Dvořák Jan Stibor Tomáš Stárek Mgr. Věra Bala VERZE 1.0

2 Obsah 1. Model ITS systému Analýza systémových parametrů aplikací/procesů Bezpečnost Spolehlivost Bezporuchovost Pohotovost, dostupnost Integrita Metodika návrhu ITS subsystémů ITS architektura ITS standardy ITS datový registr Začlenění datového registru v ITS prostředí Struktura ITS datového registru Programové vybavení pro správu ITS datového registru Pilotní naplnění ITS datového registru Pilotní realizace ITS datového registru na Internetu Závěry a doporučení Softwarová realizace ITS modelu Ukázkové příklady použití ITS architektury Silniční doprava (management dopravy Hradec Králové) Současný stav Fyzická architektura Konfigurace systému Datové toky Popis terminátorů Závěr Kombinovaná doprava (terminál Ústí nad Labem) Cíle tvorby ITS architektury terminálu Tvorba architektury ITS terminálu Analýza ITS architektury reálného příkladu Závěr Základní ekonomická analýza ITS Analýza ekonomických přínosů ITS systémů Služby pro cestující a řidiče Služby pro správce infrastruktury Služby pro provozovatele dopravy Služby pro státní správu a územní samosprávu Služby pro bezpečnostní a záchranný systém Služby pro finanční a kontrolní instituce Rozdělení ekonomických přínosů ITS systémů Podpora organizačních (podnikových) procesů Přínos architektury ITS pro podnikové procesy Základní organizační struktury organizací využívajících ITS Příklad vazby užitných vlastností ITS aplikace a podnikových procesů Procesy tvorby vlastního ITS systému Struktura aplikace ITS Systémové požadavky uživatelů Podpora vnitřních business procesů organizace (podniku) Přínos synchronizace informací pro vnitřní business procesy

3 Příklady možné podpory vnitřních business procesů Podpora vnějších business procesů organizace Příklad přínosu ITS systému pro podporu vnějších business procesů Kvantifikace užitných vlastností ITS systémů Teoretická východiska a základní charakteristiky produkčních funkcí Definice hodnotových metrik Užitné vlastnosti zabezpečovacích zařízení železniční dopravní cesty (modelový příklad) Cena realizace dopravního procesu Vztah konstrukčního prvku zabezpečovacích zařízení k nákladům Typy zabezpečovacích zařízení a příklad kvantifikace nákladů Pilotní projekty v oblast ITS Úvod Program TEMTO a projekt CONNECT Koordinační centrum pro ITS Systém tísňového volání (e-call) Literatura Příloha 1 Fyzická ITS architektura - fyzické subsystémy Příloha 2 Fyzická ITS architektura - fyzické datové toky Příloha 3 ITS datový registr Příloha 4 Uživatelské potřeby Příloha 5 Databáze ITS standardů CEN a ISO Příloha 6 Detailní popis ITS standardů CEN a ISO Příloha 7 Pilotní listy Příloha 8 Systém tísňového volání (e-call) Příloha 9 Produkční funkce - nástroj analýzy přínosů ITS systémů

4 1. Model ITS systému Pod pojmem model lze chápat objekt, často jiné povahy, který má však s originálem některé shodné vlastnosti podobné do té míry, že lze na něm studovat, analyzovat a předikovat určité aspekty originálu. Mezi originálem a modelem existuje vztah homomorfismu (zobrazení do ). Izomorfismus (zobrazení na ) je symetrické zobrazení mezi modelem a originálem. Systémový model je takový model, který má vlastnosti systému. Mohou existovat modely, které nelze považovat za systémy (postrádají systémové vlastnosti). Vystihují tedy pouze jen některé dílčí vlastnosti modelovaného objektu. Jak plyne z předchozí definice modelu, je tedy model pouze jakýmsi zjednodušením objektu. Jakým způsobem zjednodušíme model objektu při jeho tvorbě má zásadní význam. Model musí především charakterizovat v podstatných (zkoumaných) rysech originál. Základním principem implementace ITS systémů je využití všech dostupných znalostí k vytvoření modelu ITS systému, který se skládá z ITS standardů, ITS datového registru a ITS architektury, které jsou vzájemně propojeny a reflektují jak stávající stav ITS systému, tak i stav budoucí. V tomto pojetí je model ITS strategickým záměrem pro dlouhodobou implementaci ITS systémů. M A N A G E M E N T MODEL ITS SYSTÉMU ITS architektura REALNÝ ITS SYSTÉM ITS standardy ITS data registr ITS aplikace ITS rozhraní ITS databáze Obr.1.1. Vazba modelu a reálného ITS systému Model ITS systému musí být propojen s reálným ITS systémem tak, aby mohly být monitorovány jednotlivé změny v rozhraní (souvislost s ITS standardy), ve změně databází (souvislost s ITS datovým registrem) a přidání či změna telematické aplikace (souvislost s ITS architekturou). Porovnáním modelu a reálného ITS systému vznikají v managementu ITS systému nové služby, např. geografická optimalizace, ekonomické porovnání jednotlivých variant řešení, atd. Princip popsaných vazeb je naznačen na obr

5 1.1. Analýza systémových parametrů aplikací/procesů Každá telematická aplikace/proces je definovaná jako řetězení funkcí a ke každé aplikaci/procesu lze přiřadit množinu systémových parametrů 1 : bezpečnost - analýza rizik, strom hypotéz, atd., spolehlivost - schopnost systému poskytovat požadované funkce za daných podmínek v daném časovém intervalu, dostupnost - schopnost systému poskytovat požadované funkce při vyvolání (inicializaci) procesu (aplikace) využívajících této funkce, integrita - schopnost systému poskytovat časově korektní a platné hlášení uživatelům o poruchách systému, kontinuita - schopnost systému poskytovat požadované funkce bez přerušení během vyvolání procesu (aplikace), přesnost - schopnost systému garantovat souběh mezi požadovanými (předdefinovanými) parametry a skutečnými (měřenými) parametry Bezpečnost Pojem bezpečnost systému lze definovat dvěma způsoby. Obecně pro systémy s kterými se setkáváme v běžném životě. Druhým způsobem definice bezpečnosti systému vychází ze specifických požadavků dopravních systémů, konkrétně z požadavků železniční zabezpečovací techniky. V železniční dopravě jsou kladeny vysoké nároky na zabezpečovací zařízení. Z tohoto také vyplývají zvýšené nároky na bezpečnost systému v tomto odvětví dopravy oproti jiným např. silniční dopravě. Obecně lze tedy pojem bezpečnosti definovat jako míru odolnosti jednotlivých funkcí (procesů) vůči rušivým zásahům a to jak náhodných tak i zlovolných. Při studiu bezpečnosti systému narazíme také na otázky spojené s ohrožením funkce jiných soustav v jejich bezprostředním okolí systému. Pojem bezpečnosti systému lze rovněž vztahovat na eliminaci negativních vlivů systému na své okolí, tedy požadavek na minimalizaci škodlivých dopadů na své okolí (např.: zdraví lidí, škody na životním prostředí a majetku). Problematika bezpečnosti systémů (nejen dopravních) má v širších souvislostech mimo technických dopadů také dopady společenské, právní a sociální. Speciální kategorií zkoumání bezpečnosti je obor železniční zabezpečovací techniky. Bezpečnost systému je zde chápána jako schopnost systému omezit důsledky poruch zařízení tak, že při jejich výskytu bude vyvolána výstupní informace, která není méně omezující než ta, která by byla výsledkem funkce neporouchaného systému v téže situaci. Tato schopnost představuje kvalitativní stránku bezpečnosti. U systémů s vnitřní bezpečností by bylo dosaženo bezpečnosti absolutní v případě, že by platilo absolutně roztříděných poruchových stavů (nevyskytl by se nikdy žádný případ nepravděpodobné nebo neuvažované poruchy). V zabezpečovacím systému na železnicích mohou existovat poruchové stavy, s pravděpodobností výskytu ležící pod požadovanou úrovní, při kterých zabezpečovací zařízení nebude reagovat správně. Bezpečnost 1 Systémové parametry jsou u každé aplikace jiné, např. dynamická navigace má nižší systémové parametry než například automatické nouzové volání (e-call) nebo aplikace pro sledování přepravy nebezpečných nákladů. 5

6 zabezpečovacího zařízení lze kvantifikovat jako pravděpodobnost nepřítomnosti hazardního stavu v zařízení po jistou dobu jeho využívání a za určitých podmínek provozu a údržby. S bezpečností systému velice úzce souvisí pojem spolehlivost systému. Pravděpodobnost, že se na výstupu ze systému objeví chyba, nelze vyjádřit žádným spolehlivostním ukazatelem. Mino vlastní pravděpodobnosti výskytu chyby hraje významnou roli i její detekce - integrita 2. Vysoké bezpečnosti systému je dosahováno použitím průběžných kontrol správnosti funkce systému (např. bezpečnostní kódy, komparace, atd.). Použití průběžných kontrol funkcí systému ovšem znamená nárůst objemu prvků v systému, takže pokud nepoužijeme průběžnou kontrolu, je zvýšení bezpečnosti doprovázeno zhoršením spolehlivosti systému. Systémy, od kterých je požadována správná činnost a závisejí na ní například lidské životy, apod., obvykle vyžadují vysokou bezpečnost i spolehlivost. V tomto případě je třeba doplnit zabezpečení systému samočinnou opravou Spolehlivost Spolehlivost je obecná komplexní vlastnost systémů, zahrnující více jednotlivých parametrů či jejich vzájemnou kombinaci, která spočívá ve schopnosti plnit souhrn specifických vlastností, předepsaných pro požadovanou funkci systému, jeho provoz, údržbu, přepravu, opravu a skladování, při zachování stanovených provozních parametrů v daných mezích a v čase podle stanovených technických norem nebo požadavků uživatele. Spolehlivost je komplexní vlastnost, tzn. zahrnuje několik různorodých hledisek (stěží lze vyjádřit jedinou číselnou hodnotou), která by umožnila uspořádání systémů dle jejich spolehlivosti. Dle normy jsou zavedeny ukazatele spolehlivosti, které lze jednotlivě vyhodnocovat. Ukazatele spolehlivosti jsou ve svém důsledku kvantitativním vyjádřením dílčích vlastností, které ve své postatě charakterizují spolehlivost systému. Podle toho jestli během životnosti systému je prováděna obnova bezporuchového stavu, nebo ne, rozlišujeme systémy na obnovované a neobnovované. Obnova je chápána jako přechod ze stavu poruchy do bezporuchového stavu. Oprava je činnost která zapříčinila výše zmíněný proces obnovy systému Bezporuchovost Neobnovované systémy Základní sledovanou náhodnou veličinou t charakterizujeme velikost časového intervalu od uvedení do provozu do poruchy systému. Čas t měřený od uvedení systému do provozu má distribuční funkci Q(t), která vyjadřuje pravděpodobnost poruchy od času t. Pravděpodobnost bezporuchového stavu R(t) systému v čase t je doplňková hodnota do R () t Q() t =1 (1.1) Je-li náhodná veličina spojitá, lze odvodit její hustotu pravděpodobnosti f(t) () dq t f () t = (1.2) dt f(t) je v teorii spolehlivosti nazývána hustotou poruch. Součin f(t)dt udává s jakou pravděpodobností nastane ve sledovaném systému porucha ve velmi krátkém časovém intervalu dt, následujícím za okamžik t. 2 definice integrity viz níže. 6

7 Intenzita poruch λ udává podmíněnou hustotu pravděpodobnosti poruch v čase t za předpokladu, že k poruče dosud nedošlo () t () t ( t) Q() t f f λ = = (1.3) R 1 Z předchozích vztahů můžeme odvodit následující: () () t dr t λ dt = (1.4) R ze kterého řešíme následující integraci λ( τ ) dτ 0 R = e (1.5) () t 1 Pokud není znám průběh intenzity poruch λ(t) na čase, není možno výraz dále zjednodušit. Empiricky bylo zjištěno, že průběh λ(t) odpovídá tzv. Vanové křivce, viz obr V intervalu <t 1,t 2 >, kterým je označeno období normálního provozu, je přibližně intenzita poruch rovna konstantě. V takovém případě dokážeme integrál vypočítat, R λt () t e = (1.6) λt () e Q t f =1 (1.7) t () t λe λ = (1.8) λ R I II e -λt 0,37 t p t k t 1 = T s λ Obr Vanová křivka a exponenciální křivka. Střední doba bezporuchového stavu T s je střední dobou provozu systému, kdy nenastala žádná porucha. Pro výpočet se používá vztah: t 0 () t T s = R dt (1.9) Známe-li průběh R(t), můžeme odvodit hodnotu T s, kde pro exponenciální rozdělení pak dostaneme: 7

8 = e 1 λ t Ts dt = (1.10) λ Obnovované systémy Systém jenž je obnovován prochází během svého života posloupností stavů bezporuchových A 1 a poruchových A 0. A 1 stav systému τ p1 τ o1 τ p2 τ o2 τ p3 τ o3 A t 1 t 1 t 2 t 2 t 3 t 3 t Obr Technický život systému. Pro obnovované systémy se místo termínu střední doba do poruchy používá termín střední doba mezi poruchami n t pi t p i= 1 Ts = =, (1.11) n n kde n je počet výpadků Pohotovost, dostupnost Okamžitý součinitel pohotovosti (dostupnosti) K p (t) udává pravděpodobnost, že v čase t K = lim K t, označovaná jako bude systém v provozuschopném stavu. Existuje limita ( ) stacionární součinitel pohotovosti. Hodnota ukazatele udává pravděpodobnost, že systém který je v ustáleném provozním stavu, bude provozuschopný v libovolně zvoleném okamžiku. Hodnotu můžeme interpolovat jako poměrnou část provozuschopné doby z celkové sledované doby K p p o P t t p = (1.12) t + t t p je kumulativní doba provozu, t o je kumulativní doba oprav během sledovaného období. Střední doba oprav T o je dána vztahem to To = (1.13) n P 8

9 Střední frekvence oprav µ je dána jako střední počet oprav, které lze dostupnou opravářskou kapacitou uskutečnit za jednotku času 1 T o = (1.14) µ Dosadíme-li postupně do předchozích vzorců dostaneme Ts µ K p = = (1.15) T + T µ + λ s o Součinitel prostoje je doplňkem součinitele pohotovosti do vztahu 1.1. Pro něj lze určit ustálenou okamžitou hodnotu K n () t K ( t) =1 (1.16) p o p která udává pravděpodobnost, že v čase t nebude systém provozuschopný. Stacionární součinitel prostoje K n = lim K n () t, udává pravděpodobnost, že systém nebude t provozuschopný v libovolně zvoleném časovém okamžiku. Součinitel technického využití K tv t p K = tv t + t + t (1.17) u t u kumulativní doba plánované údržby systému. Celková pohotovost systému lze ovlivnit následujícími faktory: Integrita vhodná architektura systému (zálohování, modularita) údržba (automatická diagnostika) organizace údržby Integrita systému vyjadřuje pravděpodobnost schopnosti systému diagnostikovat chybu při jejím výskytu. Velice úzce souvisí s pojmy spolehlivosti a bezpečnosti. Na základě předem dané hodnoty výstrahy, v rámci stanovených parametrů systému, je třeba stanovit maximální přípustnou dobu (risk of integrity), kdy ještě nedodržení hodnoty výstrahy nebude mít výrazný vliv na celkovou bezpečnost pro požadovanou funkci systému. Integrita je ve své podstatě bezpečnostní požadavek, který zahrnuje schopnost systému včas a správně varovat uživatele v případě, že systém již neodpovídá stanoveným technickým normám nebo jeho požadavkům. Mez výstrahy (Alert Limit - AL) je maximální velikost chyby, při jejímž překročení dojde k výstraze o nedodržení parametrů systému. Čas do vydání výstrahy (Time-to-Alert - TTA) je maximální zpoždění mezi vznikem důvodu pro výstrahu na požadované úrovni bezpečnosti a vyhlášením poplachu. Integritu (Integrity Risk) pak lze definovat jako pravděpodobnost, že v případě vniku závady (překročení AL) bude vydána výstraha uživateli o této závadě před uplynutím času stanoveného k vydání výstrahy (TTA). Sledujeme-li výslednou spolehlivost systému (nejčastěji sledujeme, zda-li nedošlo k poruše systému pravděpodobnost bezporuchového stavu, sledujeme tedy pouze jeden z parametrů spolehlivosti sytému, viz výše) jako celku, musíme sledovat spolehlivost jednotlivých dílčích procesů na sebe vzájemně navazujících (sériových) nebo souběžných 9

10 (paralelních) procesech. Existují známé metody jakým způsobem získáme výslednou spolehlivost systému jako celku. Pro ilustraci uveďme použití sérioparalelních modelů jako metody vedoucí k získání výsledné spolehlivosti u vzájemně nezávislých procesů. Jsou-li procesy závislé, používají se modely složitější. Vhodným dynamickým spolehlivostním modelem pro většinu technických systémů je diskrétní markovský náhodný proces. Soustřeďme se na případ dvou nebo více paralelně probíhajících procesů. Budeme-li tyto procesy chtít vyhodnotit a sloučit, budeme potřebovat zařízení zvané komparátor, viz Obr.1.4 Úloha spočívá v řešení pravděpodobnosti detekce chybových stavů jednotlivých procesů. V závěru určíme pravděpodobnosti falešného poplachu (byl detekován chybový stav, ale ve skutečnosti nenastal) a pravděpodobnost správné detekce (chyba opravdu nastala a byla detekována). A 1 T K T Obr 1.4. Paralelní model s komparátorem. Označme pravděpodobnost správné detekce chybového stavu jako P S a pravděpodobnost nesprávné detekce chybového stavu vlivem náhodného šumu jako P CH. Vzhledem k tomu, že pravděpodobnost P CH je u většiny detekčních senzorů poměrně vysoká, je nutno systém detekovat větším množstvím paralelně uspořádaných senzorů a využít jejich vhodnou kombinaci jako způsobu snížení pravděpodobnosti chybového stavu P CH. Nejvíce využívanou metodou pro rozhodování pomocí paralelních senzorů je filtr "M z N". Mějme N senzorů a pro jednoduchost předpokládejme stejné pravděpodobnosti správné detekce chybového stavu a pravděpodobnosti nesprávné detekce vlivem náhodného šumu. V případě, že tato podmínka není splněna, je možno metodiku jednoduchým způsobem rozšířit. Označme hypotézou H 0 bezchybný stav systému a hypotézou H1 stav, kdy nastala chyba systému. Dále definujme pravděpodobnost, že v případě bezchybného stavu systému, k senzorů chybu detekuje jako: N k N k P[ k H 0 ] = P CH ( 1 PCH ) (1.18) k Stejným způsobem definujme pravděpodobnost, že v případě chyby systému pouze k senzorů tuto chybu detekuje: N k N k P[ k H1 ] = P S ( 1 PS ) (1.19) k Princip filtru M z N spočívá v definici hodnoty M značící minimální počet senzorů detekujících chybu, aby chyba byla ohlášena jako skutečná a byl spuštěn poplach. Přitom práh M je třeba volit s ohledem na následující vztahy: A n 10

11 P P F D = = N k = M N k = M N k N k P P k S k CH ( 1 P ) S N k ( 1 P ) CH N k (1.20) kde P P F, D značí pravděpodobnost falešného poplachu (chyba je detekována aniž ve skutečnosti nastala) a pravděpodobnost správné detekce (chyba je správně detekována). S ohledem na kvalitu detekčního senzoru (pravděpodobnosti P S, P CH ) je třeba volit počet paralelních detektorů N a práh M, při kterém je detekována chyba tak, aby diagnostický systém vykazoval požadované vlastnosti (pravděpodobnosti P, P ). Obecně lze schopnost diagnostikovat stav telematického systému charakterizovat veličinou - integrita. Její definici nalezneme výše v textu Jednoduchý paralelní model s komparátorem Mějme jednoduchý příklad dvou paralelních procesů, které detekují chybu terminátoru T 1. Správnost funkce obou procesů kontrolujeme pomocí komparátoru. Výsledný stav je přenášen do terminátoru T 2. Definujeme parametry příkladu. Minimální počet senzorů, které detekují chybu je M = 1, celkový počet senzorů N = 2, Počet senzorů detekujících chybu k = 2. A 1, A 2 jsou procesy u kterých budeme sledovat pravděpodobnost vzniku falešného poplachu. F D A 1 T 1 K T 2 A 2 Obr Jednoduchý paralelní model spolehlivosti procesů. Graf popisuje jakým způsoben závisí pravděpodobnost vzniku falešného poplachu P f a pravděpodobnost, že chybu bude detekována správně. 11

12 1 0.9 Paralelní zapojení s komparátorem a parametry M=1, N=2, k=2 Pf Pd Pf, Pd Ps Obr Závislost detekce chyby (nenastala P f ; nastala P d ) na pravděpodobnosti správné detekce chybového stavu. Z grafu na Obr.1.6 je patrné, že s rostoucí pravděpodobností správné detekce chybového stavu P S nám zároveň roste, v případě dvou paralelně probíhajících procesů, pravděpodobnost falešného poplachu. Z předchozího konstatování můžeme vyvodit závěr, že u komparovaných paralelních procesů roste pravděpodobnost falešného poplachu úměrně pravděpodobnosti správné detekce chybového stavu jednotlivých komponent Kombinované modely s komparátorem Mějme kombinované modely s komparátorem v následujících zapojeních: sériovém paralelním A K T A A T K A Obr Paralelní zapojení modulů s komparátorem 12

13 A A T K K T A A Obr Sériové zapojení modulů s komparátorem. Pro obě zapojení platí následující parametry: Minimální počet senzorů detekujících chybu M = 1. Počet senzorů N = 2. počet senzorů detekujících chybu k = 2 počet skupin po N senzorech zapojených v sérii/paralelně n = 2 až 5 1 Porovnání paralalní x sériové zapojení s komparátorem a parametry M=1, N=2, k=2, n=5 0.9 n = n = Pf n = 2 Pf serial Pf paralel 0.2 n = Ps Obr Závislost pravděpodobnosti detekce falešného poplachu P f na pravděpodobnosti správné detekce chybového stavu, počtu a způsobu zapojení skupin senzorů Z grafu na Obr.1.9 vyplývá, že pravděpodobnost falešného poplachu roste daleko rychleji u paralelního zapojení skupin s komparátorem než u sériového zapojení. Dokonce lze konstatovat, že čím více je skupin zapojeno do série/paralelně tím pomaleji/rychleji roste 13

14 pravděpodobnost falešného poplachu v závislosti na pravděpodobnosti detekce chybového stavu. V případě zapojování prvků (procesů) do série či paralelně je také ovlivňována spolehlivost a bezpečnost. Na základě předchozího příkladu můžeme uvést hypotézu, že zvyšujeme-li spolehlivost systému jako celku zapojováním prvků (procesů) paralelně, zvyšujeme tím riziko (pravděpodobnost) falešného poplachu. Zvyšující se pravděpodobnost falešného poplachu má nepříznivý vliv na integritu celého systému. Z definic víme, že integrita a bezpečnost mají úzkou souvislost Metodika návrhu ITS subsystémů Podstatnou část analýzy systémových parametrů na telematické aplikace/ procesy tvoří dekompozice systémových parametrů na jednotlivé funkce telematického řetězce včetně návrhu informačních vazeb mezi těmito funkcemi tak, aby celý telematický řetězec vyhovoval výše definovaným systémovým parametrům. Provedená dekompozice systémových parametrů umožní vytvoření metodiky pro následnou syntézu telematických řetězců dle různých kritérií (optimalizace přenosu informace mezi mobilní jednotkou a centrem zpracování, maximální využití stávající informační a telekomunikační infrastruktury, atd.). Po provedené analýze a dekompozici systémových parametrů na jednotlivé subsystémy lze získat tabulku systémových požadavků jednotlivých výše uvedených representantů na jednotku uživatele, vozidlovou jednotku, telekomunikační prostředí či centrum zpracování informací. Následným krokem návrhu je shluková analýza jednotlivých požadavků na jednotlivé subsystémy dopravně-telematického řetězce dle předem definovaných kritérií. Volba kritérií je podstatnou částí návrhu, neboť má-li návrh podle definované architektury sehrát integrační a optimalizační roli, je třeba hledat vhodná kritéria optimalizace, např. výběr nejpřísnějších kritérií ze všech representativních aplikací, vážený průměr ze všech nejpřísnějších kritérií, atd. V této části je třeba heuristicky posoudit jednotlivé telematické aplikace, výhledy jejich nasazení, atd. Výsledkem této části metodiky je návrh jednotlivých subsystémů, funkčních bloků včetně definovaných jejich systémových parametrů. Z hlediska vlastní konstrukce jednotlivých subsystémů je možno uvažovat o následujících řešení: jeden universální subsystém splňující nejpřísnější systémové parametry - viz obr. 1.10, který je možno nasadit ve velkém množství - příkladem může být vozidlová jednotka, která umožní všechny možné telematické aplikace dle přání zákazníka na jedné infrastruktuře, kde velké množství prodaných jednotek pokryje universálnost konstrukce jednotky, vytvoření několika tříd subsystémů dle množiny systémových parametrů - viz obr. 1.11, kdy pro jednu skupinu aplikací je třeba využít pouze funkci f 1, pro druhou skupinu je třeba funkcí f 1 a f 2, atd. - pokud zákazník chce rozšířit množinu aplikací, zvýšit systémové požadavky dané funkce, vymění se jeden subsystém za druhý, vytvoření modulárního subsystému, kde přidáním dalšího modulu dojde ke zvýšení systémových požadavků nebo ke zvýšení funkcí daného subsystému - 14

15 viz obr. 1.12, - pokud zákazník chce rozšiřovat telematické aplikace, není třeba výměny subsystému, ale pouze se doplní softwarový modul obsahující funkce s danými požadavky dle přání a potřeb zákazníka. Stejný princip jako byl předveden při návrhu jednotlivých subsystémů, lze využít i při návrhu telekomunikačního prostředí mezi mobilní jednotkou a centrem zpracování informací (jednotné frekvenční radiové pásmo pro všechny dopravně-telematické aplikace, kombinace jednotlivých přenosových systémů, kombinace pevných a radiových sítí, atd.). Řešení telekomunikačního prostředí lze jako v případě ITS subsystémů rozdělit do několika tříd, případně přenosové prostředí řešit modulárně, kde přidáním dalších modulů je možno docílit vyšší systémové požadavky na přenos informací. Obdobná situace je pro centra zpracování, zpoplatňování uživatelů, atd. Je třeba zvážit, zda každý dopravní obor musí mít vybudováno centrum zpracování informací, zda není možné tyto centra vzájemně sdílet, je nutno provést geografickou optimalizaci center zpracování, atd. f 1 -f n Obr Universální subsystém f 1 f 1, f 2 Obr Různé třídy subsystémů f 2 f 3 f 1 kernel f n Obr Modulární řešení subsystémů Při návrhu ITS subsystémů hraje spolehlivost a tedy také jeho dostatečně dlouhá životnost významnou roli. Způsoby zajišťování spolehlivosti systémů můžeme zhruba rozdělit do následujících čtyř hlavních skupin: 15

16 Robustní uspořádání - Můžeme zařadit mezi jedny z nejstarších způsobů zajišťování spolehlivosti systémů. Spočívá ve výběru a použití co nejkvalitnějších součástí či prvků systému pro jeho realizaci. Tato cesta je z praxe i běžného života osvědčená. Ovšem z ekonomického hlediska výběr nejkvalitnějších prvků systému vyžaduje vysoké náklady. Zálohováním kritických prvků - Obdobně jako v předešlém způsobu zajišťování spolehlivosti také zálohování kritických prvků systému patří mezi nejstarší způsoby zajišťování spolehlivosti systémů. Z hlediska spolehlivosti musí být zálohovány ty nekritičtější části nebo prvky systému. Ty lze určit na základě expertního odhadu nebo na základě modelování či výpočtů. Zálohování bývá často vícenásobné. Zálohovat lze jak jednotlivé kritické prvky tak i celý systém. Operačně tak může být buď nasazen pouze jeden systém a ostatní jsou připraveny v záloze k co nejrychlejšímu zprovoznění v případě potřeby, nebo v případě kritických aplikací (kde hrozí riziko z prodlení např. atomová elektrárna) mohou být tyto prvky či systémy provozovány paralelně. Vícenásobné zálohování prvků systému je v praxi často realizováno skupinovým nasazením velkého počtu identických prvků či systémů v případě vysoké pravděpodobnosti nespolehlivosti prvku či systému. Paralelní spojení jednotlivých prvků do jisté míry kompenzuje nízkou funkční spolehlivost. Zálohování jednotlivých prvků systému vede vždy ke spolehlivějšímu systému než zálohování na úrovni větších celků. Poznamenejme, že například v přírodě je tento způsob zvyšování spolehlivosti přežití značně rozšířen, například výskytem velkého množství jedinců stejného druhu, atd. Nejpoužívanější vhodné modely systému jsou Markovské procesy, které v praxi poskytují adekvátní výsledky, jsou-li doby bezporuchového provozu a doby obnovy všech prvků rozděleny exponenciálně. Pokud není tato podmínka splněna, lze v některých případech převést nemarkovský model na markovský. V tomto způsobu zvyšování spolehlivosti systému jsou z ekonomického hlediska značně vysoké provozní a pořizovací náklady na takovýto systém. Redundantní systémy je nutno optimalizovat z hlediska pořizovacích a provozních nákladů. Modifikace struktury systému - Modifikace struktury systému je podstatně efektivnější způsob zvyšování spolehlivosti systému než dva výše uvedené způsoby. Modifikace struktury systému spočívá kupříkladu v modifikaci citlivosti dominantních systémových funkcí, které reagují na změny hodnot parametrů systému. Dalo by se říci, že provedeme znecitlivění těchto dominantních systémových funkcí. Modifikace jsou opět prováděny na nejkritičtějších místech v systému. Predikční diagnostika - Hlavní podstatou predikční diagnostiky je snaha předpovědět, kdy se trajektorie tzv. čáry života Ψ(t) systému může přiblížit výrazněji hranicím jejich oblasti přijatelnosti RA. Ta je definována v prostoru parametrů systému, v nichž se nalézají všechny funkčně vyhovující přijatelné realizace. Dle charakteru průběhu čáry života systému, přesněji její predikce (předpovědi) v blízkosti hranice oblasti přijatelnosti systému, je pak možno navrhnout nebo zvolit vhodný proces včasné korekce parametrů systému tak, aby její funkční schopnosti zůstaly plně zachovány. V případě, že z charakteru korekce není možné její provedení za provozu systému, je nutné zvolit optimální proces obnovy (opravy) systému. Prozatím není v přírodě pro tento proces známá analogie. 16

17 Žádný z výše popsaných přístupů ke zvyšování spolehlivosti systému není univerzální. Každý přístup má své přednosti a naopak i stinné stránky, které bývají často v praxi vzájemně kombinovány a jejich uplatnění závisí na vhodnosti pro konkrétní aplikaci. Neméně důležitým faktorem volby přístupu ke zvyšování spolehlivosti bývá i ekonomický aspekt. Ψ(t) x 2 RA x 1 Obr Trajektorie čáry života systému ITS architektura Tato technická zpráva navazuje na již vytvořenou funkční a informační architekturu, kde funkční architektura obsahuje hierarchické dělení jednotlivých makrofunkcí na funkce a podfunkce a informační architektura definuje informační vazby mezi jednotlivými funkcemi a podfunkcemi případně mezi funkcemi a terminátory. Metodika tvorby ITS fyzické architektury je založena na definici fyzických subsystémů, kde v rámci fyzické architektury byly zvoleny následující dostatečně obecné fyzické subsystémy: 1. Databáze systému a datový management 2. Subsystém správy komerčních vozidel 3. Subsystém kontroly komerčního vozidla 4. Subsystém komerčního vozidla 5. Subsystém managementu záchranných a integrovaných systémů 6. Subsystém záchranného vozidla 7. Subsystém managementu vozového parku 8. Subsystém nákladního zařízení 9. Subsystém managementu nákladní dopravy 10. Subsystém poskytovatele informačních služeb 11. Subsystém informačních kiosků 12. Subsystém pro zachování práva 17

18 13. Subsystém managementu údržby 14. Subsystém vozidel pro údržbu silničních komunikací 15. Subsystém parkovacích ploch 16. Subsystém managementu parkovacích ploch 17. Subsystém způsobů komunikace 18. Subsystém osobního dopravního prostředku 19. Subsystém managementu veřejné dopravy 20. Subsystém vozidla veřejné dopravy 21. Subsystém silniční komunikace 22. Subsystém správy mýtného 23. Subsystém placení mýta 24. Subsystém dopravního managementu 25. Subsystém koordinace dopravy Výše uvedené subsystémy byly zvoleny tak, aby fyzická architektura byla kompatibilní s ITS architekturami, např. KAREN, ACTIF, FRAME, ARTIST a zároveň navržené subsystémy bylo možno jednoduchou změnou názvu využít ve všech dopravních oborech. Jako příklad uveďme popis subsystému číslo 19 - Subsystém osobního dopravního prostředku, který je umístěn ve vozidle, kde poskytuje sběr dat, jejich zpracování, komunikaci pro provedení bezpečného a efektivního vedení vozidla v železniční dopravě. Tab Význam navržených funkcí pro železniční dopravu (příklad) číslo funkce název funkce 5.2 Automatizované řízení vozidla Reprezentace dané funkce v železniční dopravě Zabezpečuje automatické, bezpečné a ekonomické řízení hnacího vozidla železniční dopravy. Typicky AVV (automatické vedení vlaků), VZ (vlakový zabezpečovač), ETCS/ERTMS Podélná dynamická kontrola Funkce umožňuje automatizované řízení zrychlení a brždění hnacího vozidla. Typicky systém AVV (automatické vedení vlaků) Boční dynamické řízení Funkce automatického bezpečného zastavení vlaků. Základní funkce VZ (vlakový zabezpečovač), ETCS Interaktivní automatické řízení Základní funkce ETCS/ERTMS (evropského systému řízení vlaků). 18

19 Podpora infrastruktury ze strany vozidla Diagnostika infrastruktury ze strany vozidla. Například sledovaní dynamických tepelných vlastností kolejiva Inteligentní dynamické scénáře Zvýšení řidičovy bdělosti Funkce automaticky a dynamicky nahrazuje chybu lidského činitele (strojvedoucího při nerespektování příkazu návěstidel, dodržení stanovené rychlosti atd.). Reakcí může být snížení rychlosti a zastavení hnacího vozidla. Funkce poskytuje všechny metody, jak zvýšit řidičovu bdělost. Metody zvýšení řidičovy bdělosti jsou například zvuková/optická varování atd Monitorování stavu vozidla Prostředky pro adaptivní řízení rychlosti Funkce poskytuje monitorování vozidla za účelem odhalení hrozícího selhání nebo ztráty výkonu, který by mohl mít dopad na bezpečnost dopravy. Typicky diagnostika hnacího vozidla. Typické vybavení hnacích vozidel železniční dopravy Automatické převzetí řízení Komunikace vozidlo infrastruktura Funkce umožňuje automatické převzetí řízení vozidla v případě zhoršení stavu strojvedoucího a měla by zahrnovat procedury nezbytné k bezpečnému zastavení hnacího vozidla. Funkce zabezpečující bezpečné a ekonomické vedení dopravního prostředků. Typicky vazba ETCS/ERTMS, AVI systém, VZ Telematická architektuta vozidla 5.8. Integrace vozidla v dopravním systému Funkce poskytuje a zachycuje ve vozidle architekturu (sítě a protokoly) pro všechny telematické služby. Zahrnuje také vhodné protokoly pro různé služby a specifické vstupní body nebo firewall v případě, kdy informace jsou předávány z jedné služby k další, například komunikace hnací vozidlopřívěsné vozidlo.typicky z GSM-R prostředí. Funkce umožňuje provést integraci vozidla, opatřeného telematickými systémy, s celým dopravním systémem umožňující všechny služby pro efektivní využití dopravní telematiky. Mezi jednotlivými subsystémy lze definovat fyzické toky, které shlukují jednotlivé informační vazby mezi jednotlivými funkcemi. Metodika tvorby fyzické a komunikační architektury je založena na přiřazování jednotlivých funkcí z již existující ITS funkční architektury k jednotlivým (již definovaným) subsystémům. Toto přiřazení může respektovat stávající organizační strukturu, existující informační systémy, legislativní rámce tím, že k danému fyzickému subsystému jsou přiřazeny jen ty funkce, které odpovídají těmto požadavkům. Pokud se k definovaným fyzickým subsystémům přiřadí konkrétní funkce z funkční ITS architektury, je možno ke každé funkci přiřadit též dle ITS informační architektury informační 19

20 vazby mezi jednotlivými funkcemi. Shlukováním funkcí do fyzických subsystémů dochází zároveň ke shlukování informačních vazeb do fyzických datových toků mezi jednotlivými fyzickými subsystémy tak, aby základní logika ITS systému zůstala zachovaná. Fyzická a komunikační ITS architektura je zobrazena na Obr Detailní popis fyzických subsystémů je uveden v Příloze 1, kde ke každému subsystému jsou přiřazeny následující (databázové) položky: název subsystému, popis subsystému, funkce z logické architektury, které jsou subsystémem plněny, databáze (z logické architektury), které jsou použity, vstupní fyzické datové toky, výstupní fyzické datové toky, standardy, vztahující se k danému subsystému. Příloha 2 popisuje fyzické datové toky a ke každému fyzickému datovému toku jsou přiřazeny následující (databázové) položky: název fyzického datového toku, popis fyzického datového toku, zdroj, ze kterého fyzický datový tok vychází, cíl, kam fyzický datový tok vstupuje, logické datové toky, ze kterých je fyzický datový toky tvořen, standardy, vztahující se k danému fyzickému datovému toku. 20

21 Obr 1.14 Fyzická a komunikační architektura - ukázka grafického rozhraní a jeho popis Pro detailnější porozumění jednotlivých funkcí jsou v Příloze 4 popsány základní potřeby uživatelů na ITS systém, na základě kterých byly jednotlivé funkce definovány. Tyto požadavky vychází z dalekosáhlého průzkumu konaného v mnoha zemí EU, kdy prostřednictvím těchto požadavků byla definována funkční architektura. Databázové propojení uživatelských požadavků a jednotlivých funkcí umožní jednak na straně funkcí jejich lepší specifikaci a porozumění a na straně uživatelů snazší komunikaci mezi systémovým inženýrem (ITS architektem) a konkrétním uživatelem (jím specifikované požadavky definující konkrétní ITS funkce a tím i informační vazby, na základě kterých lze navrhovat fyzické subsystémy a fyzické datové toky). Uživatelské potřeby jsou v databázi reprezentovány: popis uživatelské potřeby, seznam funkcí, které plní danou uživatelskou potřebu ITS standardy V rámci řešení byla provedena analýza existujících i připravovaných CEN a ISO standardů, kde každý standard byl analyzován z pohledu ITS architektury a konkrétní standard byl přiřazen k odpovídající funkci, databázi či informačnímu toku. Touto analýzou dochází k propojení aktivit CEN a ISO standardů a ITS architektury. 21

22 ITS architektura v tomto pojetí je grafickým rozhraním k získávání všech potřebných informací o stávajícím stavu (viz ITS datový registr) a o stavu budoucím (ITS standardy). U každé funkce či informačního toku lze získat odkaz na standard, který tuto funkci či informační vazbu definuje. Kromě vlastní databáze standardů, byl vytvořen detailní popis všech dostupných standardů, který je koncipován tak, aby poskytl základní informace prostřednictvím webového rozhraní o daném standardu. Uživatel tohoto systému získá rychlou orientaci v ITS standardech a může si tak jednoduše vyhledat konkrétní standard týkající se jeho problémové oblasti. V rámci řešení byly analyzovány, popsány a propojeny s ITS architekturou následující ITS standardy: Tab. 1.2.ITS Standardy ITS Standardy ENV ISO Dopravní telematika - AFC - Specifikace rozhraní pro platební styk mezi operátory RTTT - Automatic fee collection (AFC) - Interface specification for clearing between operators pren ISO Dopravní telematika - EFC - Aplikace definice rozhraní pro vyhrazené spojení krátkého dosahu (ISO/DIS 14906:2002) RTTT-EFC, Application interface definition for dedicated short-range communication (ISO/DIS 14906:2002) ENV ISO RTTT - EFC - Zkušební postupy pro uživatelská a stacionární vybavení - Část 1: Popis zkušebních postupů (ISO/TR :2000) RTTT - EFC - Test procedures for user and fixed equipment - Part 1: Description of test procedures )ISO/TR :2000) pr CEN ISO TS EFC - Zkušební postupy pro uživatele a stacionární zařízení - Část 2: Specifikace zkoušek pro posouzení shody na rozhraní systému EFC EFC - Test procedures for user and fixed equipment - Part 2: EFC application interface conformance tests specification ENV ISO Dopravní telematika - EFC - Architektura systému RTTT-EFC-System architecture for vehicle related to transport services (ISO/DTS 17573:2002) prenv ISO EFC-Bezpečnostní rámec EFC-Security framework pr CEN ISO TS Dopravní telematika - EFC - Definice aplikačního rozhraní pro globální navigační satelitní systémy a celulární sítě (GNSS/CN) RTTT - EFC - Application Interface Definition for global Navigation Satellite Systems and Cellular Networks (GNSS/CN) prenv Telematika silniční dopravy a provozu - Systémy řízení nákladů a posádky (FFMS) - Referenční architektura a terminologie - Část 1: Vysokoúrovňová architektura a podmínky RTTT - FFMS - Reference Architecture and Terminology - Part 1: High Level Architecture and Terms 22

23 ENV PT - Silniční vozidla - Požadavky na rozměry proměnných elektronických externích značek PT - Road vehicles - Dimensional requirements for variable electronic external signs ENV RTTT - PT - Označovače jízdenek RTTT - PT - Validators pren PT - Referenční datový model PT - Reference Data Model ENV PT - Silniční vozidla - Požadavky na mechanické rozhraní přístrojové desky řidiče - Minimální parametry displeje a tlačítkového ovládacího panelu PT - Road vehicles - Driver s console mechanical interface requirements - Minimum display and keypad parameters pren PT - Systémy řízení a sestavování jízdních řádů - Část 1: Definice systému WORLDFIP a aplikační pravidla pro palubní přenos dat mezi zařízeními uvnitř vozidla PT Road vehicle scheduling and control systems Part 1: WORLDFIP definition and application rules for onboard data transmission pren PT - Systémy řízení a sestavování jízdních řádů - Palubní přenos dat mezi zařízením uvnitř vozidla - Část 2: Specifikace pro kabelové vybavení WORLDFIP PT - Road vehicle scheduling and control systems - On board data transmission between equipment inside a vehicle - Part 2: WORLDFIP cabling specifications ENV PT - Systémy řízení a sestavování jízdních řádů - Část 4: Všeobecná aplikační pravidla pro přenosové sběrnice CANopen PT - Road vehicle scheduling and control systems - Part 4: General application rules for CANopen transmission buses ENV PT - Systémy řízení a sestavování jízdních řádů - Část 5: Specifikace pro kabelové vybavení přenosové sběrnice CANopen PT - Road vehicle scheduling and control systems - Part 5: CANopen cabling specifications pr CEN TS Veřejná doprava osob - Systémy řízení a sestavování jízdních řádů - Část 2: Obsah zprávy CAN PT - Road vehicle scheduling and control systems - Part 6: CAN message content prenv RTTT - PT Neinteraktivní dynamické informace pro cestující na zastávkách RTTT - PT - Non-interactive dynamic passenger information on ground pr CEN TS PT - Silniční vozidla veřejné dopravy osob - Zařízení pro vizuální proměnné informace pro cestující ve vozidle PT - Road vehicles - Visible variable passenger information devices inside the vehicle pr ENV PT - Veřejné interaktivní informační terminály - Rozhraní pro cestující Public interactive information terminals - traveller interface ENV TTI - Zprávy TTI prostřednictvím kódování dopravních zpráv - Část 4: Kódovací protokol pro rádiový 23

24 datový systém - Kanál dopravních zpráv (RDS-TMC) - RDS-TMC s použitím ALERT Plus a ALERT C TTI - TTI Messages via traffic Message Coding - Part 4: Coding Protocol for Radio Data System - Traffic Message Channel (RDS-TMC) - RDS-TMC using ALERT Plus with ALERT C ENV TTI - Zprávy TTI prostřednictvím DSRC - Část 1: Specifikace dat - spojení z komunikace do vozidla TTI - TTI Messages via DSRC - Part 1: Data Specification - Downlink (Roadside to Vehicle) ENV TTI - Zprávy TTI prostřednictvím DSRC - Část 2: Specifikace dat - spojení z vozidla na komunikaci TTI Messages via DSRC - Part 2: Data Specification - Uplink (Vehicle to Roadside) EN ISO TTI - TTI zprávy postřednictvím dopravního kódování - Část 1: Protokol kódování pro rádiový datový systém - Kanál dopravních zpráv (RDS-TMC) - RDS-TMC s využitím ALERT-C (ISO/DIS :1999 TTI - TTI messages via traqffic message coding - Part 1: Coding protocol for Radio Data System - Traffic Message Channel (RDS-TMC) - RDS-TMC using ALERT-C (ISO/DIS : 1999) EN ISO TTI - TTI zprávy postřednictvím dopravního kódování - Část 2: Akční a informační kódy pro rádiový datový systém - Kanál dopravních zpráv (RDS-TMC) )ISO/DIS :1999) TTI - TTI Messages via traffic message coding - Part 2: Event and information codes for radio Data systém - Traffic Message Channel (RDS-TMC) (ISOúDIS :1999) pren ISO TTI - Zprávy TTI prostřednictvím kódování dopravních zpráv - Část 3: Odkazy na polohu pro ALERT- C (ISO/TS :2000) TTI - TTI Messages via traffic message coding - Part 3: Location referencing for ALERT-C (ISO/TS :2000) pren TTI - Zprávy TTI předávané kódováním dopravních zpráv - Část 6: Kódování a vstupní podmínky pro Rádiový datový systém - Kanál dopravních zpráv s využitím ALERT-C TTI - TTI Messages via traffic message coding - Part 6: Encryption and condition access for the Radio Data System - Traffic Message Channel ALERT C coding prenv ISO TTI - Zprávy TTI prostřednictvím celulárních sítí - Část 1: Všeobecné specifikace (ISO/DTR :2000) TTI - TTI messages via cellular networks - Part 1: General specifications (ISO/DTR :2000) prenv ISO TTI - Zprávy TTI prostřednictvím celulárních sítí - Část 2: Číslování a hlavička zpráv ADP (ISO/DTR :2000) TTI - TTI messages via cellular networks - Part 2: Numbering and ADP message header (ISO/DTR :2000) prenv ISO TTI - Zprávy TTI prostřednictvím celulárních sítí - Část 3: Základní informační prvky (ISO/DTR :2000) TTI - TTI messages via cellular networks - Part 3: Basic information elements (ISO/DTR :2000) prenv ISO TTI - Zprávy TTI prostřednictvím celulárních sítí - Část 4: Protokoly nezávislých služeb (ISO/DTR :2000) TTI - TTI messages via cellular networks - Part 4: Service-independent protocols (ISO/DTR :2000) 24

25 prenv ISO TTI - Zprávy TTI prostřednictvím celulárních sítí - Část 5: Vnitřní služby (ISO/DTR :2000) TTI - TTI messages via cellular networks - Part 5: Internal services (ISO/DTR :2000) prenv ISO TTI - Zprávy TTI prostřednictvím celulárních sítí - Část 6: Vnější služby (ISO/DTR :2000) TTI - TTI messages via cellular networks - Part 6: External services (ISO/DTR :2000) prenv ISO TTI - Zprávy TTI prostřednictvím celulárních sítí - Část 7: Funkční požadavky na palubní určení polohy (ISO/DTR :2000) TTI - TTI messages via cellular networks - Part 7: Performance requirements for onboard positioning (ISO/DTR :2000) prenv ISO TTI - Zprávy TTI prostřednictvím celulárních sítí - Část 8: Specifické parametry GSM (ISO/DTR :2000) TTI - TTI messages via cellular networks - Part 8: GSM-specific parameters prenv ISO Přenos informací přes DSRC v středním rozsahu - Obecná specifikace - Část 1: Spojení komunikace - vozidlo RTTT-TTI Medium range pre-information via DSRC General specification - Part 1: Down link (ISO WD 14822) prenv ISO TTI - Šírení zpráv prostřednictvím stacionárních systémů nezávislých na mediích - Slovník grafických dat pro systém šíření informací před jízdou a za jízdy TTI - Messages via media-independent stationary dissemination systems - Graphic data dictionary for pre-trip and in-trip information dissemination system pr CEN ISO TS TTI TTI předávané rozšiřitelným označovacím jazykem (XML) expertní skupiny pro protokoly (TPEG) Část 1: Úvod, typy společných dat a tpegml TTI - TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) Part 1: Introduction, common data types and tpegml pr CEN ISO TS TTI TTI předávané rozšiřitelným označovacím jazykem (XML) expertní skupiny pro protokoly (TPEG) Část 2: tpeg-locml TTI - TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) Part 2: tpeg-locml pr CEN ISO TS TTI TTI předávané rozšiřitelným označovacím jazykem (XML) expertní skupiny pro protokoly (TPEG) Část 3: tpeg-rtmml TTI - TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) Part 3: tpeg-rtmml pr CEN ISO TS TTI TTI předávané rozšiřitelným označovacím jazykem (XML) expertní skupiny pro protokoly (TPEG) Část 4: tpeg-ptiml TTI - TTI via Transport Protocol Experts Group (TPEG) Extensible Markup Language (XML) Part 4: tpeg-ptiml prenv ISO GDF - Geografická silniční databáze - Celková datová specifikace (ISO/DIS 14825:2002) GDF - Geographic Data Files - Overall data specification (ISO/DIS 14825:2002) ENV

26 Dopravní telematika - Slovník DATEX dopravních a cestovních dat (verze 3.1a) RTTT DATEX traffic and travel data dictionary (version 3.1a) ENV Dopravní telematika - Specifikace DATEX pro výměnu dat mezi dopravními a cestovními informačními centry (verze 1.2a) RTTT DATEX specifications for data exchange between traffic and travel information centres (version 1.2a) pren RTTT - DSRC - Fyzická vrstva mikrovlnné DSRC na 5,8 GHz RTTT - DSRC - Physical Layer using Microwave at 5,8 GHz EN RTTT- DSRC - Vrstva datového spojení DSRC: řízení středního přístupu a logického spojení RTTT - DSRC - DSRC data link layer: medium access and logical link control pren RTTT - DSRC - Aplikační vrstva DSRC RTTT - DSRC - DSRC Application layer pren RTTT - DSRC - DSRC profily pro aplikace dopravní telematiky RTTT - DSRC - DSRC profiles for RTTT Applications EN ISO Silniční vozidla Ergonomické aspekty dopravních informačních a řídících systémů Zásady řízení dialogu a postupy hodnocení shody Road vehicles - Ergonomic aspects of transport information and control systems - Dialogue management principles and compliance procedure (ISO 15005:2002) pren ISO Silniční vozidla - Dopravní informační a řídící systémy - Rozhraní člověk-stroj - Prezentace zvukových informací - Část 1: Požadavky Road vehicles - Transport information and control systems - Man machine interface - Auditory information presentation - Part 1: Requirements EN ISO Silniční vozidla - Měření zrakové aktivity ve vztahu k dopravním informačním a řídícím systémům - Část 1: zařízení a postupy (Definice a parametry) (ISO/FDIS :2001) Road vehicles - Measurement of driver visual behaviour with respect to transport information and control systems - Part 1: Definitions and parameters (ISO/FDIS :2001) EN ISO Silniční vozidla - Měření zrakové aktivity ve vztahu k dopravním informačním a řídícím systémům - Část 2: vybavení a postupy Road vehicles - Measurement of driver visual behaviour with respect to transport information and control systems - Part 2: Equipment and procedures EN ISO Silniční vozidla - Ergonomické aspekty dopravních informací a řídících systémů Specifikace a postupy posouzení shody pro vizuální prezentaci informací ve vozidle Road vehicles Ergonomic aspects of transport information and control systems Specifications and compliance procedures for in-vehicle visual presentation (ISO/FDIS 15008:2002) EN ISO Silniční vozidla - Ergonomické aspekty dopravních informačních a řídících systémů - Postup posouzení vhodnosti pro použití při řízení vozidla (ISO/FDIS 17827:2002) Road vehicles Ergonomic aspects of transport information and control systems Procedure for assessing suitability for use while driving (ISO/FDIS 17827:2002) 26

27 pren ISO RTTT- Automatická identifikace vozidel a zařízení (AVI/AEI) - Referenční architektura a terminologie RTTT - AVI/AEI - Reference Architectures and Terminology (review of ENV ) (in parallel with ISO NP 14814) pren ISO RTTT - AVI/AEI - Systémová specifikace RTTT AVI/AEI System specification (ISO/TR 14815:2000) pren ISO RTTT - AVI/AEI - Číslování a datové struktury RTTT AVI/AEI Numbering and data structures (ISO/TR 14816:2000) prenv ISO Dopravní informační a řídící systémy (TICS) - AVI/AEI - Architektura a terminologie TICS - AVI/AEI - Intermodal goods transport - Architecture and terminology CEN ISO TS RTTT - AVI/AEI - Intermodální přeprava zboží - Číslování a datové struktury RTTT - AVI/AEI Intermodal goods transport Numbering and data structures (ISO/DTS 17262:2002) CEN ISO/TS RTTT - AVI/AEI - Intermodální přeprava zboží - Systémové parametry AVI/AEI Intermodal goods transport System parameters (ISO/DTS 17263:2002) pr CEN ISO TS RTTT - AVI/AEI Elektronická registrace a identifikace vozidel RTTT - AVI/AEI Electronic Registration Identification (ERI) for vehicles (ISO WD 24534) ENV ISO Výkladový slovník terminologie pro dopravní informace a sektor řízení Glossary of standard terminologies for the transport information and control sector prenv ISO Koncepce a terminologie - Požadavky na popis koncepcí v normách TICS RTTT - Architecture and Terminology - Requirements for Architecture description in TICS Standards prenv ISO RTTT - RTTT Architektura - Prezentace dat v ASN.1 RTTT - RTTT Reference Architecture - Data Presentation in ASN.1 Provázanost ITS funkcí a informačních vazeb s jednotlivými ITS standardy je uvedena v Příloze 5, kde každý standard je (databázově) reprezentován s následujícími atributy: číslo pracovní skupiny (WG), ve které je standard zpracováván číslo standardu a jeho označení datum schválení standardu název standardu česky a anglicky zkratka standardu anotace standardu počet stran standardu 27

28 stadium schvalování standardu seznam funkcí, které souvisí s daným standardem seznam datových toků logických/fyzických, které souvisí s daným standardem seznam databází, které souvisí s daným standardem seznam subsystémů, které souvisí s daným standardem. Detailní popis ITS standardů je obsažen v Příloze 6. Mnohé z uvedených standardů mají platnost pro několik dopravních oborů, např. standardy popisující reprezentaci dopravních informací, informací o veřejné osobní přepravě, atd. V oblasti vybraných telematických aplikací železniční dopravy lze využít Směrnici 2001/16/EC o interoperabilitě železnic, dle které je potřeba připravit soubor Technických specifikací pro interoperabilitu (TSI) s nimiž mají být v souladu složky a subsystémy a také určitou měrou postupy pro železniční sektor. Oblast zavádění této Směrnice do ČD je řešena v rámci projektu č. CZ EUROPEAID/114172/D/SV/CZ. Z hlediska oblasti ITS je velmi důležitá oblast definice datových elementů a metadat, které budou součástí ITS datového registru ITS datový registr Začlenění datového registru v ITS prostředí Následující schéma ukazuje začlenění ITS datového registru do ITS prostředí České republiky. Předadatel ITS aplikace ITS interface Uživatel Registrátor Správce ITS architektura ITS datový registr Předkladatel vyhledává a vyjednává předání metadat stávajících ITS aplikací, používaných nebo standardizovaných rozhraní a ostatních datových struktur používaných v ITS prostředí. 28

29 Transformuje předaná metadata do standardního formuláře pro import metadat do datového registru. Správce kontroluje metadata, nastavuje vazbu na ITS architekturu a provádí jejich import do datového registru. Předkládá nová metadata k registraci registračnímu úřadu. Podrobný popis celého postupu a kompetencí je v kapitole «Proces kontroly, schvalování a registrace metadat», Příloha 3. Správce poskytuje metadata uživatelům z ITS datového registru formou rešerše případně povolením přístupu jen pro čtení přes webové rozhraní. Uživatelem může být státní správa, výzkum, vývoj nových aplikací apod., kde ITS architektura a ITS datový registr by měly být klíčem pro skutečně inteligentní, vzájemně propojený a funkční telematický systém Struktura ITS datového registru Struktura ITS datového registru je popsána v Příloze 3 pomocí ER datového modelu a popisu struktury databáze v kapitole «Datová struktura ITS datového registru». Datová struktura je tvořena: prvky systému, datovými koncepty, relacemi datových konceptů, užitím datových konceptů, datovými elementy, číselníky Programové vybavení pro správu ITS datového registru Správa ITS datového registru je zajištěna aplikací v prostředí MS Access, která se skládá ze tří částí: kontrola a import nových metadat, aktualizace jednotlivých záznamů registru, aktualizace číselníků. Aplikace pro správu datového registru je podrobně popsána v Příloze 3, kapitola «Popis aplikace pro aktualizaci ITS datového registru» Pilotní naplnění ITS datového registru V rámci pilotního projektu byl datový registr naplněn metadaty pěti ITS aplikací, které se podařilo zajistit. O zdrojích metadat pojednává kapitola «Zdroje metadat a standardů» Přílohy Pilotní realizace ITS datového registru na Internetu Obsah datového registru je zpřístupněn přes webové rozhraní na adrese Přístup je pouze pro čtení po zadání uživatelského jména a hesla. Jméno i heslo přiděluje správce ITS datového registru. Přes webové rozhraní je zajištěna i vazba na ITS architekturu. Podrobný popis aplikace je uveden v Příloze 3, kapitola «Přístup k ITS datovému registru přes webové rozhraní» Závěry a doporučení Aby se přínos ITS datového registru projevil v plném rozsahu bude nutno zajistit: 29

30 1. Provozování ITS datového registru, 2. Činnost předkladatele metadat, 3. Správu ITS datového registru, 4. Naplňování a aktualizaci datového registru, 5. Propagace účelu a poslání ITS architektury a datového registru v odborné veřejnosti, 6. Vytváření podmínek pro získávání metadat o dalších ITS aplikacích, rozhraních apod., 7. Využívání ITS datového registru při návrhu nových aplikací, 8. Využívání ITS datového registru při vyhledávání zdrojů dat pro nejrůznější analýzy Softwarová realizace ITS modelu Základem ITS architektury je relační databázový model. Všechna data jsou prezentována pomocí relačních tabulek. K datům, uloženým v relační tabulce, je umožněn přístup pomocí kombinace názvu tabulky, názvu sloupce a hodnoty primárního klíče. Pomocí databázového jazyka je autorizovaným uživatelům umožněn přístup k datům a k jejich popisům (metadata). Implementace rozhraní pro úpravu a manipulaci s daty bude popsána níže. 30

31 Obr Diagram struktury databáze architektury ITS 31

32 Struktura ITS architektury je tvořena logickou a fyzickou částí. Logická část architektury definuje jaké funkce musejí být v navrhovaném systému zahrnuty, aby byly uspokojeny uživatelské potřeby na tento systém. Dále ukazuje, jaký je vztah mezi jednotlivými funkcemi, databázemi a terminátory. Tyto vztahy jsou vyjádřeny logickými datovými toky. Fyzická část architektury alokuje funkce a databáze na fyzické subsystémy na úrovni dopravní infrastruktury, dopravních prostředků, cestujících nebo řídících center a definuje rozhraní mezi jednotlivými subsystémy. Fyzická část je prostředkem pro snadnější a pohodlnější přístup k ITS architektuře, protože objekty, se kterými se pracuje jsou blíže konkrétnímu vnímání dopravního systému. Nicméně fyzická část zůstává obecným abstraktním modelem, který může být nejrůznějšími způsoby aplikován na reálné systémy. Logickou část tvoří pět hlavních tabulek, které obsahují údaje o makrofunkcích (funct_areas), funkcích (functions), terminátorech (terminators), datových tocích (dataflows_logical), databázích (datastores). Dále je tvořena tabulkami, které podávají upřesňující informace o daném objektu, případně zajišťují relace mezi ostatními tabulkami. Fyzická část architektury je tvořena třemi hlavními tabulkami, které obsahují údaje o fyzických datových tocích (dataflow_physical), subsystémech (subsystems), uživatelských potřebách (userneeds). Propojení logické a fyzické části architektury je realizováno těmito relačními tabulkami: dtflw_logical_physical, která každému fyzickému datovému toku přiřazuje příslušné logické datové toky funct_subsystem, která obsahuje informace o tom, které funkce jsou vykonávány daným subsystémem temp_inputflow_physical, temp_outputflow_physical, subs_inputflow_physical, subs_outputflow_physical podávají výčet vstupních a výstupní fyzických datových toků Implementace rozhraní pro úpravu a manipulaci s daty je realizována formou webových stránek. 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. 32

33 Obr Přihlášení do systému Po přihlášení uživatele do systému se zobrazí hlavní stránka s přehledem novinek a důležitými sděleními pro uživatele. V závislosti na přístupových právech se generuje hlavní nabídka možností. 33

34 Obr Hlavní stránka Výběrem položky z nabídky se uživatel dostane do příslušné sekce. Obr Sekce editace funkcí ITS Architektury 34

35 Obr Sekce editace funkcí ITS Architektury přehled funkcí 35

36 Prováděné úpravy procházejí procesem schvalování. Obr Editace funkce ITS Architektury Pro snadné procházení ITS architekturou a zobrazení všech relací slouží volba prohlížení ITS architektury. Obr Procházení ITS Architekturou 36

37 Obr Procházení ITS Architekturou Obr Procházení ITS Architekturou 37

38 2. Ukázkové příklady použití ITS architektury 2.1. Silniční doprava (management dopravy Hradec Králové) Pro názornost univerzálnosti architektury ITS byl vytvořen model řízení dopravy a poskytování cestovních a dopravních informací pro město Hradec Králové. Nejdříve je v tomto příkladu popsán současný stav. Ten odráží opět pouze to co se bezprostředně týká řízení dopravy a poskytování informací. Důvodem výběru města byla jeho velikost a rozsah používaných systémů. Nešlo o použití všech funkcí oblasti managementu dopravy a poskytování cestovních informací, ale pouze o ukázku možnosti použití části modelu univerzální ITS architektury. V této kapitole je navržena koncepce řešení dopravního systému v Hradci Králové. Vychází se přitom jednak z atypičností historického vývoje topografie a celkového mimořádně uceleného urbanistického pojetí města, jednak ze současné dopravní situace a z existujících a předpokládaných budoucích hlavních sociálních, ekologických a ekonomických hledisek. Při návrhu koncepce dalšího celkového řešení dopravního systému města Hradec Králové jsou brány v úvahu jak současné i perspektivní technické, zejména dopravně informační prostředky, tak i možnosti postupné ekonomické a ekologické realizace navrhovaného systému Současný stav Město Hradec Králové je mezi českými (ale i evropskými městy vůbec) mimořádné svým urbanistickým vývojem a celkovou koncepcí. Ta se, jako je tomu dosud v řadě jiných našich měst, nevyvíjela pod přednostními živelnými tlaky, ale byla již po několik desetiletí ovlivňována systematicky a cílevědomě rozvíjenou urbanistickou koncepcí města. Integrovaný dopravní systém zahrnuje celou řadu funkčních a technických komponent, jejichž návrhové i provozní parametry mají klíčový význam pro celkové vlastnosti výsledného dopravního systému. Těmito komponentami jsou zejména: systémové a technické prostředky světelných signalizačních zařízení, zařízení a vybavení dopravní ústředny, technické ústředny, systém pro identifikaci námrazy, systém pro identifikaci a predikci smogu, systém televizního dohledu a jednotný bezpečnostní systém Dopravní ústředna ELSCOMP Dopravní ústřednou rozumíme hardwarovou podporu celého managementu dopravy. V principu se jedná o: hlavní ústřednu tvořenou - datovým koncentrátorem VBR - počítačem PC hvězdicovou propojující kabelovou síť. Základem pro možnost řízení nebo monitorování je propojení řízeného uzlu s ústřednou. V Hradci Králové je relativně hustá kabelová síť. V převážné míře se jedná o kabely TCKEE 38

39 20 (60) nebo o kabely CYKY x 1,5 mm 2. Kabely TCKEE jsou stíněné, každá dvojice vodičů je volně kroucena (twistována). Kabely CYKY jsou běžné silnoproudé kabely. Dopravní data shromažďovaná v řadičích budou, pro statistické účely, sbírána v pravidelných časových intervalech pomocí přenosných počítačů. Nebude probíhat řízení dle momentální dopravní situace v sítí, ale plná dynamika uzlu. Přes tento handicap lze očekávat významné změny v kvalitě řízení, neboť ke stávajícímu, relativně uspokojivému systému řízení, přistupuje dynamické řízení každé křižovatky Technická ústředna Technická ústředna slouží pracovníkům Technických služeb hlavně ke sledování provozuschopnosti SSZ. Jedná se v zásadě o výkonnější počítač třídy PC, na který bude zaznamenáván poruchový deník dopravní ústředny. Počítač bude vybaven dalším programovým vybavením, které umožní modemovou komunikaci se servisní organizací, která bude při poruše SSZ automaticky vyrozuměna. Po odstranění poruchy servisní organizací bude hlášení uloženo v provozním deníku technické ústředny Světelná signalizační zařízení Základním článkem řízení dopravy ve městě je světelné signalizační zařízení (SSZ). Jedná se o regulovanou soustavu tvořenou vstupními senzory, měřícími stav dopravy nebo čas a výstupními akčními členy - světelnými návěstidly. Vlastní řízení SSZ a jeho styk s nadřazeným systémem zabezpečují dopravní řadiče SSZ na jednotlivých křižovatkách a dopravních uzlech. Dopravní řadiče jsou dnes velice propracovanými řídícími systémy, umožňujícími řídit dopravu v příslušné lokalitě v reálném čase Systém identifikující námrazu Systém HS4Cast je velmi rozsáhlý systém, který lze však modulárně přizpůsobovat na konkrétní podmínky. V nejjednodušším případě se jedná o pouhé měření fyzikálních parametrů (teploty) v daném místě, bez předpovědi vzniku námrazy. V nejkomplexnějším případě je systém tvořen senzory snímajícími všechny fyzikální parametry (teplota, tlak, rychlost větru, rosný bod atd.) a programovým vybavením umožňujícím na tři hodiny dopředu předpovědět možnost vzniku námrazy. Součástí může být i automaticky řízené postřikové zařízení Vybrané funkce z managementu dopravy Sběr dopravních dat Správa dopravních dat Řízení dopravním zařízením Poskytování řízení dopravy Operátorský vstup Statická data Sledování počasí Sledování znečištění ovzduší Údržba v krátkém čase Údržba v dlouhém čase Rozmrazování Vstup operátora údržby 39

40 Vybrané funkce z poskytování cestovních informací Určení poruchy Fyzická architektura V loňském roce řešení bylo za úkol na středně malé město (Hradec Králové) vytvořit návrh funkční architektury. Po provedené analýze bylo vybráno 12 funkcí patřících do oblasti 3 Management dopravy a 1 funkce z oblasti 6 Poskytování cestovních informací. Vybrané funkce byly použity pro tvorbu funkční a datové architektury. Vybrané funkce byly propojeny patřičnými datovými toky. Byly použity pouze toky, které mají v systému svůj zdroj nebo cíl. Datové toky, které jsou sice součástí managementu dopravy nebo poskytování cestovních informací, ale bezprostředně se nedotýkají zvolených funkcí byly vypuštěny. V dalším postupu byla vytvořena obecná fyzická architektura. Tato fyzická architektura opět vychází z analyzovaných potřeb, na základě kterých došlo k výběru potřebných funkcí. Nástavbou dojde opět k vybrání potřebných fyzických bloků a jejich vzájemnému propojení fyzickými datovými toky. Opět jsou vybrány pouze ty fyzické bloky a fyzické datové toky, které sdružují požadované funkce a realizují mezi nimi fyzický přenos. Nutno podotknout, že takto vytvořená architektura je vlastně blokovým řešením. Definuje základní požadavky na výměnu informací, stanovuje základní protokoly při výměně informací a klade požadavky na rychlost přenášení informací. Konkrétní detailní návrh již musí vytvořit odborný projektant, který dodrží požadavky stanovené rámcovou architekturou. V rámci jednotlivých fyzických subsystémů je mu ponecháno spoustu prostoru pro realizaci, jen je pouze omezen vstupními a výstupními toky, které musí mít předepsaný tvar a formát. Při tvorbě fyzické architektury se vycházelo z navržených potřeb města a podle toho navržených funkcí Konfigurace systému Na Obr je blokové schéma subsystému management dopravy a poskytování cestovních informací. Výběr konkrétních fyzických bloků byl proveden na základě funkční architektury, ve které se definovaly předpokládané požadavky města. Pod každým fyzickým blokem je na obrázku dopsána funkce, kterou musí daný blok zajišťovat. Jak je patrno z Obr. 2.1., jsou zapotřebí pouze 4 fyzické subsystémy. Každý fyzický subsystém plní několik definovaných funkcí. V plné verzi architektury inteligentních dopravních systémů je samozřejmě ke každému fyzickému subsystému možno přiřadit více funkcí, resp. fyzický subsystém dokáže provádět více funkcí než v tomto konkrétním návrhu. Pro zvolený případ Hradce Králové se ale spokojíme pouze s tímto omezeným přístupem. 40

41 Obr Blokové schéma fyzické architektury Fyzické komponenty Pro dodržení požadovaných funkcí je nutné použít některé fyzické komponenty. Těmito komponentami jsou zejména: systémové a technické prostředky světelných signalizačních zařízení, zařízení a vybavení dopravní ústředny, technické ústředny, systém pro identifikaci námrazy, systém pro identifikaci a predikci smogu, systém televizního dohledu a jednotný bezpečnostní systém. Všechny použité komponenty splňují funkce, které byly definovány dříve. Jednotlivé komponenty jsou podle své funkce přiřazeny do fyzické architektury podle blokového schématu na Obr Na Obr je již konkrétní situace spolu se všemi prvky 41

42 fyzické architektury. Obrázek slouží pouze jako upřesnění fyzických komponent. Nejsou na obrázku vyobrazeny všechny jednotlivé komponenty použité k řízení města, a i lokalita je vybrána jen pro názornost. Obr.2.2. Fyzická architektura konfigurace systému V další kapitole následuje popis jednotlivých fyzických komponentů, které se budou podílet na řízení města, které mají vliv na zvýšení plynulosti dopravy, snížení počtu dopravních nehod, dosažení co nejmenšího ekologického a tím i ekonomického zatížení jak pro řidiče a uživatele, tak pro orgány státní správy Popis fyzických bloků Indukční smyčky Indukční smyčky patří do subsystému Systém silniční komunikace. Zajišťují funkci Sběr dopravních dat. Indukční smyčky jsou tvořeny drátem o určitém počtu závitů a jsou zabudovány do vozovky. Indukční smyčky mohou sbírat údaje o intenzitě, rychlosti, skladbě dopravního proudu, obsazenosti, atd. Údaje jsou předávány do řadiče. Dopravní uzel je vybaven obvykle dvěma druhy detektorů: prodlužovacím a výzvovým detektorem. Dopravní řadič řídí program, který trvale testuje obraz dopravy nad jednotlivými 42

43 detektory a na základě předem daných algoritmů prodlužuje délky zelených, modifikuje pořadí fází nebo vkládá fázi na výzvu. Tyto změny se obvykle provádí v rámci předem dané doby cyklu a předem daných maximálních délek zelených. Prodlužovací detektor, umístěný cca m před Stop-linií, má název odvozen z toho, že trvale měří odstupy mezi vozidly a pokud jsou menší než daná hodnota (obvykle 3-5 sec) tak prodlužuje délku zelené až do předem daného maxima. Tento způsob řízení se nazývá řízení měřením časové mezery. Oproti tomu je výzvový detektor umístěn buď těsně před Stop-linií nebo ve vzdálenějších místech, kde se mohou nepravidelně tvořit kongesce. V obou případech se dle algoritmů řízení vkládá fáze, pokud je indikováno obsazení detektoru vozidlem. Detektory u izolovaných řadičů neposkytují informace pro reálné řízení dopravy na úrovni oblasti. Data se získávají pouze off-line prostřednictvím laptopu a slouží ke statistickým účelům Videodetekce Videodetekce patří do subsystému Systém silniční komunikace. Zajišťuje funkci Sběr dopravních dat. Videodetekční zařízení je tvořeno kamerami spolu s příslušným software pro detekování události. Kamery je možno umístit vedle nebo nad jízdní pruh, který chceme sledovat. Videodetekce může sbírat údaje o intenzitě, rychlosti, skladbě dopravního proudu, obsazenosti, atd. Údaje jsou předávány do řadiče. Obraz z kamery může být dále přenášen k operátorovi dopravy a sloužit k ručnímu řízení dopravy Mikrovlnné detektory Mikrovlnné detektory patří do subsystému Systém silniční komunikace. Zajišťují funkci Sběr dopravních dat. Mikrovlnné detektory je možno umístit vedle nebo nad jízdní pruh, který chceme sledovat. Mikrovlnné detektory mohou sbírat údaje o intenzitě, rychlosti, skladbě dopravního proudu, atd. Údaje jsou předávány do řadiče. V tomto případě je mikrovlnný detektor použit pro měření rychlosti. Změří se okamžitá rychlost vozidla a ta je pak prezentována na display umístěném za měřícím místem Hlavní dopravní ústředna (HDŘÚ) HDŘÚ patří do subsystému Systém dopravního managementu a Systém poskytovatele informačních služeb. Zajišťuje funkce Správa dopravních dat, Poskytování řízení dopravy, Statická data a Určení mimořádné události. Dopravní ústřednou rozumíme hardwarovou podporu celého managementu dopravy. V principu se jedná o: hlavní ústřednu tvořenou - datovým koncentrátorem VBR - počítačem PC ATí hvězdicovou propojující kabelovou síť Základem pro možnost řízení nebo monitorování je propojení řízeného uzlu s ústřednou. V Hradci Králové je relativně hustá kabelová síť. V převážné míře se jedná o kabely TCKEE 20 (60) nebo o kabely CYKY x 1,5 mm 2. Kabely TCKEE jsou stíněné, každá dvojice vodičů je volně kroucena (twistována). Kabely CYKY jsou běžné silnoproudé kabely. 43

44 Dopravní data shromažďovaná v řadičích budou, pro statistické účely, sbírána v pravidelných časových intervalech pomocí přenosných počítačů. Nebude probíhat řízení dle momentální dopravní situace v sítí, ale plná dynamika uzlu. Přes tento handicap lze očekávat významné změny v kvalitě řízení, neboť ke stávajícímu, relativně uspokojivému systému řízení, přistupuje dynamické řízení každé křižovatky. Adaptivní řízení: je novou formou řízení, která je použita zatím pouze asi v pěti aplikacích v Evropě, vždy ale s vynikajícími výsledky. Jedná se o představitele kategorie decentralizovaného on-line adaptivního řízení se třemi funkční úrovněmi: o Strategická úroveň - každých min je modifikována doba cyklu, rozdělení zelených, základní sled fází a parametry koordinace (ofset). Řízené parametry jsou adaptovány na aktuální dopravní podmínky. o Taktická úroveň - každých cca sec je ovlivňován lokální sled fází, například pro preferování městské hromadné dopravy. o Operační úroveň - reakce na každé vozidlo na lokální úrovni (každou sec) prodlužováním/zkracováním zelené (Traffic responsive). Úrovně 1 a 2 jsou zajišťovány centrálním počítačem, zbytek zajišťuje dopravní řadič, který je vybaven programem, reagujícím na okamžité dopravní vztahy v křižovatce, preference MHD a excesy v dopravě (lokální řízení). Řadiči je ponechána značná míra vlastní inteligence. Při dlouhodobém sledování trendů v řízení dopravy lze říci, že tento způsob řízení kombinující možnosti dokonalého lokálního řízení a centrální on-line optimalizace se jeví být optimální, neboť neklade obzvláštní nároky na výpočetní výkony dopravní ústředny jako systémy s centralizovanou inteligencí ani na kvalitu a rychlost komunikace mezi uzlem a ústřednou, přičemž také pracuje v reálném čase a reaguje nejenom na okamžité excesy v dopravě, ale i na výkyvy počasí Technická ústředna Technická ústředna slouží pracovníkům Technických služeb ke sledování provozuschopnosti SSZ, PIT, mostních systémů, atd. Jedná se v zásadě o výkonnější počítač třídy PC, na který bude zaznamenáván poruchový deník dopravní ústředny. Počítač bude vybaven dalším programovým vybavením, které umožní modemovou komunikaci se servisní organizací, která bude při poruše technologických zařízení automaticky vyrozuměna. Po odstranění poruchy servisní organizací bude hlášení uloženo v provozním deníku technické ústředny. Technickou ústřednu tvoří server, na který jsou připojeny jednotlivé diagnostické prvky technologických zařízení města. K tomuto serveru je připojen i operátor údržby, operátor dopravy a operátor poskytování informací Řadič Řadič patří do subsystému Systém dopravního managementu. Zajišťuje funkci Správa dopravních dat. Měřené dopravní parametry vstupují do procesu řízení jako vstupní veličiny do matematického modelu implementovaném v dopravním řadiči. Vstupními údaji jsou například časové odstupy vozidel v jednotlivých směrech získané z indukčních detektorů. Tento model, který je realizován programovým vybavením dopravního řadiče zajišťuje, pro dané vstupní parametry, přepínání a změny délek jednotlivých fází světelných návěstidel a tím ovlivňuje chování dopravního proudu v daném uzlu. Řízení křižovatky tedy probíhá v 44

45 otevřené smyčce a kvalitu řízení lze zhodnotit pouze nepřímo prostřednictvím změny parametrů dopravního proudu. Na postižení různých poruchových stavů, kterým může být například extrémní zvýšení intenzit v některém směru v důsledku sportovního utkání musí předem reagovat dopravní inženýr zavedením těchto stavů do dopravního řešení. Základním hodnotícím kritériem pro kvalitu řízení dopravního uzlu je počet všech zastavených vozidel a celková doba jejich stání. Existuje i celá řada doplňujících kritérií: poskytování preference veřejné dopravě, snížení počtu nehod apod. Dopravní řadič je propojen přes ODŘÚ (je-li použita) na HDŘÚ. Tato ústředna poskytuje řadiči potřebné modely, které si potom řadič volí podle konkrétní dopravní situace Světelná signalizační zařízení (SSZ) SSZ patří do subsystému Systém dopravního managementu. Zajišťuje funkci Poskytování řízení dopravy. Základním článkem řízení dopravy ve městě je světelné signalizační zařízení (SSZ). Jedná se o řízenou soustavu tvořenou vstupními senzory (dopravními detektory), měřícími stav dopravy nebo čas a výstupními akčními členy - světelnými návěstidly. Vlastní řízení SSZ a jeho styk s nadřazeným systémem zabezpečují dopravní řadiče SSZ na jednotlivých křižovatkách a dopravních uzlech. Dopravní řadiče jsou dnes velice propracovanými řídicími systémy, umožňujícími řídit dopravu v příslušné lokalitě v reálném čase Proměnná informační tabule (PIT) PIT patří do subsystému Systém dopravního managementu. Zajišťuje funkci Poskytování řízení dopravy. Proměnné informační tabule slouží účastníkům provozu na pozemních komunikacích pro informování o aktuálních dopravních omezeních, uzavírkách, nehodách, atd. Tyto tabule jsou ovládány přímo z informačního centra nebo mohou být ovládány dopravními zařízeními (toho se využívá hlavně u tunelů, kdy při nutnosti uzavřít tunel posílá ŘS automaticky zprávu, které se zobrazí na PIT). Nevýhodou těchto tabulí je, že řidiči samy o sobě nic nepřikazují nebo nezakazují, ale pouze informují o situaci v následujícím úseku Proměnné dopravní značky (PDZ) PDZ patří do subsystému Systém dopravního managementu. Zajišťuje funkci Poskytování řízení dopravy. PDZ jsou nejčastěji zákazové omezující rychlost nebo omezující vjezd nebo předjíždění a příkazové (přikázaný směr jízdy, atd.). Jsou používány k zabránění vjezdů např. před tunelem nebo mostem. V případě potřeby snižují povolenou rychlost (např. před mostem, kde je detekována námraza). Příkazové značky jsou používány hlavně pro odklonění průjezdu přes silně zatíženou oblast v době špičky Operátor dopravy Operátor opravy patří do subsystému Systém dopravního managementu. Zajišťuje funkci Operátorský vstup. Hlavní činností operátora je monitoring a sledování dopravní situace prostřednictvím kamer, sledování hlášení z ostatních dopravních zařízení a v případě potřeby přebírá operátor funkci řízení za automatizované systémy. Pracoviště operátora dopravy tvoří PC připojené na technickou ústřednu, hlavní dopravní ústřednu, a další systémy. Dále je součástí pracoviště 45

46 monitorová stěna, kam jsou připojeny výstupy z kamer. Vzhledem k předpokladu, že kamer bude více než monitorů, dochází k přepínání výstupů několika kamer vždy na jeden monitor Meteohlásky Systém identifikující námrazu patří do subsystému Management silniční údržby. Zajišťuje funkci Rozmrazování. V zimním období je informovanost o sjízdnosti komunikací v období spadu sněhu, vniku náledí apod. jednou z nejsledovanějších. Jedna část informací má charakter meteorologické informace týkající se vybraných lokalit významných z hlediska dopravy, druhá část má za cíl informovat o aktuálním stavu zajišťování sjízdnosti komunikací pro všechny druhy uživatelů včetně vrcholných orgánů města. Výhledově je plánována instalace systému identifikujících námrazu na každém mostě přes Labe a Orlici. Informace o stavu a činnosti těchto zařízení jsou centralizovány na technickou ústřednu. Pro sledování pohybu posypových vozů je možno nainstalovat zařízení, které umožní sledovat posypový vůz, jeho výskyt a činnost. Meteohlásky je možno doplnit automatickým posypovým (samorozmrazovacím zařízením). Toto zařízení automaticky v případě detekce vzniku námrazy aktivuje posypové zařízení. Systém HS4Cast je velmi rozsáhlý systém, který lze však modulárně přizpůsobovat na konkrétní podmínky. V nejjednodušším případě se jedná o pouhé měření fyzikálních parametrů (teploty) v daném místě, bez předpovědi vzniku námrazy. V nejkomplexnějším případě je systém tvořen senzory snímajícími všechny fyzikální parametry (teplota, tlak, rychlost větru, rosný bod atd.) a programovým vybavením umožňujícím na tři hodiny dopředu předpovědět možnost vzniku námrazy. Součástí může být i automaticky řízené postřikové zařízení Měřiče CO a NO x Měřiče CO a NO x patří do subsystému Systém silniční komunikace. Zajišťují funkci Sledování znečištění ovzduší. Tyto měřiče sledují znečištění ovzduší a poskytují informace o koncentracích škodlivin v pravidelných intervalech, popř. na vyžádaní operátora. V případě překročení stanovených limitů musí dojít k omezení dopravy Operátor údržby Operátor údržby patří do subsystému Management silniční údržba. Zajišťuje funkci Vstup operátora údržby. Operátor údržby sleduje a koordinuje provádění údržbových prací technologických zařízení, informuje servisní organizaci a nefunkčnosti zařízení a kontroluje, zda je porucha odstraněna. Součástí pracoviště operátora údržba je pracoviště s PC, které je napojeno na technologickou ústřednu. Operátor údržby má také přehled a koordinuje krátkodobou a dlouhodobou plánovanou údržbu jednotlivých zařízení Operátor poskytování informací Operátor poskytování informací patří do subsystému Podpora cesty. Zajišťuje funkci Určení mimořádné události. Funkce určuje jakékoliv omezení v multimodální síti (včetně veřejné dopravy). Tvoří se porovnání současné situace s plánem a výsledek je zaznamenán. Tato funkce také stanovuje dopravní události za účelem informování cestujícího. Informace poskytuje prostřednictvím 46

47 proměnných informačních tabulí pokud se týkají řidičů nebo prostřednictvím informačních kiosků pro hromadnou dopravu Datové toky Podle výstupů řešení z roku 2002, byl vytvořen přehled datových toků, které vstupují nebo vystupují z fyzických komponent, které jsou využity pro řízení a organizaci dopravy v Hradci Králové. Celkem, v plné verzi architektury je to 59 vstupních a 68 výstupních datových toků, které přenášejí potřebné informace. Protože však nejsou pro město Hradec Králové předpokládány všechny funkce, které oblast 3 Management dopravy umožňuje, nebudou samozřejmě využity ani všechny datové toky. V dalším odstavci je uveden popis, kolik a jaké datové toky jsou využity pro řízení dopravy v Hradci Králové. Do fyzického bloku 22 Roadway system vstupuje 6 datových toků. V případě Hradce králové budeme potřebovat pouze polovinu, tedy 3 datové toky. Stejně tak využijeme pouze dva výstupní datové toky ze 7, které jsou pro tento subsystém definovány. Pro fyzický subsystém 14 Maintenance management system je definováno 21 vstupních a 20 výstupních datových toků. Ze všech možných využijeme pouze 8 vstupních datových toků a 9 výstupních. Pro fyzický subsystém 25 Traffic management system je definováno 32 vstupních datových toků a 41 výstupních datových toků. Ze všech definovaných využijeme pouze 7 vstupních datových toků a 10 výstupních. Datové toky, které jsou pro nás důležité, a které budeme pro management města Hradec Králové používat jsou v Tab atm.led_namrzani_podminky din_doprava_strategie_data dpz.dopravni_proud_data exp.atmosfericke_znecisteni_vstupy exp.pocasi_vstupy md.ci_dlouhodoba_udrzba_data md.ci_doprava_odchylka md.ci_kratkodoba_udrzba_data md.ci_posypove_prace_data md_cesta_uziti_data md_dlouhodoba_udrzba_potvrzeni md_doprava_management_strategie md_doprava_tok_management_data md_kratkodoba udrzba_potvrzeni md_opeartor_doprava_staticka_data_odezva md_operator_doprava_staticka_data_zadost md_operator_management_dopravy_odezva md_operator_management_dopravy_zadost md_potvrdit_dlouhodoba_udrzba md_potvrdit_kratkodoba_udrzba md_sebrana_dopravni_data md_staticka_data md_staticka_data_aktualizace md_staticka_data_cteni pdc.aktualni_podminky udr.dlouhodobe_prace 47

48 udr.kratkodobe_prace udr.posypove_prace_ukoly Tab Datové toky Tab. obsahuje seznam datových toků, jejichž obsah je potřebný pro správnou a celkovou funkci námi definovaných požadavků. Jak bylo řečeno v předešlém výčtu a také jak plyne z Tab. pro námi definovanou situaci v Hradci Králové budeme využívat celkem 28 datových toků. Bližší přehled, popis a vysvětlení ohledně datových toků je součástí výroční zprávy za rok 2002 tohoto projektu v příloze Požadavky na datové toky Součástí názornosti univerzálnosti architektury ITS systému je také specifikace požadavků kladených na datové toky. Každý datový tok má jinou důležitost a je kladen důraz na jinou vlastnost. U některých je to rychlost přenosu informace, u některých je požadavek na zajištění bezpečnosti při přenosu, atd. V této části bude ukázka pouze vybraných datových toků a jejich nejdůležitějších vlastností Datový tok din_doprava_strategie_data Obsahuje data o dopravním proudu a strategická data, která jsou z databáze doprava a strategie přenášena k dopravnímu úřadu. Datový tok tedy obsahuje statické informace nasbírané za nějakou časovou dobu. Datový tok tedy není náročný na vysokou rychlost přenosu, neboť stačí přenášet požadované informace jednou za den nebo i v delším časovém horizontu. Samozřejmě, že čím delší bude časový horizont, tím větší bude velikost přenášených dat Datový tok md_doprava_management_strategie Obsahuje detaily nové řídicí strategie, která je právě zavedena a může být zavedena v databázi dopravy a strategie.detaily zahrnují takové věci, jako ovlivnění křižovatky, metody řízení, předešlou strategii, atd. Tento datový tok je náročný na rychlost přenášených informací, neboť přenáší řídicí strategie, které musí včasně reagovat na vzniklou situaci a stanovit povely pro změnu nepříznivých dopravních podmínek. Pro přenos těchto informací je doporučeno využívat pevného metalického nebo optického vedení Datový tok pdc.aktualni_podminky Obsahuje analogová data ze senzorů pro určení současného stavu povrchu komunikace. Jde o měření teploty a vlhkosti na povrchu pozemní komunikace. Tento datový tok přenáší informaci o nutnosti použití rozmrazovacího zařízení. Požadavkem pro tuto funkci je vysoká přenosová rychlost. Není nutné přenášet tuto informaci každou sekundu, ale je potřeba přenášet tuto informaci v intervalu cca minut. Přenos této informace není ze své podstaty kapacitně náročné, neboť stačí přenášet pouze informaci o teplotě a vlhkosti vozovky do subsystému rozmrazování. Pro přenos tohoto datového toku je možno využít např. radiové sítě provozované na území města nebo GSM přenos Datový tok udr.posypove_prace_ukoly Obsahuje žádost organizace provést rozmrazovací práce. Tento datový tok přenáší informaci od systémů identifikujících námrazu, resp. identifikujících situaci, kdy je velmi pravděpodobné, že námraza může vzniknout. Informace jsou přenášeny v intervalu cca

49 20 minut k organizaci údržby, která zajišťuje posyp nebezpečných lokalit. Informace není v podstatě kapacitně náročná, jen je oproti datovému toku pdc.aktualni_podminky navíc potřeba přenášet informaci, které zařízení, v jaké lokalitě vyhlásilo potřebu posypu. Pro přenos těchto informací je dostačující využití GSM přenosu Popis terminátorů Definované datové toky mimo jiné přenášejí informace od/k terminátorům. Přehled terminátorů je uveden v Tab Podrobnější popis jednotlivých terminátorů potom následuje. Atmosférické podmínky Dopravní instituce Dopravní provoz Externí podmínky Organizace údržby Povrch dopravní cesty Tab Seznam terminátorů Terminátor Atmosférické podmínky Obecně poskytuje terminátor škálu informací týkajících se atmosférických podmínek, předpovědi počasí, atd. Informace v tomto pojetí se týkají identifikace vzniku námrazy a predikce možnosti vzniku námrazy. Data jsou přenášena v případě potřeby (identifikace námrazy) datovým tokem z tohoto terminátoru do bloku Rozmrazování Terminátor Dopravní instituce Obecně terminátor reprezentuje veřejné instituce různých stupňů, kteří mají vliv na řízení dopravy, tvorbu strategií řízení, atd. Jedná se především o: Ministerstvo dopravy Regionální dopravní odbory Městské dopravní odbory atd. V tomto konkrétním případě budeme terminátor dopravní instituce chápat na místní úrovni, tzn., že představuje instituce městský úřad, městský dopravní odbor, atd. Data jsou v pravidelných intervalech přenášena prostřednictvím datového toku z bloku Správa dopravních dat do tohoto terminátoru. Obsahují statistické hodnoty o vytížení pozemní komunikace (intenzitu, obsazenost, rychlost, atd.) Terminátor Dopravní provoz Obecně terminátor reprezentuje počet dopravních prostředků pohybujících se po dopravní cestě, na jejichž základě jsou získávány informace o dopravním provozu, které se uplatňují hlavně při jeho řízení. V tomto konkrétním případě se jedná o získávání dopravních parametrů prostřednictvím indukčních smyček zabudovaných do pozemní komunikace a prostřednictvím videodohledu. Z tohoto terminátoru jsou data přenášena prostřednictvím datového toku do bloku Sběr dopravních dat. 49

50 Terminátor Externí podmínky Obecně terminátor reprezentuje podmínky, ve kterých jsou poskytovány ITS služby, např. povětrnostní podmínky sníh, déšť, znečištění životního prostředí, atd. V tomto pojetí je terminátor chápán jako fyzické zařízení, které umožňuje poskytovat tyto informace. V našem případě budeme od tohoto terminátoru využívat především analogová data o situaci na silnici co se námrazy týče. Ve druhém případě to bude sledování atmosférického znečištění. V tomto případě se jedná o sledování CO a NO x. Informace je od tohoto terminátoru předávána prostřednictvím datových toků k funkci Sledování počasí (informace o teplotě, vlhkosti, atd.) a k funkci Sledování znečištění ovzduší (informace o koncentracích škodlivin ve vzduchu v oblasti kolem komunikací) Terminátor Organizace údržby Obecně tento terminátor reprezentuje lidské zdroje či technické systémy, které zajišťují práce při stavbě či údržbě dopravní infrastruktury, eventuelně při údržbě ITS prostředků, jež jsou součástí samotného ITS systému. terminátor je schopen výměny dat dvěma způsoby předáváním informací o čase, místě a trvání plánovaných prací do ITS systému získávání požadavků z ITS systému k provedení určitých prací. V tomto případě se údržba týká i senzorů a aktorů, které jsou součástí ITS systému. V našem konkrétním případě řešení chápeme funkci terminátoru Organizace údržby jako způsob předávání informací od části ITS systému. Informace k tomuto terminátoru je předávána datovými toky od funkce Údržba v krátkém čase, kde jsou obsažena data o potřebnosti krátkodobé údržby, od funkce Údržba v dlouhém čase, kde jsou obsaženy údaje o počasí pro stanovení dlouhodobé údržby a od funkce Rozmrazování, kde jsou obsažena data o potřebě aktivace rozmrazovacího zařízení. V případě nefunkčnosti nebo absenci automatického rozmrazovacího zařízení, provádí tuto funkci servisní organizace Terminátor Povrch dopravní cesty Obecně tento terminátor má za úkol monitorovat stav povrchu dopravní cesty. Pomocí zjištěných údajů umožní rozhodování o způsobu zajištění bezproblémového pohybu dopravních prostředků, chodců a invalidních vozíků po dopravní cestě, chodníku, atd. V našem konkrétním případě půjde především o měření náledí, respektive hodnot, které algoritmus vyhodnotí jako potencionální nebezpečí vzniku náledí. Informace z tohoto terminátoru je prostřednictvím příslušného datového toku předávána k funkci Rozmrazování. Na Obr je blokové schéma fyzických subsystémů, které budeme využívat pro tvorbu architektury inteligentních systémů. Na obrázku jsou také znázorněny terminátoři, kteří jsou definováni v předešlém textu a jednotlivé datové toky mezi systémem a terminátory. 50

51 Obr Blokové schéma fyzických bloků propojených datovými toky 51

52 Závěr Architektura představuje otevřený univerzální nástroj pro tvorbu telematického dopravního systému. Cílem této kapitoly bylo ukázat, jak lze prakticky aplikovat jednotlivé úrovně architektury v oblasti silniční dopravy. Na vytvořený model je nutné pohlížet jako na univerzální otevřený systém, který slouží jako praktická ukázka aplikace architektury. Hlavním rysem architektury je zajištění možnosti modifikace dle požadavků uživatele a provozovatele. Tento model systému je příkladem využití obecné architektury ITS systému při budování konkrétního ITS systému pro definované území. Jako příklad bylo vybráno město Hradec Králové. V rámci budování ITS systému v tomto městě bylo v loňském roce pro řešení tohoto projektu navrženo a vyspecifikováno několik funkcí, které by bylo vhodné a účelné zavést pro optimalizování silniční dopravy, snížení nehodovosti, ekologické zátěže, zvýšení plynulosti, informovanosti řidičů a cestujících, atd. V dalším kroku řešení byly vyčleněny datové toky, které se k daným specifikovaným funkcím vztahují, tzn., že jsou jejich zdrojem nebo cílem. K vybraným datovým tokům byly na ukázku popsány požadavky, jaké jsou na ně kladeny, tzn. Rychlost přenosu, nutnos přenosu velkého množství dat, popřípadě požadavky kladeny na zabezpečení informací. Součástí návrhu systému je také popis terminátorů. Podle obecné architektury mohou tyto jednotlivé terminátory provádět mnohem více funkcí a přijímat, popř. předávat mnohem více informací. V tomto konkrétním případě jsou však využívány pouze některé vlastnosti terminátorů Kombinovaná doprava (terminál Ústí nad Labem) Terminál je třeba chápat jako základní systémový prvek, v němž dochází ke vzniku multimodality, proto je na příkladu terminálu možné modelovat podstatnou část ITS systému logistického řetězce. Jedná se o praktickou ukázku provedenou na příkladu nejpoužívanějšího způsobu mezinárodní exportní a importní přepravy. Pro Českou republiku, jakožto vnitrozemský stát bez přímého přístupu k moři, je modelovaný příklad jeden z nejvýznamnějších multimodálních přeprav. Uvedené zpracování příkladu si klade za cíl sloužit jako demonstrace účelnosti a výhodnosti použití globální architektury ITS při práci s ITS systémy. Na příkladu je prakticky demonstrováno a popsáno, jak se utváří architektura ITS systému terminálu, jakožto samostatného subsystému v přepravním procesu, jak lze tímto systémem rozšířit stávající architekturu ITS a jak lze na výsledné architektuře modelovat konkrétní příklad. V závěru bude shrnuta výhodnost tohoto přístupu ve srovnáním s výstavbou systému bez znalosti globální architektury ITS. Řešení příkladu vychází z přepravního procesu mezinárodní, multimodální nákladní dopravy se všemi jejími funkcemi, na základě současného funkčního a informačního uspořádání systémů Cíle tvorby ITS architektury terminálu V rámci příkladu je znázorněn doporučený postup pro práci s architekturou ITS systémů, jehož cílem je popsat výhody, které této přístup přináší. Jde především o definovatelná doporučení pro dodržení jednotné globální strategie ITS systémů a z toho vyplývající zvýšení kvality vyvíjených informačních systémů. 52

53 Zvýšenou kvalitou pak rozumíme: vyšší produktivitu systému (jasná definice - životního cyklu IS, jednotlivých funkcí systému, odstranění duplicit, atd.), pomocný nástroj pro jasnou definici standardů (pro komunikaci i jednotlivé subsystémy), umožnění tvorby specializovaných týmů na konkrétní problematiky v subsystémech, dosažení pružnosti vzhledem k vývoji uživatelských potřeb, možnost rychlejší a efektivnější modifikace systému, podpora projektovému řízení prací na systému. Pro názornou ukázku praktického použití architektury ITS je vhodné pracovat s praktickým modelem určitého subsystému na dostatečně nízké úrovni v hierarchické struktuře architektury ITS. Budeme-li se pokoušet o tvorbu modelu na vyšší úrovni, nebude možné být příliš konkrétní a názornost příkladu nebude dostatečná. Řešení tohoto problému má stejný základ jako problematika volby rozlišovací úrovně v systémové analýze. Model terminálu v příkladu je vybrán tak, aby byl vhodný pro návrh a implementaci nového subsystému ITS Tvorba architektury ITS terminálu Pro modelování terminálu je nutné nejprve mít k dispozici architekturu ITS, která řeší tuto problematiku (nedopravních procesů) na dostatečné úrovni. V některých architekturách je tato problematika řešena v oblasti kompetence terminátorů. V podmínkách ČR je však výhodnější tuto problematiku zahrnout do systémů ITS jako takových, protože terminály v ČR jsou zpravidla integrovány do logistických center, kde opakovaně přechází dopravní a nedopravní činnosti v rámci jednoho procesu. Architektura v tomto případě slouží jako základní nástroj k modelování konkrétního příkladu ITS systému. Architektura systému musí být definována ve třech základních rovinách objektová, strukturní a záměrová. V případě architektury ITS je možné analogicky tyto roviny převést na architekturu funkční (funkčních bloků), komunikační (datových toků) a fyzickou (interpretující cílovost v chování fyzických subsystémů). Konečným cílem tvorby architektury je vytvořit dostatečně vhodné podmínky pro tvorbu modelů konkrétních systémů tak, aby věrně popisovaly daný reálný příklad. Toho využíváme k řešení základních úloh návrhu systému a rozšíření jeho funkcionality: optimalizace systému analyzování a úpravy systému, odstranění systému odstranění funkcionality. V jednotlivých architekturách tak musí být model příkladu zobrazitelný tak, aby byla možnost na modelu zkoumat chování systému ve výše uvedených situacích Funkční architektura terminálu V rámci popsaného uspořádání se k nákladní dopravě vztahují funkce uspořádané do 8. kapitoly ITS architektury. Následující výběr funkcí architektury je vytvořen k popisu výše uvedených příkladů a byl proveden z makrofunkce Management nákladní dopravy, která se týká řízení nákladní přepravy a řízení vozového parku (flotily dopravních prostředků). Funkce architektury ITS: 8.1 Řízení pohybu zboží a nákladní přepravy 53

54 8.2 Řízení obchodní flotily 8.3 Řízení dopravních prostředků / řidičů / nákladu / vybavení Funkce: 8.1. Řízení logistických procesů a nákladní dopravy Popis: Funkce by měla obsahovat aktivity spjaté s tokem logistického řetězce od odesílatele k příjemci zboží a měla by řešit intermodální dopravní procesy a optimalizaci při uvážení udržení mobility, bezpečnosti a ochrany životního prostředí. Budou zpracovávány informace z celé řady zdrojů v rámci této makrofunkce, i z makrofunkcí jiných, nebo z externích zdrojů od terminátorů. Komponenty: Správa přepravně obchodních transakcí Příprava přepravní operace Správa dopravně přepravních operací Ocenění dopravně přepravní operace Řízení a synchronizace intermodální dopravy Vstupující logické datové toky: opr.rdt_naklad_transakce_data eps.psp_sklad_odpoved uzp.odpoved_na_prepravu_nebezpecneho_nakladu uzp.id_potvrzeni msy.mnd_informace_z_jineho_modu opr.pre_vstup_data nd_flotila_data nd_zadost_pro_oblast_rezervace Vystupující logické datové toky: nd_akce_oblast_rezervace nd_dopravovane_zbozi_data nd_dopravovane_zbozi_stav_zadost nd_zakonne_dokumenty_pro_dopravovane_zbozi rdt.odj_naklad_stav rdt.odj_naklad_transakce_data psp.eps_sklad_zadost uzp.celni_deklarace uzp.zadost_pro_prepravu_nebezpecneho_nakladu mnd.msy_informace_zadost_mody pre.opr_vystup_data Funkce: 8.2. Řízení dop. prostředků dopravců Popis: Funkce by měla pokrývat aktivity spojené s plánováním, správou, rozvojem a údržbou vozového parku a jeho zdrojů. Informace by měly být předávány se všemi možnými uživateli mimo makrofunkci, mimo všechny makrofunkce, externě přes terminátory. Velké množství dat by se mělo předávat s funkcí (8.3), pokud bude úzká vazba mezi řízením provozu a řidičem. Komponenty: Řízení dopravních transakcí pro více dopravních prostředků Řízení dopravních operací Ocenění hodnoty dopravní operace 54

55 Vstupující logické datové toky: zs.nd_incident_oznameni_potvrzeni opr.odp_naklad_transakce_data rdc.rnv_vstup_management_data eps.pdp_vyjimecny_zdroj_nabidka uzp.odpoved_pro_registraci_flotily uzp.poruseni_zakona_nasledek opr.svp_vstup_data nd_dopravovane_zbozi_data nd_zdroj_klientsky_profil nd_zdroj_komercni_informace nd_zdroj_provozni_informace nd_zdroj_regulace_data nd_zdroj_zakonne_informace nd_zdroj_prenos_data ci.nd_pozemni_cesta_a_dalsi_informace Vystupující logické datové toky: nd.zs_incident_oznameni nd.ci_pozemni_informace_a_zadost nd.pd_podvod_oznameni nd_flotila_data nd_management_prenos_data odp.odj_flotila_data rnv.rdc_prace_informace pdp.eps_vyjimecny_zdroj_zadost uzp.zadost_pro_flotila_registrace_a_platba svp.opr_vystup_data nd.ci_informace_a_zadost Funkce: 8.3. Řízení dopravních prostředků/ řidičů/ nákladu/ vybavení Popis: Funkce v oblasti řízení nákladní přepravy a flotily dopravních prostředků poskytuje funkčnost pro řízení z kabiny nákladního vozidla/prostředku. Tato funkce je rozdělena do 3 funkcí nižší úrovně: Řízení zadání a objednávka dopravy, Monitorování prostředků a Obtíže s předpisy Funkce je odpovědná za řízení objednávky přepravy pokrývající zásilky zboží vozidlem. Provádí to v reakci na podrobnost objednávky, kterou obdržela od jiné funkce v oblasti Řízení nákladní přepravy a flotily.od druhé funkce obdrží výsledná data od jiné funkce - řízení zdrojů-surovin. Třetí funkce kontroluje procesy vyhovění využitelným předpisům. Tyto budou skryty tak jako oblast odpovědnosti řidiče (přestupky). Přístup k datům vyplývajícím z kontroly je podmíněn pro řidiče a orgány státní správy. Tento přístup k těmto datům obsahuje přiměřenou ochranu a kontrolu pro prevenci. Činnosti ve všech funkcích jsou řízeny řidiči nákladních vozidel přes rozhraní (interface) uvnitř každé z nich. Řidič často ovlivňuje funkce v činnostech přičleněných k Řízení vozového parku, protože tyto funkce nemají jistotu v činnostech nákladních vozidel a k nimž nemá dispečink parku/flotily přímý přístup. Databáze palubního PC v datovém skladu zaznamenávají všechny informace o každém zboží odvezeném vozidlem. Komponenty: Řízení zadání a objednávka dopravy Monitorování prostředků Dodržování předpisů Zajištění přístupu ke komfortním službám Vstupující logické datové toky: ep.nd-platba_potvrzeni rv.nd-dopravni_prostredek_data 55

56 ci.nd_na_palube_cesta_a_dalsi_informace pd.nd_podvod_oznameni rdc.rnv_vstup_data znd.vstup_data ulk.nakladni_vozidlo_pozice dpr.nvo_dopravni_prostredek_senzor_data nd_management_komercni_informace nd_management_incident_informace nd_management_operacni_informace nd_management_zadost nd_management_zakonne_informace nd_management_prenos_data Vystupující logické datové toky: nd.rv_telematika_specificka_data nd.ci_na_palube_informace_a_zadost nd.pd_naklad_data nd_zdroj_provozni_informace nd_zdroj_regulace_informace nd_zdroj_prenos_data rdt.odj_naklad_stav rnv.rdc_vystup_data znd.vystup_data nvo.dpr_vystup_data Tab Detailní popis funkcí 8.1., 8.2., 8.3. Při tvorbě rozsáhlejšího ITS systému samozřejmě dochází i ke sdílení funkcí mezi jednotlivými kapitolami. Pro umístění takové funkce v rámci celé architektury pak musí rozhodnout expertní odhad majoritního významu funkce (y tohoto důvodu je také nutné aby architektura byla dlouhodobě spravována týmem specialistů, kteří ji budou udržovat v aktuální a jednotné podobě) Komunikační architektura terminálu Základem je určení dvojic funkcí které spolu v rámci modelu systému na dané rozlišovací úrovni spolupracují. Tento fakt vyplývá z definovaných uživatelských potřeb (zřetězenných činností v silných procesech systému) a dále z hierarchie funkční architektury. V případě, že byl již na úrovni funkční architektury model systému plně identifikován, lze převzít informační architekturu z celkové architektury ITS, je však nutné prověřit správnost převzaté architektury podle uživatelských potřeb. Zásadní je volba jednotné metriky v rámci celého zřetězeného procesu na dané rozlišovací úrovni. Na základě úloh o společném rozhraní lze definovat vazby mezi jednotlivými funkcemi, které vytváří informační (datové) toky v systému. Pro velkou rozsáhlost množiny datových toků není možné na tomto místě jmenovat všechny informační vazby mezi jednotlivými funkcemi, ani v rámci provedeného výběru kapitoly 8., v předchozím bodě B.4. Nicméně je třeba uvést, že mezi těmito vybranými funkcemi jsou v rámci architektury expertně definovány datové toky na základě výš uvedených principů. Celkově tedy pro další práci na příkladu budeme pracovat s následujícími toky: - informační vazby v architektuře ITS (pro zjednodušení budeme pracovat jen s výběrem dle bodu B.4) - informační vazby mezi funkcemi architektury ITS a okolím (terminátory) 56

57 - informační vazby vzniklé rozšiřováním funkcionalit (viz. dále Návrh subsystému ITS) Fyzická architektura terminálu Z výše uvedeného popisu příkladu můžeme vytvořit následující seznam ITS systémů v terminálu. Název systému Uživatelé Vazby na další ITS Dakosy Boatracs, terminátoři Terminál, dopravce SEEDOS ZAPP Terminál, přepravce, dopravce, terminátoři Terminál, státní správa Dakosy Dakosy ZOODIAK/DOUANE GEGIS Terminál, státní správa Terminál, přepravce, dopravce, terminátoři Dakosy Dakosy Boattrackcs Dopravce Dakosy, terminátoři Inmarsat Přpravce, dopravce terminátoři Bolero Přpravce, dopravce terminátoři Tab Fyzické systémy v ITS logistického řetězce Pro vytvoření architektury je nutné systémy uspořádat z hlediska jejich hierarchie a významu pro celý ITS systém. Protože se jedná převážně o expertní řešení problému a je zde vysoká pravděpodobnost, že při jednotlivých řešeních by vznikaly zásadní odchylky, je vhodné přihlédnout k doporučenému uspořádání dle architektury ITS. Nebudou-li pro popis dané reálné situace jednotlivé fyzické systémy v architektuře již zadány, lze projít specifikace jednotlivých skupin a systém zařadit dle jeho silných funkcí (např. jako lokalizační zařízení, evidenční systém, atd.). Ze zařazení do konkrétní skupiny lze na principu dědičnosti vlastností pro tento systém přejmout mnohé vlastnosti objektově definované pro celou skupinu. V dalším kroku vybereme systémy tvořící ITS terminálu, nebo s přímou vazbou na ITS terminálu (součást podstatného okolí). 57

58 datové toky Obr Fyzická architektura ITS terminálu Pro další práci s ITS systémem terminálu je vhodné znát všechny silné procesy, které v systém řeší. V úrovní funkční architektury jsou tyto procesy dále dělitelné na jednotlivé činnosti menších funkčních seskupení (popř. samotných funkcí). Produktem procesů ITS systému, ve fyzické dimenzi popisu, jsou služby, které tento systém produkuje. Kontrolou vhodné koncepce služeb je uspokojení uživatelských potřeb, které musí být definovány jako první krok veškerého návrhu práce ITS systému. Uživatelé ITS terminálu jsou: - dopravci (procesy přemístění ve všech dopravních druzích), - přepravci (organizátoři dopravních i nedopravních procesů), 58

59 - terminál (procesy nedopravního typu v logistickém řetězci), - terminátoři (činnosti ohraničující logistický řetězec). V následující části jsou popsány stávající fyzické systémy v multimodálních přepravních systémech (tak jak je zadáno v architektuře ITS), které musí být vzaty v úvahu při návrhu fyzické architektury. V současné nákladní dopravě se v celém světě používá mnoho národních spedičních systémů a z nich je pro názornost uvést některé používané zejména u nás v ČR a v Evropě. Zásadně se jedná o dva nezávislé informačně řídící systémy systémů družicového spojení ve vodní i v návazných dopravách a to: rádiové určování polohy pomocí družic a řešení úkolů návazných inteligentních řídících a naváděcích, provozních, bezpečnostních systémů, přenos zpráv a dat přes satelity. Ve multimodální dopravě existují družicové systémy: INMARSAT - komerční navigační systém, je nejrozšířenějším pro oceánskou plavbu (International Maritime Satellite Organisation). GPS NAVSTAR, systém ministerstva obrany Spojených států, umožňující určit polohu přijímače kdekoli na Zemi se systémy řízení a navádění vojenských mobilních jednotek.dnes se využívá v mnoha civilních oborech a i v dopravě. BOATRACS - základem je systém firmy Qualcomm - OMNITRACS umožňující určit polohu přijímače na kontinentálním území USA. Systém je vhodný zejména pro sledování pohybu dopravních prostředků ze skupiny uživatele systému zejména v silniční a vodní dopravě a příp. u dalších uživatelů. Tento byl aplikován nad evropou pomocí dvou družic a je provozován jako systém firmy Alcatel Qualcomm a společnosti Eutelsat EUTELTRACS pro automobilovou dopravu a ve vodní dopravě jako BOATRACS a umožňuje určovat polohu kdekoli v Evropě. Multimodální doprava používá další řídící a datové systémy nákladní a osobní plavby jako: UN/EDIFACT Electronic Data Interchange For Administration, Commerce and Transport je mezinárodní standard pro elektronický přenos dat - Normy ISO9735 a ČSN ISO 9735 a Usnesení vlády ČFSR č. 440/1990 Sb. o zavedení v ČR a SR DAKOSY Daten-Komunikations-Systeme fur Verkehrswitschaft je komunikační a informační systém elektronického přenosu dat pro oblast dopravního hospodářství (dopravy, přepravy) v přístavu Hamburk. Skládá se z programů zpracovávajících další pracovní postupy : SEEDOS (Seehafen- Dokumentations-Systém), Ships (Schiffsabfahrts- und Informations-Systém), ZODIAK/DOUANE (Zoll-Kommunikations-Systém), GEDIS (Gefahrgut- Information-Systém), HABIS (Hafenbahn-Betriebs- undinformationssystem) a dalších programů. BOLERO - komunikační a datový systém elektronického přenosu dat v námořní dopravě založený na základě námořního konosamentu (Bill of Loading) s dalšími programy -Nakládací a manipulační systém se zbožím na námořní lodi s vazbou na přístavy, návaznou dopravu a s dalšími optimalizačními, ekonomickými a personálními kalkulacemi přeprav a provozu lodí. 59

60 TELEPORT logistické spojení mezi přístavem Duisburg Ruhr a dopravci, přepravci pomocí elektronické plavební mapy s datovým a hlasovým komunikačním systémem Vnitrozemská vodní doprava používá další řídící a datové systémy nákladní a osobní plavby jako: CONDOR Container- Duisburk Opti-modal Rotterdam slouží kontejnerové kombinované dopravě a je včleněn do EDI a pracuje v holandském systému datové sítě INTIS DAKOSY Daten-Komunikations-Systeme fur Verkehrswitschaft, Hamburg COMPASS - Computerorientierte Metode fur Planung und Ablaufsteuerung im Seehafen, Bremen WADIS Warendispositions- und Informationssysteme, Bremen optimalizuje přístavní práce mezi námořní a vnitrozemskou dopravou. V jednotlivých dopravách multimodální dopravy se dnes používají tyto další telematické systémy: ARTEMIS - železniční systém řídící dopravu CIR-ELKE elektronický systém integrované dopravy automobilové dopravy na železnici, DEUFRACO M německo-francouský bilaterální systém železniční dopravy DIBMOF otevřený radiový komunikačně přepravní systém pro železniční a silniční dopravu ETCS kontrolní systém evropských železnic GIPAS - železniční zbožový, informační, plánovací, ekonomický a řídící systém TELEROUTE elektronický zbožový systém pro evropskou silniční nákladní dopravu. V provozu přístavů a překladišť multimodální dopravy existují další řídící a datové systémy manipulace se zbožím, kontejnery, surovinami, atd.: LADAR satelitní systém kontejnerového terminálu Fy HHLA v Hamburku založeného na kombinaci Laseru / Radaru / DGPS. Čárový kód je dnes základem sledování zásilek kusového a baleného zboží a kontejnerů a jsou na něj navázány další komunikačně informační systémy Analýza ITS architektury reálného příkladu Popis příkladu, na němž bude demonstrován další postup vychází z provedené analýzy dopravy a přepravních potřeb ve IV. transevropském koridoru. Na základě reálných přepravních procesů realizovaných v rámci mezinárodní a vnitrostátní přepravy zboží multimodálními přepravními řetězci procházejícími vybraným terminálem v Lovosicích byl pro názornou demonstraci možností architektury ITS vybrán příklad Přepravy nebezpečné tekuté látky v kontejnerech (import). Speditér připraví a projedná přepravní trasu, doklady v elektronickém obchodním standardu u jeho provozovatele (Dakosy, Boatracs) na dané trase: Přístav Hamburk - překlad z kontejnerového terminálu HHLA na říční loď. 60

61 Vodní vnitrozemská doprava - po Labi z Hamburku do přístavu Ústí n.l. Přístav Ústí n.l. kontejnerový terminál - překlad zboží loď / vagon. Železniční doprava na místo určení - vlečka závodu se stáčecím překladištěm kyseliny do zásobníků závodu. Popis jednotlivých ITS systémů pro definovaný příklad: 1. Speditér využívá k řízení přepravy a přepravního řetězce elektronický informační a komunikační systém DAKOSY, který je kompatibilní s elektronickým řízením procesů kont.terminálu HHLA a který umožňuje: vystavení nákladních listů, faktur, dobropisů a účetnictví, elektronický přenos dat jako příkazy k nakládce/vykládce, bezpapírový přenos dokladů programem SEEDOS, který přes speditéra a i přímo informuje o zboží na cestě jednotlivé články přepravního řetězce (dopravce, překladiště, příjemce zboží), program ZODIAK/DOUANE a ZAPP zavádí zboží do celního systému SRN celní údaje pro proclení zboží, zprávy pro hraniční celnice, popř. i další celní odbavení i v ČR, program GEGIS je databankou o pohybu nebezpečného zboží, jeho klasifikaci, třídy nebezpečnosti, chemických a fyzikálních vlastnostech zboží, předpisech pro dopravu, označování a balení. Obsahuje informace o nebezpečí při haváriích, opatření první pomoci, odstraňování následků nehod (Pokyny pro případ nehod Unfallmerkblatt). 2. Vodní vnitrozemská doprava po Labi -Hamburku / Ústí n.l. jako dopravce : používá satelitní polohový a komunikační systém Boatracs, zajišťuje bezpečnost dopravy nebezp. zboží podle nařízení správce toku WSA (označení lodě, zvláštní kotviště, hlášení polohy), celní odbavení (nahlášené systémem DAKOSY z Hbg), hlásí plavbu štábu přeprav nebezpečných věcí Severočeského kraje, hlásí předpokládaný příjezd do přístavu Ústí n.l.a žádá o přistavení k vykládce 3. Přístav Ústí n.l. kontejnerový terminál - překlad zboží loď / vagon, terminál pracuje podle platného Provozního a Havarijního řád pro skladování a manipulace s kontejnery a zejména obsahujících nebezpečné látky: žádá o přistavení vagonů na den xx, objednává přepravu od dopravce na den yy 4. Železniční doprava terminál Ústí n.l. - závod Břeclav, má vlastní vlečku, Dopravce ČD: oznamuje předpokládaný čas příjezdu vagony s kontejnery 61

62 hlásí průjezd vlaku štábu přeprav nebezpečných věcí Severočeského, Středočeského, Východočeského a Jihomoravského kraje, dojednává se správcem vlečky odběr vagonů ve stanici xy. 5. Překladiště na vlečce závodu překladiště má platný Provozní a Havarijní řád pro stáčení kyseliny do zásobníků závodu a podle něho postupuje předání kyseliny. Překladiště zajistí vyčištění kontejnerů pro zpáteční dopravu odesilateli, popř. pro následnou přepravu. Tato analýza slouží k vytvoření souhrnu procesů probíhajících v rámci vybraného místa na logistickém řetězci. Tímto místem je dopravní terminál logistického centra Lovosice. V tomto reálném místě můžeme za předem daných podmínek simulovat práci ITS systému (reálného i fiktivního). Základním předpokladem pro sestavení kvalitního modelu ve všech třech základních úlohách příkladu je znalost následujících vstupních podmínek: a. uživatelské potřeby, b. stávající funkční architektura, c. stávající fyzická architektura, d. stávající informační architektura, e. platné standardy (zákony a normy). Znalost těchto podmínek se musí týkat jak subsystému samotného, tak jeho podstatného okolí. Důležitým parametrem je volba vhodné rozlišovací úrovně, která musí být ve vztahu k modelovanému problému vhodně stanovena. Při řešení jednotných úloh je vhodné pracovat v jednotlivých krocích na různých úrovních, nicméně je důležité aby sestavený model pro řešení konkrétní úlohy byl celý sestavený na jednotné rozlišovací hladině. Funkční popis potřeby Uživatelé funkcionality Vazby na Terminátory Systém EDI Terminál, dopravce, Zasílatel, odběratel přepravce Systémy řízení logistického řetězce Terminál, přepravce, dopravce Satelitní polohovací systém Přepravce, dopravce Komunikační systém Hlášení přepravy nebezpečného zboží Sledování zboží v terminálu Systém celního odbavení Přepravce, dopravce Přepravce, terminál Terminál, přepravce, dopravce, terminátoři Dopravce, přepravce,terminál správní orgány správní orgány, zasílatel, odběratel Tab Uživatelské potřeby definované v zadání příkladu Pro uživatelské potřeby definované v příkladu (Tab. 2.5) je možné z obecné architektury ITS terminálu přiřadit následující funkce 3.úrovně. 62

63 Obr Tvorba architektury příkladu 63

64 Funkční popis potřeby Funkce Vazby na Terminátory Systém EDI Systémy řízení logistického řetězce Řízení přepravních operací Řízení a zadání dopravy Zasílatel, odběratel Řízení obchodně přepravních transakcí Satelitní polohovací systém Komunikační systém Hlášení přepravy nebezpečného zboží Sledování zboží v terminálu Systém celního odbavení Řízení administrativních procesů Řízení a synchronizace multimodální dopravy Monitorování prostředků Řízení dopravních operací Sledování a řízení manipulačních procesů Řízení skladovacích procesů Řízení zdrojů terminálu Řízení celních služeb Dopravci, přepravci správní orgány správní orgány, zasílatel, odběratel Tab Funkce architektury ITS příkladu Proces srovnání s obecnou architekturou může přinést upozornění na chybné nebo nekompletní zadání uživatelských potřeb, absenci informačních systémů pro vykonávání požadovaných funkcí a další výsledky. 64

65 Závěr Obr Funkční architektura ITS příkladu Ze zpracované architektury příkladu lze vyčíst doporučené uspořádání systému ITS a využití vhodných technologií k praktické realizaci systému ve fyzické úrovni. Při využití globální ITS architektury lze z příkladu zároveň vyčíst doporučení k napojení na stávající systémy ITS, doporučení k funkční realizaci příkladu (rozšíření, odstranění duplicit, přeskupení funkčních bloků) a doporučení k využití informační struktury, která je k dispozici v rámci kapacit již realizovaných ITS systémů. Při návrhu nového systému lze pokračovat v detailním návrhu ITS systému, kdy na tento postup by pak dále měly navázovat následující kroky návrhu systému: detailní konceptuální model ITS systému, detailní technologický model ITS systému, konečný posudek návrhu ITS systému, detailní návrh ITS systému. Budeme-li architekturu systému zpracovávat v kontextu globální architektury, lze dále zvoleného postupu s výhodou použít nejen při návrhu ITS systémů jako takových, ale zároveň k plánování dynamického vývoje systému podél jeho celého životního cyklu. Lze vytvořit 65

66 doporučení pro organizační strukturu všech subjektů (popř. až jednotlivých pracovníků) pracujících s tímto systémem. Jestliže budeme v systému dlouhodobě sledovat (nebo předpovídat) jeho základní silné procesy, můžeme v kterémkoli okamžiku sestavit jeho požadavky na úpravu jeho funkční nebo komunikační architektury. Můžeme-li například předpovídat příchod nové technologie, můžeme naopak podle inovované fyzické architektury systému klást požadavek na změnu fyzické nebo komunikační architektury. Popsaný postup lze také chápat jako metodiku poskytující obecný (sjednocující) základní rámec pro činnosti spojené s vývojem ITS systému. Tímto vývojem jsou chápány tři základní úlohy ve správě systému: výstavba (rozšíření implementace funkčního bloku), optimalizace (změna uspořádání funkčních bloků), redukce (omezení funkcionality vyjmutí funkčního bloku). S přijmutím této metodiky je však nutné zároveň upřesnit výběr řady technik a nástrojů pro konkrétní práci se systémem na jednotlivých úrovních jeho správy. Je nutné každou konkrétní situaci doplnit upřesňujícími specifikacemi, aby mohla být stanovena technologie vývoje pro konkrétní ITS systém. Tato technologie vyplyne z použitého vývojového prostředí (organizace práce se systémem) a implementačního prostředí (způsob práce se systémem). Cílem budování ITS systému je vytvořit takový systém, který má optimální kvalitu a je adekvátně řízen. Konečné výstupy je nutné cíleně strukturovat tak, aby mohla být hodnocena jejich efektivita podle obecně platných norem a standardů. Ve standardu ISO/IEC 9126 je definováno šest charakteristik jakosti programovaného produktu, které by s měly vztahovat i na výstupy uvedeného příkladu (jakožto i veškerých výstupů práce s architekturou ITS). Jsou to funkčnost, spolehlivost, použitelnost uživatelem, efektivnost, udržovatelnost a přenositelnost. Práce s architekturou ITS, jak již bylo zmíněno, je jedním z kroků návrhu finální podoby systému, nicméně již tento krok nesmí být proveden tak, aby nebyly splněny požadované parametry systému. 66

67 3. Základní ekonomická analýza ITS 3.1. Analýza ekonomických přínosů ITS systémů Systematický přístup k rozvoji inteligentních dopravních systémů vytváří předpoklad vstupu metodiky, respektive metodik pro posuzování užitných vlastností systémů, subsystémů a aplikací ITS. Pojmu užitné vlastnosti systému je dnes přisuzováno mnoho významů odvislých od pohledu uživatelů aplikací. Například dopravce či správce infrastruktury bude zajímat, co rozvíjení systémů a subsystémů ITS přináší organizaci, kolik ušetří pracovníků, provozních nákladů, kolik nových znalostí získají manažeři všech stupňů tak, aby byly konkurenceschopní. Státní správu a územní samosprávu zase zajímá o kolik se sníží nehody, zvýší se bezpečnost na silnicích, jak je nakládáno s dotacemi do osobní dopravy atd. Projektanty a konstruktéři ITS systémů, subsystémů a aplikací zase zajímá cena vlastního řešení architektury v HW a SW oblasti tak, aby jimi navrhované řešení nebylo investičně, ale i provozně nákladnější než vlastní přínosy aplikací, subsystémů a systémů ITS. Systematický přístup k rozvoji ITS umožní tvorbou přesně definovaných rozhraní a vstup investičních prostředků z netradičních zdrojů 3. Investory do oblasti ITS bude nejen zajímat, jak investičně náročný bude vlastní systém, subsystém případně aplikace, jak náročný bude jeho provoz, ale i zejména kolik tržeb bude možno realizovat tak, aby se vložené prostředky vrátily. Užitná vlastnost systému je tedy množina přínosů pro jednotlivé uživatele. Jednotlivé přínosy se dají přesně ekonomicky vyčíslit 4. Je potřebné si však uvědomit, že i vlastní vývoj, projektování a realizace ITS systémů představuje na straně druhé i množinu nákladů 5. Náklady mají také jasný ekonomický rozměr. Užitná vlastnost ITS architektury je tedy vztah mezi přínosy a náklady ITS řešení. Přínosy ITS se pohybují od podpory činnosti organizace typu dopravce, správce infrastruktury až po činnost dodavatele ITS služeb 6 jako je například systémy elektronického mýtného 7. Pro stanovení výchozích směrů rozkladu užitných vlastností telematických systémů bylo potřebné analyzovat stav současného vnímaní přínosů telematických aplikací pro uživatele ITS služeb Služby pro cestující a řidiče Například informace o dopravních cestách, o dopravních spojích, dopravní informace prezentované řidičům prostřednictvím informačních systémů na dálnicích, dopravní informace presentované prostřednictvím rádia, televize nebo internetu, informace zasílané řidičům do automobilů (dynamická navigace, kongesce atd.), služby mobilních operátorů, atd. Dobře je vnímáno poskytování dopravních informací prostřednictvím rádia, televize, internetů, prostřednictvím informačních tabulí. Méně již prostřednictvím mobilů, služeb 3 Banky, pojišťovny, ale i soukromý kapitál atd. 4 Pomocí tvrdých (pevných) metrik 5 Například investičních, provozních, atd. 6 Například v programech PPP 7 Elektronické platby v dopravě mýto, odbavovací systémy 67

68 mobilních operátorů, zkrátka veškerých služeb, které koncovému uživateli přinášejí náklady 8. Výjimkou není ani dynamická navigace. Náklady na tyto služby koncový uživatel nevnímá. Náklady na tvorbu služeb i v budoucnu pravděpodobně musí nést stávající investoři 9. Přínosem pro stávající investory je potom zvýšený počet cestujících v hromadných dopravních prostředcích, snížení počtu kongescí, méně CO 2 v atmosféře, méně nehod atd. Lze ale přepokládat i vývoj v oblasti dynamické navigace tedy zvýšení zájmu uživatelů o tyto služby Služby pro správce infrastruktury Typicky pro správce dopravních cest jako je například Správa železniční dopravní cesty (SŽDC), Ředitelství silnic a dálnic ČR (ŘSD) atd., správci dopravních terminálů jako je například Správa letišť atd.. K základním službám ITS pro tyto uživatele patří například: sledování kvality dopravních cest, řízení údržby dopravní infrastruktury, sledování a řízení bezpečnosti dopravního provozu, ekonomika dopravních cest, atd. Přínosy služeb touto skupinou uživatelů jsou vnímány dobře zejména v oblasti IS/IT podpory řízení ekonomiky, v oblasti řízení údržby dopravní silniční infrastruktury, stavu infrastruktury, sledování kvality dopravních cest, atd. V železniční dopravě je vnímán vliv technického vybavení tratí ITS systémy na náklady údržby a obsluhy dopravní cesty. 10 Letecká a železniční doprava potom pokládá důraz na řízení provozu na dopravní infrastruktuře, jako je například řízení bezpečného pohybu vlaků, respektive vozidel po letištní ploše. Řízení rozvoje ITS v jednotlivých organizacích je však rozdílné a v současné době nevytváří předpoklad rozvoje služeb s vyšší přidanou hodnotou. Nejsou s výjimkou železnic vytvořeny podmínky pro efektivní sledování nákladů organizace celkem a v jednotlivých segmentech. Nicméně vývoj i v oblasti managerské ekonomiky v těchto organizacích bude nevyhnutelný. Proto přínosy v cílovém stavu je možno sledovat ve snížení nákladů údržby, efektivním využívání prostředků údržby, zvýšení bezpečnosti atd Služby pro provozovatele dopravy Typicky se jedná o dopravce. Volba dopravních cest a nejvýhodnějších tras, řízení oběhu vozidlového parku, dálková diagnostika vozidel, dodávka náhradních dílů, kontrola charakteru vedení vozidla atd. jsou stručné charakteristiky služeb jednotlivých aplikací v tomto segmentu. Protože na trhu dopravců 11 silně působí již liberální principy, lze konstatovat příznivé vnímání přínosů, ale i nákladů spojených s ITS touto skupinou uživatelů služeb. Většina dopravců již dnes sleduje náklady a hospodaření organizace celkem, ale i v jednotlivých položkách směřovaných například na prostředek dopravy, prostředek údržby, ale i ITS. Proto kvantifikace přínosu bude možno jednoznačně určit, ale také sledovat například v okruhu snížení spotřeby pohonných hmot, snížení osobních nákladů, atd. 8 telefonní poplatek, příplatek k ceně vozidla, jízdenky atd. 9 státní správa a územní samospráva, dopravci, správci infrastruktury 10 Jednoznačným metrikem nákladovými položky v Kč. 11 S výjimkou ČD 68

69 Služby pro státní správu a územní samosprávu Napojení systémů dopravní telematiky na informační systémy veřejné správy (ISVS), sledování a vyhodnocování přepravy osob a nákladů, řešení financování dopravní infrastruktury (fond dopravy), nástroje pro výkon dopravní politiky měst, regionů, státu, jako je například elektronické mýto, kontrola jízd na červenou, kontrola rychlosti, sledování kázně řidičů, evidence řidičských oprávnění atd. jsou základní a rozvojové služby ITS v tomto segmentu. Pohybujeme se v oblasti veřejných rozpočtů, proto i vnímání přínosů a nákladů jednotlivými uživateli je rozdílné. Například od zavedení elektronického mýtného se očekává přínos do fondu dopravy, naproti tomu chybí vnímání elektronických plateb v celém konceptu rozvoje ITS s možností náběhu dalších ITS služeb, ale i celkových nákladů realizace. Jsou vnímány možnosti elektronických plateb ve veřejné dopravě, jsou také vnímány přínosy kontrolinků veřejné dopravy pro zajištění dopravní obslužnosti a kontrolu dotačních prostředků. Přínos systematického rozvoje ITS právě pro tuto oblast služeb vytváří předpoklady vstupu netradičních investičních prostředků 12, například do oblasti elektronických plateb. Naproti tomu služby represivních nástrojů ITS jako je například kontrola jízdy na červenou, měření rychlosti, dopravní statistika atd. je plně v režii státní správy. Přínosy rozvoje ITS v této oblasti služeb lze kvantifikovat (sledovat) a to například ve snížení počtu dopravních nehod, zvýšení kázně řidičů, ekonomických přínosů do fondu dopravní infrastruktury, úspora dotačních prostředků do veřejné dopravy, ale také kvantifikace externích nákladů 13, atd Služby pro bezpečnostní a záchranný systém Typicky se jedná o integrovaný záchranný systém. Propojení systémů dopravní telematiky na integrovaný záchranný systém a bezpečnostní systémy státu, zabezpečení lepší organizování zásahů při likvidaci havárií, nehod, zvýšení prevence proti vzniku mimořádných událostí s ekologickými důsledky, ale také zabezpečení rozkladu nákladů spojených s odstraňováním důsledků dopravních nehod. Vnímání přínosů služeb ITS v tomto segmentu u jednotlivých aktérů (organizačních jednotek) je na dobré úrovni. Je dobře vnímána zlepšená organizace zásahu, navádění vozidel záchranné služby na místo zásahu, ale i prevence nehod plynoucí z organizace přepravy nebezpečných nákladů a věcí a také je možno sledovat snahu o propojení ekonomických aplikací k přesnému vyčíslení nákladů jednotlivých zásahových složek. Vnímání nákladů na ITS je ovlivněna značným organizačním rozptylem. Opět investiční zdroje (náklady) na rozvoj ITS jsou rozdílné. Částečně jdou ze státního rozpočtu, částečně z rozpočtů krajů a částečně z rozpočtů měst. Přesto lze sledovat a kvantifikovat přínosy zejména v úspoře prostředků záchranných složek (optimalizace), pohonných hmot, snížení důsledků nehod a mimořádných událostí, tvorbě předpokladů pro internacionalizaci externalit 14, atd. 12 Vnější investoři programy PPP. 13 Základní předpoklad pro stanovení podmínek harmonizace dopravy 14 Například: přiřazení nákladů na jeden km silnic (hasiči, zdravotníci, bezpečnost, důsledky nehod atd.) 69

70 Služby pro finanční a kontrolní instituce Typicky pojišťovny, leasingové společnosti, banky atd. Elektronická identifikace vozidel a nákladů, sledování a vyhledávání odcizených vozidel, elektronické platby za poskytnuté ITS služby (EFC), elektronické obchodování v nákladní dopravě (voda, železnice, silniceintermodální a multimodální doprava), atd. jsou typickými aplikacemi v této oblasti. Vnímání přínosů v této skupině uživatelů je opět na velmi dobré úrovni. Například pojišťovny chystají poskytovat slevy při pojištění vozidel a přepravovaného nákladu pokud jsou přepravní prostředky vybaveny sledovacími a vyhledávacími aplikacemi ITS. Banky jsou ochotny poskytovat slevy za služby elektronických plateb 15, protože jim to zvýší počet zákazníků, atd. Vnímaní nákladů potřebných na provoz a pořízení ITS technologií je v této skupině na velmi dobré úrovni. Například banky jsou připraveny investovat do systémově připravených projektů rozvoje ITS, jako je například elektronické mýtné v silniční dopravě, v intermodální dopravě, ve veřejné dopravě, atd Rozdělení ekonomických přínosů ITS systémů Systémově řešené ITS aplikace ovlivňují vlastní organizaci práce podniku, její organizační struktury, ale mají dopad i na vlastní náklady organizace, které výrazně ovlivňují hospodaření organizace 16. Základní užitné vlastnosti ITS lze rozdělit do následujících čtyř skupin: Organizační (podnikové) procesy kvantifikace vlivu architektury ITS na činnost organizace, její organizační strukturu atd. Procesy tvorby vlastního ITS systému kvantifikace investičních a provozních nákladů vlastní fyzického řešení ITS systému - podpora vývoje ITS systému, návrh a projektování ITS architektury, atd. (systém technické podpory organizačních jednotek a vnitřních a vnějších business procesů). Vnitřní business procesy - ekonomická váha podnikových (organizačních) procesů uvnitř organizace (kvantifikace ekonomických přínosů vazeb mezi jednotlivými organizačními jednotkami). Vnější business procesy - ekonomická váha vnějších business procesů podniků a organizací (vazba investora a organizace, ekonomické vazby mezi jednotlivými podniky a organizacemi). 15 Odbavovací systémy pro cestující 16 Zatěžují zejména fixní náklady 70

71 Vnější business procesy Podnikové(organizační)procesy ITS podpora podnikovým procesům Vnitřní business procesy Obr.3.1. Princip rozdělení procesů pro vyjádření užitných vlastností ITS 3.2. Podpora organizačních (podnikových) procesů Koncepčně sestavená architektura může být významnou podporou organizačním (podnikovým) procesům. Podnikové procesy jsou charakterizovány modely organizace vyjadřující podporu předmětu podnikání 17, kterým může být přeprava zboží a osob v případě dopravců, nabídka přepravních tras a její kvalita v případě správců dopravních cest, ale i nabídka služeb dopravní telematiky pro různé uživatele. Jedná se o podporu procesů organizací uplatňující, či využívající služeb dopravní telematiky 18 a organizací podnikající v oblasti služeb dopravní telematiky Přínos architektury ITS pro podnikové procesy Vzájemné sdílení informací mezi jednotlivými segmenty architektury ITS bude iniciativovat vznik nových aplikací (služeb), které výrazně ovlivní racionalizaci práce a řízení procesů uvnitř organizace. Například diagnostické systémy infrastruktury 20, spojené s rozvojem dynamické navigace, doplněné informacemi z pasportních a ekonomických aplikací umožní optimalizovat strukturu nákladových středisek údržby, jak je uvedeno na obr. 3.2 (rozšíření území údržby). 17 Například: Hiearchické, divizní atd. organizační uspořádání. 18 Dopravní telematika uvnitř podniku např. ČD, SŽDC, ŘSD atd. 19 Například: PPP programy, ousorcing, atd. 20 Dopravních cest, telekomunikačních sítí atd. 71

72 Stávající střediska Nová střediska- racionalizace Obr.3.2: Příklad optimalizace středisek údržby Základní organizační struktury organizací využívajících ITS Organizační struktura podniků využívajících služeb ITS je důležitým fenoménem pro tvorbu vlastní architektury a je zpravidla tvořena různým organizačním uspořádáním základních organizačních buněk nákladových středisek a hospodářských středisek, které jsou účelově uspořádány podle podnikatelských cílů organizace případně dopravního podniku. Rozvoj architektury IS/IT aplikací podporující ekonomiku podniků výrazně sledoval vlastní organizační strukturu. Například organizace hiearchického typu 21 (obr.3.3) byla podporována sálovými počítači později centralizovanými servery. Nevýhodou tohoto typu organizace je náchylnost k neustálým organizačním změnám a obrovské nároky na přenos informací mezi jednotlivými organizacemi uvnitř podniku. 21 Typicky ČD, ŘSD 72

73 Obr.3.3: Princip organizace hiearchické Druhým typem organizační struktury využívaným u organizací je divizní uspořádání (obr.3.4). IS/IT podpora využívá technologie PC. Nevýhodou této organizační struktury je postupný vznik informačních barier mezi jednotlivými subjekty (divizemi). Obr. 3.4: Princip divizního uspořádání organizace Novým progresivním organizačním uspořádáním je organizace flexibilní (obr. 3.5). Je charakterizována tvorbou virtuálních pracovních týmů. Systematické řešení ITS architektury 22 zahrnující vazbu mezi jednotlivými aplikacemi, subsystémy a systémy dopravní telematiky 23 umožní flexibilní přizpůsobení jakékoliv organizační struktuře, ale také tvorbu virtuálních obrazů o objektech a procesech organizace. 22 Informační, logická, funkční a fyzická architektura 23 Prostředky infrastruktury, prostředky pro řízení procesů na infrastruktuře, pasporty a ekonomické aplikace 73

74 Obr. 3.5: Princip organizace podniku moderního typu Příklad vazby užitných vlastností ITS aplikace a podnikových procesů Na obr.3.2. je principielní zobrazení redukce počtu nákladových středisek údržby a na obr.3.6 je zobrazen systémový model universálního řešení ITS podpory pro managera infrastruktury Dopravní cesta, dopravní terminál atd. 74

75 Dopravce Dopravce Dopravce MI 1 MI 2 MI n Rozhraní Subsystém účtování poplatků za dopravní cesty (terminál) Subsystém přidělování dopravních cest (terminálů) Subsystém řízení pohybu dopravních prostředků Managerský subsystém správce cest (terminálu) Telekomunikační prostředí - manager infrastruktury LDD 1 LDD 2 LDD 3 LDD n Obr.3.6: ITS podpora pro managera ITS podpora činnosti managera infrastruktury (Obr.3.6) na jedné straně podporuje efektivní, bezpečné organizování pohybu dopravních prostředků po dopravní infrastruktuře vzájemnými vazbami mezi aplikacemi ITS dopravní infrastruktury (LDD 1 n). Vzájemnou vazbou těchto systémů ITS, pasportů a ekonomiky vzniká managerský systém, který pomocí vnitřních business procesů podporuje vnější business procesy, které jsou na obr. 3.6 zobrazeny rozhraním pro nabídku služeb (vnější business) 25. Uvedený příklad je i příkladem 25 Nabídka tras, dopravních cest 75

76 možností systémového přístupu k rozvoji ITS, přičemž model je možno sestavit virtuálně bez ohledu na organizační strukturu organizace Procesy tvorby vlastního ITS systému Mají-li být přesně vyčísleny užitné vlastnosti ITS aplikace, subsystému, systému, je potřebné vyčíslit náklady vstupní - investiční, ale i následné provozní. Vyčíslení nákladů je velmi důležité pro: - projekt a návrh například telekomunikačního prostředí, - řešení bezpečnosti, dostupnosti a spolehlivosti atd., - rozhodnutí, zda ITS systém bude podnikový nebo bude nakoupen 26, - sestavení business modelu poskytovatelů služeb ITS, - atd. Vzrůst celkových fixních nákladů organizace za sledované období % 140,0 120,0 100,0 80,0 60,0 40,0 20,0 0, Rok Obr.3.7.: Vyjádření vzrůstu celkových fixních nákladů organizace za sledované období způsobený nasazením ITS Pro pochopení významu zařazení tohoto procesu do ekonomické analýzy ITS je nutno uvést vzájemné souvislosti, kdy například náklady na pořízení a provoz ITS systémů, subsystémů a aplikací výhradně zatěžují fixní náklady organizace. Na obr.3.7 je vyjádřen nárůst těchto nákladů u dopravní organizace způsobený rozvojem ITS technologií 27. Cílem systematického rozvoje ITS musí být snížení vlivu nákladů ITS na fixní náklady organizací nebo výrazné snížení nákladů v jiných nákladových položkách Struktura aplikace ITS Každá aplikace ITS se skládá z prostředků: sběru nebo pořízení informací 26 Ousorcován 27 Nesystémovým rozvojem rozvoj nepřinesl výraznou úsporu nákladů v jiné položce 76

77 přenosu informací zpracování informací IS/IT aplikace Prostředky sběru informací Prostředky přenosu informací Prostředky zpracování informací Obr Blokové schéma obecné ITS aplikace Následující vzorec vyjadřuje princip tvorby nákladů ITS aplikace: Cn =Nsi +Npi + Nzi (3.1) Přičemž Nsi jsou náklady na získání informace, Npi náklady na přenos informace a Nzi náklady na zpracování informace Systémové požadavky uživatelů K parametrům výrazně ovlivňujícím ekonomiku vlastní fyzické realizace ITS systému jsou specifikace systémových požadavků (parametrů) získaných analýzou potřeb uživatelů 28. Na příkladu rozkladu požadavku na dostupnost bude problematika specifikace systémových parametrů přiblížena. Dostupnost vyjadřuje požadavek na udržení provozuschopnosti aplikace ITS a je definována následujícím vztahem: D = ti ti + t 0i (3.2) kde t i - kumulovaná doba provozu objektu nebo množiny objektů, která definuje požadavek udržení provozuschopnosti v čase. t oi - kumulovaná doba obnovy objektu nebo množiny objektů, která definuje celkovou poruchu systémů v čase. Požadavek na dostupnost aplikace řídící dopravní proces je 95%. Aplikace je v provozu po celý rok trvale. Pro vývoj či projektování takovéto aplikace je nutno vyjádřit ze vztahu (3.2) ukazatel střední doby obnovy systému (to) tak, aby provoz této aplikace byl zabezpečen v požadovaných časových intervalech. 28 Bezpečnost, dostupnost, spolehlivost případně integrita 77

78 Definujme následující parametry: ti = hodin - kumulovaná doba provozu D = 0,95 - je hodnota požadované dostupnosti (systémový parametr) Ze vzorce (3.2) vyjádříme hodnotu to, kde dostaneme: i t (1 D) t0 = [ např. hod/rok ] ( 3.3) D Hodnota vychází v tomto příkladu to = 461, 05 hod/rok Objekt může být mimo provoz celkem 461, 05 hod v průběhu celého roku. Tato hodnota je vstupní informací pro vývoj jednotlivých aplikací, jejich projektování a realizaci a tato hodnota musí být dodržena v celém řetězci ITS, případně v subsystémech organizací Podpora vnitřních business procesů organizace (podniku) Vnitřní business procesy jsou ekonomickým zhodnocením jednotlivých podnikových procesů a na obr.3.1 jsou naznačeny jako ekonomické vazby mezi jednotlivými organizačními (podnikovými) jednotkami. Vnitřní business procesy mohou být nástrojem pro realizaci vnějších business procesů 29. Základní organizační jednotkou podnikových procesů jsou nákladové střediska a vzájemnými vazbami mezi nimi lze optimálně využít kapacit a možností daného podniku Přínos synchronizace informací pro vnitřní business procesy Důležitým fenoménem k zabezpečení plnohodnotného vyjádření hodnot v oblasti vnitřních 30 business procesů je synchronizace informací. Synchronizace informací usnadní jejich zpracování v centrech zpracování a vede k optimální architektuře ITS systému a tedy i k výrazným ekonomickým úsporám. Problematika synchronizace informací má také i technický rozměr. Optimalizace a zjednodušení vazeb uvnitř systému a okolí směřuje k jednoduššímu technickému řešení vzájemných vazeb, což vede ke stabilizaci celého systému a k výraznému zvýšení užitných vlastnosti jednotlivých aplikací. Synchronizaci informací pro podporu vnitřních business procesů je nutno zabezpečit v: parametru - jednotné značení objektů (např. most), událostí (např. nehoda) a procesů (např. údržba) v dopravně přepravním procesu v celém dopravně přepravním řetězci a okolí, přičemž nástrojem jsou parametrické synchronizace jsou číselníky, čase - událost, proces je sledován v reálném čase, či přesně definovaném časovém úseku, prostoru - jednotné umístění události, procesu a objektu v prostoru např. na dopravní cestě, přičemž nástrojem jsou také číselníky vycházející z reálné geodetické informace (např. získané ze systému GPS). 29 Snížením nákladů realizace předmětu podnikání vnějšího businessu 30 Ale i vnějších business procesů 78

79 Synchronizace informací vychází z metodických a legislativních rámců a musí být zajištěna u všech organizačních stupňů podniku jednotně tak, aby bylo možno implementovat technickou podporu vnitřním business procesům Příklady možné podpory vnitřních business procesů Příkladem technické podpory vnitřních business procesů může být systém pro sledování nákladů na 1km silnice, který je naznačen na obr.3.9, na základě kterého mohou být porovnány parametry jednotlivých nákladových středisek, atd. Náklady na 1 km komunikace Silniční úsek Obr.3.9: Sledování nákladů Dalším příkladem na obr může být sledování tržeb a nákladů jednotlivých vozidel hromadné dopravy osob na definovaných linkách. 79

80 Tržby Náklady Vůz(spoj) 01-n Obr. 3.10: Sledování ekonomiky veřejné dopravy 3.5. Podpora vnějších business procesů organizace ITS systémy výrazně podporují vnější business procesy organizací či podniků působících v celém dopravně přepravním řetězci, přičemž pojem vnější business je produkt organizace, podniku atd. Například produktem dopravce je přeprava zboží, měřítkem je např. tuna přepraveného zboží, nebo přeprava osob, kde měřítkem je počet přepravených osob a vzájemným jmenovatelem je tržba. Produktem správce infrastruktury např. v železniční dopravě je poskytování přepravních tras, či dopravní infrastruktury, měřítkem je trasa či 1 km přepravní trasy, tržbou je pak úhrada za 1 km nebo za celou trasu. Pro organizaci poskytující ITS služby jsou měřítka a produkty obdobné. Významným přínosem ITS systémů je potom působení ITS systémů jako podpora podnikovým procesům, vnitřním business procesům, která vede ke snížení nákladů a lepší organizaci, což se zpětně promítne do vnějších business procesů Příklad přínosu ITS systému pro podporu vnějších business procesů Produktem správce infrastruktury v železniční dopravě je cena za použití dopravní cesty. Podmínkou úspěchu na trhu v budoucnu bude schopnost snížení této ceny. Telematické aplikace jsou nástrojem tohoto vnějšího business procesu a poskytují nutné znalosti. V příkladu uvedeném v kap 3.7 je popsán rozbor nákladů realizace dopravního procesu po železniční infrastruktuře, které ovlivňuje vybavení železničních stanic zabezpečovacím zařízením. Zabezpečovací technika je základním stavebním prvkem železniční telematiky 31. Na obr je zobrazen vliv techniky do ekonomiky drah (C - cena realizace dopravního procesu, Cn - celkové náklady na zabezpečovací zařízení, N+V - provozní a ostatní náklady). 31 Poskytuje základní informace o pohybu dopravního elementu, je základním prostředkem přenosu ale i zpracování informací v regionální dopravě. 80

81 Pro podporu vnějších business procesů nás zajímá průběh křivek od položky 6 výše na ose x, který je výrazně ovlivněn systematickým rozvojem techniky (vyznačená část) a položka 8 již také teoriemi ITS systémů. Uvedený příklad a zejména uvedený postup vyčíslení užitných vlastností je praktickým příkladem vlivu systematického rozvoje systémů a aplikací s inteligencí. Cn [%] N+V [%] No [%] % podíl 70,0 60,0 50,0 40,0 30,0 20,0 10,0 0, Typ zařízení Obr : Poměr jednotlivých nákladů (N+V, No a Cn) plynoucích z provozu jednotlivých typů zabezpečovacích zařízení k celkovým nákladům (C) vztažených k modelové ŽST 3.6. Kvantifikace užitných vlastností ITS systémů Pro vlastní kvantifikaci užitných vlastností budou využity základní teorie produkčních funkcí, které jsou detailně popsány v Příloze Teoretická východiska a základní charakteristiky produkčních funkcí Vymezení produkční funkce Produkční funkcí se obvykle rozumí konkrétní matematická funkce, popisující technologickou závislost vstupů a výstupů výrobního procesu. V obecném tvaru ji lze vyjádřit ve tvaru (3.4) takto: y = f (x 1, x 2,, x i,, x m ) (3.4) kde y je objem výroby, x 1,, x 2,, x i,, x m jsou různé výrobní faktory, f je obecné vyjádření nějaké matematické funkce (rovnice). Základy teorie produkčních funkcí položila práce Ch. W. Cobba a P. H. Douglase, v níž jsou uvedeny výsledky empirických zkoumání, vycházejících z makroekonomické analýzy údajů za odvětví zpracovatelského průmyslu v USA za období Praktický význam produkčních funkcí spočívá především v možnosti jejich využití při řešení takových specifických strategických úloh, jako jsou: 81

82 určení efektivnosti každého z jednotlivých výrobních faktorů při neměnných (konstantních) ostatních faktorech, kvantifikace vzájemné zaměnitelnosti (substituce) výrobních faktorů a jejich důsledků, stanovení vlivu technického pokroku a know how (informací, znalostí) výrobních, informačních, počítačových, komunikačních a dalších technologií a jejich různých forem, využívaných při výrobě statků (komodit a služeb) a ovlivňujících dynamiku objemu výroby, určení výsledného objemu výroby v závislosti na možných variantních změnách jednotlivých výrobních faktorů, a to včetně trendů vymezení podmínek optimalizace výrobního procesu, stanovení rozsahu některého výrobního faktoru při dané úrovni ostatních výrobních faktorů pro předem požadovaný nebo plánovaný objem výroby. Při konkrétní specifikaci produkční funkce je třeba především vymezit množinu relevantních výrobních faktorů a zároveň určit, v jakých jednotkách a jejich metrice se vyjádří vstupy do a výstupy z výrobního procesu. Dle počtu faktorů (mohutnosti konečné množiny X = {x 1, x 2,, x i,, x m } výrobních faktorů) se produkční funkce dělí na jednofaktorové a vícefaktorové. Jako proměnné x 1, x 2,, x i,, x m se používají nejčastěji základní fondy (F), pracovní síla (P, resp. L), finanční kapitál (C), přírodní zdroje a podmínky a některé další faktory. Při praktických ekonomických analýzách se objem výroby obvykle vyjadřuje pouze v závislosti na dvou výrobních faktorech, a to na věcném činiteli, představovaném základními výrobními fondy (jakýsi stabilní parametr), a živou lidskou pracovní silou (jakýsi proměnný parametr). Základní fondy se obvykle vyjadřují pomocí hodnotových ukazatelů o stavu základních prostředků, někdy jenom strojních. Živou práci člověka lze charakterizovat různými způsoby, zpravidla se používá ukazatele průměrný počet pracovníků, počet odpracovaných hodin/dní, objem vyplacených mezd, apod. Proměnnou objem výroby (y) lze vyjádřit různými ekonomickými ukazateli (hrubý národní produkt, hodnota přidaná zpracováním, aj.), a to v závislosti na charakteru a cíli ekonomické analýzy. V souvislosti se specifikací a aplikací produkčních funkcí se lze setkat s řadou interpretačních a implementačních problémů, m. j. vyplývajících ze skutečnosti, že při konstrukci produkčních funkcí se využívá jak průřezových údajů, tak údajů časových řad, navíc různými způsoby agregovaných Definice hodnotových metrik Z uvedených teorií produkčních funkcí je patrná nutnost stanovení hodnotových metrik pro vyjádření užitných vlastností ITS systémů. Na základě analýzy vnímaní přínosů a nákladů ITS služeb příjemci uživateli bylo rozhodnuto o využívání pevných a měkkých metrik pro hodnotové vyjádření. Metriky v ITS mají velký význam. Rozklad metrik přinese tvorbu měřítek pro kvantifikaci užitných vlastností systémů, subsystémů a aplikací ITS Pevné metriky Vyjadřují v ITS pevné měřitelné hodnoty jako je například z oblasti nákladů cena za přenesený kilobit v telekomunikačním prostředí, cena kabelu, cena PC v systémech zpracování informací a z oblasti přínosů např. cena za poskytované služby, uspořené pohonné 82

83 hmoty, uspořené osobní náklady, uspořené náklady na telekomunikace, atd. Hodnoty jsou vyčíslitelné a zpravidla je možno je určit již v průběhu přípravy rozvoje ITS služeb. Typicky pevných metrik lze použít pro kvantifikaci přínosů služeb ITS pro dopravce, správce infrastruktury a pro finanční a kontrolní instituce Měkké metriky Vyjadřují v ITS neměřitelné hodnoty přínosů služeb ITS, jako je například sledování statistických údajů o dopravě pro výkon státní správy a územní samosprávy, přenos informací z ITS systémů do informačních systémů policie a hasičů, ale např. i přínos systému pro poskytování dopravních informací. Pro stanovení metrik v této oblasti je nutno definovat měřítko jako je například vyčíslení přínosů snížení kongescí, atd. Cílem řešitelů musí být minimalizovat podíl měkkých metrik v oblasti kvantifikace užitných vlastností Shrnutí Definování metrik je důležitým nástrojem pro sledování a následný rozklad užitných vlastností ITS systému. Rozdělením ekonomických přínosů do čtyř základních tématických okruhů s možností následného členění (řetězení) na jednotlivé položky vytváří předpoklad využívání zejména pevných metrik pro vyjádření užitných vlastností. Pevné metriky mají jednoznačně ekonomickou váhu, a proto je nutno 9. stávajících základních makrofunkcí v ITS architektuře doplnit o 10 makrofunkci vyjadřující ekonomické přínosy a náklady ITS systémů. Na obr.3.12 je vyjádřen princip vazeb pro hodnotové vyjádření metrik v celé architektuře ITS. Služby ITS pro ekonomické procesy: I. II. III. IV Obr.3.12: Princip vazeb mezi ekonomickými procesy a funkční ITS architekturou - I. - podpora podnikových procesů, II. - podpora vnitřních business procesů, III. - podpora vnějších business procesů, IV. - procesy tvorby vlastní (podnikové) architektury ITS 83

84 Každá funkce v architektuře ITS je členěna na podfunkce, kde ke každé podfunkci jsou přiřazeny ekonomické parametry rozdělené do čtyř výše popsaných kategorií. Metodou produkčních funkcí bude možno modelovat jednotlivé ekonomické přínosy a náklady a posuzovat jednotlivá ITS řešení Užitné vlastnosti zabezpečovacích zařízení železniční dopravní cesty (modelový příklad) V současné době zabezpečovací zařízení prodělává generační změnu konstrukčního prvku, kdy reléový prvek nahrazuje prvek s mikroprocesory. Generační změna způsobuje přechod od nepružných analogových systémů k přizpůsobivým systémům digitálním. Vlastnosti systémů digitálních technologií zvyšují užitné vlastnosti systémů zabezpečovacích zařízení a tím i výrazně působí na snížení úrovně nákladů realizace dopravního procesu. Prosperity železnic může být dosaženo obnovou stávajících zabezpečovacích zařízení, avšak při dodržení určitých pravidel a principů. Mezi první princip patří seznámení odborníků s netradičním pohledem na technické prostředky, a to pomocí ekonomicko-manažerského náhledu. Jeho základem jsou nákladové analýzy vztažené k provozu zabezpečovacích zařízení Cena realizace dopravního procesu Základem manažerského pohledu je celková cena za realizaci dopravního procesu (C). Zjednodušeně ji lze vyjádřit pro libovolný traťový úsek takto: C = N infr + N obs + O + N traen [Kč] (3.5) kde v přepočtu na sledovaný traťový úsek jsou N infr - souhrn nákladů infrastruktury včetně režie (v podmínkách ČD: DDC) N obs - souhrn nákladů na obsluhu dopravní cesty včetně režie (t.j. DOP) O - součet odpisů vztažený pro daný úsek N traen - náklady na trakční energii resp. pohonné hmoty trakčního prostředku. Z (3.5) je zřejmé, že technické vybavení traťového úseku může ovlivnit všechny části ceny realizace dopravního procesu. Například: Řídící systém (s technickou podporou: systémy dálkového ovládání nebo kontroly) sníží náklady infrastruktury (N infr ), ale i případně náklady na obsluhu (N obs ) a spotřebu trakční energie (N traen ). O velikosti hodnoty odpisů rozhoduje redundance zařízení infrastruktury. Zabezpečovací zařízení svojí technickou úrovní, rozsahem, konstrukčním provedením ovlivní všechny složky realizace dopravního procesu. Telekomunikace (přenos informací) působí obdobně jako zabezpečovací technika Vztah konstrukčního prvku zabezpečovacích zařízení k nákladům U každého železničního podniku jsou provozovány různé typy zabezpečovacích zařízení, neboť základní konstrukční prvek byl v době vzniku vázán na úroveň technického a technologického stupně poznání. Je skutečností, že zařízení byla instalována na traťové úseky a jejich stanice nesystémově, podle ekonomických možností. Pouze na hlavních tratích byl udržován určitý systémový pohled. 84

85 Při řešení a konstruování zabezpečovacích zařízení je nutno respektovat požadavky na traťovou rychlost, hustotu provozu a organizaci dopravního procesu. Nepřizpůsobivost analogových systémů (tzv. pevné páky a reléových ze systémů volné páky ) již změněným požadavkům nevyhovuje. Jak provoz různých typů zabezpečovacích zařízení ovlivňuje náklady realizace dopravního procesu? Při determinaci odpovědi budou sledovány všechny provozní náklady železničního podniku. Modelově jsou sledovány náklady na provoz staničního zabezpečovacího zařízení v železniční stanici (ŽST) střední velikosti: 30 výhybkových jednotek, v hlavních kolejích uvažována rychlost 120 km.h -1, uvažováno zařízení 1. až 3. kategorie dle TNŽ , s přihlédnutím k návrhu ČSN a to i z hlediska jejich historického vývoje, ŽST je vybavena dvěmi závislými stavědly. Vlastní provozní náklady zabezpečovacího zařízení (N) lze definovat: N = Nu + Np + Nm + Nr + Nn [Kč] (3.6) kde Nu - náklady osobní (vyjádření pracnosti údržby) na zajištění provozuschopného stavu dle předpisových ustanovení železničního podniku (u ČD zejména předpisy řady T); Np - náklady potřebné na odstranění poruch zařízení; Nm - průměrné materiálové náklady na údržbu a opravy techniky (např. oprava relé); Nr - režijní náklady (střediska, provozní a správní režie); Nn - náklady na energetické napájení zabezpečovacího zařízení. Náklady N jsou částí N infr z (3.5). Náklady na obsluhu zabezpečovacího zařízení (No) lze určit: No = Nr + Nm [Kč] (3.7) kde Nr - součet všech režijních nákladů; Nm - mzdové náklady. Náklady No jsou částí N obs z (3.5). Ostatní náklady (V) zahrnují náklady vyvolané provozem a poruchami zabezpečovacích zařízení: V = Vth + Vte + Vp [Kč] (3.8) kde Vth - vícenáklady u traťového hospodářství na údržbu kolejové svršku (izolované styky apod.) vyvolané aplikací kolejových obvodů a dalších venkovních prvků zabezpečovacích zařízení různých typů; Vte - náklady na trakční energii spojené se zajištěním provozu při poruše zabezpečovacího zařízení a z toho plynoucích nepravidelností v železničním provozu; Vp - náklady v ostatních odvětvích spojených se zajištěním železničního provozu při poruchách zabezpečovacích zařízení (např. střežení železničních přejezdů). Ostatní náklady (V) zahrnují dílčí části všech složek ceny realizace dopravního procesu (3.5). 85

86 Celkové náklady (Cn) provozovaného zabezpečovacího zařízení lze popsat: Cn = N + No + V [Kč] (3.9) Typy zabezpečovacích zařízení a příklad kvantifikace nákladů Pro dále uvedenou kvantifikaci nákladů jsou použity: analytické přípravné materiály k dokumentům zpracované dle: - metodik ČD SR 79 a SR 71 včetně účetních sestav, - statistiky poruch jednotlivých typů a funkčních celků zabezpečovacích zařízení a jejich vlivů do nákladových položek, - doplňujících výpočtů (např. spotřeba trakční energie vyplývající ze snížení rychlosti vlaku o průměrné hmotnosti), - statistických výpočtů průměrné hmotnosti vlaků ve sledovaném úseku za časové období jednoho roku, vstupní hodnoty nákladů valorizované inflačním koeficientem pro příslušný rok v období , vstupní statistické hodnoty upravené koeficientem vyjadřujícím pokles intenzity dopravy v závislosti na čase ( ). Do nákladů nejsou zahrnuty: náklady na investice, modernizace a rekonstrukce, hodnota odpisů z hlediska jejich přiřazení k zabezpečovacímu zařízení. Přesnost výpočtu je zatížena statistickou chybou a valorizací ekonomických vstupů. Chyba je vyjádřitelná ± 20 % z celkové hodnoty, což pro orientaci v problematice je vyhovující. Volba typů staničního zabezpečovacího zařízení vyjadřuje základní (typové) vybavení dané technologií použitého konstrukčního prvku. V provozu je však i určité množství jejich modifikací, které rovněž mohou způsobit nárůst nákladů. Typy staničních zabezpečovacích zařízení jsou s určitým zjednodušením popsány v tabulce 3.1. Typ č. Kategorie Typ zařízení Charakteristika a konstrukční prvek 1 I. Nezávislá návěstidla Výměnový zámek, tabule na zavěšování klíčů; rychlost vlaků výrazně omezena 2 II. Mechanické Závislosti mezi návěstidly, výhybkami a ostatním zařízením v kolejišti jsou mechanické; systém pevné páky ; Rychlost až 120 km.h -1 3 II. Elektromechanické Závislosti mezi návěstidly, výhybkami a ostatním zařízením v kolejišti jsou mechanické a elektrické; systém pevné páky ; rychlost až 120 km.h -1 4 II. Elektromechanické Dtto ad 3, avšak návěstidla jsou světelná, kolejiště se souvislými kolejovými obvody; přestavníky elektromotorické 5 II./III. Reléové a elektronické (hybridní) Závislosti mezi návěstidly, výhybkami a ostatním zařízením v kolejišti jsou výhradně elektrické; systém volné páky ; rychlost až 160 km.h -1 6 III. Elektronické (s kolejovými Dtto ad 5; mikroprocesor, reléové rozhraní 86

87 obvody) 7 III. Elektronické (s bodovými prvky v kolejišti) 8 III. bis Elektronické v systému dálkového ovládání (s bodovými prvky v kolej.) Dtto ad 6; mikroprocesor, rozhraní reléové nebo elektronické Dtto ad 7; dálkové ovládání a dálková kontrola ŽST s centralizovanou nebo decentralizovanou výstrojí včetně technické diagnostiky Tabulka 3.1.: Typy staničních zabezpečovacích zařízení a jejich charakteristický konstrukční prvek V následujících tabulkách a grafech je finanční hodnota nákladů za časové období jednoho roku vyjádřena v % vztažených k celkovým nákladům železničního podniku a zprůměrována na modelovou ŽST. Typ zařízení N [%] No [%] V [%] Cn [%] 1 0,2 52,5 0,2 52,9 2 0,7 52,5 0,5 53,7 3 1,4 52,5 1,4 55,3 4 4,5 52,5 6,2 63,2 5 6,2 21,4 7,6 35,2 6 4,4 21,4 6,6 32,4 7 1,7 21,4 1,2 24,2 8 2,7 4,9 1,4 8,9 Tabulka 3.2.: Procentuální podíl nákladů jednotlivých typů zařízení z celkových nákladů C vztažených k modelové ŽST 87

88 Cn [%] N+V [%] No [%] % podíl 70,0 60,0 50,0 40,0 30,0 20,0 10,0 0, Typ zařízení Graf 3.1.: Poměr jednotlivých nákladů (N+V, No a Cn) plynoucích z provozu jednotlivých typů zabezpečovacích zařízení k celkovým nákladům (C) vztažených k modelové ŽST Strmost směrnice u nákladů na obsluhu (No) až po zlom v bodu označeném je způsobován technickými možnostmi systému pevné páky. Požadavek na počty zaměstnanců obsluhujících staniční zabezpečovací zařízení zůstává stejný, avšak postupně se zvyšuje počet vnějších zařízení v kolejišti a zvyšují se náklady na energetické hospodářství (napájení). Se vzrůstajícím počtem vnějších zařízení rovněž vzrůstá počet poruch. U zařízení typu 4 a 5 narůstají náklady N a V. Od padesátých let jsou budovány systémy volné páky (typ 5). Pro tato zařízení lze z grafu 1 zjistit výrazné snížení nákladů na obsluhu (No) a pokračující nárůst nákladů N a V, který je dán náročností na údržbu reléových systémů, vnějších zařízení a náročností na elektrické napájení včetně náhradních proudových zdrojů. U staničních zabezpečovacích zařízení typu 6 a 7 (rovněž v systému volné páky ) se použitými konstrukčními prvky zvyšuje spolehlivost systému a zejména je zřejmé výrazné snížení technických nákladů N a V. Nové technologie a konstrukční prvky umožňují, zejména při využití bodových automatizačních prvků, diagnostických systémů, inteligentního přenosu informací a napájení, efektivněji řešit vybavení nejen ŽST, ale celého traťového úseku zabezpečovací technikou. Také je umožněn systémový přístup při obnově technologických zařízení infrastruktury tratě vedoucí k systémové integraci a k přizpůsobení technického prostředku požadavkům provozu a jejího provozovatele. Lze zohlednit i sociální aspekty. 88

89 % Typ zabezpečovacího zařízení Graf 3.2.: Procentuální podíl výhybkových jednotek u jednotlivých typů staničních zabezpečovacích zařízení ve vztahu k celkovému počtu zabezpečených vyhybek Zabezpečovací zařízení má rozhodující význam pro zajištění bezpečnosti drážní dopravy. Význam zabezpečovacích zařízení je zdůrazněn v 47 zákona č. 266/1994 Sb., o drahách a v prováděcí vyhlášce č. 100/1995 Sb., řád určených technických zařízení (UTZ), neboť, podle písm. k) odst. (4) 1 citované vyhlášky, zabezpečovací zařízení, jehož elektrické obvody plní funkci přímého zajišťování bezpečnosti drážní dopravy, je UTZ a podléhá dozoru podle zákona o drahách. A to jak pro jeho uvedení do drážního provozu ( 47 zákona č. 266/1994 Sb.), tak i při jeho provozování ( 48 téhož zákona). Schválení způsobilosti nového UTZ k provozu a vydání Průkazu způsobilosti (PZ) je obvykle obsahem smlouvy u příslušné stavby dráhy. Prodloužení platnosti PZ ve smyslu 48 zákona je ovšem ekonomické zatížení přímého správce tohoto UTZ stejně jako provádění komplexních prohlídek nebo prohlídek zabezpečovacích zařízení podle přílohy č.1 k vyhlášce č. 177/1995 Sb. Současné vybavení staniční zabezpečovací technikou u ČD dle typů uvedených v tab. 1 je zobrazeno v grafu 3.2. Z grafu 3.2 je zřejmé, že u ČD jsou ve staniční zabezpečovací technice nejrozšířenější typy 2 až 5, jakož i jejich modifikace (Poznámka: v době tvorby grafu bylo v ověřovacím provozu několik zařízení typu 6 a jediné typu 7). Provozování UTZ ovlivňuje průběh nákladů Cn zejména tím, že vyvolává náklady na jeho opravy, modernizaci a případně i investice. Pro kvantifikaci souhrnu těchto technických nákladů (Nt) lze definovat: Nt = N + V + Ks (3.10) kde Ks - nutné náklady na modernizace, opravy, případně investice. Hodnota Ks byla stanovena analytickým výpočtem vztaženým ke stavu provozovaných zařízení a časovému aspektu. Z předchozího vyplývají hodnoty v tabulce 3.3 a v grafu 3.3. Hodnota Cp vyjadřuje pro období 4 až 8 roků předpokládané zvýšení celkových nákladů Cn o hodnotu Ks. 89

90 Typ zařízení No [%] Cn [%] Nt [%] Cp [%] 1 52,5 52,9 0,4 52,9 2 52,5 53,7 1,2 53,7 3 52,5 55,3 10,6 60,3 4 52,5 63,2 26,3 78,8 5 21,4 35,2 27,4 48,8 6 21,4 32,4 11,0 32,4 7 21,4 24,2 2,8 24,2 8 4,9 8,9 4,1 8,9 Tabulka3.3.: Rozšíření nákladů na provoz zabezpečovacích zařízení (Cn) o předpokládané náklady vyžadované zachováním provozuschopnosti techniky (Ks) 100,0 80,0 Nt [% ] Cp [% ] No [% ] % podíl 60,0 40,0 20,0 0, Typ zař íze ní Graf 3 3.: Porovnání nákladů na obsluhu (No), souhrnných technických (Nt) zahrnujících předpokládaný nárůst nákladů na uchování provozuschopnosti zabezpečovacích zařízení (Cp) Z uvedeného je zřejmé, že většina provozovaných staničních zabezpečovacích zařízení (typy 2 až 5) svými náklady zvyšují cenu realizace dopravního procesu (C). Náklady na obsluhu (No) jsou všeobecně vnímány, avšak souhrnné technické náklady Nt již méně. Právě tyto náklady budou výrazně ovlivňovat cenu realizace dopravního procesu (1) v následném výše definovaném období. Tento závěr plyne z průběhu křivek v grafu 3.3 zejména u nejvíce rozšířených typů zařízení (4 a 5). 90

91 4. Pilotní projekty v oblast ITS 4.1. Úvod Je samozřejmé, že bez výkonné dopravní sítě nemůže být konkurenceschopné hospodářství. Vytvoření trans-evropské dopravní sítě TEN a plynulého provozu na ní se stalo oficiální politikou Evropského společenství před deseti lety jako klíčová podmínka pro úspěšný vnitřní trh a pro zajištění udržitelné mobility v rozšířené Evropě. V současné době dopravní provoz roste rychlým tempem a nevyváženě. Není možné popřít, že pro úspěšné rozšíření bude jako klíčové vytvoření patřičné dopravní infrastruktury, která poskytne odpovídající propojení, stále ještě někde chybějící, mezi patnáctkou a novými členskými státy a která zajistí pro všechny členské země maximální zisk z jednotného evropského prostoru. To bude zahrnovat nejen modernizaci dopravní infrastruktury nebo nové stavby na ní pouze v nových členských zemích, ale také ve stávajících členských státech EU. Trans-evropská dopravní síť zahrnuje nejen dopravní infrastrukturu, ale i systémy řízení dopravy a lokalizační a navigační systémy. Dopravní infrastruktura tedy zahrnuje silniční a železniční sítě, vnitrozemské vodní cesty a body vzájemného propojení. Tyto body vzájemného propojení tvoří námořní přístavy, vnitrozemské přístavy a intermodální terminály. Za intermodální terminály se považují letiště, logistická centra, terminály pro kombinovanou dopravu, ale třeba i důležité železniční stanice s návaznosti na další druhy veřejné osobní dopravy. Body vzájemného propojení jsou nezbytnou podmínkou pro integraci různých druhů dopravy do tzv. multimodální sítě. Systémy řízení dopravy a systémy určování polohy a navigace zahrnují nezbytné technické instalace a informace, a v neposlední řadě zahrnují telekomunikační systémy k zajištění harmonického provozu sítě a efektivního řízení dopravy. Vodítkem pro rozvoj trans-evropské dopravní sítě se v roce 1996 stala směrnice ES č. 1692/96. Následně po skončení řešení několika výzkumných a vývojových programů byla přijata v tomto roce směrnice pro rozvoj trans-evropské dopravní sítě, která znamenala začátek opatření a kroků Společenství zaměřených k podpoře Informační společnosti prostřednictvím dopravního systému. Tato směrnice zahrnuje také telematickou infrastrukturu pro systémy řízení dopravního provozu a pro systémy poskytující dopravní informace. Cílem je zabezpečení interoperability a kontinuity služeb přes hranice států. Také v Bílé knize Evropská dopravní politika do roku 2010: čas rozhodnout bylo zdůrazněno, že směrnice TEN musí být upravena tak, aby vzala v úvahu zneklidňující nárůst kongescí způsobených přetrvávajícími úzkými místy na síti, mnohde ještě chybějícími spojeními s odpovídajícími parametry, nedostatkem interoperability, a v neposlední řadě aby vzala v úvahu naléhavou potřebu prosadit a uvést do rovnováhy používání jednotlivých druhů dopravy. Na podzim roku 2003 bude směrnice pro rozvoj trans-evropské dopravní sítě revidována. Podkladem pro tento proces je závěrečná zpráva s doporučeními pro Evropskou komisi vypracovaná expertní skupinou vysoce postavených zástupců členských a budoucích členských zemí EU. Tato expertní skupina pod vedením bývalého komisaře EK pro dopravu Karl Van Mierta doporučila Evropské komisi seznam nových projektů na síti TEN, které mají být dokončeny do roku Ačkoliv cíle pro rozvoj této sítě, stanovené Evropským společenstvím, mají své opodstatnění a jsou náročné, výsledky do této doby nesplnily očekávání: pouze tři ze 14 prioritních projektů podpořených šéfy států a vlád v Essenu v roce 1994 byly dokončeny a některé z dalších 11 jsou stále ve stavu předběžných studií. Na skutečnost, že není shoda mezi 91

92 proklamovanými cíly a možnými finančními zdroji Společenství z hlediska budování a financování trans-evropské sítě, se Evropská komise zaměřila ve své Bílé knize Evropská dopravní politika do roku 2010: čas rozhodnout. Kromě technických problémů a problémů spojených s vlastním plánováním rozvoje dopravních sítí čelí projekty na síti TEN největší těžkosti, a to zdrojem financování. Odhaduje se, že samotné náklady na všechny projekty na síti TEN, které mají být dokončeny do roku 2010, budou asi 500 mil. včetně projektů na území budoucích členských států. Skutečností je, že financování této dopravní infrastruktury bylo členskými i kandidátskými státy z jejich národních rozpočtů posunuto a odpovídající fondy pro čerpání pomoci z Unijních zdrojů jsou nedostatečné, což je to také dáno určitými limity a možnostmi rozpočtů veřejné správy Program TEMTO a projekt CONNECT Evropské společenství pomáhá financovat rozvoj trans-evropské dopravní sítě, a to spolufinancováním příslušných projektů. Jednou z priorit Evropské unie je potřeba koordinovaného a synchronizovaného národního plánování rozvoje Inteligentních dopravních systémů a služeb (ITS) v rámci Evropy, což je v období zabezpečováno prostřednictvím víceletého cíleného programu MIP (Multi-annual Indicative Programme). Víceletým programem pro harmonizovaný rozvoj ITS v oblasti silniční dopravy je program TEMPO. Program zahrnoval nejprve 5 euro-regionálních projektů ARTS, CENTRICO, CORVETTE, SERTI a VIKING a později přibyl jeden projekt STREETWISE. V rámci těchto projektů se řeší problematika implementace telematiky, řízení dopravy na Transevropské dopravní síti, řídící dopravní ústředny, informace pro řidiče, informace pro cestující apod. Sedmým novým euro-regionálním projektem bude s největší pravděpodobností projekt pod pracovním názvem CONNECT (Co-ordination and stimulation of innovative ITS activities in Central and Eastern European Countries), který je nyní připravován, byl předložen Evropské komisi a předpokládá spolupráci těchto zemí: Česká republika, Slovensko, východní část Německa (Berlín, Braniborsko, Sasko, Sasko-Anhaltsko), Rakousko (regiony na východě země), Slovinsko, Maďarsko a Polsko. CONNECT má za cíl nastínit vzorový plán pro rozvoj a rozšiřování Inteligentních dopravních systémů a služeb na Trans-evropské silniční síti (TERN) v zemích zařazených do oblasti CONNECT. Hlavní částí pracovního plánu projektu je navrhnout podstatné ovlivnění dopravní mobility a bezpečnosti v oblasti CONNECT. Na závažných nehodových lokalitách a koridorech sítě TERN budou navržena opatření pro management dopravy a budou určeny hlavní problémy v předmětné oblasti (např. management dopravy a bezpečnosti v tunelech, logistika a řízení oběhu vozidlového parku pro nákladní dopravu, management tísňového volání a nepříznivé meteorologické podmínky). Další hlavní důraz je přisuzován službám tzv. Infomobility. Program bude zahrnovat nezbytné studie, předpoklady a možnosti proveditelnosti a pilotní projekty jako základu pro zavedení vysoce kvalitních informací o dopravní situaci a informace pro cestující (TTI - Traffic and Traveller Information) v oblasti CONNECT. Tyto služby budou pokryty zlepšenou kvalitou sbíraných údajů, zlepšením telematických spojení mezi údaji, obsahem a poskytovateli služeb a z tohoto důvodu se zlepší dostupnost informací vztahujících se k mobilitě, management poskytování služeb a v neposlední řadě se zvýší okruh potencionálních uživatelů. Projekt bude řešit tyto oblasti-domény: 1. Road Monitoring Infrastructures, 2. European Network of Traffic Centres, 3. Traffic Management and Control, 4. Traveller Information Services, 5. Fraight and Fleet Management, 6. Electronic Fee Collection, 7. Incident and 92

93 Emergency handling, 8. Horizontal Issues. K řešení těchto domén je Česká republika připravena a bude se ve všech doménách účastnit řešení. Záleží ale na rozhodnutí každé účastnické země v jaké doméně se bude účastnit a jakým způsobem (bude se podílet pouze na řešení společné studie apod.). Doba řešení projektu se předpokládá 3 roky ( ), přičemž koncem roku 2003 bude jednotlivými zeměmi projektu CONNECTu dokončena náplň jednotlivých pracovních balíčků a Evropskou komisí bude odsouhlasen pracovní plán projektu. Pracovní balíčky musí obsahovat i další vizi projektu a návrhy řešení po roce Pro rok 2004 se předpokládá vypracování plánů rozvoje ITS a studií proveditelnosti navrhovaných projektů, případně pilotních projektů, v roce 2005 by měly být zahájeny pilotní projekty nebo i vlastní implementace a tyto činnosti by měly pokračovat i v roce Evropská komise předpokládá, že země CONNECTU budou moci v období vynaložit ze svých veřejných i soukromých rozpočtů na rozvoj tohoto projektu asi 25 mil.. Komise je připravena pomoci financovat rozvoj projektu CONNECT spolufinancováním příslušných projektů, a to u studií a pilotních projektů až do výše 50% uznatelných nákladů, u vlastní implementace projektů ITS až do výše 10% uznatelných nákladů, avšak v případě, že se projekt nachází na Trans-evropské dopravní síti určené pro silniční dopravu (TERN) je Komise připravena u implementace projektů ITS finančně přispět až do výše 20% uznatelných nákladů. Na toto spolufinancování má Komise plánováno 7 mil.. Kromě projektů na síti TERN budou podporovány i projekty ITS na území statutárních měst ležících na TERN, pokud budou respektovat směrnice Evropské komise a priority programu TEMPO. Navržené aktivity v jednotlivých doménách musí být reálné a musí být v souladu s rozvojovými plány zemí, správců infrastruktury, měst. Poté, co bude jednotlivými národními koordinátory dodán šéfovi projektu (Via-Donau) seznam jednotlivých aktivit podle domén, bude posouzen a odsouhlasen Evropskou komisí. Tento odsouhlasený plán pak ale bude nutné dodržet a ročně vyčerpat nejméně 75% plánovaných nákladů. Taková jsou pravidla programu TEMPO. Bude-li vydáno na řešení programu méně než 75% ročně, přistoupí Komise k úpravě finanční pomoci (většinou je to směrem dolů, a to podstatně). Je důležité, že Česká republika má prostřednictvím Ministerstva dopravy, Krajských úřadů, Magistrátů některých statutárních měst, Ředitelství silnic a dálnic, ale i Českých drah zpracovány relevantní studie jako základ pro další pokračování prací na rozvoji ITS a také plánuje vyhlásit řešení dalších výzkumných programů nebo plánuje zahájit pilotní projekty. Tyto aktivity tak mohou být chápány jako vklad ČR pro řešení evropského programu, na který může Evropská komise naší zemi finančně přispět. Kromě harmonizovaného a synchronizovaného rozvoje ITS prostřednictvím programu TEMPO byla v rámci procesu revize řídících zásad Trans-evropské dopravní sítě zřízena v roce 1999 Evropskou komisí expertní skupina "Trans-evropské dopravní sítě pro inteligentní dopravní systémy pro řízení silničního provozu". Tato skupina vypracovala v dubnu 2000 "Doporučení k revizi řídících zásad TEN-T pro řízení silničního provozu". Řídící zásady TEN-T pro ITS přispějí k rozšiřování opatření a projektů zabývajících se bezpečným a efektivním přemísťováním lidí a zboží po celé Evropě, minimalizací ekologických a sociálních nákladů a projektů zabývajících se podporou využívání multimodálních přepravních služeb. V rámci tohoto projektu byly vypracovány pilotní listy, které jsou uvedeny v Příloze 7, které byly akceptovány EU. 93

94 5. Koordinační centrum pro ITS Koordinační centrum pro ITS je realizováno prostřednictvím ITS portálu, což je dynamické webové rozhraní implementované pomocí interpretovaného programovacího jazyka PHP a založené na relačním databázovém modelu. Mechanismus provádějící vlastní fyzickou manipulaci s daty je uskutečňován MySQL serverem. ITS portál je navržen tak, aby umožňoval práci mnoha subjektů odkudkoliv, kde je přístup na Internet. Tato vlastnost je realizována díky autentifikačnímu systému a správě uživatelských práv. Po úspěšném přihlášení se do systému lze editovat nebo doplňovat příslušné 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ší. Součástí portálu je výpis novinek a zpráv z různých oblastí dopravní problematiky. Návštěvník tak dostane aktuální informace o stavu vývoje celého projektu. ITS portál dále slouží jako nástroj pro procházení a prohlížení ITS architektury a to jak v českém, tak i anglickém jazyce. 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 nebo Obr Ukázka úvodní stránky ITS portálu. Jednoduchým a přehledným způsobem je členěna do několika tematických sekcí. 94

95 Obr Přehledně uspořádané subsystémy fyzické části architektury jsou branou k procházení celé ITS architektury. 95

96 Obr Ukázka výpisu detailních informací konkrétní funkce logické části architektury. 96