Nach den Jahren des Kalten Krieges stehen der ?NASA nun nicht mehr unbegrenzte Mittel zur Verfügung. Sowohl Zeit als auch Geld sind sehr knapp. Daher änderte sich die Strategie der ?NASA zu "faster / better / cheaper". Statt wie bisher für einzelne Projekte bis zu 10 Jahre zu benötigen und dabei immense Kosten zu verursachen, versuchte man ein Projekt mit erheblich weniger Zeit und erheblich weniger Kosten auf die Beine zu stellen. So hatte Pathfinder "nur" ein Budget von 150 Millionen Dollar (es hat letztendlich ca. 170 Millionen Dollar verschlungen). Der Zeitplan des gesamten Projekts war auf 3 Jahre beschränkt.

Daher mussten die Ingenieure abwägen, was selber entwickelt und gebaut werden sollte und was gekauft wird. Eigenentwicklungen sind meist leistungsfähiger, besser angepasst und vor allem zuverlässiger, allerdings auch entscheidend teurer! Militärische Ausrüstung ist zwar zuverlässig und robust genug, aber zu gross, zu schwer und zu stromintensiv für Weltraummissionen. Ausserdem ist sie auch nicht gerade billig. Kommerzielle Systeme sind relativ günstig zu bekommen, in ihren Anforderung meist bedeutend genügsamer, wenn auch nicht so robust. Letztendlich wurden z.B. alle Radios des Kommunikationssystems zugekauft und für die Mission lediglich noch modifiziert. So wurde auch das Betriebssystem für den Roboter Sojourner zugekauft. Man entschied sich für das ?Echtzeitbetriebssystem VxWorks von Windriver.

Das Ziel der gesamten Mission war dreigeteilt:
Es sollte zum einen eine neue Landetechnik erprobt bzw. deren Tauglichkeit für den Einsatz auf anderen Planeten gezeigt werden. Man wollte zum ersten mal in der letzten Landephase nicht auf Fallschirme oder Raketen gesetzt werden, sondern auf Luftsäcke. Das Landemodul pumpt nach dem Abbremsvorgang durch Fallschirme und Raketen in der Atmosphäre Luftsäcke auf, die das Modul vollständig umgeben, und landet daraufhin ungebremst auf der Planetenoberfläche.
Zum anderen sollte gezeigt werden, dass die "faster / better / cheaper"-Strategie wirklich funktioniert.
Und schließlich sollten der Lander und die Drone Bilder der Umgebung aufnehmen, geologische Proben nehmen und vor allem meteorologische Daten sammeln, um Grundlagen für zukünftige Missionen zu schaffen. Die Dauer des Projektes war auf ca. 7 Tage bis max. 1 Monat festgelegt. Danach wären die Batterien der Drone erschöpft, so dachte man. Alles darüber hinausgehende wäre "fein" gewesen. Die Mission dauerte letztendlich 3 Monate und war ein voller Erfolg.

Die gesamte Mission besteht im Prinzip aus 5 Teilen:

• der Transport-Rakete aus dem Erdorbit (Bild 1)
  
• einem Antriebsmodul für den Flug zum ?Mars (Bild 2)
  
• einem Hilfsmodul welches Bremsraketen und -fallschirme für den Lander bereitstellt (Bild 3)
  
• und letztendlich dem eigentlichem Lander (Bild 4)
  
• mit der darin enthaltenen Drone (Bild 4)

Das System wurde von einem PowerPC, einem gegen Strahlung geschützten IBM RAD6000, kontrolliert und gesteuert. Damit war der Lander das rechenstärkste Gerät, dass das ?JPL jemals ins All geschossen hatte. Als Betriebssystem wurde VxWorks von Wind River eingesetzt. Die Kommunikationsprotokolle etc. wurden vom ?JPL selber entwickelt.

Die Jet Propulsion Laboratories (?JPL) konstruierten ein völlig neues Modell, welches in der Lage war, nur aus eigenem Antrieb extrem holpriges Terrain zu überqueren, ohne die Unebenheiten auf den Rover selbst zu übertragen. So war das Fahrzeug in der Lage, Hindernisse bis zum anderthalbfachen seines Raddurchmessers einfach zu überrollen. Auch sollte er sich selbst bei großen Neigungen waagrecht halten können, um nicht die solare Energieversorgung oder die Durchführung der hochentwickelten chemischen und biologischen Experimente zu gefährden. Doch das größte Problem stellte die Steuerung des Gefährts dar: Die Entfernung zur Erde würde sehr groß sein (circa 20 bis 30 Lichtminuten), so dass eine direkte Steuerung so gut wie unmöglich wäre. Daher begann man erste Tests mit intelligenten, eigenständig handelnden Robotern durchzuführen: Erst wurde ein kleines Vehikel mit noch einfacher KI namens Tooth entwickelt, dann Rocky und Rocky 2 und schließlich Rocky 3, welcher in der Wüste sehr gute Ergebnisse vorlegte. So entschloss sich das Pathfinder-Team, auf Grundlage dieser Entwicklungen einen eigenen Rover zu entwerfen. Eine Version des Rocky 3 stellte die Basisversion dar, doch wurde das System von 25 auf 7 Kilogramm abgespeckt und mit moderneren Geräten ausgestattet, beispielsweise einem zigarettenschachtelgroßen Seismometer (welches allerdings später kaum stärkere Marsbeben feststellen sollte). Tests des Vehikels in der Wüste verliefen sehr erfolgreich, der sechsrädige Roboter nahm eigenständig Gesteinsproben und führte Untersuchungen durch.
Doch erst durch einen glücklichen Umstand wurde es offiziell beschlossen, einen Rover in die Konfiguration der Sonde mitaufzunehmen und damit neben technischer Forschung ("faster / better / cheaper") auch wissenschaftliche Forschung durchzuführen, denn deutsche Raumfahrtwissenschaftler boten an, einen am Mainzer Max-Planck-Institut entwickelten Alpha-Proton-Röntgenspektrometer (APXS) zu liefern. Zur Freude der Geologen wurde der Vorschlag angenommen und das APXS neben - ebenfalls in Deutschland entwickelten - Kameras, einer Wetterstation und anderen Instrumenten in die Sonde eingebaut. Doch um das Gerät sinnvoll einzusetzen, musste man es direkt an die Steine heranführen und dazu war eben nur ein Rover geeignet. Damit war der Weg für Sojourner endgültig geebnet.

Als Recheneinheit wurde ein ?80C85-Prozessor gewählt. Dieser ist zwar relativ langsam, aber dafür vor allem sehr stromsparend, was bei der mobilen Einheit trotz einem kleinen Sonnensegel sehr wichtig war. Auch Sojourner wurde übrigens mit dem ?Echtzeitbetriebssystem VxWorks von Windriver betrieben.

Auf der Erde blieb eine exakte Kopie des Sojourners namens "Marie Curie" zurück. Der Hintergedanke war, evtl. auftretende Probleme beim Sojourner auf dem Mars anhand der Kopie direkt nachzuvollziehen und so eine schnellere und bessere Lösung zu finden. Dies erwies sich - wie sich später rausstellte - als gute Investition.

Nach einer siebenmonatigen Reise trat die vom Flugmodul abgetrennte Landeeinheit mit über 7500 m/s in 125 km Höhe in die Mars-Atmosphäre ein. Noch vor der Abtrennung des Hitzeschildes werden die Fallschirme geöffnet. Diese bremsen das gesamte Modul im Verlauf der nächsten 4 Minuten auf ein 10tel der ursprünglichen Geschwindigkeit herab. Nach dem Abwurf des Schildes beginnt Pathfinder den Boden nach einem geeigneten Landeplatz mit Radar abzusuchen. Mit Hilfe der Bremsraketen dann wird das Modul auf max. 25m/s herabgebremst. Kurz vor der Landung dann werden die Luftsäcke aufgeblasen. In einer Höhe von ca. 30 Metern wird der Lander dann vom Anflugmodul getrennt und stürzt ungebremst zu Boden.

Nach dem Aufprall flog Pathfinder noch fast 2,5 Meilen, bis er seinen Landeplatz letztendlich erreichte. Dort wurden die Säcke wieder zusammengezogen, das Landemodul in die richtige Position geschubst und die Ladeklappen geöffnet. Hierbei trat dann das erste Problem auf. Eine der Rampen konnte nicht geöffnet werden, da sich einer der Luftsäcke im Öffnungsmchanismus verklemmt hatte. Sojourner nutze daraufhin aber einfach die zweite, welche sich zuverlässig geöffnet hatte.
Auch unmittelbar nach der Landung begann sich die Hochleistungsantenne mithilfe der Position der Sonne in Richtung Erde auszurichten. Alle warteten gespannt auf das erste Bild von der Oberfläche...

Allerdings waren diese Fehler auch schon bei den ersten Tests auf der Erde aufgetreten! Damals aber entschied man sich, die Fehler zu ignorieren. Zum einen schienen es Hardwarefehler zu sein und zum anderen waren sie stets durch einen Neustart des Systems wieder "verschwunden". Dies war eine der negativen Auswirkung der "cheaper / better / faster"-Strategie, welche früher vermutlich niemals vorgekommen wäre.

Nachdem die Fehler auf dem ?Mars recht häufig auftraten, begann man auf der Erde mit einer fieberhaften Suche nach selbigen. Doch trotz ewiger Versuchsreihen schaffte man es nicht mit "Sojourners" Zwilling "Marie Curie" den Fehler zu reproduzieren. Erst früh am darauffolgenden Morgen, als alle Techniker bis auf einen einzigen nach Hause gegangen waren, wurde der Fehler entdeckt. Durch Analyse des Logbuches zu diesem Zeitpunkt konnte festgestellt werden, dass es bei der Programmierung von "Sojourner" ein Problem gab, "Prioritäten-Inversion" genannt.

Bei ?Echtzeitsystemen wird einzelnen Prozessen eine maximale Reaktionszeit garantiert. Um dies zu ermöglichen, erhalten einzelne Prozesse unterschiedliche Prioritäten. Bei einem preemptiven ?Echtzeitsystem wie VxWorks bedeutet dies, dass die Ausführung eines Prozesses mit niedriger Priorität von einem Prozess mit hoher Priorität unterbrochen werden kann.

Im Mehrprogrammbetrieb müssen Ressourcen, auf die von mehreren Prozessen zugegriffen wird, geschützt werden. Beispielsweise darf ein hochpriorisierter Prozess einen niedrigpriorisierten Prozess, der gerade Daten in einen Netzwerkpuffer schreibt, nicht unterbrechen, um selbst Daten in den Puffer zu schreiben, denn ansonsten würden korrupte Daten entstehen.
Um solche Fehler zu vermeiden bieten sich zum Beispiel auf Benutzerebene ?Semaphoren an. Vor dem Aquirieren einer Ressource muss ein Prozess stets die ?Semaphore anfordern und selbige nach Freigabe der Ressource ebenfalls wieder freigeben. Da das Überprüfen und Anfordern eine atomare Operation ist – vom Kern des Betriebssystems sichergestellt – ist dies eine deterministische Methode parallele Zugriffe zu verhindern.
Beispiel:

Prozess L belegt die ?Semaphore (die mit dem Puffer assoziert ist) bevor er Daten in den Puffer schreibt. Wenn nun Prozess H versucht, den laufenden Prozess zu unterbrechen und dieselbe ?Semaphore zu belegen, wird er vom Betriebssystem davon abgehalten. Dies bedeutet, dass H keinen Zugriff auf den Puffer hat und warten muss, bis L seine Arbeit beendet hat und die ?Semaphore frei gibt.

Probleme können dabei auftreten, wenn ein niedrig priorisierter Prozess eine Ressource blockiert und ein hoch priorisierter Prozess dadurch seine Fälligkeit überschreitet. Dies muss bereits beim Entwickeln des System beachtet werden.

Ein anderes Problem, welches nur schwer zur Entwicklungszeit vorausgesehen werden kann, tritt auf, wenn 3 oder mehr unterschiedlich priorisierte Prozesse auf eine gemeinsame aber exklusive Ressource zugreifen.

Hat der am niedrigsten priorisierte Prozess (L) eine ?Semaphore blockiert und wird ihm durch einen mittelpriorisierten Prozess (M) zwischenzeitlich der Rechnerkern entzogen, muss ein hochpriorisierter Prozess (H) nach seiner Anforderung der ?Semaphore bis zum Abschluss sämtlicher niedrig- und mittelpriorisierter Prozesse warten (im Beispiel rechnet zuerst M zu Ende, dann erst L, der dann auch die Semaphore frei gibt). Dies kann dazu führen, dass der hochpriorisierte Prozess seine Fälligkeit überschreitet!

Diesen Effekt nennt man Prioritäteninversion (priority inversion).

Dem Problem der Prioritäteninversion kann mit der sogenannten Prioritätenvererbung begegnet werden.

Dabei wird dem Prozess, der aktuell eine Ressource belegt, die maximale Priorität der noch auf diese Ressource wartenden Prozesse zugewiesen (die Überwachung der Zugriffe und die Zuweisung erledigt das Betriebssystem). Daduch kann beispielsweise ein mittel priorisierter Prozess nicht die Ausführung eines niedrig priorisierten Prozesses unterbrechen und somit die Ausführung eines hoch priorisierten Prozesses verzögern oder gar verhindern. Der hochpriorisierte Prozess muss nur warten, bis der niedrigpriorisierte Prozess seine Arbeit beendet hat und die ?Semaphore frei gibt. Der ursprünglich niedrigpriorisierte Prozess erhält nach Freigabe der ?Semaphore seine ursprüngliche Priorität zurück.

Ein konkretes Beispiel für diesen Lösungsansatz findet sich weiter unten bei Prioritäteninversion beim Pathfinder.

Aber auch hier kann es Situationen geben, in denen trotz Prioritätsvererbung immer noch Probleme auftreten:

Eines dieser Probleme ist die Verwendung von mehreren Ressourcen durch einen einzelnen Prozess, wenn diese von anderen unterschiedlichen Prozessen bereits belegt werden. Hier kommt zwar der hoch priorisierte Prozess letztendlich schon zur Ausführung, es wird aber sehr lange gewartet.

Ein weiteres Problem ist die Verklemmung. Diese tritt auf, wenn zwei Prozesse auf meherere Ressourcen parallel zugreifen und sich dabei nicht "abstimmen". Im Beispiel nimmt sich der niedrig prioriserte Prozess die ?Semaphore 1, wird durch einen höher priorisierten Prozess unterbrochen welcher sich ?Semaphore 2 nimmt und kommt selbst nach dem Schlafenlegen des höher prioriserten Prozesses nicht mehr zu Ausführung, da er mittlerweile die vom höher priorisierten Prozess belegte ?Semaphore 2 benötigen würde.

Dazu wird bereits vor Inbetriebnahme (offline sozusagen) die Priorität des Prozesses mit der höchsten Priorität bestimmt, welcher jemals überhaupt eine ?Semaphore anfordern würde. Dieser Wert wird als Semaphoren-Attribut gespeichert. Sobald nun ein Prozess diese ?Semaphore anfordert wird seine Priorität sofort auf eben diesen maximalen Wert angehoben. Somit ist sichergestellt, dass er in seiner Ausführung nicht mehr durch ursprünglich höher priorisierte Prozesse unterbrochen werden und somit dem maximal priorisierten Prozess eine Ressource vorenthalten kann.
Eine Vorstellung von dieser Vorgehensweise erhält man durch folgende Übersicht:

Prozess M mit der niedrigsten Priorität aber der längsten Laufzeit war für das Sammeln von meteorologischen Daten zuständig.
Prozess Z mit mittlerer Priorität und Laufzeit sammelte Informationen über den Zustand der Drone und Prozess B (geringe Laufzeit aber höchste Priorität) war für die Verwaltung des Busses zuständig.

Alle drei Prozesse liefen parallel und mussten natürlich gewisse Fälligkeiten erfüllen. An der Grafik sieht man sehr schön das Problem der Prioritäteninversion beim B-Prozess und der daraus resultierenden Nichteinhaltung seiner Fälligkeit.
Eine ebenfalls unabhängig aktive Laufzeitüberwachung erkannte das Problem der Fälligkeitsüberschreitung, interpretierte es als kritischen Fehler und löste eine Systemrücksetzung aus. Alle Daten, welche sich zu diesem Zeitpunkt noch im Zwischenspeicher befanden, gingen natürlich verloren. Auch die bisher durchgeführten Arbeitsschritte wurden zurückgesetzt, so dass nach dem Systemneustart wieder von vorne begonnen werden musste.

Lösung des Problems:

Bei Sojourner löste man dieses Problem mit Prioritätenvererbung. Das Betriebssystem VxWorks unterstützt diese eigentlich von Haus aus, doch war sie ausgerechnet an dieser Stelle deaktiviert worden. Da allerdings ein C-Code-Interpreter auf dem System vorhanden war, schickten die JPL-Ingenieure ein Programm zur Drone hoch, welches letztendlich ein einziges Bit in den Tausenden von Programmzeilen kippte und somit die Überwachung aktivierte.
Nachfolgende Grafik zeigt (bei gleichem Sachverhalt wie oben) den korrekten Ablauf nachdem das Problem behoben wurde.

Nachdem das Betriebssystem sich der Prioritäteninversion angenommen hatte, verlief die Mission die restlichen 3 Monate problemlos.

Im Frühjahr 2003 soll eine weitere Mission zum ?Mars gestartet werden. Diesesmal sollen gleich 2 mobile Dronen die Marsoberfläche erkunden.
Die Landung ist für Januar 2004 geplant.
Der Projektname lautet momentan "Mars Exploration Rovers".
Ein endgültiger Name für die einzelnen Dronen ist bisher noch nicht gefunden.

Eine Möglichkeit, in die Geschichte mit einzugehen, bietet www.nametherovers.org – dort kann man Namensvorschläge für die beiden kleinen Roboter abgeben.

Vermeidung des Fehlers:

Wie hätte man aber diesen kleinen Fehler, der beinahe katastrophale Auswirkungen nach sich zog, nun vermeiden können?
Nun ganz einfach: Durch die Radarstrahlen bzw. die Laufzeit der Radarstrahlen kann man die Entfernung eines Objekts bestimmen. Hätte man nun diese Messung in das Programm miteinbezogen und ausgewertet, hätte man den aufgehenden Mond von anfliegenden Atomraketen unterscheiden können.

weitere Bilder zu NORAD