Anweisung für Intervalle ermöglichen

[GNock]

Guten Morgen Forum,

ich möchte heute eine vorstellen, die ich seit einiger Zeit im Hinterstübchen habe.

Beim Bedienen einer Relation von Taktpunkt zu Taktpunkt wird der Fahrplan manchmal nicht mehr eingehalten, wie ich mit folgendem Sachverhalt kurz beschreiben möchte:

Die RE Hannover-Bremen fahren mit einer Wartezeit 40-60 Sekunden und bedienen auf dieser Strecke sieben Haltepunkte.
Durch Akkumulation kommt es manchmal zu Verspätungen, die üblicherweise am nächsten Taktpunkt (hier in Bremen) ausgeglichen werden.
Aber in Bremen sind Verspätungen wegen des Gleisbildes manchmal kritisch.

In der Realität holt der Lokführer verspätete Zeit durch höheres Tempo (im Rahmen der erlaubten Höchstgeschwindigkeit) wieder auf - in BAHN fehlt dieser Lokführer, der die Entscheidung über die Geschwindigkeit trifft bzw. umsetzt.

Aufgrund der schönen Regelmäßigkeit dieser Relation den ganzen Tag über bot es sich an, die Position der Züge zu einem bestimmten Zeitpunkt zu ermitteln. An dieser Position habe ich zur Einhaltung des Fahrplans eine Lafa mit einer Anweisung eingebaut, die sich vielleicht in eine kürzere allgemeingültige Form bringen lässt. Befahren die Züge diese Position vor dem Zeitpunkt, fahren sie mit ihrer planmäßigen Geschwindigkeit weiter. Bei Verspätung wird ihr Tempo durch eine Lafa um 10 km/h erhöht. Die Anweisung in der Linienliste der Lafa:

R124(z=6:21-6:22 +7:21-7:22 +8:21-8:22 +9:21-9:22 +10:21-10:22 +11:21-11:22 +12:21-12:22 +13:21-13:22 +14:21-14:22 +15:21-15:22 +16:21-16:22 +17:21-17:22 +18:21-18:22 +19:21-19:22 +20:21-20:22 +21:21-21:22 +22:21-22:22 +23:21-23:22 +0:21-0:22 +1:21-1:22)

Der Gedanke: Lässt sich dieser Rattenschwanz durch eine erweiterte Bedingung so kurz darstellen, dass er auch bei halbstündigen Zugverkehren übersichtlich bleibt? Für das Beispiel habe ich den Kleinbuchstaben "i" für Intervall genommen, denn durch seinen aufgesetzten Punkt ist er eigentlich ganz gut erkennbar, im Gegensatz zu seinem Bruder bei den Großbuchstaben. Es ließe sich aber auch "p" für "Plan" nehmen.

R124(z=6:21-1:21, i=01+60)

<Erläuterung>
Die erste Ziffer nach dem "i" bezeichnet die Dauer der Gültigkeit ab Intervallbeginn (eine Minute ab 6:21, 7:21, 8:21 ... 1:21), die zweite Ziffer die Zeit bis zum nächsten Intervall.
Diese Anweisung gilt für alle Züge der Linie R124, die die Lafa im Zeitraum 6:21-6:22 ("i=01+..") bis 1:21-1:22 stündlich (i=..+60) befahren. Sie erhalten dann die für ihre Kategorie und Gattung eingestellte Geschwindigkeit.
<Erläuterung Ende>

Soweit erstmal das Grundgerüst meiner Anregung – die Syntax ist allerdings suboptimal, denn zum einen ist die Bedingung „i“ (oder „p“) nicht eigenständig, sondern eine Erweiterung der Bedingung „z“, zum anderen teilte JanBo mir mit, dass Intervalle in Fahrplänen meist in (eckigen) Klammern angegeben werden. Diese Vorgaben sollten auch in die Anweisung eingebracht werden. Deshalb liste ich ein paar Varianten auf, damit wir vielleicht auch die Syntax ermitteln können, die für das Verständnis der Anweisung am besten ist (sofern JanBo die Idee in BAHN umsetzt). Weitere Vorschläge für die Liste sind sehr erwünscht.

• a) R124(z=6:21-1:21[60,1])
  b) R124(z=6:21-1:21[60/1])
  c) R124(z=6:21-1:21[60;1])
  d) R124(z=6:21-[60,1]-1:21)
  e) R124(z=6:21[60,1]1:21)
  f) R124(z=6:21(60,1)1:21)

Mein Favorit ist Variante a).

Ein weiteres Fahrwegelement, bei dem die Anweisung gut genutzt werden kann, ist die Verzweigungsweiche. Ich nenne als Beispiel die U3 in Hamburg mit den Endbahnhöfen Barmbek auf der einen sowie Billstedt und Mümmelmannsberg auf der anderen Seite. Tagsüber fährt die U3 im 5-Minuten-Takt und hält in Billstedt abwechselnd an Bahnsteig 1 (von da weiter nach Mümmelmannsberg) und an Bahnsteig 2 (von da zum Kehrgleis). Belegt man die Eingabezeilen der Weiche mit

Fahrtrichtung 1: keine Anweisung
Fahrtrichtung 2: U3(z=8:55-15:35 + 19:05-21:25[10,2])

so wird der Fahrplan erfolgreich umgesetzt:
Alle Züge der Linie U3 fahren nach Mümmelmannsberg außer den Zügen, die die Weiche in den Zeiträumen 8:55 – 15:35 und 19:05 – 21:25 im 10-Minuten-Takt mit einer Toleranz von +2 Minuten befahren – diese Züge enden in Billstedt.

Das Beispiel zeigt auch, warum ich Variante a) bevorzuge : Wie in BAHN üblich lassen sich so auch mehrere Zeiträume durch das „+“-Zeichen in einer Anweisung zusammenfassen.

Schöne Grüße
Gerd

[Rolf R]

Moin Gerd,

keine schlechte Idee. Auf jeden Fall könnte man somit einige Takt-, Rangier-Punkte [etc.] etwas übersichtlicher gestalten, was die Anzahl der Einträge betrifft.
Falls es programmiertechnisch und möglich & machbar ist, wäre ich auch für den Lösungsvorschlag "a)", weil hiermit keine weiteren Kompromisse bezüglich der Vergleichbarkeit mit den bestehenden Einträgen gemacht werden müssten und man hier nicht großartig neue Wege gehen müsste.

(wobei ich auch mit einem anderen Sonder- bzw. Trennzeichen für die Intervallkennung leben könnte - sprich "b)" oder "c)")

Die Vorschläge "d)" bis "f)" halte ich nicht so für sinnvoll, weil schon mit einem Zeitintervall 2 einzelne Zeitdaten im Raum stünden. Würde man die dann noch mit anderen Intervallen verknüpfen, würden zuviel einzelne Zeitdaten in der Klammer stehen.
Beispiel: R124(z=6:21[60,1]1:21+6:51[60,1]8:51+15:51[60,1]18:51) als Taktverstärkung im Berufsverkehr.

"a)" bis "c)" vermitteln da eine offensichtliche Hierarchie
Beispiel: R124(z=6:21-1:21[60,1]+6:51-8:51[60,1]+15:51-18:51[60,1]) für das oben genannte Taktverstärken. -> ist für mich nachvollziehbarer, weil übersichtlicher.

....falls machbar und überhaupt möglich....

Gruß an die Alster
Rolf

P.S.: Gerd, ich hoffe mal, dass Du nichts dagegen hast, dass ich Deine Intervall-Vorschlagsdaten für die Beispiele verwende

[GNock]

P.S.: Gerd, ich hoffe mal, dass Du nichts dagegen hast, dass ich Deine Intervall-Vorschlagsdaten für die Beispiele verwende

Also Rolf, duuh hast ja Ideen, einfach meine Daten zu verwenden - hat mich viel Mühe gekostet, sie mir auszudenken. Aber nach Rücksprache mit meiner Rechtsabteilung sind sie denn jetzt zur allgemeinen Verwendung freigegeben

Übrigens, dein Beispiel R124(z=6:21-1:21[60,1]+6:51-8:51[60,1]+15:51-18:51[60,1]) zeigte prinzipiell auf, dass meine Idee nicht ganz durchdacht war, denn bei

U3(z=8:55-15:35 + 19:05-21:25[10,2])

würde BAHN die Auswertung bei jeder U3 mit TRUE abbrechen, die im Zeitraum 8:55-15:35 z.B. eine Weiche befährt, und die Anweisung ausführen. Geht natürlich auch, aber für eine Taktverstärkung in dem Zeitraum ist die Syntax zu ändern in

U3(z=8:55-15:35[10,2] + 19:05-21:25[10,2])

Ein fröhliches "hi" ins Wildwest
Gerd

P.S.: Rolf, wenn du die Zeiträume in deinem Beispiel so in BAHN eingibst, erhältst du Fehler 762. Vielleicht solltest du hieran noch ein ganz klein wenig arbeiten

[Christopher Spies]

Hallo Gerd,

die Angabe von Wochentagen ist bei Zeitangaben ja optional. Wie wäre es also, einfach auch die Angabe der Stunde optional zu machen? Dann könnte man Dein obiges Beispiel so schreiben:

Code: Alles auswählen

R124(z=:21-:22)

Rechteckige Klammern als zusätzliche Symbole wären dann nicht erforderlich. Freilich wäre diese Lösung weniger flexibel als die hier von Anderen vorgestellten.

Gruß
- Christopher

[Rolf R]

Hallo Christopher & Gerd,

in Deinem Beispiel müsste es dann aber noch eine Möglichkeit geben, die Stunden einzugrenzen. Ansonsten würde die Anweisung ja immer für den ganzen Tag gelten (ggf. incl. der Einschränkungen auf die Wochentage).
Für den einzelnen Befehl würde es also in dieser Hinsicht keinen Vorteil bedeuten, wobei allerdings im Falle von mehreren, einzelnen Intervallen durchaus Einsparpotential gewonnen werden könnte:

Bsp. L1(z=:21-:22,h=4-6+15-17) für die Intervalle 4:21-4:22+5:21-5:22+6:21-6:22+15:21-15:22+16:21-16:22+17:21-17:22), wobei man den Buchstaben "h" ggf. durch einen noch nicht von BAHN verwendeten ersetzen könnte.

@Gerd:

Das mit der Fehlermeldung hab' ich befürchtet . Allerdings hatte ich auch keine Testschaltung geplant (BAHN hatte ja selbst bei fehlerloser Syntax sicherlich eine Fehlermeldung geschickt, weil es ja mit der Klammer noch nix anfangen kann), sondern das ganze nur als "bildliche" Unterstützung für meine Argumentation angesehen.

Grüße aus dem Wilden Westen
Rolf

[GNock]

die Angabe von Wochentagen ist bei Zeitangaben ja optional. Wie wäre es also, einfach auch die Angabe der Stunde optional zu machen? Dann könnte man Dein obiges Beispiel so schreiben:

Code: Alles auswählen

R124(z=:21-:22)

Rechteckige Klammern als zusätzliche Symbole wären dann nicht erforderlich. Freilich wäre diese Lösung weniger flexibel als die hier von Anderen vorgestellten.

Hallo Christopher, du schreibst ganz richtig, dass diese Lösung nicht flexibel genug ist, denn die Syntax
U3(z=8:55-15:35 + 19:05-21:25[10,2])
wäre so nicht einsetzbar.

Weiter geht es auch darum, meinen Vorschlag für alle Funktionselemente zur Verfügung zu haben, also die Bedingung "z=" nicht nur in einer Lafa oder einer Weiche zu nutzen, sondern auch in einem Datenwechsel oder Rangierpunkt mit dem Parametern "L=" einsetzen zu können.

Und wie Rolf bereits antwortete, enthält deine Variante einerseits keine Zeitbeschränkung. Außerdem fehlt die Taktung des Intervalls, z.B. alle zwei Stunden oder jede halbe Stunde - diese Parameter müssen folglich unbedingt vorhanden sein.

Zuguterletzt: Zeitangaben in Funktionselementen werden im gewohnten Format hh:ss genutzt (eine der wenigen Ausnahmen ist die Wartezeitliste unten im Haltepunkt). Änderungen dieses Formats, besonders wenn sie dann noch mit Wochentagen kombiniert werden sollen, wären sehr verwirrend. Und würden es für JanBo erforderlich machen, die Routine zur Auswertung der Zeitdaten in den Eingabezeilen zu modifizieren.

@Rolf, der letzte Absatz gilt auch für dein Beispiel. Ich denke, die Einsparung von ein paar Zeichen in der Eingabezeile wiegen den meiner Ansicht nach vorhandenen Nachteil nicht auf, dass wir uns an zwei verschiedene Stunden:Minuten-Formate gewöhnen müssten.

Grüße von der Waterkant
Gerd

[Rolf R]

Moin Gerd,

@Rolf, der letzte Absatz gilt auch für dein Beispiel. Ich denke, die Einsparung von ein paar Zeichen in der Eingabezeile wiegen den meiner Ansicht nach vorhandenen Nachteil nicht auf, dass wir uns an zwei verschiedene Stunden:Minuten-Formate gewöhnen müssten.

Da bin ich Deiner Meinung. Aber was wäre, wenn man das Pferd an dieser Stelle von der anderen Seite aufzäumt?
Die Intervall-Verarbeitung kann man ja eigentlich für alle Befehle verwenden in denen der Parameter "z=" oder "Z=" eingesetzt wird. Es gibt ja durchaus noch andere Einsatzmöglichkeiten - z.B. Ein-/Ausrücken, Geschwindigkeitsbegrenzungen, Taktpunkte [unterschiedlich lange Züge] etc.
Dies könnte durch einen neuen Parameter (z.B. "I=" oder "i=") geschehen, denen man dann auch separate Zeitformate wie Stunden und Minuten vorgeben könnte.
Die Frage ist aber hier, wie die Programmiersprache in der BAHN geschrieben ist (Jan schreibt ja, dass es "C" ist), mit Zeit-Daten umgeht bzw. wie BAHN diese Daten verarbeitet. Da wird Jan sicherlich im Programmtext etliche Abfragen/Schleifen etc. integriert haben.
Eine weitere Frage ist auch die nach der Kompatiblität zu den Vorgänger-Versionen von BAHN.

Lieben Gruß an die Waterkant
Rolf

[GNock]

Moin Rolf, Moin Moin an alle

Die Intervall-Verarbeitung kann man ja eigentlich für alle Befehle verwenden in denen der Parameter "z=" oder "Z=" eingesetzt wird. Es gibt ja durchaus noch andere Einsatzmöglichkeiten - z.B. Ein-/Ausrücken, Geschwindigkeitsbegrenzungen, Taktpunkte [unterschiedlich lange Züge] etc.

Richtig, die generelle Verwendbarkeit der Intervall-Bedingung gehört dazu, auch wenn eine intervallmäßige Behandlung bei etlichen Parametern (im Datenwechsel Daten genannt) nur sehr selten bis nie genutzt werden dürfte.

Dies könnte durch einen neuen Parameter (z.B. "I=" oder "i=") geschehen, denen man dann auch separate Zeitformate wie Stunden und Minuten vorgeben könnte.

Das "i" hatte ich ja in dem ersten Beispiel zur Beschreibung genommen, dabei aber als Ersatz noch das "p" erwähnt. Denn das "i" oder "I" kann sehr leicht mit der "1" oder mit klein-"L" verwechselt werden, besonders in anderen Schriftarten als Courier New.

Dass ich der Syntax a) R124(z=6:21-1:21[60,1]) den Vorzug gebe, hat drei Gründe:

1. Die Einfassung der Bedingung "60,1" - Intervalltakt 60 Minuten und jeweilige Bezugsdauer eine Minute - in (eckigen) Klammern verdeutlicht, dass diese Bedingung nicht alleine stehen kann, sondern immer nur in Verbindung mit einer anderen Bedingung - hier die zeitliche Begrenzung "z=".

2. Zudem spart man dadurch einen Buchstaben ein - und das wirkt sich schon positiv aus auf die Realisierbarkeit der hier geäußerten Wünsche nach mehr Möglichkeiten der Zugbeeinflussung. Zudem versucht JanBo nach Möglichkeit, den Daten einen Buchstaben zuzuordnen, der dem Begriff möglichst nahe kommt ("L" für Linie, "N" für Nummer). Und das nicht nur in deutsch, sondern auch in anderssprachlichen Alphabeten einschließlich des Russischen.

3. Die Verwendung der eckigen Klammern anstatt der runden macht diese Syntax übersichtlicher und ist auch konfliktfrei bei der Auswertung einer Anweisung mit deren runden Klammern.

Eine weitere Frage ist auch die nach der Kompatiblität zu den Vorgänger-Versionen von BAHN.

Hier sehe ich kein Problem, da die Anweisungen, die in älteren Netzen die Züge beeinflussen, in neueren BAHN-Versionen ohne Einschränkung weiterhin verstanden und umgesetzt werden.

Die Waterkant dankt für die Grüße
Gerd

[Seb144]

Hallo zusammen,

um mal auf die Ausgangssituation zurück zu kommen:

Beim Bedienen einer Relation von Taktpunkt zu Taktpunkt wird der Fahrplan manchmal nicht mehr eingehalten, wie ich mit folgendem Sachverhalt kurz beschreiben möchte:

Die RE Hannover-Bremen fahren mit einer Wartezeit 40-60 Sekunden und bedienen auf dieser Strecke sieben Haltepunkte.
Durch Akkumulation kommt es manchmal zu Verspätungen, die üblicherweise am nächsten Taktpunkt (hier in Bremen) ausgeglichen werden.
Aber in Bremen sind Verspätungen wegen des Gleisbildes manchmal kritisch.

In der Realität holt der Lokführer verspätete Zeit durch höheres Tempo (im Rahmen der erlaubten Höchstgeschwindigkeit) wieder auf - in BAHN fehlt dieser Lokführer, der die Entscheidung über die Geschwindigkeit trifft bzw. umsetzt.
...
Bei Verspätung wird ihr Tempo durch eine Lafa um 10 km/h erhöht. Die Anweisung in der Linienliste der Lafa:

Ich finde die Idee von Dir gut, sehe aber zwei Nachteile:
a) Bei unregelmäßigen Takten kann man den "Rattenschwanz"nicht kürzen.
b) Ist auf der Strecke irgendwo eine für alle Züge gültige Langsamfahrstelle (z.B. Brücke), müsste danach wieder
so eine Langsamfahrstelle mit (zeitlich angepassten) Intervallen gesetzt werden, damit die Verspätung weiter abgebaut
wird, sodass der Aufwand recht hoch wird.

Für den Benutzer erscheint es mir einfacher, wenn stattdessen zwei zusätzliche Funktionen eingeführt würden:

1. Einführen einer Richtgeschwindigkeit
Das gab's mal bei der DR als "energetische Richtgeschwindigkeit". Z. B. war auf einer Strecke vmax=120 km/h,
der Fahrplan aber für 100 km/h (Richtgeschwindkeit) berechnet, sodass 120 km/h nur bei Verspätungen zu fahren
waren.
Fahrzeitreserven sind ja heute auch noch in der Form vorhanden, ich denke nur z. B. an Hannover - Berlin, da wird
auch nicht immer mit 250 km/h gefahren.

2. Einführung eines Zugstatus "verspätet"
Kommt ein Zug an einem für ihn gültigen Taktpunkt verspätet an, könnte der Status verspätet gesetzt werden.
Dieser wird wieder gelöscht, wenn er am nächsten Taktpunkt pünktlich ankommt oder einrückt.

Damit würde dann ein Zug bei einer in den Zugdaten eingetragenen Richtgeschwindkeit sich an diese halten und nur
bei Status "verspätet" die Streckenhöchstgeschwindigkeit fahren. Die Ausgangssituation wäre damit realistisch
darzustellen und mit weniger Aufwand verbunden. Außerdem wäre es auch eine Lösung, die bei unregelmäßigen Takten
funktioniert, ohne solche "Rattenschwänze" eingeben zu müssen.

Die Richtgeschwindigkeit müsste dann auch per Datenwechsel verändert werden können (wie heute schon vmax), da diese
je nach Strecke ja verschieden sein kann.

Ob die Idee umsetzbar ist, kann ich leider nicht beurteilen. Falls das schon mal diskutiert wurde, sorry, aber die
Suchfunktion ergab kein sinnvolles Ergebnis.


Sebastian
_________________
Potsdam und Umgebung im Jahr 1989

http://www.bahnbln89.homepage.t-online.de

[Rednael_186]

Guten Abend,

erstmal möchte ich anmerken, dass mir die Idee solcher Intervalle sehr zusagt, da ich schon heute an Datenwechseln so etwas benutze, mir aufgrund des immensen Aufwands aber sogar ein kleines Programm geschrieben habe, welches mir die Einträge generiert...

Fragt jetzt aber bitte nicht, wozu zum ich diese Funktion nutze, das würde eine abendfüllende Veranstaltung, das hier zu erklären

Zu Deinem Einfall, Sebastian, allerdings ein Einwand:
Wie soll auf einer Strecke, die mit Haltestellen bedient wird (im Gegensatz zu Taktpunkten) festgestellt werden, ob der Zug pünktlich ist oder nicht?
Ich habe durchaus schon Netze gesehen, bei denen das dann ein "verspätetes" Fahren über knapp 100 km bedeuten würde.

Dieser Einwand nur, da Verspätungen ja oftmals eben nicht an Taktpunkten, sondern an Haltestellen mit variabler Haltezeit entstehen.

Schönen Abend noch,
Leander

[micha88]

Ich finde es unnötig aufwändig, erst variable Haltezeiten zuzulassen, um diese dann wieder über Geschwindigkeiten abzufangen – letztenendes kommt ja dann doch fast das gleiche heraus, als würde man feste Haltezeiten einstellen. Und wenn einmal Verspätungen entstehen, die über das Ausnutzen der maximalen Geschwindigkeit nicht mehr abgebaut werden können, hat man sowieso ein Problem. Beim Vorbild würde ein Disponent dann Kreuzungen bzw. Überholungen verlegen, ein anderes Gleis nehmen etc. Aber das kann man in größeren Netzen nicht mit vertretbarem Aufwand automatisiert in BAHN umsetzen. (Für wenige Strecken mit kleineren Bahnhöfen ist das sicher noch ganz gut über Signalanlagen machbar.)

Wenn es um Fahrzeitreserven geht, wird eigentlich nicht mehr mit Richtgeschwindigkeiten gearbeitet; stattdessen wird einfach Zeit aufgeschlagen, die der Lokführer in der Praxis dann umsetzt, indem er weniger stark beschleunigt bzw. vor allem den Zug ausrollen lässt, statt bis zum Schluss die Höchstgeschwindigkeit zu halten und dann stark zu bremsen. Statt einer Richtgeschwindigkeit müsste man also die Beschleunigungs- und Bremswerte ändern.... das macht die Sache nicht eben einfacher.

Dazu ist das alles eher für die Eisenbahn relevant. Straßenbahn und Busse können schlecht im laufenden Verkehr einfach langsamer fahren oder länger halten, um Pufferzeiten abzubauen, wenn es gut läuft

Die Idee von getakteten Intervallen als Zeitparameter finde aber trotzdem sehr interessant, besonders auch für den ÖPNV.

Zur Syntax könnte ich mir auch vorstellen, dass man das erste Intervall, die Taktzeit und die Anzahl der Wiederholungen dieses Intervalls angibt. Stellt sich die Frage, wie herum es besser ist...

[GNock]

Guten Morgen,

a) Bei unregelmäßigen Takten kann man den "Rattenschwanz"nicht kürzen.

Das ist richtig - hier gilt: Man kann nicht alles haben Für jeden Zug einer Linie, der nicht fest im Takt fährt (und das sind zur morgendlichen und abendlichen HVZ nicht wenige beim großen Vorbild) müsste man überlegen, ob man die Verspätung toleriert oder sich der Mühe unterzieht, diese zu beheben - wie bisher auch.

b) Ist auf der Strecke irgendwo eine für alle Züge gültige Langsamfahrstelle (z.B. Brücke), müsste danach wieder
so eine Langsamfahrstelle mit (zeitlich angepassten) Intervallen gesetzt werden, damit die Verspätung weiter abgebaut
wird, sodass der Aufwand recht hoch wird.

In einer solchen Situation würde ich erstmal überlegen, ob ich die Zeitaufholung nicht erst nach der Brücke beginne. Ist das nicht möglich, gibt es einen kleinen Trick: Man begrenzt das Tempo nicht mittels Lafa, sondern mit Vorsignal, Minus-Kontakt und Hauptsignal (alle unsichtbar) - das erspart den Aufwand nach passieren der Langsamfahrstelle, da die Züge dann automatisch ihre vorige Geschwindigkeit erhalten.

Für den Benutzer erscheint es mir einfacher, wenn stattdessen zwei zusätzliche Funktionen eingeführt würden:

1. Einführen einer Richtgeschwindigkeit

Ist das praktikabel? Auf besagter Strecke beträgt laut Deutsche Bahn Vmax=160 km/h, im beschriebenen Fall erhöhen verspätete Züge ihr Tempo aber nur moderat von 120 auf 130 - bei automatischer Nutzung der Vmax wären sie also viel zu schnell, und dann müsste das wieder abgefangen werden.

2. Einführung eines Zugstatus "verspätet"

Analog zu Leanders Antwort: Die Abfahrt beim letzten Taktpunkt (in Hannover) erfolgte pünktlich, die Verspätung passiert auf der Strecke nach Bremen und soll noch VOR der Ankunft dort behoben werden. In Bremen aber fährt er am Taktpunkt wiederum pünktlich ab.
-----------------------

Die "Verspätung" ist aber nicht die einzige Situation, die durch die erweiterte Bedingung "[...]" mit NUR EINER Anweisung für eine große Anzahl von Zügen behandelt werden kann. Gleiches gilt für Verfrühungen, da sich die Wartezeit (aktuell "H=40-60") per Datenwechsel erhöhen lässt, um eine vorzeitige Abfahrt am nächsten Haltepunkt zu verhindern: R124(z=6:21-1:21[60,1], H=60-70)
Diese Variante kann man vornehmlich dann einsetzen, wenn man die Strecken noch nicht durchgehend signalisiert hat und somit auch die Ausfahrsignale fehlen, die eine verfrühte Abfahrt verhindern.

Oder die erweiterte Bedingung "[...]" wird in einer Verzweigungsweiche genutzt, wie ich im Eröffnungsbeitrag für die U3 beschrieb.

Allgemein gesagt: "z=...[...]" sollte genauso universell eingesetzt werden können wie "z=..." allein.

Ich finde es unnötig aufwändig, erst variable Haltezeiten zuzulassen, um diese dann wieder über Geschwindigkeiten abzufangen – letztenendes kommt ja dann doch fast das gleiche heraus, als würde man feste Haltezeiten einstellen.

Aufwändig ja, aber für mich Teil meines Hobbys. Gerade durch variable Haltezeiten erreicht man ja gewissen interessante Aspekte im Simulationsablauf - und die damit verbundenen Begleiterscheinungen wie Verspätungen würzen diese zusätzlich. Und wenn man sich der Mühe unterzieht, kann man Abweichungen vom Fahrplan bisher auch schon abfangen, allerdings mit einem "Rattenschwanz" an Anweisungen. Und der wird für nicht gleichmäßig getaktete Linien weiterhin vonnöten sein.

Vielleicht hätte ich besagtes Problem für besagte REs ja nicht, wenn ich statt "H=40-60" nur 10 Sekunden für die Wartezeit - also "H=40-50" - genommen hätte, aber ich wollte es so

Die Idee von getakteten Intervallen als Zeitparameter finde aber trotzdem sehr interessant, besonders auch für den ÖPNV.

Siehe oben: Es geht auch um die universelle Verwendung dieses Zeitparameters.

Zur Syntax könnte ich mir auch vorstellen, dass man das erste Intervall, die Taktzeit und die Anzahl der Wiederholungen dieses Intervalls angibt. Stellt sich die Frage, wie herum es besser ist...

Die Diskussion über die Syntax ist Bestandteil dieses Themas.

Schöne Grüße
Gerd

[Jan Bochmann]

Guten Tag,

Die Idee von getakteten Intervallen als Zeitparameter finde aber trotzdem sehr interessant, besonders auch für den ÖPNV.

Zur Syntax könnte ich mir auch vorstellen, dass man das erste Intervall, die Taktzeit und die Anzahl der Wiederholungen dieses Intervalls angibt. Stellt sich die Frage, wie herum es besser ist...

Der Originalvorschlag ist m.E. besser, weil eher an die menschliche Art zu Denken angepaßt, die andere ist mehr Computerdenken:
Unter "von 6:00 bis 20:00 alle 20min für je 10min" kann man sich leichter etwas vorstellen als "ab 6:00 43mal für je 10min". Bei der Ermittlung der Anzahl würde man sich obendrein oft verrechnen.

Die Angabe der Endezeit ist aber auch diskussionswürdig: Wirklich korrekt wäre wohl beim obigen Beispiel eine Deutung "von 6:00-6:10 bis 19:40-19:50", d.h. 3*14 = 42 Wiederholungen, aber typisches Verständnis ist eher "6:00-6:10 bis 20:00-20:10", d.h. die zweite Zeitangabe begrenzt nicht wirklich das Intervall und die Wiederholungen, sondern meint den Beginn des letzten wiederholten Intervalls.

Grüße
Jan B.