DREHSCHEIBE-Online 

Anzeige

HIER KLICKEN!

 01 - News 

  Neu bei Drehscheibe Online? Hier registrieren! Zum Ausprobieren und Üben bitte das Testforum aufsuchen!
News und aktuelles Betriebsgeschehen - Fragen sind keine News, können aber in den anderen Foren gerne gestellt werden. Für Updatemeldungen von Websites bitte das Forum Bahn und Medien verwenden.
Seiten: 1 2 3 4 5 All Angemeldet: -

Re: LZB-Hersteller aufkaufen

geschrieben von: Traumflug

Datum: 10.01.21 23:21

ReneRomann schrieb:
Traumflug schrieb:
ReneRomann schrieb:
Versuche einfach mal auf einem heutigen x86-System ein Windows 95 zu installieren - ich garantiere dir, dass du Schiffbruch erleiden wirst
Das geht ziemlich problemlos. Das Zauberwort heisst 'QEMU': [de.wikipedia.org]

Dennoch macht es relativ wenig Sinn, LZB weiterzuentwickeln, wenn man eigentlich ETCS/DSTW haben will. Das ist schon richtig.
QEMU funktioniert aber nicht (oder nicht vernünftig), wenn du auf Hardware zugreifen musst. Weil QEMU direkten Hardwarezugriff nicht gewähren kann - denn der wird über das jeweilige Host-OS "geblockt".
Das letzte Mal ging's noch.

Für mehr Frieden auf Drehscheibe-Online: DSO peacemaker

Re: LZB-Hersteller aufkaufen

geschrieben von: ReneRomann

Datum: 10.01.21 23:47

Traumflug schrieb:
ReneRomann schrieb:
Traumflug schrieb:
ReneRomann schrieb:
Versuche einfach mal auf einem heutigen x86-System ein Windows 95 zu installieren - ich garantiere dir, dass du Schiffbruch erleiden wirst
Das geht ziemlich problemlos. Das Zauberwort heisst 'QEMU': [de.wikipedia.org]

Dennoch macht es relativ wenig Sinn, LZB weiterzuentwickeln, wenn man eigentlich ETCS/DSTW haben will. Das ist schon richtig.
QEMU funktioniert aber nicht (oder nicht vernünftig), wenn du auf Hardware zugreifen musst. Weil QEMU direkten Hardwarezugriff nicht gewähren kann - denn der wird über das jeweilige Host-OS "geblockt".
Das letzte Mal ging's noch.
Direkten Hardwarezugriff kann QEMU nicht leisten. Du kannst definitiv NICHT direkt eine PCI-Karte o.ä. zugreifen, weil dort das Host-OS die Hand drauf hat.
Alles andere wie z.B. das emulierte USB ist KEIN direkter Zugriff - wenn du auf direkten Zugriff zur Sicherung der Exklusivität und des Timings angewiesen bist, hilft dir das nicht weiter.
Denn QEMU hat als Prozess im Userspace keinerlei Rechte direkt auf die Hardware direkt zuzugreifen - dazu müssen mindestens immer der Kernel des Host-OS als auch entsprechende Treiber im Kernelspace involviert werden, ein direkter Hardwarezugriff aus dem Userspace hingegen ist nicht möglich.

Wenn QEMU direkten Hardwarezugriff hätte, hätte man innerhalb des virtualisierten Systems nämlich auch keine Probleme, auf die Grafikkarte zuzugreifen und deren Funktionen zu nutzen - hat man aber nicht, stattdessen muss QEMU hier die Grafikkarte emulieren und die virtuellen Grafikbefehle in die Grafiksprache das Host-OS "umsetzen", damit das Host-OS dann seinerseeits über den Treiber die richtige Grafikkarte ansprechen und das Bild ausgeben kann. Alle Hardwarebeschleunigung aber auch erweiterte Funktionalität wie z.B. DirectX oder OpenGL werden daher in der Regel nur rudimentär bis hin zu gar nicht unterstützt.
Für andere Hardware, z.B. Controllerkarten, sieht die Sache noch schlechter aus...

Re: LZB-Hersteller aufkaufen

geschrieben von: bahnmuffel

Datum: 11.01.21 00:19

Zugsicherer schrieb:
NBStrecke schrieb:
Ja, wobei es vorm Hintergrund der ganzen Auslandsinvestitionen aber doch mal eine sinnvolle Investition seitens der DB AG wäre, wenn man die/den nötigen LZB-Hersteller aufkaufen würde ;)
Naja, der Börsenwert der Thales Group liegt nach meiner Rechnung aktuell bei etwa 16 Milliarden Euro, das ist im Vergleich zu den geschätzten 30 bis 35 Milliarden Euro für die Digitale Schiene ein Schnäppchen ;-)
Klar, und Siemens Mobility als kleines Dessert gleich noch hinterher...

Wer aus der Bahn geworfen wird, sollte die Weichen für sein Leben neu stellen.
Christian Snizek schrieb:
So weit brauchst gar nicht in der Zeit zurück. Bestes Beispiel aus der aktuellen Zeitgeschichte wären die Smartron alias 192. Diese sind nur mit PZB/LZB ausgeliefert worden. Ein Update hätte hier größere finanzielle Auswirkungen. Klar ist auch, dass es für einzelne Betreiber/Eigentümer der letzten 140 und Co wohl das finale Ende wäre.
Siemens hat aber bei der Smartron immer gesagt, dass eine ETCS Nachrüstung angeboten wird wenn das in Deutschland Zugangsvoraussetzung wird. Da kann man sich jetzt nur noch darüber streiten ab wann das zutrifft. Erst wenn man auf der letzten Strecke ETCS braucht, oder vielleicht doch schon wenn der er erste wichtige Güterkorridor mal umgestellt wird.
Nicht vergessen, es gibt bereits zwei Strecken auf denen ETCS Zugangsvoraussetzung ist, die VDE 8.1 und 8.2.
MrEnglish schrieb:
Christian Snizek schrieb:
So weit brauchst gar nicht in der Zeit zurück. Bestes Beispiel aus der aktuellen Zeitgeschichte wären die Smartron alias 192. Diese sind nur mit PZB/LZB ausgeliefert worden. Ein Update hätte hier größere finanzielle Auswirkungen. Klar ist auch, dass es für einzelne Betreiber/Eigentümer der letzten 140 und Co wohl das finale Ende wäre.
Siemens hat aber bei der Smartron immer gesagt, dass eine ETCS Nachrüstung angeboten wird wenn das in Deutschland Zugangsvoraussetzung wird. Da kann man sich jetzt nur noch darüber streiten ab wann das zutrifft. Erst wenn man auf der letzten Strecke ETCS braucht, oder vielleicht doch schon wenn der er erste wichtige Güterkorridor mal umgestellt wird.
Nicht vergessen, es gibt bereits zwei Strecken auf denen ETCS Zugangsvoraussetzung ist, die VDE 8.1 und 8.2.
Moin.

Und da fahren genau wie viele Güterzüge? Hatten wir alles schon ...

Grüsse, Krischan

"Theoretisch müsste ich mich eigentlich aufregen - aber der Gesundheit zu liebe ist es mir völlig egal!"

Schaut doch mal vorbei:
[www.mec-loerrach.de]
Mein Kanal: [m.youtube.com]


mit ortsfesten Signalen kommt man weiter,die stehen auch noch da, wenn der Computer abstürzt !
Lok35 schrieb:
mit ortsfesten Signalen kommt man weiter,die stehen auch noch da, wenn der Computer abstürzt !
Die ETCS-Balisen liegen dann auch noch da. Und sind dann genauso nutzlos, wie die Signale, die man nicht mehr stellen kann. Weiter kommt man also nicht mehr.

Mal abgesehen davon, dass die ortsfesten Signale für Schnellfahrten hierzulande und heutzutage nicht ausreichen.

Abseits der SFS könnte man natürlich, wenn man wollte, auch mechanische Stellwerke mit ETCS L1 bauen. Da dürfte eher der Personalaufwand als die Technik das Problem sein.



1-mal bearbeitet. Zuletzt am 11.01.21 08:39.
Lok35 schrieb:
mit ortsfesten Signalen kommt man weiter,die stehen auch noch da, wenn der Computer abstürzt !
Bei einem Stellwerks-Ausfall in einem ESTW / DSTW kommt man mt ortsfesten Signalen auch nicht sehr viel weiter. Die bleiben höchstens für die bereits eingestellte Fahrstraße noch auf "Grün", danach folgt "rot". Und dann folgen mit hoher Wahrscheinlichkeit weder drei weiße Lichter in Form eines A noch drei gelbe Lichter in Form eines V. Einfach weil der örtlich zuständige Fdl bei der typischen Ausdehnung eines ESTW-Bezrik ohne die Zugnummern-Meldeanlage gar nicht weiß, wo welcher Zug ist. Und bei der schieren Menge von Zugnummer, die der Fdl jeden Tag sieht ist auch davon auszugehen, das der özF gar nicht, wohin welcher Zug genau will. Oder gibt es in einer Bz noch einen ausgedruckten Fahrplan für die Zugmeldestellen - so quasi als allerletzter Notnagel?

MfG Martin Pfeifer

Lieber Blech- als Plastikspielzeuge!
Lok35 schrieb:
mit ortsfesten Signalen kommt man weiter,die stehen auch noch da, wenn der Computer abstürzt !
kommt drauf an ist klare Antwort darauf. Stürzt im Falle von ESTW/DSTW mit ETCS L2 und RBC "der Stellwerk-Computer" ab, kannst du Signale haben wie du willst... da geht signalisiert nichts mehr.
Stürzt hingegen der RBC-Computer ab, ist auf der VDE 8.1/8.2 NBS nur noch Rückfallebene (derzeit Fahren in SR) möglich.

Die Entwicklung eines RBCs erfolgt hier mit den gleichen hohen Ansprüchen an die Sicherheit, Zuverlässigkeit und Verfügbarkeit wie für ein Stellwerk. Verfügbarkeitssorgen lassen sich mit Redundanzen sehr gut "behandeln", so dass ich hier keinen großen Bedarf für die Rückfallebene "100 Jahre altes System mit SIL 0" sehe. Der Betrieb auf der VDE8 zeigt es doch deutlich. Die Infrastrukturseite (Stellwerk+ RBC) sind bisher nahezu durchgehend verfügbar. Die einzigen Probleme von denen ich bisher weiß beruhen meist darauf, dass die ETCS Spezifikation aus Hersteller an einigen Stellen noch interpretierbar ist und somit Integrationsprobleme von Produkten verschiedener Hersteller auftreten können.
Zugseitig gab es bereits mehrere Ausfälle auhc der ETCS-Onboard-Komponenten, so dass Züge entweder nur in SR oder geschleppt den lichtsignalisierten Bereich erreichen konnten.

Wer aus der Bahn geworfen wird, sollte die Weichen für sein Leben neu stellen.
Dafür gäbe es ja noch GSM-R.
Der Tf sollte wissen wo er hin will bzw hin fahren soll (hat ja auch einen Fahrplan) , und kann dies dann dem Fdl mitteilen und der den Fahrweg entsprechend stellen.
Oder wäre das mal wieder viel zu einfach und damit inakzeptabel, um den Eisenbahnbetrieb im Störfall laufend zu halten?

http://www.trainweb.org/railphot/x-hikashi2.gif
De David schrieb:
Dafür gäbe es ja noch GSM-R.
Der Tf sollte wissen wo er hin will bzw hin fahren soll (hat ja auch einen Fahrplan) , und kann dies dann dem Fdl mitteilen und der den Fahrweg entsprechend stellen.
Oder wäre das mal wieder viel zu einfach und damit inakzeptabel, um den Eisenbahnbetrieb im Störfall laufend zu halten?
Servus,

selbstverständlich kann man notfalls mittels GSM-R bei jedem Zug einzeln anfragen, wie er hinwill. Aber das ist wenig praktikabel, weil der Bereich eines özF deutlich mehr als ein Bahnhof ist. Wir reden da eher von 50 bis 100 km Strecke. Auf einer nur dem Personenverkehr dienenden SFS ist das noch übersichtlich, aber was machst Du auf einer Mischbetriebsstrecke mit Güter- und Personenverkehr? Dazu vielleicht noch ein virulenter Knoten. Ich glaube der Fdl wüsste hier nicht einmal, unter welcher Zugnummer er die einzelnen Güterzüge erreichen kann.

MfG Martin Pfeifer

Lieber Blech- als Plastikspielzeuge!
Martin Pfeifer schrieb:
selbstverständlich kann man notfalls mittels GSM-R bei jedem Zug einzeln anfragen, wie er hinwill. Aber das ist wenig praktikabel, weil der Bereich eines özF deutlich mehr als ein Bahnhof ist. Wir reden da eher von 50 bis 100 km Strecke. Auf einer nur dem Personenverkehr dienenden SFS ist das noch übersichtlich, aber was machst Du auf einer Mischbetriebsstrecke mit Güter- und Personenverkehr? Dazu vielleicht noch ein virulenter Knoten. Ich glaube der Fdl wüsste hier nicht einmal, unter welcher Zugnummer er die einzelnen Güterzüge erreichen kann.
Es gibt ein solches Rückfallverfahren (Fahren mit Fahrstraßenkarten), aber man darf nicht vergessen, dass bei einem Stellwerksausfall erst Handverschlüsse angebracht werden müssen. Wenn sowas passiert, dann hat man ein richtiges Problem.

Was bei ETCS L2 natürlich ein zusätzliches Problem ist, ist ein GSM-R Ausfall. Dann gibt's nämlich weder Movement Authorities noch Befehle. Dem könnte man entgegenwirken indem man L1 als Rückfallebene einbaut, die Holländer machen das.
Hallo MrEnglish,

MrEnglish schrieb:
Zitat:
Was bei ETCS L2 natürlich ein zusätzliches Problem ist, ist ein GSM-R Ausfall. Dann gibt's nämlich weder Movement Authorities noch Befehle. Dem könnte man entgegenwirken indem man L1 als Rückfallebene einbaut, die Holländer machen das.
Nein, sie haben das einmal vor vielen Jahren bei Ihrer ersten ETCS-Strecke gemacht - und seitdem nie wieder!

Das hatte damals auch einen ganz anderen Grund. Die HSL ZUID war die erste ETCS-Level 2 Strecke die über eine Landesgrenze führte, und die Belgier hatten sich für einen anderen Anbieter entschieden. Damals war die Schnittstelle zwischen zwei RBC noch nicht spezifiziert und jeder Hersteller setzte seine eigene ein. Die holländische ETCS Level 2-Streckenzentrale war also inkompatibel zur belgischen ETCS Level 2 Streckenzentrale. Um die Strecke dennoch in Betrieb zu nehmen wurde zustzlich ETCS Level 1 mit minimale Aussensignale realisiert (Es gibt nur Hauptsignale und die haben nur eine einziges weißes Kennlicht, weliches um überfahren der folgenden Balisengruppe berechtigt - so konnte man sich den Euroloop sparen).

Gruß Jörg
JoergAtDSO schrieb:
Nein, sie haben das einmal vor vielen Jahren bei Ihrer ersten ETCS-Strecke gemacht - und seitdem nie wieder!

Das hatte damals auch einen ganz anderen Grund. Die HSL ZUID war die erste ETCS-Level 2 Strecke die über eine Landesgrenze führte, und die Belgier hatten sich für einen anderen Anbieter entschieden. Damals war die Schnittstelle zwischen zwei RBC noch nicht spezifiziert und jeder Hersteller setzte seine eigene ein. Die holländische ETCS Level 2-Streckenzentrale war also inkompatibel zur belgischen ETCS Level 2 Streckenzentrale. Um die Strecke dennoch in Betrieb zu nehmen wurde zustzlich ETCS Level 1 mit minimale Aussensignale realisiert (Es gibt nur Hauptsignale und die haben nur eine einziges weißes Kennlicht, weliches um überfahren der folgenden Balisengruppe berechtigt - so konnte man sich den Euroloop sparen).
Das ist richtig, was die Problematik an der Grenze und die Ausstattung der Strecke mit "Overrun lights" angeht. Aber das Problem erklärt nicht, warum es auf der gesamten Strecke und vor allem auch im Nordteil L1 gibt. Dazu hätte auch eine Transition aus L2 nach L1 kurz vor der Grenze gereicht, ohne jede Weißlampe.

L1 ist auf der HSL Zuid durchaus als Rückfallebene gedacht, und das ähnlich wie in Deutschland mit PZB und LZB (z.B. Hannover-Würzburg) auch nur mit geringerer Blockteilung und nur mit 160 km/h. Ich weiß nicht einmal, ob die Strecke jemals auf L1 umgeschaltet wurde, seitdem L2 funktionsfähig ist.

Anders ist es auf der HSL 4, also dem belgischen Teil, wo L1 parallel genutzt wird (sozusagen als Hot Standby) und ebenfalls 300 km/h erlaubt.

Gruß,
Sven

Keine Termine für ETCS-Ausstattung von Irgendetwas

geschrieben von: Saxobav

Datum: 15.01.21 10:19

Hadufuns schrieb:
50 3529 schrieb:
...
Für die Sicherheit des Fahrweges sorgt das Stellwerk, nicht das Zugbeeinflussungssystem.
Auf den alten SFS findest du neben wenigen ESTW vor allem eine bunte Mischung von Relaisstellwerksbauarten.
Das sind z.B. SpDrL60, SpDrS60, SpDrS600 bis zu MCL84.
[...]
Zumindest bei den SpDrL60-Stellwerken (Zuffenhausen und Vaihingen (Enz)) wäre eine "Teilerneuerung" denkbar, für deren Realisierung im besten Fall nicht mehr als ein oder zwei Sperrpausen notwendig wären (vgl. Bad Krozingen, Denzlingen).
Für mich ist die Situation sehr ähnlich wie bei der Digitalisierung des Telefonnetzes in den 90ern mit ATM/ISDN.

Wo und wie anfangen?
Nach einer Vorsortierung in Exoten, starker Unzuverlässigkeit und hohen Betriebskosten hatte man eine erste Bedarfsgruppe, die man mit wenig Änderungen schnell auf die neue Technik bringen mußte. Hinzu kamen die Überlandleitungen mit den Adaptern zu den Vermittlungen.
Und dann kam die Entwicklung der zwischenzeitlichen Baugruppen, die als Interface zur Alttechnik auf der abgewandten Seite eines der Standard-Interfaces hat.
Beim Rollout hatte man dann bei halber Umstellung den maximalen Bedarf an solchen Interfaces. Danach werden mit weiteren Umstellungen diese Interfaces freigestellt und können ggf. bei anderen Altsystemen eine Mehrfachverwendung finden.

Hier im Fall wären also für leistungsfähige Altsysteme entsprechende NeuPro-DSTW-Schnittstellen zu entwickeln. Wer von den Großlieferanten das nicht hinbekommt, wäre schon mal aus dem Geschäft draußen, egal warum. Und danach geht es also um den Einbau der Neupro-Schnittstellen in Bestandsstellwerke. Egal, ob das Alt-Stellwerk mit neuer Außentechnik verbunden wird, oder alte Außentechnik mit neuen Stellwerkskernen.

Die genannten Stellwerke klingen für mich nach weitverbreiteten Standardtypen. Damit lohnen sich sowohl Baugruppenentwicklung als auch Wissensaufbau für die Implementierung und Wartung.
Ohne konkretes Wissen vermute ich den höchsten Bedarf bei den frühen mikroprozessorgesteuerten Baugruppen, zumindest bei den Triebfahrzeugen ist das so. Das würde also die frühen ESTW betreffen. Deren Generationswechsel (insbesondere bei Kleinserien oder nicht mehr vorhandener Lieferanten) würde diese vermutlich in die Exotenliste bringen.

Na ja, und dann kommt der nicht kalkulierbare politische Einfluß, weil man irgendwo im Tal einen Leuchtturm bauen muss, wider die wirtschaftliche Vernunft. Immerhin gibt es dann ein größeres Fettauge auf der Suppe, wo man homogen ausgestattete Bereiche hat.

Konkret am Thema müßte also die Entscheidung getroffen werden, ob man für die LZB eine DSTW-Schnittstelle schafft, weil eine große Menge von Altfahrzeugen noch für 10+ Jahre am Leben auf den Magistralen gehalten werden muss. Da die publizierte Entscheidung dagegen steht, kann die LZB mit zwei Jahren Vorankündigung netzseitig abgeräumt werden. Mit entsprechender Kompensation (streckenseitiger Extraaufwand entfällt) als Investvorlauf an Betreiber von Drehstromfahrzeugen und nachfolgende ETCS-Pflicht ist dann Ende der Diskussion.

Überhaupt vermisse ich eine aktive Rolle von DB Netz zur Gestaltung des eigenen Netzes bezüglich ETCS. Man läßt sich von irgendwelchen Verkehrsverbünden und wechselnden politischen Kräften treiben oder verhindern. Mit zwei Jahren Vorlauf für geänderte Netzzugangsbedingungen könnte jeder Nutzer seine Fahrzeuge anpassen. Der gesetzliche Rahmen seitens der EU ist vorhanden, die Ausnahmen müssen nicht ausgeschöpft werden.

Schönen Tag, saxobav.
Seiten: 1 2 3 4 5 All Angemeldet: -