Zitat
Bd2001
Wann gab es auf der Görlitzer Bahn im Bereich Adlershof Automatikblock? Die Blockstelle Betriebsbahnhof ist Baujahr 1988 und seit dem immer örtlich besetzt. Die Blockstelle Adlershof ist nur ein Ersatzbau für das abgerissene Stellwerk Swad.

Hast Recht. Ein Foto, das ich beim Schreiben in Erinnerung hatte und wo das BkSig noch mit wswsw-Mastschild ausgestattet war, ist datiert auf 1983.

--
Das Gegenteil von umfahren ist umfahren.

Zitat
Arnd Hellinger
Kann man ESTW denn nicht von Grund auf so projektieren und bauen, dass zum Planungszeitpunkt bereits vorgesehene Änderungen an Spurplan und Außenanlage eben nur noch kleinere Eingriffe entweder durch zertifizierte Fremdfirmen oder LST-Menschen der DB selbst erfordern...?

Da könnte man tatsächlich meinen, früher sei Alles besser gewesen: Als in den 1980er Jahren etwa die Hauptbahnhöfe Würzburg, Fulda und Nürnberg für SFS bzw. S-Bahn grundlegend neue Spurpläne erhielten, hat die DB zuerst neue SpDrS-Stellwerke bauen und in Betrieb nehmen lassen und erst danach mit dem Bahnhofsumbau begonnen. Nach Inbetriebnahme der Stellwerke an jeweils nur einem Wochenende gab es während der gesamten folgenden Umbauzeit nicht eine einzige Komplettsperrung dieser doch nicht ganz inkomplexen Bahnhöfe.

Sollte durch Digitalisierung nicht alles einfacher und schneller handhabbar werden? :-)

Das war nie das Ziel. Digitalisierung erfolgt nur zum Zwecke der Automatisierung der Bedienung und der damit verbundenen Personaleinsparung.

Das Problem der ESTW ist eben die verwendete Software, die aus Gründen der Sicherheit einfach gestaltet sein muß. Daher sind solche Dinge wie Plug & Play da undenkbar.

Die Folge ist, das für jede kleinste Änderung eine neue Software geschrieben werden muß. Da es für jedes ESTW nur ein Rechnerverbund (zwei oder drei parallel arbeitende Rechner) gibt wird damit das ganze ESTW beim Softwarewechsel lahmgelegt. Da die Software kompakt geschrieben ist muß nach dem Softwarewechsel auch ein kompletter Funktionstest folgen. In der Zeit ruht der Betrieb.

Beim Spurplanstellwerk (und nur da) reichte ein Test der Spurplangruppe vor dem Einbau und ein Test der betreffenden Spurkabel nach dem Einbau.

Abhilfe sollen erst die geplanten DSTW schaffen. die modular aufgebaut werden sollen. Noch gibt es die nicht. Die bisher als Digitale Stellwerke verkauften Piloten in Annaberg-Buchholz oder Warnemünde sind mehr klassische ESTW als moderne DSTW.

Bist du dir da sicher oder sind das deine Vermutungen?

Ich bin kein Experte für ESTWs, kenne mich jedoch in der IT ganz passabel aus. Vor diesem Hintergrund klingt das für mich hanebüchen, da es im Prinzip jeglichen Grundregeln der IT widerspricht.

Zitat
Wutzkman
Bist du dir da sicher oder sind das deine Vermutungen?

Ich bin kein Experte für ESTWs, kenne mich jedoch in der IT ganz passabel aus. Vor diesem Hintergrund klingt das für mich hanebüchen, da es im Prinzip jeglichen Grundregeln der IT widerspricht.

Den IT Schutzzielen widerspricht so ein Vorgehen gar nicht. Es ist auch immerhin keine x-beliebige Anwendung, sondern hoch sicherheitskritisch.

Die Berliner Linienchronik (+Stationierungen S-Bahn/BVG) 1858-2024

Zitat
Wutzkman
Bist du dir da sicher oder sind das deine Vermutungen?

Ich bin kein Experte für ESTWs, kenne mich jedoch in der IT ganz passabel aus. Vor diesem Hintergrund klingt das für mich hanebüchen, da es im Prinzip jeglichen Grundregeln der IT widerspricht.

Also Redundanz, Vermeidung von Bloatware und das fail-safe-Prinzip sind grundlegende IT-Prinzipien. Von "jeglich" kann daher keine Rede sein.

--
Das Gegenteil von umfahren ist umfahren.

Zitat

Florian Schulz am 4.1.2023 um 10.20 Uhr:

[...] Vermeidung von Bloatware [...]

Ah, also nach dem KISS-Prinzip geschriebene Programme, verstehe. Frage: Was hat das alles mit dem Umbau des Bahnhofs Schöneweide zu tun?

Viele Grüße, Thomas

--
Thomas Krickstadt, Berlin, Germany, usenet@krickstadt.de

Zitat
krickstadt

Zitat

Florian Schulz am 4.1.2023 um 10.20 Uhr:

[...] Vermeidung von Bloatware [...]

Ah, also nach dem KISS-Prinzip geschriebene Programme, verstehe. Frage: Was hat das alles mit dem Umbau des Bahnhofs Schöneweide zu tun?

Viele Grüße, Thomas

Dass der Umbau noch unter Alttechnik läuft und daher die "ESTW-Probleme" keine Rolle spielen. ;)

--- Signatur ---
Bitte beachten Sie beim Aussteigen die Lücke zwischen Bus und Bordsteinkante!

Zitat

"Jay" am 4.1.2023 um 10.42 Uhr:

Dass der Umbau noch unter Alttechnik läuft und daher die "ESTW-Probleme" keine Rolle spielen. ;)

Das sind dann aber ganz schön viele Beiträge, um das klarzustellen. ;-) Was die Kabelkanäle auf Ost- und Westseite des Bahnhofs angeht, scheint die Bahn aber für dem Umbau folgende Arbeiten gut vorbereitet zu sein.

Viele Grüße, Thomas

--
Thomas Krickstadt, Berlin, Germany, usenet@krickstadt.de

Zitat
Florian Schulz

Zitat
Wutzkman
Bist du dir da sicher oder sind das deine Vermutungen?

Ich bin kein Experte für ESTWs, kenne mich jedoch in der IT ganz passabel aus. Vor diesem Hintergrund klingt das für mich hanebüchen, da es im Prinzip jeglichen Grundregeln der IT widerspricht.

Also Redundanz, Vermeidung von Bloatware und das fail-safe-Prinzip sind grundlegende IT-Prinzipien. Von "jeglich" kann daher keine Rede sein.

Nein, natürlich nicht. Von den von dir aufgebrachten Argumenten war aber auch keine Rede.



1 mal bearbeitet. Zuletzt am 04.01.2023 21:03 von Wutzkman.

Zitat
Bd2001
Das Problem der ESTW ist eben die verwendete Software, die aus Gründen der Sicherheit einfach gestaltet sein muß. Daher sind solche Dinge wie Plug & Play da undenkbar.

Ob eine Software "einfach" oder "kompliziert" ist, spielt aus Sicherheitsgründen, wenn überhaupt, eine untergeordnete Rolle. Wichtig ist vor allem, dass sie, wenn sie nicht eh komplett eigenständig entwickelt ist, quelloffen ist. Somit ist sichergestellt, dass man selbst - und bei hochkritischer Infrastruktur beispielsweise auch das BSI - immer weiß, was genau passiert und was eben genau nicht passiert. Bloatware kommt dabei im Prinzip nicht vor, weil sie sofort im Quelltext gefunden wird. Weiterhin findet man so auch mögliche Backdoors etc, die der Hersteller versucht zu implementieren oder dies sogar standardmäßig tut, aus welchen Gründen auch immer.

Zitat

Die Folge ist, das für jede kleinste Änderung eine neue Software geschrieben werden muß.

Wenn die Software jedes Mal vermeintlich neu geschrieben werden muss, entspricht das ebenso keinem Standard, nirgendwo. Üblicherweise wird die verwendete Software, wenn sie nicht eh Out Of The Box die gesuchte Funktionalität mit sich bringt, entsprechend gepatcht. Dies kann auf verschiedenen Wegen passieren. Kleinere Sachen durch Minor Releases, teilweise sogar im laufenden Betrieb, größere Sachen dann durch Versionsupgrades oder Major Releases. Alternativ können - dank der Quelloffenheit - kleinere Sachen auch direkt im Core angepasst und größere Sachen durch Erweiterungsmodule ergänzt werden. Letzteres ist vor allem dann sinnvoll, wenn die Funktionserweiterung nur temporär ist oder nur einem ausgewählten Personenkreis zugänglich gemacht werden soll.

Und ja, natürlich gleicht kein ESTW dem anderen, aber dennoch sind es alles ESTWs, haben also im Wesentlichen die gleiche Aufgabe. Daher würde ich vermuten, dass da auch die gleiche, oder wenigstens stark ähnliche Software zum Einsatz kommt und nicht jedes Mal für jedes ESTW komplett neu geschrieben. Ich will weiß Gott nicht behaupten, dass das einfach ist und mal eben so aus dem Daumen geschüttelt wird, aber man muss eben nicht das Rad jedes Mal neu erfinden, sondern könnte sich an Standards in der IT orientieren.

Zitat

Da es für jedes ESTW nur ein Rechnerverbund (zwei oder drei parallel arbeitende Rechner) gibt wird damit das ganze ESTW beim Softwarewechsel lahmgelegt.

Das schockiert mich ehrlich gesagt am meisten. Gott sei Dank setzt man hier auf Redundanz, aber warum nutzt man sie denn nicht vollständig? Standardmäßig trennt man während des Wartungsfensters das Cluster und führt ein rollierendes Upgrade durch. Das heißt, der Betrieb wird auf dem verbleibenden Knoten abgewickelt, ggf. im Vier-Augen-Prinzip, um die temporär fehlende Redundanz auszugleichen. Währenddessen wird der andere Knoten gepatcht und geprüft, ob das Ergebnis der Erwartung entspricht. Falls ja, wird der Betrieb auf den upgegradeten Knoten geschwenkt und der fehlende Knoten wird ebenso installiert inklusive Funktionstest. Falls nein, führt man ein Rollback auf den Ursprungszustand des ersten Knoten durch. Nach der Arbeit wird das Cluster wieder synchronisiert. Der Betrieb ist nur während des Schwenks unterbrochen und diesen Schwenk kann man im Millisekundenbereich halten, wenn man es denn möchte.

Zitat

Da die Software kompakt geschrieben ist muß nach dem Softwarewechsel auch ein kompletter Funktionstest folgen. In der Zeit ruht der Betrieb.

Auch hier die Frage, was das mit der Kompaktheit zu tun hat. Ein Funktionstest muss immer erfolgen, egal wie kompakt der Code ist. Und damit in dieser Zeit der Betrieb nicht ruhen muss - das ist der absolute Worst Case, den es unter allen Umständen zu vermeiden gilt - wird die neue Software vorher in einer Referenzumgebung entwickelt und getestet bis sie die gewünschte Funktionalität mit sich bringt. Üblicherweise ist diese Referenz virtualisiert und damit für jedes neue Szenario - im diskutierten Fall in jedem neuen / zu ändernden ESTW skalier- und anpassbar.

Das war ein (nicht mehr ganz so) kleiner Exkurs in die IT.

Das würde ich alles als selbstverständlich ansehen - auch ich beschäftige mich mit IT, wenn auch in ganz kleinem Maßstab, und kann das alles nur bestätigen. Mich schockiert, dass das in der Praxis bei der Bahn offenbar nicht so ist.

Zitat
Wutzkman

Zitat
Bd2001
Das Problem der ESTW ist eben die verwendete Software, die aus Gründen der Sicherheit einfach gestaltet sein muß. Daher sind solche Dinge wie Plug & Play da undenkbar.

Ob eine Software "einfach" oder "kompliziert" ist, spielt aus Sicherheitsgründen, wenn überhaupt, eine untergeordnete Rolle. Wichtig ist vor allem, dass sie, wenn sie nicht eh komplett eigenständig entwickelt ist, quelloffen ist. Somit ist sichergestellt, dass man selbst - und bei hochkritischer Infrastruktur beispielsweise auch das BSI - immer weiß, was genau passiert und was eben genau nicht passiert. Bloatware kommt dabei im Prinzip nicht vor, weil sie sofort im Quelltext gefunden wird. Weiterhin findet man so auch mögliche Backdoors etc, die der Hersteller versucht zu implementieren oder dies sogar standardmäßig tut, aus welchen Gründen auch immer.

Das "einfach" bezog sich darauf das das Programm auch nur wenigen verschiedenen Kommandos besteht. Und nein, bei der Eisenbahnsicherungstechnik ist nichts quelloffen. Damit schottet man sich vor Mitbewerbern ab. Daher kann auch nur der Hersteller Änderungen vornehmen.

Zitat
Wutzkman

Zitat

Die Folge ist, das für jede kleinste Änderung eine neue Software geschrieben werden muß.

Wenn die Software jedes Mal vermeintlich neu geschrieben werden muss, entspricht das ebenso keinem Standard, nirgendwo. Üblicherweise wird die verwendete Software, wenn sie nicht eh Out Of The Box die gesuchte Funktionalität mit sich bringt, entsprechend gepatcht. Dies kann auf verschiedenen Wegen passieren. Kleinere Sachen durch Minor Releases, teilweise sogar im laufenden Betrieb, größere Sachen dann durch Versionsupgrades oder Major Releases. Alternativ können - dank der Quelloffenheit - kleinere Sachen auch direkt im Core angepasst und größere Sachen durch Erweiterungsmodule ergänzt werden. Letzteres ist vor allem dann sinnvoll, wenn die Funktionserweiterung nur temporär ist oder nur einem ausgewählten Personenkreis zugänglich gemacht werden soll.

Und ja, natürlich gleicht kein ESTW dem anderen, aber dennoch sind es alles ESTWs, haben also im Wesentlichen die gleiche Aufgabe. Daher würde ich vermuten, dass da auch die gleiche, oder wenigstens stark ähnliche Software zum Einsatz kommt und nicht jedes Mal für jedes ESTW komplett neu geschrieben. Ich will weiß Gott nicht behaupten, dass das einfach ist und mal eben so aus dem Daumen geschüttelt wird, aber man muss eben nicht das Rad jedes Mal neu erfinden, sondern könnte sich an Standards in der IT orientieren.

Man orientiert sich nicht an der IT, sondern an der Eisenbahnsicherungstechnik. Da ist es Stand der Technik, das bei Arbeiten an der Sicherungstechnik der Betrieb an der betreffenden Einheit ruht. Das frühere Verfahren "Aufgehobene Signalabhängigkeit" funktioniert heute mangels örtlichen Personal nicht mehr.

Du hast Recht, in der Regel nutzt man standardisierte Software. Trotzdem benötigt man jedesmal eine Individualisierung um die entsprechenden Außenanlagen ansteuern zu können, deren Rückmeldungen richtig zu verarbeiten und richtig darstellen zu können.

Dann gibt es Fälle, wo man keine standardisierte Software hat. Diese Fälle wurden auch schon zu Spurplanstellwerkszeiten individuell geplant und verdrahtet.

Zitat
Wutzkman

Zitat

Da es für jedes ESTW nur ein Rechnerverbund (zwei oder drei parallel arbeitende Rechner) gibt wird damit das ganze ESTW beim Softwarewechsel lahmgelegt.

Das schockiert mich ehrlich gesagt am meisten. Gott sei Dank setzt man hier auf Redundanz, aber warum nutzt man sie denn nicht vollständig? Standardmäßig trennt man während des Wartungsfensters das Cluster und führt ein rollierendes Upgrade durch. Das heißt, der Betrieb wird auf dem verbleibenden Knoten abgewickelt, ggf. im Vier-Augen-Prinzip, um die temporär fehlende Redundanz auszugleichen. Währenddessen wird der andere Knoten gepatcht und geprüft, ob das Ergebnis der Erwartung entspricht. Falls ja, wird der Betrieb auf den upgegradeten Knoten geschwenkt und der fehlende Knoten wird ebenso installiert inklusive Funktionstest. Falls nein, führt man ein Rollback auf den Ursprungszustand des ersten Knoten durch. Nach der Arbeit wird das Cluster wieder synchronisiert. Der Betrieb ist nur während des Schwenks unterbrochen und diesen Schwenk kann man im Millisekundenbereich halten, wenn man es denn möchte.

Man, wir sind hier bei der Eisenbahntechnik und nicht in einem Kernkraftwerk.

Zitat
Wutzkman

Zitat

Da die Software kompakt geschrieben ist muß nach dem Softwarewechsel auch ein kompletter Funktionstest folgen. In der Zeit ruht der Betrieb.

Auch hier die Frage, was das mit der Kompaktheit zu tun hat. Ein Funktionstest muss immer erfolgen, egal wie kompakt der Code ist. Und damit in dieser Zeit der Betrieb nicht ruhen muss - das ist der absolute Worst Case, den es unter allen Umständen zu vermeiden gilt - wird die neue Software vorher in einer Referenzumgebung entwickelt und getestet bis sie die gewünschte Funktionalität mit sich bringt. Üblicherweise ist diese Referenz virtualisiert und damit für jedes neue Szenario - im diskutierten Fall in jedem neuen / zu ändernden ESTW skalier- und anpassbar.

Das war ein (nicht mehr ganz so) kleiner Exkurs in die IT.

Die neue Software wird auch in einer Referenzumgebung entwickelt und getestet. Trotzdem wird vor der Freigabe an den Betrieb noch einmal getestet. Dabei geht es in erster Linie um das Zusammenwirken mit der Außenanlage.

Aufgrund der geschwungenen Balken an der Rückseite des Schuppens vermute ich eine ehemalige Bahnsteigüberdachung, evtl. auch für Personenverkehr. Vielleicht weiß die Denkmalpflege mehr und im Grunde müsste ja auch der Schuppen und dieses Gebälk erhalten bleiben, da die Anlage unter Denkmalschutz steht. Außerdem sieht man noch zwei historische Stufen an der Stirnseite des Schuppens. Die lässt mich argwöhnen, dass das Gebäude einmal anders aussah.

Zitat

"Heidekraut" am 5.1.2023 um 1.51 Uhr:

[...] vermute ich eine ehemalige Bahnsteigüberdachung, evtl. auch für Personenverkehr. [...]

Diesen Verdacht (oder eventuell eine Wartehalle zu einem Bahnsteig) hatte ich auch, als ich vom Bahnsteig C aus die Rückseite des Gebäudes fotografierte (ich glaube, diese Rückansicht noch nie so deutlich wahrgenommen zu haben, vermutlich waren früher mehr Bäume im Blickfeld):


(Ausschnitt aus der Originalbildddatei dieses Fotos)

Viele Grüße, Thomas

--
Thomas Krickstadt, Berlin, Germany, usenet@krickstadt.de

Für den Denkmal-Nostalgiker, ist das ja eigentlich ein Schmuckstück. Man könnte es entkernen und wieder herrichten. Ich hab extra auf der Visualisierung danach geschaut, aber da erscheint das nur als dunkler Block. Insofern ein sehr interessantes Foto bzw. Ausschnitt.

Zitat

"Heidekraut" am 5.1.2023 um 8.16 Uhr:

Ich hab extra auf der Visualisierung danach geschaut, aber da erscheint das nur als dunkler Block.

In der Visualisierung ist aber auch die Begründung zu sehen, weshalb der ganze östlich des Bahndamms gelegene Teil des Bahnhofs sehr "unspezifisch" aussieht:

Zitat

Projektgebiet DB Station & Service. Zuwegung zwischen Haltestelle und S Bahnsteige [*sigh*] geplant

(Es gibt schlicht und einfach noch keine veröffentlichte Planung, was mit diesem Gebäudeensemble geschehen soll. Eventuell ist dies auch ein Grund, warum die BVG diese Visualisierung bisher nicht selbst veröffentlicht hat.)

Viele Grüße, Thomas

--
Thomas Krickstadt, Berlin, Germany, usenet@krickstadt.de

Das kann gut sein, ist mir auch aufgefallen.

Zitat
krickstadt

Zitat

"Heidekraut" am 5.1.2023 um 1.51 Uhr:

[...] vermute ich eine ehemalige Bahnsteigüberdachung, evtl. auch für Personenverkehr. [...]

Diesen Verdacht (oder eventuell eine Wartehalle zu einem Bahnsteig) hatte ich auch, als ich vom Bahnsteig C aus die Rückseite des Gebäudes fotografierte (ich glaube, diese Rückansicht noch nie so deutlich wahrgenommen zu haben, vermutlich waren früher mehr Bäume im Blickfeld):

Ich hatte das Gebäude auch mal aus der Nähe fotografiert:

https://www.baustellen-doku.info/berlin_goerlitzer-bahn/umbau_bahnhof_schoeneweide/20181128/ (Bilder 31 und 32).

Dort habe ich es als "Wartehalle" bezeichnet, kann mich aktuell aber nicht an die Quelle der Aussage erinnern. Eine reine Spekulation war es ganz sicher nicht.

Die Denkmaldatenbank (https://denkmaldatenbank.berlin.de/daobj.php?obj_dok_nr=09045209) schreibt dazu:

Zitat

Der zweigeschossige Hauptbau in der Mitte der Bahnhofsanlage nahm die zentrale Empfangshalle auf, der südliche Flügel mit seinem angeschlossenen Biergarten diente als Bahnhofsgaststätte, während im nördlichen Flügel die Bahnhofsverwaltung untergebracht war. Bis zum Bau des Bahndamms verliefen die Gleise der Berlin-Görlitzer Eisenbahn ebenerdig hinter dem Bahnhofsgebäude.

"Südlicher Flügel" bezieht sich hier aber m.E. primär auf den Ziegelbau, dort war ja bis zuletzt eine Bahnhof-Gaststätte beheimatet. Ob diese sich früher einmal auch auf den Holzbau ausdehnte, weiß ich nicht. Ggf. ist der Holzbau eine (ehem. offene) Überdachung des Biergartens.


EDIT: Folgendes Foto mit interessanter Bildunterschrift habe ich bei einer Google-Suche noch gefunden:
[encrypted-tbn0.gstatic.com]
"Der Bahnhof Nieder-Schöneweide-Johannisthal (heute Bahnhof Schöneweide) im Jahre 1909. Links der Wartesaal mit dem Bahnhofs-Restaurant und Bahnhofsgarten." (https://www.grin.com/document/177249)

Viele Grüße
André



2 mal bearbeitet. Zuletzt am 05.01.2023 13:53 von andre_de.

Zum Bahnhofsvorplatz (Bezirk) und dem Gelände zwischen Bahnhofsgebäude und Bahnsteigen (DB Station & Service AG) hat es bisher noch keine Anfrage von einem Abgeordneten gegeben?
Oder da ist einfach noch alles offen und es gibt nichts verlässliches was sich kommunizieren lässt.

Zitat
ECG7C
Zum Bahnhofsvorplatz (Bezirk) und dem Gelände zwischen Bahnhofsgebäude und Bahnsteigen (DB Station & Service AG) hat es bisher noch keine Anfrage von einem Abgeordneten gegeben?
Oder da ist einfach noch alles offen und es gibt nichts verlässliches was sich kommunizieren lässt.

Das lokale Wahlkreis-MdA verriet mir gestern, dass es für den Bereich aus ihm unbekannten Gründen nach wie vor keine konkrete Planung gebe und es daher nochmal bei SenUMVK sowie DB nachfragen wolle...

Aber evtl. wissen ja auch die hier mitlesenden IGEB-Aktiven genauer, woran es hier warum hapert und wen man dafür anal penetrieren muss?

Viele Grüße
Arnd