Wettermesspunkt Berlin Friedrichshain

Wetterstation Richard-Sorge Straße

Beschreibung des technischen Stacks

Damit Sie zuverlässig aktuelle Wettermesswerte erhalten können, ist hinter den Kulissen ein gewisser Aufwand erforderlich. Dieser bezieht sich zum einen auf die Messung selbst, die so präzise wie möglich sein soll, andererseits aber auch auf die Verarbeitung und Speicherung der Messdaten. Diese müssen betriebstechnisch erfasst, gespeichert und mathematisch aufbereitet werden. Zu guter Letzt müssen Sie im Web dargestellt werden, was Server und Webtechnologien erfordert. Im Folgenden zeige ich Ihnen, wie die technischen Einrichtungen hinter der Wetterstation Berlin Friedrichshain aussehen und wie sie arbeiten.

Technischer Stack der Wetterstation
1. Ansicht des Sensorfeldes der Wetterstation aus Dachperspektive im Winter.

Generell funktioniert die Wetterstation so, dass über mehrere Wettermessgeräte (Sensorköpfe) das aktuelle Wetter gemessen wird. Hierzu fragt ein Raspberry Pi Mikrocomputer alle 20 Sekunden die Messwerte von 2 elektronischen Messköpfen ab und vergleicht diese miteinander. Hierbei kommen zum Einsatz ein UMB 800 Sensor der Firma LUFFT (Hauptsensor, kalibriert) und ein automatischer Wettermesskopf der Firma Thies (Referenzmesskopf). Beide Sensoren werden per Linux-Cronjobs seriell über eine spezielle Schnittstelle angefragt und senden dann alle Messwerte in je einem Telegramm. Diese etwa 25-30 Messwerte werden von beiden Sensoren vom Raspberry Pi empfangen und gegeneinander auf Plausibilität geprüft. Liegen die Messwerte gegeneinander in einem gewissen, akzeptablen Toleranzband, gibt der Rechner die Werte frei. Weiterhin werden noch die Daten einer DAVIS Wetterstation erfasst, diese fließen aber mangels Genauigkeit nicht in die Messreihe ein; sie dienen aber der Überprüfung der Plausibilität. Die folgende Abbildung zeigt das Gesamtsystem schematisch übersichtlich dargestellt.

Gesamtaufbau des Systems
2. Übersicht des technischen Aufbaus des Gesamtsystems.

Zu sehen ist weiterhin, dass für die Messung auch eine hochpräzise Zeitquelle erforderlich ist. Diese dient einerseits der Vergabe von präzisen Zeitstempeln für jeden einzelnen Messwert ("wann wurde dieser Messwert erfasst?"), andererseits dient die hochgenaue Referenzfrequenz auch der Unterstützung der Radarmessung für die Tropfengröße des Niederschlages.

Das Data Aquisition Module
Data Aquisition Module
3. Ansicht des Data Aquisition Modules. Es fragt alle Sensorköpfe alle 20 Sekunden ab und prüft das Ergebnis auf Plausibilität.

Das Data Aquisition Module besteht aus zwei Netzgeräten zur Erzeugung der 24-Volt Betriebsspannung für die Sensorköpfe sowie die Heizungen von Regen- und Windsensoren. Ein serielles Kommunikationsmodul bildet die Schnittstelle zwischen Raspberry Pi Mikrocontroller und den Sensorköpfen. Außerdem erfolgt noch eine Wandlung von RS-232 auf TTL. Nach der Plausibilitätsprüfung der Messwerte erzeugt der Raspberry Pi Computer mittels Python einen Sendestring mit den Messwerten und schickt diesen an zwei Destinationen: einmal an ein Empfangsscript im Rechenzentrum und einmal an einen lokalen Linux-Rechner mit Influx DB Server. In der Influx Datenbank werden die Daten dauerhaft "unendlich lange" gespeichert und archiviert, wohingegen die Maria DB im Rechenzentrum nur der Darstellung der Daten im Web dient - aus Gründen der Geschwindigkeit beim Laden der Website werden diese Daten automatisch nach 365 Tagen gelöscht.

Data Aquisition Module
4. Gesamtansicht des Data Aquisition Modules von außen. Eine USV sichert den dauerhaften Betrieb, 24 Stunden am Tag, 365 Tage im Jahr, für eine Messung alle 20 Sekunden.
Zeitserver und Antennenanlage

Die gesamte Anlage benötigt hochgenaue Zeitinformationen. Zum einen müssen Messungen auf der Zeitskala eindeutig zugeordnet werden können, was insbesondere bei den Umstellungen von Sommer- auf Winterzeit oder bei dem Einfügen von Schaltsekunden wichtig ist. Zum anderen müssen alle beteiligten Rechner untereinander genau synchron laufen, damit übergebene Messdaten-Pakete nicht unterschiedlich interpretiert werden können. Um die Anforderung einer genauen Zeitbasis erfüllen zu können, werden zwei Zeitserver mit Antennenanlage betrieben, welche die Zeit aus zwei unterschiedlichen Quellen beziehen und per NTP hochgenau im Netz bereitstellen.

Data Aquisition Module
5. Ansicht des Zeitserver-Setups. Oben: M300 Zeitserver für DCF77 und unten: Meinberg MicroSync Zeitserver für GPS-Empfang. Mit den Systemen ist eine mittlere Abweichung von UTC im Bereich um 25 Milliardstel Sekunden möglich.
Data Aquisition Module
5.1. Ansicht Zeitserver Frontpanel. Die Anzeige der Zeit sowie die blaue LED zur Visualisierung der Sekundenmarken dienen der Überwachung der Anlage auf korrekte Funktionalität.

Bild Nr. 5 zeigt das Setup der Zeitserver für die Anlage. Die beiden Systeme liefern jeweils ein NTP (Network Time Protocol) Telegramm aus, basierend auf zwei unterschiedlichen Disziplinierungsquellen. Während das Meinberg MicroSync System (unten) GPS als Zeitquelle nutzt, referenziert sich der M300 (oben) mit dem Zeitzeichensender DCF-77 der Physikalisch-Technischen Bundesanstalt PTB in Mainflingen bei Frankfurt am Main. Beide Zeitbasen werden fortlaufend miteinander verglichen und auch gegenüber mehreren Internet-Zeitdiensten gespiegelt. Die lokal erreichbare Genauigkeit der Zeitinformation ist hierbei um Größenordnungen besser als jeder Internetdienst: im Mittel weicht die lokale Zeitskala nur um 25 ns (das sind Milliardstel Sekunden!) gegenüber der wahren UTC-Skala ab. Die geringste, jemals erreichte Abweichung von UTC betrug mit 2 ns nur unfassbare 2 Milliardstel Sekunden. Die lokalen Zeitskalen werden laufend gegeneinander bewertet und mittels Linux-Software (chrony) erfolgt automatisch die Auswahl der genauesten Zeitreferenz.

Data Aquisition Module
6. Ansicht der Antennenanlage. Zu erkennen sind die spitz zulaufenden GPS-Antennen zum Empfang des GPS-Zeitsignals, sowie die längliche horizontale Antenne zum Empfang des DCF-77-Signals des Zeitzeichensenders der PTB. Diese Antenne ist auf den Sendeort Mainflingen bei Frankfurt am Main ausgerichtet.
Linux-Server, Influx DB und Backups

Die erfassten Messdaten werden einerseits über ein Sendetelegramm alle 20 Sekunden auf einen Webserver im Rechenzentrum gesendet, von wo aus die Aufbereitung für diese Website erfolgt, andererseits werden alle Daten auch lokal im Netz auf Linux-Servern gespeichert. Dies erfolgt mit Influx DB, da eine große Menge an Daten zu archivieren ist: 30 Messpunkte alle 20 Sekunden, 365 Tage im Jahr, 24 Stunden am Tag. Dies resultiert in einer Gesamtzahl von rund 1,57 Millionen Messpunkten pro Jahr. Diese müssen nicht nur sauber gespeichert und archiviert werden, sondern auch visualisiert werden und vor allem: einer Backup-Strategie unterliegen. All dies erfolgt auf einem lokalen Linux-Server (Lenovo ThinkCentre) mit Ubuntu Server. Auf der Maschine läuft unter anderem ein Influx DB Server sowie eine Grafana-Instanz. Das Backup erfolgt vollautomatisch unter Linux alle 2 Stunden auf einen Cloud-Server.

Data Aquisition Module
7. Ansicht des lokalen Server-Setups. Das Lenovo ThinkCentre führt Ubuntu Server aus und kümmert sich um Langzeit-Archivierung, Visualisierung und Backups.
Data Aquisition Module
8. Ansicht des Linux-Servers vor dem Deployment.

Backups sind gut, müssen aber streng überwacht werden. Aus diesem Grund ist ein Heartbeat-Server aufgesetzt, der in einem Rechenzentrum die korrekt erfolgten Backups checkt: auf der lokalen Linux-Maschine wird das Backup-Script automatisch alle 2 Stunden ausgeführt. Sobald die Daten gesammelt, komprimiert und verschlüsselt wurden, sendet sie der Backup-Server an einen Cloud-Dienst im Internet (EU). Nur wenn dieser Upload erfolgreich war, meldet er dies dem Heartbeat-Server. Dieser Server erwartet alle 2 Stunden (mit einer Toleranz von 20 Minuten) die Meldung des Backup-Servers. Unterbleibt diese, so ist das letzte Backup nicht ordnungsgemäß erfolgt und der Heartbeat-Server sendet eine Email an mich.

Data Aquisition Module
9. Beispielhafte Ansicht der Heartbeat-Liste von erfolgreich abgeschlossenen Updates auf dem Server. Man erkennt gut die Frequenz der gefahrenen Updates: sie erfolgen alle 2 Stunden.

Wie Sie sehen, ist doch ein nicht zu unterschätzender Aufwand notwendig, um die Wetterdaten kontinuierlich alle 20 Sekunden zu erfassen, zu speichern und zu visualisieren. Ich hoffe, dass Sie genau so viel Freude an meinem Projekt haben wie ich, als ich es realisierte und bis heute pflege. Vielleicht ist es sogar ein wenig nützlich für Sie. Liebe Grüße, H. Vitzthum.

Zurück zu Messwerten