Erstellung des Echtzeitmodells einer Boeing 737 zum Einsatz im zukünftigen B737 Simulator der Hochschule Bremen

Inhaltsverzeichnis

  Abstract  IV

  Formelzeichen  VI

  Indizes  X

1  Kontext und Aufgabenstellung  1

2  Das Interface  2

2.1  Systemarchitektur  3

2.2  Echtzeitumgebung mit Real Time Windows Target  5

2.3  Simulink Interface  6

2.3.1  ActiveX  7

2.3.2  Virtuelles Hardware Board  9

2.3.3  Interface Funktionen  9

3  Das Modell  13

3.1  Erde  15

3.1.1  Geodätisches Bezugssystem  15

3.1.2  Atmosphäre  18

3.2  Boeing 737 800  22

3.2.1  Bewegungsgleichungen  23

3.2.2  Aerodynamik  25

3.2.2.1  Aerodynamische Kräfte und Momente  27

3.2.2.2  Aerodynamische Geschwindigkeiten und Winkel  28

3.2.2.3  Standardarbeitsbereich  29

3.2.2.3.1  Längsbewegung  29

3.2.2.3.2  Seitenbewegung  43

3.2.2.4  Verhalten bei großen Anstellwinkeln  50

3.2.2.5  Bodeneffekt  52

3.2.3  Triebwerke  54

3.2.3.1  Triebwerkskräfte und momente  55

3.2.3.2  Kraftstoffverbrauch  58

3.2.4  Fahrwerk  59

3.2.4.1  Fahrwerkskräfte und momente  62

3.2.4.2  Oleo-pneumatischer Dämpfer  63

3.2.4.3  Reibung  64

3.2.5.1  Skalare Masse  69

  II  

3.2.5.2  Trägheitstensor  71

3.2.5.3  Schwerpunktlage  75

3.2.6  Struktur  76

3.2.7  Stellerdynamik  78

4  Resümee und Ausblick  80

Anhang A:  Technische Daten Boeing 737 800  82

Anhang B:  B737 Block Bibliothek  84

Anhang C:  Aerodynamische Kenngrößen  87

Anhang :D  Abkürzungsverzeichnis  97

Anhang E:  Abbildungsverzeichnis  98

Anhang F:  Literaturverzeichnis  100

  III  

Abstract

Im Rahmen der vorliegenden Diplomarbeit wurde die Flugphysik-Software des

Fixed-Base Boeing 737-800 Simulators der Hochschule Bremen erstellt.

Hierfür wurde zunächst eine Schnittstelle zwischen den beiden

Entwicklungsumgebungen des Simulators – Borland Delphi und Mathworks

MATLAB – geschaffen und anschließend das Modell in MATLAB Simulink entwickelt.

Das Interface

Das Interface nutzt den Microsoft COM Standard für die Herstellung einer schnellen

und integren Datenübertragung.

Das Modell

Ein System aus vier gekoppelten, nichtlinearen Vektordifferenzialgleichungen liefert

die Bewegung des Flugzeugs in seinen sechs Freiheitsgraden. Es wird mit den

Trägheitsgrößen sowie den Kräften und Momenten aus Aerodynamik, Triebwerk und

Fahrwerk gespeist.

Abb. I: Modellschema der Flugzeugbewegung

IV

Dem System übergeordnet ist ein Erdmodell. Es stellt den Zusammenhang zwischen

den Ausgangsgrößen der Flugzeugbewegung in lokalen geodätischen Koordinaten

und dem WGS84 als Bezugssystem her. Darüber hinaus beschreibt es über ein

integriertes Atmosphärenmodell die gegenwärtigen Umgebungsbedingungen.

V

Formelzeichen

Vektorgrößen sind fett gedruckt bzw. in Simulink mit einem vorangestellten

Unterstrich gekennzeichnet. Bei doppelt besetzten Formelzeichen liefert der Index

die Bedeutung.

Zeichen Elemente Bedeutung Einheit

[ ]

[ ]

VI

[ ]

[ ]

⎡ ⎤

Ω

Θ

Φ

[ ]

Ψ

⎡ ⎤

[ ]

VII

[ ]

[ ]

⎡ ⎤

[ ]

VIII

[ ]

V

[ ]

W

IX

Indizes

Voll ausgeschriebene Indizes (z.B. wing ) sind nicht aufgeführt.

Index Bedeutung

Null

z

X

A n s t r ö m ~

W

XI

1 Kontext und Aufgabenstellung

Kontext

Im Rahmen des Ausbaus der Luftfahrtkomponente der Hochschule Bremen soll ein Boeing 737-800 Fixed-Base Simulator entstehen. Ziel des Projekts ist eine möglichst realistische Demonstration des Flugzeugs, eine für den Einsatz des Simulators in der kommerziellen Verkehrspilotenausbildung erforderliche Genauigkeit aller Komponenten wird jedoch ausdrücklich nicht avisiert.

Aufgeteilt in die Bereiche Hard- und Software kann das Hardware-Team auf einen ausgemusterten B737-100 Simulator der Lufthansa zurückgreifen. Die Software soll mit Ausnahme der grafischen Ausgabe der Flugzeugumgebung komplett neu entstehen.

Aufgabenstellung

Aufgabe dieser Diplomarbeit ist die Erstellung der Flugphysik-Software des Simulators.

Hierfür wurde im Vorfeld die MATLAB Simulink Toolbox „Real Time Windows Target“ als Echtzeitumgebung ausgewählt, die nun gemeinsam mit dem auf Delphi basierenden Netzwerk der fünf Arbeitsstationen die Systemarchitektur des Simulators bilden soll. In einem ersten Teil der Diplomarbeit gilt es demnach, eine Schnittstelle zwischen Borland Delphi und Simulink zu schaffen, die eine für die Zwecke des Simulators ausreichend schnelle sowie integre Datenübertragung gewährleistet.

In der so entstandenen Echtzeitumgebung soll daraufhin ein Modell der Flugphysik des Simulators entstehen, das mit den Steuerbefehlen des Piloten als Eingangsgrößen die Flugzeugbewegung ausgibt.

1

2 Das Interface

Das Simulink Interface stellt die Kommunikation zwischen Borland Delphi und

MATLAB Simulink „Real Time Windows Target“ her. Seine Entwicklung ist (auch

personell, s. Kap. 2.3.2) eng verwoben mit der Entwicklung der Systemarchitektur des Simulators und soll deshalb im Zusammenhang mit dieser dargestellt werden. An erster Stelle steht ein Überblick über die Systemarchitektur des gesamten Simulators sowie die Herstellung einer Echtzeitumgebung mittels Real Time Windows Target. Schließlich folgt die Darstellung des Interface an sich, das als direkte Schnittstelle zur Echtzeitumgebung auch die Kommunikation mit dem Nutzer des Simulators übernimmt (z.B. Positions- und Atmosphäreneingaben).

2

2.1 Systemarchitektur

Die entstehende Systemarchitektur des Bodensimulators basiert auf einem Netzwerk fünf verschiedener Arbeitsstationen (Abb. 2-2).

Server

Der Server bildet den Kern des Systems. Er erfüllt zwei Hauptaufgaben: Zum einen verwaltet er den Datentransfer zwischen den Arbeitsstationen, indem er die ankommenden Daten zu einem Array zusammenfasst, das er als Rundsendung an alle Peripherie-Rechner verschickt. Zum anderen sorgt er mittels dreier angeschlossener Beamer für die Visualisierung der Flugzeugumgebung. Dazu bedient er sich der Grafikengine eines kommerziellen PC-Flugsimulators – derzeit der Microsoft Flight Simulator – der er über die bestehende FSUIPC Schnittstelle [7] die Eulerwinkel und die aktuelle Position übergibt.

Peripherie Rechner

Die Peripherie Rechner bewerkstelligen die eigentliche Datenverarbeitung des Simulators. Sie nehmen die Eingaben der Cockpit Hardware auf, liefern über das Echtzeitmodell die Bewegung des Flugzeugs im Raum und stellen diese als Cockpitanzeigen – z.B. mit PFDs und NAV-Displays für Kapitän und FO – dar.

3

2.2 Echtzeitumgebung mit Real Time Windows Target

Die MATLAB Simulink Toolbox „Real Time Windows Target“ nutzt ein und denselben Rechner als Host und Target. So kann ein Modell in gewohnter Simulink-Umgebung erstellt und direkt in Echtzeit zum Laufen gebracht werden.

Vom Standard Simulink Modell zur Echtzeitanwendung

Um Echtzeitmodelle möglich zu machen, generiert Real Time Windows Target anhand des in Simulink entworfenen Modells C-Code, aus dem - nachdem er mithilfe eines Drittcompilers kompiliert wurde (z.B. Open Watcom, Microsoft Visual C/C++ Compiler) – eine Executable erstellt wird, die über den Simulink External Mode als Echtzeitanwendung aufrufbar ist.

Einmal gestartet läuft die Echtzeitanwendung mit der RTWT Real Time Kernel auf

CPU Ring Null (privilegierter Modus) und synchronisiert sich auf die PC-Uhr, die für

ein präzises Sampling softwaremäßig auf eine höhere Frequenz getaktet wird. Die Kernel sitzt damit noch vor dem Betriebssystem, fängt Aufrufe an dieses ab und versorgt es mit Timer Interrupts der Originalfrequenz.

Dabei bleibt das Block Diagramm des Modells als Simulink GUI (Graphical User Interface) erhalten und gestattet eingeschränkte Veränderungen des Modells zur Laufzeit. Möglich macht dies der Simulink External Mode, der mittels einer .dll (rtwinext.dll) die Kommunikation zwischen Real Time Executable und normaler Simulink Ebene herstellt.

5

2.3 Simulink Interface

Aufgabe der Schnittstelle ist es, dem Echtzeitmodell die in Delphi angelieferten Daten zur Verfügung zu stellen und umgekehrt. Da sie die direkte Verbindung zur Echtzeitsimulation herstellt, ist es nur folgerichtig, wenn über sie auch die für die Simulation erforderlichen Nutzereingaben vorgenommen werden. Dies umfasst z.B. die Festlegung der Startposition des Flugzeugs, aber auch die eigentliche Steuerung der Simulation mit Start-, Stop- und Pause-Befehl.

Die Kommunikation zwischen Borland Delphi und Simulink RTWT wird im Folgenden über zwei Methoden hergestellt, die durch ihre unterschiedlichen Charakteristiken an verschiedenen Stellen ihre Vor- und Nachteile haben und entsprechend eingesetzt werden. Die erste Methode nutzt die Microsoft ActiveX Technologie und zeichnet sich durch ihre Flexibilität aus. Die zweite Methode erstellt ein virtuelles Hardware Board am Parallel Port und ist aufgrund ihrer Leistungsfähigkeit für eine Dateneingabe auf Software-Basis unverzichtbar.

6

2.3.1 ActiveX

ActiveX ist die Microsoft Technologie, die es ermöglicht, z.B. eine Excel Tabelle in Word einzufügen und dort direkt zu bearbeiten. Der Name ActiveX fasst dabei heute nahezu alle den Microsoft COM Standard nutzenden Technologien zusammen.

Möglich wird eine solche Schnittstelle dadurch, dass sowohl Borland Delphi als auch Mathworks MATLAB den Microsoft COM Automation Server Standard unterstützen, der es einer Anwendung (dem Controller; hier: Delphi) erlaubt, eine andere Anwendung (den Server; hier: MATLAB) zu kontrollieren.

Dazu muss von der Controller Anwendung zunächst eine Instanz des Automation Servers erstellt werden. Unter Delphi wird hierfür lediglich die ProgramID der zu instanzierenden Anwendung benötigt. Sie ist in der Windows Registry zu finden und lautet für MATLAB so simpel wie logisch „matlab.application“.

Damit nun eine Kommunikation zwischen Controller und Server hergestellt werden kann, wurden vom Entwickler einer Automation Server fähigen Anwendung bestimmte Funktionen spezifiziert, die sich über ein Industrie-Standard-Interface (IDispatch) aufrufen lassen.

Ein Beispiel: Ist der Server erstellt, liefert Delphi einen Handle zum IDispatch Interface zurück, der hier als „MATLAB“ bezeichnet werden soll. Mathworks MATLAB dagegen besitzt die Automation Server Funktion „Execute“, die eine übergebene Zeichenkette wie einen Standard MATLAB-Befehl im Command Window ausführt. Wird unter Delphi nun „MATLAB.Execute(’a=b+c’)“ aufgerufen, übergibt IDispatch den Befehl „Execute(’a=b+c’)“ mithilfe des COM Standards an MATLAB, das diesen – da „Execute“ als Automation Server Funktion spezifiziert wurde – interpretieren kann und „a=b+c“ wie im Command Window ausführt.

7

Das Simulink Interface mit ActiveX

Das Simulink-Interface verwendet ausschließlich ActiveX für die Ausgabe von Daten. Hierzu schreibt die Real Time Executable die Ausgangsgrößen bei jedem Simulationsschritt als Matrix in den MATLAB Workspace, der sich mit Delphi über eine Automation Server Funktion auslesen lässt.

Für die Eingabe von Daten gingen die Entwickler von Real Time Windows Target nun jedoch davon aus, dass die mit der Real Time Executable über die Standard Input Kanäle aufgenommenen Signale in jedem Fall von fremder Hardware (z.B. einer Messstelle) stammen müssen und dementsprechend über ein PC-Hardware Board Eingang in die Simulation finden. RTWT bietet für die Standard Inputs deshalb zur Laufzeit keine Möglichkeit, Eingangsgrößen einzulesen, die bereits auf Software- Basis vorliegen (z.B. im MATLAB Workspace).

Eine Eingabe der Daten auf Software-Basis ist dennoch über einen Umweg möglich, beispielsweise mit der oben erwähnten Execute Funktion. Diese ermöglicht die ganze Bandbreite der MATLAB-Befehle, vom Neu-Setzen der Initial Condition eines Simulink Integrators mit „set param“ bis zum Ausführen von .m- Dateien. Die Methode ist damit sehr komfortabel und flexibel, sie hat jedoch einen entscheidenden Nachteil: Alle Änderungen stehen zunächst nur auf normaler MATLAB-Ebene zur Verfügung und müssen - um zur Laufzeit Einfluss auf die Simulation nehmen zu können - erst noch von Real Time Windows Target über die rtwinext.dll zur Real Time Executable heruntergeladen werden. Diese Art des Dateneingangs kann daher nur für weniger schnell veränderliche Parameter (z.B. ein Neu-Setzen der Atmosphärenbedingungen durch den Nutzer) verwendet werden, stellt dann aber eine sehr komfortable Lösung dar.

8

2.3.2 Virtuelles Hardware Board

Auch wenn die meisten Eingangsgrößen wie von RTWT erwartet direkt von der Cockpit Hardware über ein Hardware Board Eingang in das Modell finden können, muss es der Echtzeitumgebung immer noch möglich sein, ohne Einschränkung mit allen anderen Simulatorkomponenten auf reiner Software-Basis zu kommunizieren. Die entsprechende Idee hierfür ist simpel: Es könnte ein virtuelles Hardware Board erstellt werden (angesteuert aus Delphi), das sich mit Real Time Windows Target über Standard Input Blöcke auslesen lässt.

Umgesetzt hat diese Idee Florian Andresen, der auch die Systemarchitektur gestaltet, das Interface zum FS geschrieben hat sowie aktuell die Programmierung der Cockpitanzeigen vornimmt. Er wird die Methode im Rahmen seiner Studienarbeit darstellen.

2.3.3 Interface Funktionen

Damit das Simulink Interface im Simulator-Alltag einsetzbar ist, muss es von der Fehlererkennung bis zur Benutzer-Eingabe viele Funktionen bieten, die im Rahmen des ersten Teils dieser Diplomarbeit entwickelt wurden. Um die Bildung des Modells jedoch in den eigentlichen Mittelpunkt der Arbeit stellen zu können, sollen hier lediglich die wichtigsten Aspekte des Interface dargestellt werden.

Initialisierung

Nachdem in einem ersten Schritt MATLAB als Automation Server instanziert wurde, sucht sich das Interface den Ordner, in dem sich die SimFlugphysik.mdl gerade befindet und setzt das MATLAB Working Directory auf diesen Pfad. Dann gibt es den Befehl zum Öffnen des Modells, was nun zunächst dazu führt, dass das Modell die in den Pre Load Callbacks spezifizierten Befehle (auf MATLAB-Ebene) ausführt. Damit werden unter anderem verschiedene .m-Dateien aufgerufen, die die später für die Simulation benötigten Konstanten initialisieren.

9

Pause

Eine Echtzeitanwendung läuft - wie der Name schon sagt – in Echtzeit und kann dementsprechend nicht ohne weiteres unterbrochen werden. Die Pause Routine umgeht das Problem, indem sie lediglich die Ein-/Ausgabe zur Real Time Executable kappt, während die Anwendung im Hintergrund weiterläuft. Mit Wiederaufnahme der Simulation setzt sie dann alle Integratoren auf die zuletzt gespeicherten Werte zurück und die Simulation geht für den Nutzer an genau der Stelle weiter, an der er sie unterbrochen hatte.

Fehlererkennung

Damit ein reibungsloser Ablauf der Simulation gewährleistet werden kann, überwacht das Interface ständig, ob es Daten von der Real Time Executable erhält. Sollte dies für einen Zeitraum größer 200 ms nicht der Fall sein, setzt es die Simulation auf Pause.

Ein automatisches Auslösen der Pause-Funktion erfolgt darüber hinaus auch durch eine Routine, mit der das Interface erkennt, ob es nicht mehr auf den FS zur grafischen Ausgabe der Flugzeugumgebung synchronisiert ist.

Ping

Mit Simulationsbeginn sendet die Controlleranwendung den aktuellen Tickcount (Zeit nach Systemstart in ms ) auf einem Kanal an das Echtzeitmodell, das es unverändert wieder ausgibt und an die Controlleranwendung zurückschickt. Diese vergleicht stetig das empfangene mit dem gesendeten Signal. Sind die Signale identisch, zieht es den empfangenen Tickcount vom nun aktuellen Tickcount ab und erhält damit den Ping der Simulation (die Zeit, die das Signal zum Durchlaufen des Streckenloops benötigt hat). Von nun an liegt der neue Tickcount am Ausgang des Controllers an und der Ping kann sofort neu bestimmt werden.

10

Simulationsstatus

Um einen Einblick in den Status der Simulation zu ermöglichen, stellt das Interface

einige wichtige Rechengrößen der Echtzeitumgebung dar.

11

Soundengine

Das Interface verwendet provisorisch die Standard Playsound-API zur Audio- Wiedergabe von z.B. Triebwerksgeräuschen oder der Stall Warning. Da die Audio- Umgebung des Simulators damit starken Einschränkungen unterworfen ist (unter anderem ist nur ein Kanal möglich), sollte für den endgültigen Simulator aber noch eine leistungsfähigere Soundengine eingebunden werden.

12