Deadlock auffinden

Hier kann alles Allgemeine rund um Zusi 3 gefragt und beantwortet werden. Neuigkeiten zum Programm werden hier erscheinen.
Nachricht
Autor
Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Deadlock auffinden

#1 Beitrag von Johannes »

Josch hat geschrieben:Ich teste gerade in mehreren Durchläufen die Chaosfunktion mit der Einstellung 80. Ich habe dafür den Gag 57566 (BR 120 Himmighausen > Altenbeken) bis Langeland gefahren und stehe dort nun auf dem rechten Gleis am Hp0. Links neben mir steht der Dg 53842 (BR 216 Bad Driburg > Altenbeken). Links neben diesem ist kurz darauf auch noch der E 5912 (BR 216 Bad Driburg > Altenbeken) eingefahren und außen auf der Umfahrung stand der Dstg 80248 (BR 260 Himmighausen > Altenbeken).
All diesen Zügen standen am Langelander Ende des Rehbergtunnels aus Altenbeken kommend entgegen: auf dem rechten Gleis der N7910 (BR 110 Altenbeken > Himmighausen) und daneben der E 3541 (BR 216 Altenbeken > Bad Driburg).
Interessanter Beitrag, weil sich anhand der Zugnummern und Positionen die Situation genau nachstellen lässt. Ich habe mal versucht, das aufzuzeichnen:
Bild
Die blauen Quadrate sollen (fiktive) Fahrstraßenregister darstellen. Ich frage mich nun, ob man einen solchen Deadlock, wenn nicht vermeiden, dann doch erkennen kann. (In komplexeren Netzen kann so etwas sicher auch ohne 80% Chaosregler auftreten.) Der Benutzer könnte dann (falls sein Zug von dem Deadlock betroffen ist) eine gut verständliche Meldung erhalten. Man könnte dann in einem weiteren Schritt eine Empfehlung abgeben, welcher Zug aus der Simulation entfernt werden muss, damit der Betrieb wieder zum Laufen kommt.

Für einen Deadlock müssen vier Bedingungen erfüllt sein. Drei davon sind in einer Eisenbahnsimulation immer erfüllt (1. ein Gleis kann immer nur durch einen Zug belegt sein (Mutual Exclusion), 2. ein Zug belegt ein Gleis und will weitere Gleise belegen (Hold and wait), 3. man kann einem Zug sein belegtes Gleis nicht wegnehmen (No preemption)). Die vierte ist eine Anforderung an die aktuelle Situation und besagt, dass eine zyklische Abhängigkeit zwischen den Zügen bestehen muss (Circular Wait).

Diese zyklische Abhängigkeit kann man mit Hilfe des sogenannten Resource Allocation Graph finden. Die Fahrstraßenregister sind hier durch graue Quadrate dargestellt. Eine dicke Linie Fahrstraßenregister → Zug bedeutet, dass der Zug dieses Register belegt hält. Eine Linie Zug → Fahrstraßenregister bedeutet, dass der Zug dieses Register für seine nächste Fahrstraße belegen möchte (anfordert). Außerdem muss noch berücksichtigt werden, dass ein Zug mehrere alternative Fahrwege haben kann. Diese werden jeweils durch nummerierte Rauten dargestellt und haben eigene Registeranforderungen.
Bild

Die vierte Deadlock-Bedingung besagt nun, dass man in diesem Graphen einen gerichteten Kreis finden muss (also einen Pfad, der den Pfeilen folgt und wieder zum Ausgangspunkt zurückkehrt). Außerdem müssen wieder die alternativen Fahrwege berücksichtigt werden: Es sollte die Bedingung genügen, dass für jeden Zug, der im Kreis auftaucht, jeder seiner möglichen Fahrwege in einem Kreis liegen muss.

Tatsächlich finden wir in diesem Graphen einen solchen gerichteten Kreis (wegen der Fahrwegalternativen ist es eher ein „zyklischer Subgraph“):
Bild

Damit ist klar, dass ein Deadlock existiert, der nicht ohne Löschen eines Zuges aufgelöst werden kann. Hier würde das Löschen von Dg 53842 den Deadlock auflösen (wobei dann E 3541 das durch diesen Zug belegte Register zugesprochen bekommen sollte). Der Deadlock würde übrigens sogar ohne die Züge Gag 57566 und E 5912 auftreten.

Was bringen diese theoretischen Überlegungen? In Zusi selbst wäre solch eine Spezialfunktion sicher falsch aufgehoben. Was man sich aber durchaus vorstellen könnte, ist, ein Plugin für so etwas zu entwickeln. Es bräuchte Zugriff auf sämtliche Stellwerksdaten (Züge, Register, Fahrstraßen) sowie die Fahrpläne der Züge. Man könnte periodisch nach Deadlocks suchen oder wenn ein Zug außergewöhnlich lange steht. Natürlich wären optimierte Algorithmen nötig, um auch bei dutzenden von Zügen und hunderten von Registern in vernünftiger Zeit die Berechnung zu Ende zu führen. Hilfreich könnte das auch für Fahrplanbastler sein, die wissen wollen, wann und wo sich ihr Fahrplan zufährt.

Warten wir also mal die Plugin-Schnittstelle von Zusi ab :). Oder ist es eventuell sogar geplant, solch eine Funktionalität in Zusi zu integrieren? Oder hat es jemand sogar schon versucht und ist gescheitert? Bestünde denn generell Interesse an solch einer Funktion?

Grüße
Johannes

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

Allgemeine Rückmeldungen zur Zusi 3-Demo

#2 Beitrag von Michael_Poschmann »

Hallo Johannes,

ein netter Ansatz. :tup Damit öffnest Du natürlich ein weites Betätigungsfeld.

Vielleicht ergibt sich dereinst mal eine Option für eine Art von Dispatcher-Software, die dann neben der reinen Analysefunktion womöglich auch noch koordinierend eingreift. Ob durch Vorschläge an einen menschlichen Bediener oder sogar automatische Aktionen, das sei mal dahingestellt. Ich gebe zu, die Idee hat etwas.

Sollte irgendwann einmal die Option des Rangierens zur Verfügung stehen, werden die betrieblichen Abläufe eh an Komplexität zunehmen, so daß der Bedarf durchaus gegeben sein könnte.

Gruß
Michael

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Allgemeine Rückmeldungen zur Zusi 3-Demo

#3 Beitrag von Carsten Hölscher »

Diese Daten wird man schon zugänglich machen können, wenn ich ernsthaftes Interesse an einer Nutzeng vermuten darf. Das gilt für etliche Daten, die für Schnittstellen in Frage kommen, für die eine konkrete Schnittstelle aber noch nicht ausgeführt ist.

Carsten

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Allgemeine Rückmeldungen zur Zusi 3-Demo

#4 Beitrag von Johannes »

Carsten Hölscher hat geschrieben:Diese Daten wird man schon zugänglich machen können, wenn ich ernsthaftes Interesse an einer Nutzeng vermuten darf. Das gilt für etliche Daten, die für Schnittstellen in Frage kommen, für die eine konkrete Schnittstelle aber noch nicht ausgeführt ist.
Das klingt schon mal gut. Dieses Problem reizt mich durchaus; ich würde mich aber erst um die Algorithmik kümmern und einen Prototyp mit Dummy-Daten erstellen, um die Machbarkeit abschätzen zu können. Dann würde ich nochmal wegen der Daten anfragen.

Wobei ich gedacht hätte, dass der Großteil der Daten über die Stellwerksschnittstelle ohnehin verfügbar sein sollte?

Grüße
Johannes

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Allgemeine Rückmeldungen zur Zusi 3-Demo

#5 Beitrag von Carsten Hölscher »

Ja, sobald diese funktioniert...

Carsten

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Allgemeine Rückmeldungen zur Zusi 3-Demo

#6 Beitrag von Johannes »

Carsten Hölscher hat geschrieben:Diese Daten wird man schon zugänglich machen können, wenn ich ernsthaftes Interesse an einer Nutzeng vermuten darf. Das gilt für etliche Daten, die für Schnittstellen in Frage kommen, für die eine konkrete Schnittstelle aber noch nicht ausgeführt ist.
Ich habe jetzt mal einen Prototypen erstellt (wen’s interessiert …). Weiter unten kommen noch meine Einschätzungen zur Machbarkeit, davor aber eine Frage:

Gesetzt den Fall, es gäbe eine solche Schnittstelle in Zusi: Welche Daten würde ich in welcher Form bekommen? Ich gehe in meinem Prototypen davon aus, dass folgende Daten vorliegen:
  • Liste der belegten Fahrstraßenregister; für jedes Register die Information, durch welchen Zug es belegt ist.
  • Liste der (stehenden) Züge; für jeden Zug eine Liste mit möglichen Folge-Fahrstraßen. Von diesen Fahrstraßen interessieren mich lediglich deren Register.
Liegen diese Daten alle so vor, wie ich mir das hier vorstelle? Und in welcher Form ließe sich das am besten realisieren (TCP-Schnittstelle, Plugin)?

Zur Machbarkeit: Meiner Einschätzung nach dürfte das Problem in durchaus akzeptabler Rechenzeit zu lösen sein. Für das weiter oben angeführte Beispiel kommt nach einigen Optimierungen (deren Laufzeit linear in der Anzahl der Fahrstraßenregister und der Anzahl der Züge ist) folgender Wait-For-Graph heraus:

Bild

Darin Zyklen zu finden ist dann die eigentliche Arbeit, die etwas mehr Rechenzeit benötigt. Tiefensuche an sich ist zwar linear in der Anzahl der Züge, aber dank der Fahrwegalternativen muss ich mehrere Tiefensuchen auf einmal durchführen, womit die Laufzeit exponentiell von der Anzahl Fahrwegalternativen pro Zug abhängen dürfte. Diese schätze ich im Regelfall als eher niedrig ein, somit bleibt die Laufzeit insgesamt im Rahmen.

Grüße
Johannes

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Deadlock auffinden

#7 Beitrag von Carsten Hölscher »

Register und Züge mit Standorten wären nicht das Problem. Folgefahrstraßen müßte man mal schauen. Liegen natürlich irgendwo in den Stellwerksfunktionen vor, kann man aber auch über Strecken- und Zugdateien selbst rauskriegen.

Carsten

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Deadlock auffinden

#8 Beitrag von Johannes »

Carsten Hölscher hat geschrieben:Register und Züge mit Standorten wären nicht das Problem.
Bezieht sich „Standort“ hier nur auf die belegten Streckenelemente oder auf die gesamte Fahrstraße? Im ersteren Fall müsste ich ja für Register, die nur gesperrt (aber noch nicht belegt) oder geräumt (aber noch nicht aufgelöst) sind, selber herausfinden, von welchem Zug sie belegt sind?

Manchmal habe ich nämlich das Gefühl, dass Zusi selbst nur die belegten Streckenelemente kennt – beim Löschen eines Zuges werden die für diesen Zug eingestellten Fahrstraßen nicht aufgelöst; dadurch ist auch eine Deadlock-Auflösung im Moment nicht möglich.
Carsten Hölscher hat geschrieben:Folgefahrstraßen müßte man mal schauen. Liegen natürlich irgendwo in den Stellwerksfunktionen vor, kann man aber auch über Strecken- und Zugdateien selbst rauskriegen.
Da die Funktion in Zusi schon existiert, wäre es natürlich tendenziell besser, sie nicht nochmals implementieren zu müssen (Aufwand und mögliche Diskrepanzen zwischen den Implementierungen).

Grüße
Johannes

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Deadlock auffinden

#9 Beitrag von Johannes »

Lässt sich eigentlich herausfinden, welcher der wartenden Züge nach dem Löschen eines Zuges dessen Fahrstraße „zugesprochen“ bekommen wird? Oder ist das sozusagen nichtdeterministisch?

(Anwendungsbereich: Empfehlung für das Löschen eines Zuges nach Erkennen des Deadlocks. Man will ja nicht, dass die gleiche Stelle zwei Minuten später wieder zugefahren ist.)

Grüße
Johannes

Benutzeravatar
Carsten Hölscher
Administrator
Beiträge: 33384
Registriert: 04.07.2002 00:14:42
Wohnort: Braunschweig
Kontaktdaten:

Re: Deadlock auffinden

#10 Beitrag von Carsten Hölscher »

Das ist im Regelfall "zufallsbehaftet". Man könnte sich natürlich drauf einigen, dass es bei Chaosregler=0 ein deterministischer Vorgang wird, nur ist das vielleicht auch nicht 100% praxistauglich. Aber wenn ein neuer Deadlock entsteht, könnte der Algo ja weiter arbeiten bis es irgendwann läuft.

Carsten

Hp2
Beiträge: 29
Registriert: 27.10.2008 19:58:55

Re: Deadlock auffinden

#11 Beitrag von Hp2 »

Ist ein Deadlock eigentlich eine Sache, die nur in der Simulation auftreten kann?

In der Realität kann man schließlich nicht einen Zug einfach so in Luft auflösen. Wie würde man denn da vorgehen?

Benutzeravatar
Michael_Poschmann
Beiträge: 19877
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Modul Menden (Sauerland)
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

Re: Deadlock auffinden

#12 Beitrag von Michael_Poschmann »

Hallo "Hp2",

erfahrene Notfallmanager führen im Handgepäck für solche Fälle immer eine Tüte Rostfix mit, welche den Deadlock in kürzester Zeit auflösen hilft. Und zudem den zu üppigen Fahrzeugbestand auf elegante Art und Weise verkleinert - die Controller danken es.

8) Michael

Alwin Meschede
Beiträge: 8927
Registriert: 04.11.2001 19:57:46
Aktuelle Projekte: Zusi3 Objektbau
Kontaktdaten:

Re: Deadlock auffinden

#13 Beitrag von Alwin Meschede »

Hp2 hat geschrieben:Ist ein Deadlock eigentlich eine Sache, die nur in der Simulation auftreten kann?

In der Realität kann man schließlich nicht einen Zug einfach so in Luft auflösen. Wie würde man denn da vorgehen?
Natürlich ist es denkbar, dass man sich auch bei der richtigen Eisenbahn durch unsachgemäße Disposition einen Engpass so unglücklich zufährt, dass erstmal nichts mehr geht. Wer das als Fdl oder BZ-Disponent schafft, hat natürlich 100 Punkte erzielt... Einen Güterzug mal eben zurückdrücken is' meist nicht, das wird dann eine riesige Aktion, um so einen Knoten wieder aufzulösen.

Im Gegensatz zu Zusi, der so lange nach dem Prinzip "vorwärts immer, rückwärts nimmer" die Züge fahren lässt, bis eben nichts mehr geht, hat man bei der Eisenbahn allerdings die Möglichkeit, Deadlocks mit Intelligenz und Voraussicht schon zu verhindern, bevor sie entstehen. Es ist z.B. absolut üblich, dass ein Rangierbahnhof meldet, dass die Einfahrgruppe gerade dabei ist, überzulaufen. Dann wird frühzeitig begonnen, Züge im Netz zurückzuhalten.
Mein Youtube-Kanal: youtube.com/echoray1

F(R)S-Bauer
Beiträge: 6281
Registriert: 09.11.2002 02:00:47

Re: Deadlock auffinden

#14 Beitrag von F(R)S-Bauer »

Mahlzeit,

die Situation in Zusi kann man IMHO nur entschärfen, wenn man die Möglichkeit hat in einer Art Regelsprache bedingungen zu erstellen, die ein Zulaufen wenn schon nicht vermeidet, so aber doch erschwert.

Z.B in diesem Berich von über nach dürfen nur X Züge von A nach B, Y Züge von B nach A und insgesamt maximal Z Züge sein. Oder Zug X darf erst fahren wenn Zug X durch ist, solang der nicht mehr als M Minuten verspätung hat.

Damit könne sowohl der Strecken als auch der Fahrplanbauer die Situation entschärfen.

Alleine mit Vorausberechnug wird es nicht gehen, weil du ja die "Überaschungen" durch z.B ein Zufallsgesteuertes zs1 kompensieren muß, was die Zugfolge umwirft.

Ein weitere Punkt währe, das der Autopilot 2 Geschwindigkeiten pro Strecke kennt , eine für den Normalbetrieb, und eine
wenn er hinter Plan ist.

Bei euren Überlegunge müst Ihr eins Berücksichtigen: der Normalfall und der Fahrplan-Sollwert ist ja "kein Deadlock"
Die Deadlocks kommen immer duch zufälligkeiten rein, u.a auch deshalb, weil der AP immer Vollgas fährt und sich Zugfolgen verändern.

mfg

Ralf
Zuletzt geändert von F(R)S-Bauer am 06.10.2012 13:52:07, insgesamt 2-mal geändert.
Verstehe die IT, heute: IoF -> Internet over Fax, eine Deutsch Erfindung...

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Deadlock auffinden

#15 Beitrag von Johannes »

F(R)S-Bauer hat geschrieben:Bei euren Überlegunge müst Ihr eins Berücksichtigen: der Normalfall und der Fahrplan-Sollwert ist ja "kein Deadlock"
Die Deadlocks kommen immer duch zufälligkeiten rein, u.a auch deshalb, weil der AP immer Vollgas fährt und sich Zugfolgen verändern.
Du kannst aber mit einem schlecht gestalteten Fahrplan durchaus einen „planmäßigen“ Deadlock erzeugen, wenn du zum Beispiel zwei Züge aus entgegengesetzten Richtungen auf eine eingleisige Strecke schickst. Ich meine, dass Zusi da nicht so schlau ist, das zu erkennen. Bei größeren Fahrplänen ist so etwas sicher etwas schwieriger zu erkennen, weshalb so ein Deadlock-Erkennungs-Tool nützlich sein könnte.

(Beim Berechnen einer Zugmenge minimaler Größe, deren Löschen den Deadlock auflöst, stößt man übrigens unweigerlich auf NP-schwere Probleme … Ich bin deshalb schon echt gespannt, wie die Laufzeit mit echten Eingabedaten sein wird.)

Man sollte auch immer beachten, dass man mit genügend Vorausschau (wobei da auch wendende Züge, Auf- und Abgleisen etc. berücksichtigt werden muss) einen Deadlock in der Simulation sicher so gut wie ausschließen könnte – aber dann würde kein Zug mehr planmäßig fahren. Zum Thema Deadlockvermeidung wird übrigens auch geforscht, hier mal ein Papier aus Braunschweig, dessen Autor, soviel ich weiß, hier im Forum auch ab und an unterwegs ist.

Übrigens können Deadlocks bei Straßenbahnen, wo die Fahrstraßen nicht zentral gestellt werden, durchaus im Betrieb auftreten. Hier einmal ein Bild eines Deadlocks, so wie ich ihn selbst erlebt habe:
Bild
(Man hat dann die eigentlich nach links abbiegende Bahn nach rechts abbiegen und an einer nahe gelegenen Wendeschleife eine Ehrenrunde drehen lassen.)

Grüße
Johannes

F(R)S-Bauer
Beiträge: 6281
Registriert: 09.11.2002 02:00:47

Re: Deadlock auffinden

#16 Beitrag von F(R)S-Bauer »

Johanes,

richtig, das hat zu eine Bösen Unfall Geführ und den Disponenten in Haft gebracht. Sollte also nicht mehr gemacht werden.
Das Zufahren eine Eingleisigen Abschnittes ohne Bf kann ich als Streckenbauer wie auch 1:1 verhindern. Also wenn sich 2 Züge Kopf an Kopf gegenüber stehen hat der Streckenbauer oder Signalplaner was falsch gemacht. Ich bekomme auch als Streckenbauer hin das ein Eingleisiger Abschnitt mit ein KopfBf am Ende nicht zuläuft.

Das wirkliche Problem geht los wenn in einem Eingleisigen Abschnitt ein Zweigleisiger oder mehrgleisiger Bf ist. Da müste dein Deadlock Erkennug greifen.

Bastel mir mal eine Logik die auf meiner Strecke zwischen Freiberg und Vierkreuz ein Zulaufen verhindert. Mir Streckenbauermitteln aus Zusi bin ich daran gescheitert., zumindest wenn ich Flexibel bleiben will. :ausheck

mfg

Ralf
Verstehe die IT, heute: IoF -> Internet over Fax, eine Deutsch Erfindung...

Jan
Beiträge: 513
Registriert: 28.11.2007 19:13:51
Wohnort: Stutensee

Re: Deadlock auffinden

#17 Beitrag von Jan »

Johannes hat geschrieben:Übrigens können Deadlocks bei Straßenbahnen, wo die Fahrstraßen nicht zentral gestellt werden, durchaus im Betrieb auftreten. Hier einmal ein Bild eines Deadlocks, so wie ich ihn selbst erlebt habe:
[...]
(Man hat dann die eigentlich nach links abbiegende Bahn nach rechts abbiegen und an einer nahe gelegenen Wendeschleife eine Ehrenrunde drehen lassen.)
Hmm, war das zufälligerweise an der Schillerstraße in Karlsruhe?

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Deadlock auffinden

#18 Beitrag von Johannes »

Jan hat geschrieben:
Johannes hat geschrieben:Übrigens können Deadlocks bei Straßenbahnen, wo die Fahrstraßen nicht zentral gestellt werden, durchaus im Betrieb auftreten. Hier einmal ein Bild eines Deadlocks, so wie ich ihn selbst erlebt habe:
[...]
(Man hat dann die eigentlich nach links abbiegende Bahn nach rechts abbiegen und an einer nahe gelegenen Wendeschleife eine Ehrenrunde drehen lassen.)
Hmm, war das zufälligerweise an der Schillerstraße in Karlsruhe?
Respekt, der Kandidat hat volle Punktzahl! :)

In beiden Richtungen war die vordere Bahn jeweils eine Einfachtraktion der Linie 2E, die hintere Bahn jeweils eine Doppeltraktion der Linie 1. Das besagte Fahrzeug der Linie 2E wendete dann außerplanmäßig an der Wendeschleife am Kaiserplatz. Das war auch die einzig sinnvolle Möglichkeit, denn auf der Kaiserallee wartete inzwischen schon die nächste Bahn der Linie 1; man hätte die 1er-Doppeltraktion links im Bild über die gesamte eingleisige Strecke bis zur Sophienstraße zurücksetzen müssen.

Grüße
Johannes

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Deadlock auffinden

#19 Beitrag von Johannes »

Ich habe mal eine vorläufige Version des Deadlock-Prüfers für Zusi 2.4.7.3 erstellt. Eigentlich diente sie dazu, den Algorithmus einmal für die Praxis zu implementieren, und wird voraussichtlich nicht mehr groß weiterentwickelt. Insbesondere auf komplexen Streckennetzen kann es ab und an auch zu Fehlmeldungen kommen. Umlaute mag es im Moment auch nicht wirklich. Vielleicht nützt das Tool trotzdem jemandem etwas.

Die Datei gibt es hier zum Download (ungefähr 8 MB bedingt durch die Entwicklung in Python und Konvertierung mit py2exe – es ist schließlich nur ein Prototyp). Das Programm muss nach dem Laden der Strecke und vor dem Start der Simulation aufgerufen werden. Beendet wird es mit der Tastenkombination Strg+C.

Grüße
Johannes

Benutzeravatar
Johannes
Beiträge: 3197
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Deadlock auffinden

#20 Beitrag von Johannes »

Nach der Implementierung des Algorithmus habe ich nun ein etwas klareres Bild von den Informationen, die ich für die Deadlock-Erkennung am liebsten von Zusi hätte. Ich schreibe das einfach mal runter, vielleicht kann es ja als Anregung für die Schnittstelle dienen.
  • Es ist sinnvoll, nur Züge zu betrachten, die vor einem haltzeigenden Signal stehen. Grund dafür ist, dass ein Zug, der noch eine signifikante Strecke bis zum Zielsignal zurückzulegen hat, dabei eventuell Register wieder freigibt, auf die ein anderer Zug wartet. Dadurch wird also die fehlerhafte Meldung eines Deadlocks verhindert.

    Man könnte das anhand der folgenden Informationen feststellen: die Entfernung zum Ende der letzten gestellten Fahrstraße für diesen Zug sowie bei Reisezügen ggf. der aktuelle Planhalt. Dann gilt:

    Code: Alles auswählen

    Zug vor haltzeigendem Signal <=> Zielentfernung <= x  oder  Aktueller Planhalt = Block, bis zu dem die Strecke frei ist
    Wobei x eine sinnvolle Entfernung ist, bis zu der der Zug als „steht vor dem Signal“ betrachtet wird, beispielsweise die Entfernung, bis zu der auch der Befehl angezeigt wird. Wenn man noch die aktuelle Geschwindigkeit des Zuges kennt, kann man die Berechnung frühzeitig abbrechen, wenn der Zug nicht steht.
  • Die aktuell gestellte Fahrstraße für einen Zug wäre auch gut zu wissen. Damit kann man angeben, auf welchem Streckenabschnitt sich ein blockierter Zug befindet.
  • Selbstredend müsste man wissen, von welchem Zug ein Register belegt ist. Wenn das intern nicht gespeichert wird, könnte man alternativ in das Ereignis „Fahrstraße wird durch Zug belegt“ einen Hook einbauen. Ob ein Register belegt ist oder nicht, müsste man dann aber immer noch wissen.
  • Ein sinnvoller Zeitpunkt, um das Vorhandensein eines Deadlocks zu prüfen, ist das Ereignis „Alle möglichen Fahrstraßen des Zuges sind blockiert“. Wenn es da eine Art Hook gäbe, wäre das praktisch. Allerdings funktioniert das vermutlich nur, wenn die Stellwerksfunktion nicht an andere Stellwerke ausgelagert ist. Hier fällt mir nur eine (wesentlich aufwändigere) periodische Überprüfung ein.
  • Wenn die Folgefahrstraßen (samt zugehörigen Registern) für einen Zug eh irgendwo vorliegen, wäre es echt nett, die öffentlich zu machen. Man spart sich einfach doppelten Rechenaufwand.
  • Ein optionales Highlight wäre natürlich eine Funktion, die es ermöglichen würde, die Funktion „Außenansicht anderer Zug“ programmseitig aufzurufen. Damit könnte man direkt zu den blockierten Zügen springen. (In Zusi 2 vermisse ich hier übrigens bei größeren Fahrplänen ein Zugnummern-Suchfeld im „Anderen Zug auswählen“-Dialog. Vielleicht gibt es das in Zusi 3 irgendwann?)
Damit erst mal genug des Wunschzettels. Ich denke mal, dass diese Daten intern sowieso vorhanden sind (wenn nicht, muss ich eben schauen, wie ich mit den vorhandenen Daten etwas Sinnvolles anstellen kann. Schließlich kenne ich die internen Strukturen von Zusi nicht). Damit dürfte es hoffentlich nicht allzu schwierig sein, diese für Plug-ins öffentlich zu machen, wenn das sinnvoll erscheint.

Grüße
Johannes

Antworten