Home Site Map Sonstige Aufsätze Weblog und Gequassel counter

Web Log Teil 368: 22.1.2014 -

22.1.2014: Warum ist Raumfahrt so teuer?

Na ja zumindest meistens. Interessanterweise war das schon immer so. Als die NASA in den frühen sechziger Jahren, also kurz nach Beginn der Raumfahrt Ranger Raumsonden am Stück verlor erschien folgende Cartoon:

Eine Ranger Raumsonde kostete 28 Millionen Dollar. Davon entfielen 8,5 Millionen Dollar auf die Trägerrakete Atlas Agena B. Das Verhältnis ist also kein anderes als heute, obwohl damals erheblich mehr Träger produziert wurden. 1964, als der Comic erschien, starteten z.B. 18 Atlas Trägerraketen. Die Summe klingt gering, doch man muss die Inflation berücksichtigen und da sind die 28 Millionen von 1964 heute 211 Millionen Dollar wert. Das gesamte Ranger Programm kostete 260 Millionen Dollar, davon 170 Millionen Dollar für die Raumsonden.

Warum ist nun die Raumfahrt so teuer. Es gibt einige Gründe. Da sind zum einen mal bei Satelliten und allem was in den Orbit gelangt, die Bedingungen im All. Im Vakuum unter Schwerelosigkeit und mit starker Bestrahlung mit Sonnenstrahlung und energiereichen Teilchen braucht man andere Lösungen für viele Aufgaben wie auf der Erde. Kühlung und Temperaturregelung wird z.b. eine Herausforderung, Es gibt keine Luft die Wärme von der warmen zur kalten Seite transportiert. Elektronische Bauteile müssen energiereicher Strahlung widerstehen können etc. Doch dafür gibt es auch Lösungen die man entwickelt hat und heute einsetzt.

Der wichtigste Grund ist aber der, dass es keine Reperaturmöglichkeit gibt, bei Raketen keine Möglichkeit einer Notlandung wie bei einem Flugzeug. Wenn etwas versagt, so ist es meistens das Aus. Bedingt kann man sich Absichern durch Redundanz. Solarzellenarrays sind ao ausgelegt das einzelne Zellen ausfallen können, manchmal ganze Unterpanels, Computer sind redundant vorhanden. Drallräder meistens auch. Das ganze hat aber auch Grenzen. es gibt z.B. keine Trägerrakete (auch nicht Trägerraketen die mit Engine-out capabaility entwicklelt wurden, wie die Saturn I oder Falcon 9), bei denen ein Triebwerk in jeder Missionsphase ausfallen darf, z.B. direkt nach dem Start.

Die wichtigste Absicherung gegen Ausfälle ist es vor einem Start alles zu testen. Nicht nur den gesamten Satelliten, sondern jede Komponente, jedes Bauteil, jedes Pfitzelchen. Beim Apolloprogramm wurde mal bekannt das eine Schraube die verbaut wird insgesamt 11 Zertifizierungen hinter sich hat. Die erste beginnt schon bei der Mine in der das Eisenerz abgebaut wird. Man beschränkt sich also nicht darauf nur das Endprodukt "Schraube" zu prüfen, sondern beginnt bei den Rohstoffen. Das scheint überall so zu sein. eine Leuchte auf der ISS hat, wenn sie eingebaut ist ein Prüfprotokoll von 550 Seiten hinter sich. (Da wegen der extrem langen Projektlaufzeit der ISS der Hersteller keine neuen mehr fertigt, brauen die Astronauten übrigens aus den ATV und HTV welche dieselben Lampen einsetzen, diese aus um Ersatzlampen zu haben).

Kann man drauf verzichten? Man kann und eine Menge Geld sparen. Dann gibt es so rätselhafte Fehlstarts wie man sie von einigen russischen Trägern kennt, wie Fremdkörpern in Treibstoffleitungen, verkehrt herum eingebaute Beschleunigungssensoren, verunreinigter Treibstoff oder eine falsche Betankung einer Stufe. Man kann es auch zum Geschäftskonzept machen und ein Triebwerk nach 28 Tests und unter 3000 s Brennzeit für qualifiziert erklären. Ein Triebwerk ist schnell entwickelt und ein lauffähiger Prototyp ist schnell gebaut. Doch viel mehr Zeit braucht man um genügend Erfahrung zu gewinnen, alle Störsituationen zu simulieren und vor allem viel Prüfzeit zu akkumulieren, damit auch statistisch seltene Fehler vorkommen. Hätte man sich beim SSME mit 3000 s Testzeit zufrieden gegeben, die Shuttles hätten schon 1976 abheben können.

Der Ausfall von Missionen durch relativ einfache Ursachen wie defekte Transistoren hat zu einem Qualitätssicherungssystem geführt bei dem erheblich mehr kontrolliert, protokolliert und dokumentiert wird als tatsächlich gearbeitet wird. In wieweit dieses überzogen oder ausreichend ist, ist schwer zu entscheiden. Als die NASA mit dem Ansatz "Faster Cheaper, Better" neue Sonden und Satelliten entwickelte konnte sie die Kosten stark senken, musste aber zum ersten Mal seit 25 Jahren wieder mit dem Verlust von Sonden leben. Drei Raumsonden (Mars Climate Orbiter, Mars Polar Lander und Contour) gingen vor dem Ziel verloren, andere hatten andere gravierende Probleme, wie ein Harter Aufschlag der Landekapsel bei Genesis oder der Ausfall der Kameraverfolgung bei DS-1. Sie hat inzwischen diesen Ansatz wieder aufgegeben.

Ein Ansatz ist es zumindest viele Elemente, Module oder Baugruppen, wenn nicht ganze Satelliten, identisch zu entwickeln. Man muss dann zwar noch jedes Teil testen, aber man spart sich bei die Tests die überhaupt die Weltraumqualifikation beweisen. Diese sind nur beim ersten Exemplar nötig. So entstehen heute Kommunikationssatelliten aus kompletten Bussen, selbst bei wissenschaftlichen Satelliten wird dies heute schon eingesetzt. So wurden Mars Express und Venus Express billig, weil sie den Sondenkörper von Rosetta nochmals einsetzten (und auch Experimente die man schon entwickelt hatte).

Die Industrie versucht auch über en Tellerrand zu schauen und nicht mehr alles neu zu entwickeln. COTS heißt das Zauberwort und gemeint ist damit nicht das Transportprogramm zur ISS, sondern Commercial Off the Shelf Technologie, also Dinge, die kommerziell eingesetzt werden. Man erhofft sich hier viel vor allem bei Technologien die hohe Entwicklungskosten haben, wie Mikroelektronik. Nur für einige Hundert Prozessoren wird man keine Fertigung in einer Chipfabrik aufbauen, vor allem wenn die Fertigungsschritte andere sind, als bei der normalen Chipherstellung.

Russland hatte lange Zeit einen anderen Ansatz. Anstatt die Technik dem Weltraum anzupassen, versuchte man die Bedingungen am Boden herzustellen. russische Raumsonden hatten einen mit Stickstoff gefüllten druckdichten Körper bei dem ein Ventilator die Atmosphäre umwälzte. Die Zenit-Aufklärungssatelliten waren ausgeweidete Wostokkapseln mit einer Kamera vor dem Bullauge. Da die meisten russischen Raumsonden nicht lange lebten und es mindestens zwei Ausfälle gab, die auf diesen Mechanismus zurückzuführen waren, denke ich aber nicht, dass das System sich so gut bewährt hat.

Trotz allem scheint es noch enormes Einsparpotenzial zu geben. Glaubt man einem Blogkommentator "Jewgeni-7" so entwickelt Russland Methan-LOX Triebwerke, weil der Wasserstoff zu teuer ist - doch selbst der teure Wasserstoff macht bei den meisten Raketen nicht mal 1% der Gesamtkosten aus. Eine andere Persönlichkeit glaubt, da der Treibstoff nur 0,2% der Kosten und die Materialen nur 2% einer Rakete ausmachen, die Startkosten um den Faktor 100 senken zu können. Gut zu wissen, dass alle anderen 50 Jahre lang es falsch gemacht haben, das wäre sonst niemand sonst aufgefallen....

25.1.2014: Das NSA Protokoll

Der Arm der NSA ist lang, wie lang, das konnte man am Freitag sehen, als bei Wikileaks ein Transscript (Zusammenfassung eines mündlichen Vortrags) bei der NSA auftauchte und schon wenige Stunden später war das Dokument verschwunden. Offensichtlich kann die NSA nicht nur abhören sondern auch Inhalte kompromittieren.

Dank Browsercache kann ich euch trotzdem informieren. Das ich drauf kam war eigentlich mehr ein Zufall, denn ich suchte wieder mal nach neuen Infos über SpaceX und da war bei den hinteren Treffern auch dieser Link. Es geht um einen Vortrag von Emiliy Shanklin, Senior Director, Marketing & Communications bei SpaceX. Der Vortrag mit dem Titel "Public Relations - the SpaceX Way" ging um die Öffentlichkeitsarbeit von SpaceX und wie die NSA davon profitieren könnte.

Shanklin bedankt sich zuerst für die Einladung und erwähnt die "gute Zusammenarbeit" mit der NSA die SpaceX "mehr als 1 Milliarde Dollar" an Entwicklungskosten eingespart habe.

Nach einigen Einführungen, warum Public Relations für alle (auch die NSA) wichtig sei kommt sie zum Kernpunkt: Dem SpaceX Way of Public Relations und warum er auch für die NSA wichtig sei. Sowohl SpaceX wie auch die NSA seien weltweit bekannt, woraus sich eine Öffentlichkeitsarbeit ableite. Würde man diese unterlassen, so würden sich Gerüchte verbreiten, die nicht kontrollierbar seien. Diese könnten für eine Firma geschäftsschädigend sein, für eine staatliche Agentur noch desaströser und sie verwies auf Verschwörungstheorien und nannte als Beispiel die 911 Theorie des US-Angriffs auf die Twin-Towers. SpaceX wie auch NSA verbindet dabei dass Sicherheitsbedürfnis nicht viel über die Arbeit nach außen zu tragen, andererseits muss man genau dies bei einer Öffentlichkeitsarbeit tun.

Nun zum SpaceX Way: Das wichtigste ist es die Informationsabgabe zu kontrollieren. Es sollte nur so viel veröffentlicht werden, wie nötig. Als Beispiel nannte Shanklin die Life-Übertragungen von SpaceX Starts, die es in dieser Form bei keinem anderen LSP (Launch Service Provider) gibt. Das wirkt zum einen unheimlich progressiv, zum anderen ist es eine tolle Möglichkeit den Informationsfluss zu kontrollieren. Das fängt schon damit an, dass der ganze Start nicht in Realzeit übertragen wird, sondern 30 Sekunden zeitverzögert. Das erlaubt es bei einem unvorhergesehenen Ereignis auf eine andere der vielen Kameras umzuschalten die das Ereignis nicht zeigen oder bei einer Explosion den Stream abzubrechen (so geschehen beim dritten Falcon 1 Start).

Das zweite ist es so wenig wie möglich an Informationen zu verbreiten, was natürlich problematisch ist, wenn man Öffentlichkeitsarbeit betreibt. Es gibt jedoch einige Möglichkeiten diesen Spagat zu meistern. Das eine ist es Informationen zu veröffentlichen die nicht relevant sind. Auch hier verweist Shanklin auf den Webcast: Es zeigen diese Bilder nur die Rakete beim Aufstieg, sie enthalten aber keinerlei für Experten brauchbare Informationen wie Geschwindigkeit, Höhe oder Abweichung von der Aufstiegsbahn, wie sie z.B. Arianespace in ihren Life-Webcast einblendet. Mehr als das eine Rakete da gerade fliegt kann man nicht aus den Bildern ableiten.

Dokumente gibt es von SpaceX so wenige wie möglich, und wenn dann enthalten sie immer die gleichen Informationen nur etwas anders gemixt. Wenn man konkrete Werte nennen muss, dann in einer Maßeinheit die sie verschleiert, wie Brennzeiten in Minuten oder man lässt wesentliche Informationen weg, z.B. bei Nutzlastangaben die genauen Bahnparameter des Orbits. SpaceX  ist stolz dass nach mehreren Jahren nicht einmal Basisinformationen über ihre Programme nach außen gedrungen sind, trotzdem hält sie jeder für das innovativste Unternehmen in der Branche.

Der dritte wichtige Punkt ist Ablenkung. Um von Problemen, Verzögerungen oder unangenehmen Fragen abzulenken, ist es wichtig Alternativen zu präsentieren. SpaceX macht dies auf zweierlei Weise: Zum einen durch den CEO Elon Musk der dauernd medienpräsent ist, aber nie über aktuelle Projekte, nie über die Technik, sondern nur über erreichte Erfolge (neimals über Fehlschläge reden!) oder noch besser über die Zukunft, wobei die fernere Zukunft gemeint ist, also nichts was in einigen Jahren erreichbar ist. Bei SpaceX sind es die Wiederverwendungspläne und die Marskolonisationspläne.

Damit einem dies auch abnimmt, ist es wichtig, einige Alibiobjekte zu haben die wenig Geld kosten aber so aussehen als würde man diese Zeile ernsthaft zu verfolgen. Bei SpaceX ist dies das Grasshopper Programm (eine ausgediente Raketenstufe wird mit Treibstoff gefüllt und in die Luft geschickt und landet wieder - das hat natürlich gar nichts mit den wirklichen Herausforderungen der Wiederverwendung zu tun).

Wichtig ist es auch die modernen Medien zu nutzen. Sie haben für die gezielte Desinformation enorme Vorteile:

Niemand stört sich an nur kurzen Statements bei Twitter und Facebook, weil eh niemand mehr gewohnt ist längere Texte zu lesen.

Sollte diese Politik durch das Heraussickern von Informationen durchkreuzt werden, so muss man alles tun das Leck zu stopfen. Emily Shanklin nannte den Prozess gegen Hoe Fragola oder das Löschen des Webcastvideos beim CRS-1 Flug. Dies zeige auch wie wichtig es ist, auf die Einhaltung der Regeln zu achten, denn damals habe ein neuer Mitarbeiter das mit den 30 s Zeitverschiebung nicht gewusst und so sei der Triebwerksausfall bekannt geworden.

Für dei Kommunikation ist es auch wichtig eine eigene Sprache zu haben, die für Außenstehende nicht durchaubar ist und verharmlosend ist. Als Beispiel nannte Shanklin die Wortwahl bei Problemen:

Der absolut wichtigste Grundsatz sei aber, dass man die Informationen die jeder zur Verfügung hat begrenzt. Bei SpaceX gibt es nur wenige Akademiker. Sie alle müssen Verträge unterschrieben die sie auch nach dem Ausscheiden zur Verschwiegenheit verpflichtet. Trotzdem weis jeder nur über das Bescheid was er gerade bearbeitet. Drei viertel aller Beschäftigten sind ohne Ausbildung und werden nur an dem ausgebildet, was sie gerade machen müssen. Einen Edward Snowden, hätte es bei SpaceX nicht geben, resümiert sie. Selbst sie wüsste für öffentliche Statements genau so viel, wie sie weitergeben darf.

In der Fragenstunde zeigte sich dann, dass der Vortrag auf fruchtbaren Boden gefallen ist, denn die Anwesenden konnten sich gleich auf die Grundzüge einer neuen NSA-Terminologie einigen:

Man wird gespannt sein ob diese neue Terminologie in den nächsten Wochen auch auf der NSA Homepage zu finden ist.

26.1.2014: Warum gibt es so wenige Triebwerke die nach dem Hauptstromverfahren arbeiten?

... zumindest im Westen, denn in Russland gibt es viele. Zeit für einen Beitrag über die Grundlagen. Im Prinzip kann man das ja auch alles auf der Website nachlesen, doch wer macht das schon?

Fangen wir mal erst mal mit was Grundlegendem an: wie kommt der Treibstoff in die Brennkammer. Jedes Triebwerk das flüssige Treibstoffe einsetzt, muss diese (Treibstoff soll hier eine Sammelbezeichnung für Verbrennungsträger und Oxydator sein) gegen den Brennkammerdruck einspritzen. Dieser entsteht durch die Verbrennung des Treibstoffs, wenn aus Flüssigkeiten Gase werden.

Die einfachste Möglichkeit ist die Druckgasförderung, Dabei stehen die Treibstofftanks selbst unter Druck. Dieser Druck presst den Treibstoff in die Brennkammer. Mit vertretbarem Gewicht für dick Tanks beträgt bei Satelliten so der Tanndruck 20 bar, der Brennkammerdruck muss geringer sein, sonst klappt das Einspritzen nicht. Druckgas geförderte Triebwerk arbeiten daher mit niedrigem Brennkammerdruck typisch 8 bis 12 bar. Damit kann man sie kaum am Erdboden einsetzen, da hier schon der Außendruck 1 bar beträgt und die Brennkammer ist relativ groß, verglichen mit höheren Bremnnkammerdrücken bei gleichem Schub.

Die Lösung ist es den Treibstoff aktiv gegen den Brennkammerdruck zu fördern, das heißt einen Druck durch eine Maschine aufzubauen. Das älteste Verfahren ist das Nebenstromverfahren im englischen "Gas Generator Cycle" was auch die praktische Umsetzung beschreibt. Ein Gasgenerator (eine Brennkammer ohne Düse) erzeugt ein Arbeitsgas. Das Arbeitsgas treibt eine Gasturbine an, die über eine Welle eine Pumpe antreibt, das ganze ist meist ein Komplex und wird als Turbopumpe bezeichnet. Das Arbeitsgas wurde früher (A4, Redstone) extra erzeugt. Dazu wurde Wasserstoffperoxid katalytisch zersetzt, Gas also "generiert", woraus die Bezeichnung des Verfahrens herkommt. Heute üblich ist das Abzweigen eines Teils des Treibstoffs aus dem Fluss zum Triebwerk und Verbrennen im Überschuss einer Komponente, damit die Gastemperaturen in für Metalle ohne Kühlung erträglichen Maßen bleiben. Er kann beim Nebenstromverfahren dann aber nicht nochmal verbrannt werden.

Der Nachteil ist, das je höher der Brennkammerdruck ist (und er sollte zur Erhöhung des Wirkungsgrades hoch sein) man immer mehr Gas braucht. Das Arbeitsgas steht aber nicht mehr zur Verbrennung zur Verfügung. Irgendwann ist der Gewinn durch einen höheren Brennkammerdruck geringer als der Verlust an Treibstoff für den Antrieb. Das Optimum für Gasgeneratortriebwerke liegt bei etwa 90 bis 100 bar Brennkammerdruck.

Die Lösung für das Dilemma ist es diesen Gasstrom auch in das Triebwerk zu lenken. Da nun der Nebenstrom wegfällt nennt man dies das Hauptstromverfahren. Dabei gibt es zwei Verfahren. Das am Gasgeneratorverfahren angelehnte ist das Staged Combustion Verfahren, gestufte oder gestaffelte Verbrennung. Dabei wird ein Teil des Treibstoffs verbrannt, dieses Gas treibt die Turbopumpe an und wird mit geförderten Treibstoff eingespritzt. So kann man sehr hohe Brennkammerdrücke (170 bis 250 bar) erreichen. Das ganze klingt wie eine supertolle Lösung, doch die Anforderungen an die Technik sind gewaltig. Da die Gase beim Passieren der Turbopumpe an Druck verlieren arbeiten die Turbopumpen mit sehr hohen Drücken. Beim RS-25 treten Drücke von bis zu 423 Bar auf. Die Drehzahlen sind ebenso sehr hoch. Problematischer bei der Konstruktion ist, dass die Einzelteile mit einander verzahnt sind. Bei einem Nebenstromtriebwerk kann man Brennkammer, Turbopumpe und andere Subsysteme separat entwickeln und auch austauschen. Änderungen wirken sich selten auf das Gesamtsystem aus. So hat man beim J-2X die Turbopumpe des J-2S durch die des Aerospike Triebwerks ersetzt. Beim Hauptstromtriebwerk geht dies nicht und die Probleme beginnen schon beim Anlassen. Bei einem herkömmlichen Triebwerk startet man den Gasgenerator entweder durch ein Startgas oder eine Gas bildende Kartusche (z.B. Feststofftreibstoff) und öffnet die Treibstoffventile, der langsam auf Turen kommende Gasgenerator fördert den Treibstoff, und baut den Brennkammerdruck auf, er wird dann konstant gehalten weil ein konstanter Teil des Treibstoffs durch den Gasgenerator strömt und dieser so einen konstanten Gegendruck erzeugt und eine konstante Treibstoffmenge fördert.

Bei dem Hauptstromtriebwerk erzeugt ein Vorbrenner das Arbeitsgas, dass nun die Turbine auf hohe Drehzahlen bringt. Sie kommt innerhalb eines Sekundenbruchteils auf ihre Nenndrehzahl weil der Vorbrenner nur mit Tankdruck arbeitet, also von Anfang an schon die immer gleiche Treibstoffmenge fördert und nicht erst langsam hochläuft, doch es gibt noch kennen Gegendruck von der Brennkammer. Die muss nun einen Sekundenbruchteil (beim SSME: 0,1 s) später zünden, sonst würde die Rotationsgeschwindigkeit der Blätter zu hoch werden und sich die Turbine zerlegen. Zündet sie zu früh, so ist die Turbopumpe noch nicht hochgelaufen und der Gegendruck treibt heißes Verbrennungsgas in sie und sie schmilzt. Beim SSME dauerte es Monate nur um die ersten 3 s der 4,7 s langen Startsequenz bei den Tests zu erreichen.

Das zweite Verfahren, das Expander Cycle oder Bootstrap Cycle. Es ist vom Aufbau her das einfachste Verfahren: Eine Komponente des Treibstoffs, die mit dem niedrigeren Siedepunkt wird zum Teil zuerst durch die Brennkammerwand geleitet, verdampft dort und erzeugt das Arbeitsgas für die Turbopumpe, die nun die zweite Komponente und den Rest des Treibstoffs fördert. Das klingt einfach und ist es im stationären Zustand auch. Das Problem ist auch hier das Anlassen. Dann hat die Brennkammerwand noch nicht die hohen Temperaturen. Dazu gibt es verschiedene Lösung z.B. einen Tank mit Startgas der zuerst die Turbopumpe antreibt damit diese anläuft und die Brennkammer gezündet werden kann. Erzeugt diese erst mal Hitze, dann reicht das erzeugte Arbeitsgas für den Betrieb aus. Da das Gas erst die Turbopumpen erreicht wenn es schon vorher die Brennkammerwand durchlaufen hat, baut sich der Druck langsam auf. Um Kavitation zu unterdrücken, war es bei den ersten Konstruktionen üblich eine Vorpumpe direkt nach dem Tank zu schalten die die Leitungen auf einen höheren Druck setzte. Diese wurde mit einem Gasgenerator angetrieben. Bei modernen Konstruktionen reicht der Tankdruck alleine aus. Die Grenzen des Expander Cycle liegen in zwei Limitationen: Der Treibstoff muss leicht verdampfbar sein und sich nicht zersetzten. In der Praxis wird es nur mit Wasserstoff eingesetzt. Das zweite ist, das der Treibstoff muss genügend Energie aufnehmen muss, um zu verdampfen und genügend Druck für die Turbinen zu bilden. Da je größer ein Triebwerk wird, seine Oberfläche im Verhältnis zum Schub abnimmt, eignet sich das Verfahren nur für kleine bis mittelgroße Triebwerke.

Es gibt noch ein drittes Verfahren, das aber soweit ich weis in keinem eingesetzten Triebwerk genutzt wird: Es ist das Topping oder Bleeding verfahren. Dabei wird aus den heißen Gasen der Brennkammer ein Teil abgezapft und für den Antrieb der Turbine genutzt.

Gibt es nun das optimale Verfahren? Das Expander Cylce Verfahren eignet sich wegen des geringen Schubs nur für Oberstufen, ebenso die Druckförderung, Gasgenerator oder Staged Compustion Verfahren eignen sich auch für Erststufen. Zumindest bei Wasserstoff als Treibstoff sind wegen der hohen Fördervolumina die Anforderungen beim staged Compustion Verfahren deutlich höher als beim Gasgeneratorverfahren. Das zeigte sich sowohl bei der Entwicklung entsprechender Triebwerke in Russland wie den USA. Dagegen baut Russland seit Mitte der sechziger Jahre vorwiegend Triebwerke mit lagerfähigen Treibstoffen und dem Staged Combustion Prinzip während man im Westen meistens das Gasgeneratorverfahren nutzt. Allerdings sind hier durch die höhere Dichte die Anforderungen auch geringer als bei der Verwendung von Wasserstoff und die Entwicklung der LOX/LH2 Triebwerke für die Energija (RD-0120) gestaltete sich in Russland genauso aufwendig wie die SSME.

27.1.2014: Die Crux eines Landers / Rovers

Vor wenigen tagen konnte Opportunity seinen zehnten Geburtstag auf dem Mars feiern. Das ist sehr lange, alle Systeme haben längst ihre Designlebensdauer übertroffen. Zuallererst natürlich der Rover der nur drei Monate arbeiten sollte (eine Prognose basierend auf Pathfinder bei dem Staub innerhalb dieser kurzen Zeit zur Abnahme der Leistung der Solarzellen führte - glücklicherweise verstauben die höher abgebrachten Solarpaneele der Rover weniger und sie werden ab und an durch Windhosen gereinigt), dann Fahrwerk und auch Instrumente, auch wenn einige wie das RAT nicht mehr nutzbar sind. Trotzdem kommt Opportunity kaum in den Nachrichten vor, anders als der inzwischen auch Zehn Jahre den Mars umkreisende Maes Express.

Warum? Es ist die Crux der Lander, aber jedes Rovers: Während ein Orbiter in den meisten Fällen den ganzen Planeten überfliegen kann und so Dinge an verschiedenen Orten entdecken kann (mit hochauflösenden Kameras wie an Bord des MRO sogar Veränderungen wie Sanddünen, Hangabrutsche oder abgetautes Eis) verändert sich die Landschaft am Boden nicht. Ein Rover kann zwar sich vom Landeort entfernen, doch wenn er wie Opportunity inzwischen 35 km weit gefahren ist. Er ist in einer weiten Ebene gelandet und bis auf einige Einschlagskrater sieht die auch in einigen Kilometern Entfernung noch gleich aus.

Das mag nun für die Bilder gelten, doch wie sieht es beiden anderen Instrumenten aus? Etwas besser, aber nicht fundamental. Man kann mit Spektrometern oder direkten Probennamen die chemische Zusammensetzung einzelner Steine oder Felsen bestimmen. Solche  mit einer vom Rest abweichenden Zusammensetzung kann man auch in einer Schwemmebene finden, entweder durch frühere Fluten mitgetragen oder durch Einschläge aus dem Untergrund freigelegt und sie können von dem sonst gleichförmigen Material abweichen. ansonsten zeigte sich der Landeplatz von Opportunity mehr oder wenig auch chemisch eintönig, was jetzt nicht so verwunderlich ist, es war ja mal ein überschwemmtes Gebiet, da haben die fluten die Sedimente überall gleich verteilt.

Doch ohne Tektonsiche Aktivität wird die Zusammensetzung der meisten Gebiete nicht groß variieren sein. Mehr Variation wird man in Gelände erwarten das durch Naturgewalten verändert wurde, auf dem Mars wären dies das Valles Marineris oder das chaotische Gelände, doch aus Sicherheitsgründen wird man dort nicht landen können.

Was folgert daraus: die Forderung nach mehr Mobilität. So wie es bisher läuft wird es nicht gehen. Heute bewegt sich ein Rover nur einige Meter, wenn das Gelände absolut flach und ohne Hindernisse ist auch bis zu 100 m. Danach wird von der Bodenkontrolle eine neue Route auf Basis der ermittelten Aufnahmen ermittelt. Damit man von einem sicheren Landeplatz zu einem interessanten, aber riskanten Gebiet aufbrechen kann wird man aber viel größere Strecken zurücklegen müssen. Dafür muss der Rover viel autonomer sein und selbst die beste Strecken finden können. Es besteht Hoffnung das man dieses Problem lösen kann, den für das Militär werden Roboter entwickelt, die genau das können müssen. Ob man aber dass Regime ändert? Ich wette spätestens wenn man in unwegsamen Gelände angekommen ist wird es vorbei mit der Autonomie sein. Früher war man da optimistischer, wenn ich da in ein älteres Buch schaue finde ich dort den Vorschlag für einen Post-viking Rover der täglich bis zu 500 m und in 6 Monaten 50 km zurücklegt - mehr als Opportunity in 10 Jahren schaffte....

Die Lösung könnte es sein in die Luft auszuweichen. Doch das ist gerade beim Mars sehr schwierig. Der Bodendruck ist bei Normal-Null (es gibt ja keine Meeresoberfläche) bei 6,1 mb - einem 160-stel des irdischen auf Meereshöhe Das macht sowohl das Segeln (mit oder ohne antrieb) wie auch Ballons schwierig. Die Dichte der Atmosphäre liegt im Mittel so hoch wie auf der Erde in 30 bis 34 km Höhe. Um dorthin zu gelangen braucht man riesige Ballons mit Helium gefüllt, was auf dem Mars ausscheiden wird, dort denkt man eher an Segler oder Heißluftballons (Solarballons). An der Umsetzung habe ich meine Zweifel.

Eher umsetzbar dürfte es auf dem Titan sein, auch wegen der großen Dichte. Da man nicht richtig durch die Atmosphäre schauen kann wäre dort ein Lander auch sinnvoll, aber es ist auch aufwendig dorthin zu kommen, auch wenn die Landung ziemlich einfach ist, wie auch Huygens bewies.

Trotzdem sind weitere Lander geplant. Das europäisch-russische Exomarsprojekt (falls es mal dazu kommt), 2016 Insight, ein stationärer Lander, ähnlich Phoenix und 2020 oder 2022 ein Nachbau vom MSL. Alles was nach 2016 geplant ist muss man als offen ansehen, so findet man auf den NASA Webseiten z.B. noch die Beteiligung an Exomars, obwohl da die NASA letzte Jahr ausstieg.

28.1.2014: Warum gibt es so viele Programmiersprachen?

Zuballerst bitte ich um Entschuldigung: Für die Vereinfachung. Das mache ich immer, schließlich richtet sich der Blog an die (interessierte) Allgemeinheit, doch bin ich mir sicher das bei Raumfahrt und Chemie / Ernährung nur wenige Experten mitlesen. Bei diesem Thema ist es anders, vor allem gibt ex da viele selberernannte Experten und meistens kommt dann auch nach dem zweiten Kommentar die fruchtlose Diskussion auf: "Welche Programmiersprache ist die beste". Doch darum geht es nicht, sondern warum gibt es so viele Sprachen.

Als ich mich für Computer interessierte, gab es schon Dutzende von Programmiersprachen, heute sind es noch viel mehr. Ich wage zu behaupten es gibt mehr Programmiersprachen als es Rechnerarchitekturen gibt. Aber fangen wir an es mal genauer zu beleuchten. Ich meine es gibt mehrere Gründe.

Grund Nummer 1: Es gibt so viele Programmiersprachen weil man immer leistungsfähigste Konstrukte entwickelt hat.

Oder anders ausdrückt: genauso wie sich die Hardware weiter entwickelt, so entwickeln sich auch die Softwaretechnik weiter, wobei dies Hand in Hand geht, denn mit den ersten Rechnern hätte man sicher kein System wie ADA laufen lassen können.

Anfangs gab es gar keine Programmiersprachen: die Programmierer gaben die Maschinensprache in binärer Form ein. Jedes Bitmuster stand für einen Befehl oder einen Daten/Adresswert. Die erste Verbesserung war der Assembler bei dem man für die Befehle einigermaßen verständliche Wörter ausdachte wie "Add", "Mov" oder "JMP" für Addiere, Bewege oder Springe. Bis heute gilt: Mikroprozessoren verstehen nur sehr einfache Befehle. Der Assembler brachte noch eine weitere Verbesserung: Man konnte Konstanten und Variablen definieren und er kümmerte sich um die Adressberechnung denn bei Verzweigungen oder wenn Daten eingeladen werden sollten musste man Adressen angeben.

Die ersten höheren Programmiersprachen wie COBOL und FORTRAN boten eine höhere Abstraktionsebene. Man konnte und mathematische Formeln direkt eingeben, ohne sich darum zu kümmern wie der Prozessor sie berechnet. Damit waren sie zum ersten Mal unabhängig von der verwendeten Hardware. Was FORTRAN oder COBOL von den nachfolgenden Sprachen unterschied war, das beide spezialisiert waren. COBOL eignete sich hervorragend zur formatierten Datenverarbeitung wie sie bei Versicherungen, Lohnabrechnungen oder anderen betriebswirtschaftlichen Abläufen vorkommt. Gerüchteweise sollen einige BW-Ausbildungen auch COBOL Kurse enthalten. Mit  FORTRAN konnte man dagegen vornehmlich Berechnungen vor allem naturwissenschaftliche spezialisiert. Beide kannten nicht die Typisierung von Daten, man gab bei einer  FORTRAN Routine z.B. nur die Parameter an, nicht welchen Datentyp sie hatten und in der ursprünglichen Form keine Möglichkeit für strukturierte Programmierung also bedingte Schleifen. Stattdessen wurde mit GOTO im Programm herumgesprungen.  FORTRAN und COBOL waren Programmiersprachen für einen bestimmten Einsatzzweck. Das ist zwar immer gegeben, doch sie waren schon sehr eingeschränkt. Mit COBOL würde man keine mathematischen Probleme angehen (es gab die Grundrechenarten, aber nichts weitergehendes) und die Fähigkeiten von  FORTRAN Text zu verarbeiten sind doch sehr beschränkt. (der Datentyp Char wurde erst später eingeführt). FORTAN hatte anfangs sogar keine mit der Backus-Naur form definierte Grammatik. Das bewirkte bei der Raumsonde Mariner 2 einen Totalverlust, da eine Zeile wie

DO 15 I = 1.100

im Quelltext stand und da stehen sollte:

DO 15 I = 1,100

Das letztere Stand für eine zählende Schleife bei der I von 1 auf 100 hochgezählt wurde und der Schleifenblock wurde mit Anweisungsnummer (Zeilennummer) 15 beendet.

Der Compiler meldete dies jedoch nicht als Fehler, da (zumindest damals) Leerzeichen nicht als Trenner betrachte und der Punkt für den Dezimalpunkt ansah war für den Compiler die Zeile gleichbedeutend mit

DO15I=1.100

Also Zuweisung des Wertes 1.1 an die Variable DO15I ....

Die nächste Generation waren Sprachen die geeignet waren verschiedenste Problemen auf algorithmischem Wege zu lösen, also mit einer Lösungsvorschrift die man auch umfangssprachlich formulieren kann. Dazu gab es Schleifen wie die While Schleife "Mache etwas so lange ... gegeben ist" oder Repeat Schleife "Wiederhole solange bis ..." anstatt den Gotos die vorher dominierten. Dazu gehöre auch das es nun nicht nur die elementaren Datentypen des Prozessors gab sondern neue wie Teilbereiche (für Jahreszahlen sollte vielleicht ein wert von 2178 nicht zulässig sein) zusammengefasste Daten (die Bestandteile einer Person sind Name, Vorname, Telefonnummer etc...).

Dazu gehören eine Reihe von Programmiersprachen. Stammvater ist Algol, wichtige Ableger sind Pascal und C.

Eine Frage, die sich spätestens jetzt auftut ist: Warum hat man nicht einfach  FORTRAN erweitert. Ich denke es sind drei Gründe die dafür verantwortlich sind. Das eine ist das sobald eine Sprache etabliert ist, d.h. weit eingesetzt wird, es sehr schwer ist an der bisherigen Syntax zu ändern Denn damit würde die alte Software nicht mehr laufen. Selbst wenn alle sich einig sind, das die bisherige Syntax Scheisse ist. Ein Paradebeispiel ist die Stringverwaltung von C. Die Länge eines Strings wird durch ein Nullbyte festgelegt und wenn man nicht ganz genau aufpasst kann man mit einem zu langen String für den man nicht den Platz vorgesehen hat, wichtige Daten überschreiben. Darauf beruht ein Angriff auf Software, der sogenannte Buffer-Overflow beim dem Strings Code überschrieben und so Schadcode einschleusen. Heute legen Compiler Prüfdaten auf den Stack um eine Veränderung festzustellen, aber die Stringverarbeitung von C wurde nie geändert.

Bei FORTRAN sieht man dies deutlich. Dem ersten Compiler im April 1957 folgten bald FORTRAN II bis IV in vier Jahren bis 1961. Der nächste Standard wär dann  FORTRAN 66. Nach weiteren 11 Jahren folgte  FORTRAN 77 und nach 13 Jahren FORTRAN 90. Danach ging es dann wieder schneller mit FORTRAN 95,2003 und 2008. Das spiegelt dann auch den Rückgang in der Verbreitung wieder, denn je weiter eine Sprache verbreitet ist, desto mehr wollen bei neuen Features mitreden.

Anstatt das jemand seine Ideen in einem Komitee einbringt und Jahre wartet bis sie umgesetzt werden, ist es meist so, dass er eine eigene Sprache kreiert. Das ist möglich, weil eine Programmiersprache letztendlich Software ist und wie jede andere Software kann sie entwickelt werden. Ich selbst habe schon eine Programmiersprache für entwickelt und dann noch zweimal in modifizierter Form eingesetzt. Es gibt sogar Tools wie LEX und Yacc die einem einen Teil (das Parsen des Quelltextes) abnehmen. Wenn man ein völlig neues Konzept kreieren will das es so noch nicht gibt wie regelbasierte Programmierung (Prolog) Objektorientierung in reiner Form (Smalltalk) so kommt man gar nicht um diesen Schritt herum. Bei dem einbetten in vorhandene Programmiersprachen muss man dann zu viele Kompromisse eingehen. So ist reine Objektorientierung schwer möglich wenn die Programmiersprachen auch Datentypen kennt die nicht vom Basistyp Objekt abstammen. Eine regelbasierende Programmiersprache die keinen linearen Ablauf kennt sondern Backtracking verwendet wird man schlecht mit einer prozeduralen Sprache mit einem linearen Ablauf verheiraten können.

So, morgen geht es dann weiter mit weiteren Gründen....

29.1.2014: Weitere Gründe, warum es so viele Programmiersprachen gibt

Eine ganze Menge Programmiersprachen entstanden, weil man sie nur in einer bestimmten Softwareumgebung braucht. Die ersten Programmiersprachen waren zum einen kompiliert, erzeugten also Maschinencode. Zum anderen waren sie für die Entwicklung von Stand-Alone Anwendungen gedacht. Mit einem zweiten Konzept, des Interpreters konnte man dagegen eine Programmiersprache in jedes Programm einbauen. Bei einem Interpreter wird der Quelltext on the fly übersetzt und daher gibt es hier auch die Möglichkeit Funktionen eines Systems aufzurufen in das die Programmiersprache eingebettet ist. Ein Großteil der Scriptsprachen entfällt in diese Kategorie wie die ganzen Shell-Scripts, aber auch in komplexer Software integrierte Sprachen wie die in Matlab oder R in Statistikpaketen.

R ist auch inzwischen eine eigenständige Programmiersprache gehört aber zu den "Special Purpose" Sprachen. Während Sprachen wie Pascal, C oder Java den Anspruch haben sich für eine breite Anwendung zu eignen. wenn auch nicht für jede gleich gut, ist eine Special Purpose Sprache eine die bestimmte Feature hat die man nur für bestimmte Anwendungen braucht, dann sind sie aber sehr nützlich. R hat z.B. als elementaren Datentyp das Array nicht Skalare. Sinnvoll wenn man Statistik betreibt also große Datenmengen auswertet. Bei Pearl hat man eine Skriptsprache rund um die regulären Ausdrücke herum gebaut. APL ist eine Sprache für Mathematiker die nicht mal in einer Programmiersprache von ihren geliebten Symbolen lassen wollen. Alle drei - wen verwundert es - sind interpretiert.

Eine andere Intention für eine neue Sprache sind veränderte Anforderungen. Mit dem Auftauchen des Internets kommunizierten plötzlich Computer auf der ganzen Welt miteinander. Vorher tauschte man Daten aus oder hatte statische Informationen in HTML. Doch wie realisiere ich eine Anwendung die auf dem Zielcomputer Daten eines Servers braucht oder interaktiv ist, ohne das der Anwender jedes Mal eine Anwendung installiert und damit sie auf jedem Rechner läuft und nicht nur auf dem PC unter Windows. Es entstanden mindestens drei Ansätze dieses Problem zu lösen. PHP ist eine Scriptsprache die man in HTML einbetten und mixen kann. Die Ausgabe erscheint dann da wo der PHP Quelltext im HTML steht. Zur Ausführung braucht man ein Modul auf dem Server, der also die ganze Arbeit hat (ein Grund warum der Blog deutlich langsamer als die Webseite ist). Javascript macht das gleiche nur im Browser, verlagert also die Arbeit auf die Clients was eigentlich besser ist, doch dafür muss der Browser auch die Sprachfeatures verstehen was in der Anfangszeit problematisch war, weil Microsoft und Netscape jeweils ihre eigenen Süppchen kochten. Java entwickelt als vollwertige Programmiersprache für Anwendungen die vom Microcontroller bis zum Großrechner alles abdecken sollte, erlaubte es die Arbeit aufzuteilen - sie konnte vollständig auf dem Client laufen, auf dem Server oder verteilt. Das Konzept hat sich nicht durchgesetzt. Java erweis sich als zu viel Speicher verbrauchend, zu langsam und obwohl als da in einer eigenen virtuellen Umgebung ablaufend, als sicher angepriesen, gilt Java neben Adobe Produkten heute als ein Einfallstor für Schadsoftware,.

Java führt mich zur letzten Gruppe: Den Firmenstandards. Denn als Microsoft seine selbst veränderte Java-Engine aufgrund eines Prozesses von Sun nicht mehr ausliefern dürfte entwickelten sie einfach ihren Java-Clone - nur ein bisschen besser: C#. Es ist nicht der erste Firmenstandard. Microsoft hatte auch BASIC für Microcomputer adaptiert. Das Microsoft-BASIC wurde zum Standard, mit der Folge das jeder diese fürchterliche Implementation mit dem Spagetti Code für BASIC hielt - dagegen wehrten sich die Erfinder von BASIC erfolglos. Google musste als Folge natürlich auch eine eigene Sprache kreieren, nämlich Go. Firmenstandards haben Vor- und Nachteile. Der Vorteil ist, das eine Firma eine Sprache schneller weiter entwickeln kann, als wenn man immer mit einem Gremium alles abstimmen muss. Paradebeispiele sind die Entwicklung von BASIC durch Microsoft oder Pascal durch Borland. Der andere ist, dass man nun natürlich auch auf Produkte dieser Firma angewiesen ist.

In der Summe wird es wohl immer mehr Programmiersprachen geben. Auch weil immer neue Konzepte auftauchen. In den Sechzigern war es die Strukturierte Programmierung und die Typisierung von Daten, in den Siebzigern die Objektorientierung, die es enorm erleichterte, Code wieder zu verwenden und Probleme zu abstrahieren.  Schon hier gab es aber den Bruch: erfolgreich wurden nicht Sprechen die vollständig objektorientiert waren wie Smalltalk, sondern Sprachen die Objektorientierung mit dem vorigen Modell verheiraten wie C++. (Ob dies angesichts der Fehler von C so sinnvoll ist sei mal bezweifelt).

Doch nicht immer braucht man alles, weshalb Dinosaurier wie FORTRAN noch heute eingesetzt werden, auch weil man bestehende Programme zwar erweitert, aber selten in eine neue Sprache umschreibt. Vor allem kann es auch nicht "die Sprache" geben, schon alleine weil es zu viele grundlegende Konzepte gibt. Es gibt mindestens drei unterschiedliche Ansätze:

Je nachdem welche Problemstellung man hat, wird eine der Gruppen besser geeignet oder schlechter geeignet sein. So wird es auch in Zukunft immer mehr Sprachen geben. ich muss auch sagen ich will nicht die Programmiersprache die alles kann, denn dann wird sie auch unhandlich und schwerfällig. Man kann in Maßen Funktionalität in Bibliotheken auslagern aber wenn eine Sprache schon in den Kernfeatures viel können muss, ist auch der Kern entsprechend groß. Darüber hinaus gibt es natürlich noch die technischen Grundgegebenheiten, Java hat diesen Spagat versucht, vom Microcontroller bis zum Server auf allen Systemen zu laufen, ob im Browser oder als Standalone Anwendung und ist daran gescheitert.

 


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