4000er Serie der Stadtbahn gesichtet!

[dt8.de]

Für den RBL-Datenfunk steht der SSB m.W. nur ein (oder sind es inzwischen mehr?) 20 KHz breites Frequenzband zur Verfügung, da darf ein Nachrichtentechniker gerne mal erzählen, was da maximal an Daten drüber geht. Dürfte im Bereich eines 14k-Modems liegen, und damit müssen alle Bahnen und Busse mit RBL-Daten versorgt werden (natürlich beide Richtungen).

Ich bin zwar kein Nachrichtentechniker, aber nach meinen Physik und IT-Kenntnissen kommt es auch nochmal auf die Frequenz an, in dem das Frequenzband liegt.

Ich meine, das ist von der Frequenz unabhängig, siehe anderes Posting. Ist aber auch bei mir schon sehr lange her.

Es ist die Frage was für eine Technologie das rechnergesteuerten Betriebsleitsystem (RBL) für den Datenfunk verwendet. Es ist nicht ausgeschlossen, das hierbei GSM oder gar UMTS-Technik verwendet wird was weit mehr als 14 kBit ermöglicht. Es ist auch nicht ausgeschlossen das gar das öffentliche Netz z.B. D2-Netz (das ist meines Wissens in den Tunneln der SSB am besten empfangbare), verwendet wird, oder gar mehrere.

M.W. (zumindest zu Anfängen des RBL) normaler Betriebsfunk im 2m-Band um 140 MHz.

Und mit der entsprechenden Technologie ist zwar die Übertragung pro Gerät begrenzt, aber es sind durchaus relativ viele Verbindungen gleichzeitig möglich, zudem wird sicher nicht ganz Stuttgart eine einzige Funkzelle sein.

Pro Zelle ist nur die gegebene Bandbreite möglich. Diese kann einen Gerät voll zur Verfügung stehen oder an mehrere Geräte verteilt werden, dann geht aber wieder die Bandbreite herunter.
Und dummerweise ist ganz Stuttgart eine einzige Funkzelle, zumindest im bisherigen RBL1-Datenfunk.
Die Fahrzeuge werden da reihum nacheinander "aufgerufen", mit Daten versorgt und Daten abgefragt. Ich weiß nicht, wie lange so ein Zyklus dauert, aber diese Zeit "dauert" es dann auch, bis solche Informationen wieder aktualisiert werden können.

Auch dürfte sich die Menge der Daten schon sehr in engen Grenzen halten, selbst wenn man diese an 1000 Fahrzeuge übermitteln muss, schließlich sind es keine Multimediadaten...

Richtig, aber durch die Positionsdaten etc. ist das Datenfunknetz schon recht gut ausgelastet. Werden es mehr Daten, dann werden die Zyklen eben entsprechend länger (und damit die Positionsangaben entsprechend ungenauer)

So wie ich es verstanden habe ist RBL nicht für Sicherheitskritische Funktionen zuständig.

Korrekt. Wobei ich mir nicht sicher bin, wie inzwischen der Sprechfunk funktioniert. Da könnten solche Dinge wie Sprechwünschmeldungen, Notrufsignalisierungen usw. über den Datenfunk laufen. Das weiß ich aber nicht.

---

Ich verschleuder mal ne Runde Wissen/Halbwissen (bitte beliebig auswählen auf Zutreffendes und Halbzutreffendes). Wenn 20kHz Breite zur Verfügung stehen, ist tatsächlich nur die Hälfte nutzbar, weil man zur Dartellung von einer einzelnen Schwingung immer zwei Punkte braucht, wenn man davon ausgeht, da werden binäre Inhalte per Schwingung übertragen. Dann geht man in der Regel noch ein wenig runter, um Aliasing zu vermeiden (siehe Audio-CD: 44,1Khz für Bandbreite 20Hz bis 20kHz).

Ja, Nyquist. Hatte ich gestern abend nicht mehr dran gedacht. War nur Überschlagen und ist bei mir schon über 15 Jahre her.

Und ja, es ist richtig, dass da noch mitspielt, welcher Frequenzband zur Verfügung steht. Denn im hohen Frequenzband kann man schneller modulieren und erhält eine höhere Speicherdichte. Im niederen wird langsamer moduliert, also geringere Speicherdichte.

Sicher? Eine "schnellere" Modulation heißt doch, daß das Frequenzband breiter wird. Und die Breite ist ja fest. Daher sollte die Rate auch nur von der Bandbreite abhängig sein. Zumindest meine ich, das mal so gelernt zu haben.
Zusätzlich ist das auf Analogtechnik bezogen, ich weiß nicht, was es heute bei der Übertragung von digitalen Informationen für "Tricks" gibt. Bei analogen Modemverbindungen hat man da ja noch ein paar Dinge "erfunden", um bis zu den 56k zu kommen.

So, nun aber mal zur Informatik: Was wird denn da übertragen? Ein paar Bit breite Infos zu Verspätungen. Es muss ja kein kompletter Bildschirminhalt übertragen werden. Nur Zahlen! Nur einzelne Daten über erreichbare Anschlüsse (was im Endeffekt pro Anschlussmöglichkeit auch wieder nur einen vielleicht 8Bit-breiten Zahlenwert in Binärform darstellt). Rechnet doch mal zusammen: Da bestehen insgesamt am Hauptbahnhof vielleicht 15 Anschlussmöglichkeiten. Oder sagen wir einfach 16 (weils ne 2er-Potenzzahl ist). Macht 2x16Bit, einmal für Anschlusscode, einmal für Zeitwert, wann der Anschluss abfährt. Hallo! Das sind 4Byte!! Das ist nicht mal ein SMS-Rülpser wert!! Und da sprecht ihr von Notwendigkeit hoher Bandbreiten?
Außer es kann hier einer fundiert sagen, welche Informationen übertragen werden, geh ich jetzt einfach mal vom oben Beschriebenen aus. Und diese Informations-"Menge" ist so klein, dass sie vom Stand der Funktechnik aus schon hätte vor vielen Jahren übertragen werden können (nur halt noch nicht interpretiert hätte können von einem passenden Bildschirm mit angeschlossener Logik-Einheit).

Ja und Nein. Die Datenmenge ist nicht wirklich groß (wenn man es richtig macht), muß aber einerseits aktuell gehalten werden, und hat andererseits keinen eigenen Kanal zur Verfügung, d.h. das RBL muß die Daten im richtigen Moment dem RBL-Datenstrom beifügen.
Ich weiß jetzt nicht, wie oft ein Fahrzeug RBL-Daten austauscht, aber wenn das z.B. einmal pro Minute stattfindet, dann ist das schon ein recht langer Zeitraum. In der Zeit fährt die Bahn schon vom Schlossplatz (ein Anschluß-Datensatz) zum Hbf (nächster Datensatz).

Wenn z.B. 300 Fahrzeuge (Bahn+Bus) im Netz unterwegs sind, dann würde ein Datenaustausch pro Minute bedeuten, daß pro Sekunde 5 Fahrzeuge einen Datenaustausch machen müssen. Mit Protokolloverhead (Aufruf des Fahrzeugs etc.) auf nur einem Kanal würde ich nicht sagen, daß das "nichts" ist.
Natürlich kann das RBL Fahrzeuge priorisieren, die auf eine Haltestelle mit Umsteigemöglichkeiten zufahren, aber das geht auch nur in begrenzten Umfang, sonst werden irgendwann andere Fahrzeuge nur noch selten bedient.

Daß es schon heute hin und wieder klemmt dürfte die Ursache dafür sein, daß die Haltestellenanzeigen schon heute manchmal hinerherhinken und SPrünge machen: erst steht die Anzeige ewig auf z.B. drei Minuten und springt dann gleich auf eine Minute. Das kommt genau daher, daß es irgendwo an der Aktualisierung gefehlt hat.

Allerdings weiß ich definitiv nicht, ob meine Information mit einem 20 kHZ breiten Datenfunkkanal noch stimmt. Das war bei Einführung des ersten RBL so. Da aber exklusive Funkfrequenzen auch heute nicht billig sind spricht dieses dafür, daß es noch heute so sein dürfte.

[luchs]

Wenn z.B. 300 Fahrzeuge (Bahn+Bus) im Netz unterwegs sind, dann würde ein Datenaustausch pro Minute bedeuten, daß pro Sekunde 5 Fahrzeuge einen Datenaustausch machen müssen. Mit Protokolloverhead (Aufruf des Fahrzeugs etc.) auf nur einem Kanal würde ich nicht sagen, daß das "nichts" ist.

5 mal pro sek....
Das ist doch nicht aufwendig. Hast du eine Vorstellung wie häufig das Fequenz-Switching bei einem normalen Handy pro Sekunde durchgeführt wird. Da ist man sicher schon weit über 100 oder gar 1000 und dadurch ist es ja überhaupt möglich auf einem Fequenzband loker 100 oder mehr Verbindungen gleichzeitig aufrecht zu erhalten.
Wird z.B. GPRS verwendet wäre es gar kein Problem zu jedem Fahrzeug logisch permanent eine Verbindung offen zu halten. Meist ist das nur eine Frage der Software auf dem Server, weil historisch gewachsen und dafür nicht ausgelegt...

Allerdings weiß ich definitiv nicht, ob meine Information mit einem 20 kHZ breiten Datenfunkkanal noch stimmt. Das war bei Einführung des ersten RBL so.

Wann war denn das mit der ersten Einführung?

Da aber exklusive Funkfrequenzen auch heute nicht billig sind spricht dieses dafür, daß es noch heute so sein dürfte.

Das spricht für mich eher dafür, das man den Service und das Netz (D1, D2, E-Plus etc.) etablierter Mobilanbieter verwendet. Schließlich ist ein exklusives Netz mit eigener Frequenz sehr teuer im Unterhalt. Und GSM, UMTS etc. bieten ausreichend Möglichkeiten die Dienste ggü. normaler privater Nutzung zu priorisieren. Ausfallsicherheit dürfte über diesen Weg sogar einfacher zu realisieren sein, als wenn man ein Netz auf eigener Frequenz nutzt.

Aber wir spekulieren hier schon ganz wild - vielleicht findet sich ja noch einer der sich auskennt...

[Andy0711]

Wenn z.B. 300 Fahrzeuge (Bahn+Bus) im Netz unterwegs sind, dann würde ein Datenaustausch pro Minute bedeuten, daß pro Sekunde 5 Fahrzeuge einen Datenaustausch machen müssen. Mit Protokolloverhead (Aufruf des Fahrzeugs etc.) auf nur einem Kanal würde ich nicht sagen, daß das "nichts" ist.
Natürlich kann das RBL Fahrzeuge priorisieren, die auf eine Haltestelle mit Umsteigemöglichkeiten zufahren, aber das geht auch nur in begrenzten Umfang, sonst werden irgendwann andere Fahrzeuge nur noch selten bedient.

Man müsste das halt als Broadcast durchführen, d. h. an alle gleichzeitig senden.
Wenn man annimmt, dass
a) die Fahrpläne lokal im System gespeichert sind
b) maximal 80 S-Bahn-, 140 Stadtbahn- und 280 Buskurse unterwegs sind (Summe z. B. 500)
c) man Kursnummern im 16-Bit-Bereich verwendet (0-65535)
d) die Verspätung auf 30 Sekunden genau mit 8 Bit (-6 bis 120 Minuten) angegeben wird.
e) man 8 Bit für Statusflags, Fehlercodes o. ä. verwendet (z.B. 256 Fehlercodes, 00 = OK)
f) anschließend eine CRC-Prüfsumme einbaut und davor eine Datensatzkennung berücksichtigt
hätte man z.B. 512 x 32 Bit = 16 KBit = 2 KB für einen Datensatz. (=> 14K-Modem weniger als eine Sekunde).
Das macht bei (Annahme) 4 Datensätzen/Minute 4 Sekunden Kanalbelegung bei einer Leistungsfähigkeit eines 14k-Modems.

Bei Bedarf könnte man das Konzept natürlich variabler machen, zum Durchrechnen sollte es aber ausreichen.

Denoch möchte ich ein Beispiel ohne zusätzlichen Datentransfer für die 8-Bit-Verspätung aufzeigen, um die Möglichkeiten, die in ein paar Bits stecken, zu verdeutlichen:
00-3f (000-063): 0 Sekunden Verspätung bis 630 Sekunden in 10-Sekundenschritten.
40-7f (064-127): 10,5 Minuten Verspätung bis 42 Minuten Verspätung in 30-Sekundenschritten
80-bf (128-191): 42 Minuten Verspätung bis 105 Minuten Verspätung in Minutenschritten
c0-df (192-223): 110 Minuten Verspätung bis 265 Minuten Verspätung in 5-Minutenschritten
e0-ef (224-255): 30 Sekunden Verfrühung bis 8 Minuten Verfrühung in 30-Sekundenschritten
f0-ff: 10 Minuten Verfrühung bis 40 Minuten Verfrühung in 2-Minutenschritten (nur für die DB ;-))

Für Sonderkurse müsste man natürlich einen Kursnummernbereich reservieren und min. 8 statt 4 Bytes benutzen und den Kurs sowie die Abfahrtszeit nach einem anderen Schema codieren (Liniennummer; Unter-/Teilstrecke usw.). Beispiel für Kursnummern:
0000-1fff (00000-08191): Stadtbahnlinie+Kurs: z.B. U1-01 = 0101
2000-7fff (08192-32767): Buslinie+Kurs: z.B. 80-01 = 5001 (80 = 50 hexadezimal)
8000-bfff (32768-49151): S-Bahnen nach Fahrt: z.B. 7151 = 30000+7151 (diesesmal Dezimal); Kursnummern für andere Züge müssten geschlüselt werden.
c000-ffff (49152-65535): Zusatzfahrten nach gesondertem Schlüssel

...

PS: Da die DFI-Anzeigen an Haltestellen nicht ausreichend intelligent dafür sein dürften, könnte dieses Konzept dort natürlich nicht funktionieren.

[dt8.de]

Wenn z.B. 300 Fahrzeuge (Bahn+Bus) im Netz unterwegs sind, dann würde ein Datenaustausch pro Minute bedeuten, daß pro Sekunde 5 Fahrzeuge einen Datenaustausch machen müssen. Mit Protokolloverhead (Aufruf des Fahrzeugs etc.) auf nur einem Kanal würde ich nicht sagen, daß das "nichts" ist.

5 mal pro sek....
Das ist doch nicht aufwendig. Hast du eine Vorstellung wie häufig das Fequenz-Switching bei einem normalen Handy pro Sekunde durchgeführt wird. Da ist man sicher schon weit über 100 oder gar 1000 und dadurch ist es ja überhaupt möglich auf einem Fequenzband loker 100 oder mehr Verbindungen gleichzeitig aufrecht zu erhalten.
Wird z.B. GPRS verwendet wäre es gar kein Problem zu jedem Fahrzeug logisch permanent eine Verbindung offen zu halten. Meist ist das nur eine Frage der Software auf dem Server, weil historisch gewachsen und dafür nicht ausgelegt...

Und Du kennst sicher die Kanalbreite und Datenübertragungsrate von GPRS. Das ist mit einem Betriebsfunkkanal im 20kHz-Raster nicht realisierbar. Frequenzhopping ist eh eine andere Baustelle, da wir hier nur eine Frequenz haben.

Allerdings weiß ich definitiv nicht, ob meine Information mit einem 20 kHZ breiten Datenfunkkanal noch stimmt. Das war bei Einführung des ersten RBL so.

Wann war denn das mit der ersten Einführung?

Keine genaue Ahnung, zwischen 1984 und 1990. Die Frage ist auch nicht, ob das Netz noch verwendet wird (das wird es), sondern ob inzwischen weitere Kanäle darin zur Verfügung stehen. Die Funkanlage in einem DT8 ist eine etwas komplexere Sache als ein Handy, die wird nicht kurz mal ausgetauscht. Um vom 150MHz-Betriebsfunk in den 900 oder 1800MHz-GSM oder gar UMTS-Bereich zu kommen ist etwas mehr Aufwand erforderlich. Da reicht es nicht, das Endgerät zu tauschen, da müsste wahrscheinlich sogar die komplette Antennenverkabelung gewechselt werden.

Da aber exklusive Funkfrequenzen auch heute nicht billig sind spricht dieses dafür, daß es noch heute so sein dürfte.

Das spricht für mich eher dafür, das man den Service und das Netz (D1, D2, E-Plus etc.) etablierter Mobilanbieter verwendet. Schließlich ist ein exklusives Netz mit eigener Frequenz sehr teuer im Unterhalt. Und GSM, UMTS etc. bieten ausreichend Möglichkeiten die Dienste ggü. normaler privater Nutzung zu priorisieren. Ausfallsicherheit dürfte über diesen Weg sogar einfacher zu realisieren sein, als wenn man ein Netz auf eigener Frequenz nutzt.

Warum sollte das Ausfallsicherer sein? Erst neulich hat D1 mal wieder gezeigt, was ausfallsicher heißt. Bei einer eigenen Frequenz kann fast nichts ausfallen, da brauchst Du nur einen (mehrere) Sende- und Empfangsmasten mit recht einfacher Anlage (Analogtechnik!), das Gegenstück ist ja in den Bahnen. Wenn da was ausfällt, dann tut der nächste Mast noch immer. Dann Modem dran und gut ist.
Die Digitaltechnik in Mobilfunknetzen ist wesentlich komplexer, da kann viel mehr ausfallen. Und warum soll Digitaltechnik immer und für alles besser sein als Analogtechnik?

Das RBL gibt es nun seit ca. 20 bis 25 Jahren, wie oft hat in dieser Zeit die Mobilfunktechnik gewechselt? C-Netz, D-Netz, UMTS. Das ist nicht gerade Investitionssicherheit, wenn man den Mobilfunkbetreibern ausgeliefert ist.
Übrigens habe ich zwischen Weinsteige und Bopser keinen Mobilfunkempfang. Und nun?

Was die Infrastruktur angeht: per PM nenne ich Dir gerne den Standort zumindest eines SSB-Sendemastes. Die Infrastruktur ist da.
Es ist nicht so, daß ich gar nicht weiß, wovon ich spreche.

Martin

---

Hallo,

per Broadcast wäre es vielleicht auch machbar, ich bin davon ausgegangen, daß jedem Fahrzeug die Daten für die nächste Haltestelle individuell mitgeteilt werden. Das RBL kennt ja den Standort und weiß daher, welche Daten benötigt werden.

Man müsste das halt als Broadcast durchführen, d. h. an alle gleichzeitig senden.
Wenn man annimmt, dass
a) die Fahrpläne lokal im System gespeichert sind

Falsche Annahme: bei der Sonderfahrt war ja zu sehen, daß der Zug ohne Fahrplan fuhr, dennoch im RBL erfasst war und an den Haltestellen korrekt angezeigt wurde. Mit ausschließlich lokal gespeicherten Fahrplänen wäre das nicht möglich.

Ich halte eine individuelle Datenübertragung für wahrscheinlicher, da da ja nur Linie/Ziel und Verspätung übertragen werden muß. Wenn ich für Linie/Ziel 3 Byte nehme (ist so im IBIS hinterlegt), für die Zeit zur Abfahrt 1 Byte bin ich pro Datensatz bei 4 Byte. Wenn wir von 20 angezeigten nächsten Verbindungen ausgehen (10 Linien a 2 Richtungen) sind das 80 Byte. Diese sende ich im normalen RBL-Zyklus mit, also kein großer zusätzlicher Overhead. Diese sende ich nur an Fahrzeuge, die sich gerade in Anfahrt auf eine Umsteigehaltestelle befinden. Wieviele der 300 Kurse wären das? Wahrscheinlich auch nicht wesentlich mehr an Daten als im Broadcast, aber flexibler.

Halt mit dem Nachteil, daß das im normalen RBL-Zyklus wäre, also eine gewisse Zeitverzögerung hat.
Das Problem ist nicht, die Daten rüberzubekommen, sondern nur die Frage, wann das stattfindet. Je mehr Daten übertragen werden, desto länger wird der Zyklus, und desto unaktueller die Daten. Aber funktionieren wird es. (Um beim IT-Analogon zu bleiben: Token-Ring, wers noch kennt)

PS: Da die DFI-Anzeigen an Haltestellen nicht ausreichend intelligent dafür sein dürften, könnte dieses Konzept dort natürlich nicht funktionieren.

Die lassen wir mal weg, die werden ja anders versorgt.

Ich habe übrigens auf der Sonderfahrt versucht, diese Frage zu stellen. Die Antwort klang mir allerdings nicht unbedingt passend (das Wort "WLAN" fiel ... / ja, das gibt es zur Datenversorgung auf den Betriebshöfen. Aber da nutzt es nicht für den Zweck).

[Andy0711]

a) die Fahrpläne lokal im System gespeichert sind

Falsche Annahme: bei der Sonderfahrt war ja zu sehen, daß der Zug ohne Fahrplan fuhr, dennoch im RBL erfasst war und an den Haltestellen korrekt angezeigt wurde. Mit ausschließlich lokal gespeicherten Fahrplänen wäre das nicht möglich.

Klar. Ich wollte darauf hinaus, dass man es so realisieren könnte, dass entweder vorhersehbare Sonderfahrten über ein System angesprochen werden könnten oder nur bei Sonderfahrten (welche ja nur eine Minderheit darstellen) die Fahrpläne direkt übertragen werden müssten. (Das müsste ja wiederum nicht bei jeder Übertragung stattfinden.) Lokalen Speicher einzubauen wäre ja ein günstig zu machen und man könnte theoretisch auch ein paar Mal am Tag den gesamten Fahrplan übertragen. Es geht ja um ein neues System, falls die Ressourcen des aktuellen nicht ausreichen - daher der Gedanke.

Ich halte eine individuelle Datenübertragung für wahrscheinlicher [...] sind das 80 Byte. Diese sende ich im normalen RBL-Zyklus mit, also kein großer zusätzlicher Overhead. Diese sende ich nur an Fahrzeuge, die sich gerade in Anfahrt auf eine Umsteigehaltestelle befinden. Wieviele der 300 Kurse wären das? Wahrscheinlich auch nicht wesentlich mehr an Daten als im Broadcast, aber flexibler.

Halt mit dem Nachteil, daß das im normalen RBL-Zyklus wäre, also eine gewisse Zeitverzögerung hat.
Das Problem ist nicht, die Daten rüberzubekommen [...]

Eben. Ich wollte mit dem Beispiel nur zeigen, dass man sich viele Lösungen vorstellen kann und es in jedem Fall irgendwie möglich sein würde - und dass die dazu benötigten Datenmengen zu Zeiten von DSL gerne überschätzt werden.

[ICE-Charly]

Hallo Freunde,
ohne, daß es jemandem groß aufgefallen ist, war am 23.05.09 ganz unspektakulär und ohne Vorankündigung durch diverse Informanten die erste Doppetraktion der 4000er Serie auf Linie 6 im Einsatz.

[Hase]

Der DT8S war aber nur kurzweilig auf der U6 eingesetzt, da es zuvor durch einen angetrunkenen
Fahrgast in der U6 zu erheblichen Schwierigkeiten und dadurch zu einer 15 minuetigen Verspaetung kam.

Es war purer Zufall das gerade eine Doppeltraktion DT8S durch die Fahrschule der SSB unterwegs war und somit ab Gerlingen fuer die U6 eingesetzt werden konnte.

Ansonsten findet man den DT8S auf der Linie U8 und natuerlich auch wenn es moeglich ist als Fahrschulwagen fuer Einweisungen der Fahrer

[AFu]

Hallole,

gestern, 28.5.09 habe ich gegen 17:10 einen stadtauswärts fahrenden DT8S auf der U4 beim Leo-Vetter-Bad gesichtet. Nummer konnte ich leider nicht erhaschen.

Grüßle
AFu

[dt8.de]

Hallo,

gestern, 28.5.09 habe ich gegen 17:10 einen stadtauswärts fahrenden DT8S auf der U4 beim Leo-Vetter-Bad gesichtet. Nummer konnte ich leider nicht erhaschen.

könnte das eine Fahrschule gewesen sein? Auf der U4 werden die DT8S kaum als erstes zum Einsatz kommen. Wegen der Nähe zur HW sollen die zunächst von Möhringen aus eingesetzt werden, also U3, 5, 6, 7, 8, 15.

Martin

[AFu]

Hallole,

ja, richtig, es war Ein B-Wagen.

Grüßle
AFu