Umlaufprüfung

In der Umlaufbildung früherer Visum-Versionen mussten Umläufe stets korrekt sein, das heißt, sie durften zum Beispiel weder Zeit- noch Ortsbrüche aufweisen. Dies hatte zur Folge, dass die Umläufe bei wesentlichen Änderungen im Netz (zum Beispiel an Fahrplanfahrten) gelöscht wurden. Dies ist insbesondere dann nicht tolerierbar, wenn Umläufe manuell durch einen Planer bearbeitet wurden und dadurch nicht ohne Weiteres durch erneute Ausführung der Umlaufbildung wiederherstellbar sind. In dem nun in Visum verfügbaren Umlauf-Datenmodell wird die Konsistenz der Umläufe zum Netz sichergestellt und dafür die jederzeitige Korrektheit des Umlaufs in sich nicht gefordert. Vielmehr haben Sie die Möglichkeit, mit Hilfe der Umlaufprüfung für jeden Umlauf einen Status mit Konsistenzinformationen zu berechnen (im Folgenden Fehlerflags genannt). Diese Fehlerflags geben Ihnen eine Information darüber, ob die Umläufe fehlerfrei sind und – falls nicht – in welchen Bereichen Inkonsistenzen auftreten. Es gibt insgesamt acht Fehlerflags.

Das Zustandsmodell in Abbildung 194 zeigt die möglichen Zustandsübergänge eines Umlaufs und wie die acht Fehlerflags dabei gesetzt werden.

Abbildung 194: Zustandsmodell für Umläufe

Ändert sich die Netzgrundlage, so reagieren die Umläufe darauf. Es werden Änderungen an der Umlaufversion, den Umlaufelementen und den Fahrplanfahrtabschnitten berücksichtigt. Außerdem reagieren Umläufe auf Änderungen der grundsätzlichen Netzeinstellungen, vor allem am Kalender.

• Ortsbruch (LocationFault)

Zwei in einem Umlauf aufeinander folgende Fahrten passen nicht zusammen, da die Nachfolgefahrt nicht am selben Haltepunkt beginnt, an dem die Vorgängerfahrt endet.

• Zeitbruch (TimeFault)

Zwei in einem Umlauf aufeinander folgende Fahrten überlappen sich zeitlich. Das bedeutet, die Vorgängerfahrt kommt später an als die Nachfolgefahrt abfährt.

• Wendezeitfehler (LayoverTimeFault)

Zwei in einem Umlauf aufeinander folgende Fahrten überlappen sich zeitlich nur dann, wenn bei der ankommenden Fahrt die Nachbereitungszeit und bei der abfahrenden Fahrt die Vorbereitungszeit miteinbezogen wird. Das bedeutet, dass die eingeplante Wendezeit nicht ausreichend ist. In der Praxis kann ein solcher Fehler manchmal ignoriert werden, was aber manuell zu prüfen ist. Sind die beiden Fahrten durch eine Zwangsbindung miteinander verbunden, wird die Einhaltung der Vor- und Nachbereitungszeit für diesen Übergang nicht geprüft, da die Zwangsbindung Vorrang hat.

• Fahrzeug falsch (VehicleFault)

Es gibt innerhalb des Umlaufs Fahrplanfahrtabschnitte, denen eine nicht zum Umlauf passende Fahrzeugkombination zugeordnet wurde. Dieser Fehler kann zum Beispiel auftreten, wenn die Umlaufbildung einen Umlauf für einen Standardbus berechnet hat und später manuell einem der Fahrtabschnitte ein Gelenkbus zugeordnet wird. Bei der Auswertung dieses Fehlers geht das Attribut Hat Fahrzeugaustausch ein. Dieses entscheidet, ob das Fahrplanfahrtabschnitts-Attribut Fahrzeugkombination oder Fahrzeugkombinations-Set für den Abgleich herangezogen wird.

• Umlauftags-Fehler (EmptyDayFault)

Gibt es einen leeren Umlauftag, so wird dieser Fehler gesetzt. Das bedeutet es gibt einen Umlauftag, an dem an keinem Kalendertag ein Umlaufelement (abgesehen von Stand-Elementen) liegt. Die Konsequenz dieses Fehlers ist, dass ein Fahrzeug zu viel eingeplant wurde.

• Grenzwertfehler (LimitFault)

Dieser Fehler tritt nur auf, wenn es benutzerdefinierte Umlaufelemente gibt. Wird innerhalb eines Umlaufs der definierte minimale Ladezustand unterschritten oder werden die definierten Zeit- oder Längengrenzwerte überschritten, wird das durch dieses Fehlerflag angezeigt.

• Zwangsbindungsfehler (ForcedChainingFault)

Es gibt im Umlauf einen Fahrplanfahrtabschnitt, der Ausgangspunkt einer gültigen Zwangsbindung ist, die aber im Umlauf nicht realisiert wird. Der Nachfolger dieses Fahrplanfahrtabschnitts im Umlauf ist also nicht der Ziel-Fahrplanfahrtabschnitt der Zwangsbindung.

• Fahrtrichtungsfehler (DirectionFault)

Es gibt im Umlauf entweder einen Fahrplanfahrtabschnitt, der an verschiedenen Tagen in umgekehrter Fahrtrichtung bedient wird, oder aber im Fall eines abgeschlossenen Umlaufs ändert sich die Fahrtrichtung des Fahrzeugs nach einem kompletten Durchlauf des Umlaufs. Dieser Fehler wird nur dann geprüft, wenn am Umlauf das Attribut Fahrtrichtung beachten wahr ist.

Besitzt ein Umlauf die Flags ungeprüft (unchecked) oder Zeitbruch oder Ortsbruch, so darf er nicht in nachfolgenden Auswertungen verwendet werden (zum Beispiel im Verfahren ÖV-betriebliche Kennzahlen). Die anderen sechs Fehlerflags hingegen schränken die Verwendbarkeit nicht ein. Dies ist notwendig, um auch Planungen aus anderen Systemen übernehmen und für die Linienleistungs- und -erfolgsrechnung im Verfahren ÖV-betriebliche Kennzahlen (Verfahrensbeschreibung ÖV-Umsetzmatrix) verwenden zu können, die häufig solche Fehler (teilweise gewollt) enthalten.

Gewöhnliche und forcierte Umlaufprüfung

Es können durch nachträgliche Netzänderungen zwei Arten von Inkonsistenzen zwischen Netzgrundlage und Umläufen entstehen, die in der gewöhnlichen Umlaufprüfung nicht gefunden werden. Um die Konsistenz in jeder Hinsicht zu prüfen, kann optional die so genannte forcierte Prüfung durchgeführt werden (Anwendung: Umlaufprüfung durchführen). Bei den beiden Inkonsistenzen handelt es sich um die folgenden:

• Bei Verwendung von verkürzten Wendezeiten kann es sein, dass ein Umlauf kein Fehlerflag anzeigt, obwohl er einen Wendezeitfehler (LayoverTimeFault) enthält. Dies ist dann der Fall, wenn nachträglich ein Wert in den drei die verkürzte Wendezeit beschreibenden Attributen (von Ihnen festlegbare Attribute des Haltepunkts beziehungsweise des Fahrtabschnitts für verkürzte Vorbereitungszeit, verkürzte Nachbereitungszeit und maximale Aufenthaltsdauer) vorgenommen wurde oder die Auswahl eines dieser Attribute geändert wurde. Der Grund hierfür ist, dass diese drei Attribute von Ihnen dynamisch festgelegt werden können (insbesondere können auch indirekte oder benutzerdefinierte Attribute verwendet werden). Aus Gründen der Rechenzeit ist es nicht effizient möglich, auf Änderungen in diesen Attributen zu reagieren und das Fehlerflag automatisch zu setzen. Deswegen müssen Sie die forcierte Variante der Umlaufprüfung ausführen um sicherzustellen, dass alle Wendezeitunterschreitungen (Zeitunterschreitungs-Fehler) in den geprüften Umläufen ermittelt werden, wenn nachträgliche Änderungen stattgefunden haben. Werden keine verkürzten Wendezeiten benutzt (Eigenschaft der Umlaufversion), kann dieses Problem nicht auftreten.
• Nachträgliche Änderungen im Netz führen nicht zu Anpassungen eventuell davon betroffener Leerfahrten (zum Beispiel bei Änderungen von ÖV-Fahrzeiten auf Strecken oder beim Sperren von Strecken für ein ÖV-Verkehrssystem). Somit können sogar Orts- oder Zeitbrüche unentdeckt bleiben. Auch hier ist aufgrund der Rechenzeit keine Reaktion der Umläufe auf die Netzänderung möglich. Deshalb kann erst durch eine forcierte Prüfung sichergestellt werden, dass solche Fehler nicht in den Umläufen enthalten sind, wenn nachträglich das für Leerfahrten benutzte Netz verändert wurde.