Für Forscher und Entwickler der Luft- und Raumfahrttechnik sind Simulationsanlagen mit zunehmender Komplexität der Flugzeuge unverzichtbar geworden. Grundsätzlich gilt dabei, daß fliegende Simulatoren die Einrichtungen am Boden nicht ersetzen, sondern nur ergänzen können (und umgekehrt). Bestimmte Daten oder Ereignisse wie beispielsweise realistische Sichtbedingungen stehen nur im Flugzeug zur Verfügung.

In einer Kooperation mit dem Luftfahrtunternehmen MBB (Messerschmidt-Bölkow-Blohm), Bremen, entwickelte die DFVLR in den letzten vier Jahren das System "Attas" (Advanced Technologies Testing Aircraft System) als neuen Versuchsträger. Dieses auf Basis des Verkehrsflugzeugs VFW 614 entwickelte Gerät soll dem Forschungszentrum Braunschweig in den nächsten 15 bis 20 Jahren als zentrales Forschungsobjekt dienen. Die Abteilung Simulationstechnik im Institut für Flugmechanik trägt bei dem Attas-Projekt die Verantwortung für die gesamte elektrische Steuerung, für die Simulation und für die gesamte Softwareentwicklung.

Flugsimulation

Im Institut für Flugmechanik, Braunschweig, werden theoretische und experimentelle Forschungs- und Entwicklungsarbeiten zur Lösung flugmechanischer Probleme überwiegend auf dem Gebiet der Luftfahrt durchgeführt. Ein wichtiges Forschungsziel besteht dabei in der Anpassung des Verhaltens des Flugzeugs oder Hubschraubers an die Fähigkeiten des Piloten sowie in der Verringerung des technischen und wirtschaftlichen Risikos für Hersteller und Nutzer bei der Integration neuer Technologien und zunehmender Automatisierung.

Zwei technische Aufgabenbereiche stehen im Vordergrund:

- Entwicklung und Anwendung effektiver Simulationsmethoden am Boden, im Windkanal und in der Luft (In-Flight-Simulation) und die

- Entwicklung und Nutzung effektiver Flugversuchsmethoden zur Identifizierung, Analyse und Optimierung von Fluggerät.

Rechenanlagen bilden die Dynamik ab

Wesentlich ist, Simulationsanlagen für die flugmechanische Forschung am Flugzeug sowohl am Boden (Festsitzsimulatoren, in denen die Rechenanlagen die Dynamik des Flugzeugs abbilden) als auch in der Luft (fliegende Simulatoren) zur Verfügung zu stellen. Die fliegenden Simulatoren sind Flugzeuge, denen man mit Hilfe von Rechnern andere Eigenschaften aufprägen kann. Ziel ist dabei, dem Piloten den Eindruck zu vermitteln, daß er entweder mit einem anderen Flugzeug fliegt oder daß sich das ihm bekannte anders verhält. Es geht also darum, gezielt durch die Veränderung bestimmter Größen die Flugeigenschaften des Flugzeugs zu beeinflussen. Damit lassen sich die zunächst in der Bodensimulation erprobten Änderungen in der Praxis untersuchen.

Erforscht werden in Braunschweig auch die Fliegbarkeitsgrenzen: Welche Größen dürfen wie geändert werden, bis man an eine Grenze stößt und beispielsweise ein Pilot das Flugzeug nicht mehr manuell beherrschen kann. Diese Erkenntnisse fließen in sogenannte Flugeigenschaftkriterien ein, die in den Forderungskatalogen bei der Entwicklung neuer Flugzeuge wieder auftauchen.

Der Flugversuchsträger Attas (Advanced Technologies Testing Aircraft System) wurde gemeinsam von der DFVLR und MBB auf der Basis des zweistrahligen Verkehrsflugzeugs VFW 614 entwickelt. Attas dient als universell einsetzbarer fliegender Simulator und als Demonstrator für neue Techniken in der Zivilluftfahrt. Herz des Versuchsträgers ist ein redundantes Rechnerverbundsystem, bestehend aus neun Rechnern, die über einen schnellen seriellen, optischen Datenbus mit Ringstruktur miteinander kommunizieren.

"Für komplexe Flugregelungsaufgaben steht ein spezieller flugtauglicher 32-Bit-Rechner zur Verfügung," erklärt Dietrich Hanke, Leiter der Abteilung Simulationstechnik. Die Echtzeitanforderungen an die Programmabläufe werden durch eine weitgehend parallele Datenverarbeitung erfüllt.

Das Rechnersystem verknüpft alle Steuerkommandos des Piloten und eine Vielzahl von Sensor- und Avionik-Systemen mit insgesamt fünfzehn elektro-hydraulischen Stellgliedern, die über einen seriellen Datenbus angeschlossen sind. Die Softwarefunktionen umfassen im wesentlichen die elektrische Steuerung des Flugzeugs und die Herstellung verschiedener Experimentumgebungen im Versuchsflugzeug.

Am Boden werden für die Simulationsaufgaben

- das System MV/6000 mit 4 MB Hauptspeicher

- 16 Leitungen (zwei IAC 8)

- ständig 13 Terminals

- 147 MB Magnetplattenspeicher

- 1 CDC-Plattenstapel mit 300 MB Kapazität

- zwei Magnetbandgeräte

eingesetzt. Die Vernetzung mit den anderen vier S 140 sowie mit der über I/O-Bus angekoppelten MSE 14 vom Rolm erfolgt über MCA-Anschluß.

Die MV/6000 wird von dem Betriebssystem AOS/VS (Advanced Operating System/Virtual Storage) mit den üblichen Utilities unterstützt. Darüber hinaus wird das Text Control System TCS, das dem sogenannten "Configuration Management" dient, eingesetzt. In TCS-Dateien wird der gesamte Source-Code einschließlich Zusatzinformationen wie Datum, Kommentare über Änderungen (wer hat wann was warum geändert) dokumentiert. Dadurch wird eine sehr saubere Beschreibung der Vergangenheit möglich. Für die Abteilungsdokumentation und das Berichtswesen, technische Berichte und Softwarebeschreibungen greifen die Entwickler auf CEO (Comprehensive Electronic Office) zurück.

Bei Entwicklungen an einem Projekt der Attas-Größenordnung, an dem beispielsweise sechs Entwickler ständig an der Software-Basis arbeiten, ist es nicht nur eine Frage des Überblicks, daß jeder der an dem Projekt beteiligten Entwickler immer auf den neuesten Stand der Software zurückgreifen kann.

Entwickler sind immer auf dem neuesten Stand

der Software zurückgreifen kann.

Entwickler sind immer auf dem neuesten Stand

Die Software-Tüftler lösten das Problem dadurch, daß unter TCS ein Directory Attas angelegt wurde, in dem in Subdirectories die aktuellen Sources, zugeordnet zu den Nutzern, verwaltet werden. Mit dem Hilfsprogramm "Build" kann ein Entwickler jetzt auf die Gesamtdatei zugreifen (entweder auf die aktuellen Daten oder auf die, die er von einem bestimmten Zeitpunkt benötigt). Diese Möglichkeiten insgesamt stellen heute das wesentliche Kommunikationsmittel unter den Entwicklern dar.

Wichtig dabei ist, daß bei Änderung eines Moduls alle anderen betroffenen Programmteile automatisch neu generiert werden. Heute überlegt niemand mehr, was im einzelnen geändert werden muß. Die Build-Befehle laufen ab, und das System organisiert dann selbst, welche Endprodukte aufgrund der Änderung neu geschaffen werden müssen.

Diese Eigenschaft des TCS hilft auch, eine Schwachstelle der Softwareentwicklung unter AOS/VS für 16-Bit-Prozessoren zu mildern: Insbesondere der Fortran-Compiler stellt ein echtes Nadelöhr dar. Die Software-Truppe behilft sich, indem sie ihre Fortran-Programme zunächst auf dem 32-Bit-Entwicklungssystem austestet und dann, wenn das Endprodukt erstellt werden soll, auf 16 Bit übergeht. Die Compile-Zeiten belaufen sich dann allerdings auf "Stunden". Dank TCS müssen bei einer Änderung nur die jeweils modifizierten Module neu übersetzt werden.

Anfänglich gestaltete es sich etwas schwierig, TCS zum Laufen zu bringen. "Die ersten Versionen", erinnern sich Dietrich Hanke und Hans-Heinz Lange, Gruppenleiter im Attas-Projekt, "funktionierten überhaupt nicht; erst nachdem ein DG-Systemingenieur beim Debugging der TCS feststellte, wie gut diese Software ist, kam die Sache in Gang." In den letzten eineinhalb bis zwei Jahren seien auch die anderen Hersteller aufgewacht. Mittlerweile gehört ein derartiges Produkt zum Standard-Angebot.

Ihren ersten Digitalrechner, eine alte Honeywell-Maschine, konnte die Abteilung für Simulationstechnik am Institut für Flugmechanik der DFVLR 1974 an Bord nehmen. Bis dahin beherrschten Analogrechner die DV-Szene. Inzwischen arbeiten die Simulationstechniker mit Systemen von Rolm und den dazu kompatiblen Data General Maschinen. Rund fünf Millionen Mark gab das Institut bislang für DV-Anlagen aus, davon 750 000 Mark für Ellipse- und MV-Systeme von DG. die MV/6000 kam 1983 ins Haus, da die bis dahin für die Programmentwicklung eingesetzte S 140 die sechs parallel arbeitenden Entwickler nicht mehr verkraftete.

Bei der Auswahl der Rechner für die Aufgaben in der Luft war eine der wesentlichsten Forderungen natürlich die Flugtauglichkeit. Der DFVLR erschienen zum Zeitpunkt der Auswahl (1981) hier die Produkte von Rolm geeignet, nachdem auch Systeme der AEG sowie von EMM und DEC untersucht worden waren. Am Boden verwenden die Braunschweiger Forscher Systeme von Data General, die vollkommen softwarekompatibel zu den Rolm-Rechnern sind - eine weitere wichtige Forderung im Auswahlverfahren.

Es begann mit den Rolm-16-Bit-Systemen MSE/14, von denen sieben Stück an Bord des Flugzeugs sind. Inzwischen sind zwei 32-Bit-Systeme Hawk/32 hinzugekommen. Diese Systeme kommunizieren über einen optischen Bus, der theoretisch fünf Megabit pro Sekunde überträgt. Dieser Bus mit der Bezeichnung SMCA (Serial Multiprocessor Communications Adapter) ist eine Rolm-Entwicklung und verbindet maximal 15 Rechner miteinander.

Am Boden arbeiten drei 16-Bit-Systeme S 140 von Data General im Verbund mit einem weiteren Data-General-Rechner, dem 32-Bit-Modell MV/6000, sowie einem Rolm-Computer MSE 14. Dieser Rechner stellt verschiedene Schnittstellen bereit, etwa zum SMCA-Bus, zum Mil-Bus (der den Anschluß zu elektro-hydraulischen Stellgliedern herstellt) oder zum Arinc-Bus, einem Luftfahrt-Standard. Diese Boden-Konfiguration entspricht exakt der Konfiguration an Bord des Flugzeuges.

Das Flugverhalten wird vollständig simuliert

Das Flugverhalten der Maschine wird vollständig simuliert. Entscheidend ist, daß die Rolm- und die Data-General-Rechner über die gleichen Ein- und Ausgänge verfügen. Die Software wird im wesentlichen auf der MV/6000 von Data General entwickelt und läuft dann im Verbundsystem unter Echtzeitbedingungen so wie im Flugzeug ab.

An Bord selbst arbeitet das zum AOS befehlskompatible Echtzeit-Betriebssystem ARTS (Advanced Realtime Operating System) von ROLM. Auf dem 32-Bit-Rechner Hawk/32 läuft entsprechend ARTS/32, das befehlskompatibel zum AOS/VS ist. Vorteil für die Entwickler: AOS und ARTS bedienen sich der gleichen Befehlsstruktur.

Ziel der ganzen Entwicklungsarbeit des Braunschweiger Teams ist in Zukunft Flugzeuge "elektrisch" zu fliegen: Die Befehle/Aktivitäten des Piloten werden von einem Rechner in entsprechende Steuerungsbewegungen umgesetzt. Allein für diese Software wendete die Simulationsabteilung bisher rund 30 Mannjahre Entwicklungszeit auf.

Ein großer Teil dieser Arbeiten läßt sich nicht direkt am Flugzeug machen. Immerhin kostet eine Flugstunde rund 10 000 Mark - und Testzeiten von 1000 Stunden oder mehr sind nicht ungewöhnlich. Andererseits stehen eine Reihe von Meßsignalen nur dann direkt am Flugzeug zur Verfügung, wenn es auch tatsächlich in der Luft ist. Aus diesem Grund sind zum einen Parallelentwicklungen, zum anderen die Simulationen am Boden notwendig. Nur so läßt sich in angemessener Zeit, zu vertretbaren Kosten, zu den benötigten Resultaten kommen.

Die Programmentwicklungen sind so komplex, daß man viele Fehler machen kann. Eine wesentliche Rolle bei Echtzeitanwendungen spielt nämlich das Timing, wie die Daten in die Rechner gelangen, dort verarbeitet werden und wie dies dann alles zusammenpaßt. Dazu kommt, daß die Aufgaben auf die Rechner verteilt sind, die dann miteinander kommunizieren müssen. Dies geschieht am Boden über den parallelen MCA-Bus.

Wenn das Flugzeug am Boden ist, werden die Programme über den SMCA-Bus in das Bordrechnersystem geladen. Ohne diesen Anschluß wäre der Austausch von Magnetbändern erforderlich. Dank der Softwarekompatibilität der Rolm- und Data-General-Systeme können die Entwickler heute beispielsweise ihre Programme auf der MV/6000 unter dem Betriebssystem AOS/VS entwickeln und über den Bus in die Bordrechner laden.

Während eines Testfluges zeichnet ein Magnetband alle relevanten Daten auf. Dieses Band kann in der Simulationsabteilung ausgewertet werden, jedoch geschieht dies in der Regel auf den Großrechnern der zentralen Datenverarbeitung des Forschungszentrums. Dort existieren spezielle Programme für die Auswertung dieser Daten. Diese Ergebnisse gehen dann wieder in die Programme ein.

Als nächsten Schritt planen die Entwickler in der Simulationsabteilung des Instituts für Flugmechanik, den Entwicklungsrechner MV/6000 völlig von den zur Zeit noch notwendigen Simulationsaufgaben zu befreien und allein für die dann mögliche parallel laufende Softwareentwicklung einzusetzen.

Interessiert sind die Simulationsleute des Instituts für Flugmechanik auch an ADA. Vor allem die Softwarepflege stellt sich das Braunschweiger Team mit ADA einfacher vor als mit durch andere Kriterien geprägte Sprachen wie Fortran 77, das jetzt im wesentlichen von den Entwicklern verwendet wird.