MÜNCHEN - "Über den Wolken, da muß die Freiheit wohl grenzenlos sein.." - Irrtum. Daß dem nicht so ist, wissen zumindest die, die schon einmal (ernsthaft) versuchten, einen Computer zwar nicht auf den Mond, aber in den Orbit zu schießen. Die Optimierung von Raumbedarf und Leistungsbreite ist eines der ganz großen Probleme der Datenverarbeitung in der Raumfahrt. Vor allem das Zusammenspiel zahlreicher Expertenteams unterschiedlicher Provenienz erfordert Lösungen und Wege, die - fast - von erdgebundener Realität abheben.

Seit Sputnik I im Jahre 1957 seine weltbewegenden Piepser machte und die USA mit Explorer 1 die Herausforderung zur Forschung und Nutzung des Weltalls annahm, hat sich außerhalb unserer Atmosphäre einiges im All getan. Laut einer Statistik der NASA vom Juni 1987 sind 1128 Nutzlasten der USA und 2256 der Sowjetunion erfolgreich auf eine extra-terrestrische Mission geschickt worden - zuerst als Satelliten, in neuester Zeit unter dem Aspekt der Stationierung als ansteuerbare Plattform außerhalb der Erde, die durch das US-amerikanische Spaceshuttle mit Spacelab und die sowjetische Sajus-T-Serie mit dem unbemannten Versorger "Progress" und der Raumstation "Mir" neue Dimension für Forschung und Lehre aufgetan haben.

Spacelab, das erste wiederverwendbare und bemannte Weltraumlabor Europas, findet in dem europäischen "Columbus" eine konsequente Fortsetzung.

Das Columbus-Programm mit Laboratorien und Plattformen ist auf deutsch-italienische Initiative europäisiert worden und wird von der ESA gemanagt.

Verschiedene Großprojekte der deutschen Elektronik- und Raumfahrtindustrie wurden erfolgreich durchgeführt: Azur, Helios und Spacelab mit seiner Mission D1, die den aktiven deutschen Einstieg in die bemannte Raumfahrt kennzeichnet. Die zukünftige Entwicklung der europäischen Raumfahrt wird zweigleisig verlaufen, schreibt Ants Kutzer, damals Ressortleiter Raumfahrtprogramme der MBB/ERNO in einem Beitrag im Handbuch der Raumfahrttechnik. So seien transatlantische Kooperationen durch Vorhaben wie D2 und Columbus projektiert und parallel dazu europäische Autonomiebestrebungen durch die Entwicklung der Ariane V, Hermes und einer bemannten Raumfahrt-Infrastruktur in Angriff genommen. Das allgemeine Konzept moderner Raumplattformen sieht vor, Nutzlasten in den Orbit zu befördern, die konsequent im Turnus von Monaten oder Jahren ausgetauscht werden. Eine Plattform im Weltraum setzt sich aus verschiedenen Elementen zusammen, die jede für sich verschiedenen Aufgaben zu erfüllen haben.

Raumfahrt ist immer eine Geldfrage - der Transport von Nutzlasten in den Orbit kostet derzeit, so wurde errechnet, rund 10 000 Mark pro Kilogramm - und über die Lebensdauer der Plattformkomponenten heißt es aus eben diesen Aspekten, verschiedene Nutzlasten - im Extremfall auch Hardwarekomponenten der DV an Bord - auszutauschen.

So ist es notwendig, die Software, die "onboard" läuft und das System überwacht, steuert und kontrolliert flexibel gegen eine aktuelle Konfiguration zu gestalten. Eine der sinnvollen Forderungen daher: Die Programme müssen missions-spezifisch datengetrieben laufen.

Dieses Konzept erwächst letztlich aus einer Diskrepanz: Auf der einen Seite muß eine Lebenszeit im Orbit von einigen Jahrzehnten unterstützt werden - die Konfiguration, die finanziell sehr aufwendig konzipiert ist, ist sehr starr gegenüber Veränderungen und Erweiterungen. Das, was terrestrisch als "evolutive maintenance", also als sukzessive Erweiterung und Verbesserung einer Applikation zugute kommt, stößt orbital auf große Schwierigkeiten.

Auf der anderen Seite sind natürlich in der Projektlebenszeit verschiedene Missionen durchzufahren. Eine Mission kennzeichnet sich dadurch, daß unterschiedliche Experimente in einer Konfiguration beherbergt werden - besondere Anforderungen an die Flexibilität des Softwaresystems werden gestellt.

Die Intelligenz der einzelnen Komponenten eines Systems für den Orbit ist insbesondere deshalb wichtig, weil in der Raumfahrt Hardware eingesetzt wird, die sehr lange Qualifikationsphasen hinter sich hat.

Zurück zur Software: Hier sind modernste Konzepte auf den Entwicklungsschreibtischen. Tools verschiedenster Provenienz werden eingesetzt - Menütechniken, grafische Benutzeroberflächen, relationale Datenbanken gleichen die technisch bedingten Hardware-Nachhänger aus. Bei einem der neueren Plattformprojekte ist als Entwicklungsumgebung für die Software der Einsatz von Uniface von der GEI GmbH aus Aachen vorgesehen; die konzeptionellen Arbeiten an der datengetriebenen Software werden mit diesem DB-übergreifenden Tool unterstützt.

Eine Besonderheit macht bei Raumfahrtprojekten die Software-Entwicklung zu einem spannenden Unterfangen. Fliegt die Anwendung erst einmal, dann können nur noch bedingt Änderungen an der Software vorgenommen werden. Der Konzeption und strukturell-inhaltlichen Gestaltung kommt so eine wichtige Rolle zu: Projektvorbereitungszeiten von bis zu zehn Jahren sind deshalb auch aus Aspekten der Vollständigkeit heraus der Normalfall. Die notwendige Datenbeschreibung im System zur Steuerung der Experimente an Bord beinhaltet so auch alle Informationen über die Konfiguration, die zu einem normalen Betrieb notwendig sind und die die Realtime-Software zu ihrem Ablauf benötigt.

Der funktionale Kern bleibt immer gleich

Betrachtet man Software als Folge von Funktionen, so ist ein funktionaler Grundstock vorgesehen, der über die Projektdauer gleichbleibt. Denn was im Orbit immer wieder und wieder abläuft, ist die Akquirierung von Daten ähnlich einem terrestrischen Echtzeitsystem - ist, eine Grenzwertüberwachung durchzufahren und heißt im besonderen, im Falle der Überschreitung dieser Grenzwerte eine automatische Fehlerkontrolle durchzufahren und eine Korrektur einzuleiten. Dazu sind zwischendurch gezielt operationelle Tätigkeiten anzustoßen: Testabläufe müssen ein- und ausgeschaltet oder Probenarme ein- oder ausgefahren werden. Dazu ist die gesamte Kontrolle der Zuladung in bezug auf Außentemperatur, Stromverbrauch oder anderer externer Einflüsse Datenbank-orientierte Anwendung.

Aus der Komplexität des gesamten Softwareumfanges einer Raumfahrtmission sei der Hardware-bezogene, Experiment-spezifische Teil herausgegriffen. Der funktionale Kern in der Software für alle Nutzanwendungen kann auf Grund der oben beschriebenen, immer wiederkehrenden Aufgaben als identisch betrachtet werden. Um möglichst effizient arbeiten zu können, sind zudem die rein räumlichen Abmessungen der Experimente genormt. Beide Aspekte zusammen haben sich als tragbar für eine kostensensible Projektierung im Weltraum erwiesen.

Im Austausch einer Anwendung bedeutet die Standardisierung praktisch, daß für die neue Payload, die eingeschoben wird, dieselben Pins für die Datenakquisition eingesetzt werden aber anstatt einer Spannungsmessung mit einer Kalibrierung von beispielsweise real Null bis zehn Volt ist jetzt eine Temperaturmessung mit einer vollkommen unlinearen Kurve und Kalibrierung von beispielsweise Minus 200 bis Plus 800 Grad durchzuführen.

Die Funktion der Datenerfassung findet nach wie vor Anwendung, lediglich die Bedeutung hinter den Pins als Meßwertgeber ist payload-spezifisch geändert. Dem System muß also mit der Software auch die Bedeutung des einzelnen Pins zur Verfügung gestellt werden.

Konsequenterweise ändert sich bei der Neubelegung mit einem Experiment auch die Grenzwertüberwachungsfunktion der gemeldeten Daten. Die Bereitstellung der Rohdaten auf einer Engineering-Unit-Ebene mit der tatsächlichen Bedeutung leistet das System. Die Abbildung an sich ist Teil der Funktionalität und wird durch die Datenbank geleistet.

Der Trick bei der Pin-Umbelegung besteht darin, die eingehende Integerzahl von meist 12-Bit-Länge in dem Rechner, in dem die Grenzwertüberwachung stattfindet und in Engineering Unit Values (also als Gleitkomma-Realzahl) festgelegt ist, mit Hilfe eines Polynoms in eine Realzahl umzuwandeln. Die Koeffizienten für dieses Polynom und die Umwandlung stehen in einer Tabelle und werden über die Datenbank kontrolliert. Die Kalibration als solche bleibt erhalten - die Auswahl des richtigen Polynoms für den Pin geschieht über die Tabellenstruktur.

Es existieren somit Datenstrukturen, die die Basisfunktionalität des Systems (Datenakquisition, Kalibration, Grenzwertüberwachung) durch Pointerstrukturen unterstützen. Die SW-Ingenieure legen bei ihren Arbeiten am Datenbank-orientierten System für die Hardware-ausgelegten Missionen Typdefinitionen fest, die in die Software hineinkodiert werden. Die tatsächlichen Objekte zu diesen Typen sind relativ variabel, denn sie können mit mehr oder weniger Pins belegt werden.

Die Datenstrukturen reglementieren so das wirkliche Objekt. Die Software weiß etwas über die Typen und sie erfährt aus den Daten, wieviele Inkarnationen von diesen Objekten im Moment vorhanden sind. Der Aufbau der Datenstruktur beginnt mit der Zahl der Einträge und ihrer Klassifizierung (zum Beispiel analoger Sensor: Hier weiß die Software, daß an erster Stelle das Polynom steht, dann die Grenzwerte kommen und so weiter).

Ada als Sprache eine Grundvoraussetzung

Im Prinzip liegt also zwischen der Datenbank und dem Onboard-System eine Festlegung über die Struktur von Objekten. Die tatsächliche Ausprägung indes ist nur in der Datenbank gespeichert. Die Datenstrukturen sind dabei selbsterklärend für die Software. So kann das Programm über die Struktur alles über den Umfang der Inkarnationen der Anwendung erfahren. Bereits Spacelab wurde nach dieser Vorgehensweise erarbeitet.

Als Sprache für kommende Weltraumanwendungen ist Ada eine unabdingbare Forderung. Der nächste Schritt bei der Entwicklung einer solchen Software ist, daß die Initiatoren und Nutzer der Zuladungen die tatsächliche Ausprägung in die DB eingeben müssen. Das geschieht durch eine klassische Datenbanktechnik, also ein menügesteuertes, interaktives System. Mit Uniface hat die GEI GmbH aus Aachen ein Produkt im Markt, das für diese Aufgabe unterstützend geeignet ist.

Aus Softwaresicht erkennt man hier einen ganz klassischen Datenbankansatz. Uniface findet seinen Einsatz als Anwendungsgenerator für die Menüsteuerung. Für anfallende Aufgaben als Reportwriter wird Uniface bislang in keinem bekannten Projekt eingesetzt, obwohl das Tool auch hierfür ausgelegt ist. Diese Einschränkung in der Anwendung begründet sich allerdings, so Raumfahrt-DV-Experten, an der Komplexität der Raumfahrtapplikation, die das konzeptionelle Schema des Tools sprengen müsse.

Außensicht der Objekte hierarchisch organisiert

Wichtige Aufgabe im Vorfeld der eigentlichen Softwareerstellung ist die Konzeption aller Masken inklusive der komplexen Integritätsbedingungen, die gleich bei der Dateneingabe abgefragt werden sollen. Die Bedingungen werden in der Terminologie von Uniface über Trigger implementiert - und zwar inklusive der Datenstrukturen, die aus der Endbenutzersicht nicht relational sind. Dennoch finden, so hat sich im Laufe bisheriger Raumstationkonzepte herauskristallisiert, relationale Datenbanken Verwendung. Oracle beispielsweise gilt nach Mitteilung von GEI-Experten in ihrem relationalen Aufbau als klassisch für eine Uniface-Anwendung. Es ist interessant, daß die Außensicht der Objekte, also letztlich das, was logisch in der Datenbank gespeichert wird, hierarchisch organisiert ist.

Menge der Objekte ist unbegrenzt

Die Sicht der Objekte ist in der Tat eine der komplexeren Angelegenheiten bei einem solchen Projekt und kann am besten an Hand eines Beispiels aus der täglichen Realität erläutert werden. Der hierarchische Baum in der DV-Technik entspricht inhaltlich in etwa einer Aufteilung: Auto - Karrosserie - Kofferraumdeckel - Halterung - Schraube, wobei sich die eigentlichen Informationen in den Blättern des Baumes befinden. Die Schraube in diesem Beispiel nämlich wiederum führt eine relationale Attributliste mit ihren Ausprägungen: Rechtsgewinde - Selbstblockierend - Durchmesser. Ein anderer Schraubentypus hat entsprechend eine andere Attributliste.

In der Raumfahrt ist die Menge der Typen fest vorgeschrieben - sie ergibt sich aus den Charakteristika der Hardware selber. Es können nur analoge oder diskrete Sensoren eingesetzt werden, die wiederum nur diskrete Stimuli (also Ein-/Ausbetriebe) geben und keinen analogen Output fabrizieren.

Alle diese Objekte, die aus der Systemsicht heraus vollständig in der Datenbank abgebildet werden können, lassen sich also in einer endlichen, wohldefinierten Menge von Typen (Objektarten) darstellen.

Die Menge der Objekte selber aber ist unbegrenzt. Es können eine beliebige Anzahl Inkarnationen von der Ausprägung "analoger Sensor" eingesetzt werden.

Den Pfadnamen als Primärschlüssel im Datenbanksinne wächst hier eine besondere Bedeutung zu. Sie können bis zu 800 Buchstaben haben; durch sie wird durch die hierarchische Strukturierung bis auf den Pin-Level runter auch über die erkennbare semantische Bedeutung (Payload1 Modul3, vordere Ecke rechts, Temperatur) eine strukturelle Zerlegung vorgenommen.

Jedes Objekt muß jetzt genau zu einem der vordefinierten Typen gehören. Damit sind seine Attribute bestimmt und daraus ergibt sich eine Maske - für das Maskenlayout eignet sich Uniface und wird auch eingesetzt.

Schwierigkeiten, die man bei früheren Projekten im Datenbanksinne hatte, sollen in Zukunft über den Namensbaum vermieden werden. Bislang nämlich wurde diese Strukturierung allgemein über Nummernschlüssel mit relativ wenig Aussagekraft durchgeführt.

Die Punktnotation mit Bezeichnungen wie System 17 und Datenbeschreibung 1 bis 275 führte bei nicht dauerhaftem Umgang mit dem System denn auch in der Vergangenheit eher in die Wüste denn zu einer laufenden Anwendung im Weltraum.

Ein weiterer Vorteil aus der Sicht der Entwickler, die in weltweitem Gedankenaustausch stehen, ist, daß etwas ähnliches wie "Besitzrechte" an den Daten eingeführt werden können. So kommen sich die verschiedenen Softwerker mit ihren Teilprojektarbeiten nicht ins Gehege. Diese Besitzrechte auf Knotenebene können auch an Kollegen weitergegeben werden.

Hinzu kommt, daß dieses neue Konfigurationskonzept die Möglichkeit bietet, die Gesamtdatenmenge aus Teilbäumen sukzessive zusammenstellen zu können. Um hier Fehler zu vermeiden, zum Beispiel die Doppelbelegung von Pins, ist ein Prüfungsprogramm für die Konsistenz der Datenbankinhalte sinnvoll.

Luxus der Parallelität

"Einfrieren" ist ein weiteres Vorgehen, das aus der Raumfahrt-DV in eine erdgebundene Anwendung übernommen werden kann. Versionen werden je nach ihrer Güte mit immer restriktiveren Schreibrechten versehen, bis sie in einem ausgereiften Zustand "eingefroren" werden. Für weitere Anwendungen wird hiervon dann eine Kopie gezogen, die wieder völlig frei von Schreibrestriktionen ist und entsprechend abgewandelt werden kann.

Mit Realtimeproblemen und Fragen der Konfigurierbarkeit kämpfen viele DV-Experten. Bei den Raumfahrtapplikationen kommt hinzu, daß viele Projektteams in einem großen Kontext zusammenarbeiten und Daten eingeben und vor allem über einen langen Zeitraum der Entwicklungsgang an sich unterstützt werden muß. Bei terrestrischen Anwendungen wie zum Beispiel einer Prozeßkontrolle wird das Design erstellt und das System ausgetestet - eine Versionskontrolle auf der Datenbank ist in dem Sinne nicht mehr notwendig. Sie kommt ebenso wie das "Ownership"-Konzept nur bei der Entwicklung zum Tragen. Nur das Nametree-Konzept überlebt oft in die Anwendungsphase hinein.

Ähnlich funktioniert nach Aussage von DV-Raumfahrtexperten die Datenbank onboard, die als Extrakt in der Orbitalstation mitfliegt. Auch hier ist nur noch das Nametree-Konzept erhalten, eine einzige Version geladen, keine Konfigurierbarkeit vorgesehen und kein Ownership mehr notwendig - die Anwendung ist monolithisch. Bei Wechsel der Anwendung wird die orbitale Datenbank einfach umgeladen; am Boden leistet man sich indes den Luxus der Parallelität der Versions- und Datenhaltung.

Das Problem letztendlich ist, wie man die angerissenen Ideen, Konzepte und Vorgehensweisen in einer relationalen Datenbank unter einen Hut bekommt - durchaus nicht trivial, meinen die Weltraumorientierten Softwerker.

Uniface leistet bei dieser Fragestellung als Anwendungsgenerator da Hilfe, wo es heißt, mit vergleichsweise wenig Manpower-Aufwand zu sinnvollen, umfassenden Masken zu kommen, nachdem das System designed ist. Auch bei komplizierten Applikationen kann dieser Gang, für den sonst maßgeschneiderte Software vonnöten ist, mit einem Anwendungsgenerator durchgeführt werden. Der Vorteil wird von Softwarespezialisten darin gesehen, daß externe Schemata definiert werden können, die mit dem konzeptionellen Schema kongruent sein müssen. Dies bezieht sich auf die Attribute von Typen.

Es ist so, daß viele Typen gewisse Attributklassen teilen, die unter Uniface zu einem externen Schema gemacht werden. Wenn der Benutzer jetzt einen Typ als eine Enduser-Repräsentation definiert, dann sucht sich die Applikation aus einer Liste die Menge der Attributklassen raus, die dann in die Hauptmaske einfließen und aus denen dann relationale Verknüpfungen erstellt werden. Fehlermöglichkeiten sind somit minimiert. Aber auch hier wird Vorsorge getroffen. Treten Fehler auf, so ist über die Versionskontrolle und die funkgesteuerte Lösch- und Ladefunktion der Datenbank eine Korrekturmöglichkeit über die gesamte Lebensdauer der orbitalen Anlage gegeben.

Externe Schemata sollten getrennt sein

Die externen Schemata sollten getrennt sein, um die Applikationen einwandfrei zu strukturieren. Zu jedem externen Schema gehört im Sinne einer relationalen Datenbank genau eine Table; sie muß den eindeutigen Schlüssel des End-Items plus weitere Schlüssel des Attributrecords beinhalten. Obwohl also in der Attributmaske selber der Primärschlüssel nicht wieder dargestellt wird, muß er aus dem externen Schema an die Table übergeben werden. Genau diese Information, die für das externe Schema die globale Datenselektion steuert, und den Primärschlüssel identifiziert, übergibt man diesem Fall.

Die Masken sind vom Layout her auf dem Schirm gestuft - die Hauptmaske stellt dem Primärschlüssel bereit, das externe Schema beginnt erst in einer untergeordneten Schicht und zeigt nur noch die Attribute an - dennoch muß der Primärschlüssel in dem externen Schema verfügbar sein.

Was gespeichert wird ist Sache das Anwenders

Bei der Software-seitigen Projektierung der Missionen einer Raumplattform rechnen die Entwicklungsingenieure mit bis zu 200 verschiedenen Typen, die eingebracht werden müssen; die Menge der Attributreports liegt ungefähr bei 100. Was letztendlich in der Datenbank als Information für die einzelnen Experimente gespeichert ist, ist übrigens Sache der Anwender - und des Managements im Vorfeld eines solchen Projektes.

Konzeptionelles Schema vorteilhaft

Schnittstellen, Konventionen und Formulare sind so ein wichtiger Bestandteil der Vorbereitungen einer erfolgreichen Mission. Aber auch ein sauberes konzeptionelles Schema, das die Aufgaben der Create Table-Funktion einer relationalen Datenbank ins Vorfeld verlagert, hat Vorteile und ist auch für erdgebundene tabellengesteuerte Prozesse sinnvoll, meinen die Raumfahrt-DVIer bescheiden, "nur, daß unsere Anwendungen

halt fliegen".

* Martin J. P. Hoffmann ist freier DV-Fachjournalist in München