Schnittstelle zu anderen Programmen

[Christopher Spies]

Hallo!

Ich würde es sehr begrüßen, wenn BAHN über eine Schnittstelle verfügte, über die zur Laufzeit Informationen mit anderen Programmen ausgetauscht werden können.

Mir schwebt insbesondere vor, dass BAHN beim Befahren von Schaltkontakten Nachrichten an ein anderes Programm sendet, und dass dieses Programm mittels Nachrichten an BAHN den Zustand von Signalanlagen und ggf. auch den von Weichen ändern kann. Auf diese Weise könnten komplexe Stellwerkslogiken in ein externes Programm ausgelagert werden. Der hier schon mehrfach geäußerte Wunsch nach Fahrstraßenlogik könnte dann durch ein Zusatzprogramm erfüllt werden, das auch von Dritten erstellt werden könnte, sofern es der Schnittstellenspezifikation genügt. BAHN wäre dann hervorragend als Gegenstück zu einer Stellwerkssimulation geeignet.

Der Datenaustausch könnte beispielsweise wie bei Zusi per TCP/IP erfolgen.

Gruß
- Christopher

[Jan Bochmann]

Guten Abend,

Hallo!

Ich würde es sehr begrüßen, wenn BAHN über eine Schnittstelle verfügte, über die zur Laufzeit Informationen mit anderen Programmen ausgetauscht werden können.

Datenaustsuch in welchem Format? Binär oder Text? Text als ANSI (besser nicht), UTF-16 oder UTF-8?

Mir schwebt insbesondere vor, dass BAHN beim Befahren von Schaltkontakten Nachrichten an ein anderes Programm sendet, und dass dieses Programm mittels Nachrichten an BAHN den Zustand von Signalanlagen und ggf. auch den von Weichen ändern kann.

Synchron oder Asynchron?

Asynchron = BAHN meldet das und simuliert weiter.

Synchron = BAHN meldet das und hält an, bis irgendeine Reaktion oder zumindest Quittierung erfolgt.

Bei asynchroner Kommunikation wird die Simulation vermutlich nicht allzusehr ausgebremst. Allerdings dürfte das für den gewünschten Zweck wenig nützen.

Auf diese Weise könnten komplexe Stellwerkslogiken in ein externes Programm ausgelagert werden. Der hier schon mehrfach geäußerte Wunsch nach Fahrstraßenlogik könnte dann durch ein Zusatzprogramm erfüllt werden, das auch von Dritten erstellt werden könnte, sofern es der Schnittstellenspezifikation genügt. BAHN wäre dann hervorragend als Gegenstück zu einer Stellwerkssimulation geeignet.

Der Datenaustausch könnte beispielsweise wie bei Zusi per TCP/IP erfolgen.

Oder über irgendeine Schnittstellenfunktion in einer DLL. Ich glaube, das wäre das geringste Problem dabei.

Eine etwas genauere Auflistung von gewünschten Funktionen wäre aber als Spezifikation schon nötig.

Gruß,
Jan B.

[Sascha Claus]

Tagchen,

Zustand von […] Weichen ändern kann.

Weichen haben keinen Zustand, also kann den auch niemand ändern. Gefragt wäre hier wohl eine extern gesteuerte Weiche, die bei jedem vorbeikommenden Zug die Schnittstelle fragt, wohin dieser fahren soll (1, 2 oder ggf. 3, vielleicht noch warten wie bei signalabhängiger Weiche, wenn alle Signale rot sind).

Der hier schon mehrfach geäußerte Wunsch nach Fahrstraßenlogik könnte dann durch ein Zusatzprogramm erfüllt werden, das auch von Dritten erstellt werden könnte,

Wer würde denn? Könnte nutzt ja nix, wenn’s keiner macht.

sofern es der Schnittstellenspezifikation genügt. BAHN wäre dann hervorragend als Gegenstück zu einer Stellwerkssimulation geeignet.

Neue Märkte erschließen.

Datenaustsuch in welchem Format? Binär oder Text? Text als ANSI (besser nicht), UTF-16 oder UTF-8?

Text lieber nicht, denn der muss ja wieder geparst werden. Dann läuft ja nicht mal mehr das Strausberger „Straßen“bahnnetz in Echtzeit. Wenn’s »über irgendeine Schnittstellenfunktion in einer DLL« geht, dürfte binär doch einfach sein?

Eine etwas genauere Auflistung von gewünschten Funktionen wäre aber als Spezifikation schon nötig.

Bei extern gesteuerter Weiche „Adresse“ der Weiche und des Zugs, bei extern steuernden Signalkontakten „Adresse“ des Kontaktes und des auslösenden Zuges. Abfrage von Daten zu Weichen, Zügen, Signalanlagen und -elementen. Ändern von Signalanlagenzählern, Ausgabe der Richtung bei extern gesteuerten Weichen.

Vielleicht noch extern gesteuerte DWPs?

[Jan Bochmann]

Guten Tag,

Tagchen,

Zustand von […] Weichen ändern kann.

Weichen haben keinen Zustand, also kann den auch niemand ändern.

Ja. Man könnte aber z.B. eine Federweiche hierzu mißbrauchen, indem man deren Richtung "umschaltet". Ebenso wäre eine Verzweigung denkbar, bei der man die Hauptrichtung ändert. In den Linienlisten der Weiche muß ja nichts eingetragen sein (könnte aber, unabhängig davon).

Gefragt wäre hier wohl eine extern gesteuerte Weiche, die bei jedem vorbeikommenden Zug die Schnittstelle fragt, wohin dieser fahren soll (1, 2 oder ggf. 3, vielleicht noch warten wie bei signalabhängiger Weiche, wenn alle Signale rot sind).

Der hier schon mehrfach geäußerte Wunsch nach Fahrstraßenlogik könnte dann durch ein Zusatzprogramm erfüllt werden, das auch von Dritten erstellt werden könnte,

Wer würde denn? Könnte nutzt ja nix, wenn’s keiner macht.

Hier beißt sich die Katze in den Schwanz, wie bei manchen anderen Vorschlägen auch. Ohne solche Schnittstelle wird keiner versuchen, ein solches Programm zu schreiben.

sofern es der Schnittstellenspezifikation genügt. BAHN wäre dann hervorragend als Gegenstück zu einer Stellwerkssimulation geeignet.

Neue Märkte erschließen.

Unwahrscheinlich. Es gibt Stellwerkssimulationen, und ich glaube, das ist eine noch kleinere Nische als die für BAHN. Eine realistische Stellwerks-Simu kann doch nur jemand bedienen, der die passende Berufsausbildung dafür hat.

Datenaustsuch in welchem Format? Binär oder Text? Text als ANSI (besser nicht), UTF-16 oder UTF-8?

Text lieber nicht, denn der muss ja wieder geparst werden. Dann läuft ja nicht mal mehr das Strausberger „Straßen“bahnnetz in Echtzeit. Wenn’s »über irgendeine Schnittstellenfunktion in einer DLL« geht, dürfte binär doch einfach sein?

Bei binär muß man sich auf genaue Datentypen einigen. Da BAHN nur mit ganzen Zahlen arbeitet, sollte das kein wirkliches Problem sein. Beim Austausch von Gleitkommazahlen zwischen unterschiedlicher Software oder gar Hardware hat sich aber die Textdarstellung tatsächlich als nahezu einzige allgemein verwendbare Methode bewährt.

Eine etwas genauere Auflistung von gewünschten Funktionen wäre aber als Spezifikation schon nötig.

Bei extern gesteuerter Weiche „Adresse“ der Weiche und des Zugs, bei extern steuernden Signalkontakten „Adresse“ des Kontaktes und des auslösenden Zuges.

Was ist "Adresse"? Ein Koordinaten-Tripel (x,y,z)? Oder die Weichennummer bzw. der Objektname (Taktpunkt, Datenwechsel, Signal, Kontakt)? Die letztere Methode hätte den Vorteil, daß man das Objekt im Netz auch woanders hin schieben kann, ohne das externe Programm anpassen zu müssen. Aber genau deshalb kam oben die Frage nach Text oder binär...

Abfrage von Daten zu Weichen, Zügen, Signalanlagen und -elementen. Ändern von Signalanlagenzählern, Ausgabe der Richtung bei extern gesteuerten Weichen.

Und wohl mindestens noch eine Abfrage / Synchronisationsmöglichkeit zur Simulationszeit.

Vielleicht noch extern gesteuerte DWPs?

An denen welche Angaben geändert werden sollen/können? Alle, die bisher gehen, oder genügt ein Subset (Teilmenge), oder braucht man weitere?

Grüße,
Jan B.

EDIT: Rechtschreibung korr.

[Christopher Spies]

Hallo allerseits,

Synchron oder Asynchron?
Asynchron = BAHN meldet das und simuliert weiter.
Synchron = BAHN meldet das und hält an, bis irgendeine Reaktion oder zumindest Quittierung erfolgt.
Bei asynchroner Kommunikation wird die Simulation vermutlich nicht allzusehr ausgebremst. Allerdings dürfte das für den gewünschten Zweck wenig nützen.

ich hatte eigentlich gedacht, eine asynchrone Ausgabe würde ausreichen. Bei höheren Geschwindigkeiten könnte die bis zum Eintreffen der Reaktion vergehende Simulationszeit allerdings problematisch sein. Insofern wäre eine synchrone Kommunikation vielleicht besser.

Man könnte aber z.B. eine Federweiche hierzu mißbrauchen, indem man deren Richtung "umschaltet".

Genau so hatte ich mir das vorgestellt; das wäre ja auch vorbildgetreu.

Gefragt wäre hier wohl eine extern gesteuerte Weiche, die bei jedem vorbeikommenden Zug die Schnittstelle fragt, wohin dieser fahren soll

Das müsste meiner Meinung nach nicht unbedingt sein, wäre aber durchaus denkbar.

Es gibt Stellwerkssimulationen, und ich glaube, das ist eine noch kleinere Nische als die für BAHN.

So klein kann diese Nische nicht sein, wenn es derart viele verschiedene Stellwerksimulationen gibt. Mir fallen auf Anhieb EStwSim und die Produkte der Firma Signalsoft ein, zusätzlich gibt es zahlreiche Hobbyprojekte. Die Bedienung eines Stellwerks im Regelbetrieb ist ja recht einfach. Problematisch sind die vielfältigen Störungen, die aber oft nicht simuliert werden.

Eine Stellwerkssimulation muss immer auch eine Simulation und eventuell auch eine Visualisierung der Außenanlagen beinhalten. Mit der von mir vorgeschlagenen Schnittstelle könnte BAHN diese Aufgaben übernehmen.

Bei binär muß man sich auf genaue Datentypen einigen.

Man kann Binärdaten und Text ja auch mischen. Solange das Format unzweideutig spezifiziert ist, sollte es keine Probleme geben.

Eine etwas genauere Auflistung von gewünschten Funktionen wäre aber als Spezifikation schon nötig.

Folgende Funktionen würde ich mir wünschen:

• Ausgabe der "Adresse" (Name oder eindeutige Nummer) ausgelöster Kontakte, ggf. auch
  • Ausgabe der Schaltfunktion des Kontakts sowie
  • der Linie und Zugnummer des auslösenden Zugs und
  • unterschiedliche Meldungen bei Befahren und Verlassen des Kontakts, wobei anders als bislang "Verlassen" auch das vollständige Freifahren des Elements bedeuten sollte
• Möglichkeit, Signalanlagen durch Angabe ihrer "Adresse" auf frei oder gesperrt zu schalten, ggf. auch
  • die Stellung von Federweichen durch Angabe ihrer "Adresse" zu verändern

Gruß
- Christopher

[Jan Eisold]

Hallo !

Ich finde die Idee, einen Austausch von Daten zwischen BAHN und anderen Programmen zu ermöglichen, sehr interessant. Damit würde sich vermutlich eine Reihe von Möglichkeiten ergeben.

Ich muss allerdings, was den Wunsch nach einer externen Stellwerkssimulation angeht, ein wenig auf die Euphorie-Bremse treten. Wenn man sowas realisiert, und das geht nur in Form eines synchronen Datenaustausches, wird es trotzdem noch nötig sein, für jeden Bahnhof in BAHN ein eigenes Stellwerksprogramm (bzw. einen Programmteil) zu schreiben. Das wird sicherlich für kleinere Netze funktionieren, aber nicht für richtig große, bei denen man andererseits die Effekte realistischer Stellwerkstechnik erst so richtig bemerkt. Auch im wahren Leben ist jedes speicherprogrammierbare Stellwerk in Bezug auf seine Software eine Einzelanfertigung. Mit Hilfe des Spurplanprinzips lässt sich zwar die Logik für beliebige Topologien sehr einfach erzeugen, trotzdem sind auch hier noch viele händische Eingaben erforderlich (Durchrutschwege, Geschwindigkeiten, Zwieschutzweichen, fortgesetzte Fahrstraßen,...).

Die Auslagerung der Stellwerksfunktionen an ein externes Programm mit Hilfe der jetzt diskutierten Schnittstelle ist sicherlich ein gangbarer und gar nicht mal so schlechter Weg. Die Lösung des Problems der Abbildung der Stellwerkslogik ist allerdings damit immer noch offen. Und auch die Fahrdynamik müsste noch stark verbessert werden, ehe sowas wirklich sinnvoll funktioniert.

MfG Jan

[micha88]

Zweifellos würde selbst eine minimalistischer und sehr effiziente Erweiterungsschnittstelle BAHN ausbremsen, und es müssten sich auch erst noch Programmierer finden, die eine Erweiterung programmieren würden. Allerdings wurde ja bisher in BAHN die steigende Leistungsfähigkeit der PCs auch immer ganz gut mit neuer/erweiterer Funktionalität ausgeglichen - vielleicht ist ja in ein paar Jahren auch mal die Zeit für Erweiterungen gekommen. Also habe ich mir in einem Anfall von Langeweile mal etwas ausführliche Gedanken darüber gemacht, wie so eine Schnittstelle denn nun aussehen könnte:

BAHN bekommt ein neues Element "Aktionselement", ähnlich einem Schaltkontakt (Gültig für eine oder beide Richtungen, nur für bestimmte Linien, zug- oder fahrzeugweise Auslösung usw.), bei Passieren durch einen Zug/Fahrzeug wird die Funktion "Aktion" (siehe unten) der Erweiterung aufgerufen. (Natürlich nicht direkt bei Passieren, sondern gessammelt für alle passierten Aktionspunkt nach ansonsten vollständig durchgeführtem Simulationsschritt.) Der Funktion wird eine Aktionsnummer übergeben, die im "Aktionselement" einzugeben ist (statt einer Schaltwirkung bei Signalanlagen), aktuelle Uhrzeit und Datum der Simulation sowie ein Identifikator für den passierenden Zug und ggf. die Nummer des passierenden Fahrzeugs (fortlaufend gezählte Position im Zug).
Auf diese Weise dürfte der Geschwindigkeitsverlust auch eher gering sein, wenn diese Funktion in BAHN nicht genutzt wird?

Die Erweiterungen hat folgende zwei Funktionen als Fest definierte Schnittstelle, die von BAHN aufgerufen werden können:
"Initialisierung" - wird direkt nach dem Laden des Netzes aufgerufen um ggf. Erweiterungs-intern irgendwas zu initialisieren, zudem irgendwo in BAHN die Möglichkeit, per Button diese Initialisierung später nochmal anzustoßen
"Aktion" - wird bei passieren eines Aktionselements aufgerufen

BAHN bietet folgende Funktionen, die durch die Erweiterung aufgerufen werden können:
"SignalanlageFinden" - die Erweiterung übergibt einen Signalanlagennamen als Zeichenkette und bekommt, wenn es eine solche Signalanlage gibt, einen Identifikator für diese Signalanlage
"SignalanlageLesen" - Erweiterung übergibt Signalanlagen-Identifikator und kann die drei Zählerwerte lesen
"SignalanlageZaehlerSetzen" - die Erweiterung setzt über den Signalanlagen-Identifikator für die entsprechende Signalanlage einen neuen Zählerwert
"ZugLesen" - Erweiterung kann anhand eines Zug-Identifikators Eigenschaften des Zugs lesen (Linienname, Nummer, Zugtyp, Höchstgeschwindigkeiten, Länge, ...)
"ZugSchreiben" - Erweiterung kann anhand eines Zug-Identifikators Eigenschaften des Zugs setzen (im Prinzip alles das, was man an einem Datenwechselpunkt ändern kann zzgl. alle 4 einzelnen Geschwindigkeits-Werte)
"ZugRangieren" - Erweiterung kann anhand eines Zug-Identifikators den Zug wenden/trennen/in den Kuppelzustand versetzen (mit zu übergebenden Parametern wie bei einem Rangierpunkt) oder den Zug eine angegebene Zeit lang halten lassen
"Fehler" - Erweiterung setzt einen Text als benutzerdefinierte Dispatcher-Nachricht ab und stoppt ggf. die Simulation.
"Timer" - Erweiterung übergibt (Simulations-)Wochentag und Uhrzeit und einen Aktionsnummer an BAHN. BAHN ruft dann einmalig zur angegebenen Zeit die Funktion "Aktion" der Erweiterung auf und übergibt die Aktionsnummer.
"FahrzeugLesen" - Erweiterung kann über Zug-Identifikator und Position des Fahrzeugs im Zug (1., 2., 3. ...) auslesen, um welches Fahrzeug es sich handelt (Fahrzeugsatz-Nummer, Nummer im Fahrzeugsatz und Fahrzeug-Länge) *1

Wem das jetzt alles zu kompliziert war, der sollte nicht weiter von einer Erweiterung träumen. Prinzipiell ist das trotzdem nur ein grobes Konzept, programmieren kann man das so noch lange nicht...

Was wahrscheinlich damit nicht geht:
Verbindung zu anderen parallelen Simulationen. Also z.B. ein zweites BAHN, in dem ein anderes Netz synchron läuft und z.B. Züge vom einen ins andere Netz fahren. Dafür müsste man mehrere Simulationen synchronisieren. Das geht sicher auch irgendwie, aber ich habe keine Ahnung, ob und wie man so etwas effizient umsetzen kann.

Was man mit so einer Schnittstelle anfangen könnte:
Von den bisher mal gewünschten Funktionen könnte man z.B. signalanlagenabhänge Rangierpunkte/Datenwechsel/Langsamfahrstellen, Abwarten von Anschlüssen mit definierter Übergangszeit umsetzen, ebenso eine Signalisierung mit richtigen Fahrstraßen, verschiedenen Einfahrgeschwindigkeiten (siehe hier: http://www.das-bahn-forum.de/bahnforum/ ... f=3&t=3435) usw.

Natürlich müsste dann noch jemand ein allgemeines Fahrstraßen-Plugin schreiben,
der Nutzer müsste alle erfolrderlichen Aktionspunkt, Schaltkontakte, Signalanlagen anlegen und
(in einem noch zu erfindenden Dateiformat) sehr detailliert die Fahrstraßen-Struktur des Netzes aufschreiben ((Teil-)Fahrstraßen topologisch oder tabellarisch mit all ihren Eigenschaften, sowie die Verknüpfung zu den BAHN-Daten, d.h. z.B. die Belegung von Gleis-Abschnitt 123 wird durch die Signalanlage XY_G123 repräsentiert, das Hauptsignal N123 kann durch die Signalanlage XY_N123 gesteuert werden, Zuglenkpunkt XY_A hat die Aktionsnummer 0815 usw.).

Noch komplizierter könnte man natürlich auf dieser Basis sogar eine automatische Disposition entwickeln, in dem die Erweiterung über die Aktionspunkte quasi mitschreibt, welcher Zug gerade wo ist und daraus automatisch irgendwelche Entscheidungen ableitet (wenn ein Zug der Linie G13 den Bahnhof XY erreicht, soll die Fahrstraße ins Überholungsgleis 3 eingestellt werden und der Zug dort so lange stehen, bis ein Zug der Linie ICE25 den Bahnhof passiert hat).

Ebenso könnte man vielleicht sogar mehr oder minder asynchron eine Stellwerkssimulation anbinden - d.h., Belegungsinformationen/Zugmeldungen werden über die Aktionspunkte nur mitgelesen, und ab und zu werden die eingestellten Fahrstraßen usw. durch Ändern von Signalanlagenzähler in BAHN übertragen. (Das muss sicher nicht in jedem Simulationsschritt geschehen - mehr als ein Zug, der vom Halt erwarten zeigenden Vorsignal ausgebremst wird, kann ja nicht passieren). Im Gegensatz zu reinen Stellwerkssimulations-Programmen hat man aber das Problem, dass man nicht irgendeinen Startzeitpunkt vorgeben kann, bei dem man beginnt - sondern man muss dann eben wirklich immer den ganzen Tag bzw. die ganze Woche durchspielen!

*1 Wenn man noch, wie schonmal diskutiert, einführt, dass jedes Fahrzeug eines Zugs eine Eigenschaft bekommt, die auch beim Rangieren erhalten bleibt, könnte man auch sehr ausgefeilte Ablaufsteuerungen entwickeln.

Und grundsätzlich gilt für alle denkbaren Anwendungsfälle: Entweder, man schreibt für einen ganz bestimmten Fall ein spezielles Plugin - dann muss dieses bei jeder Änderung am Netz auch geändert und neu kompiliert werden. Oder es werden mit deutlich mehr Aufwand allgemeine Plugins geschrieben - dann müssen mit dem Netz stets noch zusätzliche Datendateien (eben z.B. die Fahrstraßen) mitgeführt werden, die auch immer aktuell gehalten werden müssen!
Ebenso würde sich die Plugin-Schnittstelle sich sicherlich auch alle paar Versionen ändern - alle Plugins müssen dann angepasst werden, sonst laufen die entsprechenden Netze mit der neuen BAHN-Version nicht. Ebenso müssten die Plugin-Programmierer immer darauf achten, dass das Plugin auf allen Systemen läuft, auf denen BAHN auch läuft - ich fürchte fast schon, dass das nicht passieren wird...

Einfach und Benutzerfreundlich wird das ganze also in keinem Fall, selbst, wenn man selber nicht programmieren muss.

Fazit: Wäre also schon eine sehr mächtige "Waffe", die meiner naiven Vorstellung nach keine allzugroßen Änderungen an BAHN erfordern würde. Aber es müsste eben jemand bereit sein, solche Plugins zu entwickeln, und es müssten sich genügend Nutzer finden, die mit den komplexen Möglichkeiten dieser Plugins auch arbeiten können...

[Christopher Spies]

Werte versammelte Experten,

ich möchte nachfolgend kurz schildern, wie ich mir eine BAHN-externe Fahrstraßen-Erweiterung und ihre Kommunikation mit BAHN vorstelle. Meine Beschreibung soll bewusst der konkreten technischen Umsetzung nicht vorgreifen, weswegen ich (anders als Micha) nicht einzelne Funktionsaufrufe beschreibe.

Michas Idee mit den "Aktionspunkten" finde ich sehr gut. Damit kann die Kommunikation auf das tatsächlich benötigte Maß verringert werden, weil nur beim Befahren eines solchen Aktionspunkts (und nicht beim Befahren anderer Wirkelemente wie Signalanlagenkontakten) Daten mit der Erweiterung ausgetauscht werden müssten.

Die Funktion eines derartigen Aktionspunkts stelle ich mir so vor:
Beim Befahren eines Aktionspunkts durch einen Zug wird die Erweiterung über dieses Ereignis informiert. Die Erweiterung erkennt die Linie, auf welcher der Zug verkehrt, und ggf. noch weitere Zugeigenschaften wie Zugnummer, Ein-/Ausrückzustand usw.; welche dieser Daten BAHN beim Befahren des Aktionspunkts der Erweiterung mitteilt, ob Aktionspunkte (wie Logpunkte auch) linienabhängig sein können und welche Daten die Erweiterung bei BAHN erfragt, ist erst einmal egal und ich möchte darauf an dieser Stelle nicht näher eingehen.
Wie bei Logpunkten auch, sollte wählbar sein, ob beim Erreichen, beim Verlassen oder in beiden Fällen ein Ereignis ausgewählt werden soll.

Den Ablauf und die Arbeitsweise einer Fahrstraßen-Erweiterung für BAHN bei einer Zugfahrt stelle ich mir folgendermaßen vor:

1. Ein Zug befährt einen Aktionspunkt, der in der Erweiterung eine Fahrstraße für diesen Zug anfordert.
   Dazu müssen die Aktionspunkte durch Namen oder Kennnummern eindeutig unterscheidbar sein, und der Nutzer muss der Erweiterung mitteilen, welche Fahrstraßen es gibt und welcher Aktionspunkt der Anforderung welcher Fahrstraßen dient.
   Eine Fahrstraße kann auch zeitgesteuert kurz vor der planmäßigen Abfahrt an einem Taktpunkt angefordert werden.
2. Die Erweiterung prüft, ob der Zielabschnitt frei ist.
   Das könnte in BAHN mittels einer Signalanlage mit entsprechenden Schaltkontakten geschehen, deren Zustand von der Erweiterung ausgelesen wird, oder die Erweiterung könnte selbst darüber Buch führen. In jedem Fall muss der Nutzer definieren, welche Gleisabschnitte für welche Fahrstraße relevant sind.
3. Ist der Zielabschnitt frei, prüft die Erweiterung, ob irgendwelche feindlichen Fahrstraßen eingestellt sind.
   Welche Fahrstraßen sich gegenseitig ausschließen, kann zum Teil automatisch erkannt werden (z. B. bei gleichem Startsignal oder Zielabschnitt); weitere Ausschlüsse muss der Nutzer der Erweiterung mitteilen.
4. Sind alle Vorbedingungen erfüllt, weist die Erweiterung BAHN an, eine bestimmte Signalanlage freizuschalten.
   Diese Signalanlage ist an Vor- und Hauptsignalen und signalabhängigen Weichen im Netz eingetragen, so dass in BAHN das Signal für den Zug in Fahrtstellung kommt und der Zug auf das richtige Gleis geleitet wird.
5. Sobald der Zug einen weiteren Kontaktpunkt verlässt, wird die Fahrstraße aufgelöst.
   Alternativ erfolgt die Auflösung nach Besetzung des Zielabschnitts (ggf. mit einer gewissen Zeitverzögerung).

Als absolute Minimalanforderungen würde ich daher ansehen, dass

• BAHN die Erweiterung darüber informiert, wenn ein bestimmter Punkt im Streckennetz von einem Zug befahren wird,
• BAHN die Erweiterung darüber informiert, wenn ein bestimmter Punkt im Streckennetz von einem Zug geräumt wird,
• die Erweiterung den Zustand beliebiger Signalanlagen in BAHN abfragen kann und
• die Erweiterung den Zustand beliebiger Signalanlagen in BAHN ändern kann.

Gruß
- Christopher

[Cappy]

Hallo Leute!

Wenn auch erst Monate später, so möchte ich zu diesem Thema auch mal einen kleinen Satz loswerden, da auch mich die Themen "Schnittstellen" und "Fahrstrassen" etc. interessiert. Was ich so in den vorhergehenden Beiträgen gelesen habe erinnert mich immer wieder an die "Lenktabellen" meines ehemaligen ESTW-S. Was ich als Problem sehe, ist die riesige Datenmenge, die hier verarbeitet werden müsste. Erst einmal müsste, wenn es denn ein externes Programm gäbe, jeder Strecken- und Bahnhofsbereich editierbar sein. So benötigt man für einen 2 gleisigen Bahnhof, dessen beide Bahnhofsgleise in beiden Richtungen befahren werden, 6 frei editierbare Datenpunkte: Je ein Datenpunkt Einfahrgleis/Einfahrsignal, dann für jedes Bahnhofsgleis einen Datenpunkt und natürlich je einen Zieldatenpunkt. Weiterhin muss man dann entsprechend wissen, ob man nur Linien oder gar nach Zugnummern steuern möchte. Und wer es vielleicht noch komplizierter haben will, Wochentagsangaben/Verkehrszeiten. Ich selbst habe bei Siemens-Verkehrstechnik in Berlin mit einem Kollegen die Lenktabelle für unser ESTW-S geschrieben und weiß daher, welche Mengen an Daten dies allein für einen mittelgroßen Bahnhof werden können. Umgesetzt auf BAHN und dessen vielfältige Gestaltungs- und Ausbaumöglichkeiten, nehmt es mir nicht übel, halte ich sowas für unsinnig. Denn es geht ja hier um ganze, zu steuernde Netze. Zumindest möchte ich dann nicht derjenige sein wollen, der die Daten eingibt . Falls irgend jemand die Lenktabellen nicht kennt, bin ich gern bereit, eine fiktive Lenktabelle mal schematisch bereit zu stellen, nur damit sich jeder mal etwas darunter vorstellen kann. Ich denke aber, dieses Thema hatte ich bereits unter dem Thread bezüglich Fahrstrassen beschrieben.

Gruß Jens

[Christopher Spies]

Hallo Jens,

Umgesetzt auf BAHN und dessen vielfältige Gestaltungs- und Ausbaumöglichkeiten, nehmt es mir nicht übel, halte ich sowas für unsinnig. Denn es geht ja hier um ganze, zu steuernde Netze. Zumindest möchte ich dann nicht derjenige sein wollen, der die Daten eingibt

ich verstehe Deinen Einwand. Ich hatte bei meinem Vorschlag nicht an riesige Netze wie z. B. Eberhards Modellbahn gedacht, sondern an kleine und kleinste Netze mit z. B. nur einem Bahnhof.

Falls irgend jemand die Lenktabellen nicht kennt, bin ich gern bereit, eine fiktive Lenktabelle mal schematisch bereit zu stellen, nur damit sich jeder mal etwas darunter vorstellen kann.

Ich habe den Begriff Lenktabelle bislang noch nicht gehört und würde gern mal eine sehen.

Gruß
- Christopher

[Cappy]

Hallo Christopher!

Ich hoffe mal ich kann anhand der beiden nachfolgenden Bilder die Lenkung etwas veranschaulichen.
Als erstes erstmal ein Bild vom Beispielbahnhof:


Dazu nun die Lenktabelle als Beispiel, diese weicht von der realen Lenktabelle dahingehend ab, dass ich statt Zugnummern Linien verwendet habe.


Zur Erklärung:
E105 = Startpunkt (meist Einfahrsignal) Hier wird die Fahrstrasse angesteuert
A101 (A103) = Zielpunkt für die Einfahrt, Startpunkt für die Ausfahrt
E109 = Zielpunkt für die Ausfahrt

EZ (siehe Lenktabelle) = Einbruchszeit (hierauf könnte man unter Umständen verzichten)

Anstelle der Linien könnte man in der Lenktabelle auch Zugnummern verwenden, welche man in Bahn bereits verwendet, also bestehend aus Linie und Zugnummer (Bsp.: 500/2 = Linie 500 Zugnr. 2). Im ESTW-S wird ja auch über Zugnummern gelenkt.
Für einen großen Bahnhof mag diese Art der Zuglenkung sicher sinnvoll sein, wenn man einzelne Zugfahrten gelenkt haben möchte, andererseits: Bei kleinen Bahnhöfen bin ich persönlich dafür, diese über normale Verzweigungen (mit Linienangabe oder Zugnummernangabe) zu steuern.

Übrigens: Die Lenktabelle ist nur ein nachgestelltes Beispiel. Regulär ist die Tabelle um etliches komplexer und steuert ganze ESTW-Steuerbereiche. Leider gibt es in meiner Sammlung kein entsprechendes Foto dazu.

Gruß Jens

[Jan Eisold]

N´Abend !

Übrigens: Die Lenktabelle ist nur ein nachgestelltes Beispiel. Regulär ist die Tabelle um etliches komplexer und steuert ganze ESTW-Steuerbereiche.

Naja, richtig müsste es heißen: Über die Lenktabelle werden Fahrstraßen im ESTW angestoßen. Dann weiß das Stellwerk, welche Fahrstraßen ein Zug befahren soll, aber das eigentliche Stellwerk braucht man eben trotzdem noch. Was zu den jeweiligen Fahrstraßen gehört, das weiß die Lenktabelle nämlich nicht.

MfG Jan

[Cappy]

N´Abend !
Naja, richtig müsste es heißen: Über die Lenktabelle werden Fahrstraßen im ESTW angestoßen. Dann weiß das Stellwerk, welche Fahrstraßen ein Zug befahren soll, aber das eigentliche Stellwerk braucht man eben trotzdem noch. Was zu den jeweiligen Fahrstraßen gehört, das weiß die Lenktabelle nämlich nicht.

MfG Jan

Nun gut, ich dachte, dass spricht als Beispiel für sich selbst. Der Anstoß erfolgt im Allgemeinen ja durch die Zugnummer, oder in meinem genannten Beispiel durch die Linie. Der Anstoßpunkt könnte ein Kontakt einer vorgelegenen Betriebsstelle sein oder wie auch immer. Wobei hier vermutlich das Problem bestünde, wenn mehrere Strecken auf einen Bahnhof zulaufen und zwei Züge gleichzeitig die Lenkung anstoßen. Hier müßte ausgeschlossen werden, dass beide Züge sich gefährden. Also Einer nach dem Anderen. Hierzu müsste sich das System jedoch "merken", dass zwei "Fahrstrassen" angestoßen worden sind und diese nacheinander abarbeiten.

Jetzt wirds kompliziert...

Gruß Jens

[Jan Eisold]

Der Anstoß erfolgt im Allgemeinen ja durch die Zugnummer, oder in meinem genannten Beispiel durch die Linie. Der Anstoßpunkt könnte ein Kontakt einer vorgelegenen Betriebsstelle sein oder wie auch immer. Wobei hier vermutlich das Problem bestünde, wenn mehrere Strecken auf einen Bahnhof zulaufen und zwei Züge gleichzeitig die Lenkung anstoßen. Hier müßte ausgeschlossen werden, dass beide Züge sich gefährden. Also Einer nach dem Anderen. Hierzu müsste sich das System jedoch "merken", dass zwei "Fahrstrassen" angestoßen worden sind und diese nacheinander abarbeiten.

Jetzt wirds kompliziert...

Gruß Jens

Ja, genau, so könnte man das realisieren. In der Vergangenheit bestand aber genau das Problem, dass sich BAHN nicht so richtig "merken" konnte, dass da zwei Fahrstraßen angefordert wurden, sondern die Schaltzustände passen sich beim Befahren der Schaltkontakte sofort an. Somit ist es möglich, dass ein als zweiter auf den Fahrstraßenknoten zufahrenden Zug eine höher priorisierte Fahrstraße erhält und dabei einem anderen Zug das bereits Fahrt zeigende Signal wieder auf Halt wirft.

MfG Jan