DREHSCHEIBE-Online 

Anzeige

HIER KLICKEN!

 21 - Stuttgart 21 

  Neu bei Drehscheibe Online? Hier registrieren! Zum Ausprobieren und Üben bitte das Testforum aufsuchen!
In dieses Forum gehören alle Diskussionen und News zum Thema "Stuttgart 21". - Eine dringende Bitte an alle Beitragsverfasser: Sachlich bleiben - ganz gleich, ob man für oder gegen dieses Projekt ist. Beleidigungen und Verleumdungen sind auch in diesem Forum NICHT gestattet!
Moderatoren: Rönshausener - TCB
Diesen Beitrag den Moderatoren melden?

Re: Das Jahr 2026

geschrieben von: kmueller

Datum: 25.10.20 17:24

schienenbieger schrieb:
kmueller schrieb:
Rein technisch gedacht könnte man bei 'freiem Fahrweg bis zum Stillstand' den Zug aus der Verpflichtung entlassen, sich die Fahrerlaubnis Block für Block immer wieder neu zu holen. Das sicher zu implementieren (z.B.: wie erfolgt ein sicherer Reset in den Zustand 'Position bekannt', sobald die Kommunikation wieder - oder intermittierend immer wieder mal - funktioniert) führt in die Details, wo bekanntlich der Teufel residiert, und zur Verträglichkeit mit Vorschriften (insbes. den Rahmenvorschriften für Vorschriftenwerke) schreibe ich besser nichts.
Ich sehe gerade keinen Grund, warum bei einem freien Gleis und vorhandener Fahrterlaubnis mindestens bis zum Haltepunkt, in den Teilblöcken davor weitere Fahrterlaubnisanfragen und Übermittlungen erfolgen sollten.

Es gibt eigentlich nur einen Betriebszustand, bei dem sich die Fahrterlaubnis dynamisch verändert; das ist das Nachrücken ins freiwerdende Gleis.
D.h. bei jedem Nachrücken (vulgo: Hinterherfahren). Das zu optimieren ist wesentlich, wenn man - wie in Stuttgart geplant - die feine Blockteilung für eine Erhöhung des Durchsatzes einsetzen will.

Zitat:
In diesem Fall würden die Achszähler dem Stellwerk die freien Blöcke melden und die ETCS-Zentrale mit dieser Information eine Fahrterlaubnis für diesen Block erteilen und ungefragt an den nachfahrenden Zug übermitteln.
Dadurch verlängert oder verändert sich die Fahrterlaubnis für den nachfahrenden Zug automatisch mit jedem Block, der vorne frei wird.
Aufgrund einer Achszählermeldung läßt sich der Block hinter einem vorfahrenden Zug freigeben, aber schon nicht mehr feststellen, mit welcher Geschwindigkeit dieser Zug unterwegs ist, und ob er womöglich im nächsten Block zum Halt kommt oder zumindest kommen könnte. In Ermangelung besseren Wissens muß das Überwachungssystem letzteres bei einem Abriß der Kommunikation als Möglichkeit einkalkulieren, den nachfolgenden Zug (sowie den nachnachfolgenden usw.) dementsprechend steuern, und damit können keine nennenswert kürzeren Zugabstände realisiert werden als mit einer festen, aber an die Fahrdynamik der Züge angepaßten PZB-Blockteilung (Blockverkürzung passend zur Verlangsamung vor dem Bahnhof und Blockverlängerung passend zur Beschleunigung dahinter).

Das Problem verschärft sich, wenn sich der vorfahrende Zug nicht sehr bald wieder mit seiner aktuellen Position meldet: solange nicht jeder Block mit Achszählern bestückt ist, muß der nachfahrende dann im letzten freigemeldeten Block angehalten werden, selbst wenn der vorfahrende real schon fünf Blöcke weiter ist. Das wäre sogar eine Verschlechterung der Zugfolge gegenüber einer (funktionierenden) PZB.

Genau deswegen ging ich in einer früheren Diskussion ganz selbstverständlich davon aus, daß ETCS Level3 (mit virtuellen beweglichen Blöcken) realisiert werden soll. Nur so kann man überhaupt zuverlässig zu einer Verkürzung der Zugabstände kommen - allerdings muß dann die Kommunikation perfekt, d.h. insbes. ohne Aussetzer funktionieren.

(was in ETCS als Methode(n) zur Meldung der Zugposition als Standard vorgesehen bzw. zulässig/erprobt ist, ist mir unbekannt).

Nachtrag: Hinsichtlich der möglichen Zugfolge ist das grundsätzliche Problem dasselbe, egal ob eine auszuwertende Positionsmeldung von ortsfesten Achszählern oder von ortsfesten Balisen ausgeht. Beides für im Normalfall verschiedene Zwecke parallel zu erheben, auf verschiedenen Kanälen an verschiedene Stellen zu senden (Stellwerk bzw. ETCS-Zentrale), im Störungsfall aber mal ersteres für zweiteren Zweck zu verwenden, ist ganz bestimmt keine gute Idee. Da gebe ich E44 recht. Sicherheitsysteme sollten auf jeder Ebene möglichst simpel strukturiert sein und vor allem sollte es im Störungsfall keine Form von 'Normal'weiterbetrieb geben.

Gib bitte eine Erläuterung, warum Du diesen Beitrag melden möchtest. Dies erleichtert es den Moderatoren, Deine Meldung zu verstehen.