Seit Monaten fragt die Community, was bei Fenix eigentlich los ist, vor allem bei der A320neo. Jetzt gibt es Antworten, und zwar reichlich: Aamir Thacker, CEO von Fenix Simulations, hat auf dem YouTube-Kanal von Fenix ein zweistündiges Video im mit GTA-Intro veröffentlicht, in dem er selbst als Sprecher durch die Präsentation und Features eines großen Fenix-Update führt. Yes, laaaaaaang: Das Schlusswort beginnt bei 1:46:54. Aamir erklärt, woran das Team gearbeitet hat und was Fenix-Kundschaft in Version 3 erwarten kann. In der Beschreibung ist von der „bald erscheinenden“ Version 3 der A32X-Produktlinie die Rede. Ein Veröffentlichungsdatum nennt weder die Beschreibung noch das Video – auch nicht zum NEO.

Und wer sich auf Vergleichsvideos freut, wird bedient: Fenix zeigt teils direkte Gegenüberstellungen mit einem Full-Flight-Simulator, dem echten Flugzeug und anderen Desktop-Produkten, weil man Verhalten manchmal einfacher zeigen als beschreiben kann. Nehmt euch Zeit und Getränk, vielleich noch Snacks. Wir haben das Video für euch durchgearbeitet.

Flugmodell, Fly-by-Wire, Flight Director und Autopilot: alles hängt an der Trägheit

Der Einstieg ist das Flugmodell, und der Hebel heißt Trägheitstensor. Asobo hat in MSFS 2024 eine bessere Lösung dafür geliefert, wie die Trägheit eines Flugzeugs verwaltet wird. Fenix hat die trägheitsbezogenen Einträge im Flugmodell damit komplett neu aufgebaut. Das betrifft alle Achsen: Nick, Roll, Gier, also alles daran, wie sich die Masse des Flugzeugs durch den Raum bewegt.

• MSFS 2020: Die Änderungen wurden auf das ältere Massenträgheitsmoment-System zurückportiert. Randfälle und Feinheit des vollen 2024er-Tensorgitters fehlen dort, der Großteil der Verbesserung stammt laut Fenix aber aus dem Refactoring und nicht aus der neuen Technik.
• Rotation und Flare: Beide kritischen Flugphasen hängen eng an der Trägheit und wurden fortlaufend überprüft.
• Bodeneffekt: Wurde an das neue Handling angepasst, mehrere extern ausgelagerte Bodeneffekt-Controller wurden neu abgestimmt.

Zum Tensor selbst gibt es im Video keinen Exkurs. Thacker verweist auf die Übersicht im Asobo-SDK.

Fly-by-Wire. Wegen der gestiegenen Komplexität bei der Trägheit musste auch das Fly-by-Wire umgebaut werden. Das brachte Verbesserungen bei Nick und Roll in der grundlegenden Verarbeitung, dazu neue Parameter und Controller-Integrationen, mit denen sich das Handflug-Gefühl justieren lässt.

Fenix zeigt dazu ein Side-by-Side-Video mit einem Full-Flight-Simulator. Absichtlich hat man die Fenix im Roll etwas straffer gemacht als den FFS. Der Grund ist durchgängiges Feedback der beteiligten Piloten über den Unterschied zwischen FFS und realem Flugzeug im Normalflug.

Lässt man den Stick los, wirkt die Fenix etwas weniger träge. Im Testpool saßen fünf verschiedene zertifizierte Full-Flight-Simulatoren sowie Piloten des echten A320, die zu jedem Feedback gaben. Auch die Nick-Achse wurde mit derselben Sorgfalt gegen das Pilotenfeedback abgestimmt, ebenso Rotation und Flare. Ja, Simulatoren geben kein Feedback. Aber natürlich deren Nutzer, heh.

Flight Director. Beim Handflug fiel auf, dass die Flight Director Liebe brauchen. Der alte Code war schon am Limit abgestimmt, gab Anweisungen aber oft ruppig aus und reagierte überempfindlich. Fenix hat ihn komplett entfernt und durch Code ersetzt, der eigens für den neuen Flugstack gebaut wurde. Der alte Director hatte konzeptionell keine Vorausschau. Der neue gibt Kommandos mit gewisser Voraussicht und etwas Glättung aus, wie das echte Flugzeug.

Autopilot. Wer Flugmodell, Fly-by-Wire und Flight Director anfasst, bekommt den Autopiloten gratis mit auf die Liste. Der Autopilot des Airbus ist relativ entkoppelt von den Flight Directors: Der Director gibt das Ziel vor, der Autopilot versucht es zu fliegen, so wie man es im Handflug tut.

Im Alltag war er etwas zappelig und weniger gemessen als das Original. Die Director-Änderungen brachten schon eine leichte Besserung. Fenix hat zusätzlich die Roll- und Nick-Regler des Autopiloten überarbeitet und zusammengeführt, um Ansprechverhalten, Wirksamkeit und Sanftheit besser auszubalancieren. Das klingt klein, verändert laut Aamir aber spürbar, wie sich das Flugzeug unter Autopilot verhält.

Das Gesamtpaket aus Flugmodell, Fly-by-Wire, Director und Autopilot ist am Ende eine Gefühlssache. Von der Rotation bis zum Flare habe man nie so konsistent positives Feedback vom Testteam aus echten A320-Piloten bekommen.

Bodenmodell, Settings-App und Dokumente-App

Bodenmodell. Kurz, aber nützlich: Fenix hat Teile des Bodenhandlings ausgelagert und eine Hybridlösung für den Taxi-Bereich gebaut, die oberhalb normaler Taxi-Geschwindigkeit komplett ausblendet. Ziel ist genauere Kontrolle über das Handling in dieser Phase und ein Weg um mehrere ziemlich auffällige Bugs im Bodenverhalten des Simulators. Genannt werden:

• Mehr nötiger Schub auf nassem Untergrund, weil Pfützen die Reifenreibung verschlechtern.
• Diverse Bremsmerkwürdigkeiten.
• Die Anpassung der Vorwärtsträgheit bei engen Kurven.
• Der übergroße Einfluss von Hängen und Hügeln auf den Schub, der zum Anrollen nötig ist.

Außerdem muss die Bodenreibung nicht mehr nur für das Rollen mit zwei Triebwerken abgestimmt werden, zulasten des Rollens mit einem. Beides soll nun angemessener zur jeweiligen Situation passen. Fenix wird das weiter verfeinern, sobald Feedback eintrudelt.

Settings-App. Sie wurde komplett neu gebaut, damit man sich durch die vielen Optionen findet. Die Liste wird mit den NEOs weiter wachsen, daher gibt es jetzt eine Suche. Wer lieber stöbert, kann die Abschnitte durchblättern. Optional zeigen Bilder, wie die jeweilige Option aussieht.

Dokumente-App. Die eigentliche Großbaustelle, ausdrücklich mit dem Ziel, die ganze eingebaute Raffinesse zugänglicher zu machen:

• Ein komplettes Quick Reference Handbook, in Abschnitte gegliedert, durchsuchbar, mit Pin-Funktion für das, was man oft braucht.
• Die QRH-Verfahren sind interaktiv, man hakt Punkte ab, während man sie durchgeht, ob beim simplen Crossbleed-Start oder bei unangenehmen Fehlern.
• Löst man einen Fehler aus, pinnt die App automatisch die passenden Dokumente an.
• Normale Checklisten für jeden Flug sind ebenfalls enthalten.
• Das System lässt sich auch mit eigenen Dokumenten und Checklisten füllen, etwa für airline-spezifische SOPs.

Optik und Sound: Es wackelt, es spiegelt, es hört sich nach Raum an

Optik. Eigentlich wollte man bei den Artworks nur das Nötigste reparieren. Leerlauf ist aber bekanntlich des Teufels Werkstatt: Nach der Fehlerliste wurden mehrere Verbesserungen und Immersionsfeatures der NEO-Artworks auf die CEO zurückgeholt. Im Cockpit stecken Dutzende subtile Änderungen an Modellen, Texturen, Animationen und Verhalten.

Neu ist ein physikbasiertes Animationssystem, das Masse, Steifigkeit und Trägheit von Paneelen, Einbauten und Bedienelementen berücksichtigt. Bei Turbulenz, harten Landungen oder schon beim Rollen über ein Rollbahnfeuer vibrieren und wackeln Cockpitteile an ihren Aufhängungen. Das ist subtil, soll aber vermitteln, dass man ein Flugzeug aus tausenden Einzelteilen steuert und kein perfekt verklebtes Modellflugzeug.

In der Kabine wurde der Fensterglanz grundlegend überarbeitet, mit besseren Texturen und physikalisch korrekter Modellierung der Glanzelemente. Am echten A320 sieht man deutliche Lichtbrechung am Rand der äußeren Scheibe, und die wurde im MSFS nachgebaut. Dazu kommen laut Fenix zu viele Fixes für eine Aufzählung.

Sound. Dave war bei der NEO eingespannt, hat aber trotzdem einen großen Teil des Basis-Soundsets neu gebaut, um es mit dem kommenden NEO-Soundscape in Einklang zu halten:

• Neue Aufnahmen und eine eigene Binaural-Implementierung. Fenix simuliert, wie Schall mit dem menschlichen Ohr interagiert. Mit geschlossenen Augen soll man Raumgröße, Position der Geräusche und ihre Verdeckung durch Objekte oder Reflexionen an Flächen wahrnehmen. Laut Fenix ist das ein Novum im MSFS, und es funktioniert mit oder ohne aktivierten Spatial-3D-Sound.
• Wegen der Eingriffe ins Kern-Soundscape mussten auch die Soundsets des CFM56 und des IAE V2500 stark überarbeitet werden, teils mit neuen Aufnahmen. Beide klingen laut Fenix besser denn je und enthalten subtile Layering-Verbesserungen für alle sechs Untervarianten über A319, A320 und A321.
• Active Noise Cancelling: Ein lang gewünschtes Feature kommt als vollständige Implementierung. Es lässt sich schalten, indem man das Headset aus dem Staufach nimmt oder wieder verstaut. Fenix hat nicht nur die Gesamtlautstärke gesenkt, sondern auch die tonalen Änderungen pro Layer abgebildet, bei tausenden Soundlayern.

Im Video übernehmen danach die Sounds das Reden: GPWS-Ansagen von Sink Rate über Don’t Sink bis Too Low Terrain und Too Low Flaps sowie der Autocallout-Countdown beim Aufsetzen. Fenix betont, dass das Art-Team zwar auf die NEO fokussiert war, die CEO aber sichtbar und hörbar vorankommt, inklusive einiger Performance-Verbesserungen.

CIDS und FAP: Fenix simuliert die Kabine bis aufs Klo

Neu ist ein komplettes System zum Herumprobieren: das Cabin Intercommunication Data System (CIDS) und damit das Flight Attendant Panel (FAP). Ja genau das, was ihr links an der Wand seht, wenn ihr als Passagier in einen A320 steigt.

Wie üblich bei Fenix ist es so eins zu eins wie möglich gebaut. Keine hübsche Oberfläche, auf der man ein paar Lichter schaltet, sondern eine Simulation bis auf Komponentenebene. Daten laufen vom passenden Sensor über Decoder-Encoder-Einheiten bis zu den steuernden Computern, und jede dieser Einheiten ist korrekt mit Strom versorgt und für Ausfälle und abnormale Zustände gebaut.

Thacker schickt eine Vorwarnung hinterher: Man wolle ein möglichst vollständiges Flugzeug bauen und nicht definieren, welcher Teil allein in einem Full-Fidelity-Simulator zählt. CIDS löst ECAM-Memos aus und hat Ausfalllogik und Redundanzen. Außerdem diente das Projekt dazu, neue Teammitglieder an einem überschaubaren, in sich geschlossenen Teil arbeiten zu lassen, ohne den Druck, etwas Missionskritisches anzufassen.

Die Hardware dahinter

• CIDS-Director: Die Gehirne des Systems. Sie sprechen mit weiteren Bordsystemen wie dem SDAC, den DEUs, dem Flight Warning Computer und dem FAP. Es gibt zwei, einer ist aktiv, der andere läuft als Hot Standby mit.
• Circuit Breaker: Zieht man einen der beiden Director-CBs, gibt es eine ECAM-Meldung, das System bleibt aber oben. Auch die Bootzeit samt eingebautem Selbsttest ist nachgebaut. Drückt man den CB wieder rein, gibt es also eine kleine Verzögerung.
• Kaltstart: Er sieht dadurch lebensechter aus, mit einem CIDS-Memo beim Start. Solange das System bootet, hat das Umschalten der Kabinenbeschilderung keine Wirkung, die Kabinenlichter und Schilder blinken sogar im Hochlaufen. Erst wenn das Memo verschwindet, ertönt der vertraute Gong hinter einem.
• DEUs (Decoder Encoder Units): Verteilt in der Kabine, versteckt hinter den Deckenpaneelen, in zwei Typen. Typ A kümmert sich um Passagierfunktionen: No-Smoking- und Anschnallzeichen, Kabinenlicht, Lautsprecher, Rufknöpfe. Typ B ist für Crew-Funktionen und Kabinensysteme zuständig: Türen und Slide-Druck-System, Crew-Interphone und diverse Toilettensysteme, darunter Abwasserstandssensor und -sender, Flush Control Unit, Vakuumgenerator, Rauchmelder und Frischwassersensoren. Thacker: willkommen bei der Toilettensimulation auf Schaltplanebene.

Das FAP

Das Fenster in die Welt des CIDS ist das FAP. Die meisten modernen A320 haben das Enhanced Flight Attendant Panel, und das hat Fenix gebaut. Die Oberfläche ist eine Eins-zu-eins-Nachbildung des echten FAP, inklusive der seltsamen Display-Gremlins, die das Original zeigt. Auch hier gibt es die Einschalt- und Selbsttest-Sequenz, und was sich sinnvoll als Seite anbieten ließ, wurde gebaut. Als Komfortfunktion ist das FAP außerdem als externes Gerät über die EFB verfügbar.

Virtual Purser

Bisher gab es nur ein sehr leichtes Kabinenelement in Form des Cabin-Ready-Memos. Jetzt kann man dem virtuellen Purser dabei zusehen, wie er am FAP navigiert und auf Ereignisse in der Kabine reagiert:

• Ansagen zum richtigen Zeitpunkt abspielen.
• Die Beleuchtung für Nachtflüge während des Services anpassen.
• Toiletten abschließen, wenn angebracht.
• Bei einer Dekompression den Service stoppen und eine Sonderansage abspielen.
• Die Arbeitslast hängt vom Auslastungsgrad ab. Bei mehr Passagieren dauern Kabinensicherheitschecks länger, bei denen geprüft wird, dass alle angeschnallt sind, bevor die Kabine für Start oder Landung meldet.

Airline Packs und Ansagen

• Aus dem Announcement Pack wird ein Airline Pack. Der Unterschied: Er enthält zusätzlich EFB-Hintergrundbilder und FAP-Bildschirmschoner.
• Die Sammlung alter Ansagen muss man nicht neu machen: Das System ist vollständig rückwärtskompatibel mit alten Announcement Packs.
• Neu sind kontextspezifische Tags in den Audiodateien, mit denen der Virtual Purser Ansagen passend zum Zustand der Simulation wählt, etwa bei Flügen mit Wasseranteil oder speziell bei einer A321. Tags lassen sich stapeln oder kombinieren. Mehrere Varianten einer Datei werden wie beim Altsystem weiter unterstützt. Nativ lassen sich so zum Beispiel drei unterschiedlich klingende Ansagesätze für eine A319 mit USB-Steckdosen anlegen, die nachts bei der Boarding-Betankung steht.
• Dank FAP und Virtual Purser unterscheidet Fenix nun zwischen aufgezeichneten Ansagen, die am FAP sichtbar und wählbar sind, und Ansagen, die die Crew manuell über den PA-Kanal macht und die am FAP weder sichtbar noch wählbar sind.
• Für alle, die tiefer einsteigen wollen, gibt es ein eigenes Dokument zum Thema.

Türen und Slides

Oberflächlich zeigt die Seite, ob Türen offen oder geschlossen, armed oder disarmed sind. Dahinter steckt eine Kette:

• Der Türzustand kommt von Näherungsschaltern. Sie hängen an DC Bus 1 und haben einen eigenen Circuit Breaker. Zieht man ihn, geht die Türdarstellung am FAP in einen Fehlermodus, weil der Zustand nicht mehr erkannt wird.
• Das Signal läuft weiter in den SDAC, dann in den CIDS-Director und schließlich zum FAP. Jedes Glied der Kette kann ausfallen. Das zeigt sich nicht nur am FAP, es zwingt auch die ECAM-SD-Türseite in einen eingeschränkten Zustand.
• Die Arming-Information kommt von komplett anderen Näherungssensoren, die über den Battery Hot Bus oder den DC Battery Bus versorgt werden, mit einem eigenen CB-Paar. Sie läuft durch dieselbe Kette SDAC, Director, FAP und kann auf dieselbe Weise ausfallen, inklusive Auswirkung auf die ECAM-SD-Türseite.
• Virtual Purser und Crew können Türen armen, disarmen, öffnen und schließen. Für A321-Betreiber mit eigenen Verfahren, etwa die mittleren Türen im Turnaround armed zu lassen, gibt es dazu nun eine Option.

Temperatur

Die Temperatursimulation hängt an den Auswahlen, die man oder der Virtual Purser am FAP trifft, und respektiert die Steuerlogik: Erlaubt ist ein Versatz von 2,5 °C gegenüber dem, was die Crew im Cockpit gewählt hat, samt aller Eigenheiten beim Maximieren und Minimieren des Werts. Die Daten kommen von den Zonenreglern. Läuft der Galley Extract Fan nicht oder ist er defekt, gibt es diese Temperaturen nicht, wie am echten Flugzeug, wegen Aufbau und Position des Sensors.

Wasser und Abwasser

Thacker genießt die Polarisierung der Community bei Toilettensimulation sichtlich, und die Wasser-/Abwasserseite nennt er selbst „fast Fiebertraum“. Menge des Frischwassertanks, des Abwassertanks und Status der Spülsysteme sind Teil der Simulation:

• Verbrauch und Anfall hängen von Passagierzahl und Flugdauer ab und sind an den Kabinenstatus gekoppelt. Ob die Anschnallzeichen an oder aus sind, beeinflusst die Toilettennutzung.
• Auch hier fließen Daten korrekt: Wer in der Toilette ist, löst die Flush Control Unit aus, die ein Signal über die nächste DEU an den CIDS-Director schickt. Der weist bei Bedarf den Vakuumgenerator an, hochzufahren, und befiehlt der Flush Control Unit das Spülen.
• Spürbar für den Flug: Ein leerer Frischwassertank oder ein voller Abwassertank verschiebt je nach Flugzeugtyp den Schwerpunkt marginal.
• Gewartet wird über die Failures-Seite im MCDU oder per GSX-Wasser- und Abwasserservice.

ECAM und Flight Warning Computer: Herz-OP am offenen Flugzeug

Viele haben nicht verstanden, was Fenix meint, wenn von einem neu gebauten Flight Warning Computer (FWC) oder ECAM-Engine die Rede ist. Thackers Bild dazu: Man habe die CEO auf den OP-Tisch gelegt, aufgemacht und Gehirn, Rückenmark und jeden einzelnen Nerv herausgezogen. Dann wurde alles ersetzt. Der FWC ist beim Airbus so grundlegend, dass er laut Thacker praktisch der Airbus ist. Selbst der Herzschlag des Flugzeugs, das Timing, mit dem jedes System, jeder Sensor, jede Anzeige und jeder Schalter mit dem Piloten interagiert, hängt daran.

Was sich für euch jetzt ändert und was erst später

• Die emulierte FWC-Version bleibt dieselbe wie heute. Es ist also ein Umbau hinter den Kulissen, wenn auch ein großer.
• Er schafft die Grundlage für kommende Dinge: komplettes State Saving, ein MEL-System und mehr, über das Fenix noch nicht reden will. Mit State Saving ist in dieser Version nicht zu rechnen, laut Thacker ist es aber „kein technisches Hindernis mehr“.
• Wer künftig die NEOs kauft und schon die CEO besitzt, bekommt ein kostenloses FWC-Software-Standard-Upgrade, um die neuesten Funktionen auf der älteren Zelle zu nutzen.
• Thacker rechnet vor, dass sich schon die 49,99 Dollar von 2022 weiter auszahlen.

Schneller und gleichzeitig langsamer

Ein erstes Ziel war, alles schneller laufen zu lassen, und dann wieder langsamer. Der alte FWC lief etwas zu schnell, Fenix wollte näher an die Zykluszeit des echten Geräts. Das ist bei Signalein- und -verarbeitung wichtig, weil die Timing-Spielräume schmal sind und verschiedene Signale in verschiedenen Takten ausgegeben werden. Erst maximal schnell, dann kontrolliert gebremst, so lässt sich nuanciertes Verhalten nachbilden. Dafür mussten alle Systeme an Bord synchron schneller laufen. Das sei nicht schlampig erledigt worden: Man habe so lange daran gearbeitet, dass die CPU-Last der Systeme trotz höherer Geschwindigkeit sogar sinkt.

Aural Alerts als Beweis

Am anschaulichsten wird es bei den Aural Alerts, die extrem timingabhängig sind. Zwischen dem FWC-Befehl und dem Ton im Cockpit liegen mehrere Audiogeneratoren und Hardwareeinheiten, dazu mehrere Signaltypen von synthetischen Stimmen bis Summern. Alle sind jetzt wie im Original abgebildet.

Beispiel Autopilot-Disconnect: In anderen Simulationen und selbst in Level-D-Simulatoren sind Alerts so umgesetzt, wie sie in Schaltplänen stehen, als durchgehender Dauerton. Schaltpläne und Handbücher sagen aber, was das Gerät tun soll, nicht wie die Hardware es ausführt. Im Video spielt Fenix den unfreiwilligen Disconnect auf einer alten Fenix-Version samt anderen Desktop-Produkten, dann auf der neuen Fenix und danach am echten Flugzeug. Die neue Fenix klingt deutlich anders und entspricht dem Original. Man hielt das zuerst für einen Fehler, denn weder Ton noch Schleifenlänge wurden verändert. Der Unterschied entsteht allein durch die Simulation dessen, was die Hardware dahinter tut. Thacker nennt das selbst obsessiv und unnötig, aber ein Detailniveau, das man anderswo nicht sieht.

Intermediate Callouts

Als Nebenprodukt gibt es etwas, das vielen Konkurrenten fehlt, wobei Thacker ausdrücklich FlyByWire dankt, die es kürzlich ergänzt haben: Intermediate Callouts. Der ECAM kombiniert dabei zwei Radiohöhenansagen spontan zu einer neuen. Das ist schwer auszulösen, passiert aber, wenn die Radiohöhe über einen Zeitraum nicht ausreichend abnimmt. Der FWC gerät dann in leichte Panik und sagt von sich aus, wo man ist.

Was ihr sehen werdet

• Die Formatierung vieler Memos ist deutlich besser. Man sieht den Unterschied, wenn man ihn einmal gesehen hat.
• Ein „Brain Shim“ emuliert zwei getrennt und nicht synchron laufende FWCs. Dadurch erscheinen FWC-gesteuerte Lichter und Warnungen mit kleinen, voneinander unabhängigen Verzögerungen, was man in keinem Schaltplan findet.
• Grundfunktionen und Interaktion mit dem ECAM sind besser und verhalten sich laut Fenix näher am Original als in den Full-Flight-Simulatoren. Beispiel Emergency Cancel: Der Full-Flight-Sim verhielt sich anders als das echte Flugzeug, weil er die Hardwareverzögerungen zwischen den Systemen nicht berücksichtigt. Auch die Kernlogik des Knopfes ist neu, von der Funktion bei mehreren Einträgen bis zu deren Gruppierung.
• Überarbeitet wurden das Verhalten bei ECAM-Overflows und beim Clear-Knopf sowie der Umgang mit rechtsseitigen Memos samt Regeln.
• Das Flugzeug ist voll TS1-konform (Takeoff Surveillance Version 1, wie in der CEO verbaut). Drückt man T.O. CONFIG am ECAM Control Panel, gleicht es im FMS eingegebene Flaps, Trimmung und Startgeschwindigkeiten mit den Live-Parametern ab, um die richtige Konfiguration zu prüfen. Die NEOs gehen mit dem TO2-Paket weiter.

Hochgeschwindigkeitskamera am echten ECAM

Bei der Optik hat Fenix mangels Daten das echte ECAM im echten Flugzeug mit einer Hochgeschwindigkeitskamera gefilmt, um die Aktualisierungsraten der einzelnen Anzeigen zu ermitteln. So wird die EGT mit anderem Intervall gemeldet als N1, und N1 wieder anders als N2. Die Zahlen springen oder überspringen Werte zwischen den Meldeschwellen. Der Flugsteuerungscheck zeigt es hübsch: Querruder, Spoiler, Seitenruder und THS ruckeln jeweils mit eigener Verzögerung. Sogar Power Transients, die das ECAM kurz leeren, sind umgesetzt, laut Fenix in keiner anderen Desktop-Software.

Thacker fasst es so zusammen: Der FWC allein decke alle drei Punkte ab, die man sieht, hört und anfasst. Die ganze Überarbeitung wurde mit State Saving und Persistenz im Kern der Konstruktion gebaut. Angekündigt wird dazu noch nichts, aber es sei nun „kein technisches Hindernis mehr“.

FADEC: Neuaufbau für vier Triebwerkstypen

Die komplette Überarbeitung war nötig, weil mit den LEAP und den Pratt & Whitney GTF zwei deutlich komplexere Triebwerke dazukommen. Der alte Code war ausschließlich für die CEO gebaut und hätte Einschränkungen auf die NEO übertragen. Also hat Fenix von oben neu begonnen, um am Ende vier völlig unterschiedliche Triebwerkssimulationen auf einer Plattform zu tragen. Das sind bislang rund 11 konkrete Modelle, alle mit demselben Anspruch an Authentizität.

Die Demo: Circuit Breaker mitten im Start ziehen

Das Beispiel zeigt zugleich, wie eng Logik und physische Simulation verzahnt sind und wie unterschiedlich zwei Triebwerke reagieren.

CFM56:

1. Erst CB A4 ziehen. Er versorgt DC-Strom für FADEC A und EIU-Kanal 1 von Triebwerk 1. FADEC B und der zweite EIU-Kanal laufen noch, ein Start ist also möglich.
2. Währenddessen CB R41 ziehen. Das nimmt beide FADECs und beide EIU-Kanäle vom Strom.
3. Das Triebwerk hat aber eine kleine eigene Lichtmaschine für das FADEC. Sobald es die Self-Supply-Schwelle überschreitet, beim CFM56 etwa 12 % N2, ist das FADEC wieder versorgt.
4. Die Steuerlogik hat einen Failsafe für den kompletten EIU-Verlust. Er nimmt an, dass der Master Lever an ist und das Flugzeug in der Luft, und fährt deshalb den Starter-Assisted Air Start statt eines normalen Bodenstarts.
5. Es fehlen einige Temperaturdaten, es gibt ein paar ECAM-Alerts, das Triebwerk startet aber weiter. Das hydromechanisch gesteuerte High-Pressure-Shutoff-Valve öffnet durch steigenden Kraftstoffdruck und lässt Sprit in die Brennkammer. Ergebnis: ein laufender CFM56, nur mit mehr Orange auf dem ECAM, als einem lieb ist.

IAE V2500: Das Ergebnis ist ein anderes. Das High-Pressure-Shutoff-Valve hat drei elektrische Steueranschlüsse: einen fest verdrahteten Master-Lever-Eingang, der alles andere übersteuert und das Ventil schließt, und zwei Eingänge von den beiden FADEC-Kanälen. Die FADEC-Kanäle brauchen 28 V DC vom Flugzeug, um das Ventil zu bewegen. Die Versorgung über die Lichtmaschine am Triebwerk reicht dafür nicht. Das Startventil bleibt offen, das Shutoff-Ventil geschlossen, das Triebwerk dreht munter durch. Es schaltet auch nicht auf Air Start um: Der Failsafe prüft die Fluggeschwindigkeit und erkennt korrekt, dass man nicht fliegt. Also läuft die normale Bodensequenz, und der Start wird nach ausbleibender Zündung abgebrochen.

Thacker betont, dass hier nichts herausgepickt und einzeln programmiert wurde. Das sei eine von hunderten Demos, und gerade deshalb gewählt, weil das richtige Verhalten nur bei ausreichend detaillierter Systemsimulation durchgängig entsteht. Für die NEO-Wartenden: Die Arbeit gibt Fenix tiefen Zugriff auf die Grundlagen dieser Triebwerke, mit Funktionen, die man „in due course“ zeigen will.

Was CEO-Besitzer sonst noch bekommen

• Pack-Inhibit-Logik beim Start: Timings überarbeitet, plus drei Optionen für den jeweiligen Flugzeugstandard: eine Legacy-Version, eine Pre-Service-Bulletin- und eine Post-Service-Bulletin-Version. Sie unterscheiden sich darin, wann Close-Kommandos ausgegeben werden, und im Verhalten etwa bei Crossbleed-Starts.
• IAE: Neue Option für das Pre-Start-Motoring. Das Motoring-Timeout lässt sich zwischen 30 und 50 Sekunden einstellen, je nach Ausstattung des Betreibers.
• Auto TOGA: Setzt man das Flugzeug in Flex, ohne eine Flex-Temperatur einzugeben, gibt es ein ECAM, wie bei anderen auch. Was andere nicht abbilden: Tut man 8 Sekunden lang nichts, kommandiert das FADEC volle TOGA-Leistung. Das wurde im Lebenszyklus des A320 als zusätzliches Sicherheitsnetz per operationeller Modifikation eingeführt. In der Fenix ist es per Option an- und abschaltbar, je nach nachzubildendem Standard.
• Seltene ECAM-Alerts, Warnungen und Memos: Alles, was man nur bei Fehlern oder in Ausnahmesituationen sieht, existiert am echten Flugzeug und nun auch hier, laut Fenix nirgends sonst.

Flex-Temperatur: Das FADEC schaut sich die Umgebung an

Das FADEC prüft das Umfeld und lehnt Flex-Temperaturen nach Bedarf ab, bei jedem Triebwerk und Optionssatz anders. Am Beispiel eines IAE nach Auto-TOGA-Service-Bulletin:

• Gibt man eine Flex-Temperatur ein, die 10 Grad unter der Außentemperatur liegt, gibt es ein Warn-ECAM, das FADEC lehnt den Eintrag ab. Zu sehen ist das am Thrust Rating oben rechts im oberen ECAM.
• Liegt der Wert zwischen diesem Wert und der Außentemperatur, gibt es kein ECAM. Das FADEC akzeptiert den Eintrag nur teilweise: Der Flex-Modus wird angenommen, die Temperatur abgelehnt, und das Flugzeug gibt TOGA aus, obwohl es in Flex ist. Das sieht bei der NEO anders aus als bei der CEO, mit anderer Symbologie.
• Ohne das Auto-TOGA-Service-Bulletin ändert sich das bei CEOs zu einer Ablehnung nur dann, wenn Flex unter der Außentemperatur liegt.
• Der gute alte Traktor CFM56 verhält sich davor und danach gleich.
• Auch die Datenquellen stimmen und variieren je Triebwerkstyp. Fällt bei einem CFM56 ein ADR aus, kommt diese Warnung nicht mehr, und das Flugzeug geht auch gar nicht erst in Flex. Fällt das ADR aus, nachdem Flex aktiv ist, rastet es ein und bleibt.

Zwei unabhängige FADECs

Jedes Triebwerk wird wie in Wirklichkeit von seinem eigenen FADEC gesteuert. Das führt zu ziemlich schrägen Zuständen. Zur Demonstration führt Fenix einen derated Takeoff vor, ein Feature, das später kommt, aber das Engine Thrust Disagree ECAM freischaltet, das man vermutlich noch nie gesehen hat. Es zeigt, dass FADEC 1 mit Flex nicht garantiert, dass FADEC 2 ebenfalls akzeptiert.

Der Ablauf für den Flex-Wert:

1. Angefordert: Das passiert im MCDU.
2. Empfangen: Die Anforderung wird erst gegen die Sensoren auf der Zellenseite geprüft (erstes Gate), geht an die EIU und von dort ans FADEC. Dort gilt sie als empfangen, und auch der FWC bekommt sie zum ersten Mal, sodass hier einige ECAM-Meldungen ausgelöst werden.
3. Bestätigt: Das FADEC verarbeitet die Anfrage, bestätigt sie gegen die Triebwerksseite und sendet ein Signal an die Zelle zurück. Auf dem oberen ECAM wird daraus ein Thrust Rating, basierend auf dem Cross-Engine-Status: Läuft das andere Triebwerk, wie steht sein Thrust Lever Angle, welcher Modus ist bestätigt? Weil die FADECs unabhängig sind, kann es dabei zu Uneinigkeit kommen.
4. Eingerastet (Latched): Sobald man den Thrust Lever auf das aktive Limit schiebt, hält das FADEC seine bisherigen Entscheidungen fest, egal was passiert, etwa bei einem EIU-Ausfall im Startlauf.

All diese Logik steckt hinter dem winzigen Thrust-Limit-Indikator im oberen ECAM. Es sind Randfälle in Randfällen, aber laut Thacker ein Fenster in die Tiefe des Produkts.

VNAV entmystifiziert: Es gibt nicht den einen A320-Sinkflug

Das Herzstück des Updates ist ein kompletter VNAV-Umbau und eine sehr große Überarbeitung des gesamten FMS. Thacker beginnt mit einem Abschnitt, den er „Demystifying VNAV“ nennt, bei den Airbus-Fans „Managed Descent“. Seit der Ankündigung des Rework hat es ihm zufolge einen rasanten Anstieg an Experten für vertikale Navigation gegeben. Viele behaupten absolut, wie VNAV sich verhalten sollte. Auch Piloten, ob A320 oder andere Muster, bringen berechtigte und unberechtigte Punkte vor. Für Fenix war es aufschlussreich, durch welche enge Linse viele typberechtigte Piloten manche Systeme erleben.

Zwei FMS-Typen und mehrere Optionen

Ein A320 kann mit einem Honeywell- oder einem Thales-FMS ausgestattet sein. Fenix, Flight Sim Labs und Toliss, die drei Payware-Flieger, mit denen die meisten vertraut sind, simulieren ein Thales-FMS, sodass sich direkt vergleichen lässt. Der Unterschied ist laut Thacker nicht Charakter oder etwas Immaterielles: Die Pfadkonstruktion unterscheidet sich fundamental, mit spürbar anderen Ergebnissen bei einem voll gemanagten Sinkflug. Honeywell kennt zudem drei Untervarianten:

• Standard ohne CDA.
• Optional CDA (Continuous Descent Approach).
• Optional Latched Descent als jüngste und modernste Variante.

Thales: Drop and Drag

Ein Thales-FMS regelt die Verzögerung für den Anflug auf die alte Art, bekannt als Drop and Drag oder Dive and Drive, bei Airbus Decelerated Approach. Das FMS erzeugt ein Level-Segment, in dem auf Anfluggeschwindigkeit verzögert wird. Das gilt nur für diese letzte Verzögerung. Geschwindigkeitsänderungen weiter oben, etwa wegen Restriktionen oder für die 250 Knoten auf 10.000 Fuß, werden im Sinkflug erledigt. Ob ILS, RNAV, RNP, VOR, NDB oder Sichtanflug: Das Flugzeug nivelliert zum Verzögern immer – anders gesagt: es richtet sich waagrecht aus. Je nach Spielraum bei Streckenmeilen, Wetter, Gewicht und Anflugsteilheit kann das FMS verschiedene Zielkonfigurationen für das Ende des Segments wählen. Manchmal geht es gar nicht auf, dann wirft das System die Hände hoch und erzeugt ein Too-Steep-Segment, um das Level-Segment zu erzwingen. Das Level-Segment wird immer eingefügt.

Honeywell: CDA statt Level-Segment

Auch ein Honeywell-FMS hat dieselbe Logik, aber mit einer Wendung. Level-Segmente sind in der Realität weder besonders effizient noch komfortabel und erfordern häufig Schubeingaben bei Unterschreiten des Ziels, das bei einem konservativen Profil gar nicht selten ist. Die CDA-Funktion ersetzt das Level-Segment durch einen flachen Sinkflug. Der Gedanke: Dauerhaftes Sinken von oben bis unten ist effizienter, leiser und angenehmer für Passagiere und Crew.

Beide Varianten zielen darauf, auf 1.000 Fuß in Anfluggeschwindigkeit zu sein. Die Segmente sind nicht immer lang genug, um Flaps und Fahrwerk komplett auszufahren. Sie sollen eine Konfiguration erreichen, mit der man bis 1.000 Fuß voll konfiguriert und auf Speed sein kann. Beim Non-CDA-Flugzeug kann das FMS die Level-Segmente zwischen mehreren Restriktionen aufteilen und entlang des Pfads verteilen, wenn der Platz fehlt. Mehrere Level-Segmente sind keine Seltenheit, besonders bei stark restringierten RNAV-Anflügen, und können für die Besatzung verwirrend sein. Kein Wunder, dass CDA bei Honeywell-Betreibern beliebt ist.

Latched Descent

Latched Descent ändert nicht die Profilkonstruktion, sondern die Ausführung. Airbus priorisiert im Sinkflug traditionell Geschwindigkeit vor Pfad: Das Flugzeug weicht vom Pfad ab, um die befohlene Geschwindigkeit plus/minus Toleranz zu halten. Die Latched-Descent-Option priorisiert den Pfad: Die Geschwindigkeit kann wegdriften, während das Flugzeug dem berechneten Vertikalprofil folgt, ganz egal, wie groß die Differenz ist. Für Boeing-Piloten entspricht das VNAV PATH auf der FMA.

Was das für die Praxis heißt

Bei manchen Betreibern wissen die Crews, mit welchem Optionssatz sie fliegen, bei anderen nicht. Manche haben gemischte Flotten aus Honeywell und Thales mit verschiedenen Optionen, je nach Stand des Upgrade-Zyklus. Daher das VNAV-Mysterium. Warum reden Piloten kaum darüber? Laut Thacker ist es selten, dass jemand voll im gemanagten Modus bis zum Anflug sinkt. Einige Test-Piloten könnten es an einer Hand abzählen, manche glauben, es noch nie getan zu haben. Aus einem Datensatz über mehrere hunderttausend Flüge ergibt sich: knapp unter 5 % der Flüge bleiben global in vollständig gemanagten Modi bis etwa 10 Meilen vor der Schwelle. Dazu kommen regionale Unterschiede und starre SOPs. In der Simulation, besonders offline, lässt man das Flugzeug dagegen oft machen, sodass Managed Descent dort viel mehr zählt.

Performance: Der A320 ist immer zu schnell, zu langsam oder genau richtig: je nach Airline

Thacker nimmt drei Expertenaussagen auseinander: „der A320 wird im Sinkflug immer schnell, ich brauche immer die Speedbrakes“, „er wird immer langsam und fügt Schub hinzu“ oder „er ist perfekt auf Speed, ich brauchte nie die Speedbrakes“. Alle können stimmen, alle sind lokale Erfahrungen.

• Idle-Sinkflug: Der A320 versucht standardmäßig ohne Restriktionen einen Sinkflug im Leerlauf zu berechnen und fügt auch bei Restriktionen Schub nur hinzu, wenn es nötig ist. Dafür müssen Gewicht, Geschwindigkeit, Temperatur, Wind, Höhen- und Geschwindigkeitsrestriktionen und sogar die Kabinenhöhe zur Repressurisierung gegen das Performance-Modell und die Gleitfähigkeiten in der FMS-Datenbank gerechnet werden.
• Toleranz: Weil ein perfekter Leerlauf-Sinkflug in der Realität und in der Simulation kaum zu treffen ist, gibt es Spielraum von 20 Knoten auf beiden Seiten der Zielgeschwindigkeit.
• Wind: Das FMS ist nicht allwissend. Es werden nur fünf Windstufen hochgeladen, nicht über bestimmte Wegpunkte, sondern fünf Sätze Windgeschwindigkeit und -richtung auf fünf Höhen, die über den gesamten Sinkflug linear interpoliert werden. Was dazwischen passiert, ist synthetisch.
• THR IDLE auf der FMA: Es heißt nicht zwingend, dass das Flugzeug im Leerlauf ist. Es gibt einen eingebauten Idle Factor, der ein Quäntchen Schub addiert, besonders bei sinkender Energie. So kann man THR IDLE auf der FMA sehen und trotzdem einige Prozent N1 anliegen haben oder etwas überschüssige Energie über dem Ziel mitführen, bevor es in echten Leerlauf geht. Echter FADEC-kommandierter Leerlauf wird auf dem oberen ECAM (EWD) als IDLE angezeigt. Bei den Großraum-Airbus wurde das verbessert: Dort gibt es THR DES analog zu THR IDLE am A320, während THR IDLE für echten Leerlauf reserviert ist.
• Airlines justieren: Sie können den Idle Factor erhöhen oder senken, was das FMS-Performance-Modell draggier oder glatter macht. Ältere Zellen sind draggier als neue, und Airlines setzen die Werte nicht pauschal, sondern pro Flugzeug, weil sich der Luftwiderstand je nach Lebenslauf unterscheidet. Das spart Treibstoff. Ein zweiter Hebel, der Perf Factor (bei Thacker Puff Factor genannt), korrigiert nur die Kraftstoffberechnung nach oben oder unten. Manche Airlines aktualisieren täglich, andere wöchentlich, monatlich, vierteljährlich, einige gar nicht. Manche setzen konservativ auf weniger Energie, andere aggressiv auf mehr und benutzen halt die Speedbrakes, für die sie bezahlt haben.
• DPO (Descent Profile Optimization): Airbus bietet das für alle FMS-Typen als Datenbankänderung an, die die konservativen Margen reduziert, das Flugzeug im Reiseflug länger lässt, alle Sinkwinkel steiler macht und die Fehlermarge bei der Verzögerung senkt.

Die Daten

Firmen, die für Airlines Treibstoffeinsparungen analysieren, besitzen sehr granulare Datensätze. Thacker zitiert Zahlen aus einem globalen Datensatz von hunderttausenden Flügen mit Dutzenden Betreibern, gefiltert auf passende Autopilot-Modi:

• Trotz angewandter Performance- und Idle-Faktoren brauchen 20 % der Flüge irgendwann unter 10.000 Fuß die Speedbrakes, weitere 10 % zwischen 10.000 Fuß und dem Top of Descent.
• Jeder dritte Flug braucht in einem Idle-Sinkflug irgendwann Schub.
• Die Faktoren sind von Profis täglich und pro Flugzeug angepasst. Außerdem deckt der Datensatz nur Airlines ab, die aggressiv aktualisieren und sich für die Analyse entschieden haben. Bei anderen dürfte öfter eingegriffen werden müssen.

Fenix hat darum versucht, die Mitte zu treffen und ein Verhalten zu liefern, das den Durchschnitt repräsentiert. Wer Speedbrakes oder Schub im Sinkflug braucht, muss sich also nicht wundern. Ein wichtiger Vorbehalt: Das alles setzt die fünf Windstufen im FMS voraus. Sind sie ungenau, rechnet das Flugzeug eine andere Realität, und der Sinkflug braucht manuelle Eingriffe.

Wer mag, kann Idle- und Perf-Factor selbst einstellen, die Datenbank und Idle-Faktoren werden wie in der Realität moduliert. Positive und negative Werte werden akzeptiert und real genutzt: Manche Zellen sind glatter und müssen flacher gerechnet werden. Der Trend laut Fenix: Brandneue NEOs, vor allem A321, laufen mit positiven Perf-Faktoren und werden flacher gemacht. Viele ältere EIS-1-Zellen laufen stark im Negativen und werden steiler, weil das Alter den Luftwiderstand erhöht.

VNAV-Logik: Idle- und Geometric-Segmente und der DECEL-Pseudo-Waypoint

Abseits der Verzögerungsphase gibt es zwei Sorten von VNAV-Konstruktion:

• Idle-Segment: Das FMS hält es für möglich, den faktorisierten Leerlauf durch den geplanten Sinkflug zu halten, mit oder ohne Restriktionen.
• Geometric-Segment: Das Flugzeug plottet einen Punkt-zu-Punkt-Vertikalpfad zwischen Restriktionen, der nach Ansicht des FMS nicht im Leerlauf zu halten ist. Es wechselt dann von THR IDLE/DES auf SPEED DES und gibt etwas Schub, um die Zielgeschwindigkeit zu halten. Restriktionen allein machen noch kein Geometric-Segment, oft landet man aber bei vielen Restriktionen darin.

Ein Geometric-Segment kann gleichzeitig im Leerlauf geflogen werden, denn für steile Sinkflüge wegen aggressiver Restriktionen kann halbe Speedbrake-Ausfahrt eingeplant sein. Dann gibt es zwei Meldungen:

• MORE DRAG: Erscheint, wenn das FMS ein Segment vorberechnet hat, das halbe Speedbrake braucht. Sie kann auch ungeplant erscheinen, wenn man vom Pfad abgewichen ist und das FMS halbe Speedbrake zum Wiedereinfangen der nächsten Restriktion braucht, Geschwindigkeit oder Höhe. Die richtige Handlung ist, halbe Speedbrake zu setzen und die Energie zu beobachten, bis die Meldung verschwindet.
• TOO STEEP: Selbst mit halber Speedbrake ist der Pfad laut FMS nicht erreichbar.

Beides gibt es real und beides ist in der Fenix passend umgesetzt. Manche Verfahren sind schlicht nicht für gemanagten Sinkflug gemacht und erwarten ATC-Eingriffe, weil Höhen- und Geschwindigkeitsrestriktionen Sinken und Verzögern gleichzeitig nahezu unmöglich machen.

Geschwindigkeitsänderungen im Sinkflug

Sie laufen je nach Segmenttyp ganz unterschiedlich:

• Im Idle-Segment verringert das Flugzeug die Sinkrate auf etwa 500 Fuß pro Minute und lässt Geschwindigkeit ab, um eine kommende Restriktion zu erreichen. Die Berechnung ist statisch: Das FMS rechnet die Strecke von Zielgeschwindigkeit zu Zielgeschwindigkeit, die Toleranz von plus/minus 20 Knoten ist nicht Teil davon, ein Live-Element gibt es nicht. Wer oben im Band liegt, braucht Speedbrakes, weil die Strecke nicht reicht. Wer unten liegt, bekommt zu viel Strecke und das Flugzeug braucht Schub, um im Rahmen zu bleiben.
• Im Geometric-Segment reduziert das Flugzeug nicht die Sinkrate. Es nimmt den Schub auf Leerlauf (THR IDLE auf der FMA) und lässt die Verzögerung bei der bisherigen Vertikalgeschwindigkeit geschehen. Ist ein Segment geometrisch und steil, bleibt nur die Speedbrake, um Geschwindigkeit zu ändern und die Höhenrestriktionen zu halten, denn die Kernlogik kennt keine Reduktion der Vertikalgeschwindigkeit. Deshalb darf auch die halbe Speedbrake Teil der normalen geometrischen Berechnung sein. Thacker rät, hier selbst einzugreifen. Ein paar STARs verlangen fast immer Speedbrakes, mehrere nach Heathrow nennt er als Beispiel.

DECEL: Hier ist die Fenix laut Aamir einzigartig

Bei den Level-Segmenten des Anflugs passieren Dinge, die nach seiner Aussage selbst typberechtigte Tester überrascht haben. Hier sei die Fenix nun einzigartig nah am echten Thales-FMS. Einige Konkurrenten zeigten Teile des Verhaltens, keine aber so vollständig.

• Wie das Flugzeug nivelliert: Durch eine sichtbare und doch unsichtbare Restriktion. Sie hängt an keinem Navigations-Wegpunkt, nur am DECEL-Pseudo-Waypoint, kann nicht gelöscht und nicht manuell angepasst werden. Im Flug wirkt sie wie eine Höhenrestriktion. Dreht man den FCU-Höhenwähler unter die DECEL-Höhe, wird sie, wenn nichts anderes im Weg ist, magenta auf dem PFD angezeigt. Am DECEL-Pseudo-Waypoint nivelliert das Flugzeug im ALT-CSTR-Modus.
• Unabhängig vom Verfahren: Die DECEL-Berechnung hängt nicht an Verfahren, Wegpunkten oder Datenbankrestriktionen. Fenix empfiehlt zum Vergleich einen Sichtanflug, weil er ohne Abkürzungen zeigt, was die Logik tut. Man kann das in anderen Simulationen dieser Nav-Suite selbst nachprüfen.
• Unrunde Zahlen: Meist versucht das FMS, das DECEL-Segment an eine bestehende Höhenrestriktion zu koppeln. Manchmal entscheidet es, dass der optimale Verzögerungspunkt an keiner bestehenden Restriktion hängt, und fügt das Segment exakt dort ein. „Exakt“ ist wörtlich gemeint, mit unrunden Höhenwerten. Mancher meldet das als Bug, ist es aber nicht, so rechnet das Original. Das ist laut Fenix ein Novum am Desktop und ein Nebenprodukt der nachgebildeten FMS-Rechenlogik. Selbst die Leute an den Level-D-Sims glaubten es zunächst nicht, bis Fenix es zeigte. Mit der Zeit konnten sie es auf ihren Sims nachstellen.
• Mehrere Level-Segmente: Auch sie werden laut Fenix von niemandem am Desktop vollständig unterstützt. Die Symbologie im Final Approach ist speziell: keine ALT-Restriktion möglich, aber trotzdem magenta Level-Off-Pfeile. Das entspricht nach den Tests dem Level-D-Sim und dem echten Flugzeug, und laut Thacker ist diese Kombination in keiner anderen Simulation abgebildet.

Direkte Vergleiche und Kritik an der Debatte

Fenix hat lange überlegt, ob man andere Produkte direkt gegenüberstellt, und sich dafür entschieden, weil es der fairste Weg sei, Fehlinformationen über die Simulationstiefe zu begegnen, ohne sich in vage Andeutungen zu flüchten. Man habe die Diskussion über die Avionik schließen wollen. Thacker bemängelt, dass die Beurteilung des besten VNAV meist daran hängt, ob das Flugzeug im Sinkflug Speedbrakes braucht. Das zeichne ein unvollständiges Bild. Dass etwas so Grundlegendes wie die DECEL-Pseudo-Waypoint-Logik seit Jahren nicht diskutiert werde, falle ihm ebenfalls auf. Die Zusammenfassung: Es sei sehr viel Aufwand geflossen, um von den Basics bis zu den schrägsten Eigenheiten alles des gemanagten Sinkflugs abzubilden.

FMS und LNAV: Wer Kurven nicht berechnen kann, zeichnet keine mehr einfach weg

Neben dem gemanagten Sinkflug wurde das FMS in mehreren Punkten aufgewertet: fehlende Symbologie auf der Flugplanseite, Datenbank-Holds, allgemeine Verfeinerung von Handling, Datenanzeige und Formatierung. Als kleines Beispiel nennt Thacker das korrekte Sperren von Daten auf der Fuel-Pred-Seite vor dem Triebwerksstart. Auch PBD-Wegpunkteinfügungen im Secondary Flight Plan wurden überarbeitet, damit sie der Realität entsprechen.

LNAV und VNAV sind voneinander abhängig. LNAV braucht die Geschwindigkeit aus VNAV für den Kurvenradius, VNAV braucht die gekrümmten Distanzen aus LNAV für Geschwindigkeits- und Höhenvorhersagen. Der Airbus verfolgt eine „Fly what you see“-Philosophie: Das Flugzeug berechnet und bildet seine eigene Performance auf den gezeichneten Pfad ab, und der Autopilot fliegt diesen Pfad.

• Neuer Lateral-Algorithmus: Ist die Geschwindigkeit zu hoch, übersteigt der Kurvenradius den Abstand zwischen den Legs, und der Pfad lässt sich nicht zeichnen. Der alte Algorithmus gab dann auf, übersprang den Kurvenübergang und ließ eine gerade Linie auf dem ND. Der neue hat dafür eine eigene Behandlung. Fehlende Kurvenübergänge soll man nicht mehr sehen. Wie das echte FMS arbeitet er nach dem Best-Attempt-Prinzip: Überschießt das Flugzeug einen Fix, geht er Standardstrategien durch, wie den Fix zu umgehen, das nächste Leg erneut abzufangen und zur Route zurückzukehren. Klappt nichts, zeigt er an, was er berechnet hat. Wie das Original sei er nicht unfehlbar und kann gelegentlich etwas Unfug produzieren.
• Nav-Datenbank: Die Interpretation wurde insgesamt verbessert. PI-Legs, ein eher seltener prozeduraler Kurswechsel an einem bestimmten Fix, behandelte die Fenix früher wie einen normalen Wegpunkt. Jetzt wird der Course Reversal aus den kodierten Daten der Datenbank so gebaut, wie das Verfahren ihn definiert. Beide gezeigten Pfade sind fliegbar, aber nur der neue Algorithmus trifft laut Fenix Karte und Datenbank genau.
• Holds: Ein Hold besteht aus Einflug, Racetrack und Ausflug. Der alte Code hatte die richtigen Formen, baute das Muster aber bei jedem Neuzeichnen aus der aktuellen Position neu auf, sodass es flackerte und verrutschte. Der Einflug wurde bei jeder Regeneration neu abgeleitet, die Ausflug-Geometrie war oft falsch. Die neue Fenix fliegt einen sauberen Racetrack, friert den Einflug ein, sobald er geflogen wurde, hält im Muster die richtige Geschwindigkeit und verlässt es mit einem ordentlichen Kurvenübergang.
• Laterale Offsets: Sie sehen simpel aus, aber Offset-Tracks können sich überlappen, der Algorithmus muss daher die Ecke sauber aufteilen. VNAV muss Geschwindigkeits- und Höhenvorhersagen korrekt auf diese Offset-Route anwenden, was vorher nicht richtig funktionierte. Behoben wurden außerdem wegfallende Berechnungen bei Offset plus ABeam, wackelnde Offset-Ein- und -Ausstiege und einige Logik-Durchsetzungsfehler.
• Eine Pfadquelle: Intern wurden Leitungen und Struktur so umgebaut, dass Guidance und Anzeige denselben berechneten Pfad lesen. Der gezeichnete Pfad deckt eine viel größere Performance-Hülle ab, und der Pfad, den man sieht, ist der, den man fliegt.

Thacker nennt das die bislang bedeutendste Verbesserung der Nav-Suite, im Vergleich zur alten Fenix wie zu anderen Darstellungen derselben Nav-Suite. Perfekt sei es nicht. Wer Perfektion behaupte, für sich oder andere Airbus-Simulationen, dem wolle er eine Brücke verkaufen.

Letzte Worte und Daves Bits and Bobs

Und was ist sonst noch wichtig? Aamirs Schlussworte

• Kinderkrankheiten: Es ist ein sehr umfangreiches Update, daher kann es Anlaufprobleme geben. Fenix hofft das Beste und plant das Schlimmste. Am Starttag steht das Team bereit, um besonders gravierende Probleme anzugehen. Der Schritt von rund 100 Betatestern zu mehreren hundert Mal so vielen Nutzern sei ein Skalierungsspiel, dem Betatests nie gewachsen sind, bei Flugsimulations-Addons wie bei AAA-Titeln.
• Debattenkultur: Fenix hat offen kommuniziert, dass VNAV und ECAM Arbeit brauchen. Entmutigend sei gewesen, wie Vermutungen das Feedback ergriffen und sich bei einigen lauten Stimmen von „VNAV braucht Arbeit“ zu „komplett unbenutzbar“ hochschaukelten, ohne dass sich die Software dazwischen geändert hätte. Das ersetzte VNAV sei fast vier Jahre lang in verschiedenen Ausprägungen brauchbar gewesen, wenn auch etwas aggressiv, und habe logisch in kritischen Teilen wie DECEL-Geschwindigkeitsänderungen, Höhenrestriktionen und Geometric- und Idle-Segmenten ähnlich gearbeitet wie einige der gezeigten Konkurrenzprodukte. Die Ausnahme: der häufige Speedbrake-Bedarf. Eine wesentliche Verbesserung sei es trotzdem, weil immer Luft nach oben bleibt.
• Perfektion: Man solle nicht auf sie warten. Auch das echte Flugzeug sei in vielem unvollkommen. Airbus liefere nach rund 40 Jahren weiter Software-Updates für den A320, Honeywell und Thales ebenfalls fast quartalsweise für das FMS, und das schon viel länger als Fenix.
• Der Name: Version 3.0, weil das Update Qualität, Genauigkeit und Politur in fast allen Bereichen deutlich bewegt. Es ist halb neu und glänzend, halb Fundament für künftige Arbeiten, und „größtes Update bislang“.

Daves Bits and Bobs

Ursprünglich sollte der Abschnitt anders heißen, doch Thacker hat Dave nach vier Stunden zum ersten Mal aus der Aufnahmekabine gelassen, und der läuft nun herum und macht PTU-Geräusche. Also Daves Bits and Bobs:

• Navdaten: Werden komplett anders gehandhabt. Aktualisierung geht über das MCDU, und man kann auf die vorherigen Navdaten zurückschalten. Wer kein Navigraph-Abo hat, aber Navdaten nutzen will, findet einen Knowledge-Base-Artikel auf der Website.
• ILS-Signal des Simulators: Es gibt eine Option, das vom Simulator erzeugte ILS-Signal zu nutzen, wenn Navdaten und Szenerie nicht zusammenpassen.
• IAE-Öltemperaturen: Berührten Triebwerksmodell, Panelzustände und ECAM-Arbeit, sind jetzt gelöst.
• RMP: Jeder Radio Management Panel hat nun seine eigenen lokalen Standby-Frequenzen. Dave hat es sich mit MS Paint erklären lassen und weiß nur: Es ist behoben.
• Cockpittür: Der hohe Piep oder Einzelpiep beim Start ist das neue Audio des Cockpittür-Verriegelungssystems. Dazu gibt es einige Optionen in der EFB.
• GSX: Fenix synchronisiert seinen Zustand mit dem GSX-Menü, Bodendienste lassen sich dort oder über die EFB anfordern.
• TCAS: Ein paar seltene Fälle behoben, in denen das eigene Flugzeug zum TCAS-Ziel werden konnte, was Dave in Kombination mit TCAS-AP für ziemlich aufregend hält.
• Nächste Flughäfen: Mehrere Fixes an Logik und Formatierung der Closest-Airports-Seite.

Das komplette Changelog soll später folgen. Fenix hätte das Update gern in kleinere Häppchen zerlegt, schon wegen Thackers Haaransatz, aber praktisch alles hängt an einem der großen Umbauten. Zum Schluss dankt das Team der Community und lobt jeden, der das im Video versteckte NEO-Easter-Egg entdeckt hat.

Und die NEO? Termin gibt es keinen, Hinweise reichlich

Ein Datum für die A32Xneo nennt das Video nicht, und für Version 3 der CEO auch nicht. Aber der rote Faden zieht sich durch die ganze Präsentation: Vieles in Version 3 stammt aus dem Aufbau der NEO und dient ihr zugleich als Fundament.

• Triebwerke: Das neue FADEC trägt auf einer Plattform vier Triebwerkssimulationen (CFM56, IAE V2500, LEAP, Pratt & Whitney GTF), bislang rund 11 konkrete Modelle.
• FWC und TO2: Die NEOs bekommen die erweiterte Takeoff-Surveillance (TO2). Wer NEO und CEO besitzt, bekommt ein kostenloses FWC-Software-Upgrade für die CEO.
• Sound: Das neu gebaute Soundscape orientiert sich am kommenden NEO-Sound.
• Weitere Features: State Saving, MEL-System und derated Takeoff sind angekündigt, ohne Termin.

Gut, das war viel Text. Wer lieber Sofa und Video bevorzugt, hier ist nochmal das Video zum Nachsehen: