„Betriebslenkung“ ist die Überwachung des planmäßigen Verkehrsangebotes eines Verkehrsunternehmens und die aktive Beeinflussung des Verkehrsablaufes im Fall von Störungen. Dazu dienen verschiedene Regelkreise im Zusammenspiel zwischen zentraler Leitstelle und Fahrzeugen.

Das ITVU-Branchenmodell bietet eine Daten- und Systemmodellierung für die dazu notwendigen IT-Systeme, eingebettet in eine konsistente Modellierung aller spezifischen Geschäftsprozesse eines Verkehrsunternehmens. Kern des Modells ist ein Klassenmodell gemäß UML 2.0.

Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

1 Einleitung und Begriffe

Die Kernaufgabe eines Verkehrsunternehmens im öffentlichen Personenverkehr ist die Erbringung von Fahrgastfahrten im Einklang mit einem vorher definierten und veröffentlichten Beförderungsangebot (Fahrplan).

„Betriebslenkung“ ist die Überwachung und Beeinflussung dieses Beförderungsprozesses. Die aktive Beeinflussung ist insbesondere dann notwendig, wenn das Beförderungsangebot durch unvorhergesehene Ereignisse (Unfall, technische Störung, Stau...) gestört wird. Dabei geht es um die möglichst rasche Wiederherstellung des ungestörten Beförderungsangebotes unter Berücksichtigung des Ressourcen-Einsatzes (Fahrer, Fahrzeuge).

Ein anderer verbreiteter Begriff für „Betriebslenkung“ ist daher „Flottensteuerung“ (engl. „Fleet Control“ oder „Fleet Management“). Dieser Begriff ist aber weniger spezifisch für den öffentlichen Personenverkehr, er wird auch z.B. in der Logistik-Branche benutzt.

Die zur Betriebslenkung eingesetzten IT-Systeme werden klassisch als RBL (Rechnergestütztes Betriebsleitsystem) bezeichnet, in letzter Zeit auch als ITCS (Intermodales Transport Control System). Im Englischen sind die Begriffe AVL (Automatic Vehicle Location) und AVM (Automatic Vehicle Monitoring) verbreitet.

2 Einbettung in das übergreifende Branchenmodell ITVU

Die hier vorgestellte Diskussion der Betriebslenkung ist Bestandteil eines umfassenden Branchenmodells (Domain-Modell) für den öffentlichen Personenverkehr mit Bahnen, Bussen, Straßenbahnen etc. Dieses Modell heißt ITVU („IT-Systeme für Verkehrsunternehmen“)

Gegenstand des Modells sind die Kern-Geschäftsprozesse im Zusammenhang mit der Personenbeförderung, gegliedert in die folgenden sechs Prozess-Gruppen:

- Planung (Fahrplan, Dienstplan, Umlaufplan)

- Disposition (Fahrzeugeinsatz, Personaleinsatz)

- Betriebslenkung (Überwachung und Störungsmanagement)

- Fahrgastinformation (Fahrplanauskunft, dynamische Fahrgastinformation)

- Ticketing

- Auswertung

Die dargestellte Reihenfolge dieser Geschäftsprozess-Gruppen orientiert sich grob an der zeitlichen Abfolge, wobei Betriebslenkung, Fahrgastinformation und Ticketing im Wesentlichen zeitlich parallel während des eigentlichen Fahrbetriebs erfolgen.

Neben dieser zeitlichen Strukturierung der (Teil-)Prozesse gibt es eine natürliche räumliche Strukturierung. Die Handlungen in und mit den Systemen des ITVU Modells finden an verschiedenen Orten statt:

- In der Zentrale des Verkehrsunternehmens (Verwaltung, Leitstelle, Betriebshöfe)

- Auf der Straße (bzw. Schiene) als Ort der eigentlichen Beförderungsleistung

- An der Haltestelle/„Überall“ in der Kommunikation mit dem Fahrgast

Abbildung 1 illustriert die wesentlichen IT-Systeme eines Verkehrsunternehmens in ihrem Zusammenspiel. In horizontaler Richtung ist dabei die (zeitliche) Gliederung in die Geschäftsprozess-Gruppen wiedergegeben, in vertikaler Richtung ist die räumliche Strukturierung angedeutet.

Einige der modellierten Geschäftsprozesse (z.B. Fahrplanerstellung) wurden auch schon vor der Einführung von IT-Systemen in den Verkehrsunternehmen durchgeführt, andere Prozesse (z.B. Optimierung, Dynamische Fahrgastinformation, elektronisches Ticketing) wurden erst mit der Einführung von IT-Systemen realisierbar. Heute sind alle beschriebenen Prozesse in der Regel durchgehend in IT-Systemen abgebildet.

Die Prozesse der Betriebslenkung sind in ihrer hier beschriebenen Form ebenfalls nur mit Hilfe von IT-Systemen durchführbar. Theoretisch denkbar ist die Betriebslenkung zwar auch auf Basis einer reinen Sprechfunk-Kommunikation zwischen Fahrzeugen und der Leitstelle, über die aktuelle Positionen gemeldet und Anweisungen gegeben werden. Ein solches Verfahren stößt jedoch sehr schnell an die Grenzen der Praktikabilität. Im Maßstab eines Verkehrsbetriebs praktisch flächendeckend einsetzbar wird die Betriebslenkung daher erst mit dem Einsatz von Datenfunk und IT-Systemen in Leitstelle und Fahrzeug.

Bild 1: Systeme des ITVU-Modells

Die im Folgenden näher betrachteten Systeme der Betriebslenkung sind in der Abbildung hervorgehoben. Es wird deutlich, dass in der Betriebslenkung sowohl zentrale als auch dezentrale Systeme beteiligt sind. Des Weiteren ist die Betriebslenkung vielfältig mit den anderen Prozessen und Systemen des Modells vernetzt:

- Die zugrundeliegenden Planungsdaten stammen aus den vorgelagerten Planungs- und Dispositions-Systemen.

- In der Kommunikation mit den Feldsystemen greifen Betriebslenkung und Fahrgastinformation auf dieselben Systeme (Funk) zurück.

- Auf dem Fahrzeug besteht eine Integration mit den Systemen des Ticketings.

- Die Betriebslenkung liefert Echtzeit-Daten für die Fahrgast-Information.

- Schließlich liefern die Systeme der Betriebslenkung Daten für die nachgelagerte Auswertung.

Die Verzahnung der Prozesse und Systeme legt eine Modellierung der zugrunde liegenden Daten in einem einheitlichen und übergreifenden Datenmodell nahe. Dieses objektorientierte Klassenmodell ist der Kern des ITVU Modells.

Das Klassenmodell enthält ca. 230 Klassen, die in ca. 30 Paketen gruppiert sind. Die Pakete sind wiederum zu 9 Funktionsbereiche zusammengefasst. Abbildung 2 zeigt die Struktur der Funktionsbereiche und Pakete.

Bild 2: Funktionsbereiche und Pakete des ITVU-Klassenmodells

Eine bestimmte Anwendung benutzt in der Regel einen ihr zugeordneten Teilbereich des Klassenmodells. Durch die ganzheitliche Modellierung ist damit gleichzeitig die logische Struktur der Schnittstellen zwischen den verschiedenen Anwendungen gegeben.

Die Prozesse und Systeme der Betriebslenkung beruhen auf Klassen des Funktionsbereiches „Steuerung“ (hervorgehoben in Abbildung 2), insbesondere auf den Paketen „Störungsmanagement“ und „Kommunikation“.

Wegen der zentralen Rolle der Betriebslenkung bestehen auch Beziehungen zu Klassen aus den meisten anderen Modellteilen.

Bei der Ausarbeitung des ITVU-Modells wurden die bereits vorliegenden Modellierungen auf deutscher und europäischer Ebene berücksichtigt. Für den Bereich der Betriebslenkung ist hier besonders zu nennen

- Das ÖPNV-Datenmodell des VDV (Verband Deutscher Verkehrsunternehmen) gemäß [6] und die darauf aufbauenden Modellierungen zu Plandaten-Schnittstellen ([7] und [8]) sowie zu Istdaten-Schnittstellen ([9] und [10])

- Die Arbeiten im Umfeld des VDV zur digitalen (Funk-)Kommunikation im ÖPNV [11] sowie zur generellen Funktionsbeschreibung von Betriebslenkungs-Systemen (itcs) [12].

- Das europäische Datenmodell Transmodel [14] sowie die darauf aufbauende Modellierung SIRI zu Istdaten-Schnittstellen [13].

3 Betriebslenkung – Kern-Geschäftsprozess im Verkehrsunternehmen

3.1 Grundlage: Plandaten

Ein Betriebsleitsystem beruht auf dem Fahr- und Dienstplan des jeweiligen Tages, in der Sprache des Klassenmodells sind das die Haupt-Klassen FahrtX, UmlaufX und DienstX (mehr dazu, insbesondere auch zum Suffix „X“ siehe Abschnitt 5.1). Außerdem benötigt das Leitsystem detailliertes Wissen über den Fahrweg und die einzelnen Strecken.

Ein Betriebsleitsystem importiert die Basisdaten im Normalfall aus einem Planungssystem. Sie werden dann – falls erforderlich - durch Bearbeitungsvorgänge angereichert und an dezentrale Geräte (Fahrzeugrechner, Verkaufsgeräte, DFI-Anlagen) verteilt. Für diesen gesamten Prozess hat sich die Bezeichnung Datenmanagement eingebürgert.

Mit den Fahrplan-Daten erhalten die Systeme der Betriebslenkung die Vorgabe, wie der Betrieb im ungestörten Fall ablaufen soll. Dieser Soll-Zustand wird mit dem tatsächlichen Betriebsgeschehen verglichen.

3.2 Ortung und Regelkreise

Die Basis für den Vergleich des tatsächlichen Betriebsgeschehens mit dem Fahrplan ist die kontinuierliche Ortung aller Fahrzeuge, d.h. die Feststellung der Position auf dem Liniennetz. Dazu kann es verschiedene Verfahren geben, angefangen von manueller Eingabe durch den Fahrer (nur an Haltestellen praktikabel), über eindimensionale Ortung entlang der bekannten Linienfahrwege mit Hilfe eines Wegimpulsgebers, bis hin zur heute üblichen Ortung mittels eines GPS-Empfängers. Dabei muss betont werden, dass ein GPS-Empfänger zunächst nur eine Geokoordinate liefert. Die verarbeitenden Systeme ermitteln daraus die Position auf dem Liniennetz.

Der nächste Schritt ist der ebenfalls kontinuierliche Soll-Ist-Vergleich, d.h. Ort und Zeit des Fahrzeugs im Liniennetz werden mit den Soll-Vorgaben lt. Fahrplan verglichen, es ergibt sich die sog. Fahrplanlage.

Weicht die Fahrplanlage (Ist) vom Fahrplan (Soll) ab, so ist dies eine Störung. Kern-Aufgabe der Betriebslenkung ist es, Störungen zu erkennen und durch geeignete dispositive Maßnahmen zu beseitigen.

Des Weiteren dient die aktuelle Fahrplanlage als Ausgangspunkt der dynamischen Fahrgastinformation, d.h. die Fahrgäste werden zeitnah über das aktuelle Beförderungsangebot informiert, auch wenn dieses aufgrund von Störungen vom veröffentlichten Plan abweichen sollte. Die Prozesse der Fahrgastinformation sind somit eng an die Betriebslenkung gekoppelt, werden aber im Folgenden nicht weiter betrachtet, da es sich um eine eigene Prozess-Gruppe des Modells handelt.

Die zentrale Aufgabe der Betriebslenkung besteht darin, den Fahrbetrieb so nahe am Plan zu halten wie irgend möglich. Abstrakt gesprochen geht es dabei um eine Aufgabe der Regelungstechnik:
Plan und Istwert müssen verglichen werden, um aus der Abweichung eine geeignete Aktion abzuleiten; über ein „Stellglied“ entsteht eine Wirkung, durch die sich Ist und Soll annähern.

Diese Aufgabe wird in der Betriebslenkung mit Hilfe von zwei Regelkreisen gelöst:

1. Die selbstregulierende Flottensteuerung auf dem Fahrzeug 

    Dieser Regelkreis läuft autonom an Bord des Fahrzeugs ab – daher ist dieser Mechanismus sogar anwendbar, wenn gar kein zentrales System vorhanden ist (sog.„fahrzeugautonomer Betrieb“).

2. Die zentralenbasierte Flottensteuerung

    Dieser Regelkreis arbeitet übergreifend über Fahrzeug und Zentrale und ergänzt den fahrzeugautonomen Regelkreis.

Abbildung 3 zeigt die beiden Regelkreise und ihr Zusammenspiel.

Basis beider Regelkreise ist die Ortung auf dem Fahrzeug und der Soll-Ist-Vergleich mit der Bestimmung der aktuellen Fahrplanlage.

Im Fahrzeugautonomen Regelkreis wird diese Fahrplanlage dem Fahrer angezeigt, der daraufhin – im Rahmen der zulässigen Möglichkeiten – für eine Korrektur sorgt, z.B. durch Verkürzung/Verlängerung von Haltezeiten oder durch Geschwindigkeits-Anpassung.

Bild 3: Regelkreise der Flottensteuerung

Nicht für jeden Regelungszweck genügt allerdings die Information, die das einzelne Fahrzeug besitzt. Sobald übergeordnete Aspekte ins Spiel kommen, muss die Leitstelle entscheiden. Sie kümmert sich um Anschlüsse, um die Einhaltung eines gleichmäßigen Takts über mehrere Fahrzeuge hinweg und greift in Störfällen ein.

Wir haben es also mit zwei verschiedenen Regelkreisen zu tun, die nach dem Subsidiaritätsprinzip arbeiten: Was auf der unteren Ebene erledigt werden kann, dringt gar nicht erst nach oben durch oder wird dort ausgefiltert.

Die beiden beschriebenen Regelkreise dienen zur Reaktion auf singuläre Störungen, wie z.B. Unfälle, hohes Verkehrsaufkommen etc. Daneben gibt es aber auch systematische Störungen des Betriebsablaufes. Beispielsweise kann es sein, daß eine Linie regelmäßig zu bestimmten Uhrzeiten verspätet ist, weil die Verkehrslage (z.B. morgendlicher Berufsverkehr) die Einhaltung der geplanten Fahrzeiten nicht zulässt.

Hier greift ein dritter Regelkreis. Nicht die einzelne Abweichung ist jetzt der Auslöser, sondern die statistische Häufung. Die Regulierung erfolgt auf der Ebene der Planung, also außerhalb der hier diskutierten Betriebslenkung. Das Betriebsleitsystem ist insofern beteiligt, als es einzelne Störungen aufzeichnet und Auswertemöglichkeiten anbietet.

3.3 Maßnahmen

Im äußeren Regelkreis der zentralenbasierten Flottensteuerung erfolgt der regelnde Eingriff der Leitstelle in Form von „dispositiven Maßnahmen“.

Diese Maßnahmen der Leitstelle bei Störungen können unterschiedlicher Natur sein:

- Automatische Maßnahmen können vom Leitstellen-System ohne manuelles Zutun des Leitstellen-Disponenten durchgeführt werden. Dazu gehören z.B. die Sicherung eines Anschlusses durch Zurückhalten des Abbringers bei Verspätung des Zubringers oder die Sicherung eines gleichmäßigen Linien-Taktes durch Verlangsamen eines Fahrzeuges, das auf einen Vorgänger aufläuft. Für derartige Maßnahmen werden in der Regel Grenzen festgelegt, über die hinaus das System nicht automatisch agieren darf, z.B. eine maximale Rückhaltezeit für einen Abbringer.

- Manuelle Maßnahmen, die nur durch den Leitstellen-Disponenten durchgeführt werden können, wie z.B. die Kurzwende eines Fahrzeugs vor Erreichen des planmäßigen Fahrweg-Endes (wg. Streckensperrung) oder der Einsatz eines Verstärker-Fahrzeugs bei erhöhtem Beförderungsbedarf.

Der letztgenannte „Verstärker“ ist ein Beispiel für eine dispositive Maßnahme zur Behebung einer Störung, die nicht allein aufgrund des Soll-Ist-Vergleichs erkannt werden kann: Das eigentliche Plan-Fahrzeug kann prinzipiell sogar pünktlich sein, bietet aber nicht genügend Kapazität (obwohl sich in der Praxis hier häufig zusätzlich eine Verspätung wegen erhöhter Fahrgast-Wechselzeiten ergeben wird). Aber auch bei dieser Maßnahme bleibt das Grundprinzip erhalten, dass die Betriebslenkung auf Basis eines Fahrplans arbeitet: Die Verstärker-Fahrt wird kurzfristig durch den Leitstellen-Disponenten in den Plan eingefügt und anschließend wie jede andere Plan-Fahrt durch die Regelkreise der Betriebslenkung kontrolliert.

4 Systeme der Betriebslenkung

Die wichtigsten Systeme der Betriebslenkung sind (vgl. auch Abbildung 1)

1. Die Leitstelle

In der Leitstelle wird dem Leitstellen-Disponenten die aktuelle Betriebs-Situation angezeigt. Dazu gibt es tabellarische Darstellungen (Betriebsübersicht, Störungsmeldungen...), schematisch-grafische Darstellungen (Linienleiter, Regionaldarstellung...) und die kartografische Darstellung (ggf. inklusive Satelliten/Luftbildern). Automatische dispositive Maßnahmen werden vom Leitstellen-System im Hintergrund ausgeführt und dem Leitstellen-Disponenten angezeigt, für die Durchführung von manuellen dispositiven Maßnahmen gibt es entsprechende Dialoge.

2. Kommunikation zwischen Leitstelle und Fahrzeug

Für die Betriebslenkung wird eine Online-Datenkommunikation zwischen Leitstelle und Fahrzeug benötigt, um Ortungs-Information zur Leitstelle und Anweisungen zum Fahrzeug zu übertragen. Dafür werden verschiedene Funkverfahren eingesetzt (analoger/digitaler Betriebsfunk, öffentlicher Mobilfunk). Die Datenübertragung erfolgt automatisch im Hintergrund durch das Leitstellen-System bzw. den Bordrechner zyklisch und/oder als Folge von Betriebsereignissen, es sind keine expliziten Bedienhandlungen zur Datenübertragung erforderlich.

Dasselbe Funksystem wird in der Regel auch zum Aufbau von Sprechfunk-Verbindungen zwischen der Leitstelle und einem oder mehreren Fahrzeugen benutzt. Die Bedienung des Sprechfunks ist dabei in die Oberflächen von Leitstelle und Bordrechner integriert. Aus Sicht der Betriebslenkung ist der Sprechfunk eine zusätzliche Kommunikation, die insbesondere in nicht standardisierbaren Betriebssituationen (Unfall, Notruf...) eingesetzt wird und in diesen Fällen auch sehr wichtig ist. Für die normalen Prozesse der Betriebslenkung jedoch ist der Datenfunk die primäre Kommunikation.

3. Bordrechner

Der Bordrechner ist das aktive Element der Betriebslenkung auf dem Fahrzeug mit einer Benutzer-Schnittstelle für den Fahrer [4]. Hier erfolgen Fahrer-Eingaben wie z.B. die Anmeldung auf eine Fahrt. Der Bordrechner ermittelt die Ortungs-Information, übermittelt diese über Datenfunk an die Leitstelle und stellt sie dem Fahrer zusammen mit Anweisungen der Leitstelle dar.

Darüber hinaus steuert der Bordrechner Fahrzeug-Peripherie (Anzeigen, Ansagen) und ist in vielen Fällen mit Ticket-Verkaufsgeräten vernetzt und/oder vereint die Verkaufsfunktion in einem Gerät zusammen mit den Betriebslenkungs-Funktionen.

5 Betriebslenkung im Klassenmodell

Im Folgenden werden drei Bereiche des ITVU-Klassenmodells vorgestellt, die von besonderer Bedeutung für die Betriebslenkung sind:

- Plan und Realisierung

- Ereignisse und Maßnahmen

- Kommunikation

Darüber hinaus macht die Betriebslenkung intensiven Gebrauch von folgenden Bereichen des Klassenmodells (vgl. Abbildung 2):

- Netz-und Fahrplanung gemäß Funktionsbereich „Angebot“

- Fahrzeug-Einsatzplanung gemäß Funktionsbereich „Umläufe“

- Personal-Einsatzplanung gemäß Funktionsbereich „Dienste“

Die Detail-Beschreibung dieser Modellteile ist Gegenstand der Prozeßbeschreibungen zur Angebots- und Ressourcenplanung, siehe [5], insbesondere Kapitel 6 und 7.

5.1 Plan und Realisierung (Fahrt/FahrtX)

Dieser Aspekt des Modells zeigt gleichzeitig ein fachliches Grundkonzept in der Modellierung von ITVU:

Im Modell wird unterschieden zwischen der Planung einer Fahrt und ihrer Ausführung, denn zu einer Planung gibt es im Allgemeinen viele Ausführungen: eine für jeden Firmenkalendertag (z.B. Donnerstag 16.12.2010), der zu der Tagesart (z.B. Donnerstags in Schulzeit) gehört, für die die Fahrt vorgesehen ist.

Zur Unterscheidung wird die abstrakte Planung als „Fahrt“ bezeichnet, die konkrete Fahrt an einen bestimmten Tag/Uhrzeit als „FahrtX“.

Dieses Konzept wird genauso für andere Klassen wie Umlauf, Dienst, Umlaufelement, etc. eingesetzt, d.h. es existiert jeweils eine „Schwesterklasse“ mit dem Namens-Suffix „X“ für die konkrete zeitliche Instanziierung.

Abbildung 4 zeigt als kleinen Modell-Auszug die Beziehungen zwischen Fahrt(X) und Umlauf(X).

Bild 4: Teilmodell: Fahrt(X) und Umlauf(X)

Hier wird auch deutlich, dass die konkreten zeitliche Instanziierungen erweiterte Eigenschaften gegenüber den abstrakten Planungen haben: Ein Attribut „Verspätung“ hat nur Sinn für einen konkrete FahrtX, nicht aber für eine geplante Fahrt, die beispielsweise an jedem Werktag einer Planperiode durchgeführt werden soll (und potenziell an jedem Tag eine andere Verspätung haben kann).

5.2 Ereignisse und Maßnahmen

In der Betriebslenkung wird mittels Maßnahmen in das Betriebsgeschehen eingegriffen. Die Maßnahme stellt die Reaktion auf ein Ereignis dar, das zu der Störung geführt hat.

Üblicherweise liegen vorbereitete Maßnahmen als Handlungsmuster vor („…wenn Streckensperrung an A, dann Umleitung über B-C...“), die im konkreten Fall umgesetzt werden können. Entsprechend wird hier wieder die Modellierung über Maßnahme (=Handlungsmuster) und MaßnahmeX (=konkrete Handlung) angewendet.

Es gibt verschiedenste Maßnahmen, je nach zugrunde liegendem Ereignis:

- Fahrt-Löschung

- Fahrt-Einfügung (insbes. als Verstärker)

- Fahrt-Verschiebung (zeitlich)

- Fahrweg-Veränderung (Kurzwende, Langwende, Umleitung,...)

- Fahrzeugwechsel

- Fahrerwechsel

Der Modellausschnitt in Abbildung 5 behandelt Maßnahmen, Ereignisse und Reaktionen.

Ein großer Teil des Modells befasst sich mit den diversen Spielarten von Maßnahmen und MaßnahmenX (abgekürzt als MNX-..). Im abstrakten Bereich ist die Gliederung relativ grob: Es wird nur unterschieden zwischen der MaßnahmeFahrtVerstärkung und Fahrweg- bezogenen Maßnahmen (MaßnahmeFahrweg). Bei der Konkretisierung wird entsprechend der obigen Liste von Maßnahmen stärker differenziert.

Bild 5: Teilmodell: Ereignisse und Maßnahmen (Störungsmanagement)

5.3 Kommunikation

Dieses Teilmodell behandelt die Kommunikation zwischen verschiedenen Systemen des ITVU-Modells. In der Betriebssteuerung wird es für die Modellierung der Kommunikation zwischen Leitstelle und Fahrzeugen verwendet. Das Modell macht keine spezifischen Annahmen über die verwendete Funk-Technologie.

Im Mittelpunkt des Kommunikationsmodells (Abbildung 6) steht der Teilnehmer. Teilnehmer kann eine natürliche Person sein, aber auch ein Fahrzeug, eine Haltestelle, ein Aufzug oder eine andere technische Einrichtung. Im linken Teil des Bildes sind exemplarische einige Klassen dargestellt, die aus Kommunikationssicht die Rolle eines Teilnehmers einnehmen können.

Bild 6: Teilmodell: Kommunikation

Der fachliche Adressraum eines Verkehrsunternehmens ist durch seine Internet-Domain abgrenzbar; die Beziehung zwischen AdressRaumFachlich und Verkehrsunternehmen drückt dies im Modell aus.

Das Modell sieht die Möglichkeit vor, Teilnehmer zu Gruppen zusammenzufassen (z.B. alle Fahrzeuge einer Linie). Die so entstehende TeilnehmerGruppe ist in vieler Hinsicht mit einem einzelnen Teilnehmer vergleichbar – insbesondere kann man sie auf die gleiche Weise adressieren wie einen einzelnen Teilnehmer. Um dies auszudrücken gibt es die gemeinsame, abstrakte Elternklasse KommunikationsPartner.

Damit ein Teilnehmer überhaupt erreichbar ist, muss er Zugang zu (mindestens) einem technischen Netz besitzen. In der Sprache des Modells: Er muss ein KommunikationsGerät benutzen, das zu einem bestimmten technischen Adressraum (AdressRaumTechnisch) gehört und innerhalb dieses Adressraums eindeutig identifiziert werden kann.

Das KommunikationsEreignis fungiert als abstrakte Oberklasse für DatenNachrichten und SprachVerbindungen.

6 Use Case Anschlußsicherung

An dieser Stelle soll beispielhaft ein Anwendungsfall („Use Case“) beschrieben werden. Damit soll auch gezeigt werden, wie im Branchenmodell ITVU die Klassenmodellierung und die Beschreibung der Systemlandschaft ineinandergreifen. Klassen-Bezeichner aus dem Klassenmodell sind im Folgenden durch die Schriftart hervorgehoben, Attribute und Funktionen sind zusätzlich kursiv gesetzt. Dies verdeutlicht auch, wie die Begriffe aus dem UML-Modell in eine sprachliche Beschreibung von Geschäftsprozessen einfließen können. In dieser Weise wird die Brücke geschlagen zwischen der formal strengen UML-Modellierung, wie sie für das Design von IT-Systemen unverzichtbar ist, und der mehr praxisorientierten verbalen Beschreibung von Geschäftsprozessen, die dem Anwender im Verkehrsbetrieb näher steht.

Als Beispiel aus der Betriebslenkung sei hier die Anschlußsicherung für einen geplanten Anschluss betrachtet.

Ein Anschluss ist die Definition einer Abhängigkeit von zwei Fahrten, bezogen auf einen bestimmten HalteOrt. Der ÖPV-Anbieter verspricht, dass ein Fahrgast, der auf einer Zubringerfahrt ankommt, für das Umsteigen in die Abbringerfahrt mindestens eine MinimaleUmsteigeDauer von X Minuten haben wird. Hat der Zubringer eine Verspätung, so muß der Abbringer ggf. warten, um dieses Versprechen einzuhalten. Damit dieses Warten aber nicht zu unvertretbaren Folgen im weiteren Fahrtverlauf des Abbringers führt, legt man zusätzlich bereits in der Planung die MaximaleWarteDauerAbbringer fest, d. h. man begrenzt das Warten auf eine Zeitspanne, die das wartende Fahrzeug innerhalb einer gewissen Zeit voraussichtlich wieder einholen kann.

Im Fahrbetrieb befinden sich nun Zubringer und Abbringer jeweils auf einer konkreten FahrtX, deren korrespondierende Fahrten in der Planung durch einen Anschluss verbunden sind.

Baut der Zubringer Verspätung auf (FahrtX.FahrplanLage), so greift zunächst unabhängig von der Anschlusssituation der fahrzeugautonome erste Regelkreis der Flottensteuerung (vgl. Abschnitt 3.2).

Gleichzeitig sind die Bordrechner beider Anschlusspartner Teilnehmer der Datenfunk- Kommunikation und melden ihre aktuelle FahrtX.FahrplanLage an die Leitstelle.

Die Anschlußüberwachung in der Leitstelle ist Teil des zweiten äußeren Regelkreises der Flottensteuerung. Sie berechnet aus den übermittelten Fahrplanlagen für den Zubringer die prognostizierte Fahrplanabweichung für die Ankunftszeit am Anschlussort (HaltBeiFahrtX.AbweichungIstSollAnkunft()) und für den Abbringer die prognostizierte Fahrplanabweichung für die Abfahrtszeit am Anschlussort (HaltBeiFahrtX.AbweichungIstSollAbfahrt()). Folgt daraus, daß die MinimaleUmsteigeDauer nicht eingehalten werden kann, so ist der Anschluss gefährdet.

Falls die MaximaleWarteDauerAbbringer ausreicht, um den Anschluss durch Zurückhalten des Abbringers zu sichern, dann löst das Leitsystem automatisch eine entsprechende MaßnahmeX aus, konkret eine MNX-Fahrtmodifikation. Als Folge wird an den Abbringer eine DatenNachricht geschickt. Inhalt der Nachricht ist die Änderung des HaltBeiFahrtX.AbfahrtZeitPunkt für den Anschlussort, so daß der Abbringer die Ankunft des verspäteten Zubringers abwartet.

Reicht die MaximaleWarteDauerAbbringer dafür nicht aus, so kann das Leitsystem keine automatische Sicherung des Anschlusses erreichen, es erzeugt aber eine entsprechende Störungsmeldung für den Leitstellen-Disponenten. Dieser kann manuell entscheiden, die entsprechende Maßnahme trotz der Verletzung der MaximaleWarteDauerAbbringer einzuleiten. Ggf. wird er vorher über Sprechfunk beim Fahrer des Zubringers anfragen, ob für den konkreten Anschluss überhaupt umsteigewillige Fahrgäste vorhanden sind.

Durch die übergreifende Modellierung ist die potenzielle Auswirkung der Anschlußsicherung auf die dynamische Fahrgastinformation implizit berücksichtigt, da die durch die MaßnahmeX veränderte FahrtX des Abbringers auch Basis der Fahrgastinformation ist.

Diese Darstellung gibt einen kleinen Einblick in die Modellierung der Anschlußsicherung. In ähnlicher Weise können im ITVU-Modell verwandte Use Cases beschrieben werden, wie z.B.

- Spontane Anschlußsicherung (ohne Vorplanung auf Einzelfahrt-Ebene)

- Anschlußsicherung mit externem Zubringer/Abbringer mittels betriebsübergreifender Leitsystem-Kopplung unter Nutzung der VDV453-ANS-Schnittstelle (siehe [9]) oder der SIRI-CM-Schnittstelle (siehe [13])

7 Modellierungs- und Dokumentations-Methodik

Das gesamte ITVU-Modell ist als objektorientiertes Klassenmodell in der Modellierungsprache UML 2.0 (Unified Modeling Language) beschrieben [15].

Funktionsbereiche sowie Pakete wurden im Sinne der UML als „Pakete“ (hierarchisch geschachtelt) modelliert.

Alle Klassen des Modells wurden jeweils beschrieben mit

- Name

- wichtigen Attributen

- Beziehungen zu anderen Klassen/Paketen

- Methoden (Funktionen)

- textueller Erläuterung

Zur Modellierung der Beziehungen zwischen den Klassen und Paketen wurden folgende Elemente der UML benutzt

- Vererbung

- Freie Beziehungen unterschiedlicher Kardinalität

- Beziehungsklassen

- Aggregationen

- Interface-Vererbung

- Entwurfsmuster (Design Patterns)

Die Darstellung des Modells erfolgt als UML-Klassendiagramm. Hierbei wird unterschieden zwischen dem Gesamtmodell und den Teilmodellen.

Zum Gesamtmodell gehören folgende grafische Darstellungen:

- Paketübersicht: alle Pakete, jeweils mit Name und Liste der Klassen; optische Anordnung nach Modellbereichen

- Kernmodell: die wichtigsten Klassen (ca. 25) und ihre Beziehungen (ca. 40)

- Hauptmodell: ca. 70 Klassen (incl. Attribute, Funktionen, Legende) und deren Beziehungen; die restlichen Klassen sind pauschal als Pakete aufgelistet; das Kernmodell ist im Hauptmodell enthalten.

- Kompaktmodell: gleicher Umfang wie das Hauptmodell, jedoch wird von jeder Klasse nur der Name angezeigt

Teilmodelle beschreiben jeweils die Klassen eines Pakets. Zusätzlich enthalten sie diejenigen Klassen anderer Pakete, zu denen irgendeine Klasse des betreffenden Pakets eine direkte Beziehung hat.

Als Modellierungswerkzeug für das ITVU-Modell wurde „Enterprise Architect“ (EA) der Firma Sparx System (www.sparxsystems.at) eingesetzt.

Die vollständige Dokumentation des Modells mit ausführlichen Erläuterungen zu allen Funktionsbereichen (u. A. die hier behandelte Betriebslenkung) ist im Buchhandel erhältlich[5].

8 Literatur

[1]    BRAUER, K. (1986). Informationswesen der Verkehrsbetriebe. Duncker +Humblot, Berlin

[2]    BECKER, G.(HRSG.) (Mai 1994) Einsatz neuer Informations- und Leitsysteme in Verkehr, Prozessführung, Fertigung. 3. Internationaler Workshop Leitwarten, Köln

[3]    EBNER, A. (2005) Selbstorganisierende Datenfunknetze für Anwendungen im Strassenverkehr. Cuvillier-Verlag, Göttingen

[4]    SCHOLZ, G.; DOHMEN,C. (2004). Fahrzeugrechner mit deutlich erweitertem Leistungsspektrum. Der Nahverkehr 22(12), S. 54-57.

[5]    SCHOLZ, G. (2011). IT-Systeme für Verkehrsunternehmen, UML-Modellierung von Geschäftsprozessen und Daten im öffentlichen Personenverkehr, dpunkt.verlag Heidelberg (in Vorbereitung)

[6]    VDV-Schrift 450 (08/1996). ÖPNV-Datenmodell Version 4.1 Teile A/B/C, Verband Deutscher Verkehrsunternehmen (VDV), Köln

[7]    VDV-Schrift 452 (03/2008). ÖPNV-Datenmodell 5.0 "Schnittstellen-Initiative" VDV- Standardschnittstelle Liniennetz/Fahrplan, Version: 1.4, Verband Deutscher Verkehrsunternehmen (VDV), Köln, Ausschuss für Informationsverarbeitung (AIV), Arbeitsgruppe ÖPNV-Datenmodell

[8]    VDV-Schrift 455 (03/2005). ÖPNV Datenmodell 5.0 "Schnittstellen-Initiative" VDV- Standardschnittstelle Dienstplan, Version: 1.0a, Verband Deutscher Verkehrsunternehmen (VDV), Köln, Ausschuss für Informationsverarbeitung (AIV), Arbeitsgruppe ÖPNV-Datenmodell

[9]    VDV-Schrift 453 (03/2008). Ist-Daten-Schnittstelle Anschlusssicherung, Dynamische Fahrgastinformation, Visualisierung, Allgemeiner Nachrichtendienst, Version 2.3, Verband Deutscher Verkehrsunternehmen (VDV), Köln, Ausschuss für Informationsverarbeitung (AIV)

[10]    VDV-Schrift 454 (03/2008). Ist-Daten-Schnittstelle Fahrplanauskunft, Version: 1.2, Verband Deutscher Verkehrsunternehmen (VDV), Köln, Ausschuss für Informationsverarbeitung (AIV)

[11]    VDV-Schrift 423 (2011). Digitaler Standard für Telekommunikation im ÖPNV (DISTEL- ÖV), Teile 1-5, Verband Deutscher Verkehrsunternehmen (VDV), Köln, Ausschuss für Informationsverarbeitung (AIV), Unterausschuss „intermodale transport control systems“ (itcs), (in Vorbereitung)

[12]    VDV-Schrift 730 (2011). Funktionale Anforderungen an ein itcs - Leitfaden für die itcs- Ausschreibung, Verband Deutscher Verkehrsunternehmen (VDV) Köln, Ausschuss für Informationsverarbeitung (AIV), Unterausschuss „intermodale transport control systems“ (itcs), (in Vorbereitung)

[13]    SIRI Technical Specification (2006). Public transport - Service interface for real-time information relating to public transport operations - Parts 1/2/3: prCEN/TS 15531-1, prCEN/TS 15531-2, prCEN/TS 15531-3, CEN EUROPEAN COMMITTEE FOR STANDARDIZATION, Brüssel

[14]    Transmodel (2001). The European Reference Data Model for Public Transport V5.0, revised ENV 12896, CEN EUROPEAN COMMITTEE FOR STANDARDIZATION, TC278/WG3, Brüssel

[15]    SEEMANN, J.; VON GUDENBERG, W. (2006). Software-Entwurf mit UML 2. Springer, Berlin