Chaosfaktor differenzieren

[Sebastian Leonow]

Hallo,

ich habe nach einigen frustvollen Erlebnissen mit der echten Bahn mal den Chaosfaktor etwas erhöht, bin aber mit dem Ergebnis nicht so ganz zufrieden. Der Regler steht bei mir gerade auf 5% und es hagelt Ersatzsignale ohne Ende. Das man aber tatsächlich mal vor einem Hp0 wartet, weil die Strecke noch belegt ist, lässt sich kaum erreichen. Selbst in Knoten wie Köln, Kassel, Lehrte oder Altenbeken kam das jetzt in den letzten ca. 30 Fahrten nicht vor, abgesehen von kompletten Deadlocks. Gefühlt konnte Zusi 2 das besser, was wahrscheinlich völliger Mumpitz ist.

Mein Wunsch wäre, Infrastruktur und Betriebsablauf bzgl. des Chaosfaktors zu trennen. Dann könnten einerseits die dauernden Zs1 und Zs7 je nach Belieben etwas reduziert werden, andererseits die KI Züge z.B. mal ne Minute länger zum Fahrgastwechsel brauchen, so dass man dann mit dem eigenen Zug vor dem Esig steht.
Ob und wie das programmtechnisch geht, kann ich natürlich nicht einschätzen, wollte den Wunsch nur mal absetzen.

Gruß
Sebastian

[Selbstblock]

Schönen Guten Morgen,

ich möchte mich an der Stelle meinem Vorredner anschließen. Auch wenn man munkelt, dass Ersatzsignale bei der Bahn keine Fake-News sind, muss auch ich gestehen, dass es ein wenig ernüchternd ist, dass es in Zusi häufig nur hierdurch zu gewissem Chaos in der eigenen Fahrt kommt. Klar, auch in echt kann es mal sein, dass auf einer Stecke einmal häufiger Ersatzsignale auftauchen. Nur denke auch ich, dass Zusi seine Möglichkeiten hier noch nicht voll ausschöpft, bzw. dass es hier auch mehr Möglichkeiten braucht.
Den Ansatz, dass auch das rollende Material ein wenig für Chaos sorgt, finde ich an der Stelle sehr gut. Wenn z.B. der Autopilot mit einer gewissen Wahrscheinlichkeit P eine oder zwei Minuten länger am Bahnsteig hält (Fahrgastwechsel nicht abgeschlossen), oder beispielsweise nicht auf Streckengeschwindigkeit beschleunigt sondern nur auf 60 km/h oder 80 km/h (Schaden am Zug, Sturmwarnung, zu viele betrunkene Fahrgäste, usw...), dann ist die Strecke davor länger belegt und man würde auch unterwegs einmal z.B. auf einen Halt zeigenden Streckenblock auffahren.
Auch in Zusammenhang mit der Möglichkeit, Zusi mittelfristig ein Stück weit das (falsche ) disponieren beizubringen, wäre das schon ein gewisser Anfang.

Noch ein Gedanke: Wenn der oben genannte Zufallswert des Autopiloten ermittelt wurde, könnte es ja auch eine programminterne Kommunikation mit dem Zusi-FDL geben. So könnte beispielsweise eine S-Bahn vor dem sonst viel schnelleren ICE fahren, bzw. vorgelassen werden. Oder aber der entsprechende Fahrweg ist schon gestellt und alle müssen auf die Abfahrt von Zug xy warten. Ergo: Auch mehr Abwechslung für den Spieler, der gerade vor seinem Computer sitzt und dann hinter einem Bummel-ICE selbst hinterher bummelt.

Ich denke, an der Stelle gäbe es viele Möglichkeiten, für ein Stück weit mehr Abwechslung zu sorgen, mitunter ist die eine Möglichkeit leichter umzusetzen, als die andere. Das Gesamtergebnis würde das Spielerlebnis jedoch signifikant verbessern.

Viele Grüße und einen schönen Tag

[oberstrom (Markus)]

Hallo,

ich schließe mich dem Wusch auch an. Bei den Abläufen gibt es in Zusi definitiv noch Optimierungspotential. Das schwierigste wird wahrscheinlich sein, ein gutes, schlüssiges Modell für die Wahrscheinlichkeitsverteilung zu konstruieren. Wenn das aber steht, könnte man im Fahrplan-Editor entsprechende Einstellmöglichkeiten ergänzen, etwa ein Maximalwert für die Haltezeitüberschreitung oder verspätete Aufgleisung (Voreinstellung natürlich auf 0, wer alles beim alten behalten möchte). Vor einiger Zeit hatte ich mir auch gewünscht, dass über den Fahrplan-Editor einstellbar wird, bestimmte Ausfahrsignale auch schon früher als 1 Minute vor Planabfahrt zu stellen.

[johannes4321]

Meiner Erfahrung nach sorgt der Chaos-Faktor durchaus mal dafür, dass man Hp0 ohne Zusatzsignal bekommt, weil die Strecke blockiert ist. Und zwar, weil sich das komplette Netz blockiert und nichts mehr geht. Inzwischen habe ich Chaos wieder runter gestellt. Da zehnmal hintereinander Zs1 und dann ein deadlock im Netz ist kein Spaß ...

[Dirk1970]

Ohne Chaos Faktor geht bei mir gar nichts, das wäre mir zu öde, ich brauche Abwechslung.
Deswegen hoffe ich inständig, dass diese deadlock Problematik bald mal der Vergangenheit angehört und sei es nur, dass Zusi warnt wenn solch eine Situation sich aufgebaut hat und den Zug benennt der das verursacht hat, sodass man ihn wenigstens händisch löschen kann.

[oberstrom (Markus)]

In ähnlicher Form hatte es Alwin auch mal geschrieben

Johannes hat ja schon gezeigt, dass man einen Deadlock algorithmisch detektieren kann. Jetzt könnte man den Wunsch äußern, diese Funktionalität entweder direkt oder per Schnittstelle in den Simulator zu integrieren. In der ersten Ausbaustufe könnte der Apparillo dann eine gelbe Meldung bringen "Züge 4711 und 4712 sind im Deadlock, bitte einen davon abgleisen". Im zweiten Schritt könnte man versuchen, dass die Automatik auch das Abgleisen übernimmt (möglichst natürlich nicht den Zug wo der Spieler drinsitzt).

[Dirk1970]

Das stimmt, umso mehr hoffe ich, dass dies bald auch umgesetzt wird, immerhin gibt es dieses Deadlock-Problem schon seit ZUSI 2.

[Sebastian Leonow]

Meine Hoffnung wäre, dass zufällig längere Bahnsteigaufenthalte oder zufällig v<vmax bei den KI Zügen weniger Deadlocks erzeugen, als die bisherige Umsetzung des "Chaos", bei der auch zufällig alternative Fahrstraßen gewählt werden (so ist es doch?). Daher mein Vorschlag der Differenzierung zwischen Chaos im Sinne von Ersatzsignalen und alternativen Fahrwegen und Chaos im Sinne von langsamen Betriebsabläufen.

[Michael Springer]

Falls ich Euch jetzt die Euphorie nehme: Sorry, Zusi hat mehr oder weniger (hart ausgedrückt keinerlei) KI, um alternative Fahrwege und Betriebssituationen zu erkennen oder zu erzeugen. Die KI bei Zusi ist der Fahrplanbauer. Er muss die alternativen (Halte-)Gleise oder alternativen Fahrwege vorgeben. Zusi selbst hangelt sich nur Fahrplaneintrag zu Fahrplaneintrag.

Das bedeutet:
- Würde ein Fahrplanbauer für alle seine Züge jedes auf der Strecke vorhandene Signal (vom Start bis zum Ziel) angeben, so würdet ihr niemals einen alternativen Fahrweg erhalten. Nur zum eingestellten Chaosfaktor Zs1/Befehl. Also bei 2% im Schnitt bei jedem 50. Signal

- Gibt ein Fahrplanbauer nur Bhf A Asig und Bahnhof B Asig vor, würde Zusi beim Fahrstraßen stellen an Bhf A Asig zu 98% den Fahrweg im Regelgleis und zu 2% am Gegengleis wählen. Also bei 50 Fahrten fährst du im Schnitt einmal im Gegengleis. Diese Wahlregel gilt aber nur, wenn das Gegengleis zum Zeitpunkt des Fahrstraßenstellens frei ist. Ansonsten gibts immer den Fahrweg im Regelgleis. (Würde man einen Chaos-Faktor von 100% einstellen und das Gegengleis wäre ständig belegt, so gibt es immer den Fahrweg im Regelgleis).

Ich hatte das auch hier schon mal kurz ausgeführt.
viewtopic.php?p=284041#p284041" target="_blank

Michael

[Sebastian Leonow]

Gerade der Umstand zeigt doch, dass Zusi eigentlich sowas wie zufällig längere Bahnsteighalte oder langsame Züge bräuchte. So könnte ohne Deadlock Gefahr und ohne die KI des Autopiloten groß anfassen zu müssen ordentlich Chaos erzeugt werden.

[Michael Springer]

Ich sehe es nicht so.

Versuch eines schnellen Beispiels:
Eingleisige Strecke mit Bahnhhöfen: A B C

- Zug fährt verspätet von B nach C ab
- Gegenzug fährt dadurch verspätet von C nach B ab (Zug CB soll planmäßig in A kreuzen)
- Pünktlich fährt der Gegenzug von BC in A los (in richtiger Fahrplanlage)
- Beide Züge sollen in B auf Gleis 1 durchfahren und haben nur Gleis 1 im Fahrplan (Gleis 2 darf wegem höhengleichen Übergang nicht benutzt werden)
- Der eine steht dann in Gleis 1, der andere vorm Esig.

Somit hat deine einfache Chaos-Idee nichts gebracht, außer wieder einen Deadlock.

[Sebastian Leonow]

Ja das stimmt, hier müsste der Algorithmus dann einfach mehr können. Im Allgemeinen (mal abgesehen von eingleisigen Strecken) glaube ich aber trotzdem, dass sich mit absichtlich verspäteten Zügen ein interessanterer Betrieb als jetzt einstellen würde.
Ich messe diesem Zufallsfaktor viel bei, da er, neben vielem anderen, Zusi von den anderen Sims abhebt und das Fahren deutlich spannender macht.

[Michael Springer]

Ich habe schon ein paar Fahrpläne für Zusi gebaut (auch welche mit schrägen Ideen wie Linksverkehr). Ich kann Dir sagen, dass es verdammt schwierig ist, einen komplexe Fahrplan zu bauen, so das es keinen Deadlock gibt mit dem bisherigen Chaos-Regler. Die Züge eines Fahrplans beeinflussen sich jetzt schon an so vielen Stellen gegenseitig, das es eine Herausforderung ist. Wenn man solche Dinge wie einen weiteren Zufallsfaktor für Abfahrten (oder was auch immer) einbaut, wird es den Fahrplanbauern in vielen Fällen nicht mehr möglich sein einen durchlaufenden Fahrplan zu bauen. Der Frust der Spieler wird dadurch auch größer, wenn nix mehr stabil durchläuft. Ach ja, man könnte gegensteuern, in dem man wild die Deadlockenden Züge per Funktion rauslöscht.
Man könnte auch Argumentieren, Zusi ist eine Simulation der echten Bahn und in echt ist es eben auch so, dass 98% aller Zugfahrten normal und ohne Besonderheiten (wie alternativer Fahrweg) enden. Daher hat Zusi im aktuellen Konzept nichts falsch gemacht.

Aber dieser Zufallsfaktor kann von Dir jetzt schon genutzt und eingebaut werden. Nimm einfach einen Zug (oder eine .trn Datei) den du fahren willst und ändere darin deine Abfahrtszeiten. Hier 30 Sekunden oder da 2 Minuten und du hast so dein gewünschstes Verhalten an Zusi erreicht. Zufallsgenerator geht prima mit Würfeln.
Oder du bittest einen der Zusi-Programmierer-Cracks um ein Tool, das einfach per Zufall alle Abfahrtszeiten der Züge in einem Fahrplan um x Sekunden schwanken lässt und die geänderten Daten ins private Datenverzeichnis schreibt.

Btw

hier müsste der Algorithmus dann einfach mehr können.

Wenn Du es schaffst diesen zu entwickeln, kannst den für Millionen an die DB verkaufen. Die suchen nämlich auch sowas.

Michael

[Sebastian Leonow]

Wieso macht der zusätzliche Zufallsfaktor es dem Fahrplanbauer so viel schwerer? Auch jetzt laufen die meisten Fahlpläne wohl nicht zuverlässig mit hohen Zufallswerten und es ist doch nur legitim, wenn beim Fahrplanbau der Zufall nahe bei 0 gelassen wird.
Zum Algorithmus: Ich nutze das Beispiel eingleisige Strecke gerne in meiner Vorlesung um zu zeigen, wie schnell Deadlocks in Steuerungen entstehen. Daher kann ich gut einschätzen, dass ein intelligenter FDL nicht mal so eben programmiert ist. Einige Teilaspekte ließen sich aber glaube ich schon umsetzen. Wenn z.B. ein Zug auf eingleisigen Strecken seine Fahrstraße immer bis zur nächsten Kreuzungsstelle durchstellen muss (was dann also nur geht wenn Strecke und Kreuzungsstelle frei sind), dann ließe sich doch ein Deadlock vermeiden? Im obigen Beispiel wäre dann B keine Kreuzungsstelle, weil nicht als solche nutzbar.
Kann zu naiv gedacht sein, sonst wäre das vermutlich schon umgesetzt. Außerdem kenne ich die Details in Zusi nicht.

[Michael_Poschmann]

Hallo Sebastian,

Dein Ansatz ist sicherlich richtig gedacht, auch wenn "bis zur nächsten Kreuzungsstelle" ja noch keine Aussage über die Belegbarkeit der (Ausweich-) Gleise im Bahnhof ergibt. Da bestehen Randbedingungen wie z.B. Bahnsteiggleise, nicht gleisfreie Zugänge, Gleislängen etc. Zusi "denkt" aber derzeit nicht im Sinne einer Netzdisposition, sondern stumpf von Hauptsignal zu Hauptsignal, also blockweise. Ob sich das überhaupt aufbohren ließe, entzieht sich meiner Kenntnis. Trivial wird das sicherlich nicht sein.

Wie mein Namensvetter richtig schreibt, wenn das "einfach" algorithmisch zu lösen wäre, würde DB Netz demnächst in den Betriebszentralen entsprechende Zusi-Software nutzen. Derzeit experimentiert man beim großen Vorbild allerdings eher mit chaosstiftenden Ansätzen, so mein Eindruck nach den jüngsten Fahrten. Was Zusi garantiert nicht so elegant bewerkstelligen wird, ist der "Sichtanschluss" vom über 80 min verspäteten IC auf den über dreißig Minuten hinter Plan verkehrenden RE1 in der Stadt mit der großen Bahnhofskapelle. Und das sogar bahnsteiggleich. Da muss man schon extrem versiert mit den Bedingungsdateien arbeiten, um so etwas immer wieder hinzubekommen. Hut ab vor den Kollegen in der Dispo und auf dem örtlichen "Turm". Aber ich schweife ab...

Ein wenig wundert es mich, dass ich Fahrpläne so oft zufahren sollen. Auch wenn ich selbst kaum zum Ausprobieren komme und lediglich mal Gäste an meinem Fahrpult unterwegs sind, ist es mir in den letzten Jahren nicht gelungen, einen Deadlock zu produzieren, trotz teilweise sehr komplexer Holger-Fahrpläne und moderat eingestelltem Zufallsfaktor. Was natürlich ein Risiko beinhaltet, sind Fahrpläne mit einer möglichst hohen Auswahl an nutzbaren Gleisen und kruden Fahrwegen. Vielleicht sollten Fahrplanbauer hier ein wenig Selbstbeschränkung walten lassen.

Grüße
Michael

[Sebastian Leonow]

Wie gesagt, ich will den Zusi internen FDL nicht kritisieren, komplex genug ist das Ganze ja wahrscheinlich ohnehin schon.
Ich habe jetzt mal wie von Michael Springer vorgeschlagen im Düsseldorf-Köln Fahrplan (2016) einen RE in Benrath etwas länger stehen lassen und mich am erzeugten Chaos im nachfolgenden Fernverkehr erfreut, das fühlte sich schon an wie in echt. Oft reichen ja die "wir sind pünktlich" +5:59 aus, um den Anschluss zu verpassen.
Vllt. ließe sich das ja als Erweiterung für ZusiStart vorsehen. Da könnte dann nach dem Auswählen des eigenen Zuges der Rest ein wenig mit Zufall versehen, als temporärer Fahrplan abgelegt und dann geladen werden.

[Michael Springer]

Selbst bei Chaosfaktor 0 kanns schief gehen. Da brauchen wir einen Gegenfahrschutz würde ich mal sagen, weil die Schwaben ihre Signale so "deppert aufg'hängt hom". Im Rücken von T970 hängt Q970.

[Dirk1970]

Wie gesagt es wäre schon ein großer Fortschritt wenn Zusi eine Warnung ausgibt und den Deadlock Verursacher benennt, sodass man ihn händisch löschen kann.

[Selbstblock]

Hallo und Guten Tag zusammen,

ich denke auch -wie Michale Springer meinte-, dass das Gehirnschmalz des Fahrplanbauers über kurz oder lang weiter eine zentrale Rolle bei allen Fahrplänen spielen wird. Nun bietet aber Zusi dennoch Möglichkeiten, ein Stück weit zu optimieren, denn im Gegenteil zu echten Bahn hat der Zusi-FDL -zumindest in der Theorie- die Möglichkeit, die Situation des gesamten Streckennetzes zu analysieren. Genau an dieser Stelle böten sich einige Ansatzmöglichkeiten.

Zur Thematik der Deadlocks: Eine Möglichkeit, solche Probleme zu erkennen wäre die Aufteilung der Gleise eines Bahnhofes/Streckenabschnitts in einen bipartiten Graphen (Stichwort: Graphentheorie); Jeder Zug bildet dabei auf die Streckenelemente bzw. die Gleise ab, die er theoretisch benutzen kann. Das Ganze ließe sich also zu einem Matchingproblem reduzieren, für die es einige brauchbare Algorithmen gäbe (insbesondere, da es nicht mehrere tausend Gleise in einem Bahnhof gibt).
Erkennt man nun das zwei Züge das jeweils andere Gleis benutzen wollen bzw. einen Teil des Fahrweges, der aber vom anderen Zug blockiert ist und (meistens zumindest) die Züge in entgegengesetzte Fahrtrichtung unterwegs sind, dann liegt ein Deadlock vor. Einer der Züge muss entfernt werden, der andere erhält nun bevorzugt einen Fahrtbegriff um eine ähnliche Situation durch nun nachrückenden Zug zu vermeiden.

Dieser Gedanke ließe aber auch eine weitergeführte Idee zu. So könnte für jeden Bahnhof x und alle Züge z die sich innerhalb eines bestimmten Radius um den Bahnhof befinden ein solcher Graph gebildet werden, der die Situation am Bahnhof zur geplanten Ankunftszeit der Züge abbildet. Der Fahrplan liefert an der Stelle die Information wann Züge ankommen sollten, ob eine Verspätung vorliegt, kann Zusi ja jetzt schon gut berechnen. Lässt sich aus dem Matching ableiten, dass zwei Züge zur gleichen Zeit auf die gleiche Ressource zugreifen wollen, kann gleich überprüft werden, ob es denn eine Alternative für einen der Züge gäbe. Wenn ja, wird dieses Gleis sozusagen reserviert; es findet ein "Gleiswechsel" statt.
Findet sich keine solche Möglichkeit, könnte der Computer z.B. durch Zufall entscheiden, dass ein Zug an Stelle x (Streckenblock, Esig, anderer Bf, usw...) warten muss. Dazu wird erst ein neues theoretisches Matching durchgeführt, wenn es zu keiner Verklemmung mehr kommt, wird dementsprechend verfahren, ansonsten wird z.B. die Wartezeit des Zuges weiter erhöht, oder auch ein Fahrweg über das Gegengleis geprüft, dann wieder ein Matching durchgeführt.

Auch auf eingleisigen Strecken wie im Beispiel weiter oben beschrieben könnte man so auch Deadlocks verhindern. Der Radius um einem Bahnhof muss dazu mindestens die beiden Nachbarbahnhöfe beinhalten. Stellt sich zur Zeit x eine Verklemmung ein, wird ein Zug einfach am vorherigen Bahnhof zurückgehalten.
Auf die gleiche Weise ließe sich -zumindest teilweise- die in meinem ersten Beitrag zu diesem Thema beschriebene zufällige Verspätung von Zügen behandeln, die vom Autopiloten gesteuert werden, denn wenn nun ein Zug verspätet ist, wird überprüft, ob er in verspäteter Fahrplanlage im Moment überhaupt fahren kann, oder ob er nicht noch länger abwarten muss.
Um nun aber zu vermeiden, dass ein Zug mit viel Verspätung überhaupt keine Chance mehr hat, in endlicher Zeit ans Ziel zu gelangen, könnte man nun sagen, dass Züge mit Verspätung eher nicht mehr noch extra andere Züge abwarten müssen, Züge mit weniger Verspätung hingegen schon.

Im Grundsatz würde man also das bisherige Vorgehen beibehalten, dass der Zug von Hsig zu Hsig an Hand des Fahrplans fährt. Man würde auf diese Weise aber für eine Art dynamisierung der Fahrplanlage eines Zuges sorgen, die aber in sich stabil ist. Gleichzeitig hat die Idee ein Stück weit den charmanten Charakter, dass solche Matchingoperationen theoretisch losgelöst in einem eigenen Thread ablaufen könnten, da nicht in jedem Moment der Simulation ein neues Matching benötigt wird, sondern die Fahrplanlage der Züge fortlaufend optimiert werden kann. Mit anderen Worten: Wenn das Signal x auf Fahrt ist, dann ist es auf Fahrt und ich brauche in dem Moment keine weitere Berechnung.

Ich hoffe meine Gedanken waren halbwegs nachvollziehbar, ich würde mich über weitere Ideen zu diesem Thema sehr freuen!

[F. Schn.]

Ich verlinke mal Johannes: viewtopic.php?f=47&t=11155" target="_blank

Das ist noch mal das selbe, was du gerade beschreibst, nur in anderen Worten.

Man kann nun das Tool auch Vorbeugend laufen lassen, und somit das Einstellen von Fahrstraßen, die ein Deadlock erzeugen, verhindern. Dazu müsste man mal kurz berechnen, welcher Zug welche Register belegen wird, wenn er am Ende des aktuell eingestellten Fahrweges angekommen ist. So etwas ähnliches beschreibst du ja auch.

Es wäre halt relativ viel für Carsten. Und ich glaube auch, dass Schnittstellen für externe Toolbauer schwierig seien werden. Irgendwas werden wir aber für die StellSi-Zusi- und die Zusi-Zusi-Kopplung langfristig eh benötigen.