CBTC soll die Kapazität der Frankfurter Stadtbahn um 25% erhöhen

Zitat von zip-drive

Du scheinst eine andere Definition als die BOStrab zu haben. Gerade das Vorhandensein von Zugsicherung (Signale usw.) grenzt eben das Fahren auf Zugsicherung vom Fahren auf Sicht ab.

https://www.gesetze-im-internet.de/strabbo_1987/__49.html

Fahren auf Sicht meint das Fahren ohne Zugsicherung (also allenfalls mit Fahrsignalen/"Balkensignalen"), der Fahrer muss den Zug so bewegen, dass er vor einem Hindernis zum Stehen kommen kann. Dies kann bedeuten, dass er bei schlechten Sichtverhältnissen usw. nicht die zulässige Geschwindigkeit fahren darf. Wohingegen Fahren auf Zugsicherung das Fahren mit technischen Rahmenbedingungen (Zugsicherungsanlagen wie "bunten" Signalen, Fahrsperren usw. oder eben dieses CBTC meint) hier verlässt sich der Fahrer darauf, dass er bei "grün" der Fahrweg sicher ist bis zum nächsten Signal. Er muss hier nicht mit Hindernissen rechnen, vor denen er rechtzeitig zum Stehen kommen müsste, sondern darf die volle zulässige Geschwindigkeit fahren.

Das was du meinst, sind Wartungsarbeiten oder ähnliches im Tunnel, bei denen mit Personal im oder am Gleis gerechnet werden muss. Dennoch ist auch in diesem Betriebszustand die Zugsicherung im Tunnel aktiv und die Züge fahren immer noch auf Zugsicherung.

Alles anzeigen

Ja, die Zugsicherung ist weiterhin aktiv, dennoch gilt Fahren auf Sicht: 40 km/h (irrtümlicherweise habe ich von 20 km/h gesprochen) mit Warnsignalen.

Zitat von baeuchle

„Verbindung zwischen verschiedenen Systemen“ ist die Definition von „Schnittstelle“. Da ist nix mit „teilweise“. Der Unterschied zwischen „alles aus einer Hand“ und „Flickenteppich“ ist, dass die Schnittstellen im letzteren Fall wohldefiniert sein müssen. Im ersten Fall können sie das sein, es ist aber keine notwendige Voraussetzung. Bei „alles aus einer Hand“ gibt es folglich null Anreiz, bei Änderung oder Weiterentwicklung eines Teils des Systems nicht die anderen Teile auch auszutauschen.

Alles eine Sache der Verträge die geschlossen werden und selbstverständlich die der finanziellen Mittel.

Kopenhagen nutzt schon das CBCT von Siemens und hat Siemens auch als Vollausrüster.

Zitat von lillywho

Mir bleibt immer noch eine Frage: Warum eigentlich ein System, das wohl proprietär von Siemens kommt, und nicht sowas wie ein ETCS? Soweit ich weiß, hat ETCS ja genauso moving blocks.

Ganz einfach gesprochen ist CBTC das ETCS für Stadt und Metros. Damit stellt sich gar nicht die Frage, warum man kein ETCS verbaut, sondern man verbaut eines. Die On-Board-Unit Trainguard MT hat etliche Gemeinsamkeiten mit der Trainguard 200, wie sie aktuell bei Eisenbahnen verbaut wird.

Streckenseitig gibt es verschiedene Ausrüstungslevel. Level 3 entspricht dabei schon sehr stark dem CBTC Standard. Die Anbindung der Stellwerke an das CBTC erfolgt dabei, wie bei ESTW über definierte Schnittstellen.

Es gibt als kein entweder oder sondern nur ein gemeinsam.

Der wesentliche Vorteil, von Anfang an mit mehreren Anbietern zu arbeiten ist wirklich, dass alle Schnittstellen zwischen unterschiedlichen Systemen schriftlich ausformuliert sind.

Ja, das mag vielleicht zuerst etwas hakeln - aber bei Einsatz eines einzigen Anbieters passiert das auch, wird aber oft dadurch gelöst, dass auf Obergefreitenebene Abteilung A mit Abteilung B spricht und eine Anpassung vornimmt. Die wird dann aber nie offiziell und landet entsprechend nie in der Dokumentation der Schnittstellen.

Wird dann jahre später eine Komponente ausgewechselt oder kommt hinzu(neue Fahrzeuggeneration, neue Steuerung, neue Signale, etc. oder eben auch nur ein neues oder zusätzlches Signal), dann wird zu deren Bau natürlich nur die offizielle Dokumentation benutzt - und prompt hakelts.

Da ist dann, wenn erstmals ein neuer Anbieter genutzt wird, der neue Anbieter schuld und nicht der ursprüngliche, dessen Dokumentation der Systeme falsch bzw. unvollständig ist.

Besonders peinsam: Wenn der ursprüngliche Anbieter nicht mehr existiert und man daher auf die Unterlagen angewiesen ist.

Entsprechend: Es ist sinnvoll, wenn mehrere Firmen von Anfang an zusammenarbeiten und es ist sinnvoll, wenn deren Kommunikation nur über ein Dokumentationsrepository erfolgt, auf das auch der Auftraggeber Zugriff hat.

Verträge sind eine Sache, aber die tatsächliche Kommunikation zwischen den Bereichen eines Unternehmens ist kaum zu unterbindenund führt in viel zu vielen Fällen zu "Abkürzungen" der Lösungsfindung, die langfristig trotz Unterlagen und Vetrträgen zum Lock-in des Auftragebers beim Einzelanbieter.

Und, ja, diese Vorgehensweise erfordert mehr Koordinationsaufwand auf der Seite des Auftraggebers, der eben nicht mehr simpler "Auftrag-Geber" ist, sondern Mitwirkender bleibt und auch die Verantwortung für das Ergebnis nicht abgeben kann. Sie erfordert auch Sachkompetenz beim Auftrageber.

Man darf nicht vergessen, dass die Anbieterstruktur für Leit- und Sicherungstechnik nicht gerade viel Auswahl zu lässt. Daher wird seitens der Infrastrukturbetreiber vermehrt versucht Schnittstellen zu standardisieren, um auch weitere Anbieter in den Markt zu integrieren. Allerdings ist das ein langwieriges Unterfangen, da auch die bisherigen Anbieter einbezogen werden müssen.

Natürlich. Kein einziger etablierter Anbieter hat Lust auf so ein Verfahren. Dei Leben ja alle vom Kunden-Lock-in auf ihre Universen.

Das wird auch teurer - beim ersten Mal.

Alle Änderungen und Upgrades dagegen werden günstiger, weil die dann ein beliebiger Anbieter, der nach Specs arbeitet machen kann.

Da das keinen der heute Verantwortlichen interessiert ("Nach mir die Sintflut!") macht man aus Bequemlichkeit das was der Anbieter will.

Wir haben das im IT-Bereich vor ein paar Jahren durchgezogen und beginnen gerade mit der Ernte - durch die kürzeren Lebenszyklen, können das hier noch die gleichen Leute machen, die damals die Entscheidungen getroffen haben - und Sie bekommen einiges an Lob ab, dass sie das gegen Widerstand aller Anderen durchgedrückt haben. Teils sogar von denen die damals Widerstand leisteten.

In einem frischen Blogbeitrag erklärt die VGF (erneut) die Digital Train Control DTC, siehe hier. Interessant ist der Zeitplan zur Einführung:

Zitat

• 2023 erste Fahrzeug-Umrüstungen und Tests auf dem Rundkurs unserer Stadtbahn-Zentralwerkstatt
• 2025 Abschluss Umrüstung „B“-Strecke
• 2028 Abschluss Umrüstung „A“-Strecke
• 2031 Abschluss Umrüstung „C“-Strecke und Straßenbahn

Irgendwie finde ich diesen Beitrag ein bisschen wie einen Schlag ins Gesicht für das Fahrpersonal. Die Vorteile, die (abgesehen von den variablen Blockabständen, Ersatz gealterter Technik usw). genannt werden, unterstellen dem Personal irgendwie alle, nicht gescheit fahren zu können. Da wird von höherer Zuverlässigkeit, Pünktlichkeit, aber auch gleichzeitig mehr Komfort und Energiesparen geredet. Kann das Personal das etwa nicht, so lange es möglich ist? Vor allem, das eine ist mit dem anderen in der Praxis nunmal oft nicht vereinbar, wie soll das ein Computer dann schaffen?

Zitat von MdE

Da wird von höherer Zuverlässigkeit, Pünktlichkeit, aber auch gleichzeitig mehr Komfort und Energiesparen geredet. Kann das Personal das etwa nicht, so lange es möglich ist?

Niemand unterstellt dem Personal, inkompetent zu sein. Aber es liegt ja in der Natur der Sache, dass ein Mensch mit einem Sollwertgeber niemals punktgenaue Beschleunigungs- und Bremskurven (ggf. sogar angepasst auf den aktuellen Fahrplan, Verspätungen etc.) nachvollziehen kann, welche mit einer automatischen Steuerung möglich sind.

Zitat von MdE

Die Vorteile, die [...] genannt werden, unterstellen dem Personal irgendwie alle, nicht gescheit fahren zu können.

Sie unterstellen dem Personal, nicht alle möglichen Varianten durchrechnen zu können und die Fahrstrategie optimieren zu können. Und das ist nun nicht so ganz aus der Luft gegriffen.

Vor ca. 2 Wochen lief eine sehenswerte Reportage in der der berufliche Alltag und die Wechselwirkung auf das Privatleben u.a. von einer U-Bahn-Fahrerin (München) gezeigt wurde. Und wenn ich mich recht erinnere sagte die Fahrerin das auch die gefahrene Geschwindigkeit der U-Bahn-Züge überwacht wird. Ob in München schon DTC installiert ist weiß ich nicht. Ob nun DTC installiert ist oder nicht, jedenfalls erhalten die Fahrerinnen und Fahrer der Münchner U-Bahn Rückmeldung wenn sie zu schnell fahren und sie müssen sich erklären. Ich vermute das dies auch schon heute in andern Städten mit Stadtbahn- bzw. U-Bahn-System gelebte Praxis ist. Von daher würde ich das nicht so sehen, dass das die Fahrerinnen und Fahrer "nicht gescheit fahren können".

Ein wesentliches technisches Merkmal von DTC ist das an den Strecken keine statischen Signale mehr verbaut sein werden sondern die Signalisierung dynamisch im Fahrzeug angezeigt wird. Weiterhin muss das Ganze mit der Zugsicherungstechnik gekoppelt werden falls in einer Notsituation die Fahrerin oder Fahrer das Fahrzeug nicht mehr steuern können. Auch das ist heute schon ein notwendiger Standard. Von daher ist das Nicht-gescheit-fahren-können unter diesem Aspekt ebenfalls zu relativieren.

Ich zitiere mal aus dem oben verlinkten Blog: "Die moderne und leistungsfähige Zugsicherungstechnik sorgt aber nicht nur für mehr Züge auf der Strecke, sondern auch für eine größere Taktgenauigkeit und -verläßlichkeit. Sie ermöglicht energieeffizienteres Fahren – Einsparungen von bis zu 20 Prozent sind möglich – und einen verbesserten Passagierkomfort durch sanfteres Beschleunigen und Bremsen. Das verringert außerdem den Verschleiß von Fahrzeugen und Schienen."

Der Gewinn an Komfort und die Reduzierung an Verschleiß sind aus meiner Sicht sekundäre Merkmale von DTC und nicht das Primärmerkmal für die Einführung.

Der Tempobegrenzer, Spurhalteassistent oder Fahrtenschreiber beim LKW könnte man auch als Computer oder KI bezeichnen, entlässt aber auch dort nicht die Fahrerin oder den Fahrer aus ihrem fahrerischen Können bzw. der Pflicht zum verantwortungsvollem Fahren.

Naja....ein Computer ballert den Zug auf ein rotes Signal das wegen eines zu spät gesetzten Anstosspunktes

für den Selbststellbetrieb sehr spät schaltet an das Signal ran und beschleunigt nach dem Umschalten, auch

wenn das darauffolgende auch noch rot ist, sofort wieder hoch.....der Mensch fährt vorausschauen und energie-

sparend sobald er diese Problematik erkannt hat.....

Ich bin die Tage einige Male mit der U-Bahn gefahren und habe den Verdacht, dass auf Südbahnhof zu so eine

Stelle ist.

Zitat von Darkside

ür den Selbststellbetrieb sehr spät schaltet an das Signal ran und beschleunigt nach dem Umschalten, auch

wenn das darauffolgende auch noch rot ist, sofort wieder hoch.....der Mensch fährt vorausschauen und energie-

sparend sobald er diese Problematik erkannt hat.....

Wobei dieses Problem nun vergleichsweise trivial zu lösen ist, indem man die Automatik prüfen läßt, ob das Folgesignal schon hochgelaufen ist. Das läßt sich durchaus mit ein paar anderen Parametern kombinieren. Z. B. kann bei pünktlichen Zügen dann auf die Beschleunigung ganz oder teilweise verzichtet werden oder eben nur bei Verspätung am oberen Rande der zulässigen Kurve gefahren wird. Und der Mensch vorausschauend, naja. Wenn ich sehe, wieviele im Straßenverkehr wie blöde aufs Gaspedal drücken, obwohl erkennbar die Ampel auf rot steht...

Was der Mensch auch nicht kann, ist "rückschauend" zu fahren. Du läßt Dich also gemütlich auf das nächste Signal zurollen, aber ggf. wäre es sinnvoller gewesen, doch etwas stärker zu beschleunigen, weil ansonsten der folgende Zug schon wieder ausgebremst wird. Solche Interaktionen kannst Du - sinnvolle Programmierung vorausgesetzt - natürlich deutlich besser automatisiert abwickeln.

Zitat von Darkside

Naja....ein Computer ballert den Zug auf ein rotes Signal das wegen eines zu spät gesetzten Anstosspunktes

für den Selbststellbetrieb sehr spät schaltet an das Signal ran und beschleunigt nach dem Umschalten, auch

wenn das darauffolgende auch noch rot ist, sofort wieder hoch.....der Mensch fährt vorausschauen und energie-

sparend sobald er diese Problematik erkannt hat.....

Eigentlich beschreibst du es genau andersherum. Ein Mensch weiß in der Regel nicht, wann ein Signal umschaltet und was die nächsten Signale anzeigen (Ja, es gibt Erfahrungswerte, Rückstau A- Strecke). Auch der zu spät gesetzte Anstoßpunkt (ein manueller Fehler? ) dürfte der Vergangenheit angehören.

Ein gutes System sollte den Betriebszustand der kommenden Abschnitte kennen, so können theoretisch bei o.g. Rückstau die Züge an jeder Station zeitgleich losfahren.

Im Optimalfall kann ein verspäteter Zug bevorzugt werden und nicht stur in einem starren Ampelumlauf warten oder sogar noch zusätzlich durch Fußgängerampeln ausgebremst werden. Setzt natürlich einen Vernetzung mit der allgemeinen Verkehrssteuerung (und den politischen Willen dazu) voraus.

Meine Sicht als Fahrgast auf die U-Bahn Nürnberg, dort die von Computern gefahrene U2: sicher, der Computer trifft jede H-Tafel absolut punktgenau, kann ich nicht anders sagen. Ansonsten erscheint mir der Fahrstil aber sehr auf das sture Erreichen und Halten bestimmter Geschwindigkeiten ausgelegt und absolut nicht darauf, das unterirdische Gelände (Steigungen und Gefälle) auszunutzen. Ich dachte schon paarmal, wenn ich selber von Hand dort fahren würde, würde ich anders fahren und eben nicht ständig die zulässige Geschwindigkeit ausreizen, sondern Neigungen gezielt zum Beschleunigen oder Bremsen ausnutzen und außerdem am Wochenende auch nicht ständig mit 100% anfahren, sondern durchaus auch mal sanfter und dafür die Haltezeiten bedarfsgerecht verkürzen. Im Berufsverkehr natürlich straffer fahren und längere Zeiten für den Fahrgastwechsel einkalkulieren, das ist ja klar.

Erfahrung und Fahrbegabung, dazu ständiges Anpassen an die jeweilige Betriebslage, sind meiner Meinung nach Sachen, die die Computer einfach noch nicht können.

Zitat von Tatrafan

Erfahrung und Fahrbegabung, dazu ständiges Anpassen an die jeweilige Betriebslage, sind meiner Meinung nach Sachen, die die Computer einfach noch nicht können.

Es gibt viele Erfahrungen, wo der Mensch einer Maschine überlegen ist. Allerdings bei solch einfache Dinge, die sich quasi in einem Satz beschreiben lassen, eher nicht. Wie ich schon oben andeutete ist ein Regelsatz à la "wenn Pünktlich, dann Beschleunigung 0,5 m/s^2, ab 30 Sekunden 0,6, ab 40 Sekunden 0,7, ..." relativ trivial umsetzbar (und auch vom Sicherheits-/Zulassungsaspekt prüfbar). Die Frage ist an dieser Stelle also eher, ob solche Features in der Ausschreibung gefordert waren und/oder man sie einfach vom Nutzen-Kosten-Verhältnis her einfach ignoriert/verworfen hat.

Man braucht ja nur mal in ATO Fahrzeugen mitfahren und genau beobachten.....dann bekommt man schnell

mit wie flexibel die ATO-Coderoutinen sind.....

Condor....eine ATO weiss ebenso nicht wann ein Signal schaltet....die reagiert einfach nur auf die Information

wie weit vom Fahrzeug weg der Fahrweg frei ist. Und genau das ist das was ich beschrieben habe.

Zitat von Darkside

eine ATO weiss ebenso nicht wann ein Signal schaltet....die reagiert einfach nur auf die Information

wie weit vom Fahrzeug weg der Fahrweg frei ist.

Es ist aber deutlich einfacher, diese Information einer ATO bereitzustellen als dem Fahrpersonal.

Ich glaube, es würde die Diskussion hier sehr verkürzen, wenn wir uns auf zwei Dinge einigen könnten:

1. ATO hat das Potential, deutlich mehr Informationen zu verarbeiten und auf deren Grundlage optimiert fahren zu können, mit verschiedenen möglichen Optimierungszielen
2. Bisher existierende ATO nutzen dieses Potential nicht vollständig aus.

Zitat von Darkside

Condor....eine ATO weiss ebenso nicht wann ein Signal schaltet....die reagiert einfach nur auf die Information

wie weit vom Fahrzeug weg der Fahrweg frei ist. Und genau das ist das was ich beschrieben habe.

Nun, wie uns auch der Blogbeitrag wieder erklärt, wird es ja keine Signale mehr geben. Weshalb das Diskutieren über Reaktionen auf Signalstellungen nicht für Fahrzustände nach Einführung der DTC relevant ist.

Zitat von Condor

Im Optimalfall kann ein verspäteter Zug bevorzugt werden und nicht stur in einem starren Ampelumlauf warten oder sogar noch zusätzlich durch Fußgängerampeln ausgebremst werden. Setzt natürlich einen Vernetzung mit der allgemeinen Verkehrssteuerung (und den politischen Willen dazu) voraus.

Siehe drittletzter Absatz des von mir zitierten Blogbeitrags. Genau das ist vorgesehen. Weitere Informationen zu Frankfurt MIND+ hier.

Mir geht es hauptsächlich darum, dass sich energiesparendes und komfortables Fahren sowie hohe Pünktlichkeit im Alltag einfach ausschließen, egal wer fährt! Deshalb weiß ich nicht, wie das ein Computer besser machen soll. Wenn der Zug verspätet ist, muss er entweder sanft und effizient fahren oder ruppig und schnell. Beides geht einfach nicht. Wird aber trotzdem im selben Atemzug genannt!

Es wird bei Neuerungen immer gerne von allen Vorteilen gesülzt, die die Technik zwar grundsätzlich bietet, aber entweder nicht bestellt oder in der konkreten Situation nicht ausgeführt werden können.

Nettes Beispiel war der BÜ in Friedrichsdorf, vorher eine Bliklichtanlage. Die neue moderne Anlage sollte viel sicherer sein und den Autofahrern weniger Wartezeit aufdrücken, posaunte man damals. Ja, es wurde die erlaubte Geschwindigkeit der Bahn auf 60 km/h reduziert und das Vorsignal des ESig aus Köppern her um ein paar Hundert Meter versetzt. Aber das in Gegenrichtung hängt immer noch nahe Bahnsteigende Seulberg am ESig Friedrichsdorf. Da mit der neuen Anlage noch eine zu räumende Grundstückszufahrt gesichert wird, ist die Wartezeit nun länger...

Zitat von baeuchle

Sie unterstellen dem Personal, nicht alle möglichen Varianten durchrechnen zu können und die Fahrstrategie optimieren zu können. Und das ist nun nicht so ganz aus der Luft gegriffen.

Genau das ist es ja. Letztlich muss sich auch der Computer für eine Variante entscheiden. Und kann nicht alle Vorteile gleichzeitig bieten.