vienna-spirit: situationsbezogene, integrierte reiseunterstützung für intermodale reisen

K. Rehrl, H. Rieser, S. Bruntsch 83

Vienna-SPIRIT: Situationsbezogene, integrierteReiseunterstützung für intermodale Reisen

Karl Rehrl1, Harald Rieser1, Stefan Bruntsch2

1Salzburg Research Forschungsgesellschaft mbH {krehrl | hrieser}@salzburgresearch.at

2ARC Seibersdorf research GmbH Bereich Intelligente Infrastrukturen und Weltraumanwendungen

[email protected]

ZUSAMMENFASSUNG

Das österreichische Forschungsprojekt Vienna-SPIRIT hat zum Ziel, ein integriertes Reiseinformationssystem für intermodale Reisen zu konzipieren und pilothaft umzuset-zen, wobei bestehende intermodale Fahrplanauskunftssysteme sowie Kfz-Navigationssysteme in ein System mit einer durchgängigen, situationsbezogenen Pre-trip- und On-trip-Reiseunterstützung für intermodale Reisen integriert werden sollen. Der folgende Beitrag beschreibt ein Modell für diese situationsbezogene Reiseunter-stützung, die daraus abgeleitete Systemarchitektur und deren Umsetzung im Vienna-SPIRIT-Pilotsystem.

EINLEITUNG

Reiseinformations- bzw. Auskunftssysteme für den öffentlichen Verkehr (ÖV) sowie Routenplanungs- und Navigationssysteme für den Motorisier-ten Individualverkehr (MIV) entwickelten sich bisher weitgehend unab-hängig voneinander und stellen nicht vernetzbare bzw. nicht interoperable Insellösungen dar. Fahrplanauskunftssysteme wie die Elektronische Fahr-planauskunft (EFA) oder HAFAS-Intermodal haben sich mittlerweile zwar zu intermodalen „Tür-zu-Tür“-Routenplanungssystemen entwickelt, aller-dings muss gänzlich auf Navigation und andere Orientierungshilfen wäh-rend der Reise verzichtet werden. Routenplanung, Navigation und Echtzeit-Verkehrsinformationen im Individualverkehr berücksichtigen Intermodali-tät überhaupt nicht. Des Weiteren sind auch die geografischen Informatio-nen, die die Grundlage für Routenplanung als auch Navigation bilden, nicht allumfassend integriert. Dazu fehlt die Integration der Verkehrsnetze aller Transportmodi in ein intermodales geografisches Referenzsystem. Auf-grund dieser separierten Informationsinseln konnte bisher noch keine integ-

84 K. Rehrl, H. Rieser, S. Bruntsch

rierte und durchgängige Reiseunterstützung für intermodale Reisen zur Verfügung gestellt werden.

STATE-OF-THE-ART

Der Bereich der intermodalen Reiseinformationssysteme ist mittlerweile relativ gut erforscht, einige Entwicklungen befinden sich bereits im kom-merziellen Betrieb. Im EU-Forschungsprojekt EU-SPIRIT2 wurden offene Schnittstellen sowie harmonisierte Metadaten entwickelt, um die Planung von durchgängigen ÖV-Verbindungen von „Tür-zu-Tür“ zwischen hetero-genen Auskunftssystemen in europäischen Regionen und Städten zu er-möglichen. Im Projekt ISCOM3 wurde die intermodale elektronische Fahr-planauskunft (EFA) konzipiert, welche die Routenplanung im ÖV um die Modellierung und Einbeziehung von Zu- bzw. Abgangswegen für Halte-stellen erweitert. Durch die Georeferenzierung von Haltestellen, Wegen und Linienführungen auf der Basis eines intermodalen digitalen Verkehrs-netzes konnten diese Wege in die Routenplanung miteinbezogen werden. Dieses System kommt seit einiger Zeit beispielsweise beim Verkehrsver-bund Ost-Region4 in der Region Wien zum Einsatz.

Projekte, die sich ebenfalls mit der Weiterentwicklung von intermodalen Reiseinformationsdiensten in verschiedenen deutschen Städten beschäfti-gen, sind Mobinet, Intermobil, Mobilist, Stadtinfoköln und Wayflow. Zu-sätzlich zur intermodalen Routenplanung werden in den meisten Projekten neben der Pre-trip-Planung zum Teil auch einfache Funktionen zur On-Trip-Unterstützung (SMS-/WAP-Abfrage) angeboten. Allerdings sind die Informationsdienste nicht integriert, daher kann nicht von einer durchgän-gigen Unterstützung gesprochen werden.

Im Projekt „Der Orientierte Mensch“5 liegt der Fokus auf der Personalisie-rung des Reiseinformationsdienstes. Geplante Routen im ÖV oder mit dem Auto (eine Kombination ist nicht möglich) können in einer Reisemappe abgelegt werden. Durch den Zugriff vom PDA aus kann diese Mappe als Reisebegleitung verwendet werden.

Smartkom Mobil (Häußler 2003) ist als System konzipiert, das Fußgänger- und Autonavigation ermöglicht. Der Fokus liegt dabei speziell auf ver-schiedenen Interaktionsmodalitäten für Karten-Navigation. Die integrierte Routenplanung bezieht sich nur auf Kfz- und Fußgängerrouten und inklu-

2 http://www.eu-spirit.com

3 http://www.iscom-ec.de

4 http://www.vor.at

5 http://www.der-orientierte-mensch.de/


diert das Auffinden von geeigneten Parkmöglichkeiten in der Nähe von Se-henswürdigkeiten.

BARRIEREN AUF INTERMODALEN REISEN

Während einer intermodalen Reise werden Reisende aufgrund der unter-schiedlichen Verkehrsmittel, zwischen denen gewechselt werden muss, mit komplexen Reisesituationen konfrontiert. Im Vergleich zu monomodalen Reisen führt diese zusätzliche Komplexität zu Barrieren, die Reisende oft davon abhalten, sich für eine intermodale Reise zu entscheiden bzw. eine begonnene monomodale Reise intermodal fortzusetzen. Zu diesen Barrie-ren zählen:

•Intermodale Reiseplanungssysteme decken hauptsächlich die Pre-trip-Planung ab, im Voraus geplante Reisen können nicht auf mobilen Endgerä-ten während der Reise abgerufen werden bzw. auf die Reise mitgenommen werden. Eine durchgängige On-trip-Unterstützung ist daher nicht möglich.

•Das Fortsetzen einer monomodalen Reise (z.B. Autoreisen) mit öffentli-chen Verkehrsmitteln wird unzureichend unterstützt. Bei Kfz-Navigationsgeräten fehlen Möglichkeiten zur Fahrplanabfrage im ÖV, zum Auffinden von möglichen Umstiegspunkten im Bereich der aktuellen Posi-tion, zum Abfragen von Parkplatzinformationen an möglichen Umstieg-spunkten, zu Informationen über Fahr- und Parkpreise sowie zu dynamischen Änderungen der geplanten monomodalen Route zu einer in-termodalen Route. Außerdem vermisst man ähnliche Navigations- bzw. Orientierungsunterstützung im ÖV wie auf Autorouten („Integrierte Ziel-führung“).

•Existierende, gewohnte Navigationsanwendungen können im ÖV nicht weiter verwendet werden. Dadurch wird die Komplexität zusätzlich erhöht, da Reisende mit weiteren, ungewohnten Informationssystemen konfrontiert werden. Zusätzlich müssen sich Reisende selbst um eine sinnvolle Integra-tion der Informationen bemühen.

•Bei existierenden mobilen intermodalen Informationssystemen handelt es sich weitgehend um Auskunftssysteme, bei denen die aktuelle Situation der Reisenden (wie z.B. die aktuelle Position, der gegenwärtige Transportmo-dus, Transportpräferenzen) nicht betrachtet wird. Dadurch ergeben sich un-zureichende bzw. z.T. unbrauchbare Reiseinformationen.

•Geografische Informationen für Routenplanung und Navigation werden heute von verschiedenen privaten und öffentlichen Anbietern bereitgestellt. In der Regel wird Kartenmaterial angeboten, das für die Navigation mit


dem Auto optimiert ist. Es fehlen meist das Fuß- und Radwegenetz sowie öffentliche Verkehrsnetze.

SITUATIONSBEZOGENE, ADAPTIVE REISEUNTERSTÜTZUNG

Im Folgenden soll das im Rahmen des Projektes Vienna-SPIRIT entwickel-te Modell vorgestellt werden. Es soll Lösungen aufzeigen, wie die zuvor genannten Barrieren mit Hilfe einer situationsbezogenen, adaptiven Reise-unterstützung verringert werden können. Ein zentraler Bestandteil dieses Modells ist eine brauchbare Definition einer intermodalen Reise inklusive den typischen Situationen mit denen intermodal Reisende konfrontiert wer-den und für die eine Unterstützung notwendig erscheint. Da die Bedeutun-gen des Wortes situationsbezogen in wissenschaftlichen Beiträgen immer häufiger werden (z.B. Reichenbacher 2003), soll es an dieser Stelle defi-niert werden. Unter situationsbezogen wird im Projekt Vienna-SPIRIT eine „Anpassung der Funktionalität des Reiseinformationssystems an den jewei-ligen Kontext in der sich intermodal Reisende befinden“ verstanden. Der im Informationssystem zu berücksichtigende Kontext ergibt sich aus ver-schiedenen Parametern die vor oder während der Reise festgelegt werden (s. Abb. 1).

Position

DerzeitigerTransport-

modus

Benutzerprofil

Reisezweck

Nächster, bevorzugterTransport-

modus

Zeit

Endgerät/Interaktion

Anpassungen bei•Routenplanung

•Reiseinformationen•Navigation

GeplanteReise

Abb. 1: Kontext-Parameter, die für Anpassungen im Informationssystem verwendet werden

Die in der jeweiligen Reisesituation relevanten Parameter werden im In-formationssystem zu Anpassungen genutzt. Die jeweils gültige Reisesitua-tion kann entweder automatisch aus dem Reiseverlauf erkannt werden (z.B.


Verlassen des Autos am P+R Parkplatz) oder sie muss von Reisenden ex-plizit bestimmt werden.

Bei der Modellierung von Reisesituationen muss zwischen der Pre-trip- und der On-trip-Phase unterschieden werden. Pre-trip umfasst die Reise-vorbereitung bzw. -planung vor Antritt der Reise, wobei intermodale Rei-sen mit allen Verkehrsmitteln möglich sind. Für die On-trip-Phase wird in Vienna-SPIRIT eine „aktive Reise“ vorausgesetzt, das heißt, alle On-trip-Reisesituationen stehen immer in direktem Bezug zu dieser pre-trip-geplanten Reise.

Pre-trip On-trip

FahrradFußwegMIV ÖVBedarfs

ÖV

Auto Motorrad

Reisevorberei

tung

Bus Bahn U-Bahn TaxiBedarfs

bus

Abb. 2: Reisesituationen (inkl. Umsteigesituationen) auf intermodalen Reisen

Reisesituationen auf intermodalen Reisen bestehen typischerweise aus ei-ner Kette von unterschiedlichen Transportmodi: MIV (Motorisierter Indi-vidualverkehr), ÖV (Öffentlicher Verkehr), Fußweg, Fahrrad, Bedarfs-ÖV (s. Abb. 2). Die Kette wird durch Wechsel der Transportmodi verbunden, die wichtigsten davon sind Umsteigesituationen wie MIV ÖV, ÖV ÖV, ÖV Bedarfs-ÖV. Um eine durchgängige Unterstützung zu schaffen, muss im Modell geklärt werden, welche Anpassungen des Informationssys-tems in den jeweiligen Situationen notwendig sind. Tab. 1 zeigt eine Über-sicht, welche Form der Unterstützung in den jeweiligen Situationen not-wendig bzw. sinnvoll ist.


Tab. 1: Unterstützungsmöglichkeiten bezogen auf die jeweilige Reisesi-tuation

pre-trip

Reisevor-bereitung MIV ÖV Bedarfs-ÖV Fußweg Fahrrad Umsteigen

Intermodale

Routenplanung/Fa

hrplanauskunft

(z.B. HAFAS, EFA,

EU-SPIRIT),

Autoroutenplanung

(z.B. MS

Autoroute, Map24)

Kfz-Navigation

(z.B. Siemens

VDO, Blaupunkt,

Bosch), PDA-

Navigation (z.B.

TomTom

Navigator, Navigon

Mobile Navigator),

Smartphone-

Navigation (z.B.

W ayfinder)

SMS-Abfrage,

W AP-Abfrage (z.B.

EFAwap, HAFAS-

W AP), PDA-

Abfrage (z.B.

EFApda),

Smartphone-

Fahrplan (z.B.

HAFAS

Smartphone)

Taxi-Ruf, AST-

/Rufbus-Service

Off-board

Navigation (z.B.

W ayfinder)

PDA-Navigation,

PDA-Informationen

Planung von

intermodalen

Routen, Anzeige

von

Alternativrouten,

Verwaltung von

persönlichen

Routen &

Voreinstellung im

Benutzerprofil

Planung einer

intermodalen

Route von der

aktuellen Position,

Anzeige von

intermodalen

Alternativrouten,

Vorschlag von ÖV-

Routen bei

Verkehrs-

behinderungen

Planung von

Alternativrouten

von der aktuellen

Position (andere

Verkehrsmittel,

späterer

Zeitpunkt),

Anschlusspla-nung

mit Bedarfs-ÖV

Finden von

Bedarfs-ÖV

Angeboten an der

aktuellen Position

Planung einer

intermodalen

Route von der

aktuellen Position

Planung einer

intermodalen

Route vom

aktuellen Punkt

Umsteigeweg,

Nächste

Verbindung zum

Ziel (Echtzeit)

On-board/Off-

board, GPS-

basiert,

Zielführung mit

Auto, Änderung

der Zielführung

zum

Umstiegspunkt

Detaillierte

Routeninformation

en, Verfolgen der

Route am

Endgerät,

Hinweise zum

Umsteigen,

Umsteigekarten

Verfolgen der

Route am

Endgerät, GPS-

basiert

On-board/Off-

board, GPS-

basiert, speziell

Fußwege,

alternative

Lokalisierung in

Städten,

Gebäuden

On-board/Off-

board, GPS

basiert, speziell

Radwege

Umsteigekarte,

Umsteigenavi-

gation (Indoor),

Information über

Orientierungs-

hilfen

Internet-PC,

Laptop, Settop-

Box, Info-Terminal

Kfz-Navigations-

system, PDA-

Navigation,

Sprachinterface

Smartphone, PDA,

(Sprachinterface)

Smartphone, PDA,

(Sprachinterface)

Smartphone, GSM-

Sprachinterface,

SMS, MMS Smartphone, PDA Smartphone

Karten, Fahrpläne,

Routeninformation

en, Reisezeit,

Kosten (Vergleich

von Alternativen)

Aktive intermodale

Route, Aktuelle

Verkehrs-

meldungen,

Straßenkarten,

Parkplätze, ÖV-

Umstiegspunkte,

ÖV-Fahrplan-

informationen

Aktive intermodale

Route, Details zu

ÖV-Teilen,

Umsteige-

informationen,

Echtzeit-

informationen,

reale Ankunftszeit,

Anschluss-

sicherung

Aktueller

Fahrpreis,

Rufmöglich-keiten,

Anschluss-

sicherung

Fußwege,

touristische

Informationen,

Informationen zu

Quereinrichtungen

auf Straßen,

Informationen zu

W egpunkten

Fahrradabstell-

plätze beim

Umsteigen,

Radwege,

Fahrradmit-nahme

im ÖV

Umsteigeweg-

beschreibung (+

Angabe Aufzüge,

Rolltreppe etc.),

Informationen über

neues

Verkehrsmittel (Art,

Nummer,

Ausstattung),

Informationen über

Abfahrtszeiten,

Bahnsteige

on-trip

Informationstech-nische

Unterstützung/ Reisesituation

Reiseinformationen

Existierende/Nicht-

Integrierte Systeme

Reise-/Routenplanung

Navigation/Orientierung

Endgeräte/Interaktionsmodus

Das oben beschriebene Modell bildet die Grundlage für mögliche Adaptie-rungen des Informationssystems für die jeweiligen Situationen. Der Fokus bei Vienna-SPIRIT liegt auf der durchgängigen Unterstützung der MIV-Situation. Dafür sind auch Anpassungen in der Planungsphase und beim Umsteigen notwendig. Im Folgenden sollen anhand der Situationen „Rei-sevorbereitung“ und „MIV-Situation“ die spezifischen Probleme aufgezeigt und mögliche Anpassungen vorgeschlagen werden. Weiters werden auch Anforderungen an geografische Informationen für eine integrierte Reiseun-terstützung formuliert.

Situation „Reisevorbereitung/-planung“

Die intermodale Reiseunterstützung in Vienna-SPIRIT beginnt bei der Rei-sevorbereitung und -planung. Da die statische intermodale Routenplanung


(pre-trip) bereits relativ gut von bestehenden Systemen abgedeckt wird, kann in dieser Situation eine integrierte Lösung durch Adaptierungen von Web-basierten Informationssystemen (z.B. von EFAwww) erreicht werden. Als sinnvolle Adaptierungen können folgende Funktionen genannt werden:

•Exakte Planung von intermodalen Reisen (z.B. durch Angabe von Via-Punkten, Transportmitteln für Teilabschnitte, bekannten Umstiegspunkten)

•Anpassung der Routenplanung für intermodale Reisen ohne ÖV bzw. in-termodale Reisen mit festgelegten Autorouten (Autorouten werden nicht nur als Zubringer zum ÖV betrachtet)

•Personalisierung des Informationssystems (z.B. durch personalisierte Verwaltung von Reisen inklusive der Aktivierung einer Reise, die Verwal-tung eines Benutzerprofils, Angabe von Präferenzen für eine einfachere und exaktere Reiseplanung und Reiseinformation)

•Integration und Bereitstellung der Reisedaten für den Zugriff von mobilen Endgeräten in der On-trip-Phase

•Dynamische Routenberechnung auf der Basis von Echtzeitdaten zur aktu-ellen bzw. prognostizierten Verkehrslage im MIV sowie ÖV.

Situation „MIV“

Bei der MIV-Situation handelt es sich um eine On-trip-Situation, daher steht die Bereitstellung der Daten aus der Pre-trip-Planung für einen durch-gängigen mobilen Zugriff im Vordergrund. Folgende spezifische Teilprob-leme sind zu lösen:

•Laden und Anzeigen einer in der Pre-trip-Phase geplanten intermodalen Route am Autonavigationsgerät oder PDA (Adaptierung an das Endgerät)

•Übernehmen von Auto-Routenabschnitten mit Start-/ Umstiegspunkt und Navigation auf diesen mit On-board-Navigationsgerät oder Navigations-anwendung am PDA (integrierte Zielführung)

•Berechnung von intermodalen Alternativrouten im ÖV (z.B. bei Verkehrs-behinderungen auf der Autoroute) vom Navigationssystem aus

•Berücksichtigung der MIV-Situation und der aktuellen Positionen bei der On-trip-Berechnung einer intermodalen Route (keine Tür-zu-Tür-Planung). Diese Kontext-Parameter werden von bestehenden Systemen ignoriert, müssen aber für eine sinnvolle On-trip-Routenplanung unbedingt berück-sichtigt werden.

•Suche von Umsteigemöglichkeiten in den ÖV im Bereich der aktuellen Position (erfordert den Zugriff auf die automatische Lokalisierung des Na-vigationssystems)


•Zugriff auf Parkrauminformationen an möglichen Umstiegspunkten inklu-sive Bereitstellung von Detaildaten und Preisen sowie der Reservierung von Parkplätzen.

Anforderungen für ein integriertes intermodales Reiseinformationssys-tem

Die sich dadurch ergebenden Anforderungen für die Konzeption eines In-formationssystems sind die Heterogenität der verschiedenen Endgeräte und der Interaktionsmodi (Autonavigationsgeräte, PDAs aber auch Smartpho-nes mit GUI oder Sprachinteraktion), Integration mit bestehenden Informa-tionssystemen und Ausnutzung lokaler „Intelligenz“ (Integration von lokal vorhandener Infrastruktur am mobilen Endgerät wie angeschlossene GPS-Empfänger für die automatische Lokalisierung oder die Integration von lo-kalen, monomodalen Navigationssystemen bzw. -anwendungen wie z.B. TomTom-Navigator für die Autonavigation), Durchgängigkeit und Adap-tierung der Unterstützung (MIV-Situation ist nur ein Teil in dieser inter-modalen Reisekette, Schaffung eines integrierten Informationssystems), Integration und Interoperabilität von Reiseinformationen (eine Vielzahl von Informationen ist notwendig, Fahrplan- und Echtzeitdaten des ÖV, Park-platzdaten, touristische Informationen, Verkehrsinformationen bis hin zu Wetterdaten). Die Grundlage für integrierte Reiseinformationen muss ein geografisches Informationssystem für alle Verkehrsmittel bzw. deren Netze bilden.

Anforderungen an geografische Informationen

Durch die Optimierung von Kartenmaterial für die Kfz-Navigation fehlen meist das Fuß- und Radwegenetz sowie öffentliche Verkehrsnetze. Ein in-termodales geografisches Informationssystem sollte deswegen folgende Datenschichten enthalten:

1.Straßennetz: Das vektorielle Straßennetz mit Informationen zur Geomet-rie (Polygonzug), zu Attributen (z.B. Einbahnregelung, Neigung, zul. Ge-schwindigkeit, zugelassene Verkehrsmittel) und Straßennamen. Für das Routing im Straßennetz werden außerdem noch Informationen über die Verbindungen der Kanten, also Abbiegeverbote etc. erforderlich.

2.Fußwegenetz: Das Fußwegenetz ist dichter als das Straßennetz, da es ne-ben straßenbegleitenden Fußwegen auch Fußgängerzonen sowie zusätzli-che Wege durch Parks, Häuserdurchgänge und innerhalb von Gebäuden (z.B. Einkaufspassagen) gibt.

3.Radwegenetz: Das Radwegenetz stimmt nur auf ausgewiesenen Radrou-ten mit dem Straßennetz überein. Radfahren kann z.B. auch gegen die Ein-


bahnrichtung zugelassen werden. Außerdem gibt es straßenunabhängige Radwege.

4.ÖV-Netz: Das öffentliche Verkehrsnetz überlagert sich nur zum Teil (Straßenbahn, Bus) mit dem Straßennetz, ein anderer Teil ist straßenunab-hängig (U-Bahn, Stadtbahn und Eisenbahn). Neben den Linienwegen müs-sen Haltestellen georeferenziert sein. Haltestellen gliedern sich räumlich in Bereiche und Steige (Bus- und Bahnsteige), zwischen denen Fußwege und Höhenunterschiede zurückgelegt werden müssen. Diese Umsteigewege müssen beim Routing berücksichtigt werden. Außerdem müssen auch Ü-bergangspunkte zum MIV definiert werden.

In Vienna-SPIRIT kann durch die Anbindung der intermodalen Fahrplan-auskunft des Verkehrsverbundes Ost-Region teilweise auf zusätzlich zum Straßennetz erfasste ÖV-Netz- bzw. Fußwegenetzdaten zugegriffen wer-den. Integrierte geografische Informationen für alle Endgeräte können al-lerdings im Rahmen des Projektes nicht bereitgestellt werden und sind da-her eine offene Fragestellung.

SYSTEMARCHITEKTUR

Die Systemarchitektur des Vienna-SPIRIT-Systems ist speziell durch die zuvor genannten Anforderungen geprägt. Für die konzeptionelle Architek-tur (s. Abb. 3) wurde deshalb ein hierarchisches Schichtenmodell gewählt, welches den logischen Aufbau des Systems darstellt. Für Vienna-SPIRIT wurden 4 logische Schichten definiert, wobei jede logische Schicht spezifi-sche Anforderungen im System erfüllt. Die logischen Schichten sind in Device Layer, Adaptation Layer, Middleware Services Layer und Legacy Systems/Data Layer eingeteilt. Unter den Anforderungen speziell hervor-zuheben ist einerseits die Integration von heterogenen Daten, die vor allem in den unteren beiden Schichten (Middleware Services Layer und Legacy Systems/ Data Layer) mit Hilfe von offenen Schnittstellen und Standards erfüllt wird. Andererseits wurde zur Anbindung der heterogenen Endgeräte eine eigene logische Schicht zwischen Device Layer und Middleware Ser-vices Layer, der sogenannte Adaptation Layer konzipiert, der für die An-passungen der Datenformate und Interaktionen zwischen heterogenen End-geräten und Middleware Services sorgt.


Abb. 3: Konzeptionelle Systemarchitektur (Schichtenmodell)

Im Folgenden werden die logischen Schichten und ihre Aufgaben beschrie-ben:

•Device Layer: Für die Modellierung von Endgeräten wurden Klassen konzipiert, nach denen bestehende und zukünftige Endgeräte eingeteilt werden. Die Endgeräteklassen ergeben sich einerseits durch die Funktiona-lität der Endgeräte, andererseits aber auch durch Interaktionsmodi. Folgen-de Klassen werden unterschieden: Car-embedded Telematics Platform (Au-tonavigationsgeräte mit On-board-Navigation und offener Schnittstelle, die meisten Navigationsgeräte erlauben keine Ausführung zusätzlicher lokaler Logik, daher ist ein Proxy notwendig), Active Client (Smartphones oder PDAs auf denen Programmlogik lokal ausgeführt werden kann, optional sind das lokale Navigationssystem und ein GPS-Empfänger), Web-Client (alle Formen von Web-Clients, auch mobiles Web), Mobile Messaging Client (SMS und MMS Clients) und Voice Client (Sprachdialog als Benut-zerinteraktion). Durch diese Modellierung der Endgeräteklassen kann loka-le Infrastruktur auf „intelligenten“ Endgeräten genutzt werden. Endgeräte mit wenig Infrastruktur hingegen erhalten weiterhin volle Serverunterstüt-zung.


•Adaptation Layer: Diese Schicht ist als logische Schicht zwischen Devi-ce Layer und Middleware Services Layer konzipiert und besteht im wesent-lichen aus einer erweiterbaren Menge von Gateways, die Zugang für End-geräte aus ein- oder mehreren Endgeräteklassen bieten. Aufgabe der Gate-ways ist es, zwischen heterogenen Endgeräten und Middleware Services durch Transformation von Datenformaten zu vermitteln. Dadurch ergibt sich ein sehr flexibles System, das relativ einfach für neue Endgerätetypen erweitert werden kann. Die Middleware Services müssen dabei nicht ver-ändert werden. Zusätzlich kann fehlende „Intelligenz“ am Endgerät im Ga-teway der Endgeräteklasse ausgeglichen werden.

•Middleware Services Layer: Im Middleware Services Layer sorgen eine Reihe von unabhängigen Services dafür, dass die Daten aus den Fremdsys-temen und Datenbanken integriert und den darüber liegenden Schichten über offene Schnittstellen zur Verfügung gestellt werden. Die Services in dieser Schicht sind beliebig erweiterbar. Zurzeit sind vor allem Services zur Anpassungen von bestehenden Funktionen der Fremdsysteme konzipiert. Zusätzlich wird Funktionalität wie die Verwaltung von Benutzerprofilen und Präferenzen durch eigene Services abgedeckt. Durch die Verwendung von offenen Schnittstellen und einheitlichen Datenformaten sind die Servi-ces für alle Endgeräte nutzbar, wodurch die permanente, mobile Verfüg-barkeit sichergestellt wird.

•Legacy Systems/ Data Layer: In dieser logischen Schicht wird der An-forderung Rechnung getragen, dass für ein durchgängiges Reiseinformati-onssystem viele heterogene Daten integriert werden müssen. In Vienna-SPIRIT wird die Philosophie verfolgt, dass bestehende intermodale bzw. monomodale Informationssysteme unbedingt weiter zu nutzen sind. Da-durch ergibt sich die Anforderung der Integration dieser Datenquellen. Die in der Architektur konzipierten Datenquellen sind nur die zurzeit angedach-ten Datenquellen, die Integration von zusätzlichen ist jederzeit möglich. Um die Harmonisierung der Daten zu gewährleisten wird auf einen Adap-ter-Mechanismus zurückgegriffen. Durch die Verwendung von Adaptern bleiben die angebundenen Systeme dahinter weitgehend austauschbar.

Die Systemarchitektur von Vienna-SPIRIT wurde als Gesamtarchitektur für integrierte, intermodale Reiseinformationssysteme konzipiert. Für die zuvor postulierten Problemstellungen wurden konzeptionell Lösungen er-arbeitet. Im Pilotsystem, das Teil des Vienna-SPIRIT Projektes ist, werden einzelne Teile der Architektur umgesetzt und evaluiert. Der Fokus liegt da-bei ebenfalls wie bei der Modellierung auf der Unterstützung der MIV-Situation.


PILOTSYSTEM

Mit Hilfe des Pilotsystems von Vienna-SPIRIT wird in der Region Wien während einer mehrmonatigen Pilotphase in einer begleitenden Studie eva-luiert6, ob die angestrebte intermodale Reiseunterstützung sich in der Praxis als brauchbar erweist. Während der Pilotphase steht ein Concept-Car, aus-gestattet mit den modernsten Telematiklösungen zur Verfügung. Im Pilot-system wurden mit Hilfe der Vienna-SPIRIT-Partner Verkehrsverbund Ost-Region GmbH, ARC Seibersdorf research GmbH, Salzburg Research For-schungsgesellschaft mbH, Materna Information & Communications GmbH, Sonorys Technology GmbH und anderen Werkvertragspartnern folgende Funktionalitäten implementiert:

•Erweiterung der EFAwww Fahrplanauskunft von Mentz Datenverarbei-tung GmbH um die zuvor genannten zusätzlichen Funktionen (exaktere Routenplanung, Personalisierung, aktiv setzen einer Reise usw.); Integrati-on und Anpassung der EFA in das Vienna-SPIRIT System.

•Als Autonavigationssystem wird das Siemens VDO PC5500pro Gerät verwendet. Dieses Gerät verfügt über eine serielle Schnittstelle, die es er-laubt, auf die Funktionen des Gerätes von außen zuzugreifen. Als Proxy wird ein Java Active Client auf einem Nokia 6600 Smartphone verwendet, der auch die GPRS-Verbindung herstellt. Die Verbindung zwischen dem Navigationsgerät und dem Smartphone erfolgt über Bluetooth. Vom Navi-gationsgerät aus ist es möglich, die aktive Reise zu laden (inklusive der au-tomatischen Übernahme von Autoteilen direkt zur Navigation), Details zur Reise anzuzeigen (auch ÖV-Routen), jederzeit eine intermodale Routen-planung mit aktuellen Parametern (z.B. Position, aktuelles Transportmittel) zu starten, Parkplätze mit Anschluss an den ÖV in der Umgebung zu fin-den, Details zu Parkplätzen abzufragen, Parkplätze zu reservieren.

•Als Active Clients werden sowohl ein Smartphone Active Client (auf Ja-va-Basis) als auch ein PDA Active Client (auf Microsoft .NET-Basis) ver-wendet. Beide Clients verwenden Bluetooth-GPS-Empfänger für die auto-matische Lokalisierung. Der .NET Client verwendet zusätzlich ein Inter-face zum PDA-Navigationssystem TomTom-Navigator 2. Dadurch wird eine Navigation für Autostrecken auch auf dem PDA möglich. Zusätzlich kann auch von TomTom aus der Vienna-SPIRIT Active Client aktiviert werden. Die Funktionen am PDA sind ident zu denen am Autonavigations-system. Das Smartphone wird vor allem auch dazu verwendet, um die ge-plante Reise beim Umsteigen vom Auto in den ÖV mitzunehmen. Nach

6 Erwarteter Nutzen und verkehrliche Auswirkungen dokumentiert in Bruntsch, Rehrl et al. 2004.


dem Umsteigen ist es möglich, sich jederzeit Details zur gesamten Route, Karten für die Routenteile bzw. Umsteigewege anzeigen zu lassen.

•Mit einem Sprachinterface wird es möglich, intermodale Reiserouten komplett per Sprache zu planen und sich die geplante Route per SMS oder MMS zuschicken zu lassen. Damit ist der Vienna-SPIRIT-Dienst von bei-nahe jedem handelsüblichen Mobiltelefon zugreifbar. Ist der Benutzer im System bereits registriert, kann die geplante Route auch im System zur Ab-rufung mit einem anderen Endgerät aktiv gesetzt werden.

•Die Middleware Services wurden als Web Services7 realisiert. Die einzel-nen Services sind modular aufgebaut, wodurch voneinander unabhängige Funktionalitäten in unterschiedlichen Services gekapselt werden können. In den Parametern der Funktionen werden in XML-Schema8 definierte Daten-pakete ausgetauscht. Diese Datenpakete werden (falls nötig) in den Gate-ways in Ausgabeformate transformiert und an die Endgeräte weitergege-ben. Durch die Verwendung von W3C9-Standards wird die Offenheit und Interoperabilität der Schnittstellen gewährleistet.

•Als Fremdsysteme wurden die EFA für intermodale Routenplanung, das Parksystem der Skidata AG sowie Map24 der Mapsolute GmbH für die serverunterstützte Planung von Autorouten und die Korridorsuche von Parkplätzen eingebunden.

SCHLUSSBEMERKUNGEN UND AUSBLICK

In diesem Beitrag wurde ein Modell für eine situationsbezogene, adaptive Reiseunterstützung für intermodale Reisen vorgestellt. Auf Basis der Sys-temarchitektur und der Umsetzung im Pilotsystem konnte gezeigt werden, wie dieses Modell als integriertes Reiseinformationssystem umgesetzt wer-den kann. Der spezielle Fokus liegt dabei auf einer integrierten Reiseunter-stützung für MIV-Situationen. Offene Fragestellungen ergeben sich unter anderem noch im Bereich der Umsteigemodellierung, der Unterstützung in ÖV-Situationen und bei Fußgängern. Diese Teilproblematiken sollen im Nachfolgeprojekt Open-SPIRIT erforscht werden.

7 http://www.w3.org/2002/ws/

8 http://www.w3.org/XML/Schema

9 http://www.w3.org/


LITERATUR

Bruntsch, S., Rehrl, K. et al. (2004): Intermodale Reiseinformation als Bei-trag zu einer nachhaltigeren städtischen und regionalen Verke-hrsentwicklung. Tagungsband zur CORP 2004 Wien: 503-509

Häußler, J., Zipf, A. (2003): Multimodale Karteninteraktionen zur Naviga-tionsunterstützung für Fußgänger und Autofahrer. AGIT-Symposium Salzburg: 110-119

Reichenbacher, T. (2003): Adaptive Methods for Mobile Cartography. Pro-ceedings of the 21st International Cartographic Conference, South Af-rica: 1311-1320

vienna-spirit: situationsbezogene, integrierte reiseunterstützung für intermodale reisen

Documents