Abbildung 1: BR480
Abbildung 2: BR481 (mod.)
Abbildung 3: BR483/484

Einleitung

Kostengünstige und kompakte Plattformen wie der Raspberry Pi ermöglichen es, geosensorische Messsysteme einzusetzen und individuell an spezifische Fragestellungen anzupassen. Im Bereich des öffentlichen Personennahverkehrs spielen solche Messungen eine wichtige Rolle, da sie Aufschluss über den Zustand von Fahrzeugen, Gleisanlagen und den Fahrkomfort geben können.

Im Rahmen dieses Projekts wird ein mobiles Messsystem aufgebaut, das Vibrationen und somit mitunter den Fahrkomfort während der Fahrt mit S-Bahnen in Berlin erfasst und räumlich verortet. Der Fokus liegt dabei auf dem Vergleich zwischen den unterschiedlichen Baureihen BR 480, BR 481 (modernisiert) sowie BR 483/484. Durch die Kombination von bereitgestellter Sensorik sollen Unterschiede im Vibrationsverhalten analysiert, ausgewertet und visuell dargestellt werden.

Motivation und Ziel

Die Motivation für dieses Projekt liegt einerseits im eigenen Interesse, ob auch messbare Unterschiede zwischen den Baureihen zu erkennen sind, andererseits in der Anwendung von geosensorischen Messmethoden in Kombination mit der Datenverarbeitung. Durch den Einsatz eines Raspberry Pi 4 in Kombination mit einem Beschleuingungssensor und Global Navigation Satellite System (GNSS)-Empfänger wird ein vollständiger Messworkflow nach dem EVAP-Modell (Erfassung – Verwaltung – Analyse – Präsentation) dokumentiert.

Fragestellung

Ausgehend von der technischen Umsetzung sowie der Datenerhebung ergibt sich folgende zentrale Fragestellung:

Inwiefern unterscheiden sich die geosensorisch erfassten Vibrationsmuster der Berliner S-Bahn-Baureihen BR 480, BR 481 (modernisiert) sowie BR 483/484? Lassen sich diese Unterschiede räumlich und statistisch nachvollziehbar visualisieren?

Aufbau der Messung

Das Messsystem basiert auf:

  • einem Raspberry Pi 4 mit Speicherkarte: Der Raspberry Pi dient als zentrale Recheneinheit des Messsystems. Mithilfe eines Python-Skripts werden die Messdaten der per USB angebundenen Sensoren erfasst, verarbeitet und als CSV-Datei abgespeichert. Aufgrund der kompakten Bauweise sowie der universellen Unterstützung für serielle Schnittstellen eignet sich der Raspberry Pi besonders für mobile geosensorische Anwendungen.

  • dem u-blox EVK-F9DR mit integriertem ZED-F9K-Modul: Das u-blox EVK-F9DR ist ein Evaluations- und Entwicklungsboard zur hochpräzisen GNSS-Navigation mit integrierter Dead-Reckoning-Funktionalität (Koppelnavigation). Es unterstützt den gleichzeitigen Empfang mehrerer GNSS-Systeme und ermöglicht in der Theorie eine zuverlässige Positionsbestimmung durch näherungsweise Ortsbestimmung aufgrund der Aufzeichnung der Fortbewegungsrichtung und -geschwindigkeit auch in GNSS-gestörten Umgebungen, wie z. B. in Tunneln. Das Board stellt die Schnittstelle zwischen den Sensoren und dem Raspberry Pi dar (Quelle und weitere Informationen: https://www.u-blox.com/en/product/evk-f9dr). Das ZED-F9K-Modul ist das zentrale GNSS- und IMU-Modul innerhalb des EVK-F9DR. Es liefert satellitengestützte Positionsdaten wie auch inertiale Messeinheiten (IMU) als Kombination von Translationssensoren und gyroskopischen Sensoren. Letztere und genauer die Beschleuingungssensordaten werden zur Erfassung von Vibrationen während der S-Bahn-Fahrten genutzt. Durch die Verknüpfung mit den Positionsdaten können die gemessenen Vibrationen räumlich eindeutig zugeordnet und für den Vergleich der verschiedenen Fahrzeugbaureihen ausgewertet werden.

Abbildung 4: Messaufbau im Feld

Für die mobile Stromversorgung wird eine Powerbank mit hoher Kapazität verwendet.

Vorbereitende Maßnahmen

Vor dem Feldeinsatz wurde der Raspberry Pi entsprechend eingerichtet. Die Linux-Distribution Raspberry Pi OS mit einer aktuellen Version der universell einsetzbaren Programmiersprache Python und notwendigen Python-Bibliotheken zur Ausführung des Skriptes wurden hierfür installiert.

Im Detail wurden folgende Voraussetzungen wurden dabei für das Skript erfüllt:

  • Python 3.13 oder höher
  • Python-Bibliothek pyubx2 in der Version 1.2.59 oder höher
  • Python-Bibliothek PySerial in der Version 3.5 oder höher

Pyserial dient zur Kommunikation mit vorhandenen seriellen Schnittstellen des Computers via Python. Mithilfe dieser Bibliothek ist das Lesen von Daten oder Senden von Befehlen an angebundene Geräte möglich. Die Python-Bibliothek pyubx2 wird zur einfacheren Interpretation des Datenstroms, welcher per USB vom EVK-F9DR übermittelt wird, verwendet.

Ziel des Skriptes ist es die Verbindung zum EVK-F9DR herzustellen und eine passende Konfigurations-Nachricht an diesen zu senden, damit dieser nicht die Standard-Nachrichten über die serielle Schnittstelle versendet, sondern die von uns angefragten. Pro Sekunde werden 100 Nachrichten vom EVK-F9DR empfangen. Daraufhin werden die empfangenen Daten je nach Art interpretiert und jede zwanzigste Nachricht in eine CSV-Datei geschrieben. Dadurch ergibt sich eine Aufzeichnungsfrequenz von 1/5 Sekunden.

Das Skript wurde sorgfältig aufbereitet, wodurch es entsprechend auf unterschiedliche Szenarien reagieren kann. Es werden die zuvor erwähnten Voraussetzungen überprüft, bei Bedarf können die Standardvariablen, wie Port oder Baudrate mit entsprechenden Argumenten beim Ausführen des Python-Skript mit angegeben und somit überschrieben werden. Auch diese werden vor der Prozesserung überprüft.

Abbildung 5: Ausgabe der Hilfe-Option für das Python-Skript in einem Linux-Terminal

Durch die Ausgabe von Statusmitteilungen in entsprechenden Farben (Grün - Orange - Rot) wird der Nutzende stets über den aktuellen Stand informiert und kann bei Fehlern oder Warnungen entsprechend direkt handeln. Bis bspw. nicht eine positive Bestätigung seitens des EVK-F9DR zum Ändern der auszugebenen Nachricht erscheint, laufen die weiteren Schritte nicht und bei Fehlern wird das Skript entsprechend abgebrochen. Teile der Prozessierung des Nachrichtenstroms werden gleichzeitig mithilfe von Multithreading (Mehr- bzw. Nebenläufigkeit von Prozessen) ausgeführt, um Ausführungszeiten zu reduzieren, somit Effizienz zu verbessern und möglichst wenige Verzögerungen zu erzeugen. Allgemein wurden die verwendeten Funktionen in der Python-Klasse chronologisch definiert und Zeilen stets kommentiert, sodass Details dem Skript entnommen werden können.

Das Skript ist unter “/Python/ubx_F9K_log_acc_gyro_pos.py” zu finden.

Um die notwendigen Konfigurationen korrekt anzuwenden, wurden die von u-blox entwickelten Evaluierungs-Software u-center sowie unter https://www.u-blox.com/en/product/evk-f9dr?&legacy=Current#Documentation-&-resources veröffentlichten Dokumentationen verwendet. So kann z. B. über das “Genration 9 Configuration View”-Menü im u-center der notwendige Konfigurations-Hex-Code generiert werden, welcher an den EVK-F9DR gesendet werden muss, um die benötigten Nachrichten von diesem zu erhalten. Das gleiche Verfahren wird zum Schluss beim Abbruch des Programms und dem einhergehenden Versenden der Reset-Konfiguration angewandt.

Mithilfe der pyubx2-Bibliothek wäre auch die manuelle Konstruktion der CFG-VALSET- und CFG-VALDEL-Nachrichten anhand einzelner Nachrichten-Komponenten möglich. Jedoch scheint es im Moment ein Bug mit der Firmware des Gerätes zu existieren, welcher diese neuen Arten der Konfiguration-Nachrichten nicht erwartungsgemäß verarbeitet. Explizit werden CFG-VALDEL-Nachrichten nicht vom Gerät korrekt erkannt und die Konfiguration nicht zurückgesetzt. Aus diesem Grund wurde im Rahmen des Projektes auf die veraltete UBX-CFG-CFG-Methode zurückgegriffen (vgl. Zeilen 131 - 155 im Python-Skript).

Nach erfolgreichreich Konfiguration der auszugebenden Nachrichten, werden folgende Werte erfasst und in eine CSV-Datei geschrieben:

Attributwerte aus ESF (External Sensor Fusion) - RAW (Raw Measurements)-Nachrichten:

  • Beschleunigungswerte (Accelerometer) in drei Raumachsen X/Y/Z
  • Gyroskopwerte / Winkelgeschwindigkeiten in drei Raumachsen X/Y/Z

Attributwerte aus NAV (Navigation) - HPPOSLLH (High Precision Geodetic Position)-Nachrichten:

  • Längengrad (Longitude)
  • Breitengrad (Latitude)
  • Horizontale Genauigkeitsschätzung (Accuracy Estimate 2D (Horizontal))

Attributwerte aus NMEA (National Marine Electronics Association) - GxGGA (Global Positioning System Fix Data)-Nachrichten:

  • Längengrad (Longitude)
  • Breitengrad (Latitude)
  • HDOP (Horizontal dilution of precision; beschreibt den Fehler, welcher durch die relative Position der GNSS-Satelliten entstehen kann; je niedriger der Wert, desto besser)

Bei erstem Anblick erscheint die Anzahl an aufzuzeichnenden Attributwerten hoch und teilweise redundant. Die Gyroskopwerte wurden mitaufgezeichnet, um bei Bedarf die Winkelgeschwindigkeiten bei der Ermittlung von Vibrationen und Fahrkomfort einzubeziehen. Im Endeffekt wurden die Daten im Rahmen der im Verlauf folgenden Analyse nicht verwendet, da die Beschleunigungswerte bereits aussagekräftige Ergebnisse geliefert haben. Die doppelte Aufzeichnung der Position resultiert aus Testläufen, wo nur NAV-HPPOSLLH-Nachrichten verwendet wurden. Dabei wurden leider zu oft Probleme bei der Positionsbestimmung verzeichnet, wodurch bei der finalen Messung die Attributwerte aus NMEA-GxGGA-Nachrichten mitaufgezeichnet wurden, um eine Absicherung bei kompletten Versagen der Positionsaufzeichnung mithilfe der NAV-HPPOSLLH-Nachrichten zu haben. Doch auch diese Positionsbestimmung verlief im Endeffekt nicht einwandfrei und stellte keine lückenlose Aufzeichnung dar. Mehr dazu im Abschnitt zu möglichen Fehlerquellen.

Empfangen wird jeweils eine der zuvor aufgelisteten Nachrichten mit den jeweiligen Attributwerten. Während ESF-RAW-Nachrichten in hoher Frequenz (alle 1/10 Sekunden) versendet werden, erfolgt die Aktualisierung der Positionsdaten nur einmal die Sekunde. So wird beim setzen von neuen Werten nur der jeweilige Wert aktualisiert, der auch empfangen wurde. Alte Attribute behalten ihren Wert, bis eine neue entsprechende Nachricht empfangen wurde und diesen ersetzt.

Abbildung 6: Statusmitteilungen des Python-Skriptes während der Ausführung in einem Linux-Terminal

Nach dem Start des Skriptes läuft die Aufzeichnung ununterbrochen als Schleife weiter, solange keine Fehler aufkommen. Sollte dies passieren, bricht das Skript und die Aufzeichnung ab. Zuvor aufgezeichnete Werte bleiben in der jeweiligen CSV-Datei erhalten. Die manuelle Unterbrechung der Schleife ist mithilfe der allgemein gültigen Tastenkombination zur Porgrammunterbrechung Strg + C möglich.

Datenerhebung

Rahmenbedingungen und Vorgehensweise:

Für die Datenerhebung wurden zunächst zwei Verfahren geprüft: Entweder wird eine feste Strecke mit den unterschiedlichen Baureihen oder drei unterschiedliche, möglichst kurvenarmen Strecken mit der darauf in Betrieb befindlichen Baureihe befahren. Da in Berlin nach dem Fahrplanwechsel im Dezember 2025 leider keine Strecke existiert, auf welcher alle Baureihen verkehren, wurde die zweite Methode gewählt

Mögliche Fehlerquellen

Grobe Fehler

  • Verbindungsprobleme zwischen Raspberry Pi und EVK-F9DR (z. B. lose USB-Verbindung)
  • Ausfall der Stromversorgung während der Messung
  • Softwareabsturz oder falsches Starten des Python-Codes

Systematische Fehler

  • Streckenvariabilität: Unterschiede in Gleisbeschaffenheit, Kurvenradien oder Weichen beeinflussen die Vibrationsdaten konstant auf bestimmten Streckenabschnitten
  • Fahrweise der Lokführer: Unterschiede im Beschleunigungs- oder Bremsverhalten zwischen einzelnen Baureihen oder Fahrten
  • GNSS-Signalstörungen: Tunnel, Unterführungen, Überdachungen verursachen systematisch reduzierte Positionsgenauigkeit oder Signalabbrüche

Zufällige Fehler

  • Umgebungsbedingte Vibrationen, z. B. Passagierbewegungen oder vorbeifahrende Züge
  • Kurzfristige Störungen in der Datenaufzeichnung (z. B. einzelne fehlerhafte Messpunkte)
  • Klimabedingte Einflüsse (z. B. Temperaturschwankungen zwischen Außen- und Innenbereichen)

Datenaufbereitung: Aufgezeichnete, vorverarbeitete Daten

Datenstruktur

Die erfassten Daten liegen in einer strukturierten Textdatei vor und enthalten pro Zeile folgende Mess-Informationen:

  • date: Datum der Messung (Sollte eine Messung über mehrere Stunden bzw. Tage gehen, so kann hiermit die zeitliche Einordnung besser stattfinden)

  • timestamp: Zeitstempel des Raspberry Pi OS

  • gps_timestamp: Umgewandelter GPS-Zeitstempel in UTC (Zur Kontrolle, ob Zeit stimmt und keine Verzögerungen entstehen)

  • lon: Längengrad der ermittelten GNSS-Position (EPSG:4326; WGS84 Ellipsoid)

  • lat: Breitengrad der ermittelten GNSS-Position (EPSG:4326; WGS84 Ellipsoid)

  • accuracy: Horizontale Genauigkeit der Positionsbestimmung

  • lon_nmea: Längengrad der ermittelten GNSS-Position mithilfe von NMEA-Standard-Nachrichten (EPSG:4326; WGS84 Ellipsoid)

  • lat_nmea: Breitengrad der ermittelten GNSS-Position mithilfe von NMEA-Standard-Nachrichten (EPSG:4326; WGS84 Ellipsoid)

  • hdop: Horizontale Verringerungen der Genauigkeit (Horizontal Dilution of Precision; beschreibt den Fehler, welcher durch die relative Position der GNSS-Satelliten entstehen kann; je niedriger der Wert, desto besser)

  • acc_x / acc_y / acc_z: Beschleunigungswerte in drei Raumachsen (m/s²)

  • gyro_x / gyro_y / gyro_z: Gyroskopwerte bzw. Winkelgeschwindigkeiten in drei Raumachsen (°/s)

Können Werte wie Längen- oder Breitengrad nicht ermittelt werden, werden diese als “None” oder leerer Wert gespeichert. Dementsprechend passt sich auch die Genauigkeitsspalte an (bspw. 99.99 Meter).

Analyse

Untertitel

Im Folgenden findet die Analyse der zuvor aufgezeichneten Messdaten statt.

Datenanalyse und Visualisierung

Datenaufbereitung: Analyse

Berechnung der Vibrationsstärke (RMS)

Zur Quantifizierung der Vibrationsbelastung während der S-Bahn-Fahrten wurden Beschleunigungsdaten in drei Achsen (acc_x, acc_y, acc_z) mit einer Abtastrate von ca. 5 Hz aufgezeichnet. Die Root Mean Square (RMS)-Beschleunigung wurde als standardisierte Größe berechnet, um die effektive Vibrationsenergie zu erfassen.

Schritt 1: Zeitliche Segmentierung Die unregelmäßig zeitgestempelten Messungen (HH:MM:SS.mmm) wurden in 1-Sekunden-Fenster unterteilt:

window_id = floor(as.numeric(hms::parse_hms(timestamp)))

Schritt 2: Vektor-RMS pro Fenster Für jedes Zeitfensterni mit Ni Messungen wurde der resultierende RMS-Wert berechnet:

\[ \text{RMS}_i = \sqrt{\frac{1}{N_i} \sum_{k=1}^{N_i} (a_{x_k}^2 + a_{y_k}^2 + a_{z_k}^2)} \]

Der RMS-Wert repräsentiert die Größenordnung des Ausschlags bezogen auf die Vibrationswerte in dem zuvor berechneten Sekundenfenster.

Bei den S-Bahn-Messungen würden sich Werte von 9-11 g ergeben, wobei der Großteil auf die Gravitationskomponente (≈9.81 m/s²) zurückzuführen ist. Um diesen Faktor auszugleichen, wurde die Graviationskomponente im Anschluss vom RMS abgezogen. Bei statischen Messungen ist es leichter diese Komponente aus den gewonnenen Messungen rauszurechnen. Die S-Bahn-Messungen bedeuten ein ständiges Beschleunigen, wobei sich die Gravitationskomponente auch auf die Achsen acc_x und acc_y auswirken. Eine vollständige und saubere Trennung der Gravitations- und Bewegungsanteile würde daher komplexere, weiterführende Berechnungen erfordern. Im Rahmen dieses Projekts wird jedoch auf eine solche detaillierte Analyse verzichtet und es bleibt bei der hier dargestellten vereinfachten Herausrechnung.

Räumliche Aufbereitung der Streckenmessung

Im folgenden Plot werden die Messdaten der sechs Streckenfahrten kompakt dargestellt, jeweils getrennt nach Baureihe und Richtung. Die einzelnen Fahrten sind dabei mit den entsprechenden Koordinaten pro Punktmessung abgebildet und nach dem Schema „Baureihe + f“ für die Hinfahrt sowie „Baureihe + b“ für die Rückfahrt benannt. So lassen sich qualitative Unterschiede zwischen den Streckenmessungen zwischen Hin- und Rückfahrten auf einen Blick vergleichen.

Interaktive Karte

Die folgende interaktive Karte zeigt die aufgezeichneten Messpunkte entlang der Strecke, wobei die Farbgebung Abweichungen von der normalen Beschleunigung darstellt: grüne Punkte entsprechen typischen Werten, während rote Punkte auf erhöhte Vibrationen hinweisen. Zusätzlich spiegeln die unterschiedlichen Punktgrößen die Stärke der gemessenen Vibration wider, sodass größere Punkte für stärkere Beschleunigungen stehen. Auf diese Weise lassen sich sowohl räumliche Muster als auch besonders auffällige Messwerte auf einen Blick erkennen.

Interpretation der Ergebnisse

Auswertung

Die Auswertung des Boxplots zeigt, dass sich die Vibrationsintensität der Baureihen BR 480, BR 481 (mod.) und BR 483/484 nur geringfügig unterscheidet. Die Medianwerte liegen bei allen nahe 0,16 m/s², sodass das typische Vibrationsniveau während der Fahrt vergleichbar ist. Auffällig ist der schmalere Kasten bei BR 483/484, der einen geringeren Interquartilsabstand signalisiert: Die mittleren 50% der Messwerte streuen hier weniger und sind homogener gebündelt, im Gegensatz zu den stärkeren Schwankungen bei BR 480 und BR 481 (mod.). Ausreißer oberhalb und unterhalb der Whisker treten bei allen Baureihen ähnlich häufig auf und erreichen vergleichbare Extremwerte – sie deuten auf punktuelle, streckenbedingte Ereignisse wie Gleisunebenheiten oder Weichen hin. Insgesamt ergeben sich moderate Unterschiede im Variationsgrad (konstanter bei BR 483/484), aber kein klarer Vorteil im durchschnittlichen Fahrkomfortniveau.​

Auswertung

Die Zeitreihen ergänzen den Boxplot und bestätigen das ähnliche Vibrationsniveau: Bei allen Baureihen schwanken die Vibrationswerte überwiegend zwischen -0,2 und 0,3 m/s², mit Spitzen über 0,5 m/s², die sich strecken- und situationsspezifisch über alle Fahrzeuge verteilen. Dies unterstreicht, dass starke Ausschläge primär durch Einflüsse wie Gleiszustand, Kurven oder Weichen entstehen, nicht durch den Fahrzeugtyp. Bei BR 483/484 wirken die Punktwolken im Zeitverlauf kompakter und gebündelter, was die geringere Streuung aus dem Boxplot plausibel macht; ältere Baureihen zeigen streuendere Verteilungen. Somit stützt die Darstellung das Gesamtbild: vergleichbares Niveau, aber tendenziell konstantere Vibrationen bei BR 483/484.

Diskussion

Bewertung der Messergebnisse

Die Messergebnisse zeigen ein sehr ähnliches Vibrationsniveau für alle drei Baureihen (BR 480, BR 481 (mod.), BR 483/484). Die Medianwerte der Vibration liegen dicht beieinander, sodass sich im Durchschnitt kein deutlicher Komfortvorteil einer Baureihe erkennen lässt. Die geringere Streuung bei BR 483/484 deutet jedoch auf ein homogeneres Vibrationsverhalten hin, was durch die kompakteren Punktwolken in der Zeitreihendarstellung bestätigt wird.

Vergleich mit Erwartungen / Theorie

Theoretisch wäre zu erwarten, dass modernere Fahrzeuge wie BR 483/484 durch optimierte Fahrwerke und Dämpfungselemente ein gleichmäßigeres Vibrationsverhalten aufweisen. Die Messungen stützen diese Annahme teilweise, da sich für BR 483/484 eine geringere Streuung zeigt, während das absolute Niveau vergleichbar bleibt.

Fazit

Zusammenfassung der Ergebnisse

Alle Baureihen weisen ein vergleichbares Vibrationsniveau auf, mit Vibrationswerten überwiegend zwischen -0,2 und 0,3 m/s². BR 483/484 zeigt eine geringere Streuung im mittleren Bereich, was auf homogenere Vibrationen hindeutet.

Beantwortung der Fragestellung

Die zentrale Fragestellung lässt sich wie folgt beantworten: Es zeigen sich moderate Unterschiede, mit konstanteren Vibrationen bei BR 483/484, während das durchschnittliche Niveau ähnlich bleibt. Starke Extremwerte sind ggf. streckenbedingt. Aufgrund begrenzter Messungen sind die Ergebnisse jedoch vorsichtig zu interpretieren und liefern nur erste Hinweise statt belastbarer Schlussfolgerungen.

Ausblick und Verbesserungsvorschläge

Weiterführende, über längere Abschnitte, unter unterschiedlichen Bedingungen oder nahezu gleichen Verhältnissen getätigte Messungen können die Qualität der Messungen verbesseren und weitere Ergebnisse liefern. Auch die Verbesserung des verwendeten Equipments, überlegte Planung der Messraumzeiten und ggf. weitere Verbesserungen an der Software können an den Ergebnissen zusätzliche Verbesserungen bringen.

Quellen

Abbildungsverzeichnis

Abbildung 1: Unsere Baureihe 480. BR 480[2026-01-26].

Abbildung 2: Unsere Baureihe 481. BR 481[2026-01-26].

Abbildung 3: Unsere neue S-Bahn. BR 483/484[2026-01-26].