Abstract
Formelzeichen
Indizes
1 Kontext und Aufgabenstellung
2 Das Interface
2.1 Systemarchitektur
2.2 Echtzeitumgebung mit Real Time Windows Target
2.3 Simulink Interface
2.3.1 ActiveX
2.3.2 Virtuelles Hardware Board
2.3.3 Interface Funktionen
3 Das Modell
3.1 Erde
3.1.1 Geodätisches Bezugssystem
3.1.2 Atmosphäre
3.2 Boeing 737-800
3.2.1 Bewegungsgleichungen
3.2.2 Aerodynamik
3.2.2.1 Aerodynamische Kräfte und Momente
3.2.2.2 Aerodynamische Geschwindigkeiten und Winkel
3.2.2.3 Standardarbeitsbereich
3.2.2.3.1 Längsbewegung
3.2.2.3.2 Seitenbewegung
3.2.2.4 Verhalten bei großen Anstellwinkeln
3.2.2.5 Bodeneffekt
3.2.3 Triebwerke
3.2.3.1 Triebwerkskräfte und -momente
3.2.3.2 Kraftstoffverbrauch
3.2.4 Fahrwerk
3.2.4.1 Fahrwerkskräfte und -momente
3.2.4.2 Oleo-pneumatischer Dämpfer
3.2.4.3 Reibung
3.2.5 Massen
3.2.5.1 Skalare Masse
3.2.5.2 Trägheitstensor
3.2.5.3 Schwerpunktlage:
3.2.6 Struktur
3.2.7 Stellerdynamik
4 Resümee und Ausblick
Anhang A: Technische Daten Boeing 737-800
Anhang B: B737 Block Bibliothek
Anhang C: Aerodynamische Kenngrößen
Anhang D: Abkürzungsverzeichnis
Anhang E: Abbildungsverzeichnis
Anhang F: Literaturverzeichnis
Anhang G: Versicherung eigenständiger Arbeit
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.
Abbildung in dieser Leseprobe nicht enthalten
Abb. I: Modellschema der Flugzeugbewegung
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.
Formelzeichen
Vektorgrößen sind fett gedruckt bzw. in Simulink mit einem vorangestellten Unterstrich gekennzeichnet. Bei doppelt besetzten Formelzeichen liefert der Index die Bedeutung.
Abbildung in dieser Leseprobe nicht enthalten
Indizes
Voll ausgeschriebene Indizes (z.B.[Abbildung in dieser Leseprobe nicht enthalten]) sind nicht aufgeführt.
Abbildung in dieser Leseprobe nicht enthalten
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.
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).
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2-1: Hauptbildschirm des Interface direkt nach Ladevorgang. Links: Delphi-Seite der Schnittstelle, Rechts: MatLab Seite der Schnittstelle (Data Input, Data Output)
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.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2-2: Systemarchitektur Boeing 737-800 Fixed-Base Simulator der Hochschule Bremen mit Server und Peripherie-Rechnern
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.
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.
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.
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.
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.
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.
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 Abbildung in dieser Leseprobe nicht enthalten 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 Abbildung in dieser Leseprobe nicht enthalten) 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.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2-3 Ping Fenster des Interface
Simulationsstatus
Um einen Einblick in den Status der Simulation zu ermöglichen, stellt das Interface einige wichtige Rechengrößen der Echtzeitumgebung dar.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2-4 Simulation Status Fenster des Interface
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.
Für das Modell wird festgelegt:
- Die Erde ruht und ist damit ein Inertialsystem.
- Es herrscht zu jedem Zeitpunkt reine Unterschallströmung.
- Das Flugzeug ist starr, aeroelastische Effekte treten nicht auf.
- Ein Einfluss der Triebwerke auf die Strömungsverhältnisse an Flügel und Leitwerk ist nicht vorhanden.
- Die Umströmung des Flugzeugs im Standardarbeitsbereich ist quasistationär, einzelne instationäre Effekte außerhalb dieses Bereichs (z.B. Strömungsabriss) werden gesondert und lediglich phänomenologisch berücksichtigt.
- Die aerodynamischen Zentren von Flügel und Leitwerk liegen für den gesamten Betriebsbereich konstant bei [Abbildung in dieser Leseprobe nicht enthalten.]
- Kreiseleffekte bei Lagewinkeländerungen (z.B. Triebwerksfan, rotierende Räder nach Abheben) sind vernachlässigbar.
- Der Einsatzbereich des Flugzeugs beschränkt sich auf geodätische Breiten vom Äquator bis 85° N/S.
Die konsekutive Abfolge der nachstehenden Ausführungen orientiert sich am Aufbau des Modells. Dabei soll der direkte Bezug zum Modell durch entsprechende Abbildungen der Simulink-Systemebenen erleichtert werden.
Die oberste Ebene des Modells bilden Erd- und Flugzeugmodell:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-1: Oberste Modellebene […/Simulation]
Eine solche Einteilung wurde nicht allein aus Übersichtlichkeitsgründen gewählt sondern resultiert vor allem aus den gebrauchten Koordinatensystemen. Während das Flugzeugmodell für eine einfache Darstellung der Kräfte ein flugzeugfestes, ein flugwindfestes und ein lokales geodätisches Achsensystem verwendet (vgl. DIN 9300, Teil 1 [5]), liefert das Erdmodell den Zusammenhang zwischen der aktuellen Position in lokalen geodätischen Koordinaten und dem WGS84 als Bezugssystem.
Der Geodetics Block verwendet das WGS84 als Bezugssystem. Er liefert den Zusammenhang zwischen der aus dem Flugzeugmodell in lokalen geodätischen Koordinaten vorliegende Position [Abbildung in dieser Leseprobe nicht enthalten] und einer entsprechenden Position [Abbildung in dieser Leseprobe nicht enthalten].
Hierfür soll ein weiteres Koordinatensystem verwendet werden, das Earth Centered, Earth Fixed (ECEF) Koordinatensystem, ein kartesisches Achsensystem mit dem Ursprung im Erdmittelpunkt, der z-Achse zusammenfallend mit der Erdachse (positiv zum Nordpol), der x-Achse zum Schnittpunkt von Äquator und Nullmeridian sowie einer y-Achse, die mit den anderen beiden Achsen ein rechtshändiges Koordinatensystem bildet.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-2: Lokales geodätisches und Earth Centered Earth Fixed Koordinatensystem
Hier kann die Position des Flugzeugs als Vektoraddition dargestellt werden:
Abbildung in dieser Leseprobe nicht enthalten
In einem ersten Schritt soll daher ein im WGS84 angegebener Ursprung des lokalen geodätischen Koordinatensystems in das ECEF transformiert werden. Nach [29] gilt:
Abbildung in dieser Leseprobe nicht enthalten
Mit N als Distanz von der Ellipsoidoberfläche entlang der Ellipsoidnormalen zur kleinen Halbachse:
Abbildung in dieser Leseprobe nicht enthalten
Die große Halbachse [Abbildung in dieser Leseprobe nicht enthalten] ist über das WGS84 definiert. Die numerische Exzentrizität [Abbildung in dieser Leseprobe nicht enthalten] folgt mit einem weiteren Definitionsparameter, dem Kehrwert der Abplattung [Abbildung in dieser Leseprobe nicht enthalten], über die Abplattung [Abbildung in dieser Leseprobe nicht enthalten] und die lineare Exzentrizität [Abbildung in dieser Leseprobe nicht enthalten].
Der zweite Summand aus Gleichung erfordert die Drehung vom lokalen geodätischen Koordinatensystem in das ECEF. Für diese ergibt sich mit der geodätischen Länge und Breite [29]:
Abbildung in dieser Leseprobe nicht enthalten
Nach DIN 9300 [5] zeigt die [Abbildung in dieser Leseprobe nicht enthalten]-Achse des lokalen geodätischen Koordinatensystems in Richtung der abwärts verlaufenden Lotlinie, die der Normalen zum Geoid entspricht. Für das Modell werden Geoidnormale und Ellipsoidnormale als deckungsgleich angenommen.
Für die Rücktransformation aus dem ECEF in das WGS84 folgt diese Diplomarbeit einer Methode, wie sie auch in [12] Anwendung findet:
Abbildung in dieser Leseprobe nicht enthalten
Mit
Abbildung in dieser Leseprobe nicht enthalten
Über die nun dargestellten Beziehungen und einen Reset des Positionsintegrators (vgl. Kap. 3.2.1) kann der Ursprung des lokalen geodätischen Koordinatensystems im Modell alle paar Minuten nachgesetzt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-3: Nachsetzen des Ursprungs des lokalen geodätischen Koordinatensystems im Modell
Normatmosphäre
DIN ISO 2533 [6] legt eine Normatmosphäre fest. Temperatur und Druck lassen sich im Höhenband von 0 bis 20 km analog zu [6] wie folgt ausdrücken:
Abbildung in dieser Leseprobe nicht enthalten
Die Dichte wird nach [6] aus Druck und Temperatur unter Verwendung der Zustandsgleichung der idealen Gase berechnet:
Abbildung in dieser Leseprobe nicht enthalten
Hierbei sind [Abbildung in dieser Leseprobe nicht enthalten], [Abbildung in dieser Leseprobe nicht enthalten], [Abbildung in dieser Leseprobe nicht enthalten], [Abbildung in dieser Leseprobe nicht enthalten], [Abbildung in dieser Leseprobe nicht enthalten] und [Abbildung in dieser Leseprobe nicht enthalten] festgelegt.
Bei Höhen außerhalb des Gültigkeitsbereichs der Gleichungen und extrapoliert das Modell mit dem aktuellen Temperaturgradienten (z.B. Flughäfen unterhalb MSL).
Die geopotentielle Höhe ergibt sich als Abbildung in dieser Leseprobe nicht enthalten [6]. Für die Zwecke des Modells ist die Abweichung der geopotentiellen von der geodätischen Höhe jedoch vernachlässigbar:
Abbildung in dieser Leseprobe nicht enthalten
Die Schallgeschwindigkeit Abbildung in dieser Leseprobe nicht enthalten idealer Gase ist eine reine Funktion der Gastemperatur T. Unter Annahme von Luft als idealem Gas gilt [6]:
Abbildung in dieser Leseprobe nicht enthalten
Die dynamische Viskosität [Abbildung in dieser Leseprobe nicht enthalten] der Luft wird mit den empirischen Sutherland Konstanten zu [6]:
Abbildung in dieser Leseprobe nicht enthalten
Es sind [Abbildung in dieser Leseprobe nicht enthalten] und [Abbildung in dieser Leseprobe nicht enthalten].
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-4: Schema des Atmosphärenmodells […/Simulation/Atmosphere]
Benutzerdefinierte Atmosphäre
Die im Modell verwendete benutzerdefinierte Atmosphäre basiert auf den Gleichungen und der Normatmosphäre. Im Gegensatz zu dieser sind nun jedoch Temperatur und Druck auf Meereshöhe, die Tropopausenhöhe sowie die Temperaturgradienten vom Benutzer wählbar.
Die Dichtehöhe Abbildung in dieser Leseprobe nicht enthalten repräsentiert die Höhe der Normatmosphäre, deren Dichte mit der aktuellen Dichte übereinstimmt. Für das Modell liefert die folgende aus der praktischen Verkehrspilotenausbildung stammende Beziehung eine ausreichende Genauigkeit:
Abbildung in dieser Leseprobe nicht enthalten
Die Dichtehöhe wird später für die Ermittlung des Triebwerksschubs benötigt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-5: Benutzerinterface des Atmosphärenmodells
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-6: Schema des Flugzeugmodells […/Simulation/Aircraft]
Die Flugzeugbewegung soll analog zu [4] über ein System von vier gekoppelten, nichtlinearen Vektordifferenzialgleichungen beschrieben werden. Aufgelöst nach den Ableitungsvektoren stellen sich diese wie folgt dar:
Abbildung in dieser Leseprobe nicht enthalten
Mit
Abbildung in dieser Leseprobe nicht enthalten
sowie [Abbildung in dieser Leseprobe nicht enthalten] und [Abbildung in dieser Leseprobe nicht enthalten].
Da [Abbildung in dieser Leseprobe nicht enthalten] für [Abbildung in dieser Leseprobe nicht enthalten] eine Singularität aufweist, soll der Längsneigungswinkel in seinem Wertebereich begrenzt werden.
Abb. 3-7 zeigt den Aufbau der Bewegungsgleichungen im Modell:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-7: Bewegungsgleichungen […Simulation/Aircraft/Equations of Motion]
Für einen auf hohem Niveau einsetzbaren kommerziellen Simulator muss die Aerodynamik auf erflogenen Datensätzen des Flugzeugs basieren. Da der entstehende Bodensimulator der Hochschule Bremen weder solch hohen Ansprüchen zu genügen hat noch die erforderlichen finanziellen Mittel zur Beschaffung der Daten zur Verfügung stehen, sollen diese Kenngrößen im Folgenden nur grob überschlagen werden.
Der Abschnitt wird durch Anhang C: Aerodynamische Kenngrößen ergänzt.
Vorbemerkungen
Die gesamte Aerodynamik wird in flugwindfesten Achsen aufgebaut, bevor am Ausgang die Kräfte und Momente in das flugzeugfeste Koordinatensystem transformiert werden.
Alle hier angegebenen Gleichungen verwenden die Bezugsflügeltiefe [Abbildung in dieser Leseprobe nicht enthalten] als Bezugslänge der Längs- bzw. die Halbspannweite [Abbildung in dieser Leseprobe nicht enthalten] als Bezugslänge der Seitenbewegung.
Modellschema:
Abb. 3-8 zeigt das Schema des Aerodynamikmodells:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3-8: Schema des Aerodynamikmodells […Simulation/Aircraft/Aerodynamics]
Für die Transformation der aerodynamischen Kräfte und Momente aus flugwindfesten in flugzeugfeste Achsen gilt [4]:
Abbildung in dieser Leseprobe nicht enthalten
Mit
Abbildung in dieser Leseprobe nicht enthalten
Die resultierenden aerodynamischen Kraft- und Momentenvektoren in flugwindfesten Koordinaten ergeben sich zu:
Abbildung in dieser Leseprobe nicht enthalten
Nach [4] gilt bzgl. des Zusammenhangs der aerodynamischen Geschwindigkeiten und Winkel:
Abbildung in dieser Leseprobe nicht enthalten
Um mit dimensionslosen Drehgeschwindigkeitsderivativen arbeiten zu können, sollen über die Bezugszeitkonstanten [Abbildung in dieser Leseprobe nicht enthalten] bzw. [Abbildung in dieser Leseprobe nicht enthalten] normierte Drehgeschwindigkeiten verwendet werden:
Abbildung in dieser Leseprobe nicht enthalten
[...]
