Anwendertipp Geschwindigkeitsumrechnung

Geschwindigkeitsumrechnung

Wozu eine Geschwindigkeitsumrechnung für eine digitale Steuerung und auch Railware ??? Warum müssen wir uns damit befassen? Railware kennt doch die Geschwindigkeiten, wenn ich die entsprechenden Werte an der Strecke eingebe sowie für Züge und Loks die entsprechende Höchstgeschwindigkeit angebe.



Ganz einfach, uns fehlt oft die Vorstellung, was in einem bestimmten Zeitabschnitt auf der Anlage geschieht. Die Geschwindigkeit spielt dabei schon eine wesentliche Rolle.

Wenn man sich nun bei einer digitalen Steuerung vor Augen führt, dass es für die Ereignissteuerung bei einem automatischen Fahrbetrieb (so auch automatisches Fahren und Bremsen) im Gesamtsystem folgende Grundeigenschaft benötigt:

• Ereignis auf der Anlage erzeugen (Taster betätigen; Schienenstück befahren mit Strommessfühlung; Read-Kontakt? überfahren; usw.),
• Ereignis technisch feststellen (digitaler Rückmelderbaustein wertet das Ereignis aus) und Ereignis an Digitalzentrale (ggf. einstellbare Verzögerung des Melders beachten und zeitlichen Ablauf der technischen Bauart des Meldebussystems beachten) melden und aufbereiten für das Senden an den Computer,
• Ereignis von der Digitalzentrale über den Computer (und ggf. im Netzwerk über dieses) der Software übermitteln,
• Ereignis in der Software verarbeiten; Reaktion erzeugen,
• Reaktion an die Zentrale senden und
• Zentrale sendet dies an den Empfänger.

Dieser Prozess läuft im Prinzip genau so ab, wenn z.B. ein Zug in einen neuen Belegtmelderabschnitt einfährt und dann durch Auslösen des Belegtmelders aufgrund eines roten Signals abgebremst werden soll.

Durch das Auslösen des Belegtmelders erfährt Railware für die Zugverfolgung, dass der Zug in dem neuen Abschnitt in der Anlage angekommen ist. Gleichzeitig stellt es beim Prüfen einer weiteren Fahrstraße fest, dass der Zug anhalten muss, weil das Signal auf Rot steht und kein weiterer Weg derzeitig möglich ist. Nun muss Railware aufgrund der vorhanden Grunddaten (Lokdatenbank-Infos, Wegeinformationen) die Entscheidung treffen, wann welche Fahrstufen gesendet werden müssen, damit der Zug entsprechend den Grunddaten (Bremsweg) vor dem Signal halten soll.

Nehmen wir einmal an, wir sind in der Spur N.

Der Zug (ICE 1) kann modelltechnisch tatsächlich 250 km/h fahren und der Oberbau des Schienenweges lässt dieses auch zu, ohne dass wir unseren ICE unterhalb der Platte in Einzelteilen suchen müssen, dann legt dieser in 1 Sekunde ca. 43,40 cm zurück.

Angenommen der Bremsweg wäre für den Gleisabschnitt 60 cm, weil der Belegtmelder nichts weiter hergibt, dann müsste Railware schon Nothalt senden, so dass der Zug sofort halten müsste. Ich glaube nicht, dass er dies tun würde, selbst wenn man ihm den „Saft“, sprich Strom abdrehen würde. Mit Sicherheit würde der ICE auf Grund der Masse des Zuges, der hohen Geschwindigkeit und der ggf. sogar noch vorhandenen Schwungmasse über den Gleisabschnitt hinaus fahren.

Viel schlimmer ist, wir sind davon ausgegangen, dass wir von dem optimalen Gesichtspunkt ausgegangen sind, Belegtmelder löst aus und sofort Nothalt! Wie oben aber ausführlich beschrieben, ist ein Zeitverzug da, so dass in keinem Fall ein Belegtmelder etwas sofort auslösen kann. Je nach Zentrale, Bus-System?, Dekoder, Dateninterface, Datenprotokoll, Computerausstattung, Betriebsmenge verzögert sich eine solche Situation. Ich will damit sagen, wir müssen unserer digitalen Steuerung auch noch die Chance geben, nach einem Ereignis geeignete Befehle zu erzeugen und abarbeiten zu können.

Nehmen wir an, die Geschwindigkeit würde für einen solchen Abschnitt auf 60 km/h – Modellgeschwindigkeit verringert werden, dann würde unser ICE ca. 10,42 cm/s tatsächlich zurücklegen. Hiermit hätten wir sicherlich gute Karten, eine Reaktion bis zum Halt vor dem Signal zu erzeugen und den Zug sogar zum Stehen zu bringen.

Es gibt nun zwei Möglichkeiten, wir fahren generell nur 60 km/h in diesem Abschnitt, oder wir müssen eine Lösung finden, die Strecke länger zu machen. Da Letzteres nicht geht (hätten wir sonst sicherlich gleich gemacht), müssen wir nach einer Lösung suchen, wie wir das Signal und den Streckenabschnitt vorher so beeinflussen, dass bereits hier die Geschwindigkeit verringert wird.

Da eine solche Lösung nur kompliziert über eine oder mehrere Hilfsautomatiken lösbar wäre, sollte man trotzdem besser die Strecke umplanen. Die Lösung mit Hilfsautomatiken birgt immer Gefahren und kostet erhebliche Resourcen und sollte nur im Notfall genutzt werden.

Daher sollte auf Nebenbahnen (dort gibt es meist nur kurze Gleisabschnitte und dann auch noch zumeist im Bahnhof) die Geschwindigkeit herabgesetzt werden. Wenn ein Gleis nur 40 cm hat, dann muss eben ggf. die Geschwindigkeit auf 30 km/h herabgesetzt werden. Dann klappt es nicht nur mit dem Geschirr und dem Nachbarn, nein auch mit dem sachgerechten Bremsen.

Version 5:

In der Version 5 kann nun eine Lösungshilfe genutzt werden.

Die neue Funktion "Vollständig durchfahren" in einem Bahnhof bietet eine Lösung für folgenden Fall:

Ich habe langsame Nebenbahnzüge, die in dem kurzen Gleisabschnitt notfalls halten und damit bereits vorrutschen können. Schnelle Züge sind länger (dies ist ausdrücklich Voraussetzung), dann kann man die Funktion benutzen um langsame Züge halten zu lassen, weil sie durch die Zugverwaltung langsamer fahren und noch sachgerecht halten können sowie schnelle Züge durchfahren stets diesen Abschnitt, weil sie länger sind als der Gleisabschnitt.

Bitte beachten, dass dann dieser Gleisabschnitt als Bahnhof deklariert werden muss, um diese Funktion zu erhalten und die schnellen Züge stets länger sein müssen, als der betroffene Gleisabschnitt.

Anlagen

In der Anlage sind zwei Tabellen für Originalgeschwindigkeiten von 300 bis 10 km/h in 10 km/h-Schritten.



Taballe 1 alle Spurweiten





Tabelle 2 HO bis Z

---