Horizontale Schnittstellen

[Roland Ziegler]

Die vertikalen Schnittstellen sind wohl weitgehend unbestritten:

• Stellwerkslogik / Zusi (Weichen, Signale, Fahrstraßen, Zugmeldungen, Zugeinwirkung, Gleisbesetztmeldungen,...)
• Benutzeroberfläche / Stellwerkslogik

Diese Liste an der Schnittstelle zu Zusi ist schon nicht konsequent, wenn man genau hinguckt: Eine Zugmeldung ist schon eher was auf der horizontalen Ebene, von Stellwerk zu Stellwerk, und darum geht es mir hier.

Was wird zwischen Stellwerken (bzw Zugfolgestellen) ausgetauscht (peer to peer)?

• Zugmeldungen
• Vor/Rückblocken
• Erlaubniswechsel
• möglicherweise irgendwelche Schlüsselungen bei Sperrfahrten
• Bahnhofsblock: Befehlsabgabe, Zustimmungsabgabe
• Fahrstraßenauflösung bei Ff mit Wechselstromblock
• ...

Nach dem bisherigen Konzept wird auch der horizontale Datenaustausch über Zusi abgewickelt. Hieran möchte ich, wenn irgend möglich, festhalten, weil mir eine einheitliche und allumfassende Server-Rolle einfacher zu handhaben scheint.

Der interessante Punkt sind jetzt solche Messages, die von einer Gegenstelle (Peer) kommen müssen, und die Gegenstelle möglicherweise von ihrem Glück, diese Message senden zu müssen, noch nichts weiß.

Drei Beispiele:

1. Erlaubniswechsel: Stellwerk B möchte eingleisige Strecke nach C befahren. Benötigt dazu Erlaubnis von C. Ließe sich über eine formalisierte Anfrage von B an C im Rahmen des Kommunikationskanals umsetzen.
2. Bahnhofsblock: Stellwerk F benötigt Zustimmung für Fahrstraße vom Stellwerk W. Formalisierte Anfrage von F an W im Kommunikationskanal sollte das auslösen können.
3. Bahnhofsblock: Stellwerk W benötigt Befehl für Fahrstraße vom Stellwerk F. Eine formalisierte Anfrage von W and F im Kommunikationskanal wäre zwar vorstellbar, aber kaum vorbildkonform. Ich vermute mal, die Zugmeldung als auslösendes Kriterium geht aber an den Fdl im Stellwerk F, und der wird darauf von sich aus tätig.

Um diese Daten im horizontalen Datenauschtausch verarbeiten zu können, könnte es sein, dass das Zusi-interne Pseudo-Stellwerk entsprechende Funktionalität berücksichtigen muss, auch wenn bei einem reinen Zusi-Fdl-Betrieb wegen intern anderer Wge für Fahrstraßenanforderung davon kein Gebrauch gemacht wird.

[Andreas Karg]

Was du sicher schon im Geiste berücksichtigt hast, was aber in der Liste nicht drinsteht: Die Kommunikation des Stellwerkspersonals der Betriebsstellen untereinander, sprich: Eine Chatfunktion. Wie kompliziert die ausfallen soll ("Wähle Nachbarstellwerk" vs. virtuellen Hörer aheben und Nummer aus virtuellem Telefonbuch abtippen) sei mal dahingestellt, aber überhaupt sowas zu haben erscheint mir wichtig. Einerseits, damit man die Möglichkeit hat, in Zugpausen zu ratschen, andererseits natürlich, um Nachrichten/Meldungen auszutauschen, die nicht einem starren Syntaxschema folgen ("Wird Zug 12345 angenommen?" / "Zug 12345 wird angenommen." / "Ja, richtig").

[Roland Ziegler]

Ja, diese im Prinzip nicht formalisierte Kommunikation steht bereits in der Anforderungsliste.

Es könnte gut möglich sein, im selben Kanal auch besagte formalisierte Messages auszutauschen.

Auch die zitierten Zugmeldungen alter Güte, also fernmündlich, ließen sich natürlich über Templates formalisieren und damit vereinfachen, und für Zusi lesbar machen.

Übrigens, der Kommunikationskanal Stellwerk - Tf sollte ebenfalls bereits in der Afo-Liste stehen.

[Andreas Karg]

Ah, okay.

Ich hab mich da bereits in diversen Phantasien ergangen, wo man in der Simulation Streckenfernsprecher anrufen kann, und ein eventuell in der Nähe haltender Tf ein "Sie haben Post!"-Fensterle kriegt oder so. Aber ich glaub das wäre mit Spatzen auf Kanonen geschossen und hat mittelfristig ungefähr die Relevanz einer Windwarnanlage.

[Max Senft]

Hoi,

also da wäre es wohl am besten, wenn es fest definierte Kommandos gibt, die dann entsprechend in Zusi ebenfalls integriert sind, falls es mal keinen "lebenden" Nachbarfdl gibt. Diese sollte aber von der Chat-Funktion getrennt sein, da man ja, wenn Zusi dazwischenhängt, noch die ChatMsgs überprüfen müsste.

Ergo: Es sollte spezielle Kommandos geben, wie z.B. Erlaubniswechsel oder so, die Zusi versteht, aber auch fest dokumentiert sind, falls mal andere Stw-Programme am anderen Ende hängen. Die müssen das dann natürlich zwingend implementiert haben, sonst gibts da ein durchnander.

So long,
Max Senft

[Andreas Karg]

Eine Arbeitserleichterung für Carsten:
Ein Kommando "Erlaubnis abgeben!" AN den Nachbar-Fahrdienstleiter, sodass sich der menschliche FdL damit praktisch die Erlaubnis holen kann, wenn er sie braucht. Damit würden gegebenenfalls umständliche Erkennungsroutinen entfallen, wann denn nun die Erlaubnis abzugeben ist.
Normalerweise wird meines Wissens die Erlaubnis normal aber nach der Zugmeldung abgegeben (Mal bei den UseCases kruschteln), sodass zumindest eine billige Automatik (Zugmeldung->Erlaubnisabgabe) drin sein müsste. Aber es läuft ja nicht immer alles ganz nach Plan und so hätte der FdL noch eine kleine Rückfallebene, falls mal was etwas schief läuft. Nen realer Fahrdienstleiter wird notfalls sicher auch den Kollegen anrufen, und fragen, ob er bittschön nochmal die Erlaubnis haben könnte.

[Daniel Rüscher aka Merlin]

Hallo,

Eine Mitwirkung von Zusi an der Kommunikation ist, zumindest bei Lebenden Fdls nicht notwendig. Das mit der Erlaubnis funktuniert ja folgendermaßen:
Zugmeldegespräch (Wird Zug 12345 angenomen?/Ja Zug 12345 wird angenommen) - Erlaubnissabgabe FDL BDorf (EaGT EAT) - FDL AHausen empfängt Erlaubnis - Fdl Ahausen lässt Zug auf Strecke ab.
Bei den Automatisierten Stellwerken bevorzuge ich die Rechtsklickvariante wie in Sesam ausgeführt: Rechtsklick auf letztes Streckenelement/Erlaubnissempfang. Damit hätte sich die Variante das der virtuelle Zugfunk von Zusi abgehört werden muss erledigt. Nebenbei lässt das dann alle Freiheiten für die Zugfunkentwicklung offen.

Als Chatsystem böte sich DirectChat an. Evtl. später auch als Voicechat ausgeprägt. Direct X bringt die nötigen Techniken für sowas mit (siehe DirectX SDK).

[Roland Ziegler]

@Max und Andi:

Durch die Verwendung von Templates könnte ein im Prinzip textorientierter Kanal formalisierte Messages aufnehmen, ohne diese umständlich parsen zu müssen, genau wie Ihr das skizziert.

@Daniel:

Das Problem entsteht, wenn der Nachbar eben nicht ein augelagertes Stellwerk ist, sondern das Zusi-interne.

Und irgenwie widerstrebt es mir, bei der Erlaubnisabgabe oder Bahnhofsblock-Befehlsempfang die originäre Reihenfolge der Handlungen zu ändern bzw abzukürzen.

Für die Implementation eines Textkanals mit Templates sehe ich im Moment noch keine Notwendigkeit einer externen Lib. Der wird sich bei den bisherigen Anforderungen sicher unkomplizierter als Eigenbau in die sowieso selbst zu gestaltende Schnittstelle einfügen lassen, als die Einpassung eines externen Systems mit einer garantiert abweichenden Umgebung.

[Daniel Rüscher aka Merlin]

@Daniel:

Das Problem entsteht, wenn der Nachbar eben nicht ein augelagertes Stellwerk ist, sondern das Zusi-interne.

Und irgenwie widerstrebt es mir, bei der Erlaubnisabgabe oder Bahnhofsblock-Befehlsempfang die originäre Reihenfolge der Handlungen zu ändern bzw abzukürzen.

Naja, im Prinzip hat die Kommunikation nix mim Stellwerk zutun. Man könnte da Rauchzeichen implementieren wenn man könnte. Drum auch der Gedanke eines direkten Chatsystems, das auch für andere Sachen "Missbraucht" werden könnte (Ey du Tf 12345 mach ma langsamer, du hast ne RB vor dir).

Und das mit dem Rechtsklick is ja keine Abkürzung, sondern einfach ein Remoteprozeduraufruf. Abgesehen davon isses wesentlich einfacher zu Realisieren, weniger Leistungshungrig und Fehlerresistenter, als den kompletten Kommunikationsverkehr abzuhören.

Gruß Daniel[/quote][/url]

[Andreas Karg]

Roland: Templates entsprechen durchaus meinen Vorstellungen. Einziger Wunsch meinerseits wäre, dass das Ganze auch noch irgendwie aussieht als würde es tatsächlich "gesprochen", also nicht einfach ein Dialogfenster "Zugmeldung" mit einem Auswahlfeld für die Ziel-Betriebsstelle und einem Eingabefeld für die Zugnummer, sondern halt mehr Lückentext-Stil, wo man also mit dem tatsächlichen Wortlaut noch irgendwie in Berührung kommt.
Das macht nämlich meines Erachtens durchaus nen gewissen atmosphärischen Unterschied, besonders, wenn man auf einem Stellwerk ohne große Automatisierung sitzt.

[Roland Ziegler]

@Daniel:

Das Problem, was ich hier schildere, tritt auf, wenn das Nachbarstellwerk kein Stellwerk sondern Zusi ist. Bei meinem Ansatz müsste Zusi in diesem Fall die formale Kommunikation emulieren, die es selbst nicht braucht.

Daran und an der korrekten Reihenfolge möchte ich aus Nähe zum Vorbild gerne festhalten.

Ein Textkanal, der an der normalen Zusi-/Stellwerk-Schnittstelle mit dran hängt, kann als Abfallprodukt sicher auch Chat mit aufnehmen. Warum dafür dann ein zweites paralleles System, wenn es doch schon eines geben wird?

Asynchrone Messages zu synchronisieren, ist eines meiner "Hobbies", das bekommen wir schon hin. Bevor wir damals zu Corba gewechselt sind, hatten wir uns ein eigenes "RPC" geschaffen, das auf TCP-Sockets aufsetzte, und alle Ebenen ab Socket selbst implementiert. Verfahren ist also geläufig.

@Andi:

Da sehe ich kein Problem, wäre wohl eher ein Implementierungsdetail. Formalisiert muss es abgehen, wenn der Nachbar "nur" Zusi ist. Wenn ein Mensch da sitzt, kannst Du sicher auch nicht vorschriftenkonforme Zugmeldungen absetzen. Wenn Du so'ne Meldung an 'nen Zusi-Nachbar schickst und Du bekommst "hääh" zurück (oder wie auch immer Carsten sowas implementieren mag) dann kannst Du es ja etwas formaler nochmal versuchen.

[Andreas Karg]

Hmm. Einigen wir uns einfach auf eine Liste von Zusi-konformen "Vordrucken", die man nutzen kann, wenn man mag, oder auch nicht. Damit wären wohl alle zufrieden.

(Wie wär's, wenn wir die Vordrucke per Script.... achne, lassen wir das.)

[Michael_Poschmann]

(Ey du Tf 12345 mach ma langsamer, du hast ne RB vor dir).

Ich erinnere mich dunkel an die Afo "Zugbahnfunk" mit entsprechendem kodierten Befehlsumfang. Kurz danach sollte ich kielgeholt werden...

Michael

[Andreas Karg]

Hey, das wär doch nen schönes Feature für ambitionierte PlugIn-Programmierer.
Dann kriegt Daniel auch noch sein DirectX mit Voicechat und wir haben eine Zugfunk-funktion.

Ach, genau.
Vormerken: Bei Zusi3 unbedingt Befehlsvordrucke zum Ausdrucken mitliefern.
Wie wär's dann gleich mit einem Merchandising-Paket mit der ORIGINAL-Zusi-Befehlsklammer für zum an den Bildschirm kleben und dem ORIGINAL-Zusi-Befehlsblock. (Nur 59,95€ plus Versand beim Carsten Hölscher Ihres Vertrauens)

[Roland Ziegler]

Andi hat es schon passend formuliert.

An jenem windigen Morgen ging es ja um die Übermittlung von Befehlen, iirc. Das sah ich zunächst mal nicht als Teil des Kerngeschäfts an. Wenn man solche Templates dafür auch ohne Plugin nutzen können sollte, dann gerne.

Aber hier geht es mir im Moment nur um den Ansatz, dass für einige ganz gewöhnliche Bedienhandlungen eine "maschinenlesbare" Formalisierung von normalerweise freier Kommunikation sinnvoll wäre.

[Michael_Poschmann]

An jenem windigen Morgen ging es ja um die Übermittlung von Befehlen, iirc. Das sah ich zunächst mal nicht als Teil des Kerngeschäfts an.

Wenn ich sehr pessimistisch über den Fortgang des Stellwerksprojekts sinne, halte ich die Rückfallebene des Fahrens auf Befehl für gar nicht mal so irrelevant...

So, das war wieder grob unsachlich, am besten einfach drüber weglesen.

Michael
der heute 2 Arbeitsstunden "dank" Winword-Großversagens verloren hat und entsprechend gleich ein wenig Volleyball zum Abreagieren braucht.

[Patrick_Evert]

Zum Thema Zugmeldungen:

Könnte man nicht vom Grundsatz her die -zumindest im Bereich der ehem. DB- im Wesentlichen standardisierte Zugnummernmeldeanlage ZN 800 implementieren?

Diese arbeitet ja die Abmeldungen automatisch ab. Anbieten und Annehmen (bzw. weigern) müssen jedoch über standardisierte Tastenkommandos (Zugnr+Nachbar-Fdl+Gleisnr.+ANB bzw. ANN) gegeben werden.

Wenn man nun alle Zusi-Stellwerke grundsätzlich mit diesem System ausstattet, sollte die Kommunikation Zusi/Fdl/Zusi problemlos und realitätsnah vonstatten gehen. Gibt es jetzt einen zweiten "echten" Fdl, schaltet man die ZNA einfach ab und macht die Zugmeldungen "manuell" über einen Chat.

Gruß Patrick

[Roland Ziegler]

@Patrick:

ZN800 war mir für die formalisierte Zugmeldung auch in den Sinn gekommen. So in der Richtung stelle ich mir das vor.

Gibt es ähnliche formalisierte Vorbilder für Erlaubniswechsel- oder Bahnhofsblock-Anfragen?

[Andreas Karg]

Meines Wissens nicht, aber da könnten wir ja vorerst ein wenig schummeln und uns ein paar zusätzliche Knöpfe reindenken.

Frage: Hat jemand eine sinnvollere Idee für eine austauschbare Benutzeroberfläche für die Kommunikation als diese über ein PlugIn zu realisieren? Die Billigversion für "Hauptsach' geht", wie wir sie uns hier grade ausdenken, kann meinetwegen gern als Hardcode ins Programm, aber sie *sollte* mE zumindestens in irgendeiner Weise austauschbar sein.

[Patrick_Evert]

Nun, der Erlaubniswechsel steht ja in unmittelbarem Zusammenhang mit dem Anbieten/Annehmen. Man könnte also der Annahme kurze Zeit später (vorausgesetzt, dass kein Zug mehr auf der Strecke ist) die Erlaubnisabgabe folgen lassen.

Für die Bahnhofsblockbedienung gibt es keine vorgeschriebenen Wortlaute. Ich habs auch schon erlebt, dass der Wärter von sich aus die Zustimmung gegeben hat, weil laut Fahrplan ein Zug zu erwarten war.

Gruß Patrick