Datenkommunikation zu Remotesternwarten

Einleitung

Unsere Hochschule OWL hatte von 2011 bis 1016 Gelegenheit, eine Remotesternwarte in den französischen Alpen zu betreiben. Das Hauptproblem im Betrieb war die Datenkommunikation zwischen dem Hochschulstandort in Lemgo und der Anlage in Moydans in den französischen Seealpen. Die Geräte am Remotestandort wurden über einen VPN-Server [1] mit dem Programm Remote Desktop (RDP [2]) betrieben. Die Erfahrungen und Probleme mit der Datenkommunikation sollen in diesem Beitrag näher erläutert werden.

Abb. 1: Standort der Remotesternwarte im den französischen Seealpen

Betriebserfahrungen

An "guten" Tagen war es eine Freude, mit der Anlage zu arbeiten. "Gute" Tage waren Tage, an denen die Kommunikation funktionierte. Dann konnte man unter perfektem Himmel schöne Astrofotos machen. Leider hatten wir in dem Vertrag mit dem Gastgeber keine Mindeststandards für die Kommunikation vereinbart. Da der Standort im Gebirge weitab von jeder Stadt gelegen ist, war die Datenkommunikation problematisch. Das 1. Problem war die technische Ausführung der Kommunikationsverbindung.

Technische Daten und Zuverlässigkeit der Verbindung

In den ersten 2 Jahren war die Leitung zum Remote-Standort stark wetterabhängig. Bei Regen war ein Betrieb nicht möglich, da es wohl Undichtigkeiten in der Isolierung der Leitung gab. Die anschließende Lösung mit einer Satellitenverbindung war stabil, der Delay (Antwortzeit) von 700 ms war für einen Remote-Desktop-Betrieb jedoch zu lang. Erst die Anbindung des Observatoriums über WiFi brachte einen einigermaßen zuverlässigen Betrieb.

Belegung der Verbindung

Ein weiteres Problem war die Mehrfachnutzung der Leitung durch andere Nutzer der Anlage. In diesem Betriebsfall stiegen die Antwortzeiten im RDP-Betrieb so stark an, dass ein Bildaufbau nach einem Mausklick ca. 1 min dauerte. Interaktiver Betrieb - wie Fokussieren - war dann nicht mehr möglich. Deshalb wurden später auch alle Webcams abgeschaltet, wenn sie für den Betrieb nicht unbeding benötigt wurden. Um stark interaktive Tätigkeiten zu vermeiden, haben wir gezwungenermaßen viele Aktionen weitgehend automatisiert (Fokussieren mit FocusMax und MaxIm DL, exaktes Ansteuern eines Objektes durch gute Pointing-Files in TheSky6, Aufnahme von Serien mit MaxIm DL). Ein vollständig automatisierter Betrieb mit einem Sternwartenprogramm wie ACP wäre auch möglich gewesen. Wir haben jedoch darauf verzichtet, da die hierzu notwendigen Tests sehr zeitaufwändig gewesen wären und wir den direkteren Kontakt zu den Geräten bevorzugt haben. Wir haben gelernt, dass in der Komplexität einer solchen Anlage ein erheblicher Unterschied zwischen einer direkten Steuerung der Geräte im Remote-Betrieb und einem vollautomatischem Betrieb besteht.

Die Kommunikation

Wir haben 6 Jahre lang alle 60 s Pings zum VPN-Server des Remote-Standortes geschickt. Pings sind Datenpakete, mit denen man überprüfen kann, ob ein Server erreichbar ist [3]. Der Server schickt die Datenpakete zurück. Die Antwortzeiten und der Verlust von Datenpaketen werden registriert. Ein geeignetes Programm ist z.B. Smokeping [4]. So konnten alle Betriebsfälle gut dokumentiert werden – gute Zeiten, schlechte Zeiten, Totalausfälle usw. Die folgenden Abbildungen zeigen die Antwortzeiten und Paketverluste auf der Strecke Lemgo - Moydans - Lemgo über der Zeit. Wichtig für einen Remote-Betrieb sind kleine Antwortzeiten < 400 ms und Paketverluste von < 10%. Zusätzlich sollte die Datenrate mindestens 4 Mbit/s betragen, um eine flüssige Bedienung von Windows zu ermöglichen.

Die Messungen

Abb. 2 zeigt eine gute Phase des Betriebs. Die mittleren Antwortzeiten liegen hier bei 68 ms, die Paketverluste betragen 0 % bis 10 %. Die Änderungen der Antwortzeiten ergeben sich aus den unterschiedlichen Wegen, die die Pakete im Netz zurücklegen. Der Betrieb ist hier so flüssig, als wenn man direkt an seinem Rechner sitzt.

 

Abb. 2: Paketlaufzeiten bei guten Übertragungsbedingungen

Abb. 3 zeigt in der Mitte des Diagramms Störungen des Betriebs durch zu viel Verkehr auf der Leitung durch andere Nutzer, die vermutlich ihre Bilder runterladen. Mittlere Antwortzeiten von 500 ms bis 600 ms machen die Bedienung der Remote-Rechner zu einem Geduldsspiel: die Reaktionszeiten nach einem Mausklick betragen in diesem Betriebsfall mehr als 1 min, ein erneuter Bildaufbau gelingt nicht mehr und der RDP-Betrieb bricht manchmal ab und muss neu aufgebaut werden.

Abb: 3: Paketlaufzeiten bei gestörter Leitung

Abb. 4 zeigt die konstanten aber zu langen Antwortzeiten bei Satellitenbetrieb. 240 ms beträgt hier alleine die Übertragungszeit zwischen Erde und Satellit. Hinzu kommen die Zeiten für die Übertragung der Datenpakete im Leitungsnetz zu den Erde-Funkstellen. Ein Remote-Betrieb war so ebenfalls nicht möglich. Ob andere Verfahren als RDP toleranter gegenüber langen Antwortzeiten sind, konnten wir nicht testen.

Abb. 4: Paketlaufzeiten bei Satellitenbetrieb

Allgemeine Hinweise für einen erfolgreichen Remote-Betrieb

Für einen erfolgreichen und stressfreien Remotebetrieb sollte man folgenden Punkten besondere Aufmerksamkeit widmen:

- ausgiebiger Test der geplanten Internetverbindung vor der Entscheidung für einen Standort, Regelung von Qualitätsstandards in einem Vertrag

- sich einer Person vor Ort versichern, die fachkundig kleinere Wartungs- und Reparaturarbeiten durchführen kann

- ausgiebiger Test der Anlage vor dem Transport über eine Zeit von mindestens 6 Monaten

- vermeiden von USB-Verbindern, viele Verbindungen laufen heute über RJ45- Verbinder und Netzwerk-Kabel, die deutlich zuverlässiger sind

- Ersatzteile und Werkzeug vor Ort lagern

- ausführliche Dokumentation über Hardware, Software, Wartungen usw. anlegen

- mindestens eine Wartungsreise pro Jahr einplanen

Resumee

Wir haben in den 6 Jahren sehr viel über die Planung und den Betrieb von Remote-Sternwarten, die Datenkommunikation und die Automatisierung von Abläufen gelernt.

Ein solches Projekt ist sehr Technik-orientiert. Um Erfolg zu haben, sollte man auf allen angesprochenen Gebieten solide Grundkenntnisse haben.

Der vollständige Artikel findet sich im VdS-Journal 1/2017 (Nr. 60) , das leider nur in gedruckter Form vorliegt

 

Quellenangaben

(alle aus März 2017)

[1] de.wikipedia.org/wiki/Virtual_Private_Network

[2] de.wikipedia.org/wiki/Remote_Desktop_Protocol

[3] de.wikipedia.org/wiki/Ping_(Datenübertragung)

[4] www.heise.de/download/product/smokeping-56266

 

2 Gedanken zu „Datenkommunikation zu Remotesternwarten

  1. Dark Sky Friend

    Sehr interessanter Artikel, Herr Berlemann, doch bleiben noch ein paar Dinge unklar:

    1. Wie stellt man sich denn vor, dass Sie "Windows flüssig bedienen"?

    2. Was ist denn für den Betrieb einer solchen Anlage der Unterschied von "schlechten Zeiten" zu "Totalausfall"? Schlechte Zeiten - schlechte Kommunikation? Totalausfall - gar keine Kommunikation? Wie viele Totalausfälle hat es denn gegeben?

    3. Wenn man mal das Szenario des Totalausfalls nimmt, also keine Kommunikation, wie geht es denn dann weiter - ohne Kommunikation? Gibt es nach dem Totalausfall einen kommunikationslosen Betrieb oder ganz neue technische Methoden, die hier nicht beschrieben wurden? Das ist ja gerade das, was mich interessiert.

    Astronomisch technische Grüße
    Ihr Dark Sky Friend

    Antworten
  2. Jochem Berlemann

    Hallo Dark Sky Friend,

    1. Windows flüssig bedienen heißt, dass man wie gewohnt auf einen Mausklick innerhalb von < 1-2 s eine Reaktion bekommt.

    2. In schlechten Zeiten bekommt man innerhalb von 5 - 30 s eine Reaktion
    ( eine Aktion oder einen neuen Bildaufbau) auf seinen Mausklick. Das behindert besonders interaktive Tätigkeiten wie die Fokussierung oder die Feinausrichtung des Teleskops auf ein Zielobjekt. Das kann dann schon mal 30 min dauern. Bei Totalausfall der Kommunikation kann man die Anlage nicht mehr kontrollieren. Wenn der Totalausfall im Betrieb auftritt, konnte man nur noch in Frankreich anrufen, um die Anlage abschalten zu lassen. Totalausfälle dauerten zwischen einigen Minuten und mehreren Tagen, je nach Ursache.

    3. Man kann den Remotebetrieb auch mit einem Script vollständig automatisieren. Dieses leisten Programme wie z.B. ACP. Man programmiert eine ganze Session (anfahren des Objektes mit der Montierung, fokussieren, Autoguider in Betrieb nehmen und auf einen Leitstern synchronisieren, Aufnahmesequenz starten, Bilder auf einem Server abspeichern) und bittet den Betreiber vor Ort, die Session zu starten. Danach holt man sich die Bilder per FTP. Hierzu braucht man nicht den direkten Link zu den Geräten. Leider kann man bei dieser Betriebsart nicht eingreifen, so dass bei Problemen wie durchziehenden Wolken oder schlechtem Seeing die Aufnahmen nichts werden, die Erfolgsrate ist nicht so hoch.
    Da die Vorbereitungen für einen solchen Scriptbetrieb sehr zeitaufwändig sind, wird diese Betriebsart vorwiegend von Sternwarten angewendet, die mit dem Betrieb Geld verdienen wollen, indem sie Teleskopzeit vermieten. Der Anwender braucht dann auch keine technischen Kenntnisse zum Betrieb der Anlage. Wir haben auf den Scriptbetrieb verzichtet.

    Ich hoffe,dass die meisten Ihrer Fragen hiermit beantwortet sind.

    Freundliche Grüße
    Jochem Berlemann

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.