Home Site Map Sonstige Aufsätze Weblog und Gequassel counter

Web Log Teil 262: 11.1.2012 - 20.1.2012

11.1.2012: Lösungen für das Computer-Dilemma in der Raumfahrt

Bei der Raumfahrt wird ja alles selbst entwickelt oder wenn es so was wie Serien gibt, dann ist es die Kleinserie. Das ist sehr oft kein Problem. In vielen Branchen ist die Einzelanfertigung ja noch die Regel. Natürlich im Handwerk, aber auch in der Luftfahrt, aus der sich die Raumfahrt zumindest von ihrer industriellen Basis her entwickelte. Wer ein eigenes selbst konstruiertes Flugzeug haben will, kann sich noch heute eines bauen lassen. Dasselbe gilt im Instrumentenbau - Großinstrumente waren schon immer Einzelanfertigungen. Es gibt nur eine Industrie wo das nicht der Fall ist: Die Mikroelektronik.

Das Kennzeichen der Herstellung von integrierten Schaltungen, ist das der Prozess  weitgehend automatisch abläuft, extrem hohe Anforderungen an die Reinheit der Umgebung hat und immer hunderte von Chips gleichzeitig bearbeitet. Er ähnelt dem Drucken von Zeitungen. Zeit, mal die bisherige Geschichte der Mikroelektronik in der Raumfahrt zu betrachten.

In den sechziger und Siebziger Jahren waren die Computer noch aus diskreten Bauteilen aufgebaut wie Transistoren oder manuell hergestellten Ringkernspeichern. Später kamen einfache integrierte Schaltungen in LSI und MSI Technik dazu. Für diese Elemente in niedriger Dichte, war noch ein geringer Aufwand nötig und die Industrie nahm damals auch noch gerne Fremdaufträge an, um ihre Fertigung auszulasten, die sich an die Computerhersteller richtete und da waren auch die Stückzahlen begrenzt.

Es kam dann die Periode, in der Standardprozessoren verwendet wurden, wenn sie den Anforderungen genügten. Das war während der achtziger und frühen Neunziger der Fall. Hubble bekam einen 80386, Rosat einen 8086, die Transputer kamen in viele Satelliten und Raumfahrzeuge.

Seitdem gibt es ein Problem: Die Hardware die serienmäßig produziert wird, ist nicht mehr weltraumtauglich. Die früher üblichen Serien mit militärische Spezifikationen (höherer tolerierbarer Temperaturbereich, höhere Strahlungstolernz) gibt es bei modernen Prozessoren nicht mehr, Die NASA erwarb mal von Intel das Design des Pentium, um auf ihm basierend eigene Prozessoren zu kreieren, kam aber nie dazu und inzwischen hat es Intel wieder zurückgekauft, sonst hätte die Firma bei ihren Atom-Prozessoren ein kleines Lizenzproblem. Die Investitionskosten für die nächste Chipgeneration steigen aufgrund der immer höheren Anforderungen an. Sie liegen derzeit bei mehreren Milliarden Dollar pro "Fab" (Farbik). Entsprechend fertigen immer weniger Hersteller Chips in der kleinsten möglichen Strukturbreite. Bei der aktuellen sind es nur noch Intel und zwei Konglomerate. Außer Intel leistet sich keine Firma alleine mehr die Investitionskosten in eine Fab - schwer zu vorstellen, dass sich diese dann für die kleinen Stückzahlen für die Raumfahrt rentieren würden.

Seitdem hinkt die für Weltraumtechnik verfügbare Technologie der irdischen hinterher. Der schnellste verfügbare Prozessor ist der RAD-750. Er basiert auf dem PowerPC Prozessor 750 aus dem Jahr 1998. Er ist in etwa so schnell wie ein Pentium II PC - und seit er ist seit 2005 verfügbar. Seitdem gab es keine neue Generation. Er befindet sich auf 150 Satelliten - viel für Raumfahrtmaßstäbe, aber wenig für die kommerzielle Fertigung, vor allem, wenn sich diese Zahl auch noch auf 6 Jahre verteilt. Es gab ihn also erst 7 Jahre nach dem PC-Vorläufer und anders als bei diesem gibt es nicht alle 2-3 Jahre eine neue Generation. Das verschärft die Situation in der Zukunft noch weiter.

Hoffnung ist nicht in Sicht: Da die Preise für kleinere Strukturbreiten bei einer nächsten Generation für die Fertigung ansteigen, wird es schwer sein diese Kosten für die nächste Generation zu rechtfertigen. Welche Lösungen gibt es dann?

Eine Lösung, wenn man nur für eine bestimmte Funktion viel Rechenleistung benötigt, ist es für diesen Zweck eigene Hardware zu fertigen. Wer ein älteres Semester ist, kennt vielleicht noch den 80x87 Coprozessor der Berechnungen schneller durchführen konnte - um den Faktor 10-20, bei Funktionen wie Logarithmus oder Sinus sogar noch mehr. Ein aktuelles Beispiel sind die Chips, die in Fernsehern stecken um die komprimierten Signale des H264 Formats in HD-Videos auszurechnen. Wenn das Software macht, wie im PC noch vor 1-2 Jahren üblich, dann benötigt man dazu einen Dual-Core Prozessor. Im Fernseher reicht ein wesentlich einfacher Chip. der typische Gewinn liegt beim Faktor 10-100 wenn man Software durch Hardware ersetzen kann. je nach Komplexität und Paralellisierbarkeit Das ist für die Datenverarbeitung ein Weg, so erfuhr ich bei einem Besuch eines Frauenhofer IMS, dass dort ein Chip für TerraSAR-X entwickelt wurde. Nur sind die dort gebauten Custom-Gate Arrays begrenzt in der Transistorzahl, noch mehr als die aktuellen Prozessoren für die Raumfahrt. Der RAD-750 hat 10,4 Millionen Transistoren (heutige Prozessoren für den PC über 2 Milliarden). IMS kann bis 0,5 µm Strukturbreite Chips mit bis zu 30.000 Gattern, das sind 120.000 Transistoren, fertigen.

So ist heute es noch ein zweiter Weg möglich: FPGA. Sie sind anders als ASICs nachträglich programmierbar und werden mittlerweile in größeren Stückzahlen hergestellt, was es ermöglicht sie auf ähnlichen Fertigungsstraßen wie Prozessoren herzustellen. Bis zu 10 Millionen Gatter und 1,5 GHz sind zumindest für nicht-weltraumtaugliche Hardware verfügbar. Dann muss allerdings noch die Weltraumtauglichkeit geprüft werden. Ein deutscher Kleinsatellit sollte deren Einsatzmöglichkeiten erproben.

Die Alternative ist es "normale" Hardware zu verwenden, im Fachjargon immer gerne als COTS bezeichnet - Common off the Shelf. Die Technologiesonde ST-8 sollte z.B. herkömmliche PC-Technik erproben. Die Empfindlichkeit der herkömmlichen PC-Technik soll durch Redundanz sowohl bei den Prozessoren wie auch beim Speicher kompensiert werden. Dazu kommt ein strahlengehärteter FPGA-Controller, der nachprüft ob alle Teile noch richtig rechnen oder ein Prozessor abgestürzt ist oder es Defekte beim Speicher gibt. Sofern es nur temporäre Ausfälle gibt, also als Paradebeispiel ein Bit durch ein geladenes Teilchen umkippt. Wogegen dies nicht hilft, sind permanente Schäden, wie sie durch statische Elektrizität auftreten können. Die Technologien für Redundanz sind nicht gerade neu. Entweder man legt ein System mehrfach aus, wir kennen das auf der Erde als RAID-1, wenn zwei Festplatten dieselbe Information speichern. Bei Halbleiterspeichern ist es gängiger, sie gleich dreifach redundant auszulegen und dann eine Mehrfachentscheidung zu fällen. Bei Prozessoren muss man diese synchronisieren, wie dies z.B. bei den Shuttle Hauptcomputern der Fall war - in periodischen Intervallen werden sie angehalten und geprüft ob sie noch arbeiten, oder ein Kontrollergebnis bei allen Prozessoren das gleiche ist. Bei Speichern ist es üblicher, heute sie mit Standardfehlerkorrekturen wie ECC zu versehen.

Die dritte Lösung, die ich mal so in die Diskussion werfe, ist das Abschirmen. Auf der ISS arbeiten normale PC's. Zumindest bei den mobilen Rechnern sind nur leicht modifizierte Laptops üblich (Schnittstellen die nicht benutzt werden geerdet und Zugänge durch Blenden abgedeckt, besserer Schutz gegen statische Elektrizität). Die Strahlendosis ist in den Labors so weit abgeschirmt, dass sie nicht mal Menschen gefährlich wird, die noch empfindlicher als Elektronik sind. Bei den bekannten Massen der Hüllen der Labors entspricht die Abschirmung einer von 33 kg/m² MPLM bis 80 kg/m² (Columbus). Das sind 1-3 cm Aluminium, woraus die Wand üblicherweise besteht. Da heute PC-Technik recht wenig Platz braucht (denken sie an einen Laptop, Smartphone, Ipad ...) wäre eine analoge Abschirmung auch bei Satelliten tolerierbar. Nimmt man an, dass man die gesamte Elektronik in einem Quader von 20 x 10 x 10 cm Größe unterbringen kann (2 l Volumen, ein Nettop-PC, denn die ct' in der ct 2/2012 testete, hatte nur 0,8 l Volumen), so wiegt die Abschirmung zwar 4 bis 8 kg zusätzlich - doch das denke ich ist verschmerzbar. Man müsste eben wieder zu einer zentralen Datenverarbeitung zurückkehren, also nicht wie heute üblich dass jedes Experiment seine eigene Elektronik lokal direkt am Instrument mitbringt und man entweder diese in das Computersystem integriert oder dieses leistungsfähig ist, dass gar keine eigene Elektronik für Instrumente nötig ist.

Ich denke auf Dauer wird man nur eine von beiden Ansätzen nehmen können. Da auch bei COTS Hardware aufgrund der immer stärkeren Empfindlichkeit der Hardware der Aufwand für die Synchronisation und Erhaltung der Konsistenz der Daten ansteigt, halte ich die Abschirmung für die bessere Möglichkeit, die ja hier auch nur überschlägig berechnet ist. Der Schutz ist sicher noch auf die tatsächlich nötige Abschirmung optimierbar. (Stärke, Material...). Die immer höheren Datenraten von Instrumenten die ja auch verarbeitet und zwischengespeichert werden müssen, werden mehr Prozessorpower nötig machen.

14.1.2011: Neues

So, nun sind meine im Voraus geschriebenen Blogs (während der Weihnachtspause) am Ende, aber mir fehlen auch ein bisschen die Themen für neue Blogs. Also schreibe ich mal was ich so mache. Derzeit tanze ich auf zwei Hochzeiten: Zum einen habe ich von Januar bis März die doppelte Stundenzahl an Vorlesungsstunden an der DHBW, dadurch sind zwei Tage schon mal ausgebucht. Bisher bin ich ganz zufrieden mit den Studenten. Informatik wurde nun sowohl von der Stundenzahl wie auch von den ECTS Punkten aufgewertet. Als ich anfing wurde es mit Elektrotechnik zusammengezählt wobei man auch in Informatik durchfallen konnte weil die Note zusammengerechnet wurde, dann musste man auch in Informatik bestehen, aber es war nach wie vor ein Nebenfach, nun sind es 5 ECTS Punkte die es dafür gibt - allerdings bei nur 66 Präsenzstunden, das ist ziemlich wenig. Immerhin 50% mehr Stunden als vorher.

Bisher habe ich den Eindruck, dass die Studenten interessierter sind, vorher gab es (ich habs schon mal erwähnt) dauernd die Frage warum nicht das Vermitteln von Excel Bestandteil des Informatikunterrichts ist ...

Das zweite ist dann die Arbeit an dem Projekt an der ich schon seit September dran bin. Nominell sind es nur etwa zwei Mannmonate, aber weil ich immer Pause machen muss, wenn entweder mein Kontakt der seinen Teil an der Steuerung programmiert eine andere Arbeit hat oder der Kontakt für den Auftrag auch keine Arbeit hat. So musste ich Mitte November aufhören und nun bin ich dran wieder eine 53 Seiten Liste an neuen Requirements abzuarbeiten. Klingt viel, ist auch viel, aber vor allem sollen alle Menüs, Hinweise, Icons etc. geändert werden. In manchen Teilen ist die komplette Logik flöten gegangen, dafür kamen neuen Menüpunkte dazu, die sich wohl aus der Logik anderer Anwendungen der Firma ergaben, aber keinen Sinn machten. Dadurch habe ich auch so gut zu tun. Knapp 30 Stunden sind noch übrig, aber ich bin mir sicher, da kommen noch mehr dazu, denn was ich jetzt mache ist eigentlich nicht das was ausgemacht war. Ausgemacht war eine Adaption der Software an eine Steuerung der Firma als Testsystem, anstatt einer Hardware der Firma Jäger, die vorher genutzt wurde. Was herauskam, war eine Erweiterung in vielen Usabilitypunkten, weitgehende Neugestaltung der Oberfläche das sicher die Hälfte der Zeit beansprucht hat, aber nicht Bestandteil des Auftrags war. Dafür stehen einige Kernpunkte des Auftrags noch aus - Komplette Tests mit der Steuerung der Firma (bisher unmöglich, weil ihre Software dafür noch nicht fertiggestellt ist), Installationspakete schnüren und auf verschiedenen PC's testen und vor allem die Hilfe in das Firmenformat umwandeln und überarbeiten - bisher gab es nur von mir eine Hilfe, damit ich selber jeweils nach einigen Jahren wieder schnell in das Programm hineinkam, eine Forderung war die Hilfe nie.

Aus beiden Gründen komme ich kaum zu neuen Blogs, aber ich habe wieder mal Lust bekommen was zu programmieren, auch weil mir zwei Ideen im Kopf herumgeisterten. So habe ich diese Woche zwei kleine Hilfsprogramme geschrieben. Das eine ist SmartMove. Am besten schreibe ich mal warum ich das Programm schrieb: Also man lädt Dateien vom Internet runter und die landen alle im Download Ordner. Dumm, ich habe eigene Ordner für PDF's, Bilder, Exes etc... Oder man speichert mal ein Bild in einem Ordner und dann aus versehen das nächste PDF dort auch. Genauso passiert es einem leicht beim Bearbeiten mit Office schnell in einem falschen Ordner zu landen. Smartmove macht nur eines: Man gibt ihm eine Liste von Quellordnern, dazu gehörigen Zielordnern und einen Filter. Dann wird es die Dateien im Quellordner die auf den Filter passen in den Zielordner kopieren oder verschieben, je nach Einstellung. Das ganze kann auch automatisiert beim Windows Start erfolgen oder die Ordner können laufend überwacht werden.

Das zweite ist EasyBackup. Backup sind wichtig, aber sie haben nur Sinn, wenn sie regelmäßig angefertigt werden. Ich habe bisher dazu Duplikati genutzt. Das Problem ist dass es wenn es kopiert praktisch nicht mehr gearbeitet werden kann. Zudem legt es zwar Zip Archive an, aber ich denke ohne Duplikati könnte ich sie später nicht mehr nutzen um Dateien zu restaurieren. Für Vollbackups läuft Acronis True Image, doch das ist wegen der Container auch keine Lösung für einzelne Verzeichnisse und Dateien ist das nicht geeignet. Also habe ich mich drangesetzt das zu programmieren was ich brauche - eine Art moderner XCOPY Ersatz, das ganze Verzeichnisse kopiert. Ja und genau das ist Easy Backup. Man gibt ein Zielverzeichnis und viele Quellverzeichnisse mit Filtern an und alle Dateien die es dort gibt werden kopiert. Beim zweiten Lauf dann nur noch ide geänderten und neu hinzugekommen. Auch EasyBackup kann beim Autostart laufen und man kann angeben alle wie viele Tage es Kopien ziehen soll. Auch hier gibt es ein Restore und eine Bereinigungsfunktion - wenn sich im Backupverzeichnis "Dateileichen" ansammeln die man in der Quelle längst gelöscht hat, kann man so "rücksynchronisieren" und alle Dateien löschen die es im Quellverzeichnis nicht mehr gibt.

16.1.2011: Ein Triebwerk für alle Stufen?

Ich dachte mir, ich nehme heute mal wieder ein theoretisches Thema und greife das auf. Ideal wäre es doch, wenn man ein Triebwerk bei einer Trägerrakete in allen Stufen einsetzen könnte. Das würde Kosten für die Entwicklung verschiedener Triebwerke sparen und es würde eine höhere Stückzahl ergeben, also auch bei der Fertigung Kosten sparen. Die Oberstufen würden dann nur geringe Modifikationen erfordern wie eine verlängerte Düse, die z.B. aus einem einfachen, ungekühlten Zeil bestehen kann und die Fähigkeit zur Zündung unter Schwerelosigkeit (Auf die man mit Hilfsraketen verzichten kann, wenn diese vorher den Treibstoff sammeln).

Schaut man sich die existierenden Typen an, so gibt es in der Tat einige Umsetzungen dieser Idee. Hier eine kleine Liste (ohne Anspruch auf Vollständigkeit):

Zu den russischen Triebwerken NK-XX wäre zu sagen, das NK-33/43 dasselbe Triebwerk mit unterschiedlichen Düsen und NK-9/19 ebenfalls eines mit oder ohne kardanische Aufhängung sind, also zwei Versionen eines Typs.

Versuchen wir uns aber mal dem Problem theoretisch zu nähern. Der Schub eines Triebwerks bzw. der Gesamtschub ergibt sich aus der Gesamtmasse beim Start und der benötigten Beschleunigung. Am einfachsten ist dies bei der ersten Stufe: sie muss mit mindestens 1 g starten, vorzugsweise mehr, weil sie sonst erst mal über dem Starttisch schweben würde. Bei mit flüssigen Treibstoffen angetriebenen Raketen ist eine Beschleunigung um 1,2 bis 1,4 g üblich. Bei mehr besteht bei zweistufiger Bauweise die Problematik, dass bei Brennschluss eine sehr hohe Spitzenbeschleunigung resultiert. Bei militärischen Raketen gibt es diese Einschränkung nicht, da Atomsprengköpfe nicht so empfindlich wie Satelliten sind, so hat die Dnepr z.B. eine Startbeschleunigung von 2 g.

Schwieriger ist es bei den Oberstufen. Hier spielt schon eine Rolle, wie das Trägersystem ausgelegt ist, das heißt welchen Anteil der Geschwindigkeit die sie aufbringen muss und bei welcher Geschwindigkeit sie gezündet wird. Wenn schon fast Orbitalgeschwindigkeit erreicht wird, wie dies z.B. bei der Ariane 5 nach Brennschluss der EPC der Fall ist, kann die Oberstufe eine sehr geringe Beschleunigung aufweisen (Extrembeispiel: ATV Missionen mit der EPS: nur 0,1 g Beschleunigung. Üblich sind aber eher 0,5 bis 0,8 g. Bei einer zweiten Stufe ist der Wert eher höher als bei einer dritten Stufe. Er muss nicht über 1 g liegen, weil die Beschleunigung in der Vertikalen von der ersten Stufe zum größten Teil erbracht wurde. Typisch ergibt sich dann eine Aufstiegskurve mit einem Buckel: die erste Stufe liefet eine hohe vertikale Beschleunigung und die oberen Stufen beschleunigen vor allem in die Horizontale. Dadurch steigen die Stufen erst auf, fallen dann nach Erreichen einer Spitzenhöhe und fangen sich in der Höhe einer stabilen Umlaufbahn, wenn dort dann die Kreisbahngeschwindigkeit erreicht ist. Ist der Schub zu niedrig, dann ist die Höhe zu gering und die erste Stufe muss mehr Hubarbeit für die Vertikale aufbringen. Nehmen wir also 0,5 bis 0,8 g als Vorgabe.

Konzentrieren wir uns nun erst mal auf zweistufige Träger. Warum? Nun leicht zu begründen. Sind es drei Stufen und setzen wir ein Triebwerk in der dritten Stufe ein, so ist bei typischen Stufenmassen schon in der zweiten vier Triebwerke nötig und 16 bis 25 in der ersten. Das ist dann schon recht viel und wir bekommen zwei Probleme die ich weiter unten angehen will. Bei zwei Stufen sind in der ersten Stufe dann nicht so viele Triebwerke nötig. Weiterhin reichen zwei Stufen bei LOX/Kerosin für gute LEO-Nutzlasten und bei LOX/LH2 auch für GTO oder Fluchtbahnen aus.

Die Abschätzung der Stufenmassen kann man leicht aus folgenden Überlegungen machen: Bei gleichen Treibstoffen in allen Stufen sollte gelten: Startmasse (Stufe 1 / Startmasse Stufe 2) ~ (Startmasse Stufe 2 / Nutzlast). Die Nutzlast ist von bisherigen Trägern bekannt. Sie beträgt bei LOX/Kerosin etwa 2,5 bis 3% der Startmasse und bei 7% bei LH2/LOX.

Die Stufenverhältnisse bekommt man dann aus der Wurzel dieses Verhältnisses also bei LOX/Kerosin = √ 100/3 und bei LOX/LH2 = √ 100/7 oder 3,8 bzw. 6:1. Daraus kann  man, ausgehend von der Nutzlast, die zweite Stufe berechnen und dann die erste. Nehmen wir mal eine Trägerrakete mit jeweils 200 t Startmasse, einmal mit LOX/LH2 und einmal mit LOX/Kerosin, dann kommt man auf folgende Stufenmassen:

  LOX/LH2 LOX/Kerosin
Nutzlast 14 t 5,5 t
zweite Stufe 53,2 t 33,1 t
erste Stufe 146,8 t 166,9 t
Startgewicht mit Nutzlast: 214 t 205,5 t

Das soll nur eine empirische Näherung sein, die aber nicht weit von optimalen Werten entfernt ist. Nehmen wir mal an, das die zweite Stufe 70% des Gewichts (Masse x Erdgravitation) der zweiten Stufe mit Nutzlast als Schub bringen muss und die erste Stufe 130%, so kommt man zu folgender Schubtabelle:

  LOX/LH2 Triebwerke LOX/Kerosin Triebwerke
zweite Stufe 470 kN 1 270 kN 1
erste Stufe 2780 kN 5,9 ~ 6 2671 kN 9,7 ~ 10

Das zeigt schon ein Problem: Aufgrund des höheren Schubs den die erste Stufe erbringen muss (Beschleunigung über 1 g) und der viel größeren Masse, steigt selbst bei Bestückung mit nur einem Triebwerk die Anzahl der Triebwerke für die erste Stufe stark an. Hier sind es 10 bei der LOX/Kerosin Lösung und immerhin noch 6 bei der LOX/LH2 - hier ist die zweite Stufe und die Nutzlast schwerer, sodass die Unterschiede im Schub kleiner sind.

18.1.2011: Ein Triebwerk für alle Stufen - Teil 2

Im ersten Teil habe ich dargelegt das bei zweistufigen Raketen sehr viele Triebwerke in der ersten Stufe benötigt werden, wenn man nur ein Triebwerk in beiden Stufen verwendet wird. Heute will ich die Konsequenzen dessen darlegen.

Nun ist es sicher so, dass größere Stückzahlen ein Triebwerk preiswerter ist, das muss aber gegengerechnet werden, dass ein großes, schubstarkes Triebwerk immer noch preiswerter als zehn kleine sind. Ich denke, wenn man einen Vergleich zur Luftfahrt macht, wo ein Jumbojet auch maximal vier anstatt 10 bis 12 Triebwerke hat, liegt die Obergrenze bei vier Triebwerken.

Das ist bei LOX/LH2 noch zu erreichen, wenn man bei der zweiten Stufe etwas höheren Startschub toleriert, hier 700 kN, entsprechend 10,4 m/s Beschleunigung beim Start und 36,9 m/s² Brennschluss. Würde man bei der LOX/Kerosinlösung genauso verfahren, so kommt man auf 668 kN Schub pro Triebwerk und 17,3 m/s² Start- und 83 m/s² Brennschlussbeschleunigung. Der letzte Wert ist intolerabel hoch und auch ist dann die Brennzeit so kurz, dass zu Brennschluss eventuell ohne Freiflugphase noch kein Orbit erreicht wurde.

So ist das Bündeln mehrerer Triebwerke eher sinnvoll für zweite und dritte Stufen, da hier:

Es gibt noch einen zweiten Grund, der gegen zu viele Triebwerke spricht: Die Wahrscheinlichkeit eines Ausfalls. Es ist das komplexeste einer Stufe, mit den meisten mechanisch-beweglichen Teilen, mit der höchsten Temperaturbelastung. Wenn ein Triebwerk eine Zuverlässigkeit von 99% hat, dann beträgt die Wahrscheinlichkeit dass eines von 10 Triebwerken ausfällt schon 10%, mithin die Wahrscheinlichkeit eines Fehlstarts 10%, ein Wert der indiskutabel hoch ist, zumal es ja auch noch andere Risiken gibt, die sich dazu addieren.

Das bedeutet: setzt man mehrere Triebwerke ein, so muss man auf den Fall eines Ausfalls gewappnet sein, was im Fachjargon "engine-out capability" heißt. Das bedeutet: Ein Triebwerksausfall muss rechtzeitig festgestellt werden, das Triebwerk sauber abgeschaltet werden, bevor es beschädigt wird und eventuell andere Triebwerke beschädigt. Danach muss der Treibstoff umverteilt und andere Triebwerke müssen den asymmetrischen Schub kompensieren können (Schwenkbar sein und dafür einen ausreichend großen Bereich verfügen oder man schaltet ein gegenüberliegendes Triebwerk ab und lebt dann mit dem doppelten Schubverlust).

Es hat auch Auswirkungen auf das Missionsdesign und die Auslegung der Trägerrakete. So müssen die Treibstoffvorräte so ausgelegt sein, dass die erhöhten Gravitationsverluste durch den Triebwerksausfall aufgefangen werden können. Der Schub muss ausreichend sein, um den Ausfall aufzufangen. Das ist meist beim Start nicht gegeben und so wird dann oft gesagt dass z.B. ab de 30 Sekunde eine Engine-Out Capability gegeben ist. Vor allem aber muss es auch getestet sein - bei Tests am Boden und beim Flug. Das erfolgte z.B. bei der Saturn I bei einem Testflug - die Saturn I/V sind auch die einzigen Raketen wo Engine-Out Capability wirklich funktionierte - bei einem Saturn IB Start fiel ein Triebwerk aus und bei zwei Saturn V Starts jeweils ein Triebwerk der S-II. Bei der N-1 funktionierte es nicht. Beim Space Shuttle funktionierte es, aber er ist ein Sonderfall: hier ging es darum das Shuttle sicher zu landen - die Mission wäre nur geglückt, wenn der Triebwerksausfall recht spät vorkommt, was einmal vorkam.

Ich denke in der Praxis ist die Engine-Out Capability eine Absicherung, wenn wirklich gut getestete und überwachte Triebwerke trotzdem ausfallen sollten. Das war bei der Saturn gegeben. Bei der S-IC konnte man sich wegen der langsamen Beschleunigung erst auf die Engine-Out Capability verlassen, wenn die 30 s Flugsekunde verstrichen war. Also wurden die F-1 Triebwerke extrem viel getestet - mehr als jeder andere Typ seitdem. Es sollte eben vermieden werden, dass sie überhaupt ausfallen sollten. Bei den J-2 war ein Ausfall nicht so dramatisch, er konnte von der S-II aufgefangen werden. Und in der Tat kamen alle Ausfälle von Triebwerken auch bei der S-II vor (bei dem zweiten Testflug, als eine falsche Verdrahtung sogar zwei Triebwerke abschaltete - anstatt dem betroffenen wurde ein anderes abgeschaltet) und bei der Mission von Apollo 13.

Nichte jede Rakete mit vielen Triebwerken hat eine Engine-Out Capability, z.B. die Ariane 1-4 hatte sie nicht und so gingen auch zwei Starts bei Versagen eines Triebwerks der Erststufe verloren Gerade Ariane 4 zeigt aber auch, dass ein Träger mit bis zu acht Triebwerken erfolgreich sein kann und eine hohe Zuverlässigkeit erreichen kann - hier war der Schlüssel eine sehr robuste Technologie der Triebwerke, die weit von dem entfernt war, was technisch damals möglich war. Das konservative Design lies aber auch wenig Platz für Fehler.

20.1.2012: Drei Bücher ein Thema

Zeit mal wieder für eine Buchkritik. Ich will heute mal drei Bücher besprechen, die ich für mein Skylab Buch gelesen habe. Also weniger eine Rezension sondern mehr ein Vergleich. Fangen wir mit dem ältesten an. Es ist Skylab. Labor im Weltraum. Es erschien 1973 vor dem Start von Skylab. Es unterscheidet sich in einigen Punkten von den beiden anderen Büchern. So erschien es 1973 vor dem Start des Labors, es wendet sich an eine interessierte Allgemeinheit, aber keine "Raumfahrt-Fans" und es ist in deutsch.

Werner Büdeler ist Weltraumjournalist gewesen. Damals konnte man damit seine Brötchen noch verdienen. Was er machte, ist eine für das allgemeine Publikum angepasste Umsetzung des Buchs "Skylab: a Guidebook" der NASA. Ich denke das ist sehr gut gelungen. Ob es für den Personenkreis der meinen Blog liest, geeignet ist, wage ich zu bezweifeln. Das Buch ist gut, aber es ist aus einer anderen Zeit. er erklärt viele Sachen in einfachen Worten und geht daher nicht so sehr in die Tiefe. Die interessierte, aber nicht vorgebildete Allgemeinheit gibt es kaum noch, sondern nur noch Raumfahrthardcore-Fans die von einem Buch erwarten, dass dort mehr drin steht als sie schon durch Internetrecherche erfahren haben und eine überhaupt nicht an Raumfahrt interessierte Allgemeinheit. Englisch können heute auch die meisten, sodass man wenn man interessiert ist auch eher auf englischsprachige Bücher zurückgreift, die man vor 40 Jahren nicht im Bücherregal fand (Computerbestelölung oder gar Internet gab es ja nicht). Wer englisch kann findet die Vorlage bei der NASA zum lesen. Natürlich fehlt bei diesem Buch die Rettung von Skylab, die Ergebnisse und die Dramatik beim Weidereintritt.

Das zweite ist das Buch Homesteading Space, das auch mit der Zusammenarbeit mit zwei Astronauten entstanden ist. Ich halte es für das schwächste dieser Bücher, doch wird es sicher das Buch sein für die die an bemannter Raumfahrt interessiert sind. Es deckt zwar nominell das ganze Projekt ab, von den ersten Planungen für die Nutzung einer leeren Stufe als Übungsort im Weltraum, bis zu den Erkenntnissen die man gewann. Aber es ist alles aus der persönlichen Perspektive und eben eingeschränkt auf die Dinge in denen die beiden Astronauten involviert waren. Also erfährt man von einem frühen Test bei dem Kerwin probierte den Deckel des Treibstofftanks zu lösen (und scheiterte), aber sonst von den vielen Wirrungen und Unsicherheiten des Projekts wenig. Da war er eben nicht beteiligt. Das Hauptthema sind daher auch die Missionen und nach den Missionen, wenn es um einen Rückblick auf Skylab ging, ist es eben die Erfahrung der Astronauten die man bei der ISS einbringen sollte. Ergänzt wird das Buch durch Tagebuch von Alan Bean von seiner Mission als Faksimile und als Abschrift. Also wer wirklich an den Missionen interessiert sind, bei denen bei wichtigen Teilen sogar der Sprechfunkverkehr auszugsweise wiedergegeben ist, der sollte hier zugreifen. Daten und Fakten findet man wenig. Das Buch ist also sicherlich definitiv etwas für Fans von Astronauten und ihren Erlebnissen.

Das beste Buch dieses Dreipacks ist Skylab: America's Space Station. Es brachte auch mir am meisten für die Recherche. Shyler ist ein relativ fleißiger Autor der schon einige Bücher über bemannte Raumfahrt geschrieben hat. Ich hatte mir schon von ihm sein Buch über Gemini gekauft, war aber wegen dessen Aufbau doch enttäuscht. Er hatte offensichtlich Dokumente wie "Biomedical Results of Gemini" und hat daraus jeweils ein Kapitel gemacht, anstatt die Missionen chronologisch aufzuarbeiten. Diesen Fehler hat er bei diesem Buch nicht gemacht. Es geht chronologisch vor und beginnt mit den Plänen für das AAP, es folgen die Flugpläne für Skylab, die Selektion von Astronauten und ihr Training, dann die Missionen. Es folgt der Niedergang von Skylab und Pläne für Skylab B und eine Wiederverwendung. Im Anhang geht er kurz auf die Forschungsfelder ein und die Erkenntnisse von Skylab.

Es ist ein gutes Buch über das Projekt, nun mit einem externen Blickwinkel. Weniger aus der Ich-Perspektive geschrieben. Es enthält relativ viele Fakten, wenn auch wenige Zahlenangabe. Also wer sich über das Projekt als ganzes informieren möchte sollte zu diesem Buch greifen. Es ist leider etwas teurer, obwohl es nur als Paperback erhältlich ist. Für mich war es für die Recherche auch von den drei Büchern das nützlichste. Ein Manko an dem Buch ist seine recht bescheidene Druckqualität bei Grafiken, die ich aber schon bei einigen Büchern von Springer im Paperback-Format gesehen habe.

Zum Schluss noch eine Bemerkung zu zwei anderen englischsprachigen Büchern, die man bei Amazon findet. Ich kann nichts zu Around the World in 84 Days: The Authorized Biography of Skylab Astronaut Jerry Carr sagen, da ich mich weniger für Astronauten interessiere. Daher habe ich es nicht gekauft. Den Kauf von Living and Working in Space kann man sich sparen, es nichts anderes als eine Wiederauflage des NASA Buchs SP-4208 von 1983, dass man auch online lesen kann und das mir sehr nützlich für die Recherche war.

Wie passt nun mein eigens Werk Skylab: Amerikas einzige Raumstation da hinein? Nun ich habe wieder eine andere Perspektive. Während die anderen Bücher sich auf Astronuten und ihre Geschichte oder das Projekt als ganzes konzentrieren, liegt bei mir der Schwerpunkt auf der Raumstation, also der Hardware und den Experimenten, also wieder eine andere Perspektive. Wie gut oder wie schlecht es ist, diese Beurteilung überlasse ich anderen.


Sitemap Kontakt Neues Impressum / Datenschutz Hier werben / Your advertisment here Buchshop Bücher vom Autor Top 99