TOGAF C

Die Informationssystemarchitektur

Die Informationssystemarchitektur beschreibt die Entwicklung einer Zielarchitektur für Informationssysteme in der multimodalen Reiseinformation, in welcher die Geschäftsarchitektur (Phase B) und die Architekturvision (Phase A) umgesetzt werden sollen. Die Informationssystemarchitektur unterscheidet dabei die Bereiche Datenarchitektur und Anwendungsarchitektur. Bei der Entwicklung der Geschäftsarchitektur wurden unter anderem IVS-Geschäftsprozesse identifiziert. Diese bestehen aus Aktivitäten, die rollenbezogen durchgeführt werden. Zwischen den Aktivitäten werden Informationsobjekte ausgetauscht. Diese Informationsobjekte werden in der Datenarchitektur betrachtet und detailliert beschrieben. Anschließend werden die Schnittstellen, über die die Informationsobjekte ausgetauscht werden sowie die Anwendungen, mit denen die Informationen bearbeitet werden, in der Anwendungsarchitektur genauer untersucht.

Datenarchitektur

In der Datenarchitektur werden alle relevanten Informationsobjekte beschrieben, die zwischen den Rollen einer „multimodalen Reiseinformation“ respektive den Akteuren der Rollen übergeben werden. Das Informationsobjekt beinhaltet Daten für die drei Bereiche: *Rollen & Geschäftsmodelle (geschäftliche Ausprägung) *Regeln & Rahmenbedingungen (Rechtliche Ausprägung) *Informations- & Kommunikationstechnologie (Inhaltliche Ausprägung). Dazu können u. a. das Verkehrsnetz und die Abbildung der Verkehrsinfrastruktur, Bezugssysteme zur Verortung von Informationen (wie Adressen, Stationierungen oder TMC), routingrelevante Informationen, Sensorstandorte sowie mögliche Aktivitäts- und Zielstandorte und dynamische Verkehrsdaten zählen wie auch Vertragsregeln, kaufmännische Vereinbarungen, zugrundeliegende Gesetze sowie Prozesse und Abläufe zur Kommunikation und Organisation des Datenaustauschs und der Datenbereitstellung und -verwendung.

Aufgrund des föderalen Raums in Deutschland, der unterschiedlichen Entwicklungs- und Realisierungszeiträume, der geltenden Förderbindungen und des Investitionsschutzes bei Bestandsystemen (Investitionen) ist die Umsetzung einer deutschlandweiten „multimodalen Reiseinformation“ unrealistisch. Die Entwicklung einer Datenarchitektur für eine „multimodale Reiseinformation“ muss daher zwar zum einen Vorgaben entlang von national und international gültigen Standards machen, zum anderen aber Flexibilität im Hinblick auf Datenherkunft und Datenformat erlauben. Damit soll ein Ersatz und die Weiterentwicklung von Datenquellen bzw. eine Kombination von Datenquellen für idente Inhalte nach Netzkategorien oder administrativen Gebieten ermöglicht und mit der IVS-Referenzarchitektur „multimodale Reiseinformation“ dauerhaft sichergestellt werden.

Position der Informationsobjekte einer multimodalen Reiseinformation

Aufgrund der zahlreichen Akteure für eine „multimodalen Reiseinformation“ in einem Betrachtungsraum wird in der Referenzarchitektur eine vereinfachte generische Darstellung aller typischerweise für einer „multimodalen Reiseinformation“ benötigten Informationsobjekte gewählt. Die Informationsobjekte werden dabei entlang der Wertschöpfungsstufen der Rollen „Inhalteanbieter“, „Dienstebetreiber“, „Diensteanbieter“ und „Kunde“ sowie der stereotypischen Akteure „Mobilitätsdienstleister“, „IVS-Integrator“ und „Infrastrukturbetreiber“ positioniert.

   

Daten der Informationsobjekte einer multimodalen Reiseinformation

Informationsobjekte können drei Ausprägungen haben und dabei unterschiedliche Daten transportieren:

• Geschäftliche Ausprägung
  für Informationen zu Rollen & Geschäftsmodellen einer „multimodalen Reiseinformation“. Hierzu zählen u. a. Daten zu:
  • Organisatorische und betriebliche Abläufe (z. B. Qualitäts- und Eskalationsmanagement)
  • Nutzungsbedingungen (z. B. Logos, Haftung)
  • Finanzierungsbedingungen (z. B. Margen)
• Rechtliche Ausprägung
  für Informationen zu Regeln & Rahmenbedingungen einer „multimodalen Reiseinformation“. Hierzu zählen u. a. Daten zu:
  • Datenschutz
  • Vertragswerke
  • AGBs
  • SLAs / PKIs
  • Pönalen
• Inhaltliche Ausprägung
  für Informationen zu Informations- & Kommunikationstechnologie einer „multimodalen Reiseinformation“. Hierzu zählen u. a. Daten zu:
  • Tarifdaten
  • Dynamische Daten
  • Statische Daten
  • Schnittstellenbeschreibungen

Zum besseren Verständnis, werden die Informationsobjekte in Phase C im Anschluss an die allgemeine Beschreibung (IVS_Informationsobjekte) mithilfe der bereits für den Schritt Phase B verwendeten Use Cases beispielhaft beschrieben. (Use_Case_Flug / Use_Case_Grenzüberschreitend / Use_Case_Intermodal)

Beschreibung der allgemeinen Informationsobjekte

Die in der Abbildung dargestellten stereotypischen Informationsobjekte werden anhand der Nummerierungen unterschieden und anhand der vorgenannten Daten einheitlich beschrieben. Die konkreten Ausarbeitungen sind unter folgendem Link zu finden: 

• IVS Informationsobjekte

Use Case Flug

Der Dienstreisende Herr Müller zeichnet sich neben einer von ihm geführten Abteilung am Standort Michelstadt im Odenwald zum 01.03.2016 zusätzlich verantwortlich für eine Abteilung am Standort Hamburg. Er plant ein Teamevent vor Ort mit seiner neuen Abteilung. Als gehbehinderter Dienstreisender reist er morgens am 21.03.2016 von Michelstadt nach Hamburg und kommt am 23.03.2016 abends wieder zurück.

Durch seine Behinderung benötigt Herr Müller einen Kofferservice für die Reise. Die Reise beginnt er mit seinem PKW, der am Abflughafen geparkt werden soll. In Hamburg soll ihn ein Transferservice zum Hotel bringen. Am Hotel wird ihm dann ein Mietwagen zur Verfügung gestellt.

Die Inhalteanbieter liefern Informationen zu Fahr-/Flugplandaten, Tarifdaten, Routen- und Parkplatzinformationen, Koffer- und Transferservice.

Die intermodale Logik verarbeitet diese Informationen unter Berücksichtigung von öffentlichen Strategien, von Präferenzen des Nutzers (Dienstreiserichtlinien und persönliche Vorlie-ben, z. B. Schwerbehindertenangebote) und von Distributionsinformationen und liefert die Multimodale Reiseinformation mit den verschiedenen Reisemitteln der Reisekette an den Dienstanbieter zur Darstellung. 

• Template: Use Case Flug

Use Case Grenzüberschreitend

Herr Meier wohnhaft im Münchner Umland muss Ende Juli zu einer eintägigen Sitzung nach Salzburg reisen. Im Vorfeld informiert er sich, wie er am einfachsten dorthin kommt. Da er einen eigenen PKW besitzt und die nächste S-Bahn Anbindung recht weit entfernt ist, entscheidet er sich mit dem Auto zu fahren. Kurz vor Ankunft an der Grenze meldet sein Bordnavigationsgerät eine Schlechtwetterwarnung mit einem absoluten Fahrverbot im Stadtgebiet Salzburg und somit einem Einfahrtverbot (1. Juli bis Ende August – Verordnung Stadt Salzburg). Das Einfahrverbot gilt ab der Autobahnausfahrt Salzburg-Mitte. Herr Meier fragt über das Bordnavigationsgerät eine Alternativroute an und entscheidet sich, in der Region zur nächstgelegenen S-Bahnstation zu fahren in Piding, um dort umzusteigen. Mit Hilfe des Mobilitätsdienstes kann er das ÖV-Ticket und einen Stellplatz für seinen PKW bereits auf der Fahrt dorthin buchen. An der S-Bahn Haltestelle Mülln-Altstadt steigt er aus und legt die restliche Strecke zu Fuß zurück.

Bezogen auf den Auszug aus dem Use Case mit näherer Betrachtung On-Trip ergibt sich folgende Situation:

Der Endnutzer hat seine Route und auch den Modus geändert als er in den ÖV umgestiegen ist. Dabei werden nun vom Dienstebetreiber die Informationsobjekte Fahrplanauskunft, Tarif-daten, ÖV-Routing und Verkehrsprognose sowie die Echtzeitinformation über die Position auf der Zugfahrt verarbeitet und diese Information über die App des Diensteanbieters dem Endnutzer zur Verfügung gestellt.

• Template: Use Case Grenzüberschreitend

Use Case Intermodal

Tag 1:

Ein Reisender fährt mit dem PkW von Stadt A zur Stadt B, um dort am flughafennahen Kongresszentrum (Z1) einen Vortrag zu halten und auch im zugehörigen Hotel zu übernachten. Im Parkhaus des Kongresszentrums stellt er seinen PkW ab.

Tag 2:

Am darauf folgenden Tag hat er im Zentrum der Stadt B einen halbtägigen Besprechungstermin wahrzunehmen und entscheidet sich, die Strecke vom Kongresszentrum zum Stadtzentrum (Z2) mit der S-Bahn und der Tram zurückzulegen. Nach der Besprechung kehrt er aus Zeitgründen per Taxi zum Kongresszentrum (Z1) zurück und fährt mit seinem dort geparkten PkW weiter zur Stadt C, um dort zu übernachten (Z3).

Tag 3:

Am dritten Tag sind weitere dienstliche Angelegenheiten in der Stadt C zu erledigen (Z4). An diesem Tag findet in der Stadt C ein Marathonlauf statt, und der Reisende stellt sich darauf ein, die öffentliche Beschilderung für die Wegweisung neben dem Navigationsgerät in seinem PkW zu nutzen. Auf dem Rückweg von Z4 nach Z gibt sein Navigationsgerät innerhalb der Stadt C eine Umwegroute an, da diese von der Stadt als strategische Route unter Berücksichtigung des Abbaus von Absperrungen zum stattgefundenen Marathonlauf vorgegeben ist.

Typische MIV bezogene Informationsobjekte sind für das Beispiel „Route S > Z1“ in der nachfolgenden Abbildung zusammengestellt. Die Abbildung zeigt auch typische Akteursstereotypen für die drei Rollen Inhalteanbieter, Dienstbetreiber und Dienstanbieter sowie typische Endgeräte bzw. -systeme für die Präsentation des IVS-Dienstes.

• Template: Use Case Intermodal

Datenmodell-Katalog

Im Rahmen der Entwicklung einer Datenarchitektur werden ebenfalls die derzeitigen Datenmodelle dargestellt. Folgende Tabelle gibt eine Übersicht zu den Datenmodellen die derzeitig in der multimodalen Reiseinformation verwendet werden.

• Katalog

Datenmodelle Mobilitätsanbieter

• IVS Datenmodelle Mobilitätsanbieter

Datenmodelle Infrastrukturanbieter

• IVS Datenmodelle Infrastruktur

Ortsreferenzierung

Im Hinblick auf die Ortsreferenzierung haben multimodale Reiseinformationssysteme Anforderungen, die weitestgehend über die IV und ÖV Anforderungen abgedeckt sind.

Diese Anforderungen beziehen sich auf

·         die eineindeutige Referenzierung von Informationsobjekten auf die IV-Netze wie auf die ÖV-Netze,

·         auf die möglichst verlustfreie Übertragung von Ortsreferenzen zwischen unterschiedlichen Referenzierungsmethoden oder Netzversionen, sowie

·         auf die räumliche Referenzierung von Reiserouten (Navigation).

Spezielle Anforderungen ergeben sich bei multimodalen Reisen im Umfeld von Umstiegspunkten. Da jede ÖV Route allerdings auch als multimodal gesehen werden kann, sind die Anforderungen dort weitestgehend ident. Zentrale Problematik ist dabei insbesondere die mangelnde Datenverfügbarkeit, aufgrund von Datenlücken und mangelnden Detailinformationen im Bereich von Umsteigebauwerken.

Die Rolle der unterschiedlichen Methoden von Ortsreferenzierungen im Kontext von multimodalen Reiseinformationen wird anhand der Methoden

1.         IVS-Ortsreferenzierung „AGORA-C“

AGORA-C kann ausschließlich im IV Bereich eingesetzt werden, und wird – da lizenzpflichtig – nicht empfohlen.

2.     IVS-Ortsreferenzierung „Alert-C“

Alert-C dient zur Ortsreferenzierung im hochrangigen Straßennetz. Aufgrund der weiten Verbreitung (insbesondere bei Verkehrsmeldungen IV) ist eine Unterstützung auf absehbare Zeit notwendig und sinnvoll.

3.         IVS-Ortsreferenzierung „Geographische Koordinaten“

Die universell einsehbare Methode „Geographische Koordinaten“ findet sehr stark bei der Datenerfassung von Primärinformationen Verwendung (beispielsweise Objekte im Straßenraum), was außerhalb des Betrachtungsgegenstandes liegt.

4.         IVS-Ortsreferenzierung „Lineare Referenzierung“

Die Methode der linearen Referenzierung ist die präferierte Ortsreferenzierung der Infrastrukturbetreiber im hochrangigen Straßennetz wie im Bahnnetz. Damit ist es die originäre Ortsreferenzierung von Daten dieser Infrastrukturbetreiber, kommt in Ausnahmefällen jedoch auch in der Kommunikation mit Reisenden zum Einsatz („Unfall A8 bei KM xyz“).

5.         IVS-Ortsreferenzierung „Netzmodell“

Aufgrund der eindeutigen und durchgängigen Zuordenbarkeit wird diese Methode für IVS Services präferiert, soferne idente Modelle und Versionen in der Informationskette sichergestellt werden können. Im Falle von unterschiedlichen Netzmodellen und/oder Netzversionen in der Informations- und Servicekette, ist jedoch eine potenziell fehlerbehaftete Konvertierung durchzuführen. Als Standardmethode dafür hat sich OpenLR etabliert, wobei zur Qualitätsverbesserung bei der Konvertierung ergänzende Methoden/Heuristiken sinnvoll erscheinen.

6.         IVS-Ortsreferenzierung „OpenLR“

OpenLR setzt sich zunehmend als Standardverfahren für die Konvertierung von Ortsreferenzen zwischen unterschiedlichen Netzmodellen durch. Eine eineindeutige Konvertierung kann nicht gewährleistet werden, die Konvertierungsqualität kann aber durch ergänzende Methoden weiter verbessert werden.

7.         IVS-Ortsreferenzierung „TPEG LOC“

Als Standard im Bereich Verkehrsmeldungen etabliert.

8.         IVS-Ortsreferenzierung „Traces“

• Katalog: IVS-Ortsreferenzierungen

Anwendungsarchitektur

In der Anwendungsarchitektur werden alle relevanten Anwendungen, deren fachliche Komponenten über Schnittstellen in Beziehung (Interaktion) treten und zur Bereitstellung der in Phase B definierten Geschäftsprozesse erforderlich sind, beschrieben und kategorisiert. Die Anwendungsarchitektur bildet damit die logischen Bausteine der Geschäftsarchitektur (Phase B) einer „multimodalen Reiseinformation“ ab, welche dann in Phase D (Technologiearchitektur)  Software und Hardwareseitig konkretisiert werden können.

IVS Anwendungen der multimodalen Reiseauskunft

• Katalog und Anwendungen
• Komponentendiagramm_Multimodale_Reiseinformation

IVS Schnittstellen der multimodalen Reiseauskunft

• Schnittstellen Katalog

Schnittstellen Mobilitätsanbieter

• IVS-Schnittstellen Mobilitätsanbieter

Schnittstellen Infrastrukturanbieter

• IVS-Schnittstellen Infrastrukturanbieter