Spezifikation gesucht: Events bei Fahrplanhalt

[The-Tauri]

Hallo zusammen,

ich habe soeben folgendes Verhalten der Plugin-Schnittstelle beobachtet: Ich hatte einen Zug am Bahnsteig stehen, der seine Abfahrtszeit erreicht hatte (gelb hinterlegt). Wegen eines Gegenzuges war sein Signal noch in Haltstellung und er konnte nicht abfahren.
Über die Plugin-Schnittstelle wurden währenddessen ständig, ca. alle 600 ms, das Event "abfahrt" getriggert. Im Gegensatz zu anderen Zügen war dann bei der tatsächlichen Abfahrt in den Zugdetails noch der aktuelle, soeben verlassene Bahnsteig gesetzt, statt der nächste Bahnsteig.

Generell würde mich die Abfolge der Events bei einem Fahrplanhalt und die dabei mitgesendeten Zugdetails interessieren.
Meiner Beobachtung nach sind es folgende:

1. ankunft;gleis="dieser Bahnsteig";amgleis="true"
2. Falls Ausfahrsignal in Haltstellung: alle 600ms abfahrt;gleis="dieser Bahnsteig";amgleis="true"
3. Falls Ausfahrsignal in Haltstellung war und jetzt in Fahrtstellung wechselt: abfahrt;gleis="dieser Bahnsteig";amgleis="false"
4. Falls Ausfahrsignal nicht in Haltstellung war: abfahrt;gleis="nächster Bahnsteig";amgleis="false"

Über eine Antwort, ob ich das Verhalten korrekt wiedergegeben habe und ob dieses Verhalten so beabsichtigt ist, würde ich mich sehr freuen :)

Viele Grüße,
Moritz

[The-Tauri]

Hallo zusammen,

dann die Frage an die anderen Plugin-Entwickler: Wie habt ihr die Erkennung umgesetzt, an welchem Bahnsteig ein Zug gerade angekommen oder abgefahren ist? Wertet ihr (wie ich) den Bahnsteig in den Zugdetails aus, oder prüft ihr zu welcher Fahrplanzeile die aktuelle Zeit minus aktueller Verspätung passt? Ist die Verspätung zum Zeitpunkt einer Ankunft, Abfahrt und Durchfahrt dann auch in allen Fällen bereits aktualisiert?

Das von mir beobachtete Verhalten ist zwar meistens so, aber leider nicht immer. In seltenen Fällen steht bei der Abfahrt nicht der nächste Bahnhof in den Zugdetails, sondern der aktuell verlassene Bahnhof, obwohl das Ausfahrsignal in Fahrtstellung war und kein Abfahrts-Event mit amgleis=true getriggert wurde.
Ich habe das ganze bereits zeitintensiv beobachtet aber konnte keine Regel finden, wann bei der Abfahrt trotz amgleis=false ohne vorausgegangenes amgleis=true der aktuelle und wann der nächste Bahnsteig in den Zugdetails steht.

Falls es eine offizielle Spezifikation dazu gibt, wäre ich natürlich auch daran noch immer interessiert.

Viele Grüße,
Moritz

[manuel3108]

Hi Tauri,

bis ich deinen Beitrag heute morgen gelesen hatte, habe ich das ereignis-tag noch nicht verstanden gehabt. Das liegt unter anderem daran, dass ich mir noch nicht die Mühe gemacht habe nachzufragen, und das ich die Schnittstelle (logischerweise) als erstes programmiert habe und mich dann nicht mehr viel mit der Dokumentation beschäftigt habe.

Ich weiß nicht, in wieweit du mein Plugin kennst, deshalb hier kurz zur Erklärung: Ich mache das eigentlich so, wie du das als erste Möglichkeit beschrieben hast. Ich frage den "Sim-Server" in einem vom User vorgegebenen Intervall nach allen Zugdaten und werte diese dann aus. Das folgende verstehe ich nicht ganz, vielleicht kannst du das nochmal kurz ausführen:

[...] oder prüft ihr zu welcher Fahrplanzeile die aktuelle Zeit minus aktueller Verspätung passt? Ist die Verspätung zum Zeitpunkt einer Ankunft, Abfahrt und Durchfahrt dann auch in allen Fällen bereits aktualisiert?

Ich habe mir gerade noch die Dokumentation angesehen und finde die Idee prinzipiell ganz gut. Nur würde mir bei meinem Plugin z.B. die Rückmeldung fehlen, wenn ein Zug seine Verspätung ändert oder das Gleis gewechselt wird. Das würde die Programmierung auf der Plugin-Seite meiner Meinung nach vereinfachen.

Mit meinem Vorgehen habe ich keine Problem festgestellt. Sobald bei einer neuen Abfrage irgendetwas im Sim an dem Zug geändert wurde, werden diese Daten mir auch korrekt mitgeteilt, sodass keine solch von dir genannten Probleme entstehen. Ansonsten kann ich dir zu den Events wenig sagen, da ich sie wie gesagt nicht benutzt habe.

Falls du dir genauer anschauen möchtest wie ich die Verbindung programmiert habe, kannst du das gerne unter Github tun. Für dich interessant wären dann Folgende Klassen: Verbindung, XMLHandler, Zug und FahrplanHalt. Die drei letztgenannten Klassen werden alle in der Verbindungs-Klasse erzeugt.

Manuel

[endour]

ich habe soeben folgendes Verhalten der Plugin-Schnittstelle beobachtet: [..]

Ich habe die Events noch nie benutzt, aber wenn deine Beobachtung so stimmt, würde ich das auch als "unpraktisch" oder als Fehler bezeichnen. Wenn je nach dem, ob zum erstmaligen Abfahrtsversuch eine gültige Fahrstraße gestellt ist, bei der Abfahrt dann unterschiedliche Gleise gemeldet werden ist das jedenfalls nicht ideal.

Ich nehme an, dass du selbst schon ähnliche Gedanken hattest, aber was ich in deinem Fall ganz konkret tun würde (nachdem ein Beitrag hier mit Hoffnung auf Fehlerbeseitigung noch nichts gebracht hat): Für jeden Zug (oder für jeden "Bahnsteig") ein Flag abspeichern, mit dem erfasst wird, wenn ein "erfolgloser" Abfahrtsversuch stattfindet (amgleis=true). Wenn eine "erfolgreiche" Abfahrt gemeldet wird, erkenne ich anhand des Flags, ob es direkt im ersten Abfahrtsversuch geklappt hat oder ob der Zug schon eine Weile versucht hat abzufahren, und somit ob der im Event übertragene Bahnsteig der nächste oder der vorherige Halt ist und kann mir je nach dem, was ich benötige, den anderen Wert aus vorher abgespeicherten Fahrplandaten oder über einen API-Request holen. Dann das Flag wieder zurücksetzen.

PS: Ich finde es sehr schön, dass du hier fälschlicherweise von "Bahnsteig" statt "Gleis" schreibst (viele der Stellwerksim-Gleise, an denen Züge halten können, haben ja nicht mal Bahnsteige aber trotzdem einen Namen/Nummer). Habe ich in einem Skript auch falsch gemacht, und jetzt habe ich eine Datenbank mit Begriff "bahnsteig", wo eigentlich Gleise gemeint sind. Stört mich etwas, aber ich habe auch keine Lust, das alles anzupassen.

Edit: Mit den Verspätungszeiten würde ich nicht rumrechnen. Das wird vermutlich zu ungenau.

[endour]

Ich bin jetzt doch über die Ereignisse gestolpert, und auch ich werde aus dem Abfahrt-Ereignis nicht recht schlau.

So wie du es ganz oben im Topic beschrieben hast könnte man ja noch irgendwie damit umgehen (in meinem Fall alle abfahrt-Events mit amgleis=true wegwerfen, weil ich nur an dem Moment interessiert bin, in dem der Zug tatsächlich losfährt – wenn er noch 30 Minuten ohne Fahrstraße am Bahnsteig steht ist das weniger relevant – und bei Event mit amgleis=false dann in der eigenen Datenstruktur nachschauen, wo der Zug gerade gehalten hat), aber irgendwie traten immer wieder seltsame Fehler auf.

Jetzt habe ich mal wireshark angeworfen und festgestellt, dass bei einem der Züge, der losfahren wollte, aber noch kein grünes Signal hatte, im üblichen Rhythmus eine Nachricht mit amgleis=false und sogar sichtbar=false (!) gesendet wurde, dabei stand er in der visuellen Darstellung im Sim noch am Bahnsteig und wartete wie gesagt auf ein grünes Signal. Danach hätte er noch ein kurzes Stück fahren müssen und wäre dann im BW gelandet. Blöderweise ist wireshark wieder zu, aber wenn ich nicht falsch geschaut habe, kam die identische Nachricht bis zur tatsächlichen Abfahrt und dann nichts mehr.

Den tatsächlichen Abfahrtszeitpunkt feststellen könnte man, wenn ich jetzt nichts falsch gesehen habe, so nur noch ganz krude: Sobald die erste Abfahrtsmeldung kommt alle 1-2 Sekunden nachschauen, ob noch eine neue Abfahrtsmeldung für den Zug kam. Bleibt die Meldung für 1-2 Sekunden aus, so ist der Zug gerade abgefahren. Nicht wirklich schön zu programmieren und streng genommen hat man dann eine Race Condition (vielleicht hängt ja nur der STS-Client, der Rechner, oder irgendwas in der TCP-Verbindung mal für 2 Sekunden und daher bleiben die Abfahrtsmeldungen so lange aus).

Vermutlich kann ich auf das Event irgendwie verzichten, aber schöner wäre es finde ich, wenn das besser funktionieren würde (oder wenn es Absicht ist, der gedachte Einsatzzweck genauer dokumentiert wird).

[The-Tauri]

Hallo zusammen,

Danke für eure Rückmeldungen, fürs Mitdenken und Analysieren!

ich habe soeben folgendes Verhalten der Plugin-Schnittstelle beobachtet: [..]

Ich habe die Events noch nie benutzt, aber wenn deine Beobachtung so stimmt, würde ich das auch als "unpraktisch" oder als Fehler bezeichnen. Wenn je nach dem, ob zum erstmaligen Abfahrtsversuch eine gültige Fahrstraße gestellt ist, bei der Abfahrt dann unterschiedliche Gleise gemeldet werden ist das jedenfalls nicht ideal.

Ich nehme an, dass du selbst schon ähnliche Gedanken hattest, aber was ich in deinem Fall ganz konkret tun würde (nachdem ein Beitrag hier mit Hoffnung auf Fehlerbeseitigung noch nichts gebracht hat): Für jeden Zug (oder für jeden "Bahnsteig") ein Flag abspeichern, mit dem erfasst wird, wenn ein "erfolgloser" Abfahrtsversuch stattfindet (amgleis=true). Wenn eine "erfolgreiche" Abfahrt gemeldet wird, erkenne ich anhand des Flags, ob es direkt im ersten Abfahrtsversuch geklappt hat oder ob der Zug schon eine Weile versucht hat abzufahren, und somit ob der im Event übertragene Bahnsteig der nächste oder der vorherige Halt ist und kann mir je nach dem, was ich benötige, den anderen Wert aus vorher abgespeicherten Fahrplandaten oder über einen API-Request holen. Dann das Flag wieder zurücksetzen.

So habe ich mir das auch gedacht und für die Züge, die ein amgleis=true senden funktioniert es auch.

[...] aber irgendwie traten immer wieder seltsame Fehler auf.

Jetzt habe ich mal wireshark angeworfen und festgestellt, dass bei einem der Züge, der losfahren wollte, aber noch kein grünes Signal hatte, im üblichen Rhythmus eine Nachricht mit amgleis=false und sogar sichtbar=false (!) gesendet wurde, dabei stand er in der visuellen Darstellung im Sim noch am Bahnsteig und wartete wie gesagt auf ein grünes Signal. Danach hätte er noch ein kurzes Stück fahren müssen und wäre dann im BW gelandet. Blöderweise ist wireshark wieder zu, aber wenn ich nicht falsch geschaut habe, kam die identische Nachricht bis zur tatsächlichen Abfahrt und dann nichts mehr.

Den tatsächlichen Abfahrtszeitpunkt feststellen könnte man, wenn ich jetzt nichts falsch gesehen habe, so nur noch ganz krude: Sobald die erste Abfahrtsmeldung kommt alle 1-2 Sekunden nachschauen, ob noch eine neue Abfahrtsmeldung für den Zug kam. Bleibt die Meldung für 1-2 Sekunden aus, so ist der Zug gerade abgefahren. Nicht wirklich schön zu programmieren und streng genommen hat man dann eine Race Condition (vielleicht hängt ja nur der STS-Client, der Rechner, oder irgendwas in der TCP-Verbindung mal für 2 Sekunden und daher bleiben die Abfahrtsmeldungen so lange aus).

Vermutlich kann ich auf das Event irgendwie verzichten, aber schöner wäre es finde ich, wenn das besser funktionieren würde (oder wenn es Absicht ist, der gedachte Einsatzzweck genauer dokumentiert wird).

Ich werde noch eine Prüfung implementieren, die bei Abfahrts-Events prüft, was im letzten Ankunfts-Event dieses Zuges angegeben war (sofern es eines gab). Wenn bei der Abfahrt und amgleis=false nicht der Bahnsteig angegeben ist, der nach dem Ankunfts-Bahnsteig folgen würde, stimmt etwas mit dem Abfahrts-Event nicht. Ich bin noch am Überlegen, ob ich den Bahnsteig dann manuell ändere, oder in diesem Fall das Event einfach verwerfen soll.

Viele Grüße,
Moritz