std.aero — Flugleistung und Flugführung

→ Zurück zur Unit-Übersicht · Guide: Standardatmosphäre · Guide: Flugführungsrechner bauen · std.astro · std.geo

Fünf Units, die das rechnen, was ein Flugführungsrechner (MCDU/FMS) an Bord ausrechnet: von der Standardatmosphäre bis zum Sinkflugbeginn, der dem Piloten als Symbol auf der Flugroute erscheint. Sie bauen aufeinander auf — std.aero.atmos ist das Fundament, ohne das jede Steig- und Sinkrechnung falsch wäre.

std.aero selbst ist keine Unit, sondern ein Verzeichnis; importiert wird immer eine konkrete Unit wie std.aero.perf.

Autor: Andreas Röne
Copyright: 2026 Andreas Röne
Quelle: std/aero/

<WRAP center round important 90%> Diese Units sind neu (Compiler-Repo, 2026-09-04) und im ausgelieferten lyxc 1.1.18A noch nicht enthalten. Übersetzt wird derzeit nur gegen den Standardbibliotheks-Baum des Compiler-Repos. Prüflauf tests/aero_test.sh: 20 PASS, 0 FAIL. </WRAP>

Units im Überblick

Unit	Import	Beschreibung
std.aero.atmos	`import std.aero.atmos;`	ICAO-Standardatmosphäre (zwei Schichten bis 20 km), Druck- und Dichtehöhe, QNH, Flugflächen, Übergangsfläche, Schallgeschwindigkeit, CAS/EAS/TAS/Mach kompressibel, Übergangshöhe
std.aero.perf	`import std.aero.perf;`	Bahngeometrie, Zwangspunkte, Kurvengeometrie, Pseudo-Wegpunkte (T/C, T/D, DECEL), Steigen aus Energieüberschuss, Dienstgipfelhöhe, spezifische Reichweite, Breguet, W/δ-Optimalhöhe, Stufensteigflug, Cost Index, Wind, Punkt gleicher Zeit und ohne Wiederkehr
std.aero.vnav	`import std.aero.vnav;`	Segmentierte Steig- und Sinkprofile mit Geschwindigkeitsplan, Drift-Down, Notabstieg, Sauerstoffreichweite
std.aero.fplan	`import std.aero.fplan;`	Fortschreibbare Vorhersage entlang der Route (Zeit, Strecke, EFOB), Reserven nach europäischer Aufteilung, Ankunftszeit
std.aero.holding	`import std.aero.holding;`	Warteschleifen: Einflugverfahren, ICAO-Zeiten und -Geschwindigkeiten, Rundenzeit und -verbrauch, Ausdehnung, Windkorrektur

Abhängigkeiten: perf, vnav, fplan und holding bauen alle auf atmos auf; vnav, fplan und holding zusätzlich auf perf.

Fünf Entwurfsregeln, die durch alle Units gehen

Sie erklären, warum die API so aussieht, wie sie aussieht — und sind beim Lesen der einzelnen Seiten die halbe Miete.

1. Die Einheit steht im Namen

AvTasKtAusCasKt nimmt und liefert Knoten, AvIsaDruckPa liefert Pascal, AvDruckhoeheFt Fuß. Intern wird in SI gerechnet, nach außen in den Einheiten der Luftfahrt — aber an der Aufrufstelle ist sichtbar, was übergeben wird. Ein Name ohne Einheit ist in diesen Units ein Fehler.

2. Der Fehlerwert ist NaN, nicht 0

var tas: f64 := AvTasKtAusCasKt(casKt, hM, oatC);
if (AvIsError(tas)) { /* Eingabe außerhalb des Gültigkeitsbereichs */ }

0 und 1 sehen bei physikalischen Größen beide nach einem gültigen Ergebnis aus, und ein stiller Ersatzwert wandert unbemerkt in die nächste Rechnung. Eine Steigrate von 0 ist eine Aussage; eine Steigrate von 0, weil die Eingabe unsinnig war, ist eine Lüge. Geprüft wird mit AvIsError — NaN ist der einzige Wert, der sich selbst ungleich ist.

3. Außerhalb des Gültigkeitsbereichs wird nicht extrapoliert

atmos gilt für 0 bis 20 km geopotentielle Höhe und Unterschall bis Mach 1. Darüber hinaus liefert jede Funktion den Fehlerwert, statt eine Formel weiterzurechnen, die dort nicht mehr gilt.

4. Musterabhängige Kennzahlen kommen vom Aufrufer

Gleitzahl, spezifischer Verbrauch, Schub- und Widerstandswerte, Verzögerungsvermögen, W/δ im Optimum: alles aus dem Flughandbuch des jeweiligen Musters, nichts eingebaut. Ein „typischer„ Vorgabewert wäre für jedes andere Muster falsch und würde nirgends auffallen. Dasselbe gilt für die Reservevorschriften in fplan — sie stehen im Betriebshandbuch und unterscheiden sich je nach Betreiber.

5. Vier Fragen, vier Funktionen

Ein FMS rechnet nicht „die“ Sinkrate. Es beantwortet vier verschiedene Fragen, und wer sie verwechselt, bekommt eine Zahl, die plausibel aussieht und nicht zur Lage passt:

Frage	Funktion	Wovon sie abhängt
Welche Rate hält einen 3°-Pfad?	`AvSinkrateFpm`	nur von der Grundgeschwindigkeit — reine Trigonometrie
Welche Rate erreicht „FL100 bei 30 NM„?	`AvNoetigeSinkrateFpm`	Geometrie mit Höhe und Strecke als Vorgabe
Wo muss der Sinkflug beginnen?	`AvTodStreckeNm`	Gleitzahl des Musters und Wind
Welche Geschwindigkeit ist wirtschaftlich?	`AvGuenstigere`	Cost Index — eine Optimierung, keine Geometrie

Eine gemeinsame Sinkrate() wäre bequem und würde genau die Verwechslung einladen, um die es geht.

Die Fallen, gegen die diese Units gebaut sind

Jede hat in der Luftfahrt schon Zwischenfälle verursacht:

Falle	Was hier dagegen steht
Eine Flugfläche ist keine Höhe. FL350 heißt: Höhenmesser auf 1013,25 hPa, Anzeige 35000 ft. Bei ISA−30 fehlen auf 10000 ft rund 1200 ft geometrische Höhe — im Winter fliegt man tiefer, als man denkt	Druckhöhe und wahre Höhe sind getrennte Größen mit getrennten Funktionen; `AvWahreHoeheM` verlangt die Temperaturabweichung als Argument
TAS ist nicht CAS·√(ρ0/ρ) — das ist EAS. Der Unterschied ist die Kompressibilität und wächst mit der Geschwindigkeit: bei 300 kt in FL350 über zehn Knoten	`atmos` rechnet durchgehend kompressibel
Über der Tropopause gilt die Troposphärenformel nicht — oberhalb 11 km ist die Temperatur konstant, der Druck fällt exponentiell	Zwei Schichten, ausdrücklich getrennt
Eine Mittelung über die ganze Strecke ist bei Gegenwind auf der zweiten Hälfte gutmütig falsch — sie sagt zu wenig Verbrauch voraus, und zwar in die gefährliche Richtung	`fplan` führt einen fortschreibbaren Zustand je Abschnitt, keine Formel über die Gesamtstrecke
Eine mittlere Steigrate über den ganzen Höhenbereich ist zu grob — unten 2500 ft/min, oben 500, und der Stundenverbrauch fällt dabei um ein Drittel	`vnav` integriert in Schritten über die Höhe
Die optimale Reiseflughöhe ist keine feste Zahl — sie folgt aus W/δ und steigt, während Treibstoff verbrennt	`AvOptimaleHoeheM` und `AvStufensteigGewinnM`

Einstiegsbeispiel

unit main;
import std.aero.atmos;
import std.io;
import std.string;

fn main(): int64 {
    // FL350 bei ISA−10: was zeigt der Höhenmesser, wie schnell fliegen wir wirklich?
    var druckhoeheFt: f64 := AvDruckhoeheFtAusFlugflaeche(350.0);
    var hM:           f64 := AvFtToM(druckhoeheFt);
    var oatC:         f64 := AvKToC(AvIsaTemperaturK(hM)) - 10.0;

    var tas:  f64 := AvTasKtAusCasKt(280.0, hM, oatC);
    var mach: f64 := AvMachAusCasKt(280.0, hM);

    PrintLn(StrConcat("Druckhoehe (ft): ", FloatToStr(druckhoeheFt, 1)));
    PrintLn(StrConcat("OAT (C):         ", FloatToStr(oatC, 1)));
    PrintLn(StrConcat("TAS (kt):        ", FloatToStr(tas, 1)));
    PrintLn(StrConcat("Mach:            ", FloatToStr(mach, 1)));
    return 0;
}

Druckhoehe (ft): 35000.0
OAT (C):         -64.3
TAS (kt):        462.5
Mach:            0.8

Was diese Units nicht leisten

Kein Flughandbuch. Schub- und Widerstandspolaren, V-Geschwindigkeiten, Buffet-Grenzen, Klappenpläne — alles musterabhängig und deshalb Sache des Aufrufers.
Keine Navigation. Kurse und Strecken über Grund rechnet std.geo, Bahnmechanik std.astro.
Keine Zulassung. Die Units rechnen; ob eine Rechnung in einem zulassungspflichtigen Gerät verwendet werden darf, entscheidet der DO-178C-Prozess → DO-178C-Guide.
Keine Zeitzonen. fplan rechnet in Minuten seit Mitternacht, damit keine Zeitzonenlogik in die Unit gerät.

Letzte Aktualisierung: 2026-09-05 — Seite neu angelegt; erhoben aus std/aero/*.lyx im Compiler-Repo (Stand 2026-09-04), Beispiel gegen lyxc 1.1.18A übersetzt und ausgeführt.

Prüflauf 2026-09-05 mit doku-pruefer.py über den gesamten Aero-Bereich (Repo-Compiler lyxc 1.2.2A): 13 Vollprogramme, 13 übersetzen, 0 echte Fehler; 193 Aufrufe gegen die pub fn-Signaturen in aurum/std gehalten, 0 Abweichungen.