Exitus mit Ansage
BLOG: Go for Launch
Der Bericht zur Analyse des Versagens des japanischen Satelliten Astro-H (Beiname: “Hitomi”, japanisch für “Pupille”) liest sich ähnlich wie mancher Flugzeug-Unfallbericht. Eigentlich ist die Technik in dieser Domäne mittlerweile so ausgereift, dass es nicht einfach so passiert, dass eine Sache nicht funktioniert und dadurch gleich das Gesamtsystem ausfällt. Wahrscheinlicher ist eine Kette von Fehlern und Problemen, von denen einige schon in der Entwurfsphase gemacht wurden, andere erst im Betrieb, von denen einige vollkommen unerwartet auftreten, andere schon vorhergesehen, aber für unwahrscheinlich gehalten wurden.
Dass der Ausfall eines ganzen Satelliten von vorneherein unausweichlich ist, passiert ebenso wie bei Flugzeugabstürzen eher selten. Normalerweise ist bekannt, was schiefgehen kann, und mehrfache Redundanz wichtiger Komponenten verhindert effektiv, dass es überhaupt erst kritisch wird. Wenn es aber doch kracht, ist die spätere Analyse des Hergangs in der Regel voll von Aussagen wie “An dieser Stelle wäre eine Wiederherstellung des sicheren Betriebs möglich gewesen, wenn nur …”. Oft wundert man sich, wenn man liest, was für eine Offensichtlichkeit auf das “wenn nur …” folgt und dann die Begründung, warum es nicht so kam.
Der Fall von Astro-H / Hitomi ist schon außergewöhnlich. Allerdings muss man bei der Bewertung eines beachten: Wir schauen jetzt auf die Ereignisse zurück und haben Informationen, die bei Planung und Bau der Sonde nicht unbedingt verfügbar waren,
Astro-H / Hitomi war ein orbitales Röntgenteleskop mit einer Masse von 2.7 Tonnen. Es wurde am 17. Februar 2016 mit einer H-IIA-Rakete von Tanegashima aus in eine leicht exzentrische Bahn mit einer Neigung von 31 Grad und einer großen Halbachse von 6949 km gestartet. Nach der Kommissionierungsphase, bei der die Systeme in Betrieb genommen wurden, begannen im März erste Testbeobachtungen, die aber auch noch Teil der Inbetriebnahmephase waren. Der wirkliche operationelle Betrieb hätte erst nach Abschluss der Kalibrationsphase etwa im Juni stattfinden sollen. Man kann jetzt nicht wirklich sagen, dass die Inbetriebnahme unrealistisch kurz geplant war.
Keine 6 Wochen später war ASTRO-H / Hitomi nur noch Schrott.
Das Problem, in dessen Folge der Satellit verloren ging, trat am 25. März um 18:01 UTC auf. Da sollte das Teleskop vom Krebsnebel im Sternbild Stier zum AGN Markarian 205 im Drachen geschwenkt werden. Dazu muss der gesamte Satellit geschwenkt werden. Dabei ist es erforderlich, dass die Lageregelung an Bord zu jedem Zeitpunkt die aktuelle Ausrichtung im Raum in allen drei Komponenten, ebenso wie die aktuellen Änderungsraten jeder dieser Komponenten kennt.
Ich muss jetzt erst einmal etwas ausholen. Vorsicht: es wird technisch!
Das System, das mit der Berechnung der Lageinformation betraut ist, ist die inertiale Plattform. An Bord von Astro-H / Hitomi hieß dieses System IRU (Inertial Reference Unit). Die generelle Funktionsweise dieses Systems ist bei allen Satelliten und Raumsonden im Wesentlichen gleich, aber die individuelle Ausführung unterscheidet sich je nach Satellit, wobei es mal mehr, mal weniger gelungene Implementationen gibt.
Die IRU ist ein Rechnersystem, das Eingaben von verschiedene Quellen bezieht: Gyroskopen, Sternsensoren und Sonnensensoren. Die Messdaten dieser Quellen sind voneinander unabhängig und komplementär. Wie alle Messgeräte unterliegt auch jeder dieser Sensoren Messfehlern.
Einige Fehler sind stochastisch – man misst viele Male dieselbe Größe und bekommt jedes Mal ein (leicht) unterschiedliches Ergebnis. Wenn man alle Messungen statistisch analysiert, sieht man eine Normalverteilung mit einer deutlichen Ballung um den Mittelwert.
Einige Fehler sind systematisch. Da misst man viele Male dieselbe Größe und bekommt eine Anzahl Ergebnisse, deren Mittelwert um einen gewissen Betrag vom richtigen Wert verschoben ist, was man aber nur merkt, wenn man den richtigen Wert kennt. Systematische Messfehler kann man durch geeignetes Kalibrieren minimieren, aber kaum eliminieren, weswegen es wichtig ist, voneinander unabhängige Datenquellen zu haben.
Sensoren können auch vollkommen ausfallen und gar keine oder unsinnige Werte liefern. Sonnensensoren funktionieren logischerweise nicht, wenn sie so montiert werden, dass sie die Sonne nicht sehen. Oder aber, ein anderes Bauteil spiegelt Sonnenlicht direkt in den Sonnensensor, der dann annimmt, die Sonne sei dort, von wo das gespiegelte Licht kam. Sternsensoren brauchen eine gewisse Anzahl genügend heller Sterne. Wenn die Seite, auf der sie montiert sind, zur Erde zeigt, sehen sie aber keine Sterne. Sternsensoren werden oft durch kosmische Strahlung irregeleitet. Diese erzeugt auf dem CCD-Sensor elektrische Impulse, die mit Sternen verwechselt werden können.
Je nach Situation sind also die Daten einzelner Sensoren mehr, weniger oder gar nichts wert; sie müssen stärker oder schwächer gewichtet oder ganz ignoriert werden. Alles schon mal gar nicht so einfach.
Im Rechner der IRU werden die Messdaten zusammen gefasst. Die Lage eines Satelliten ist direkt nicht zu messen. Man kann aber eine Anfangsschätzung der Orientierung seiner drei Hauptachsen in einem iterativen Prozess so lange verfeinern, bis die daraus zurückgerechneten Werte dessen, was die Sensoren eigentlich messen müssten, wenn dies wirklich die inertiale Ausrichtung wäre, möglichst genau zu den gewichteten Messwerten passen. Eines der mathematischen Verfahren, das hierbei zum Einsatz kommt, ist der Kalmanfilter.
Nun ist das mit iterativen Prozessen ja immer so eine Sache. Sie müssen konvergieren; sie bewegen sich stückweise auf die richtige Lösung zu. Diese Konvergenz kann man durch Steuerparameter beeinflussen. Man kann versuchen, sie zu beschleunigen, auf die Gefahr hin, dass der Prozess weit über das Ziel hinaus schießt und die richtige Lösung vielleicht gar nicht findet. Man kann den Prozess abbremsen, indem nur sehr geringe Schrittweiten zugelassen werden. Dann aber hinkt die Lageberechnung womöglich der tatsächlichen Lagedynamik der Raumsonde hinterher. Generell kann jeder iterative Prozess auch in einer mathematischen Sackgasse, einem lokalen Minimum hängen bleiben. Also auch nicht gar so einfach.
Die IRU hat nicht nur zur Aufgabe, Messdaten aufzunehmen und daraus die inertiale Ausrichtung zu berechnen. Sie stellt auch die Basis für die Berechnung der Steuerbefehle an die Aktuatoren dar, wenn der Satellit seine Lage autonom ändern muss.
Solche Aktuatoren können Schwungräder sein: große, schwere Scheiben, die von einem Elektromotor in Rotation versetzt werden. Hat man drei davon, deren Rotationsachse jeweils senkrecht zu der der beiden anderen steht, kann der Satellit allein schon dadurch gedreht werden, dass man die Elektromotoren oder Bremsen jedes Schwungrads steuert.
Eine andere Art der Aktuatoren sind Lageregelungstriebwerke: Kleine Raketenmotoren, in denen aus einer Düse Gas ausgestoßen wird. Über das Rückstoßprinzip wird eine Kraft ausgeübt, diese wird zu einem Drehmoment, wenn die Schubrichtung nicht durch den Massenmittelpunkt geht. Will man einen Satelliten drehen, ohne die Schwungräder zu benutzen, lässt man erst das Triebwerk auf der einen Seite kurz pupsen, um die Rotation in Gang zu setzen und dann, wenn die Drehung erfolgte, das Gegenstück auf der anderen Seite ebenso lang pupsen zu lassen, um die Rotation wieder anzuhalten.
Das aber kann nur funktionieren, wenn das Lageregelungssystem genau weiß, wie die Massenverteilung des Satelliten aussieht. Darüber gibt der Trägheitstensor Auskunft. Das System muss auch wissen, wie die Triebwerke angeordnet sind und in welche Richtung sie feuern. Das alles sind Konfigurationsdaten, die einfach stimmen müssen, sonst kann das Lageregelungssystem nicht funktionieren.
Falls alle Stricke reißen, gibt es als letzte Rettung immer noch den “Safe Mode”. Dieser ist ein Notfallmodus, der sicherstellen soll, dass die Sonde sich in Richtung Sonne orientiert und typischerweise um die Richtung zur Sonne hin rotiert, damit einerseits die Solargeneratoren Sonnenlicht bekommen und die elektrischen Bordsysteme Saft haben, andererseits aber kein Bauteil überhitzt oder unterkühlt wird. Die Einleitung des Safe Mode und die Manöver dorthin sollte man einem besonders zuverlässigen Untersystem übertragen, das auch dann noch funktioniert, wenn der Rest des Lageregelungssystems bereits kapituliert hat. Gelungene “Safe Mode”-Implementationen haben bereits viele Satellitenmissionen gerettet. Ist der Satellit erst einmal im “Safe Mode”, ist die akute Gefahr gebannt. Dann gewinnt das Kontrollzentrum Zeit, um das Problem zu analysieren und einen geeigneten Rettungsplan umzusetzen. So etwas geht nun einmal nicht unter Zeitdruck.
Hier endet die heutige Vorlesung “Lageregelung von Raumfahrzeugen” auf “Go for Launch” und es geht zurück zu ASTRO-H / Hitomi.
Also. Das Unheil nimmt am 25. März um 18:01 UTC seinen Lauf. Der Satellit soll einen großen Schwenk absolvieren. In der IRU ist ein Kalmanfilter implementiert, um aus den Sensordaten in Nah-Echtzeit die aktuelle Ausrichtung des Satelliten zu berechnen. Der Kalmanfilter ist so eingestellt, dass er schnell konvergiert, was das höhere Risiko birgt, die falsche Lösung zu finden. Genau das passiert. Laut der von dem Rechner in der IRU gefundenen Lösung ist der Satellit in einer anderen Lage angekommen als geplant. Das aber ist noch nicht einmal das größte Problem. Die IRU ist dazu auch noch fälschlich der Meinung, der Satellit drehe sich mit einer Rate von 21.7 Grad pro Stunde, obwohl seine Lage in Wirklichkeit stabil ist.
Dass der Kalmanfilter auf den falschen Wert konvergiert, ist für sich genommen noch nicht kritisch. Das würde die IRU normalerweise aufgrund der Messdaten der Sternsensoren (“Star tracker”) merken. Hier aber schaut der Sternsensor gerade auf ein zu sternarmes Gebiet. Man hätte seine Sensibilität erhöhen müssen, damit er auch schwächere Sterne detektiert, Ein empfindlich eingestellter Sternsensor neigt aber zu Ausfällen aufgrund von Falschmessungen. Er fängt an, Sterne zu sehen, wo keine sind, sondern eben nur Streulicht oder kosmische Strahlung. Deswegen hat man ihn auf unempfindlich gestellt und er macht dicht.
Also keine Sternsensoren, sondern nur die (falsche) Lösung der IRU.
Was ist mit dem zweiten Sternsensor? Natürlich ist so ein wichtiges Bauteil redundant ausgelegt. Das Lageregelungssystem von ASTRO-H / Hitomi ist aber nicht dafür programmiert, bei einem Problem mit einem Sternsensor auf den zweiten umzuschalten. Es muss ihm per Telekommando von der Erde aus gesagt werden, welchen Sternsensor es nehmen soll. Bei Ausfall des Sternsensors verlässt es sich auf die IRU-Ausgabe. Diese Daten waren aber falsch.
ASTRO-H / Hitomi wäre in dieser Situation noch zu retten gewesen. Während drei Kommunikationsphasen mit Bodenstationen wurde der Bordstatus in der Telemetrie zur Erde geschickt und im Kontrollzentrum empfangen. Daraus ergab sich eindeutig eine Anomalie in der Lageregelung. Jetzt hätten die Bediener reagieren müssen, schlimmstenfalls durch Auslösen des “Safe Mode”. Das geschah aber nicht – wohl auch, weil man im Kontrollzentrum meinte, sich darauf verlassen zu können, dass die Raumsonde den “Safe Mode” auch selbständig einnehmen könne. Eine durchaus gerechtfertigte Annahme. Wozu hat man denn sonst Safe Modes?
Das Problem lag schon tiefer. Das Problem mit den Sternsensoren war bekannt. Deswegen hatte man sie auf unempfindlich gestellt. Aber das ist ja keine Art, das Problem zu lösen, sondern es führt nur dazu, dass die Sternsensoren gerade dann nicht verfügbar sind, wenn die Sonde sie dringend braucht. Besser wäre es gewesen, in einer ausführlichen Testserie die Sternsensoren langsam empfindlicher zu regeln, bis man den noch akzeptablen Kompromiss zwischen Verfügbarkeit und Ausfallsicherheit gefunden hatte. Bis zum Abschluss dieser Tests hätte man aber tunlichst alle größeren Lagemanöver unterlassen sollen. Hier wurde also schon ein erhebliches Risiko eingegangen.
Dann gibt es ja auch noch Sonnensensoren. Deren Messdaten zur Ausrichtung sind zwar deutlich weniger genau als die von Sternsensoren. Aber wirklich grobe Lageabweichungen kann man damit allemal messen und zur Sonne drehen kann man damit auch noch. Auf ein, zwei Grad Genauigkeit kommt es bei einem “Safe Mode” nicht an. Die Bedienermannschaft in Japan hatte im Lageregelungssystem die Sonnensensoren aber abgestellt. Sie hatten ein zu geringes Sichtfeld (was ich auf Anhieb nicht nachvollziehen kann) und man befürchtete fälschlich ausgelöste “Safe Modes”, die zu Zeitverlust führen würden.
Ohne Sonnensensoren ist es aber nicht möglich, das ganze System einzunorden, indem sich der Satellit nur aufgrund der Sonnensensoren in eine definierte Richtung zur Sonne dreht und der Konvergenzprozess der IRU neu beginnt. Das heißt, ohne Sonnensensoren ist ein wesentlicher Rettungsanker einfach weggebrochen.
Alles hängt nur noch an der IRU – die wird damit zu einem “Single Point of Failure”. Alles hängt an ihr. Aber wie wir wissen, funktionierte sie in der gegebenen Situation nicht.
Und nun ging es los. Die IRU zeigt an: Der Satellit rotiert. Das stimmt nicht, aber Schwungräder werden hochgefahren, um die vermeintliche Rotation des Satelliten zu stoppen. Dadurch wird in einem Teufelskreis die Ausgabe der IRU immer falscher, was die Schwungrädern wiederum zu kompensieren versuchen … und so weiter. Das Resultat ist, dass der Satellit, der anfangs die korrekte, stabile Ausrichtung hatte, nun um seine Längsachse rotiert, der Fehler in der Ausrichtung zunimmt und eines oder mehrere Schwungräder an ihrer Drehzahlgrenze ankommen.
Man kann Schwungräder nicht einfach abbremsen. Der Drehimpulserhaltungssatz sagt aus, dass ein Drehimpuls nicht einfach verschwindet. Wenn Schwungräder langsamer rotieren, rotiert dafür etwas anderes schneller, in diesem Fall der Satellit. Es gibt eine magnetische Vorrichtung, mit der ein Teil der Rotationsenergie hätte dissipiert werden sollen. Aber der Satellit rotiert mittlerweile zu schnell dafür.
Letzte Rettung: Der “Thruster Safe Hold Mode” bei Nutzung der Lageregelungstriebwerke unter direkter Nutzung der Sonnensensoren. Dieser Modus umging offenbar die nicht richtig funktionierende IRU. Allerdings braucht der Modus zwingend einen korrekten Trägheitstensor, also die Matrix von Daten, die die Masseverteilung beschreibt. Der an Bord geladene Trägheitstensor war allerdings offenbar falsch. Dies deswegen, weil der Satellit einen ausfahrbaren, 6.3 Meter langen Instrumententräger aufweist. Dieser wurde erst während der ersten Wochen der Mission ausgefahren. Dabei änderte sich natürlich die Masseverteilung erheblich. Dann muss ein neuer Tensor hochgeladen werden. Tut man das nicht, ist es unmöglich, Lageregelungsmanöver mit den Triebwerken durchzuführen. Wenn dann die Triebwerke feuern, macht die Sonde schon irgendwas. Aber nicht unbedingt das, was man erwartet. Vielleicht das genaue Gegenteil.
Das Update des Trägheitstensors ist an und für sich nichts Außergewöhnliches. Man hat das bei vielen Raumfahrzeugen.
Aber bei ASTRO-H / Hitomi ging dieses Update der Konfigurationsdaten in die Hose. Das kommt vor. Wo Menschen an einem Computer Daten eingeben, können Fehler auftreten. Offenbar wurde aber der neue Tensor nicht im Simulator oder mit kleinen Testmanövern am Satelliten getestet, bevor er operationell ging, sodass die fehlerhaften Werte nicht auffielen. Den Grund hierfür habe ich nicht wirklich verstanden. Er ist auf den Seiten 62 ff des Untersuchungsberichts der JAXA.
Konsequenz dieses letzten Fehlers war eine ungewollte, massive Erhöhung der Rotationsgeschwindigkeit durch die Lageregelungstriebwerke. Am Ende der Pannenkette, Stunden nach der ersten Manifestation des Problems und nach vielen versäumten Chancen zur Rettung, war die erreichte Drehrate und damit die Fliehkraft so hoch, dass Solargeneratoren und Instrumententräger den Abgang machten. Anstelle eines funktionierenden Satelliten hatte man nun einen Haufen orbitaler Trümmer.
Keiner der offenbar gemachten Fehler, keine der Fehleinschätzungen ist für sich genommen außergewöhnlich. Manche sind trivial, manche sind bemerkenswert. Die meisten Einzelfaktoren hat man so schon mal anderswo gesehen, wenn auch ohne kritische Konsequenz, weil das System mit einzelnen Fehlern fertig wird. Wirklich dramatisch ist aber die Verkettung von Umständen, die in letzter Konsequenz zum kompletten Aufgeben der Redundanz führte und einem einzigen System die vollständige Kontrolle überließ – einem System, das dann noch nicht einmal funktionierte, wie es sollte. Was bleibt ist die altbekannte Erkenntnis, dass der Weltraum eine ziemlich gnadenlose Umgebung ist, die Fehler jedwelcher Art nicht verzeiht. Das weiß zwar im Prinzip jeder, in der Praxis wird der Maxime manchmal nicht der gebührende Respekt gezollt.
Weitere Information
Cutting Corners & Lack of Operational Protocols Doomed Japan’s Hitomi Observatory, Quelle: spaceflight101.com, 30. Mai 2016
Hitomi Experience Report: Investigation of Anomalies Affecting the X-Ray Astronomy Satellite “Hitomi” (ASTRO-H), Quelle: JAXA, 24. Mai 2016
Geschrieben wie ein Krimi. Mit ein Grund, warum ich hier immer wieder gerne mitlese.
Also eine Kombination von falschen Daten und falschen Automatismen und einer falschen Reaktion des Bodenpersonals im Kontrollzentrum.
Sensoren, die falsche Daten liefern sind nicht nur in der Raumfahrt ein Problem. Sie haben auch – zusammen mit einer falschen Reaktion der Crew – den Absturz der Air France 447 verursacht.
Ich denke, es ist komplizierter. Nicht nur falsche Daten, sondern auch unzureichende Prozeduren für kritische Komponententests sowie in Teilen, mangelhaftes Qualitätsmanagement. Siehe Seiten 63ff im bemerkenswert offenen JAXA-Bericht, den ich verlinkt habe (Fettdruck von mir eingefügt):
++++++++++++++++++++++
5.1.4 Inappropriate Parameter Setting
Facts
JAXA carries out the operation of ASTRO-H under a support contract with an operations support company. ASTRO-H is a special satellite whose mass properties change after EOB extension. Accordingly, after EOB extension on orbit, parameters related to the mass properties (center of mass and moment of inertia [MOI]) have to be changed.
1.
Feb 25: As a part of operations to change parameters after EOB extension, JAXA held discussions with the support company and decided to change the thruster control parameters according to the actual properties of the thrusters. The company started the process. Note that this operation (changing the parameters) was not described in the documents prepared prior to launch that regulated the operational plan. In addition, details of this operation (which parameters are changed and how) were not shared between the support company and JAXA.
2.
There were errors in data input by the support company when the updated thruster control parameters were calculated. Accordingly, inappropriate parameters were derived.
3.
The support company was busy with duties on that day. One reason for this was that the company had to perform a task that was not described in the document governing the operational plan. This situation led to miscommunication of operational instructions between staff members of the company. Thus, a part of required verification was not implemented.
4.
JAXA, which was in charge of operations, did not confirm the preparation process for changing the thruster control parameters. Then, JAXA, without noticing the omission of the verification, ordered the implementation of the operation.
5.
Feb 28: After EOB extension, an operator followed the instruction given by JAXA, and sent the parameters prepared in item 2 above to the satellite.
++++++++++++++++++
Spannend und informativ vom ersten bis zum letzten Satz.
Irgendwie ist es schade, aber ich glaube man erfährt oft am meisten
über die Details von Raumfahrtmissionen wenn was nicht so klappt
wie geplant.
Es ist schon was Wahres dran, Fehlerszenarien werden detaillierter beschrieben als Erfolgsszenarien. Das liegt aber auch daran, dass es wohl einfach zu viel Arbeit wäre, ein komplexes Gesamtsystem “Satellit” zu beschreiben. Bei einem Fehlerszenarion beschränkt man sich ja auf den Teil des Systems, der versagt hat. Das ist ein einigermaßen eng umrissenes Problem. Und selbst dann merkt man schnell, dass es nicht mal eben so abgehandelt werden kann. Ich bin überall oberflächlich geblieben, und trotzdem kam schon ein langer Beitrag heraus.
Wenn ich mir die Zugriffszahlen so anschaue, kann ich mich allerdings der Erkenntnis nicht verschließen, dass dieses Thema eh keine Sau interessiert. Muss ich einfach mal so sagen.
Aber, aber! Bei Sodom & Gomorrha wäre der liebe Gott schon mit einem einzigen Gerechten zufrieden gewesen! Hier hingegen finden sich immerhin mindestens vier! ^^
Sehr schöner und ausführlicher Artikel … es gibt schon einige ‘Säue’, die so etwas wirklich interessiert 😉
Als Anmerkung zum Auszug aus dem JAXA Bericht – laut diesem Bericht:
http://spaceflight101.com/h-iia-astro-h/hitomi-failure-cutting-corners/
sind zwei Programme für die Ermittlung der Thruster Control Parameter genutzt worden. Das erste Programm – RCS Drive Matrix Generation Tool – hat 6 vorzeichenbehaftete Werte geliefert.
Diese mussten von Hand – !!! – und als vorzeichenlose – !!! – Werte in das zweite Programm – Thruster Parameter Table Generation Tool – eingegeben werden … was prompt falsch gemacht wurde, auch weil es dafür keinerlei Dokumentation gab.
Ich weiß wirklich nicht, was da der größte WTF ist …
Gruß & gerne weiter so mit technischen Artikeln!
Ein wirklich lesenswerter, schön geschriebener und sehr informativer Beitrag, danke dafür!
Das ist wirklich mal ein sehr aufschlussreicher Artikel, insbesondere die kurze “Technikvorlesung” finde ich gelungen.
Ach ja, und was so ein Gesamtsystem Satellit angeht, das lässt sich zwar nicht in einem Beitrag erklären, aber vielleicht in einer kleinen Serie, sofern Sie denn die Lust dazu auftreiben können. 😉
Davon abgesehen: Ich hab mir ja vor längerer Zeit mal die ESA-SPxxxx Schriften angesehen. Das sind ja teilweise mehrere hundert Seiten umfassende Schriftstücke, die sich nur auf einen einzigen Satelliten beziehen. (Gaia mag da ein besonderer Fall sein, weil es dazu nach meinem Eindruck besonders viele Hefte gibt. – Aber das kann auch eine Täuschung meinerseits sein.)
Ach ja, und gute Bücher darüber, die auf mittlerem Niveau die Technik beschreiben, gibt es soweit ich weis, auf Deutsch ja auch nicht. Bestenfalls auf Englisch, aber ich glaube, ein solches müsste ich mit dem Wörterbuch nebendran lesen…
Dann mal kurz zu den Sternsensoren: In welcher Grössenordnung liegt denn die benötigte Helligkeit der Sterne so in etwa? – Müssen das unbedingt die hellen Sterne von 0 bis… – sagen wir mal 2 oder 3 mag sein, oder können die auch dunkler sein? – Und sucht so ein Teil dann nach Sternbildern oder wie funktioniert das?
Ja, ganz genau, Sternsensoren (engl.: “star tracker”) suchen nicht nach einzelnen Sternen, sondern nach Sterngruppen, die per Bildverarbeitung erkannt und einem Sternkatalog zugeordnet werden. Somit reicht ein Sternsensor aus, um die komplette Lageinformation eines Satelliten relativ zu allen drei Achsen zu bestimmen.
Europa dominiert aktuell den Weltmarkt für Sternsensoren.
Es sind schon ziemlich komplexe optoelektronische Einheiten, die in verschiedenen Leistungsstufen (und Preisklassen) angeboten werden.
Ein Sternsensor umfasst eine – für Teleskopverhältnisse – weitwinklige Optik (Sichtfeld 10-20 Grad), einen CCD- oder CMOS-Sensor und eine Rechnereinheit, um die Bildverarbeitung und Sternidentifizierung zu leisten.
Ein führender deutscher Hersteller ist das deutsche Unternehmen Jena Optronik mit seinen Baureihen Astro 15, Astro 10 und Astro APS. Sie finden unter dem Link auch Datenblätter zu den einzelnen Modellen. Teurer bedeutet mehr Auflösung, höhere Störunempfindlichkeit und natürlich schnellere Verarbeitungszyklen.
Viele Sternsensoren gestatten auch das Auslesen des Bilds auf dem Sensor. Ich habe beispielsweise Bilder gesehen, die vom Sternsensor einer Mondsonde aufgenommen wurden und die die Mondoberfläche zeigten.
Besten Dank.
Interessant. – Es bleibt dann wohl den Missionsdesignern überlassen, diese Möglichkeit zu nutzen oder auch nicht.
Wäre das nicht noch was für Sie? – So ein paar Mondbilder aus unmittelbarer Nähe? Oder spricht etwas dagegen?
Die Bilder, die ich meinte, sind von SMART-1. Siehe hier und hier.
Oh, interessant.
Das führt dann (oder mich zumindest) aber auch gleich weiter zu der Frage, warum man in Europa mit der Mondforschung nach SMART-1 nicht weiter gemacht hat? – Die hatten Sie ja auch schon mal in den Raum gestellt, wenn ich mich nicht irre. – Und nein, ich erwarte darauf jetzt keine Antwort, denn die wäre bei der Politik zu suchen, die sich zwischenzeitlich andere Prioritäten gesetzt hatte…
SMART-1 wurde nie wirklich als wissenschaftliche Mondmission gesehen. Man wollte in erster Linie Erfahrungen im Betrieb einer interplanetaren Sonde mit Schwachschubantrieb machen. Die 15 kg wissenschaftlicher Nutzlast waren so etwas wie eine Dreingabe, aber es gab damals keinen Plan zur dedizierten Mondforschung seitens der ESA. Deswegen kann man auch der Politik keinen Vorwurf machen. Wenn man denen nichts vorlegt, haben sie auch nichts zum Abnicken.
Ach so. Okay, wenn das so ist, dann bleibt zu hoffen (jedenfalls für mich) dass Herr Wörner es schafft, eine wissenschaftliche Mondforschung der ESA anzustossen, bzw. voran zu treiben, die den Namen auch verdient. – Dabei wäre seine Vision vom Moon Village zwar die Krönung, aber ob es dazu kommt, wird sich erst noch zeigen müssen.
Ist ja gut, Leute, ihr braucht mich nicht zu trösten. 🙂
Für mich war das ein sehr guter und informativer Artikel, unglaublich gut auch für absolute Laien wie mich aufbereitet. Spitze!
Ich habe die Seite heute erst entdeckt ( bzw. Florian Freistetter für mich http://scienceblogs.de/astrodicticum-simplex/2016/09/05/in-einer-dunklen-ecke-des-kometen-philae-wurde-wieder-gefunden/#comment-970342 )
Super super interessant, toll und spannend geschrieben und stellenweise mit einem Schmunzeln zu lesen.
Werde mir heute Abend noch den ein oder anderen Artikel zu Gemüte führen und bestimmt nochmal vorbei schauen!