FAKULTA
DOPRAVNÍ
ČVUT | KONVIKTSKÁ 20, 11000 PRAHA 1
ITS v podmínkách dopravně-telekomunikačního prostředí ČR (802/210/108) (technická zpráva za rok 2002)
Doc. Dr. Ing. Miroslav Svítek Doc. Ing. Zdeněk Votruba, CSc. Ing. František Kopecký Ing. Jan Čábelka, CSc. Doc. Ing. Mirko Novák, DrSc. Prof. Ing. Vladimír Svoboda, CSc. Ing. Michal Šubrt Ing. Petr Říha Ing. Jiří Matějec Ing. Petr Zobaník Ondřej Galík Martin Dvořák Mgr. Věra Bala
VERZE 1.0
Motto ze systémového inženýrství: "Základem systému jsou prvky jakožto nositelé základních funkcí (implicitních). Řetězením prvků pomocí vazeb vzniká struktura systému. Při konstruktivním přístupu k vytváření systému základní prostorové1 uspořádání (zpravidla s agregací funkcí prvků do makrofunkcí a s vytčenými globálními kriteriálními funkcemi) zachycuje architektura systému2. Silné procesy, jež jsou dostupné na této architektuře a jsou aktivovány vnějšími požadavky nebo význačnými vnitřními stavy systému definují aplikace (tedy explicitní funkce systému)"
1
Dimenze a metriku prostoru dominantně určuje alternativně objekt (originál), záměr (strategie) a infrastruktura (systému a blízkého okolí). Podle tohoto kriteria se provádí základní členění typů architektur. 2 Samozřejmě je architektura systému též systémem (t.j. systémovým modelem)
1
OBSAH 1. TEORETICKÝ ÚVOD .........................................................................................................4 1.1 Základní terminologie ...................................................................................................4 1.2 Teorie architektur telematických systémů .....................................................................6 1.3 Metodika tvorby ITS architektury ..................................................................................7 1.4 Metodika ITS datového registru....................................................................................9 1.4.1 Obsah datového registru .....................................................................................11 1.4.2 Funkce datového registru ....................................................................................16 1.4.3 Správa datového registru.....................................................................................17 1.4.4 Implementace ITS datového registru ...................................................................21 1.4.5 Standardy ÚVIS...................................................................................................26 1.4.6 Příklad ITS datového registru (Datový registr FAA)..............................................28 2. ITS ARCHITEKTURA ČR.................................................................................................37 2.1 Procesy v ITS systému dominované infrastrukturou ...................................................37 2.3 Kontextový diagram ITS systému ČR .........................................................................43 2.4 Funkční ITS architektura ČR (shrnutí) ........................................................................43 2.4.1 Elektronické vybírání poplatků .............................................................................44 2.4.2 Zabezpečení bezpečnostních a záchranných služeb ...........................................45 2.4.3 Management dopravy ..........................................................................................46 2.4.4 Management veřejné dopravy .............................................................................47 2.4.5 Podpora řízení vozidla .........................................................................................48 2.4.6 Poskytování cestovních informací........................................................................49 2.4.7 Podpora dohledu .................................................................................................50 2.4.8 Management nákladní dopravy............................................................................51 2.4.9 Dopravně-přepravní databáze .............................................................................52 2.5 Informační ITS architektura ČR (shrnutí) ....................................................................53 2.5.1 Elektronické vybírání poplatků .............................................................................57 2.5.2 Zabezpečení bezpečnostních a záchranných služeb ...........................................57 2.5.3 Management dopravy ..........................................................................................58 2.5.4 Management veřejné dopravy .............................................................................59 2.5.5 Podpora řízení vozidla .........................................................................................60 2.5.6 Poskytování cestovních informací........................................................................61 2.5.7 Podpora dohledu .................................................................................................62 2.5.8 Management nákladní dopravy............................................................................63 2.5.9 Dopravně-přepravní databáze .............................................................................63 2.6 Příklady tvorby funkční a informační architektury........................................................64 2.6.1 Příklad ITS architektury města Hradec Králové....................................................64 Výhledový stav .............................................................................................................66 2.6.2 Příklad ITS architektury integrovaného systému nákladní dopravy ve vodní a železniční dopravě přes dopravní terminál - přístav Ústí nad Labem............................67 3. TECHNICKÉ PROSTŘEDKY PRO TVORBU ITS ARCHITEKTURY ČR..........................72 3.1 Struktura ITS databáze...............................................................................................72 3.2 Dálkový přístup k ITS architektuře ..............................................................................73 3.3 Zpracování informací ITS architektury ........................................................................74 3.3.1 Výměna, sdílení a přístup k ITS architektuře .......................................................74 3.3.2 Optimalizační úlohy nad ITS architekturou...........................................................75 4. NÁVRH KONCEPCE DOPRAVNÍ TELEMATIKY ČR .......................................................75 4.1. Role dopravní telematiky (ITS) v ČR .........................................................................77 4.2. Strategické cíle ITS v dopravní politice ČR a EU .......................................................78 4.3 Úloha a cíle veřejné správy při zavádění ITS..............................................................84 4.3.1 Strategické cíle zavádění ITS v ČR .....................................................................85 4.3.2 Naplňování strategických cílů ITS v ČR ...............................................................85 4.4 Úloha a cíle soukromého sektoru při zavádění ITS.....................................................87
2
4.5 Návrh postupných kroků zavádění ITS v ČR ..............................................................89 4.5.1 Silniční doprava ...................................................................................................89 4.5.2 Železniční doprava ..............................................................................................90 4.5.3 Veřejná osobní doprava.......................................................................................90 4.5.4 Nákladní doprava a přeprava...............................................................................91 4.5.5 Vodní doprava .....................................................................................................91 4.5.6 Letecká doprava ..................................................................................................91 4.6 Závěr..........................................................................................................................92 6. LITERATURA...................................................................................................................93 7. PŘÍLOHA 1 - FUNKČNÍ ITS ARCHITEKTURA ČR...........................................................94 8. PŘÍLOHA 2 - INFORMAČNÍ ITS ARCHITEKTURA ČR ....................................................94 9. PŘÍLOHA 3 - POPIS DATABÁZÍ ITS ARCHITEKTURY ČR .............................................94 10. PŘÍLOHA 4 – POPIS TERMINÁTORŮ ITS ARCHITEKTURY ČR..................................94 11. PŘÍLOHA 5 - TELEKOMUNIKAČNÍ PROSTŘEDÍ ČR A JEHO VYUŽITÍ V ITS..............94
3
1. TEORETICKÝ ÚVOD 1.1 Základní terminologie Abychom mohli hovořit o systému, musí být přinejmenším takto definovaný systém možno popsat jako konečný automat, který je definován mapováním vstupů systému na vnitřní stavy plus mapováním vstupů a vnitřních stavů na výstupy systému. Pro aplikace ITS zpravidla požadujeme identifikovat strukturní systém3 (identifikace systému v základních krocích, např. struktura systému4, resp. pravidla systému, mohutnost systému (tj. množina procesů systému), mechanismus koheze systému - soudržnost, cílovost systému (množina výstupních stavů systému jako cílů systému), množina silných procesů systému (genetický kód systému), identita ). Pro subsystém platí, že musí být popsatelný stejnou metodikou jako systém a ve své podstatě je subsystém systémem na podrobnější rozlišovací úrovni. Systém má jednak strukturu a jednak architekturu, kdy struktura je obvykle daleko podrobnější než architektura. Architektura definuje základní uspořádání subsystémů a funkčních bloků (o funkčním bloku hovoříme, když neumíme / nemůžeme daný blok popsat jako systém nebo subsystém) v prostoru5. Architektura je globálnější a jejím cílem je co největší přehlednost a srozumitelnost. Struktura jde až na prvky systému, je složitější, úplnější ale nepřehlednější. Na obr. 1 je zobrazena základní terminologie odvozená ze systémového inženýrství. Zobrazený subsystém je popsán strukturou prvků subsystému (na obr.1 zobrazeny žlutě) a vazbami mezi nimi (na obr. 1 zobrazeny jako černé šipky). Seskupením funkčně souvisejících prvků vznikají funkční bloky, které jsou nositeli makrofunkcí (na obr.1 zobrazeny červeně). Seskupením vazeb mezi funkčními bloky vznikají informační rozhraní (na obr.1 zobrazeny modře). Na základě obr.1 a výše uvedené základní terminologie je možno definovat:
A. Telematický systém (chápáno jako celý systém pro všechny dopravní obory) B. Telematické subsystémy (části systému jež jsou samy systémem - např. manager infrastruktury, dopravce, logistické centrum, letiště, vozidlo, atd.) C. Funkční bloky (jsou nositelé makrofunkcí, nejsou identifikovány jako systém - v naší metodice budou funkční bloky hierarchicky členěny, např. F1, F1.1, F1.1.1) - podmínkou funkčních bloků je, že musí být složitelné z prvků!! D. Prvky (dále nedělitelné části systému nesoucí dílčí resp. implicitní funkce systému - v některých studiích jsou označovány jako p-funkce)
3
tedy identifikovat systém na podrobnější rozlišovací úrovni To je množina prvků (nosičů funkcí) a zřetězených dvojic prvků (definující vazby) 5 Právě způsob volby tohoto prostoru a jeho metriky vede k rozlišení typů architektur (Jde vlastně o „úhel pohledu“, podle nějž architekturu (jako systémový model objektu nebo primárního systému) identifikujeme nebo konstruujeme. Triviální požadavek je „vejití se“ do tohoto prostoru. 4
4
Obr.1 - Základní terminologie
Budeme-li hovořit o architektuře, máme na mysli části A, B, C uspořádané ve vybraných prostorech (funkční, informační, atd.). Pro případ architektury ITS bude vhodné, aby funkční bloky a informační bloky zachycovaly (modelovaly) stejné objekty. Potom funkční architektura zobrazuje uspořádání subsystémů a jejich funkčních bloků v hierarchické úrovni, kde v každém funkčním bloku jsou zobrazeny realizované makrofunkce. Informační architektura definuje vztahy mezi nositeli těchto makrofunkcí, tj. jak se mezi funkčními bloky přenášejí informace případně jak se tyto informace zpracovávají6. Na základě informačních vazeb mezi funkčními bloky je možno definovat informační vazby mezi subsystémy v horizontální i vertikální úrovni. Na základě funkční a informační architektury lze definovat fyzickou, komunikační a organizační architekturu, kdy fyzická architektura přiřazuje jednotlivým subsystémům a funkčním blokům konkrétní zařízení včetně jejich alokace (např. HDŘU - Hlavní dopravní řídící ústředna), komunikační architektura definuje konkrétní požadavky na přenos informací mezi jednotlivými fyzickými subsystémy (s respektováním požadavků na dostupnost, spolehlivost, bezpečnost, atd.) z čehož je možno odvodit možnou technologii přenosu (GSM, GPRS, ATM, TETRA, atd.) případně i použitý protokol (různé stupně zabezpečení, atd.). Organizační architektura přiřazuje jednotlivým funkcím humánní komponenty případně organizační zabezpečení jednotlivým funkcím (ŘSD - odbor technické politiky, ČD Divize dopravní cesty, atd.). Návrh fyzické architektury musí respektovat legislativu ČR případně další národní konvence a odpovědnosti jednotlivých organizačních jednotek. Budeme-li hovořit o struktuře, máme na mysli části A, B, C, D.
6
Metodická poznámka pro identifikátora systému: je špatné, když je spojen každý funkční blok s každým blokem (nárůst entropie, který je důsledkem nevhodně volené rozlišovací úrovně vazeb) i když není propojen nikdo s nikým (jde o opačný extrém - rozpad soudržnosti systému).
5
Proces zobrazuje zřetězení událostí v systému. Událostí může být změna stavu / stavů systému, vyvolaná iniciací na vstupech (přivedení vstupních hodnot), nebo iniciací vnitřních stavů systému (dovedeno do důsledků je to „vybavením“ vnitřního stavu některého z prvků nebo změnou funkce prvku, někdy „spuštěnou“ např. samovolně vlivem poruchy, atd.), nebo „jen“ krokem vnějšího času7. Množina všech aktivovatelných procesů při možných stavech okolí definuje chování systému. Struktura systému může být i flexibilní, jako je tomu např. v oboru výpočetní techniky, kdy struktura je měněna dle určitého kritéria kvality. Základem tohoto přístupu je tzv. konfigurátor, což je např. tabulka plus vyhodnocovací a ovládací SW, pomocí kterého je možno rekonfigurovat strukturu nebo architekturu systému. Pro systémy, kde v roli prvků systému vystupují lidé nebo organizované skupiny lidí (např. státní správa), je řízení rekonfigurace systému složité a nastávají problémy s dynamikou rekonfigurace.. K tvorbě architektury ITS existují dva základní přístupy: • detailní tvorba struktury ITS systému až do dílčích prvků - tento přístup vede k lokální (detailní) optimalizaci systému - tato metoda se používala ve výpočetní technice 50. - 60 let a byla neúspěšná - složitě se udržovala, nebyla robustní na změny požadavků na systém, vznikaly velké problémy v chybových stavech a při procesech obnovy po poruše a její zisk byl v porovnání s náročností údržby malý, • hrubá tvorba struktury ITS systému - tento přístup se omezuje na definování co možná nejuniversálnějších funkčních bloků (i když se využije třeba jen 20% jejich možností v daném dopravním oboru) a návrh promyšlené architektury z funkčních bloků, která bude na úrovních jednotlivých subsystémů dobře postavená a bude výhodná z hlediska přenosu informací ve vertikální i horizontální úrovni (analogie v počítačích: generace instrukčního souboru z mikroinstrukcí a inkorporace pravidel pro flexibilní tvorbu makroinstrukcí). Na základě diskusí řešitelského týmu i na základě vyhodnocení ITS architektur jiných zemí (zejména Francie a Itálie) se řešitelský tým rozhodl pro druhou z uvedených možností. 1.2 Teorie architektur telematických systémů Architektura systému je dle [1] uspořádání částí v celku podle podmínek infrastruktury existence celku s cílem zajistit požadované chování celku (záměr). Infrastrukturou existence celku se rozumí soubor podmínek prostorových, časových, finančních, technologických, legislativních, organizačních a sociálních, za nichž může být systém jako reálný objekt projektován, realizován a ovládán. Požadovaných chováním celku se rozumí typy cílového chování (otevřené či autarkní), druhového chování (přežití, mutace, havárie, katastrofa) s hodnotami etiky, identity a kompetence, tj. definované systémové vlastnosti. Architektura systému je pak konstrukcí, resp. modelem vzájemné projekce tří systémů (ve formě tří systémových modelů): objektu (co), infrastruktury (kde, kdy) a záměru (jak, resp. proč), který odráží stupeň poznání jako motivu rozvoje. Všechny tři složky modelu architektury jsou systémy ve smyslu koncepce systému a jemu odpovídající definice včetně identity a kompetence, viz. [1]. 7
Pokud je vnější nebo reálný čas zaveden. Vnitřní – systémový čas nemá význam zde uvažovat, protože ten je definován „pouze“ změnami stavů prvků nebo změnami struktury a to jsme již uvedli.
6
1.3 Metodika tvorby ITS architektury Základním východiskem tvorby ITS architektury je doplněný universální procesní model, který popisuje základní silné procesy ITS systému a jejich utřídění dle infrastruktury tak, aby tyto procesy byly shodné ve všech druzích dopravy. V pojetí [1] toto představuje architekturu systému dominovanou infrastrukturou. Výhodou tohoto postupu je, že utřídění silných procesů dle infrastruktury je srozumitelné odborné veřejnosti8 a výběr jednotlivých silných procesů reprezentuje ve vhodné podobě požadavky uživatelů na vlastní ITS systém. Je zřejmé, že ne všechny procesy se týkají samotného ITS systému a bude třeba tyto procesy rozdělit na: • procesy probíhající pouze v rámci vlastního ITS systému, • procesy probíhající mezi vlastním ITS systémem a okolím ITS (buď vlastní ITS poskytuje informace okolním systémům /osobám /organizacím, nebo okolní systém /osoby /organizace poskytují informace vlastnímu ITS systému). Informační systém nebo organizace /osoba mající informační vazbu se zkoumaným ITS systémem se nazývá terminátor. Typickým terminátorem ITS systému jsou osobní databáze řidičů či dopravního personálu, vnitřní informační systémy a databáze jednotlivých dopravních organizací, dopravci, přepravci, státní správa a územní samospráva, řidiči, atd. Definici přesného rozhraní ITS systému a terminátorů zobrazuje tzv. kontextový diagram (viz. obr. 2).
Obr. 2 - Kontextový diagram
8
Tato metodika byla uplatněna při tvorbě koncepce dopravní telematiky na Ředitelství silnic a dálnic ČR, kde bylo shledáno, že jednotlivé definované silné procesy buď již existují nebo jsou ve výhledovém plánu rozvoje této organizace. Další formy architektur definované v kap. 1.2 jsou více abstraktní a tím i hůře použitelné pro získávání potřeb uživatelů systému.
7
Každý silný proces je možno dekomponovat na jednotlivé funkce, databáze a informační vazby na předdefinované rozlišovací úrovni. Každou funkci získanou dekompozicí silného procesu na dané rozlišovací úrovni je možno dále rozložit na podfunkce (viz. obr.3)9. Tento rozklad si následně vyžádá i rozklad informačních vazeb, čímž vznikne model ITS systému na jemnější úrovni. Celý tento proces lze opakovat a získávat stále jemnější a jemnější popis ITS systému. Samozřejmě s větší rozlišovací úrovní je obtížné sledovat jednotlivé vazby a je stále složitější architekturu ITS systému udržovat tak, aby sloužila svému účelu.
Obr. 3 - Rozlišovací úrovně ITS systému
Jak bylo již řečeno, řešitelé se snažili nalézt vhodný poměr mezi hloubkou podrobnosti ITS architektury a využitelností ITS architektury v co nejvíce aplikacích a podmínkách (region, město, různé dopravy, atd.). Je zřejmé, že některé funkce, podfunkce, informační vazby či databáze se budou v procesech objevovat vícekrát, čímž bude docházet k propojení jednotlivých silných procesů (vznikne více dílčích procesů). Čím jemnější popis ITS systému, tím větší souvislosti lze objevit mezi jednotlivými silnými procesy a tím větší je provázanost jednotlivých funkcí a vazeb. Z hlediska tvorby ITS architektury je velmi důležitým bodem návrh systémové integrace jednotlivých funkcí a databází tak, aby daná funkce či databáze byla využitelná v co nejvíce silných procesech. Shluková analýza provedená nad jednotlivými funkcemi, podfunkcemi a databázemi případně informačními vazbami vede na vznik logické ITS architektury, která sdružuje jak funkční tak informační architekturu.
9
Definování a uspořádávání makrofunkcí, funkcí a podfunkcí odpovídá architektuře determinované objektem, v tomto případě funkčností ITS systému.
8
Pokud se objeví požadavek přidání dalšího silného procesu např. vlivem dalšího vývoje ITS v ČR, je třeba daný proces dekomponovat jako v případě tvorby ITS architektury a provést kontrolu pokrytí tak, aby se maximálně využilo stávajících funkcí, podfunkcí, databází a daný proces bylo možno namapovat na stávající logickou architekturu. Tím se sníží investice do vzniku paralelní infrastruktury se stejnou funkčností. Bude-li nový silný proces obsahovat prozatím neexistující funkci, podfunkci, databázi, informační vazbu, bude tento prvek do architektury přidán a bude ho možno využít ve všech dalších nových procesech. K jednotlivým funkcím, podfunkcím, databázím případně i informačním vazbám lze přidat jednotlivé atributy, jako je geografická lokalizace, organizační začlenění, atd. Tímto postupem je možno sdružovat jednotlivé funkce vztažené k danému fyzickému subsystému, jako je např. jednotka ve vozidle, čipová karta řidiče /cestujícího, centrum řízení, atd., čímž jsou získány funkční požadavky na jednotlivé subsystémy10 a zároveň i požadavky na komunikaci mezi těmito subsystémy11. ITS datový registr přiřazuje k jednotlivým prvkům ITS architektury dostupné technické i organizační informace, jako je např. použitá digitální mapa, použitý software, kvalita a četnost ukládaných dat v ITS databázích, atd. Informačním propojením ITS architektury a ITS datového registru vzniká analytický nástroj pro tvorbu ITS strategie a implementace ITS systémů. Na základě vytvořené ITS architektury informačně svázané s ITS datovým registrem lze modulárně řešit zavádění jednotlivých ITS aplikací dle platné dopravní politiky, strategie či záměru státu, regionu, města, atd. Naplňování jednotlivých funkcí ITS architektury v časovém měřítku na principu modularity vede k definování ITS architektury determinované záměrem (strategií). Záměrem v tomto případě je Koncepce dopravní telematiky ČR řešená paralelně s vlastní ITS architekturou.
1.4 Metodika ITS datového registru Systémy uvedené do provozu ve velkých organizacích typu dopravy byly historicky vytvořeny k řešení specifických problémů na základě pevně definovaných podmínek. Uvedení každého nového systému zvyšujícího nějakým způsobem výkon a efektivitu organizace má za následek vzrůst složitosti celkové struktury daného prostředí a způsobuje obtíže při výměně dat mezi jednotlivými systémy. Z hlediska tvorby systémů bylo často definováno rozhraní pouze pro spolupráci s jedním systémem, což dnes způsobuje potíže při provádění výměny a sdílení dat mezi více systémy. Dalším problémem je používání stejného názvu pro různé typy dat, nebo rozdílné definování významu dat v různých systémech. Pro ilustraci je uvedena tabulka 1, kde jsou výše uvedené problémy demonstrovány na příkladu letu letadla. Pro každou jeho pozici (levý sloupec) existuje různá kombinace dat k jejímu vyjádření (pravý sloupec, rychlosti IAS, TAS jsou jednoznačně definovány, zde slouží pouze jako příklad ve spojení s výrazy ze sloupce pozice)
10
Tyto požadavky mohou sloužit pro zadávání vývoje jednotlivých komponent ITS systému ze strany státní a veřejné správy. Kromě základních funkčních požadavků je možno k jednotlivým funkcím přiřadit i systémové požadavky (performance requirements) např. na bezpečnost, dostupnost, spolehlivost, integritu, atd., které definují zabezpečení dat, kódování informací, redundanci fyzických modulů, atd. 11 Tyto požadavky vedou na definici předávaných informací, případně na další atributy jako je bezpečnost, dostupnost a spolehlivost přenosu. Na základě těchto informací lze definovat jak přenosovou technologii (SDH, ATM, atd.) tak protokol přenosu.
9
Tabulka 1 – Možné varianty v datech o letu: Pozice
Vyjádření pozice Čas: UTC, lokální, uplynulý Rychlost: IAS, TAS, GS
Aktuální Vypočtená Přidělená Předpokládaná Poslední Následující
Jednotky rychlosti: KT, Mach Výška: AMSL, AGL, FL Jednotky výšky: stovky stop, stopy Souřadnice: WGS 84, sférické
Řešením, které by zabezpečilo integraci dat, jednotnost významů, atd. je tzv. ITS datový registr. Zavedení datového registru do prostředí ITS má následující výhody: • Kvalita dat a přístup k nim – kvalita bude zlepšena snížením dvojznačnosti podobných dat z různých systémů. Pomocí přístupu k širokému spektru dat bude možné provádět analýzy, které povedou k dalšímu zlepšení dat v oblasti dopravy. • Interoperabilita – standardizací datového registru se výměna dat výrazně zjednoduší, čímž se zjednoduší i zavádění nových ITS systémů. Pomocí datového registru bude umožněna i komunikace mezi staršími systémy, u kterých to dříve bylo vyloučené. • Efektivita nákladů – finanční prostředky mohou být využity mnohem efektivněji, pokud jsou vynaloženy pouze jednou na standardizaci dat. Pokud by standardizace neproběhla, byly by finanční prostředky vynakládány opakovaně na více místech s neuspokojivým výsledkem, např. překlad nestandardních formátů dat mezi systémy, atd. • Flexibilita – nové služby vytvořené pomocí automatizovaných nástrojů dovolují aktualizaci a zavádění nových standardů téměř v reálném čase a u všech uživatelů jednotně, čímž je zajištěna i nutná synchronizace standardů. Otevřená filozofie přístupu do registru ponechá také volný prostor k uplatnění specifických potřeb uživatelů. Různé termíny a pojmy používané v ITS se liší a proto je třeba nejprve provést v rámci této zprávy ujednocení základních definic: • Atribut – charakteristika objektu nebo entity • Data – hodnoty nesené datovými elementy • Datový element (datový prvek podle standardu ÚVIS) – jeden údaj o objektu jako výsledek pozorování, měření, konstatování • Datový koncept – definovaná struktura dat ze slovníku dat používaná v ITS registru (do datového konceptu spadá i datový prvek) • Datový prvek – (obecně) jednotka dat, která je v daném kontextu považována za nedělitelnou • Datový sklad – zařízení, kde jsou fyzicky uloženy datové elementy • Hodnota datového prvku – hodnota (např. číslo, znak nebo logická hodnota), kterou může nabývat daný datový prvek
10
• Metadata – informace o datech nebo o datových elementech (určují jejich charakteristiky a udávají jejich doplňující informace), kde konkrétní informace jsou vyjádřeny pomocí atributů • Složený datový prvek – datový prvek složený (podle Standardu ÚVIS pro popis datových prvků) ze dvou nebo více dílčích datových prvků.
1.4.1 Obsah datového registru Datový registr je produkt určený ke správě informací. V podstatě jde o databázi informací o informacích, která říká jaká data a kde jsou obsažena, kdo poskytuje data, za jakých podmínek, jak často atp. K určení těchto vlastností se používají metadata (standardizované výrazy, které umožňují vyhledávání a třídění dat). Datový registr tedy neobsahuje samotná data, ale jen návod, jak a kde data získat včetně jejich vlastností (rozsah, formát, administrativní atributy, atd.). Normy ISO 11179 a 14817 definují datový registr následovně: Informační zdroj spravovaný registračním úřadem popisující význam a formu datových elementů, zahrnující registrační informace, definice, názvy, formáty hodnot, metadata a administrativní atributy. Obsah datového registru zahrnuje dvě hlavní oblasti týkající se datových elementů: • Standardy datových elementů – které podporují výměnu dat, zlepšují interoperabilitu systémů, zlepšují management registru, usnadňují vývoj nových systémů a úpravu systémů starých. • Informace o stávajících datových elementech a jejich napojení na nové standardy – popisují obsah stávajících datových elementů (metadata) a ukazují na jejich ekvivalent v nově stanovených standardech vytvořených pro datový registr. Udávají také poskytovatele, správce a umístění těchto dat ve stávajících systémech. Pro zamýšlený datový registr ČR (ať už pro jednotlivé druhy doprav budou vybudovány jednotlivé datové registry nebo bude vytvořen jeden centrální datový registr pro všechny druhy doprav) bude nutné zjistit, jaká data jsou k dispozici v elektronické formě včetně jejich formátu, umístění, přístupových práv, atp. Obr. 4 zobrazuje rozdíl mezi daty a metadaty. Jako příklad je uveden datový element ICAO značící zkratku letiště. Metadata popisují všechny vlastnosti daného datového prvku formou atributů. Atributy v tomto případě jsou: název datového elementu (identifikace letiště v kódu ICAO), definice (jednoznačný kód přiřazený letišti) a formát (4 znaky). Data v tomto případě reprezentují konkrétní kód letiště (LKPR).
Obr. 4 - Data a metadata – příklad ICAO zkratky letiště Praha – Ruzyně
11
Atributy jsou rozčleněny do několika skupin a kategorií. V případě specifických potřeb ITS systému je možné doplnit vlastní atributy tzv. rozšiřujícími atributy. Při jejich zavádění a pojmenování je nutno vycházet z doporučení normy ISO 14817. Konkrétní výčet atributů dle ISO 14817 a je uveden v následujících tabulkách: • Identifikační - tato skupina atributů odděluje každý konkrétní datový koncept jeden od druhého. Identifikátor a verze se doplňují automaticky. Název atributu
Popis
Identifikátor datového konceptu
Je automaticky přiřazen k datovému konceptu vstupujícímu do ITS registru. Jeho formát závisí na správci datového registru.
Verze datového konceptu
Určuje jiné než významové změny datového konceptu, které nemají vliv na celkovou změnu datového konceptu.
Popisný název
Udává význam datového konceptu.
Synonymum popisného názvu
Název lišící se od popisného jména, ale reprezentující stejný datový koncept. Může se vyskytovat i u více stejných datových konceptů.
Symbolické jméno
Název užívaný v aplikačních programech.
ASN.1 jméno
Název datového konceptu vyjádřený podle ASN.1.
Identifikátor zprávy
Jednoznačná identifikace zprávy podle ASN.1, jak je definováno v normě ISO 8824-1.
ASN.1 identifikátor objektu
Celosvětově jednoznačná identifikace objektu podle ASN.1 pro některé datové koncepty.
URL
Udává URL pro nalezení metody sestavení a čtení datového konceptu, který není v ITS registru.
• Definiční - skupina popisuje významové aspekty datového konceptu a to buď přímo (definice) nebo nepřímo (zdroj). Název atributu
Popis Otevřený text vyjadřující význam datového konceptu, slouží člověku pro
Definice
12
snadnější orientaci. Kontext popisného jména
Určuje oblast (subsystém), kde se datový koncept používá.
Použití popisného jména
Udává jména aplikací, kde se datový koncept používá.
Zdroj
Dokument, podle kterého byl datový koncept vyvinut.
Odkaz na architekturu
Název ITS architektury, její zdroj a umístění, do které může být datový koncept začleněn.
Název architektury
Udává označení architektury a její oblast působení.
Verze architektury
Číselně udaná verze architektury.
Typ datového konceptu
Základní typ datového konceptu.
Poznámka
Text v otevřené řeči souvisejí s datovým konceptem.
Kontext
Další příslušné okolnosti datového konceptu.
Norma dat
Označuje normu nebo dokument, který definuje datový koncept.
Zdroj metadat
Udává, kde jsou umístěna metadata používaná k popisu a interpretaci datového konceptu.
Priorita
Vyjadřuje jakou má zpráva prioritu před ostatními zprávami v systému.
Frekvence / mód zprávy
Udává periodicitu nebo podmínku pro odesílání zpráv.
Kontrola doručení
Indikuje, zda je požadováno potvrzení přijetí zprávy, případně kdy je nutné uskutečnit pokus o opakované zaslání.
Tělo zprávy (rámec)
Popis uspořádání zprávy nebo datového rámce podle ASN.1. (výčet a umístění jednotlivých datových elementů).
• Relační -tyto atributy dokumentují vztahy mezi datovým koncepty. Název atributu
Popis Sémanticky starší datový koncept, který je nahrazován aktuálním.
Předchůdce Následovník
Sémanticky novější
13
datový koncept, který nahrazuje aktuální. Synonymum
Sémanticky podobný datový koncept.
Výtah
Indikuje, zda třída objektů obsahuje objekty.
Funkce
Udává funkce třídy objektů v asociaci.
Počet vztahů
Počet případů, při kterých je aktuální datový koncept spojen s daným datovým konceptem.
Omezení asociace
Udává jakákoli zvláštní omezení pro asociaci.
Vztah celku a částí
Indikuje, zda třída objektů označuje celek v asociaci.
Funkční klíč
Mechanismus, při kterém je třída objektů označena jako zvláštní případ.
Indikace vztahu mezi třídami objektů
Indikuje vztah aktuální třídy objektů k ostatním třídám objektů v asociaci.
Odkazované zprávy
Soubor zpráv účastnících se dialogu.
Odkazované datové rámce
Soubor datových rámců používaných ve zprávách nebo dialozích.
Odkazované datové elementy
Soubor datových elementů používaných ve zprávách nebo datových rámcích.
Odkazované třídy objektů
Soubor tříd objektů používaný ve vyšších typech datových konceptů.
Odkazované asociace
Soubor asociací používaný v dialozích.
• Reprezentativní - popisují požadavky na fyzické zastoupení datových prvků a formátů hodnot a jejich zobrazení v databázích nebo uživatelských rozhraních. Název atributu
Popis
Typ dat
Určuje typ vyjadřovaných dat tak, jak jsou definovány v ASN.1.
Formát
Popis otevřenou řečí uspořádání
14
datového konceptu. Měrná jednotka
Udává jednotky míry nebo stupně ohodnocení.
Pravidlo platnosti hodnoty
Možný rozsah hodnot nebo podmínky jejich platnosti.
• Administrativní – udávají původní organizaci, poskytovatele, registrátora atd. Název atributu
Popis
Stav registrace
Vyjádření stavu registrace datového konceptu (udání úrovně).
Datum registrace
Datum první registrace datového konceptu do ITS datového registru.
Datum poslední změny
Datum, kdy byla poslední verze datového konceptu zaznamenána do datového registru.
Poslední měnící subjekt
Název uživatele, který provedl poslední změnu datového konceptu. Odkaz na subjekt, který registroval datový koncept.
Údaje registrátora Telefonní číslo registrátora
Telefonní číslo registrátora. Odkaz na subjekt, který zodpovídá za poskytování datových konceptů.
Údaje poskytovatele Telefonní číslo poskytovatele
Telefonní číslo poskytovatele. Odkaz na subjekt, který podává datové koncepty k registraci.
Údaje zasilatele Telefonní číslo zasílatele
Telefonní číslo zasílatele.
Uživatel
Název subjektu, který má práva pouze pro čtení.
Náhled
Logické uskupení obsahu datového registru z hlediska funkčního, objektového, standardizačního.
Vztažené skupiny
Popis poskytovatelů, kteří mohou být ovlivněni změnou datového konceptu.
Třída bezpečnosti
Stupeň zabezpečení datového konceptu proti nepovolenému přístupu.
15
Je zřejmé, že pro dosažení požadované kompatibility, budou muset být vytvořeny standardy i pro samotné atributy. Tato problematika se týká zejména těchto oblastí přímo souvisejících s definováním atributů: • Klíčová slova – použití slov z pevně daného seznamu atributů usnadní dodržení jednotného popisu datových elementů a přispěje k jejich snazšímu vyhledávání. • Kategorie – každý datový element musí být přiřazen do jedné nebo více kategorií z oblasti jeho působnosti. Vhodným zavedením kategorií se usnadní přístup a vyhledávání datových elementů (metadat o nich). • Názvy – soubor názvů, které se použijí v kontextových atributech k oddělení datových elementů se stejným názvem ale rozdílnou definicí. • Pravidla pro vytváření jmen datových elementů – tato pravidla budou použita pro vytváření nových standardů pro datové elementy nově přidané do datového registru nebo pro použití v nově vyvíjených systémech, již kompatibilních s datovým registrem.
1.4.2 Funkce datového registru Datový registr je zamýšlen jako automatizovaný zdroj informací (metadat), které jsou uloženy v databázi. Autorizovaný uživatel by měl obdržet výstup, splňující všechny jeho potřeby, vložené do dotazu jako požadavky a interpretované při vyhledávání jako atributy, podle níž se daná informace bude vyhledávat. Metadata jsou při registraci rozdělena do pěti stavů podle množství použitých a správně vyplněných atributů. Každá úroveň má stanoven jejich minimální požadovaný výčet a všeobecnou snahou je, aby pokud možno všechna data v ITS byla registrována v co nejvyšší úrovni. Úrovně stavu registrace jsou následující: Stav registrace
Popis
Preferovaný (Preferred)
Výbor pro řízení změn doporučil tento datový koncept upřednostňovat v ITS systému. Všechny atributy vyhovují požadavkům ITS systému.
Kvalifikovaný (Qualified)
Výbor pro řízení změn potvrdil správnost a kvalitu vyplněných atributů.
Zaznamenaný (Recorded)
Navrhovatelem jsou vyplněny všechny povinné atributy, jejichž obsah nemusí odpovídat požadavkům na kvalitu, což znamená, že tento datový element může být sdílen v celém ITS systému.
Navrhovaný (Draft)
Navrhovatel dává všem subjektům ITS systému na vědomí existenci tohoto datového elementu a chce jej postoupit do ITS datového registru. Každá aktualizace elementu jej zcela nahradí a starší verze se nearchivují.
Zapsaný (Card)
Navrhovatel dává všem subjektům ITS systému na vědomí existenci tohoto datového elementu ve své oblasti působnosti a kontroluje také jeho aktualizaci.
16
Navrhovatel může tento element kdykoli vyjmout z registru nebo jej může postoupit stanovenou procedurou do vyššího stavu. Datové elementy jsou popsány množinou atributů. Skupina atributů je nezávislá na použití datového elementu v databázích či aplikacích. Atributy jsou následující: • Povinné - musí být použit bez výjimky • Přiřazené - hodnota atributu je generována automaticky • Volitelné - mohou být použity, jestliže je to požadováno v oblasti působnosti atributu • Vázané - jejich užití závisí na implementaci jiného atributu • Podmínkové - jejich použití závisí na podmínkách užití jiných atributů Funkci datového registru zjednodušeně ukazuje obr. 5. Datovým elementům jsou při registraci přiřazena metadata, která jsou následně uložena do datového registru a jsou podle daných pravidel spravována. Uživatel pomocí dotazu vyhledá požadovaná metadata a s jejich pomocí přistupuje přímo do datových skladů v jednotlivých ITS aplikacích.
Obr. 5 - Funkce datového registru ITS
1.4.3 Správa datového registru Pro zajištění požadovaných služeb datového registru je třeba stanovit nezávislé subjekty, jejich úlohy, funkce, práva a rozsah odpovědnosti. Je třeba se poté dále zabývat jejich legislativní otázkou, a to jak při jejich vytváření a spoluprací
17
s ostatními subjekty pracujícími s ITS registrem, tak zejména z hlediska výkonu jejich funkcí (získávání, poskytování a správa metadat). Následující úlohy při správě datového registru mohou být i sdruženy a přiřazeny několika subjektům, které tak mohou plnit více funkcí najednou, což záleží na konkrétních podmínkách vytváření ITS registru tak, aby sdružování a vykonávání funkcí v daných podmínkách bylo proveditelné. • Pořizování dat – tato funkce vytváří spojení mezi procesem získávání dat a samotným datovým registrem. Kontroluje požadavky získaných dat s požadavky datového registru. • Plánování administrativy – plánuje správu metadat a administrativní záležitosti, spolupracuje se správou registru. • Správa metadat – spravuje metadata během celé jejich životnosti v datovém registru. Spravuje definice stávajících datových elementů a nových standardů, pomáhá také při jejich vytváření. • Správa datových modelů – vytváří datové modely pro datový registr a tím je dána nutnost spolupráce se správou metadat na informacích o jejich vytváření a uchovávání. • Analýza požadavků dat – pracuje se správou jednotlivých aplikací a sleduje jejich data, porovnává je s aktuálním obsahem datového registru. • Analýza bezpečnosti dat – dohlíží na tvůrce aplikací a uživatele, aby dodržovaly bezpečnostní strategie. • Správa databáze – zodpovídá za instalaci a chod základní databáze v datovém registru, její kapacitu, zálohování a implementaci bezpečnostních prvků. • Užívání – činnost uživatelů datového registru. • Prosazování politiky ITS – stanovuje strategie, kterými se bude řídit činnost datového registru a jeho vztah k ostatním částem ITS systému tak, aby jeho činnost byla maximálně efektivní. • Vývoj systému a programování – vytváření transformací a podpůrných programů pro metadata před tím, než jsou zahrnuty do datového registru. • Reprezentace systému – vytváří prostor pro komunikaci mezi datovým registrem a aplikacemi. • Správa nástrojů – testuje a hodnotí IT produkty vhodné pro činnost datového registru. • Vytváření webových databází – vytváří provázání mezi prohlížečem a databází registru, aby bylo možno získávat data i přes webový prohlížeč. Norma ISO 14817 definuje organizační subjekty, které jsou potřebné pro všechny činnosti spjaté se správou metadat (viz. obr 6). Registrační úřad Je to nejvyšší instance, která zastřešuje celý proces schvalování dat, určuje registrátora a správce registru.
18
Registrátor Registrátor je zodpovědný za provádění registrace datových elementů a za jejich zpřístupnění po celém ITS systému. Jedná se zejména o: • monitorování a správu obsahu registru, • prosazování strategií, procedur a formátů pro použití v registru, • navrhování procedur a standardů výboru pro řízení změn ke zvážení, • zaznamenávání současného stavu registrace datového elementu, • zajišťování přístupu pro oprávněné uživatele, • spolupráce při postupné registraci datových elementů, • spolupráce při identifikaci a řešení duplikovaných datových elementů, • plnění příkazů registračního úřadu, • provádění registrací ITS datových elementů i v jiných registrech, • prosazování registrační procedury pro předkládání datových konceptů do registru, • vedení dokumentu obsahující kontakty na členy výboru pro řízení změn a výkonného výboru, • přidávání nových uživatelů, kteří mohou získat přístup do registru. Správce Tento subjekt je zodpovědný za přesnost, spolehlivost a srozumitelnost metadat v přidělené oblasti působnosti. Správci jsou určeni postupem stanoveným registračním úřadem. Jeho činnost norma ISO 14817 popisuje takto: • koordinace rozpoznávání a dokumentování datových elementů v oblasti jeho působnosti, • zajišťování, že správná metadata v jeho působnosti jsou správně registrována, • koordinování s jinými správci k zabránění výskytu a řešení duplikovaných metadat, • opakované kontroly metadat ve stavu "zaznamenaný" a koordinace s jinými správci z jiných oblastí, • zajišťování kvality metadat pro datové elementy "kvalifikovaný", i za pomocí standardů z registru,
registrované
jako
• navrhování statutu "preferovaný" v jeho oblasti působnosti, • zajišťování schválených registračních procedur a datových elementů v jeho oblasti působnosti, • doporučování navrhovatelů registračnímu úřadu. Předkladatel Subjekt doporučený správcem a schválený registračním úřadem. Předkladatel vyhledává a oznamuje datové elementy vhodné k zařazení do datového registru. Je zodpovědný za: • provádění vlastní identifikace pro registrátora,
19
• vyhledávání v registru,
a
dokumentování
datových
elementů
vhodných
k použití
• navrhování datových elementů do registru, • zajišťování kompletních "zaznamenaný".
povinných
atributů
navrhovaných
pro
stupeň
Uživatel Subjekt, který je oprávněn k čerpání informací z datového registru. Předkládá žádosti o přístup do registru, ale není oprávněn k zápisu. Výbor pro řízení změn Výbor provádí technické směrování a harmonizaci dat v registru. Členy tohoto výboru by měly být i předkladatelé. Jeho odpovědnosti jsou: • celkové vedení registračních procedur, • podpora opakovaného použití a sdílení dat v registru a v celém ITS systému, • podpora datových elementů do stavů "kvalifikovaný" a "preferovaný", • vyhledávání datových elementů pro registraci z externích datových registrů, • řešení technických otázek spojených s datovými elementy, • schvalování změn k datovým "kvalifikovaný" a "preferovaný",
konceptům
registrovaným
v úrovních
• navrhování registrační strategie výkonnému výboru ke schválení, • schvalování navrhovatelů, uživatelů registru, • schvalování struktury registru, procedur a formátů, • navrhování doporučení o správě výkonnému výboru, • jednání podléhající výkonnému výboru. Výkonný výbor Výbor je zodpovědný za celkovou strategii registrace metadat a obchodní řízení registru. To zahrnuje: • sestavování celkové strategie datového registru, • řešení obchodních záležitostí týkajících se registru, • zajišťování dlouhodobé výkonnosti a spolehlivosti registru,
• sestavování a aktualizace strategií.
20
Obr. 6 - Organizační subjekty pro správu datového registru
1.4.4 Implementace ITS datového registru Datový registr může být vytvořen dvěma způsoby - buď jako jeden centrální datový registr pro celý ITS systém, nebo budou vytvořeny pro každé odvětví dopravy zvláštní datové registry propojené předem definovaným způsobem. Definicí požadavků na obsah datového registru musí být pověřen pouze jeden subjekt napříč celým ITS systémem, aby se zajistila jednoznačnost a kompatibilita spravovaných atributů. Tento subjekt musí mít zájem na dalším zdokonalování a implementaci nových metadat. Jestliže budou všechna požadovaná metadata určena a definována, stanou se tak základem pro budoucí datové sklady a databáze ITS dle definované ITS architektury, čímž se zvýší interoperabilita mezi jednotlivými ITS subsystémy. Jakmile je určena struktura metadat, odpovědnosti subjektů a organizací správy registru, je možno přistoupit k získávání metadat a jejich třídění. Základem procesu transformace existujících dat na standardizovaná data je přiřazení každého existujícího datového elementu do jednoznačně určených kategorií reprezentujících oblast působení datového elementu např. dle universálního procesního modelu ITS systému. Příklad dané transformace je uveden na obr. 7, kde v levém sloupci je uveden datový element A (například ID vozidla) v různých stávajících ITS systémech, který je uveden pokaždé v jiném formátu, ale který má vždy stejný nebo podobný význam. Tento element A je zařazen do kategorie 1 (v případě kategorizace dle universálního ITS procesního modelu B.1. Data popisující technické parametry dopravních prostředků – elektronická identifikace vozidla) a označen v obrázku podle svého původního systému (na obrázku jako element 1A). Nakonec jsou všechny varianty elementu A přiřazeny do standardizovaného elementu A, který odkazuje zpětně na všechny své varianty ve stávajících systémech.
21
Obr. 7 - Metodika transformace stávajících dat na standardizovaná data
Výše uvedený proces je kontinuální a nové standardy vznikají s potřebami a zdokonalováním vlastního ITS systému. Tyto změny musí být včas ohlášeny všem subjektům se systémem pracujícím a archivovány pro potřeby auditů a zpětných dohledávání. Pro správnou a efektivní funkci je proto třeba je provádět koordinovaně ve vhodných termínech. Získání atributů od všech zúčastněných subjektů lze rozdělit do dvou částí. První je samotná inicializace datového registru a druhá kontinuální aktualizace a přidávání nových dat. Základním předpokladem je opět stanovení požadovaných atributů v ITS systému, což umožní vytvořit metadata pro veškerá data v existujících i budoucích ITS subsystémech. Inicializace datového registru Předpokladem k inicializaci datového registru je stanovení atributů, vytvoření a obsazení organizačních subjektů datového registru a schválení a vytvoření datové i fyzické struktury ITS registru. Na začátku je třeba mít dvě oddělené databáze, jednu pro stávající data a druhou pro nové standardy. Databáze musí vyhovovat očekávaným objemům dat a musí být zajištěna její správa, zálohování a obnovování. S těmito předpoklady probíhá inicializace dle obr 8. Na straně stávajícího systému (vlevo) musí být mechanismus přístupu k dostatečně definovaným metadatům, která umožní vytvářenému datovému registru, jejich získání a transformaci do své struktury metadat. To je možné buď přímo automatickou cestou mezi databázemi, nebo u nestandardních systémů za asistence správců. Všechny hodnoty získané datovým registrem ze stávajících systémů musí být uchovány přesně v původních hodnotách. K nim může datový registr doplnit informace (požadované atributy) podle svých pravidel. Počet atributů by neměl být příliš malý, protože tak by znemožnil komplexnější vyhledávání podle požadavků různých uživatelů. Neměl by však také přesáhnout rozumný počet, kvůli kapacitním omezením databáze a samotného registru. Na straně datového registru jsou pro jeho správu a potřebu vytvořeny další pomocné databáze: • Databáze kategorií (například podle universálního datového modelu) • Databáze stávajících metadat přímo z původních systémů
22
• Databáze transformovaných metadat z původních systémů • Databáze standardů • Databáze datových modelů • Databáze klíčových slov a definic termínů Pro získávání metadat do datového registru jsou možné dva způsoby. PUSH znamená, že poskytovatel posílá metadata buď pravidelně nebo na základě nějaké události. Posílání metadat by se mělo dít u všech posílajících najednou. Při PULL módu si sám datový registr zjišťuje aktuální verze metadat z aplikací. PULL módu mohou využívat při moderní úrovni databází také poskytovatelé metadat, ale správce datového registru v takovémto případě musí určit pravomoci a označit schválená a neschválená metadata. Dále musí být vytvořeny funkce pro dotazování a přístup do databáze. Pro tento účel je možné při dnešním stavu IT technologií použít aplikaci naprogramovanou i pro webový prohlížeč. Norma ISO 14817 popisuje registraci datových elementů pomocí postupných kroků, které jsou rozlišeny pro každou úroveň datových elementů. Celý proces jejich registrace začíná u předkladatele, tak jak ukazuje obr. 9.
Obr. 8 - Inicializace datového registru
23
Obr. 9 - Proces registrace datových elementů
Předkladatel je zodpovědný za poskytnutí a dokumentaci datových elementů pro registraci do úrovně "pracovně zapsaný", nebo je-li to proveditelné, tak i do úrovně "zaznamenaný". Předkladatel, aby zajistil správnou funkci registru, by měl splnit následující: • rozumět významu datových elementů v jejich oblasti působnosti, také kontextu, významu a jejich zdroji, • připravit návrhy atributů datových konceptů (názvy, definice, další povinné atributy k zajištění charakteristiky a administrace), • poskytnout element k registraci do úrovně "zaznamenaný", jestliže se ujistil, že všechny povinné atributy jsou vyplněny. Správce může ze své oblasti působnosti vybrat datový element, který je předán registrátorovi a schválen výborem pro řízení změn a poté zaregistrován v úrovni "kvalifikovaný" nebo "preferovaný". Aby toho dosáhl, musí splnit následující: • udržovat co nejširší přehled o datech ve své oblasti působnosti, • mít přehled o metadatech z datového registru týkající se jeho oblasti, • ujistit se, že všechny povinné a podmínkové atributy pro status "zaznamenaný" jsou vyplněny a jejich kvalita a srozumitelnost je dodržena, • provádět pravidelnou kontrolu datových elementů z registru pro jejich přesunutí do vyšší úrovně nebo vyřazení, • zveřejňovat účel a možnosti dosažení datového registru. 24
Správa metadat Ideálně je každá aplikace v elektronickém kontaktu s datovým registrem a tak je aktualizace metadat prováděna automaticky mezi databázemi. Jindy je nutno změnit uspořádání metadat v registru, kde tyto změny ovlivní také formát posílaný poskytovateli, což ovlivní jejich výstupy z telematických aplikací do registru. Protože samotné telematické aplikace se liší, budou se lišit i postupy u těchto změn u daných poskytovatelů. Správou samotného registru je pověřen registrátor. Je zodpovědný za činnost datového registru a za možnost přístupu do něho. Pro účely správy byly vytvořeny ještě tři administrativní úrovně registrace datových elementů: • Dočasně kvalifikovaný – udává, že správce potvrdil vyplnění a požadovanou kvalitu povinných atributů. Může to učinit v čase, kdy se předpokládá splnění všech kvalitativních požadavků. • Dočasně preferovaný – udává, že správce doporučil datový element pro všeobecné použití v celém ITS systému, ale schvalovací proces do úrovně "preferovaný" není ještě dokončen. Správce může element registrovat do této úrovně, kdy předpokládá splnění všech požadavků pro úroveň "preferovaný". • Vysloužilý – udává, že výbor pro řízení změn nedoporučil dále tento datový koncept používat v systému ITS. Tyto elementy jsou nadále uchovávány v archivu registru pro zpětné odkazy - může obsahovat také odkaz na element, který jej nahradil. Při změnách metadat v datovém registru se postupuje obdobně jako při zavádění nových metadat, s tím rozdílem, že správce oznámí původnímu předkladateli návrh na změnu od jiného předkladatele. Jenom původní předkladatel nebo odpovědný správce pro úroveň "kvalifikovaný" a vyšší jsou oprávněni ke změnám v registru, ty však musí být schváleny výborem pro řízení změn. Registr sám automaticky poté oznámí příslušným ostatním správcům změny u elementů v úrovni "zaznamenaný". Všechny neshody mezi předkladateli řeší registrátor. Oznamuje také návrh změny ostatním zainteresovaným předkladatelům a při vyšší úrovni než "kvalifikovaný" oznámí výboru pro řízení změn případnou změnu verze (jestli k ní došlo, určí správce). Nastavitelné položky v datovém registru jsou dvojí: • ITS standardní datové elementy, • atributy. Pro snazší řízení změn se využívají ucelené soubory těchto položek, takzvané základní soubory. Toto řízení je prováděno výborem pro řízení změn. Základní soubor může být buď stávající nebo vývojový. Pro normální použití platí stávající, pokud není schválen vývojový. Změny nebo rozšíření položek je vyžadováno v souladu s následujícími procedurami: • správce a registrátor schraňují, ohodnocují a dokumentují požadavky na změny atributů, • správce postoupí tento seznam registrátorovi s doporučeními, • registrátor návrhy s doporučeními předá výboru pro řízení změn, • výbor pro řízení změn rozhodne, • registrátor oznámí správcům stav každého návrhu.
25
Registrátor provádí pravidelnou kontrolu současného uceleného souboru. Ohodnocuje atributy z registru oproti atributům ze stávajícího uceleného souboru. V případě, že datový element je navrhován pro úroveň "vysloužilý" je realizována podobná procedura. Dojde k tomu například při nahrazení jiným elementem. Změna úrovně je provedena registrátorem, při úrovni vyšší než "kvalifikovaný" je třeba souhlas výboru pro řízení změn. Datové elementy v úrovni "vysloužilý" by měly být uchovány v archivu registru pro pozdější odkazy. Datový registr je zamýšlen jako automatizovaný zdroj informací (metadat). Uživatelé díky různým kombinacím dotazů postupem času najdou nové a efektivní cesty, jak tyto informace využívat a proto by bylo vhodné přístup do registru řešit jako ad-hoc. Autorizovaný uživatel by tedy měl obdržet výstup, splňující všechny jeho potřeby, vložené do dotazu jako požadavky a interpretované při vyhledávání jako atributy, podle níž se daná informace bude vyhledávat. Pro zabezpečení funkce datového registru je dále nutné určit subjekty pro jeho správu a rozsah jejich odpovědnosti.
1.4.5 Standardy ÚVIS V této kapitole jsou uvedeny pro příklad části standardů Úřadu pro veřejné informační systémy, které byly vytvořeny pro metadata využívaná systémy veřejné správy a pro jejich výměnu mezi aplikacemi. Standard ISVS pro popis datových prvků 003/01.03 Postup při registraci datových prvků upravuje norma (návrh) ČSN P 97 4001-2 Národní registrace datových prvků. Tato norma popisuje součinnost Správce datového prvku (SDP, tj. většinou Gestorů), Pověřené organizace (PO, tj. ÚVIS) a Registračního úřadu (RÚ, tj. ČSNI). ÚVIS je PO pouze pro zajištění registrace datových prvků standardizovaných v Informačních systémech veřejné správy. Projekt národní registrace datových prvků byl odložen. Náhradou za něj je vytvoření veřejně přístupného informačního systému o datových prvcích, do kterého budou postupně zařazeny všechny prvky z informačních systémů veřejné správy a výhledově i některé prvky užívané mimo veřejnou správu. Základní rozdělení zahrnuje jednoduchý datový prvek a složený datový prvek. Pro popis jednoduchého prvku se používají následující atributy (každý atribut má samozřejmě ještě svůj vlastní popis): Název atributu
Popis
Identifikátor
Identifikátor jednoduchého datového prvku přiřazený Úřadem pro veřejné informační systémy.
Název
Pojmenování prvku, jedno nebo víceslovné určení přiřazené datovému prvku.
Akronym Verze Definice
Zkrácená forma názvu datového prvku. Identifikace vydání specifikace datového prvku v sérii vývoje specifikací datového prvku v rámci ÚVIS. Tvrzení vyjadřující podstatnou povahu datového
26
prvku a umožňující jeho odlišení od ostatních datových prvků. Komentář
Komentář
Související právní předpisy
Odkaz na právní předpisy související s konkrétním datovým prvkem, který ovlivňuje definování atributů prvku.
Související jiné předpisy
Odkaz na předpis, který není právním předpisem, souvisí s konkrétním datovým prvkem a ovlivňuje definování atributů prvku.
Zdroj hodnot ze zákona
Právnická nebo fyzická osoba, v rámci jejíž existence nebo činnosti konkrétní datový prvek vzniká, a to na základě právních předpisů.
Kategorie prezentace
Druh symbolů, znaků nebo jiného způsobu označení užívaného k prezentaci datového prvku.
Forma prezentace
Název nebo popis formy prezentace.
Datový typ hodnot
Množina různých hodnot pro prezentaci hodnoty datového prvku. Používá se, je-li hodnota kategorie prezentace znakový řetězec.
Maximální délka hodnot
Maximální počet znaků nebo číslic, které prezentují hodnotu datového prvku.
Minimální délka hodnot
Minimální počet znaků nebo číslic, které prezentují hodnotu datového prvku.
Schéma prezentace
Schéma zápisu znaků v hodnotách datových prvků vyjádřené znakovým řetězcem nebo symbolikou vycházející z pravidel dosud používaného atributu.
Přípustné hodnoty
Množina prezentací přípustných výskytů datového prvku, která odpovídá formě prezentace, plánu umístění prvků do daného formátu, datovému typu a maximální a minimální hodnotě, jak jsou specifikovány v příslušných atributech a nebo v číselníku.
Číselník
Seznam přípustných hodnot datového prvku, obvykle ve formě dvojic kódovaného údaje a hodnoty jeho kódu.
Správce číselníku Provozovatel
Právní subjekt odpovědný za tvorbu a distribuci číselníku. Organizace odpovědná zejména za tvorbu a správnost datového prvku.
Správce datového toku
Právní subjekt, který nové datové prvky předkládá, navrhuje jejich změnu nebo zrušení.
Platnost od
Datum zařazení jednoduchého datového prvku do Katalogu jednoduchých datových prvků ISVS nebo datum změny základního čísla verze.
27
Standard ISVS pro strukturu a výměnný formát metadat informačních zdrojů 011/01.02 Standard vychází z předběžné normy ČSN P ENV 12657 pro metadata prostorových dat a je rozšířen pro popis datových souborů bez prostorové lokalizace a dále pro popis objektů typu událost, služba, aplikační programové vybavení a dokument. Pro popis dat bez prostorové lokalizace a popis objektů využívá Standard a další dostupné zdroje. Standard definuje strukturu a výměnný formát metadat pro popis: • • • • •
datových souborů s prostorovou lokalizací nebo bez ní, událostí, služeb, aplikačního programového vybavení, dokumentů.
Standard popisuje třídy metadat a jako spojující součást udává nadtřídu (ta je pro všechny popisy datových prvků pomocí metadat společná viz obr. 10). Třída Objekty standardu je nadtřídou podtříd Datový soubor, Událost, Služba, Aplikační programové vybavení a Dokument. Nadtřída Objekty standardu a podtřídy DS, Událost, Služba, APV a Dokument jsou v rámci Standardu hlavní popisované třídy metadat. Třídy Organizace, Osoba a Adresa jsou pomocné třídy, u kterých Standard pouze formalizuje zápis údajů potřebných pro popis ostatních tříd v rámci metadat. Každé třídě je předepsán a nadefinován soubor atributů.
Obr. 10 - Schéma hierarchie tříd metadat
1.4.6 Příklad ITS datového registru (Datový registr FAA) Dobrým příkladem použití ITS datového registru je jeho zavedení ve Federálním úřadu pro civilní letectví USA. Úřadu FAA je podřízeno téměř 200 různých agentur a organizací, každá z nich používá několik informačních systémů vzniklých v různé
28
době za jedním konkrétním účelem a mající tudíž rozdílný přístup k tvorbě, správě a sdílení dat. Celková interoperabilita FAA se stávala stále nákladnější a složitější. Na správu a provoz celého IT sektoru je každoročně vydáváno 2,1 miliardy USD. Postupem doby vznikla potřeba a v zájmu dalšího zefektivnění celého systému spadajícího pod FAA (v podstatě celé civilní letectví USA) informace sdílet mezi všemi subjekty v tomto odvětví. Skupina odborníků po analýze prostředí došla k závěru, že řešením bude vytvoření centrálního ITS datového registru, který by obsahoval jak informace o datech ze starých systémů, tak i nové standardy pro systémy zaváděné, aby se předcházelo zdlouhavé a nákladné konverzi při zavedení sice nového, ale opět jednoúčelového systému, potřebě tyto převodní postupy měnit při přechodu na novější systém a z toho pramenících chyb a nepřesností. Bezpečnost, která patří v letectví na první místo, by se tedy stávala stále nákladnější při stejné úrovni zabezpečení služeb. Přístup k datům obsažených v dílčích systémech by se zrychlil a poskytl mnohem komplexnější výsledek. Postupem času se počítá také s napojením na subjekty mimo FAA, jako například letečtí dopravci, provozovatelé letišť, ministerstvo dopravy a obrany, mezinárodní uživatelé (JAA, Eurocontrol, ICAO). Některé organizace budou datový registr využívat ke zjišťování standardů, většina však ho bude využívat k vyhledávání požadovaných dat, jejich zdrojů a aplikací, které je používají. Datový registr uvedený v dokumentu FAA Data Registry Concepts of Use and Implementation zpracovaný společností Mitre Corp. je vytvořen podle standardů ISO 11179 a 14817. Při jeho tvorbě se tedy na základě aplikace těchto norem participující odborníci přiblížili velmi výhodnému řešení, které se s určitými specifiky (rozsah atributů a nebo správa registru) blíží ITS datovému registru popsanému v předchozí metodice. Výčet atributů sloužících k popisu dat v datovém registru FAA (FDR - FAA Data Registry) je uveden: • Identifikační - tato skupina atributů odděluje každý konkrétní datový koncept jeden od druhého. Identifikátor a verze se doplňují automaticky. Název atributu
Popis Slovní popis datového elementu, musí být jedinečný v daném datovém registru. Popis původu (název aplikace) odkud datový element pochází. Jedinečný kód přiřazený datovému elementu registrátorem Jedinečný kód přiřazený registrátorovi v rámci mezinárodního datového registru. Určuje nevýznamové změny datového elementu, které nemají vliv na celkovou změnu datového konceptu. Subjekt určený jako správce datového registru. Název lišící se od popisného jména, ale reprezentující stejný datový element. Může se vyskytovat i u více
Jméno
Kontext jména Identifikátor dat Identifikátor registrátora
Verze
Registrátor Synonymum názvu
29
stejných datových konceptů. Jestliže se toto vyjádření vyskytuje i u jiných aplikací, je třeba použít kontext synonyma názvu. Musí se použít, když je synonymum názvu z jiného konceptu.
Kontext synonyma názvu
• Definiční - skupina popisuje významové aspekty datového konceptu a to buď přímo (definice) nebo nepřímo (zdroj). Název atributu
Popis Vyjádření, které jednoznačně popisuje datový element. Nejmenší velikost rozdílu mezi hodnotami datového elementu. Nejvyšší akceptovatelná hodnota datového elementu. Nejnižší akceptovatelná hodnota datového elementu. Jednotka užitá při vyjádření datového elementu.
Definice Přesnost Největší hodnota Nejnižší hodnota Měrná jednotka
• Relační -tyto atributy dokumentují vztahy mezi datovým koncepty. Název atributu
Popis
Identifikace klasifikačního schéma
Konkrétní položka klasifikačního schéma
Identifikace klíčového slova
Klíčová slova
Reference na další přidružená data
Typ vztahu
30
Jméno nebo identifikace schéma, které spojuje datové elementy se společnými charakteristikami. Popis identifikující konkrétní klasifikační schéma., kam je přiřazen daný datový element. Určení souboru klíčových slov použitelných pro přístup k popisu datových elementů. Klíčová slova vybraná z určeného souboru. Odkaz na další datové elementy, které mají vztah k popisovanému elementu. Výraz udávající vztah popisovaného datového
elementu k odkazovaným. • Reprezentativní - popisují požadavky na fyzické zastoupení datových prvků a formátů hodnot a jejich zobrazení v databázích nebo uživatelských rozhraních. Název atributu
Popis Typ symbolu nebo jednotky použité k zobrazení datového elementu. Název nebo popis formy zastoupení (kód, text, obraz) Termín popisující typ dat (integer, bit) Maximální počet použitých znaků datového typu. Minimální počet použitých znaků datového typu. Rozložení znaků při reprezentaci datového elementu. Soubor přípustných hodnot datového elementu.
Kategorie zastoupení Forma zastoupení Datový typ Maximální počet znaků Minimální počet znaků Formát Přípustné hodnoty Příklad
Uvedení typického příkladu. Slovní popis dalších vlastností, který není zahrnut v jiných atributech. Odkaz nebo metoda použitá k vytvoření k popisu datového elementu (UML, XML) Popis částí a vztahů mezi datovými elementy tvořící složitější strukturu. Výčet jednotlivých datových elementů tvořících komplexní datový element.
Popis zastoupení Komplexní typ zastoupení Popis - komplexní Komponenty
31
• Administrativní – udávají původní organizaci, poskytovatele, registrátora atd. Název atributu
Popis Kontaktní údaje organizace zodpovědné za obsah povinných atributů.
Zodpovědná organizace
Zasílatelská organizace
Kontaktní údaje organizace zodpovědné za poskytování metadat a jejich změn k registraci.
Datum dodání dat
Datum, kdy byl podán datový element k registraci.
Datum přijetí návrhu
Datum zahájení procesu standardizace
Platnost od
Datum, od kterého může být standard používán (je schválen)
Platnost do
Datum, od kterého standard elementu nemůže být používán.
Řídící identifikátory
Identifikátory přiřazované během procesu registrace a schvalování změn.
Stav registrace
Údaj o stavu registrace datového elementu.
Stav standardizace
Stav elementu z hlediska standardizace.
Priorita standardizace
Údaj o prioritě z hlediska standardizace elementu.
Bezpečnost
Udává třídu bezpečnosti pro elementy.
FAA Data Registry - odkazy Požadavky
Dokument popisující primární zdroje dat.
Jiné požadavky
Dokument popisující alternativní zdroje dat.
Datový model
Ukazatel na použitý datový model.
Technická architektura
Odkaz na architekturu elementu. Seznam dalších odkazů a dokumentů poskytujících dodatečné informace o datovém elementu.
Další odkazy
32
FAA Data Registry - užití Implementace
Seznam systémů a aplikací používajících tento datový element.
Ekvivalence
Udává, jak blízko je datový prvek k uživatelským požadavkům.
Transformace
Popis transformace mezi implementovaným datovým elementem a standardizovaným elementem.
Používané aplikace
Seznam systémů a aplikací se stejnou nebo podobnou definicí datových konceptů.
Časový plán
Plán kdy a jaká data budou uvedena v platnost.
Platná omezení použití
Omezení použití datových elementů.
Aktivita datového modelu
Ukazatel na aktivitu datového modelu. Popis limitů kvality dat reprezentovaným datovým elementem (popis neurčitosti měřených dat, pravděpodobnost, že data jsou narušená)
Kvalita služby
Jsou zde některé odlišnosti dané zejména různorodými potřebami FAA, která jsou díky zaměření vytvářeného datového registru více specifické. FAA stanovil také komplexní požadavky na systém datového registru, které zahrnují část funkční, technickou, vnitřního a vnějšího rozhraní, bezpečnostní, řízení a kontroly konfigurace, požadavky na výpočetní techniku. FDR bude fungovat jako most mezi starými a novými systémy, mezi současnými a budoucími přístupy k nim a mezi stávajícími a budoucími datovými elementy. Bude to zdroj informací o současných systémech a pomůže spravovat informace o datových standardech pro budování nových systémů NAS (National Airspace System) a bude také nástrojem, který umožní uživatelům NAS získávat a poskytovat informace o systémech a jejich procesech i jejich vztazích k okolním uživatelům i jejich systémům. Vztah FDR k okolním subjektům je na obr 12. Hlavní funkce FDR je uchovávat všechny schválené standardizované datové elementy a poskytovat metadata o stávajících datových elementech. Z hlediska softwarového řešení k tomu FDR bude obsahovat nástroje, které jsou nutné pro základní popis a standardy datových elementů z NAS. Tyto nástroje zahrnují také správu databází, datový slovník a datový adresář. • Správa databáze – je to softwarové prostředí používané k vytváření, správě a použití databází, ve kterých jsou uložena metadata. Pro tuto činnost je možné použít komerční databázové produkty. Pomocí správy databází je možné získat hodnoty požadovaných metadat z FDR. • Datový slovník – nástroj pro vytváření a dokumentaci syntaxe datových elementů, případně jejich názvů a definic. Datový slovník může být také již součástí správy databází.
33
• Datový adresář – specializovaný nástroj vytvořený pro dokumentaci umístění datových elementů a k nalezní souborů dat, které tyto elementy používají. Adresář může obsahovat také informace o možnostech přístupu, získání nebo rozsahu hodnot příslušných datových elementů. • Datový registr – samotný nástroj, který kombinuje možnosti datového slovníku, datového adresáře a přidává k nim kontextové informace o datových elementech jako například poskytovatele, práva a odpovědnosti k jejich používání atd. Účelem registru je zahrnovat metadata o významu, standardizaci a použití datových elementů z celé oblasti působnosti FDR. Obr. 11 ilustruje vazbu jednotlivých hlavních nástrojů datového registru. Správa databází leží zcela uvnitř obrazce, který vyjadřuje jejich kombinaci, tedy datový registr.
Obr. 11 - Funkce správy metadat v FDR
Datový registr zpočátku pojme metadata o všech elementech ze systémů IT v FAA. Dnes také existují omezené zdroje metadat, avšak obsahují metadata jen o omezeném počtu datových elementů z malé části systémů, které jsou však odlišné ve své struktuře a proto nekompatibilní. Některé existují jen v papírové formě. Funkce FDR bude základním přínosem k přesné a kvalitní výměně dat mezi všemi uživateli NAS včetně jejich aplikací, jak je zobrazeno na obr 12.
34
Obr. 12 - Vztah FDR k okolním subjektům z hlediska výměny informací
Mimo obecné výhody je vhodné uvést také některé výhody, jak z hlediska leteckého provozu, tak i z hlediska samotné správy systémů v podřízenosti FAA. To znamená ty, kde přístup do registru bude mít přímý příznivý vliv na provoz letecké dopravy v NAS. Provozní výhody z leteckého hlediska jsou následující: • Sjednocení pravidel a významu označení výrobce, modelu a série letadla – hlavním důvodem je snaha o zvýšení schopnosti získat výsledky analýz incidentů v leteckém provozu a získat tak výsledky ze zpráv o selhání materiálu, chybnému rozmístění přístrojů v kabině daného typu. Při získávání dat podle nejednotného klíče, může dojít k nenalezení všech relevantních informací. Tento problém je obzvláště markantní u letadel všeobecného letectví, kde se vyskytuje množství úprav a modifikací. • Integrování několika systémů pro vedení letadel po trati v rámci programu Free Flight – program předpokládá, že všechny části systému (avionika, FMS, operační dispečink provozovatele, řídící letového provozu, ostatní podpůrné aplikace) pracují se shodnými daty v reálném čase. • Správa dat potřebných pro řízení toku letového provozu – vytvořené standardy letových dat umožní rychlejší a přesnější analýzu letových plánů a jejich vrácení provozovateli. To jim dovolí provést změny podle nejaktuálnějších informací blíže času odletu a tak provést let efektivněji z hlediska provozních nákladů nebo času. • Výměna dat s jinými subjekty v letectví jako je Eurocontrol atd. – výměna dat v elektronické formě mezi FAA a Eurocontrolem samozřejmě probíhá, ale každá strana si je dále konvertuje do svého formátu pro další použití. Jsou zde odlišnosti například v definování významu datového prvku. Je zde také vhodné uvést výhody z hlediska správy systémů FAA. Jejich výčet a stručný popis na konkrétním příkladě jednoznačně podporuje obecné výhody uvedené v metodice ITS datového registru. Je z nich patrné, že zavedení datového registru je velkým přínosem i pro tuto druhotnou stránku problému (prvotní je efekt možnosti přístupu k datům z různých systémů). Mezi výhody pro správu systémů patří: • Snížení nákladů na aktualizaci a zavádění nových rozhraní – současný stav systémů a jejich vzájemné komunikace vyžaduje mnoho práce softwarových
35
odborníků při zavádění nebo zdokonalování jednotlivých rozhraní (interface) mezi dvěma systémy. Po zavedení FDR bude tato činnost zdokonalena tím, že požadavky na jednotlivá rozhraní budou dostupná z FDR a pro nové systémy se bude využívat uvedených datových standardů. • Snížení nákladů při pořizování systémů – nedostatek standardů otevírá pro dodavatele možnost vytváření vlastních formátů dat a tedy další přizpůsobení existujícím systémům si vyžaduje dodatečné zdroje na úpravu jejich výstupů i samotných formátů dat. V FDR budou uvedeny datové standardy pro každý zaregistrovaný datový element, možnost další výměny bude tedy výrazně zjednodušena, což bude mít velký efekt na interoperabilitu všech systémů FAA. • Zdokonalení struktury systému NAS – současné chování je silně determinováno fyzickou strukturou, která je charakterizována složitou a nedostatečně dokumentovanou soustavou různých sítí, což přispívá k celkové degradaci a snižování efektivity právě při spolupráci mezi systémy zahrnutými v NAS. Pomocí získaných metadat bude umožněn co nejefektivnější přístup k datům a tím zlepšena výkonnost stávajících komunikačních zařízení. • Budoucí zřízení datového skladu FAA – zdokonalení výkonnosti a širší možnosti při získávání informací pro leteckou dopravu podnítí vznik datového skladu uvnitř FAA, který napomůže jeho agenturám vytvářet podrobné analýzy a podklady pro další rozhodování. • Zdokonalení analýzy procesů – existence datových modelů, metadat a datových standardů ulehčí získávání samotných dat pro zdokonalené nebo i dříve nerealizované analýzy a studie. • Integrace automatizovaných nástrojů – v dnešní době je zavedeno množství automatizovaných systémů, které sbírají data z několika zdrojů a podporují rozhodovací proces, což vyžaduje mnoho transformací dat a má za následek vznik nepřesností. Zavedením standardů se tento proces zrychlí a jeho výsledek se zpřesní. Všeobecná vyspělost USA v telematických aplikacích se projevila i v tomto případě. Datový registr je chápán komplexně a je velkým příslibem do budoucna, zejména pro možnost napojení všech dalších subjektů působících v oblasti civilní letecké dopravy v USA. FAA vytvořením úvodních prací, zavedením subjektů pro správu datového registru a stanovením procesu registrace elementů získal značnou výhodu, a to zejména z těchto důvodů: • S vývojem ITS datového registru bylo zahájeno s velkým předstihem, což umožní připravenost jednotlivých organizací na příchod tohoto nástroje a výhledově také přípravu na otevření datového registru pro aerolinie, letiště, jiné státní a federální organizace a létající veřejnost. • Od počátku počítá ITS datový registr se zahrnutím všech dostupných datových elementů v oblasti letecké dopravy, aplikací a zejména nových standardů, aby postupem času při vývoji nových systémů bylo použito právě těchto registrovaných standardů. • Rozsah a počet atributů umožní v podstatě registraci dat i z jiných oblastí, než je letectví. Tato univerzalita vytváří značný prostor i pro data z aplikací, které ještě nejsou vyvinuty, a pro možnost sdílení s jinými registry navrhovanými podle normy ISO 11179. Je samozřejmostí, že atributy se časem mohou podle potřeby rozšiřovat, aby datový registr stále plnil stanovené úkoly. • ITS datový registr je navržen tak, aby jej bylo možno provozovat na stávající technice používané v informačních technologiích (běžné hardwarové i softwarové nástroje). Běžný uživatel dokonce bude moci zadávat své dotazy i 36
přes webový prohlížeč. Přednost je však dána automatizovanému přístupu bez zásahu člověka.
2. ITS ARCHITEKTURA ČR Následující kapitoly zprávy popisují souhrnně jednotlivé části ITS architektury ČR, kde kompletní popis jednotlivých funkcí a informačních vazeb je uveden v přílohách této zprávy. Jako příklad praktické implementace ITS architektury na národní úrovni řešitelům posloužila národní ITS architektura Francie (ACTIF), která byla též využita při tvorbě národní ITS architektury Itálie (ARTIST), kde jednotlivé prvky ITS systému byly analyzovány ve vztahu k procesnímu modelu ITS systému, případně k dalším dostupným specializovaným architekturám, jako např. THEMIS pro multimodální dopravu, atd. 2.1 Procesy v ITS systému dominované infrastrukturou
ITS procesy dominované infrastrukturou A. Dopravní infrastruktura A.1. Infrastruktura dopravní cesty A.1.1. Sledování technického stavu dopravních cest • parametry dopravní cesty (mapy dopravní sítě, pasporty technického vybavení dopravních cest, lokalizace poškození infrastruktury dopravní cesty, atd.) • omezující a bezpečnostní parametry dopravní cesty (rozdělení dopravních cest podle tříd12, označení míst omezené rychlosti, označení míst častých nehod, označení míst nevhodných pro nebezpečný náklad, označení uzávěr, atd.) • pasporty dopravních cest
A.1.2. Sledování klimatických a povětrnostních podmínek na dopravních cestách • povětrnostní parametry měřené na dopravní cestě (náledí, vlhkost, teplota, atd.) • související klimatické a povětrnostní podmínky (informace z meteorologických ústavů, informace o znečištění životního prostředí, atd.)
A.1.3. Sledování, řízení, hodnocení provozu a údržby technických zařízení dopravních cest • diagnostické, dohledové a bezpečnostní systémy infrastruktury dopravních cest • energetické a zabezpečovací systémy infrastruktury dopravních cest 12
definice třídy dopravní cesty je chápána buď dle zavedených pojmů (dálnice, rychlostní komunikace atd.) či z hlediska tvorby telematických systémů s vazbou na charakter dopravy na dopravní cestě
37
• sledování a řízení údržby dopravních cest (např. dle predikovaných klimatických podmínek) • management dopravních cest
A.1.4.
Plánování a rozvoj dopravních cest • sledování změn dopravních toků (predikce dopravních toků) • podpora pro rozhodování při modernizaci dopravních cest • vazba na dopravní politiku • plánování rozvoje dopravních cest
A.2. Infrastruktura dopravních terminálů A.2.1.
Sledování technického stavu dopravních terminálů • parametry dopravních terminálů (pasporty technického vybavení dopravních terminálů, atd.) • omezující a bezpečnostní parametry dopravních terminálů (rozdělení dopravních terminálů podle tříd, omezení provozu terminálů - např. dle parametrů dopravních prostředků, atd.) • pasporty dopravních terminálů
A.2.2. Sledování klimatických a povětrnostních podmínek v dopravních terminálech • povětrnostní parametry měřené v dopravním terminálu (náledí, vlhkost, teplota, atd.) • související klimatické a povětrnostní podmínky (informace z meteorologických ústavů, informace o znečištění životního prostředí, atd.)
A.2.3. Sledování, řízení, hodnocení provozu a údržby infrastruktury dopravních terminálů • diagnostické, dohledové a bezpečnostní systémy infrastruktury dopravních terminálů • energetické a zabezpečovací systémy infrastruktury dopravních terminálů • sledování a řízení údržby dopravních terminálů (např. dle predikovaných klimatických podmínek) • management údržby dopravních terminálů
A.2.4.
Plánování a rozvoj dopravních terminálů • sledování nárůstu dopravních výkonů v terminálech • podpora pro rozhodování při modernizaci dopravních terminálů • vazba na dopravní politiku
B. Dopravní prostředky B.1. Monitorování dopravního procesu (z pozice dopravního prostředku) B.1.1.
Monitorování situace dopravního provozu • rozpoznávání překážek na dopravní cestě • noční vidění
38
• rozpoznávání dopravních značení (dopravní značky, krajnice vozovky, atd.) • automatická identifikace jiných účastníků dopravního provozu (chodci, atd.) • sledování charakteristik provozu (např. plovoucí vozidla)
B.1.2.
Monitorování reakcí řidiče při řízení dopravního prostředku • identifikace poklesu pozornosti řidiče • monitorování interakce řidiče s technickým vybavením dopravního prostředku • přizpůsobení parametrů dopravního prostředku reakcím řidiče
B.1.3.
Monitorování technického stavu dopravního prostředku • diagnostika dopravního prostředku • dálkový servis dopravního prostředku • identifikace odcizení dopravního prostředku
B.2. Ovlivňování dopravního prostředku B.2.1.
Informační systémy • rozesílání dopravních informací do dopravního prostředku • rozesílání meteorologických informací do dopravního prostředku • dálkové informační služby pro dopravní prostředky (SOS, informace o odcizení dopravního prostředku, servisní služby, služby Internetu)
B.2.2.
Navigační systémy • autonomní navigace dopravního prostředku • dynamická navigace dopravního prostředku (vedení dle aktuálního stavu dopravní cesty) • on-line navigace dopravního prostředku (optimální trajektorie je počítána v centru)
B.2.3.
Automatické vedení dopravního prostředku • autopilot • automatické udržování vzdálenosti • automatické omezování rychlosti • protisrážkové systémy • bezpečné vedení dopravního prostředku
C. Dopravní procesy C.1. Řízení provozu (pohybu dopravních prostředků) na dopravní cestě C.1.1
Řízení dopravního provozu • monitorování dopravního provozu (sběr dopravních informací) • automatická identifikace kongescí a nehod • řízení dopravy dle kategorií dopravních cest a charakteru dopravy (města, koridory, atd.) • informace o dopravním provozu před cestou
39
• informace o dopravním provozu během cesty (návěsti případně informační tabule na dopravní cestě)
C.1.2.
Řízení oběhu vozidel nákladní dopravy13 • dispečerské řízení vozidlového parku nákladní dopravy • řízení a monitoring dopravních prostředků (vozidel) přepravujících nebezpečný náklad • ekonomika nákladní dopravy
C.1.3.
Spolupráce záchranných a bezpečnostních složek • dispečerské řízení záchranných a pohotovostních vozidel • krizový management pro minimalizaci dopadů havárií
C.1.4.
Řízení provozu veřejné osobní dopravy • preference dopravních jednotek veřejné dopravy • systémy pro zvýšení bezpečnosti veřejné dopravy • management veřejné dopravy
C.2. Řízení (pohybu dopravních prostředků) v dopravních terminálech C.2.1.
Systémy operativního řízení provozu v dopravních terminálech • logistika uvnitř dopravního terminálu • managerské informační systémy • řízení manipulace s nákladem v dopravním terminálu • řízení multimodálních logistických center
C.2.2.
Řízení oběhu nákladních vozidel v dopravních terminálech • dispečerské řízení vozidlového parku nákladní dopravy • řízení a monitoring dopravních prostředků (vozidel) přepravujících nebezpečný náklad • ekonomika nákladní dopravy
C.2.3. Spolupráce záchranných a bezpečnostních složek v dopravních terminálech • dispečerské řízení záchranných a pohotovostních vozidel v dopravních terminálech • krizový management pro minimalizaci dopadů havárií v dopravních terminálech
C.2.4. Řízení provozu veřejné osobní dopravy v dopravních terminálech • dispečerské řízení dopravních jednotek veřejné dopravy v dopravních terminálech • systémy pro zvýšení bezpečnosti veřejné dopravy v dopravních terminálech • management veřejné dopravy
13
Řízení se provádí prostřednictvím dispečerského centra dopravce
40
C.3. Procesy související s dopravním provozem C.3.1.
Ekonomika dopravního procesu • zpoplatnění použití dopravní cesty • elektronická platba za použití veřejné osobní dopravy • elektronická platba za využití terminálu • elektronické výměna dat mezi jednotlivými dopravci (clearing) • výpočet interních a externích nákladů souvisejících s dopravním procesem • ekonomika dopravních cest a terminálů
C.3.2.
Vymáhání a prosazování předpisů a zákonných ustanovení • varovné a dohledové systémy (jízda na červenou, přetížení vozidel, atd.) • kontrola zaplacení povinných (zákonných) poplatků • evidence prvků a vybavení dopravních cest z hlediska zákonných norem (např. UTZ v rámci železniční dopravy)
C.3.3.
Systémy pro podporu elektronické výměny informací • systémy pro podporu elektronického celního řízení • komunikační systémy EDI • elektronická komunikace s orgány státní a veřejné správy
D. Dopravní personál D.1. Řídící dopravního provozu14 D.1.1.
Sledování zdravotního a fyzického stavu dispečerů • identifikace dispečera (ID karta) • databáze stavu a výběru dispečerů • prevence - kontrola požití alkoholu nebo drog • zvyšování pozornosti řídících zaměstnanců • volba vhodné interakce řídící zaměstnanec - telematický systém
D.1.2. Sledování dodržování bezpečnostních předpisů řídících dopravního provozu • stav a plánování intenzity dopravního provozu ve vazbě na přepravní proudy, na krizová místa infrastruktury, na stav dopravních prostředků, atd. • nástroje pro monitorování práce řídících zaměstnanců • volba vzdělávacích a školících programů (tréninkové simulátory) • kontrola objektivnosti hlášení podávaných řídícími zaměstnanci
D.2. Profesionální řidiči15 a piloti
14
Je součástí řízení dopravního toku popřípadě dopravního parku dopravce - fleet management Pod pojmem řidič rozumíme zaměstnance určeného pro vedení kolejového dopravního prostředku (strojvůdce), řidiče silničního vozidla (veřejného i soukromého), posádky určené k řízení plavidla.
15
41
D.2.1. a pilotů
Sledování zdravotního a fyzického stavu profesionálních řidičů • identifikace řidiče, pilota (ID karta) • evidence platnosti zdravotních prohlídek řidičů - požadavek na národní samostatnost a celoevropskou platnost • prevence - kontrola požití alkoholu nebo drog • zvyšování pozornosti řidičů (např. proti mikrospánku) • volba vhodné interakce řidič - telematický systém
D.2.2. Sledování dodržování bezpečnostních předpisů profesionálními řidiči a piloty • personální práce, plánování nasazení, dodržování provozní doby, střídání posádek, atd. • monitorování přestupků a nehod • volba vzdělávacích a školících programů (telematické a navigační systémy a jejich používání v dopravě) • volba organizace práce (odpočinky) • evidence platnosti průkazů způsobilosti k řízení dopravního prostředku
E. Přepravní procesy E.1. Přeprava osob E.1.1.
Identifikace osob • identifikace cestujících (jízdenky, čipové karty) • identifikace řidičů
E.1.2.
Řízení přepravy osob • platba čipovou kartou případně universálním platebním médiem • rezervační systémy v osobní přepravě • systémy pro odbavování zavazadel cestujících • integrované systémy jízdních řádů pro cestující • informační kiosky pro cestující (mobility center) • telematické systémy pro hendikepované spoluobčany • statistické informace o osobní veřejné dopravě pro státní a veřejnou správu
E.2. Přeprava nákladů E.2.1.
Identifikace nákladů • identifikace nákladů (elektronické nákladní listy, konosament)
E.2.2.
Řízení přepravy nákladů • systémy pro řízení a sledování přepravy nebezpečných nákladů • logistika nákladů v multimodálních přepravních systémech • informační systémy pro optimalizaci přepravy nákladů • statistické informace o pohybu zboží pro státní a veřejnou správu • elektronická celní deklarace nákladu
42
• platby za přepravu zboží
2.3 Kontextový diagram ITS systému ČR Základem analýzy ITS systému je definování rozhraní mezi vlastním ITS systémem a okolí ITS systému, tzv. terminátorů ITS systému. Obr.13 zobrazuje vztah ITS systému a terminátorů ITS systému, kde detailní popis jednotlivých terminátorů je uveden v Příloze 4 této zprávy.
Obr. 13 - Kontextový diagram ITS systému ČR
2.4 Funkční ITS architektura ČR (shrnutí) Funkční architektura zachycuje základní makrofunkce, funkce, podfunkce, případně p-funkce ITS systému dle požadavků uživatelů na tento systém. Definice makrofunkcí byla provedena v rámci projektu KAREN, kde bylo definováno osm základních makrofunkcí. V rámci projektu ACTIF byla přidána devátá makrofunkce týkající se dopravně-přepravních databází. Každou makrofunkci je možno dále dekomponovat na funkce, podfunkce, případně p-funkce. Detailní popis makrofunkcí, funkcí, podfunkcí a p-funkcí ITS architektury ČR je uveden v příloze 1 této zprávy. V následujících kapitolách jsou uvedena bloková schémata výsledné funkční dekompozice.
43
2.4.1 Elektronické vybírání poplatků Makrofunkce Elektronické vybírání poplatků zahrnuje možnosti elektronických plateb za služby jiných funkcí architektury ITS. Makrofunkce má rozhraní na terminátory zahrnující bankovní instituce tak, aby mohly být prováděny platební transakce. Pokud je detekována podvodná platba, všechny dostupné informace jsou předány do makrofunkce Podpory dohledu. Tato makrofunkce též poskytuje možnost standardizované výměny dat mezi různými operátory.
Obr. 14 - Makrofunkce Elektronické vybírání poplatků
44
2.4.2 Zabezpečení bezpečnostních a záchranných služeb Makrofunkce Zabezpečení bezpečnostních a záchranných služeb zajišťuje management bezpečnostních a záchranných systémů pro cestující a zboží v rámci ITS systému. Makrofunkce reaguje na zprávy a požadavky od ostatních makrofunkcí týkající se bezpečnostních a záchranných služeb.
Obr. 15 - Makrofunkce Zabezpečení bezpečnostních a záchranných služeb
45
2.4.3 Management dopravy Makrofunkce Management dopravy provádí na základě dat ze zařízení podél dopravních cest řízení dopravy. Součástí makrofunkce je jak řízení dopravy ve městě tak i mimo město. Jednotlivé funkce poskytují data jak o situaci na dopravních cestách tak i zabezpečují priority různých druhů vozidel.
Obr. 16 - Makrofunkce Management dopravy
46
2.4.4 Management veřejné dopravy Makrofunkce Veřejná doprava slouží k informační podpoře veřejné dopravy a obsahuje jak množinu služeb tak i funkce pro generování informací pro cestující. Makrofunkce má úzkou vazbu na makrofunkci Managementu dopravy, zejména při přiřazování priorit dopravním prostředkům a při poskytování dat sloužících k řízení přístupů pro různé dopravní módy.
Obr. 17 - Makrofunkce Management veřejné dopravy
47
2.4.5 Podpora řízení vozidla Makrofunkce podpora řízení vozidla umožňuje kontrolu pohybu vozidla na dopravní síti a neustálé monitorování dopravní scény a samotného vozidla (senzory, automatické řídící moduly, atd.) a využití těchto informací pro podporu řízení vozidla (Driver Assistance). Makrofunkce má definováno rozhraní na bezpečnostní a záchranné služby tak, aby byla umožněna rychlá odezva na "mayday" volání z vozidla. Identifikace vozidla je prováděna ostatními funkcemi v rámci elektronických plateb či identifikací podvodů. Dalším výstupem jsou informace pro funkce poskytování dopravních a cestovních informací za pomoci funkcí řízení dopravy.
Obr. 18 – Makrofunkce Podpora řízení vozidla
48
2.4.6 Poskytování cestovních informací Makrofunkce Poskytování cestovních informací poskytuje množství informací všem typům cestujících o dopravních podmínkách případně i o možnostech dopravy. Funkce též zajišťuje plánování, stanovení a vedení nejvhodnější trasy. Pomocí této funkce je umožněn přístup i k dalším informačním službám jako např. ubytování, atd. Tato makrofunkce vyžaduje standardizovanou výměnu informací mezi jednotlivými operátory ITS služeb.
Obr. 19 - Makrofunkce Poskytování cestovních informací
49
2.4.7 Podpora dohledu Makrofunkce Podpora dohledu poskytuje různá opatření a rozhraní na organizace provádějící dohled nad dodržováním zákonů a předpisů. Toto rozhraní poskytuje informace a podvodech či porušení zákonů a předpisů, jež byly detekovány ve všech ostatních makrofunkcích. Příkladem porušení zákonů či předpisů může být např. překročení povolené rychlosti, přejetí jízdních pruhů, neuposlechnutí příkazů zaslaných řidiči, atd.
Obr. 20 - Makrofunkce Podpora dohledu
50
2.4.8 Management nákladní dopravy Makrofunkce Management nákladní přepravy a činnosti flotily dopravních prostředků zabezpečuje funkce nákladní dopravy, logistického řetězce, od odesílatele k příjemci zboží. Makrofunkce zahrnuje i intermodální přepravu s podporou pro přizpůsobení dopravní infrastruktury při zachování udržitelné mobility, bezpečnosti a ochrany životního prostředí. Data jsou předávána s identifikací odesílatele v rámci datových toků uvnitř nebo vně makrofunkce, nebo s identifikací vnějšího odesílatele v rámci datových toků s terminátory.
51
Obr. 21 - Makrofunkce Management nákladní dopravy
2.4.9 Dopravně-přepravní databáze Makrofunkce Dopravně-přepravní databáze je určena k vyhledávání, úpravě a poskytování dat z datových skladů. Poskytuje odpovědi terminátorům, kteří jsou uživatelé databáze. Uživatelem může být jakýkoli uživatel požadující informace z databází v rámci architektury ITS. Poskytovanými informacemi jsou uložená provozní data ze všech datových skladů z jednotlivých makrofunkcí architektury ITS.
Obr. 22 -Makrofunkce Dopravně-přepravní databáze
52
2.5 Informační ITS architektura ČR (shrnutí) Informační architektura zachycuje vzájemné informační vazby mezi jednotlivými makrofunkcemi, funkcemi, podfunkcemi, p-funkcemi vlastního ITS systému včetně informačních vazeb jednotlivých makrofunkcí, funkcí, podfunkcí, p-funkcí s jednotlivými terminátory ITS systému. Na následujících obrázcích jsou informační vazby v rámci vlastního ITS systému zobrazeny v bílém rámečku, kdežto informační vazby ITS systému s terminátory jsou zobrazeny v šedém rámečku. Pro přehlednost je ve všech informačních vazbách zachována konvence značení zkr1.zkr2_popis, kde zkr1 je zkratkou zdroje informační vazby, zkr2 je zkratkou cíle informační vazby a popis charakterizuje krátkou identifikaci informační vazby. Následující tabulky obsahují zkratky terminátorů (vždy tři písmena) a zkratky makrofunkcí (vždy dvě písmena).
MAKROFUNKCE
ZKRATKA
1. Elektronické vybírání poplatků
ep
2. Zabezpečení bezpečnostních a záchranných služeb
zs
3. Management dopravy
md
4. Management veřejné osobní dopravy
vd
5. Podpora řízení vozidla
rv
6. Poskytování cestovních informací
ci
7. Podpora dohledu
pd
8. Management nákladní dopravy
nd
9. Dopravně-přepravní databáze
db
53
TERMINÁTOR
ZKRATKA
TERMINÁTOR
ZKRATKA
Atmosférické podmínky
atm
Poskytovatel dopravních a cestovních informací
dci
Cestující
cst
Poskytovatel geografických informací
pgi
Cestující (v klidu)
cvk
Poskytovatel informací
pif
Cestující (v pohybu)
cvp
Poskytovatel rezervačních služeb
rez
Cyklista
ckl
Povrch dopravní cesty
pdc
Dispečer parkoviště
dpa
Pronajímatel skladovacího prostoru
psp
Distribuce informací
dst
Provozovatel lokalizačních služeb
pls
Dopravní instituce
din
Provozovatel veřejné dopravy
pvd
Dopravní plánování
dpl
Půjčovna (pronájem) dopravních prostředků
pdp
Dopravní prostředek
dpr
Přepravce
pre
Dopravní provoz
dpz
Přidružený dopravní systém
pds
Externí podmínky
exp
Příjemce zboží
pzb
Externí poskytovatel služeb
eps
Ředitel/organizace
rdt
Finanční středisko
fis
Řidič
rdc
Chodec
cho
Řidič nákladního vozidla
rnv
Informační operátor multimodální přepravy
omp
Řidič osobního vozidla
rov
Infrastruktura mostů a tunelů
mtl
Řidič pohotovostního vozidla
rpv
Multimodální přejezd
mpr
Řidič vozidla přepravující nebezpečný náklad
rnn
Multimodální systém
msy
Řidič vozidla veřejné dopravy
rvd
Multimodální řídící systém
mrs
Řízení multimodálních terminálů
rmt
Nákladní spedice
nsp
Soukromé vozidlo
svo
Nákladní vozidlo
nvo
Správce vozového parku
svp
Odesílatel/ přepravce
odp
Systém jiných dopravních modů pro nákladní dopravu
mnd
Odesílatel/příjemce
opj
Tísňový operátor
top
Operátor cestovních informací
oci
Účastník veřejné dopravy
uvd
Operátor dopravní sítě
ods
Uživatel dopravně-přepravní databáze
udb
Operátor ITS systému
opr
Úřad pro dodržování zákonů a předpisů
uzp
Operátor pro výběr mýtného
ovm
Vedoucí půjčovny automobilů
vpa
Organizace údržby
udr
Vozidlo přepravující nebezpečný náklad
vnn
Organizátor naplánované akce
ona
Vozidlo veřejné dopravy
vvo
Ostatní databáze
odb
Zařízení pro nákladní dopravu
znd
Podpora cestování
pce
Zdroj údajů pro lokalizaci
Ulk
Pohotovostní systémy
Pos
Pohotovostní vozidlo
pov
Obr. 23 na následující straně zobrazuje informační vazby mezi jednotlivými makrofunkcemi a terminátory ITS systému, kde v následujících kapitolách jsou popsány jednotlivé informační vazby v rámci každé makrofunkce. Detailní popis jednotlivých informačních vazeb je uveden v příloze 2 této zprávy.
Obr. 23 - Diagram informačních vazeb mezi makrofunkcemi
56
2.5.1 Elektronické vybírání poplatků
Obr. 24 - Diagram informačních vazeb v rámci makrofunkce Elektronické vybírání poplatků
2.5.2 Zabezpečení bezpečnostních a záchranných služeb
Obr. 25 - Diagram informačních vazeb v rámci makrofunkce Zabezpečení bezpečnostních a záchranných služeb
57
2.5.3 Management dopravy
Obr. 26 - Diagram informačních vazeb v rámci makrofunkce Management dopravy
58
2.5.4 Management veřejné dopravy
Obr. 27 - Diagram informačních vazeb v rámci makrofunkce Management veřejné dopravy
59
2.5.5 Podpora řízení vozidla
Obr. 28 - Diagram informačních vazeb v rámci makrofunkce Podpora řízení vozidla
60
2.5.6 Poskytování cestovních informací
Obr. 29 - Diagram informačních vazeb v rámci makrofunkce Poskytování cestovních informací
61
2.5.7 Podpora dohledu
Obr. 30 - Diagram informačních vazeb v rámci makrofunkce Podpora dohledu
62
2.5.8 Management nákladní dopravy
Obr. 31 - Diagram informačních vazeb v rámci makrofunkce Management nákladní dopravy
2.5.9 Dopravně-přepravní databáze
Obr. 32 - Diagram informačních vazeb v rámci makrofunkce Dopravně-přepravní databáze
63
2.6 Příklady tvorby funkční a informační architektury Pro ukázku využití ITS architektury ČR v konkrétních praktických případech byly zvoleny dva příklady. První příklad se týká funkční a informační architektury řízení dopravy a poskytování cestovních informací ve městě Hradec Králové, kde na základě stávajícího stavu a požadavků na ITS systém byly vybrány požadované funkce a na základě ITS architektury ČR k těmto funkcím byly přiřazeny informační vazby. Druhý příklad se týká ITS architektury integrovaného systému nákladní dopravy ve vodní a železniční dopravě přes dopravní terminál - přístav Ústí nad Labem, kde na základě stávajícího stavu a požadavků na ITS systém byly stanoveny požadované funkce a na základě ITS architektury ČR k těmto funkcím byly přiřazeny informační vazby. 2.6.1 Příklad ITS architektury města Hradec Králové Pro názornost univerzálnosti ITS architektury byl vytvořen model řízení dopravy a poskytování cestovních a dopravních informací pro město Hradec Králové. V úvodu je uveden současný stav, který odráží stávající řízení dopravy a poskytování informací. Důvodem výběru města byla jeho velikost a rozsah používaných systémů, na kterém je ukázáno použití modelu ITS architektury ČR. Koncepce řešení dopravního systému v Hradci Králové vychází jednak z atypičnosti 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.
64
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 48-19 x 1,5 mm2. 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čů. Proto nemůže probíhat řízení dle momentální dopravní situace v sítí. I 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 světelných signalizačních zařízení (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í.
65
Výhledový stav V rámci výhledového stavu je provedena definice návrhu funkcí, které je vhodné realizovat. Jedná se pouze o ukázku univerzálnosti architektury ITS. Pro každou konkrétní realizaci je třeba definovat potřeby a možnosti zavedení vybraných funkcí, které se budou lišit případ od případu. Pro Hradec Králové je makrofunkce Management dopravy tvořena 12 funkcemi. Ostatní funkce nejsou do systému začleněny a nepočítá se s nimi. Funkce managementu dopravy 3.1.1 Sběr dopravních dat 3.1.4 Správa dopravních dat 3.1.5 Řízení dopravním zařízením 3.1.5.1 Poskytování řízení dopravy 3.1.5.7 Operátorský vstup 3.1.5.9 Statická data 3.4.1 Sledování počasí 3.4.2 Sledování znečištění ovzduší 3.5.1 Údržba v krátkém čase 3.5.2 Údržba v dlouhém čase 3.5.4 Rozmrazování 3.5.5 Vstup operátora údržby Funkce poskytování cestovních informací Makrofunkce Poskytování cestovních informací je tvořena v případě Hradce Králové pouze dvěmi funkcemi. 6.3 Podpora cesty 6.3.2 Určení mimořádné události Tyto dvě funkce mají za úkol usnadnit uživateli orientaci a pomoci mu v případě mimořádné události. Funkce podpora cesty může být realizována před cestou nebo během cesty. Vytváří optimální návrh trasy s přihlédnutím k dopravní i povětrnostní situaci. Funkce určení mimořádné události detekuje omezení, které vzniká na pozemních komunikacích. Zjištěním aktuální pozice uživatele a podle jeho zadaného plánu dochází k modifikaci v případě, že dojde k mimořádné události, která má vliv na uživatele. Obě tyto funkce mají za úkol usnadnit orientaci a dosažení uživatelem zadaného cíle. Nemalou mírou také tyto funkce přispívají ke zmírnění nepříznivého dopadu na životní prostředí a bezpečnost provozu na pozemních komunikacích.
66
Obr. 33 – Schema datových toků pro příklad ITS architektury města Hradec Králové
2.6.2 Příklad ITS architektury integrovaného systému nákladní dopravy ve vodní a železniční dopravě přes dopravní terminál - přístav Ústí nad Labem V tomto příkladě se jedná o přepravu nádržových kontejnerů s nebezpečným nákladem (výrobní surovinou) pro závod na jižní Moravě (Břeclav). Přeprava je provedena multimodálně, vodní dopravou z Hamburku do Ústí n.L.a následnou železniční dopravou z Ústí n.L. do Břeclavi. V tomto logistickém řetězci se vyskytují nedopravní procesy překládky a skladování, které jsou prováděny v kontejnerovém terminálu přístavu Ústí n.L. Vzhledem k tomu, že se jedná o přepravu nebezpečného nákladu, je třeba dodržet podmínky předpisů pro přepravu nebezpečného zboží dopravy vodní – ADN a železniční – ADC. Přeprava v dopravním řetězci byla připravena a sjednána spediční firmou v Hamburku po převzetí od námořního rejdaře na kontejnerovém překladišti a následná přeprava bude realizována s českým rejdařem po Labi do přístavu Ústí n.L. a dále s Českými drahami přímo k příjemci – výrobnímu závodu.
Stávající informačních systémů kooperujících subjektů Speditér využívá k řízení přepravy a přepravního řetězce elektronický informační a komunikační systém DAKOSY, který umožňuje vystavení všech dokladů pro realizaci přepravy, vystavení nákladních listů, faktur, dobropisů a účetnictví, dále 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 nebo přímo informuje o zboží na cestě
67
jednotlivé články přepravního řetězce (dopravce, překladiště, celní úřady, 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), atd. Dále existují specializované programy (TALDOS, ACTION) pro zpracování dopravně přepravních a dalších problematik speditérů, liniových agentů, překladištních terminálů, atd. Takovéto systémy jsou vybudovány v dopravě pro jednotlivé námořní přístavy, dopravce, druhy zboží (kontejnery, hromadné a kusové zboží, atd.) a používány v jednotlivých regionech a jejich kompatibilita přenosu a doručení datových standardů je zajišťována pomocí EDI v rámci celosvětového standardu UN/EDIFACT. Využívané dopravně-telematické služby Každý dopravce používá svůj systém řízení a sledování pohybu vozového / lodního parku a zboží, jeho parametrů a množství, sledování jejich pohybu a provozních údajů, pohyb a činnost posádek, sledování a kontrola činností dopravce, opravárenství, ekonomie podniku a dopravně-přepravních činností, atd. Jedním z takovýchto řídících, komunikačních, polohových a informačních systémů je i BOATTRACS a FLOSYSS ve vodní dopravě. Jedná se o komerční navigační systém pro vnitrozemskou plavbu zavedený v Evropě, který je shodný s EUTELTRACS silniční dopravy. Jedná se o jednodušší a levnější navigační a komunikační systém, který pro přenos údajů a zpráv používá dvou stacionárních družic, mobilních palubních terminálů na dopravních prostředcích, přenosová pozemní centra se serverem propojující dopravní park s uživatelskými dispečerskými a řídícími centry pomocí telefonu, faxu, e-mailu, Internetu pro přenos údajů, modemových souhrnných zpráv (makra) a dat. Je vybaven polohovým a trasu sledovacím systémem, elektronickým mapovým podkladem pro udání polohy, dvoucestnou datovou komunikací s bezpečnostním a kódovacím systémem. Distributorem systému pro ČR je firma DaCOMM, poskytovatelem služeb jsou České komunikace. Na tento posiční a datově – komunikační a informační systém navazuje obchodně-přepravní systém dopravce – rejdaře – FLOSSYS. Jedná se o řídící a informační program pro obchodně přepravní a technické otázky flotily lodního parku, i jednotlivých lodí, sledování a přiřazování zakázek – přepravy zboží, plánování kapacit, optimalizace, lodního parku, opravárenství, personalistiky, účetnictví, ekonomiky, atd. Zpracovatelem programu (hardware, software) je německá firma NWS Softwareentwicklungs- und Vertriebs GmbH, Laufach-Hain. Tvorba telematické podpory popsanému přepravnímu řetězci Aplikace telematiky u přepravy nebezpečných nákladů směřuje k potřebám státní správy, sledování a kontrole dopravně-přepravních toků pomocí ITS systémů používaných pro dopravu (podpora sledování, plánování a i kontroly doperavněpřepravních procesů). Proto je potřebné navrhnout takovou architekturu systémů ITS v nákladní dopravě, kde budou zapojeny všechny funkce nutné pro navrhovaný systém.
68
Navržená ITS architektura ČR umožňuje v plné šíři podchytit skutečné přepravně informační toky pro potřeby rozhodování a řízení dopravních procesů na různých úrovních pro potřeby všech uživatelů dopravy zboží. Členění systému vychází ze základního rozdělení úrovně řízení a tím i jejího rozdělení na všechny funkce v jejich podúrovních, které přepravní systém sledují a prověřují. Selekce funkcí architektury vybraných k popisu výše uvedeného přepravního případu byla provedena 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ů). Jedná se o funkce: 8.1 Řízení pohybu zboží a nákladní přepravy 8.2 Řízení obchodní flotily 8.3 Řízení dopravních prostředků / řidičů / nákladu / vybavení Při modelování tohoto sytému byl striktně brán v úvahu pouze stávající stav, což znamená, že byly vybírány pouze funkce, které popisují funkcionalitu stávajícího přepravního řetězce. Protože se jedná o velice širokou problematiku s návazností na řadu dalších oblastí, výběr funkcí se omezuje v tomto příkladu pouze na funkce managementu nákladní dopravy. Při komplexnějším řešení problematiky, příp. při snaze o zobrazení možností rozšíření a zdokonalení systému, by se stal příklad nepřehledným. Výběr konkrétních funkcí makrofunkce 8. Management nákladní dopravy 8.1. Řízení logistických procesů a nákladní dopravy 8.1.1. Správa přepravně obchodních transakcí 8.1.1.1. Sjednání základních požadavků 8.1.1.2. Výběr dodavatele dopravních služeb 8.1.1.3. Správa přepravní transakce 8.1.2.1. Celní řízení - celní deklarace 8.1.2.2. Dokumentace přepravy nebezpečného zboží 8.1.2.3. Příprava a vydání přepravních dokumentů 8.1.3. Správa dopravně přepravních operací 8.1.4. Ocenění dopravně přepravní operace 8.1.5. Řízení a synchronizace intermodální dopravy 8.1.5.2. Rezervace skladovacích a stohovacích kapacit 8.2.1.2. Správa dopravních transakcí 8.2.2. Řízení dopravních operací 8.2.2.1.2. Řízení využití zdrojů 8.2.2.1.3. Příprava a vydání dopravních a nákladních dokumentů 8.2.2.2. Řízení a sledování dopravních operací 8.2.2.2.1. Příprava/přenos informací z/do dop. prostředku 8.2.2.2.2. Řešení nehod 8.2.2.2.5. Ohodnocení a zaznamenání úrovně bezpečnosti 8.2.2.3. Řízení zdrojů dopravce 8.2.2.3.2 Řízení dop. prostředků a vybavení 8.2.3 Ocenění hodnoty dop. operace 8.3 Řízení dopravních prostředků/ řidičů/ nákladu/ vybavení 8.3.1 Řízení zadání a objednávka dopravy 8.3.1.1 Kontrola objednávky dopravy 8.3.1.2 Vytvoření nové přepravní jednotky /celku/
69
8.3.1.3 Řízení objednávky dopravy 8.3.1.4.2 Příprava nakládacího plánu 8.3.1.4.4 Příprava cesty 8.3.1.4.5 Kontrola profilu a omezení klienta 8.3.2 Monitorování prostředků 8.3.2.2 Monitorování vozidla/dopravních prostředků 8.3.2.3 Monitorování nákladu/zboží 8.3.2.4 Monitorování vybavení 8.3.3 Dodržování předpisů
70
Obr. 34 - Schema datových toků pro příklad ITS architektury integrovaného systému nákladní dopravy ve vodní a železniční dopravě přes dopravní terminál - přístav Ústí nad Labem
71
3. TECHNICKÉ PROSTŘEDKY PRO TVORBU ITS ARCHITEKTURY ČR 3.1 Struktura ITS databáze Základem ITS architektury je databáze funkcí, informačních vazeb, terminátorů, atd., která je místem, kam se ukládají všechny aktuální údaje. Přístup k údajům uloženým v databázi obstarává program SŘBD - Systémy Řízení Báze Dat (DataBase Management System). Mezi SŘBD patří programy jako je Oracle, MS SQL Server, Sybase, Informix, Progress, InterBase, MySQL, PostgreSQL a další. SŘBD při uspořádání údajů v databázi vychází z relačního modelu dat. Název tohoto modelu vychází z relační algebry, což je matematický aparát, na kterém relační model dat staví. V tomto modelu jsou data uspořádána do tabulek. Tabulka zpravidla shromažďuje údaje o jednom druhu objektu. Sloupce jsou nazývány položky nebo atributy. Řádky jsou nazývány záznamy. Využitelnost relačních databází vychází jednak ze způsobu, jakým jsou data rozdělena na menší entity, jednak ze způsobu, jakým data v jedné tabulce souvisejí s daty v jiné tabulce. Přístup k údajům uloženým v databázích obstarává SŘBD. Aby mohly být údaje z databáze přístupné telematickým aplikacím nebo jednotlivým specialistům v ITS oboru, musí SŘBD nabízet rozhraní, pomocí kterého s ním mohou spolupracovat ostatní programy. Komunikace mezi telematickou aplikací a SŘBD funguje na principu modelu klient/server. V roli serveru je SŘBD a proto se také nazývá databázový server. Pro zadávání požadavků na databázový server aplikace nejčastěji používají jazyk SQL (Structured Query Language). Popis struktury databáze ITS: ITS databáze se skládá z objektů (tabulek), které jsou vzájemně propojeny jednoznačně definovanými vazbami (klíči). Při návrhu tabulek databáze se postupovalo podle zásad normalizace databáze. Normalizace umožňuje klasifikovat návrh databáze podle specifických úrovní, jimž se říká normované formuláře. Pravidla normalizace se s každou vyšší úrovní zpřísňují. Důsledkem je, že veškerá data, která nejsou v přímém vztahu s primárním klíčem dané tabulky jsou oddělena. Toto umožňuje flexibilitu databáze pro její budoucí rozšiřování. ITS architektura je v databázi zachycena čtyřmi hlavními tabulkami, na které jsou navázána další data. Tyto tabulky obsahují základní data (název, popis, zkratka) o : makrofunkcích (tabulka funct_areas) funkcích (tabulka functions) terminátorech(tabulka terminators) datových tocích(tabulka dataflows_logical) databázích (tabulka datastores). Struktura datových toků je popsána prostřednictvím tabulek dtflw_parent (informace o nadřazených datových tocích), dtflw_source resp. dtflw_target (informace o zdroji resp. cíly směřování datového toku). Struktura funkcí zachycena v tabulkách funct_parent (nadřazené funkce), funct_inputflow_logical resp. funct_outputflow_logical (struktura vstupních resp. výstupních datových toků). Terminátory jsou popsány vstupními resp. výstupními datovými toky (tabulky term_inputflow_logical resp. term_outputflow_logical). 72
Databáze jsou určeny tabulkami o vstupních resp. výstupních datových tocích (tabulky dtstr_inputflow_logical resp. dtstr_outputflow_logical).
3.2 Dálkový přístup k ITS architektuře V roli klienta pro SQL-server architektury ITS může vystupovat i skript zapsaný v PHP tak, aby byl přes www zpřístupněn obsah nějaké databáze ITS architektury. Každý SQL-server má svůj vlastní protokol, kterým s ním může klient komunikovat. Pokud musí klient komunikovat s více různými databázovými servery, musí být podporováno více protokolů, a proto na platformě Windows vzniklo rozhraní ODBC (Open Database Connectivity), které slouží jako prostředník mezi klientskou aplikací a databázovým serverem. Pokud je klient napsaný v Java jazyce, z hlediska rychlosti přístupu do databáze je výhodné použít rozhraní JDBC (Java Database Connectivity). Z hlediska poskytování údajů z databáze ITS architektury existují dva přístupy: • statické generování údajů z databáze - každá změna údajů v databázi způsobená např. změnou jednotlivých prvků ITS architektury, přijetím nových metadat, atd. spustí program, který vygeneruje datový soubor v daném datovém formátu (ASN.1, XML, atd.) a tento soubor je uložen do předdefinovaného adresáře. Na požádání klienta prostřednictvím komunikačních programů např. http, https, ftp, php, atd. je tento soubor klientovi zaslán. Výhodou statického ukládání dat je možnost generování datových souborů pouze při změně údajů v databázi a poskytnutí tohoto souboru velkému množství klientů. Nevýhodou je, že není možné zajistit speciální dotaz klienta (všichni klienti dostanou požadovaná data v předdefinované šabloně). • dynamické generování údajů - při každé žádosti klienta je vygenerován datový soubor v daném datovém formátu (ASN.1, XML, atd.) dle specifických požadavků klienta, které jsou v souladu s přidělenými přístupy do databáze a tento soubor je dynamicky klientovi zaslán. Soubor může obsahovat část funkcí, informačních vazeb, atd. např. pro zvolený dopravní obor, atd. Výhodou dynamického generování údajů je možnost specifických dotazů. Nevýhodou je, že při každém dotazu klienta je nutné spojení s databází, čímž se databáze zatěžuje. Pro zasílání vygenerovaných datových souborů se využívají komunikační subsystémy, které se většinou navrhují podle normy ISO/OSI (ISO Open System Interconnection). Model OSI je rozdělen do sedmi po sobě jdoucích vrstev: • 1. Fyzická vrstva definuje fyzické propojení mezi prvky sítě (konektory, médium), elektrické vlastnosti (napětí, kódování, modulace) a u lokálních sítí i způsob propojení. • 2. Spojová (linková) vrstva zajišťuje data proti chybám při přenosu. Zprávy jsou přenášeny v pevně definovaných rámcích. Struktura rámce často limituje délku bloků dat síťové vrstvy – mluví se o tzv. paketech. • 3. Síťová vrstva definuje způsob, jakým se pakety pohybují sítí, jak si je jednotlivé prvky předávají na jejich cestě od odesílatele k adresátovi. Mechanismy vrstvy se konečně starají i o ochranu sítě proti nadměrné zátěži. • 4. Transportní vrstva umožňuje komunikaci aplikačních programů v síti, zajišťuje vytváření dočasných komunikačních kanálů mezi nimi a konečně rozklad zpráv do paketů a naopak.
73
• 5. Relační vrstva (vrstva sezení) doplňuje logické rozhraní pro aplikační programy o funkce jakými jsou podpora poloduplexu a vkládání synchronizačních bodů. Zjednodušuje komunikaci programů i uživatelský pohled na komunikační kanál. • 6. Prezentační vrstva transformuje přenášená data – zajišťuje převody kódů a formátů dat pro nekompatibilní počítače, kompresi přenášených dat a konečně i jejich utajování. • 7. Aplikační vrstva je vrstvou standardních aplikací a vrstvou rozhraní, která zjednodušují programování jednoúčelových aplikací. Komunikační systém pro dálkový přístup pro ITS architekturu bude využívat tyto vrstvy, u kterých jsou uvedeny jednotlivé normy či protokoly: • 1. Fyzickou vrstvu pro vlastní přenos dat • 2. Spojovou (linkovou) vrstvu pro přenos paketů podle standardů IEEE 802.x • 3. Síťovou vrstvu, kterou využívá protokol IP • 4. Transportní vrstvu, kterou využívá protokol TCP • 6. Prezentační vrstvu, použitou pro kódování a komprimaci dat (SSL, GZIP) • 7. Aplikační vrstvu, použitou pro servery SQL, http, ftp a klienty SQL, http, ftp
3.3 Zpracování informací ITS architektury 3.3.1 Výměna, sdílení a přístup k ITS architektuře Pro využívání architektury ITS v různých situacích, např. jednotlivá města, region, atd. je vhodné umožnit sdílení a výměnu informací o jednotlivých prvcích ITS architektury, které jsou uloženy v ITS databázi. Pro výměnu dat mezi databázemi ITS architektur je vhodné využít XML (eXtensible Markup Language), který je otevřený formát pro výměnu a sdílení informací a který není svázán se žádnou platformou ani žádnou proprietární technologií. XML umožňuje definici vlastní sady značek (označované jako "tagy"), která se bude v dokumentu používat. XML je svou strukturou velmi podobné jazyku HTML (Hypertext Markup Language) a lze ho též využít pro tvorbu webových stránek, ale narozdíl od HTML si může programátor definovat vlastní značky (tagy), což umožňuje mnohem lepší a přesnější vyhledávání informací. Dokument DTD (definice typu dokumentu) definuje, jaké značky může XML dokument obsahovat. Pomocí DTD se zjednoduší další práce s XML dokumentem, např. zcela automaticky lze kontrolovat, zda dokument obsahuje pouze povolené značky, atd. Programu, který kontroluje správnost XML dokumentů, se říká parser. Bohužel DTD neobsahuje nástroje na kontrolu různých typů dat jako čísla, údaje o datu a čase, atd. což je velice důležité pro ITS architekturu (např. informační vazby musí mít přiřazenu zdrojovou a cílovou funkci, atd.), kde si jednotlivé ITS databáze posílají pomocí formátu XML údaje databázového charakteru o dílčích prvcích ITS architektury. Pro tyto potřeby existuje několik dalších jazyků pro určení správného "schéma" dokumentu, které jsou v současné době zpracovávány pod názvem "XML schémata" na půdě konsorcia W3C do formy standardu.
74
3.3.2 Optimalizační úlohy nad ITS architekturou Technické prostředky pro tvorbu ITS architektury byly zvoleny tak, aby bylo možno nad databází prvků ITS architektury provádět různé analytické a optimalizační úlohy. První již zmiňovanou úlohou je propojení ITS architektury a ITS datového registru, což z hlediska technických prostředků znamená propojení několika databází. Tímto propojením jsou jednotlivým prvkům ITS architektury přiřazeny jednotlivé atributy, např. geografická poloha daného prvku, použitý software, požadavky na bezpečnost, dostupnost a spolehlivost prvku, atd. Všechny tyto informace mohou být zpracovávány a na jejich základě je možno např. určit optimální geografickou polohu centra zpracování informací tak, aby cena za přenos informací byla minimalizována, atd. Další analytickou úlohou může být výhodná volba ITS infrastruktury v závislosti na přesně definovaných potřebách uživatelů, což znamená, že budoucí uživatel ITS systému pouze vyplní universální dotazník, na jehož základě budou vygenerovány potřebné funkce, databáze a informační vazby16. Znalost funkcí a informačních vazeb je nutnou podmínkou pro doporučený modulární návrh ITS systému tak, aby byly splněny všechny systémové požadavky na bezpečnost, dostupnost a spolehlivost jednotlivých telematických aplikací.
4. NÁVRH KONCEPCE DOPRAVNÍ TELEMATIKY ČR Doprava je jedním z klíčových faktorů v moderních ekonomikách a v celém svém řetězci je dnes podporována aplikacemi a systémy založenými na moderních informačních a telekomunikačních prostředcích, které umožnily vznik nových systémů a aplikací v dopravě a přepravě nazývané jako dopravní telematika nebo inteligentní dopravní systémy a služby. Inteligentní dopravní systémy a služby jsou základní složkou integrované dopravní politiky, zvyšují bezpečnost dopravy, přispívají k udržení synergie dopravního systému, podporují udržitelnou mobilitu osob a zboží a poskytují dostatečný objem informací o dopravě jako nástroje regulace pro veřejnou správu, ale i jako služby pro uživatele dopravních systémů a jsou nástrojem pro zlepšení interoperability celého dopravně-přepravního řetězce. Aby mohla doprava poskytovat zákazníkům komplexní a kvalitní služby v oblasti osobní nebo nákladní přepravy, musí mít dopravní zaměstnanci i manažeři dopravních a zasilatelských společností dostatek informací pro rychlé a správné rozhodování. Určitého standardu služeb zákazníkům (např. cestujícím, přepravcům, uživatelům dopravní infrastruktury) je možné dosáhnout jen za využití podpory moderních technologií, a to zejména kvalitní telekomunikační infrastruktury a vhodného aplikačního vybavení. A tak i v České republice byla samozřejmě rozvíjena oblast ITS a byly zavedeny některé aplikace ITS, a to ať už jednotlivými dopravními společnostmi, správci infrastruktury, veřejnou správou nebo veřejným sektorem. Stávající stav dopravní telematiky v České republice se vyznačuje bouřlivým rozvojem nových technologií, které však nejsou informačně propojeny, čímž se 16
Tento proces byl proveden ručně u dvou uvedených příkladů v kap. 2.6.
75
snižují jejich užitné vlastnosti, dochází k narušení bezpečnosti systému, zhoršuje se spolehlivost řídících systémů, atd. Dopravní prostředky, tedy osobní a nákladní automobily, autobusy, vlaky nebo lodě již neznají hranice uvnitř Evropy, a je tedy třeba při rozvoji ITS postupovat systémově a respektovat určitá pravidla nebo normy. A naopak dopravní infrastruktura na území jednotlivých zemí musí splňovat takové parametry, aby vozidla vybavená odpovídajícím zařízením mohla využívat telematické služby bez ohledu na místo, kde se právě nachází. Z tohoto důvodu nabývá na významu struktura a zvolená strategie rozvoje dopravě-telematických systémů. Doprava se vyznačuje velkou dynamikou zpracovávaných informací. Je zřejmé, že tak komplexní systémy jako jsou systémy ITS nelze zavádět a tvořit bez předem stanovené a všemi zúčastněnými odsouhlasené architektury. Při tvorbě architektury telematických systémů není možno sledovat pouze technickou stránku věci, ale celý koncept je nutno svázat s podobou organizační struktury dané organizace, definováním jednotlivých kompetencí, pravomocí, stavem legislativy atd. Tvorba architektury dopravně-telematického systému je proto multidisciplinární problém, jehož řešení vede na funkční systémy, které slouží svému účelu, pracují optimálně a vytváří užitné vlastnosti té které organizace. V současné době existuje velké množství různorodých dat z oblasti dopravy, přičemž jsou často shromažďována data s podobným obsahem, a to paralelně různými složkami veřejné správy bez jakéhokoli propojení. Bohužel v řadě případů jsou tato data nejednotná a roztříštěná (např. popis dopravní infrastruktury, údaje vztahující se k dopravním nehodám). Ukazuje se, že v některých případech je třeba definovat společný formát a strukturu zaznamenávání údajů. Kromě toho je důležité vložená data smysluplně zpřístupňovat a využívat je podle stanovených pravidel a na základě přístupových práv. Tento systém by se měl neustále rozvíjet nejen ve svém objemu dat, ale především v jejich využívání pro zefektivnění rozhodovacích procesů.Tento přístup by pomohl veřejné správě vytvořit jednotné a transparentní informační prostředí, ve kterém by byla operativně k dispozici potřebná data na všech úrovních veřejné správy. Inteligentní dopravní systémy a služby umožňují vytvořit nástroje na podporu rozhodování v tak složitém systému jakým bezesporu doprava je. Například propojení a zpracování informací lze zabezpečit jak na straně tzv. správce infrastruktury, tak i na straně aplikanta (dopravce nebo jeho zákazníka). V definované informační architektuře lze zabezpečit i základní posouzení provozních nákladů různých druhů dopravy a získat tak data pro internalizaci externích nákladů a jejich hrazení dopravci v té míře, ve které je vyvolají. Rozdíl v přístupu státu k podpoře rozvoje ITS nebo naopak vliv absence národní politiky telematiky dokládá příklad z Japonska a z USA. Japonská vláda již koncem 60-tých let provedla rozsáhlou analýzu dopravy a jejího vlivu na společnost. Výsledkem byla „Bílá kniha“ prokazující, kromě jiného, že cena za kongesce je 3,53 miliard Kč, za rok se stráví v kolonách 5,6 miliard hodin a na silnicích je 10 000 usmrcených. Na základě této a dalších analýz byly zpracovány pětileté plány implementace telematiky. Pokud se týká řízení měst bylo soustředěno úsilí na budování integrovaných center řízení dopravy, řízení dopravy v případě kongescí, automatizované identifikaci nehod a kongescí, televizním dohledům a zvýšení atraktivity veřejné dopravy. Kromě toho byla realizována celá řada projektů zabývajících se navigováním vozidel a optimalizací jejich trasy. Informační a navigační systém například v rámci světové výstavy v Ósace v roce 1990 řídil 38 vozidel (policie, taxi, nákladní vozidla) pomocí displejů ve vozidlech a dále celý provoz 22 informačními tabulemi u vozovek. Investice, které věnuje japonská vláda do rozvoje telematiky dosahovaly například v létech 1985 až 1992 částky v přepočtu 67 miliard Kč a mezi roky 1993 až 1997 hodnoty 25 miliard Kč.
76
Oproti tomu vláda v USA nezachytila nástup těchto technologií. Sice již v průběhu 60-tých let byla iniciována řada studií, které se však nepromítly do národní politiky implementace telematiky. Stalo se tak, že v 70 až 80-tých letech vznikla řada zajímavých projektů, do kterých se investovaly nemalé prostředky. Protože ale neexistovala jednotná báze, neměly naději na větší úspěch. Teprve v roce 1990 byl zpracován základní dokument „The National ITS Architecture“, který byl o rok později odsouhlasen Kongresem. Vytvoření a akceptování tohoto dokumentu poskytlo podmínky pro cílené budování telematiky. Odhaduje se, že vláda vynakládá každým rokem více než 7 miliard USD na rozvoj telematických systémů.
4.1. Role dopravní telematiky (ITS) v ČR Dopravní telematika (inteligentní dopravní systémy a služby - ITS) integruje informační a telekomunikační technologie s dopravním inženýrstvím za podpory ostatních souvisejících odvětvích (ekonomika, teorie dopravy, systémové inženýrství, atd.) tak, aby se pro stávající dopravní infrastrukturu zajistily moderní systémy řízení dopravních a přepravních procesů (zvýšily se přepravní výkony a efektivita dopravy, stoupla bezpečnost dopravy, zvýšil se komfort přepravy, atd.). Základním cílem dopravní telematiky je nabízet uživatelům dopravy inteligentní služby, které je nutno sledovat v několika rovinách: • služby pro cestující a řidiče (uživatelé) - 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. • služby pro správce infrastruktury (správci dopravních cest, správci dopravních terminálů) - 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. • služby pro provozovatele dopravy (dopravci) - 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ů, atd. • služby pro veřejnou sprá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, atd. • služby pro bezpečnostní a záchranný systém (IZS - 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šího 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, atd. • služby pro finanční a kontrolní instituce (pojišťovny, leasingové společnosti, atd.) - elektronická identifikace vozidel a nákladů, sledování a vyhledávání odcizených vozidel, elektronické platby za poskytnuté ITS služby, atd. Výsledkem koncepčního propojení jednotlivých subsystémů dopravní telematiky vznikne informační nástavba nad dopravou, která umožní implementovat stejné řídící nástroje pro toto síťové odvětví, jako je tomu dnes např. u řízení výrobních podniků (sledování nákladů, vznik samostatných nákladových středisek, atd.).
77
Znalost ekonomických procesů spojených s dopravou usnadní výkon státní dopravní politiky a nabídne smysluplnou investiční strategii v tomto odvětví. Dopravní telematika v tomto pojetí může nabídnout jasná, kontrolovatelná a transparentní pravidla pro vstup privátních investorů do dopravní infrastruktury (včetně vlastních prostředků dopravní telematiky).
4.2. Strategické cíle ITS v dopravní politice ČR a EU Důležitost inteligentních dopravních systémů a služeb byla zdůrazněna Evropskou komisí jako součást procesu budování mobilní společnosti v rámci informační společnosti. Vývoj inteligentních dopravních systémů může být hlavním příspěvkem k zvýšení účinnosti všech druhů dopravy, její bezpečnosti, ale i ohleduplnosti k životnímu prostředí a jako takový je hlavním cílem dopravní politiky EU („BÍLÁ KNIHA - Evropská dopravní politika pro rok 2010: čas rozhodnout“), Akčního plánu elektronická Evropa (pro kandidátské země „eEurope+ 2003“) a nově vytvořené evropské iniciativy „e-bezpečnost“ (e-Safety) s cílem zlepšit silniční bezpečnost a také vytvořit strategii Evropy k urychlení výzkumu a vývoje, rozšiřování a využívání inteligentních integrovaných bezpečnostních systémů. Podle Smlouvy o ES (články 154 a 155) je úkolem Společenství přispívat k vytváření a rozvoji transevropských sítí v oblasti dopravy. Aby bylo možno dosáhnout těchto cílů, musí Společenství podniknout veškerá opatření nezbytná pro zajištění interoperability sítí, zejména v oblasti technické standardizace. Největší přínos ze zavádění ITS se předpokládá v oblasti evropské železniční dopravy. Provoz vlaků na transevropské železniční síti vyžaduje zejména vynikající kompatibilitu mezi charakteristikami infrastruktury a charakteristikami vozidlového parku a též efektivní propojení informačních a telekomunikačních systémů různých správců dopravní infrastruktury a dopravců. Výkonové úrovně, bezpečnost, kvalita poskytovaných služeb a příslušné náklady jsou závislé na takové kompatibilitě a takovém propojení stejně jako zejména interoperabilita transevropského konvenčního železničního systému. Termínem "interoperabilita" se rozumí schopnost transevropského konvenčního železničního systému umožňovat bezpečné a nepřerušované pohyby vlaků, které splňují požadované úrovně výkonových parametrů pro tyto tratě. Nedostatečná interoperabilita na evropské železniční síti je jednou z největších překážek pro poskytování pan-evropských služeb, zejména v oblasti nákladní dopravy. Proto byla přijata Směrnice 2001/16/ES o interoperabilitě konvenčního železničního systému přijatá 19. března 2001. Podobně jako směrnice o vysokorychlostním systému zavádí postupy Společenství pro přípravu a přijetí Technických Specifikací Interoperability (TSI) a společných pravidel pro posuzování shody s těmito specifikacemi. Daná směrnice požaduje přijetí první skupiny prioritních TSI do tří let, tj. v roce 2004, a to v následujících oblastech: řízení provozu a návěštění; telematické aplikace pro nákladní dopravu; provozování a management dopravy (včetně kvalifikací pracovníků pro zahraniční dopravu); nákladní vozy; problémy s hlukem.
Telematické aplikace jsou v oblasti železniční dopravy definovány následovně: • aplikace pro osobní dopravu, včetně systémů poskytujících cestujícím informace před cestou a během cesty, rezervačních a platebních systémů, organizace přepravy zavazadel a aplikace pro podporu integrovaných dopravních systémů,
78
• aplikace pro nákladní dopravu, včetně informačních systémů (monitorování nákladů a vlaků v reálném čase), seřaďovacích a rozdělovacích systémů, rezervačních, platebních a fakturačních systémů, aplikace podporující kombinovanou dopravu včetně vytváření elektronických průvodních dokumentů. Výměna dat a informační systémy jsou významným prvkem mezinárodní nákladní dopravy. Potřeby výměny dat u moderních železnic jsou velmi významné. Tyto výměny se týkají informací souvisejících s provozem/poskytováním dopravních služeb (například plánování vlaků, řízení vozového parku, sestavování jízdních řádů), nahlašováním místa/stavu a přepravními/komerčními aplikacemi (například nákladní listy, rezervace nákladního vozu v určitém vlaku prováděné zákazníkem, fakturační činnosti, atd.). Vytvoření jednotného trhu pro železniční dopravu a železniční zařízení znamená, že se zvyšuje význam sdílení informací. Evropská standardizace služeb železniční nákladní dopravy zvyšuje potřeby konkurujících si železničních dopravců a správců, resp. manažerů infrastruktury v oblasti výměny dat a informačních systémů (např. pro management vozového parku, tvorbu jízdních řádů, vyhledání a sledování, vztahy se zákazníky, atd.). Interoperabilita patří v současné době mezi prioritní problematiky dopravní politiky Evropské unie. Nové přístupy k zpracování a schvalování evropských (EU) standardů, k posuzování shody a schvalování železničních výrobků i k činnosti notifikovaných osob mohou mít dalekosáhlé dopady jak pro českou železnici, tak pro český železniční průmysl. Aby byla postupně zajištěna interoperabilita na evropské železniční síti, Evropská komise v současné době zvažuje se zavedení podmínky interoperability pro financování transevropských projektů v oblasti železniční infrastruktury ze zdrojů Společenství. Co se týče silniční dopravy, na mnoha místech v Evropě byly již realizovány moderní systémy pro řízení silničního provozu a systémy poskytující služby dopravních informací. Nicméně stále existují, spíše než homogenní trh, dílčí systémy fragmentárních regionálních a vnitrostátních služeb ITS. Na základě evropské strategie o rozšiřování ITS v rámci Evropy budou podporovány panevpropské služby, tedy budou zajištěny provozní provázanosti a dostupnosti služeb jak na dálkových tazích, tak v městských aglomeracích. Transevropská silniční síť (Trans-European Road Network, „TERN“) zahrnuje dálnice spojující velká a střední města a dopravní uzly jako jsou přístavy, letiště, důležité železniční stanice a logistická centra. Rovněž zajišťuje napojení na regionální a místní silniční sítě. Řízení dopravy na TERN vyžaduje integrovaný přístup, který bere ohled na místní požadavky, na řízení dopravy na celé síti a místní přístupy k intermodalitě. Řídící zásady TEN-T pro ITS přispívají k rozšiřování opatření a projektů zabývajících se bezpečným a účinným přemísťováním lidí a zboží po celé Evropě, minimalizací ekologických a sociálních nákladů s ohledem na: • zlepšení bezpečnosti uživatelů silnic, • účinnější řízení dopravního provozu a řešení dopravních kongescí, • poskytování pan-evropských informačních služeb za poplatek, • poskytování přesných, včasných a relevantních informací uživatelům silnic,
79
• zlepšování ekonomické efektivnosti uplatňováním spravedlivého a účinného oceňovacího mechanismu včetně sociálních a ekologických nákladů, • podporování užívání multimodálních dopravních služeb ode dveří ke dveřím s cílem podporovat optimální využívání dostupných způsobů dopravy, • podporování bezpečné a hospodárné přepravy zboží, • prevence dopravních nehod a včasná identifikace nehodové události, • integrování ekologických hledisek v projektování, provozování a užívání systémů. V roce 1999 byla v rámci procesu revize řídících zásad trans-evropské dopravní sítě zřízena Evropskou komisí expertní skupina "Trans-evropské dopravní sítě pro inteligentní dopravní systémy pro řízení silničního provozu". Tato skupina vypracovala "Doporučení k revizi řídících zásad TEN-T pro řízení silničního provozu". Trans-evropská silniční síť zahrnuje infrastrukturu pro řízení dopravy a informační služby založené na aktivní spolupráci mezi systémy řízení dopravy na evropské, národní a regionální úrovni. Za projekty společného zájmu jsou považovány všechny projekty zahrnující infrastruktury vztahující k těmto článkům, které řeší oblast rozvoje telematických aplikací systémů řízení dopravy a uživatelských informací, zejména: 1. Řízení a kontrola dopravního provozu • Podpora rozšiřování příslušných opatření řízení dopravy a plánů na hlavních (mezinárodních) koridorech a (městských) obchvatech TERN, včetně strategických městských a periferních městských spojů • Rozšiřování provozních opatření k lepšímu řízení nákladní dopravy s ohledem na zlepšování bezpečnostních podmínek a koexistenci lehkých a těžkých vozidel • Podporování užší mezinárodní spolupráce mezi orgány silniční dopravy a provozovateli a účast ostatních příslušných orgánů jako jsou orgány a provozovatelé veřejné dopravy, vysílací stanice, apod. 2. Cestovní informační služby • Podpora zdokonalování a rozšiřování pokrokových silničních a multimodálních informací před cestou a na cestě a navigačních služeb (VMS, RDS-TMC, DAB, GSM, GPS, GNSS, internet, atd.) na hlavních transevropských koridorech a na rozhraní mezi městskými aglomeracemi a sítí TEN • Prozkoumání nových služeb využívajících technik komunikování pomocí satelitů (např. GPS, GNSS)
určování
polohy
a
• Podpora při zřizování partnerství mezi soukromým a veřejným sektorem pro další rozšiřování informačních služeb před cestou a na cestě • Zvyšování znalostí zákazníků o dostupných možnostech dopravy za pomoci zdokonalených informačních služeb. • Podpora prací na řídících zásadách pro rozhraní člověk-stroj pro systémy ve vozidle, a to v zájmu minimalizování bezpečnostního rizika při řízení.
80
• Poskytování informací ve více než jednom jazyku (např. poskytováním volby jazyka na internetových stránkách). 3. Řízení nákladní dopravy a vozového parku • Podpora rozšiřování systémů stopování nákladů a vyhledávacích systémů (tj. s ohledem na nebezpečné věci a multimodální dopravu). • Podpora služeb zaměřených na zvyšování účinnosti nákladní dopravy (např. snižování podílů prázdných jízd těžkých nákladních vozidel). 4. Řešení nehodových událostí a stavů nouze • Vypracování řídících zásad pro dohody mezi různými účastníky (soukromými a veřejnými) procesu řešení příhod a pro normy výměny informací mezi těmito účastníky. • V rámci těchto řídících zásad podporování rozšiřování služeb pro řešení příhod a nouzových stavů na TERN (např. telefonní číslo 112 pro celou EU). 5. Elektronické vybírání poplatků • Vypracování a realizace memoranda o porozumění Evropské unie o elektronickém vybírání poplatků a pan-evropských službách včetně harmonizace národních daňových a právních předpisů, například prostřednictvím euronálepky. • Podpora rozšiřování provozně propojených služeb a sbližování provozně nepropojených systémů. • Podpora integrace spolehlivých zařízení pro komunikací na krátkou vzdálenost (DSRC) a systémů využívajících satelitů (GPS/GSM). 6. Monitorování stavu infrastruktury • Instalování zařízení pro monitorování infrastruktury na TERN, kdekoliv to je nezbytné (pro dopravní provoz, počasí, bezpečnost, stav kvality ovzduší), což rovněž umožní poskytování odhadů cestovních časů a záruku plynulosti služeb. • Podpora sběru příslušných statistických dat o poskytování a provozu TERN. • Podpora dohod o přístupu poskytovatelů služeb k veřejným datům, kteří provozují obchodní služby, a o integraci různých monitorovacích systémů (provozovaných různými účastníky). 7. Dopravní řídící ústředny a informační centra • Rozšiřování a/nebo zdokonalování regionálních a národních dopravních středisek včetně příslušných rozhraní a výměny dat mezi těmito středisky a podpora opatření k řízení přeshraniční dopravy a přeshraničních informačních služeb. • Podpora sdílení dat mezi silničními dopravními středisky a provozovateli jiných druhů dopravy, pokud to bude nezbytné.
81
8. Horizontální problémy • Koordinace národních a regionálních plánů rozšiřování ITS: definování a dohoda o sspolečných službách ITS a zavedení plánů na rozšiřování těchto služeb. • Technická a provozní propojenost. • Systémová architektura a normalizace rozhraní pro provozní propojenost. • Organizační otázky jako například partnerství mezi soukromým a veřejným sektorem. • Vyhodnocování a ekonomická efektivnost investic. • Aspekty rozhraní člověk-stroj. Dle doporučení komise 2001/551/ES ze dne 4. července 2001 o vypracování právních a obchodních rámcových podmínek pro účast soukromého sektoru na rozšiřování telematických dopravních a cestovních informačních služeb v Evropě je vyžadován harmonizovaný přístup k telematickým dopravním a cestovním informačním službám. Rovněž je důležité plně využívat zdroje údajů a informací dostupné prostřednictvím veřejných úřadů s cílem zbezpečit hospodárnost při zajišťování informací a údajů nezbytných pro rozsáhlé rozšiřování dopravních a cestovních informačních služeb. Členské státy by na měly zajistit, aby požadavky na dopravní a cestovní informační služby byly na vnitrostátní, regionální a místní úrovni harmonizovány. Za tímto účelem jsou členské státy vyzývány, aby učinily tato opatření: • zveřejnit a zpřístupnit požadavky a použitelné právní předpisy a nařízení vztahující se k veřejné bezpečnosti, bezpečnosti dopravního provozu, řízení dopravy a dopravního provozu a k ochraně soukromí a osobních údajů, které musí poskytovatelé dopravních a cestovních informačních služeb na vnitrostátní, regionální a místní úrovní plnit; • doporučit veřejným úřadům a veřejným agenturám, aby používaly standardní smlouvy a dohody o úrovni služeb, poskytují-li provozovatelům obchodního sektoru a uživatelům dopravy dopravní a cestovní údaje o všech druzích dopravy; • doporučit veřejným úřadům a veřejným agenturám provozujícím on-line zařízení na zjišťování stavu dopravního provozu a jeho sledování, aby všem poskytovatelům dopravních a cestovních informačních služeb dávaly údaje k dispozici v reálném čase a za stejných podmínek; • podporovat partnerství mezi veřejným a soukromým sektorem při poskytování dopravních a cestovních informačních služeb. Vláda České republiky si je vědoma důležitosti oblasti ITS. Již základní strategický dokument sektoru dopravy „Dopravní politika České republiky" počítá se zaváděním dopravní telematiky. Dopravní politiku schválila vláda ČR dne 17. června 1998 svým usnesením č. 413 a uložila členům vlády a vedoucím ostatních ústředních orgánu státní správy zabezpečovat cíle a principy Dopravní politiky, mezi které patří také zavádění Inteligentních dopravních systémů a služeb, zejména v oblastech: • inovace technologické vybavenosti dopravních sítí a zabezpečovacích systémů včetně telematiky
82
• snížení nehodovosti v silničním provozu zaváděním telematiky do vozidel • snížení počtu a následků nehod zaváděním telematiky do všech oblastí zasahujících do silničního provozu a zlepšujících bezpečnost jejich uživatelů • výzkumu a vývoje řešením progresivních dopravních technologií s využitím logistiky, telematiky i globálních navigačních systémů • statistiky a informačních systémů v dopravě. Dokument „Dopravní politika České republiky“ zcela zřetelně stanovuje cíl dalšího rozvoje informačních systémů: dát státní správě k dispozici potřebné informace k rozhodovacímu procesu a podpoře podnikání v dopravě. To představuje především komercionalizaci informačních systémů, což na jedné straně umožní racionalizaci fyzických zbožních toků a usnadní vztah dopravce zákazník, ale na druhé straně činí značné nároky na databázové programy. V zájmu komplexní informovanosti je třeba rozvíjet informační systémy státní správy včetně propojení s informačními systémy EU a mezinárodních organizací. V této souvislosti bude podporován i vstup do mezinárodních projektů a grantů. Dále vláda ČR výše zmíněným usnesením č. 413/98 uložila ministru dopravy a spojů ve spolupráci s ministry financí, vnitra a práce a sociálních věcí zabezpečit plnění úkolu obsažených v Dopravní politice, a to v „Souhrnu opatření k realizaci hlavních cílů vyplývajících z Dopravní politiky“ uvedeném v části „Postup realizace státní dopravní politiky“, kde se v tzv. II. fázi realizace (bezprostřední období po vstupu ČR do EU) počítá s „realizací elektronického mýta na silniční síti“. Inteligentní dopravní systémy a služby jsou také jednou z oblastí „Státní informační politiky České republiky“ Vláda České republiky přijala svým usnesením č. 525 ze dne 31.5.1999 Státní informační politiku jako strategický dokument vlády. Tento dokument určuje dlouhodobý strategický cíl České republiky a klade si za cíl „vybudovat a rozvíjet informační společnost a tím vytvořit předpoklady zejména pro zvýšení kvality života jednotlivých občanů, zefektivnění státní správy a samosprávy a zkvalitnění podpory rozvoje podnikání“. Tento Akční plán sleduje cíle obsažené i v návrhu politické iniciativy „Evropa, informační společnost pro všechny“, označovaný jako „Prodiho iniciativa eEurope“, kterou Evropská komise zveřejnila dne 8. prosince 1999. Na Evropské ministerské konferenci, která se konala 11. - 12. května 2000 ve Varšavě, se zavázaly země střední a východní Evropy splnit cíle uvedené v dokumentu „Akční plán eEurope+“. Konkrétní kroky vedoucí k naplnění této strategie v České republice byly stanoveny v následně vypracovaném dokumentu „Akční plán realizace státní informační politiky České republiky pro období do konce roku 2002“, který vláda na svém zasedání schválila svým usnesením č. 527 ze dne 31. května 2000. Jednou z oblastí tohoto akčního plánu jsou také Inteligentní dopravní systémy. Při rozvoji telematiky budou muset být vyřešeny klíčové aspekty jako identifikace překážek v zavádění ITS, posuzování účelnosti telematických systémů před jejich realizací, uživatelská práva, oprávnění, přístup, osobní data, ochrana soukromí a udržení kontroly veřejného sektoru nad některými poskytovanými informacemi. Důležitou otázkou je také financování ITS. Budování ITS je spojeno zpravidla se značnými investičními a provozními náklady. Tento problém může pomoci vyřešit také partnerství veřejného a soukromého sektoru při poskytování služeb s přidanou hodnotou. Trendy rozvoje ITS systémů ve světě ukazují, že je nutné hledat úzké vazby s privátním sektorem, a že bez jeho podílu je výstavba takto komplexních systémů 83
velmi obtížná. Efektivní práce s informacemi může vytvořit základní předpoklad pro komerční využití technologií zpracování a přenosu informací. Vhodně obohacená informační úroveň poskytovaných služeb i o informační vstupy plynoucí z výkonu státní správy a uzemní samosprávy muže býti vhodným a rychlým informačním mediem (jako je například Internet, digitální televize, rozhlas či plošné zobrazovací tabule atd.) oslovujícím co nejvíce potencionálních uživatelů a vhodným sestavením informačních bloků také vytvořit prostor pro komercionalizaci služeb (služba proti úhradě). Toto řešení otevírá prostor pro účast soukromého kapitálu v rozvoji inteligentních dopravních systémů.
4.3 Úloha a cíle veřejné správy při zavádění ITS Úlohou Ministerstva dopravy musí být garance koncepce rozvoje dopravní telematiky, tvorba regulačních nástrojů pro implementaci systémů a aplikací, respektive služeb, pravidel atd. tak, aby si veřejný sektor udržel kontrolu nad informacemi, ale i informačním obsahem. Proto je nutné ve vytypovaných oblastech ověřit základní pravidla, dále technické, informační, ale i legislativní rámce a na základě ověření v pilotních aplikacích připravit tyto pravidla tak, aby bylo možné bez závažných překážek a problémů zapojit soukromý kapitál do rozvoje dopravní telematiky. Veřejný sektor by mohl využít informace ze systémů ITS a při vhodném zpracování dat tak může být veřejné správě poskytnuto dostatek informací pro podporu rozhodování. Tím by bylo zaručeno účinnější využívání sítí veřejných informačních systémů při jejich interoperabilitě a tím by mohlo dojít k zefektivnění vložených finančních prostředků do systémů veřejné dopravy ze státního, z regionálních a obecních rozpočtů. Ministerstvo dopravy by mělo ovlivňovat rozvoj inteligentních dopravních systémů a služeb jak legislativou, tak i přidělováním finančních zdrojů a uplatněním ostatních finančních nástrojů v oblastech: • zlepšení řízení dopravního provozu, zvyšování bezpečnosti dopravy a zlepšení koordinace záchranných prací, • zkvalitnění a zatraktivnění veřejné osobní dopravy, • optimální využití finančních prostředků a zprůhlednění využívání dotací na udržení potřebné dopravní obsluhy regionů a spravedlivější rozdělování přepravních tržeb mezi jednotlivými dopravci v rámci integrovaného dopravního systému, • zlepšení dopravního a územního plánování. Pro systémové řešení je nutné, aby všechny podpůrné systémy v rámci ITS (také s vazbami na ostatní informační a řídící systémy dalších resortů) vzájemně spolupracovaly, ať už systémy veřejného nebo soukromého sektoru, anebo obou sektorů navzájem. Z hlediska financování ITS a poskytování veřejných informací pro systémy ITS je nutno definovat z úrovně státu, které telematické služby jsou ve veřejném zájmu a jsou v souladu s dopravní politikou ČR, kde pro takto definované služby by měly být dopravní a přepravní informace poskytovány zdarma bez rozdílu, zda je poskytovatel služeb veřejná či soukromá organizace.
84
4.3.1 Strategické cíle zavádění ITS v ČR Bez provozní propojenosti mají systémy ITS pouze omezenou budoucnost. Inteligentní dopravní systémy a služby mohou vzájemně spolupracovat a tím usnadňovat splnění výše definovaných cílů evropské a národní dopravní politiky, pokud budou naplněny následující strategické cíle: • vytvoření či převzetí národních norem a standardů, které budou konsistentní s mezinárodními normami (normy a standardy rovněž zlepšují soutěž, snižují rizika pro uživatele a projektanty systémů a regulují náklady), • vytvoření otevřených architektur ITS systémů s vazbou na národní ITS architekturu ČR, která je zpracovávána v rámci tohoto projektu s cílem zajišťovat provozní propojenost a konkurenční prostředí ITS, • vytvoření ITS datového registru, který by poskytoval informace o informacích v rámci ITS, čímž by byla usnadněna výměna a sdílení informací, • zabezpečení jednotnosti digitálních geografických map v rámci různých organizací a různých dopravních oborů, • zabezpečit jednotný popis prvků dopravní infrastruktury tak, aby bylo možné sledování přímých a nepřímých nákladů dopravně-přepravního procesu, • zabezpečit legislativní rámce a organizační zajištění (např. vznik nezávislého regulačního orgánu) pro dosažení provozní propojitelnosti dílčích ITS systémů • vytvoření národního centra dopravních a přepravních informací, které by zabezpečovalo systémovou integraci dopravních a přepravních informací (zajištění věrohodnosti a aktuálnosti informací, jednotného formátu, lokalizace informací, atd.) a tyto informace by byly poskytovány provozovatelům telematických služeb buď zdarma (veřejný zájem), nebo za úhradu (neveřejný zájem). Při zajišťování výše uvedených strategických cílů ITS má na národní úrovni nezastupitelný význam veřejná správa. Pro zajištění kompatibility jednotlivých telematických systémů je velmi důležitý proces standardizace. Ten se odehrává na úrovni celosvětové v organizaci ISO a na úrovni evropské v organizaci CEN. Podstatné pro rozvoj telematiky v České republice je, že Ministerstvo dopravy (MD) již několik let koordinuje a podporuje standardizaci telematiky v technické komisi TC278 „Road Transport and Transport Telematics“ (Silniční doprava a dopravní telematika). Delegáti ČR se účastní zasedání odborných komisí CEN, ale zároveň řídí národních aplikační týmy, které jsou paralelou ke skupinám evropským. Tato činnost vyplývá i z asociační dohody mezi naší republikou a EU, která byla podepsána v roce 1995 a která mluví i o přejímání evropských standardů.
4.3.2 Naplňování strategických cílů ITS v ČR Překonání bariér bránících dalšímu rozvoji ITS v ČR a tím zajištění naplňování strategických cílů v ČR je možno zabezpečit pomocí tzv. pilotních ověření, jejichž výstupem budou metodické, legislativní, technické, atd. závěry získané na základě praktických ověřovacích zkušeností. Základní problémové okruhy v oblasti ITS byly definovány v rámci projektu Plány rozvoje ITS s vazbou na výkon veřejné správy realizovaného v roce 2001. Velmi podstatnou roli sehrává MD i v zadávání a vyhodnocování pilotních projektů. ITS systémy jsou totiž na národní úrovni velmi komplexní systémy a pilotní projekty by měly být řízeny nebo alespoň vyhodnocovány z úrovně MD.
85
Teprve po jejich vyhodnocení mohou být rozšířeny pro praktické aplikace, které pak mohou být realizovány různými organizacemi a podnikatelskými subjekty. Systémově se tedy jedná o strukturu znázorněnou v obr. 35. Velmi podstatnou složkou takto koncipovaného systému je i zpětná vazba, kdy jsou sledovány nejenom vynaložené investiční náklady, ale i provozní náklady a hlavně se vyhodnocuje, zda projekt přinesl předpokládaný profit. Tuto činnost mohou vykonávat podřízené složky státní a veřejné správy, Ředitelství silnic a dálnic, magistráty a městské úřady nebo jiné pověřené organizace, vč. organizací privátních. Spolupracují i další ministerstva, jako např. Ministerstvo vnitra a Ministerstvo životního prostředí. Sama metodika zadávání, vyhodnocování a evaluace pilotních projektů je odborně velmi složitá a mnohé státy EU si vytvořily vlastní metodiku, jako např. Finsko (Guidelines for the evaluation of ITS Projects, FITS Publication 4/2002).
Obr. 35 - Role MD při zadávání a vyhodnocování pilotních projektů ITS
Výše uvedené řešení urychlí dynamiku zavádění ITS v ČR, což bude mít pro státní správu a územní samosprávu ČR následující přínosy: • získání aktivního nástroje pro výkon národní i regionální dopravní politiky, • urychlení zapojení českých dopravních cest do evropského dopravního systému (splnění výše uvedených směrnic ES), • výrazné zvýšení bezpečnosti dopravy na dopravních cestách ČR, • zvýšení propustnosti stávající dopravní infrastruktury bez nutnosti výstavby nové infrastruktury (zvyšuje se efekt vložených prostředků), • zvýšení komfortu a vzájemných vazeb veřejné osobní přepravy,
86
• zmírnění dopadů dopravy na životní prostředí a přispění k udržitelné mobilitě osob a zboží zejména ve vybraných regionech a příměstských lokalitách, • získání nástroje kontroly dotační politiky státu a regionů do dopravní obslužnosti, • atd.
4.4 Úloha a cíle soukromého sektoru při zavádění ITS V procesu plánování, ale i v procesu realizace ITS sehrává privátní sektor podstatnou roli. Pro vzájemné partnerství soukromého a veřejného sektoru (PPP Private Public Partnership) je nutnost vzájemného porozumění obou partnerů, k čemuž musí státní orgány vytvořit tvůrčí klima spočívající v organizaci diskusních fór, seminářů apod. Problém PPP (viz. obr. 36) je ve světě velmi diskutován a je označován za klíčový moment masové aplikace a rozšiřování ITS systémů. Základními předpoklady pro kooperaci soukromého a veřejného sektoru jsou: • • • • •
partnerský vztah musí být rovnoprávný a musí z něj profitovat obě strany případná rizika jsou rozložena na oba partnery, od samého začátku musí být jasně definovány role partnerů, vlastnické vztahy a struktury musí být definovány od začátku, musí být definován předmět činnosti a výstupy z něho.
87
Obr. 36 - Vztah veřejného a privátního sektoru v ITS
Při realizaci telematických systémů je třeba vzít na zřetel, že aplikace jsou tvořeny konsorciem různých účastníků. Úkoly, funkce a institucionální charakteristiky různých účastníků se dají popsat následovně: • Uživatel. Jako uživatel se označuje vlastní zákazník, případně zájemce o telematické dopravní služby. Je současně i uživatelem dopravní infrastruktury. Uživatel je zpravidla soukromá osoba, případně účastník dopravy, který musí učinit rozhodnutí ve věci způsobu, doby a cíle dopravního prostředku nebo trasy, které si zvolí. K podpoře tohoto rozhodnutí využívá telematických dopravních služeb. K uživatelům telematických služeb mohou být počítány i veřejné instituce, např. veřejné dopravní podniky, pokud se dává přednost veřejné dopravě. • Majitel/provozovatel dopravní infrastruktury, případně dopravních služeb. Do této kategorie patří v první řadě majitelé a provozovatelé dopravní infrastruktury, jejichž úkolem je v podstatě zabezpečení připravenosti infrastruktury. • Poskytovatel telematických dopravních služeb. Poskytovatelé telematických dopravních služeb mohou být různé instituce. Mezi provozovateli dopravní infrastruktury a poskytovateli telematických služeb existuje zpravidla pevná vazba a vždy podle konkrétní služby je třeba stanovit překrývání kompetencí těchto dvou skupin. U komplexnějších zařízení se mohou objevit soukromí poskytovatelé telematických dopravních služeb, což by se mělo týkat i např. distribuce dopravních informací. Provozovatelé dopravní infrastruktury musí v každém případě mít zájem na tom, aby poskytovatelé telematických služeb jednali v jejich intencích a přispívali k optimálnímu využití jejich infrastruktury. Služby mohou být uživatelům poskytovány pomocí rozhlasu, Internetu, dopravní signalizace a dalších technických prostředků.
88
• Poskytovatel dopravních informací. Podstatným znakem dopravní telematiky je rozšiřování informací o aktuálním dopravním dění. Tyto informace mohou pocházet z různých zdrojů. Provozovatelé dopravní infrastruktury patří přirozeně k hlavním dodavatelům aktuálních dopravních dat. Kromě toho mohou provádět i sběr soukromých dat a zpracovávat je, aby mohla být rozšiřována poskytovateli telematických dopravních služeb. V tomto odvětví se předpokládá podstatná činnost privátního sektoru • Tvůrce technologií dopravní telematiky. Technologie pro rozšiřování telematických dopravních služeb se vytvářejí zpravidla v soukromých institucích a firmách. Ve veřejném zájmu je především interoperabilita takových technologií, kterou mají zajistit nově zpracovávané normy. • Zákonodárce/normalizační instituty. Zákonné a normativní rámcové podmínky musí stanovit zákonodárce a normalizační instituty Trendy rozvoje telematických systémů ve světě ukazují, že je nutné hledat úzké vazby s privátním sektorem, a že bez jeho podílu je výstavba takto komplexních systémů iluzorní. Přitom je ovšem nutné mít na zřeteli, že se jedná o trochu jiné myšlení a jinou kulturu práce. Některé příklady odlišností jsou: Státní a veřejné orgány
Privátní sektor
Požadavek na široký konsensus
Rychlé rozhodování
Demokratické přemýšlení
Obchodní uvažování
To nejlepší pro veřejnost
Tvorba zisku
Citlivost na veřejné mínění
Citlivost na mínění zákazníka
Součástí telematických projektů a koncepcí musí být i jasné vymezení úloh mezi privátním a veřejným sektorem.
4.5 Návrh postupných kroků zavádění ITS v ČR Prvním krokem zavádění ITS v ČR je zajištění, aby byly publikovány a každoročně aktualizovány registry infrastruktury, vozidlového parku a subsystémů a dat ITS, které budou uvádět hlavní charakteristiky každého subsystému nebo dílčího subsystému v daném procesu (například základní parametry) a jejich vzájemný vztah s těmito charakteristikami. Druhým krokem zavádění ITS v ČR je zabezpečení rozvoje systémů ITS dle definované ITS architektury ČR. Následující část zdůrazňuje návrh jednotlivých telematických aplikací v různých dopravních oborech z hlediska krátkodobých a střednědobých cílů zavádění ITS v ČR. 4.5.1 Silniční doprava Postupné kroky a priority ČR v oblasti silniční telematiky lze definovat v následujících oblastech: • Zvýšení bezpečnosti silniční dopravy
89
o Řízení dopravy v městských aglomeracích. o Liniové řízení dopravy. o Pokročilé řízení dopravy navigováním. • Dopravní informační systémy o Vybudování národního centra dopravních a přepravních informací informačně propojeného s regionálními a městskými dopravně-informačními centry, případně i dalšími poskytovateli dopravních a přepravních informací (veřejné i soukromé subjekty), meteo informací, atd. o Rozšíření systému RDS-TMC pro distribuci dopravních informací řidičům. o Dokončení navigační mapy ČR. • Elektronické vybírání poplatků za použití silniční dopravní infrastruktury o Zpoplatnění silniční infrastruktury dle parametrů vozidel a ujeté vzdálenosti (v prvním kroku zavádění systému se předpokládá aplikace tohoto systému pro nákladní vozidla nad 3.5 tuny). o Zpoplatnění a řízení přístupu do center velkých měst (např. Praha).
4.5.2 Železniční doprava Postupné kroky a priority ČR v oblasti železniční telematiky lze definovat v následujících oblastech: • Zvýšení bezpečnosti železniční dopravy o Realizace pilotního projektu GSM-R v ČR, který řeší potřeby interoperability digitálního radiového přenosu informací. o Realizace pilotního projektu ERTMS/ETCS (Europeans Rail Traffic Management System/European Train Control System), který řeší potřeby interoperability jednotného standardizovaného evropského systému v oblasti managementu a řízení železniční dopravy. • Dopravní informační systémy o Další rozvoj systémů pro management dopravní infrastruktury a dopravních prostředků • Inteligentní vozidlo o Zavádění inteligentních vozidlových subsystémů, jako např. systém AVV automatické vedení vlaku
4.5.3 Veřejná osobní doprava Postupné kroky a priority ČR v oblasti telematiky lze definovat v následujících oblastech: • Zvýšení bezpečnosti dopravy o Zavádění hlasových informačních a navigačních systémů určených pro hendikepované občany využívajících veřejnou osobní dopravu. • Poskytování dopravních a cestovních informací o Rozvíjení národního informačního systému pro poskytování jízdních řádů veřejné osobní dopravy různými prostředky jako Internet, GSM, atd.
90
o Poskytování vizuálních a hlasových informací pro cestující na zastávkách veřejné dopravy. • Elektronické zpoplatnění veřejné osobní dopravy o Zavádění elektronických jízdních dokladů ve veřejné osobní dopravě v rámci integrovaných dopravních systémů měst a regionů.
4.5.4 Nákladní doprava a přeprava Postupné kroky a priority ČR v oblasti telematiky nákladní dopravy lze definovat v následujících oblastech: • Zvýšení bezpečnosti dopravy a přepravy o Zavádění databázových a informačních systémů pro podporu sledování a řízení přeprav nebezpečných a nadrozměrných nákladů. • Poskytování dopravně-přepravních informací o Poskytování dopravně-přepravních informací různým institucím dotčených dopravně-přepravním procesem • Elektronická výměna dat o Zavádění prostředků standardizované elektronické výměny dat mezi různými institucemi spojenými s dopravně-přepravním procesem.
4.5.5 Vodní doprava Postupné kroky a priority ČR v oblasti telematiky vodní dopravy lze definovat v následujících oblastech: • Zvýšení bezpečnosti dopravy a přepravy o Zavádění vybavování lodí ITS technickými prostředky zejména u lodí dálkové zahraniční plavby a harmonizace systémů ITS se státy EU. o Sledování a řízení přepravy nebezpečných nákladů po vodních dopravních cestách a přístavech. • Poskytování dopravně-přepravních informací o Poskytování informačních, navigačních a komunikačních služeb všem účastníkům dopravně-přepravního řetězce (rejdaři, dopravci, spedice, atd.). • Elektronická výměna dat o Zavádění prostředků standardizované elektronické výměny dat mezi různými institucemi spojenými s dopravně-přepravním procesem vodní dopravy a přepravy (EDI, EDIFACT).
4.5.6 Letecká doprava Postupné kroky a priority ČR v oblasti telematiky letecké dopravy lze definovat v následujících oblastech: • Zvýšení bezpečnosti letecké dopravy o Harmonizace řízení civilního a vojenského letového provozu. o Monitorování a řízení pohybu pohyblivých objektů po pohybové ploše letiště (program A-SMGCS - Advanced Surface Movement Control Guidance System).
91
o Postupné zavádění a koordinace národního řízení letového provozu a řízení letového provozu zemí střední Evropy (CEATS - Central European Traffic Services) • Poskytování dopravně-přepravních informací o Rozvoj rezervačních a informačních systémů pro cestující (rezervace letenek prostřednictvím Internetu, vybudování zákaznických call center, zabezpečení návaznosti letecké dopravy a veřejné osobní dopravy). • Aplikace nových technologií v letecké dopravě o Využití budoucího navigačního systému GALILEO ve všech fázích letu, výhledově jako podporu koncepce volných letů (Free Flight) o Zavádění prostředků standardizované elektronické výměny dat mezi různými institucemi spojenými s dopravně-přepravním procesem letecké dopravy (informační vazba mezi ŘLP ČR, s.p. a ČSL, s.p., atd.).
4.6 Závěr Z výše uvedených výsledků je zřejmé, že tak komplexní systémy jako jsou systémy dopravní telematiky nelze zavádět a tvořit bez předem stanovené a všemi zúčastněnými odsouhlasené architektury. Tvorba architektury však vyžaduje základní úvahy a teorie známé z vědních oborů inženýrská informatika, systémová analýza, operační výzkum, atd. Při tvorbě architektury telematických systémů není možno sledovat pouze technickou stránku věci, ale celý koncept je nutno svázat s podobou organizační struktury dané organizace, definováním jednotlivých kompetencí, pravomocí, atd. Tvorba architektury dopravně-telematického systému je proto multidisciplinární problém, jehož řešení vede na funkční systémy, které slouží svému účelu, pracují optimálně a vytváří užitné vlastnosti té které organizace. Na problému dopravní telematiky lze koncept tvorby architektury velmi dobře demonstrovat, neboť doprava se vyznačuje velkou dynamikou zpracovávaných informací. Je nutno poznamenat, že podobný přístup lze definovat pro tvorbu telematických systémů všech síťových odvětví s plošnou působností, jako je např. plynárenství, energetika, atd. Oblast dopravní telematiky je na evropské úrovni sledována a koordinována Evropskou komisí, dále pak organizacemi jako UIC, ERTICO, které sdružují významné subjekty z celého evropského prostoru. Jelikož každá země má svá specifika, vznikají v Evropě různá národní sdružení, která sledují koncepce dopravní telematiky v té které zemi. V ČR vzniklo v roce 2000 Sdružení pro dopravní telematiku ČR, které má rozvinutu spolupráci se sousedními zeměmi střední a východní Evropy. Jedině vzájemnou koordinací a konsensem mezi všemi zúčastněnými stranami lze docílit vzniku fungujícího telematického systému, neboť jak bylo již mnohokráte zmíněno, je dlouhá cesta mezi fyzickou vrstvou systému a jeho funkčností.
92
6. LITERATURA [1]
Vlček J.: Systémové inženýrství, vydavatelství ČVUT, Praha 1999.
[2]
Výstupy projektů KAREN, ACTIF, ARTIST, FRAME
[3]
M. Svítek, F. Kopecký: Dopravní telematika jako speciální služba mobilních operátorů, Sdělovací technika, 5/2002.
[4]
M. Svítek, F. Kopecký: Koncepce dopravní telematiky na Ředitelství silnic a dálnic, studie pro Ředitelství silnic a dálnic, červen 2002.
[5]
M. Svítek: Procesní modely dopravních telematických systémů, docentská habilitační práce, ČVUT, Fakulta dopravní, červen 2002.
[6]
M. Svítek: Towards to e-Transport, mezinárodní konference SSGRR2002 Advances in Infrastructure for Electronic Business, Science, Education and Medicine on the Internet, Řím 2002, ISBN 88-85280-63-3.
[7]
M. Svítek: Towards to Telematics, II. International Conference Transport Systems Telematics TST02, Katowice 2002.
93
7. PŘÍLOHA 1 - FUNKČNÍ ITS ARCHITEKTURA ČR
8. PŘÍLOHA 2 - INFORMAČNÍ ITS ARCHITEKTURA ČR
9. PŘÍLOHA 3 - POPIS DATABÁZÍ ITS ARCHITEKTURY ČR
10. PŘÍLOHA 4 – POPIS TERMINÁTORŮ ITS ARCHITEKTURY ČR
11. PŘÍLOHA 5 - TELEKOMUNIKAČNÍ PROSTŘEDÍ ČR A JEHO VYUŽITÍ V ITS
94
