Internetový geografický informační systém, který provádí integraci dat, modelů a uživatelů pro dopravní aplikace Athanasios K. Ziliaskopoulos a, S. Travis Waller b a b
Department of Civil Engineering (Katedra stavebního inženýrství), Northwestern University, Evanston, IL 60208, USA Department of Industrial and Systems Engineering (Katedra průmyslového a systémového inženýrství), Northwestern University, Evanston, IL 60208, USA
Tento materiál se zabývá vývojem internetových geografických informačních systémů GIS, které spojují dohromady prostoročasová data, modely a uživatele v jednom společném efektivním rámci, který se pak používá pro širokou řadu dopravních aplikací, jako jsou - plánovací, inženýrské a provozní aplikace. Jsou zde načrtnuty funkční požadavky systému, které berou v úvahu různé podpůrné technologie, jako jsou internetové nástroje, rozsáhlé databáze a distribuované početní systémy. Stručně je pojednáno o problémech v oblasti realizace a též o nezbytných modelech potřebných pro podporu daného systému.
1. Úvod Dopravní systémy jsou složité celky, které vyžadují monitorování, řízení, udržování a zlepšování podstatných dat a též různé pracovní modely, které pomáhají různým skupinám úřadů provozovat daný systém. Data, která jsou v současné době shromažďována dopravními úřady a orgány, mohou být volně klasifikována v následujících typech: plánovací, inženýrská a provozní; obdobnou klasifikaci je možno provést pro používané modely. Tato data mají určité podobné prvky: (i) všechna tato data se týkají stejné sítě, dopravní poptávky a kontrolních zařízení, přestože se jedná o různé úrovně seskupování a přesnosti reprezentace, (ii) jedná se o prostoročasová data, tj. tato data je možno sdružit s prostorovými a časovými souřadnicemi, (iii) tato data jsou často používána více než jedním modelem pro různé aplikace. Bylo by možno dosáhnout velkých přínosů, kdyby tato data byla integrována do jediné databáze nebo do spojených distribuovaných databází a kdyby byla přístupná pro všechny potřebné modely. Data a modely by pak mohly být k dispozici všem zúčastněným subjektům: plánovačům, inženýrům, provozovatelům a rovněž různým dalším zainteresovaným osobám, jako jsou výzkumníci a poradci, společnostem provozujícím silniční nákladní dopravu, zvláštním zájmovým skupinám a dokonce i cestující veřejnosti. V současné době se musejí odborníci v oblasti dopravy vypořádat s rozštěpenými databázemi, násobnými a neslučitelnými modely, redundantními a často vzájemně protichůdnými snahami o pořizování dat, nedostatkem koordinace mezi různými úřady a soukromými společnostmi působícími na stejných dopravních zařízeních. To má za následek vážnou neefektivnost a plýtvání zdroji. Například pracovník v oblasti dopravního plánování využívá síť metropolitní oblasti pro analýzu kvality ovzduší, jež je zpracována v určitém formátu, který je obvykle neslučitelný se softwarem pro optimalizaci signálů (např. pro semafory) nebo simulační prostředí, který používá dopravní inženýr téže městské oblasti za účelem optimalizace operací na dané městské síti. V typickém případě oba tito odborníci nezávisle na sobě shromažďují a kódují data pro stejnou síť a poptávku (i když se jedná o
různé úrovně seskupení), aniž by využívali stávajících zdrojů, které jsou vzájemně k dispozici u jednotlivých úřadů. Podpůrné technologie vyvinuté v průběhu posledních několika let vytvořily bezprecedentní příležitosti pro překonání některých z výše uvedených problémů. Tyto technologie zahrnují rozmach internetu a internetových podpůrných nástrojů, databází o velikostech v řádu terabyte, distribuovaných výpočetních architektur, vývoj inteligentních dopravních systémů. Mnoho z těchto technologií již bylo přijato podnikovými strukturami a vedlo k vývoji nových obchodních modelů. Skutečnost je taková, že od dynamiky dodavatelského řetězce přes řízení vztahů se zákazníky až po umožnění infrastruktury pro elektronický obchod nebyla nikdy větší příležitost k propojení obchodních procesů a příslušných lidí v rámci organizace (Chambers, 1999). Internetově podporovaný geografický informační systém (GIS) rovněž získal velkou pozornost v posledních několika letech: Jankowski a Stasik (1997) zavedli internetový GIS pro umožnění spolupráce při rozhodovacím procesu o prostorových otázkách prostřednictvím veřejné účasti. Keisler a Sundell (1997) předložili integrovaný geografický víceatributový systém obslužných prostředků s aplikací na parkové plánování. Rozsáhlý přehled aplikací a výzkumných úkolů pro aplikace geografických informačních technologií v obchodu je uveden v Mennecke (1997). Tento materiál představuje prototypový internetový GIS, jehož cílem je integrace prostoročasových dat a modelů pro široké spektrum dopravních aplikací: plánovacích, inženýrských a provozních aplikací. Grafické uživatelské rozhraní GIS (GUI) je vytvořeno v prostředí JAVA, takže může být používáno přes internet (nebo nějakou jinou velkou síť). Daná databáze zajišťuje efektivní uložení a vyhledávání prostoročasových dat tím, že sdružuje údaje pro zeměpisné souřadnice a čas. Tato databáze je navržena tak, aby zajišťovala efektivní řízení širokého spektra dopravních dat: od plánování off-line způsobem a inženýrských činností po proudy v reálném čase, jako jsou data přicházející z čidel rozmístěných v ulicích a u zařízení na novějších vozidlech. Navíc platí, že řízení a souhrn dat, který je díky takovému systému umožněn, pomáhá vypořádat se s problémy vznikajícími z požadavků specifických pro příslušný úřad. Řada modelů byla zakódována v tom samém rámci a je možno k nim získat přístup přes GUI systému GIS v nastavení klientského serveru. Přístup k modelům je umožněn dálkovým způsobem přes GIS a tyto modely je možno provozovat v nějakém distribučním prostředí založeném na brokerské architektuře požadavků společných objektů (common object request broker architecture - CORBA). Realizované modely zahrnují tradiční nástroje pro řízení a analýzu signálů (semafory), plánovací modely a též nová dynamická dopravní přiřazení (dynamic traffic assignment - DTA) a směrovací algoritmy. Tento materiál pojednává o interakcích mezi modely, potenciálními přínosy na straně efektivity dosaženými integrací dat a modelů, realizačních problémech a též o důsledcích na praktické postupy v oblastech plánování, inženýrství a v provozní oblasti. Měli bychom poznamenat, že hlavní zaměření je na technické aspekty této integrace a nikoliv na institucionální/koncepční otázky, i když by tyto institucionální a koncepční otázky vedly zřejmě k užšímu vymezování konečného systému. Takové otázky si však zaslouží velkou pozornost a přesahují rozsah tohoto příspěvku. Navíc platí, že v důsledku širokého spektra koncepcí a úřadů tento přestavovaný systém není v současné době prezentován v kontextu s nějakou konkrétní státní agenturou nebo nějakým orgánem. Namísto toho se prozkoumávají klíčové charakteristiky dopravních dat a modelů, aby bylo možno vyvinout nějaký systém, který by bylo možno později zařadit do institucionálního rámce nějakého konkrétního subjektu. V následujícím oddílu popíšeme potřeby a funkční požadavky daného systému. Celková architektura modelu je popsána v oddílu 3. Modely, které jsou v současné době realizovány nebo u nichž je třeba, aby tvořily součást rámce, jsou popsány v oddílu 4. Oddíl 5 obsahuje
2
podrobné údaje týkající se realizace, včetně odůvodnění pro internetové GUI a distribuované výpočetní prostředí. Oddíl 6 pojednává o potenciálních přínosech, které je možno realizovat integrací dat, modelu a uživatelů. Oddíl 7 představuje závěr tohoto materiálu a uvádí směry pro budoucí výzkum.
2. Potřeby a funkční požadavky Dopravní praxe zahrnuje data, modely a uživatele. Data, která jsou v současné době shromažďována dopravními úřady a orgány, mohou být volně klasifikována v následujících typech: plánovací, inženýrská a provozní; obdobnou klasifikaci je možno provést pro používané modely. Plánovací data obsahují širokou třídu dat od cestovních průzkumů přes společenskoekonomická data podle regionů a data týkající se síťové infrastruktury až po souhrnné dopravní toky pro každodenní spoje. Tato data se používají pro účely dlouhodobého plánování, jako je například odhad vlivů při zlepšeních infrastruktury, rozdělení jednotlivých druhů dopravy a při odhadu ekologických dopadů. Používané modely zahrnují tradiční čtyřstupňové plánovací modely, jakož i další prognostické modely a modely diskrétního výběru. Inženýrské aplikace v typickém případě vyžadují podrobnější síťová, řídící a dopravní data, která se získávají přímým pozorováním a za pomoci dopravních inženýrských studií. Síťová data zahrnují podrobnou reprezentaci geometrie křižovatek, odbočovací pohyby a zákazy; dopravní data jsou často seskupována každých 15 minut, zatímco je třeba mít k dispozici signální (semafory) nebo významové řídící informace, jako je typ řídící jednotky a přesný časový plán. Tato data jsou používána pro krátkodobější inženýrské aplikace, jako je záruková analýza, vývoj plánu pro časování signálů (semafory) a řízení dálnic. Modely používané inženýry jsou v typickém případě tvořeny optimalizací signálů (semafory), simulací a kapacitní analýzou. Konečně, dopravní provozovatelé shromažďují data v reálném čase z čidel instalovaných on-line způsobem, na jejichž základě se provádějí operativní rozhodnutí v reálném čase. Data síťové infrastruktury jsou též spojitým způsobem aktualizována na základě změn územního plánování, stavebních plánů, událostí a řízení dopravy. Modely typu městských systémů řízení dopravy (UTCS) jsou často používány řídícími centry a příležitostně též algoritmy pro funkční měření a proměnné hlášky, které jsou používány u provozovatelů dálnic. Tabulka 1 pak uvádí dosti stručný seznam různých typů dat, modelů a uživatelů. Jak bylo uvedeno níže, je stav dopravní praxe charakterizován rozštěpenými databázemi, redundantním a často nevhodným úsilím v oblasti pořizování dat, databázovým softwarem zděděným z jiných aplikací, nedostatkem profesionální softwarové podpory, nekompatibilními a neúplnými množinami dat. Dané modely jsou dosti zvláštní směsí orgánů vyvinutých a udržovaných státními úřady (jedná se například o nástroje TRANSYT, NETSIM a TRANSIMS), které konkurují modelům vyvíjeným a udržovaným v rámci soukromého sektoru (Synchro, TransCad a Integration). Většina modelů je v typických případech neslučitelná a jediným způsobem, jak provádět konverzi datových množin z jednoho modelu do jiného modelu je přes pečlivý proces konvertování souborů formátu ASCII. Konečně je třeba zmínit i skutečnost, že počty uživatelů dat a modelů se neustále zvyšují, přičemž se v typických případech jedná o vzdálené uživatele s různými potřebami, cíli a s různými úrovněmi vyspělosti systému. Nedostatečná koordinace mezi odborníky uvnitř jednoho úřadu a též mezi různými státními úřady a soukromými společnostmi působícími na stejných dopravních zařízeních je rovněž velmi dobře známa.
3
Tabulka 1 Typy dat modelů a uživatelů pro dopravní aplikace (DOT = ministerstvo dopravy; MPO = metropolitní organizace pro územní plánování)
UŽIVATELÉ Provozovatelé Inženýři DOT Města Oblast
Plánovači MPO DOT
Tvůrci koncepcí Veřejnost Zainteresované strany Přepravci AAA Poradci Tranzit
DATA Reálný čas
MODELY APLIKACE Dopravní simulátory Plánování
Čidla AVL I-PASS Tranzit/doprava Neveřejná data
Mikroprostředí Střední prostředí Makroprostředí
DTA Založené na simulaci Analytické FAT/UE/SO Víceuživatelské
Historická/Offline Souhrnné RT Sčítání lidu Zvláštní studie
Směrování Řízení
Přehledy Offline Online
Izolovaná/páteřní/síť/ rampová funkce měření Online/Offline
Speciální Pracovní oblast Nehody Záruková analýza
HCS UE/SUE Diskrétní výběr Logit/Multi-/Nested
Obec. vyhodnocení Vyhodnocení vlivů infrastruktury CM/kvalita ovzduší Tranzitní trasy
Inženýrink Návrh Řízení Údržba Bezpečnost VMS Loc., ITMS
Tvorba koncepcí Monitorování projektů Hospodářské dopady Legislativa
Veřejnost Plánování cest ATIS
První problém, kterému jsme čelili během vývojové fáze našeho rámce, bylo stanovení potřeb dopravních systémů ve světle příležitostí prezentovaných různými podpůrnými technologiemi. Tyto potřeby byly seskupeny do tří celků: 1. Potřeby rozhraní a uživatelských spojení 2. Integrační potřeby databází 3. Potřeby modelování. Aby bylo možno splnit výše uvedené potřeby, jsou stanoveny následující funkční požadavky. 2.1 Internetová rozhraní společná všem uživatelům majícím přístup do systému Tento funkční požadavek uvádí internet jako prostředek pro přístup k systému, ačkoliv by intranet nebo nějaká jiná podniková síťová struktura velkého rozsahu mohla rovněž splňovat tento požadavek. Vzhledem k tomu však, že by jednou třídou uživatelů mohla být v konečném stupni vývoje veřejnost, zdá se, že logickým a nejméně nákladným přístupem, který bychom měli přijmout, je skutečně internet. Kromě toho stávající široká infrastruktura internetu zaručuje rozsáhlou aktualizaci, nové nástroje a seznamování uživatelů s těmito nástroji. Pokud bude k rozhraní GIS přístup přes internet, bude mnoho uživatelů moci přistupovat k systému současně a budou moci provádět velké množství operací. 2.2 Integrovaná (a případně distribuovaná) internetově podporovaná databáze, která může řídit velké skupiny offline a online dat Databázová podpora a funkce poskytování zpráv mohou být získány z komerčních balíků, které jsou nabízeny již v připraveném stavu, jako je například ORACLE 8i, který rovněž podporuje internetový přístup. Otázkou, která potřebuje zvláštní aspekty, je schopnost 4
pracovat s daty v reálném čase, která přicházejí od snímačů nainstalovaných na infrastruktuře, jejich filtrace, slučování a archivování. Výhodou toho, že je k dispozici jedna databáze (i když distribuovaná nebo tvořená určitým počtem spojených databází), ke které je přístup přes nějaké společné rozhraní, je to, že uživatelé mají přístup k obdobným a konzistentním datovým množinám. Kromě toho platí, že pokud bude jeden uživatel provádět aktualizaci dané databáze, budou příslušné změny transparentní pro všechny ostatní uživatele. Problematika návrhu spojená s databází GIS je široce projednána v literatuře - Healey (1991). 2.3 Distribuované modely tak, aby bylo možno vykonat zabudované algoritmy s velkými potřebami výpočetních kapacit v přiměřeném čase Jednoduše vzato, distribuované systémy umožní simultánní provádění pro mnoho objektů na mnoha počítačích, které jsou prostorově rozloženy a propojeny přes internet nebo jinou síť. Distribuované systémy mají v sobě zabudované schopnosti pro synchronní i asynchronní komunikaci mezi objekty. To umožní, aby rozhraní byla prováděna dálkovým způsobem z realizace příslušných algoritmů a aby byly používány multiprocesory pro provádění algoritmových modulů, pokud to bude třeba. 2.4 Účinný reportingový systém, který může provádět dotazy na databázi a vytvářet intuitivní zprávy, jež mohou být zaměřeny na potřeby všech uživatelů Tento funkční prvek usnadní komunikaci mezi odborníky. Podobně, jak je uvedeno výše, tak i tento funkční prvek v typických případech přichází jako podpůrný nástroj do komerčních databází, jako je ORACLE 8i. Mělo by se však zdůraznit, že je třeba najít určitou optimální rovnováhu mezi reportingovým systémem, který se snadno používá, a umožněním uživateli, aby si přizpůsobil dotazový a reportingový systém, což zvyšuje potřebu školení a vede ke složitosti používání systému. 2.5 Účinný administrativní podpůrný systém, který umožní uživatelům řídit jejich datové množiny a zprávy Během průběhu používání daného systému bude vytvářeno mnoho zpráv a sekundárních datových množin. Uživatelé by měli mít možnost řídit své soubory, odstraňovat dočasné datové množiny a trvale ukládat a publikovat konečné datové množiny. 2.6 Účinný zabezpečovací systém, který chrání integritu dat a autorizovaný přístup k datům Různí uživatelé budou mít přístup do databáze na různých úrovních autorizace. Například stavební inženýr může provádět aktualizaci stavebních plánů pro nějakou oblast pracovní zóny, která mění dostupnou kapacitu na daném konkrétním zařízení. Tyto změny budou okamžitě známy obsluze daného zařízení, která však nemusí mít pravomoc provádět další změny. Opačná situace může nastat při strategii měření rampových funkcí nějakého zařízení ve výstavbě: se změnami může být obeznámen stavební nebo rezidentní inženýr, ale nemůže provádět další změny. 2.7 Stupňovitost systému takovým způsobem, aby bylo možno provádět rozšiřování dat a modelů s tím, jak se budou vyvíjet potřeby uživatele
5
Daný systém bude neustále rozvíjen s tím, jak do něj budou zahrnováni další uživatelé, data a modely. Díky tomu by měl být systém stupňovitého typu, aby bez problémů umožňoval další růst a změny. 2.8 Komunikace mezi uživateli umožňující vytvoření virtuálních odborných společenství Internet a integrovaná databáze zajišťují transparentní systém, ve kterém jsou kromě dat a modelů ostatním uživatelům pracujícím na daném systému k dispozici též sekundární data, zprávy, analýzy a akce. To bude umožňovat nejen získání informací, ale též i jejich výměnu; pokud budou do procesu zahrnuti výzkumní činitelé, mohlo by se jednat o výhodný prostředek pro převod technologií.
3. Celkový přístup a architektura modelů Celkový přístup představený v tomto materiálu byl inspirován a realizován podle praktik přijatých v sektoru informačních technologií (IT). Cílem je splnit funkční požadavky popsané v předchozím oddílu a spojit dohromady data, modely, uživatele a aplikace do jednoho homogenního, účinného, vzájemně protkaného systému. Zavedený rámec se nazývá vizuální interaktivní systém pro dopravní algoritmy (visual interactive system for transportation algorithms - VISTA). VISTA je distribuovaným systémem splňujícím standardy CORBA, který je přístupný přes nějakou síť (včetně internetu1), daný klient je nezávislý na stroji (technologie JAVA), systém je charakterizován přívětivostí k uživateli a přístup do systému je založen na různých úrovních autorizace. Přístup k datům a modelům je pro všechny uživatele na různých úrovních a umožňuje vyhledávání, údržbu a analýzu. CORBA se používá vzhledem k tomu, že aplikační moduly jsou psány v různých jazycích (C, C++, FORTRAN, atd.) a mohou běžet na různých platformách Windows nebo UNIX. Zatímco jiné distribuční technologie (RMI, DCOM) se vyvíjely směrem k této otevřenější objektově orientované rámcové struktuře, jedná se o poměrně nedávné změny a tyto změny nejsou považovány za dostačující pro splnění funkčních požadavků v době vývoje. Konkrétně dosud realizovaný systém zahrnuje: • Modul datového skladu (obdobný jako v případě ORACLE 8i), k němuž je přístup přes nějakou síť (intranet/internet). • Stávající a nové dopravní modely a nástroje (plánovací, inženýrské, řídící, monitorovací, hodnotící a provozní nástroje). • Uživatelská rozhraní pro různé zainteresované subjekty (plánovače, inženýry, tvůrce koncepcí a operátory), která umožňují přístup k datům a modelům z jakéhokoliv počítačového zařízení v jakémkoliv místě, v jakoukoliv dobu a pro jakéhokoliv uživatele. • Daný systém je distribuovaným systémem splňujícím standardy CORBA, který umožňuje, aby byly modely s intenzivními nároky na CPU prováděny na mnoha počítačích. • Podpůrné schopnosti pro všechny příslušné dopravní aplikace. • Funkční prvky pro interakci mezi uživateli. • Určité reportingové schopnosti. • Bezpečnostní charakteristiky pro mnoho uživatelů, kteří mají přístup do stejné databáze na různých úrovních autorizace. • Některé základní administrativní schopnosti.
1
http://its.civil.nwu.edu/vista-beta/ 6
Daný systém je zamýšlen tak, aby byl používán na státní úrovni, kde budou mít ministerstvo dopravy příslušného státu (DOT), metropolitní organizace pro územní plánování (MPO), inženýři působící na úrovni oblasti a města, úřady a orgány pro tranzitní dopravu, úřady pro nákladní dopravu a další zainteresované subjekty přístup k danému systému na různých úrovních autorizace, aby mohli získat/udržovat data, spouštět modely a provádět analýzu. Tvůrci koncepcí na federální úrovni, státní úrovni a úrovni místních samospráv budou moci monitorovat projekty, získávat data, vyhodnocovat vlivy daných koncepcí a provádět rozhodnutí. Celková struktura systému VISTA je načrtnuta na obrázku 1.
Komunikace přes ILU ORB RouteSim Synch Java 1.2 ORB přes spojení TCP/IP (internet)
VISTA Java GIS
JDBC
SQL a CORBA knihovny C++
Databázový modul (částečně k dispozici celému rámci)
Synch Asynch
Řídící modul
Synch DTA
DYNASMART
Synch Synch
Synch
Statické dopravní přiřazení
Časově závislé cesty
Obrázek 1: Struktura systému VISTA Uživatelské rozhraní je napsáno zcela v prostředí JAVA, takže je možno jej snadno použít na násobných platformách a přes internet. Komunikuje s řídícím modulem přes standardní broker objektových požadavků (ORB) Java 1.2, který umožňuje každému uživateli, který má k dispozici novější prohlížeč Netscape nebo internet Explorer, přístup k systému za použití prostředků (výměnný díl) Java 1.2. Toto rozhraní pracuje jako exkluzivní pro klienta a komunikuje pouze s řídícími a databázovými moduly. Pokud klient pracuje jako Applet, je omezen přísnými bezpečnostními omezeními se zřetelem na síťovou komunikaci. Podstatné je, že Applet může komunikovat pouze se strojem, z něhož pochází. Z tohoto důvodu je důležité, aby daný řídící modul běžel na stejném stroji, který obsluhuje webovou stránku systému VISTA. Když dojde k natažení stránky VISTA HTML, je načítán řetězec interoperabilního objektového odkazu (IOR) jakožto parametr. Tento řetězec IOR se skládá z posloupnosti znaků, která jednoznačně určuje řídící modul a umožňuje rozhraní, aby jej mohl prohlížet prostřednictvím funkce ORB.string\_to\object (ior) architektury CORBA. Tato funkce vrací odkaz, který je možno použít za účelem získání nějakého objektu JAVA řídící třídy (Management). Jakmile bude tento odkaz získán, je možno pracovat s daným řídícím objektem, jako by se jednalo o jakýkoliv jiný lokální objekt.
7
Aktuální databázový modul je založen na kombinaci databázového řídícího systému a specializovaných rutin pro práci se soubory. Tyto specializované rutiny jsou implementovány za účelem optimálního uložení pomocných dat modelu. Taková data zahrnují cestovní výlohy, jak jsou uváděny simulátorem v rámci každé iterace algoritmu DTA. Avšak jakmile je daný algoritmus kompletně proveden, převádějí se nákladová data do databáze strukturovaného dotazového jazyka (SQL), a to jak v rozdělené, tak filtrované uskupené formě, aby bylo možno podporovat unifikovaný reportingový model. K původním předběžným binárním datům je stále ještě možno získat přístup přes knihovní funkce CORBA a C/C++. K danému databázovému modelu je možno přistupovat přes knihovny CORBA, C/C++, knihovny otevřené databázové připojitelnosti (ODBC) nebo přes knihovny databázové připojitelnosti Java (JDBC). Vzhledem k tomu, že databázový modul podporuje rozhraní ODBC, je možno použít pro manipulaci s daty architektury VISTA široce dostupné nástroje, jako jsou Microsoft Access. Konečně je třeba říci, že prostřednictvím realizace standardního databázového protokolu je hlavní datový řídící nástroj slučitelný s jinými splňujícími databázovými systémy, jako je ORACLE 8i, nebo je možno jej snadno změnit na tyto systémy. Typickou obavou při práci s unifikovanými dopravními systémy zahrnujícími nástroje GIS je prezentace geografických informací. V této oblasti byl vykonán velký kus práce, jedná se například o lineární referenční systém (NHCRP 20-27, 1997). Předkládaná práce se nepokouší podrobně rozebírat toto specifické pole působnosti, ani nepopisuje žádný systém, který by závisel na nějaké reprezentační metodice. Namísto toho je možno provádět údržbu reprezentací vnitřních dat, které jsou nezávislé na specifických standardech, a to použitím objektově orientované povahy daného rámce. To je možno zajistit prostřednictvím uzavření dat uvnitř databáze a poskytováním přístupu pouze prostřednictvím zástupných datových hodnot. Další obavou je slévání dat a archivování dopravních dat získávaných v reálném čase ze snímacích zařízení, které by mělo být prováděno tak, aby bylo možno daná data používat pro inženýrské a plánovací aplikace. Například data získaná pomocí čidel (snímačů) by měla být k dispozici: • ve formátu 6-s provozovateli dálnice, který může vyvolávat řídící strategie v reálném čase; • v "procesovém formátu 6-s" jako jízdní doby na dálnici pro provozovatele dálnice, který může vyslat nějakou radu řidičům kamionů (nebo v konečné řadě též cestující veřejnosti); • v souhrnném formátu 15-min by tato data měla být k dispozici oblastnímu inženýrovi, který navrhuje plány na zlepšení dopravy v rámci nadcházejících stavebních plánů; • v souhrnném průměrném ročním formátu denní dopravy (AADT) by data měla být k dispozici nějakému plánovači v oblasti MPO, který vytváří systém pro řízení přetížených míst, nebo federální vládě pro monitorovací systém fungování dálnic. Oblast archivace dat je aktivní pole výzkumu v oblasti Computer Science. Bylo vykonáno jen málo práce v oblasti zabudování těchto přístupů do současného rámce, ale v této oblasti existují potřeby dalšího rozvoje. Dalším příkladem zlepšené efektivity udržováním dat v jedné databázi je udržování nehodových dat a provádění bezpečnostní analýzy. V současné době jsou data o nehodách udržována různými jurisdikcemi a pracuje s nimi řada lidí, kteří jsou zaměstnáváni úřady pro kódování a čištění dat. Pokud se člověk chce dostat na data za rok 1999, musí ve většině států čekat alespoň rok, než budou tato data dána k dispozici (pokud vůbec). U navrhovaného systému bude mít příslušný úředník možnost přímého vstupu k datům přes internet a nějaké příruční zařízení (v nějakém formuláři na rozhraní, který bude suplovat papírové formuláře, které vyplňuje). Tato data budou okamžitě k dispozici všem agenturám s minimálním objemem dalšího zpracovávání. Přístupnost k datům v rámci jednotné databáze umožní
8
expertům z oblasti bezpečnosti provádět přesnou korelaci databáze do převládající infrastruktury, ať již se jedná o povětrnostní podmínky, dopravní situaci a řízení (v době nehody), a tento přístup bude umožňovat vývoj příslušných opatření včasným způsobem. Přítomnost značného množství dat sama o sobě nezaručuje užitečné informace pro potenciální uživatele. Navíc nejsou specifické informační požadavky často známy předem, když pracujete s rozsáhlými složitými systémy. Jedná se o specifické problémy, které vedly k motivaci SQL, ODBC a JDBC protokolů. Podporou všech těchto protokolů s kompletní dostupností sítě a internetu umožňuje databázový modul širokou řadu nástrojů pro úplný (nebo omezený z důvodů bezpečnosti) přístup k rámcovým datům. Tento řádně zavedený návrhový model umožňuje přímou realizaci komplexního dotazování a komplexní tvorby zpráv přes podporu JDBC z GIS. Typické charakteristiky, které jsou očekávány uživateli, mohou být snadno zabudovány do daného rámce jako jednoduché formuláře a tlačítka uvnitř GUI. Navíc platí, že tento návrh otevřené architektury zajišťuje, že pokud bude opomenuta požadovaná funkčnost, může uživatel získat požadované informace prostřednictvím nástrojů třetích stran, aniž by bylo třeba provádět změny v daném rámci. Kromě přínosů SQL/ODBC k požadavku užitečného informačního reportingu byly v praxi zaznamenány přínosy též se zřetelem na správu uživatelských datových množin. S datovými tabulkami je možno manipulovat a mohou být přesouvány za pomoci typických příkazů SQL (které je možno snadno automatizovat přes rozhraní GUI). Kromě funkčních prvků SQL mohou uživatelé manipulovat s pomocnými daty binárního modulu přes rozhraní prohlížeče Java s odkazy, které architektura CORBA vyvolává do řídícího modulu. Přístup k datům se může odehrávat za pomoci tří metod přes síť: CORBA, JDBC a ODBC. Pro přístup přes CORBA se uživatel musí nejprve přihlásit s nějakým akceptovaným účtem. Až poté je možno získat přístup k pomocným binárním datům. Přístup k této formě dat je možno snadno omezit podle toho, jak si budou přát správci serverů. Podpora JDBC a ODBC zahrnuje všechny typické bezpečnostní charakteristiky, které daleko přesahují rozsah tohoto stručného popisu, jako je například šifrování. Typický uživatelský účet SQL a bezpečnostní informace jsou vedeny jako uživatelská privilegia a vlastnictví dat. V důsledku distribuované povahy daného rámce, jedna metoda, která je k dispozici pro odstupňování funkční schopnosti systému, zahrnuje přidání pracovních stanic. Zatímco tento krok je zřejmě přínosem v případech, kdy více uživatelů provozuje různé algoritmy nebo když jeden uživatel provozuje více algoritmů, mnoho modelů může využívat přímé výhody z přídavné CPU přes průvodní paralelní charakteristiky. Další servery jsou rovněž možností pro řízení dat, neboť mnoho serverů SQL podporuje rozšiřování dat na jiné databáze splňující ODBC a též různé lokální vyrovnávací strategie. V dalším textu bude popsána struktura modelu, zatímco podrobnosti o realizaci distribuovaného systému jsou uvedeny v oddílu 5. 4. Struktura modelu Primární moduly, které jsou v současné době realizovány v rámci systému VISTA, zahrnují dopravní simulátor (RouteSim), tradiční (statické) plánovací modely, modely DTA, síťové směrovací algoritmy, optimalizační modely signálů (semafory), měření rampových funkcí a modely pro nehodové řízení. Interakce mezi modely jsou koordinovány centrálním řídícím modulem. Přestože každý z těchto modelů může mít různé požadavky na typ dat a strukturu dat, je formát pro tato data udržován v jednotné podobě. Způsob, jakým moduly systému VISTA interagují, je znázorněn na obrázku 1. Každá interakce je specifikována jako buď synchronní nebo asynchronní vyvolávání.
9
4.1 Řídící modul (Management Module) Řídící modul je centrální komponentou rámce systému VISTA a je to jeden z těch modulů, s nimiž uživatelské rozhraní přímo komunikuje. Tento modul běží spojitě na daném serveru, pracuje s příchozími dotazy pro dálkové moduly rozhraní a provádí algoritmové moduly. Vzdálený objekt architektury CORBA může být popsán pomocí svého souboru IDL (Řídící skupina objektů, 1995). Jak je projednáváno v oddílu 3, platí, že když bude řídící modul běžet poprvé, vytvoří soubor HTML, který obsahuje řetězec IOR jako nějaký HTML parametr. Tento řetězec provádí jedinečnou identifikaci řídícího modulu jakožto objekt CORBA. Díky znalosti tohoto řetězce má každý objekt podporovaný architekturou CORBA, který je umístěn na internetu, schopnost prohlížení a komunikace s řídícím objektem. Alternativně platí, že vzdálený modul by mohl kontaktovat různé systémové moduly přístupem k názvoslovné službě CORBA, která je k dispozici na centrálním serveru. Když řídící modul obdrží vzdálený požadavek na provedení nějakého algoritmu, provádí to různými prostředky. Nejjednodušší metodou je použití funkce systému ANSI ( ) pro provedení nějakého samostatného programu. Vstupní parametry jsou specifikovány jako argumenty příkazové řádky a výsledný výstup je načten z dočasného souboru, pak je vrácen na objekt rozhraní provádějící dané vyvolání. Tato metoda je nejlepší pro relativně malé algoritmy, které potřebují jen malý objem výpočtového času a manipulace s daty. Pro větší a komplexnější systémy, jako je DTA, daný algoritmus vypadá jako odlišný modul architektury CORBA, který obsahuje své vlastní dálkové metody. Pro tyto případy jsou dané dálkové metody specifikovány jako asynchronní nebo jednocestné (které jsou interpretovány jako asynchronní v rámci používaných implementací ORB). Pro velmi složité systémy, kde je distribuce jednou možností, tato volba rovněž umožňuje další distribuci v rámci daného algoritmu za použití rámcových služeb. 4.2 RouteSim RouteSim je simulátor středního rozsahu založený na rozšíření modelu pro přenos buněk (Daganzo, 1994) zavedený Ziliaskoupoulosem a Leem (1997). RouteSim je jedním ze základních modulů, neboť se používá pro simulaci, DTA a vyhodnocování. Hlavními přednostmi nad základním modelem pro přenos buněk jsou: (i) koncepce buněk s nastavitelnou velikostí, která zlepšuje flexibilitu, přesnost a výpočetní požadavky modelu, a (ii) modelový přístup pro reprezentaci signalizovaných (semafory) křižovatek. Základní model pro přenos buněk spolu s dalšími prvky vedl k vytvoření modelu, který je schopen simulovat integrované sítě dálnic/pozemních komunikací s měnícím se stupněm detailu. RouteSim považuje za své vstupy geometrii sítě a data o toku na cestě. Data o toku na cestě mohou být vygenerována z časově závislých matic nebo z matic typu statický počátek destinace nebo mohou být zadávána přímo uživatelem. RouteSim přiřazuje každé vygenerované vozidlo nějaké cestě, podobně jako v případě modelu DYNASMART, který byl zaveden Mahmassanim a kol. (1993). Výhodou RouteSimu je, že je možno provést seřízení simulačního kroku a reprezentačního detailu na geometrii dané sítě. Dlouhé dálniční segmenty, které není třeba modelovat podrobně, jsou simulovány jako souhrnné dlouhé buňky a jejich stav je aktualizován s nízkou četností - například dvoumílový dálniční segment bez nájezdů a sjezdů by mohl být modelován jako jediná buňka a jeho aktualizace by mohla probíhat každé dvě minuty. Na druhé straně, v blízkosti křižovatek nebo problematických bodů, kde vytváření kolon, prostoročasová dynamika dopravy a signalizační fáze (semafory)
10
potřebují podrobné zachycení, je možno zajistit, aby simulační krok byl až 2 sekundy. Simulační kroky tohoto rozsahu umožňují podrobnou reprezentaci signalizovaných křižovatek (se semafory). To znamená strategie pro řízení semaforů, fázování, spouštěcí/ztrátové časy a chování v oblasti akceptace mezer. Poznamenejme, že zatímco podrobná data (např. geometrie, časovací plány, odbočovací pohyby) jsou požadována pro přesnou simulaci sítě se semaforově řízenými křižovatkami, RouteSim bude běžet i tehdy, když nebudou žádná taková data k dispozici s tím, že dojde k převzetí geometrie, řízení a dopravních dat a uživatel bude příslušným způsobem vyzván. 4.3 Plánovací modely Došlo k implementaci algoritmů pro optimalizaci systému a rovnovážné statické přiřazení uživatelů a tyto algoritmy je možno vyvolat přes systém VISTA. Tyto algoritmy jsou deterministickými přístupy založenými na Frank-Wolfeově metodě konvexních kombinací (Sheffi, 1985); v současné době probíhá vývoj stochastického uživatelského rovnovážného modelu za použití párovaného kombinatorického logit modelu (Gliebe a kol., 1995). Tabulky s nároky jsou součástí vstupních dat, neboť v současné době nejsou realizována žádná generování cesty, distribuční moduly a moduly pro rozdělení podle druhů dopravy. Systém VISTA však poskytuje vhodný rámec pro zabudování takových modelů a též pro jejich používání ve spojení s modely DTA. Kromě toho jsou v současné době implementovány moduly pro analýzu dálničních kapacit, takže úroveň dopravy pro křižovatky a úseky komunikací je možno počítat pro rovnovážné toky. Výpočtové postupy jsou prováděny podle návrhů z Highway Capacity Manual. Bylo by možné tvořit rozhraní se současným softwarem, jako je HCS. 4.4 Modely pro řízení signálů (semaforů) Plány pro časové řízení signálů (semaforů) je možno vypočítat pro samostatné křižovatky na základě jednoduchých funkcí prodlevy a kompenzací pro křižovatky podél nějaké dopravní tepny (McShane a Roess, 1990). Modely pro optimalizaci semaforů v rámci celé sítě jsou v současné době právě vyvíjeny, přestože jakékoliv z již stávajících modelů (např. STRANSYT) by mohly snadno tvořit rozhranní. Bylo též vyvinuto uživatelsky přívětivé grafické rozhraní pro zobrazování (nebo úpravu) časových plánů pro semafory na křižovatkách. 4.5 Dynamické dopravní přiřazení 1. 2.
3.
V rámci systému VISTA byly implementovány různé modely DTA: Verze DTA simulačně orientované uživatelské rovnováhy (UE) založená na čase odjezdu a pevném čase příjezdu provádí přístup za použití RouteSim pro šíření dopravy a řešení kapacitních omezení (Ziliaskopoulos a Rao, 1998). Upravená verze DYNASMART-X (Mahmassani a kol., 1992), která je schopna modelovat násobné uživatelské třídy včetně uživatelské rovnováhy a systémově optimálních (SO) uživatelů. Tato verze je založena pouze na časech odjezdu a používá DYNASMART pro simulaci dopravy (Hawas a kol., 1997). Dva analytické modely DTA: přístup založený na času odjezdu a času příjezdu; oba přístupy jsou založeny na lineárním programování a jsou řešeny pomocí CPLEX (Ziliaskopoulos, 2000).
11
4.
Kombinovaný analytický model založený na času odjezdu a příjezdu, který je rovněž řešen za použití CPLEX (Yue a kol., 1999). Všechny tyto modely DTA používají stejné datové vstupy v oblasti geometrie, řízení a požadavků; je třeba, aby tabulky s požadavky byly založeny na času příjezdu a/nebo odjezdu, v závislosti na vyvolávaném modelu. Modely DTA založené na simulaci provádějí přístup k jednomu z modulů simulátoru (RouteSim nebo DYNASMART), k časově závislým modulům s minimalizací času a nákladů cesty a rovněž k různým dalším modulům. Vzhledem k tomu, že tyto systémy pracují iterativním způsobem, stává se velmi důležitým faktorem výpočtový čas dílčích modulů. Modely DTA jsou modely s největší spotřebou času, ale mnoho z těchto modulů má operace, které je možno provádět paralelním způsobem. Jako příklad uveďme, že časově závislé algoritmy nejkratší cesty mají schopnost být distribuovány přes více procesorů (Ziliaskopoulos a kol., 1998). Navíc platí, že všechny moduly vztažené ke směrování různých tříd v DYNASMART-X mohou být provozovány na samostatných procesorech. Vzhledem k tomu, že systém VISTA je založen na specifikaci CORBA, může pracovat s komunikací a vyvoláváním těchto modulů na samostatných procesorech. Určité informace o provádění výpočtů pro upravený systém DYNASMART-X jsou zahrnuty v tabulce 2. Tato data jsou pro jednu iteraci algoritmu DTA na síti se 444 spoji, s požadavkem 8000 vozidel během doby 50 minut. Daný požadavek byl rozdělen rovnoměrným způsobem do dvou tříd tvořených chováním UE a SO. V rámci tohoto systému DTA existují tři moduly: UE skládající se v převážné míře z časově závislého algoritmu nejkratší cesty (TDSP), SO skládající se v převážné míře z časově závislého algoritmu nejmenších nákladů (TDLC) a modul simulátoru skládající se z DYNASMART. Jak bylo uvedeno výše, je možno tyto dvě třídy provádět paralelním způsobem. Z tohoto důvodu je čas vyvstávající v případě UE modulu v podstatě zanedbatelný a celkový čas se skládá pouze z modulů simulátoru a SO. Tato zkouška byla provedena na duálním procesoru UltraSparc II (167 MHz).
4.6 Směrovací algoritmy Různé směrovací algoritmy je možno vyvolávat přes systém VISTA: statické a dynamické algoritmy nejkratších cest založené na čase nebo nákladech na daných spojích. Verze dynamických algoritmů, které souběžně optimalizují trasu a dobu odjezdu, jsou v současné době rovněž vyvíjeny. Tyto algoritmy jsou realizovány v C++. Podrobnosti o realizaci je možno nalézt v literatuře (Ziliaskopoulos a Mahmassani, 1994). Směrovací algoritmy vyžadují za vstup doby a/nebo náklady cesty na daném spoji, typologii sítě a mají schopnost pracovat s prodlevami při pohybech přes křižovatky. Výstupem je v typickém případě strom, jehož kořeny spočívají ve výchozím bodě nebo destinaci. Tabulka 2 Čas CPU u DTA na jednu iteraci Modul UE (algoritmus TDSP) SO (algoritmus TDLC) Simulátor (DYNASMART)
Čas CPU (s) 72 177 265
12
5. Realizace distribuovaných systémů Klientský modul má přístup ke dvěma primárním rámcovým zdrojům: řídící modul a databázový modul. Přestože primární návrhovou zásadou pro rámec je centralizace všech dat v dané databázi, je možno určitá dočasná data efektivním způsobem předávat přímo mezi moduly přes zpracování za použití dálkových metod. Vzhledem k tomu, že řídící modul musí koordinovat provádění četných algoritmových modulů a manipulovat s určitými datovými prvky, je realizován robustní protokol CORBA, jak je stanoveno OMG. OMG neprovádí vývoj produktů; zaměřuje se na vytváření specifikací, které mohou být realizovány prodejci. Pro tento návrh se používá balík mezijazykové unifikace (ILU) (Janssen a kol., 1998), který byl původně vyvinut Xeroxem. Tento balík byl vyvinut nezávisle na architektuře CORBA, ale přesouval se konzistentním způsobem ke standardům OMG. Je bezplatně k dispozici ve formě zdrojového kódu a má podporu pro C, C++, Java, Modula-2, Python a FORTRAN pomocí zabalení s C kódem. Vzhledem k tomu, že ILU je k dispozici ve formě zdrojového kódu, je možno provádět jeho kompilaci a použití na široké řadě platforem včetně Windows NT, Solaris, SGI, HP a Linux. Přestože ILU má určitou podporu pro Java, chybí silná podpora pro Applets. Avšak vzhledem k tomu, že ILU sleduje standardy OMG, jsou Java 1.2 ORB stejně jako mnoho dalších prostředí plně kompatibilní s moduly, které jsou psány za použití ILU. 5.1 Přínosy architektury CORBA Základem pro zavedený rámec je architektura CORBA, která je součástí architektury řízení objektu (OMA) (Soley, 1993). Cílem architektury OMA je usnadnit konstrukci systémů od objektů distribuovaných přes vyšší počet počítačů. Některé z přínosů vytvářených v důsledku používání tohoto systému zahrnují: • Objektovou orientaci. CORBA je vnitřně objektově orientovaný systém. Z tohoto důvodu je každá komponenta uznávána za samostatný objekt s nějakým vnitřním stavem. To podporuje opětné používání kódů, rámcové struktury a rozšíření. • Distribuované schopnosti. Architektura CORBA obsahuje vnitřní schopnosti pro synchronní i asynchronní komunikaci mezi objekty. To umožňuje, aby bylo rozhraní prováděno dálkově z realizace algoritmů a aby se používalo více procesorů pro provádění modulů algoritmů, pokud to bude třeba. • Jazyk pro definici rozhraní OMG (IDL). Jedná se o základní psací jazyk používaný pro specifikaci rozhraní pro každý modul. Díky tomu potřebuje každý modul pouze znát rozhraní jiných modulů, aby s nimi mohl komunikovat. To podstatně odděluje publikované rozhraní nějakého objektu od jeho implementace. • Broker objektových požadavků (ORB). Tento prostředek pracuje s hlavními otázkami síťové komunikace a umožňuje vyvolávání vzdálených objektů, jako by se jednalo o objekty lokální. Navíc ORB pracuje s přenosem dat (seřazování dat), prováděním implementací objektů (aktivace objektů) a nahlašováním výjimek k vyvolávajícímu objektu. Prostřednictvím kombinace architektury CORBA a otevřené databázové struktury bude daný rámec umožňovat přidání a úpravu modulů přímým způsobem. Každý modul v rámci, který může fungovat jako server, je reprezentován přes rozhraní IDL. Abstrakcí spojení mezi rozhraním a implementací může modul jednoduše publikovat své rozhraní v daném rámci a tedy veškeré další komponenty, včetně přídavných zařízení třetích stran, mohou přistupovat k
13
veřejným funkcím a datům modelů. To umožňuje interakci soukromých i otevřených modelů v daném rámci a snižuje potřebu specifických programovacích detailů. 5.2 Standard IDL IDL je univerzálně aplikovatelná notace pro rozhraní aplikačních programů. Mezinárodní organizace pro standardizaci (ISO) provedla extrakci sekce IDL z architektury CORBA, aby byla navržena jako mezinárodní norma (ISO DIS 14750). V podstatě je IDL jednoduchým psacím jazykem, který umožňuje programátorům zadefinovat neprůhledné hranice mezi klientským kódem a implementací objektu. Zahrnuje názvy rámcových modulů a prototypy metod pro každý z těchto modulů. Jakmile bude proveden zápis nějakého souboru IDL, bude použit syntaktický analyzátor nebo kvadrantový systém pro zpracování daného souboru IDL a vytvoření programového zdrojového kódu pro nějaký specifický jazyk. Vzhledem k tomu, že IDL závisí na příslušném jazyku, musí mít každý programovací jazyk samostatný rozhodovací program. Výsledný kód je uváděn jako skeletový kód a je následně kompilován s uživatelsky psaným implementačním kódem za účelem vytvoření příslušného programu CORBA. V rámci systému VISTA se požadují kvadrantové rozhodovací systémy pro prostředí C, C++ a Java, neboť všechny tyto tři jazyky se používají pro různé moduly. IDL rovněž podporuje definici nových datových typů způsobem obdobným k C. Definováním nějakého nového datového typu v souboru IDL bude každý jazyk přítomný v daném rámci rozumět tomuto datovému typu a bude schopen jej předávat a vyhledávat. Standard IDL podporuje též specifikaci atributů a výjimek. GIS udržuje spojení pro dva primární externí protokoly: jedná se o systém JDBC a CORBA. Ze systému CORBA je poskytnut přístup pro interakce komplexních modulů, zatímco protokol JDBC poskytuje funkce pro práci s velkými datovými strukturami. Samotný GIS je navržen pomocí Swingovy architektury model-pohled-řídící jednotka (MVC) podle specifikace JDK 1.2 Sun Microsystems. GIS-GUI se rozděluje do pěti hlavních skupin tříd. Pohled. Udržuje specifická obrazovková souřadnicová data a kreslící funkce pro aktualizaci vlastní zobrazitelné obrazovky, jako je například jednoduché dotazování a najíždění transfokátorem. Interaguje s třídami typu data za účelem získání kreslitelných dat a složitých geografických dotazů, s třídami typu uživatel pro uživatelsky specifické informace, jako jsou například preference a povolení, a s třídami typu modul pro výstup aplikací a příslušné funkce. Data. Pracuje s připojením k protokolu JDBC a uzavírá všechna síťová data v rámci GIS. Má přístup ke složitému dotazování SQL na vzdálené databázi prostřednictvím připojení JDBC. Vrací data ve formě kartézských souřadnic do skupiny pohled tříd a provádí dotazy založené na vzdálené databázi nebo ze své vlastní vnitřní reprezentace v závislosti na povaze daného dotazu. Uživatel. Udržuje uživatelsky specifické informace, jako jsou preference, povolení a prováděcí protokoly. Má omezenou kapacitu pro komunikaci s řídícím modulem CORBA se zřetelem na uživatelsky specifické informace. Modul. Koordinuje řízení a interakci s dálkovými aplikacemi přes řídící modul CORBA. Uzavírá všechny interakce s moduly v rámci GIS. Reporting. Pracuje s reprezentací negrafického reportingu v rámci GIS. Interaguje převážně s třídami typu data pro datové dotazy a třídami typu uživatel pro preference, atd. Klíčová sada struktur, "kreslící třídy" udržují vnitřní reprezentaci pro každý datový subjekt, jako je například vozidlo, signál (semafor), uzel, spojení, atd. Navíc jsou jednotlivá kreslící pravidla delegována na vlastní třídy subjektu, které mohou být používány jako objekty formátu Java. Například třída spojení odpovídá za vyžádání nezbytných informací pro specifické použití ze vzdáleného serveru SQL, konverze (je-li to třeba) těchto informací do 14
jejich vnitřní reprezentace a předání žádané kreslící schopnosti do příslušného pohledu, pokud se to požaduje. Výše uvedená struktura je zamýšlena pro abstrahování a izolování těch otázek, které nejpravděpodobněji reprezentují problémově specifické otázky. Síťová data jsou například uzavřena v rámci skupiny data GIS tříd a též v samotné databázi SQL. Bylo shledáno, že tato struktura je nezbytná, neboť geografické reprezentace stejně jako řada různých aplikací požadují, aby síťová data byla reprezentována značně rozdílným způsobem. Navíc platí, že s četnými aplikacemi je možno pracovat jednotným způsobem z prostředí GIS tím, že dojde k pozdržení implementačně specifických požadavků na řídící modul a dále. 5.3 Specializované datové typy Když je třeba vracet specifická data z nějakého vzdáleného modulu, je jednou z možných metod definice specializovaného datového typu v daném rámci. To umožňuje návrat veškerých potřebných dat pomocí vzdálených procedur za použití typické schopnosti návratových funkcí. Jako příklad uveďme, že funkce dopravního simulátoru RouteSim vrací takové informace, jako je celková systémová jízdní doba a počet uzlů, spojů, buněk a vozidel. Pro vytvoření tohoto specializovaného datového typu se nejprve zadá v rámcovém souboru IDL toto: struct s_RSimData { double ttime; int nodes,links,cell,vehicles; }; typedef s\_RSimData RSimData; Další specializované datové typy zahrnují takové věci, jako jsou souhrnná data ze statického přiřazení a modulu DTA, administrativní hlášky a varování, historii provádění modulu a informace o cestě z algoritmů pro síťové směrování. Alternativní metodou by bylo použití centrální databáze SQL. Tato databáze nabízí větší robustnost, zatímco přímé převody CORBA v typických případech poskytují významně rychlejší komunikaci a prokázaly by se jako velmi užitečné z hlediska požadavků reálného času. 5.4 Přenos dat CORBA Jak již bylo uvedeno výše, umožňuje standard CORBA vyvolávání vzdálených objektů jako by se jednalo o typické lokální objekty. To umožňuje přímý prostředek pro datovou komunikaci mezi moduly. Typické dálkové provádění a vyhledávání dat pro synchronní metodu by vypadalo takto: try { RSimData rsimdata = Management.RunRouteSim(start, stop, step); } catch(Exception e) { … } V tomto příkladu se spouští dopravní simulátor RouteSim se specifikovanými časy začátku, konce a kroku. Metoda RunRouteSim( ) nemá specifikaci ONEWAY v souboru IDL, což znamená, že se bude jednat o synchronní funkci. Z tohoto důvodu bude rozhraní čekat, dokud nebude simulátor kompletně proveden předtím, než se bude pokračovat v provozu. Jakmile bude kompletně proveden, vrátí vzdálené vyvolání proměnnou typu RSimData. Tento typ byl zadefinován ze souboru IDL, takže všechny moduly architektury CORBA v rámci VISTA budou rozumět tomuto datovému typu. Jedná se o nejjednodušší druh datové komunikace: data jsou předávána vzdáleným modulům jako parametry ve vzdálených voláních procedur a data se vrací zpět ke klientovi jako specializovaný datový typ.
15
6. Problémy a očekávané přínosy Zdá se, že neexistují žádné větší technické problémy pro realizaci a používání navrženého rámce, je zde však několik institucionálních otázek. Daný systém vyžaduje úzkou spolupráci mezi mnoha úřady a dalšími subjekty, které tradičně neinteragují. Systém rovněž předpokládá, že určité organizace upustí od řízení dat a budou požádány o změnu určitých praktik. Jsme si vědomi toho, že se může jednat o podstatnou překážku. Avšak očekávané přínosy jsou tak zřejmé a podstatné, že s tím, jak tyto techniky budou rutinně akceptovány a používány podniky, bude růst tlak na veřejné úřady a orgány a konečným výsledkem bude skutečnost, že dojde k přijetí nějaké verze navrhovaného systému. V dalším textu jsou stručně uvedeny a pojednány některé očekávané přínosy z používání navrženého systému: Konzistence dat. Daný systém zajišťuje použití stejných dat všemi účastnickými úřady a odborníky. Efektivita. Dochází k eliminaci duplikace dat a činností zaměřených na shromažďování redundantních dat. Úspory z rozsahu. Bylo by možno shromažďovat zdroje různými úřady a orgány za účelem získání dalších dat nebo funkčních prvků, z nichž budou mít prospěch všichni. Kromě toho je možno snadno zjistit hodnotu shromažďování dalších dat nebo rozvíjení dalšího modelu; toto zjištění může pomoci zajistit rovnost pro všechny zúčastňující se subjekty. Nové shromažďování dat a další přístupy. Přijetí této nové techniky může fungovat jako katalyzátor pro nové přístupy, jež budou zvažovány různými úřady a orgány. Jako příklad uveďme skutečnost, že daný systém je přístupný přes internet, což jej činí otevřeným vůči široké veřejnosti. Cestující veřejnost by jej mohla používat za účelem získání dopravních a tranzitních informací, a to buď před cestou nebo během cesty. Současně s tím by však daný systém mohl obsahovat data od těchto cestujících, jako jsou výchozí bod - destinace, doba cesty a případně další druhy informací, které jsou tradičně získávány cestou průzkumů. Dostupnost dat. Kdykoliv může kdokoliv (oprávněný) kdekoliv mít přístup do systému a k jeho funkčním prvkům. Zlepšení produktivity. Systém umožní odborníkům v oblasti dopravy lépe vykonávat svou práci tím, že budou oproštěni od zdlouhavých prací v oblasti manipulace s daty a konverze dat, a rovněž již umožní lepší interakci s jinými odborníky, neboť budou používat konzistentní data a modely. Kromě toho skutečnost, že budou všechny nástroje a data po ruce na jakémkoliv místě a v kteroukoliv dobu, jim pomůže při snadném provádění prohlížení a prezentace výsledků. Informace o jakékoliv komponentě dopravního systému bude dostupná online způsobem, což umožní, aby časově citlivá rozhodnutí byla prováděna v mnohem kratším časovém rámci. Implementace modelů bude prováděna spojitě a včas. Vytvoření odborného společenství. Komunikace mezi uživateli by mohla zajistit vytvoření virtuálních odborných komunit. Sekundární data, zprávy, analýza a akce mohou být k dispozici všem odpovědným stranám přes databázi. To umožní nejen výměnu informací, ale též i výměnu znalostí. Pokud má nějaký oblastní inženýr problémy při provádění nějaké úlohy, může mít přístup k odborným zkušenostem v jiné oblasti nebo ve státním úřadu pouhým kliknutím na vhodné tlačítko. Vývoj nových produktů. Otevřená architektura systému umožní vývojovým pracovníkům provádět potvrzování a zkoušky nových modelů založených na stejných datech, která používají všichni ostatní odborníci v dopravě, což zvýší kredit jejich práce a povede ke snížení času potřebného pro vstup na trh. Navíc platí, že navrhovaný systém možní novým
16
uživatelům vyvíjet dopravní software založený na nějaké společné platformě, což povede ke snížení nákladů na vývoj a realizaci softwaru. Transparentnost a odpovědnost. Za použití elektronických podpisů budou příslušné subjekty vědět, kdo, kde a kdy a za jakým účelem podpis provedl.
17
7. Závěry Tento materiál představil integrovaný rámec pro dopravní analýzu, řídící a optimalizační algoritmy, které spojují několik dopravních nástrojů tak, že sdílejí společné datové specifikace a uživatelské rozhraní. Hlavní oblastí zaměření jsou spíše interakce mezi daty a modely, které jsou charakteristické pro dopravní systémy, a nikoliv specifické otázky geografické reprezentace. Dopravní simulátor středního rozsahu (RouteSim), statické dopravní přiřazení, DTA, řízení a směrovací algoritmy byly v daném rámci realizovány a zabudovány. Rámec je založen na specifikaci brokerské architektury požadavků společných objektů (common object request broker architecture - CORBA), která umožňuje, aby moduly byly psány v samostatných programovacích jazycích a aby byly provozovány na různých strojích na síti. Geografický informační systém (GIS) založený na jazyku Java se používá jako uživatelské rozhraní se schopnostmi najíždění transfokátorem, panorámování a dotazů a může být prováděn na světovém webu. GIS běží na uživatelském počítači a předkládá dálkovým způsobem požadavky na provádění na server. V materiálu byly projednávány otázky spojené s návrhem rámce CORBA, integrací dat a modelů, vývojem algoritmů a síťovou komunikací.
Literatura Chambers, J.T., 1999. Virtual close-virtual manufacturing (Virtuální a téměř virtuální výroba). Fortune 139 (10), 104. Daganzo, C.F., 1994. The cell transmission model: a simple dynamic representation of highway traffic consistent with the hydrodynamic theory (Model přenosu buněk: jednoduchá dynamická reprezentace dálniční dopravy konzistentní s hydrodynamickou teorií). Transportation Research B 28 (4), 269-287. Gliebe, J., Ziliaskopoulos, A.K., Koppelman, F., 1999. Stochastic network loading using a paired combinatorial logit model (Natahování stochastických sítí za použití párovaného kombinatorického logit modelu). Transportation Research B (následující). Hawas, Y., Mahmassani, H.S., Peeta, S., Taylor, R., Ziliaskopoulos, A.K., Chang. G., Peeta, S., 1997. Development of DYNASMART-X software for real-time dynamic traffic assignment (Vývoj softwaru DYNASMART-X pro dynamické dopravní přiřazení v reálném čase). Technical Report ST0067-85-TASK E, Center for Transportation Research, The University of Texas at Austin. Healey, R.G., 1991. Database management systems, In: Maguire, D.J., Goodchild, M.F., Rhind, D.W. (Eds.), Geographic Information Systems: Principles and Applications, vol. 1. (Geografické informační systémy: zásady a aplikace, svazek 1) Longman Scientific and Technical, London, str. 251-267.
Zdroj: Transportation Research Part C 8 (2000) 427-444 Překlad: Petr Zavadil www.elsevier.com/locate/trc
18
